I've just had my adapter completely crash out. It's no longer responding, even after restarting the server and using https://github.com/mvp/uhubctl to reset power to the adapter. I likely need to pull it from the port to fix it, which I can't do right now. Here's the logs from before it crashed. I will re-enable debug logging when I do, but I'll say that this took several days or even a week before it happened.
May 20 20:08:35 zigbee2mqtt npm[9396]: Zigbee2MQTT:info  2023-05-20 20:08:35: MQTT publish: topic 'zigbee2mqtt/Pedestal 4/availability', payload 'offline'
May 20 20:08:38 zigbee2mqtt npm[9396]: Zigbee2MQTT:error 2023-05-20 20:08:38: Publish 'set' 'color_temp' to 'Main Floor Hallway' failed: 'Error: Command 1 lightingColorCtrl.moveToColorTemp({"colortemp":373,"transtime":450}) failed (SRSP - AF - dataRequest
Ext after 6000ms)'
May 20 20:08:55 zigbee2mqtt npm[9396]: Zigbee2MQTT:warn  2023-05-20 20:08:55: Failed to ping 'Desk 1' (attempt 1/1, Read 0xb0ce1814030112c2/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 (SRSP - AF - dataRequest after 6000ms))
May 20 20:09:20 zigbee2mqtt npm[9396]: Zigbee2MQTT:warn  2023-05-20 20:09:20: Failed to ping 'Door 2' (attempt 1/1, Read 0xb0ce1814030151bf/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 (SRSP - AF - dataRequest after 6000ms))
May 20 20:09:52 zigbee2mqtt npm[9396]: Zigbee2MQTT:warn  2023-05-20 20:09:52: Failed to ping 'Josephine’s Side Table' (attempt 1/1, Read 0xa4c138e8c3e759b7/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disable
Recovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
May 20 20:10:03 zigbee2mqtt npm[9396]: Zigbee2MQTT:warn  2023-05-20 20:10:03: Failed to ping 'Emily’s Side Table' (attempt 1/1, Read 0xa4c138d11f67cdfd/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableReco
very":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
May 20 20:10:27 zigbee2mqtt npm[9396]: Zigbee2MQTT:warn  2023-05-20 20:10:27: Failed to ping 'Desk 2' (attempt 1/1, Read 0xb0ce18140301d37f/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 (SRSP - AF - dataRequest after 6000ms))
May 20 20:12:05 zigbee2mqtt npm[9396]: Zigbee2MQTT:warn  2023-05-20 20:12:05: Failed to ping 'Desk 1' (attempt 1/1, Read 0xb0ce1814030112c2/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 (SRSP - AF - dataRequest after 6000ms))
May 20 20:12:22 zigbee2mqtt npm[9396]: Zigbee2MQTT:warn  2023-05-20 20:12:22: Failed to ping 'Pedestal 1' (attempt 1/2, Read 0xb0ce18140301289c/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":tr
ue,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SRSP - AF - dataRequest after 6000ms))
May 20 20:12:31 zigbee2mqtt npm[9396]: Error: SRSP - SYS - version after 6000ms
May 20 20:12:31 zigbee2mqtt npm[9396]:     at Timeout._onTimeout (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35)
May 20 20:12:31 zigbee2mqtt npm[9396]:     at listOnTimeout (node:internal/timers:559:17)
May 20 20:12:31 zigbee2mqtt npm[9396]:     at processTimers (node:internal/timers:502:7)
May 20 20:12:31 zigbee2mqtt systemd[1]: zigbee2mqtt.service: Main process exited, code=exited, status=1/FAILURE
May 20 20:12:31 zigbee2mqtt systemd[1]: zigbee2mqtt.service: Failed with result 'exit-code'.
May 20 20:12:31 zigbee2mqtt systemd[1]: zigbee2mqtt.service: Scheduled restart job, restart counter is at 1.
May 20 20:12:31 zigbee2mqtt systemd[1]: Stopped zigbee2mqtt.

Bus 001 Device 015: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

If anyone has any other tricks for remotely resetting a zzh! I'd be glad to hear them!

20230507 feels more responsive.
I do have way more unavailable for all sensors. Just witnessed one and looks like the addon is restarting. Logging mentions a ton of timeouts before.

An update. Moved my coordinator away from as much interference as possible. Changed to channel 25. Repaird all 125 devices. I have light that im trying to link but just can't get it to stay paired.
Definitely more responsive since I removed the chatty tuya devices.  Fingers crossed.
I might add some more of the ham geek adapters and flash them with router firmware to see if that helps with coverage.

@Koenkk
Great work, just switched to your implementation for the CC1352P7 using BeagleBoard BeaglePlay.
Before I was using older self complied version. So far all good - but this is experimental network.
In free time I will try to address dual stack implementation to utilize Sub 1GHz features of the chip.
The idea is to have Zigbee and proprietary 868 MHz protocol stack running on same radio chip using DMM approach from TI.

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 ?

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?

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: @.***>

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: @.***>

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.

zzh (CC2652R) working well with the latest firmware.

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: @.***>

Improvements here for me in 20230507

have been running 20221122 for a few months, and a couple weeks ago the adapter (HamGeek CC2652P ETH) started rebooting every few minutes (adapter disconnected). Rebooting/power/offline didn't help. Flashing to latest, and adapter appears stable. So far so good.

@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.

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 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!

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 !

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)

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: Device seen - marking the device available and resetting counter
2023-06-06 20:39:12.004 DEBUG (MainThread) [homeassistant.components.zha.core.device] 0x85CF: 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
`

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?

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

@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?

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.

@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

@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.

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

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 teh fyrtur's sometimes the network is unresponsive for a fex 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.

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.

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

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.

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

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 re-pairing devices work fine again.

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

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.

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)'

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

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!.
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 yesterday at noon, and since then the ZZH! froze twice in 36 hours, about 18 hours apart.
 Just resetting the USB port did not help.
I've downgraded to CC2652R_coordinator_20221226.hex for now.

@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.

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. It appears to be related to the NWK_TABLE_FULL issue others have reported. The battery-powered Aqara devices worked fine, though. I've had to roll 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))```

@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.

@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.

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.
If is covered here:

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.

I successfully utilized cc2538-bsl to update my SONOFF Zigbee 3.0 USB Dongle-P with the CC1352P2_CC2652P_launchpad_coordinator_20230507.hex file.

sudo python cc2538-bsl.py --bootloader-sonoff-usb
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.

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.

sudo python cc2538-bsl.py --bootloader-sonoff-usb
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: @.***>

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.

sudo python cc2538-bsl.py --bootloader-sonoff-usb
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: @.***>

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.

sudo python cc2538-bsl.py --bootloader-sonoff-usb
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

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.

sudo python cc2538-bsl.py --bootloader-sonoff-usb
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: @.***>

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.

sudo python cc2538-bsl.py --bootloader-sonoff-usb
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: @.***>

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.

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<PHONE_NUMBER> 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?

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

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

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.
 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: @.***>

So I finally bit the bullet and went to 0507 and started to repair all devices. A lot of them fall offline quick well faster than the 8 hour timeout. Also, it seems like my home assistant instance is crashing. I’m not sure if it’s because of the firmware or what but a lot of timeouts and watch dog failures. Anyone have this? 0411 was stable for a good week and half at a time but 0507 just seems to wreck me.
Sent via RFC 1149
Get some Carrier Pigeonshttps://en.m.wikipedia.org/wiki/IP_over_Avian_Carriers...

From: harryfine @.>
Sent: Friday, June 23, 2023 12:21:56 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)
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.
 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: @.***>

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

Upgraded to this firmware, as I thought the TubeZB poe module had latest as it had paper stating latest firmware flashed and i ordered week ago, but before I had version 20221226 had a lot of issues with NWK_TABLE_FULL after upgrade it seams better and more responsive, but still getting NWK_TABLE_FULL errors:
My setup is this:

Zigbee2MQTT version: 1.31.2 commit: unknown
Coordinator type: zStack3x0
Coordinator revision: 20230507
Coordinator IEEE Address: 0x00124b002a2e354a
Frontend version: 0.6.129
Stats
Total: 97
By device type
Router: 97
By power source
Mains (single phase): 97
By vendor
IKEA of Sweden: 77
_TZE200_holel4dk: 11
_TZE200_jva8ink8: 8
SONOFF: 1
By model
TRADFRIbulbE27WSglobeclear806lm: 56
TRADFRI bulb E14 WS globe 470lm: 20
TS0601: 19
TRADFRI bulb E27 WW 806lm: 1
DONGLE-E_R: 1

After update I am still getting these errors:
{"level":"error","message":"Publish 'set' 'brightness' to 'lamp22' failed: 'Error: Command 0x003c84fffe17004c/1 genLevelCtrl.moveToLevelWithOnOff({\"level\":3,\"transtime\":30}, {\"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\":11894,\"options\":0,\"radius\":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))'"}
{"level":"error","message":"Publish 'set' 'brightness' to 'lamp74' failed: 'Error: Command 0xdc8e95fffe4a1d64/1 genLevelCtrl.moveToLevelWithOnOff({\"level\":3,\"transtime\":30}, {\"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\":42711,\"options\":0,\"radius\":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))'"}
{"level":"error","message":"Publish 'set' 'brightness' to 'lamp84' failed: 'Error: Command 0x003c84fffe2e0e03/1 genLevelCtrl.moveToLevelWithOnOff({\"level\":254,\"transtime\":15}, {\"sendWhen\":\"immediate\",\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":false,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Timeout - 40674 - 1 - 134 - 8 - 11 after 10000ms)'"}
{"level":"error","message":"Publish 'set' 'brightness' to 'lamp72' failed: 'Error: Command 0x84b4dbfffeec28ea/1 genLevelCtrl.moveToLevelWithOnOff({\"level\":254,\"transtime\":15}, {\"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\":19527,\"options\":0,\"radius\":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))'"}
{"level":"error","message":"Publish 'set' 'brightness' to 'lamp10' failed: 'Error: Command 0x84b4dbfffeebfae0/1 genLevelCtrl.moveToLevelWithOnOff({\"level\":254,\"transtime\":0}, {\"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\":38827,\"options\":0,\"radius\":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))'"}

I've been running 0507 for a little over a month now, and have just recently started to see my entire network drop off of HA all at once. My setup is a little different and may help @Koenkk to figure out the source of the dropout issues. I have z2m, mosquito, and Node-Red running on one box, and HA runs on a separate rPi. HA uses the MQTT integration to pull in devices from my mosquito instance.
Every so often (it's happened 3 times in the past month, and never happened before I upgraded to 0507 that I recall) all my zigbee devices suddenly show unavailable in HA. The are all still online in reality... if I go to the z2m web interface on the other box I can see and control the devices perfectly, and all my Node-Red automations continue to work. It's just HA that's lost its connection. 2 of the 3 instances occurred after an HA core or HAOS update - after reboot HA reported all zigbee devices as unavailable. The solution was to restart z2m, after which HA showed everything online. Seems like there's some odd interplay between HA, MQTT, z2m, and the 0507 firmware that's causing this. Everything is up-to-date with the latest release. I would postulate that people who have posted mass dropouts of devices are actually seeing the same issue I've seen, but it's harder for them to differentiate because z2m is running as an HA addon and they don't have as much familiarity with the z2m web interface as a direct-access tool. If they open the interface when HA reports a mass dropout, I'd wager z2m still has control of the network and it's HA that's not reading the keepalive info correctly from MQTT.

Been running 0507 for a few weeks, first lockup yesterday. power-cycle, and we're back. Had been stable up to that point.
I am seeing a few route messages, but it seems back alive for now.
warn  2023-06-30 09:07:01: Failed to ping 'Pantry.Light' (attempt 1/1, Read 0x000d6ffffefc7260/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 (Data request failed with error: 'No network route' (205)))
warn  2023-06-30 09:07:08: Failed to ping 'EW.Dad.Office.1' (attempt 1/1, Read 0x000d6f00036af3b0/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 (Data request failed with error: 'MAC no ack' (233)))
warn  2023-06-30 09:07:29: Failed to ping 'Enerwave.DaughtersRoom' (attempt 1/1, Read 0x000d6f00034b1053/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 (Data request failed with error: 'MAC no ack' (233)))
warn  2023-06-30 09:07:56: Failed to ping 'EW.Dad.Office.1' (attempt 1/1, Read 0x000d6f00036af3b0/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 (Data request failed with error: 'No network route' (205)))

Is it possible the firmware downgrade of my ZZH! adapter from CC2652R_coordinator_20230507.hex back to CC2652R_coordinator_20221226.hex was not complete?
Or that data in my ZZH! adapter is corrupt since the upgrade? Version shown is CC1352/CC2652, Z-Stack 3.30+ (build 20221226)
FWIW, in tracing all event in https://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1591982856 since the first issue.

Running tubeszb-cc2652-poe-2022
Zigbee2MQTT version 1.31.2 commit: 21f5125
Coordinator revision 20230507
Total 102 devices, 2 dedicated routers running slightly outdated firmware (20221102 and 20210128)
Still seeing this in my logs:
2023-07-01 18:10:01Failed to read state of 'Back Bedroom 1' after reconnect (Read 0x00158d0004775c1c/1 genOnOff(["onOff"], {"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":65410,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)')))```

Upgraded from 20220219. No issues so far, running for a week. :+1:

47 devices (end devices: 27, routers: 20)
tubeszb-cc2652-poe coordinator
Availability disabled (caused issues in the past, also with older Z-Stack)
Z2M 1.31.2

For those having NWK_TABLE_FULL or NETWORK_NO_ROUTE, do you have any AwoX devices in your network? (open your data/database.db and search for AwoX, if yes, try removing them from the network.

No, mostly ikea light bulbs and one manufacturer presence sensor

$ grep -i awox database.db | wc -l
0

For those having NWK_TABLE_FULL or NETWORK_NO_ROUTE, do you have any AwoX devices in your network? (open your data/database.db and search for AwoX, if yes, try removing them from the network.

I don't have any AwoX devices, either:
$ grep -i awox database.db  | wc -l
0

What stack are you using? (HA/Z2M)
How many devices in your network?
What was the latest known working firmware version?

What stack are you using? (HA/Z2M)

Z2M 1.31.2 commit: 21f5125

* How many devices in your network?

35 devices

* What was the latest known working firmware version?

20221226

Today I tried to install the 20230507 version on USB Dongle-P.
The device again non -functional - there is a timeout.
After returning to version 20220219, it is fine.

What stack are you using? (HA/Z2M)
Z2M 1.32.0

How many devices in your network?

Total 78 devices
Depending on the type of device
Router: 41
Ending devices: 37
According to the power supply
Network (single -phase): 41
Battery: 37

What was the latest known working firmware version?
20220219

Thank you for your work.

What stack are you using? (HA/Z2M)

Zigbee2MQTT running in k8s - config here
TubesZB CC2652P2 Based Zigbee to PoE Coordinator 2022

How many devices in your network?

102 devices

What was the latest known working firmware version?

It did happen for me on 20220219 but far less often

Does anyone else’s dongle just crash? I get timeouts and watchdog failures all the time. I just have no idea how to troubleshoot. 156 devices, home assistant on a raspberry pi, and zbdongle-p on 0507. I also have two other dongles on the 1229 router firmware.
Sent via RFC 1149
Get some Carrier Pigeonshttps://en.m.wikipedia.org/wiki/IP_over_Avian_Carriers...

From: Adam Petrovic @.>
Sent: Tuesday, July 4, 2023 5:04:26 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)

What stack are you using? (HA/Z2M)

Zigbee2MQTT running in k8s - config herehttps://github.com/adampetrovic/k8s-home/blob/main/kubernetes/apps/automation/zigbee2mqtt/app/helmrelease.yaml

TubesZB CC2652P2 Based Zigbee to PoE Coordinator 2022

How many devices in your network?

102 devices

What was the latest known working firmware version?

It did happen for me on 20220219 but far less often
—
Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1620741193, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRTYTPDGYJFKROKOABQLXOSANVANCNFSM6AAAAAAWPPN23Q.
You are receiving this because you were mentioned.Message ID: @.***>

Did you try to disconnect the stick when something goes wrong, or when upgrading firmware? I do it systematically and fixed some strange behaviors this way.
To come back to 20230507, I still have network table full errors, and significantly more "No network route" than with 20221226. Note that amazingly, these errors are often with routers.
Z2M 1.30.4, 117 devices, including 11 routers, slaesh stick.

Happened a few times now where part of the mesh becomes unavailable but not really anything of value is logged except:
error 2023-07-05 18:11:21: Publish 'set' 'color_temp' to 'adaptive_ligthing' failed: 'Error: Command 10100 lightingColorCtrl.moveToColorTemp({"colortemp":346,"transtime":30}) failed (SRSP - AF - dataRequestExt after 6000ms)'
debug 2023-07-05 18:11:21: Error: Command 10100 lightingColorCtrl.moveToColorTemp({"colortemp":346,"transtime":30}) failed (SRSP - AF - dataRequestExt after 6000ms)
error 2023-07-05 18:16:21: Publish 'set' 'color_temp' to 'adaptive_ligthing' failed: 'Error: Command 10100 lightingColorCtrl.moveToColorTemp({"colortemp":348,"transtime":30}) failed (SRSP - AF - dataRequestExt after 6000ms)'
debug 2023-07-05 18:16:21: Error: Command 10100 lightingColorCtrl.moveToColorTemp({"colortemp":348,"transtime":30}) failed (SRSP - AF - dataRequestExt after 6000ms)
error 2023-07-05 18:21:21: Publish 'set' 'color_temp' to 'adaptive_ligthing' failed: 'Error: Command 10100 lightingColorCtrl.moveToColorTemp({"colortemp":351,"transtime":30}) failed (SRSP - AF - dataRequestExt after 6000ms)'
debug 2023-07-05 18:21:21: Error: Command 10100 lightingColorCtrl.moveToColorTemp({"colortemp":351,"transtime":30}) failed (SRSP - AF - dataRequestExt after 6000ms)

Not seen those dataRequestExt before. I wiped and reflashed with the same version to see if it helps, it was fine for weeks before.

@sjorge I think the network have broken routing then the firmware have patched out of standard for broadcast and the routing diecovery is made with broadcast that is being blocked in the IEEE 802.15.4 network layer if getting more then 8 broadcast in 9 seconds in all zigbee routers.
See closed issue https://github.com/Koenkk/Z-Stack-firmware/issues/443
Is unicast working for routers that is in the first level / direct from the coordinator ?

@sjorge I think the network have broken routing then the firmware have patched out of standard for broadcast and the routing diecovery is made with broadcast that is being blocked in the IEEE 802.15.4 network layer if getting more then 8 broadcast in 9 seconds in all zigbee routers.
See closed issue https://github.com/Koenkk/Z-Stack-firmware/issues/443
Is unicast working for routers that is in the first level / direct from the coordinator ?

Not much is working and over time it loses connections to more devices.
But that theory is not totally crazy as there is usually one or two messages to a group before. Mostly eliminated groups except for 6 at the moment. They are rather big though. (Came from like 20)

Going on that theory, i winder if the new queuing system in zh might make things worse with groups as it will try more often now i think... or are groups exempt from it.
I wonder if we can somehow reserve a few of those broadcast slots just for route discovery

Is routers that have direct connection also stop working for broadcast ?
Then its one broadcast storm blocking in the 15.4 network.
Also its 2 types of broadcast acking the old = sending the broadcast 3 times (its only counting as one address slot) and the new (passive acking)  sending 1 time and listening for the neighbors is relaying it and if all is doing it = OK and if not reseeding.
Also you can sniffing and see if the broadcast is working in your network or where is blocked. Very likely you i getting unicast problems with the same devices that the broadcast is not working then the routing discovery is not working and is timing out the routers.

By the way some ZHA user with large networks and EZSP is disabling sours routing and getting the network more stable and i think its the router discovery that is getting problems and the 15.4 is blocking broadcasts.

Some interesting reading how dence mesh network is working and the performance but no dilates of routing and broadcast in it.
https://www.silabs.com/documents/login/application-notes/an1138-zigbee-mesh-network-performance.pdf

You can also simulating it by making one group of 1 or more lights and fuddling it with commands. and between sending some unicasts and see if routing and routing discovery is working all the time.

Starting to see lockup/crashes every few days.. is there a new release candidate to test?

I just experienced another crash. I had to pull the stick to reset it. There's no obvious errors in the logs other than timeouts. There was two seconds of quiet logs before this so I don't think any earlier logs are relevant. Let me know if there's anything more I should look for or post.
https://gist.github.com/deviantintegral/60a2fbaa66527ceb460d87678f74a372

What stack are you using? (HA/Z2M)

zigbee2mqtt 1.32.0

How many devices in your network?

101 devices with 60 end devices and 41 routers.

What was the latest known working firmware version?

Good question. I had other more frequent issues with prior firmwares, but I don't think I had complete crashes with the 20220219 or 20221226 releases.

Now starting to see MAC Channel access failure errors.
Zigbee2MQTT:error 2023-07-08 12:50:00: Publish 'set' 'state' to '0x00158d0004768fa1' failed: 'Error: Command 0x00158d0004768fa1/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 (Data request failed with error: 'MAC channel access failure' (225))'

This is my related issue on z2m with almost same errors everyone talked in last comments, I have received too https://github.com/Koenkk/zigbee2mqtt/issues/18196

MAC channel access failure' (225) means there is interference, this cannot be solved from the firmware. See https://www.zigbee2mqtt.io/guide/faq/#common-error-codes

MAC channel access failure' (225) means there is interference, this cannot be solved from the firmware. See https://www.zigbee2mqtt.io/guide/faq/#common-error-codes

I was also getting this but before this version never seen this, and nothing changed plus almost no wifi signals at coordinator location as everything is still under construction. So I feel something withing firmware triggered these errors.

Sorry, but much more worse than 20221226. My end devices, Aqara/Hue PIRs misses all the time.
Nothing changed but firmware (using ZHA and Sonoff Plus).

Just to counter the negative: I've been running 20230507 for weeks and haven't seen any major issues.

Pretty much destroyed a network of primarily Aquara + Sonoff devices. Huge delivery delays and missing routes

Same here and having 200+ devices (zzh stick and this firmware). Rock solid for me.

having 200+ devices (zzh stick

Isn't CC2652R limited to a maximum of 200 devices in the best conditions?

@aurimasniekis there is only a limit on the amount of Zigbee 3.0 devices that can join, you can theoretically join an endless amount of 1.2 devices.

i had alot of problems with latest updates after i changed te transmit power to 20dbm. thene i changed the transmit power back to standard 9dbm and everything is working very good again. (problem=stick is screaming to devices, but devices cant send back direct to coordinator.)
maybe its a solution for someones problems.

So I have two zbdongles as routers at 9db but don't even know if I can change the coordinator power. The routers are on an older firmware as I didn't see a 0507 router.
I do notice that most of my sengleds lights drop off after a few days to a week. I've had luck power cycling them via an automation that detects when they go offline and it keeps them running. It's almost like some devices go into a death spiral and contest the network till they are rebooted.
Sent via RFC 1149
Get some Carrier Pigeonshttps://en.m.wikipedia.org/wiki/IP_over_Avian_Carriers...

From: propi62 @.>
Sent: Monday, July 10, 2023 4:59:51 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)
i had alot of problems with latest updates after i changed te transmit power to 20dbm. thene i changed the transmit power back to standard 9dbm and everything is working very good again. (problem=stick is screaming to devices, but devices cant send back direct to coordinator.)
maybe its a solution for someones problems.
—
Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1629724069, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRT3TM7V4HAQB5HRAU2LXPRUMPANCNFSM6AAAAAAWPPN23Q.
You are receiving this because you were mentioned.Message ID: @.***>

After one day from the upgrade of z2m to 1.32.1 I started having massive devices offline for NWK_TABLE_FULL with 59 devices. Need to reboot and pairing some of them. Never seen before
https://github.com/Koenkk/zigbee2mqtt/issues/18287

Pretty much destroyed a network of primarily Aqara + Sonoff devices. Huge delivery delays, missing routes and Mac access issues.
UPD: rollback to 20221226 fixes it, so definitely attributed to update

seeing a ton of issues with my network as well, lots of errors in log with "failed to configure" even though not new devices. Rolling back firmware to 20221226 as well to hopefully fix the slow/non-responsiveness of my network now :(

Running CC1352P2_CC2652P_launchpad_coordinator_20230507 on my Sonoff_Zigbee_3.0_USB_Dongle_Plus with zigbee2mqtt (latest as of today). 52 device total (not all of them always on.)
It works, but I see significantly increased latency (several seconds) to the point of making the network unusable.
Was running 20221226 before and am considering to downgrade.

Running CC1352P2_CC2652P_launchpad_coordinator_20230507 on my Sonoff_Zigbee_3.0_USB_Dongle_Plus with zigbee2mqtt (latest as of today). 52 device total (not all of them always on.)
It works, but I see significantly increased latency (several seconds) to the point of making the network unusable.

2023-07-11 22:15:03 Publish 'set' 'brightness' to '0x00XXXXXXXXX' failed: 'Error: Command 0x00XXXXXXX/11 genLevelCtrl.moveToLevelWithOnOff({"level":254,"transtime":10}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 47713 - 11 - 210 - 8 - 11 after 10000ms)'

Is a typical error.
Was running 20221226 before and am considering to downgrade.

Roll back... instantly fixed my network delay/freezing issue!

Well i had my first disaster on this firmware. I went to add another device, and for some reason it completely broke
info  2023-07-13 17:34:20: Logging to console and directory: '/config/zigbee2mqtt/log/2023-07-13.17-34-20' filename: log.txt
info  2023-07-13 17:34:20: Starting Zigbee2MQTT version 1.32.0-dev (commit #08e82e4)
info  2023-07-13 17:34:20: Starting zigbee-herdsman (0.16.0)
error 2023-07-13 17:36:00: Error while starting zigbee-herdsman
error 2023-07-13 17:36:00: Failed to start zigbee
error 2023-07-13 17:36:00: Check https://www.zigbee2mqtt.io/guide/installation/20_zigbee2mqtt-fails-to-start.html for possible solutions
error 2023-07-13 17:36:00: Exiting...
error 2023-07-13 17:36:00: Error: SRSP - ZDO - startupFromApp after 40000ms
    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)

I have had these in the past, and i can usually just restart my PoE Zigstar, but it was not having any of it. Im re flashing to see if that helps. It just does not want to connect anymore.

Just rolled back to 20221226 because I had big problems with Aqara devices losing connection all the time. Never experienced this behaviour on 20221226 but with this 20230507.

Same as people above - after few days of using it in rather moderate network (50 devices, couple of Aqara ones too), I usually end up in state where coordinator no longer works and I have to replug it in order to have it working again. I've reverted few days ago to 20221226 and problem seems to be gone

@Koenkk please consider removing this version as the default/recommended firmware until these issues are fixed., or if its just those with Aqara, add a big warning :) thanks!

With new firmware I have problems with sonoff devices - on 20221226 network was rock solid and only when battery was low I had problems with communication. Now devices such like motion sensor and door sensor can hang for few hours to start working again after some time. But it's very annoying when motion sensor work only once per few hours. I tried to change batteries to new, but nothing helped.

With new firmware I have problems with sonoff devices - on 20221226 network was rock solid and only when battery was low I had problems with communication. Now devices such like motion sensor and door sensor can hang for few hours to start working again after some time. But it's very annoying when motion sensor work only once per few hours. I tried to change batteries to new, but nothing helped.

Did you read above? rollback to 20221226 to fix.

With new firmware I have problems with sonoff devices - on 20221226 network was rock solid and only when battery was low I had problems with communication. Now devices such like motion sensor and door sensor can hang for few hours to start working again after some time. But it's very annoying when motion sensor work only once per few hours. I tried to change batteries to new, but nothing helped.

Did you read above? rollback to 20221226 to fix.

Yes I know. I only wrote about sonoff devices that there are problems with them too - maybe it will help to debug problems

2x SLZB-06  PoE with Z2M. Had to roll back to 20221226, as 20230507 would take about many minutes to start and was unusable.
Coordinator 1 (Z2M 1.32.1)
Total 167
By device type
Router: 115
End devices: 52
By power source
Mains (single phase): 115
Battery: 52
By vendor
Signify Netherlands B.V.: 71
LUMI: 37
Inovelli: 21
Philips: 21
eWeLight: 6
Leviton: 5
eWeLink: 3
Kwikset: 1
XIAOMI: 1
_TZE204_t1blo2bj: 1
By model
LTW015: 25
VZM31-SN: 21
LTA008: 20
lumi.sensor_wleak.aq1: 12
1741930V7: 12
lumi.sensor_magnet.aq2: 9
ZB-CT01: 6
lumi.remote.b286acn02: 6
DG15S: 5
lumi.weather: 5
SML003: 4
LTA010: 4
LWB015: 4
LTE001: 4
LCA003: 3
LST002: 3
SML001: 3
1741730V7: 3
MS01: 3
lumi.remote.b1acn01: 3
RWL020: 3
LTA003: 2
LCT016: 2
lumi.sensor_motion.aq2: 2
SMARTCODE_CONVERT_GEN1_W3: 1
lumi.sen_ill.mgl01: 1
TS0601: 1

Coordinator 2 (Z2M 1.31.2)
Total 12
By device type
Router: 12
By power source
Mains (single phase): 12
By vendor
sengled: 7
Signify Netherlands B.V.: 3
eWeLink: 1
Philips: 1
By model
E1C-NB7: 7
LLC011: 2
LLC012: 2
ZB-SW01: 1

Migrating back to 1.30.2 and reverting firmware to 20221226 on my TubesZB 2022 PoE stick has essentially solved all my problems. I haven't seen a single NWK_FULL error or any timeouts in 2 days across my 85 devices.

Migrating back to 1.30.2 and reverting firmware to 20221226 on my TubesZB 2022 PoE stick has essentially solved all my problems. I haven't seen a single NWK_FULL error or any timeouts in 2 days across my 85 devices.

You had to downgrade z2m itself as well for it to work?
@Koenkk I was curious and downgraded to 20221226 as well, even though I wasn't seeing massive issues with the current firmware. The old one is massively better in terms of latency somehow.

You had to downgrade z2m itself as well for it to work?

I found lots of timeout weirdness and MAC no ACK with the latest version of herdsman even on the reverted firmware. These have gone away moving back to my previously running z2m version

You had to downgrade z2m itself as well for it to work?

I found lots of timeout weirdness and “MAC no ACK” messages with the latest version of herdsman even on the reverted firmware. These have gone away moving back to my previously running z2m version

Interesting. 1.30.2 is four months old. I'll try that out.

The firmware I provide consist of 2 parts:

The Texas Instruments SDK
Some manual changes I make to the Texas Instruments SDK (this patch)

In 20221226 -> 20230507 both these parts changed. I've compiled a new firmware which reverts all my changes to the ones from 20221226. So this firmware contains:

Texas Instruments SDK from 20230507
Manual changes from 20221226

In this way we can identify what causes the issues, the new Texas Instruments SDK or my changes. Please only test this firmware when:

20221226 works fine
20230507 gives issues

Link: coordinator_20230716.zip

Hi, with 20230507 I get an error "Your firmware looks like an Intel Hex file" while trying to flash my electrolama zzh.
./cc2538-bsl.py -p /dev/tty.usbserial-14410 -evw CC2652R_coordinator_20230507.hex
/Users/andreas/Documents/cc2538-bsl-master/./cc2538-bsl.py:971: SyntaxWarning: "is not" with a literal. Did you mean "!="?
if int(value) % int(device.page_size) is not 0:
/Users/andreas/Documents/cc2538-bsl-master/./cc2538-bsl.py:976: SyntaxWarning: "is not" with a literal. Did you mean "!="?
if int(value, 16) % int(device.page_size) is not 0:
Opening port /dev/tty.usbserial-14410, baud 500000
Reading data from CC2652R_coordinator_20230507.hex
Your firmware looks like an Intel Hex file
ERROR: Firmware is Intel Hex, but the IntelHex library could not be imported.
Install IntelHex in site-packages or program your device with a raw binary (.bin) file.
Please see the readme for more details.
With previews Versions I had no Problem. Console History ;-)
166  ./cc2538-bsl.py -p /dev/tty.usbserial-14410 -evw CC2652R_coordinator_20211217.hex
237  ./cc2538-bsl.py -p /dev/tty.usbserial-14110 -evw CC2652R_coordinator_20220219.hex
255  ./cc2538-bsl.py -p /dev/tty.usbserial-14110 -evw CC2652R_coordinator_20221226.hex
Any Idea, thanks in advance
Andreas

While I don't have any logs to go by, for as long as I have been running 20230507 I have had daily zigbee sensors dropping off and coming back on their own after a while. It's noticeable on temperature graphs and motion triggered automations failing. I'll try this latest update to see if it changes.

I uploaded the modified version (Coordinator_20230716) and again "timeout". I went back to firmware 20220219.
All devices immediately functional without defects.
Part of Error Messages
`error 2023-07-17 15:25:51Publish 'set' 'state' to 'Předsíň LEDpásek RGB' failed: 'Error: Command 0xa4c1388163d6b97e/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 - 19235 - 1 - 14 - 6 - 11 after 10000ms)'
error 2023-07-17 15:25:51Publish 'set' 'state' to 'Kuchyně zásuvka digestoř' failed: 'Error: Command 0xa4c1389e116a3c55/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 - 7317 - 1 - 29 - 6 - 11 after 10000ms)'
error 2023-07-17 15:25:51Publish 'set' 'state' to 'Kuchyně LED Kávovar' failed: 'Error: Command 0xa4c13869e2685330/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 - 46541 - 1 - 27 - 6 - 11 after 10000ms)'

I had to roll-back to the previous version because 20230507 would not let my new Hue wall switches pair. https://github.com/Koenkk/Z-Stack-firmware/issues/467


[New method suggestion] Augmentation-Augmented Variational Autoencoders

Ciao ragazzi!
I was wondering whether the new method AAVAEs proposed by William Falcon et al. can interest you and thus be implemented in your library or not.
The authors of the paper claim and suggest that autoencoding is a viable third family of self-supervised learning approach in addition to contrastive and non-contrastive learning although their method failed to outperform or perform comparably to the existing families of self-supervised learning algorithms.
I really enjoyed the idea behind this method and I wanted to strongly suggest it to you!

Hey!
I've read the paper and it is indeed very interesting. We will add it to the pipeline, but if you wanna contribute please let us know and I can guide you through how to add new methods. We also plan on releasing "how to implement X" tutorials so the community can help! :)

Hi!
I would love to contribute! If you agree I can wait your official tutorials and then start to implement it.
Meanwhile thank you for considering this suggestion!


Changing build.rollupOptions.output.entryFileNames option in vite throws an error.

the error thrown
Error: ENOENT: no such file or directory, copyfile '/home/nrb/tst/.solid/server/entry-server.js' -> '/home/nrb/tst/.solid/server/handler.js'
    at copyFileSync (node:fs:2866:3)
    at Object.build (file:///home/nrb/tst/node_modules/solid-start-node/index.js:32:7)

config
  build: {
    rollupOptions: {
      output: {
        entryFileNames: "entry.[hash].js",
        chunkFileNames: "chunks/chunk.[hash].js",
        assetFileNames: "assets/asset.[hash][extname]",
      },
    },
  },

take a look at this:
https://github.com/solidjs/solid-start/blob/c1b0b13ee7ed1a52743d68ea4c195876a4c75493/packages/start-node/index.js#L32-L35

I think solid-start is assuming you have entryFileNames: '[name].js' in server/SSR mode.
I think this may be fine for your use case. It is quite rare to need hashes in the file name on the server side, only on the browser side. Maybe try customizing entryFileNames for the browser build only? Here are some examples from other Vite projects:
https://github.com/vitejs/vite/blob/07d3fbd21e6b63a12997d201a2deb5b2f2129882/packages/vite/src/node/build.ts#L547
https://github.com/sveltejs/kit/blob/5a54eb4af542a4b0c3b4c589c3df3ea520f5ca00/packages/kit/src/exports/vite/build/utils.js#L124


Error code 230 [Added 2023 v1.1]

Note: This rule was added by DFE in the 2023/24 v1.1 validation check document.
Error information
Error code
230
Description to display
Ofsted Unique reference number (URN) is required for any English H5 placements from 28 October 2023.
DfE Long-form description of error
From 28 October 2023, semi-independent living placements (H5) are not valid placement types for children placed in England.
These young people may have moved placement from semi-independent living to regulated supported accommodation. If so then provide a new episode for this placement move.
If these young people have remained at the same provider, but the provider has now registered with Ofsted as a regulated supported accommodation provider, then please provide a new episode recorded as a 'H5 placement', with the provider URN and the relevant reason for new episode of 'T' or 'U'.
If the provider has submitted their registration request to Ofsted and are still awaiting the outcome then please submit a bypass request.
DfE suggested coding
Where <PL> = 'H5' and <LA_PLACEMENT> not in (‘WAL’, SCO’, NIR’, ‘NUK’) and <DEC> >= 28/10/2023 or missing then <URN> should be provided
For further info, refer to the DfE validation document here

I'm going to assume that DFE mean <PL_LA> where they've written <LA_PLACEMENT>...


Django 使用 Github Actions - TERR的博客 | TERR Blog

https://terrluo.github.io/2020/04/29/Django-使用-Github-Actions/
Every failure is leading towards success.

233333


feat: load clusterfile from template

Signed-off-by: fengxsong<EMAIL_ADDRESS>https://github.com/labring/sealos/issues/1480

More details need to be discussed.

Add docs for this feature


feat: add support for squared conversions

Overview
Discovered this morning that converting between units like feet to miles requires different conversion factors than converting between square feet and square miles. This PR covers the work required to support squared unit conversions. The following updates were made:

add modifiers for mi2, ft2, and in2
restructure the types variable so measurement type (i.e. length or area) can be captured along with the conversion factor
add validation utility to throw error if user tries to convert from a length to a measurement and vice versa
add converters for mi2, ft2, and in2,
add logic to humanize for squared units
add tests for squared units

Thanks, published to 3.0.0

Thanks, published to 3.0.0


How to install?

How do I install frontend & backend?

It is still under development.
The backend is compatible with: https://github.com/Saebasol/Heliotrope
frontend is
https://github.com/Saebasol-hibiscus/hibiscus-frontend/blob/master/src/api.ts
Just edit the api path of that file.
However, there may be CORS issues.


Version catalogs for compose-1.2

Removed the buildSrc module in favour of version catalogs.
Summary of changes:

Created the libs catalog: gradle/libs.versions.toml.
Migrated all build files.
Purged buildSrc.
Made when exhaustive, this led to a compilation error :thinking:.

Interestingly I get this error only after my changes:
'when' expression must be exhaustive, add necessary 'ProfileSettingsScreenDestination' branch or 'else' branch instead

Shouldn't be a deal-breaker though.

Try a clean build. KSP and Kotlin compiler sometimes give that error for no reason 😐

Try a clean build. KSP and Kotlin compiler sometimes give that error for no reason :neutral_face:

Did a clean build on the original compose-1.2 branch and got the same error, doesn't seem to have anything to do with my changes. Let me know if and how you want me to fix it, I can revert the commit too if needed.

@raamcosta Done!

Thanks! 🙇


When num_ctrl_qubits=0, creating controlled gates will produce an AttributeError

Information

Qiskit Terra version: 0.14.1
Python version: 3.8
Operating system: both Windows and Linux

What is the current behavior?
When num_ctrl_qubits=0, creating controlled gates will produce an AttributeError.
Steps to reproduce the problem
>>> from qiskit.circuit.library import ZGate
>>> ZGate().control(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.8/dist-packages/qiskit/circuit/library/standard_gates/z.py", line 100, in control
    return super().control(num_ctrl_qubits=num_ctrl_qubits, label=label, ctrl_state=ctrl_state)
  File "/usr/local/lib/python3.8/dist-packages/qiskit/circuit/gate.py", line 132, in control
    return add_control(self, num_ctrl_qubits, label, ctrl_state)
  File "/usr/local/lib/python3.8/dist-packages/qiskit/circuit/add_control.py", line 70, in add_control
    cgate.base_gate.label = operation.label
AttributeError: 'ZGate' object has no attribute 'base_gate'

What is the expected behavior?
Create a gate without control bits successfully.
Suggested solutions
This bug happens because the control function inqiskit/circuit/add_control.py directly returns operation (the first argument) when num_ctrl_qubits=0, but the add_control function expects that the return value from the control function has the base_gate attribute.
Either the control function should always return a Gate object with the base_gate attribute, or the add_control function should not assume that the base_gate attribute always exists.

Another option would be to raise an exception if num_ctrl_qubits=0. Then whenever control is called a ControlledGate is always returned. Letting num_ctrl_qubits=0 doesn't seem necessary to support since one could just use the original gate.

Indeed a ControlledGate with 0 control bits does not seem to be necessary to be supported. However having such support would be a little bit more user-friendly. I discovered this bug when I try to implement "multiply amplitude by -1 when all n qubits are |1>" for arbitrary n with the following code:
circuit.append(ZGate().control(n - 1), range(n))

The code fails when n=1, so I have to deal with this case separately.

Since it seems the intention is to create a controlled gate then having n>=2 doesn't seem like an unreasonable assumption.


tileRequestLimit: limit concurrent connections

Due to new limitations of the OSM tiles usage policy I added tilesRequestLimit in<EMAIL_ADDRESS>option to limit concurrent connections to the tiles server. This value is set to 2 by default and can be overwritten or disabled with tilesRequestLimit: 0.

@OlivierKamers FYI

Nice 👍
I also saw the update to get rid of the request library. I played around with it a few weeks ago because we had issues parallelising multiple map renderings. I added an option to provide a custom tile loader function (so we can use our blob storage functions and some memoization) but it looks like the got library you're using now might already take care of the issues we had. I haven't been able to clean up the implementation yet so that's why I didn't propose the change here, and it's just on a branch in our fork: https://github.com/Sitemark/staticmaps/commit/5084341d87d19940659a8b59473f37088b546916

What kind of issues?

I had to limit the number of requests to avoid timeouts from the request library. Externalising the function also allowed me to use a cache for tiles that are requested more than once.

Ok, that could indeed be an improvement. I thought for now caching should be done at the tiles server side, for example via CDN.


Remove dependency on IRGenModule of some linkage computations

This is designed to allow TBDGen to reuse this for computing information about all the various symbols it touches.

@swift-ci Please smoke test.
I updated the PR with some of the feedback, and also added a bit of an unfortunate hack to the first commit. I'm curious if it seems sensible.
    // A hidden-external conformance doesn't make sense: we can't refer to
    // it. Thus, the only way to end up in that situation is if the linkage is
    // actually public.
    return linkage == SILLinkage::HiddenExternal ? SILLinkage::PublicExternal
                                                 : linkage;

@swift-ci Please smoke test.

@swift-ci Please smoke test

https://github.com/apple/swift-lldb/pull/177
@swift-ci Please smoke test

Hidden external means the symbol is defined in a different translation unit of the same module. Think two files that reference each other's internal symbols. This can totally happen -- something else must have gone wrong.