Can only pair devices when close to the coordinator (ZZH) #7762
Comments
|
Can you provide a sniff of this? https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html |
|
Hi Koen, Thanks, see below, this time it was a brand new IKEA remote I paired (W2045) exactly the same thing happens PairingNearRouter.zip |
|
Thanks, something goes wrong at the coordinator side. Can you try flashing this firmware and provide me the herdsman debug logging when pairing close to a router? See https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files. |
|
Thanks Koen, I’m away until Friday, but I’ll do it once I’m back home and get you the logs over as soon as I can. hoggerz |
|
I am having the same issues as @hoggerz. When you look through the issues and discussions, several people are having very similar issues with the zigbee2mqtt and the zzh usb stick (see links at bottom of post). I reached out to Omer the founder of the zzh stick, provided logs and he indicated that he believed it was a software/firmware issue. Please note that I also tried ZHA and got the same results (realize they both use the same zigbee-herdsman coordinator firmware...so wondering if that is where the issue lies). I am willing to provide herdsman logs, but don't want to derail @hoggerz issue...but figured I would offer assistance since he is not available until Friday. I am running zigbee2mqtt in docker and have added -e DEBUG=zigbee-herdsman* to the docker run command. When doing so does this include the herdsman debug within the regular log? I attached a sample log file...its a little messy as I had to change my usb device mappings. Can you just verify that it includes the herdsman debugging...if so, I can start a clean network and provide logs, sniffing, etc. to keep this issue moving forward...or if necessary can also make a minimal network with just one of the routers below. I am also wondering if it makes sense with people who are having this issue to list the routers that they have on their network in case there is some common thread of a device causing issues with the network. My routers are as follows:
Here are some links to the other discussions and issues that match my experience: Discussions: |
|
@seaverd I'm not sure what to do with the log you provided, I see a successful pair in it but totally missing the context. If providing any logging, please keep it as short as possible (e.g. start capturing when putting the device in pairing mode). Explain what you did any preferably also add a sniff: https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html |
|
Attached is a short zigbee2mqtt log file set to debug inclusive of herdman logs. Also is a sniff during an attempted pairing. Zigbee2mqtt docker container was shut down and ZZH usb stick removed for 30 seconds(on an extension cable). All routers listed in my above post were already paired with the coordinator, but I unplugged them while the docker container was stopped. ZZH was plugged back in and container was started. I then plugged in/restored power to all 6 routers. I then went to zigbee2mqtt and disabled the join all and switched it to join (TeaKettle) which is the Xiaomi plug that is closest to the device that I am about to sniff. Once the join was active, I started the sniff. The endpoint device, bathroomtemp would not pair. I then disabled the join and set it to join all devices, then attempted to pair the bathroomtemp device. The pair was successful. At this point I stopped the sniff...so it should have only two attempted pairs. Based on my previous post this device will stay connected to the network for a couple of hours...then it will completely drop. I did restart the sniff after saving the one attached to this post and can post it once this device drops if that is helpful. If you need the network key it is: 1C:A9:C9:90:FA:94:46:6D:6E:19:58:93:0E:7C:1C:A8 If happens with other devices, just trying to keep the sample small per your request. Let me know if you need anything else. I just saw you posted an alternate coordinator firmware to try. I can test that tomorrow to see if there is any improvement. Thanks, |
|
@seaverd I expected |
|
So sorry! That was a mistake. See attached sniff |
|
@Koenkk Interested in what you find. Oddly enough the bathroom temp device has not dropped out yet. Wondering if It was powering everything down before pairing or the fact that I am normally repairing all 20 of my endpoints and this time I have only paired/added a single device. Attached is the network map…wondering why bathroomtemp, kitchenmotion and kitchenmotion2 are not shown with a connection to either a router or the coordinator.
|
|
I've investigated the sniff. The funny thing is that the device joins via the same device in both the failed and successful attempt. The first attempt fails because the coordinator does not follow up with a About the Xiaomi battery powered devices:
|
|
Hi Koen, Just flashed the new firmware and repeated what I did previously, I've also included a wireshark capture as well from the same time. Let me know If you need anything else. pairingdebug.zip hoggerz |
|
@hoggerz in your sniff I see exactly the same problem as @seaverd and @sjorge have. The @hoggerz @sjorge indeed started to wonder if it has something to do with the new backup mechanism. @hoggerz did you ever reflash your coordinator after updating to 1.19.0 and before flashing the debug fw I provided? (What was the last time you reflashed your coordinator not couting flashing the debug fw?) |
|
Hi Koen, Last time I updated the coordinator was 08/05/21 with CC2652R_coordinator_20210430, I would have been running on whatever the latest dev branch currently released around that date. hoggerz |
Seems a likely candidate yes, my issues started when testing Reverting to Since then I've been on a mix of those two and a few of your debug ones. I've had other distraction the past few days so i did not dig further into the new backup/restore code, but as I mention at least one a few occasions it is also rather slow at startup. I don't remember if these were after a flash or after a usb unplug. Of course when I tried to trigger it with logging it didn't have the behavior. My plan was to closely look at the code and see the different code paths it can take as there seem to be different stages it can start/continue from, I was going focus on cold (usb unplugged for a while) vs warm (usb still plugged in and running) start. But yeah not had the time to dig into it. I did verify pairing super close to the zzhp-lite has a very high success rate. But once I am about 50cm away it nearly impossible. |
|
@hoggerz that makes the backup procedure itself being the issue less likely. This was merged on 13 May (Koenkk/zigbee-herdsman#303), the last time the backup procedure was triggered on your side was 08/05/21 which is before this. What could still be the problem is that
|
I use |
|
@sjorge |
Hmmm I did start seeing ext_pan is reversed warnings, I did end I could try reversing the PAN in the configure.yaml and try again? |
|
Hi Koen, Tried on the older firmware, no luck either, here's the logs from that anyway: pairing-olderFW.zip Here's the logs from the Newer debug firmware, same thing, wouldn't pair. PairingNewDebug.zip Anything else you want me to try? hoggerz |
|
Just out of interest, how long does the restore step stake after flashing a different firmware? |
|
Thanks for your reply and I am aware of the issues with xiaomi devices. I haven’t tried new batteries, so good suggestion. Last night I decided to add the balance of my devices to the network. Prior to adding the devices I updated to the firmware you posted in this thread and started a sniff while pairing. Unfortunately dinner time fell in the middle of pairing so the log file and sniff are long (couple of hours). That being said, the first device I added, I attempted to pair it via a router…it didn’t pair so I then switched to pair all for all of the balance of the devices. All devices appeared to pair correctly and right after pairing functioned as expected. However devices started dropping off the network. Oddly of my 22 devices it seems the first 11 paired seem to have stayed connected. I am not home and can post the logs if you wish….but they are long….but maybe they need to be to see why devices are dropping. Let me know if you would like me to post or repair the network from scratch to keep the logs shorter. |
@sjorge revering the pan id in the configuration.yaml won't change anything on the coordinator side. This has been put in place because < z2m 1.19.0 set a reversed pan id so now both reversed and non reversed are allowed @hoggerz I see some debug logging now, can you check again with this fw? (will not fix it but contains some more logging). @seaverd device dropping of the network is a separate issue (lets stay to joining only issues in this issue). Please create a new issue. To debug, provide a sniff when triggering the sensor after it has dropped from the network (e.g. click the reset button once on a xiaomi device). Note: I will be on a short holiday this weekend so will respond on Monday again. |
|
Hi Koen, Thanks, here's captures & logging with the newer firmware, let me know If its any help and If you need anything else. PairingNewDebug2.zip hoggerz |
|
@hoggerz can you try with this fw? (may fix it) |
|
Hi Koen, Thanks, I won’t be back home until Friday again I’m afraid, but I’ll let you know as soon as I can. I appreciate your help with this. hoggerz |
|
I flashed the new fw, was unable to join a specific router. See attached zip files. One is for joining my TeaKettle router...the second is when Join All is selected..the join all paired but will likely drop. I will create another issue and hit reset button once per your request. zigbee2mqtt_join_all_paired.zip |
|
Hmm that would make sense my other test I did with flashing the same firmware with -ewr also had the issue, which I wasn't expecting so I had planned to redo it before posting. |
|
I have the Same Problems with a DeconZ Stick and a new CC2652RB Stick (Slaesh's CC2652RB stick ) ... I cant Bind any Devices over a Router. I can only bind directly to a Coordinator ... With the Slaesh´s Stick i have bad lqi too... (Gartenbeleuchtung_Lampe are 2 Meter Air to Air ) |
|
Damn ... this is the worst case scenario. My motion sensors are parents are not the bulb that are 10cm away ... they catch the coordinator 7 Meters away, hurra! I wait 1/2 days ... maybe... |
Is it missing in the backup? Or just not restored. I was also able to replicate with flash, erase, flash same firmware too now so it doesn't seem firmware related at all (so the newer ones are probable indeed fine) |
|
@sjorge it is in the backup before the flash, not restored correctly and therefore not in the new backup after the flash. |
OK that would mean a repair then unless there is a backup from the backup, gonne be a pain with the in the wall stuff but I could maybe shuffle these to my dev coordinator 🤞 |
|
You will probably only need to repair the routers that you want to pair via. Maybe a |
|
Oh so in theory I could start with the routers close to the coordinator and repair them and work my way outward so all routers are repaired 👍 thats worth a shot. I'm getting the missing info in the in devices list where it stores per router key material that is missing in my current backup except for one newly paired router. So I'm guessing its this is the problematic part: [
{
"link_key": {
"key": "51c0371456e5a8051f9722c114823428",
"rx_counter": 0,
"tx_counter": 0
}
}
]It's only present for one bulb I joined next to the coordinator but missing for all other entries. If so it should be easy to check once the bug is fixed. |
|
Updating like key is only being done of Zigbee 3 (Zigbee PRO more exact) deices that requesting one new trust center link key then pairing. So for your IKEA devices is only the old CWS 600 lm and the old motion sensor that is not requesting the key update. The frame counter must also being OK or the devices is trowing the package then it think its on replay attack. Also with the new TI radios look for corrupted IEEE that is saved in the NVR that can happening and making problems. |
|
@sjorge As we found out the firmwares behave pretty differently. In some cases the firmware fills up the TCLK table end-to-start or randomly. I iterate the table from beginning to start. I will work on this when I get a chance so we could make the backup properly. |
|
Hey All, reporting the same issue here, have to pair devices right next to the coordinator (zzh), I bought two dedicated router devices, which pair fine, and appear to route stuff (but im just going on the map here) but still unable to pair devices to them. My network is growing (see below) and wanted to use routers to extend range into the garden, but I can't join them from there as it is out of range of the coordinator. I have read all the above, what is the latest to help with testing or are we awaiting a fix at the moment?(happy to buy another zzh for sniffing or whatever.
|
|
I seem to be having the same issue, but with a CC2531 stick as main coordinator. Plenty of routers around my house as well. I need to get within about 30 cm of the stick for it to recognize anything. I am running the Z-Stack_Home_1.2 (default) firmware of 27 november 2020. I reflashed my stick recently but that didn't fix the issue. My Z2M HA addon is on version 1.20.0-1. In december 2020, I was running Z2M through docker and didn't have this issue (can't find the version I was using). |
|
So I repaired every device using join via and snaking my way out form the coordinator, took something like 4h. |
|
I tried out the following previous Z2M versions until the problem didn't occur again: 1.20.0, 1.19.1, 1.18.3, 1.17.1. (I did so by forking the hass github repo and force resetting the branch to the correct commit, then installing my fork in HA) |
|
The #7762 (comment) is pity nasty if being triggered and if you have getting the key table corrupted in the NVR and rebooting the system is adios amigos. I think its one old bug that normally is being fixed with re flashing of CC-253X coordinator and not looking for the bug that is doing the problem. The joining devices thru one router is one firmware bug that ZHA have pinpointed for some mouths ago and need having the coordinator open for joining or the trust-center is not accepting the joining device from on router. |
|
I received my TI debugger, so I got my ZZH stick restored. @Koenkk Based on what is known so far is there a specific firmware or version of zigbee2mqtt where I can roll back to and build a new network to get back up and running? Or if corruption when reflashing the coordinator is part of the problem...since I have a debugger, what is the best way to wipe the coordinator and start fresh? Thanks, |
|
Corruption happens after flashing because the backup doesn’t restore anything. You should be able to rebuild the network, as land as you don’t flash a new firmware to the stick until the backup procedure is fixed.
I had to start from scratch, I tried the repair each router way first that that didn’t work for me.
~ sjorge
… On 20 Jul 2021, at 17:00, seaverd ***@***.***> wrote:
I received my TI debugger, so I got my ZZH stick restored.
@Koenkk Based on what is known so far is there a specific firmware or version of zigbee2mqtt where I can roll back to and build a new network to get back up and running?
Or if corruption when reflashing the coordinator is part of the problem...since I have a debugger, what is the best way to wipe the coordinator and start fresh?
Thanks,
Dan
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Problem has been identified and fixed. Just created a PR Koenkk/zigbee-herdsman#393. If you have running networks you should be able to create a proper restorable backup after this update. |
|
I tried what you suggested (i.e. starting from scratch) and it did not work, still can't permit a joint via a specific device. I am assuming that is because of what @Koenkk referenced in his message below. Koen only provided a firmware for the zzhp lite, and since I have the zzh, I assume that I have to wait for a version of the firmware with the fix for the zzh????
|
|
Could be yes, I did flash that zzhp-lite firmware.
~ sjorge
… On 23 Jul 2021, at 13:16, seaverd ***@***.***> wrote:
@sjorge
I tried what you suggested (i.e. starting from scratch) and it did not work, still can't permit a joint via a specific device. I am assuming that is because of what @Koenkk referenced in his message below. Koen only provided a firmware for the zzhp lite, and since I have the zzh, I assume that I have to wait for a version of the firmware with the fix for the zzh????
I found out that when permitting joining only via a specific device joining would always fail. This happens because the permit join message is only send to that specific router, the coordinator does not receive it so it will never transport the network key to the joining device. I've fixed this issue now in the firmware.
@sjorge can you try if it also fixes the issue in your case? However I don't expect it to fix it when you did a permit join all (not a specific router)
cc1352 zzhp lite firmware:
znp_CC1352P_2_LAUNCHXL_tirtos_ccs.hex.zip
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
This issue has been fixed now, it requires the latest z2m dev (https://www.zigbee2mqtt.io/how_tos/how-to-switch-to-dev-branch.html) and the 20210708 firmware (will be officially released with next z2m version on 1 August). After that repair the router where joining via is not working for and the issue should be fixed. |
|
Hello I already updated to latest version of CC2652R1 and the latest dev branch of Zigbee2Mqtt But devices are still not pairing through the router. I already reflashed my CC2652R1 twice and I already repaired my routers twice but it's still not pairing through the router. |
|
@RaffoNin did you make any progress with this? I just moved over from a CC2530 + CC2591 based coordinator to a CC2562P2 based coordinator with a few IKEA Tradfri routers and a few CC2530 based routers and seem to have this issue when pairing end devices.
I have a hunch the issue is actually with the CC2530 based routers, as upon pairing closer to the coordinator, the parent is an IKEA Tradfri router. |
|
Update: Looks like I'm running 1.18.1, which was released before this patch was implemented. |
|
You could try the new update. Other issues on GitHub have said resetting, pairing to the coordinator, resetting, and pairing to the coordinator again. This is with the latest update. Quite frankly I haven't tried the workaround because I'm scared of breaking my setup rn. I had to manually pair everything to the coordinator and move it out until it paired to a nearby router. I do have a test zigbee bulb that i play around with often and i discovered that the joining via router started to work. Maybe there's some truth to the workaround i mentioned in paragraph 1. Not really an answer but it's all I know right now. |
|
I upgraded version (was running from a repo in hassio which didn't seem to be getting the latest updates anymore, so needed to screw around with migrating data). After migrating I re-paired all my routers, but still seem to be having trouble with my CC2530 based routers after re-pairing them. Am planning on getting a wireshark dump to see later this week. |
Hello @Koenkk , I'm having the same issue now (routers only pairing with Sonoff Zigbee stick) and not to other routers, I was able to take one router Sonoff S26 plug close to the Zigbee stick and paired then moved it to the desired destination and sit still working, however I have many other ZMINI devices already wired inside their location (they are connected already to ZHA via a similar stick on another server) so while I;m migrating now from ZHA to Z2MQTT I can't/don't want to unplug them and wondering if this solution provided is still the latest versions I need to use,
|
Hi,
I have recently found this condition, running latest dev branch using a ZZH. I can only pair or re-pair devices if I’m very close to the co-ordinatior. Is there any reason for this? I’ve not actually added any new devices, but when I tried to re-pair a temperature sensor after the battery died
, when pairing there was nothing at all in the logs when pairing in its original location until I moved it next to the co-ordinator. There it paired first time. There are a total of 77 devices in my network plus the coordinator, of these, 31 are router devices (IKEA bulbs and 3 IKEA signal repeaters) so there should have been a router close enough.
hoggerz
What happened
Can’t pair when near a router device, only when very close to the cooordinator.
What did you expect to happen
Previously this has never been an issue, although I’ve not had to pair anything recently and I’m usually on Dev branch.
How to reproduce it (minimal and precise)
Enable joining and attempt to pair near a router that’s not close to the coordinator.
Debug info
Zigbee2MQTT version: 1.19.1-dev commit: 217ce22
Adapter hardware: CC26X2R1 - ZZH
Adapter firmware version: 20210430
The text was updated successfully, but these errors were encountered: