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.
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.
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).
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!
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.
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.
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.
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.
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?
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.
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.
interestingly I’m facing the same issue. Especially outside of my house, I have very bad connections, even if the devices are 10m away from each other. While inside I’m using a lot of IKEA and Hue bulbs, I’m using cheaper china E14 bulbs from various brands with sometimes cryptic names outside.
In Phoscon I see them having weak links to almost everywhere. Already changes Zigbee channel and WiFi, but this doesn’t change anything. I’m getting source routes to some, but not all of those bulbs outside, even though they do have some “green” connections. Only if I lower the LQI to 75 (which is the minimum I can set).
Could it be that these bulbs are very bad repeaters? I thought it would be sufficient to just add enough of them (and I do), but apparently this doesn’t help.
My idea is to add some IKEA power sockets here and there, which seems to be very good repeaters.
Any other suggestion to improve that situation?
Ahh! Very good point!
Those bulbs are mounted in some floor lamps made out of metal with a translucent plastic cover. The socket of the bulb is within the metal stand. That really could be the issue, but I won’t fix it. (20+ bulbs…)
That could explain the issue for sure.
I now added 3 more IKEA routers, but connections are still not getting better. Currently, I don’t trust the DeConz viz anymore, as I can’t adjust the LQI threshold properly. (See here)
Not sure what else to do
