search

chemadh / zigbee2mqtt_ha

Zigbee2mqtt High-availability controller prototype
25 stars 0 forks source link

Use Coordinator Backups Instead Of RAM Dumps? #2

Open danieledwardgeorgehitchcock opened 5 months ago

danieledwardgeorgehitchcock commented 5 months ago

I have been investigating and thinking about your project for a while now since you posted it in the Zigbee2MQTT Git Repo.

I am wondering what your driver was for using RAM dumps over the traditional coordinator_backup.json files that are already baked into Zigbee2MQTT..?

In all honesty, I haven't checked what a RAM dump offers which the coordinator_backup.json doesn't but, I am wondering if the latter could be used instead? If so, this would not require any offlining of an active coordinator and, backup / restore methods are already baked into the coordinator firmwares..

danieledwardgeorgehitchcock commented 5 months ago

Further to the above, if a coordinator backup could be used, a simple extension for Zigbee2MQTT could be created that broadcasts the file contents over MQTT itself (if it doesn't already).

With a topic retention set in MQTT, the extension could pull back the latest backup directly from the retained message and do a restore on initial start of Zigbee2MQTT therefore avoiding the need for file synchronisation and better fitting with the technologies that Z2M already has available to it.

chemadh commented 5 months ago

Thanks a lot for your feedback,

In my experience, it was not possible to get a stable behaviour (with no need of re-joining devices) between coordinator switch-overs if NVRAM is not re-flashed in the process. In the other hand, my understanding was that NVRAM contents include internal coordinator functioning variables, not fully available at Zigbee2mqtt level.

However, Zigbee2mqtt documentation points in the direction that you commented. If coordinator_backup.json file is kept up to date automatically by Zigbee2mqtt process, synchronizing and flashing that file directly during switch-over, without a previous extraction of NVRAM content from the coordinator, would be a smarter approach. I definitely will check it and share the results.

If it results in a valid approach, it could also make sense to suggest a Zigbee2mqtt functionality to backup, store, and recover the last known active config for the coordinator IEEE address, using MQTT topic retention functionality (allowing multiple Zigbee networks connected to the same MQTT Broker too).

ppanag commented 2 weeks ago

Hello. In the zigbee2mqtt documentation, it says that you can replace a adapter that is the same, and everything will work , no re-pairing. https://www.zigbee2mqtt.io/guide/faq/#what-does-and-does-not-require-repairing-of-all-devices

Does not mention copying anything between the two adapters! Is that correct??

chemadh commented 2 weeks ago

Hello. In the zigbee2mqtt documentation, it says that you can replace a adapter that is the same, and everything will work , no re-pairing. https://www.zigbee2mqtt.io/guide/faq/#what-does-and-does-not-require-repairing-of-all-devices

Does not mention copying anything between the two adapters! Is that correct??

From my home-lab experience, it is required to have NVRAM contents duplicated between coordinator dongles to obtain a seamless coordinator switch-over experience. Otherwise, most zigbee end-devices will require rejoining to the network to continue working, even when the configurable part of the coordinator IEEE address is the same in both coordinators.