Tuya Zigbee Curtain module QS-Zigbee-C01

[AdrienBigot]

Hello,

I bought a zigbee module to automate my roller shutter garage. Unfortunally, deconz mistakenly identified it as a TS130F device ( https://es.aliexpress.com/item/4001190275372.html ). In reallity this is not a switch , it's this :

Bought here : https://fr.aliexpress.com/item/1005001530266723.html

I successfully manage to go up and down with the detected TS130F configuration but the problem I encounter is that each time I execute the command to go UP or down, the opening/closing time is only 10 secondes. My roller shutter takes approximatively 30 secondes to Open/close so I have to execute 3 times the opening/closing command.

Device

• Product name: Zigbee curtain module
• Manufacturer: _TZ3000_vd43bbfq
• Model identifier: TS130F
• Device type :
  • Other: Curtain / Roller shutter module

Screenshots

thanks !

Adrien

[Smanar]

I m not sure to understand the issue. You are making the request curl "http://192.168.0.207:80/api/2D58761B15/lights/51/state" -XPUT -d'{"lift": 10}' You have the return "success" but the device don't move and the json stay at lift=0 ?

[2chilled]

@Smanar Yes, you understood correctly. This problem occurs with 2 devices installed on top of each other. I also tested them using deconz GUI and I'm getting timeouts there. What I also observed in the GUI is that both devices have bad connection and somehow they're not connecting to the nearest Zigbee routers around them. For example I have a plug 1m away from them which is very well connected but they just don't connect to it. I guess I will pull them out the wall and check if it helps or really replace them in the end.

For the deconz-rest-plugin the isolated issue I'm observing that it delivers false positives. It shouldn't return success if it wasn't successful. But it does in my case.

[2chilled]

@Smanar Update: I removed both devices from deconz and added them again. After that everything works as it should :) But the last point from above remains in general.

[Smanar]

Just for information about the deconz working mode. When you make a request, you will have a "success" if deconz can send the request, it don't mean the device will use it.

• You make the http request
• Deconz send the zigbee request
• You have the "success" message
• The device execute the request
• The device send report
• deconz Update the value

So bad connexion can explain your issue, but the question is why you have bad connexion.

[2chilled]

Ok, then deconz behaves like expected. Yeah, that one still remains. At least I know a workaround for next time ;)

[69franky]

I could successfully calibrate the device, via the rest api as described above: curl "http://openhabian:80/api/abc/lights/22" -d '{"calibration":true}' -XPUT curl "http://openhabian:80/api/abc/lights/22/state" -d '{"lift":0}' -XPUT curl "http://openhabian:80/api/abc/lights/22/state" -d '{"lift":"stop"}' -XPUT curl "http://openhabian:80/api/abc/lights/22/state" -d '{"lift":100}' -XPUT curl "http://openhabian:80/api/abc/lights/22/state" -d '{"lift":"stop"}' -XPUT curl "http://openhabian:80/api/abc/lights/22" -d '{"calibration":false}' -XPUT

Indeed after putting "calibration" to false, the return code is "success", but the device stays actually in calibration mode. I decided to apply a power off/on cycle (disconnecting the device from supply) and then the device boots up in "normal" mode. In my case the new calibration settings had been applied by the device. The default was 10 seconds for UP and 10 sec for DOWN. After power off/on cycle the device was changed to 15 seconds for UP and 15 sec for DOWN. Exactly the times which I used in the calibration procedure.

Maybe its not reproduceable, hence would appreciate if someone could also test and confirm.

[Smanar]

Indeed after putting "calibration" to false, the return code is "success", but the device stays actually in calibration mode.

If you enable log ("APS" "info" and "info_l2"), you will see a zigbee log with return from the device. It s a good way to check if the device have used the request or have skipped it (or an error if it don't like the request) Will be usefull to check, because I don't see why the request is not working.

[2chilled]

@69franky Your method to terminate calibration mode worked for me for some of my qs-zigbee-c01 devices but not for all of them. Maybe it also depends on actual manufacturer. I have both "_TZ3000_vd43bbfq" and "_TZ3000_fccpjz5z" installed.

[2chilled]

@Smanar My old issue shows up again: All of my devices on second floor, which means maximal distance to Conbee 2 which is installed in basement, don't react to writes from time to time. But when they are in this state and I hit the manual switch, they always send me their live lift state. So it seems that connection quality is ok for sending (from device to Conbee) but not for receiving. Does this make any sense to you? I already ordered a Zigbee repeater hoping that will help..

Edit: Note that all other Zigbee devices, including some which have even more distance than the qs-zigbee-c01 ones, have no issues at all.

Logs after an unsuccessful lift write:

17:22:32:801 APS-DATA.indication request id: 82 -> finished
17:22:32:801 APS-DATA.request id: 82 erase from queue
17:22:33:212 poll node a4:c1:38:31:62:9c:67:ba-01
17:22:33:212 Poll light node Problematic device
17:22:33:370 read attributes of 0xA4C13831629C67BA cluster: 0x0000: [ 17:22:33:370 0x4000 17:22:33:370 ]
17:22:33:370 add task 23269 type 19 to 0xA4C13831629C67BA cluster 0x0000 req.id 86
17:22:33:370 Poll APS request 86 to 0xA4C13831629C67BA cluster: 0x0000
17:22:33:414 delay sending request 86 dt 4 ms to 0xA4C13831629C67BA, ep: 0x01 cluster: 0x0000 onAir: 1
17:22:33:414 delay sending request 86 ep: 0x01 cluster 0x0000 to 0xa4c13831629c67ba onAir 1
17:22:33:514 delay sending request 86 dt 4 ms to 0xA4C13831629C67BA, ep: 0x01 cluster: 0x0000 onAir: 1
17:22:33:514 delay sending request 86 ep: 0x01 cluster 0x0000 to 0xa4c13831629c67ba onAir 1
17:22:33:614 delay sending request 86 dt 4 ms to 0xA4C13831629C67BA, ep: 0x01 cluster: 0x0000 onAir: 1
17:22:33:615 delay sending request 86 ep: 0x01 cluster 0x0000 to 0xa4c13831629c67ba onAir 1
17:22:33:713 DB save zll database items 0x00000081
17:25:51:766 0xA4C13831629C67BA error APSDE-DATA.confirm: 0xA7 on task
17:26:52:055 0xA4C13831629C67BA error APSDE-DATA.confirm: 0xD0 on task
17:26:52:055          drop item state/lift
17:51:22:352 0xA4C13831629C67BA error APSDE-DATA.confirm: 0xA7 on task
17:51:22:352 Erase task req-id: 42, type: 36 zcl seqno: 103 send time 17, profileId: 0x0104, clusterId: 0x0102

Edit: Found an explanation for these errors here: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log. Seems to be a connection issue. I hope this will improve once my repeater is in place.

[69franky]

@69franky Your method to terminate calibration mode worked for me for some of my qs-zigbee-c01 devices but not for all of them. Maybe it also depends on actual manufacturer. I have both "_TZ3000_vd43bbfq" and "_TZ3000_fccpjz5z" installed.

I am evaluating only one device, which is from "_TZ3000_fccpjz5z", and I could calibrate it. All this does not sound like a sustainable solution. Keep you posted.

[2chilled]

@Smanar My repeater is in place for 2 days now and the problem still persists. It seems like these devices have problems connecting with my other routers. There are 3 devices suffering from the issue described above and all of them have no connection to the Conbee2 coordinator. Is there anything I can do about it? Do you know of an alternative rollershutter device which also supports the lift API?

[Smanar]

It remember me a similar issue, an user with the same kind of issue, it was always the device at the same place that have the issue, even if he reverse them. I can't say where the issue is from, deconz, zigbee, API code, devices ..... And no I can't advice you, I haven't tuya device at all, but try on the discord or the forum, will be better than a closed issue.

[qba667]

@Smanar the problem wit calibration stop seems to be caused by invalid data type used, I can not find source of the deCONZ::ZclAttribute to check it in details.

20:19:10:328 HTTP API PUT /api/0F8185E7EF/lights/3 - 192.168.1.172
20:19:10:328 Text Data:         {"calibration":false}
20:19:10:328 ApiMode: 0
20:19:10:329 ZclAttribute::setValue(qint64 value) for unsupported datatype 0x30
20:19:10:329 write attribute of 0xB4E3F9FFFE12FC53 ep: 0x01 cluster: 0x0102: 0xF001
20:19:10:329 add task 92 type 20 to 0xB4E3F9FFFE12FC53 cluster 0x0102 req.id 140
20:19:10:329 [{"success":{"/lights/3/calibration":false}}]
20:19:10:357 APS-DATA.request id: 140, addrmode: 0x03, addr: 0xb4e3f9fffe12fc53, profile: 0x0104, cluster: 0x0102, ep: 0x01 -> 0x01 queue: 0 len: 7 tx.options 0x04
20:19:10:375 APS-DATA.indication srcAddr: 0x4a15, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0102, lqi: 255, rssi: -40
20:19:10:375    asdu: 18080400
20:19:10:387 Erase task req-id: 140, type: 20 zcl seqno: 8 send time 0, profileId: 0x0104, clusterId: 0x0102
20:19:10:387 APS-DATA.confirm id: 140, status: 0x00 SUCCESS
20:19:10:387 APS-DATA.confirm request id: 140 -> erase from queue
20:19:10:389 aps request id: 140 finished, erase from queue

Calibration start seems to work perfectly but same error is thrown

20:18:56:442 HTTP API PUT /api/0F8185E7EF/lights/3 - 192.168.1.172
20:18:56:442 Text Data:         {"calibration":true}
20:18:56:442 ApiMode: 0
20:18:56:442 ZclAttribute::setValue(qint64 value) for unsupported datatype 0x30
20:18:56:442 write attribute of 0xB4E3F9FFFE12FC53 ep: 0x01 cluster: 0x0102: 0xF001
20:18:56:442 add task 23 type 20 to 0xB4E3F9FFFE12FC53 cluster 0x0102 req.id 39
20:18:56:442 [{"success":{"/lights/3/calibration":true}}]
20:18:56:457 APS-DATA.request id: 39, addrmode: 0x03, addr: 0xb4e3f9fffe12fc53, profile: 0x0104, cluster: 0x0102, ep: 0x01 -> 0x01 queue: 2 len: 7 tx.options 0x04
20:18:56:472 APS-DATA.confirm id: 36, status: 0x00 SUCCESS
20:18:56:472 APS-DATA.confirm request id: 36 -> confirmed, timeout 0

Found the reason, as @ebaauw mentioned in one of commits:

ZclAttribute is broken for Zcl8BitEnum.

So we can not use it - we need to format data-frame own-self.

[69franky]

After intensive evaluation of the device, I returned it to the dealer. I have tested two device:

1. qs-zigbee-c01 devices from  "_TZ3000_fccpjz5z"
2. Moes MS-108ZR / _TZ3000_1dd0d5yi/ TS130F

Calibration worked for both (applying power off/on cycle at the end). But I discovered a another issue, which you might want to comment on:

Actually I wanted to implement a "toggle" function for UP/STOP and also for DOWN/STOP. The REST-API supports only commands for UP,DOWN and STOP. Actually I think that the REST API should also support the toggle commands, but maybe there are good reasons not to have it.

Hence, I decided to query the device status first and then send either UP, STOP or DOWN depended on the device state. For example: if (state.on==MOVING) then send command STOP; if (state.on==STOP) then send command UP;

At the end I failed to get the correct device state. I thougt that "state.on" (see below) should always reflect the current device state, at least if the roller shutter is on ("state.on"=true == moving up or down) or If it is not moving ("state.on"==false).

In fact this is not working on neither device. I could not figure out what is the meaning of "state.on", but definitely it does not represent the relay state. For example if the device stopped in the UP position and then you read "state.on", then it still return "state.on"=true, which is weired. Your comments are appreciated.

{ "etag": "38d61d7d3edfc5d6f193b84e64ec2ca9", "hascolor": false, "lastannounced": null, "lastseen": "2021-10-22T09:43Z", "manufacturername": "_TZ3000_1dd0d5yi", "modelid": "TS130F", "name": "Moes MS-108ZR", "state": { "bri": 254, "lift": 100, "on": false, "open": false, "reachable": true }, "swversion": null, "type": "Window covering controller", "uniqueid": "60:a4:23:ff:fe:fd:f7:6f-01" }

[Smanar]

Actually I think that the REST API should also support the toggle commands, but maybe there are good reasons not to have it.

There is a Toogle zigbee command for light, but not for covering. Personnaly I don't see utility to a "toggle" command for them, the morning I want to open them, and the night to close them.

Open is true if lift < 100 On is true if lift > 0

@qba667 Realy nice catch, thx a lot. Will see to make a work around for that.

[qba667]

@Smanar I have already recompiled the lib with the workaround, maybe today I can test. After that I will provide you a update. Do you know who is responsible for maintaining the ZclAttribute?

[69franky]

There is a Toogle zigbee command for light, but not for covering. Personnaly I don't see utility to a "toggle" command for them, the morning I want to open them, and the night to close them.

I want to use only two buttons (UP and DOWN) instead of three buttons (UP,STOP,DOWN). That would enable much more button switches which are available on the market. Three buttons for a simple UP/DOWN window covering is really too much. Think about the window lifter controller in your car :-) pls let me know if a fix would be available.

Also another question: Does someone know if it is possible to configure the behavior of the two inputs of the modules, where you connect the UP/DOWN switch? Is it possible to reconfigure them from level-controlled to edge-controlled?

[Mimiix]

That would enable much more button switches which are available on the market. Three buttons for a simple UP/DOWN window covering is really too much. Think about the window lifter controller in your car :-)

Your example uses the hold functionality. Or a seperate "press trough". So that would your switch requiring the "hold" capability.

Either way, this discussion is not for this topic. Please keep it on-topic on integrating the device :)

[Smanar]

@Smanar I have already recompiled the lib with the workaround, maybe today I can test. After that I will provide you a update. Do you know who is responsible for maintaining the ZclAttribute?

I m asking to manup ATM. For me it's from the deconz core, so IDK yet if he want to correct on his side or prefer we use "patch".

[Smanar]

@qba667 Something that can work, if you can try it with your device

        deCONZ::ZclAttribute attr(0xf001, deCONZ::Zcl8BitEnum, "calibration", deCONZ::ZclReadWrite, true);
        attr.setValue(value);

replaced by

        deCONZ::ZclAttribute attr(0xf001, deCONZ::Zcl8BitEnum, "calibration", deCONZ::ZclReadWrite, true);
        attr.setNumericValue(value);

[Smanar]

@qba667 you have tried the code modification ?

[AoSpades]

Hi there! I've got a similar device which I'm trying to use over Zigbee2Tasmota and the console.

Is there any way to enter calibration mode using a ZbSend command on these devices?

[Mimiix]

@AoSpades thats kinda off-topic..

[AoSpades]

@Mimiix As a noob I'm out of wits here, so any help would be appreciated.

[Mimiix]

@AoSpades ITs simple: Zigbee2Tasmota is not deCONZ, thus offtopic 😅

[Smanar]

Hello, someone here have issue with this device ignoring some request ? Was like it was disconnecting, but work again after a time ?

[2chilled]

Yep, I have two devices which behave sort of like that. Both have no direct coordinator connection. They can work fine for a few weeks and suddenly ignore commands for some days. Then it repeats. But they are always able to send data to coordinator. I know that because when in bad state and pushing the manual button they always tell coordinator their curtain position.

[Smanar]

Ok, thx. Because I have another user with 10 coverings, and lot of them stop working randomly, can work naturaly after some time or with some request using the GUI.

And I don't found similars issues on google, idk if it s from the device or if we can do something ....

[AdrienBigot]

Yes !!! I'm in that case. I've put in place an alarm in HomeAssistant to send me a SMS when my garage door is unavailable because I suspected this problem. And sometimes, (I can't reproduce it) I don't know why it becomes unavailable and it is back a few minutes later. First, I thought it was a conflit with my wifi, I try to change channel , try to add a 2 meters USB extension cable to place my conbee II away , but nothing change. I've tried to put some debug log in deCONZ, but my eyes has burned. So I left it as is. I'm pleased to hear about that because I always thought the problem was on my side.

[Smanar]

Thx I will ask too on Z2m issue to see if it s same for them.

Edit: Ok no need they have the same issue https://github.com/Koenkk/zigbee2mqtt/issues/9249

But not good new (I have just buy one too ...)

[2chilled]

For them it seems even buggier as they also have problems when these beasts are directly connected to coordinator. I have 7 qs-zigbee-c01 devices running and five of them which have direct connection to conbee 2 are working without any issues for months now.

[Smanar]

So they work better with direct connexion to coordinator for you ?

[2chilled]

Yes, they just work when directly connected to coordinator. But I have to add that (unfortunately) all these five directly connected devices have other ZigBee routers with proper antennas around them in a 2-3cm margin. The nearest proper routers around the two black sheeps have a distance of ~50cm. Maybe that's the actual root cause, don't know.

[Sjonnie2018]

If I understand correctly one would be best of with a more powerful coordinator. So maybe a Conbee 3 with more transmitting power would solve the problem?

[2chilled]

Yeah, perhaps. But that ConBee 3 probably would have a too high energy consumption for itself. Maybe someone can make a test and place a good ZigBee router very near to problematic qs-zigbee-c01 to see if that makes it work reliable. E.g. that Ikea "repeater" would be a good fit for that. I'll do it by myself before deciding to replace them with Shellys ;)

[Smanar]

It's perhaps possible to "fixe a route" https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Source-Routing#fixed-source-routes-source to force the device use the coordinator

But if I remember, it s totaly random for @Sjonnie2018

[Sjonnie2018]

[quote]snip I'll do it by myself before deciding to replace them with Shellys ;)[/quote]

Well... there is an alternative I hadn't thought about! The Shelly 2.5 is dirt cheap and would be an alternative to my ZigBee roller shutter devices. Shelly has a Domoticz integration (have to further investigate that) and that would make it a great companion to my home automation setup.

Thank you very much for this tip. Much appreciated!

[2chilled]

It's perhaps possible to "fixe a route" https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Source-Routing#fixed-source-routes-source to force the device use the coordinator

But if I remember, it s totaly random for @Sjonnie2018

I already tried source routing but unfortunately it made things worse for me. The whole network became much less responsive resulting in command timeouts. I guess that feature is just not yet mature enough.

@Sjonnie2018 Yeah, that's true. Only reason I didn't replace them yet is that IMO ZigBee is by far the better network protocol for home automation devices. By design it eliminates a whole bunch of security, privacy and open api problems you have with other technologies like WIFI. There is just no way for devices to talk to China Cloud because there is no gateway to the outside of your house network. Admittedly Shelly is an exception here, but it's still WIFI ;)

[Sjonnie2018]

@Sjonnie2018 Yeah, that's true. Only reason I didn't replace them yet is that IMO ZigBee is by far the better network protocol for home automation devices. By design it eliminates a whole bunch of security, privacy and open api problems you have with other technologies like WIFI. There is just no way for devices to talk to China Cloud because there is no gateway to the outside of your house network. Admittedly Shelly is an exception here, but it's still WIFI ;)

Hi,

I think I can manage the communication of the device to the outside world. I have separate SSID's/VLAN's for my talkative devices. And my UniFi router is very capable of blocking any communication over the Internet. But it's sound advice!

I have just ordered one Shelly 2.5 to experiment with. I have one ZigBee roller shutter device that has more than his fair share of failing so I will replace that one and see if I can manage it in Domoticz and test the reliability.

(They really are dirt cheap so experimenting is a joy :-) )

Again thanks for your invaluable tip! I hadn't thought of it :-)

[belly-89]

I have 2 sunshades that I operate with 2 of these devices. Calibration works and I can do it via the Deconz interface. Only after calibration do the shutters no longer open fully. I think this has to do with the fact that going "up" takes more power or something. After each closing, the sunshade opens a little less. I've already calibrated about 5 times. Also tried increasing the opening time by pressing the stop button a few seconds later while calibrating, but that doesn't work either. Anyone an idea how to solve this?

[Smanar]

I don't remember but I have this device, and if you have the GUI you have a "Calibration time (tenth of a second)" in the covering cluster, just increase this value.

[belly-89]

I don't remember but I have this device, and if you have the GUI you have a "Calibration time (tenth of a second)" in the covering cluster, just increase this value.

Thanks! I found the "Calibration time (tenth of a second)" in de GUI. On both sunscreens it has a different number. Do I need to change it before calibration or after to make an correction? Sorry, not really sure what to do!

[Smanar]

On mine there is no calibration, it s just a timed mouvement, so I put the value I want. You can try a calibration, read the value, add 20% and save it on the device.

[belly-89]

On mine there is no calibration, it s just a timed mouvement, so I put the value I want. You can try a calibration, read the value, add 20% and save it on the device.

So it is not the time of the calibration but the time the screen is active. Will try it tonight! Thanks

[Smanar]

Yep the time the contact stay active when you send an order.

[belly-89]

Unfortunately, that doesn't work for me. The time that it is active is indeed longer. But if I close my awning to 80% and then open it again, it still won't close. I think this is because closing is faster than opening because it takes less energy. So in the end it just keeps getting worse and worse. 1 sunscreen stops automatically at 100%, so I can ensure that I always open or close it completely. I don't want to open my 2nd screen 100% because of saftey reasons, so this is not an option. anyone got an other idea?

[Smanar]

I think you can't have better with this device, it don't support "lift feature", it's jut a fake one using timing, and as you say, it take more time to open the covering than to close it.

[belly-89]

Thanks! Then

I think you can't have better with this device, it don't support "lift feature", it's jut a fake one using timing, and as you say, it take more time to open the covering than to close it.

I think you are correct. Do you now an alternative that works with Deconz and has an lift feature?

[Smanar]

Yes, but the problem is there are never module, but it's the covering itself that support this feature. It s inside the covering they have electronic to know exactly the cover position.

[KipiKland]

been delivered the new module SC500ZB-V2 seen again as TS130F by deCONZ. working as a charm

Strange that it appears as a light on phoscon webapp