LIDL SilverCrest Smart Radiator Thermostat

[synatis]

Device

• Product name: LIDL SilverCrest Smart Radiator Thermostat
• Manufacturer: _TZE200_chyvmhay
• Model identifier: TS0601
• Device type : Thermostat

Screenshots

Endpoint and Node Info

Basic

Groups

Scenes

Thermostat

[rikroe]

Ok, so I got the lidl_trv branch set up and a thermostat connected. All tests were directly against the REST API (just verified in HA).

Bugs I found:

• After setting {"mode": "off"} via REST, the device shows a temperature of 0.5 (correct, also shown in REST API) but the returned mode in config is heat instead of off. https://gist.github.com/rikroe/b5e242635148f9d7673015ce33cd6eee#file-_deconz_logs_off_heat-log
• When mode is heat or off, I cannot send {"mode": "auto"}. This results in the following REST API error:

  [
   {
        "error": {
            "address": "/sensors/7/config/mode",
            "description": "Could not set attribute",
            "type": 608
        }
    }
  ]

  Log: https://gist.github.com/rikroe/b5e242635148f9d7673015ce33cd6eee#file-_deconz_logs_auto-log When sending a new (or previous) heatsetpoint, the device resets itself to auto.

Other notes:

• If mode is set to heat, the device will show 50.0° (not sure if this is good or bad)
• The current temperature from both heat and off (50° & 0.5°) is not reflected in the heatsetpoint in the REST API - there is still the 17.0° that were "scheduled"
• Regarding scheduling: I was under the impression (from what I was able to read from the code changes) that the schedule could be displayed in the REST API, however it is not visible.
  • Enabling schedules would help me personally, as I could ignore Moon/Sun temperatures completely and overwrite them via Schedule. Looking at the Thermostat Cluster in VNC it looks as if the vacation mode could also be implemented like this.
• Does the device maybe support Occupied Heating/Cooling Setpoint for Moon/Sun temperatures?

I think with the basic bugs fixed, the initial support could be added (i.e. having only one temperature to control and setting this from some 3rd party system). However it would be great if we get to the point where we are able to set both setpoints, the manual temperature and the schedule (including vacation) at a later date.

[rikroe]

Mhh, after leaving it alone for a time, the thermostat or deconz decided to stop playing with each other nicely. Mode is still set to auto with 17.5° on the TRV, but the REST API reports heat with 20.0.

This is the log where the change has to become visible (it happened at 11:52:50 according to HA): https://gist.github.com/rikroe/b5e242635148f9d7673015ce33cd6eee#file-_decons_logs_incorrect-log

I also cannot set it to auto by setting the new (old) heatsetpoint - mode heat stays displayed. https://gist.github.com/rikroe/b5e242635148f9d7673015ce33cd6eee#file-_deconz_logs_heatsetpoint_ok_wrong_mode-log

PS: If there is anything I can do to clean these logs for you, please let me know!

EDIT: just realized the TRV showed manual mode as well, my bad. Still it would be great to be able to force automatic mode and discard everything else.

[Smanar]

Hu, pls decide first what you want to do with it. ATM I m using a "set value 0.5 °C" for "off" and "set value 50 °C" for "heat", It seem you are not agree with this mode So I have proposed this one

• "heat" > "manu" with a temperature value just for heat.
• "auto" > "auto" with 1 temperature ( the "sun" and T-4 °C for the second one, the "moon") or with a second temperature setting
• "off" > the "away" mode, but haven't checked how it work yet.

However it would be great if we get to the point where we are able to set both setpoints, the manual temperature and the schedule (including vacation) at a later date.

I have too an "eco" temperature not used yet, for me it's the moon temperature. I can add it if needed, will be fast.

But the "off" mode is probably the "vacation" = "away" mode ? This mode work with a shedule ? And If I have understand it don't use mon and sun ? Or it use "moon" and "sun" from shedule part ?

[MisterPascal]

it seems like there is still some confusion about the functions of the thermostat. here is a manual from another thermostat, but the functions are completely identical to those of the lidl thermostat. i hope it creates some clarity.

[rikroe]

After putting some thought to it I do now agree with what your planning regarding the modes:

• "heat" > "manu" with high temperature valve (TRV currently shows 50, don't know if that is too much)
• "auto" > "auto" with sun & moon temperatures
  • on other TRVs like this this uses the TRV's schedule function
  • if the schedule can be read & written via deconz that would be great, otherwise this has to be done on the thermostat
  • the schedule would be in the REST API for now as 3rd party systems don't understand it yet (i.e. custom command)
• "off" > "off/manu" with 0.5 degrees is fine
  • my issue was that when setting "manu" with 0.5 degrees it will be shown as "heat" mode in REST API & HA which it is not -> it should be mode "off"

It is important to note, that as soon as you reach a time point where a schedule is set, "manu" modes will be overwritten by the respective schedule. They do not stay forever.

However there seems to be one bug where heatsetpoint and temperature are not loaded correctly from the thermostat. The TRV shows 21.5°, but the heatsetpoint is 20.0°. Also the measured temperature dropped to a default 16.0° for some time before starting to show real values. You can find the logs +-5 seconds of the respective events here: https://gist.github.com/rikroe/17835cc1c20456ce42cd4727a31ac22e At 18:15:36, the device resets to 20.0°/16.0°. At 18:59:10, the measured value again is ok (20.9 instead of 16.0) but setpoint is still 20.0 (while device show 21.5°).

I think we should get this basic functionality going first (so everything above), then we could talk e.g. about vacation mode or the second (and actually third) setpoint this thermostat has.

• On other thermostats vacation mode is a sort of "override" on auto mode - you define a temperature and an end date and the thermostat will continue to keep this temperature and not use the "normal" schedule again.
• Sun & moon temperatures are NOT what is scheduled (thats what the schedule is for). They're more or less indications and help you set the thermostat up as they are the defaults for a schedule when you set it up manually on the TRV.

Many, many thanks for your help! Really appreciate what your doing when you do not even have the device available!

[Smanar]

It is important to note, that as soon as you reach a time point where a schedule is set, "manu" modes will be overwritten by the respective schedule. They do not stay forever.

Haaaaa, ok it s that the secret that make the "manu" return to "auto" but not all the time ?

if the schedule can be read & written via deconz that would be great, otherwise this has to be done on the thermostat the schedule would be in the REST API for now as 3rd party systems don't understand it yet (i.e. custom command)

Double Bingo. There is only 1 TRV where we have spend enought time to have the schedule finished and full working. And it's not used enought for third app use it, but if we make a "clean documentation" then can add it. But I can code it, I have all the commands on the previous link.

my issue was that when setting "manu" with 0.5 degrees it will be shown as "heat" mode in REST API & HA which it is not -> it should be mode "off"

Arf good catch, In fact it s normal, it's the "manu" mode (see as "heat") but with lower temperature, need to make a hack to solve that

"auto" > "auto" with sun & moon temperatures

Do you want to be able to set the both temperature ? or only one and deconz set the second one ?

Edit: I m looking your logs for the issue, it can be normal, there is no more report in the log. This kind of device is lazy, it s possible it work in "stand alone" mode for some time, before sending report to update the app

Edit 2: Have put a new version online

• off is 0°C now
• the "heat" displayed in "off" mode is probably solved (I prevent deconz use the "heat" mode if the heatpoint is 0 °C)
• Try to solve the problem where the "auto" mode is not settable (will display more debug line)
• On "auto" mode I m making a new try, instead of using the automodeheatpoint, I m using comfort and eco heatpoint, IDK what will happen on the device , In my mind will be the moon and sun temperature, but without shedule ....

[rikroe]

Glad that I can bring in some light :) Would love working on & documenting the TRV schedule API!

Also, just tried your latest version:

• Setting mode to off will now show OFF on the device's display 👍 The REST API still reports heatsetpoint of 2150 and mode heat :(
• I cannot use heatsetpoint anymore to return the mode to auto (but this might be correct, as we're consciously overwriting the heatsetpoint - going back to "full auto" should work by setting auto via mode or when the next timer triggers)
  • EDIT: After setting it to off, the only way to get the device back to auto where the physical keys. It however changed the temperature based on the schedule, while still showing manu on the device...
• Setting auto mode still doesn't work (but you can find the full log below)
• comfort and eco heatpoints are not visible to me in the REST API. But to seet them, I would need to see them, right? Otherwise, no changes on the device.

Full log from start (I can try to cut it down if you want): https://gist.github.com/rikroe/61b2deafffabfb236c34dd5e44b3a6f0

Regarding the temperatures:

• I think heatsetpoint is the most important temperature, as this is the currently set temperature on the device (either through an on-device schedule or due to being set manually on device or via deconz)
• sun & moon don't have any actual settings except that they are default temperatures when setting up a schedule and the icons just show you that you are in the "recommended" temperature
  • they might make sense when we implement a schedule, as then a home automation system could e.g. read sun & moon temperatures and use these for high/low schedules (probably on a schedule you have to define the temperature for each part of day, as you can set the temperature on the device randomly when you create a schedule)
  • I would try to expose comfort & eco heatpoints as additional settings in config, so that one is able to read and set all three temperatures

Regarding the lazy issue: Looking through my logs there seems as if some connection was dropped or whatever? In this case, could the REST API either display the last value or no value at all? It completely messes up the graphs (and is a lot of the time wrong with default values):

[Smanar]

Ok so new version to test, I think you will have work here

• Corrected the error when trying to set the "auto" mode
• Add the field "config/eco_heatsetpoint" and "config/confort_heatsetpoint", they can be updated by the device or using the API, but better first to wait for the device update the value itself to see how it work. Not used yet.
• Have made roolback to use previous tuya request for "auto" mode
• Have corrected an issue that make the "mode" can be not updated sometime.
• New test to have "off" in the API instead of "heat".

For the "off" mode, if it still not working yet (and it s possible, I haven't touched the temperature part) can you show logs returned by the device when you make the request.

To display "off" in the api, I m waiting for a "mode report", at this moment I m checking the heatpoint, if it s 0, I use mode = "off", but on your comment the temperature was bad, so it will probably not work.

The REST API still reports heatsetpoint of 2150 and mode heat :(

Edit: Have made a typo, its confort instead of comfort (almost same word in my country)

[rikroe]

Cool, we're getting there step by step :)

eco_heatsetpoint and confort_heatsetpoint seem to be the moon & sun temperatures. I can change them now via REST API! 👍

• Bug 1: There seems to be some factor issue when setting the value. I have to send {"confort_heatsetpoint": 220} to get a value of 22.0°. 2200 leads to 47.5° shown on the thermostat. When only reading the value it always shown correctly.
• Bug 2: At first the values für both additional setpoints are not read. They only show up in the config after one successfully sends a change. Maybe one has to actively poll these values? Full log from start until confort_heatsetpoint was set via REST API (sorry, don't know what else you need to figure out why it is null from the start): https://gist.github.com/rikroe/6c38b37ad08132b92b1be326ef16930a#file-comfort_heatsetpoint-log

Regarding modes:

• {"mode": "auto"} can now be set from REST API 👍
• {"mode": "heat"} changes the TRV to 50.0°. In REST API it shows mode heat, but heatsetpoint is 20.0. It should be either 21.5 (the value it was before) or 50.0. I think 20.0 is the default value if something cannot be read correctly
• {"mode": "off"} displays OFF on the TRV but still shows heat with heatsetpoint 20.0° in REST API

I think for both heat and especially off the check against heatsetpoint does not work, as the device does not report 0.0° in case of off but defaults to this 20.0° standard value. One thing I noticed (not sure if relevant): I clicked around in deCONZ VNC GUI and when I try to read attributes from there, it all always goes back to 20.0° heatsetpoint and 16.0° temperature. Last 45 seconds around sending "off" command: https://gist.github.com/rikroe/6c38b37ad08132b92b1be326ef16930a#file-mode_off-log

[Smanar]

Temperature send using the API need to be *100 . But it s strange I m using same convertion than for classic heatpoint ....

When only reading the value it always shown correctly

Mean if you let the device sned the value using report ? So the problem is in the request made to change the value ? Have same issue with "eco_heatsetpoint" ?

BTW, have corrected the typo, it s now comfort_heatsetpoint

At first the values für both additional setpoints are not read. They only show up in the config after one successfully sends a change. Maybe one has to actively poll these values?

Nope :(, Tuya cluster is special, can't make pool, we need to wait for the device send the report. There is a "Reset" Tuya command, but need to ask for confirmation for this one, can try this modification in the xml file, to be able to use this command in the GUI, but I have never used it (in the general.xml file)

https://github.com/dresden-elektronik/deconz-rest-plugin/commit/bedfab21633d8d81eb152abbe0f19a25dab3a541

And I have found 2 issues. The first one, you are right, the returned heatpoint seem not working

21:08:11:811 Tuya debug 4 : Address 0x0C4314FFFE73C758 Payload 00101002000400000000 21:08:11:812 Tuya debug 5 : Status: 0 Transid: 16 Dp: 528 (0x02,0x10) Fn: 0 Data 0 21:08:12:294 Websocket 172.17.0.1:34108 send message: {"config":{"battery":100,"confort_heatsetpoint":2200,"eco_heatsetpoint":1700,"heatsetpoint":2000,"locked":false,"mode":"heat","offset":0,"on":true,"reachable":true,"schedule":{},"schedule_on":false},"e":"changed","id":"7","r":"sensors","t":"event","uniqueid":"0c:43:14:ff:fe:73:c7:58-01-0201"} (ret = 293)

I haven't found the problem yet, so have just added some more debug line.

And the second one is the Thermostat cluster, you are right again, this cluster have always the same value 1600 and 2000. This cluster need to be ignored, it s not used by the device, because it use the tuya cluster.

So have modified the code for deconz don't make bind on this cluster, you need to re-include the device.

Old uniqueid":"0c:43:14:ff:fe:73:c7:58-01-0201 New uniqueid":"0c:43:14:ff:fe:73:c7:58-01-EF00

Edit: Ha nope, it seem the uniqueID will be the same

        if (sensorNode.fingerPrint().hasInCluster(THERMOSTAT_CLUSTER_ID) || sensorNode.fingerPrint().hasInCluster(TUYA_CLUSTER_ID))
        {
            clusterId = THERMOSTAT_CLUSTER_ID;
        }

[rikroe]

Cool! By now I looked a little into your code and started adding my own changes/debug lines. I messed something up so cannot give you the full logs but I'll try to adhere to your logs best as I can!

Temperature send using the API need to be *100 . But it s strange I m using same convertion than for classic heatpoint .... Mean if you let the device sned the value using report ? So the problem is in the request made to change the value ? Have same issue with "eco_heatsetpoint" ?

Yes. In tuya.cpp#L1109 you multiply by 100 for these two so you need to do rest_sensors.cpp as well ;)

BTW, have corrected the typo, it s now comfort_heatsetpoint

👍

Nope :(, Tuya cluster is special, can't make pool, we need to wait for the device send the report. There is a "Reset" Tuya command, but need to ask for confirmation for this one, can try this modification in the xml file, to be able to use this command in the GUI, but I have never used it (in the general.xml file)

Not sure what you mean here or where this reset function can be found. However I found that it seems to be possible to query the TRV using the status 0x02. If I execute the following, the TRV will send the current value of 0x0265, i.e. comfort_heatsetpoint:

And I have found 2 issues. The first one, you are right, the returned heatpoint seem not working I haven't found the problem yet, so have just added some more debug line.

When setting either mode heat or off, the temperatures 0.0° and 50.0° are reported correctly to deconz.

• In heat, your "Tuya debug heatpoint 2" is reached, and the temperature should be changed but it doesn't reflect in status. Is there some range limitation where everything outside range will be ignored automatically?
• In off "heatpoint 2" and "heatpoint 3" are reached. I think item2 in tuya.cpp#L1011 is null, leading to tuya.cpp#L1017 elevating to false.

And the second one is the Thermostat cluster, you are right again, this cluster have always the same value 1600 and 2000. This cluster need to be ignored, it s not used by the device, because it use the tuya cluster.

👍 works now, altough the device didn't go to sleep so couldn't test long-term. Will update tomorrow. EDIT: Testing over night looks good, no random drops to default values. 👍

[Smanar]

However I found that it seems to be possible to query the TRV using the status 0x02

Good to know, the command 0x02 is only used by the device, as reponse to a 0x00. The reset command need to be added to the xml file (/usr/share/deCONZ/zcl/general.xml) as on my PR. From my memory when using this request it force the device to send all values (using only 1 request). Will ask today to pipiche.

Use now /100 for eco and comfort.

In heat, your "Tuya debug heatpoint 2" is reached, and the temperature should be changed but it doesn't reflect in status. Is there some range limitation where everything outside range will be ignored automatically?

Good question ^^. I realy don't see what I m doing bad. Try to set "0" and "2" as value, I rememeber an issue with some device that return "0" as value, can be an ignored value, need to check.

I think item2 in tuya.cpp#L1011 is null

How it can be null ? the device always have the field "config/mode" no ? If you look yourself in the api, the "mode" is not "off", perhaps it s just a missing notification to HA.

[rikroe]

Sorry, item2 it is not null, my mistake. This is the code I currently use for debugging (I definitely have the from string parsers... but first time working on C++).

if ((productId == "Tuya_THD SilverCrest Smart Radiator Thermostat") and (temp == 0))
{
    ResourceItem *item = sensorNode->item(RConfigMode);

    QString mode = QLatin1String("off");

    DBG_Printf(DBG_INFO, "Tuya debug heatpoint 3. mode: %s, item: %s\n", mode.toUtf8(), item->toString());

    if (item)
    {
        bool item2test = (item->toString() != mode);

        DBG_Printf(DBG_INFO, "Tuya debug heatpoint 4. item2test: %s\n", item2test);
        if (item->toString() != mode)
        {
            DBG_Printf(DBG_INFO, "Tuya debug heatpoint 4\n");
            item->setValue(mode);
            enqueueEvent(Event(RSensors, RConfigMode, sensorNode->id(), item));
            update = true;
        }
    }
}

When setting mode off via REST API, the following debug logs are created:

20:47:27:604 Tuya debug mode 1. dp: 402. mode: 1
20:47:27:604 Tuya debug mode 1
20:47:27:732 Tuya debug Request : Address 0x0C4314FFFE73C758, Endpoint 0x01, Command 0x02, Payload 00020204000101
20:47:27:732 Tuya debug 4 : Address 0x0C4314FFFE73C758 Payload 00020204000101
20:47:27:732 Tuya debug 5 : Status: 0 Transid: 2 Dp: 1026 (0x04,0x02) Fn: 0 Data 1
20:47:27:732 Tuya debug mode 1. dp: 402. mode: 1
20:47:27:732 Tuya debug mode 1
20:48:03:707 Tuya debug Request : Address 0x0C4314FFFE73C758, Endpoint 0x01, Command 0x02, Payload 00101002000400000000
20:48:03:707 Tuya debug 4 : Address 0x0C4314FFFE73C758 Payload 00101002000400000000
20:48:03:707 Tuya debug 5 : Status: 0 Transid: 16 Dp: 528 (0x02,0x10) Fn: 0 Data 0
20:48:03:707 Tuya debug heatpoint 1. dp: 210. temp: 0
20:48:03:707 Tuya debug heatpoint 2. temp: 0
20:48:03:707 Tuya debug heatpoint 2 - done. temp: 0
20:48:03:707 Tuya debug heatpoint 3. mode: @n�
, item: ���

20:48:03:708 Tuya debug heatpoint 4. item2test: (null)
20:48:03:992 Tuya debug Request : Address 0x0C4314FFFE73C758, Endpoint 0x01, Command 0x02, Payload 00101002000400000000
20:48:03:993 Tuya debug 4 : Address 0x0C4314FFFE73C758 Payload 00101002000400000000
20:48:03:993 Tuya debug 5 : Status: 0 Transid: 16 Dp: 528 (0x02,0x10) Fn: 0 Data 0
20:48:03:993 Tuya debug heatpoint 1. dp: 210. temp: 0
20:48:03:993 Tuya debug heatpoint 2. temp: 0
20:48:03:993 Tuya debug heatpoint 2 - done. temp: 0
20:48:03:993 Tuya debug heatpoint 3. mode: @:�
, item: ���

20:48:03:993 Tuya debug heatpoint 4. item2test: (null)

This shows that mode is correctly set to 1 (heat) and heatsetpoint to 0.0°. However I don't know why the last if does not elevate to true...

Also, there seems to be some other issue:

• I can set a heatsetpoint of 500 and will get [{"success":{"/sensors/7/config/heatsetpoint":500}}] returned from REST API. TRV also shows 5.0.
• With heatsetpoint of 500 and will get an empty response (but still HTTP code 200) returned from REST API, and TRV shows 4.0. But when just looking at the sensor via REST (GEE /api/API_KEY/sensors/7), then heatsetpoint is still 500.
• It is possible to go down to 100, but REST API will display nothing lower than 500.

  20:59:51:513 Tuya debug 5 : Status: 0 Transid: 105 Dp: 617 (0x02,0x69) Fn: 0 Data 10
  21:01:02:646 Tuya debug 5 : Status: 0 Transid: 105 Dp: 617 (0x02,0x69) Fn: 0 Data 8
  21:02:13:912 Tuya debug 5 : Status: 0 Transid: 105 Dp: 617 (0x02,0x69) Fn: 0 Data 6
  21:03:06:413 Tuya debug 5 : Status: 0 Transid: 105 Dp: 617 (0x02,0x69) Fn: 0 Data 2

• Sending heatsetpoint = 0 to the device will cause the device to reset to auto with standard temperature.

[rikroe]

Ok, did some further debugging (not sure if I'll be able to do any one the weekend) and I think I found the issue regarding heat instead of off.

It really seems that a heatsetpoint = 0 is the culprit. I don't really now how to get around this. After changing all heatsetpoint related temperatures in rest_sensors.cpp and tuya.cpp to 500 (or \x0A), a config read via REST API shows a heatsetpoint of 500 and finally mode off. Unfortunately the device now shows 5.0° instead of OFF as we had before with 0.

Probably thats something we have to take up with manup? Or who would be the best person to talk to?

[Smanar]

About the c++, try with

DBG_Printf(DBG_INFO, "Tuya debug heatpoint 3. mode: %s\n", qPrintable(mode));

Item is a class, not something displayable.

DBG_Printf(DBG_INFO, "Tuya debug heatpoint 4. item2test: %s\n", item2test);

item2test is not a string but a bool, so perhaps using instead %d.

I can set a heatsetpoint of 500 and will get [{"success":{"/sensors/7/config/heatsetpoint":500}}] returned from REST API. TRV also shows 5.0. With heatsetpoint of 500 and will get an empty response (but still HTTP code 200) returned from REST API, and TRV shows 4.0. But when just looking at the sensor via REST (GEE /api/API_KEY/sensors/7), then heatsetpoint is still 500.

Here I m not sure to understand, on the first line you have a return and not on the second one for the same command "heatpoint" = 500.

And I have found some explanation, heatsetpoint is locked

rItemDescriptors.emplace_back(ResourceItemDescriptor(DataTypeInt16, QVariant::Double, RConfigHeatSetpoint, 500, 3200));

Minimum value is 500, so we can send the 0 value, but the api don't accept the return.

And have similar problem here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5153

This device haven't "off" and "manu", and too much mode possible. So instead of trying to have same mode than classic TRV (using "config/mode"), I have proposed him to use the "config/preset".

[rikroe]

Thanks, figured out the qPrintable by myself already :)

I agree with you that maybe config/mode isn't the right value and preset might be better suited.

I checked the display, basically the modes on the TRV are auto, manu and away (instead of off). So if we implement vacation mode at some point, that would be the third mode.

And for OFF or BOOST (the current heat mode) we could use config/preset. This also seems to be used by the guys at https://github.com/Lavisx/lidl-valve-z2m/blob/main/lidl_radiator_valve.js you mentioned already.

I will take a look next week, won't have time over the weekend.

[Smanar]

I will take a look next week, won't have time over the weekend.

NP, I can do it for monday, will be fast, if you are agree, I will remove the config/mode and instead use config/preset with all mode.

• manu : that is not manual but auto with 1 temperature
• program with moon and sun
• boost
• away/holiday

(The "off" is not a real mode, and not specified on the manual so idk yet if we keep it, but if you still want it, better to keep it in config/mode, it will have only "off" and "auto" as mode)

And after that finish all mode, for exemple the away, I think the "program" is already able to work.

[jonny-379]

Hi, I don't know if this might help. I looked the Lidl device up on the ZigBee library https://zigbee.blakadder.com/Lidl_TVR01.html it says it is compatible with ZIGBEE2MQTT. Maybe there are some information that might help to debug the values and function from the thermostat.

[Smanar]

I have all values, it s not a problem, the problem is more how to integrate it. We can't ask to third app devs to rewrite all their code to make it compatible with all new device.

And making the API propose "standard/generic" commands, used by all devices.

[rikroe]

I think working via presets is a smart idea. However at least on the device, we would still need to set corrsponding mode values (and therefore also report them in REST API).

This is what I think we could need on the LIDL TRV (other TRVs might of course need different settings on device or don't expose everything):

TRV	preset	mode	heatsetpoint
Auto (using programmed schedule)	auto	auto mode = 0	from schedule
Manu (manual heatsetpoint until next scheduled timer)	manual	heat mode = 1	set via REST API
Vacation mode (keep one temperature until vacation mode is finished or preset switched back)	away	off mode = 2	set via vacation schedule
OFF mode on device	off	heat	0.0°
Boost mode	boost	heat	30°/50°

[Smanar]

There not the "off" in preset ^^. This mode is on the config/mode. Sorry it s me that decide "standars rules".

When it s TRC with only heat+ off + auto > "mode" When it s a on wall thermostat with 10 feature > "preset" But here ...

So if I use your tab, I need to do

• deconz preset = auto > send Tuya mode = 0 and set deconz mode to "auto"

• deconz preset = manual > send Tuya mode =1 and set deconz mode to "auto"

• deconz preset = away > send Tuya mode = 2 and set deconz mode to "auto"

• deconz mode = off > send Tuya mode = 1 and set temperature to 0°C and preset to "manual"

• deconz mode = heat > send Tuya mode = 1 and set temperature to 60°C and preset to "manual"

• deconz mode = auto > send Tuya mode = 1 and set temperature to "sun" temperature and preset to "manual"

You validate ?

[rikroe]

Looks fine 👍

On the last one I would also just go back to default scheduled mode:

• deconz mode = auto > send Tuya mode = 0 and do not set temperature and preset to "auto"

Also, if a heatsetpoint is manually send to the TRV, it should switch to preset = manual

[Smanar]

Ok so new version online, idk what can be the result.

Mode: on off auto Preset: auto manual away

Trying to reproduce the tab, have used 0°C and 60 °C for off and heat.

[steff75]

Here is the complete instruction manual online as PDF, because the printed manual from the package is not complete. https://stesbintegrationprod.blob.core.windows.net/public/articlemanual/2f64c92c-6d3c-4d50-9c05-7442f5da6107.pdf

I have now also bought 2 of these thermostats and compiled the deconz-rest-plugin from the lidl_trv branch. I'm not sure what the status is now, but currently when I change the heatsetpoint with the rest API, the device display value is not changed yet.

Thanks already for the progress so far with the thermostat integration!

[Smanar]

when I change the heatsetpoint with the rest API, the device display value is not changed yet

You mean the heat setpoint is not working ? Your device have same manufacture name ? Try in the both mode (you have 2 set heatpoint) one in "auto" the other in "heat"

[steff75]

Yes, you are right. In auto-mode I can change the heatsetpoint with the API. If I then switch to the preset "manual", then no more. The heat-mode sets the heatsetpoint to 60 °C and then also does not accept any change of the degree via the API in this mode.

I admit that the configuration with modes and presets still confuses me a bit with this thermostat. So far I had only one smart thermostat, the Danfoss Ally. There I am used to it, that this gets a heatsetpoint from the smart home and holds this temperature until it receives the next value.

What mode/preset combination is closest to that with the Silvercrest thermostat?

[Smanar]

For the moment, not comfirmed yet, but

    deconz preset = auto > send Tuya mode = 0 and set deconz mode to "auto"
    deconz preset = manual > send Tuya mode =1 and set deconz mode to "auto"
    deconz preset = away > send Tuya mode = 2 and set deconz mode to "auto"

    deconz mode = off > send Tuya mode = 1 and set temperature to 0°C and preset to "manual"
    deconz mode = heat > send Tuya mode = 1 and set temperature to 60°C and preset to "manual"
    deconz mode = auto > send Tuya mode = 1 and set temperature to "sun" temperature and preset to "manual"

So if I m right, if you set the preset = auto, it s the mode controlled by the schedule, not the set heatpoint. It was possible previously to set the heaeatpoint, so it's possible, but If I remember it was disabled to use instead the sun and moon temperature

config/comfort_heatsetpoint
config/eco_heatsetpoint

[Element2]

I believe the sun and moon temperature icons are only used to indicate any low and high temperature in a daily/weekly schedule. Low being a trivial (any) temperature which is lower then the high temperature, thus marked by a moon icon. High being a trivial (any) temperature which is higher then the low temperature and thus marked by a high icon. So the icons are schedule indications of high and low and NOT a specific value of temperature.

This schedule, including times and week days when it must heat high and when it must heat low can be programmed by hand on the device, using the buttons. However, a schedule can also be run automatically in the LIDL app. I am not sure if this is the same schedule as can be programmed on the device self.

It would be interesting to know if the LIDL app 'sends' the schedule to the device and it then runs it as an automated program on the device (if so THAT would be a nice feature to have) or that the LIDL app at the scheduled times in the LIDL app send a high temp and low temp setting to the device. If that is the case, the device is basically a dumb thermostat device and the LIDL app does the work.

The point of the above being. I believe the device is using two basic modes: Manual: The api sends only 1 heatpoint. Programmed: The api sends a schedule with week days and times and high and low heatpoints and then let the device run it OR a schedule can only be programmed by hand on the device via the buttons and then runs on the device as a program.

[rikroe]

I have a local version where I am using preset to build the boost/heat mode, therefore freeing heat alone to be activated when changing the temperature.

It's not finished, work got in the way but I should be able to get it some of it done this weekend and share with you for discussion.

The problem really is that the options you have on the device don't align with what home automation systems expect.

Edit: Yes, moon and sun are just just indicators. The device runs on schedule by default (doesn't matter if send via api or device, although we haven't figured the api part yet). If a manual temperature is set (I. E. Different from the current scheduled temp) the deivde shows manual. Problem is that home automation systems don't have a "manual" mode. There are auto, heat and off, the latter two being for dumb thermostats that can just be full on or off. Our device however always does some automatic control (except we would force it to e.g. with temperature 0 to set it to an unsupported OFF state.

In my mind we should ignore mode completely (always automatic) and rather figure out presets for boost/eco/away modes.

Also we need to figure out how to read the schedule from the device, as I wasn't able to do that yet. However schedule would be a second priority to me and personally as you can set the schedule on device.

[Element2]

@rikoe: Agreed. To transfer a schedule to the device is not a high priority. But, if you want to control a lot of individual heaters (I have 10+) you need a lot of thermostat devices. In that case the api/appication is generating a lot of traffic to manage all the individual schedules on the devices.

[Smanar]

From the doc here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5349#issuecomment-947478023

• Manual ( tuya mode = 1) use only 1 heatpoint.
• Auto (tuya mode = 0) "the device regulate the temperature beetwwen 2 temperatures" (Moon and Sun I presume).

You can set the program and it work on stand alone mode.

The problem really is that the options you have on the device don't align with what home automation systems expect.

Yeahh :(

Also we need to figure out how to read the schedule from the device

I don't think this a problem, the code have already a base, and we can find the command used on google. I m waiting for the rest is working before starting to put the schedule mode

[rikroe]

Almost 😀 maybe putting emphasis on heat & off temperatures was not smart as this is not really how the TRV is working.

@all: are OFF and BOOST modes needed? Or should they be excluded for now?

On auto (tuya mode 0) the device will work according to schedule. Sun & moon temperatures do not matter because you can schedule any temperature for a given weekday/time.

On manual (tuya mode 1) the device will keep a specific temperature until the next change from schedule, changing back to auto.

Tuya mode 3 is vacation mode but I think this is prio 3 after getting basic functionality + schedules working.

[Smanar]

are OFF and BOOST modes needed? Or should they be excluded for now?

Its 2 of the 3 modes used natively on third app ^^.

On auto (tuya mode 0) the device will work according to schedule. Sun & moon temperatures do not matter because you can schedule any temperature for a given weekday/time.

Ha, So on this mode the device don't use them ? So on wich one mode it use them ?

[ChristianH21220]

think Sun & moon (sun=standard heating temp / moon= Energy safe temp [night temp]) is used by the scheduler in the device.

As this device have a Button on the front of the devices, this can used to override the actice schedule (from the device) and use the selected heatpoint (sun or moon). At the next schedule (from the device) the selected mode is changed to the Mode from the shedule (from the device) sun or moon.

If we have one heatoint that can changed by the controller (smarthome hub/third app) then there is no need to use the scheduler from the device. The third app/controller do the job for schedule und heatpoint change. @Smanar: this singel heatpoint is the sun heatpoint - correct ?

A boost Mode is not needed (from my point of view) as the device don't have a boost Button like for example the eurotronic spirit TVR.

Vacation Mode is a nice Feature when the device scheduler is in use. Without the device scheduler this job can done as well by the controller/third App.

[rikroe]

Its 2 of the 3 modes used natively on third app ^^.

Not really in my opinion, as the TRV itself does much more than heat only (manual mode [tuya mode = 1] is keeping a temperature automatically) or just being off (vacation mode icon on the device instead of OFF for tuya mode = 2). To be honest, I don't fully get the reason for manual mode (on the device). Even when changing the temperature on the device, it stays in auto mode.

this singel heatpoint is the sun heatpoint - correct ?

You can already set the current target temperature via the heatsetpoint config. This is different from the sun heatpoint.

Sun & moon temperatures are used as default values for schedule, but you can overwrite them when setting a schedule. I'd keep them because they do no harm and one can quickly change between them by clicking a button on the device. Basically if you press the button on the device, the heatsetpoint attribute will change to either comfort_heatsetpoint or eco_heatsetpoint.

I would like to have a schedule on the device at some point because it is much more reliable against issues with your home automation setup as it is just contained on the device. Of course, adding a home automation controller tremendously improves the possibilities on how you can schedule it.

[Smanar]

So the next step is command to set the shedule for the "auto" mode ?

[pillemats]

@ALL: are OFF and BOOST modes needed? Or should they be excluded for now?

In my case off will be nice…. If its not possible to integrate now it is enough to temp low for „off“-mode

Hopefully to get work the trv in deconz because the 3rd app from lidl works terrible

Many thanks to all developers that work on that!!!

[rikroe]

So the next step is command to set the shedule for the "auto" mode ?

I'll try to check your changes on my TRV tonight. But from what you describe in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5349#issuecomment-962423760, I think we mixed some things up:

modes

tuya mode = 0 TRV shows auto. When send via deconz, just change tuya mode, device should switch back to scheduled temperature on its own.

tuya mode = 1 TRV shows Manu. 3rd parties will show "heat". Used when setting a manual (i.e. non-schedule temperature). Usually not set via deconz but by changing heatsetpoint to some other temperature.

tuya mode = 2 TRV shows vacation mode. 3rd parties will show "off". Not set directly by setting mode but with a special vacation mode command that includes end date/time and temperature during vacation mode.

presets

eco (or named off) Set tuya mode = 1 and heatsetpoint = 0. We might need to check with manup if we can remove the heatsetpoint reset.

boost Set tuya mode = 1 and heatsetpoint = 60. We might need to check with manup if we can remove the heatsetpoint reset.

That is the best understanding I have for this TRV, also based on what has been commented. Please correct me if you disagree.

@Smanar could you help implementing this logic? Thanks for your effort!

[ChristianH21220]

@rikroe: thx for the explanation regarding the shedule and sun/moon (comfort/eco heatpoint).

Agree to the modes as you wrote 👍 but why the presets should set eco to heatsetpoint 0 ? This is not eco, this is off. Eco should be the eco point (energy-heat) Off is separate and like you wrote -> heatpoint:0 without heatpoint reset

Boost (full power): fine but will this not better have a heatpoint reset after some minutes (maybe 5 min) to either comfort_heatsetpoint or the former value of the heatsetpoint before boost was called. Because if the device don't handle this via own firmware setting , it will produce a bad surprise if boost stay permanent on.

[rikroe]

The problem with the off mode you showed is that it the switch between the three is currently mapped to mode that can be one of auto, manual or vacation on the device itself.

@Smanar maybe could we change how preset and mode are handled on the device?

So tuya mode is mapped to deconz preset and vice versa? Deconz preset would be automatic, manual & away (for tuya modes 0, 1, 2). Deconz mode could be automatic, off, boost which set tuya mode 0 or 1 and a specific temperature for the latter two?

Agree that boost mode would be best with a timer, but don't know if that is possible.

[Smanar]

Yeah the timer is possible for boost from my memory, but it will another command, ATM we hare using heatpoint = 60°C and have see a boost command.

But tuya mode will be invisibles, just used by code. User need to see only deconz mode and deconz preset. Mode are not tuya mode, but deconz mode. In my mind all presets are automatic, away, schedule or sun/moon are auto for me. So mode can be off/ boost or auto (and auto mean enabling preset)

Note: As we have a config/eco_heatsetpoint, can use this value with the "manu" preset for the preset=eco

We might need to check with manup if we can remove the heatsetpoint rese

I think it will work with the online version. I can send the heatsetpoint = 0 °C, just the return can't be displayed, but if you look at the manual it s same for the device no ? (adjustement range is > 5°C and < 29.5 °C from the doc) So I m displaying "off" instead

I think we mixed some things up

Can you edit the table according to the working mode you want for preset and mode ?

but why the presets should set eco to heatsetpoint 0

This is not normal, probably an issue, "eco" as preset is not used by this device.

const std::array<KeyValMapTuyaSingle, 3> RConfigModeValuesTuya1 = { { {QLatin1String("auto"), {0x00}}, {QLatin1String("heat"), {0x01}}, {QLatin1String("off"), {0x02}} } };
const std::array<KeyMap, 3> RConfigPresetValuesTuya4 = { { {QLatin1String("auto")}, {QLatin1String("manual")}, {QLatin1String("away")} } };

[rikroe]

I have updated the table below. I think tuya modes don't matter that much, except for the first 3 (as they map to actual modes on the device).

TRV	deconz preset	deconz mode	tuya mode	heatsetpoint
Auto (using programmed schedule)	auto	auto	0	from schedule or set preset or mode to auto
Manu (manual heatsetpoint until next scheduled timer)	manual	auto	1	set by setting a temperature manually if no temp given, use sun temp
Vacation mode (keep one temperature until vacation mode is finished or preset switched back)	away	auto	2	set via vacation schedule command
Eco mode	eco	auto	0	use moon temp
OFF mode on device	-	off	1	0.0°
Boost mode	-	heat	1	60° for 5 minutes

Some findings from your current version:

• Changing heatsetpoint to be visible on TRV only works if TRV is in Auto mode.
• Deconz mode heat set TRV to 60° and Manu, but still shows deconz mode auto. deconz preset is manual
• Deconz mode heat set TRV to OFF and Manu, but still shows deconz mode auto. deconz preset is manual
• Setting deconz mode back to auto, seems not to work. Temperature is last temp before heat/off, but TRV still shows Manu. deconz preset is still manual

[Smanar]

Changing heatsetpoint to be visible on TRV only works if TRV is in Auto mode.

Was because I m using the setpointauto command only if deconz mode = auto. Now I m using the setpoint auto if deconz mode = auto AND deconz preset = auto, else use standard setpoint command

Setting deconz mode back to auto, seems not to work. Temperature is last temp before heat/off, but TRV still shows Manu. deconz preset is still manual

New version to test.

Have added "eco" preset, but I don't think it will be displayed in the API, it will change the mode to "auto" and set the temperature.

Deconz mode heat set TRV to 60° and Manu, but still shows deconz mode auto. deconz preset is manual Deconz mode heat set TRV to OFF and Manu, but still shows deconz mode auto. deconz preset is manual

Here we have a problem .. You set the device to mode = off, but after a time it will send a periodic report for his tuya mode = 1, and on the code I m using the second line of your tab.

Will try to set something in code, ignore all report for tuya mode if deconz mode is not "auto"

[rikroe]

Please find the my testing results and some tuya debug logs here: https://gist.github.com/rikroe/c06efa1f9c50147bd1c53db6f1866635#file-tuya_debug_2021-11-17t15_with_comment Full tuya debug logs (just grepped 'Tuya debug' to exclude all other spam): https://gist.github.com/rikroe/c06efa1f9c50147bd1c53db6f1866635#file-tuya_debug_2021-11-17t15_full

Unfortunately, reporting for OFF and boost is still broken.

Will try to set something in code, ignore all report for tuya mode if deconz mode is not "auto"

This will make it impossible to change mode on the device itself right (i.e. changing back from manu or vacation mode to auto on device keys)? I really think that we have to rely on the heatsetpoint, otherwise it will never be valid all the time.

Also, when changing modes, temperature on the TRV changes depending on the mode. But it seems the new temp data isn't send so I think we have to poll the temperature after tuya mode change.

Have added "eco" preset, but I don't think it will be displayed in the API, it will change the mode to "auto" and set the temperature.

Maybe automatically set mode "eco" in deconz if TRV temp = eco_heatsetpoint?

[Smanar]

This will make it impossible to change mode on the device itself right (i.e. changing back from manu or vacation mode to auto on device keys)?

Arf, yep, right.

I really think that we have to rely on the heatsetpoint, otherwise it will never be valid all the time

But the problem is the device send 2 reports, one for the temperature with setpoint = 0 °C, so ok its fine but later it send only tuya mode = 1 Can use a special preset = "forced" that can be set only by the device, and not the API, to remember thoses 2 special mode ?

Maybe automatically set mode "eco" in deconz if TRV temp = eco_heatsetpoint?

Yep but will have same problem than for "off" and "heat" when the device make a report just with tuya mode.

Also, when changing modes, temperature on the TRV changes depending on the mode. But it seems the new temp data isn't send so I think we have to poll the temperature after tuya mode change

Yes I m reading your logs ... How many temperature can be memorised by the device for different mode ? 1 heat Setpoint and 1 Auto Setpoint ( I say that because the device realy use 2 working mode for them) ? Someone have found a way to trigger a report (We can't pool tuya cluster) using the GUI with the tuya cluster, with mimic the request.

status 0
transid 0
dp = 0x0269 or 0x0210
fn = 0
and that you want as data.

Else the tuya application can work with that, so it s possible, we are already storing eco and comfort temperature, can store too 2 heatpoints.

[rikroe]

But the problem is the device send 2 reports, one for the temperature with setpoint = 0 °C, so ok its fine but later it send only tuya mode = 1 Can use a special preset = "forced" that can be set only by the device, and not the API, to remember thoses 2 special mode ?

Maybe in all 3 tuya attributes (heatsetpoint, mode, preset) we have to check against all 3 deconz values (again heatsetpoint, mode, preset) to figure out what is the correct combination in the end? So create a function that is always called when one of the three attributes from the TRV is changed?

How many temperature can be memorised by the device for different mode ?

I think 3: 1 for current value of auto (which gets overwritten from schedule), 1 for current value of manu and 1 for current value of vacation. When changing through the TRV modes, different memorized temperatures are displayed. Additionally there are the two values for eco_heatsetpoint and comfort_heatsetpoint.

Someone have found a way to trigger a report (We can't pool tuya cluster) using the GUI with the tuya cluster, with mimic the request.

Is there any way to test this? I.e. to be able to send a command like this via REST API?

[Smanar]

Why it so complicated, was so easy on his code https://github.com/Lavisx/lidl-valve-z2m/blob/main/lidl_radiator_valve.js Perhaps he manage the TRV only with code and never manualy.

So create a function that is always called when one of the three attributes from the TRV is changed?

But the problem is they are not changed in same time.

1 for current value of vacation

Lol, where this one is from ? I don't see it in tuya command. Perhpas it s from the vacation program ?

But if I m right the device make report, so even if the temperature is not updated in the API when changing the mode manualy, it will be updated after some time during the periodic report ?

Is there any way to test this? I.e. to be able to send a command like this via REST API?

He have do that using the GUI, I can reproduce the request with the code, but I don't remember wich one command he have used.

I can too just send the actual value memorised in the third app to the TRV at every mode change ?

[rikroe]

Checked the Javascript code too and I think it should be quite the same easy way for us.

• OFF and BOOST mode are only set via deconz and not on TRV. Receiving 0x0210 with either 0 or 120 will not update the deconz temperature, but just set deconz mode (and deconz preset for boost). 0 or 60° are not set to API, heatsetpoint stays.
• If either 0x0210 (Manu), 0x0269 (Auto) or the AwayTemp (to be figured) arrive, all three will overwrite deconz heatsetpoint.
• Tuya mode switches set both deconz mode and deconz preset.
• There is no eco preset

I was the one with GUI, will test. Maybe we just have to poll different attributes depending on mode changed.

[Smanar]

with either 0 or 120 will not update the deconz temperature

It s already the case no ?

but just set deconz mode (and deconz preset for boost)

mode = "heat" or "off" but for preset ?

There is no eco preset

yes, I think the "away" preset is enought

Maybe we just have to poll different attributes depending on mode changed

Not possible poll Tuya attribute :( It s for that the user have find this command to force the TRV making a report.

[rikroe]

sending mode = off will result in TRV display OFF, tuya mode 1, 0x0210 = 0 deconz mode auto and deconz preset manual. sending mode = auto will result in TRV diplay 60.0, tuya mode 1, 0x0210 = 120, deconz mode auto and deconz preset manual.

Also, we should use a heatsetpoint of 30.0° for mode heat, as the TRV will display ON when on 30. When using the wheel on the device it has a range of 0 (OFF) to 30 (ON).

The Javascript sets the following for 60° (we should use 30°): mode heat and preset boost. mode heat can also be set by the manu mode on TRV but if the temperature is 30°, then it still is preset boost.

The same goes for mode off. If device temperature reports 0°, then mode is off, doesn't matter which tuya mode it is in.

I tried around using deconz GUI to poll. But I am always setting some default values on the device. It sometimes looks as if it works but then next time it doesn't. :(