Coexistence of two nuki hubs for redundancy

[magior]

For several months, I have been using two different ESP32 devices with NukiHub installed. One is paired normally, and the other is paired as "Nuki Bridge is running alongside Nuki Hub."
I do this to address issues related to crashes that occasionally occur on one of the devices, which could leave me unable to control the door.

Until version 8, I had no problems, even though both devices were publishing to the same topic. I understand that it was a crude workaround, but it worked and provided redundancy in a very simple way.

Since version 9, this no longer works as seamlessly as before. For example, commands are sometimes executed twice in succession, which, honestly, doesn’t surprise me.

I was wondering if it might be possible to implement an advanced feature that allows two devices to coexist, perhaps by designating one as primary and the other as secondary, using an MQTT topic as a keep-alive signal.

Alternatively, an even simpler solution could be to have a switch published in Home Assistant that enables or disables communication with the Nuki Lock. This way, one device could remain in standby until activated by Home Assistant, perhaps via an automation.

Thanks,
Marco

[iranl]

I don't understand why you would use a setup like this.

What do you mean by "crashes that occasionally occur on one of the device"?

Does NukiHub crash?
Does the Nuki device?
What do you mean by crash?

A crash of NukiHub usually means a panic and an automatic reboot which would only lead to a short interruption of connectivity.

If by "crash" you mean NukiHub and the Nuki device not communicating properly you could just reboot NukiHub using MQTT or the webserver.

Even if a setup with multiple NukiHub devices connected to the same lock/opener would be logical it wouldn't be with the same base MQTT topic.

If somehow you would have "crashes" where the NukiHub device is completely unreachable over MQTT and HTTP you would be better off with a smart socket that HA could use to hard reset the ESP by disconnecting power for a short amount of time.

[magior]

Thank you for your message. In my experience, after weeks or sometimes months, it could happen that one of my ESP32 devices went into a stuck status and became unavailable. But my setup could also lead to better handling of a device hardware failure.

I agree that I could use a smart socket to reboot the device, but this introduces another possible point of failure (the smart socket), without introducing redundancy.

Using two devices with two different power supplies gives me full redundancy, but if configured with different topics, they create different locks on Home Assistant, which has a lot of complexity in handling.
Having a Home Assistant switch to turn off Bluetooth polling could avoid duplicate actions (still a rare event), but all other functions work seamlessly even if both are up and running; they just update the topic two times without any clue.

[iranl]

But how would you fix the "stuck" ESP in this case?
Would this require manual intervention (unplug/plug power)?
imho would still be more reliable/user friendly to put this on a (Zigbee/Z-wave) smart socket.

If you absolutely need redundancy I would use 2 NukiHub devices behind 2 smart sockets and export/import the settings (including pairing data) from one NukiHub to the other and make sure only one of the devices is online/on at any one time.
You could automate the sockets in HA to turn on/off/reset based on the MQTT connection status of the devices.

This way both can act as a bridge device taking over the functions of the other NukiHub seemlessly if that device goes down.
Nuki pairing is not dependent on client device (e.g. BLE address) but only on authorization id and secret key.
Your Nuki device considers both devices as one and the same if you export/import pairing data.

[magior]

Thank you. Yes, to fix the problem, I have to reboot the device, and I can do this using a smart socket. My goal is to let the service run continuosly, so I can restart the device in a convenient moment without leave my kid outside the door :-)

I think the solution with import/export configuration could be a good solution; I'll try it.