error: zh:controller:device: Default response to <Device X IEEE Address> failed

[yarafie]

What happened?

Error appearing in logs repeated multiple times as example below each time with different [Device X IEEE Address]

error: zh:controller:device: Default response to [Device X IEEE Address] failed and error: zh:controller:device: Read response to [Device X IEEE Address] failed

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.37.0 commit: 46f34c8

Adapter firmware version

20230507

Adapter

SMLIGHT SLZB-06 zStack3x0

Setup

Docker

Debug log

No response

[khataev]

The same here

[harrisonbc]

I'm getting loads of these errors too Any Ideas?

........ [2024-05-03 13:41:33] error: zh:controller:device: Default response to 0xb0c7defffe00b98b failed [2024-05-03 13:41:39] error: zh:controller:device: Default response to 0x3410f4fffee93a9e failed [2024-05-03 13:42:54] error: zh:controller:device: Default response to 0xa4c138f13915453a failed [2024-05-03 13:43:04] error: zh:controller:device: Default response to 0xa4c138e1991e152b failed [2024-05-03 13:43:31] error: zh:controller:device: Default response to 0xa4c138829ac198ac failed [2024-05-03 13:43:40] error: zh:controller:device: Default response to 0xa4c138829ac198ac failed ........

Zigbee2MQTT version: 1.37.0 commit: 46f34c8 Coordinator type: zStack3x0 Coordinator revision: 20230507 Coordinator IEEE Address: 0xxxxxxxxxxx Frontend version: 0.6.165 19.32.0 0.45.0

[harrisonbc]

After some investigation by enabling debug logging level. I found one device was sending a large no of zigbee messages (>10 a second). It was a mains-relay that reports power consumption. I tried to change timeouts to reduce the frequency of messages, but to no avail. I have removed it from the network for now to see if this remedys the stability of the zigbee network. I will report back. BTW the device was a WHD02 https://www.aliexpress.com/item/1005005528864875.html

[Koterak]

For me same issue - devices which send a lot of data (illuminace sensor/plug reporting power usage) generate such error

[khataev]

After some investigation by enabling debug logging level. I found one device was sending a large no of zigbee messages (>10 a second).

Can you please describe how to enable debug logging and hoe to observe messages?

[harrisonbc]

In the Frontend UI there is a Logs Tab at the top, on the right you can set the log level from the dropdown, set it to debug. To see the messages it depends on how you are running Xigbee2MQTT, I use docker and use the command 'docker logs ' command.

[khataev]

@harrisonbc thank you, my setup is also inside docker, I was able to view them using your instructions. Looks like my issue is different. I don't see flood messages, though I also have the same relay switch. But I'm not sure still 100% that I can identify ownership of debug messages to the specific devices, only when some button is pressed or similar, then I can see message in the topic, eg:

[2024-05-04 23:24:26] debug:    z2m: MQTT publish: topic 'zigbee2mqtt/этаж01/ванная/выключатель.повторитель', payload '{"action":"single","battery":97,"device_temperature":29,"linkquality":40,"power_outage_count":18,"voltage":2995}'

while mainly debug messages are as the following:

[2024-05-04 23:24:23] debug:    zh:zstack:unpi:writer: --> frame [254,13,36,1,100,55,1,1,6,0,54,0,30,3,1,142,1,216]
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: <-- [254,1,100,1,0,100]
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --- parseNext [254,1,100,1,0,100]
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --> parsed 1 - 3 - 4 - 1 - [0] - 100
[2024-05-04 23:24:23] debug:    zh:zstack:znp: SRSP: <-- AF - dataRequest - {"status":0}
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: <-- [254,3,68,128,0,1,54,240]
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --- parseNext [254,3,68,128,0,1,54,240]
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --> parsed 3 - 2 - 4 - 128 - [0,1,54] - 240
[2024-05-04 23:24:23] debug:    zh:zstack:znp: AREQ: <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":54}
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: <-- [254,25,68,129,0,0,6,0,100,55,1,1,0,36,0,51,3,63,0,0,5,24,142,11,1,0,221,70,28,188]
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --- parseNext [254,25,68,129,0,0,6,0,100,55,1,1,0,36,0,51,3,63,0,0,5,24,142,11,1,0,221,70,28,188]
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --> parsed 25 - 2 - 4 - 129 - [0,0,6,0,100,55,1,1,0,36,0,51,3,63,0,0,5,24,142,11,1,0,221,70,28] - 188
[2024-05-04 23:24:23] debug:    zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":14180,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":36,"securityuse":0,"timestamp":4129587,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[24,142,11,1,0]}}
[2024-05-04 23:24:23] debug:    zh:controller: Received payload: clusterID=6, address=14180, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=36, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":142,"commandIdentifier":11},"payload":{"cmdId":1,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}}
[2024-05-04 23:24:23] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:23] debug:    z2m: MQTT publish: topic 'zigbee2mqtt/этаж01/ванная/выключатель', payload '{"action":null,"device_temperature":27,"flip_indicator_light":"ON","linkquality":36,"mode_switch":null,"operation_mode":"control_relay","power_outage_count":62,"power_outage_memory":null,"state":"ON","update":{"installed_version":-1,"latest_version":-1,"state":null},"update_available":null}'
[2024-05-04 23:24:24] debug:    zh:zstack:unpi:parser: <-- [254,34,68,129,0,0,6,0,100,55,1,1,0,40,0,229,20,63,0,0,14,24,199,10,0,0,16,1,245,0,35,142]
[2024-05-04 23:24:24] debug:    zh:zstack:unpi:parser: --- parseNext [254,34,68,129,0,0,6,0,100,55,1,1,0,40,0,229,20,63,0,0,14,24,199,10,0,0,16,1,245,0,35,142]
[2024-05-04 23:24:24] debug:    zh:zstack:unpi:parser: <-- [0,0,7,221,70,28,70]
[2024-05-04 23:24:24] debug:    zh:zstack:unpi:parser: --- parseNext [254,34,68,129,0,0,6,0,100,55,1,1,0,40,0,229,20,63,0,0,14,24,199,10,0,0,16,1,245,0,35,142,0,0,7,221,70,28,70]
[2024-05-04 23:24:24] debug:    zh:zstack:unpi:parser: --> parsed 34 - 2 - 4 - 129 - [0,0,6,0,100,55,1,1,0,40,0,229,20,63,0,0,14,24,199,10,0,0,16,1,245,0,35,142,0,0,7,221,70,28] - 70
[2024-05-04 23:24:24] debug:    zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":14180,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":40,"securityuse":0,"timestamp":4134117,"transseqnumber":0,"len":14,"data":{"type":"Buffer","data":[24,199,10,0,0,16,1,245,0,35,142,0,0,7]}}
[2024-05-04 23:24:24] debug:    zh:controller: Received payload: clusterID=6, address=14180, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=40, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":199,"commandIdentifier":10},"payload":[{"attrId":0,"dataType":16,"attrData":1},{"attrId":245,"dataType":35,"attrData":117440654}],"command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}}
[2024-05-04 23:24:24] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:24] debug:    z2m: Received Zigbee message from 'этаж01/ванная/выключатель', type 'attributeReport', cluster 'genOnOff', data '{"245":117440654,"onOff":1}' from endpoint 1 with groupID 0
[2024-05-04 23:24:24] debug:    z2m: MQTT publish: topic 'zigbee2mqtt/этаж01/ванная/выключатель', payload '{"action":null,"device_temperature":27,"flip_indicator_light":"ON","linkquality":40,"mode_switch":null,"operation_mode":"control_relay","power_outage_count":62,"power_outage_memory":null,"state":"ON","update":{"installed_version":-1,"latest_version":-1,"state":null},"update_available":null}'
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: <-- [254,28,68,129,0,0,18,0,108,200,1,1,0,40,0,37,63,65,0,0,8,24,110,10,85,0,33,1,0,221,70,28]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext [254,28,68,129,0,0,18,0,108,200,1,1,0,40,0,37,63,65,0,0,8,24,110,10,85,0,33,1,0,221,70,28]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: <-- [154]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext [254,28,68,129,0,0,18,0,108,200,1,1,0,40,0,37,63,65,0,0,8,24,110,10,85,0,33,1,0,221,70,28,154]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --> parsed 28 - 2 - 4 - 129 - [0,0,18,0,108,200,1,1,0,40,0,37,63,65,0,0,8,24,110,10,85,0,33,1,0,221,70,28] - 154
[2024-05-04 23:24:26] debug:    zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":18,"srcaddr":51308,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":40,"securityuse":0,"timestamp":4276005,"transseqnumber":0,"len":8,"data":{"type":"Buffer","data":[24,110,10,85,0,33,1,0]}}
[2024-05-04 23:24:26] debug:    zh:controller: Received payload: clusterID=18, address=51308, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=40, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":110,"commandIdentifier":10},"payload":[{"attrId":85,"dataType":33,"attrData":1}],"command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}}
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:26] debug:    z2m: Received Zigbee message from 'этаж01/ванная/выключатель.повторитель', type 'attributeReport', cluster 'genMultistateInput', data '{"presentValue":1}' from endpoint 1 with groupID 0
[2024-05-04 23:24:26] debug:    z2m: MQTT publish: topic 'zigbee2mqtt/этаж01/ванная/выключатель.повторитель', payload '{"action":"single","battery":97,"device_temperature":29,"linkquality":40,"power_outage_count":18,"voltage":2995}'
[2024-05-04 23:24:26] debug:    z2m: MQTT publish: topic 'zigbee2mqtt/этаж01/ванная/выключатель.повторитель', payload '{"action":"","battery":97,"device_temperature":29,"linkquality":40,"power_outage_count":18,"voltage":2995}'
[2024-05-04 23:24:26] debug:    z2m: MQTT publish: topic 'zigbee2mqtt/этаж01/ванная/выключатель.повторитель/action', payload 'single'
[2024-05-04 23:24:26] debug:    z2m: Received MQTT message on 'zigbee2mqtt/этаж01/ванная/выключатель/set' with data 'OFF'
[2024-05-04 23:24:26] debug:    z2m: Publishing 'set' 'state' to 'этаж01/ванная/выключатель'
[2024-05-04 23:24:26] debug:    zh:controller:endpoint: ZCL command 0x54ef4410004c8020/1 genOnOff.off({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
[2024-05-04 23:24:26] debug:    zh:zstack: sendZclFrameToEndpointInternal 0x54ef4410004c8020:14180/1 (0,0,1)
[2024-05-04 23:24:26] debug:    zh:zstack:znp: SREQ: --> AF - dataRequest - {"dstaddr":14180,"destendpoint":1,"srcendpoint":1,"clusterid":6,"transid":55,"options":0,"radius":30,"len":3,"data":{"type":"Buffer","data":[1,143,0]}}
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:writer: --> frame [254,13,36,1,100,55,1,1,6,0,55,0,30,3,1,143,0,217]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: <-- [254,1,100,1,0,100]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext [254,1,100,1,0,100]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --> parsed 1 - 3 - 4 - 1 - [0] - 100
[2024-05-04 23:24:26] debug:    zh:zstack:znp: SRSP: <-- AF - dataRequest - {"status":0}
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: <-- [254,3,68,128,0,1,55,241]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext [254,3,68,128,0,1,55,241]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --> parsed 3 - 2 - 4 - 128 - [0,1,55] - 241
[2024-05-04 23:24:26] debug:    zh:zstack:znp: AREQ: <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":55}
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: <-- [254,25,68,129,0,0,6,0,100,55,1,1,0,40,0,13,80,65,0,0,5,24,143,11,0,0,221,70,28,163]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext [254,25,68,129,0,0,6,0,100,55,1,1,0,40,0,13,80,65,0,0,5,24,143,11,0,0,221,70,28,163]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --> parsed 25 - 2 - 4 - 129 - [0,0,6,0,100,55,1,1,0,40,0,13,80,65,0,0,5,24,143,11,0,0,221,70,28] - 163
[2024-05-04 23:24:26] debug:    zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":14180,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":40,"securityuse":0,"timestamp":4280333,"transseqnumber":0,"len":5,"data":{"type":"Buffer","data":[24,143,11,0,0]}}
[2024-05-04 23:24:26] debug:    zh:controller: Received payload: clusterID=6, address=14180, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=40, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":143,"commandIdentifier":11},"payload":{"cmdId":0,"statusCode":0},"command":{"ID":11,"name":"defaultRsp","parameters":[{"name":"cmdId","type":32},{"name":"statusCode","type":32}]}}
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:26] debug:    z2m: MQTT publish: topic 'zigbee2mqtt/этаж01/ванная/выключатель', payload '{"action":null,"device_temperature":27,"flip_indicator_light":"ON","linkquality":40,"mode_switch":null,"operation_mode":"control_relay","power_outage_count":62,"power_outage_memory":null,"state":"OFF","update":{"installed_version":-1,"latest_version":-1,"state":null},"update_available":null}'
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: <-- [254,34,68,129,0,0,6,0,100,55,1,1,0,36,0,13,99,65,0,0,14,24,200,10,0,0,16,0,245,0,35,143]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext [254,34,68,129,0,0,6,0,100,55,1,1,0,36,0,13,99,65,0,0,14,24,200,10,0,0,16,0,245,0,35,143]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: <-- [0,0,7,221,70,28,164]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext [254,34,68,129,0,0,6,0,100,55,1,1,0,36,0,13,99,65,0,0,14,24,200,10,0,0,16,0,245,0,35,143,0,0,7,221,70,28,164]
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --> parsed 34 - 2 - 4 - 129 - [0,0,6,0,100,55,1,1,0,36,0,13,99,65,0,0,14,24,200,10,0,0,16,0,245,0,35,143,0,0,7,221,70,28] - 164
[2024-05-04 23:24:26] debug:    zh:zstack:znp: AREQ: <-- AF - incomingMsg - {"groupid":0,"clusterid":6,"srcaddr":14180,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":36,"securityuse":0,"timestamp":4285197,"transseqnumber":0,"len":14,"data":{"type":"Buffer","data":[24,200,10,0,0,16,0,245,0,35,143,0,0,7]}}
[2024-05-04 23:24:26] debug:    zh:controller: Received payload: clusterID=6, address=14180, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=36, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"manufacturerCode":null,"transactionSequenceNumber":200,"commandIdentifier":10},"payload":[{"attrId":0,"dataType":16,"attrData":0},{"attrId":245,"dataType":35,"attrData":117440655}],"command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}}
[2024-05-04 23:24:26] debug:    zh:zstack:unpi:parser: --- parseNext []
[2024-05-04 23:24:26] debug:    z2m: Received Zigbee message from 'этаж01/ванная/выключатель', type 'attributeReport', cluster 'genOnOff', data '{"245":117440655,"onOff":0}' from endpoint 1 with groupID 0
[2024-05-04 23:24:26] debug:    z2m: MQTT publish: topic 'zigbee2mqtt/этаж01/ванная/выключатель', payload '{"action":null,"device_temperature":27,"flip_indicator_light":"ON","linkquality":36,"mode_switch":null,"operation_mode":"control_relay","power_outage_count":62,"power_outage_memory":null,"state":"OFF","update":{"installed_version":-1,"latest_version":-1,"state":null},"update_available":null}'

Still I started to notice that recently there are moments when devices react with big delay on my actions in home assistant or zigbee2mqtt actions.

[harrisonbc]

I had delays on devices also, as well as some devices not responding at all (such as blind motors)
My remedy, which has restored good operation to my network was to remove the offending device from the zigbee network. See if that works for you?

[angrycatmeowmeow]

I'm getting the same error and I believe it is bringing my whole network down. How are you determining which device is the offending device? Z2M is showing only routers offline but all devices are in fact offline and unplugging the coordinator is the only fix.

[harrisonbc]

In my log (debug level) I was getting about 35 messages a second, like the one below. Predominantly from the same device. (In my case "BedroomMainZB")

[2024-05-03 17:00:01] debug: z2m: Received Zigbee message from 'BedroomMainZB', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":0,"rmsCurre nt":0,"rmsVoltage":247}' from endpoint 1 with groupID 0

To me that was the clue. I removed the device and the message rate dropped,

[trozman]

Similar here. My zigbee network became very unstable in last few days, after the last update of z2m (to 1.37). A lot of errors in the log (such as 'Default response to X failed', 'Failed to execute LQI for X', ''MAC channel access failure' and similar). Network map shows no routes between routers, only a connection to a coordinator. Removing 2 Tuya smart sockets helped for a half a day, now the problem is back.

Update (fixed): I updated the Sonoff USB dongle Plus (P) (2652P) firmware using these instructions, reset all routers and it seems issues are gone.

[DerSchiman]

Same issue for me, after a downgrade to 1.36.0 everything is working without problems again.

[GregHilston]

@DerSchiman How does one downgrade?

EDIT: I ended up solving my problem by ensuring that my zigbee2mqtt was pointed to the correct MQTT instance by IP, and had the proper username and password set.

[BetyOops]

Hi,

Same problem here with Tuya TS0601 (consumption measurement) in 1.37.0 or 1.37.1.

Anyone solve this issue ?

EDIT:

After:

• Upgrading my sonoff dongle P to lastest firmware
• Reseting the dongle
• upgrading to 1.37.1 It "seems" to be ok.

[yarafie]

I'm also still getting this even after 1.37.1

error: zh:controller:device: Default response

Things seem to be working though

[angrycatmeowmeow]

After:

• Upgrading my sonoff dongle P to lastest firmware
• Reseting the dongle
• upgrading to 1.37.1 It "seems" to be ok.

Which firmware did you use?

[BetyOops]

After:

• Upgrading my sonoff dongle P to lastest firmware
• Reseting the dongle
• upgrading to 1.37.1 It "seems" to be ok.

Which firmware did you use?

For my Sonoff P version I used CC1352P2_CC2652P_launchpad_coordinator_20230507.hex like here: https://www.zigbee2mqtt.io/guide/adapters/flashing/flashing_via_cc2538-bsl.html

[invisible999]

Update (fixed): I updated the Sonoff USB dongle Plus (P) (2652P) firmware using these instructions, reset all routers and it seems issues are gone.

Can the upgrade performed on PI4 running HA or the dongle has to be removed from the PI?

[invisible999]

How one can downgrade z2m to 1.36 version if there is no backup?

[trozman]

Update (fixed): I updated the Sonoff USB dongle Plus (P) (2652P) firmware using these instructions, reset all routers and it seems issues are gone.

Can the upgrade performed on PI4 running HA or the dongle has to be removed from the PI?

You have to do it from Linux command line. The dongle has to be plugged to the machine that runs Linux.

[szaman-89]

I have exact same problem with all my routers. I'm loosing my heart for using zigbee network. After each power outage I have crash of whole network and this time it's "Default response to failed" errors. Devices still reporting but can't be controlled anymore. Re-Configuring not working, Re-Pairing either...

[trozman]

I have exact same problem with all my routers. I'm loosing my heart for using zigbee network. After each power outage I have crash of whole network and this time it's "Default response to failed" errors. Devices still reporting but can't be controlled anymore. Re-Configuring not working, Re-Pairing either...

Have you tried to update the dongle's firmware? It worked for me and other people.

[Satalicious]

I have exact same problem with all my routers. I'm loosing my heart for using zigbee network. After each power outage I have crash of whole network and this time it's "Default response to failed" errors. Devices still reporting but can't be controlled anymore. Re-Configuring not working, Re-Pairing either...

Have you tried to update the dongle's firmware? It worked for me and other people.

I also have this issue, i'm on the latest firmware.

Zigbee2MQTT-Version
   1.37.1

Coordinator-Typ
    zStack3x0

Coordinator-Version
    20230507

Coordinator IEEE Adresse
    0x00124b002c3ae922

Frontend-Version
    0.6.167

Zigbee Herdsman Konverter Version
    19.37.2

Zigbee Herdsman Version
    0.46.6

[szaman-89]

I have exact same problem with all my routers. I'm loosing my heart for using zigbee network. After each power outage I have crash of whole network and this time it's "Default response to failed" errors. Devices still reporting but can't be controlled anymore. Re-Configuring not working, Re-Pairing either...

Have you tried to update the dongle's firmware? It worked for me and other people.

Just did it and now have different problem :D

[2024-05-15 17:55:42] error: z2m: Error: network commissioning timed out - most likely network with the same panId or extendedPanId already exists nearby at ZnpAdapterManager.beginCommissioning (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:341:23) at ZnpAdapterManager.start (/app/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/manager.ts:86:17) at Controller.start (/app/node_modules/zigbee-herdsman/src/controller/controller.ts:124:29) at Zigbee.start (/app/lib/zigbee.ts:62:27) at Controller.start (/app/lib/controller.ts:109:27) at start (/app/index.js:107:5)

[invisible999]

I have rolled back zigbee add-on to 1.36 and I don't have these problems any more. I did not upgrade coordinator firmware.

[Satalicious]

I just rolled back to 1.36 and it works like a charm.

[Soundmaker-73]

Same issue for me, after a downgrade to 1.36.1 everything is working without problems again.

[yarafie]

I downgraded to 1.36.1 (Running in Docker so was essy) and so far so good

[summer1090]

i was also had to rollback to 1.36.1, as later versions are not stable

[Koenkk]

1.36.1 probably has exactly the same issue, the only difference is that it is not logged there (this was added in 1.37.0)

[iceland12]

Confirmed, after downgrade from 1.37 to 1.36.1 all working as expected. No firmware upgrade needed.

[summer1090]

1.36.1 probably has exactly the same issue, the only difference is that it is not logged there (this was added in 1.37.0)

but network is stable with 1.36.1 and laggy with next releases

[heisenberg2980]

I was having some problems lately with my zigbee network and found this issue, will try to downgrade to 1.36.1 and see if the problems dissapear

[foux]

After:

• Upgrading my sonoff dongle P to lastest firmware
• Reseting the dongle
• upgrading to 1.37.1 It "seems" to be ok.

Which firmware did you use?

For my Sonoff P version I used CC1352P2_CC2652P_launchpad_coordinator_20230507.hex like here: https://www.zigbee2mqtt.io/guide/adapters/flashing/flashing_via_cc2538-bsl.html

Upgrading the firmware worked for me, thanks a lot, I was going crazy

[Pferdebockwurst]

Since upgrading from 1.34 to 1.37.1 today I also see a lot of these messages in my log. But I can't say that my network has become unstable or laggy.

@Koenkk Is this particular error message a serious problem and can it really be fixed by upgrading the coordinators firmware, like some people said?

[foux]

Since upgrading from 1.34 to 1.37.1 today I also see a lot of these messages in my log. But I can't say that my network has become unstable or laggy.

@Koenkk Is this particular error message a serious problem and can it really be fixed by upgrading the coordinators firmware, like some people said?

Just FYI I was spammed by the message, and a network really instable. Since updating my firmware not a single message and network working like a charm

[szaman-89]

Yesterday I updated my Sonoff Dongle P with 20240315 firmware and errors are still visible but after few hours.

[trozman]

Yesterday I updated my Sonoff Dongle P with 20240315 firmware and errors are still visible but after few hours.

Did you reset (disconnect from mains, connect back) all the ZigBee routers? This helped me after the fw update.

[simondrake]

I'm seeing the same issue with a ZigStar UZG-01. There are no available firmware updates.

[szaman-89]

@trozman Because of this errors at the begining I reflashed stick with the same firmware and all my network crashed permanently. After that I needed to configure z2m from begining and all devices again and did power off whole house to be sure that this step isn't missed. Errors came back after another day.

[iceland12]

Confirmed, after downgrade from 1.37 to 1.36.1 all working as expected. No firmware upgrade needed.

sorry for late reply but I was too optimistic, also my network become unstable.

[szaman-89]

Today I did another chance to rescue my network and I played with interferences. All I did was change 2 AP's wifi channels from 1 to 6 because of using channel 11 on zigbee network. Second thing I did was increasing distance of sonoof dongle p from my terminal. Stick was 5 cm away from two SSD's. After about 5-6 hours I have 0 errors. Even zigbee network is now much more responsive and wasn't ever as much stable as it is now. I wonder for how long. Will update if something will change.

[heisenberg2980]

As the inestability issues were not improving after changing the z2m version or the coordinator firmware, I decided to sniff the traffic to try to find out what was happening, and it turns out that the issue in my case seemed to be the position of the coordinator, which was too close to the server as I was not using a usb extension cable (I know, rocky mistake...). After connecting the coordinator using a usb extension cable, the zigbee network has improved a lot. This might not be the same case for everyone, but I recommend everyone having stability issues get a cheap CC2531 and sniff the zigbee traffic following this guide: https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html

These screenshots show the difference in the data sent by one of my motion sensors. The sensor always sends two messages (motion and light value), and before adding the extension cable, the device had to send the first message four times (sequence number 8) without receiving any ACK, and the second message three times (sequence number 9, luckily the third time it received an ACK, which means the coordinator received this last message):

After adding the extension cable, the device received the ACK immediately after the first try for both messages (sequence numbers 14 and 15):

[Satalicious]

As the inestability issues were not improving after changing the z2m version or the coordinator firmware, I decided to sniff the traffic to try to find out what was happening, and it turns out that the issue in my case seemed to be the position of the coordinator, which was too close to the server as I was not using a usb extension cable (I know, rocky mistake...). After connecting the coordinator using a usb extension cable, the zigbee network has improved a lot. This might not be the same case for everyone, but I recommend everyone having stability issues get a cheap CC2531 and sniff the zigbee traffic following this guide: https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html

These screenshots show the difference in the data sent by one of my motion sensors. The sensor always sends two messages (motion and light value), and before adding the extension cable, the device had to send the first message four times (sequence number 8) without receiving any ACK, and the second message three times (sequence number 9, luckily the third time it received an ACK, which means the coordinator received this last message):

After adding the extension cable, the device received the ACK immediately after the first try for both messages (sequence numbers 14 and 15):

Adding a USB extension cable is a game changer. It is so smooth now!

[PavelSkyba]

Greetings to all. I have a problem too. started after firmware 1.37.1. I solved the USB problem with an extension cable.

[mremedi2023]

Same problem here