Tuya TS0601 - Window covering device - Manufacturer _TZE200_rddyvrci - wrong directions

[raoulx24]

Describe the bug

The values for open and close seems to be reversed for Tuya TS0601 - Manufacturer _TZE200_rddyvrci

Steps to reproduce the behavior

I compared the outputs for Fyrtur and this (TS0601) and, although they are both open (up), they look different in in api

IKEA Fyrtur:
/api//lights/41

{
    "etag": "[...]",
    "hascolor": false,
    "lastannounced": "2021-04-08T15:45:10Z",
    "lastseen": "2021-08-22T12:17Z",
    "manufacturername": "IKEA of Sweden",
    "modelid": "FYRTUR block-out roller blind",
    "name": "Bedroom Roller Left",
    "state": {
        "bri": 0,
        "lift": 0,
        "on": false,
        "open": true,
        "reachable": true
    },
    "swversion": "2.2.009",
    "type": "Window covering device",
    "uniqueid": "[...]"
}

Tuya TS0601
/api//lights/48

{
    "etag": "[...]",
    "hascolor": false,
    "lastannounced": "2021-08-16T07:52:03Z",
    "lastseen": "2021-08-20T22:40Z",
    "manufacturername": "_TZE200_rddyvrci",
    "modelid": "TS0601",
    "name": "Smart plug 48",
    "state": {
        "alert": "none",
        "bri": 254,
        "lift": 100,
        "on": true,
        "open": false,
        "reachable": true
    },
    "swversion": null,
    "type": "Window covering device",
    "uniqueid": "[...]"
}

Because of this, I think, in homeassistant, the behavior is a bit strange, similar to the comment
Koenkk/zigbee2mqtt#5596 (comment)

The stange behaviour is that the buttons in HA are working differently:
HA Lovelace Button <-> Blind Operation
Up <-> STOP
Stop <-> DOWN
Down <-> UP

The buttons on the device are working as expected.

I also tried to reverse the direction, as stated in
#3348 (comment)

Expected behavior

The API output to be consistent with IKEA Fyrtur

Screenshots

Environment

• Host system: PC
• Running method: Marthoc Docker container
• Firmware version: 26390500
• deCONZ version: 2.11.05 (image tag: stable - latest one)
• Device: ConBee I
• Do you use an USB extension cable: yes
• Is there any other USB or serial devices connected to the host system? If so: Which? Aeotec Z-Stick Gen5

deCONZ Logs

Additional context

[raoulx24]

Addition to the req/additional info:

If I execute
PUT http://deconz.home/api//lights/48/state
with Body

{
    "stop": true
}

it will start to go down, exactly as in Koenkk/zigbee2mqtt#5596 (comment)

I didn't take a look on what was committed for the fix (considering that the manufacturer code is the same), but I think there it is the solution.

LE removed the token :-)

[Smanar]

Hello, for memory #5049

Do you have a linux machine with full OS to test code modification ?
The reverse command haven't worked ?

Up <-> STOP
Stop <-> DOWN
Down <-> UP

The other command are reversed too ?

[raoulx24]

Thanks for the prompt answer :-)

The reverse command didn't work. What is more puzzling is that all of them seem to be mixed. As stated in the prev comment, if I issue a stop command (in REST API), it will start to go down.

Now I double checked the behavior, and it is like this:
HA buttons - device action
Up - Up
Stop - Down
Down - Stop
My appologies for the wrong description.

Regarding the spare machine, I think I can grab one and use a Conbee II USB (which I recently bought in order to do an upgrade). If you think it is safe to use the stick (and then to use it on a different install) I can give it a try.

[Smanar]

Regarding the spare machine, I think I can grab one and use a Conbee II USB (which I recently bought in order to do an upgrade). If you think it is safe to use the stick (and then to use it on a different install) I can give it a try.

No problem, the device configuration is stored on the host, and the network config is stored on the conbee.
If you plug the conbee on a new host, you will see strange result (in deconz device wiill have "0xXXXX" as name), but it s not a problem.
You can use the backup / restore feature in phoscon to migrate your database, but less dangerous you can too just re-include the covering on the new host (so in the new database).

Just don't touch the network config on the second host. And replug the conbee on the dev machine after tests (Xiaomi devices don't like to be without parent too much long time)

You have the procedure here https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Compiling-the-REST-plugin-for-device-specific-testing
So for you, after having installed deconz :

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

This code is just a test (it s based on more recent deconz version) It will not impact yet the return state, so just try commands open/close/stop, to see if the command is corrected

[raoulx24]

Sorry, I am stuck.

I tried to start the deconz using headless procedure, but then I remembered that I also need the GUI (reachable in docker using VNC), in order to do the 'double inclusion' for this specific device (added as a sensor, then reopen the network and read Basic attributes). So I tried to copy the libde_rest_plugin.so file in the container, but it doesn't like it.

Side question: the libde_rest_plugin.so should work also on stable version, or is it mandatory the dev version. I am asking this because it seems that if I add it in the stable container, it doesn't work (API calls returns a lot of 404). Just if you know what can be the problem.

BTW, for the record and maybe for someone else need, qmake did not work, I had to run also

sudo apt-get install build-essential

SO Ubuntu 20.04 Server LTS

LE I will install an Ubuntu desktop on the machine and proceed with the tests. But this, tomorrow.

[Smanar]

You can too use phoscon, make "add new device" and make 2 time the inclusions. It s more random, but it work.

The code is based on last version, so for the moment it s the stable one, but It don't have impact, better to use beta branch to be sure having the last one.

It's more complicated if you use docker, you have a special procedure for them on the previous link.

[raoulx24]

Is there a different procedure to add AM43 to deconz with conbee2? I have 6 of them, all of them added to 'production' deconz with conbee1.

I did the following: installed clean Ubuntu Desktop 20.04, installed deconz from stable repo, started deconz-gui (ensured that deconz.service is disbled and stopped). I see the coordinator. In phoscon, after password creation. We have a 'testing' deconz with conbee2. I was also able to add it in Home Assistant. So far, so good.

I went to Sensors, add, reset one AM43 (by pressing control and down buttons 3 secs), it appeared in deconz app, quickly pressed Read attributes in Basic Cluster. In phoscon appeared 'Device ready' (or something). So far, so good (again).

And now, the pain starts. I tried second inclusion, by various methods

• Sensors, Add, reset AM43 (by pressing control and down buttons 3 secs), Device ready in phoscon - no new light appeared
• Lights, Add, reset AM43, no luck after 3 mins - no new light appeared
• Sensors, Add, reset AM43 and quickly reading some Attributes from various clusters - no new light appeared
• removed the node in deconz app, repeat all above steps

This is a shorter story, the longer one includes a Ubuntu install reset, and first a test with decon from dev repo with your .so compiled; because I thought the inclusion might not work because I do not know what bug in dev, I reinstalled the machine, but to no avail.

So, please, can someone tell me which is the procedure to add AM43 to conbee2 also as light (beside battery sensor)? :-)

[Smanar]

So it works better for conbee 1 than for conbee 2 ?

A tips, the inclusion create a "sensor" ZHAbattery entry, and it s this sensor that is used to create the "light" entry.
So you can take a look on logs during the inclusion (with "info" and "info_l2"), to check for the ZHAbattery creation, you realy need this one first.

What is your dev/beta/stable version you are using for your tests.

If you share a log during the inclusion, I can perhaps say to you where it block

[raoulx24]

I am, for time being, on stable channel/version.

I can share the logs, but I do not know what kind of sensitive data there is there. For instance, I found info about my Sonos devices and the other deconz (UPNP broadcasts)

The only two [INFO] and {WARNINGS] are

00:49:17:726 [WARNING] - Missing cluster in sensor fingerprint: 0xCC86ECFFFEBD30FA - 0xF44F (TS0601), endpoint: 0x01, cluster: 0x000A, payloa>
00:49:17:728 [INFO] - No button map for: TS0601, unicast to: 0x0000, endpoint: 0x01, cluster: 0x000A, command: 0x00, payload: 0700, zclSeq: 93

How do you want the logs (but tomorrow, it is kinda of late here :-) )?

[Smanar]

If you use only "info" and "info_l2", I don't think you will have sensible information.

Can use site like pastebin, some of them can be protected and removed, but you can find so much deconz log, there is no password printed for exemple.

You can too take a look yourself, for sensor you will see in log a coutdown like [X.Y] in debug line

[raoulx24]

I tried to read the logs, but I could not find anything interesting on why it doesn't create the light.

Anyway, here it is the log (clean startup, adding twice the sensor):
https://pastebin.com/03bciqcZ

I surely hope that you will find the issue :-)

[Smanar]

For logs, pls use only "info" and "info_l2" as flag, logs will be lighters.

So the battery sensor seem added

{
  "e": "added",
  "id": "2",
  "r": "sensors",
  "sensor": {
    "config": {
      "on": true,
      "reachable": true
    },
    "ep": 1,
    "etag": "09ffaa23d76c41830bba8d77dfd7d6ae",
    "id": "2",
    "lastannounced": null,
    "lastseen": "2021-08-26T18:34Z",
    "manufacturername": "_TZE200_rddyvrci",
    "modelid": "TS0601",
    "name": "Battery 2",
    "state": {
      "battery": null,
      "lastupdated": "none"
    },
    "type": "ZHABattery",
    "uniqueid": "cc:86:ec:ff:fe:bd:30:fa-01-ef00"
  },
  "t": "event",
  "uniqueid": "cc:86:ec:ff:fe:bd:30:fa-01-ef00"
}

But the "light" entry creation is only trigger 1 time, and before the ZHABattery is created, so it can't work.

21:34:33:907 ZDP Simple_Descriptor_rsp 0xCC86ECFFFEBD30FA - 0x8AD7
21:34:33:911 Tuya debug 7 : Missing manufacture name for 0xcc86ecfffebd30fa
21:34:33:912 Tuya debug 7 : Missing manufacture name, till missing in DB.

In fact you need to have thoses lines, but with the zhabattery sensor already in the database, so deconz will reconize it using this entry.
And no more tries for this one .....

Can you just

• set phoscon in permit join "add new light"
• read the simple descriptor

To trigger the same output (but with the ZHABattery already in the dataabse)

[raoulx24]

So... No luck. I really do not get it. I even readd the device (with node removed before) in 'production' deconz - conbee1 and it work instantly. I mean, I removed the old node, add new sensor, read Basic attributes and the 'light' appeared instantly.

Later on, I will try with the conbee1 usb stick on the 'test' machine to test your fix and then we will see...

[Smanar]

I have a smilar issue on another device.

So it work on deconz 2.11, but not on my recent modification ?

Have done a special version with more debug, can you try this one ?

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

And share logs during the inclusion with "info" and "info_l2" only ?

[raoulx24]

I somehow managed to add it. I did the following (but now I am 'afraid' to try it once more): I added it as sensor in phoscon, removed node from deconz, added as light.

The only caveat is that I did all the tests (since Wednesday) using docker. Now I am investigating how to proceed further more: either by creating a custom docker from your repo, either to install deconz 'normally' (by apt) and use the files config.ini,
zcldb.txt and zll.db - to copy them from persisted ones from docker volume to /root/.local/share/dresden-elektronik/deCONZ

Sorry for asking, you keep on asking to put level INFO on logging, but the documentation is quite scarce regarding this and I do not know how to do it. What I could find is this:

#55 (comment)

So, instead of --dbg-info=2 --dbg-zdp=1 --dbg-zcl=1 --db-aps=1 --dbg-http=1 what should I put?

Side comment: after I will test your fix, and close this issue, I will try to see if the workaround found by me (how to add AM43 in deconz with conbee2) is consistent. If it is, I think that there is a race condition on initial inclusion of the device. But this is a totally different topic.

[Smanar]

There is special procedure if you use docker https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Compiling-the-REST-plugin-for-device-specific-testing

It s not the same working mode at all. my command are for classic installation only.

[raoulx24]

Update: tested with your .so, on normal apt install (deconz headless). The Stop is now working, the buttons are reversed; so they are not mixed up anymore, just up si doing down and down - up. I also tried PUT api/token/lights/is with body { "reverse": true } - same effect.

The device is reset to factory defaults, so no reverse from its internal settings (from its instructions, you can change directions by pressing up and down at the same time for three seconds - I did not do that)

[Smanar]

I also tried PUT api/token/lights/is with body { "reverse": true } - same effect.

This device use probably other command for that too, or don't support it if it s possible manualy

Have updated the code again, I think now alll will be fine

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

[raoulx24]

You are a real magician :-) The buttons now work as expected. Thank you :-)

The only issue that remains is that the position and states are reversed compared to Fyrtur.

Fyrtur - open - all the way up

{
    "etag": "[...]",
    "hascolor": false,
    "lastannounced": "2021-04-08T15:45:10Z",
    "lastseen": "2021-08-29T09:16Z",
    "manufacturername": "IKEA of Sweden",
    "modelid": "FYRTUR block-out roller blind",
    "name": "Bedroom Roller Left",
    "state": {
        "bri": 0,
        "lift": 0,
        "on": false,
        "open": true,
        "reachable": true
    },
    "swversion": "2.2.009",
    "type": "Window covering device",
    "uniqueid": "[...]"
}

AM43 - open - all the way up

{
    "etag": "[...]",
    "hascolor": false,
    "lastannounced": "2021-08-29T09:08:27Z",
    "lastseen": "2021-08-29T09:22Z",
    "manufacturername": "_TZE200_rddyvrci",
    "modelid": "TS0601",
    "name": "Smart plug 2",
    "state": {
        "alert": "none",
        "bri": 254,
        "lift": 100,
        "on": true,
        "open": false,
        "reachable": true
    },
    "swversion": null,
    "type": "Window covering device",
    "uniqueid": "[...]"
}

Because of this, the buttons in HomeAssistant are not usable, unless it is in a middle position. For example, for the actual situation, when the roller is all the way up, only the Up and Stop buttons are enabled.

[Smanar]

Ok so new test (same command than before to update the code)

I m using a hack for the badly commad used by the device (used with the command open=true/false, and have reverted the return for the command lift=X)

If you can try both commands ?

[raoulx24]

i have several compile errors. First one is
tuya.cpp:422:100: error: no match for ‘operator||’ (operand types are ‘QLatin1String’ and ‘bool’)

[Smanar]

Corrected, it compile now.

[raoulx24]

I can confirm that also state is ok. Great job, thank you :-)

There is still one issue: PUT 192.168.75.10/api/[api_key]/lights/2/state with body

{
    "lift": 20
}

will, in fact, be set as 80

{
    "etag": "[...]",
    "hascolor": false,
    "lastannounced": "2021-08-29T09:08:27Z",
    "lastseen": "2021-08-29T14:07Z",
    "manufacturername": "_TZE200_rddyvrci",
    "modelid": "TS0601",
    "name": "Smart plug 2",
    "state": {
        "alert": "none",
        "bri": 203,
        "lift": 80,
        "on": true,
        "open": true,
        "reachable": true
    },
    "swversion": null,
    "type": "Window covering device",
    "uniqueid": "[...]"
}

[Smanar]

Changed again, I think now it will be fine, but I m not sure reversing the side by defaut is a good idea, on Z2m they are not reversing the device, only correcting bad values.

[raoulx24]

I can confirm that everything is working super. As I said, true magician :-)

What next? How will this fix be incorporated in the versions? Will it be an fix on current stable version 2.12 or do I have to wait for the next one (2.13)?

Thank you again :-)

[Smanar]

The PR is done, now it s in (the long) waiting list.
We have just a stable, so I thnk it will be in next beta.

[raoulx24]

I have tested also the reversing done on the device (from its instructions, you can change directions by pressing up and down at the same time for three seconds) and it is working as it should.

I created a custom container that incorporates your fixes for my 'production' usage and it also works.

So, thank you again for all your support. Take care :-)

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.