When you pair the bulbs are you pairing them through a specific switch, or using the “enable all” pairing mode? I’ve had much better luck pairing twitchy Aqara / Xiaomi devices by only allowing them to pair through a specific repeater. They seem to be “sticky” and will mostly keep routing through the router they were first paired with. I don’t have any Inovelli Blues to try this with, yet, but I can say that this has worked with my Ikea outlets acting as permanently-set routers for Xiaomi contact sensors. Maybe bulbs will behave similarly?
I tried that but it didn’t seem to work. There was no noticable difference in behavior. They started out fine with high LQI to the switch for a little bit then just dropped from the network or routed directly to the coordinator. It seems like maybe the “pair via device” function doesn’t work in zigbee2mqtt? Every time I’ve tried the device ends up with whatever route it feels like anyway.
1 Like
It’s possible that some devices play well with this feature and others don’t. I’ve never tried it with anything other than Aqara / Xiaomi motion and contact sensors… works really well for those. Too bad it didn’t give your bulbs “sticky” routes… are there any bulb config parameters that might be in play? Running out of ideas…
The bulbs don’t expose any config params that I know of other than transition time and XY color conversion. Sengled are definitely cheap bulbs but IMO they’re 70% as good as hue at ~12% the price per bulb. I filled my house with them because they’re “good enough” and affordable enough to have adjustable lighting in every room.
1 Like
For reference, here are the details about my network
I notice that the coordinator firmware is somewhat outdated at 20210708 (that’s what shipped on the stick). I wonder if updating it might help but I’ve never flashed one of these sticks before, seems like a bit of a PITA.
It’s not that bad really… start with this cross-platform tool- it requires that you have Python on your machine:
You’ll also need the firmware for your stick- the latest dev build (20220928) has been pretty good for me… grab the version appropriate for your stick here:
The command I ran on my PC to flash the latest firmware was this:
Summary
py cc2538-bsl.py -e -w -v -p com3 --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20220928.hex
You’ll have to tweak it for whatever com port your device shows up on, filename for your particular build, and you may need to remove the sonoff-specific flag (read through the instructions on the cross-platform tool to see if you need it or not). Oh, and if your stick isn’t recognized (and you’re on Windows), you’ll see something like this in the device manager:
In this case, go install this UART driver and the stick will be recognized, after which you can flash it:
3 Likes
Thanks for the tips, I actually flashed it before I saw your post. Updated to latest zstack and upped transmit power to 20, rebuilt the whole network. It works a bit better now probably due to the higher transmit power, but the problem persists.
The Sengled bulbs still refuse to consistently route via the Blue series and drop off the network seemingly randomly.
There’s a strong argument to made against increasing your coordinator Tx power: it doesn’t have any impact on Rx sensitivity. So, you can shout really loudly at all the routers and end devices, perhaps allowing the coordinator to send messages directly to devices that are not in receiving range. Best practice is to balance Tx/Rx effective range so that devices that are far away will do the appropriate thing and look for a router, instead of trying to make a direct connection. If the coordinator is sending them messages directly, they’ll get the wrong impression and do the wrong thing.
I’m starting to wonder if maybe it is a Zigbee 3.0 vs ZHA 1.2 issue… there are some (now older) Sengled bulbs out there that were designed with ZHA 1.2, which I can confirm has issues playing on a modern 3.0 mesh managed by zigbee2mqtt. My Zen thermostat, for example, worked fine with Hubitat as the sheriff, but once I switched to zigbee2mqtt it was a nightmare. There are firmware updates available for some Sengled bulbs, and OTA via zigbee2mqtt may be your solution. The trick will be keeping the devices paired long enough for the entire firmware update to run through. Perhaps rig up a test fixture right next to your coordinator, and pair the bulbs directly in that fixture just to get the OTA updates to push through?
*Edit: I’m assuming you have this bulb, which was released with both ZHA 1.2 and Zigbee 3.0 versions… E11 is ZHA1.2, and if your part # has E21 in it instead, it’s Zigbee 3.0:
2 Likes
I have these bulbs. Do you know the latest firmware version and where to find it?
As I test I unplugged the coordinator for 30 mins then plugged it back in. A bunch of the bulbs chose to re-route via the Blue series, but some are still off the network.
After some time however (I let it sit overnight) the bulbs seem to drop or route direct to the coordinator even if the LQI is really bad and I end up with a network map like the original one I posted above.
My bulbs are all E21-N1EA and E12-N1E which should be Zigbee 3.0. No firmware updates available via zigbee2mqtt.
Zigbee2mqtt is hosting Sengled firmware files on Github… no idea where Koen is getting them. Parsing through the index file for all his locally-hosted firmwares, though, it’s clear that he has a source for Sengled firmware:
https://raw.githubusercontent.com/Koenkk/zigbee-OTA/master/index.json
1 Like
And your bulbs are non-functional when they don’t show a route in map view? The reason I ask is that the map doesn’t seem to be a reliable way to tell if a device is working or not. If it’s not awake to tell the coordinator it’s current route when the map is generated, it looks orphaned. Many of my Aqara motion sensors are floating in the void in map view, but work very reliably. OTOH, I wouldn’t expect bulbs to be sleepy end devices… I’d expect them to respond to requests for what route they’re using.
And here’s the network a couple hours after the above picture (and after pairing a few more bulbs) – lots of bulbs have stopped routing through the switches even though they had near perfect lqi
Yeah generally when they don’t show on the map they don’t respond to commands. Sometimes if I send a command a whole bunch (10+) times one of those bulbs will respond, but most of the time they’re off the network.
I’ve read through the thread a couple times and have asked the firmware engineers to investigate. Do you have an Amazon link for the exact bulbs so we can get something to test with?
3 Likes
Here are the two types of bulbs I’m using, both exhibit this behavior
Model E21-N1EA: https://www.amazon.com/gp/product/B092D72L6M/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
Model E12-N1E: https://www.amazon.com/gp/product/B092D8B6FT/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
If there’s any more information I can provide to help out please let me know.
1 Like
When I click on the link you provided and scroll down, it says this is the older E11 version. Is this the wrong link, or do you perhaps not have the Zigbee 3.0 version after all?
