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.

[cobirnm]

I will skip next release until this PR is released!
I can only thank you for all your hard work!

[Smanar]

Lol, you do more work than me.
It make more work to test the code for you than editing it for me.

[axellebot]

I don't know where to ask this. Is there a way to edit the travel time of the TS130F cover?

[Smanar]

It s a device without level check that use timed move to simulated a set level command ?
You have nothing for calibration ?

[axellebot]

From what I know it's possible to setup time travel through the official (tuya/zemismart/whatever) App. But I don't wanna buy a gateway to set it up. Looks like there is attributes for this purpose but only readable according to deconz (and some time not even readable) :/

[Smanar]

Your device use tuya cluster or covering cluster ?

[cobirnm]

You need to edit geral.xml to make te attribute RW (read and right). In a couple of hours I can give you the details (I need to be on a computer)

[axellebot]

Putting info here :

From map :

From Basic section :

From Windows covering section :

You need to edit geral.xml to make te attribute RW (read and right). In a couple of hours I can give you the details (I need to be on a computer)

FYI : I added the device with HA Zigbee integration and not with Deconz plugin.

[Smanar]

Take a look in the cluster 0x0102, you will find "calibration", but he is right on some version this line is read only.

[cobirnm]

@axellebot What you are looking for is attribute 0xF001. If in the access colunm you have RW as in the picture below you are good to go.

If you don't have RW then you need to edit general.xml file as in the code: (change on line 3 bellow from access="r" to access="rw".

        </attribute-set>
        <attribute-set id="0xf001" description="Tuya Window Covering Setting">
          <attribute id="0xf001" name="Calibration" type="enum8" default="0" required="m" access="rw">
            <value name="Start" value="0"></value>
            <value name="End" value="1"></value>
          </attribute>
          <attribute id="0xf002" name="Motor Reversal" type="enum8" default="0" required="m" access="rw">
            <value name="Off" value="0"></value>
            <value name="On" value="1"></value>
          </attribute>
        </attribute-set>

Now for calibration:

1. under deconz double click the 0xF001 and select "start" from the dropdown list and press "write" button
   Now your cover should enter in calibration mode
   

2. on the cover switch press the button to fully open the cover (on my stwich it's the left button)

3. when the cover is fully open press the "stop" button (on my switch it's the midle button)

4. press the close button and wait for the cover to fully close (on my switch it's right button)

5. As soon as the cover is fully closed press the "stop" button

6. Go to deconz and change from "start" to "end" and press "write" button
   

That's it , your cover should be calibrated and ready to use!

P.S. I have noticed that my covers some times do not open fully. This happens after setting different positions (20%, 35%, 80%....). To solve this I fully close the cover and then the positions are correct again!

[TimSoethout]

Maybe this is not the place, but is it possible to change general.xml in the "hosted" deconz on Home Assistant Core?
My other option is to wait until the updated deconz version is released for Home Assistant Core.

[axellebot]

I don't really understand why I don't have the same attributes and vendor/brand info, also no "Tuya settings" section and many attributes are gray 😞
I guess I can do the same trick with "limit" attributes but seems also broken.

From "Window covering settings" section :

I think I do have the Zemismart version of the same product

Maybe this is not the place, but is it possible to change general.xml in the "hosted" deconz on Home Assistant Core?
My other option is to wait until the updated deconz version is released for Home Assistant Core.

I'm able to edit the xml file with docker's shell (after installing vi).

[cobirnm]

You don’t have manufacture name, only model. Maybe @Smanar can help with this.

[aamarques]

Thanks to @Smanar @Mimiix for your help. All woking !

[Xyaren]

@Smanar I experience a similar Issue with this device:
https://www.aliexpress.com/item/1005003612165338.html (Variant 2CH Zigbee Module)

It is a module for two independent curtains/shutters.

Showing as
TS130F
_TZ3000_j1xl73iw

The Problem

When I open the shutter in deconz, the Shutter moves all the way to the top. So far so good.

//XXXX:YYYY/api/0D6989DFA9/lights/7

{
    "etag": "8c96754153107c7502dcabf715852b44",
    "hascolor": false,
    "lastannounced": null,
    "lastseen": "2022-03-27T00:07Z",
    "manufacturername": "_TZ3000_j1xl73iw",
    "modelid": "TS130F",
    "name": "Rolladen Rechts",
    "state": {
        "bri": 254,
        "lift": 100,
        "on": true,
        "open": false,
        "reachable": true
    },
    "swversion": "0xFFFFFFFF",
    "type": "Window covering device",
    "uniqueid": "a4:c1:38:95:a7:b2:be:ee-01"
}

The api reports open: false and lift as 100%, so it is reversed.

If I click on close the shutter moves all the way to the bottom:

//XXXX:YYYY/api/0D6989DFA9/lights/7

                    {
    "etag": "14fbeaca7115074d6c129df6c6258fa0",
    "hascolor": false,
    "lastannounced": null,
    "lastseen": "2022-03-27T00:10Z",
    "manufacturername": "_TZ3000_j1xl73iw",
    "modelid": "TS130F",
    "name": "Rolladen Rechts",
    "state": {
        "bri": 0,
        "lift": 0,
        "on": false,
        "open": true,
        "reachable": true
    },
    "swversion": "0xFFFFFFFF",
    "type": "Window covering device",
    "uniqueid": "a4:c1:38:95:a7:b2:be:ee-01"
}

The API returns open: true and a lift of 0.

I already played around with the motor invert setting but that results in open/close actions being switched.

Please advise what I can do here.
Should I open a new Issue or is there anything I am missing ?

Also the device has no light, so why is there a brightness and on/off functionallity dispalyed?
I suspect this should be handled as a different model like zigbee2mqtt does:
https://github.com/Koenkk/zigbee-herdsman-converters/blob/aa996af922b11318c9b7317019f3070d5bff2990/devices/lonsonho.js#L37
https://www.zigbee2mqtt.io/devices/TS130F_dual.html

Koenkk/zigbee2mqtt#11860
_

Thank you very much in advance!

[Smanar]

Ok so the command are working but the return is reversed ?
If it s that you are lucky, you can reverse the order using DDF.

You have some explanation here #5710 (comment)

I can explain better after, but this trick can work only if the commande are working.
Else need to use the "write" feature present on the last deconz beta.

[Xyaren]

I already experimented with that.
Status and lift value looked fine.

But the "Set lift percentage" was not inverted.
So Open and Close work fine but setting to a specific value does not use the 100-x Logic.

This is how
There it is mentioned, that even if the device identifies as TS130F it is quite different from the other TS130F models.

This is my current DDF:

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZ3000_j1xl73iw",
  "modelid": "TS130F",
  "product": "TS130F Dual",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/ts130f.json",
  "subdevices": [
    {
      "type": "$TYPE_WINDOW_COVERING_DEVICE",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x01"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/lift",
          "read": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 0,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 0,
            "eval": "Item.val = (100-Attr.val)",
            "fn": "zcl"
          }
        },
        {
          "name": "state/open",
          "read": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 0,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 0,
            "eval": "Item.val = Attr.val > 90",
            "fn": "zcl"
          }
        },
        {
          "name": "state/reachable"
        }
      ]
    },
    {
      "type": "$TYPE_WINDOW_COVERING_DEVICE",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x02"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/lift",
          "read": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 0,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 0,
            "eval": "Item.val = (100-Attr.val)",
            "fn": "zcl"
          }
        },
        {
          "name": "state/open",
          "read": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 0,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 0,
            "eval": "Item.val = Attr.val > 90",
            "fn": "zcl"
          }
        },
        {
          "name": "state/reachable"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0102",
      "report": [
        {
          "at": "0x0008",
          "dt": "0x20",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 2,
      "cl": "0x0102",
      "report": [
        {
          "at": "0x0008",
          "dt": "0x20",
          "min": 1,
          "max": 300,
          "change": "0x00000001"
        }
      ]
    }
  ]
}

[Smanar]

So Open and Close work fine but setting to a specific value does not use the 100-x Logic.

Arf, so not possible without editing code, need to use a DDF to bypass the send request, and this is not yet ready for other cluster than the tuya one.

[Xyaren]

So anything I can do now to work around that?

Code changes are currently discouraged right?

[Smanar]

Yep sorry, #5733

I can explain you the code edition you need to do, but will be for you only (and need a real linux machine for compilation).

[Xyaren]

If you could point me to the relevant code lines that would be nice !

Building my own docker image should be doable for me.

Although not knowing c++ at all I am quite accustomed with Java, python and golang.

[Xyaren]

So, I just compiled my fork https://github.com/Xyaren/deconz-rest-plugin/commit/852c9384a0ebb524dec0fe193e1a2f8863bfeb13 and it seems to be working flawless.
As this is currently not possible to implement via DDF, is there any chance to get that merged ?

[Smanar]

As this is currently not possible to implement via DDF, is there any chance to get that merged ?

No, that is why I have said "only for you".
You can try but even 1 line edition PR was blocked, and the objective is exactly to remove this kind of hack.

And I realy don't have timestone for a "write" feature for others cluster than the tuya one.

[Xyaren]

Well too bad :/

Is there already an Issue for the missing feature, that would allow writing a DDF for this ?

[Smanar]

Ha nope ^^. Can ask to have information.
But manup is working on the DDF core, so every 15days/month we have new feature, I think the next one will be the battery switch support, but there is not realy ETA.
The support for tuya is not finished yet, need to be added on application core too.

[Xyaren]

@manup Would you accept a PR if it includes a DDF for the device (as fas as currently possible), a code-fix and the promise of moving the code fix into DDF as soon as it is actually possible to do so ? 😬

[manup]

Hi not sure if I understand the full discussion, only missing piece for the DDF to work is prevention to send certain requests from C++ code?

[Xyaren]

I'm sure @Smanar can provide a better explanation...

The curtain modules open-close percentage is reversed. 100->0 through 0->100.
This can be fixed for the reporting percentage and status (open/close) via DDF.
The problem is the "Set to X Percentage" request that is not controllable via DDF by my understanding.

Additionally the device reports a brightness despite not having any light physically preset or connectable to the module.
This can be fixed by a DDF already, and I am happy to provide that.

Edit:
The mentioned patch (https://github.com/Xyaren/deconz-rest-plugin/commit/852c9384a0ebb524dec0fe193e1a2f8863bfeb13)
would solve all problems with this module for me, but I understand that moving to DDF is a priority right now, and I would be happy to do so if technically possible. Until then I would prefer a code solution.

[Smanar]

After reflexion we need something more complex than just a "write" feature for all clusters (like the tuya one).

We need something to reverse the zigbee request, for exemple send the WINDOW_COVERING_COMMAND_OPEN instead of using WINDOW_COVERING_COMMAND_CLOSE when the user make {"open" : false }
(It's a sample, in reality this device reverse only the WINDOW_COVERING_COMMAND_GOTO_LIFT_PCT value)

I think it will be easier to add a setting field in the DDF that can be used in rest_lights.cpp file to reverse the request.

[manup]

Something like bool config/reverse?

[Xyaren]

With Options to reverse open/close and setLift setTilt ?

Could single commands be part of the ddf ? command/open,command/close, command/setOpenPct etc ?

[Smanar]

Something like bool config/reverse?

Yes, I think it will be better, because some covering are mounting dependent, and some third app don't have this setting.
So not possible making an universal DDF.

And for the command/open,command/close, command/setOpenPct, it the "write" feature, but I think it work only for on/off and SetLevel ATM.

[Xyaren]

there could be devices having open / close correct, but only the level switched around.

[Smanar]

This is an other problem, this need to be solved in the DDF, in this situation the device generaly don't respect rules.

[Lionoboy]

Hello,
It seems I am facing the same issue than peoples here, with a Tuya curtain switch whose manufacturer name is "_TZ3000_8kzqqzu4".

Its "lift" state is inverted on the rest API.
When the cover is fully close, I have the following JSON:

 {
    "config": {
        "groups": [
            "0"
        ]
    },
    "etag": "f855f088446a0e56d4cdeb625d81a35b",
    "hascolor": false,
    "lastannounced": null,
    "lastseen": "2023-09-30T20:05Z",
    "manufacturername": "_TZ3000_8kzqqzu4",
    "modelid": "TS130F",
    "name": "deskroom_cover",
    "state": {
        "bri": 0,
        "lift": 0,
        "on": false,
        "open": true,
        "reachable": true
    },
    "swversion": null,
    "type": "Window covering device",
    "uniqueid": ""
}

and when it is fully open, I have this JSON:

 {
    "config": {
        "groups": [
            "0"
        ]
    },
    "etag": "c2d830734ad8f467422ba5e84ece5538",
    "hascolor": false,
    "lastannounced": null,
    "lastseen": "2023-09-30T20:16Z",
    "manufacturername": "_TZ3000_8kzqqzu4",
    "modelid": "TS130F",
    "name": "deskroom_cover",
    "state": {
        "bri": 254,
        "lift": 100,
        "on": true,
        "open": false,
        "reachable": true
    },
    "swversion": null,
    "type": "Window covering device",
    "uniqueid": ""
}

I am using Deconz version 2.23.01 running on Docker and a Raspbee II with firmware version 26780700.
Is it possible to have the same correction than other had here?

[Smanar]

Depend of situation.
But if the device don't use tuya cluster, if the command is fine, and only the return need to be reversed, it's possible yes.

Just make a DDF (or take the autogenerated one by deconz) and edit thoses lines

        {
          "name": "state/lift",
          "read": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 1,
            "eval": "Item.val = (100-Attr.val)",
            "fn": "zcl"
          }
        },
        {
          "name": "state/open",
          "read": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 1,
            "eval": "Item.val = Attr.val > 90",
            "fn": "zcl"
          }
        },

[Lionoboy]

Hello @Smanar,

I used the DDF Editor of Deconz (Edit tab > Edit DDF) to implement what you gave me and then reboot the device hosting deconz.
Now, I want to "Edit DDF" of any of my "_TZ3000_8kzqqzu4" devices, the right DDF seems to be implemented:

However the JSON given by the rest API are same as before.
Did I miss something?

[Smanar]

Now, I want to "Edit DDF" of any of my "_TZ3000_8kzqqzu4" devices, the right DDF seems to be implemented:

The DDF will have the same impact on ALL _TZ3000_8kzqqzu4.

However the JSON given by the rest API are same as before.
Did I miss something?

if it work the change is not important, you can now edit thoses lines
"eval": "Item.val = (100-Attr.val)",
in
"eval": "Item.val = Attr.val",
To reverse the return. it will be visible on logs deconz/help/debug/view with flag "DDF" and "info"

Have you check :

• Your DDF need to be in "gold" state
• have you make "hot reload" in the editor or relaod deconz ?
• The code will have impact only on lift/open as bri/on as now deprecated, but third app can still use them.

[Lionoboy]

It works now, I didn't set the DDF in "gold" state.
Thank you very much for your help!

[Smanar]

Do you want to make a PR to submit the device correction ?
Or I can do it if you share the complete DDF ?

[caprageon]

Or I can do it if you share the complete DDF ?

Hi not sure if it is still needed but please find bellow the full DDF. The reporting of state/on is now perfect (running 2.28.1 and conbee ii 26720700)

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZ3000_dbpmpco1",
  "modelid": "TS130F",
  "product": "TS130F",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/ts130f.json",
  "subdevices": [
    {
      "type": "$TYPE_WINDOW_COVERING_DEVICE",
      "restapi": "/lights",
      "uuid": [
        "$address.ext",
        "0x01"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "state/bri",
          "refresh.interval": 5,
          "read": {
            "at": "0x0000",
            "cl": "0x0008",
            "ep": 0,
            "fn": "zcl:attr"
          },
          "parse": {
            "at": "0x0000",
            "cl": "0x0008",
            "ep": 0,
            "eval": "Item.val = Attr.val",
            "fn": "zcl:attr"
          }
        },
        {
          "name": "state/lift",
          "refresh.interval": 300,
          "read": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 1,
            "fn": "zcl:attr"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 1,
            "eval": "Item.val = (100-Attr.val)",
            "fn": "zcl:attr"
          },
          "default": 0
        },
        {
          "name": "state/on",
          "description": "True when device is on; false when off.",
          "refresh.interval": 5,
          "read": {
            "at": "0x0000",
            "cl": "0x0006",
            "ep": 0,
            "fn": "zcl:attr"
          },
          "parse": {
            "at": "0x0000",
            "cl": "0x0006",
            "ep": 0,
            "eval": "Item.val = Attr.val",
            "fn": "zcl:attr"
          }
        },
        {
          "name": "state/open",
          "read": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 1,
            "fn": "zcl:attr"
          },
          "parse": {
            "at": "0x0008",
            "cl": "0x0102",
            "ep": 1,
            "eval": "Item.val = Attr.val > 90",
            "fn": "zcl:attr"
          }
        },
        {
          "name": "state/reachable"
        }
      ]
    }
  ]
}