Add implementation details and other things #200
Conversation
I stumbled over this in a comment in one of the discussions. The specification is pretty vague about this at the moment. So I added a sentence that makes this requirement more explicit and less hard to miss.
This gives controllers the guarantee that as long as a device is in any of the "operational" states, they can assume that the MQTT structure of that device won't change. This also implies that each time a device goes back online, all nodes and properties must be re-checked for any changes.
In future, when referring to QoS levels, use: - "At most once (0)" - "At least once (1)" - "Exactly once (2)" Closes #196
spelling fix
There was a problem hiding this comment.
For device reconfiguration, I am not sure there is a requirement for the device to go offline or to change its state to init? @Thalhammer ?
|
Thanks for correcting the typo. Currently, the convention doesn't say anything about any changes or reconfiguration. I just thought it would make writing Homie-Controllers easier if they didn't have to be aware of any device changes all of the time (It may also make writing libraries easier). I remember some discussion about adding an explicit |
|
I think that makes sense. I'll let @Thalhammer weigh in on the proposal before approving. |
convention.md
Outdated
| * A device may try to restore its state using MQTT. This can be done by subcribing to the respective channels. | ||
| An alternative way is to recover the state from other MQTT channels that are external to the Homie specification. | ||
| This is not a recommended approach though, because retained messages are only sent by the broker in response to a new subscription. | ||
| So if a device doesn't reconnect with a clean session, then the retained messages won't be resent. |
There was a problem hiding this comment.
If a device connects with a non clean session it is assumed to "know" what happend in the last connection (mqtt kind of defines this). This means it should still know the retained values sent. If there is no persistence it should really be connecting with clean session set.
There was a problem hiding this comment.
I'm sorry, but I don't understand. What exactly is a "clean session"? What exactly is wrong about the paragraph and what should a more correct version?
My motivation behind this was to say that this approach at restoring state is a bad idea, and to explain why.
There was a problem hiding this comment.
MQTT supports keeping sessions while the device is offline.
If you connect and request a clean session you will get one that looks as if you never connected before.
However if you dont request a clean session the broker will restore all subscriptions you had the last you where connected. It will also deliver all messages sent to a subscription with qos 1 or higher while the device was offline.
You would normally connect with a clean session if your device state is lost (like after a reboot without persistent storage, or after a reset) and connect to an existing session otherwise if you're device still knows what state its world is in (like a connection drop/reconnect).
The only difference is that with an existing session you dont get retained topics unless you unsubscribe and resubscribe them again or they changed while the device was offline. Also there is no need to subscribe if you have an existing session as the broker keeps subscriptions alive.
There was a problem hiding this comment.
@homieiot/involved in my implementations, the Homie devices know their state ie on/off, dimmer percentage, temperature etc. Is there a situation where a device would not know it's own state and need to restore a value?
As part of other discussion regarding QoS, the Homie spec probably needs to address controller set messages that are not delivered in a timely fashion. Part of our discussion in #150
There was a problem hiding this comment.
@mjcumming The section I wrote about this is limited to settable properties that can't easily be recovered. Think of music players for example. Or in my case, a light effects controller.
I spent two hours reading issues and discussions so I thought I may as well put another two hours into writing down their conclusions (or at least what I think).
Any of the commits may be discussed separately and I'm open to create a distinct pull request for each if there's need for it.
This addresses topics from #150, #51, #148 and probably a few others.