whaleygeek
commented
8 years ago Also from #63 :
commanded state? (did we ask it to be on, when did we ask?) reported state? (did it tell us it is on, when did we learn it?)
overall device state have we seen this device this run? when did we last hear from it? when did we last talk to it? when do we expect to next hear from it?
(note, inner variables might have two versions for some devices, the requested value and the confirmed value. If they are different, it means might still be waiting for a reply, so can't guarantee the command was received yet)
Split out from #63
It would be useful to know the last state of a device (e.g. if it is a tx and rx device, knowing that the switch is actually on, or that it is off but commanded to on (and therefore not completely known yet) could be useful.
Sockets for two way devices could have a 4-state state machine, modelling the transient states, in order to be helpful to an added layer of retry logic later. e.g. if the last reported state was on, but the last commanded state was off, and more than 10 seconds has expired with no report, the message could be repeated again until a report comes out with the switch state as now off.
This will improve resilience on what is essentially an unacknowledged radio medium.