Stop Zigbee Mains powered device from being a router? (ZHA)

Configuration Zigbee
1

Have an issue that despite having a few mains powered devices that are routers, almost all of my zigbee devices in the mesh route themselves through a set of tradfri lights. This in itself isnt an issue as the connectivity is fine but the light switch they are attached to is still dumb and get turned off on a regular basis causing all sorts of issues with connectivity.

In ZHA is there a way for me to specify that certain mains powered devices such as the lights are not presented as routers? If it mean rebuilding my mesh by readding everything using (add device from this device) option I am willing to go that route but from my understanding this will only fix the issue for a little bit as the mesh will reconfigure on its own.

5 Likes
2

Even though this thread is a little older, and technically is not the purpose of a Zigbee mesh network - sometimes you have to make do with what you have and in my personal case, light switches unfortunately have to stay accessible and usable.

I haven’t been able to find an answer for this. Maybe someone knows how to force some devices to behave like being “battery” powered.

1 Like
3

I have another use-case and associated problem:
I have a water-valve that is mounted in the shaft with all the pipes. I don’t have electricity there, so powered the device with an external battery. However, it has AC power brick in its box and meant to be mains powered, so has corresponding config.
So, the powered device with router capabilities is actually being battery powered.
And my problem is that the 7Ah (motorcycle type) big battery is drained within a week time (without any valve toggles). A presume the signal routing consumes a lot and is a root cause for the battery drain.
Hence I’d like to disable routing capability, so the device would be just maintain signal to the coordinator (as any battery sensor) and act (toggle valve) only when instructed to. This way battery would last for a year or so, assuming valve toggles would be really rare.

1 Like
4

Understand that is really the root cause of your problem, you should not turn off Zigbee Router devices, and following the concept of Zigbee architecture design the best solution would be to instead either remove the attached switch so that devices are not turned off, or an an alternative repace your smart lightbulbs with smart switches instead.

You could maybe try enabling or disabling Zigbee “source routing” if your Zigbee Coordiantor adapter, Zigbee stack firmware, and the zigpy radio library that the ZHA integration uses for it supports it. That could perhaps help but also possibly introduce other issues such as performance lag, i.e. time delay before command message gets through to devices.

zigpy (which is the Zigbee framework library and hardware abstraction layer that the ZHA integration depends on) does however not support blocking of specific devices in order to for example force some specific devices not to be used as a router, nor does it support manually setting a specific source route for a device. While the ZHA/zigpy developers are likely busy with many other things of higher priority or more interest you might want still to consider posting that as a feature request idea to zigpy discussions just to flag it for future reference if nothing else → https://github.com/zigpy/zigpy/discussions

FYI, deCONZ/Phoscon it is possible to set routes manually, but the default and recommend is to use automatic routing as it adapts better to RF oddities, as then when some routers act up with high error rates they fall back in consideration for a new source route. deCONZ/Phoscon does however not either support blocking of specific devices in order to for example force some speicifc devices not to be used as a routers.

PS: Regardless recommend also read and follow this → https://community.home-assistant.io/t/guide-for-zigbee-interference-avoidance-and-network-range-coverage-optimization/515752/

5

Any update ? Would be cool to strip router role from some devices if they are redundant …Have a few ikea plugs that simetimes get disconnected as “someone” needs a power socket to plug something… as a result something else there that was connected to that plug goes down :frowning:

1 Like
6

Turning off the light switch is sometimes just a habit that will not go away. I have put switch covers on my switches that indo not want turned off. The switch it still accessible but you have to work at it. Casually flipping the switch as you walk by is not going to happen.

7

No, it is not possible, at least not in the ZHA integration (nor in Zigbee2MQTT), each device in a Zigbee network is meant to handle Zigbee routibg automatically and always just connect via the best link it can find, so solution should simple be to add more Zigbee Router devices. Thus suggest to get more Zigbee Router devices with stronger radios to place closer to those with issues so other devices will automatically connect to the better routes instead, again check out → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage

1 Like
8

It will still happen often if you are family with kids, have grandparents or friends over. IMHO the best for WAF is to either use a smart switch or remove the possibility for humans to make that ”mistake”, physical switches are meant to be switched of and of after all.

9

Put a switch cover over the switch so they think they are switching if ‘off’ and use something like this:

10

I came across this same issue.
My use case is because I live in a Rental place. As such, I can change light bulbs without issues for which i procured some zigbee enabled ones, but aren’t suppose to change light switches because those are not ‘consumables’ from the house.
As such, i’m now facing the situation where some lights are electrically switched off, but because they are zigbee router devices, some other end devices get orfan until the next zha mesh healing.

As such I would be interested in:

  • Flag light bulb not to be used as router. (as in OP).
  • HA service to call ZHA to perform a mesh reheal. So i could at least setup an automation for the mesh to be reconfigured once they go offline.
  • Others?

PS: Yes, I could actually replace them, but then in my next rental i might face I have swithces I no longer can sue (as in the format of the switches, e.g. singles slot with single switch, singles slot with two sitches, 3 switches together, etc…)

1 Like
11

Again it is not possible (that is not how the Zigbee specification was designed to work).

The best alternative if absolutly need to use Zigbee lightbulbs and can not remove any dumb switch that power them off is to specifically only buy Zigbee lightbulbs that are purposely designed to be Zigbee End Devices (and not Zigbee Router devices), such as for example Sengled Zigbee Smart Bulbs, see → https://support.sengled.com/hc/en-us/articles/115010871308-Do-any-Sengled-Zigbee-devices-act-as-Zigbee-repeaters-

All manufacturers should stop making Zigbee lightbulbs that act as Zigbee Router devices for this very reason, it is not very intuitive for new Zigbee users to know or think about which type of devices should be Zigbee Routers and which should not.

1 Like
12

I realize this is a strong message, however why in the world would you put a smart device of any kind behind a dumb switch? I’m pretty sure the dumb is in the person screwing in the bulb, not the switch. Good or bad, like any technology advance, home automation requires effort and education beyond the previous evolution.

Should the vendors continue to improve their documentation, yes they should. But you have to read it…

IMHO, saying it is not intuitive here, is like saying it is not intuitive to have to charge your mobile phone to get and make phone calls. I’m sure there are folks out there that still don’t grok that… but the world moved forward.

13

I do think this is an oversight in the Zigbee specification. It would be helpful to have an intermediate “unreliably mains powered” device type that could participate in mesh networking between routers when powered but would be selected by end devices as a router only as a last resort.

I also struggled with this issue. I have 40+ light sources, most of them behind a dumb switch, some even behind 4 dumb switches (hallway lights). I had constant issues with end devices stopping to work - temperature sensors, window sensors, remotes, smart thermostat valves.

The electrical installation was designed without taking “smart” into account and while I’m thinking about replacing the switches in the hallway, where I use motion sensors, I can’t be bothered with replacing those dumb switches everywhere, no thank you.

So this is a solution I came up with. I’m using it for only a week now and things are much more stable. I would even say “stable, period”, but I need to give it more time to know for sure.

I now have two Zigbee networks with two coordinators connected to my HA raspberry pi.

The first network - using SkyConnect - is controlled with ZHA and has all those unreliably powered light sources connected and some other mains powered devices I don’t trust enough to put on the “stable” network (mostly sockets). I also keep Phillips hue dimmers and some Ikea remotes in this network for now as the blueprint I use for them doesn’t seem to work properly when the remote is in zigbee2mqtt, which the new network uses. But when I fix that, I’ll move all of them to the second network.

The second network is using a Sonoff dongle and is controlled by zigbee2mqtt (you can’t control 2 dongles with ZHA anyway). The backbone of this network is made from Ikea mains powered devices that are not behind any dumb switch (except for the circuit breaker, etc) - a light bulb, two 30W drivers, several smart sockets and 5 Tradfri signal repeaters. I moved most end devices to this network (except for the remotes mentioned before).

Not having to debug breaking automations almost every day is such a relief. But yeah, it would be much better if it was so stable without having to jump through hoops like that.

Edit: typo

2 Likes
14

Kind of maybe, but it was a design choice they made pn purpose as the networking meshing in a Zigbee network mesh is that it is to just meant to work automatically without end user interaction as users are not meant to have to active decition on routing.

I still think the main root cause here are manufacturers not thinking of all scenarios when making Zigbee lightbulbs a Zigbee Router device. Smarter manufacturers should do what Sengled done and make all lightbulbs Zigbee end devices instead.

Unfortunate nieither of those are things can we as end users can really affect, so the solution right now is to have knowledge about how Zigbee Routers works in a Zigbee network and not use them with dumb switches, because doing breaks how the current Zigbee specification works.

Sadly a specification standard can not take all manufacturers bad implementations into consideration, leaving it up to the installer and/or end-user to have the knowledge and understandibg to work around all limitations, (preferably taking the limitations and intended purpose into consideration before buying any specific devices). Proffesional installers should know not place Zigbee Router devices behind dumb switches and DIY users should do their own research before buying any device.

By the way, another major limitation with the Zigbee specification is that it currently only supports a single Zigbee Coordinator, so there is no redundancy there at all, it is a single point of failure, which in my opinion is a much worse design flaw.

PS: The new Matter standard solve some of these issues by allowing you to have more than one Matter controller and more than one border router in a Matter fabric, though it is not a full active-active design but a more active-stabdby design that is meant to fail-over safe is some component stops working (however it is still up to the end user to add such redudant components to their Matter fabric).

1 Like
15

There is no way to tell a device not to be a router without changing its firmware.

However, I have the same problem and I solved it by putting all the devices with wall switches on a separate zigbee network. This means that all the other devices will not route through them and so they keep working even if the wall switch is turned off. I do this by using deconz and ZHA, but you could also use zigbee2mtq.

-David

3 Likes
16

If (as in the OP) a single set of lights is handling most of the network traffic, isn’t that a bottleneck that could be removed by adding more routers? Zigbee is supposed to be “self healing” after all.

17

It is, however, it is not fast, it can take hours, but even so, it does solve the scenario when Zigbee devices far away only have one Zigbee Router within reach signal goes down.

Preferably you should have many “known good” Zigbee Router devices acting as a stable “backbone network” that can be trusted to always be available and have enough Zigbee Router devices connected and online so that every device in your Zigbee network always have two or more alternative paths if any single Zigbee Router device goes offline, but again, even that will not be robust enough if you by random chance have many Zigbee Router devices that go down at the same time and are not available (that is an especially bad architecture design if it allows people to keeps flicking off dumb switches or unplugging Zigbee Router devices that you count on keeping all of devices in your network alive).

Normally I would that just adding more Zigbee Router devices solved most issues, but from my experience, it is more robust to have three or more “great” dedicated Zigbee Router devices. In the engineering of network architectures, it is encouraged to evaluate the robustness of complex networks for resilience since infrastructure network usually holds a pivotal role in interconnecting devices.

This is why I recommend setting up a few dedicated “known good” Zigbee Router devices that are always online → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage

2 Likes
18

I have the same problem… 4 years later.
There is still no solution. This means that ZigBee is not as dynamic and responsive as I thought.
I’ll switch to something else. Any suggestions?

19

What are you doing to your Zigbee network that requires it to be dynamic? A Zigbee mesh isn’t meant to be changed all the time.

20

If my Home Assistant goes down, then my home is dark. To avoid that, I have added a smart switch connected to the physical switch over the control signal, to turn on lights even when HA is missing. So far so good.
Now I wanted to replace my bulbs with smart ones. Please note: I still want the smart switch, but I also want the RGB dimming fun. The new problem is that when bulbs are unpowered, they will soon go offline and need to be rediscovered, which is not good.
Well, new problem = new solution: isn’t it the hobby?
The new solution was automation. It works with two components. First I created a Boolean helper and I changed it status via automation whenever the lamp-group status went up or down. I needed the helper to store this status since I cannot query the lam-group when it is unpowered. Second I created an automation on the smart switch triggered by the switch going off event. Once activated, the automation brings the switch on again, and based on Boolean helper status, turn the light on or off.
It looks complex, but I tested it and it works perfectly. I can use the physical switch, and this works also when home assistant is down. Additionally, I can turn on my lights using a smart-button or the HA app on my phone. The logic is fully validated by testing, but sometime it doesn’t work.
After investigation, I discovered that it fails when zigbee decides to change the communication route to the smart-switch. Normally this device is connected directly to the zigbee controller, but sometime it chooses a bulb as router. When it happens the my automation is in trouble because it includes a step where the smart-switch goes down because of the control signal from the physical switch, but then the automation bring it immediately up. The problem is that when the communication path is across the bulb as a router, since the bulb is now unpowered, then the command to bring the smart-switch up again doesn’t arrive, or arrives several seconds later when zigbee finds a new communication path.

The explanation is long, but you asked and you have it :-). As you can see I have a reason for doing that. Maybe there are different way for implementing a solution, but my goal is fully legit in a home automation environment, and I’m sure many folks want to be able to control their lights also in an emergency situation when Home Assistant is down.

Now that we have validated the reason why I (or anybody in the community) want that, can we focus on the solution? I need a way to prevent the smartswitch device from using those bulbs as router. It looks that on the device itself I cannot provide any hint about the route. Moving to the bulbs, it seems there isn’t a way to disable the routing feature. I’m also trying to see if I can force-set the bulb LQI to the lowest value to reduce the path quality to a level that it will not be selected, but it seems it is not possible.

It looks it is a zigbee limitation that developers do not want to address because they feel it goes against the zigbee “philosophical theory”, but I think this is not correct.

Unless we find a workaround, I guess I should replace my zigbee smartswitch with an equivalent over WiFi.

THANK YOU it is a long post