How to ensure a repeateable read across topics?

[vpopescu]

I apologize if this is the wrong forum, I am trying to get clarification on the spec. Is there any sort of implied transaction support I can leverage?

The reason I'm asking is because I'm looking at this example:

homie/device123/$homie 4.0
homie/device123/$name My device
homie/device123/$state ready
homie/device123/$extensions 
homie/device123/$nodes mythermostat

homie/device123/mythermostat/$name My thermostat
homie/device123/mythermostat/$properties temperature

...where it takes 8 topics for the publisher to describe itself.

Problem is, as a subscriber, how do I ensure a repeatable read of the device "picture", given that there is no ordering specification, and no definition of when the publisher is done describing itself?

thanks in advance! TBH I have not yet written the code for it, I'm just trying to understand how i'd implement reliably consuming a device's self description when it comes online, especially if it changes over time (for example, let's say the user changes the $name while it's online). I am hoping someone could suggest a proper pattern.

[peterhoeg]

That's what state is for: https://homieiot.github.io/specification/#device-lifecycle

[Thalhammer]

You are not supposed to publish $state with ready right at the start. Instead publish $state with init and after you published all info about your device publish a ready state of ready.

MQTT does provide message ordering as long as the qos is the same for all messages. I.e. The ready message will receive last.

[vpopescu]

Thanks, I think I understand. At least for TCP transport, where the there is guarantee of ordering. If going over UDP or something else, maybe not, but I'll figure something out.

Thank you for your answers! You can close this question if needed.