Zigbee isues after FW Update

Hi,
I updated from 2.2.143 (?) to 2.2.8.145 on thursday and experienced issues with several different Zigbee devices. Yesterday I saw that a new update is available to 2.2.8.147 - this did not change anything thoug. It seems like the devices dropped out. They do not react to the Hue dimmer switch v2. The putton pressed is logged, though and I cannot control them with the hubitat app anymore.

The devices are an Osram LED strip, 3x Hue GU10 and 3x Hue Filament bulbs. Some other devices behaved a little strange (Hue Motion sensors in two room and "their" bulbs), but that seems to work now. I tried to remove and include the 3x GU10 bulbs. They have been found again, but do not work with the remote anymore. Just tested: It looks like I can turn them off with the App, but not on. When I set a level, it works. Also the flashing works. So maybe I would tweak the rule for the hue dimmer, but obviously something is wrong here.

What I also did that day was: installed Tado integration and the MELCloud air conditioning implementation. Hence, maybe it is not the firmware, but it would be strange if other non zigbee devices could cause such a problem, wouldn't it?

@kaktus317 Do you have these bulbs on their own hub or mixed with other zigbee devices? If it's mixed that's likely your problem. Hue stuff is ZLL zigbee while other devices such sensors are ZHA zigbee. ZLL bulbs make extremely bad repeaters and cause lots of mesh issues. (The exception are Sengled bulbs as they don't repeat and there are some newer zigbee 3.0 bulbs that work well too). It can bust up a mesh quicker than a drunk bride's made at a wedding reception. This isn't an issue with the firmware as the zigbee portion hasn't had any significant changes in a few years, and unlikely to be other devices that aren't zigbee. What a lot of us do with shitty bulbs like that most of us either use another hubitat who's zigbee radio is dedicated to those bulbs or a hue bridge. If you only have bulbs in your zigbee mesh then I would suggest changing your zigbee channel as the current 2.4 ghz spectrum may be over saturated from neighbors wifi and whatnot.

1 Like

Well, I have used hubitat for almost a year know and never had such an issue before. The same with smartthings the years before. Hence, yes maybe you are right, but somehow I doubt it.
Everything is directly connected to the hubitat hub. I also use Blitzwolf zigbee plugs and some zigbee devices connected to the inwall switches as well as several sensors. The bulbs/strips are in three different rooms, are from different manufacturers (at one strip osram, bulbs hue, but I think the one bulb is also from ikea tradfri). Thus, for me this problem is really strange and the only thing what changed in that timeframe was the mentiones FW and devices added.

It often looks like that but it is very rarely the case. I had the same recently but it was actually a coincidence that my xbee ZigBee device had fallen off the network at the same and before that (like a month my wall socket fell off, that one just does randomly). Then we had a heat wave a then massive thunder storms, that night everything went hay wire and I was on the beta for about a week. So it was lots of things compounding, the network getting weaker from 2 key devices dropping and then the air pressure. Once I sorted out the network and it settled again it started working.

You would have, it's just it's never obvious and you tend to put it down to something else. As a example you press a button and nothing happens but you press it again and it does. Or a detector doesn't trigger fast but next time it does. They are all symptoms of bad routeing due to lamp. It rarely happened for me and I didn't use button much but since I separated them it never happens.

1 Like

Hm, I am not very statisfied with this answer. However, how do you do it then? All bulbs, does not matter which manufacturer, via Hue hub and then from there to the hubitat hub, which manages everything or do you guys use another way?

Actually, I was pretty happy with smartthings and hubitat, so that I do not need different stuff... :frowning:

I have two HE hubs one with old LL devices (hue gu10s, osram BC and ES lamps) and old z-wave devices that was slowing down my network. Basically a bad device hub, as devices get replaced they get moved to my "good" hub. My good hub has ZigBee 3.0 lamps/ other stuff (aurora, osram, inner, Lidl, sunricher), Xbee, some LL buttons (obviously don't repeat), a HA socket and z-wave plus devices.

I tried the hue hub route but it didn't work well due to stupid Philips stopping other manufacturers, personally unless something major changes with hue I would never waist my money on them again. Much better quality stuff out there at half the price.

1 Like

Have you shut down the Hub and pulled power for 30 seconds, and then started it back up? While people are right that the firmware updates shouldn’t have any affect on your mesh, if something has happened to put your Zigbee radio into an abnormal state, shutting down and pulling power will restart the radio, which may help. Regular restarts don’t cut power to the radio, so the firmware updates won’t have cleared any radio issues.

2 Likes

I have not, just restarted. I will give that a try, thank you. Update while typing: Have tried that and no change.

@BorrisTheCat : Okay, but when using a 2nd hubitat I don't really get the advantage for reliability. The newer devices interfere with the older Zigbee 2.x or why is it better with two hubs?

What I don't understand: As I said, when I set a level the device turns on (at least the ones I repaired, which I am trying out right now) and also off. But they do not react to the "on command" in the device page. Also, there is no log that I pressed this button on the device page. Therefore, for me this does not look like a mesh problem?!

I have two hubs running and each is set with a different Zigbee channel. One is on 15 and the other on 20. No interaction between Zigbee devices. (I don't think this works on Z-wave)
Forgot to mention, I have the ZWave disabled on second hub

1 Like

nope they are completely separate mesh networks so they don't effect each other.

z-wave also has channels as I understand as well. But you can't adjust/ see them.

No that doesn't. what driver are you using? sounds like its not configured correctly, to the device.

If they use completely different Mesh networks and don't effect each other: How/why does it help to put them on different hubs then? Because of the two different channels?

I am using the same drivers as before:
Advanced Zigbee CT bulb (3x GU10 Bulbs)
Generic Zigbee bulb (2x Hue Filament and as I believe 1x Tradfri E27 bulb)
Advanced Zigbee RGBW Bulb (2x dropped strips from Osram and 1x from Innr)
Advanced Zigbee Bulb (1x Hue Filament)

don't ask, why the one Filament is different - they got recognized as generic zigbee outlet and I changed that, obviously inconsistent.

As I said: everything was working fine for weeks/months before. I cannot control all of the above except the rejoined GU10. Those with the not recognized "on" command though!
Also changing the drivers to something else does not help.

I think your getting lost. Each hub creates 1 ZigBee (on a channel) and one z-wave mesh. You put the bad ZigBee devices on one and the good ZigBee devices on the other. Now the bad devices don't effect the good and visa versa because they are on different mesh networks. Even if they were on the same channel they wouldn't be able to talk to each other (but you would get interference due to the shared bandwidth). Then with hub mesh you can used all devices as if they all exist on the same hub.

go to the devices in question that use this device and open the logs on a new tab page. Click save preferences on the device then click configure. Watch the logs and make sure you see a completed testing. Then try the ON and off.

What make devices are they all?

I don't thin I am getting lost. I was/am just wondering where the advantage of a new Mesh on a new hub is, when the devices are in different Mesh networks anyway :slight_smile:

Tried it with the GU10 first:
dev:3162021-08-01 23:52:54.825 errorjava.lang.NullPointerException: Cannot get property 'requested' on null object on line 402 (method on)

[dev:316](http://192.168.50.92/logs#dev316)2021-08-01 23:52:54.781 [debug](http://192.168.50.92/device/edit/316)on()

[dev:316](http://192.168.50.92/logs#dev316)2021-08-01 23:52:39.317 [debug](http://192.168.50.92/device/edit/316)descMap:[raw:catchall: 0000 8022 00 00 0040 00 B367 00 00 0000 00 00 4788, profileId:0000, clusterId:8022, clusterInt:32802, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:B367, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[47, 88]]

[dev:316](http://192.168.50.92/logs#dev316)2021-08-01 23:52:38.923 [debug](http://192.168.50.92/device/edit/316)descMap:[raw:catchall: 0000 8022 00 00 0040 00 B367 00 00 0000 00 00 4688, profileId:0000, clusterId:8022, clusterInt:32802, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:B367, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[46, 88]]

[dev:316](http://192.168.50.92/logs#dev316)2021-08-01 23:52:38.506 [debug](http://192.168.50.92/device/edit/316)descMap:[raw:catchall: 0000 8022 00 00 0040 00 B367 00 00 0000 00 00 4588, profileId:0000, clusterId:8022, clusterInt:32802, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:B367, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[45, 88]]

[dev:316](http://192.168.50.92/logs#dev316)2021-08-01 23:52:38.416 [warn](http://192.168.50.92/device/edit/316)description logging is: true

[dev:316](http://192.168.50.92/logs#dev316)2021-08-01 23:52:38.412 [warn](http://192.168.50.92/device/edit/316)debug logging is: true

[dev:316](http://192.168.50.92/logs#dev316)2021-08-01 23:52:38.408 [info](http://192.168.50.92/device/edit/316)updated...

Another device (not rejoined):
dev:1962021-08-01 23:51:30.945 debugon()

[dev:196](http://192.168.50.92/logs#dev196)2021-08-01 23:51:23.187 [warn](http://192.168.50.92/device/edit/196)description logging is: true

[dev:196](http://192.168.50.92/logs#dev196)2021-08-01 23:51:23.184 [warn](http://192.168.50.92/device/edit/196)debug logging is: true

[dev:196](http://192.168.50.92/logs#dev196)2021-08-01 23:51:23.180 [info](http://192.168.50.92/device/edit/196)updated...

What make devices? As I said:
Philips Hue GU10
ikea Tradfri E27
Ostram Lightify RGBW Strip
Innr RGBW Lightstrip
Philips Hue Filament

The logic of putting zigbee light bulbs on a separate hub is based on the fact that many zigbee bulbs are bad repeaters. This is particularly true of ZLL (Zigbee Light Link) bulbs. These bulbs communicate using a limited Zigbee instruction set, but can theoretically repeat commands for full Zigbee devices. The issue is that these bulbs frequently have limited buffer size compared to full ZHA (Zigbee Home Automation) devices. What this means is that the bulb advertises to other devices on the network that it can pass messages on to the hub, but when things get busy on the network, these bulbs can build up a queue of messages which overflows its buffer capacity, so it 'forgets' to pass the messages on. This wreaks havoc on the performance of your mesh.

People work around this limitation by using a Hue Hub or a second Hubitat Hub in order to a create a separate mesh that only contains ZLL devices, because ZLL devices repeat just fine for other ZLL devices.

3 Likes

Thank you very much for this explanation. This makes sense to me now :slight_smile:
I have not came across this simple fact before! (Now, I am really not looking forward to figure out what ZLL / ZHA devices I have...)

Hue bulbs are ZLL. The OSRAM light strip is almost certainly ZLL, and OSRAM lights are notorious for screwing up mesh. I believe IKEA bulbs use a non-standard version of ZLL. For the most part, unless the packaging for a light bulb or strip says it's Zigbee 3.0, you can probably assume it's a ZLL device. Similarly anything that isn't a light bulb or strip is going to be ZHA or Zigbee 3.0.

1 Like

Well, I learned something and will think about open up a ZLL Mesh. I got a couple of Osram products and all except the outdoor plug (old version), worked pretty fine so far.

Now I only have to find out what my problem is with these dropped devices :frowning:

1 Like

Because they are not in a different mesh network!? That's what having two hubs does.

You didn't say all the brand's before.

These are the only ones which might not work. Are they RGBW or just Tunable white or just dimmable?

Also the logs you want to see are after the configure button is hit. That will tell you of they are compatible and if they get set up correctly. From your errors it looks like not but you want to see where it's failing.

As @EdMcW said these are LL

Again pretty sure LL but as @EdMcW mentioned even worse as they are none standard from a comment I saw a while back from staff.

Depends on age but if it's branded as Lightify it's definitely LL. Newer ones branded differently it depends on if it has a QR code. If it does it's 3.0 if not it's still LL.

Again depending on age. The model code changed when they went to 3.0 but they have been on 3.0 for quite a while. So you may be good with these, every innr lamp I have has been 3.0 and works well.

Again LL cuz Philips :face_vomiting:

@BorrisTheCat,
well I misunderstood your post.

I assumed when you said they are on completly different Mesh networks you meant "bad devices" (ZLL) do one mesh and the newer ones (e.g. zigbee 3.0) form another one. That's why I actually got confused by your words, since I exected one hub does a mesh for all zigbees :slight_smile:

well, maybe I missed one :wink:

Just dimmable and as I said: it just worked fine for an entire year with that "very driver" (or what changed with the FW updates).

I did the logs as you told me to. The only thing I added was a press on the "on" button on the device page, to get that log too. For the rejoined GU10 there is at least an error for that not working "on". There was nothing more in the other log.
EDIT: I never pressed configure, did I? Shame on me - sorry about that:
GU10 (rejoined):
dev:3162021-08-02 01:31:44.474 infoArbeitszimmer 1 was turned off

[dev:316](http://192.168.50.92/logs#dev316)2021-08-02 01:31:42.788 [info](http://192.168.50.92/device/edit/316)Arbeitszimmer 1 was turned on

[dev:316](http://192.168.50.92/logs#dev316)2021-08-02 01:31:41.358 [info](http://192.168.50.92/device/edit/316)Arbeitszimmer 1 was turned off

[dev:316](http://192.168.50.92/logs#dev316)2021-08-02 01:30:32.152 [info](http://192.168.50.92/device/edit/316)Arbeitszimmer 1 level was set to 20%

[dev:316](http://192.168.50.92/logs#dev316)2021-08-02 01:30:32.027 [debug](http://192.168.50.92/device/edit/316)finished options testing...

[dev:316](http://192.168.50.92/logs#dev316)2021-08-02 01:30:29.177 [debug](http://192.168.50.92/device/edit/316)starting options testing...

[dev:316](http://192.168.50.92/logs#dev316)2021-08-02 01:30:26.154 [warn](http://192.168.50.92/device/edit/316)configure...

Seems like after config the "on" works again :slight_smile:

Osram Strip :
dev:1962021-08-02 01:42:04.644 debugstarting options testing...

[dev:196](http://192.168.50.92/logs#dev196)2021-08-02 01:42:01.623 [warn](http://192.168.50.92/device/edit/196)configure...

[dev:196](http://192.168.50.92/logs#dev196)2021-08-02 01:41:58.117 [warn](http://192.168.50.92/device/edit/196)description logging is: false

[dev:196](http://192.168.50.92/logs#dev196)2021-08-02 01:41:58.112 [warn](http://192.168.50.92/device/edit/196)debug logging is: true

[dev:196](http://192.168.50.92/logs#dev196)2021-08-02 01:41:58.108 [info](http://192.168.50.92/device/edit/196)updated...
1 Like