-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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: 20 Default/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. |
I might be missing something but running this: Gives me this: Looks like it's not the proper firmware for a Sonoff Dongle-E. |
Always use then ncp one. I have created a docker container together with @Nerivec which uses the multiprotocol (rcp) one but its not quite stable yet. |
Its the correct firmware. I use the same device. Just disable the hardware(hw) flow control in z2m since this firmware uses software (sw)
Also use ember-zli in order to flash it. The official flasher will most likely not work. |
Just a note. There are variants of @Nerivecs firmware (blehci) that enable bluetooth on the dongles even if the dongle itself is not officially advertised as supporting BLE. However this will only work using multiprotocol (rcp) which is still experimental. |
Thanks!
I don't see how disabling anything in Z2M will help me flash the firmware of the dongle. Is there an option I should pass to the universal flasher, to disable the check and move from hw to sw? Additionally, doesn't it mean better performance if the flow control is hw rather than sw? |
if you dont disable it, it wont work after flasing it. It doesnt have to do with the flashing process itself. No I dont think the universal flasher will work but @Nerivec can confirm that. I myself used ember-zli to flash it. hw or sw flow has nothing to do with reliability or stability. It just how the firmware wants to handle things. The outcome is the same. |
Indeed, use Ember ZLI for flashing 8.0.2. I'm discussing with puddly to remove that restriction in universal-silabs-flasher that prevents flashing these. Some more notes:
|
I used https://darkxst.github.io/silabs-firmware-builder/ to flash 8.0.1 then 8.0.2 without issue. |
which one is stable? So its not the firmware which makes issues, its Z2M? Sorry at this point i tried so many different things that im a bit confused now. Thanks for the reply |
The trouble definitely started before 1.40 for me. Iirc 1.37 was the latest stable release for me. Though I still think it has to do with IKEA firmware in combination with ember and not Z2M itself. |
@Jojonintendo There was no change in Note that for anyone getting massive interference on 2.4GHz (regular or periodic), this is nothing the firmware or Z2M will ever be able to fix. You have to go through the usual steps to try to decrease said interference. You can also try to customize the stack parameters on Z2M start. Of particular interest here, is |
My bad, I thought I was replying to a different issue Z2M related. I'll remove my previous comments to avoid confusion. |
After updating my ember Sonoff Zigbee adapter to 8.0.1, the broadcast error seems to have been fixed. |
you my friend you are a true hero. Downgraded Z2M to 1.38.0-1. Worked out no "error: zh:ember: Delivery of BROADCAST failed for '65535'." anymore. I tried so many Ember firmware versions nothing worked. I even turned off WiFi (both 2.4 and 5) nothing worked before... |
@supaeasy Can you try walking zigbee-herdsman versions from 0.49.3 to 0.56.1 until you find exactly which one is problematic? |
Just chiming in here as well @Nerivec. Got a new Sonoff ZBDongle-E and figured it was a good time to migrate away from ZHA when setting it up. Flashed firmware 7.4.4 onto it and setup Zigbee2MQTT (ffc2ff1) using the zigbee-controller | [STACK STATUS] Network opened.
zigbee-controller | Zigbee2MQTT:info 2024-10-16 21:42:47: MQTT publish: topic 'zigbee2mqtt/bridge/response/permit_join', payload '{"data":{"time":254,"value":true},"status":"ok","transaction":"cdfgu-15"}'
zigbee-controller | Delivery of BROADCAST failed for "65532" [apsFrame={"profileId":0,"clusterId":54,"sourceEndpoint":0,"destinationEndpoint":0,"options":256,"groupId":0,"sequence":128} messageTag=255]
zigbee-controller | Delivery of BROADCAST failed for "65533" [apsFrame={"profileId":41440,"clusterId":33,"sourceEndpoint":242,"destinationEndpoint":242,"options":256,"groupId":0,"sequence":129} messageTag=10]
zigbee-controller | Delivery of BROADCAST failed for "65532" [apsFrame={"profileId":0,"clusterId":54,"sourceEndpoint":0,"destinationEndpoint":0,"options":256,"groupId":0,"sequence":130} messageTag=255]
zigbee-controller | Delivery of BROADCAST failed for "65533" [apsFrame={"profileId":41440,"clusterId":33,"sourceEndpoint":242,"destinationEndpoint":242,"options":256,"groupId":0,"sequence":131} messageTag=11]
zigbee-controller | Zigbee2MQTT:info 2024-10-16 21:46:49: Zigbee: disabling joining new devices.
zigbee-controller | Zigbee2MQTT:info 2024-10-16 21:46:49: MQTT publish: topic 'zigbee2mqtt/bridge/response/permit_join', payload '{"data":{"time":254,"value":false},"status":"ok","transaction":"cdfgu-16"}'
zigbee-controller | [STACK STATUS] Network closed. After perusing the issue thread I saw some people had luck reverting back to the If there's something I can do to provide something of more substantial value in identifiying root cause let me know as this is basically just a sandbox Zigbee network for the moment. Edit: |
@maverick1872 From that screenshot, you are running a very old version of Z2M, it does not contain the above-mentioned fix. You need 1.40.0 minimum. |
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" ? |
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. |
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: