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

[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: Dptype: 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...