Zigbee failures after 2.14 firmware upgrade

Ok, you probably don’t have to worry about it as it seems like you know about the recall. I always start there so we don’t waste time troubleshooting only to find out we’re working with bad switches.

I am slightly concerned about the bad switches being mixed with your network as I don’t know the ramifications of having them there, even if fixed. But we can try troubleshooting first before looking into them as you mentioned everything worked prior.

Yeah no problem, I understand :slight_smile:

Let me also shoot you a PM with the other Eric so we can troubleshoot this. Once we figure it out, we can report the findings in this thread in case someone else comes across it. I just don’t want all your personal info exposed publicly.

I would willing to replace my reworked switches with new switches as soon as they are available. I only went the rework route due to time constraints because of a remodel that was in progress.

The bad switches would not pair, and after reworking they did pair. However, I’m not sure exactly how strong they are. I’m not the best at interpreting the meaning LQI/RSSI numbers. My network appeared to be stable with the reworked switches, but it is possible that adding the new switches is showing some holes in the rework process.

1 Like

I pulled the cover off of every one. All the ones I have on hand have have a manufacturer date code of 2212. Including my test switch on 2.14, and two that are not installed (I assume these are 2.08.) I also assume the ones I sent back are 2212, since they were all purchased from the same vendor.

If you want the IEEEs for all of them, please let me know: I have them in a CSV.

Ok, I think we’re good. The bad ones were in a different date range. I just sent over a PM with the other Eric, so we can try to diagnose from there if you don’t mind?

1 Like

1.) Perform reset on switch. Wait till it blinks blue in pairing mode.
2.) Pull air gap out to kill power to switch.
3.) On your hub, start pairing process.
4.) After 2 seconds, push air gap back in to regain power to switch.
5.) It should pair immediately.

The reason for the pairing problems is due to other switches or devices answering at the same time to the pairing request. You need to give it no time at all so it accepts the first message and responds.

Basically, as I dug into the traffic, I see two devices responded at the same time. The switch gets confused and it basically goes out of pairing mode and the LED just goes to the normal blue when switch is off. If you already have the hub in pairing mode prior to the switch having power, it will not have enough time to receive a second response from another device and therefor should connect immediately. I have been able to not only verify this with traffic logs, but also in real life testing. Seems to work every time for me.

This isn’t a new issue btw. So far firmware v2.14 is the most stable I’ve seen so far.

Hope this helps! :slight_smile:

1 Like

I wish it were as simple as another device responding. If this were the case I’d see it with all my devices, which I don’t.

I’ve been sniffing traffic and that is not what is happening. I see beacon request from the switch, the coordinator respond with a Nwk ID and then the switch exits pairing mode, and doesn’t flash green:

Coordinator: 00:12:4b:00:24:bc:3d:3b
Switch: 6c:5c:b1:ff:fe:5e:8b:37

41090	2023-04-23 16:20:27.771729	6c:5c:b1:ff:fe:5e:8b:37	0x0000	IEEE 802.15.4	21	6c:5c:b1:ff:fe:5e:8b:37	Association Request, FFD
41091	2023-04-23 16:20:27.968537	6c:5c:b1:ff:fe:5e:8b:37	0x0000	IEEE 802.15.4	18	6c:5c:b1:ff:fe:5e:8b:37	Data Request
41092	2023-04-23 16:20:27.975063	00:12:4b:00:24:bc:3d:3b	6c:5c:b1:ff:fe:5e:8b:37	IEEE 802.15.4	27	00:12:4b:00:24:bc:3d:3b	Association Response, PAN: 0x2052 Addr: 0xe136
41093	2023-04-23 16:20:28.420354	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41094	2023-04-23 16:20:28.577299	0x0000	0xe136	ZigBee ZDP	48	00:12:4b:00:24:bc:3d:3b	Node Descriptor Request, Nwk Addr: 0xe136
41098	2023-04-23 16:20:30.327533	0x0000	Broadcast	ZigBee	50	00:12:4b:00:24:bc:3d:3b	Link Status
41099	2023-04-23 16:20:31.183530	6c:5c:b1:ff:fe:5e:8b:37	0x0000	IEEE 802.15.4	21	6c:5c:b1:ff:fe:5e:8b:37	Association Request, FFD
41103	2023-04-23 16:20:31.832447	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41104	2023-04-23 16:20:31.845560	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41105	2023-04-23 16:20:31.859674	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41106	2023-04-23 16:20:31.873847	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41107	2023-04-23 16:20:31.886879	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41108	2023-04-23 16:20:31.901081	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41109	2023-04-23 16:20:31.915253	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41110	2023-04-23 16:20:31.929305	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41111	2023-04-23 16:20:31.942340	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41112	2023-04-23 16:20:31.956576	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41113	2023-04-23 16:20:31.970584	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41114	2023-04-23 16:20:31.984804	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41115	2023-04-23 16:20:31.998857	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41116	2023-04-23 16:20:32.014079	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41117	2023-04-23 16:20:32.028268	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41118	2023-04-23 16:20:32.043478	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41119	2023-04-23 16:20:32.057614	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41120	2023-04-23 16:20:32.071693	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41121	2023-04-23 16:20:32.084883	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41122	2023-04-23 16:20:32.098893	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41123	2023-04-23 16:20:32.113146	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41124	2023-04-23 16:20:32.126125	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41125	2023-04-23 16:20:32.140369	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41126	2023-04-23 16:20:32.153418	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41127	2023-04-23 16:20:32.167558	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41128	2023-04-23 16:20:32.180649	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41129	2023-04-23 16:20:32.194736	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41130	2023-04-23 16:20:32.207836	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41131	2023-04-23 16:20:32.221964	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41132	2023-04-23 16:20:32.234937	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41133	2023-04-23 16:20:32.249232	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41134	2023-04-23 16:20:32.262175	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command
41135	2023-04-23 16:20:32.275304	0x0000	0xe136	ZigBee	73	00:12:4b:00:24:bc:3d:3b	APS: Command

See here with my test bench. This is without any coordinators accepting pairing requests, and I have used a sniffer to confirm it:

Also, when I test, the switches are reset and are still in pairing mode.

What coordinator and hub are you using?

I have tested with, on all Zigbee channels (11, 15, 20, 25) primarily with Zigbee2Mqtt stable branch:

  • CC2562P with Z-Stack 20211217, 20220219, 20221102, 20221226, 20230410
  • RaspBee II with 0x26780700
  • EFR32MG21 with EZSP 6.10.3

I have also tested with ZHA on 2023.4.6 and 2023.1.7 with CC2562P with stock firmware from SONOFF and RaspBee II.

All of those are not stable enough to run larger networks.
You need Texas Instruments CC2652 with latest firmware at minimum to use these switches.
Raspbee and Conbee II are terrible options.
I have tested them and they perform horribly bad and unstable.

Also Zigbee channel 25 is recommended, along with Z2M stable + HA stable.

All of those are not stable enough to run larger networks.

Strongly disagree. Both the CC2625P and the EFR32MG21 are excellent choices for Zigbee networks.

You need Texas Instruments CC2652 with latest firmware at minimum to use these switches.

I don’t understand? I mentioned I am using a CC2562P.

CC2652P has integrated amplifier so can transmit stronger signal than CC2652R.

EFR32MG21 is more powerful than CC2652P. The CPU of the EFR32MG21 is an ARM Cortex-M33 that work at 80Mhz with 1Mb of flash and 96Kb RAM. The CC2652P works at 48MHz, has only 300Kb of flash and a 8Kb RAM, and 256Kb ROM.

Raspbee II was for testing purposes only.

1 Like

I’m not saying it makes sense or doesn’t make sense, but I have tested almost every adapter out there with Z2M. The Sonoff with the chip I mentioned is the only one I felt operated stable. All the others had poor signal integrity or just outright died every few seconds. The absolute worst one I’ve tried was the Conbee II. It was the most unstable. The specs are clearly not everything.

The EZSP chipsets are still in the experimental stage, and the firmware is pretty bad IMO. Good luck if you’re attempting to use those and want a stable environment… maybe some day. The CC2531 chipset is too old and will consistently drop packets in a large network.

1 Like

The Sonoff with the chip I mentioned is the only one I felt operated stable.

CC2625P is used in the SONOFF Zigbee 3.0 USB Dongle Plus-P
EFR32MG21 is used in the SONOFF Zigbee 3.0 USB Dongle Plus-E.

2 Likes

Yes, however, your original post says CC2562P instead of CC2652P.
And your last post shows CC2625P instead of CC2652P.

Regardless, the SONOFF Zigbee 3.0 USB (P-version) with latest firmware is very stable.
I have a very large environment and have yet to have a single switch fail to send commands.

v2.14 is the most stable firmware they’ve released thus far.

As the OP, here is my update. I upgraded from my HUSBZB to a Sonoff Zigbee 3.0 USB (E-version). My network stability greatly improved, but all my problems have not got away. While before I had switches that would never respond and others would frequently randomly drop commands, I’m now at the point where all the switches respond, just a few will only respond about 95% of the time.

It seems to happen more frequently when an operation attempts to contact multiple switches at the same time (or rapid succession). This includes activating scenes, or automations that attempt to set the side LED on multiple switches. Or even simple automations that try to turn off two lights at the same time.

It is usually the switches that are furthest from the coordinator that seem to have this problem, which makes me wonder if it is a problem of one switch relaying a command to another.

And I don’t know if the is relevant, but the switches that are the furthest away are switch from the newest batch that just arrived about two weeks ago.

Have you decreased the reporting interval on the switches as well? Might help. Here’s an example in Z2M of where to find it. New default is 15 but I still find that to be too frequent with as many switches as I have.

I can’t seem to find the equivalent in ZHA.

I can’t seem to find the equivalent in ZHA.

It doesn’t exist, but I setup a Z2M network, changed the reporting time and the behaviour I was seeing still persists.

1 Like

I’m still fighting stability in the network. I have factory reset all my switches and rebuilt the ZigBee network. I’m still seeing commands being dropped and timeout/delivery errors.

I really don’t know where to go from here.

Have you considered switching to the “Plus-P” version of the dongle? At least for Zigbee2MQTT everything I read says to avoid the Plus-E dongle because it’s not as well supported in the drivers.

I have not tried that. However, ZHA explicitly recommends the Sonoff E, which is why I picked it. But I’m seeing the same problems with the Sonoff that I saw with the HUSBZB.