Tuya Cover - Using wrong logic for reporting "Current Position Lift Percentage"

[cobirnm]

Describe the bug

I have several tuya cover switch. It seems that the implementaiton of tuya cover devices is reporting the attribute 0x0008 "Current Position Lift Percentage" using the scale "% open". It seems that Deconz uses for most of it's cover the scale "% close".
A great job has been done implementing these tuya devices (cover was added in ##3134)
I spooted this issue in Home assistant in home-assistant/core#40627

Steps to reproduce the behavior

Expected behavior

@Smanar do you thing that the Deconz logic for "Current Position Lift Percentage" could be applied for tuya covers? I mean start using the scale "% closed".
This could be done by applying something in the code like "Current Position Lift Percentage" =100-(Present Current Position Lift Percentage)

Both me and @Kane610 have made extensive testing on this under #home-assistant/core#40627

In this post ##1121 (comment) @ebaauw explains the logic behind this.

Do you think it's possible to fix it?
Thank you in advance

Screenshots

Environment

• Host system: (Raspberry Pi / PC / NAS)
• Running method: (Raspbian / Ubuntu / Home Assistent deCONZ Add-on / Marthoc Docker container / Windows / Virtual Machine)
• Firmware version: (26xxyy00)
• deCONZ version: (2.xx.yy)
• Device: (ConBee I / ConBee II / RaspBee I / RaspBee II)
• Do you use an USB extension cable: (yes / no) -- only relevant for ConBee I/II
• Is there any other USB or serial devices connected to the host system? If so: Which?

deCONZ Logs

Additional context

[Smanar]

do you thing that the Deconz logic for "Current Position Lift Percentage" could be applied for tuya covers? I mean start using the scale "% closed".

It couldn't, it need, ebaauw logic is now a rule ^^.

But the rule is for exemple

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

And from your log (from the other issue) you have

{"bri":254,"lift":100,"on":true,"open":false,"reachable":true},"t":"event","uniqueid":"ec:1b:bd:ff:fe:32:f7:18-01"}
{"bri":0,"lift":0,"on":false,"open":true,"reachable":true},"t":"event","uniqueid":"ec:1b:bd:ff:fe:32:f7:18-01"}

So all seem fine ? Or I have look at bad device ?
lift = 0 for open device (or 0% closed)
lift = 100 for closed device ( so 100% percent closure)

[cobirnm]

What I have is the other way round:

100 is fully open
0 is fully closed

[cobirnm]

Just to be clear When I have this in deconz the cover is actually fully open:

If I execute the command in deconz to open the cover it goes to 100% as in the picture above.

The described behavior is consistent with the buttons of the cover (meaing if I use the open button the cover goes to 100% and if I use the close button the cover goes to 0%)

To close it's the other way round (0%) (idon't have a picture right now).

For me this logic was right until I found out of the rule in Deconz! (% closed) This was the reason I created an issue in Home Assistant since these were my first zigbee cover devices!

[Smanar]

Yep, but values you are seing in deconz are not the values gived by the api. HA don't use values from deconz but values from the API.

Do you have a json returned by deconz with bad values, or good values but the covering device in bad state ?

Have you for exemple the covering open but lift= 100 in the json ?

[cobirnm]

when I execute Up/open I get the following: (cover fully open)

{"e":"changed","id":"17","r":"lights","state":{"bri":254,"lift":100,"on":true,"open":false,"reachable":true},"t":"event","uniqueid":"ec:1b:bd:ff:fe:32:f7:18-01"}

When executing down/Close: (cover fully closed)

{"e":"changed","id":"17","r":"lights","state":{"bri":0,"lift":0,"on":false,"open":true,"reachable":true},"t":"event","uniqueid":"ec:1b:bd:ff:fe:32:f7:18-01"}

Please note that just to be sure I executed the Up and down actions from deconz and the output is in {} is what I get in pydeconz (home assistant component)

[Smanar]

So there is a problem yes.
Your model id is "TS130F" ? There is no hack for this one, so it s realy the pure zigbee protocol.
Are you sure the problem is not from the setting, remember you have a command to reserve the side, or just the wiring, have you tried to reverse the brown and the black wire ?

[cobirnm]

Yes my model is TS130F.
I have been playing with the reverse command. When I set it for the first 2 times the cover moves it works as it should. Then I loose the calibration and everything goes back to the starting point...

So my findings are:

1. trun on motor reversal
   the buttons on the switch do not reverse (they stay the same)
   the position in deconz is correct (before was 100, after is zero)
   The position on Home assistant is correct.

2. move the cover down executing down command. (to fully closed)
   the cover goes down
   the position reports 100 (this is ok) (in deconz)

3. move the cover up
   the cover opens fully
   the position reports 0 (this is ok) (in deconz)

4. move the cover down (in deconz)
   the cover goes down by more or less 30 % and reports 0 (it looks line it makes some kind of reset on the switch)

5. move up ( deconz)
   If goes up and shows 100%

6. move down
   Again it does not go down (not calibrated) and shows 0%

P.S. I have tried also using tuya hub for setting the reversal and calibration. When I re-add the switch to deconz there is no difference in the reposting of the position. Regarding the wiring if I reverse it the open button will close the cover and the close button will open the cover.
I have also tested in tuya app and even selecting the motor reversal it does not change the open and close command and also the phisical buttons.

Is it possible to correct the position in the code by adding some kind of combination of manufacture/moddel? I have 3 of these switches and they all behave like this

[cobirnm]

I know I'm always insisting with this issue but can't we have something like we already have in window_covering.cpp for Xiaomi (please note that I'm not a coder)

                // Reverse value for Xiaomi curtain 
                if (lightNode->modelId().startsWith(QLatin1String("lumi.curtain")) || 
                   (lightNode->modelId() == QLatin1String("Motor Controller")) )
                {
                    lift = 100 - lift;
                }

[Smanar]

Yep it s possible but we realy need to be sure the device is realy reversed, else it break the configuration on other device

I have been playing with the reverse command. When I set it for the first 2 times the cover moves it works as it should. Then I loose the calibration and everything goes back to the starting point

Ok, nice issue, and it don't happen when you use the original gateway ?

I have tried also using tuya hub for setting the reversal and calibration. When I re-add the switch to deconz there is no difference in the reposting of the position.

This is normal, the setting are reset when you change the gateway

Regarding the wiring if I reverse it the open button will close the cover and the close button will open the cover.

Ok so not the wiring.

Can try this code

sudo apt install deconz-dev
git clone --branch tuya_cov 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

[cobirnm]

Ok, nice issue, and it don't happen when you use the original gateway ?

No it does not happen with the original gateway

This is normal, the setting are reset when you change the gateway

That is not really true. The settings that I make using the tuya gateway stay in the device when I pair it with deconz. Originaly I used this to calibrate the device and then use it with deconz.

Can try this code

I will try the code but noobie question: How can I unistall it after testing?

[cobirnm]

I get an error when compiling:

rest_lights.cpp: In member function ‘int DeRestPluginPrivate::setWindowCoveringS                       tate(const ApiRequest&, ApiResponse&, TaskItem&, QVariantMap&)’:
rest_lights.cpp:1710:32: error: expected unqualified-id before ‘->’ token
            (taskRef.lightNode->->manufacturer() == QLatin1String("_TZ3000_egq7y                       6pr")) ||
                                ^~
Makefile.Release:1058: recipe for target 'release/rest_lights.o' failed
make[1]: *** [release/rest_lights.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/pi/deconz-rest-plugin'
Makefile:38: recipe for target 'release' failed
make: *** [release] Error 2

[Smanar]

Corrected, sorry typo

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

[cobirnm]

First of all sorry for the late reply. I had to learn how to install all of this! (I did manage to install the dev on docker container!)

Your code works like a charm! Now everything is working as it should with standard home assistant deconz integration!
Do you think the can go to the next release of Deconz, or should it be tested by someone else? I can see that it's model specific so there should not be a problem!

[Smanar]

Bad luck, the last date for PR was today, sorry.
I will make the PR now, but it will be surely in next version, the Beta in 15 days now.

And yes It s model specific, so I don't think we need to wait for another return.