Broadcasts failing on ember after migration #22453
Comments
|
Any chance you can downgrade to 7.4.1 and see if you still have those problems on the pi? |
|
Same problem with SLZB-06M But I don't have a raspberry pi 4, host is a x86 machine, running unraid and zigbee2mqtt in docker. |
|
Grouping the mentioned broadcasting issue here guys (#22445, #22398) I cannot reproduce this with my Dongle-E. I've tried various firmware, various ways to migrate from |
adapter: ember May need to add 'rtscts' below adapter setting. |
Two things: I recently installed https://www.zigbee2mqtt.io/devices/ZFP-1A-CH.html#siglis-zfp-1a-ch Wich I think is not a very common router. Swiss market only and most likely not very popular. Initially I had problems with it. Also shortly after I installed it, my second Dongle-E that I use as a router had to re-pair and this was one of the first devices in my 2yo network that I never had any problems with. Second: Shortly before my Router Dongle failed I set reporting interval of every lamp to 1-3 seconds because I didn't see lamps status change quickly enough (or at all) when pressing a HW button like the switches mentioned above. After the Dongle failed I reverted this to 1-30 s and had no problems since. But I did the reverting before I saw the error in logs. Also I have to say: I don't recognize bigger problems or misbehavior. I just saw the error in the logs. The only real problem I have is that sometimes (not reproducible) some IKEA Bulbs are starting in maximum dimmed mode even though at least one of them is never dimmed manually. |
As the dongle-e is working using a docker images on an x86 environnement I'm guessing there is no issue with the zigbee Dongle, so if I focus on some specifics configs, here is what's coming to my mind as part of the change that might be different than a regular installation :
everything else is quite standard in my opinion. |
|
Nothing special over here. Had 1.36 running with SLZD-06M running on zigbee FW 20231030. Everything was running OK with adapter: ezsp Did the following steps:
So currently I'm in a state that my network is running, but I can't add any new devices. Is there any more info we can provide? |
|
Oh I should have mentioned that I am running HAOS in a VM on Synology DSM 7.2. Interference should not be a problem as my dongle is in a USB 2 port with a 2 m extension cable. |
|
My setup is HAOS running on a ODROID M1 with 8GB RAM and 512 GB SSD. |
Exactly the same behavior. Plus the problem that no new devices can't be paired with ember. But with ezsp I can add devices. In my case especially all my routers get disconnected. |
|
I do have 4 mmwave presence sensors. Maybe these devices have an influence. |
|
Sorry, posted my follow-up on the wrong ticket... These are the messages I see when I startup Zigbee2MQTT. Maybe they are related. [2024-05-05 11:00:43] info: z2m: Logging to console, file (filename: log.log) [2024-05-05 11:00:51] info: z2m: Zigbee: disabling joining new devices. Whenever I try to start the pairing process, I see these messages: [2024-05-05 11:03:28] info: z2m: Zigbee: allowing new devices to join. |
Ah yes, and I wasn't aware it is related... I have a SLZB-06M as coordinator (groundfloor) and a Sonoff Dongle-E flashed as router (first floor). Yesterday evening my Sonoff router got disconnected. It is while trying to pair it again that I found out I couldn't pair any devices. I have a very small zigbee network (more a test setup here), so I have no other routers, only end devices. |
I already have nearly 70 devices... |
Here at home, HA is a small setup (12 devices) I use mainly for testing. But in our vacation home, everything is controlled by HA and we have 51 zigbee and 33 ESPHome devices. In this second setup, I also have the same SLZB-06M coordinator, but still on the older 20231030 firmware, where the adapter is still defined as 'adapter: ezsp'. Since I ugraded to 1.37, I couldn't pair any new devices too, due to another error: "zh:controller:greenpower: Received undefined command from '0'" And that setup is not a test setup :-( |
In the development-branch channel. The similarity we both have is the same coordinator (I am at the dev Firmware right now). But maybe you can rather rule out the cause if you only have 12 devices in your setup. |
|
Very very simple configuration here. HAOS on qemu VM in low end x86-64 QNAP nas, resources 2 cpu+2 GB ram as suggested by HAOS setup guide. Back to the setup, I can report two setups:
Anyway I see from other posts that the error is happening with a variety of devices and if I look at another common factor, all the variety of networks showing the error have -> a coordinator <- which again spots the light on the coordinator. I see that @Nerivec is not able to reproduce the issue, and, needless to say, also Nerivec is working with a coordinator which should obviously rule out the coordinator itself (unless there is some elusive coordinator hardware common factor), maybe a good starting point for you would be to constrain the system on a low resource/slow host or a VM with limited resources to see what happens with the coordinator handling of Z2M. Maybe another hint maybe found in the first post from @julien-billaud: "I've tried the exact same configuration on a regular x86 computer running debian (using the same zigbee dongle) and didn't face any issue which seems to be a linked with the Raspberry pi 4". |
|
OK, because my setup is a small setup mainly for test, I did the following steps:
[12:01:03] INFO: Preparing to start...
[2024-05-05 12:01:40] info: z2m: Zigbee: allowing new devices to join.
[2024-05-05 12:02:19] info: z2m: Removing device '0x00158d0008083d2a' (block: false, force: true)
[12:06:41] INFO: Preparing to start...
[2024-05-05 12:07:40] info: z2m: Zigbee: allowing new devices to join. so pairing is working and I didn't get the broadcast error now, not while starting up and not while pairing. So starting over with zigbee2mqtt solved it for me, but that is not possible for everyone I think :-) |
No, not completly... after approx 5 minutes, pairing was again not possible. No errors, but the connection / interview didn't start. Tried to restart z2m and reboot the coordinator, nothing helps. Downgraded the coordinator to the 20231030 FW (ESZP12) and switched back to "adapter: ezsp" and I still got the "error: zh:controller:greenpower: Received undefined command from '0' " messages, but pairing is possible again. Will see in about 10 minutes... |
I do also have one Sonoff TRVZB. And I also started fresh with one new zigbee2mqtt config and just the coordinator, and even at start the pairing/broadcast issue appeared immediately. I don't think that it is an issue with raspberry pi as I am using an x86 machine running a zigbee2mqtt container (docker). I also observed that a coordinator reset sometimes helped. @Nerivec recommended to do a hard reset with my device (that includes pushing the physical reset button). This also helped me once starting without any issues, but after restarting again, I again suffered by those errors. |
Just to have a better understanding: what CPU/RAM is your x86 machine? Is it running what OS? Is it on bare metal or on a virtualization environment like Proxmox or other VM of any sort? I agree dockers are less demanding, but performance then is limited by the host so it would be useful to know what kind of host is running your docker and how loaded is your x86 system. |
|
It is a Intel® Core™ i3-9100 system with 64 GB RAM ECC. |
|
I have a low-resource VM that mimics the specs of an average PI 4 to run tests on stuff that I know affect performance. No issue there either. No failed broadcast without any device, nor with devices, and successfully paired & re-paired a dozen devices since it's been running for a couple of hours. But just in case, you can try giving it some breathing room with the advanced:
adapter_delay: 20Default/min is 5, max is 60 (milliseconds). Note that at 60, you are likely to experience some delays when triggering devices rapidly. PS: I created an issue in the firmware repo for the SLZB-06M and the failing config IDs. May or may not be related to the ensuing troubles, but we need to get to the bottom of it nonetheless. darkxst/silabs-firmware-builder#90 |
Added the adapter_delay option, no joy: [2024-05-05 14:42:54] error: zh:ember: Delivery of BROADCAST failed for "65532" [apsFrame={"profileId":0,"clusterId":54,"sourceEndpoint":0,"destinationEndpoint":0,"options":256,"groupId":0,"sequence":170} messageTag=255] at startup of z2m. |
|
I've been doing little more testing and figured out "what was wrong". To conclude, it seems like the ember driver is for some reason little bit more sensitive (I know that using the Dongle without extension cord isn't ideal). |
|
Can't be my problem. USB2 Port with 2m extension cable. |
How do I do that? |
Whew. I could have sworn I watched it update to the latest version of the docker image. Guess not. Updated to latest available docker image tonight and started from scratch. Pairing seems to go off without a hitch when using |
Still buggy for me with firmware 8.0.2 |
|
Hi guys, I was facing the exact same problem. Spent 5 hours trying all and everything with no luck. Finally I gave up, uninstalled Z2M and reinstalled it from scratch. Fortunately my network is not too big, 19 devices in total. After reinstalling and readding all, everything works 100% flawlessly now. I recommend you guys try the same. 7.4.4 and 1.41.0-1. , USB extension cable 1m connected to a Intel NUC USB 2.0 port. |
|
Had the same problem. ZBDongleE. Rpi Zero2W. No extension cord. Broadcast error every 10min. Reintalling Z2M and updating firmware didn't work.
|
|
@jespervdw did you desactivate "Zigbee Home Automation" ? |
|
Not sure what option you mean. Mainly unmarked 'permit join'. Whenever I have to add a new device, will just temporarily permit it again. |
In Home assistant Parameter -> Services |
|
I am using Homebridge
I am using Homebridge. Why? |
Lot of people struggling with Z2M beacause of Home Assistant plugin |
|
Ah ok. No not for me. |
RPi Zero 2W has only WiFi (no ethernet) and the USB port I don't know if it's USB3 but anyway: having the dongle directly connected exposes to at least two factors of instability due to EMF noise.
I've got evidence of improved z2m stability with fw 8.0.2 in terms of communication between z2m and the dongle over the serial. |
|
I could not find any solution in this thread and its closed somehow. Im probably blind, but can someone point it out to me? Using Z2M 2.0 and ncp-uart-hw-v7.4.5.0-zbdonglee-115200.gbl for the Sonoff Dongle E. is what i get, Restarted HA after update, restarted the VM (HAOS runs on Promox) This error just appeared after ember. Devices are working (for now) but when i tried ember once before 3 months or so, my bosch thermostates lost connection after while. Im a bit frustrated at this point, sorry if i missed the solution, but can someone point me to a direction? EDIT: If i play around with the temp, it sometimes just does not set the temp. As u also can see in the logs. Also you can see that another Thermostate is getting error on poll check-in whatever that means. @Nerivec any ideas? |
|
@JericoPablo would you mind updating your dongle firmware to 8.0.2 as you are using fw 7.4.5? This might help. |
Hi @Ricc68 ! Thank u for ur reply. Ive read a lot about it. Already moved the dongle away and the only thing which comes to my mind is that the cable is going next to a USV and 2 HDDs. Its an Amazon Basic 3.0 USB cable. I will try to eliminate these stuffs aswell, but not sure if they really bother. I also turned WiFi off for several hours but still same errors. Please let me know if i can provide more information. The v8.0.2 firmware, where can i find it? After searching around, is it this you are refering to? |
|
Fw 8.0.2 from @Nerivec is here https://github.com/Nerivec/silabs-firmware-builder/releases. |
|
ill give it a shot with the new firmware. Thanks! ill let u guys know what the outcome is. Thank you so much for helping out. |
|
What is the USV you mention in "cable is going next to a USV" ? |
|
I have a UPS to which my SFF PC, serving as a server, is connected. The server is located inside an Ikea cabinet. The UPS is placed next to the 3D printer on top of the cabinet. The USB cable runs out of the cabinet, along the wall, and next to the UPS (with a distance of 2-3 cm), as you can see in the photos. USV was a typo sorry. |
|
Ok, understood. To be on the safe side, if you could route the cable far from the UPS, like if you could run it up behind the printer instead of back down along the side of the UPS it would rule out eventual 50 Hz EM noise coming from the transformer of the UPS which is adsorbing around 50-60W looking at your setup (should be shielded but a small emission can still happen depending on the EMC specs). |
|
I just tried the new firmware, first i was very happy but after 30 mins the errors again appeared: My next step will be:
I guess the USB Cable will arrive best on monday. Lets see. If you have any recommendation there i can also check out a specific one. |
|
No no, just the amz basic shielded, same as I have, is good. |
|
Aha ... You have a "VM (HAOS runs on Promox)". This definitely fixed some of the issues for me but they were stability issues with ZBDongle-E stalling and not responsive to commands, not broadcast issues. It may be worth a try. |
After all the stuff we discussed, which, I thought, it did not helped, i restarted yesterday the whole machine. I cant believe that it helped. No broadcast errors since yesterday midnight where I started it again. USB2.0 Cable will arrive today and I will still use it. Only thing left is
I wonder why, do u think it has another reason than interference? EDIT: |
|
Okay new setup: to then looked via File Manager to the configuration.yaml there it was still old so i changed it there aswell Now im getting: I dont understand why this did not work out but slowly getting really really frustraded and annoyed. EDIT: i made a mistake by editing wrong VM lol but corrected it and still not getting connected the dongle right. EDIT2: also tried with ttyS0 and removing the console=ttyS0 from the cmdline.txt - still same EDIT3:
there is no Dongle anymore under Hardware... |
|
Extra datapoint here: I got existing Z2M instance with TI Sonoff dongle, was hoping to migrate to SLZB-06M, by cloning IEEE address and preserving network key, PAN ID, etc configs from the old dongle. This eventually did not work, so I deleted all the devices and tried to start from scratch, however then started seeing these dreaded error, when trying to pair new devices (which brought me here...): The paring kind of pretended to work, but in many cases the deivce was not correctly recognized ("Unsupported") or dysfunctional in some other way. I have been messing with various firmwares, redoing configs, reinstalling ad-on, ember vs ezsp driver, etc - but nothing was really helping. The ezsp driver / firmware was a bit better (no error), but ultimately had problems with discovering devices and stability. I was ready to throw this SLZB-06M thing into the bin and get 'properly supported' non-M flavour, but then decided to play with it a bit more with ZHA. ZHA actually worked well, but I hated the primitive nature of it, with crude controls visibility. Then, just for fun, I re-installed Z2M addon, with a completely vanilla config (no encrytpion keys, PAN ID, channels or anything like that) - and everything started working, no dreaded TL;DR A bit unclear what fixed this for me, but I suspect some sort 'bad state' on the SLZB-06M, that got cleared by configuring it for ZHA and then reverting back to Z2M. Perhaps IEEE address clone feature is triggering this bug (ZHA seem to be reverting the address to default) or some other weird state can perist there, outside of what is in Z2A config / coordinator_backup file Not a great 'solution' of course if you want to preserve your existing network / config (unless ZHA deployment-> wipe -> Z2M install -> restore from Z2M backup can 'unclog' the device too?), but perhaps interesting datapoint for people wrestling with this. |
Im using the Sonoff Dongle E, but will maybe give it a try. Since im using Proxmox and i set it up on a new machine before 5 months, this could be indeed old data / conf issue? Anyways I could try it out and if it does not work usw a backup |
|
Same here. everythink was ok, with 18 monthes old docker version, using ezsp driver. Dongle is correctly detect:
All my devices already configured in z2m are lost, and I can't add them again:
Any advice? EDIT : I removed my previous data folder, create a new one with new configuration.yaml file, and it's ok, I can add new devices. My previous devices are still lost, but my networtk is really small. |
and others
What happened?
While I've never been facing any issues for more than a year with the Sonoff Dongle-e + ezsp driver, I've tried to change the driver to ember, but nothing is working (tried multiple time) but sometime losing all the devices, sometime they are still there but impossible to interact with them, and pairing is never working. (for now I returned to the ezsp driver).
I'm not noticing much error in the log (only the broadcast error reported here #22445)
I've tried the exact same configuration on a regular x86 computer running debian (using the same zigbee dongle) and didn't face any issue which seems to be a linked with the Raspberry pi 4
What did you expect to happen?
No response
How to reproduce it (minimal and precise)
switch from eszp to ember driver
Zigbee2MQTT version
1.37.0
Adapter firmware version
7.4.2.0 build 0
Adapter
Sonoff dongle-e
Setup
Raspberry pi 4 using docker image
Debug log
No response
The text was updated successfully, but these errors were encountered: