Stabilise UI When Changing State for Non-NASA Devices #114
Conversation
…ommand and before it has been processed by the AC device.
|
Looks pretty good. I need similar code for the nasa protocol. Do you have any ideas how we could abstract the resending parts and the parts like this into its own class to both protocols could use it, but without making it to complicated? |
|
@bzumik1 I I remind correctly, you have also ask for this. Could you please try the main branch and check if it helps? |
I'd recommend first checking whether the NASA protocol requires controller registration, and whether outdoor units send a "request_control" type of message, like Non-NASA does. If it's much the same, that probably helps to keep things simple, as the high-level logic between the two protocols is basically the same (just the packet format differs). In which case, I'd probably re-work the "protocol" source to handle the message queue and resending, but have it use a new Message class/objects instead. The Message class can represent a NASA or Non-NASA packet. For example, have "RequestControlMessage", "ControlMessage", "ControlAckMessage", "StateUpdateMessage", etc., for each. NASA and Non-NASA subclasses could handle the actual packet format reading/generation for each protocol. If NASA behaves quite differently from Non-NASA, then it's probably not worth the effort initially and I think just duplicating the queue/resending logic and modifying it for NASA would be the way to go until further down the track. I'm afraid I don't really do much work with C++ (I mostly working in Swift and C these days), so I'm really not sure what is considered best practice in the C++ world for a situation like this. I'm sure you have a much better idea than I do of how to tackle it 😊 |
If a state update comes through after a control message has been sent, but before it has been acknowledged, it should be ignored. This prevents the UI status bouncing between states after a command has been issued. This addresses #53 for Non-NASA devices.