Repository navigation
SolarLens v2.5.0
Renewing and updating a relay now shows nothing when nothing needs doing.
Changed
- The login check runs hidden, and a window opens only when a login is
needed. Since 2.4.0,renew-solis-login.cmdand every re-run of the
installer opened a visible Chrome window to check the saved SolisCloud login,
even when it worked, which is most weeks. On a machine that needed nothing,
a browser appearing and a terminal waiting looked like something going
wrong. Both now check in a hidden browser first. When the login works, a
reading goes through and nothing appears. When SolisCloud wants a login, a
window opens for it and closes itself once a reading has been sent. The check
also skips the alarm history and period totals, so it takes about twenty
seconds instead of a minute; the background relay started straight afterwards
reads them. - The
.cmdwindows close themselves when the run worked.
renew-solis-login.cmdandsetup-relay.cmdused to end on "press any key",
and a personalisedsetup-solarlens-relay.cmdwaited twenty seconds. All three
now close five seconds after success, and stay open only after a failure, so
its reason can still be read. - The installer skips what is already in place. Dependencies are installed
only whenpackage-lock.jsonchanged since the last install, and a relay task
someone disabled is left disabled rather than switched back on. Its.dev.vars
now saysRELAY_HEADLESS=1from the start.
Added
- The installer installs Google Chrome when it is missing, with winget, as
it already did for Node and Git. It used to warn and carry on, leaving a relay
that could not start a browser. RELAY_SKIP_EXTRAS=1, and distinct exit codes for a single run
(RELAY_ONCE=1):0a reading went through,3SolisCloud wants a login,
1anything else.
Fixed
- A relay with no working login could report success. It checked for the
login page once, three seconds after opening the portal. Measured with no
login at all, the portal stays on the plant page for about three seconds and
moves to its login page between three and five, so the check could miss it.
The cycle then sent no reading, logged the timeout as a per-plant error, and
reported success, and a single run told the installer a reading was through.
The relay now watches until the plant list loads or the login page appears,
and a cycle that sends no reading counts as failed. A login lost part-way
through a cycle is reported as a login to renew. - The background relay can no longer show a browser window.
scripts\relay-hidden.vbsforcesRELAY_HEADLESS=1for the relay it starts.
Before, it followed.dev.vars, where a0left by a login done by hand, or
by an installer run that stopped part-way, put a Chrome window on screen at
every logon. - A relay can no longer leave its browser open when it exits. If Chrome
does not close within fifteen seconds, the relay closes it the hard way. - A relay attached to your own Chrome (
RELAY_CDP) is no longer refused as
having no saved session when run hidden. renew-solis-login.cmdandsetup-relay.cmdno longer trip over their own
update. Both run a script that pulls new code, and that can replace the
.cmdfile itself while it is still running. cmd reads a batch file a line at
a time and carries on from the same byte offset in whatever the file now
says: in a test, a file rewritten under a running batch went on to run half a
line as a command. Each is now one parenthesised block, which cmd reads whole
before running any of it. This protects updates from 2.5.0 on; the files in a
2.4 checkout are still the old shape, so move a computer to 2.5.0 with
setup-solarlens-relay.cmd, which lives outside the repository.
Deploying: nothing to deploy; the Worker and the dashboard are unchanged. Move each relay computer to 2.5.0 by double-clicking setup-solarlens-relay.cmd, not renew-solis-login.cmd: the 2.4 copy of renew-solis-login.cmd is replaced by this update while it runs. After this update, either is safe. Regenerate setup-solarlens-relay.cmd with scripts\make-laptop-installer.ps1 for its five-second close. The full entry is in CHANGELOG.md.