MQTT command topic, state restoring etc

[kevinkk525]

I'm using mqtt for everything from sending sensor readings to controlling leds and more complex stuff.
This always relies on a command topic like home/<device-id>/led/set to which a status change request like ON is sent and
a state topic like home/<device-id>/led to which the device publishes the current state after executing the request.

This is pretty much the standard right? These topics are also used by home-assistant for controlling stuff.

Now with microcontrollers it can always happen that they are being reset and have to acquire the current state of the topic to restore the state they were in before the reset. Therefore the state topic is always published as retained, so the device can subscribe to this topic temporarily to get the current state and restore itself according to it.

If however a state change request on the command topic was sent during the reset or deepsleep then the device would need that information as well, otherwise the request would be lost. Currently that's how I handle things but I don't think it's the best way.
However to change that, I'd need to publish the state change request to command topic as retained as well.
This leads to the following situation:
- microcontroller resets
- subscribes to state topic and restores the state
- unsubscribes to state topic
- subscribes to command topic
- tries to set the new state
This is not different if command topic is retained or not.

This also means that if an impossible state change is requested as a retained publication, the microcontroller will try to execute that request every time it resets. Therefore it has to be ensured that such change requests can't result in a microcontroller reset as it would then continuosly reset itself.

What do you think is the best approach to restoring the device to its former state and not losing a state change request?

[kevinkk525]

Am I the only one trying to restore a microcontroller's state using mqtt after a reset?

[pfalcon]

This may be because this is the MicroPython forum, whereas you seek a consult with MQTT usage. I'm sure it has its own forums.

[pythoncoder]

Quite - it is rather specialised and I'm also unclear about the use case. If I were wanting to save state I'd use local flash.

[kevinkk525]

ok thanks for your answers. Guess I should ask there then as obviously not many have this usecase here.

@pythoncoder: restoring local state from local flash would require saving each state change to a file. That surely wears down the flash fast whereas the state is available as a retained message over mqtt anyway.

[loboris]

restoring local state from local flash would require saving each state change to a file. That surely wears down the flash fast whereas the state is available as a retained message over mqtt anyway.

If you have your own remote server (and it is cheap and easy to create one in the cloud), you could simply save/restore your state data to the server using http get, post or put or use FTP to save them to the file, then read them back when needed.
It would be simpler, faster and probably more reliable.

[kevinkk525]

Thanks for the ideas. I was actually not looking for an alternative solution that would make the code even bigger and more complicated by introducing new ways of saving/restoring information but was curious in how it could be best done using the information already available when using mqtt. But I guess my questions are way too specific to mqtt and not commonly implemented in micropython world.

[pythoncoder]

...restoring local state from local flash would require saving each state change to a file. That surely wears down the flash fast whereas the state is available as a retained message over mqtt anyway.

True. The optimum solution depends on how frequently you need to save state and how important it is to be able to restore the latest version. Any solution that depends on WiFi and the internet carries some risk that an outage happens at just the wrong time. Re flash you need to figure out how long it will take to get to 10K updates.

If you do decide on an internet save I would think MQTT retain is as good a way as any; possibly better than some as you have the benefit of qos==1.