v1.1.4

• A lost command gets a pause, then up to two more tries (#14). 1.1.3 on a box with ten fixtures: of 300 power commands in bursts, 4 were lost on the air and all 4 recovered by the re-send; of 280 brightness commands, 6 were lost, 5 recovered, and 1 was lost again on its second try and stayed wrong. The bench showed why a second try fails so much more often than a first: the box sent it the instant it heard the fixture's status reply, and the fixture goes on repeating that reply for a moment and does not listen meanwhile. The next try now waits 150 ms after the reply, and a command may be tried three times in all instead of two (Chris's decision on the issue; he is not concerned about the amaran-app override, which needs a tap in the app within about a second of a Home Assistant command). While a try is waiting, the stale value is not shown to Home Assistant, and a new command from outside drops the waiting try and is planned against what the fixture last reported, so a late "off" can never undo a newer "on". Evidence, dev board with a P60c, a bench-only build throwing away two commands in a row out of every seven so that a lost command's first re-send is lost too: without the wait, 6 of 130 commands ended wrong although the third try was really transmitted (0 to 6 ms after the reply); with the wait, 130 commands, 57 dropped, 54 re-sent, none gave up, none ended wrong. A lost "off" followed by an "on" 300 to 620 ms later, 17 runs: no "off" was attempted after the "on". Released code, nothing dropped: 100 mixed commands and 15 slider drags (150 commands) with no re-send and no wrong state; 64 pairs of quick color changes with 1 re-send and no wrong state (a real loss or a late reply, not told apart; either way the latest command was sent once more). Not measured yet: the ten-fixture burst on this release.

v1.1.3

• A command lost on the air is sent again (#14). Light commands go out unacknowledged, and when many lights change together, as a scene does, about one in a hundred never reaches its fixture (measured on a box with ten fixtures on 1.1.2: 9 of 680 brightness commands and 3 of 300 power commands, one of them a light that stayed on after "off"). The box already asks each fixture for its state 300 ms after a command. It now reads that first reply as a confirmation: a light still off after "on" or on after "off", another brightness than was sent, the other color mode, or exactly the look the fixture had before the command means the command was lost, and it goes out again, once, with a log line (fixture 3: look command did not arrive; sending it again). If the second try fails too, the fixture's own report stands, as before. A fixture rounding what it was sent (whole-percent brightness, #11, or a rounded color temperature) is not a loss and is not re-sent. One consequence, accepted by Chris: a change made in the amaran app in the same half second as a Home Assistant command can be overridden by the second try. Looks are now compared as the wire carries them, so a color-temperature request less than 10 K from the current one sends nothing. Evidence, dev board with a P60c. With every fourth command thrown away on purpose (a bench-only build): 30 mixed commands, 11 dropped, 11 re-sent, none ended wrong; 16 pairs of color changes 150 ms apart, 9 dropped, the 4 that mattered re-sent, none ended wrong. With the released code and nothing dropped: 100 mixed commands, 15 slider drags (150 commands) and 16 color pairs produced no re-send and no wrong state; Identify still restores the light. Not measured yet: the ten-fixture burst, which only a production box can run, after this release.
• A light is far less likely to stay unavailable after the box restarts or updates (#10). ESPHome collects state changes for 100 ms before sending them, and when the box shuts down it sends its disconnect notice first and the waiting states a few milliseconds after. Home Assistant has by then marked every light unavailable and its cached states stale; it takes the late state as that light's fresh one, changes nothing on screen because the light is unavailable, and after the reconnect drops the identical state as a duplicate. The light, and its green/magenta number with it, then stays unavailable until its state changes or the entry is reloaded. Which light is hit is chance: whichever fixture's 15-second status reply lands in the 100 ms before a shutdown. The box now sends states at once (api: batch_delay: 0ms), so in normal running nothing is waiting when it shuts down. This is a mitigation, not a guarantee: ESPHome still queues a state when the connection is backed up or still sending its first full set after a connect, and such a state can follow the disconnect in the same way; the complete fix belongs in ESPHome's shutdown (send what is waiting, then the disconnect notice). Evidence. A box with ten fixtures on 1.1.2, 40 restarts: Home Assistant's recorder shows 7 lights left unavailable; in the 20 restarts that were also watched by a second API client, the 3 stuck lights each match, to the fixture and the millisecond, a state packet received at the instant of the disconnect. The dev board, one fixture, with the race provoked on purpose (a status request timed just before a restart): on 1.1.2 Home Assistant's recorder shows the light stuck after 4 of 10 restarts; with the change, 0 of 20, and the second client saw no state at or after any disconnect. Not measured: the change on a box with many fixtures.

v1.1.2

• A light set to 15 % stays at 15 %. Some fixtures keep only whole percent and cut the rest off: Home Assistant's 15 % went out as 14.9 %, the fixture kept 14, and the slider sprang back (#11). The box now learns this from the fixture's own reply. The first time a reply comes back cut to a whole percent, the box marks that fixture, re-sends the whole percent Home Assistant shows, and sends whole percents to it from then on, so the 14 is never shown. Nothing is stored (it is relearned after a restart, on the first command) and nothing is probed (only commands someone actually sent). The lowest slider step goes to such a fixture as 1 % instead of 0.4 %, which it would have kept as 0. Fixtures that keep fractions are sent exactly what they were sent before. Proved on the dev board with a P60c: 14.9 % asked, 15 % read back and held, with the log line fixture 0 keeps whole percent only.

v1.1.1

The Edit page opens with the box's fixtures. Before any fetch, the page lists the fixtures the box already holds, with the live dot and a working ID button on each, so you can flash a light to tell which is which right after a Save. Those opening rows cannot be checked and Save stays off until you fetch from your account or open the database; a fetch replaces them with today's list and its new, renamed and gone marks, as before. Page only; the firmware is unchanged beyond the embedded page (#3).

Also in this release: the amaran B7c bulb joins the tested fixtures.

Boxes on 1.1.0 see this release as an Update row on their Home Assistant device page within an hour; press Install. Boxes on 1.0.x update once from the flasher page (erase unchecked) or over the air, and get the feed from then on.

Full Changelog: v1.1.0...v1.1.1

v1.1.0

Full Changelog: v1.0.1...v1.1.0

v1.0.1

Full Changelog: v1.0.0...v1.0.1

v1.0.0

Full Changelog: https://github.com/clwill/amble-home/commits/v1.0.0