[Help] Mesh with Hue + Xiaomi Mains Devices

[saurabh984]

Hi,

I have just bought both RaspBee and ConBee and was planning on replacing my Hue Hub and Xiaomi Gateway with just one RaspBee.

Before I go ahead and reset about 60 devices I wanted to ask if the mesh will work OK with Hue and Xiaomi Devices on the same RaspBee network?

Also, how stable would this be as I don’t have any wall switches. All have been replaced by either Hue Dimmers or Xiaomi Wireless Wall Switch (Battery Powered)?

[ebaauw]

The mesh network is made up by ZigBee routers, generally speaking mains-powered devices. If you have only Hue lights, it will be stable.

With deCONZ, you can use the Hue dimmer switches simultaneously in combination with the gateway and standalone, communicating directly with the lights. Great fallback to still control your lights in case the gateway is down.

[saurabh984]

Hi Erik,

Thank you for your help! Does that mean mixing Hue Lights with Xiaomi Aqara LN Wall Switches is not recommended.

I plan on using Home Assistant for rules. I have 3 Xiaomi Gateways to increase coverage and 1 Hue Bridge. I also have Isolicht Mains Dimmer and a few custom dimmers using JN5168 Module from NXP. Lots of Xiaomi Aqara Temp/Humidity/Pressure and Xiaomi Smart Wireless Switch for triggering scenes etc.

What I was hoping is to reduce the number of Hubs and Gateways and just use RaspBee as a co-ordinator.

Would you recommend going down this route or shall I stick to Hue Bridge and Xiaomi Gateways as they're both supported by Home Assistant.

Thank you again for the help and advice!

[ebaauw]

Does that mean mixing Hue Lights with Xiaomi Aqara LN Wall Switches is not recommended.

On the contrary, I would say. Afaik, deCONZ is the only solution that aspires to deliver true multi-vendor support, instead of hiding behind some official standard. Note however that deCONZ is still in beta. It runs stable enough for my taste, but I do have an occasional hiccup every couple of weeks. I pays off to stay on the latest version of deCONZ and of the RaspBee firmware (also because we're still adding support for additional devices).

Would you recommend going down this route

Yes. I've moved fully to deCONZ a long time ago. I currently have 86 devices on the ZigBee network: the RaspBee, 45 routers and 40 end devices. The routers are: 31 Philips lights, 5 innr lights, 3 OSRAM plugs, 2 IKEA lights, a GLEDOPTO light, a Heiman plug, a Heiman Siren, and a ubisys dimmer. The end-devices are: 21 Philips (12 motion sensors, 7 dimmer switches, 2 taps), 16 Xiaomi (7 door sensors, 4 weather sensors, 3 wireless switches, 1 leak sensor, 1 smart cube), 4 IKEA (2 remotes, 1 motion sensor, 1 dimmer), 1 Heiman (temperature/humidity sensor).

I plan on using Home Assistant for rules.

It's far more efficient to run rules on the deCONZ gateway, interacting with groups and using ZigBee scenes (e.g. see https://github.com/ebaauw/homebridge-hue/issues/15). I run most of my automation on deCONZ (240 rules) and only use HomeKit for geofencing and interacting with non-Zigbee devices (my Sonos speakers).

I also have Isolicht Mains Dimmer and a few custom dimmers using JN5168 Module from NXP.

Don't know these. They might be routers or end devices, depending on their ZigBee implementation - the older Xiaomi in-wall switches (lumi.ctrl_neutral) are end devices, the newer (lumi.ctrl_ln) are routers. If they're end devices, we need to whitelist them in deCONZ. We also need to do that to support any power consumption metering, should they provide that.

What I was hoping is to reduce the number of Hubs and Gateways and just use RaspBee as a co-ordinator.

Yes, you'd definitely want to do that. The ZigBee network gets stronger when more routers are added to it. You currently need 3 Xiaomi gateways, since you have no routers on their networks, so the end devices all need to connect to the gateway. When adding routers, the end devices connect to the nearest router, increasing network reach and scalability (there's only a limited number of end devices that can connect to a single router or to a gateway directly).
Also, I really like running deCONZ and homebridge (or in your case Home Assistent) on the same Raspberry Pi, instead of having a separate hub/gateway and home automation server. Fewer components = more stability. I recently moved to a Pi 3 B+, mainly because of the faster networking. I run the Pi headless, and interact with it over VNC, which now is much more responsive.

[saurabh984]

Hi Erik,

How do I connect the Hue Dimmer Switch so it can be used even if deCONZ is down? I'm guessing both the light and the dimmer will need to be paired to RaspBee right?

Does RaspBee still functions as a co-ordinator even if deCONZ is not running?

Thanks S

[ebaauw]

How do I connect the Hue Dimmer Switch so it can be used even if deCONZ is down? I'm guessing both the light and the dimmer will need to be paired to RaspBee right?

Yes. Don’t touchlink the switch with the light, or they will drop off the RaspBee network. Simply add the lights to the group deCONZ has created for the dimmer.

Does RaspBee still functions as a co-ordinator even if deCONZ is not running?

I don’t think so, but, frankly, I don’t know how much of that functionality is in the RaspBee firmware and how much is in the deCONZ core software. Note that the coordinator function is needed only to add new devices to the network. I think you’re asking about the gateway function (which provides the REST API and processes the rules, schedules, etc.). This is provided by the REST API plugin, and is active only when deCONZ is running.

The word “pairing” is a bit confusing here. To my understanding, when pairing a device to a gateway or hub, the following happens:

1. The device joins the ZigBee network, created by the ZigBee coordinator (typically your RaspBee or Hue bridge). I.e. the coordinator shares the network key with the device;
2. The gateway (typically the coordinator) creates REST resources for the device;
3. The configurator (again, typically the coordinator) configures the device, in particular it sets up bindings with other devices or groups, where the device needs to send its commands and reports.

When touchlinking a remote to a light, the remote creates an ad-hoc ZigBee network, and executes steps 1 and 3.

Typically, sensors and switches operate in two different ways:

1. They issue commands to control lights. Obviously, they need the right bindings to know where (which lights and/or groups) to send the command to, but other than the initial configuration, they operate standalone; or
2. They issue reports about what events have happened. Sometimes, they need the right bindings where to send the reports to, and reporting configuration when (on what conditions) and how often to send reports, sometimes (typically Xiaomi) they just send the reports to the coordinator from whom they got the network key. It’s then up to the recipients of the reports (typically the gateway) to issue commands to the lights and groups, based on these reports. This is where the gateway rules come into play.

As far as I understand, ZigBee was designed originally for devices to send commands (1). This way, the network runs independently from a central gateway, which is needed only for configuring the network. Moving into the consumer space, with the introduction of ZigBee Light Link, Philips and others introduced devices to send reports (2). This offers more functionality, at the expense of also needing the gateway to run the network.

When paired with the Hue bridge, the Hue sensors and switches issues reports (2). When touchlinked with a light, the Hue dimmer switch issues commands (1). IKEA devices issue commands (1). Xiaomi devices issue reports (2).
We found that the Hue dimmer switch actually does both at the same time, i.e. on a button action, it issues a command (1) to control lights and it issues a report (2) what button action was done.

By default, the deCONZ REST API plugin creates a group for devices that issue commands (1), and binds the device to that group. By adding lights to this group (typically in Phoscon or in the old web app), you can modify the behaviour of the device (or rather of your lights). Note that this won’t work for devices that only send reports (2), like the Xiaomi switches - you need gateway rules to use these.

To enable rules for devices that issue commands (1), the deCONZ REST API plugin eavesdrops on the commands, and reverse engineers these into events (which might then be translated into (other) commands by rules). This works automatically for group commands; when the device issues commands to single devices only (IKEA dimmer), a binding with the gateway needs to be setup.

[manup]

Does RaspBee still functions as a co-ordinator even if deCONZ is not running?

Yes it does still provide the full mesh routing only control commands aren't send. And if new devices should be added to the network deCONZ must be running and the network should be opened.

[saurabh984]

@manup Does that mean Control Commands from a Hue Dimmer would still work without deCONZ running?

From what Erik said I understand it would.