search

Koenkk / Z-Stack-firmware

Compilation instructions and hex files for Z-Stack firmwares
MIT License
2.38k stars 648 forks source link

Z-Stack_3.x.0 coordinator 20230507 feedback #439

Closed Koenkk closed 1 year ago

Koenkk commented 1 year ago

Please provide your feedback to the Z-Stack_3.x.0 coordinator 20230507 firmware here.

I hope this solves the NWK_TABLE_FULL many people were experiencing.

Changelog

20230507

  • Enable child aging to fix issues like #13478 (but not for older Xiaomi devices as they do not implement child aging correctly which gets them kicked out of the network)
  • Increase message timeout from 7 to 8 seconds to increase message delivery success rate for devices using a 7.5 seconds poll interval (#13478)
  • Improve performance with larger network
    • Optimize table sizes
    • Increase stack_size from 1024 to 8192
  • Add firmware for CC1352P7
  • SimpleLink SDK 7.10.00.98

Download

larryxxl2 commented 1 year ago

@Koenkk Firmware 20230507, SONOFF Zigbee 3.0 USB Dongle Plus.

Error 29 on send command to 1. Error: Error: Command 1 genLevelCtrl.move({"movemode":0,"rate":50}) failed (Data request failed with error: 'undefined' (29)) at ZStackAdapter.dataRequestExtended (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:1023:27) at Object.func (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:540:13) at Queue.executeNext (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:32:32)

how to fix ?

cloudbr34k84 commented 1 year ago

Overnight, i had an issue where the coordinator failed. The restarted adapter then retarted Z2M add on and slowy the devices came back online.
Now im seeing devices show offline and i have to got around and pair them.

error 2023-05-23 01:19:37: Error: CommandResponse 0x00158d0006b39f15/1 genOta.queryNextImageResponse({"status":152}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":1,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms)
error 2023-05-23 01:19:47: Exception while calling fromZigbee converter: Command 0x70ac08fffe916c19/1 manuSpecificTuya.mcuGatewayConnectionStatus({"payloadSize":1,"payload":1}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - UTIL - assocGetWithAddress after 6000ms)}

Does anyone else use alot of Tuya devices?

johnlento commented 1 year ago

This update has been pushing a lot more sengled bulbs offline sooner and I’m still getting a lot of timeouts. I think the last release was more stable. I still don’t know what to do about timeouts and what not. Could a USB extension that is too long be a problem? I still have a lot of coordinator and watch dog restarts.

Sent via RFC 1149 Get some Carrier Pigeonshttps://en.m.wikipedia.org/wiki/IP_over_Avian_Carriers...

From: Brad @.> Sent: Monday, May 22, 2023 3:41:38 PM To: Koenkk/Z-Stack-firmware @.> Cc: johnlento @.>; Mention @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230507 feedback (Issue #439)

Overnight, i had an issue where the coordinator failed. The restarted adapter then retarted Z2M add on and slowy the devices came back online. Now im seeing devices show offline and i have to got around and pair them.

error 2023-05-23 01:19:37: Error: CommandResponse 0x00158d0006b39f15/1 genOta.queryNextImageResponse({"status":152}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":1,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms) error 2023-05-23 01:19:47: Exception while calling fromZigbee converter: Command 0x70ac08fffe916c19/1 manuSpecificTuya.mcuGatewayConnectionStatus({"payloadSize":1,"payload":1}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - UTIL - assocGetWithAddress after 6000ms)}

Does anyone else use alot of Tuya devices?

— Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1557840895, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRT4MUEPZFS3TDIVPRFTXHO6PFANCNFSM6AAAAAAWPPN23Q. You are receiving this because you were mentioned.Message ID: @.***>

johnlento commented 1 year ago

Getting a lot of disconnects and lifts falling off still.

Logger: homeassistant.components.websocket_api.http.connection Source: components/zha/light.py:360 Integration: Home Assistant WebSocket API (documentation, issues) First occurred: 8:30:58 PM (1 occurrences) Last logged: 8:30:58 PM

[546517274432] Coordinator is disconnected, cannot send request Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 199, in handle_call_service await hass.services.async_call( File "/usr/src/homeassistant/homeassistant/core.py", line 1849, in async_call task.result() File "/usr/src/homeassistant/homeassistant/core.py", line 1889, in _execute_service await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)( File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 226, in handle_service await service.entity_service_call( File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 798, in entity_service_call future.result() # pop exception if have File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 980, in async_request_call await coro File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 838, in _handle_entity_call await result File "/usr/src/homeassistant/homeassistant/components/light/init.py", line 582, in async_handle_light_on_service await light.async_turn_on(filter_turn_on_params(light, params)) File "/usr/src/homeassistant/homeassistant/components/zha/light.py", line 1197, in async_turn_on await super().async_turn_on(kwargs) File "/usr/src/homeassistant/homeassistant/components/zha/light.py", line 360, in async_turn_on result = await self._on_off_cluster_handler.on() File "/usr/local/lib/python3.10/site-packages/zigpy/zcl/init.py", line 331, in request return await self._endpoint.request( File "/usr/local/lib/python3.10/site-packages/zigpy/group.py", line 57, in request await self.application.send_packet( File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 1050, in send_packet response = await self._send_request_raw( File "/usr/local/lib/python3.10/site-packages/zigpy_znp/zigbee/application.py", line 860, in _send_request_raw raise DeliveryError("Coordinator is disconnected, cannot send request") zigpy.exceptions.DeliveryError: Coordinator is disconnected, cannot send request

Sent via RFC 1149 Get some Carrier Pigeonshttps://en.m.wikipedia.org/wiki/IP_over_Avian_Carriers...

From: John Lento @.> Sent: Monday, May 22, 2023 3:46:35 PM To: Koenkk/Z-Stack-firmware @.>; Koenkk/Z-Stack-firmware @.> Cc: Mention @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230507 feedback (Issue #439)

This update has been pushing a lot more sengled bulbs offline sooner and I’m still getting a lot of timeouts. I think the last release was more stable. I still don’t know what to do about timeouts and what not. Could a USB extension that is too long be a problem? I still have a lot of coordinator and watch dog restarts.

Sent via RFC 1149 Get some Carrier Pigeonshttps://en.m.wikipedia.org/wiki/IP_over_Avian_Carriers...

From: Brad @.> Sent: Monday, May 22, 2023 3:41:38 PM To: Koenkk/Z-Stack-firmware @.> Cc: johnlento @.>; Mention @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230507 feedback (Issue #439)

Overnight, i had an issue where the coordinator failed. The restarted adapter then retarted Z2M add on and slowy the devices came back online. Now im seeing devices show offline and i have to got around and pair them.

error 2023-05-23 01:19:37: Error: CommandResponse 0x00158d0006b39f15/1 genOta.queryNextImageResponse({"status":152}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":1,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms) error 2023-05-23 01:19:47: Exception while calling fromZigbee converter: Command 0x70ac08fffe916c19/1 manuSpecificTuya.mcuGatewayConnectionStatus({"payloadSize":1,"payload":1}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - UTIL - assocGetWithAddress after 6000ms)}

Does anyone else use alot of Tuya devices?

— Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1557840895, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRT4MUEPZFS3TDIVPRFTXHO6PFANCNFSM6AAAAAAWPPN23Q. You are receiving this because you were mentioned.Message ID: @.***>

wgentine commented 1 year ago

After updating to 20230507, my entire network went down after a few hours... no coordinator errors in the logs. Switched back to the 20221226 and was even more strange...had to re-pair all devices back... quite a long process.

pannal commented 1 year ago

zzh (CC2652R) working well with the latest firmware.

johnlento commented 1 year ago

I reverted to 20230401 and everything is much more responsive than 20230507. Will see how long things stay online.

Sent via RFC 1149 Get some Carrier Pigeonshttps://en.m.wikipedia.org/wiki/IP_over_Avian_Carriers...

From: pannal @.> Sent: Saturday, May 27, 2023 8:45:18 PM To: Koenkk/Z-Stack-firmware @.> Cc: johnlento @.>; Mention @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230507 feedback (Issue #439)

zzh (CC2652R) working well with the latest firmware.

— Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1565767027, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRT7ELAXP5LJ2Q4MG6TLXIKNZ5ANCNFSM6AAAAAAWPPN23Q. You are receiving this because you were mentioned.Message ID: @.***>

dlasher commented 1 year ago

Improvements here for me in 20230507

Total 73

@Koenkk : is there a way to generate a txt/csv/CLI-style route map? I'd like to go through the device list, figure out which devices have the least/weakest routes (over time) and fix them. Feels like an opportunity for tuning here.

popy2k14 commented 1 year ago

@Koenkk i am also running 20230507 for quite a while on my rather big network (~160 devices). The slowdowns are here but rather rare in comparisation to previous stable 20221226.

Koenkk commented 1 year ago

@dlasher you can generate a raw (=json) networkmap: https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#zigbee2mqtt-bridge-request-networkmap

cloudbr34k84 commented 1 year ago

My only issue is im seeing bulbs and led strip light controllers go offline. I do get the occasional adapter 6000 error, but it's easy to recover from that with the poe adapter. Definitely more responsive.

dlasher commented 1 year ago

@dlasher you can generate a raw (=json) networkmap: https://www.zigbee2mqtt.io/guide/usage/mqtt_topics_and_messages.html#zigbee2mqtt-bridge-request-networkmap

Interesting. I'll have to play with that. Thanks!

joydashy commented 1 year ago

I'm very new to z2m, but my feedback is that for me, using the Hamgeek POE adapter (also mentioned here: https://github.com/Koenkk/zigbee2mqtt/discussions/17360), the 20221226 firmware would result in a non-operational device. Web page would work fine, but z2m would not connect.

I just flashed 20230507, and now it's working !

lvanjaarsveld commented 1 year ago

For the first time ever I had the addon come to a full stop and did not watchdog restart.

2023-06-03T17:35:26.121Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":62109,"destendpoint":2,"srcendpoint":1,"clusterid":1030,"transid":13,"options":0,"radius":30,"len":8,"data":{"type":"Buffer","data":[16,3,2,16,0,33,1,0]}} 2023-06-03T17:35:26.122Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,18,36,1,157,242,2,1,6,4,13,0,30,8,16,3,2,16,0,33,1,0,99] 2023-06-03T17:35:26.123Z zigbee-herdsman:controller:endpoint Bind 0x001788010918355f/2 genPowerCfg from '0x00124b00237dfbc0/1' failed (AREQ - ZDO - bindRsp after 10000ms) Error: Bind 0x001788010918355f/2 genPowerCfg from '0x00124b00237dfbc0/1' failed (AREQ - ZDO - bindRsp after 10000ms) at Timeout._onTimeout (/app/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35) at listOnTimeout (node:internal/timers:559:17) at processTimers (node:internal/timers:502:7)

jasondefuria commented 1 year ago

I'm getting a lot of hangs lately- 20230507 worked well for weeks, but now disconnects in about 12 hours (or less!)

Here are the last logs that I have

2023-06-06` 20:39:04.368 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x5F5A:1:0x0b04]: async_update
2023-06-06 20:39:04.369 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x5F5A:1:0x0b04]: Reading attributes in chunks: ['active_power', 'rms_current', 'rms_voltage', 'ac_frequency']
2023-06-06 20:39:04.369 DEBUG (MainThread) [zigpy.zcl] [0x5F5A:1:0x0b04] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=101, command_id=<GeneralCommand.Read_Attributes: 0>, *direction=<Direction.Server_to_Client: 0>)
2023-06-06 20:39:04.369 DEBUG (MainThread) [zigpy.zcl] [0x5F5A:1:0x0b04] Sending request: Read_Attributes(attribute_ids=[1291, 1288, 1285, 768])
2023-06-06 20:39:04.370 DEBUG (MainThread) [zigpy_znp.zigbee.application] Sending packet ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x5F5A), dst_ep=1, source_route=None, extended_timeout=False, tsn=101, profile_id=260, cluster_id=2820, data=Serialized[b'\x00e\x00\x0b\x05\x08\x05\x05\x05\x00\x03'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=None, rssi=None)
2023-06-06 20:39:04.370 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x5F5A:1:0x0b04]: failed to get attributes '['active_power', 'rms_current', 'rms_voltage', 'ac_frequency']' on 'electrical_measurement' cluster: Coordinator is disconnected, cannot send request
2023-06-06 20:39:04.370 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x43AF:1:0x0b04]: async_update
2023-06-06 20:39:04.370 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x43AF:1:0x0b04]: Reading attributes in chunks: ['active_power', 'rms_current', 'rms_voltage', 'ac_frequency']
2023-06-06 20:39:04.371 DEBUG (MainThread) [zigpy.zcl] [0x43AF:1:0x0b04] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=102, command_id=<GeneralCommand.Read_Attributes: 0>, *direction=<Direction.Server_to_Client: 0>)
2023-06-06 20:39:04.371 DEBUG (MainThread) [zigpy.zcl] [0x43AF:1:0x0b04] Sending request: Read_Attributes(attribute_ids=[1291, 1288, 1285, 768])
2023-06-06 20:39:04.371 DEBUG (MainThread) [zigpy_znp.zigbee.application] Sending packet ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x43AF), dst_ep=1, source_route=None, extended_timeout=False, tsn=102, profile_id=260, cluster_id=2820, data=Serialized[b'\x00f\x00\x0b\x05\x08\x05\x05\x05\x00\x03'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=None, rssi=None)
2023-06-06 20:39:04.371 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0x43AF:1:0x0b04]: failed to get attributes '['active_power', 'rms_current', 'rms_voltage', 'ac_frequency']' on 'electrical_measurement' cluster: Coordinator is disconnected, cannot send request
2023-06-06 20:39:04.371 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0xD6ED:1:0x0b04]: async_update
2023-06-06 20:39:04.371 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0xD6ED:1:0x0b04]: Reading attributes in chunks: ['active_power', 'rms_current', 'rms_voltage', 'ac_frequency']
2023-06-06 20:39:04.372 DEBUG (MainThread) [zigpy.zcl] [0xD6ED:1:0x0b04] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True), tsn=103, command_id=<GeneralCommand.Read_Attributes: 0>, *direction=<Direction.Server_to_Client: 0>)
2023-06-06 20:39:04.372 DEBUG (MainThread) [zigpy.zcl] [0xD6ED:1:0x0b04] Sending request: Read_Attributes(attribute_ids=[1291, 1288, 1285, 768])
2023-06-06 20:39:04.372 DEBUG (MainThread) [zigpy_znp.zigbee.application] Sending packet ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xD6ED), dst_ep=1, source_route=None, extended_timeout=False, tsn=103, profile_id=260, cluster_id=2820, data=Serialized[b'\x00g\x00\x0b\x05\x08\x05\x05\x05\x00\x03'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=None, rssi=None)
2023-06-06 20:39:04.372 DEBUG (MainThread) [homeassistant.components.zha.core.cluster_handlers] [0xD6ED:1:0x0b04]: failed to get attributes '['active_power', 'rms_current', 'rms_voltage', 'ac_frequency']' on 'electrical_measurement' cluster: Coordinator is disconnected, cannot send request
2023-06-06 20:39:04.866 DEBUG (MainThread) [zigpy_znp.zigbee.application] Trying to reconnect to /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0, attempt 52
2023-06-06 20:39:04.866 DEBUG (MainThread) [zigpy_znp.uart] Connecting to /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 at 115200 baud
2023-06-06 20:39:04.872 DEBUG (MainThread) [zigpy_znp.uart] Opened /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 serial port
2023-06-06 20:39:04.872 DEBUG (MainThread) [zigpy_znp.uart] Connected to /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 at 115200 baud
2023-06-06 20:39:04.872 DEBUG (MainThread) [zigpy_znp.api] Toggling RTS/DTR pins to skip bootloader or reset chip
2023-06-06 20:39:04.873 DEBUG (MainThread) [zigpy_znp.uart] Setting serial pin states: DTR=False, RTS=False
2023-06-06 20:39:05.024 DEBUG (MainThread) [zigpy_znp.uart] Setting serial pin states: DTR=False, RTS=True
2023-06-06 20:39:05.175 DEBUG (MainThread) [zigpy_znp.uart] Setting serial pin states: DTR=False, RTS=False
2023-06-06 20:39:05.327 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-06-06 20:39:05.829 DEBUG (MainThread) [zigpy_znp.api] Sending CC253x bootloader skip bytes
2023-06-06 20:39:08.331 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-06-06 20:39:09.332 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-06-06 20:39:10.024 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x31B5](FYRTUR block-out roller blind): Device seen - marking the device available and resetting counter
2023-06-06 20:39:10.024 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x31B5](FYRTUR block-out roller blind): Update device availability -  device available: True - new availability: True - changed: False
2023-06-06 20:39:10.333 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-06-06 20:39:11.334 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-06-06 20:39:12.002 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x7179](FLEX RGBW): Device seen - marking the device available and resetting counter
2023-06-06 20:39:12.002 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x7179](FLEX RGBW): Update device availability -  device available: True - new availability: True - changed: False
2023-06-06 20:39:12.004 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x85CF](PLUG): Device seen - marking the device available and resetting counter
2023-06-06 20:39:12.004 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x85CF](PLUG): Update device availability -  device available: True - new availability: True - changed: False
2023-06-06 20:39:12.092 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x1DD7](TRADFRI open/close remote): Device seen - marking the device available and resetting counter
2023-06-06 20:39:12.092 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x1DD7](TRADFRI open/close remote): Update device availability -  device available: True - new availability: True - changed: False
2023-06-06 20:39:12.124 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x7F41](FYRTUR block-out roller blind): Device seen - marking the device available and resetting counter
2023-06-06 20:39:12.124 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x7F41](FYRTUR block-out roller blind): Update device availability -  device available: True - new availability: True - changed: False
2023-06-06 20:39:12.335 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-06-06 20:39:13.335 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-06-06 20:39:14.336 DEBUG (MainThread) [zigpy_znp.api] Sending request: SYS.Ping.Req()
2023-06-06 20:39:14.873 DEBUG (MainThread) [zigpy_znp.api] Connection to /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 failed, cleaning up
2023-06-06 20:39:14.873 DEBUG (MainThread) [zigpy_znp.uart] Closing serial port
2023-06-06 20:39:14.873 ERROR (MainThread) [zigpy_znp.zigbee.application] Failed to reconnect
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/zigpy_znp/api.py", line 673, in _skip_bootloader
    result = await responses.get()
             ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/queues.py", line 158, in get
    await getter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/zigpy_znp/zigbee/application.py", line 754, in _reconnect
    await self.connect()
  File "/usr/local/lib/python3.11/site-packages/zigpy_znp/zigbee/application.py", line 107, in connect
    await znp.connect()
  File "/usr/local/lib/python3.11/site-packages/zigpy_znp/api.py", line 715, in connect
    self.capabilities = (await self._skip_bootloader()).Capabilities
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/zigpy_znp/api.py", line 672, in _skip_bootloader
    async with async_timeout.timeout(CONNECT_PROBE_TIMEOUT):
  File "/usr/local/lib/python3.11/site-packages/async_timeout/__init__.py", line 129, in __aexit__
    self._do_exit(exc_type)
  File "/usr/local/lib/python3.11/site-packages/async_timeout/__init__.py", line 212, in _do_exit
    raise asyncio.TimeoutError
TimeoutError
Koenkk commented 1 year ago

Since most are experiencing improvements with 20230507, I've made it the recommended firmware now.

For those having issues with 20230507, can you check if these same issues show up with 20221226?

popy2k14 commented 1 year ago

Thx for the efforts made in this release! The only thing which happens to me sometimes is a slowdown in delivering messages. You press an button and wait seconds for it to get delivered/executed.

Other than that, my network is stable with it. Here are my stats:

Zigbee2MQTT Version 1.31.1 commit: unknown Coordinator-Typ zStack3x0 Coordinator-Version 20230507 Frontend Version 0.6.129

Statistiken Gesamt 143 Nach Typ Endgerät: 86 Router: 57 Nach Stromquelle Batterie: 86 Netz (einphasig): 54 Gleichstromquelle: 3 Nach Hersteller Philips: 42 Signify Netherlands B.V.: 41 LUMI: 31 IKEA of Sweden: 11 Heiman: 4 YSRSAI: 3 Paulmann Licht: 3 HEIMAN: 3 innr: 2 Paulmann Licht GmbH : 1 Develco: 1 _TZE200_s8gkrkxk: 1 Nach Modell lumi.sensor_magnet.aq2: 25 RWL021: 24 LWB010: 12 SML001: 9 LTW013: 6 LTW010: 6 LOM007: 5 LST002: 5 FYRTUR block-out roller blind: 4 SMOK_YDLV10: 4 LTW012: 4 KADRILJ roller blind: 4 ZB-CL01: 3 500.48: 3 lumi.sensor_motion.aq2: 3 lumi.sensor_switch: 3 TRADFRI open/close remote: 3 LCT015: 3 LCL001: 2 SML003: 2 LCT007: 2 FL 120 C: 2 SmokeSensor-N-3.0: 2 SML002: 1 Switch Controller : 1 LWG004: 1 ZHEMI101: 1 SmokeSensor-EF-3.0: 1 LTA001: 1 TS0601: 1

popy2k14 commented 1 year ago

@Koenkk is there something like an priority on messages?

I think of the following: An flag that a message is a user triggered message. This messages gets priority over other status updates.

This way, the network is responsive to the user Is there something like that?

sjorge commented 1 year ago

Not on the zigbee level AFAIK, but I guess in theory have a message queue system (we already sort of do for sending to sleeping devices) where there is a 'priority' element taken into account, but we don't have that atm.

Also there are message related to the mesh management for example that should always be higher priority, e.g. a route discovery, ... it will get very complex very quickly.

I also noticed you have a few FYRTUR block-out roller blind If the are on the latest fw with ver 24, make sure to grab the latest hotfix z2m release. There is a weird issue with that firmware where they spam the mesh, which is fixed by configuring them slightly differently. That could certainly becausing a lot of slow downs.

On that note, I myself saw some improvements when eliminated 1-device groups. I use groups for all my lights and for constancy I also created them for single lights. And since I already had a few ikea remotes that I was not using because the lack of group binding I swapped some of them. That has reduced the amount of broadcasts, which has improved latancy for me too. I still have a lot of groups left though that I won't be getting rid of anytime soon.

MattWestb commented 1 year ago

@sjorge You is having one pritty large network with lights and they is using the mesh in more levels for group broadcast. Is always the first level working (that is getting the commands direct from the coordinator) and the level behind not working ?

I thinking this problem is blocking the network with broadcast storming that is also blocking the router discovery for making usnicasts until the broadcast storm have running out and the network is working normal. I was posting one issue for fixing this in the coordinator firmware but is not popular doing it but its needed for not blocking the network from time to time. https://github.com/Koenkk/Z-Stack-firmware/issues/443

sjorge commented 1 year ago

@MattWestb #443 is actually what made me eliminate some of the useless groups. Generally it was OK but when for example I asked siri to activate night scene it would send the state=off to 4x4 lights, 3x2 lights, 1x2 lights, 6x1 light, 2x1 outlet groups. There was a 1/4 chance the mesh sort of went 💩 for like 30 secs before it recovered.

I eliminated the 6x1 light and 2x1 outlet groups and it's not been an issue. And those were pretty useless. I did like I mention swap out a few old fw remotes (didn't want to update them) for new fw remotes that do device binding.

That's probably also the reason IKEA switched there remotes to be device binding would be my guess.

MattWestb commented 1 year ago

@sjorge Then you is having the group problem is the light that have direct connection to the coordinator working and the blocking is for the lights that is getting the commands true one other router (that can being blocked) ?

sjorge commented 1 year ago

I don't remember, but generally most lighst are not connected to the coordinator for me.

popy2k14 commented 1 year ago

Not on the zigbee level AFAIK, but I guess in theory have a message queue system (we already sort of do for sending to sleeping devices) where there is a 'priority' element taken into account, but we don't have that atm.

Also there are message related to the mesh management for example that should always be higher priority, e.g. a route discovery, ... it will get very complex very quickly.

I also noticed you have a few FYRTUR block-out roller blind If the are on the latest fw with ver 24, make sure to grab the latest hotfix z2m release. There is a weird issue with that firmware where they spam the mesh, which is fixed by configuring them slightly differently. That could certainly becausing a lot of slow downs.

On that note, I myself saw some improvements when eliminated 1-device groups. I use groups for all my lights and for constancy I also created them for single lights. And since I already had a few ikea remotes that I was not using because the lack of group binding I swapped some of them. That has reduced the amount of broadcasts, which has improved latancy for me too. I still have a lot of groups left though that I won't be getting rid of anytime soon.

Thx for the hint regarding the fyrtur with firmware 24. I already set the checkintervall correctly after update and they are stopped sending too much broadcasts.

But also before fw 24 of the fyrtur's sometimes the network is unresponsive for a few seconds and come back. Not often during the day, but it happens.

I am using groups for group switching and scenes. Every room has a group with all lights in it with multiple scenes. Otherwise, when HA is handling groups it sends the command for every light as an unicast, which leads to lost commands to some lights. My experience, since i use zigbee is, (before deconz and now Z2M) use zigbee groups and scenes.

Sure if i send an group/scene command, all the lights will send status updates and maybe slowing down the network.

Would be nice if this could be fixed. But maybe it's an zigbee mesh design issue, that it cant handle such amounts of devices/messages at once.

sjorge commented 1 year ago

Sure if i send an group/scene command, all the lights will send status updates and maybe slowing down the network.

Unless you also have a remote bound to the group, z2m does not setup reporting for lights.

And yeah, that's also the reason i still use groups for more than 1 devices need to be controlled as a set.

popy2k14 commented 1 year ago

Sure if i send an group/scene command, all the lights will send status updates and maybe slowing down the network.

Unless you also have a remote bound to the group, z2m does not setup reporting for lights.

And yeah, that's also the reason i still use groups for more than 1 devices need to be controlled as a set.

I have setup my hue dimmers todo also other tasks than light and also set all the button actions to my needs. So i dont want to put them in a zigbee group and loose those functionality.

sjorge commented 1 year ago

I wouldn't expect your lights to have much reporting configured then.

popy2k14 commented 1 year ago

ok, so than it must be an other issue. As stated above. It's no major issue and i can live with it.

But sure, would be nice if there where no slowdowns.

nostalgie commented 1 year ago

I have problem with timeout on 1 from 4 switches. It stops turning on through the web interface, if you turn it on manually, the status is updated and freezes. It wasn't like this before.

Sonoff Zigbee 3.0 USB Dongle Plus and TuYa TS0012

Debug 2023-06-07 13:08:09Received MQTT message on 'zigbee2mqtt/Спальня - выключатель/left/set' with data 'OFF'
Debug 2023-06-07 13:08:09Publishing 'set' 'state' to 'Спальня - выключатель'
Error 2023-06-07 13:08:32Publish 'set' 'state' to 'Спальня - выключатель' failed: 'Error: Command 0xa4c138f5c07fff4a/1 genOnOff.off({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 15132 - 1 - 199 - 6 - 11 after 10000ms)'

Reconnecting (repair) helps for about an hour. I connected the switch through the hub via Tuya integration - no problem. Through zigbe2mqtt is.

But now there are no errors with NWK_TABLE_FULL

wildekek commented 1 year ago

Updated Slaesh stick from CC2652RB_coordinator_20221226 to CC2652RB_coordinator_20230507 and all my devices in Zigbee2MQTT are offline. Zigbee2MQTT does show the right coordinator version, and herdsman starts fine. After restarting the individual devices they work fine again. Edit: re-pair to re-start

tammeryousef1006 commented 1 year ago

i couldnt upgrade firmware with the flasher tool , went to docker method and upgrade went smoothly , after starting the addon had several failes and offline , repairing all devices fixed the issue

ginkel commented 1 year ago

I have been observing complete network breakdowns (all devices going offline, but no NWK_TABLE_FULL in the logs) with 20221226 starting approximately two days ago. Just discovered 20230507, updated my CC2652P-based Sonoff coordinator and will report whether it makes any difference.

KoKolaj commented 1 year ago

20230507 - updated my CC2652P Sonoff But with this version, problems with timeout different devices in the network began I'm back back FW Z-STACK_3.X.0_COORDINATOR_20220219 and the device is already working again error 2023-06-11 08:09:57: Publish 'set' 'state' to 'Main Light' failed: 'Error: Command 0xa4c1386f9685ebe7/1 genOnOff.on({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 21231 - 1 - 117 - 6 - 11 after 10000ms)'

marcosimeone commented 1 year ago

I have about 30 device, 20 of them are routers. I just upgraded to 20230507 from 20221226 and nothing works anymore. Logs are fulls with this: Error 2023-06-13 08:57:48Publish 'set' 'state' to 'Light Living Room' failed: 'Error: Command 0x00124b0026b6bf9d/1 genOnOff.on({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SREQ '--> ZDO - extRouteDisc - {"dstAddr":15773,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))'

I will have to rollback

pdecat commented 1 year ago

I have 104 devices from various brands (Aqara/LUMI/Xiaomi, CASAIA, IKEA, Legrand, LIDL, LiXee, Sonoff) in my Zigbee network, 62 of them being routers on mains power, not counting the coordinator which is a ZZH! (which I have been using since 2020/12).

I was running CC2652R_coordinator_20221226.hex without too much issues since 2023/01/29, but a few devices were slow to respond from time to time so I had hopes CC2652R_coordinator_20230507.hex would resolve those issues.

I flashed CC2652R_coordinator_20230507.hex on 2023/06/13 at noon, and since then the ZZH! froze twice in 35 hours, about 17 hours apart.

From ZHA point of view, the error seen in logs when it freezes is:

Jun 14 22:05:20 ha hass[957501]: 2023-06-14 22:05:20.052 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Jun 14 22:05:20 ha hass[957501]: Traceback (most recent call last):
Jun 14 22:05:20 ha hass[957501]:   File "/home/patrick/workspaces/homeassistant/home-assistant/venv/lib/python3.11/site-packages/zigpy_znp/api.py", line 1058, in request_callback_rsp
Jun 14 22:05:20 ha hass[957501]:     return await callback_rsp
Jun 14 22:05:20 ha hass[957501]:            ^^^^^^^^^^^^^^^^^^
Jun 14 22:05:20 ha hass[957501]: asyncio.exceptions.CancelledError
Jun 14 22:05:20 ha hass[957501]: During handling of the above exception, another exception occurred:
Jun 14 22:05:20 ha hass[957501]: Traceback (most recent call last):
Jun 14 22:05:20 ha hass[957501]:   File "/home/patrick/workspaces/homeassistant/home-assistant/venv/lib/python3.11/site-packages/zigpy_znp/api.py", line 1055, in request_callback_rsp
Jun 14 22:05:20 ha hass[957501]:     async with async_timeout.timeout(timeout):
Jun 14 22:05:20 ha hass[957501]:   File "/home/patrick/workspaces/homeassistant/home-assistant/venv/lib/python3.11/site-packages/async_timeout/__init__.py", line 129, in __aexit__
Jun 14 22:05:20 ha hass[957501]:     self._do_exit(exc_type)
Jun 14 22:05:20 ha hass[957501]:   File "/home/patrick/workspaces/homeassistant/home-assistant/venv/lib/python3.11/site-packages/async_timeout/__init__.py", line 212, in _do_exit
Jun 14 22:05:20 ha hass[957501]:     raise asyncio.TimeoutError
Jun 14 22:05:20 ha hass[957501]: TimeoutError

Only way to get it back responding was to physically unplug the ZZH! from the USB port. Just resetting the USB port did not help.

I've downgraded to CC2652R_coordinator_20221226.hex for now.

Update 2023/06/15 10:00: another freeze happened with CC2652R_coordinator_20221226.hex this morning after about 10 hours, some other thing is going on :disappointed:

Update 2023/06/15 10:30: cold rebooting did not resolve the issue, I've plugged the ZZH! in another USB port for now.

Update 2023/06/17 18:30: no issue since I switched USB ports 2 days ago, really weird. I'll retry upgrading the firmware soon.

Update 2023/06/19 10:30: another freeze happened, unplugging the ZZH! then re-plugging it in the port made it work again. Sounds like I could be affected by https://github.com/Koenkk/zigbee2mqtt/issues/8663 but I'm on Debian 12 with Linux kernel 6.1.0-9-amd64 (upstream 6.1.27-1).

Update 2023/06/22 08:00: another freeze happened at 00:30. Upgraded kernel from 6.1.0-9-amd64 (6.1.27-1) to 6.3.0-1-amd64 (6.3.7-1).

Update 2023/06/26 16:30: so far so good since the kernel upgrade. Will retry the firmware upgrade in next week if all goes well :crossed_fingers:.

Update 2023/06/29 07:00: another freeze happened at 00:03 after 7 days. Using usbreset did not help, had to unplug/replug the ZZH! :confused: Ordered a new USB extension lead cable.

Update 2023/06/29 11:45: another freeze happened at 11:23. Unplugged/replugged the ZZH! directly in a host USB port.

Update 2023/06/29 11:55: replaced the ZZH! SMA antenna by a larger one to compensate the removal of the USB extension lead.

Update 2023/06/29 23:55: another freeze on 2023/06/29 at 23:09. So the cable is not the issue...

Update 2023/06/30 09:45: another freeze on 2023/06/30 at 09:30. Ordered a Skyconnect...

Update 2023/06/30 16:55: another freeze on 2023/06/30 at 16:38. Replaced the USB extension lead by the active one that I just received.

Update 2023/06/30 19:55: another freeze on 2023/06/30 at 19:43. Unplugged/replugged the ZZH!, removed the USB extension lead. Is it possible the firmware downgrade was not complete or that data in the stick is corrupt? Version shown is CC1352/CC2652, Z-Stack 3.30+ (build 20221226)

Update 2023/07/01 12:55: decided to bite the bullet, and made network and NVRAM backups of the ZZH!, then reset the NVRAM, and restored the network backup only :crossed_fingers:. Still running CC2652R_coordinator_20221226.hex for now. First impression, everything is much more reactive :rocket:

The procedure I followed using https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md#backup-and-restore:

# git clone https://github.com/zigpy/zigpy-znp.git
# cd zigpy-znp
# git checkout dev
# python3 -m venv venv
# ./venv/bin/pip install .
# ./venv/bin/python -m zigpy_znp.tools.network_backup /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -o network_backup.json
# ./venv/bin/python -m zigpy_znp.tools.nvram_read /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -o nvram_backup.json

# # # DANGER since this point!
# ./venv/bin/python -m zigpy_znp.tools.nvram_reset /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 
# ./venv/bin/python -m zigpy_znp.tools.network_restore /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -i network_backup.json

Update 2023/07/04 05:45: another freeze on 2023/07/04 at 02:18 :disappointed:.

Update 2023/07/05 11:00: installed an external USB hub and plugged the ZZH! to it. Hopefully, I'll be able to reset the hub remotely next time the ZZH! freezes :crossed_fingers:

Update 2023/07/08 07:20: another freeze on 2023/07/08 at 07:11. Resetting the hub did not help, still had to physically disconnect then reconnect the ZZH! :disappointed:. Upgraded from Home Assistant 2023.6.2 to 2023.7.1.

Update 2023/07/08 14:00: Just received and installed the Tuya compatible Xystec NX-4986 WLAN USB hub with 4 individually switchable ports that will allow me to remotely unplug/replug the ZZH! when it freezes. Next step will be to automate this when freezes are detected.

Update 2023/07/09 10:50: new timeout errors appear in Home Assistant logs from time to time, sending commands was no longer working, but devices attributes were still updating. This time, I did not have to physically disconnect then reconnect the ZZH!, simply reloading the ZHA integration resolved the issue. Is the main issue caused by Home Assistant / ZHA / zigpy-znp? And I just happen to have tried CC2652R_coordinator_20230507.hex a few days after upgrading to Home Assistant 2023.6.0?

Update 2023/07/09 15:45: another freeze on 2023/07/09 at 15:20. Also, devices attributes stopped updating. Remotely unplugging/replugging the ZZH! with Xystec NX-4986 and Tuya application made it come back to life :tada:.

Update 2023/07/11 15:30: another freeze on 2023/07/11 at 15:05. Remotely unplugging/replugging the ZZH! with Xystec NX-4986 and Local Tuya Home Assistant integration made it come back to life :tada:.

Update 2023/07/14 09:50: upgraded to Home Assistant 2023.7.3 which includes some fixes for ZHA / zigpy-znp.

Update 2023/07/16 08:45: another freeze on 2023/07/16 at 01:41. Remotely unplugging/replugging the ZZH! with Xystec NX-4986 and Local Tuya Home Assistant integration made it come back to life :tada:.

Update 2023/07/16 09:25: the ZZH! is freezing every few minutes now, got to find something else to test...

Update 2023/07/16 10:40: made another network and NVRAM backups of the ZZH!, then fully erased the ZZH! memory and re-flashed it to CC2652R_coordinator_20221226.hex using cc2538-bsl, and restored the network backup only :crossed_fingers:

# git clone https://github.com/zigpy/zigpy-znp.git
# cd zigpy-znp
# git checkout dev
# python3 -m venv venv
# ./venv/bin/pip install .
# ./venv/bin/python -m zigpy_znp.tools.network_backup /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -o network_backup.json
# ./venv/bin/python -m zigpy_znp.tools.nvram_read /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -o nvram_backup.json

# # # DANGER since this point!

# Erased and reflashed the ZZH! with cc2538-bsl
# cc2538-bsl.py -p /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -evw CC2652R_coordinator_20221226.hex

# Then restored the network backup only:
# ./venv/bin/python -m zigpy_znp.tools.network_restore /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 -i network_backup.json

Update 2023/07/17 12:00: another freeze on 2023/07/17 at 11:36. Remotely unplugging/replugging the ZZH! with Xystec NX-4986 and Local Tuya Home Assistant integration made it come back to life :tada:.

Update 2023/07/18 00:00: tried the migration from the ZZH! (ZHA/zigpy-znp) to a Skyconnect (ZHA/bellows) at noon, but behavior was worse, especially with Ikea light bulbs and signal repeaters, and was seing the NCP entered failed state. Requesting APP controller restart frequently. Migrated back to the ZZH! after 12 hours.

Update 2023/07/20 18:20: everything is absolutely stable since I switched back to ZZH! with CC2652R_coordinator_20221226.hexon 2023/07/18 at 00:00. Let's hope it will last :crossed_fingers:

Update 2023/07/25 17:00: everything is still perfectly stable since I switched back to ZZH! a week ago with CC2652R_coordinator_20221226.hexon 2023/07/18 at 00:00. Let's hope it will last :crossed_fingers:

Update 2023/07/27 00:15: everything is still perfectly stable since I switched back to ZZH! a week ago with CC2652R_coordinator_20221226.hexon 2023/07/18 at 00:00. I've ditched the four IKEA Signal Repeaters I had in my network (now down to 102 devices), since they're often not responding, and apparently known for behaving as black holes which may explain the issue I was facing before June 15th. I had to reset/repair some devices which were apparently bound to them, but everything seems fine now.

~Update 2023/07/29 17:20: another freeze on 2023/00/29 at 15:47 :cry: ~ False alarm, it was just my Home Assistant Android app that did not refresh properly. :sweat_smile:

~Update 2023/08/31 17:30: not a single freeze since I properly downgraded on 2023/07/18.

jasondefuria commented 1 year ago

@pdecat - you say you have Ikea- do you have the blinds? The latest firmware causes them to spam unless your remove and repair them. I had all of the lockups that kept happening, but have been stable since they have all updated.

fsevilla3 commented 1 year ago

I have a Sonoff ZBDongle-P coordinator that was working fine on Z-Stack_3.x.0 coordinator 20221226. My network has 35 devices. Flashing to 20230507 worked fine using cc2538-bsl but as soon as I upgraded all my powered devices (Moes, Tuya, UseeLink) dropped off the network. The battery-powered Aqara devices worked fine, though. This appears to be related to the NWK_TABLE_FULL issue others have reported, although I've never had NWE_TABLE_FULL issues with 20221226.

I've rolled back to 20221226 and everything is working again now.

Here are some sample log entries:


warn  2023-06-16 09:45:40: Failed to ping 'Tuya Wall Switch Pantry' (attempt 2/2, Read 0xa4c138dc01930d32/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SREQ '--> ZDO - extRouteDisc - {"dstAddr":25815,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)')))
warn  2023-06-16 09:49:06: Failed to ping 'UseeLink Power Strip Lounge TV' (attempt 1/1, Read 0xa4c138ed638f47ff/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 22178 - 1 - 36 - 0 - 1 after 10000ms))
warn  2023-06-16 09:49:35: Failed to ping 'UseeLink Power Strip MBR TV' (attempt 1/1, Read 0x84fd27fffe8d6f6f/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 49691 - 1 - 37 - 0 - 1 after 10000ms))
warn  2023-06-16 09:50:03: Failed to ping 'Moes Socket Plug Lounge Purifier' (attempt 1/1, Read 0xa4c13836d6c933de/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 63368 - 1 - 38 - 0 - 1 after 10000ms))
warn  2023-06-16 09:50:31: Failed to ping 'Moes Socket Plug Dining Bug Zapper' (attempt 1/1, Read 0xa4c138967a69046d/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 13761 - 1 - 39 - 0 - 1 after 10000ms))
warn  2023-06-16 09:51:27: Failed to ping 'Tuya Wall Switch Entrance' (attempt 1/1, Read 0xa4c1381e922cc557/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 42315 - 1 - 41 - 0 - 1 after 10000ms))
warn  2023-06-16 09:51:55: Failed to ping 'Tuya Smart Plug Dishwasher' (attempt 1/1, Read 0xa4c13835e191d771/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 53897 - 1 - 42 - 0 - 1 after 10000ms))```
MattWestb commented 1 year ago

@pdecat - you say you have Ikea- do you have the blinds? The latest firmware causes them to spam unless your remove and repair them. I had all of the lockups that kept happening, but have been stable since they have all updated.

Its one fealty setting in Z2M that is setting the checkin time to short. delete and adding the new or setting the checking time manual to 55 minute and all shall working OK.

sjorge commented 1 year ago

@pdecat - you say you have Ikea- do you have the blinds? The latest firmware causes them to spam unless your remove and repair them. I had all of the lockups that kept happening, but have been stable since they have all updated.

Its one fealty setting in Z2M that is setting the checkin time to short. delete and adding the new or setting the checking time manual to 55 minute and all shall working OK.

If they are on the new patch release, they should automatically get reconfigured. Doesn't work if they have too many though as the network is insta flooded, but pulling the batteries and inserting them one by one works in that case.

harryfine commented 1 year ago

Sonoff ZBDongle-P coordinator that was working fine on Z-Stack_3.x.0 coordinator 20221226 in homeassistant. I had updated to December 2022 using the flashing tool, so I know how to use it, and it updated fine to December 2022.

I downloaded CC1352P2_CC2652P_launchpad_coordinator_20230507.hex. Put the Sonoff 3.0 Zigbee coordinator into boot mode. Recognized it, set to CC2652P, but it would not flash with flash programmer 2. Gave me error, unknown record type 3.

Similar issue is covered here: https://github.com/Koenkk/Z-Stack-firmware/issues/397

Some discussion in other threads that it has to do with the way it was compiled, other threads say 20230507 is too large for the chip, some have said converting it to a .bin file solved it for them. Anyway, it will not flash for me, no matter how many times I try.

moritz-john commented 1 year ago

I successfully utilized cc2538-bsl to update my SONOFF Zigbee 3.0 USB Dongle-P with the CC1352P2_CC2652P_launchpad_coordinator_20230507.hex file. 1) sudo python cc2538-bsl.py --bootloader-sonoff-usb (activate bootloader without opening the enclosure) 2) sudo python cc2538-bsl.py -p /dev/ttyUSB0 -evw CC1352P2_CC2652P_launchpad_coordinator_20230507.hex

Zigbee2MQTT performs flawlessly, ensuring the availability of all my devices, just as it did before.

harryfine commented 1 year ago

So what's the issue with the .hex file with the normal recommended way? Will it be fixed? Not everyone (including me) may be able to do this workaround.

Harry Fine

647-970-6378

On Jun 18, 2023, 04:22, at 04:22, moritz-john @.***> wrote:

I successfully utilized cc2538-bsl to update my SONOFF Zigbee 3.0 USB Dongle-P with the CC1352P2_CC2652P_launchpad_coordinator_20230507.hex file. 1) sudo python cc2538-bsl.py --bootloader-sonoff-usb 2) sudo python cc2538-bsl.py -p /dev/ttyUSB0 -evw CC1352P2_CC2652P_launchpad_coordinator_20230507.hex

Zigbee2MQTT performs flawlessly, ensuring the availability of all my devices, just as it did before.

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1596028363 You are receiving this because you commented.

Message ID: @.***>

harryfine commented 1 year ago

I think you also need to have a USB to serial converter for this to work, rather than just plugging the chip into a USB port?

Harry Fine

647-970-6378

On Jun 18, 2023, 04:22, at 04:22, moritz-john @.***> wrote:

I successfully utilized cc2538-bsl to update my SONOFF Zigbee 3.0 USB Dongle-P with the CC1352P2_CC2652P_launchpad_coordinator_20230507.hex file. 1) sudo python cc2538-bsl.py --bootloader-sonoff-usb 2) sudo python cc2538-bsl.py -p /dev/ttyUSB0 -evw CC1352P2_CC2652P_launchpad_coordinator_20230507.hex

Zigbee2MQTT performs flawlessly, ensuring the availability of all my devices, just as it did before.

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1596028363 You are receiving this because you commented.

Message ID: @.***>

pfak commented 1 year ago

No. Nothing further required for the Sonoff other than plugging it in and running cc2538-bsl.

On June 18, 2023 5:10:02 AM PDT, harryfine @.***> wrote:

I think you also need to have a USB to serial converter for this to work, rather than just plugging the chip into a USB port?

Harry Fine

647-970-6378

On Jun 18, 2023, 04:22, at 04:22, moritz-john @.***> wrote:

I successfully utilized cc2538-bsl to update my SONOFF Zigbee 3.0 USB Dongle-P with the CC1352P2_CC2652P_launchpad_coordinator_20230507.hex file. 1) sudo python cc2538-bsl.py --bootloader-sonoff-usb 2) sudo python cc2538-bsl.py -p /dev/ttyUSB0 -evw CC1352P2_CC2652P_launchpad_coordinator_20230507.hex

Zigbee2MQTT performs flawlessly, ensuring the availability of all my devices, just as it did before.

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1596028363 You are receiving this because you commented.

Message ID: @.***>

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1596123222 You are receiving this because you were mentioned.

Message ID: @.***> -- Peter Kieser

harryfine commented 1 year ago

Does it have to go into boot mode first, as you did with the flasher?  Sorry, I just don't want to screw it up.

-----Original Message----- From: Peter Kieser @.> Reply-To: Koenkk/Z-Stack-firmware @.> To: Koenkk/Z-Stack-firmware @.> Cc: harryfine @.>, Comment @.***> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230507 feedback (Issue #439) Date: 2023-06-18 10:35:35 AM

No. Nothing further required for the Sonoff other than plugging it in and running cc2538-bsl.

On June 18, 2023 5:10:02 AM PDT, harryfine @.***> wrote:

I think you also need to have a USB to serial converter for this to work, rather than just plugging the chip into a USB port?

Harry Fine

647-970-6378

On Jun 18, 2023, 04:22, at 04:22, moritz-john @.***> wrote:

I successfully utilized cc2538-bsl to update my SONOFF Zigbee 3.0 USB Dongle-P with the CC1352P2_CC2652P_launchpad_coordinator_20230507.hex file. 1) sudo python cc2538-bsl.py --bootloader-sonoff-usb 2) sudo python cc2538-bsl.py -p /dev/ttyUSB0 -evw CC1352P2_CC2652P_launchpad_coordinator_20230507.hex

Zigbee2MQTT performs flawlessly, ensuring the availability of all my devices, just as it did before.

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1596028363 You are receiving this because you commented.

Message ID: @.***>

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1596123222 You are receiving this because you were mentioned.

Message ID: @.***>

harryfine commented 1 year ago

For me it seems to be sudo python3, but when I run it, I get:

[sudo] password for harry1: cc2538-bsl.py requires the Python serial library Please install it with:

pip3 install pyserial

I tried do apt list | grep pyserial but it didn't come up with anything.

-----Original Message----- From: Peter Kieser @.> Reply-To: Koenkk/Z-Stack-firmware @.> To: Koenkk/Z-Stack-firmware @.> Cc: harryfine @.>, Comment @.***> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230507 feedback (Issue #439) Date: 2023-06-18 10:35:35 AM

No. Nothing further required for the Sonoff other than plugging it in and running cc2538-bsl.

On June 18, 2023 5:10:02 AM PDT, harryfine @.***> wrote:

I think you also need to have a USB to serial converter for this to work, rather than just plugging the chip into a USB port?

Harry Fine

647-970-6378

On Jun 18, 2023, 04:22, at 04:22, moritz-john @.***> wrote:

I successfully utilized cc2538-bsl to update my SONOFF Zigbee 3.0 USB Dongle-P with the CC1352P2_CC2652P_launchpad_coordinator_20230507.hex file. 1) sudo python cc2538-bsl.py --bootloader-sonoff-usb 2) sudo python cc2538-bsl.py -p /dev/ttyUSB0 -evw CC1352P2_CC2652P_launchpad_coordinator_20230507.hex

Zigbee2MQTT performs flawlessly, ensuring the availability of all my devices, just as it did before.

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1596028363 You are receiving this because you commented.

Message ID: @.***>

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1596123222 You are receiving this because you were mentioned.

Message ID: @.***>

cloudbr34k84 commented 1 year ago

My only issue is that devices drop off for some reason error 2023-06-19 15:59:56: Publish 'set' 'state' to 'Gin Lounge EM Plug' failed: 'Error: Command 0xa4c1383b60f41ba5/1 genOnOff.off({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 40613 - 1 - 77 - 6 - 11 after 10000ms)

Then for some reason my PoE adapter crashes. Spinning it back up is such an ease, but still.

pannal commented 1 year ago

For me it seems to be sudo python3, but when I run it, I get: [sudo] password for harry1: cc2538-bsl.py requires the Python serial library Please install it with: pip3 install pyserial I tried do apt list | grep pyserial but it didn't come up with anything. … -----Original Message----- From: Peter Kieser @.> Reply-To: Koenkk/Z-Stack-firmware @.> To: Koenkk/Z-Stack-firmware @.> Cc: harryfine @.>, Comment @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230507 feedback (Issue #439) Date: 2023-06-18 10:35:35 AM No. Nothing further required for the Sonoff other than plugging it in and running cc2538-bsl. On June 18, 2023 5:10:02 AM PDT, harryfine @.> wrote: I think you also need to have a USB to serial converter for this to work, rather than just plugging the chip into a USB port? Harry Fine 647-970-6378 On Jun 18, 2023, 04:22, at 04:22, moritz-john @.> wrote: >I successfully utilized >cc2538-bsl to update my >SONOFF Zigbee 3.0 USB Dongle-P with the >CC1352P2_CC2652P_launchpad_coordinator_20230507.hex file. >1) sudo python cc2538-bsl.py --bootloader-sonoff-usb >2) sudo python cc2538-bsl.py -p /dev/ttyUSB0 -evw >CC1352P2_CC2652P_launchpad_coordinator_20230507.hex > >Zigbee2MQTT performs flawlessly, ensuring the availability of all my >devices, just as it did before. > > >-- >Reply to this email directly or view it on GitHub: >#439 (comment) >You are receiving this because you commented. > >Message ID: @.> -- Reply to this email directly or view it on GitHub: #439 (comment) You are receiving this because you were mentioned. Message ID: @.***>

It literally tells you what to do.

Am I missing something or why don't you just pip3 install pyserial?

satter commented 1 year ago

I'm running version 20230507 on Sonoff USB Dongle without any issue for a few days. Did not notice any difference from 20221226. Will be watching for this issue to reoccur

Did upgrade with single command, no need to activate bootloader beforehand

python3 /opt/cc2538-bsl/cc2538-bsl.py -e -v -w --bootloader-sonoff-usb /tmp/CC1352P2_CC2652P_launchpad_coordinator_20230507.hex
harryfine commented 1 year ago

I had the same problem, it seems that with this version, the new version that the flasher program doesn't work, the developer has posted some instructions to do it using another method. Once you learn the other method, it's even easier because you don't have to take the dongle apart to put it into boot mode. You have to make sure Python is installed and some other stuff and then it's a simple command line that updates it.

Harry Fine

647-970-6378

On Jun 23, 2023, 11:09, at 11:09, azsystem @.***> wrote:

How did you perform the update? I have tried it using FlashProgrammer 2 and it failed

-- Reply to this email directly or view it on GitHub: https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1604421432 You are receiving this because you commented.

Message ID: @.***>