search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.89k stars 497 forks source link

TV02 ZIGBEE THERMOSTAT RADIATOR VALVE - _TZE200_hue3yfsn - TS0601 - TUYA #5844

Closed Ritchie3 closed 2 years ago

Ritchie3 commented 2 years ago

https://zigbee.blakadder.com/Tuya_TV02.html

Device

Screenshots

Basic

image

Identify

n/a

Alarms

n/a

Device Temperature

n/a

Groups

image image

Scenes

image image image image

On/Off

n/a

Level Control

n/a

Color Control

n/a

Simple Metering

n/a

Diagnostics

n/a

Other clusters that are not mentioned above

Tuya specific cluster image

github-actions[bot] commented 2 years ago

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.

Ritchie3 commented 2 years ago

Is someone looking into this one?

Smanar commented 2 years ago

Heeee, I don't think ^^. So the DDF core is now able to manage tuya cluster https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5868 , so if you have a recent deconz version, can make a try.

Here a video to explain DDF https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/DDF-cheat-sheet

Just start from scratch

If I m right now the device will be reconized (the name will change for other thing than 0x0000), but will not work at all. Can you make a copy/paste of the DDF for I complete it ? You can make a c/c on the last tab of the editor, or dieclty using the file (you will have the path on the DDF editor window title)

helpsterTee commented 2 years ago

@Smanar:

As OP isn't responding, here is my config, I have a BSEED thermostat, which uses the same identifier. I tried to get it to work using your data from https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5831 but no values changed, unfortunately. And the "Trigger report all endpoints" in the Tuya Cluster did not work for me. Reading values works, but is quirky. I don't understand why changing the set point multiplier expression from Item.val = Attr.val * 10; to Item.val = Attr.val; breaks reading the value instead of just changing the value returned?

Updated:

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZE200_hue3yfsn",
  "modelid": "TS0601",
  "product": "TS0601",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/ts0601.json",
  "subdevices": [
    {
      "type": "$TYPE_THERMOSTAT",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0xff",
        "0x0201"
      ],
      "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/heatsetpoint",
          "refresh.interval": 10,
          "read": {
            "fn": "tuya"
          },
          "parse": {
            "dpid": 16,
            "eval": "Item.val = Attr.val * 10;",
            "fn": "tuya"
          },
          "default": 0
        },
        {
          "name": "config/offset",
          "description": "Relative offset to the main measured value.",
          "default": 0
        },
        {
          "name": "config/locked",
          "parse": {
            "dpid": 40,
            "eval": "Attr.val == 0 ? Item.val = false : Item.val = true;",
            "fn": "tuya"
          }
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/schedule",
          "description": "On-device heating schedules."
        },
        {
          "name": "config/schedule_on",
          "parse": {
            "dpid": 2,
            "eval": "Attr.val == 0 ? Item.val = true : Item.val = false;",
            "fn": "tuya"
          }
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/on",
          "description": "True when device is on; false when off.",
          "refresh.interval": 5
        },
        {
          "name": "state/temperature",
          "description": "The current temperature in °?C × 100.",
          "default": 0
        }
      ]
    }
  ]
}

WebAPI Response:

{
    "config": {
        "heatsetpoint": 1100,
        "locked": false,
        "offset": 0,
        "on": true,
        "reachable": true,
        "schedule": {},
        "schedule_on": false
    },
    "etag": "xxx",
    "lastannounced": null,
    "lastseen": "2022-04-05T12:51Z",
    "manufacturername": "_TZE200_hue3yfsn",
    "modelid": "TS0601",
    "name": "Thermostat 26",
    "state": {
        "battery": null,
        "lastupdated": "none",
        "on": null,
        "temperature": 0
    },
    "type": "ZHAThermostat",
    "uniqueid": "xxx"
}
Smanar commented 2 years ago

We have started to add another tuya TRV, it start working but we are blocked, it seem the "write fonction don't work perfectly, you have the issue here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5831

helpsterTee commented 2 years ago

Yes, most likely, but the reads are also not working.

I've tried all the config from https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5831#issuecomment-1086126465 this one and the values just don't change. But the other user has a _TZE200_hhrtiq0x and this is _TZE200_hue3yfsn, so maybe there is a difference...

Latest beta release. I'll guess I have to wait, if you want someone to test, just \@ me :)

Smanar commented 2 years ago

For information for the read and parse part, your device use

DPID = 24 for temperature DPID = 16 for set Heatpoint DPID = 40 for childlock DPID = 35 for battery

But for the moment I think we need a code modification to have the DDF working for the write feature.

helpsterTee commented 2 years ago

Additional values: https://github.com/zigpy/zha-device-handlers/issues/1027#issuecomment-930477929

Can confirm this config works for setting set temperature and reading temperature from thermostat:

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZE200_hue3yfsn",
  "modelid": "TS0601",
  "product": "TS0601",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/ts0601.json",
  "subdevices": [
    {
      "type": "$TYPE_THERMOSTAT",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0xff",
        "0x0201"
      ],
      "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/heatsetpoint",
          "refresh.interval": 10,
          "read": {
            "fn": "tuya"
          },
          "parse": {
            "dpid": 16,
            "eval": "Item.val = Attr.val * 10;",
            "fn": "tuya"
          },
          "default": 0
        },
        {
          "name": "config/locked",
          "parse": {
            "dpid": 40,
            "eval": "Attr.val == 0 ? Item.val = false : Item.val = true;",
            "fn": "tuya"
          }
        },
        {
          "name": "config/offset",
          "parse": {
            "dpid": 27,
            "fn": "tuya"
          },
          "default": 0
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/schedule"
        },
        {
          "name": "config/schedule_on",
          "parse": {
            "dpid": 2,
            "eval": "Attr.val == 0 ? Item.val = true : Item.val = false;",
            "fn": "tuya"
          }
        },
        {
          "name": "state/battery",
          "refresh.interval": 3600,
          "parse": {
            "dpid": 35,
            "fn": "tuya"
          }
        },
        {
          "name": "state/heating",
          "parse": {
            "dpid": 107,
            "eval": "Attr.val == 0 ? Item.val = true : Item.val = false;",
            "fn": "tuya"
          }
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/temperature",
          "parse": {
            "dpid": 24,
            "eval": "Item.val = Attr.val * 10;",
            "fn": "tuya"
          },
          "default": 0
        },
        {
          "name": "state/windowopen",
          "parse": {
            "dpid": 8,
            "eval": "Attr.val == 0 ? Item.val = false : Item.val = true;",
            "fn": "tuya"
          },
          "default": "false"
        }
      ]
    }
  ]
}

It is however not sending all values automatically, I have to force update the values.

So I'm waiting for the custom write function now :)

Smanar commented 2 years ago

It is however not sending all values automatically, I have to force update the values.

set temperature offset -> get temperature
turn wheel for set temperature -> get set temperature

Ha ? can you explain how you do that ?

helpsterTee commented 2 years ago

It does not automatically fetch the values, it only transmits when something changes (which is odd). So if you set the temperature offset via the debug dialog in the Tuya cluster settings, it will recalculate the temperature and transmit it. Same with the heat setpoint, just set it and it will transmit the status (or physically turn the wheel).

I guess this is a problem with the "ready" function not pulling all the values, that never worked for me.

Additionally, if there is ANY mistake in the Javascript expression anywhere in the DDF file, it will stop parsing all the stuff altogether. That is, if you try using the "write" function for transforming values, which does not work as of now, the whole update will fail...

Smanar commented 2 years ago

It's like the description from swoop but I still don't understand.

if you set the temperature offset via the debug dialog in the Tuya cluster settings

You mean you are using the GUI to send values, not the API/third app ?

So if m right, you have return from the DDF , with "read" and "parse" but you arenot able to send the "setHeatpoint" or childlock" using the API because of the problem with the "write" feature ?

helpsterTee commented 2 years ago

If I reset the device, all states from the API are null. I have to use Deconz to send a value to DPID 27 (temp offset), which will then have the device send the recalculated temperature, so it is no longer null. It will never transmit the temperature on its own -> no automatic refresh, I guess it's the "read" function that should be used only once. I've set it to 10 seconds, but it is not polling anything.

I can actually set the setHeatpoint via API / home-assistant. That works, because the value is transmitted without having to be transformed.

grafik

When I need a custom transform, I would use the "write" function. For example home-assistant knows "heating", and I can turn that on or off. But the device only knows "heating_stop" (inverse). So a write function would have to do "Item.val == 0 ? 1 : 0" -> "If heating set to zero, send 1 to heating_stop, otherwise 0".

So simple writes work somehow, but custom writes with "write:" do not. Sorry for the bad English, not a native speaker...

Smanar commented 2 years ago

Sorry for the bad English, not a native speaker...

Lol, np, I have an ugly english too ^^

I can actually set the setHeatpoint via API / home-assistant. That works, because the value is transmitted without having to be transformed.

But I don't understand how it can work for you, you are sure it s not just updated in the api and not send to the device ? It don't work on the other issue.

For information tuya device don't use reporting setting, it's the ahrdware itself that decide when to send values. I think it you just wait for some minuts, values will be updated, and not possible to poll them too.

Take care, you need to have only one

"read": {"fn": "tuya"},

and

"read": {"fn": "none"}

For other

The read function is special and must only be specified on one item (here state/on). It doesn't actually read a single value but triggers the Tuya device to report all datapoints.

From here https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5868

Ritchie3 commented 2 years ago

Hi Smanar,

Thanks for stepping in! I followed your steps and the device is indeed now showing and not working in HA. I tried to copy the log, but it seems my clipboard won't pick it up and I don't know where to save the json file, so I can get to it from an exposed location.... here are the screenshots. can you work with that?

image image

helpsterTee commented 2 years ago

@Smanar

you are sure it s not just updated in the api and not send to the device ? It don't work on the other issue.

Damn, you are right. I tested so much stuff parallel. It's only in the API and not sent to the device.

For information tuya device don't use reporting setting, it's the ahrdware itself that decide when to send values. I think it you just wait for some minuts, values will be updated, and not possible to poll them too.

I've restarted Deconz and waited for an hour and no values are reported by the device.

@Ritchie3

and I don't know where to save the json file, so I can get to it from an exposed location....

If it is docker, you need to use an external volume (which you should do anyways to persist, if you upgrade the container). My files are located in the deconz main folder under "/devices".

Ritchie3 commented 2 years ago

I'm running the Home Assistant Operating System on an RPi, so that's limiting my options... been wanting to move to another setup with some more freedom, but haven't gotten to that yet

Smanar commented 2 years ago

I've restarted Deconz and waited for an hour and no values are reported by the device.

Ha ? so it s perhpaps the utility of the "read": {"fn": "tuya"}, from the doc

It doesn't actually read a single value but triggers the Tuya device to report all datapoints.

So we need to put it for exemple in the fonction the most used "setheapoint", and it will enable reporting the first time we call this fonction ?

@Ritchie3 keep in mind your DDF ^^. For the moment we are stuck . And yes copy/paste ere difficult on HA. But don't worry all tuya DDF for TRV will be same, the only difference will be the start of the file (you already have it) and the dpid, I will give you them. ATM we are able to read value, but not send them (using the "write" feature).

Ritchie3 commented 2 years ago

@Smanar, great! Thanks!

Smanar commented 2 years ago

Ok the swoop PR was merged, so can do same for value we need. Problem, we need to make some change on code, I can make them in blind mode, but to go faster, there is someone able to compile code change to test future DDF ?

I will explain how to do, just need someone with a tuya TRV, and a full/real linux OS.

github-actions[bot] commented 2 years ago

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.

Smanar commented 2 years ago

Just for memory, Tuya TRV with DDF WIP is here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5831

github-actions[bot] commented 2 years ago

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.

github-actions[bot] commented 2 years ago

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.

Ritchie3 commented 1 year ago

@Smanar Hi Smanar, with Winter coming, this device still isn't working in HA. I have managed to read out the room temperature, but i'm unable to set the mode or temp on the device.

image

When I try to set the preset to 'manual': image

Is there a fix? Or should i just ditch this device? Thanks!

Smanar commented 1 year ago

Your device is "_TZE200_hue3yfsn" ? If yes, no more change since the last time, sorry.

Jumperm commented 1 year ago

I having same device, baut sadly same issues with writing commands. I would like to solve the problem, but I don' know what to do to. I would try the "brut force" method, but on what parameter?! Maybe it could be helpful to install the tuya app?!

Smanar commented 1 year ago

No change since the last time, sorry, still waiting the PR is merged.

BooWseR commented 1 year ago

Hi @Smanar,

anything new here? I have just updated to the current stable (2.21.02), but unfortunately I still can't operate the TRV.

Another Tuya TRV (_TZE200_hhrtiq0x) have been added in the current 2.21.0, but unfortunately not the _TZE200_hue3yfsn. Are the Tuya TRVs really so different in their communication?

It's quite frustrating, for over half a year there have been two TRVs sealed in the drawer and I operate the one i installed manually. :/

Best regards

Smanar commented 1 year ago

Yes, it's possible using DDF now. Can try this DDF

{
  "schema": "devcap1.schema.json",
  "manufacturername": ["_TZE200_sur6q7ko", "_TZE200_hue3yfsn", "_TZE200_e9ba97vf"],
  "modelid": ["TS0601", "TS0601", "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": 3}
        }
      },
      "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/lowbattery",
          "parse": {"fn": "tuya", "dpid": 35, "eval": "Item.val = Attr.val != 0"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/tuya_unlock"
        },
        {
          "name": "config/heatsetpoint",
          "parse": {"fn": "tuya", "dpid": 16, "eval": "Item.val = Attr.val * 10;"},
          "write": {"fn": "tuya", "dpid": 16, "dt": "0x2b", "eval": "Item.val / 10;"},
          "read": {"fn": "tuya"}
        },
        {
          "name": "config/locked",
          "parse": {"fn": "tuya", "dpid": 40, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 40, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/mode",
          "values": [
              ["auto", 0], ["heat", 1], ["off", 3]
          ],
          "parse": {"fn": "tuya", "dpid": 2, "eval": "if (Attr.val == 0) { Item.val = 'auto' } else if (Attr.val == 1) { Item.val = 'heat' } else { Item.val = 'off' }"},
          "write": {"fn": "tuya", "dpid": 2, "dt": "0x30", "eval": "if (Item.val == 'auto') { 0 } else if (Item.val == 'heat') { 1 } else { 3 }"},
          "read": {"fn": "none"}
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/temperature",
          "parse": {"fn": "tuya", "dpid": 24, "eval": "Item.val = Attr.val * 10;"},
          "read": {"fn": "none"}
        }
      ]
    }
  ]
}

It support the tuya unlock sequence, values can need convertion (*10 or / 10)

nilleiz commented 11 months ago

Yes, it's possible using DDF now. Can try this DDF

{
  "schema": "devcap1.schema.json",
  "manufacturername": ["_TZE200_sur6q7ko", "_TZE200_hue3yfsn", "_TZE200_e9ba97vf"],
  "modelid": ["TS0601", "TS0601", "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": 3}
        }
      },
      "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/lowbattery",
          "parse": {"fn": "tuya", "dpid": 35, "eval": "Item.val = Attr.val != 0"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/tuya_unlock"
        },
        {
          "name": "config/heatsetpoint",
          "parse": {"fn": "tuya", "dpid": 16, "eval": "Item.val = Attr.val * 10;"},
          "write": {"fn": "tuya", "dpid": 16, "dt": "0x2b", "eval": "Item.val / 10;"},
          "read": {"fn": "tuya"}
        },
        {
          "name": "config/locked",
          "parse": {"fn": "tuya", "dpid": 40, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 40, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "config/mode",
          "values": [
              ["auto", 0], ["heat", 1], ["off", 3]
          ],
          "parse": {"fn": "tuya", "dpid": 2, "eval": "if (Attr.val == 0) { Item.val = 'auto' } else if (Attr.val == 1) { Item.val = 'heat' } else { Item.val = 'off' }"},
          "write": {"fn": "tuya", "dpid": 2, "dt": "0x30", "eval": "if (Item.val == 'auto') { 0 } else if (Item.val == 'heat') { 1 } else { 3 }"},
          "read": {"fn": "none"}
        },
        {
          "name": "state/lastupdated"
        },
        {
          "name": "state/temperature",
          "parse": {"fn": "tuya", "dpid": 24, "eval": "Item.val = Attr.val * 10;"},
          "read": {"fn": "none"}
        }
      ]
    }
  ]
}

It support the tuya unlock sequence, values can need convertion (*10 or / 10)

I dont get any values the temperature and battery on this device. Is there something I need to change here?

//edit: Got the temperature readings now, but my thermostat seems to have different mode values. How do I read them, to map them accordingly?

Smanar commented 11 months ago

You have too

        {
          "name": "config/windowopen_set",
          "parse": {"fn": "tuya", "dpid": 8, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 8, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },

How do I read them, to map them accordingly?

Just enable logging with "info" "info_l2" and "ddf", set the fonction manualy on the device (for exemple switching the mode), and look at return, you will see the command used in log (the device send report on change), I can help you to decrypt it.

timoknapp commented 8 months ago

@Smanar any news on this? Its been a while and I was wondering when deconz will be supporting TS0601 - TZE200_hue3yfsn natively? I am currently using the custom DDF from above, but the battery indicator and the modes do not work properly.

I would be happy to support on this, if there is something I could test out.

Best Timo

Smanar commented 8 months ago

For the battery indicator, you mean the battery level ? Because I m seing only a lowbattery field. Can you explain the mode issue ?

I m seing some action on the dpid 107 but haven't more informations.

timoknapp commented 8 months ago

For the battery indicator, you mean the battery level ? Because I m seing only a lowbattery field.

Yes, that is correct. The Sensor does only have a lowbattery field. But even that field seems to be calculated wrongly. As my sensors always indicate lowbattery although the batteries are completely new. Are you confident, that the current implementation works as expected?

Can you explain the mode issue ?

So first of all the modes do not match. The thermostat provides the modes „manual“, „home“ and „vacation“ whereas the DDF maps those modes to „heat“, „auto“ and „off“. Furthermore, the mode „off“ cannot be set on the thermostat, as it always falls back to „auto“. Can you maybe explain those modes in more detail?

I m seing some action on the dpid 107 but haven't more informations.

What does the DPID 107 represent? Do you have a list of DPIDs mapped to the function on the thermostat?

Thanks, Timo

Smanar commented 8 months ago

Are you confident, that the current implementation works as expected?

No ^^, at all, I haven't the device. Can be a reversed return or a missing defaut value, will try the second one.

        {
          "name": "state/lowbattery",
          "parse": {"fn": "tuya", "dpid": 35, "eval": "Item.val = Attr.val != 0"},
          "read": {"fn": "none"},
          "default": false
        },

For the mode I think "manual" = "heat" (to force it) "auto" = "home" (normal working mode) and "vacation" = "off" but here it seem it's more "away".

I m seing this device have a "Heating stop" mode, but idk how to make it compatible with third app. Can try to add to DDF

        {
          "name": "state/on",
          "parse": {"fn": "tuya", "dpid": 107, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 107, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },

And it's possible this command will work only on "heat" mode.

timoknapp commented 8 months ago

Can be a reversed return or a missing defaut value, will try the second one.

        {
          "name": "state/lowbattery",
          "parse": {"fn": "tuya", "dpid": 35, "eval": "Item.val = Attr.val != 0"},
          "read": {"fn": "none"},
          "default": false
        },

I just tried adding the default value but unfortunately the low battery indication did not change on the thermostats. It is still showing "low" on all the thermostats.

For the mode I think "manual" = "heat" (to force it) "auto" = "home" (normal working mode) and "vacation" = "off" but here it seem it's more "away".

I m seing this device have a "Heating stop" mode, but idk how to make it compatible with third app. Can try to add to DDF

        {
          "name": "state/on",
          "parse": {"fn": "tuya", "dpid": 107, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 107, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },

And it's possible this command will work only on "heat" mode.

I also added the new state/on property but I dont know how to actually test this? The interface in Home Assistant at least did not change. How do I test the "heating stop" mode?

And generally regarding the mapping of the modes I am only concerned about the "vacation/away" = "off" mapping since this seems not to work properly. Whenever I turn it off it automatically switches back to "auto" while keeping the temperature at 21°C. Is it possible to change the temperature while switching back to "auto" mode?

image


Furthermore, how can we enable the thermostats to be recognized as proper "Thermostats" instead of "Smart Plugs" in deCONZ?

image

Smanar commented 8 months ago

I just tried adding the default value but unfortunately the low battery indication did not change on the thermostats. It is still showing "low" on all the thermostats.

Ha my bad, perhaps the defaut value is only used on inclusion for battery, else it use previous saved value. Can check if the device make report even the battery is good with editing

"parse": {"fn": "tuya", "dpid": 35, "eval": "Item.val = Attr.val == 0"},

If the device send a battery report, even the battery is full, it will reverse the value. But can need time, there is no reason to spam this result.

Deconz show the reality, I m sorry but it's the device that say it's a smart plug. We can "manipulate" it on the API, but deconz need to show the reality as we use information it give.

I think there is a "custom off", but I don't know this device at all. To test the "heating stop" you can use direclty the API, on shell

curl -H 'Content-Type: application/json' -X PUT -d '{"on":false}' http://IP:PORT/api/KEY/sensors/ID/state IP and PORT are the same used for phoscon KEY is an API key, can use the same used by HA ID the device ID

But now after reflexion I m not sure deconz permit "state" request on sensor ...

timoknapp commented 8 months ago

Ha my bad, perhaps the defaut value is only used on inclusion for battery, else it use previous saved value. Can check if the device make report even the battery is good with editing

"parse": {"fn": "tuya", "dpid": 35, "eval": "Item.val = Attr.val == 0"},

If the device send a battery report, even the battery is full, it will reverse the value. But can need time, there is no reason to spam this result.

Hmm this still did not resolve the wrong battery indication.

Deconz show the reality, I m sorry but it's the device that say it's a smart plug. We can "manipulate" it on the API, but deconz need to show the reality as we use information it give.

Okay, but how could I override the device type on the API myself? Can this be done via REST API?

I think there is a "custom off", but I don't know this device at all. To test the "heating stop" you can use direclty the API, on shell

curl -H 'Content-Type: application/json' -X PUT -d '{"on":false}' http://IP:PORT/api/KEY/sensors/ID/state IP and PORT are the same used for phoscon KEY is an API key, can use the same used by HA ID the device ID

But now after reflexion I m not sure deconz permit "state" request on sensor ...

I just tried this, but it did not succeed. I guess its because the state/on property does not have a "write" function. At least there is none shown in the DDF in deCONZ:

image

I furthermore noticed that the TRV will always fall back to 21°C in the morning whenever the "auto" mode is selected. It seems that there are some preset schedules configured. Do you know how to read or reset those schedules on the TRVs? Besides, how do I know which states / configs are set on what DPIDs? How do you do this typically?

Smanar commented 8 months ago

Hmm this still did not resolve the wrong battery indication.

Have checked again and Z2M use the same one, perhaps the device make notification only on real low battery, you haven't low battery to make tests ?

Okay, but how could I override the device type on the API myself? Can this be done via REST API?

It's done by the DDF itself. "type": "$TYPE_THERMOSTAT",

        {
          "name": "state/on",
          "parse": {"fn": "tuya", "dpid": 107, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 107, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },

There is a "write" part, you haven't the error message returned ? But you are right, I think it's more about a forbidden request but I m not sure too "state/on" can be used. Better to use

        {
          "name": "config/usertest",
          "parse": {"fn": "tuya", "dpid": 107, "eval": "Item.val = Attr.val;"},
          "write": {"fn": "tuya", "dpid": 107, "dt": "0x10", "eval": "Item.val;"},
          "read": {"fn": "none"}
        },

Yeah I know "usertest" is not logic, but I m sure this one can work, it's just for test. Need to use "config" instead of "state" in the request.

how do I know which states / configs are set on what DPIDs? How do you do this typically?

On the tuya cluster, can try "Trigger report all datapoint", they will be visible on logs. But the easier method, using deconz log Help/Debug view, with flag "info" and "info_l2", all tuya requests from and to the device are logged. So just need to use physicaly action on the device, look on the logs the request, and mimic it using DDF.

13:42:25:373 TY_DATA_RESPONSE: seq 271, dpid: 0x03, type: 0x02, length: 4, val: 230

This one is from the device, with the dpid 0x03 and with the value 230. Else can search on google, but not sure all will work (like the lowbattery)

timoknapp commented 8 months ago

how do I know which states / configs are set on what DPIDs? How do you do this typically?

On the tuya cluster, can try "Trigger report all datapoint", they will be visible on logs. But the easier method, using deconz log Help/Debug view, with flag "info" and "info_l2", all tuya requests from and to the device are logged. So just need to use physicaly action on the device, look on the logs the request, and mimic it using DDF.

13:42:25:373 TY_DATA_RESPONSE: seq 271, dpid: 0x03, type: 0x02, length: 4, val: 230

This one is from the device, with the dpid 0x03 and with the value 230. Else can search on google, but not sure all will work (like the lowbattery)

I just found a list of all datapoints of the Tuya TRV. Its documented quite well in the codebase of Zigbee2MQTT. The corresponding data point conversions are defined here. Can you maybe help me extending the DDF accordingly such that all features will be considered in deCONZ too?

tuyaDatapoints: [
  [2, 'preset', tuya.valueConverterBasic.lookup({'auto': tuya.enum(0), 'manual': tuya.enum(1), 'holiday': tuya.enum(3)})],
  [8, 'open_window', tuya.valueConverter.onOff],
  [10, null, tuya.valueConverter.TV02FrostProtection],
  [10, 'frost_protection', tuya.valueConverter.TV02FrostProtection],
  [16, 'current_heating_setpoint', tuya.valueConverter.divideBy10],
  [24, 'local_temperature', tuya.valueConverter.divideBy10],
  [27, 'local_temperature_calibration', tuya.valueConverter.localTempCalibration1],
  [31, 'working_day', tuya.valueConverterBasic.lookup({'mon_sun': tuya.enum(0), 'mon_fri+sat+sun': tuya.enum(1),
      'separate': tuya.enum(2)})],
  [32, 'holiday_temperature', tuya.valueConverter.divideBy10],
  [35, 'battery_low', tuya.valueConverter.trueFalse0],
  [40, 'child_lock', tuya.valueConverter.lockUnlock],
  [45, 'error_status', tuya.valueConverter.raw],
  [46, 'holiday_start_stop', tuya.valueConverter.thermostatHolidayStartStop],
  [101, 'boost_timeset_countdown', tuya.valueConverter.raw],
  [102, 'open_window_temperature', tuya.valueConverter.divideBy10],
  [104, 'comfort_temperature', tuya.valueConverter.divideBy10],
  [105, 'eco_temperature', tuya.valueConverter.divideBy10],
  [106, 'schedule', tuya.valueConverter.thermostatScheduleDaySingleDP],
  [107, null, tuya.valueConverter.TV02SystemMode],
  [107, 'system_mode', tuya.valueConverter.TV02SystemMode],
  [107, 'heating_stop', tuya.valueConverter.TV02SystemMode],
  [115, 'online', tuya.valueConverter.onOffNotStrict],
  [108, 'schedule_monday', tuya.valueConverter.thermostatScheduleDaySingleDP],
  [112, 'schedule_tuesday', tuya.valueConverter.thermostatScheduleDaySingleDP],
  [109, 'schedule_wednesday', tuya.valueConverter.thermostatScheduleDaySingleDP],
  [113, 'schedule_thursday', tuya.valueConverter.thermostatScheduleDaySingleDP],
  [110, 'schedule_friday', tuya.valueConverter.thermostatScheduleDaySingleDP],
  [114, 'schedule_saturday', tuya.valueConverter.thermostatScheduleDaySingleDP],
  [111, 'schedule_sunday', tuya.valueConverter.thermostatScheduleDaySingleDP],
],
Smanar commented 8 months ago

Yeah I know this list, but it don't work alone

[35, 'battery_low', tuya.valueConverter.trueFalse0],

We are using same, and the value don't move, so mean no return by the device, if you have used battery, faster to make test in real.

And it's that we are trying atm for this one

[107, 'heating_stop', tuya.valueConverter.TV02SystemMode],

timoknapp commented 8 months ago

I tried a lot but nothing worked out, which is why I decided to migrate to Zigbee2MQTT instead. Luckily all works as expected now, but sad that deCONZ could not keep up with a similar featureset.