Philips Hue Blooms behaving strangely and causing network instability

[ThatMishakov]

Hello. I have recently been investigating my network problems (which is a mixture of Philips, TuYa, Innr, Osram and Ikea routers), and I have found some strange behavior with the 1st gen Hue Blooms. I am not a 100% sure that my problems are because of these lights, but they seem to cause a lot of network instability with other devices and themselves when used with cc2652p coordinator, and with EFR32MG21 they have also been difficult to get joined to the network and constantly disconnect from it, even after I've moved my coordinator to be in 2m from them (I have 2 of these lights).

After playing around with the sniffer (I have full captures), with CC2652P as coordinator, I had found that they behave very strangely with Route Record packets. It seems to me that when another device sends a Route Record frame containing a Destination field, these lights strip it out and flip all ids of the previous relays. I have then seen these nonexistent flipped addresses throughout the network in source route attributes, causing a lot of confusion, and the light itself seems to send many Non-tree Link Failures and Many-to-One route failures. Also, sometimes the routing seems to work normally, but I haven't figured why, looks to happen when Destination field is not present. The newer Hue lights (with bluetooth) don't seem to be doing any of that, and don't cause issues. Also, I have a Philips bridge somewhere, and I'd guess I could check what it does with this if it's a real problem, but I don't have my sniffer anymore (I've repurposed ZBDongle-E as coordinator since ZBDongle-P was crashing on all 2023 firmwares, but that's for a separate discussion...)

I don't know a lot about ZigBee protocol, but from what I've read and seen, this feels very wrong to me. Is it a firmware bug, normal thing, coordinator problem? Philips' support is very difficult to get in touch with, and perhaps it's not their problem.

Here are some captures of relays seemingly being altered:

packets leaving tuya Route Record altered by Bloom

[TheJulianJES]

Interesting! I also have a Hue Bloom LLC011 that's dropping out constantly, even with the latest 2024 firmware (67.116.3).

In the deCONZ forum, I've read that 67.88.1 or 5.127.1.26581 firmware might be better. I should still have all images for the Hue Bloom, so might be able to test this (assuming there's no downgrading protection in the older Hue bulbs).

I've just moved it to my test network now where it actually responds (it's connected directly to the coordinator).
I have a source route (ZHA/custom bellows/EFR32) from my coordinator through the Hue Bloom to another Hue light and the Hue Bloom isn't even forwarding the packet at all, even though it's reacting to commands itself... Very weird.
I'll play around further to see if I see the same things as you.

Did a bit of testing and I'm already having issues contacting the Hue Bloom through another router with a set source route. It doesn't seem to work at all.. The Hue Bloom just doesn't react to that "repeated" message.
And if the Hue Bloom is directly connected to the coordinator and another router to it, trying to use a source route through the Hue Bloom to that other router doesn't work at all. The Hue Bloom doesn't "repeat" that message.

For reference, all images for the Hue Bloom LLC011 (image type 259/0x103, from new to old):

• 1124103171 (67.116.3):
  https://otau.meethue.com/storage/ZGB_100B_0103/e14480ff-2661-4abb-8dfd-275b77d876c2/LivingColors-Hue-Target_0012.sbl-ota
• 1124097291 (67.93.11):
  https://otau.meethue.com/storage/ZGB_100B_0103/5509a154-fe62-4cd3-bb11-19b46da0e074/LivingColors-Hue-Target_0012.sbl-ota
• 1124096769 (67.91.1):
  http://fds.dc1.philips.com/firmware/ZGB_100B_0103/1124096769/100B_0103_LivingColors-Hue-Target_0012_91.1.sbl-ota
• 1124096001 (67.88.1):
  http://fds.dc1.philips.com/firmware/ZGB_100B_0103/1124096001/LivCol_0103_LivingColors-Hue-Target_0012_88.1.sbl-ota
• 1107322837 (5.127.1.26581):
  http://fds.dc1.philips.com/firmware/ZGB_100B_0103/1107322837/LivCol_0103_5.127.1.26581_0012.sbl-ota

Confirmed that I'm also seeing up the messed up Nwk addresses in the Route Records.
So, both that and sources routes are seemingly completely broken. This might also explain why the EFR32 is to be worse for you.
EmberZNet seems to magically switch to use source routing after some time. It'll improve network performance... and break these old Hue lights.

I was also able to downgrade the light to 67.88.1 (without modifying the OTA file header at all). I'll see if the issues are also present in this release. At least sources routes are also broken on 67.88.1, they'll probably still be broken on 5.127.1.26581, but I'll downgrade and test too.
Uh, so, 5.127.1.26581 from 20181129 might actually be better? It seems like that version doesn't ignore/void packets with a source route for other routers so far... The Route Records also seem to be fine and not messed up anymore.
So, it really looks like 5.127.1.26581 is fine and 67.88.1 onwards broke source routing completely for this device.
Would be great if we had a contact at Signify for Philips Hue firmware now. 😄

Unrelated, I noticed that one of the recent firmware releases (likely 67.116.3) added color temperature control for this older Hue Bloom. It has RGB LEDs only, but with that functionality, it can accept color temperature commands and maps them to RGB.
So interesting that they're adding new features to this very old device with very broken firmware 😄 (but the Hue Bridge probably doesn't use source routing at all (but newer revisions always could, especially as EmberZNet somewhat "forces" source routing), so it might not be an issue there, yet).

[ThatMishakov]

Hello everyone, I had the same problem. But the following happened to me by chance: I had put a Bloom in a Z2M group when it was still accessible. And after the error occurred and the Bloom was no longer accessable, I deleted it (forced -> because it was no longer accessible). However, I forgot to reset the Bloom, and when I turned on the group, it responded.

This results in the following workaround for the problem: Simply put the Bloom in a Z2M group. Z2M throws errors, but it works! Can anyone explain why this is the case?

I did the whole thing as follows: I paired the Bloom directly via the coordinator and then put it in a group. Only the Bloom is in this group. I also added it to the groups where it actually belongs. Then I put it in its place, and as expected, it was no longer switchable as a device. BUT it still works via the group.

I hope that helps. Regards, Cold

My main issue with Blooms was not that they themselves didn't work, but that they were causing general network instability with devices around them, since it was breaking the stuff that tried to route through them.

What's different about groups is that it uses broadcast packets to control devices, and if your Bloom still reacts to them it probably is still in the network, and still can cause the trouble?

So imo the best "workaround" is to downgrade the firmware, and use them as normal.

[ThatMishakov]

@TheJulianJES any update on this? I am having this issue with other 1st-gen bulbs.

@Intecpsp It looks like a bug in the light's firmware, you probably have to complain to Signify to get the firmware fixed.

[ColdZeroHack]

Hi,
I've tested it out a bit now.
The Blooms themselves work via the group workaround. But you're absolutely right, there are still problems.
I actually had my first problem with the network yesterday evening, which can be traced back to the Blooms.
Sorry I'm only getting around to reporting it now.

Switching other lamps always worked perfectly, but there are indeed problems when pairing new lamps that are close to the Bloom. It doesn't matter whether you say “join all” or only join via a specific lamp.
If the router is close to the Blooms, there are problems.

I'll try the downgrade.

[seh-len]

This results in the following workaround for the problem:
Simply put the Bloom in a Z2M group.
Z2M throws errors, but it works!

@ColdZeroHack, I've noticed the same thing. I have a few lights in my z2m network that occasionally don't respond to requests, but they always respond when I send a request to the group. I don't know what's causing it, whether it's z2m or conbee III, but it's definitely strange that it doesn't work when addressed directly but always works when addressed via the group.
When I turn the lamp off and on again, I also see the join (reset of last seen), but then it is no longer accessible again.
Therefore, I asked in another thread whether z2m supports the source routing of the conbee III.

[ThatMishakov]

This results in the following workaround for the problem:
Simply put the Bloom in a Z2M group.
Z2M throws errors, but it works!

@ColdZeroHack, I've noticed the same thing. I have a few lights in my z2m network that occasionally don't respond to requests, but they always respond when I send a request to the group. I don't know what's causing it, whether it's z2m or conbee III, but it's definitely strange that it doesn't work when addressed directly but always works when addressed via the group. When I turn the lamp off and on again, I also see the join (reset of last seen), but then it is no longer accessible again. Therefore, I asked in another thread whether z2m supports the source routing of the conbee III.

When you add a Zigbee device to a group, the device (not Z2M) itself stores the group ID. Then, when you control the group, the message is sent to all devices in the network, and they then decide if the message is for them or not. It doesn't send commands individually to devices.

Therefore, if you have bad routers in the network (e.g. these lights) and the routing is messed up, the individual commands sent from coordinator might not reach the device (light) you're trying to control. But group commands still work in that situation. I guess there are differences in behavior between CC2652P, Conbee ii and III, but they just make the problem (of bad routers/bad firmware/bad signal/interference) present itself differently.