Essentials Smart Home Premium Radiator Thermostat

[cova-fe]

Device

• Product name: Essentials Smart Home Premium Radiator Thermostat
• Manufacturer: _TZE200_jeaxp72v
• Model identifier: TS0601
• Device type : Please remove all unrelated device types.
  • Thermostat

Screenshots

Basic

Identify

Alarms

Device Temperature

Groups

Scenes

On/Off

Level Control

Color Control

Simple Metering

Diagnostics

Other clusters that are not mentioned above

[Mimiix]

Seems to be supported already? Doesn't it show In the rest api?

[cova-fe]

Well, yes and no, to what I understand :) . I'm playing around with this device and it is recognized by the webapp but only, meaning that you can have it joining the network, but it does not shows up later in webapp sensor list. It appears on vnc GUI though and also HA is able to see it but it seems that some fields in config are not shown i.e. locked, preset and some other.

Looking into rest plugin code, in product_match.cpp we can find {"_TYST11_jeaxp72v", "eaxp72v", "Essentials", "Tuya_THD Essentials TRV"} That is pretty close but not the same, as we could expect to see {"_TZE200_jeaxp72v", "TS0601", "Essentials", "Tuya_THD Essentials TRV"}

Also, in de_web_plugin there is no real match for this device, according to what I can see from the device data there should be a line like { VENDOR_EMBER, "TS0601", silabs10MacPrefix } (I did not really looked at the whole code, so I may be wrong).

I tried to add the previous lines into rest api (basically assiming that TYST11 and TZE200 are similar) and recompile the plugin, using it on marthoc docker image and some more fields appeared in the API, I'm now testing if they work. However nothing appears in the web interfaces. I can play around a bit ad try to find also all supported fields and capabilities, but I'm not sure how to integrate them in the code, I was not able to find or understand completely how to proceed :)

[Smanar]

{"_TZE200_jeaxp72v", "TS0601", "Essentials", "Tuya_THD Essentials TRV"}

Yeah, right, I think you can add it.

VENDOR_EMBER, "TS0601", silabs10MacPrefix }

This one is not realy usefull because there is another check for all device using VENDOR_EMBER

        case VENDOR_EMBER:
            return prefix == emberMacPrefix ||
                   prefix == konkeMacPrefix ||
                   prefix == silabs3MacPrefix ||
                   prefix == silabs5MacPrefix ||
                   prefix == silabs10MacPrefix ||
                   prefix == silabs13MacPrefix ||
                   prefix == silabs14MacPrefix ||
                   prefix == silabs7MacPrefix;

[cova-fe]

I did not noticed the case statement, right. I guess my change did not had adverse effect anyway. Regarding the phoscon web app, is there anything that could be done to have the device shown under sensors?

[Smanar]

Unfortunately Phoscon don't support thermostat, so you need to use third app.

BTW if it work on your side, can purpose a PR, a 1 line modification code will be fastly validated.

[cova-fe]

I have another thermostat, different brand, and it appears on the Phoscon app: so I was expecting something similar.

I will be happy to open a PR, unfortunately the device is not working as I expect (i.e. offset setting does not work yet). I'm looking around for more details on how this specific device, to see if I can improve the situation.

[Smanar]

Ha, I did not know it was possible, but it s a thermostat device ? The icon look like a presence detector. Offset ? you mean config/offset ? this setting is not device dependent, it's something global to deconz, but take care the value is *100, so need to use 100 for 1 degree.

[cova-fe]

Ha, I did not know it was possible, but it s a thermostat device ? The icon look like a presence detector.

Indeed, this is quite weird, but the description says "Thermostat" and at least there is a visual indication that the device is there. I wonder how to get the same behavior for the thermostat that I'm trying to add. Basically now what happens is that you can open the network, have the device to join, you get the "ready" green message and after that HA can see the device, but it is not shown anywhere in phoscon webapp, that could be a bit confusing. And you have to use rest API calls to change the name, for instance :)

Offset ? you mean config/offset ? this setting is not device dependent, it's something global to deconz, but take care the value is *100, so need to use 100 for 1 degree.

Yep, I know that part. The only problem is that no matter what I set into this parameter, I'm not able to see any changes in the reported temperature. Another example is that {state:{on:}} parameter is always "false". So maybe it is better than nothing, but still something to investigate.

[Smanar]

Arf it's my fault. I forget that.

On temperature cluster you have

                                    ResourceItem *item2 = i->item(RConfigOffset);
                                    if (item2 && item2->toNumber() != 0)
                                    {
                                        temp += item2->toNumber();
                                    }

But I forget it on tuya.cpp file. I can explain how to do if you want to make a PR, but I m not sure wich one tuya command use your device, can be

case 0x0203: // Thermostat current temperature
case 0x0218: // Thermostat current temperature for moe
case 0x026B: // Temperature

For {state:{on:} perhaps your device just don't support it ?

[cova-fe]

But I forget it on tuya.cpp file. I can explain how to do if you want to make a PR, but I m not sure wich one tuya command use your device, can be [...]

Will be glad to make the changes, any useful info will be welcome. I can also test the results to see which case applies.

For {state:{on:} perhaps your device just don't support it ?

Could be. The fun part will be to understand if it is supported or not. I'm googling a bit for some info, sniffing zigbee traffic will be complicated as I own only one conbee :)

[cova-fe]

I was able to make the offset to take effect (the command seems to be 0x0203, at least is where the case is entered). It took several minutes to be seen in logs, even though I used the rest interface (postman) to set it, but at the end it worked so it is an improvement. offset got reverted to 0 after a while, dunno why. But I have still troubles in having HA dealing properly with the device (it seems not to accept on/off commands). Still investigating

[Smanar]

offset got reverted to 0 after a while

Can you show the change on your fork ? I can take a look on it.

it seems not to accept on/off commands

I don't think your device support on/off for valve, it s for that the state/on is not working.

sniffing zigbee traffic will be complicated as I own only one conbee

You don't need, all request made by the device are logged on deconz with the flag "info". The on/off is the command 0x026D

[appleonkel]

@cova-fe The description says the thermostat has the windowopen_set at True in the initial state. If it detects an "open window" it will close the ventil for 30 minutes. But i am not able to detect this attribute in deconz/phoscon. Another thing that is missing is the child-proof-lock.

I can see that sometime config/on is automatic set to true or false. And i am able to set the heatsetpoint.

[Smanar]

config/on is just for deconz, to enable or not rules for exemple For you it's state/on

Can you show the device JSON ?

[appleonkel]

This is what i get from deconz 2.12.06-raspbian-buster-stable

{
    "config": {
        "heatsetpoint": 2250,
        "offset": 0,
        "on": true,
        "reachable": true,
        "schedule": {},
        "schedule_on": false
    },
    "ep": 1,
    "etag": "577b8d9ac1b2d3d36979363cdc159207",
    "lastannounced": null,
    "lastseen": "2021-10-20T00:26Z",
    "manufacturername": "_TZE200_jeaxp72v",
    "modelid": "TS0601",
    "name": "Thermostat 23",
    "state": {
        "lastupdated": "2021-10-19T22:19:22.435",
        "on": false,
        "temperature": 2190
    },
    "type": "ZHAThermostat",
    "uniqueid": "84:71:27:ff:fe:73:04:b2-01-0201"
}

If someone can give me the right commands, i have the cli-plugn running and could help debug with that.

[Smanar]

You have added exactly this line ?

{"_TZE200_jeaxp72v", "TS0601", "Essentials", "Tuya_THD Essentials TRV"}

Because for the device "Tuya_THD Essentials TRV" you need to have too the "locked" for exemple.

[appleonkel]

This is what i get from deconz 2.12.06-raspbian-buster-stable

I added nothing, the compiled plugin comes from the repo http://phoscon.de/apt/deconz. I only joined the device as sensor and it was available through the api (not in phoscon).

[Smanar]

Ha ok, so it s normal, you need code modification to have full support.

[appleonkel]

I have updated to beta and add the line to product_match.cpp. Now, i am gettting

{
    "config": {
        "heatsetpoint": 2250, 
        "locked": false, 
        "offset": 0, 
        "on": true, 
        "preset": null, 
        "reachable": true, 
        "schedule": {}, 
        "schedule_on": false, 
        "setvalve": false, 
        "windowopen_set": false
    }, 
    "ep": 1, 
    "etag": "87ea89a173cbf0772e16e2c66386984a", 
    "lastannounced": null, 
    "lastseen": "2021-10-20T21:38Z", 
    "manufacturername": "_TZE200_jeaxp72v", 
    "modelid": "TS0601", 
    "name": "Thermostat 23", 
    "state": {
        "lastupdated": "2021-10-20T21:11:31.679", 
        "on": false, 
        "temperature": 2270
    }, 
    "type": "ZHAThermostat", 
    "uniqueid": "84:71:27:ff:fe:73:04:b2-01-0201"
}

I also tested changing offset, locked, set_valve and windowopen_set, which all seems to work.

[cova-fe]

offset got reverted to 0 after a while

Can you show the change on your fork ? I can take a look on it.

Sure, here it is: https://github.com/cova-fe/deconz-rest-plugin/commit/3cd9cbfe369077ffee58b8c0d43512188201a9bb

it seems not to accept on/off commands

I don't think your device support on/off for valve, it s for that the state/on is not working.

Uhm.. Ok, so i need to find a way to have the right controls showing up on HA dashboard. Right now it is not completely clear to how to tell the device "shut off" or "please reach the set temperature", as the HA interface seems not to care for icons clicks. But I'll look at it, maybe the problem is somewhere else.

sniffing zigbee traffic will be complicated as I own only one conbee

You don't need, all request made by the device are logged on deconz with the flag "info". The on/off is the command 0x026D

Oki, thanks!

[Smanar]

Ok so I think I have found something about the offset. but it's a long story.

Some tuya device have a special command for offset

                else if (rid.suffix == RConfigOffset) // Signed integer
                {
                    data.integer = data.integer / 10;

                    if ((R_GetProductId(sensor) == QLatin1String("Tuya_THD HY369 TRV") ||
                         R_GetProductId(sensor) == QLatin1String("Tuya_THD Essentials TRV") ||
                         R_GetProductId(sensor) == QLatin1String("Tuya_THD Smart radiator TRV") ||
                         R_GetProductId(sensor) == QLatin1String("Tuya_THD NX-4911-675 TRV") ||
                         R_GetProductId(sensor) == QLatin1String("Tuya_THD SEA801-ZIGBEE TRV")) ||
                         R_GetProductId(sensor) == QLatin1String("Tuya_THD WZB-TRVL TRV"))
                    {

So this one make conflict with the deconz integrated one. And it s probably for that I have not used it. And when the device send the report for this command it reset the value (because the device offset is still 0).

So we need to use the deconz offset OR the tuya offset.

On my side I think it s better to use the deconz one, can be used on all device, just need to be sure it s a temperature offset and not a setpoint offset, if you have the manual to be sure ?

[cova-fe]

I trust you on where is best to put the changes; I have the manual but only the user manual shipped with the device, not really informative about offset. When I forced the offset the reported temperature (not the setpoint) changed (before getting reverted). I can anyway test any change it you need it.

[cova-fe]

The manual however reports that with the app (hence I suppose there are endpoints for that) you can select three modes (Auto, manual, anti-freeze), set child lock, set window detection and valve detection (not completely sure what it does).

[Smanar]

I m asking @SwoopX to have his opinion, I m for remove the hardware offset, and he is for remove deconz offset ^^.

If we can be sure it just impact the value displayed (and have no impact on regulation), for me it's better to use the deconz offset.

Edit: I need to check but it seem this command is in fact a "thermostat calibration", so not the same thing than an offset, if it's that better to use config/offset just to add an offset a the returned temperature and change the hardware offset in config/calibration for exemple.

The manual however reports that with the app (hence I suppose there are endpoints for that) you can select three modes (Auto, manual, anti-freeze), set child lock, set window detection and valve detection (not completely sure what it does).

    "config": {
        "heatsetpoint": 2250, 
        "locked": false, 
        "offset": 0, 
        "on": true, 
        "preset": null, 
        "reachable": true, 
        "schedule": {}, 
        "schedule_on": false, 
        "setvalve": false, 
        "windowopen_set": false
    },

So "child lock" and "set window detection" can work

But for Auto, manual, anti-freeze, this device use "preset" and not "mode" ..... like thermostat and not TRV. I don't remember why, but you need to use "preset" with one thoses values

const std::array<KeyValMapTuyaSingle, 7> RConfigPresetValuesTuya = { { {QLatin1String("holiday"), {0x00}}, {QLatin1String("auto"), {0x01}}, {QLatin1String("manual"), {0x02}},
                                                                              {QLatin1String("comfort"), {0x04}}, {QLatin1String("eco"), {0x05}}, {QLatin1String("boost"), {0x06}},
                                                                              {QLatin1String("complex"), {0x07}} } };

Valve detection is the command 0x01 0x14 a bool value, on or off, this value is reported in config/setvalve. but idk what is it, if the valve is open or not ?

[SwoopX]

@Smanar mon ami, ofc we again talked about 2 different things 😃

The offset setting with thermostats is meant for the heatsetpoint only. Devices supporting it (very rare but part of the zigbee spec) get the device internal programming ajusted to heat more or less (and ideally give you the "right" temperature on their own). The current code has 4 different options (the 4th will actually never be reached for a thermostat) to make use of the offset: A whitelisted Tuya device, a Danfoss device supporting it via a manufacturer specific attribute and the standard zigbee way, which is applicable for all devices not falling under option 1 and 2 (keep in mind almost no thermostat supports the standard zigbee way here).

So that sums up to: if a thermostat is natively supporting an offset setting, which is applicable for heatsetpoint only, then it is usable. If not, then not.

state/temperature was never meant to be modifiable. However, with the DDFs, you can do whatever you wish.

[cova-fe]

Thanks for all the info.. I'm not sure to have understood all though :) So, it seems that we have 2 ways to manage the offset, either using the device or the deconz (hence data is only on controller). Now, it is not clear to me how the latter option could effectively work. If the offset is only in deconz, the thermostat will be not a thermostat but simply a thermometer and an actuator, as the decision to switching the heating will be in the deconz controller and not in the valve. Or the offest is simply saved in deconz, the device is oblivious of the situation and setpoint/temperature are corrected by deconz only to benefit of the HA application that is consuming his api?
If the offset is in the thermostat, how this is supposed to work? is the data saved somewhere in the thermostat itself and the internal logic switches the valve according to the corrected temperature, and the temperature read by deconz is the corrected one? If needed I can perform some tests on my device, but I guess I have to understand better how the device actually works :)

[Smanar]

The problem is there is 2 config/offset.

The one used for regulation, I purpose to rename it, for exemple config/calibrateoffset. The one used for temperature/pression/humidity config/offset.

If you are agree with that @SwoopX we can do it for tuya devices. And ofc config/calibrateoffset (or if you have another name ?) will be not available on device that don't support it. Config/offset will just impact the returned temperature like a sensor temperature but will be available on all device that display current temperature.

[Smanar]

SwoopX have made a good remark. The temperature displayed on the device is the measured temperature ? So use an offset to print a better temperature using deconz offset is stupid because you will see 20¨°C on the device and 18 °C on HA

[cova-fe]

SwoopX have made a good remark. The temperature displayed on the device is the measured temperature ? So use an offset to print a better temperature using deconz offset is stupid because you will see 20¨°C on the device and 18 °C on HA

According to the manual, this device displays only the set temperature, not the current one. I guess that if deconz offset is used, it must be applied to both read temperature and setpoints, otherwise it will start to behave in a funny way. However, if a device supports some behavior, shouldn't be used the device provided feature? (Not completely sure about pros and cons, though)

[Smanar]

However, if a device supports some behavior, shouldn't be used the device provided feature?

Yes probably, so better to remove the deconz offset, but for me it's better to use different name to prevent this kind of mistake. And BTW it was not working before ? Value need to be > -90 and < 90.

[github-actions[bot]]

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]]

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.

[svn2208]

If I change the temperature, it won‘t affect the displayed temperature. Someone knows why?

[Mimiix]

@smanar

[Smanar]

Can you show your device json pls ? Or debug logs when making the request ? With flags "info" and "info_l2" ?

[svn2208]

Do you mean this:

“20": { "config": { "battery": 99, "heatsetpoint": 1600, "offset": 0, "on": true, "reachable": true, "schedule": {}, "schedule_on": false }, "ep": 1, "etag": "1e8b9781d9584dc7ec9fa011390f1a41", "lastannounced": "2021-12-06T19:49:02Z", "lastseen": "2021-12-09T17:34Z", "manufacturername": "_TZE200_jeaxp72v", "modelid": "TS0601", "name": "Thermostat 20", "state": { "lastupdated": "2021-12-09T17:31:02.117", "on": false, "temperature": 1880 }, "type": "ZHAThermostat", "uniqueid": "84:fd:27:ff:fe:16:50:5c-01-0201" } }

Info and info l2 are: —dpg-info=2?

Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:29:801 don't create binding for attribute reporting of sensor Thermostat 20 Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:29:802 Force binding of attribute reporting for node Thermostat 20 Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:637 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:640 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:643 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:646 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:649 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:652 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:655 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:657 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:660 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v Dec 09 22:04:33 dantooine deCONZ[503]: 22:04:33:662 No Tuya productId entry found for manufacturername: _TZE200_jeaxp72v

[svn2208]

5404 / #5405 solved my problem.

[Smanar]

Yep, the device was missing in code, new manufacture name > _TZE200_jeaxp72v

[Mimiix]

@Smanar is battery integrated for this device?

[appleonkel]

@Mimiix Yes battery is integrated and as far as i can say, the values from the API are correct.

[svn2208]

It is not working for my device.

[svn2208]

I could resolve this by reading the node descriptor. Thank anyway

[scarre]

Is the fix available in deconz 2.13.4 ? I have this thermostat with manufacturer _TZE200_jeaxp72v, but it works only in one direction: temperature changes at the thermostat itself seems to be handled in deconz. Temperature changes in deconz are not taken into account by the thermostat itself. Other thermostat features do not work. If not in 2.13.4, will the fix be available in 2.13.5 ?

[wallesch]

Running HA on supervised installation with deCONZ, cannot using BETA ... waiting over months to get _TZE200_jeaxp72v available ... Release date moved from November => December ... all my hope on 2.13.4 and AddOn 6.11 ... but nothing changed ... sometimes i think HA and deCONZ was a wrong decision

[svn2208]

I compiled it by myself. Maybe it will work for you as well. Just exchange the lib then

[Smanar]

I don't see the model "_TZE200_jeaxp72v" on the code. And yes ATM all PR are locked to don't make the code too time, as in the future we will use DDF instead of c++ edition.

[scarre]

This is strange, because this device is a clone of {"_TYST11_jeaxp72v", "eaxp72v", "Essentials", "Tuya_THD Essentials TRV"} (same manufacturer wesmartify/essentials, same model, just a different reference) which thus only requires an additional 1 line of code. Such cloned devices were committed about 2 months ago (#5497), while this one wasn't (#5404) even though it has been identified as not conflicting since october 21 ? I guess I'll try to compile myself and replace the lib, as suggested by svn2208...

[scarre]

@svn2208

I compiled it by myself. Maybe it will work for you as well. Just exchange the lib then

I successfully modified the sources of v2.13.4, recompiled and replaced the lib. Thermostat is recognized properly now. The only thing that does not work for me is the "heat" indication; it always displays "off" even when thermostat is in heating mode. Otherwise all other functionality is working well. Do you have the same experience with the "heat" indication always reported off ?

[svn2208]

Hmm I have the feeling it is alway on heat

[Smanar]

You have a config/mode on your device ? it seem from the code there is only a config/preset (at least for the _TYST11_jeaxp72v)