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. |
Is that using the |
Yup! |
|
I still have this issues with 7.4.4 and latest Z2M. Can anyone help me out here? It's really annoying and I believe the reason why some devices lose connection. |
I believe the same thing but am still looking for a fix to it 😞 |
|
Any particular reason why you all not upgrading to the 8.x.x firmware? |
|
Good question! Didn't realise it had been released. |
Hi! Where do you fetch your firmware? Thanks! |
|
Here is the firmware |
|
Ah I had no idea @Nerivec has been doing their own firmware builds! I'll give it a go 👌 |
|
We are lost with all the firmware... |
Which one is to be used between the two ? sonoff_zbdonglee_ncp-uart-sw_115200_8.0.1.0.gbl |
|
@Neocray I'd have assumed the ncp one |
|
@lawrencedudley I’ve just found out that. NCP is for ember, RCP is the one for multiPAN zigbee+openthread, which use is officially advised against (stability issues, which is the very topic here). |
|
The RCP one won't work at all with Z2M, you'd need some kind of working multiprotocol bridge which yeah, isn't currently stable enough to use (and may never be). You give the that NCP firmware a go? I'm tempted but also I don't want to cause myself a load of headaches. |
|
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: Screenshot of Zigbee2MQTT "About" Tab
|
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: