Add DDF for a Tuya TRV _TZE200_hhrtiq0x , and prepare the code to use it

[Smanar]

So with the @TheHaf 's help, the first working tuya trv with DDF

If you want to help there is a version with more debug lines on the issue #5831

Clean version of #6054

UNTESTED YET

[Smanar]

Same question @SwoopX , about https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6674/files#diff-7548d412985c02a5cf5b188c22b61937c468e2ce2914e8ee4e8c13cd28e0750bL1690

Do you think it can break other device than use RConfigLocked ?

This field is a bool, idk why the convertion was needed previously ?

[ruipalhinhas]

Hi Smanar,
Responding to your request from the older issue (#6054 (comment)), I have a Tuya TRV (manufacturer code _TZE200_cpmgn2cf) and am happy to help test the code (just need some pointers on how to do it).

[Smanar]

@ruipalhinhas sure, you just need a real OS on linux, can work on VM, but I prefer avoid docker.
What is your OS ?

[ruipalhinhas]

@ruipalhinhas sure, you just need a real OS on linux, can work on VM, but I prefer avoid docker. What is your OS ?

I can have a Debian VM up and running on Hyper-V (Windows Server 2016 or Windows 10), would that work?

[Smanar]

I have checked the code the model "_TZE200_cpmgn2cf" is already supported, so you are already using them ?
I prefer use a nor supported device, can't break existing automation ^^.
Else we can force the core to use DDF stuff, and will be not hard for me to make the DDF as i already know the device.

And yes Debian VM should work.

If you want to make a try the procedure is explained here #6664 (comment)

And the DDF for your device

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZE200_cpmgn2cf",
  "modelid": "TS0601",
  "vendor": "Tuya",
  "product": "Tuya TRV",
  "sleeper": false,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_THERMOSTAT",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0xef00"
      ],
      "meta": {
        "values": {
          "config/mode": {"auto": 0, "heat": 1, "off": 2}
        }
      },
      "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": "config/battery",
          "parse": {"fn": "tuya", "dpid": 21, "eval": "Item.val = Attr.val;"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/heatsetpoint",
          "parse": {"fn": "tuya", "dpid": 2, "eval": "Item.val = Attr.val * 10;"},
          "write": {"fn": "tuya", "dpid": 2, "dt": "0x2b", "eval": "Item.val / 10;"},
          "read": {"fn": "tuya"}
        },
        {
          "name": "config/locked",
          "parse": {"fn": "tuya", "dpid": 7, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 7, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/windowopen_set",
          "parse": {"fn": "tuya", "dpid": 18, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 18, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/mode",
          "values": [
              ["auto", 0], ["heat", 1], ["off", 2]
          ],
          "parse": {"fn": "tuya", "dpid": 106, "eval": "if (Attr.val == 0) { Item.val = 'auto' } else if (Attr.val == 1) { Item.val = 'heat' } else { Item.val = 'off' }"},
          "write": {"fn": "tuya", "dpid": 106, "dt": "0x30", "eval": "if (Item.val == 'auto') { 0 } else if (Item.val == 'heat') { 1 } else { 2 }"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/preset",
          "parse": {"fn": "tuya", "dpid": 4, "script": "tuya_trv_preset.js"},
          "write": {"fn": "tuya", "dpid": 4, "dt": "0x30", "script": "tuya_trv_preset_set.js"},
          "read": {"fn": "none"}
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/temperature",
          "parse": {"fn": "tuya", "dpid": 3, "eval": "Item.val = Attr.val * 10;"},
          "read": {"fn": "none"}
        },
        {
          "name": "state/valve",
          "parse": {"fn": "tuya", "dpid": 109, "eval": "Item.val = Attr.val > 5;"},
          "read": {"fn": "none"}
        }
      ]
    }
  ]
}

It's the same than for the Nedis, haven't checked all dp, but most of them are same, so probably a clone again, you will miss the windowopen

[manup]

@Smanar is the PR ready to merge? :)

[Smanar]

Yes, it is just untested, but all suspicious code was removed, by master branch update, or swoops comment.
The only thing that stay are safe for me.

And all check for DDF (the news one) are made AFTER the legacy code, so will be not possible to use DDF for already managed device, but not possible to break them. And now after reflexion, it make @ruipalhinhas will be not able to full test his DDF, because some part will be managed by legacy code (till they will be removed from c++ code)
(I can reverse that If you prefer the DDF code prioritary ? Was as it just because was set like that at start)

[ruipalhinhas]

Hi @Smanar
Thanks for the instructions and your efforts in getting this issue sorted :)

I managed to get deCONZ to recognise the valve after creating the DDF file correctly. Note that on my "production" machine (i.e., Home Assistant) I cannot get the valve recognised, it just shows as 0x#### instead of as "Thermostat #" as it does now on the test machine.

The device shows up as the below screenshot, is this how it's supposed to look like? I don't see how to set/read the current temperature...

Edit: is the above because the valve is supposed to be included in the legacy code as you mentioned on your comment above (#6674 (comment))?

[Smanar]

Yep when name are 0xXXXX it mean the device is not reconized in the API.

I don't see how to set/read the current temperature...

Not possible using the GUI, all is hidden in the tuya cluster.

The DDF use thoses 2 lines to reconize the device

  "manufacturername": "_TZE200_cpmgn2cf",
  "modelid": "TS0601",

If they match, there no reasons for the device was not reconised, if you have the GUI, selecting the device with 0xXXXX, then making "Edit DDF", it's the good DDF that is used ?
You need to include the device with the DDF, so the device will be removed from your production network to the dev network.

I have someone that have partialy succed here #6664 (comment), need to check what is missing.

[ruipalhinhas]

Yep when name are 0xXXXX it mean the device is not reconized in the API.

Makes sense, that's what I get in production.

I don't see how to set/read the current temperature...

Not possible using the GUI, all is hidden in the tuya cluster.

Ah thanks!

The DDF use thoses 2 lines to reconize the device

  "manufacturername": "_TZE200_cpmgn2cf",
  "modelid": "TS0601",

If they match, there no reasons for the device was not reconised, if you have the GUI, selecting the device with 0xXXXX, then making "Edit DDF", it's the good DDF that is used ? You need to include the device with the DDF, so the device will be removed from your production network to the dev network.

In that case, it worked fine in the dev network - it recognised the device straight away once I had the DDF in the folder. Editing the DDF does show the correct one as per the json you sent.

I have someone that have partialy succed here #6664 (comment), need to check what is missing.

I also noticed the same issue with the battery as in the comment, time might indeed resolve this as I've seen it happen with other devices. I'll try to do a test over the weekend and see if it gets a battery value after a couple of days

[Smanar]

I also noticed the same issue with the battery as in the comment, time might indeed resolve this as I've seen it happen with other devices. I'll try to do a test over the weekend and see if it gets a battery value after a couple of days

But we will have some issue on your side, temperature will work because will work at 100% with DDF core, but for config/mode you will be able to have return but not sure you will be able to set it, as this part will be still on legacy code.

But if you can tell me what is working or not, will be usefull ^^, thx.

[Smanar]

Ok, so some return from @bruesche, from the moment the _TZE200_thbr5z34 is working, just an issue with battery (but nothing to see with this PR, perhaps my calculation give a value > 100) and config/mode, but his device use 2 "heatpoint" and deconz only one, so not perfect yet, but still nothing to see with this PR.

[ruipalhinhas]

Hi @Smanar

Tested over the weekend and so far, no issues at all. The valve responds well to the change of setpoints (takes a few seconds to update but nothing major). The values displayed on HA are the same on the valve (so no scaling issues there). I've also tested the presets and they all change on the valve accordingly (again, takes a few seconds to update after each command) and report the status back to HA without issues.

The only thing that is still outstanding is the battery indication - it still displays 0% after ~3 days. I recall reading some discussions on other Tuya valves that the battery indicator is for low battery only, so maybe that's why there's no values shown for the battery?

[Smanar]

The only thing that is still outstanding is the battery indication - it still displays 0% after ~3 days. I recall reading some discussions on other Tuya valves that the battery indicator is for low battery only, so maybe that's why there's no values shown for the battery?

I have same problem here #6664 (comment)

If you have the GUI and can enable the log ? with flag "info" you need to se line like
"TY_DATA_%s: seq %u, dpid: 0x%02X, type: 0x%02X, length: %u, val: %d\

With dpid 34 = 0x22 for battery level or 0x6E = 110

BTW, I your DDF I m using another value 21 = 0x15

        {
          "name": "config/battery",
          "parse": {"fn": "tuya", "dpid": 21, "eval": "Item.val = Attr.val;"},
          "read": {"fn": "none"}
        },

And have found another dpid used by Moes 0x0e = 14

[ruipalhinhas]

If you have the GUI and can enable the log ? with flag "info" you need to se line like "TY_DATA_%s: seq %u, dpid: 0x%02X, type: 0x%02X, length: %u, val: %d\

So far I'm only seeing temperature readings (dpid: 0x03) show up in the log, nothing on battery yet.

[Smanar]

Yeah, it's the bigger problem, and not possible to trigger them.

[bchhabra]

@SwoopX @Smanar
I see this is already merged.
I am using the deconz docker via the image: deconzcommunity/deconz:stable
and I still found that my trv is added as 0x0CE3.
what am I missing, I would like to avoid any manual steps of updating DDF if it is already fixed/merged.

[Smanar]

Hello, what is your deconz version (Deconz not the firmware)
Are you sure your device have same modelID/Manufacture name ?

  "manufacturername": "_TZE200_cpmgn2cf",
  "modelid": "TS0601",

And in the worse situation, what is your OS ?