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
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.
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.) 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.
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:
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.
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.
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’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.
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.
