Lonsonho QS-Zigbee-C01 unresponsive (but not disconnected?) after some time

[bonjour81]

What happened

The curtain module Lonsonho QS-Zigbee-C01 is unresponsive after a few hours.

• it won't answer to commands (cover, calibration...), ie: the blind does not move on zigbee request.
• but it still move using the wall switch (wall switch are wire connected to the module inputs) and emit some mqtt messages (updating position).
  So it's not "disconnected" from zigbee, just kind of not listening to commands.

For information, if relevant : I use "motor_reversal" get command as a "ping" to check the module is still connected
I send this command every 15 minutes. I use this because the module seems not sending any periodic message I could use.

I attached zigbee2mqtt logs: https://hastebin.com/bevahezoqa.apache

• at the beginning (line 1-7) you can see my "ping" with motor_reversal command and error message.
• starting line 8, you can see a few trials to close the blind (3 messages).
  as it was not moving, I tried wall switch.
• starting line 14 to line 35 you can see that following my wall switch trigger, the module reports several message.
• Then I send a few more zigbee commands (close close open): line 36, 43, 45).
• starting line 38 and til the end, you can see what I think is timeout message for my 6 trials to move the blind with mqtt.

What did you expect to happen

working fine?

How to reproduce it (minimal and precise)

not trigger identified, just wait a few hours.
after a power cycling, it works fine with zigbee commands.

Debug info

Zigbee2MQTT version: 1.21.2 (docker latest)
Adapter hardware: CC2652P (coordinator + router)
Adapter firmware version: Egony, last valid (coordinator: release 20210319, router: release 20210812)
A couple of philips hue lamps in my network are also routers (OTA firmware up to date in zigbee2mqtt frontend)

[Koenkk]

Please check if this also happens with the official firmware: https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin

[bonjour81]

Sure I can try: does it require re-pairing devices ?

[Koenkk]

no

[bonjour81]

CC2652P (Ebyte E72-2G4M20S1E) Coordinator now flashed with CC1352P2_CC2652P_other_coordinator_20210708.hex
The blind answer to commands, now wait & see.
I'll give some news by tomorrow latest.

[bonjour81]

Hi !
So after flashing official firmware in coordinator, I have same wrong behavior pretty quickly: less than half an hour after flashing, the module was unresponsive (but still emitting message if moved using wall switches).

After that, I reseted the module itself (unpairing, reset, re pairing). after that it worked all night til lunch today.
Since lunch, the module is unresponsive again but still when I use wall switch, it will emit messages.

[Koenkk]

Could you provide the herdsman debug log when controlling it fails?

See https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging on how to enable the herdsman debug logging. Note that this is only logged to STDOUT and not to log files.

[bonjour81]

Ah you answer before I post my message I was currently writing :)

Now I enabled the "Zigbee-herdsman debug logging". I am in a docker, so I added ENV parameter DEBUG=zigbee-herdsman*
But due to this, I restarted zigbee2mqtt and so the module works fine again (let's wait and see)

On this page: https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging, I found that I can get the logs with command docker logs CONTAINER_ID > log.txt 2>&1
Is that the right command to get the Zigbee-herdsman logs? it looks pretty similar to usual zigbee2mqtt logs...shall I seek for a specific keyword in the logs ?

[bonjour81]

Now that all debug logs are enabled : no more issue...I keep in touch in a few days.

[bonjour81]

Hi,
This morning, the module stopped answering.
Here is the log:
https://hastebin.com/ajoqezozun.apache

As you can see a couple of message above, I'm not sure if this is the "Zigbee-herdsman logs", let me know if something is missing. (if relevant, I execute Zigbee2mqtt in a docker)

[Koenkk]

This is indeed not the zigbee herdsman debug logging, with this enabled you should immediately see a lot more logging. Make sure that the environment variable is set correctly, when going into the container with docker exec -it Z2M_CONTAINER_NAME bash and executing env you should see it.

[bonjour81]

Hi, not sure why but bash is not working, I used sh instead (so docker exec -it Z2M_CONTAINER_NAME sh)
Env command is ok I think:

$ env
NODE_VERSION=14.18.0
HOSTNAME=elmut
YARN_VERSION=1.22.5
DEBUG=zigbee-herdsman
SHLVL=1
HOME=/home/node
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/app
TZ=Europe/Paris

Now I notice that here https://www.zigbee2mqtt.io/information/debug.html#zigbee-herdsman-debug-logging, there is a '*' (star symbol) after herdsman...it should be DEBUG=zigbee-herdsman* I added it and now I can see a lot more stuff in logs.
Sorry I missed this earlier.

Now let's wait for the module to get unresponsive again.

[bonjour81]

Hi ! Since last message here, the module did not really "crashed" like before, but this morning it was unresponsive a couple of hours and then get back to normal.
I've seen this with the periodic /get command I send to detect if it's alive.

Here is the log:

https://www.toptal.com/developers/hastebin/jibucecilo.rust

I tried to extract relevant part: ie when I send the "ping" ( 'zigbee2mqtt/volet_ch1/get' with data '{"motor_reversal":""}' )
and then the error message a few seconds later.

There are some message in between due to my other devices, so if some data seems to be missing, please let me know. Maybe I cut the logs in the wrong part.

[bonjour81]

Hi, here is a better log I think.
I managed to do it while the module is unresponsive.
I send a "open" command (line 3 of the log) and captured the logs til the zigbee2mqtt error message

https://www.toptal.com/developers/hastebin/ipiyuliwag.yaml

There is a an other device sending a message close the end (line 105-106) but I didn't remove to be sure I don't delete valuable information in following Herdsman logs.

[bonjour81]

Sorry, I don't mean to spam, but maybe a cleaner one: https://www.toptal.com/developers/hastebin/heyemoxewi.yaml
(without other device talking, as far as I can see).

[Koenkk]

I'm wondering if the device is directly connected to the coordinator in this case, otherwise a device should respond with a route. Could you take a sniff when sending a command to it fails?

https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

Please also post your network key (otherwise I cannot decrypt the traffic)

[bonjour81]

I prepared the sniffing setup, but module works fine again...let's wait for next unresponsive.

[bonjour81]

Here is a wireshark capture.
key is default.
I added the keys in wireshark preference as suggested in the link you shared.

lonsonho_curtain.zip

If anything is not done correctly, let me know. I already used a bit wireshark, but definitely not an expert.
I don't have the Zigbee sections in the middle part of wireshark windows, should I enable this ?

[Koenkk]

It looks that the curtain is indeed directly connected to the coordinator:

Now the question is why the coordinator cannot send messages to it.

• Is this device an end device or router?
• Could you provide a sniff when controlling the device works?
• Could you provide a herdsman debug log starting from the point where controlling still works until it stops working?

[bonjour81]

Hi,
The device is a router (it's blue in frontend / map)
Sure I can do a sniff when it work (should be ok by tomorrow).

The last one is harder as I cannot forecast when it occurs but I can try a trick. I will modify my nodered to send a get command every 1min so I can timestamp more accurately where to look in logs.

[bonjour81]

lonsonho_curtain_ok.zip

wireshark capture when it works fine (move up from 90% to 100% open)

[Koenkk]

@bonjour81 just providing the logs from starting z2m till it happens is OK

[bonjour81]

Oups I didn't see your last message,
Here is a log where it start failing.
I detected the failure at 17h35.

you can see line 270 the failed get message.
I hope the log it not too much flooded with unrelevent messages from other sensors.

I left a few minutes before and after

log8.zip

By the way: setting my detection to every 1 minutes (sending a get request): I notice some sporadic failure: I mean sometimes in a day I have no answer to get request and next minute (or longer) it will answer again.

[rdorys]

I got the exact same behaviour and I have a Tradfri Bulb router between the coordinator and the lonsonho. When I switch the power off and on the module starts to work again for few hours.
@bonjour81 On AliExpress, some comments are reporting bad quality and similar problems... It might be a quality problem in my opinion but i'm not an expert at all. Have you others QS Zigbee C01 which are working totally fine ?

[bonjour81]

Hi! Thanks for feedback
On my side it recovers if I do a power cycling or reboot z2m. I didn't tried playing with routers.
I have only one lonsonho module.
I agree with you, it may be a poor quality device: if nothing comes up here, I guess it will be the conclusion.

[rdorys]

In my case rebooting z2m when the lonsonho is working properly seems to trigger the issue... That's really weird...

However, I ordered a different one on Ali and I'm waiting for it.
https://a.aliexpress.com/_uWT3Q2

I will keep you in touch with this new one.

[GerhardLang]

I do have very similar problem, details see #9535 and am using 6 devices all reacting the same, from China and Amazon.
Bad luck with these. Did anyone try to update them on tuya hub? I do not have one, so this was an add‘l idea?
Hoping for solution and thanks to @bonjour81 for the great logging.

[rdorys]

@GerhardLang if all your 6 are reacting the same we can exclude isolated poor quality issue.
I don't have any tuya gateway sorry.
Have you always encountered the issue or did it happen after any update ?

[GerhardLang]

@rdorys the problems were from the beginning, I startet with october release with the Lohonso Curtain modules.
November update of Z2M did not change the behaviour. Nor did setting MQTT version to 5 or qos to 1.
Restarting of Z2M did not make all blinds working, only one. 🧐

[dkwireless]

I found interesting workaround, at least in my case.
If you add multiple devices in a group you can send commands even when they appear disconnected.
Once you send command to a group device becomes available again. You can just send stop.
This solves my case since 99% of the time my shutters are closed when sun goes down and opened at 9 in the morning.
I hope this might help us understanding what is going on with these devices.

[bonjour81]

Hi ! mine is _TZ3000_fccpjz5z too.
I have only one module so far.
Do you mean I can setup a group and just send a STOP command to group whenever it's disconnected to recover the connection? (or maybe just send the stop command to group before any command as preventive action).

[dkwireless]

I don't know if it would work with one module but give it a try.
Here is what I did:
I set us a group in z2m with all my QS-Zigbee-C01.

As you can see below one of them is not responding at the moment (I'm using availability so I can see state in HASS):

So first one is not responding. Then I send stop to group and:

First one is back again. I have three out of four dropping out.
Hope this helps.

[rdorys]

Wow, sounds like a useful backup for automations and routines, specially for @GerhardLang and his 6 modules... 😄
Thx for the tip even I bought another module.

[dkwireless]

Well, I use group for automations, but yes, you can bring individual one back online in automation if you need.

[dkwireless]

Update:
You can put single device into a group (while is available) and control it later even when it reports offline.
I can confirm this works with also with other devices like my Lonsonho 3CH switch that was showing similar behaviour. It is too far away to talk directly to coordinator.
Maybe this can give us some clue what could be a problem.

[bonjour81]

Hi ! I have some interesting information to share.

My module works pretty fine last weeks, I have only short disconnections, 1 or 2 times a weeks, so I was not able to test before.
I still have my "ping" system by sending motor_reversal get command every minutes to monitor the module status.

So this morning it was unresponsive.
Sending direct command tozigbee2mqtt/volet_ch1/set give errors message like described at the beginning of this issue.
In zigbee2mqtt web ui, it was "last seen" 10min ago.

So I published {"state": "STOP"} to zigbee2mqtt/mes_volets/set (mes_volets is my group name) => this gives no error and last seen on webui was updated to some seconds => So I guess it succeeded to reach the module.
But....the module was still unresponsive to direct commands published on zigbee2mqtt/volet_ch1/set : this still trigger some error messages
On the other end, publishing commands on the group topic works like a charm !
I can perfectly move up, down and stop the blind using zigbee2mqtt/mes_volets/set

so as short term workaround, I will probably use my single device group instead of the device directly.

But still, @Koenkk does this behavior make any sense ? while I fully agree this module has a design issue, z2m seems to handle it when using groups

[bonjour81]

Sending a STOP using direct topic publishing:

06.01.2022 09:54:23 zigbee2mqtt/volet_ch1/set {"state":"STOP"} 
06.01.2022 09:54:23 zigbee2mqtt/bridge/logging {"level":"debug","message":"Received MQTT message on 'zigbee2mqtt/volet_ch1/set' with data '{\"state\":\"STOP\"}'"} 
06.01.2022 09:54:23 zigbee2mqtt/bridge/logging {"level":"debug","message":"Publishing 'set' 'state' to 'volet_ch1'"} 
06.01.2022 09:54:46 zigbee2mqtt/bridge/logging {"level":"error","message":"Publish 'set' 'state' to 'volet_ch1' failed: 'Error: Command 0xa4c1384a6976ddc2/1 closuresWindowCovering.stop({}, {\"sendWhenActive\":false,\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":false,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Timeout - 25315 - 1 - 221 - 258 - 11 after 10000ms)'"} 
06.01.2022 09:54:46 zigbee2mqtt/bridge/logging {"level":"debug","message":"Error: Command 0xa4c1384a6976ddc2/1 closuresWindowCovering.stop({}, {\"sendWhenActive\":false,\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":false,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (Timeout - 25315 - 1 - 221 - 258 - 11 after 10000ms)\n    at Timeout._onTimeout (/app/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35)\n    at listOnTimeout (internal/timers.js:557:17)\n    at processTimers (internal/timers.js:500:7)"} 

Sending a STOP using group publishing topic:

06.01.2022 09:55:58 zigbee2mqtt/mes_volets/set {"state":"STOP"} 
06.01.2022 09:55:59 zigbee2mqtt/bridge/logging {"level":"debug","message":"Received MQTT message on 'zigbee2mqtt/mes_volets/set' with data '{\"state\":\"STOP\"}'"} 
06.01.2022 09:55:59 zigbee2mqtt/bridge/logging {"level":"debug","message":"Publishing 'set' 'state' to 'mes_volets'"} 
06.01.2022 09:55:59 zigbee2mqtt/bridge/logging {"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/volet_ch1', payload '{\"last_seen\":\"2022-01-06T09:55:59+01:00\",\"linkquality\":6,\"motor_reversal\":\"OFF\",\"moving\":\"STOP\",\"position\":80}'"} 
06.01.2022 09:55:59 zigbee2mqtt/volet_ch1 {"last_seen":"2022-01-06T09:55:59+01:00","linkquality":6,"motor_reversal":"OFF","moving":"STOP","position":80} 
06.01.2022 09:55:59 zigbee2mqtt/bridge/logging {"level":"debug","message":"Received Zigbee message from 'volet_ch1', type 'attributeReport', cluster 'closuresWindowCovering', data '{\"currentPositionLiftPercentage\":80,\"tuyaMovingState\":1}' from endpoint 1 with groupID 0"} 
06.01.2022 09:55:59 zigbee2mqtt/bridge/logging {"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/volet_ch1', payload '{\"last_seen\":\"2022-01-06T09:55:59+01:00\",\"linkquality\":9,\"motor_reversal\":\"OFF\",\"moving\":\"STOP\",\"position\":80}'"} 
06.01.2022 09:55:59 zigbee2mqtt/volet_ch1 {"last_seen":"2022-01-06T09:55:59+01:00","linkquality":9,"motor_reversal":"OFF","moving":"STOP","position":80} 

[Neonox31]

Hello,

Mine is a _TZ3000_vd43bbfq and experiences timeout problems too.
The link quality is not ideal but it has working rock solid until a few months ago.

I use a zzh! coordinator with latest firmware, and I will took some time to enable Zigbee-herdsman debug logging

2022-01-10 13:48:25: Received MQTT message on 'zigbee2mqtt/kitchen_cover_south/set' with data '{"state":"CLOSE"}'
2022-01-10 13:48:25: Publishing 'set' 'state' to 'kitchen_cover_south'
2022-01-10 13:48:48: Publish 'set' 'state' to 'kitchen_cover_south' failed: 'Error: Command 0xcc86ecfffebc0904/1 closuresWindowCovering.downClose({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 57244 - 1 - 21 - 258 - 11 after 10000ms)'
2022-01-10 13:48:48: Error: Command 0xcc86ecfffebc0904/1 closuresWindowCovering.downClose({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 57244 - 1 - 21 - 258 - 11 after 10000ms)
    at Timeout._onTimeout (/app/node_modules/zigbee-herdsman/src/utils/waitress.ts:64:35)
    at listOnTimeout (internal/timers.js:557:17)
    at processTimers (internal/timers.js:500:7)

[swiergot]

Same here, tried two of those. Will test the workaround. If it works, this should hide the problem entirely:

cover:
  - platform: template
    covers:
      proxy_cover_1:
        friendly_name: "Some cover"
        value_template: "{{ states('cover.original_cover_1') }}"
        position_template: "{{ state_attr('cover.original_cover_1', 'current_position') }}"
        open_cover:
          service: cover.open_cover
          target:
            entity_id: cover.group_cover_1
        close_cover:
          service: cover.close_cover
          target:
            entity_id: cover.group_cover_1
        stop_cover:
          service: cover.stop_cover
          target:
            entity_id: cover.group_cover_1
        set_cover_position:
          service: cover.set_cover_position
          target:
            entity_id: cover.group_cover_1
          data:
            position: "{{ position }}"

[xvluny]

For the protocol, thanks to the tips here, I have added my ten actors each to its individual group via the zigbee2mqtt webUI. Before they were mostly never working. Now they work like a charm.

I have also tried isolating all actors in their own zigbee network - but this did not seem to have any effect on the issue.

[rgerbranda]

I have the same issue with this device (type _TZ3000_fccpjz5z )

Does anyone knows an alternative zigbee curtain closer that is working fine?

(gray in the image is unavailable)

[rdorys]

Hi @rgerbranda

This one is working for me, but it is not hidden behind an existing roller switch.

https://www.zigbee2mqtt.io/devices/11830304.html

I bought it here :
https://a.aliexpress.com/_uQX1wZ

Good luck

[rgerbranda]

Hi @rdorys
Placement is not an issue. My question is, can I use the same roller switch I'm using now?
I cannot find wire instructions for the Lonsonho 11830304

[rdorys]

No, your current mecanical switch will become useless.

The wireming is pretty straightforward (Line, Neutral, UP et Down) and should be equivalent to your glitchy module.

[rgerbranda]

Unfortunatelly that is no solution. I'm stuck to the switch

[rgerbranda]

I have a stable situation now, but I must say I'm not using Zigbee2mqtt. I'm using Deconz.

In Deconz I enabled 'Static Routing'. Since then my QS-Zigbee-C01 is responsive 24/7
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Source-Routing

[pyrexfm]

I have the same problem. Does anyone know if it's possible to do static routing in zigbee2mqtt?

[tsjjBCNBna]

Hi, I have the same issue with offline device after 11min... Any news or is a workaround available?

[bonjour81]

The "group" trick does not work ?

[tsjjBCNBna]

I have only one device, so I created a group and added the Switch. Now I have to wait for the next offline phase...

[bonjour81]

I also have a single device. I added it alone in a group :-).
The device still get unresponsive to direct command after a while but group commands continue to works perfectly.

So I only use group command for more than a year now,it works fine.

[pyrexfm]

How can you add it to a group? My device doesn't respond to adding to a group.

[dkwireless]

Restart device and add it to group right away.

[tsjjBCNBna]

Funny that the first row is for the group and the second row is for the device!?!
In the group line I could only drive the blind down and not up.
Is the group only to keep the switch online or should it be usable?

[swiergot]

@tsjjBCNBna For each cover I have a template configured in HA so that the state is taken from the individual entity but commands go to the group entity.

cover:
  - platform: template
    covers:
      bedroom_cover_proxy:
        unique_id: bedroom_cover_proxy
        device_class: shutter
        friendly_name: "Bedroom cover"
        value_template: >
          {% set entity_id = 'cover.bedroom_cover' %}
          {% if is_state(entity_id, 'unavailable') %}
          unavailable
          {% else %}
          {{ states(entity_id) }}
          {% endif %}
        position_template: >
          {% set entity_id = 'cover.bedroom_cover' %}
          {% if is_state(entity_id, 'unavailable') %}
          unavailable
          {% else %}
          {{ state_attr(entity_id, 'current_position') }}
          {% endif %}
        open_cover:
          service: cover.open_cover
          target:
            entity_id: cover.bedroom_cover_group
        close_cover:
          service: cover.close_cover
          target:
            entity_id: cover.bedroom_cover_group
        stop_cover:
          service: cover.stop_cover
          target:
            entity_id: cover.bedroom_cover_group
        set_cover_position:
          service: cover.set_cover_position
          target:
            entity_id: cover.bedroom_cover_group
          data:
            position: "{{ position }}"

[tsjjBCNBna]

That looks good, but in my case is it the other situation. In the group there is only the down button available and usable, regardles if the blind is up or down! so driving up the blind is only possible with the device up button!?! Very strange!
But I could see, that the device stays online for several hours now. Perfect!

[swiergot]

Same here - all of my cover groups (one cover each) are showing open even though all covers are closed now. Still, the groups will accept the "open" command and correctly drive the covers up. Thus the template cover.

[tsjjBCNBna]

OK, thanks so far! As a newbie I have to learn now how to implement this template into my HA...