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.