DS82-Tuya-Zigbee Curtain Drive

[Kllrv]

This is supposedly a Zigbee 3.0 compliant curtain rail motor, released in 2020 or Jan 2021.

https://www.aliexpress.com/item/1005001874380608.html?

Device

• Product name: DS82-Tuya-Zigbee Curtain Drive
• Manufacturer: _TZE200_zpzndjez
• Model identifier: TS0601
• Device type :
  • Other: Cover

Screenshots

Somewhat misidentified as a smart plug

basic

tuya specific

otau

[Smanar]

Hello, do you have a linux machine to test code change ?

[Kllrv]

Yes - with following considerations: I run DeconZ community container in Debian Buster. If testing is required and existing setup isn't sufficient, I can make another virtual machine.

[Smanar]

Yes, I think it will be better, hard to do on docker, easier on VM.
You have the procedure here https://github.com/dresden-elektronik/deconz-rest-plugin#install-deconz-development-package-optional-linux-only
So for you

sudo apt install deconz-dev
git clone --branch DS82 https://github.com/Smanar/deconz-rest-plugin.git
cd deconz-rest-plugin
qmake && make
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

You will need 2 inclusions without deleting the device for integration.

I haven't tested the code on my side, so you can have error on compilation.

[Kllrv]

It compiled. Following error was proven to be due to a somewhat tainted environment.

● deconz.service - deCONZ: ZigBee gateway -- REST API
   Loaded: loaded (/lib/systemd/system/deconz.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/deconz.service.d
           └─override.conf
   Active: activating (auto-restart) (Result: exit-code) since Fri 2021-03-05 23:12:56 EET; 25s ago
 Main PID: 9674 (code=exited, status=1/FAILURE)
      CPU: 4ms

Mar 05 23:12:56 Docker-Host-1 systemd[1]: deconz.service: Unit entered failed state.
Mar 05 23:12:56 Docker-Host-1 systemd[1]: deconz.service: Failed with result 'exit-code'.

[Smanar]

Will try on my side, but need some time, you have the error on start ?

[Kllrv]

On a fresh install, it compiled and starts up properly after swapping the Conbee II to that VM.

Unfortunately the controls in Phoscon appear to do nothing, possibly due to an oversight on my part. Thus, I can't test whether the device connects properly now. I will attempt to add GUI to the VM during the weekend to have a look at it.

[Smanar]

Hu, it will be more complicated ^^
You are not using third app ?

The device is probably not visible in phoscon, and tuya cluster is not usable in the GUI.

You need to use third app or directly the API https://dresden-elektronik.github.io/deconz-rest-doc/getting_started/

If you have problem, I can give you curl command to test ?

[Kllrv]

Okay, I had time to take this further. Got the API calls working, what am I supposed to request from the server?

[Smanar]

For exemple with curl

curl -H 'Content-Type: application/json' -X PUT -d '{"open": true}' http://IP:PORT/api/KEY/lights/ID/state

IP and PORT : same than for phoscon
KEY is an api key
ID the device ID

To get an api key
curl http://IP:PORT/api/ -X POST -d '{"devicetype": "TestKey"}'

You have open = true/false, and lift= 0 to 100

[Kllrv]

requesting /lights/ID returns

{"etag":"e1fb00eb1b21059124536a16abc0e42e","hascolor":false,"lastannounced":"2021-03-06T13:11:59Z","lastseen":"2021-03-06T13:12Z","manufacturername":"_TZE200_zpzndjez","modelid":"TS0601","name":"Smart plug 18","state":{"alert":"none","bri":0,"lift":0,"on":false,"open":false,"reachable":true},"swversion":null,"type":"Window covering device","uniqueid":"84:71:27:ff:fe:a9:79:35-01"}

requesting /lights/ID/state returns

[{"error":{"address":"/lights/18/state","description":"resource, /lights/18/state, not available","type":3}}]

[Kllrv]

Oh nevermind, using CURL and not REST client made something happen. The motor started moving. [{"success":{"/lights/18/state/open":true}}]

[Kllrv]

I have tested
open = true/false - these spin in different directions
stop = true - stops the motor
lift = 0 .. 100 spins in one way, maybe motor should be calibrated - I was unable to guess commands for this

[Smanar]

Read the manual for calibration before, there is a command to trigger a zigbee calibration, but IDK what it do on the device. And I think you need to set it to false after.

curl -H 'Content-Type: application/json' -X PUT -d '{"calibration": true}' http://IP:PORT/api/KEY/lights/ID

To change side, it s possible with code, but try before (because the device have return state, and this one can be reversed too)

curl -H 'Content-Type: application/json' -X PUT -d '{"reverse": true}' http://IP:PORT/api/KEY/lights/ID

[Kllrv]

Unfortunately the manual is for the wifi version and only tells how to reverse motor direction or attach remote (also puts to zigbee pairing mode). I have however learned the device should auto calibrate during first run.

I was able to force auto calibration by long-pressing pairing key to reset position data, then starting the motor in each direction in sequence and stopping the motor shaft with pliers. This auto calibration happens the same whether motor is started by manually rotating it or giving zigbee signal.

Additional edit for accuracy, after testing multiple times:
Unplug device, plug it in, wait for light to stop flashing, then long press button to put it into calibration mode. Starting motion in either direction will test maximum movement in both directions.

Motor now responds to "lift": 1..100 as expected, and opens/closes to positions "calibrated" by stopping the motor.

[Smanar]

I was able to force auto calibration by long-pressing pairing key to reset position data, then starting the motor in each direction in sequence and stopping the motor shaft with pliers

You mean to calibrate the device, you have re-included it, and used it immediately ? I m realy interested by the method, lot of user ask for it.

Motor now responds to "lift": 1..100 as expected, and opens/closes to positions "calibrated" by stopping the motor.

So all is working ? no need to reserve a side or a return ?
To be sure you need to have in the JSON

shutter closed
on= true
bri = 255
open = false
lift = 100%

or ALL values reversed.

[Kllrv]

To reset calibration of the device, I simply long-pressed the include key. This should be enough, although a full reset will work for sure: like with pairing mode, one would triple-press and long press in sequence.

To reverse motor, it could be done with RF remote according to manual, or supposedly thru Zigbee command as described in zigbee2mqtt device info. https://www.zigbee2mqtt.io/devices/TS0601_cover.html

For '{"reverse": true}' I get "parameter, reverse, not available"

Where do I see this JSON info?

[Smanar]

To have the JSON just go http://IP:PORT/api/KEY/lights/ID

For the reverse it s the same command than for zigbee2mqtt, can you show the curl command you are using ? (no "state" inside)

[Kllrv]

{ "etag": "a46345e8d9b96af1c390161477dabb82", "hascolor": false, "lastannounced": "2021-03-06T13:11:59Z", "lastseen": "2021-03-06T14:29Z", "manufacturername": "_TZE200_zpzndjez", "modelid": "TS0601", "name": "Smart plug 18", "state": { "alert": "none", "bri": 254, "lift": 100, "on": true, "open": false, "reachable": true }, "swversion": "0xFFFFFFFF", "type": "Window covering device", "uniqueid": "84:71:27:ff:fe:a9:79:35-01" }

Something happened with the motor with this:

curl -H 'Content-Type: application/json' -X PUT -d '{"reverse": true}' http://ip/api/key/lights/18/

The open/close commands still move it the same way, but it reports reversed state.

{ "etag": "22953385545fd4583067f2c403473610", "hascolor": false, "lastannounced": "2021-03-06T13:11:59Z", "lastseen": "2021-03-06T14:40Z", "manufacturername": "_TZE200_zpzndjez", "modelid": "TS0601", "name": "Smart plug 18", "state": { "alert": "none", "bri": 248, "lift": 98, "on": true, "open": true, "reachable": true }, "swversion": "0xFFFFFFFF", "type": "Window covering device", "uniqueid": "84:71:27:ff:fe:a9:79:35-01" }

[Smanar]

Ha ?

I think you have find a new issue.

"lift": 98

For deconz if lift < 100 , the covering is not closed, It's because the covering is not full closed or because of the calibration ?
I think because of the calibration the min and max are different than 0 and 100 ?

The open/close commands still move it the same way

Are you sure the command have worked (because for me the difference in JSON is not from that) ? I don't think it change something, but try with removing the last "/"

[Kllrv]

It was by coincidence that the motor value changed. The motor moves a little bit back and forth when the reverse command is issued.

I'm now using Mozilla RESTClient extension to make it easier. All commands report success in response field.

commands, after which I checked for changes in the JSON:
PUT http://server/api/key/lights/18 { "reverse": false }

{
  "etag": "182cd29636a160c481fd63c6598a9703",
  "hascolor": false,
  "lastannounced": "2021-03-06T13:11:59Z",
  "lastseen": "2021-03-06T18:00Z",
  "manufacturername": "_TZE200_zpzndjez",
  "modelid": "TS0601",
  "name": "Smart plug 18",
  "state": {
    "alert": "none",
    "bri": 254,
    "lift": 100,
    "on": false,
    "open": true,
    "reachable": true
  },
  "swversion": "0xFFFFFFFF",
  "type": "Window covering device",
  "uniqueid": "84:71:27:ff:fe:a9:79:35-01"
}

PUT http://server/api/key/lights/18/status { "open": true }

{
  "etag": "7a443033d859e14d39b3f4ce530ad159",
  "hascolor": false,
  "lastannounced": "2021-03-06T13:11:59Z",
  "lastseen": "2021-03-06T18:03Z",
  "manufacturername": "_TZE200_zpzndjez",
  "modelid": "TS0601",
  "name": "Smart plug 18",
  "state": {
    "alert": "none",
    "bri": 254,
    "lift": 100,
    "on": false,
    "open": true,
    "reachable": true
  },
  "swversion": "0xFFFFFFFF",
  "type": "Window covering device",
  "uniqueid": "84:71:27:ff:fe:a9:79:35-01"
}

PUT http://server/api/key/lights/18 { "reverse": true }

{
  "etag": "16ccdbee5d7062ccdd1b0ea9181525f4",
  "hascolor": false,
  "lastannounced": "2021-03-06T13:11:59Z",
  "lastseen": "2021-03-06T18:03Z",
  "manufacturername": "_TZE200_zpzndjez",
  "modelid": "TS0601",
  "name": "Smart plug 18",
  "state": {
    "alert": "none",
    "bri": 254,
    "lift": 100,
    "on": true,
    "open": false,
    "reachable": true
  },
  "swversion": "0xFFFFFFFF",
  "type": "Window covering device",
  "uniqueid": "84:71:27:ff:fe:a9:79:35-01"
}

PUT http://server/api/key/lights/18/status { "open": true }

{
  "etag": "96e6b8bc9fcfc380382e7ac751da1e94",
  "hascolor": false,
  "lastannounced": "2021-03-06T13:11:59Z",
  "lastseen": "2021-03-06T18:03Z",
  "manufacturername": "_TZE200_zpzndjez",
  "modelid": "TS0601",
  "name": "Smart plug 18",
  "state": {
    "alert": "none",
    "bri": 254,
    "lift": 100,
    "on": false,
    "open": true,
    "reachable": true
  },
  "swversion": "0xFFFFFFFF",
  "type": "Window covering device",
  "uniqueid": "84:71:27:ff:fe:a9:79:35-01"
}

Note how the status was "not open" until issuing the open command. The motor didn't spin except for about a full rotation back and forth when attempting to apply reverse mode.

[Smanar]

So need some cycle to stabilise the "machine" ?

But I don't see difference for { "open": true } with "reverse" = true or false.
It s perfect for me, but can you see a difference on the hardware ?

[Kllrv]

I found the hardware didn't function in a different manner no matter the setting.

[Smanar]

Ok, I have found a problem in the "reverse" command, can you try with the new code.

cd deconz-rest-plugin
git pull
qmake && make
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

No need to re-include the device, just close deconz before changing file, adn restart it.

[Kllrv]

Tested multiple times, consistent results immediately after reaching position:
reverse = true - opens counter clockwise, closes clockwise. 0 when told to close. Lift 0 is closed, lift 100 is open.
reverse = false - opens counter clockwise, closes clockwise. 0 when told to close. Lift 0 is open, lift 100 is closed.

Issuing '{"open": true}' always moves to position 100, and '{"open": false}' always moves to position 0. These change the open status accordingly if motor was already in that position, overriding the reverse setting behavior. This state appears to fix itself without interaction. Not sure how that happened, unable to reproduce by waiting.

[Smanar]

So the "reverse" command now have an impact ?
It reverse the "lift" value (so I think all other values) but have no impact on working mode ?

But how you can reverse the motor side ? We can't switch wire on this device.
Nothing on the manual ? perhaps need to calibrate after reverse ?

Issuing '{"open": true}' always moves to position 100, and '{"open": false}' always moves to position 0

So if the "reverse" command switch lift position, it mean in a situation 100 is up and the other 100 is down ?

[Kllrv]

So if the "reverse" command switch lift position, it mean in a situation 100 is up and the other 100 is down ?

Yes, with current behavior this appears to be the case.

But how you can reverse the motor side ? We can't switch wire on this device.

Attaching double curtain to different sides of the rail. Single curtain, attaching it on the other side. Movement direction would then change. Because doing this is possible, reversing shouldn't be neccessary in a real world scenario so it may only exist for convenience, or because this might be shared firmware for roller curtains - those have a valid use case for a mirrored installation.

[Smanar]

Ha ok.

So it s device dependant, for your device, to reverse side, we need

• change the motor position
• use the command

so the motor still run in the same side, but the automation have the return reversed.

Thx a lot for the "reverse" issue, I realy have skipped this bug, can explain why there is so much user with side direction problem ....

And BTW, so your device works correctly finaly ? nothing to change ?

[Kllrv]

Didn't find any functional issues with the device last night.

Btw, when manually pulling the curtain (or rotating the motor without anything attached), it will move to either min or max point, and report the state change once the move completes.

[Smanar]

Btw, when manually pulling the curtain (or rotating the motor without anything attached), it will move to either min or max point, and report the state change once the move completes.

Nice feature for me, can make the motor move without using remote, just with moving a little the covering ?

Pr done

[imammedo]

@Smanar

Apparently I was not able to copy built plugin properly the first time
It seems to be working now i.e. it detects as window covering device.
Sorry for noise, I'll continue with testing it.

[imammedo]

Confirming Kllrv finding about 'reserse' command has no effect.
Also his method to put motor in calibration mode (1 long press) also worked for me.
(However one can reverse motor by pressing button on it, 2 short 1 long press, did the trick.
Well for this particular motor, for the second it didn't work but I managed to reverse it using around 6 seemingly short presses, so this needs some more experimentation).

[Kllrv]

To reverse direction with motor button, one short press and one long press did it for me. Works the same as the command, as described above.

[Smanar]

Confirming Kllrv finding about 'reserse' command has no effect.

Can you share logs ("info") when using the command, with the last code.

And BTW I have find why it can be hard to include the device some time >Smanar@31eb4b6

[Kllrv]

Can you share logs ("info") when using the command, with the last code.

Unable to compile the changes I pulled just now:

{standard input}: Assembler messages:
{standard input}:101184: Warning: end of file not at end of a line; newline inserted
{standard input}:102846: Error: unknown pseudo-op: `.lls'
{standard input}:102845: Error: invalid operands (*UND* and *UND* sections) for `-'
g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.

[Smanar]

Just now ? you are trying wich one branch ? The tuya_14 ? or the DS82 ?

[Kllrv]

DS82. Did you want me to try the other one?

[Smanar]

Depend if the device is reconized or not ?
If the device is not reconized I need to make a branch with both mixed for you (the tuya_14 improve reconization, but not support DS82)

[Kllrv]

In the DeconZ UI, it's appearing as the wrong device type - but otherwise functions as expected through API. Not sure if this would be fixed by removing and re-adding, not eager to break a working setup right now.

[imammedo]

cherry-picked 31eb4b6 into DS28 branch,

• It seems that it finds motor from the first time (tried 3 times).
  In web gui it appears as light and named as 'smart plug' (as it is without that commit), query via REST API returns Window covering.
• 'reverse' command does have effect but only in one direction, more precisely motor does about a turn back&forward 'and' direction reverts to the factory default, regardless of true/false value or how many times I repeat command
  • PS: 'reverse' didn't have 'any' effect on new motor, only after I did manual reverse it started to react.
• 5 short, 1 long (till constant light comes up) presses on button toggles direction on both of my motors

Can you share logs ("info") when using the command, with the last code

I captured log, what I should grep from it of interest?

[Smanar]

* It seems that it finds motor from the first time (tried 3 times).

So perhpas a solution ...

  In web gui it appears as light and named as 'smart plug' (as it is without that commit), query via REST API returns Window covering.

Yep, this is normal, the device present itself as a smart plug, but I can cheat for the API

* 'reverse' command does have effect but only in one direction, more precisely motor does about a turn back&forward 'and' direction reverts to the factory default, regardless of true/false value or how many times I repeat command
  
  * PS: 'reverse' didn't have 'any' effect on new motor, only after I did manual reverse it started to react.

I don't know exactly how work the reverse command, I just mimic the command send by the gateway, the last users that have tested it have said it NOT change the motor direction, but the state return when it reach a position.

I captured log, what I should grep from it of interest?

Yep the log starting by "tuya debug" when you have do the reverse command pls.

[imammedo]

I don't know exactly how work the reverse command, I just mimic the command send by the gateway, the last users that have tested it have said it NOT change the motor direction, but the state return when it reach a position.

Given reverse now works in only in one direction (CCW), maybe there is another command for an opposite direction (CW)?

Is command sent via tuya cluster?
If you give me a list of parameters for that to try, I can use deconz gui to send it (it should be faster than modifying code)

Log for reverse:
https://paste.mozilla.org/XA2LAsts

[Smanar]

I can't see the command to reverse device. Can you show the rest API command you have used ? The error handling is not perfect, so you can have a success message but without the command working

Yes it use the tuya cluster, but tuya command are not standard, you can't use the GUI for that, but If you change the side manualy on the device it s possible seing the command on deconz log (not working for all command)

13:27:39:478 Tuya debug 5 : Status: 0 Transid: 130 Dp: 515 (0x02,0x03) Fn: 0 Data 100

This is for command received, but you have too send request

The command to change side is (0x04 0x05)

[imammedo]

tested { "reverse": true } again:

:false
14:54:03:691 Send Tuya request: Dp_type: 0x04, Dp_identifier 0x05, data: 0000 14:54:03:692 add task 1496 type 41 to 0x847127FFFEA84C6A cluster 0xEF00 req.id 17 14:54:07:116 poll node 84:71:27:ff:fe:a8:4c:6a-01 14:54:08:667 0x847127FFFEA84C6A error APSDE-DATA.confirm: 0xA7 on task 14:54:24:804 poll node 84:71:27:ff:fe:a8:4c:6a-01
:true
14:54:41:099 node 0847127FFFEA84C6A leave wait state 14:54:44:117 poll node 84:71:27:ff:fe:a8:4c:6a-01 14:54:45:518 Send Tuya request: Dp_type: 0x04, Dp_identifier 0x05, data: 0001 14:54:45:519 add task 1690 type 41 to 0x847127FFFEA84C6A cluster 0xEF00 req.id 29 14:54:50:339 0x847127FFFEA84C6A error APSDE-DATA.confirm: 0xA7 on task

after manual (using button on motor) reverse:
logs have:
15:00:04:193 poll node 84:71:27:ff:fe:a8:4c:6a-01 15:00:20:886 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009b0704000100 15:00:20:887 Tuya debug 5 : Status: 0 Transid: 155 Dp: 1031 (0x04,0x07) Fn: 0 Data 0 15:00:21:094 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009b0704000100 15:00:21:096 Tuya debug 5 : Status: 0 Transid: 155 Dp: 1031 (0x04,0x07) Fn: 0 Data 0 15:00:21:296 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009b0704000100 15:00:21:298 Tuya debug 5 : Status: 0 Transid: 155 Dp: 1031 (0x04,0x07) Fn: 0 Data 0 15:00:21:499 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009b0704000100 15:00:21:499 Tuya debug 5 : Status: 0 Transid: 155 Dp: 1031 (0x04,0x07) Fn: 0 Data 0 15:00:21:699 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009b0704000100 15:00:21:701 Tuya debug 5 : Status: 0 Transid: 155 Dp: 1031 (0x04,0x07) Fn: 0 Data 0 15:00:22:108 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009c0302000400000020 15:00:22:109 Tuya debug 5 : Status: 0 Transid: 156 Dp: 515 (0x02,0x03) Fn: 0 Data 32 15:00:22:119 Websocket 127.0.0.1:51404 send message: {"e":"changed","id":"31","r":"lights","state":{"alert":null,"bri":81,"lift":32,"on":true,"open":true,"reachable":true},"t":"event","uniqueid":"84:71:27:ff:fe:a8:4c:6a-01"} (ret = 171) 15:00:22:312 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009c0302000400000020 15:00:22:313 Tuya debug 5 : Status: 0 Transid: 156 Dp: 515 (0x02,0x03) Fn: 0 Data 32 15:00:22:514 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009c0302000400000020 15:00:22:516 Tuya debug 5 : Status: 0 Transid: 156 Dp: 515 (0x02,0x03) Fn: 0 Data 32 15:00:22:717 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009c0302000400000020 15:00:22:718 Tuya debug 5 : Status: 0 Transid: 156 Dp: 515 (0x02,0x03) Fn: 0 Data 32 15:00:22:921 Tuya debug 4 : Address 0x847127FFFEA84C6A Payload 009c0302000400000020 15:00:22:921 Tuya debug 5 : Status: 0 Transid: 156 Dp: 515 (0x02,0x03) Fn: 0 Data 32

[imammedo]

If I send command to tuya cluster using deconz gui { Dp: 0x405 the rest fields are zeros } it does change direction to opposite of REST reverse command and there is no record about it in logs (how I can enable logging of what is send via deconz GUI).

Seemingly it looks like the command that 'reverse' command also sends but it sets opposite direction, which is strange
(/me went away looking for deconz usb stick to use as sniffer)

[Smanar]

I m think im wrong again in the request, I need to send "00" and "01" not "0000" and "0001".
If you can test it ?

        QByteArray direction = QByteArray("\x00\x00", 2);
        if (map["reverse"].toBool())
        {
            direction = QByteArray("\x00\x01", 2);
        }

replaced in

        QByteArray direction = QByteArray("\x00", 1);
        if (map["reverse"].toBool())
        {
            direction = QByteArray("\x01", 1);
        }

If I m right when you do the request, the device need to answer with same command (I think)

[imammedo]

I m think im wrong again in the request, I need to send "00" and "01" not "0000" and "0001".
If you can test it ?

        QByteArray direction = QByteArray("\x00\x00", 2);
        if (map["reverse"].toBool())
        {
            direction = QByteArray("\x00\x01", 2);
        }

replaced in

        QByteArray direction = QByteArray("\x00", 1);
        if (map["reverse"].toBool())
        {
            direction = QByteArray("\x01", 1);
        }

If I m right when you do the request, the device need to answer with same command (I think)

It works as expected with this change.

[Smanar]

It works as expected with this change.

Arf, IDK what I have missed that, thx, I will correct the PR immediatly.

[Smanar]

Hello, for users that have the _TZE200_zpzndjez
You haven't directions issues ? button disabled in third app ? Or have usd the "reverse" command ?

[Smanar]

@Kllrv or @imammedo you had problem with direction nope ?

[Kllrv]

@Kllrv or @imammedo you had problem with direction nope ?

Finally, I had time to test. Current live code works 100%. Of course, would be useful to have the reverse direction command available in the GUI.

[Smanar]

Not possible, the tuya cluster have a special "synthax" not compatible with deconz core.
But you can using the API.

And since the last message (22 days ago) the code have moved ^^

[shlomki]

Hi @Smanar ,
I'm running deconz v2.12.1 and I'm still seeing this device as a Smart Plug instead of a cover device.
Is this normal?

Yep, this is normal, the device present itself as a smart plug, but I can cheat for the API

I've read the entire thread and you said here that it's normal, but I couldn't understand if that was solved already or not.
As far as I understand, your PR should already be included in this release. Can you please advise how to solve this?

[Smanar]

Yep, except I have made a mistake, on the actual code all tuya covering have a new type "Window covering device"

[shlomki]

@Smanar Sorry, not sure I understand, so there's no hope of seeing it appear as a cover device in the phoscon UI and in apps such as home assistant?

[Smanar]

_TZE200_zpzndjez need to appear as cover in third app (like HA), because it s modified in the API
Still a plug in deconz application (normal, deconz show the reality)
Phoscon don't support covering yet.