Dual RaspBee Network - Phoscon needs to relearn all devices

[ignidis]

For the purpose of redundancy i created a dual Raspbee network, one of the devices runs as ZigBee Coordinator and has all the devices in the network joined and managed via phoscon. The second device runs on a tinkerboard and is setup as ZigBee router and joined to the above network. When i use phoscon on the router device i do not see any devices, eventhough the deconz app shows all devices connect to the router and the coordinator.

Is there a way to have the devices "replicated" between both phoscon applications ?

I know i can join the devices to both, but that requires using phoscon on the router / coordinator and power cycling the alredy reconized device, something that's quite unconvinient with an extense (~40 devices) network. The trick with the backup would copy all the configuration and basically clone one raspbee installation to the other and that's not what i want, as both devices should run parallel.

Would appreciate your input ... Txs and cudos for your work so far :) ... great ZigBee solution !

[ebaauw]

I know i can join the devices to both

What do you mean here?

If the 2nd RaspBee is a router on the network created by the 1st (coordinator) RaspBee, all devices are already joined to the same network. The deCONZ (GUI) on the router RaspBee needs to discover the network, which might take some time (up to an hour?). You might speed this up by power-cycling your devices, so that the router RaspBee picks up the device announcements.

That's the easy part. However, having two gateways on the same network is another story:

• To make the router deCONZ REST API plugin create the REST resources (which Phoscon or ant other app uses), you need to open the network/scan for devices from Phoscon (through the REST API on the router deCONZ), and force some traffic from the device (power cycling for a device announcement, or reading the Basic cluster in the router deCONZ GUI).
• Even if you have the REST resources on both gateways, this doesn't necessarily mean you can work with the devices from the router deCONZ/Phoscon, as you would from the coordinator deCONZ/Phoscon. Notably the router RaspBee won't see any notifications that devices (sensors) send to the coordinator. Some devices might be configured to send notifications to multiple addresses, some can only send notifications to one gateway (so the coordinator deCONZ/Phoscon would no longer receive them), others (notable Xiaomi) are hard-wired to send notifications to the coordinator. Even if the device supports multiple destinations, each deCONZ overrides the binding table, "stealing" the device notifications from the other gateway.
• Both deCONZ gateways would poll the devices to update their respective caches, likely overloading the ZigBee network (since neither expects another gateway also to be polling the network).
• (Unicast) commands send from one gateway will go unnoticed by the other gateway, so it will only update its cache (and the REST resources) when it next polls the device, or when the device is capable of (and configured for) sending multiple notifications.

In summary: having two RaspBees on the same ZigBee network is doable; having two deCONZ gateways is not.

[ebaauw]

If you're concerned about availability:

• Use switches (Hue, Trådfri) that can control your lights even when the gateway or your Wifi network is down;
• Use a USB power bank as UPS for your Raspberry Pi (that won't turn on your mains-powered lights, but automations for battery-powered devices continue to run);
• To cope with hardware failure, boot your spare (or development/test) Raspberry Pi and RaspBee which you can boot from the production SD card.

[ignidis]

@ebaauw, thank you for your extensive response. Joining to both i mean i can force the phoscon/deCONZ applications to create and "serve" the same devices with both instances of the app, including the limitations you explained. From a ZigBee point of view all works as expected, from an application point of view it works as you described, but it would be nice to have a way of exporting/importing devices and groups from one phoscon instance into the other; that's all i had in mind / was asking; just that info without all the other gateway configuration. Your recovery scenarios are ok, i use them myself (i use busch-jaeger switches), but what about extending the network ? What about subgrouping the network (e.g. some devices being served by one instance of the phoscon app, while others are served by another instance running on a router, very similar to what the busch-jaeger switches do) ? Please see my post not as a "bug description" but as something you may want to think of as feature. (I don't see where to add "feature suggestions" in github, sorry :) )

[ebaauw]

What about subgrouping the network (e.g. some devices being served by one instance of the phoscon app, while others are served by another instance running on a router, very similar to what the busch-jaeger switches do)?

Interesting thought. I've been thinking about splitting my 92-node production network since it seems to have become too large (see #850). I'd use two different Zigbee networks, each with their own coordinator/gateway, rather than a single network with two gateways. I would cascade the gateways (see #287) and/or connect both to the same home automation system (in my case: HomeKit) to have sensors on one network control lights on the other.

I think subgrouping might work. The REST API plugin should leave alone nodes on the network for which it hasn't created any resources. It will be a bit tricky to open the network from the right gateway to make sure the resources are only created on that gateway. And the resources for the Xioami devices will need to be created on the coordinator gateway.
This would likely be more efficient (and reliable?) than cascading the gateways. You can create bindings between devices served by different gateway. Group commands would reach devices served by both gateways. Rules, however, could only be triggered by resources on the same gateway, so for more elaborate automations you'd still need an overarching home automation solution.

Of course, neither cascading gateways nor subgrouping increases the availability, but they do increase scalability.