AVATTO Tuya WiFi Smart Thermostat

[b0rder]

Hi guyz!

Today I successfully set up AVATTO Tuya WiFi Smart Thermostat with Tasmota (ME81AH).

To use it with precompiled binary (Tasmota-lite), it is required to flash by soldering TX/RX and 3.3V to tuwe3s (air flash was not working for this device). No need to cut existing TX/RX traces, flash on 115200.

After flashing, use commands to configure module:

Backlog Template {"NAME":"AVATTO Heating Thermostat","GPIO":[1,1,1,1,1,1,0,0,1,1,1,1,1,0],"FLAG":0,"BASE":54}; Module 0;  TuyaMCU 11,1; TuyaMCU 42,2; TuyaMCU 72,16; TuyaMCU 71,24; webbutton1 On/Off; webbutton2 Auto/Manual; webbutton3 Lock

But to set internal clock, we need compiled binary compiled with USE_TUYA_TIME (user_config_override.h):

#ifndef USE_TUYA_TIME
#define USE_TUYA_TIME
#endif

One issue I found is that Temperature Set displayed /10. That is because it uses the same divider as Temperature sensor value (which is not correct for this device).
For example, current temperature got from MCU like this (value 245 means 24.5C):

21:42:43.884 {"TuyaReceived":{"Data":"55AA0307000818020004000000F524","Cmnd":7,"CmndData":"18020004000000F5","DpType2Id24":245,"24":{"DpId":24,"DpIdType":2,"DpIdData":"000000F5"}}}
21:42:43.888 TYA: fnId=71 is set for dpId=24
21:42:43.891 TYA: RX value 245 from dpId 24

But Set Temperature is like this (value 29 means 29C):

21:12:49.629 {"TuyaReceived":{"Data":"55AA03070008100200040000001D44","Cmnd":7,"CmndData":"100200040000001D","DpType2Id16":29,"16":{"DpId":16,"DpIdType":2,"DpIdData":"0000001D"}}}
21:12:49.633 TYA: fnId=72 is set for dpId=16
21:12:49.635 TYA: RX value 29 from dpId 16 

To fix it I made some changes (it works for Set Temperature value, but I didn't create PR because not sure my solution is good):

diff --git a/tasmota/xdrv_16_tuyamcu.ino b/tasmota/xdrv_16_tuyamcu.ino
index 68fd8ecc3..022b14af2 100644
--- a/tasmota/xdrv_16_tuyamcu.ino
+++ b/tasmota/xdrv_16_tuyamcu.ino
@@ -1360,7 +1360,7 @@ void TuyaSensorsShow(bool json)
             break;
           case 72:
             WSContentSend_PD(PSTR("{s}" D_TEMPERATURE " Set{m}%s " D_UNIT_DEGREE "%c{e}"),
-                            dtostrfd(TuyaAdjustedTemperature(Tuya.Sensors[1], Settings.flag2.temperature_resolution), Settings.flag2.temperature_resolution, tempval), TempUnit());
+                            dtostrfd(TuyaAdjustedTemperature(Tuya.Sensors[1], 0), 0, tempval), TempUnit());
             break;
           case 73:
             WSContentSend_PD(HTTP_SNS_HUM, "", dtostrfd(TuyaAdjustedTemperature(Tuya.Sensors[2], Settings.flag2.temperature_resolution), Settings.flag2.temperature_resolution, tempval));

Result looks like this:

.Will be glad to know your opinion.

FYI, I made some table of dpId for ME81AH using bookmarklet (also updated with PR to latest dpIds):

[Jason2866]

To do a general change makes no sense since there is no standard for anything in Tuya.
So what is the right choice for this device will be wrong for others.
In short Tuya is a mess...
Btw. no need to add #define USE_TUYA_TIME it is used as default since a while.

[b0rder]

To do a general change makes no sense since there is no standard for anything in Tuya.
So what is the right choice for this device will be wrong for others.
In short Tuya is a mess...
Btw. no need to add #define USE_TUYA_TIME it is used as default since a while.

It seems USE_TUYA_TIME became default in development version, because first time I tested it from stable builds.

.... to question of TempRes separation for 'Temperature' and 'Temperature Set'....

I try TempRes, but it is used as "generic" setting for both 'Temperature' and 'Temperature Set' setting. Probably, the best solution can be create additional option like 'TempSetRes' to be able separately set this value for 'Temperature' and 'Temperature Set'.

To make these changes 'backward' compatible, I propose to introduce additional command to control change of value TempRes for both 'Temp' and 'TempSet' or separately. For example:

Setoption117:
Control TempRes for 'Temperature' and 'Temperature Set':
0 = use TempRes value for both 'Temperature' and 'Temperature Set' (default)
1 = use TempRes value for 'Temperature' and 'TempSetRes' value for 'Temperature Set'

With this solution we will have backward compatibility by default, but will have possibility to change TempRes values separately for 'Temperature' and 'Temperature Set' when required.

Any comments appreciated.

[b0rder]

Created PR for this feature.
Does not affect any existing driver, but allow us to set separate Resolution for 'Temperature Set' in tuya driver.

[Kolia56]

Thank you for the nice addition related to temperature resolution.
I wonder whether a "status sensor" could be mapped to the relay state. This status sensor would be publish by MQTT. The reason I'm asking is the following: most of my heaters are already remotely controlled by a specific system. For obvious reasons, it is out of question to wire the relay output to this system. What I'm looking is to get the relay state and the by program set the corresponding order to the corresponding heater.

While I've got everything published, I don't see how I can set the temperature target with MQTT. I know how to do it using tuyaMCU command. Any idea?
Thanks again

[barbudor]

If you know to type the command in the console, you know how to send through MQTT
For command XXXX, just publish on cmnd/%topic%/XXXX and set the command's payload in the MQTT payload

[Kolia56]

Thanks, it turns out that I was about to post back. I just understood that TuyaSend2 xx,xx was also a valid MQTT command. So I came up with
cmd/%topic%/tuyasend2 16,12 to set target temperature to 12 (for instance). 16 is the dpId as explained above.

As for the other question, state of the relay, any thoughts?

[barbudor]

I don't know that device but if you get some feedback, you're likely be able to make a rule to republish to a topic of your choice
What exact feedback do you get?

[Kolia56]

it seems to me, looking at the logs (weblog 4 activated) that nothing is reported whenever the relay switches On or Off. To make sure, I installed Tuya MCU helper. I wonder whether it is a hardware or a software limitation