You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Release 2.11.0: the relay finds SolisCloud's moved plant page, and logs in by itself - #35
No Solis reading has reached the dashboard since 15 October. Three faults in the relay:
SolisCloud moved its plant page, from /station/stationDetails/generalSituation/<id> to /overview/plantStation/details/overview/<id>. The relay kept opening the old page and waited every cycle for figures that never came - with a valid login or without.
The relay died and stayed down. When a page failed to open at startup (no network yet, just after logon), a wait was left unhandled and ended the whole relay about 30 seconds later. Windows' "restart on failure" does not cover that, so it stayed down until the next logon.
The month and year totals stopped. The chart's "previous year" button is gone, and the failed click threw away the totals already read.
What changed
The relay opens the new plant page first, and the old one only if the new one sends nothing.
Every wait is handled, and a failure nothing was waiting for is logged instead of ending the relay. Setup adds a check every ten minutes that starts the relay again if it has stopped.
The walk back through earlier years stops where the button is missing and keeps what was read.
With SOLIS_USERNAME and SOLIS_PASSWORD in .dev.vars, a hidden relay whose login has run out logs in again by itself, still hidden, ticking the agreement box. A window opens only if SolisCloud asks for a puzzle or a code. At most one attempt an hour. The laptop installer carries the login, and setup writes it to .dev.vars.
CHANGELOG, README, .dev.vars.example and docs/handoff.md describe all of it.
Release 2.11.0: version in package.json, its lock and the guide; the guide's "What is new" list; the changelog's Unreleased section filed as 2.11.0. It is 2.11.0, not 2.10.1, because main already holds three additions since 2.10.0 (the guide icon, Historical Data one system at a time, the new-version notice).
How it was tested
Live against SolisCloud: a visible run after a fresh login, then a hidden run that sent a reading, the day's chart, devices, alarms and the period totals.
A hidden relay on an empty profile, with no login, logged in by itself in about ten seconds with no window.
Unit tests (401), type check, the guide's end-to-end tests, the privacy and attribution guards, and the release-notes script for 2.11.0.
After merging
Approve the production deploy.
Actions -> Release -> 2.11.0.
On each relay laptop, run the Desktop setup-solarlens-relay.cmd: it pulls main, saves the login, registers the ten-minute check.
…t log in by itself
- SolisCloud moved the plant page to /overview/plantStation/details/overview/<id>;
the relay opens it first and keeps the old page only as a fallback.
- A page that failed to open no longer ends the relay: every wait is handled,
and a failure nothing waited for is logged. Setup adds a check every ten
minutes that starts the relay again if it has stopped.
- The period totals keep what they read when the chart's "previous year"
button is missing, instead of throwing it away.
- With SOLIS_USERNAME and SOLIS_PASSWORD in .dev.vars, the relay logs in by
itself, hidden, ticking the agreement as the owner asked; a window opens only
if SolisCloud asks for a puzzle or a code. One attempt an hour at most.
- The laptop installer carries the login and setup writes it to .dev.vars.
- CHANGELOG, README, .dev.vars.example and the handover describe all of it.
Version 2.11.0 in package.json and its lock, and in the guide, whose "What is
new" list now describes this release: SolisCloud readings again, the relay that
logs in by itself, the Guide button, Historical Data one system at a time, the
new-version notice and pages no wider than a phone. The changelog's unreleased
work is filed under 2.11.0, with its compare link.
2.11.0 rather than 2.10.1: besides the relay fix, main already holds three
additions since 2.10.0.
… the ten-minute check during setup
- The window that opens after a refused hidden login is filled in but no
longer presses Login itself: the hidden attempt was the hour's one try, and
sending the same login seconds later made it two.
- Setup writes SOLIS_USERNAME and SOLIS_PASSWORD in single quotes, and the
relay, setup and the installer maker each take off one matching pair and
nothing else, so a password beginning or ending with a quote or a space
arrives as typed.
- Setup and renew-solis-login switch the task off while they run a relay of
their own and back on afterwards, so the ten-minute check cannot start a
second relay that closes the login browser.
- CHANGELOG, README, .dev.vars.example and the handover say so.
Prevent maintenance scripts from bypassing login cooldowns
agent/solis-relay.mjs:378
The maintenance scripts still bypass the hourly login limit through this visible path. After a rejected hidden login, closing its fallback window returns exit code 3. Both setup-relay.ps1:384–401 and renew-solis-login.ps1:120–125 then launch a fresh visible relay, which calls fillLogin() here with submission enabled. The same refused credentials can therefore be submitted again within seconds, despite closing the window meaning “not now.” Carry the attempt/cancellation state into the maintenance fallback and make it prefill-only, or persist and enforce the cooldown at every automatic submission.
Setup and renew-solis-login stopped the relay after switching its task off but
before the try whose finally switches it back on, so an error while stopping
left the task off for good - and the next setup took it for one paused on
purpose. The stop is now inside the try in both.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Login throttling can be bypassed, and fresh installations still open a browser unnecessarily.
No open issues 🎉
3 previously missed issues
In code that hasn't changed since last review
Use hidden login on fresh profiles when credentials are available
agent/solis-relay.mjs:129
Setup does not use this new hidden-first-run capability. On a fresh laptop, scripts/setup-relay.ps1:374–402 skips the hidden check when the profile has no Default directory and launches with -Visible, even when the installer supplied valid credentials. Chrome therefore opens without any puzzle or code, contrary to the promised hidden setup. Allow setup to try the hidden run when credentials are available, and update the equivalent empty-profile branch in scripts/renew-solis-login.ps1:113–127.
Prevent headed fallback from resubmitting credentials
agent/solis-relay.mjs:378
The headed branch still submits automatically, unlike the prefill-only loginInWindow() fallback. Setup (scripts/setup-relay.ps1:385–402) and renewal (scripts/renew-solis-login.ps1:122–127) launch a fresh headed process after a failed hidden check. If the hidden login is rejected and the user closes its window, this call submits the same credentials again within seconds, bypassing the hourly limit. Leave headed maintenance runs prefilled but unsubmitted.
Persist hourly login cooldown across relay restarts
agent/solis-relay.mjs:448
The hourly cooldown exists only in memory. Restarting the relay after a rejected login resets lastLoginAt to zero, so another hidden run can submit the same credentials within the hour. This can happen on a setup rerun or when the ten-minute task restarts a stopped relay, weakening the stated account-lockout protection. Persist the last automatic attempt beside the browser profile, check it before submitting, and record it before clicking Login.
…idden
- The time of the last automatic login is kept in a file in the relay's
profile and written before Login is pressed, so a relay started again by
setup, renew-solis-login or the ten-minute check cannot send a refused
password a second time within the hour.
- A visible run fills the saved login in and leaves Login to the person at the
window, as the window after a refused hidden login already does.
- Setup and renew-solis-login try the hidden run first on an empty profile too
when the SolisCloud login is saved, so a new laptop opens a window only if
SolisCloud asks for a puzzle or a code.
- CHANGELOG and the handover say so.
Decode .dev.vars as UTF-8 before generating installer credentials
scripts/make-laptop-installer.ps1:61
For a BOM-less UTF-8 .dev.vars, Windows PowerShell 5.1's default Get-Content decoding can corrupt non-ASCII credentials such as pässwörd. Base64 then preserves the corrupted value, so the generated installer supplies a different password from the one the relay reads as UTF-8. Read this file explicitly as UTF-8 before extracting the credentials.
Read existing .dev.vars explicitly as UTF-8 in setup
scripts/setup-relay.ps1:277
When setup reuses credentials from a BOM-less UTF-8 .dev.vars, Windows PowerShell 5.1's default Get-Content decoding can corrupt non-ASCII characters. These fallbacks then use the corrupted values, and setup writes them back to the file, breaking automatic login. Read the existing file explicitly as UTF-8, matching the relay's reader.
- When the relay cannot record the time of an automatic login, it no longer
sends one: the hourly limit would not hold, so the login goes to the window,
filled in but not sent.
- Setup, make-laptop-installer and rotate-tokens read .dev.vars as UTF-8.
Windows PowerShell 5.1 otherwise reads a file without a byte-order mark in
the local code page, which garbles a password with letters outside ASCII -
carried into the installer, or written back by setup and rotate-tokens.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What broke
No Solis reading has reached the dashboard since 15 October. Three faults in the relay:
/station/stationDetails/generalSituation/<id>to/overview/plantStation/details/overview/<id>. The relay kept opening the old page and waited every cycle for figures that never came - with a valid login or without.What changed
SOLIS_USERNAMEandSOLIS_PASSWORDin.dev.vars, a hidden relay whose login has run out logs in again by itself, still hidden, ticking the agreement box. A window opens only if SolisCloud asks for a puzzle or a code. At most one attempt an hour. The laptop installer carries the login, and setup writes it to.dev.vars..dev.vars.exampleanddocs/handoff.mddescribe all of it.package.json, its lock and the guide; the guide's "What is new" list; the changelog's Unreleased section filed as 2.11.0. It is 2.11.0, not 2.10.1, becausemainalready holds three additions since 2.10.0 (the guide icon, Historical Data one system at a time, the new-version notice).How it was tested
After merging
setup-solarlens-relay.cmd: it pullsmain, saves the login, registers the ten-minute check.