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.