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.
I’m out of ideas, I think… time to escalate to the professional level. Tagging @EricM_Inovelli
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?
The listings are strange, you can sometimes select different products by changing the quantity selector at the top. My bulbs are most definitely E21-N1EA zigbee 3.0, I just physically checked one of the bulbs itself to be sure. That listing may be wrong, you may have selected something else, or perhaps they changed the listing since I purchased them.
1 Like
@EricM_Inovelli Here is some logging output with zigbee_herdsman debug logging enabled. It seems like it shows every data frame communicated to and from the stick. I have no idea how to interpret it but I hope it can help you guys debug!
Gist link:
Full file link:
https://gist.githubusercontent.com/evelant/4596a2bf6035d283140a53517ca9dfe2/raw/a23efae8ebe90cf13192cfac79b1d36bcc99a0b8/z2mlogs.txt
1 Like
@EricM_Inovelli Here is another log snapshot that should be more useful. It shows server startup, controlling a couple groups, running a network scan, and a failed attempt to control kitchen_lights_bulb_6 near the end. Hopefully that has useful information for you.
2 Likes
I’m having a similar issue with the sengled E1F-N5EW bulbs when bound as a zigbee group to the switch set in smart bulb mode. They will connect and pair, but eventually lock up completely when bound as a zigbee group to the switch. After a day or two without lockups, they will connect directly to the blue switch (VERY good lqi, over 200), but inevitably they will lock up and quit responding until they are removed and re-added. If I send repeated commands (on and off, or several brightness adjustments from the switch), some will quit responding, or be very slow to respond. This seems to be what triggers the lockups, because sometimes they will just freeze. If I wait 10-15 seconds between button presses, they seem to usually keep working. I am using a Sonoff zigbee 3 plus dongle, and I just flashed today with the z stack coordinator firmware to see if that helps at all.
The firmware loaded on these bulbs is 0x00000016, and I’m considering picking up a sengled hub (shudder) to see if there is an update. I’ve seen no recent firmware posted to this github repo in over two years. I actually wrote to Sengled asking them to post firmware, but so far crickets. I suspect that the issue is with the bulbs themselves, but am hoping a workaround can be found.
These bulbs are a bit squirrely when bound to some other devices, but they don’t lock up completely. I’ve actually never had to repair any of the other singled bulbs I have bound to other non-blue series devices. Some are bulbs already linked by @imagio.
I also want to mention that the switch itself responds to commands pretty much instantly when they are issued from Home Assistant (running ZHA). I can see the status update, and the switch LEDS respond like lightning. It’s really just the bulbs themselves.
Also, FYI, often when the bulbs quit responding to the switch, I can still sometimes control them directly from the entity or zigbee group (via the coordinator), but not always.
I hope that helps, and I plan to try a few other brands of bulbs in the next couple weeks to see if there are any differences. I, unfortunately, need very slim bulbs to fit the bathroom fixtures, so it’s slim (lol) pickings.
Thanks!
3 Likes
That sounds more or less exactly like what I’m experiencing. The bulbs worked (mostly) OK before I installed the Blue series when I had some Sengled plugs used as routers. I suspect that the bulbs perhaps do something non-spec-compliant which will work with other Sengled devices that have the same bug but not with actual zigbee spec compliant devices. That’s all speculation however, I don’t understand the zigbee protocol well enough to figure it out.
2 Likes
I suspect that the bulbs perhaps do something non-spec-compliant
I suspect this too, but I believe there may be more going on.
So, yesterday I factory reset everything the 2-1 switch and the 4 bulbs, re-paired through the blue switch (connect through device via home assistant), recreated the group for the 4 lights I’m controlling, and re-bound the switch to the group. After several hours, 3 of the 4 bulbs showed up under the switch as children with 200+ LQI. The 4th bulb never joined. After another couple hours, the 3 bulbs that were children of the switch dropped, and connected other devices in my network (the coordinator and/or a tubes zb router) with much lower LQIs (around 40). The lights mostly were still controllable through the switch, though the colors/brightness weren’t always the same from bulb to bulb. I was careful not to issue too many commands within close proximity, and disabled all automations associated with that zigbee group.
I also have a hue motion sensor right next to the blue series switch (hue). It too prefers choosing a route through other devices much further away (LQI of about 50 when not connected to the switch, LQI of 200+ when connected to the switch). I’ve been checking on the children of the switch periodically to see what’s going on, and the list is different about every time I look at it.
I also added a new Sonoff zigbee 3.0 plus dongle flashed with router firmware between the switch and the coordinator just to see what would happen… The switch itself still responds to every command I’ve sent it.
@EricM_Inovelli, if you need ANYTHING that might help get to the bottom of this issue, please let me know. I’m comfortable capturing events, logs, and whatever else you want. I’m pretty familiar with the debugging process for embedded devices, though in other domains.
Thanks!
Edit:
Would removing the switch from the network and seeing what happens help at all?
I’ll add other info I think might be helpful here:
The dimmer has a connection to the coordinator with a LQI of 171.
I discovered that a newer version of the coordinator/router software is available for my sonoff router/coordinator (20220928). Giving that a shot now.
2 Likes
FWIW, I’ve had nothing but trouble when trying to use Sengled bulbs in my network. They always generate a ton of nwk confilcts, and then eventually give up on rejoinig as they should in that situation. I had a customer exhibit the exact same behavior. I can also set up a small test network and the Sengled bulbs remain connected fine.
I came away from it all concluding there are certain device combos on a network that the Sengleds don’t like and it hits a FW issue on the Sengled.
I know the community member who sniffed the Sengled FW URLs, he’s not super active any more but I have a hub coming and think I have the procedure down to check for FW. You need to have an account and provide a list of devices you have to the server to get the links.
1 Like
I have the procedure down to check for FW
If you happen to have it handy, let me know. I’d like to learn the procedure so I can make future contributions, though I’d rather not reward Sengled for not making the URLs known. I guess it would go towards a good cause though 
Do you happen to have any E1F-N5EW bulbs? If not I’ll grab a sengled hub.
1 Like
I don’t but it should be possible to check still
1 Like