Devices Dropping Off Network Since Update

deCONZ General Support
#1

I’ve just turned logging on.

I’ve been having a random problem, mostly with some eWeLink based LED bulbs, a GLEDOPTO GL-C-007, and a 3A Smart Home DE (clone of the GLEDOPTO GL-C-007) where after days, or even over a week, will just become unavailable. Power cycling returns them on-line.

All these devices were rock solid before I updated to 2.16.1 and the Conbee II 26780700 firmware. That is the only thing that has changed.

While gathering logs, is this a somewhat known issue?

I have a Sonoff USB 3.0 Zigbee stick that I might fire up on a different channel and run one of the error prone bulbs on for a couple of weeks just to see how it behaves there.

#2

Interesting update as I was just looking at one that went missing. I have two lights in a Phoscon group “Downstairs Lamp 1” “Downstairs Lamp 2”.

Both deconz and Home Assistant show “Downstairs Lamp 2” as unavailable. However, if I toggle the group, both lights follow the commands. So, clearly, that bulb is still attached and communicating with the network.

#3

Does this also happen with v2.17.0-beta? There were a few fixes to address reachable shown wrongly as false. (If you’re using the HA add-on the next stable version should be available soon if no regressions from 2.17.0-beta are reported).

#4

I haven’t tried the beta yet. I run it independently in Docker on an RPI away from HA. Since it is random and not very often, I’ll wait for the stable release for now. I’ll report back once that is out if it is cured or not. Thanks!

#5

I did move to the 2.17 beta and things are definitely better. I did see the GLEDOPTO GL-C-007, and a 3A Smart Home DE (clone of the GLEDOPTO GL-C-007) drop off the network for a short time the same day I updated, however.

I’ll keep an eye on things to see how it goes.

#6

Cool glad there is some progress noticeable.

#7

Definitely is better, all the LED bulbs have stabilized. The GLEDOPTO GL-C-007, and a 3A Smart Home DE (clone of the GLEDOPTO GL-C-007) drop off the network still. Fortunately, they are near a couple of my smart power strips. I plugged them into un-used outlets and have an automation in Home Assistant that watches them to go unavailable for a few minutes, then power toggles the outlet and they come right back.

I have one of the new Sonoff Zigbee 3.0 Dongles I’ve been wanting to try with Zigbee2MQTT. I might fire that up in a Docker container and try those two devices with it and see if it is them.

#8

Just has a SONOFF plug drop off for no apparent reason in the middle of the night. Just touching the power button on it made it reappear.

Just curious: I see several threads with things going offline like this since the last update. Is this somewhat of a known issue that will be addressed in the next beta/release? I’m happy to be patient and just hang on for that.

#9

On 2.17.1 now. I’m still occasionally seeing RGB lights going unavailable. Most of my lights are in groups, and as initially reported, even though appearing offline in Phoscon and HA, when the group is toggled, all of them respond.

In the screen shot attached, I have three bulbs in an OfficeAccents group. The third bulb is “off-line”, yet when controlled as the group, everything works perfectly. Color changes, on/off, etc.

When I go into deconz, even though there are no link lines connected to it, I can read cluster info and see the blue activity dot next to it.

Screen Shot 2022-07-03 at 7.08.05 PM
Screen Shot 2022-07-03 at 7.08.05 PM872×872 39.6 KB

#10

So, shortly after writing this, I remembered I wanted to try enabling source routing. I did so with what I think I needed, a minimum LQI of 100, default 5 hops. Minutes later, that OfficeAccent3 bulb came back as “available.” Interesting. I have several devices that are repeaters and am now wondering if one of them or a particular brand “isn’t doing the right thing.”

Question: can source routing values be too aggressive and cause problems? If I set the minimum LQI to the lowest value (60) and increased the hops a bit, can that cause more issues than it would solve?

#11

This is indeed interesting, the main benefit the source routing has is that the whole routing between (router) devices is determined by deCONZ and doesn’t rely on what the devices may think could be a good route.

Each message send from the coordinator contains the whole routing path and routers just forward it “blindly” without having to know or find a route. In my experience the larger or complicated the networks are the more beneficial source routing becomes. And then there is also the problem that Osram devices tend to propagate sub optimal routing information, which can be worked around with application level source routing.

Question: can source routing values be too aggressive and cause problems? If I set the minimum LQI to the lowest value (60) and increased the hops a bit, can that cause more issues than it would solve?

The defaults are a good starting point, the values are a bit trial and error to get right as this depends on the network. Usually if the GUI shows a lot of strong links like above LQI 150 I tend to set it to the rough average of the strong links. But some networks are a bit weaker here it’s okay to lower the minimum LQI value otherwise not many source routes would be created.

If the value is quite low from the beginning it’s still ok, the algorithm discards routes that don’t work out over time and still aims to get the strong routes before weak ones.

#12

Finally, I think it is stable.

Source routing fixed the majority of the issues and it did help me find that 1 or 2 of my eWeLink smart plugs are not working well and may causing some issues with their neighbors. These were the first ones I purchased and since switched to Sonoff Zigbee.

They’ve been banished to the garage to do a few things in there I’ve wanted to automate and seem okay in that location which is far away from them repeating with anything other than the window sensors in the garage.