Describe the problem you have/What new integration you would like
Restoring data from flash puts our device in risk with flash writes. If we want to reduce this risk, we must sacrifice some recent data. Restoring data from RTC is limited and not surviving a power failure.
What if the state of selected components could be restored from the mqtt broker?
Please describe your use case for this integration and alternatives you've tried:
This would be usefull for storing component data where is important to recover the latest state, like the position of an actuator, a counter, an integration, an average, ....
I would have tried with the mqtt_subscribe component, but I discarded the idea rapidly.
Additional context
This would require for selected components to:
have an mqtt_restore attribute?
delay initialisation until the device is connected to the mqtt broker / timeout management.
subscribe to the state topic / error management.
wait for the retained state to arrive / timeout management.
discard the value if it is too old?
unsubscribe from the state topic.
when publishing component state, enforce the retained flag.
Of course, also we need to setup an mqtt broker that supports retained messages and that is not using a scard or usb stick as permanent storage.
PRO: a great improvement for the safety and use cases of our devices.
CON: when the device boots it will depend on mqtt broker survival and avaliability.
Describe the problem you have/What new integration you would like
Restoring data from flash puts our device in risk with flash writes. If we want to reduce this risk, we must sacrifice some recent data. Restoring data from RTC is limited and not surviving a power failure.
What if the state of selected components could be restored from the mqtt broker?
Please describe your use case for this integration and alternatives you've tried:
This would be usefull for storing component data where is important to recover the latest state, like the position of an actuator, a counter, an integration, an average, ....
I would have tried with the mqtt_subscribe component, but I discarded the idea rapidly.
Additional context
This would require for selected components to:
Of course, also we need to setup an mqtt broker that supports retained messages and that is not using a scard or usb stick as permanent storage.
PRO: a great improvement for the safety and use cases of our devices. CON: when the device boots it will depend on mqtt broker survival and avaliability.