Deconz / Zigbee: Exclude certain Devices from beeing part of the Mesh?

Configuration Zigbee
1

Howdy,

i have some Lights, that regulary become unavailable because of beeing physically turned off.
After getting turned on again, some other Lights seem to connect to them.
But when the former get turned off again, the latter either takes 10-30 Secs to react, or don’t react at all. Most probably because the Knot in the Mash is unavailable, but not in the Mesh registered as such.

So my Question: Is there a Way to exclude certain Devices from becoming a Hop in the Mesh?
I use a Conbee II - on Phoscon there is an Option to “Edit DDF” for Devices - might there be a Solution buried?

1 Like
2

This is a rather interesting question that I would like to see tackled as well, because in similar scenarios certain devices are notoriously unreliable. And if some end device to decides to use this router as its preferred connection and it fails then your scenario is triggered as well.

The problem here: This is out of control for Home Assistant and depends solely on the Zigbee standard.

What we essentially need: Declare a router to be an end device.
But I’m not sure if Zigbee allows for that to happen.

3

A little Update with probably a Workaround - it really looks the Zigbee-Network is a Kind of a Black Box, without possibilities to configure behaviour like this. It seems it is solely in the Hand of the Devices themself how they act. Which i really think is a shame, one should have (on its own risk) the possibility to configure a Network as needed.

Anyway. For two Days i test a Workaround that came to my Mind, which looks quite promising by now:

I set up an Automation with a Trigger “State=On” for “Any of the Lights which is known to get powered off”.
It then increases Brightness +1 Step, waits 10 Secs, decreases Brightness -1 Step, waits another 10 Secs. If there still is any of the Lights reported as State=On, the Action repeats.

It seems by sending small changes to the Device, Zigbee discovers noticable faster when the Device is unavailable again.
In my Testings by now, the Time it took the Zigbee-Network to report a Device as unavailable, went from 10-15 Minutes down to 1 Minute! The Impact on the CPU is not worth mentioning. Of course it is dirty to “flood” the Network every 10 Secs with a Command. But it shouldn’t reach a critical amount, at least i couldn’t notice any negative Impact by now. Furthermore, the Automation is only running, when there is one of those Lights turned on. And in the End, its a Workaround.

So, maybe one might find this Idea helpful.
For me, if the Workaround stays as reliable as now, it is a big Step forward.

Edit: While it is not the full Solution for the Question, but soothes the Problems, i mark it as Solution anyway :slight_smile: