Timeouts sending commands to Smartwings WM25L-Z, can still receive messages, works for a while after Z2M restart

kevinmilner commented 2 months ago

What happened?

I have a number of Snartwings WM25L-Z zigbee blinds, controlled by Zigbee2MQTT using a RaspBee II.

Occasionally, one or more of the blinds (this has happened with multiple of them) will start timing out whenever I try to set the state via Zigbee2MQTT. When this occurs, no state changes can be made, but I still receive status updates if I adjust the blinds manually using the provided remote; i.e., it's only a 'set' problem and not a 'get' problem.

Restarting zigbee2mqtt resolves the problem temporarily. This has been happening every few days.

Here is the log output when the problem is occurring:

debug 2024-04-22 10:34:53Publishing 'set' 'state' to 'studio/left_blackout_shade_raw'
error 2024-04-22 10:35:03Publish 'set' 'state' to 'studio/left_blackout_shade_raw' failed: 'Error: ZCL command 0x6c5cb1fffefd7bb4/1 closuresWindowCovering.upOpen({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received (119))'
debug 2024-04-22 10:35:03Error: ZCL command 0x6c5cb1fffefd7bb4/1 closuresWindowCovering.upOpen({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received (119)) at DeconzAdapter.sendZclFrameToEndpoint (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/adapter/deconz/adapter/deconzAdapter.ts:666:23) at Request.send (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/controller/helpers/request.ts:79:20) at Endpoint.zclCommand (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:760:28) at Endpoint.command (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:591:24) at Object.convertSet (/opt/zigbee2mqtt/node_modules/zigbee-herdsman-converters/src/converters/toZigbee.ts:593:13) at Publish.onMQTTMessage (/opt/zigbee2mqtt/lib/extension/publish.ts:259:36) at EventEmitter.wrappedCallback (/opt/zigbee2mqtt/lib/eventBus.ts:174:17)
info 2024-04-22 10:35:03MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'state' to 'studio/left_blackout_shade_raw' failed: 'Error: ZCL command 0x6c5cb1fffefd7bb4/1 closuresWindowCovering.upOpen({}, {\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":false,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received (119))'","meta":{"friendly_name":"studio/left_blackout_shade_raw"},"type":"zigbee_publish_error"}'

And here is log output showing that I can still receive updates from the shade when I manipulate it manually using the remote, even when sending fails. Doing that does not seem to wake it up, sending will still fail until I restart Z2M:

debug 2024-04-22 10:36:13Received Zigbee message from 'studio/left_blackout_shade_raw', type 'attributeReport', cluster 'closuresWindowCovering', data '{"currentPositionLiftPercentage":0}' from endpoint 1 with groupID null
info 2024-04-22 10:36:13MQTT publish: topic 'zigbee2mqtt/studio/left_blackout_shade_raw', payload '{"battery":89,"linkquality":135,"position":0,"state":"CLOSE"}'
debug 2024-04-22 10:36:14Received Zigbee message from 'studio/left_blackout_shade_raw', type 'attributeReport', cluster 'genPowerCfg', data '{"batteryPercentageRemaining":93}' from endpoint 1 with groupID null
info 2024-04-22 10:36:14MQTT publish: topic 'zigbee2mqtt/studio/left_blackout_shade_raw', payload '{"battery":93,"linkquality":127,"position":0,"state":"CLOSE"}'

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.36.1 commit: ffc2ff1d

Adapter firmware version

0x26610700

Adapter

RaspBee2

Setup

Plain on ancient original raspberry pi

Debug log

No response

majkers commented 2 months ago

Seems like https://github.com/Koenkk/zigbee2mqtt/issues/22189

henryjarend commented 1 month ago

Did you ever figure out anything on how to keep that from happening? I’m running into the same problem and I’ve tried the different fixes on the other mentioned thread as well but it doesn’t seem to have helped

kevinmilner commented 4 weeks ago

Did you ever figure out anything on how to keep that from happening? I’m running into the same problem and I’ve tried the different fixes on the other mentioned thread as well but it doesn’t seem to have helped

@henryjarend, were you having the problem where it wouldn't start working again until after a restart? And what coordinator are you using?

That part seems to have gone away with recent Z2M updates. I have still been having reliability issues though, so I rebuilt my entire network over the weekend switching from my old RaspbeeII to a Sonoff USB Dongle Plus. I also added another dongle in router mode, and things have been stable thus far, indicating that it might have been due to poor signal issues. I also enabled the availability feature so that my shades keep in constant contact, thinking that it might keep them from sleeping and becoming unreachable.

I've changed too many variables to pinpoint what exactly helped the most, but I'm currently cautiously optimistic that I have things stable and working. Good luck!

henryjarend commented 4 weeks ago

I did a similar ‘solution’ I totally nuked everything and rebuilt the entire zigbee network starting from the 1.38.0 version of z2m and using the ember driver connected to the latest dev firmware on my slzb-06m. so far everything has been alright but I know as soon as I say that I’ll run into an issue. I didn’t think it was a signal strength issue because one of the shades that wasn’t responding was right next to my radio/coordinator so that seemed a little suspect. I also disabled the availability check on this new deployment because I never got any useful I formation out of it and it seemed to drain the batteries of my other devices much more quickly

Koenkk / zigbee2mqtt