Deconz-rest-plugin: Thermostat Essentials Premium (Tuya)

[markoose]

Device

• Product name: Wesmartify Thermostat „Essentials Premium“
• Manufacturer: _TYST11_jeaxp72v
• Model identifier: eaxp72v
• Device type : Please remove all unrelated device types.
  
  
  
  • Thermostat
  
  

Screenshots

[markoose]

It would be nice to get some support for the requested Thermostat device. Perhaps the vendor (Wesmartify) of the Thermostat is an OEM. I have no idea why the device is shown as „On/Off Switch“ in Deconz.
Web Link to the device: https://www.wesmartify.de/heizung/heizkoerperradiator/281/essentials-smart-home-heizkoerperthermostat-premium/

[Smanar]

Hello.

To test the new code, on an Unix machine (Hassio is not an "Unix OS")

You have the procedure https://github.com/dresden-elektronik/deconz-rest-plugin#install-deconz-development-package-optional-linux-only

Just replace the step 1 by
git clone --branch tuya https://github.com/Smanar/deconz-rest-plugin.git
and you can skip the step
git checkout -b mybranch HEAD

The last step replace your actual file, so better to close deconz before, or deconz will be closed itself by the change. (you can make a backup if you want but in another folder, file is libde_rest_plugin.so)

After that you just need to re-include the device.

[markoose]

Hi, I compiled and tested the plugin like you instructed. So far it worked very well. I got some response from the device on my REST requests and I can send commands to it. Thanks for that. What I do not know, wether it‘s ok or not is, that in the REST responses (see new screenshot) there are some JSON fields which are marked „null“ or „none“. Is this fixable? Another issue is, that in deconz App the device is shown as an „On/Off Switch“ (see one of the earlier screen shots) and not as a „Thermostat“. One last thing: Do you have a hint concerning the JSON format which I need to use to set schedules in the device?
Thank you so far.

[Smanar]

in deconz App the device is shown as an „On/Off Switch“

Yes, not my fault ^^, it s written on the device firmare, it s the real type gived by the device.

The schedule, I haven't started this part yet for tuya device, can take a look later, but need lot of change for that ( = need time)

For the missing values, yes all is fixable.

Do you have the device manual, to know the missing features on deconz but present on your device ? For the moment I have enabled lot of them, but not sure your device support them (and haven't enabled all)
And some tuya devices don't use same values than others, so not sure the values I m using will be the good one for your device.

Or you can too do that with debugging, if you enable loging, tuya device use this kind of log

Tuya debug 4 : xxxxxxxxxxxxxx
Tuya debug 5 : xxxxxxxxxxxxxxxxxxx

So if you change the mode manualy on your device, if the device support it ofc, you will see this king of line.
You can do that for all setting you can done manualy, if you show me the debug line, I can add all missing setting.

Edit:
Have translated some features

• Boost function for quickly heating up the room
• 3 Mode Settings Automatic mode Manual mode Anti freezing mode (not working)
• Parental controls (not activated)
• Detects open windows, lowers to frost protection temperature (not activated)

[markoose]

Sorry, can you please tell me how to enable debugging log. I‘m totally new at openHAB/deconz. I‘m working with openhabian on raspberry platform.

[Smanar]

Ok so if I m right you have a "normal" OS ?

Do you know, how openHAB run deconz ? if it use service or command line ?
Do you have an option to stop it ?

If yes, just stop it using openHAB and run it using command line https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-debug-switches
--dbg-error=0 --dbg-info=2 --dbg-ota=0 --dbg-zdp=0 --dbg-zcl=0 --db-aps=0 --dbg-http=0

And when you have log, you can close it again, and restart it using openHAB.

If you haven't an option to start or close it in openHAB , better to ask in openHAB forum, you can broke your installation.

[markoose]

I started deCONZ using the --dbg-info=2. I missed to use the other parameters. Hope it works for you. If not, please tell me.

In the datasheet of the thermostat the following features are mentioned:

• 3 different modes (auto, manual, frost control)
• temperature range (auto, manual): 5-30 ^C)
• temperature range (frost control): 5-15 ^C)
• child proof lock (on/off)
• window open detection (on/off)
• valve adjustment (on/off)
• time schedules
  Tuya_only.log

[Smanar]

Woaaaa perfect, I realy prefer openhab as HA just for that, a classic OS.

3 different modes (auto, manual, frost control)
temperature range (auto, manual): 5-30 ^C)
temperature range (frost control): 5-15 ^C)

Spotted, called preset, you have used value 0 / 1 / 2

                    if (data == 0) { preset = "holiday"; }
                    if (data == 1) { preset = "auto"; }
                    if (data == 2) { preset = "manual"; }

Need to check in the future if value are good again

child proof lock (on/off)

Spotted, use classic value, just need to enable

window open detection (on/off)

Not visible in log, will enable it, hopping for classic vlaue

valve adjustment (on/off)

Spotted (I think, by deduction), new, to add it in code, new value
16:23:19:508 Tuya debug 5 : Status: 0 Transid: 155 Dp: 1043 (0x04,0x13) Fn: 0 Data 0

time schedules

Need more work on my side

Manup is validating PR ATM, so I will delete all my fork tommorow to start from a clean base, so you will have the new code tommorow.

[rynr]

Anything I can do to help here? I have one of those devices, I'm using deconz through the marthoc/docker-deconz docker on a Raspberry Pi 4.
But I'm not a C/C++ Developer. If I can help here, I'm happy to do so.

[markoose]

Thanks to Smanars support, the basic features (adjusting heating point, read back temperature etc.) are already working. Excited about the quick support.

[Smanar]

Lol, but not all changes are so fast.

Ok so new version to test (based on 85 beta), check the json before testing it to be sure you have not new used field (like the "mode")

• Disabled "mode"
• Enabled "preset', it work atm with "holiday" (frost control) "auto" and "manual"
• Enabled child lock
• Enabled windows detection

For valve, I have not the good value, the 1043 is for a "valve problem", so I miss the good value, so have tried an old value to test.
And what do the "valve adjustement" in reality ?

You need to include the device again to have the new field.

[tnkn3]

I have these thermostats and tried with the 85 beta. I can connect to most of them, but they show up as light switches and have no functionality.

The JSON looks like this:
{ "config": { "heatsetpoint": null, "mode": null, "offset": 0, "on": true, "reachable": true, "schedule": {}, "schedule_on": null }, "ep": 1, "etag": "f359f123f686aa540e2f6d1a4791394f", "lastseen": "2020-10-18T10:51Z", "manufacturername": "_TYST11_jeaxp72v", "modelid": "eaxp72v", "name": "Thermostat 2", "state": { "lastupdated": "none", "lowbattery": null, "on": null, "temperature": 2160, "valve": null }, "swversion": "20180727", "type": "ZHAThermostat", "uniqueid": "14:b4:57:ff:fe:3c:e2:4f-01-0201" }

I also created a log:

20201018-1145_deconz_3381.log.txt

Is there anything else I can do to help debugging?

[Smanar]

@tnkn3 the code is not yet in beta 85.
To make tries you need to compile the code from my fork.

[tnkn3]

Thanks! I thought it was already in the beta. I'll try your branch and report back.

[tnkn3]

Now run with fork. Functionality seems roughly the same. Temperature is null again.

JSON:

{ "config": { "heatsetpoint": null, "locked": null, "offset": 0, "on": true, "preset": null, "reachable": true, "schedule": {}, "schedule_on": null, "windowopen_set": null }, "ep": 1, "etag": "52e9cb70bfc8626cf6623386b1e68263", "lastseen": "2020-10-18T13:14Z", "manufacturername": "_TYST11_jeaxp72v", "modelid": "eaxp72v", "name": "Thermostat 2", "state": { "lastupdated": "none", "lowbattery": null, "on": null, "temperature": null, "valve": null }, "swversion": "20180727", "type": "ZHAThermostat", "uniqueid": "14:b4:57:ff:fe:3c:e2:4f-01-0201" }

Log:
20201018-1505_deconz_3381.log

[Smanar]

You are using "--dbg-info=2" in your command line ?
I m not seing tuya debug line.

It seem your device was added in the database, but haven't send information yet to deconz, all values are set by defaut, the device is still recheable ?

[tnkn3]

Yes, I'm using the debug level 2. There are a few lines about missing manufacturer names towards the start of the log.

My command line:
deCONZ --dbg-error=0 --dbg-info=2 --dbg-ota=0 --dbg-zdp=0 --dbg-zcl=0 --db-aps=0 --dbg-http=0 >date +%Y%m%d-%H%M_deconz_3381.log

Example tuya line from my log:
13:05:27:301 Tuya debug 7 : Missing manufacture name for 0x14b457fffe3ce2ee

[tnkn3]

I just reset the gateway and am rebooting the machine.

Can you tell me which steps I should take to make sure the device is talking to deconz?

[Smanar]

You are right, sorry, all is fine on your side.

But all request send by the device provoke other debug log

Tuya debug 4 : xxxxxxxxxxxxxx
Tuya debug 5 : xxxxxxxxxxxxxxxxxxx

And thoses one are not displayed, it mean the device never send request to deconz.

Have you try to use the device manualy ?

Your device have probably leave the network, but it s strange as you have the json entry in the api (and with a correct "lastseen") ...

[tnkn3]

I do not see the device in the app anymore, but I did some manual interaction:

• reregister
• set manual temperature
• activate childlock

I grepped just the tuya debug lines:
20201018-1843_deconz_3381.tuya_only.log

Do you need more interactions?

[Smanar]

In the app ? you mean phoscon ? this is normal, but as you have return, I think you can see it in third app ? And I think too the json is updated now ?

And there is usefull info on your log ^^.

Valve State (already in code)

16:48:32:699 Tuya debug 4 : Address 0x14B457FFFE3CE24F Payload 00791401000101
16:48:32:699 Tuya debug 5 : Status: 0 Transid: 121 Dp: 276 (0x01,0x14) Fn: 0 Data 1

Windows open (already in code)

16:48:31:691 Tuya debug 4 : Address 0x14B457FFFE3CE24F Payload 00781201000101
16:48:31:691 Tuya debug 5 : Status: 0 Transid: 120 Dp: 274 (0x01,0x12) Fn: 0 Data 1

Childlock (already on code)

16:48:33:704 Tuya debug 4 : Address 0x14B457FFFE3CE24F Payload 007a0701000100
16:48:33:704 Tuya debug 5 : Status: 0 Transid: 122 Dp: 263 (0x01,0x07) Fn: 0 Data 0

Battery (this ons is missing on previous json, not sure it will be here on your)

16:49:14:074 Tuya debug 4 : Address 0x14B457FFFE3CE24F Payload 007e1502000400000064
16:49:14:074 Tuya debug 5 : Status: 0 Transid: 126 Dp: 533 (0x02,0x15) Fn: 0 Data 100

And some other not identified, but can you share the json ? I think you have almost all values now ?

16:49:11:117 Tuya debug 4 : Address 0x14B457FFFE3CE24F Payload 007b1104000100
16:49:11:117 Tuya debug 5 : Status: 0 Transid: 123 Dp: 1041 (0x04,0x11) Fn: 0 Data 0

[tnkn3]

Yes. I mean the Phoscon app. Glad to hear, that it is expected.

New JSON has battery:
{ "config": { "battery": 100, "heatsetpoint": null, "locked": null, "offset": 0, "on": true, "preset": "auto", "reachable": true, "schedule": {}, "schedule_on": null, "windowopen_set": true }, "ep": 1, "etag": "4f7f4703f0ec1a2bb2c80005e7448173", "lastseen": "2020-10-18T16:49Z", "manufacturername": "_TYST11_jeaxp72v", "modelid": "eaxp72v", "name": "Thermostat 2", "state": { "lastupdated": "none", "lowbattery": null, "on": true, "temperature": 2200, "valve": null }, "swversion": "20180727", "type": "ZHAThermostat", "uniqueid": "14:b4:57:ff:fe:3c:e2:4f-01-0201" }

[markoose]

Compiled the new version from your „tuya“ branch and got similar results as tnkn3. Some attributes (like „locked“) seems to leave their initial null value only, when changing the value on the device manually once?
Concerning the valve adjustment „feature“: Don‘t know the meaning of it. The data sheet only mentions that you can activate/deactivate it by app. Perhaps it‘s the „learning mode“ when setting up the device after putting in the batteries? Unforrunately I don‘t have access to the original app/gateway.

[Smanar]

I will remove the field lowbattery as it seem useless for you.
But you have both "null" as "valve", this field is never used ? Only "state/on" react ?

Some attributes (like „locked“) seems to leave their initial null value only, when changing the value on the device manually once?

I had exactly same remark on another issue today. I know tuya device don't use reporting, and send realy few notification, but I was thinking they use "periodic notification" like the hourly one for Xiaomi. But from your tests (idk how long you have waiting without touching the device) I seem the device is totaly mute without actions ?

[Arquiteto]

I had exactly same remark on another issue today. I know tuya device don't use reporting, and send realy few notification, but I was thinking they use "periodic notification" like the hourly one for Xiaomi. But from your tests (idk how long you have waiting without touching the device) I seem the device is totaly mute without actions ?

From my not so long experience with this valves that's exactly what is going on. When I was on Zigbee2MQTT for a moment I was monitoring last update of all my Zigbee devices and while all others made at least one report every hour those could be silent for hours. I thought it's a matter of early stage of support, but it seems they are designed like this.

What was found on Z2M side - sending local_temperature_calibration ("config":"offset" in deCONZ terms) makes the valve report current temperature. I think valve positions only get sent when there is a change and no more often than 5 minutes. And if the message is lost it stays lost. I have some of my valves staying at 5% for hours, probably because the message about position 0% was lost.

[Smanar]

IDK, loosing a message is rare, and there is confirmation return usable too in zigbee.

After is a good way to increase the battery life.

For usefull value like temperature, it have worked on first try https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3381#issuecomment-707933690 , so I think the problem is not for those values. But if you restart the gateway I m curious to know how many time you need to have the good values for specials settings like "window open"

[Arquiteto]

IDK, loosing a message is rare, and there is confirmation return usable too in zigbee.

Well right now I have a valve that was stuck at 10% open for 5 hours. And the setpoint was 15 with temperature reported by valve around 19-20. I didn't check it ealier, but I did now and it's really at 0%. And it's quite common for at least 1 out of 6 valves I have to get stuck at 5-10% report when they are closing.

For usefull value like temperature, it have worked on first try #3381 (comment) , so I think the problem is not for those values. But if you restart the gateway I m curious to know how many time you need to have the good values for specials settings like "window open"

Well, I started the compiled version 6 hours ago and I still have null in:

• "locked" status (except one valve I did lock)
• no value on "schedule" and null on "schedule_on" (no use for me, I manage my setpoints in HA anyway)
• null value on "windowopen_set" (and I tried to send 'true' via REST API and also set it in TRV menu on one of the valves)
• lowbattery (but I guess this one will be sent only when it's actually low)

TBH, I have no idea how this window detection works. I tried to check it on Z2M as it created entity for this by default. I tested one of the windows open but nothing really happened. Maybe it was not cold enough outside. I didn't get around yet to create templates in HA for deCONZ implementation.

[tnkn3]

I understood the window open detection is reacting to window sensor alarms.

windowopen_set could be a set of sensors this thermostat should react to.

Cannot test, because I do not have any window sensors.

[Smanar]

For schedule, I don't have time ATM, will start something this week end.
BTW you still have "lowbattery " filed ? I m sure I have removed it from code ....

IDK for your device, but for another I have add an hidden command to set the windows open value

Adding some option for TRV device, for exemple
curl -H 'Content-Type: application/json' -X PUT -d '{"windowopen_set":[true,20,20]}' http://IP:PORT/api/KEY/sensors/21/config
To set windows open mode (Valve/temperature/timer).

So after 6 hours, value are still not updated ....
Not realy good, I can try to find a command to force the device to send all value at deconz startup.
You have this problem only with this tuya TRV ?

[markoose]

Especially the items „schedule_on“, „valve“ and „lowbattery“ do not seem to change their null value at all. I can do without the lowbattery value (there is still the battery field which one can use instead and which seems to update from time to time).
I also tried to activate the window open detection. I expected the valve closing while opening the window (cold outside today;-). But like Arquiteto without success.

[Smanar]

"schedule_on“" is normal, will make it this WE
"valve" is perhaps not used on your device ? I never see it on your json, on log I m checking value (0x04,0x6D) for it
"lowbattery" I don't understand, this filed is not added on last code

                if (sensor.modelId() == QLatin1String("kud7u2l") || // Tuya
                    sensor.modelId() == QLatin1String("GbxAXL2") || // Tuya
                    sensor.modelId() == QLatin1String("TS0601") )   // Tuya
                {
                    sensor.addItem(DataTypeUInt8, RStateValve);
                    item = sensor.addItem(DataTypeBool, RStateLowBattery);
                    item->setValue(false);
                }

For windows open, the user that have it working have the values displayed too on the device (the value send by the request), but you have it too on the product manual, so no reason for it don't work. This feature work with a timer too.

The first parameter is the valve state (don't remember what is it)
The second is the temperature minimum
The third is the timer.

[markoose]

Ok, sorry...Checked out your fork, testet it and „lowbattery“ and „valve“ is gone as expected.
Misunderstood concerning windowopen_set. I didn‘t mean to say that it is not working. Wasn‘t successful in lowering down the temperature to force the thermostat closing the valve.

[Smanar]

Wich one values have you used ?
The only field I now is the last ^^ try 5 minute, but I think it s the duration of the procedure, so after this time, the valve return to "on".
The first one is the valve state, so only true or false
The temperature is perhaps the difference (this feature trigger after a temperature drop) so make try with lower value like 3.

No bad return when using the command ?

[apegam-pv]

Some observations about temperature:

• report sent when 1 degree change
• report sent after a little over an hour time passed

From log this night:

01:08:14:105 Tuya debug 5 : Status: 0 Transid: 173 Dp: 515 (0x02,0x03) Fn: 0 Data 237
01:08:15:123 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00ad03020004000000ed
01:08:15:123 Tuya debug 5 : Status: 0 Transid: 173 Dp: 515 (0x02,0x03) Fn: 0 Data 237
01:08:16:127 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00ad03020004000000ed
01:08:16:127 Tuya debug 5 : Status: 0 Transid: 173 Dp: 515 (0x02,0x03) Fn: 0 Data 237
01:37:53:693 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00ae03020004000000e3
01:37:53:693 Tuya debug 5 : Status: 0 Transid: 174 Dp: 515 (0x02,0x03) Fn: 0 Data 227
01:37:54:668 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00ae03020004000000e3
01:37:54:668 Tuya debug 5 : Status: 0 Transid: 174 Dp: 515 (0x02,0x03) Fn: 0 Data 227
01:37:55:676 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00ae03020004000000e3
01:37:55:676 Tuya debug 5 : Status: 0 Transid: 174 Dp: 515 (0x02,0x03) Fn: 0 Data 227
02:26:21:821 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00af03020004000000d9
02:26:21:821 Tuya debug 5 : Status: 0 Transid: 175 Dp: 515 (0x02,0x03) Fn: 0 Data 217
02:26:22:833 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00af03020004000000d9
02:26:22:833 Tuya debug 5 : Status: 0 Transid: 175 Dp: 515 (0x02,0x03) Fn: 0 Data 217
02:26:23:843 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00af03020004000000d9
02:26:23:843 Tuya debug 5 : Status: 0 Transid: 175 Dp: 515 (0x02,0x03) Fn: 0 Data 217
03:28:42:381 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b003020004000000d4
03:28:42:381 Tuya debug 5 : Status: 0 Transid: 176 Dp: 515 (0x02,0x03) Fn: 0 Data 212
03:28:43:392 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b003020004000000d4
03:28:43:392 Tuya debug 5 : Status: 0 Transid: 176 Dp: 515 (0x02,0x03) Fn: 0 Data 212
03:28:44:402 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b003020004000000d4
03:28:44:402 Tuya debug 5 : Status: 0 Transid: 176 Dp: 515 (0x02,0x03) Fn: 0 Data 212
04:31:24:263 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b103020004000000d0
04:31:24:263 Tuya debug 5 : Status: 0 Transid: 177 Dp: 515 (0x02,0x03) Fn: 0 Data 208
04:31:25:298 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b103020004000000d0
04:31:25:298 Tuya debug 5 : Status: 0 Transid: 177 Dp: 515 (0x02,0x03) Fn: 0 Data 208
04:31:26:298 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b103020004000000d0
04:31:26:298 Tuya debug 5 : Status: 0 Transid: 177 Dp: 515 (0x02,0x03) Fn: 0 Data 208
05:34:03:001 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b203020004000000cf
05:34:03:001 Tuya debug 5 : Status: 0 Transid: 178 Dp: 515 (0x02,0x03) Fn: 0 Data 207
05:34:04:017 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b203020004000000cf
05:34:04:017 Tuya debug 5 : Status: 0 Transid: 178 Dp: 515 (0x02,0x03) Fn: 0 Data 207
05:34:05:024 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b203020004000000cf
05:34:05:024 Tuya debug 5 : Status: 0 Transid: 178 Dp: 515 (0x02,0x03) Fn: 0 Data 207
06:36:39:257 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b303020004000000cc
06:36:39:257 Tuya debug 5 : Status: 0 Transid: 179 Dp: 515 (0x02,0x03) Fn: 0 Data 204
06:36:40:269 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b303020004000000cc
06:36:40:269 Tuya debug 5 : Status: 0 Transid: 179 Dp: 515 (0x02,0x03) Fn: 0 Data 204
06:36:41:281 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b303020004000000cc
06:36:41:281 Tuya debug 5 : Status: 0 Transid: 179 Dp: 515 (0x02,0x03) Fn: 0 Data 204
07:39:14:287 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b403020004000000cb
07:39:14:287 Tuya debug 5 : Status: 0 Transid: 180 Dp: 515 (0x02,0x03) Fn: 0 Data 203
07:39:17:027 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b403020004000000cb
07:39:17:027 Tuya debug 5 : Status: 0 Transid: 180 Dp: 515 (0x02,0x03) Fn: 0 Data 203
07:39:17:049 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b403020004000000cb
07:39:17:049 Tuya debug 5 : Status: 0 Transid: 180 Dp: 515 (0x02,0x03) Fn: 0 Data 203
08:41:46:408 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b503020004000000ca
08:41:46:408 Tuya debug 5 : Status: 0 Transid: 181 Dp: 515 (0x02,0x03) Fn: 0 Data 202
08:41:47:415 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b503020004000000ca
08:41:47:415 Tuya debug 5 : Status: 0 Transid: 181 Dp: 515 (0x02,0x03) Fn: 0 Data 202
08:41:48:425 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b503020004000000ca
08:41:48:425 Tuya debug 5 : Status: 0 Transid: 181 Dp: 515 (0x02,0x03) Fn: 0 Data 202
09:06:27:629 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b603020004000000d4
09:06:27:629 Tuya debug 5 : Status: 0 Transid: 182 Dp: 515 (0x02,0x03) Fn: 0 Data 212
09:06:28:651 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b603020004000000d4
09:06:28:651 Tuya debug 5 : Status: 0 Transid: 182 Dp: 515 (0x02,0x03) Fn: 0 Data 212
09:06:29:654 Tuya debug 4 : Address 0x14B457FFFE3CB11A Payload 00b603020004000000d4
09:06:29:654 Tuya debug 5 : Status: 0 Transid: 182 Dp: 515 (0x02,0x03) Fn: 0 Data 212

[apegam-pv]

Current JSON for sensor:

{
"config": {
"battery": 92,
"heatsetpoint": 2000,
"locked": null,
"offset": 0,
"on": true,
"preset": "auto",
"reachable": true,
"schedule": {},
"schedule_on": null,
"windowopen_set": true
},
"ep": 1,
"etag": "93be104acc517c27539aba20e342d35d",
"lastseen": "2020-10-22T09:18Z",
"manufacturername": "_TYST11_jeaxp72v",
"modelid": "eaxp72v",
"name": "Thermostat 2",
"state": {
"lastupdated": "none",
"on": true,
"temperature": 2120
},
"swversion": "20180727",
"type": "ZHAThermostat",
"uniqueid": "14:b4:57:ff:fe:3c:b1:1a-01-0201"
}

[Smanar]

During 8 hours, only temperature was updated.
So if we want the config values, we need to ask them at deconz start. But I don't see wich one command to use ....

[markoose]

Made some tests setting the config parameters with JSON requests:

• set/reset „windowopen_set“
• set/reset „locked“
• „preset“ (auto/manual/holiday)
• hetsetpoint (written some values)

Theses commands worked fine. Saw the reaction on the device and could read back the expected values by JSON.
The only attribute which is missing (in comparison to the native app/gateway) is the activation/deactivation of the valve adjustment (think it must be a boolean attribute). It can‘t be set manually on the device (only by app). But for the moment I don‘t really need it.

[Smanar]

There is a value called "Enabled/disabled Valve detection feature" on zigbee2mqtt project
This value is the state/on, but not modifiable on deconz, only readable. But writable on z2m

There is too config/offset, that is readable and writable. But it s not bool value.

This WE I will start the schedule, I can set a temporary field for you make test ?

[markoose]

Sure, let me know when you have something to test.

[Smanar]

Ok so I have started the Schedule, the code is online but not compiled on my side, so if you have error during compilation, you can stop direclty.

For the moment the code wait for data FROM the device to update the json, so have you a way to set the schedule mode manualy ?

I have (tried) added too the field "setvalve" to make action on the mystery setting.

[markoose]

Got a compilation error. Didn‘t try to fix it :-)

Concerning the schedules: I don‘t think that the schedules are editable directly on the device. Nothing mentioned about it in the data sheet (only that you can edit it in the native app).

[Smanar]

Code corrected.

Something visible on device ? because I can continue the code to make it writable, but there is no way to test it ? Instead waiting and mesuring change.

[tnkn3]

I'm getting:

database.cpp: In function ‘int sqliteLoadAllSensorsCallback(void*, int, char, char)’:
database.cpp:3539:52: error: ‘RConfigSetValve’ was not declared in this scope
sensor.addItem(DataTypeString, RConfigSetValve);
^~~~~
database.cpp:3539:52: note: suggested alternative: ‘RConfigSchedule’
sensor.addItem(DataTypeString, RConfigSetValve);
^~~~~

[markoose]

Same as tnkn3 here.
Do you have a clue which JSON requests to use to check the schedule?

[Smanar]

Corrected again.

And yep, the Json will be the same than here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2393
And it seem you have more than 1 mode possible, but I will have more information tommorow.

For the moment the code is just able (when it will compile) to display the thermostat setting in the json.

Sorry, for the moment I have not the machine able to test compilation, there will be less problem tommorow

[markoose]

No problem. New output:

make -f Makefile.Release
make[1]: Entering directory '/home/openhabian/SWDevelop/deconz-rest-plugin'
g++ -c -pipe -Wno-attributes -Wno-psabi -Wall -O2 -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DDECONZ_DLLSPEC=Q_DECL_IMPORT -DUS$tuya.cpp: In member function ‘void DeRestPluginPrivate::handleTuyaClusterIndication(const deCONZ::ApsDataIndication&, deCONZ::$tuya.cpp:178:13: error: ‘updateTUYAThermostatSchedule’ was not declared in this scope
updateTUYAThermostatSchedule(zclFrame.payload().toHex())
^~~~~~~~
tuya.cpp:178:13: note: suggested alternative: ‘updateThermostatSchedule’
updateTUYAThermostatSchedule(zclFrame.payload().toHex())
^~~~~~~~
updateThermostatSchedule
tuya.cpp:205:50: error: ‘weekdays’ was not declared in this scope
updateThermostatSchedule(sensorNode, weekdays, transitions);
^~~~
tuya.cpp:434:17: error: duplicate case value
case 0x016C: // Auto / manu
^~
tuya.cpp:383:17: note: previously used here
case 0x016c: // manual / auto
^~
tuya.cpp:568:21: warning: this statement may fall through [-Wimplicit-fallthrough=]
}
^
tuya.cpp:570:17: note: here
case 0x026A : // Siren Humidity
^~~~
make[1]: * [Makefile.Release:1336: release/tuya.o] Error 1
make[1]: Leaving directory '/home/openhabian/SWDevelop/deconz-rest-plugin'
make: * [Makefile:40: release] Error 2

[Smanar]

Code corrected, and tested this time.

The synthax is the same than here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2393 to set a shedule
Except you need to use 7 days, not an option for tuya.

The only mode possible is "holiday"

[tnkn3]

I posted a schedule to the sensor and it is returning schedule now:

{
"config": {
"heatsetpoint": null,
"locked": null,
"offset": 0,
"on": true,
"preset": null,
"reachable": true,
"schedule": {
"W127": [
{
"heatsetpoint": 1500,
"localtime": "T00:05"
},
{
"heatsetpoint": 800,
"localtime": "T08:05"
},
{
"heatsetpoint": 900,
"localtime": "T09:05"
},
{
"heatsetpoint": 1000,
"localtime": "T10:05"
},
{
"heatsetpoint": 1200,
"localtime": "T12:05"
},
{
"heatsetpoint": 1400,
"localtime": "T14:05"
},
{
"heatsetpoint": 1600,
"localtime": "T16:05"
},
{
"heatsetpoint": 1800,
"localtime": "T18:05"
},
{
"heatsetpoint": 2000,
"localtime": "T20:05"
},
{
"heatsetpoint": 2200,
"localtime": "T22:05"
}
]
},
"schedule_on": null,
"windowopen_set": null
},
"ep": 1,
"etag": "f94c7cd03dba7c493dd31da47717c181",
"lastseen": "2020-10-25T17:15Z",
"manufacturername": "_TYST11_jeaxp72v",
"modelid": "eaxp72v",
"name": "Thermostat 5",
"state": {
"lastupdated": "none",
"on": null,
"temperature": 2000
},
"swversion": "20180727",
"type": "ZHAThermostat",
"uniqueid": "14:b4:57:ff:fe:3c:e2:4f-01-0201"
}

[Smanar]

But have you a way to test it ?
Perhaps with using the preset = holiday. On my side I have not understand how work "W127" yet ^^. And I m notsure there is a value for "holiday", it s just a day counter on a week.

And the field "setvalve" chnage something ?

[markoose]

I did a PUT request and got a success response:

[
-{
-"success": {
-"/sensors/2/config/schedule": {
-"W127": [
-{
"heatsetpoint": 1500,
"localtime": "T00:05"
},
-{
"heatsetpoint": 800,
"localtime": "T08:05"
},
-{
"heatsetpoint": 900,
"localtime": "T09:05"
},
-{
"heatsetpoint": 1000,
"localtime": "T10:05"
},
-{
"heatsetpoint": 1200,
"localtime": "T12:05"
},
-{
"heatsetpoint": 1400,
"localtime": "T14:05"
},
-{
"heatsetpoint": 1600,
"localtime": "T16:05"
},
-{
"heatsetpoint": 1800,
"localtime": "T18:05"
},
-{
"heatsetpoint": 2000,
"localtime": "T20:05"
},
-{
"heatsetpoint": 2200,
"localtime": "T22:05"
}]}}}]

But when reading back I got an empty schedule attribute (like before your change). Am I missing something?

Btw I don‘t see a „setvalve“ field.

[Smanar]

Have modified the code for the field "setvalve"(will be in "config") but if you already have restarted it, strange it s not present.

I m checking the code, and all seem fine, it s probably an error from me when I make convertion, the data send to the device can be wrong and if it aswer with empty data, it can clear the data in deconz.

Can you show the log when sending the data pls ?

But it have worked on @tnkn3 side ?

[tnkn3]

I do not see any setvalve in the JSON.

Another question: Is it on purpose to have heatsetpoint instead of heatingsetpoint as mentioned in the REST API docs?

I can set it and it works. Just wondering about compatibility with 3rd party. If possible, it would be nice to have consistent naming here.

Any tests I should run?

[Smanar]

Ok my bad, I have find another error on setvalve code, updated again.

And good catch, the code use only "heatsetpoint", so there is a typo, or an anticiped feature, going to ask.

The Schedule set is persitent on your side ? Can you try to set the preset to "holiday" to test it ?

[tnkn3]

I have an SD card crash on my system. Will buy new one and set everything up. Then I will check about the schedule and holiday preset. Sorry for delay.

[Smanar]

NP, I have time, it s for you, not for me ^^.

[markoose]

I pulled your tuya branch. Still got the problem that I cannot read back the schedules. Made some debug logs while sending the schedules with REST. Hope you can see something in it or help me what I'm doing wrong.
tuya_only.log

[Smanar]

On your log I don't see anything according to schedule, incoming or outcoming.

There are easy to see:

• "Tuya : Schedule command" in log for incoming command
• the payload is longuer

You have a return when you are doing the command ?

[markoose]

I tried the schedule command multiple times while logging was active and each time I got a success response like

[
-{
-"success": {
-"/sensors/2/config/schedule": {
-"W127": [
-{
"heatsetpoint": 1500,
"localtime": "T00:05"
},
......

But I also get a success response when trying to set a false „preset“ (like „preset“ = „holida“; notice the missing „y“).

[Smanar]

Ok so the "preset" command was buggy (disabled for this device)
I have just re-enabled it.

But if you try to set a schedule, you need to see in log something like
10:57:27:718 Send Tuya Request: Dp_type: 0x04 Dp_ identifier 0x71 Data: XXXXXXXXXXXXXXXXXXX

Can you try with the last code, I have added 2 debug lines, to check the problem, you need to have them too when setting a schedule
https://github.com/Smanar/deconz-rest-plugin/commit/a2e4469ea922ed74f67434fc8a855ed0c389f4cb

[markoose]

"preset" command worked with your earlier versions (I saw reaction on the device). Only with false mode ("holida") I expected an error response. But got a success response. >Nothing changed with the new code.

Concerning schedule requests also nothing changed. I send a REST request. But nothing is in the log file. No "Send tuya" request and no new debug output.

[Smanar]

Arf you are right, I haven't reconized the device,
It s 2 time in the code now

                                                           sensor->modelId().startsWith(QLatin1String("eaxp72v")) ||
                                                          (sensor->manufacturer() == QLatin1String("_TYST11_jeaxp72v")) ||

Can you show the request and the response pls ?

[markoose]

Here is the log from yesterday...
tuya_only.log

[Smanar]

But there is a problem on the request you done, I think it was like for the preset with "holida".
You have a success message, but the request is never send.

Can you show the HTTP (REST) Request you done ansd the result ?

Because on the code, you have the debug line "Debug TUYA : 44" at the top begining, before check, before tuya code, before parsing code, not possible you haven't this one.

[markoose]

That’s mysterious. I send the PUT request to http://192.168.2.34:8080/api/xxxxxyyyyy/sensors/6/config

{
"schedule": {
"W127": [
{
"heatsetpoint": 1600,
"localtime": "T00:05"
},
{
"heatsetpoint": 1800,
"localtime": "T08:05"
}
]
}
}

and got the response

[
-{
-"success": {
-"/sensors/6/config/schedule": {
-"W127": [
-{
"heatsetpoint": 1600,
"localtime": "T00:05"
},
-{
"heatsetpoint": 1800,
"localtime": "T08:05"
}
]
}
}
}
]

[Smanar]

else if ((req.path.size() == 7) && (req.hdr.method() == "POST" || req.hdr.method() == "DELETE") && (req.path[4] == "config") && (req.path[5] == "schedule"))

It seem the code don't work for PUT.

But I realy not understand why you always have success message ....

for exemple for preset

                    if (presetSet == "holiday") { data = QByteArray("\x00",1); }
                    else if (presetSet == "auto") { data = QByteArray("\x01",1); }
                    else if (presetSet == "manual") { data = QByteArray("\x02",1); }
                    else if (presetSet == "confort") { data = QByteArray("\x03",1); }
                    else if (presetSet == "eco") { data = QByteArray("\x04",1); }
                    else if (presetSet == "boost") { data = QByteArray("\x05",1); }
                    else if (presetSet == "complex") { data = QByteArray("\x06",1); }
                    else
                    {
                        rspItemState[QString("error unknown preset for %1").arg(sensor->modelId())] = map[pi.key()];
                    }

Not normal you haven't error message with bad value ....

I haven't enought time tonight, but I need to take a look in that

[Smanar]

I realy don't understand, no problem on my side

[
  {
    "error": {
      "address": "/sensors/2/config/schedule/dd",
      "description": "method, PUT, not available for resource, /sensors/2/config/schedule/dd",
      "type": 4
    }
  }
]

The correct url is

// POST, DELETE /api/<apikey>/sensors/<id>/config/schedule/Wbbb

Wbbb is probably W127 for you

[markoose]

Ah, with POST request it worked. I got a success response and I can read back the schedule with a GET request. Thanks...
I think the reason why I always get a success response using PUT requests is the URI I was using: /api/apikey/sensors/id/config (payload: see my post from yesterday). When using URI /api/apikey/sensors/id/config/schedule/Wbbb with PUT request I also get an error response. Don‘t know why the first PUT request succeeds.

[Smanar]

Lol, there is so much think strange in code. It realy need to be cleaned, and tuya don't help for that, I m using so much hack for them.

[kgorszczyk]

Hi there,
i bought the same TRV, just from a different reseller. I believe every reseller has its own model number. For example, my model number is "fvq6avy" (Reseller "Revolt": https://www.revolt-power.de/zigbee-kompatibles-heizkoerperthermostat-mit-app-steuerung-mtrkw-11399.html).

I tried your code and just copy-pasted all if statements and edited my model number in and got my TRV working with deCONZ. Wouldn't it be easier just to check the manufacturer if the string starts with "_TYST11_j" instead having one if clause for every reseller?

[MattWestb]

@kgorszczyk Great done !!
I have ordered one 5 plus GW pack of the same from pearl.at and its posted and i'm waiting to getting them and trying out how they work :-))

I can being that every brand is doing its own model and is implanting it in there GW and other brands GW / apps is not working then so can selling more of the same thermostats / GWs = more money made.

[markoose]

Setting schedules with REST is working now (see last post). But I see no reaction on the device. Transitions are programmed but they are not executed. Neither in „holiday“ nor in „auto“ preset. I expect the schedules to be executed in „auto“ mode. Any chance to check this?

[Smanar]

@kgorszczyk no ^^, not possible, because TYST11 is just the hardware used for the device, sell by tuya, after that, the brand can do that they want with it, thermostat, but covering device or switch if they want. So you can have many device starting with "TYST11" but they can be anything, the model id too is not usable, the only to reconize a device is the full manufacture name.

BTW what if the name of your to add it in code ?

@markoose yep, but I m a litle lost ATM with all tuya thermostat. Do you know ho to enable deconz in debug mode ?
Something that wil be usefull is an incoming request from the device with the schedule command to reconize wich one this device is using.

Like I have said before they are easy to reconize, the paylaod is longer and you have "Tuya : Schedule command" written in log, problem, some device are realy mute, so you can try to provoke this request with changing mode on the device itself.

[markoose]

With debug mode you mean the „—dbg-Info=2“ switches passed when starting deconz?

[kgorszczyk]

@Smanar Ah yeah, just noticed that going through the code. Well, that's stupid ... -_-
My TRV has the following:

• Manufacturer: _TYST11_kfvq6avy
• Model identifier: fvq6avy
  Thanks for adding it!

[Smanar]

@markoose yep pls, you can set all filed to 0.
If you can't, I will search tommorow, but there is so much tuya thermostat and with at least 3 working mode, and all use same kind of command but not same value for day for exemple.

@kgorszczyk I have added it in the tuya code, I will make the final PR before the 10th, but not sure it will be validated for the next stable, have mimic the device "_TYST11_jeaxp72v" .

[markoose]

I did a log while trasmitting the schedules via REST. But nothing like "Tuya : Schedule command" showing up.
tuya_only.log

[Smanar]

Ok I have updated the code, need to pull the new one.

Ok so this device use

• dp = 0x0203 for thermostat temperature
• dp = 0x0202 for thermostat heatpoint

So taking classic values
So you have probably

• dp = 0x0070 for work day with 6 setting.
• dp = 0x0071 for holidays with 6 setting.

So the only working days are "W124" for workday and "W003" for not working day ( = holiday ?), it will not work if you use less or more than 6 values, there is a new error message in log.

To enable it, good luck ^^, perhaps on the manual ?

This is some information I have found on z2m issue

• Auto mode = weekly schedule mode on TRV itself, off = holiday mode
• complex mode (this one means that thermostat is working in schedule mode, but temperature was changed manually)

On deconz the "holiday" preset is probably an "off" preset in reality or "schedule" preset

[markoose]

Tested the new code. Worked like you said: Two sets with 6 transitions programmable. Got an error log when trying to set more than 6 transitions. But still no reaction on the device (transitions took not place while in „auto“ mode).

What I can get from the manual:

1. The three modes of operation (auto, manual, frost control) which are mentioned in the manual, corresponds directly to the three deconz presets („auto“, „manual“, „holiday“). I can verify that on the device display and vice versa.
2. According to the manual, to activate the schedules you have to activate „auto“ mode („auto“ preset in deconz). That’s all.

But when programming the schedules with deconz and activating „auto“ preset, nothing happens. What makes me think is another hint in the manual: „For auto mode the thermostat must be connected to the gateway!“ Don’t know what this means. Should this mean that the schedules aren’t stored (and aren’t executed) directly at the device but are controlled only by the gateway? So no schedule execution directly on the device (independent from the controller) possible? If so, I think we don’t need the parameters „schedule“ and „schedule_on“?

[Smanar]

Ha ....
IDK but it can explain why I never see the thermostat command from your device.

Tuya : Schedule command

In my mind the device send them at power on or if you set the good mode, but if you never see this command, it s probably the problem.

On zigbee2mqtt this device don't have schedule too https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices.js#L14459

[markoose]

I checked the log once again while power on the device and changing presets (on the device and via deconz). But never seen an „Tuya: Schedule command“ or something like that in it.
So, do you think, we should remove the parameters „schedule“ and „schedule_on“?

[Smanar]

As you want, if it disturb you, yes i can remove them, but "schedule_on" is not already removed (never used on tuya) ?

[markoose]

As I understand the data sheet now, schedules aren’t executed directly on the device. Therefore I think it makes no sense to have „schedule“ and „schedule_on“ parameters in the REST interface for that device. They only pretend a feature which (I think) the device doesn’t support. schedule_on should also be redundant to preset=„auto“. If I need schedules for this thermostat, I can still write my own deconz rules. Sorry for the work you put in it...