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.