zigbee2mqtt
zigbee2mqtt copied to clipboard
Sonoff SNZB-04 devices leave network 256 minutes after last activity.
What happened?
I have a very small network of 4 devices connected to a Sonoff ZBDongle-E. The two Sonoff SNZB-01 buttons have been rock solid, but the Sonoff SNZB-04 contact sensors periodically fall off the network. This happens about once a day and the SNZB-04's need to be re-paired with the coordinator each time.
Below, I've attached the full zigbee-herdsman log along with the snippet of the devices leaving the network.
One thing that's suspicious is that the FrontDoorLock device falls off the network 1 second after the FrontDoor device. According to HomeAssistant, I locked the door 1 second after it closed. Even more curious is that this is exactly 256 minutes from the last activity. Perhaps this can be explained by an End Device Poling Timeout.
Just to be safe, I've taken the steps documented in Improve network range and stability. Picking a zigbee channel away from my wifi channel, using a USB extension cable, and changing adapter orientation all have no effect. Link quality typically stays above 150, yet the SNZB-04's still leave the network.
This is my first time using Zigbee. When I deployed Zigbee2MQTT a couple months ago, I did not have this issue. Just a guess, but perhaps now that the CONFIG_END_DEVICE_POLL_TIMEOUT is left unset, it's defaulting to 256 minutes, which is too short for some sleepy devices.
Any ideas that would get to the root of the problem would be welcome.
What did you expect to happen?
The SNZB-04 devices should be as stable as the SNZB-01 devices on the same network.
How to reproduce it (minimal and precise)
Pair an SNZB-04 to a ZBDongle-E and wait about a day.
Zigbee2MQTT version
1.28.2-dev commit: 16398b7
Adapter firmware version
6.10.3.0 build 297
Adapter
Sonoff ZBDongle-E
Debug log
Full log:
Snippet of devices leaving:
2022-11-16T07:41:23.185Z zigbee-herdsman:adapter:ezsp:uart <-- [2350b1a9772a15b2d2a9003de77092028e4e233e8c7e]
2022-11-16T07:41:23.185Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (2,3,0): 2350b1a9772a15b2d2a9003de77092028e4e233e8c7e
2022-11-16T07:41:23.186Z zigbee-herdsman:adapter:ezsp:uart --> ACK (3)
2022-11-16T07:41:23.186Z zigbee-herdsman:adapter:ezsp:uart --> [83401b7e]
2022-11-16T07:41:23.186Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: 129001230000008b3d4a184d25004b120004
2022-11-16T07:41:23.187Z zigbee-herdsman:adapter:ezsp:ezsp <== 0x23: {"_id_":35,"_cls_":"childJoinHandler","_isRequest_":false,"index":0,"joining":0,"childId":15755,"childEui64":{"type":"Buffer","data":[0,18,75,0,37,77,24,74]},"childType":4}
2022-11-16T07:41:23.187Z zigbee-herdsman:adapter:ezsp:debg Device left network request received: 15755 00124b00254d184a
2022-11-16T07:41:23.187Z zigbee-herdsman:controller:log Device leave '0x00124b00254d184a'
2022-11-16T07:41:23.188Z zigbee-herdsman:controller:log Removing device from database '0x00124b00254d184a'
Zigbee2MQTT:warn 2022-11-16 02:41:23: Device 'FrontDoor' left the network
Zigbee2MQTT:info 2022-11-16 02:41:23: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"FrontDoor","ieee_address":"0x00124b00254d184a"},"type":"device_leave"}'
Zigbee2MQTT:info 2022-11-16 02:41:23: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x00124b00254d184a"},"type":"device_removed"}'
2022-11-16T07:41:23.989Z zigbee-herdsman:adapter:ezsp:uart <-- [3350b1a9772a14b25eec75e5e27092028e4e230c347e]
2022-11-16T07:41:23.990Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (3,3,0): 3350b1a9772a14b25eec75e5e27092028e4e230c347e
2022-11-16T07:41:23.990Z zigbee-herdsman:adapter:ezsp:uart --> ACK (4)
2022-11-16T07:41:23.990Z zigbee-herdsman:adapter:ezsp:uart --> [8430fc7e]
2022-11-16T07:41:23.990Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: 1290012300010007783fc04825004b120004
2022-11-16T07:41:23.990Z zigbee-herdsman:adapter:ezsp:ezsp <== 0x23: {"_id_":35,"_cls_":"childJoinHandler","_isRequest_":false,"index":1,"joining":0,"childId":30727,"childEui64":{"type":"Buffer","data":[0,18,75,0,37,72,192,63]},"childType":4}
2022-11-16T07:41:23.991Z zigbee-herdsman:adapter:ezsp:debg Device left network request received: 30727 00124b002548c03f
2022-11-16T07:41:23.991Z zigbee-herdsman:controller:log Device leave '0x00124b002548c03f'
2022-11-16T07:41:23.991Z zigbee-herdsman:controller:log Removing device from database '0x00124b002548c03f'
Zigbee2MQTT:warn 2022-11-16 02:41:23: Device 'FrontDoorLock' left the network
Zigbee2MQTT:info 2022-11-16 02:41:24: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"FrontDoorLock","ieee_address":"0x00124b002548c03f"},"type":"device_leave"}'
Zigbee2MQTT:info 2022-11-16 02:41:24: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x00124b002548c03f"},"type":"device_removed"}'
Update
I recreated the Z2M network with a new panID, and re-paired all 4 devices. Now, even the SNZB-01 buttons, which were stable, fall off the network exactly 256 minutes after they were last pressed. I've since disabled Z2M and added my 4 devices to ZHA, where they've stayed on the network for the last week.
This is appears to be regression in ZBDongle-E support, perhaps related to #15066.
Hi SeanCline
I experience the same on one of my HA z2m installations. But I have since 8.11.2022 filed a error report and refiled it monday, but no one seems to be looking into these error reports.
filed under 14818 and 15068 (i though I had cancelled the first one, but seems still active)
So if someone does comment on yours, I would appriciate a message Marinus
@SeanCline @marinus61 I saw your error messages. but I can’t quickly restore the adapter’s work, because I don’t find these errors in myself installation.
@SeanCline I see you tried to learn something about this error. can you test the guess and restore setup CONFIG_END_DEVICE_POLL_TIMEOUT = 14 setting? then test. I removed the parameter settings in order to use the parameters from the firmware, I hoped that this would be more correct.
Made changes, in the hope that the loss of devices will leave
I can confirm that SNZB-01 buttons leave the network after a couple hours - stumbled upon this issue while looking for solutions. Also got a ZBDongle-E.
the changes are merged. try to check the work on the updated dev / edge version of z2m
@kirovilya the CONFIG_END_DEVICE_POLL_TIMEOUT = 14 is that in z2m config file or in the GUI to be added?
Marinus
@marinus61 no. this needs to be edited in the zigbee-herdsman file... the changes have already been merged into the dev|edge branch and you can update, without file editing
@kirovilya thks for the quit reply, i have looked intot he github and see that there is an update to 0.14.76. I am on 0.14.68 However I am unable to find out howto update to latest level, since I installed Z2M via HACS and see no update here that has not been performed. Sorry to bather with low level questions Appriciated that you assist us here :)
Hi, I also join the question how to upgrade zigbee-herdsman to version 0.14.76?
@redsam69
As I have been able to find on the github written by Koenkk, seems we need to use Z2M EDGE (experimental/beta) to be able to use the "in between" updates.
So hopefully @kirovilya responds or @koenkk updates the main version in the near future
Update
I recreated the Z2M network with a new panID, and re-paired all 4 devices. Now, even the SNZB-01 buttons, which were stable, fall off the network exactly 256 minutes after they were last pressed. I've since disabled Z2M and added my 4 devices to ZHA, where they've stayed on the network for the last week.
This is appears to be regression in ZBDongle-E support, perhaps related to #15066.
@SeanCline Yes it is the same error I face and several other. Funny though that after SB-02 "left" the system, it suddenly reappeared, although with an error In order to repair with success, i need to pair, remove and new pair
I switched to Z2M Edge and my SNZB-01 buttons are still leaving the network. Interestingly one of the buttons seems to have rejoined on its own although I haven't permitted joining. It's showing a red exclamation mark which says "Interview failed" when hovering. But the weirdest thing by far is that it seems to be bound to the closest Aqara smart plug now. You can probably imagine my surprise when I pressed the button and my PC turned off.
I switched to Z2M Edge and my SNZB-01 buttons are still leaving the network. Interestingly one of the buttons seems to have rejoined on its own although I haven't permitted joining. It's showing a red exclamation mark which says "Interview failed" when hovering. But the weirdest thing by far is that it seems to be bound to the closest Aqara smart plug now. You can probably imagine my surprise when I pressed the button and my PC turned off.
@Dominator86 thks for the update, I have chosen not to go for EDGE and wait a little longer for an update from @koenkk to the stable version. If no solution is found I am thinking switching to ZHA
Meantime I installed some IKEA bulbs, and the SNZB-02 that suddently reappeared after some time had the same exclamation mark on it. In order to rejoin correct, I have to join the unit, delete it and join again, then it is back to normal fbut now linked to one of the IKEA bulps and not the SONOFF Coordinator (seems to be an issue with the new E version, since the P version in my summerhouse work fine for 4 month now
seems to be an issue with the new E version, since the P version in my summerhouse work fine for 4 month now
@marinus61 Yes looks like it, I didn't have this issue with my ZBBridge either. I'm not using it currently so I guess I could try flashing it with router firmware and pairing the buttons through that instead - not sure if there's anything else I can try.
I'd really prefer to get this to work with Z2M since I have quite a number of devices which would all need re-pairing if I switched to ZHA.
@Dominator86
Seems that the error only exists when pairing direct to the Sonoff dongle E, the system infected is not my main residens, so I will test further when I get back there, but the units paired to the IKEA bulp seems to stay online but with the exclamtion mark on it (did not remove and repair it, so I will try that, to see if the X mark vanished)
@Dominator86
Seems that the error only exists when pairing direct to the Sonoff dongle E, the system infected is not my main residens, so I will test further when I get back there, but the units paired to the IKEA bulp seems to stay online but with the exclamtion mark on it (did not remove and repair it, so I will try that, to see if the X mark vanished)
Yes, if i pair with aqara plug, everything works seeamless
Yes, if i pair with aqara plug, everything works seeamless
The problem with that is that in my case the button then toggles the plug (even though it's bound to the coordinator, not the plug) but I need my buttons to control lights.
When I pair my buttons with the dongle or my Hue and Tradfri bulbs instead they don't stay in the network.
@kirovilya
any chance that you could assist in how we can make this work or how to update the files without going via EDGE Marinus
@marinus61 I suggest you wait for tomorrow's release
@kirovilya
thanks for taking time to assist, I will await tomorrows update
Marinus
@kirovilya
Hi again, I have few days ago installed the new Herdsman 0.14.76 version
Units connect with less errors, but after about 4 hours they dissappear again and have to be repaired. Even if I try to pair them via a Router and not directly to the Coordinator Sonoff Dongle E, however SNZB-02 have issues with battery showing
It seems howeever that it is only the SNZB-04 that causes this problem, the SNZB-02 stay online. Any ideas.
Marinus
@marinus61 I'm at a loss... Sonoff sensors are so capricious. What firmware version do you have? 7.1.1
@kirovilya do you mean firmware on the Dongle?
this is what hardware says:
/dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220811180543-if00
/dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1:1.0
DEVNAME: /dev/ttyACM0
DEVPATH: >-
/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1:1.0/tty/ttyACM0
ID_BUS: usb
ID_MODEL: SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2
ID_MODEL_ENC: SONOFF\x20Zigbee\x203.0\x20USB\x20Dongle\x20Plus\x20V2
ID_MODEL_ID: 55d4
ID_PATH: platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1:1.0
ID_PATH_TAG: platform-fd500000_pcie-pci-0000_01_00_0-usb-0_1_1_1_0
ID_REVISION: '0442'
ID_SERIAL: ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20220811180543
ID_SERIAL_SHORT: '20220811180543'
ID_TYPE: generic
ID_USB_DRIVER: cdc_acm
ID_USB_INTERFACES: ':020201:0a0000:'
ID_USB_INTERFACE_NUM: '00'
ID_VENDOR: ITEAD
ID_VENDOR_ENC: ITEAD
ID_VENDOR_ID: 1a86
MAJOR: '166'
MINOR: '0'
SUBSYSTEM: tty
TAGS: ':systemd:'
USEC_INITIALIZED: '514835216654'```
@marinus61 Not this.

@kirovilya
thanks for fast reply. I am unable to find the hex update file for 7.1, do you have a link?

@kirovilya
I found the version you had, the one I had installed was the one I had foundon Sonoff link.
Update went well, SNZB-2 and -4 are now showing all info after delete and repair.
I will update tomorrow if the link stays on
Thks for your support Marinus
@kirovilya
Sonoff SNZB-04 still drop connection to system, so not even the latest updates secure the stability of the connection
Any further ideas
Marinus
@kirovilya
Hi again, have you had a chance to look into this persisting problem
@Dominator86 is your SNZB still online, mine drop out even when paired with other Zigbee units that the Sonoff stick
Marinus
@marinus61 I don't have a solution yet, but I'm trying to find it. I'm seeing a similar problem with Legrand buttons