DDF for Tuya TRV: Essentials, Revolt, Siterwell, Nedis...

[mattreim]

Reopened #7640 and #8015

My test device:
Essentials 12011

The information is from the following page zha-device-handlers.

Phoscon:

[mattreim]

I hope it's the last time, thank you @Smanar.

[mattreim]

Hello @Smanar, I noticed that Home Assistant doesn't really get along with config/preset and these devices only have three modes. Wouldn't it be better to use config/mode?

{
  "name": "config/mode",
  "parse": {
      "fn": "tuya",
      "dpid": 4,
      "eval": "if (Attr.val == 0) { Item.val = 'off' } else if (Attr.val == 1) { Item.val = 'auto' } else if (Attr.val == 2) { Item.val = 'heat' }"
   },
   "write": {
       "fn": "tuya",
       "dpid": 4,
       "dt": "0x30",
       "eval": "if (Item.val == 'off') { 0 } else if (Item.val == 'auto') { 1 } else if (Item.val == 'heat') { 2 }"
    },
    "read": {
         "fn": "none"
    }
},

[Smanar]

Right, on the orignal DDF they are using it, need to keep it (on dpid = 106).

And thoses device support both, mode and preset, mode is Heat/off/auto, preset have lot of more setting even all are not present on all device.

[mattreim]

I just wanted to set config/mode to "dpid = 4" because "dpid = 106" didn't work on my device. There is also nothing here or here that says that the devices use both modes.

[Smanar]

So it mean you don't have the same device, becuse on native code all of thoses use the dpid 106

#define DP_IDENTIFIER_THERMOSTAT_MODE_1 0x6A // mode used with DP_TYPE_ENUM

                    else if (R_GetProductId(sensor) == QLatin1String("Tuya_THD HY369 TRV") ||
                             R_GetProductId(sensor) == QLatin1String("Tuya_THD HY368 TRV") ||
                             R_GetProductId(sensor) == QLatin1String("Tuya_THD GS361A-H04 TRV") ||
                             R_GetProductId(sensor) == QLatin1String("Tuya_THD Essentials TRV") ||
                             R_GetProductId(sensor) == QLatin1String("Tuya_THD NX-4911-675 TRV") ||
                             R_GetProductId(sensor) == QLatin1String("Tuya_THD MOES TRV"))
                    {
                        const auto match = matchKeyValue(data.string, RConfigModeValuesTuya1);

                        if (isValid(match))
                        {
                            QByteArray tuyaData = QByteArray::fromRawData(match.value, 1);
                            quint8 dpIdentifier = DP_IDENTIFIER_THERMOSTAT_MODE_1;

[mattreim]

What should dpid 106 do?

[Smanar]

From that I m reading it's the "forced mode" 0x04 is the "classic mode"

// force mode 0 - normal, 1 - open, 2 - close

But idk why we are using this one. You can change the mode manualy on your device and look for return on deconz logs, you will see if your device use 0x04 or 0x6A.

[mattreim]

After some testing I changed dpid 4 from config/preset to config/mode and it works exactly as expected. Of course config/preset also worked but the thermostat was always shown as off in Home Assistant.

[Smanar]

And it don't work with dpid = 106 ?
IDK how work HA, but preset have no impact on mode, values can be

switch (Attr.val) {
    case 0:
        Item.val = 'holiday';
        break;
    case 1:
        Item.val = 'auto';
        break;
    case 2:
        Item.val = 'manual';
        break;
    case 3:
        Item.val = 'comfort';
        break;
    case 4:
        Item.val = 'eco';
        break;
    case 5:
        Item.val = 'boost';
        break;
    case 6:
        Item.val = 'complex';
        break;
}

So yes can be same Holiday/auto/manual can be off/auto/heat.
I can see the code for some device, but I don't remember wich one TRV support it or not.

[mattreim]

I tried it again with dpid 106 but it doesn't work. The device just turns on and nothing happens.

[Smanar]

The device just turns on and nothing happens.

It turn on ? so it works no ?

[mattreim]

It is only optical in HA. It does not switch the device.

[mattreim]

The device just turns on and nothing happens.

It turn on ? so it works no ?

Sorry, the display turns on and not the device.

[Smanar]

Ha yes, it's because the API is updated, if the device understand the request or not.

[mattreim]

I also made this observation during testing and sometimes the devices can crash.

[mattreim]

@Smanar With the latest changes my devices work very well and now I would like to implement state/on but unfortunately these thermostats do not have an attribute for this. Now I've tried two options.

Option 1:

        {
          "name": "state/on",
          "parse": {
            "dpid": 4,
            "eval": "Item.val = Attr.val > 1",
            "fn": "tuya"
          },
          "read": {
            "fn": "none"
          }
        },

With this option, auto and heat are always displayed with on.

Option 2:

        {
          "name": "state/on",
          "parse": {
            "dpid": 3,
            "eval": "Item.val = Attr.val * 10 < R.item('config/heatsetpoint').val",
            "fn": "tuya"
          },
          "read": {
            "fn": "none"
          }
        },

With this option, the status is adjusted every time the temperature changes.

Which option do you think is best?

[Smanar]

The DPID 0x03 is the current temperature, nothing to see with the valve state.
You can try with the "valve position" but IDK if this device support it.

        {
          "name": "state/valve",
          "parse": {
            "fn": "tuya",
            "dpid": 109,
            "eval": "Item.val = Attr.val > 5;"
          },
          "read": {
            "fn": "none"
          }
        }

[mattreim]

Unfortunately, these devices do not show the valve position, so it might be better to leave out state/on and use the attributes that the devices also support.

[Smanar]

It's a regulated device, so not possible to use local temperature, you can have local temperature+2 °C and the valve open or closed, all situations are possibles.
If you haven't the valve position can use the "config/mode" ? it will be not the state, but at least the working mode ?

[mattreim]

Yes, I think “config/mode” is good because at least the correct status is output. Thanks @Smanar

[mattreim]

Sorry, I also meant “config/mode” (dpid = 4) and have already tested it successfully.

[mattreim]

@manup I think this DDF is ready for use now. Can you merge it with 2.29.3-beta now?

[github-actions]

This pull request is now merged. The new DDB files have been uploaded to the store.

DDB Files

_{🕚 Updated for commit 394df6d}