Tuya Smart TRV HY369 Thermostatic Radiator Valve

[vegetate7]

Device

• Product name: Tuya Smart TRV
• Manufacturer: _TYST11_ckud7u2l
• Model identifier: kud7u2l
• Device type:
  • [ ] Light
  • [ ] Lock
  • [x] Remote
  • [ ] Sensor
  • [ ] Siren
  • [ X ] Thermostat
  • [ X ] Other: Don't really know, deConz-gui shows it as "On-Off Switch"

Screenshots

Endpoints and clusters:

Node info panel:

Basic cluster:

Identify cluster:

[ebaauw]

Don't really know, deConz-gui shows it as "On-Off Switch"

So the device exposes itself in a non-standard way, also see the lack of a Thermostat cluster. I doubt they provide technical documentation for this, so you'd need to sniff the ZigBee traffic when it's connected to its native hub/bridge/gateway to figure out how it works.

[Smanar]

Can you try to remake an inclusion, without deleting it, to be sure you don't miss a "0xef00" cluster. Or just read descriptor another time.

[vegetate7]

Can you try to remake an inclusion, without deleting it, to be sure you don't miss a "0xef00" cluster. Or just read descriptor another time.

Already did that with various ways. Only two clusters every time. Unfortunately I have not native gateway. Phps I'll order it, but it will take some weeks to ship.

[SwoopX]

z2m has integrated it. Seems it purely works on manufacturer specific commands (which you only can get if you have the gateway and/or sniff the traffic)...

[vegetate7]

z2m has integrated it. Seems it purely works on manufacturer specific commands (which you only can get if you have the gateway and/or sniff the traffic)...

So, what is the conclusion? Is there a chance to get it working with deconz? zigbee-herdsman-converters have a pretty well detalized Tuya thermostat commans description, so not need to sniff and parse. Can it be utilized in deconz-rest-plugin?

[vegetate7]

Looking into Koenkk's sources. Seems the '0xEF00' cluster must be. May be something wrong with device itself? Or it want FW update before use. Or some kind of registration/activation. Ordered Tuya Hub meanwhile.

[Smanar]

Yep, it s for that I m asking if you don't miss a cluster. I have already started a device with the cluster 0xEF00, but on my side, the device have the cluster.

[vegetate7]

btw the device continuosly reporting something from '0xef00' cluster: 01:46:06:776 APS-DATA.indication srcAddr: 0x9d18, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0xEF00, lqi: 255, rssi: -39

Attached deconz debug log started from device joining to the net and filtered by device address and mac. deconz_sp1.log

One more short log with --dbg-aps=2, now shows some data. deconz2_sp.log

[vegetate7]

Did quick converter on Perl, based on 'zigbee-herdsman-converters' data. Passed received ASDU from previous log. Looks reasonable. ('Prefix' - is just my quessing, I don't know what is it data in deConz) (current heating setpoint changes - it's me, pressing buttons on the device) asdu_parsed.log

[Smanar]

So the device have realy this cluster, but deconz don't see it ?

For information It 's the page I have used for my device https://medium.com/@dzegarra/zigbee2mqtt-how-to-add-support-for-a-new-tuya-based-device-part-2-5492707e882d

But I have stopped the integration because no more return. I can try to add your at the code, will be easier most of the code is already in place.

I m on another device ATM, give me 1 / 2 days pls.

[Smanar]

If you have some time. Can you make a try with this branch

git clone --branch tuya https://github.com/Smanar/deconz-rest-plugin.git

Nothing will work, it s just to test the integration, I have just added the device in whitelist and add the tuya cluster for the device creation. If it 's good, you will have this device in the API and with zhathermostat type.

I m not sure it will work because the api use information from deconz, and on deconz the tuya cluster is invisible (and I realy don't understand why after so much tries)

Make a backup of the libde_rest_plugin.so file in an other folder for rollback (before the remplacement)

[vegetate7]

I'm afraid I can not. I run deconz as HASS.IO addon in docker. I can not even build it. Tho I think I can replace libde_rest_plugin.so in the docker tree, If somebody compile it for armhf arch :)

[vegetate7]

Ok. Successfully made a qt-deconz build container. Built libde_rest_plugin.so from your branch. replaced it and general.xml. Results: deconz logs periodically freezing, same for deconz-gui (on VNC). Websocket reconnecting. in logs sometime new string: '05:59:00:914 Tuya : debug 44' in the gui - the device node have new type 'ffff' instead of 'On/Off Switch' and only one 'basic' cluster without attributes (see the picture)

Reverted .so to original.

[Smanar]

Arf, my bad, was the previous code for the switch, but don't see how it can provoke that .... I need to clean it first, you have keeped the log ?

[vegetate7]

I don't collect logs. But I keeped .so :) Can run it again if need.

[Smanar]

I m checking the code again, and the only hacky part is in file de_web_plugin.cpp line 1614. I create 2 fakes endpoint. You can disable this part with changing if (node->nodeDescriptor().manufacturerCode() == VENDOR_EMBER)

in

if (node->nodeDescriptor().manufacturerCode() == 0xAAAA)

All the rest is standard.

You can too disable the tuya managment part used for the switch in line 707 (it s this part that print 'debug 44')

        case TUYA_CLUSTER_ID:
            // Tuya manfacture cluster:
            //handleTuyaClusterIndication(ind, zclFrame);
            break;

Just with adding // at the 3th line

[vegetate7]

Actually 'Tuya: debug 44' is whre ON/OFF handled, and it apears when I'm using Tuya wired switch (I have some). I tried change to 'if (node->nodeDescriptor().manufacturerCode() == 0x0000)' - which is acually manufacturer code of my device. Nothing special, the node have one (basic) cluster, and it's attributes after some delay.

In the same time my Xiaomi Mijia Motion sensor also changed (it have manufacturerCode == 0x0000 too). It lost 'basic' cluster, and have only 'Occupancy sensing' (0x0406) cluster without attributes. It's about same as main branch, where my motionsensor have 2 clusters ( 0 and 406), both without attributes.

Then I changed to 'if (node->nodeDescriptor().manufacturerCode() == 0xAAAA)' . This will not affect any of my devices, because I do not have any with that manufacturerCode.

WRT websocket disconnects: is your branch based on 2.05.77 or earlier version? I see lot of diff's against main git. I think disconnects related to something what was fixed in 2.05.78.

Reverted to original .so again. (have some logs collected this time :)

[Smanar]

Yep using 0xAAAA was for disable this code part, because I m seing only this part to freeze deconz on your situation. And if you haven't problem with it (freeze and websoket disconnect), it mean I m right, but I m making

if (sd && (sd->deviceId() == DEV_ID_SMART_PLUG) && (node->simpleDescriptors().size() < 2))

And your device is not DEV_ID_SMART_PLUG but DEV_ID_ONOFF_SWITCH so I don't understand why it'a a problem.

And yes, this code is old, right, I have just updated the code with actual master, changes are easier to check now > https://github.com/dresden-elektronik/deconz-rest-plugin/compare/master...Smanar:tuya

[vegetate7]

Ok, I've built plugin from updated code. Deleted node, permit join, started join on device. Result: have a node with 4 clusters (2 blue, 2 grayed), all clusters with attribute count in parentheses but no attributes in 'Cluster Info' panel. Waited long time, no changes. Permit join again without deleting of node, started join on device. Result: have a node with 4 clusters (2 blue, 2 grayed), all clusters with attribute count in parentheses and all attributes shown in 'Cluster Info' panel. Node type is 'On/Off Switch'. No special cluster '0xef00', but device sending FP indications.

[vegetate7]

Just wondering. If a cluster not reported while descriptions read. Should not it be added when Indication from that cluster received?

[Smanar]

Yep, or I can just make like I m seing it in the api code. You can see the device in the API ? No more "critic" bug in deconz ?

[vegetate7]

Yes, "citic" bug is gone. Now I can keep modified .so , it is not prevent regular usage of all other devices. No, the device still not visible in API.

I am not familiar with the project, so all is just my guessing. I started to dig down to the sources, and think LightNode is not created at all for this node. May be because SimpleDescriptors not fulfilled. Some logs may be helpful:

1. Node deleted, device rejoined: deconz.smanar.pr9.1.log

2. Device rejoined again without node deletion: deconz.smanar.pr9.repeat_join.log See now it passes

   05:08:43:279 [1] get node descriptor for 0xec1bbdfffe94645a
   05:08:58:128 ZDP indication search sensors 0xEC1BBDFFFE94645A (0x1524) cluster 0x8002

   and

   05:08:58:157 [2] get active endpoints for 0xec1bbdfffe94645a
   05:08:58:493 ZDP indication search sensors 0xEC1BBDFFFE94645A (0x1524) cluster 0x8005

   But not go further. No endpoints received? Then I made changes in 'de_web_plugin.cpp' to

   //    if (node->nodeDescriptor().manufacturerCode() == VENDOR_EMBER)
   if (node->nodeDescriptor().manufacturerCode() == VENDOR_NONE)
   ....
   //        if (sd && (sd->deviceId() == DEV_ID_SMART_PLUG) && (node->simpleDescriptors().size() < 2))
       if (sd && (sd->deviceId() == DEV_ID_ONOFF_SWITCH))

   I do not think it has an effect, because no "Tuya: debug .." in logs, just for the sake of true Device deleted and rejoined ( and later rejoined again): deconz.my.no_restriction.log

Now passed:

06:51:06:679 [1] get node descriptor for 0xec1bbdfffe94645a
06:51:25:633 ZDP indication search sensors 0xEC1BBDFFFE94645A (0xF336) cluster 0x8002
...
06:51:25:638 [2] get active endpoints for 0xec1bbdfffe94645a
06:51:27:767 ZDP indication search sensors 0xEC1BBDFFFE94645A (0xF336) cluster 0x8005 // (TWISE for unknown reason!)
...
06:51:27:774 [3] get simple descriptor 0x01 for 0xec1bbdfffe94645a
06:51:28:777 ZDP indication search sensors 0xEC1BBDFFFE94645A (0xF336) cluster 0x8004
...
06:51:28:782 [4] get basic cluster attr 0x0004 for 0xec1bbdfffe94645a
.....

But no LightNode created :(

[Smanar]

Yep the part

if (sd && (sd->deviceId() == DEV_ID_SMART_PLUG) && (node->simpleDescriptors().size() < 2))

Is only for lightnode, so you can let it as it.

It seem this device is working but is realy lazy, at every try the pairing is working better. Do you have a way to keep it awake during inclusion ? Like a short pression on a button every seconds ?

I have add some debug line to checl the code after the "[4] get basic cluster" > https://github.com/Smanar/deconz-rest-plugin/commit/8c24b2e8f3c8ef34a88ffd6abd5198ac3bc41417

[vegetate7]

I've built new plugin. Deleted node, permit join, started join on device keeping pressing buttons to get device awaken. All clusters read at first attempt, but no '0xEF00' cluster. Have 'Tuya debug 88' in the log. After 10 minutes, permit join without deleting node, started join on device keeping pressing buttons to get device awaken. Nothing new. No new cluster, but nothink broke as well :) Log attached. deconz.smanar.pr9.add_debug.repeat_join.log

PS: No sensor or light in API as well.

[Smanar]

Ok So that I m understanding

• The device ask for basic attribute in order : 0004 / 0005 / 0400
• Then it will be blocked
• On second try, the api know this device havent sw build id so It ask for attribute 0006 instead of 0400
• All was fine now, so the code try to create node > addSensorNode(node); (just after "Tuya debug 88")

But no result, perhaps because there is no usefull cluster for it, I have modified the code to add a fake information according to model id, and some more debug line in the fonction addSensorNode https://github.com/Smanar/deconz-rest-plugin/commit/0cc60f566b1c36924fd9730e6fd6232909a75a51

[vegetate7]

I've built new plugin once more. Deleted node, permit join, started join on device keeping pressing buttons to get device awaken. Node appears in GUI with on e 'basic' cluster and no attributes. Wait some time. Permit join without deleting node, started join on device keeping pressing buttons to get device awaken. Node in GUI now shows as usual 4 clusters, but that time 'Node name' was set to 'kud7u2l' Phoscon WebApp show "Sensor Ready", but no new sensor added. API show sensor node:

    "29": {
        "config": {
            "heatsetpoint": null,
            "offset": 0,
            "on": true,
            "reachable": true,
            "scheduler": null,
            "scheduleron": null
        },
        "ep": 1,
        "etag": "3c29f0012a7fe10864a0daf2714ba140",
        "lastseen": "2020-07-14T16:15:49.331",
        "manufacturername": "_TYST11_ckud7u2l",
        "modelid": "kud7u2l",
        "name": "kud7u2l",
        "state": {
            "lastupdated": "none",
            "on": null,
            "temperature": null
        },
        "swversion": "20180727",
        "type": "ZHAThermostat",
        "uniqueid": "ec:1b:bd:ff:fe:94:64:5a-01"
    }

and HomeAssistant show new device on deConz integration (not working, but exists at least):

log: deconz.smanar.pr9.fake_info.repeat_join.log

After restarting deConz - all disappeared. Only node in GUI lasts without 'NodeName' again. :(

PS: Please add "\n" in "Tuya: debug .. " stings :)

[vegetate7]

Little more experiments results: Not need to push key for keep device awake when joining. It not reads first time, but reads second time.

[Smanar]

Phoscon WebApp show "Sensor Ready", but no new sensor added.

This is normal, you will see then sensor only in the api, for the rest still a mystery, why you have a different result at every try ?

BTW, the device is created (even it don't stay for the moment) So I can continue the code to make it updating his value.

[Smanar]

I have started to implement it, the temperature to start, not finished at all, not tested (so you can have error) But if you want to take a look https://github.com/Smanar/deconz-rest-plugin/commit/8730c076eea069d19232bf3cb08f3561162b8285

With this actual code, you will have a debug every time the device will use the tuya cluster DBG_Printf(DBG_INFO, "Tuya debug 4: status: %d transid: %d dp: %d fn: %d\n", status , transid , dp , fn );

[vegetate7]

Not compiling:

de_web_plugin.cpp:13386:76: error: ‘zclFrame.deCONZ::ZclFrame::payload’ does not have class type
    DBG_Printf(DBG_INFO, "Tuya : debug 1 : size %d\n",static_cast<int>(zclFrame.payload.size()));

Changed line to

DBG_Printf(DBG_INFO, "Tuya : debug 1 : size %d\n",static_cast<int>(zclFrame.payload().size()));

[SwoopX]

Correct. It also doesn't need the static cast.

[vegetate7]

Ok, I'll keep as is until your update ;) Built new code. Join procedure still same: first join create only node, second join create sensor. Device reporting now visible ("Tuya debug 4 ... " in logs). Log attached, if may be helpful. deconz.smanar.pr9.tuya_cluster.log

[Smanar]

Thx, I will take a look tomorrow. BTW I have speaked with manup with the cluster problem, are you using the modified general.xml ? Don't worry It can't break your installation, but from him, unknow cluster are created during permit join, but other cluster can be added later.

And your device make request after the permit join

01:46:06:776 APS-DATA.indication srcAddr: 0x9d18, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0xEF00, lqi: 255, rssi: -39

So if deconz know this cluster (because of xml file) perhaps it will be added during usage.

Edit: BTW you had exactly the debug I need

01:05:44:110 Tuya debug 4: status: 13 transid: 137 dp: 514 fn: 0

The temperature haven't been updated ?

For information data are always 0 because I m using only the first one ATM, the temperature is the 4 for you, I will update this debug information tommorow

[vegetate7]

Yes, I'm using modified general.xml from your branch. May be I wrong placed it, but only path I found is /usr/share/deCONZ/zcl/general.xml. Cluster not added. I'll look also tomorrow, but i think one hour will be enough for update.

The temperature haven't been updated ?

Updated. Show 20 degree (which is wrong, because 26.5 here :)

{
    "config": {
        "heatsetpoint": null,
        "offset": 0,
        "on": true,
        "reachable": true,
        "scheduler": null,
        "scheduleron": null
    },
    "ep": 1,
    "etag": "49fc9b5432f19bd8b16dff816fd7d369",
    "lastseen": "2020-07-15T19:04:42.653",
    "manufacturername": "_TYST11_ckud7u2l",
    "modelid": "kud7u2l",
    "name": "kud7u2l",
    "state": {
        "lastupdated": "none",
        "on": null,
        "temperature": 2000
    },
    "swversion": "20180727",
    "type": "ZHAThermostat",
    "uniqueid": "ec:1b:bd:ff:fe:94:64:5a-01"
}

[Smanar]

Yes, I have hardcoded 20 to test. I have updated the code, now I can read the data value, so I hope the real temperature. But I don't know the format, so will be a surprise.

And yes, you are right it s the good file, so it seem it s not working :(

Now I m adding the heatsetpoint and the state/on.

[vegetate7]

Temperature reported as signed integer, hed, LittleEnding.

ok. 28C actual temperature in the room .

{
    "config": {
        "heatsetpoint": null,
        "offset": 0,
        "on": true,
        "reachable": true,
        "scheduler": null,
        "scheduleron": null
    },
    "ep": 1,
    "etag": "a293fd8a73711e57647952d37b55d92c",
    "lastseen": "2020-07-16T18:11:17.982",
    "manufacturername": "_TYST11_ckud7u2l",
    "modelid": "kud7u2l",
    "name": "kud7u2l",
    "state": {
        "lastupdated": "none",
        "on": null,
        "temperature": 280
    },
    "type": "ZHAThermostat",
    "uniqueid": "ec:1b:bd:ff:fe:94:64:5a-01"
}

But in HA it is divided by 100 for unknown reason.

Logs: deconz.smanar.pr9.temperature.log

btw...

00:07:07:834 Tuya debug : lenght exxcess00:07:07:834 Tuya debug 4: status: 15 transid: 18 dp: 112 fn: 0

dp 112 and 113 are workdays and holidays schedules. This works for me. perl, but just for an idea:

    case 112 {
    #: // set schedule for workdays [6,0,20,8,0,15,11,30,15,12,30,15,17,30,20,22,0,15]
        #// 6:00 - 20*, 8:00 - 15*, 11:30 - 15*, 12:30 - 15*, 17:30 - 20*, 22:00 - 15*
        return {'0x7000 workdays schedule' => [
            {hour => $data[0], minute => $data[1], temperature => $data[2]},
            {hour => $data[3], minute => $data[4], temperature => $data[5]},
            {hour => $data[6], minute => $data[7], temperature => $data[8]},
            {hour => $data[9], minute => $data[10], temperature => $data[11]},
            {hour => $data[12], minute => $data[13], temperature => $data[14]},
            {hour => $data[15], minute => $data[16], temperature => $data[17]},
        ]};
        }
    case 113 {
        #: // set schedule for holidays [6,0,20,8,0,15,11,30,15,12,30,15,17,30,20,22,0,15]
        #// 6:00 - 20*, 8:00 - 15*, 11:30 - 15*, 12:30 - 15*, 17:30 - 20*, 22:00 - 15*
        return {'0x7100 holydays schedule' => [
            {hour => $data[0], minute => $data[1], temperature => $data[2]},
            {hour => $data[3], minute => $data[4], temperature => $data[5]},
            {hour => $data[6], minute => $data[7], temperature => $data[8]},
            {hour => $data[9], minute => $data[10], temperature => $data[11]},
            {hour => $data[12], minute => $data[13], temperature => $data[14]},
            {hour => $data[15], minute => $data[16], temperature => $data[17]},
        ]};
        }

[Smanar]

I have corrected the temperature

00:07:07:834 Tuya debug : lenght exxcess

Yes for the moment the code support max 4 octed data, so don't support schedule yet.

I have updated the code with last deconz version, and have started to implement the first command {"heatsetpoint":1234}, but haven't compiled the code yet, and big change. So I m sure it will not compile. When it will work We realy need to make a file just for tuya cluster to much hack ATM.

[vegetate7]

I couldn't resist, and compiled new code :) (added 'static void copyTaskReq(...)' function, actually copied it from thermostat.cpp and missed typedef 'bool ok;' in 'SendTuyaRequest'). Code compiles and starts. Now HA shows right Room temp, and Heatpoint temp. All attempts to change Heatpoint ends with Heatpoint dropped to 5* ('0x6602 min_temperature' I think).

Logs: deconz.smanar.TRV.set_heatpoint.log

[Smanar]

It s strange, on my code I m trying a fake value

QByteArray data = QByteArray("\x00\x00\x00\xff",4);

So you will have [ 0, 0, 0, 255] so 25,5 degrée, can you try "\x00\x00\xff\xff" for test ?

[vegetate7]

Ok. I tried "\x00\x00\xff\x00", and heatpoint was set to 25.5. Perhaps exess byte added? So I commented out "stream << (quint8) 0x41; // deCONZ::ZclOctedString" in SendTuyaRequest, 'zigbee-herdsman-converters' also do not put this into message. And now all works as intended. "\x00\x00\x00\xff" sets 25.5 "\x00\x00\x01\x0e" sets 27.0

[Smanar]

Good catch ! I m not using type for TransID, dp, fn, but I want to use one for data ^^.

So all is possible now. I will make a clean file just for tuya, and add the "mode", but yes, now we can finish this device without problem.

[Smanar]

Ok so I have cleaned a little the code, compiled and working.

Now you can set the heatpoint, but perhaps the convertion will be bad.

Then I have add the "mode" to the device, not compiled, so can have compilation error, you need to re-include the device, to have a new json with "mode", or if you have deconz with GUI, just set phoscon in permit join and read again basic attributes.

Mode available : auto off manual

[vegetate7]

It compiles. Heatpont set works good, only you need to divide 'heatsetpoint' to 10.

  data.append((qint8)(((heatsetpoint / 10) >> 8) & 0xff));
  data.append((qint8)((heatsetpoint / 10) & 0xff));

Modes switched (somehow), but need testing. I'll test it a bit later.

[Smanar]

Corrected. I have added missing mode and battery.

[vegetate7]

WRT modes. All good except 'manual' mode. API displaying modes correctly (tested all, but 'complex', I think the device not have it). But HA expects to see 'heat' instead of 'manual', and displays 'Off'. And also sets 'heat', therefore I can not set 'manual' mode from HA. IDK, may be it is the was how the deConz exporting node to HA. But I have not even idea where to begin investigation. This is how the Thermostat node looks in developer tools of HA:

Can not test battery, the device not reporting it. Or may be not reporting while battery is full.

PS: Couldn't you make this 'i' signed, just for shut off warning:

tuya.cpp:292:24: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
     for (uint i = 0; i < data.length(); i++)

And also, would be nice to make 'Tuya debug 4' data informative. the "%lld" show junk most of the time. I changed to

DBG_Printf(DBG_INFO, "Tuya debug 4: status: %d transid: %d dp: %d fn: %d payload %s\n", status ,
transid , dp , fn , qPrintable(zclFrame.payload().toHex()));

but perhaps there is more beautiful solution,

[Smanar]

uint > int : done

For tuya debug 4, the payload is converted to a number directly exploitable by code, so I m agree It have nothing to see with value, but I don't understand the "junk" ?

DBG_Printf(DBG_INFO, "Tuya debug 4: status: %d transid: %d dp: %d fn: %d data %lld\n", status , transid , dp , fn , data);

But yes, can use both if need.

For battery I can be wrong, you can juste take a look in your log if you see dp =533 somewhere.

For the mode there is a problem, it s realy tuya mode, so ATM it s a valve for heating, but can be one for water or air conditionning. So the "auto" is not necessary a "heat" fonction. We can put a hack if the user send a "heat", convert the "mode " in "auto", but in websocket HA will receive mode = auto. For me the modification need to be done on HA side.

[vegetate7]

but I don't understand the "junk"

It shows very long negative integer for me. like this:

11:04:15:071 Tuya debug 4: status: 22 transid: 206 dp: 1028 fn: 0 data -4715851447940415487

For battery I can be wrong, you can juste take a look in your log if you see dp =533 somewhere

Never seen this in logs. It's sad, because i'd like to know when the battery goes out, But it is the device problem, not code.

'heat' need to be converted to 'manual', but agree, it's a hack. I think probles is in where device template generated, when decons device exported/imported to HA. 'hvac_modes' == 'auto,heat,off' is very restrictive, but I can not find where it is get from. Must be some kind of dictionary...

BTW can I update deconz to 2.05.79?

[Smanar]

Ha ? Its a bug, not normal, for dp = 1028 you need to have 0 / 1 or 2 ^^ But it works on code, so surely a display bug (or signed / unsigned problem), need to take a look.

Sure you can update, this code is based on 79 version, so will be compatible.

But the hack need to be done on both side. If HA send me a "heat" I can convert it in "auto", but it will send a "auto" to HA by websocket. I can put a patch for the moment to convert it again according to device id, but will be realy an ugly patch. If you can see something on HA side ?

[vegetate7]

Ha ? Its a bug, not normal, for dp = 1028 you need to have 0 / 1 or 2 ^^ But it works on code, so surely a display bug (or signed / unsigned problem), need to take a look.

Yes, HA. But i think it is a OS/Arch conversion problem. Not a stopper, actually :)

WRT modes. My opinion. hvac_modes are hardcoded in HA's decons component. Moreover we fighting wrong direction. hvac_mode - is a nature of device. Is it a heater or ventilation or air conditioner. Or combination of those. The device's 'mode' more like a 'preset' in HA mentioning. DP 1028, Data: 0: 'holiday' (set temp, and days count), 1: 'auto' (set schedules), 2: 'manual' (set persistent temp), 3: 'comfort' (day icon, set comfort temp), 4: 'eco' (night icon, set energy saving temp), 5: 'boost' (open valve for set amount of time), 6: 'complex' (my device have not this),

And HA 'mode' for device must be other subject. 'off', 'heat', 'auto': Mode 'Off': set DP 1130, Data 2 (Force mode on, valve closed) Mode 'heat': set DP 1130, Data 1 (Force mode on, valve opened) Mode 'auto': set DP 1130, Data 0 (Force mode off)

And feedback from device - 'state' of entity based of valve position: DP 621, Data : integer percent of valve opened. Valve >0%: state = 'heating' Valve = 0% if DP 1130, Data 0 (force mode off) state = 'idle' if DP 1130, Data 0 (force mode off) state = 'off'

Something like this :)

PS: Or may be use 'hvac_action' as feedback from device, and entity state as 'hvac_mode': 'off', 'heat', 'auto' (that's how it is done for HA's virtual thermostat)

[vegetate7]

Ahh. Forget about this. HA's deconz component not dealing with presets, and decons_rest_plugin too. May be only this may be implemented:

And HA 'mode' for device must be other subject. 'off', 'heat', 'auto': Mode 'Off': set DP 1130, Data 2 (Force mode on, valve closed) Mode 'heat': set DP 1130, Data 1 (Force mode on, valve opened) Mode 'auto': set DP 1130, Data 0 (Force mode off)