Repository navigation
Fix the firmware reload, handshake faults and unusable versions - #50
Merged
Merged
Conversation
Varitras
commented
Nov 4, 2026
Varitras
commented
Owner
- A firmware update installed through Home Assistant could be reported as failed although it worked. The reload for the new firmware now waits for the install to end and for a standing connection with a complete status.
- A handshake that lacks a field ends the attempt and is retried. Setup names the field, and the debug log does when it lasts. Only a sign-in scheme the client does not know stays a refusal.
- A firmware version reported empty, blank or not as text is ignored: the last good one stays, nothing reloads, and a blank version is no longer offered as an update.
- Text the charger sends with a refusal is shortened to one line and has long numbers masked.
- A scripted charger behind the real client, hub and entry tests whole sequences of connections at the shipped timings.
Started from inside the push, the unload closed the connection a firmware install was waiting on, and tore the hub down under the running dispatch.
A missing or mistyped field ended in a timeout without a cause, or in an answer built from an empty secret.
A refusal's message, an unknown hash name and a command's refusal went out as sent: a serial in them, line breaks and any length.
A scripted charger behind the real client, hub and entry: one unusable handshake must not end the reconnecting.
Refusing it for good left a charger that was only starting up unavailable until a manual reload, behind a repair notice that did not apply.
The hub starts an install and sees it end, so a wait for that end belongs there, not in a flag the entry reads off the client.
With backoff and pause set equal the reader took the connection, so the path an install really takes went untested.
The new version can arrive with the status complete: the reload then closed the connection the install waited on, or ran into an outage with a reconnect under way.
A setup that found none took the first report for a change, and reloaded in a loop if a delta ended every status early.
Only a name the client does not know is a refusal. The reason for retrying now reaches the debug log, the one place left for it.
An empty or numeric report counted as a version: it reloaded on its own, and in a loop if every status carried it. A blank hash counted as a name in the same way.
The line for each reconnect showed None on every ordinary outage.
It kept a rule of its own: after an unusable report it showed no version, or a blank one, while the rest went on with the last good one.
Who connects first is a race, so one install says nothing about it.
A blank onv showed an update, and installing it sent the blank to the charger.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.