TuyaMCU MQTT topics vary depending on data reporting trigger

[Janrupf]

PROBLEM DESCRIPTION

I'm using TuyaMCU based thermostats with tasmota in homeasisstant with the MQTT integration. When homeassistant restarts (or reloads entities), it seems to trigger the tasmota MQTT status reporting.
This results in the current data being spit out on the stat/tasmota_kinderzimmer_thermostat/STATUS10 topic using the following format:

{"StatusSNS":{"Time":"2022-03-25T23:15:12","TuyaSNS":{"Temperature":23.0,"TempSet":215},"TempUnit":"C"}}

However, when the thermostat temperature is changed using TuyaSend2 2,240 (set target temperature to 24.0) or buttons on the thermostat, the following message is received on tele/tasmota_kinderzimmer_thermostat/SENSOR:

{"TuyaSNS":{"TempSet":240}}

This now leads to problems in homeassistant, as the topic is different and the data is not recognized anymore. The probably technically correct way of retrieving the information would be to subscribe to the tele/tasmota_kinderzimmer_thermostat/SENSOR topic, however, when homeassistant is reloading all entities and requests information using status 10, this results in the thermostat not displaying the current data.

To sum up:

• When using status 10 (homeassistant initial status request), the required data is sent on stat/tasmota_kinderzimmer_thermostat/STATUS10.
• When the temperature is changed using the TuyaMCU, the required data is sent on tele/tasmota_kinderzimmer_thermostat/SENSOR (in a different format too...).

While this behavior is logical, it creates the issue of either waiting for the teleperiod to trigger once (so that homeassistant receives data on tele/tasmota_thermostat/SENSOR or to subscribe to stat/tasmota_kinderzimmer_thermostat/STATUS10 and thus not receiving notifications on external changes. This situation is somewhat suboptimal.

See differently phrased explanation for the same problem here: #2567 (comment)

REQUESTED INFORMATION

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): ME81H
• Tasmota binary firmware version number used: 11.0.0.4
  • Pre-compiled
  • Self-compiled
• Flashing tools used: esptool
• Provide the output of command: Backlog Template; Module; GPIO 255:

3:38:14.899 MQT: stat/tasmota_thermostat/RESULT = {"NAME":"Thermostat","GPIO":[1,2272,1,2304,1,0,0,0,1,0,544,0,1,0],"FLAG":0,"BASE":54}
23:38:15.118 MQT: stat/tasmota_kinderzimmer_thermostat/RESULT = {"Module":{"0":"Thermostat"}}
23:38:15.374 MQT: stat/tasmota_kinderzimmer_thermostat/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"2272":"Tuya Tx"},"GPIO2":{"0":"None"},"GPIO3":{"2304":"Tuya Rx"},"GPIO4":{"0":"None"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"0":"None"},"GPIO13":{"0":"None"},"GPIO14":{"544":"LedLink"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"},"GPIO17":{"0":"None"}}

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

-- Not applicable

• Provide the output of this command: Status 0:

3:38:58.843 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS = {"Status":{"Module":0,"DeviceName":"Kinderzimmer Thermostat","FriendlyName":["Kinderzimmer Thermostat"],"Topic":"tasmota_kinderzimmer_thermostat","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"LedMask":"FFFF","SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":0,"InfoRetain":0,"StateRetain":0}}
23:38:58.849 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS1 = {"StatusPRM":{"Baudrate":9600,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://ota.tasmota.com/tasmota/release/tasmota.bin.gz","RestartReason":"External System","Uptime":"0T05:40:00","StartupUTC":"2022-03-25T16:58:58","Sleep":50,"CfgHolder":4617,"BootCount":13,"BCResetTime":"2022-03-25T17:12:03","SaveCount":56,"SaveAddress":"F4000"}}
23:38:58.854 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS2 = {"StatusFWR":{"Version":"11.0.0.4(tasmota)","BuildDateTime":"2022.03.24 16:40:49","Boot":31,"Core":"2_7_4_9","SDK":"2.2.2-dev(38a443e)","CpuFrequency":80,"Hardware":"ESP8266EX","CR":"401/699"}}
23:38:58.859 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS3 = {"StatusLOG":{"SerialLog":0,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["mlig-orbi",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C80001000600003C5A0A190000000000","00000280","00006000","00004000"]}}
23:38:58.870 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS4 = {"StatusMEM":{"ProgramSize":631,"Free":372,"Heap":21,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"1440C8","FlashFrequency":40,"FlashMode":3,"Features":["00000407","8FDAC787","04368001","000000CF","010013C0","C000F981","00004004","00001000","00000020"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,27,29,30,35,37,45,56","Sensors":"1,2,3,4,5,6"}}
23:38:58.879 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS5 = {"StatusNET":{"Hostname":"tasmota-kinderzimmer-thermostat","IPAddress":"192.168.10.137","Gateway":"192.168.10.1","Subnetmask":"255.255.255.0","DNSServer1":"192.168.1.2","DNSServer2":"192.168.3.1","Mac":"BC:DD:C2:8D:36:FC","Webserver":2,"HTTP_API":1,"WifiConfig":4,"WifiPower":17.0}}
23:38:58.883 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.10.3","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_8D36FC","MqttUser":"tasmota","MqttCount":2,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30,"SOCKET_TIMEOUT":4}}
23:38:58.890 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS7 = {"StatusTIM":{"UTC":"2022-03-25T22:38:58","Local":"2022-03-25T23:38:58","StartDST":"2022-03-27T02:00:00","EndDST":"2022-10-30T03:00:00","Timezone":"+01:00","Sunrise":"06:42","Sunset":"19:09"}}
23:38:58.895 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS10 = {"StatusSNS":{"Time":"2022-03-25T23:38:58","TuyaSNS":{"Temperature":23.0,"TempSet":200},"TempUnit":"C"}}
23:38:58.901 MQT: stat/tasmota_kinderzimmer_thermostat/STATUS11 = {"StatusSTS":{"Time":"2022-03-25T23:38:58","Uptime":"0T05:40:00","UptimeSec":20400,"Heap":21,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":2,"POWER":"ON","Wifi":{"AP":1,"SSId":"mlig-orbi","BSSId":"0E:02:8E:8F:D8:D9","Channel":9,"Mode":"11n","RSSI":100,"Signal":-47,"LinkCount":2,"Downtime":"0T00:00:08"}}}

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

-- Not applicable

TO REPRODUCE

1. Install tasmota on a ME81H thermostat (or really any tuya based thermostat)
2. Connect thermostat to MQTT
3. Add thermostat to homeassistant using the HVAC MQTT integration

EXPECTED BEHAVIOUR

Unclear, however, there are multiple solutions:

• Blame homeassistant for not allowing multiple MQTT topics for a single state variable (ugh?)
• Introduce something like option 59 (SetOption59) for Tuya SNS
• Always send tele/.../SENSOR topic on Status 10
• Send stat/.../STATUS10 on TuyaSNS changes

SCREENSHOTS

Homeassistant display (missing data) before initial tele/.../SENSOR is received:

ADDITIONAL CONTEXT

This seems to have been somewhat discussed in #2567 (especially #2567 (comment)), though only scratching the surface and not addressing the root cause.

I'm not really aware of a workaround at the moment, and this seems somewhat simple to fix. In case we can decide on a solution, I'd be happy to contribute the required code to implement it.

[barbudor]

Have HA to send a 'teleperiod' command instead of a 'sensor 10' to receive a tele/../SENSOR message instead

[Janrupf]

How would I do that? From my understanding the cmnd/.../STATE message is sent by the Tasmota HA integration - though this integration doesn't deal with thermostats, so no option of changing that.

Furthermore, I'd like to keep this open in order to discuss on possible solutions on the tasmota side.

[sfromis]

I'd expect the TuyaSNS messages to be in addition to the regular sensor payloads, and not really intended for backend usage, unless you know exactly what you want to do.

[barbudor]

The problem is HA not sending the right command
You said you want to contribute, so fix HA

Why overloading again and again the embedded software that runs on a constraint MCU to solve issues in the software that runs on computer with much more ressources?

[Janrupf]

I'd expect the TuyaSNS messages to be in addition to the regular sensor payloads, and not really intended for backend usage, unless you know exactly what you want to do.

I'm not exactly sure why tasmota sends the data the way it does, the message looks like this:

// topic = tele/tasmota_kinderzimmer_thermostat/SENSOR
{"Time":"2022-03-26T00:22:13","TuyaSNS":{"Temperature":23.5,"TempSet":200},"TempUnit":"C"}

Since tasmota does not provide preconfigured devices for Tuya thermostats, my best guess is that this format is simply the result of me manually binding that data (also note that tasmota reports the set temperature as 200°C, because the TuyaMCU uses 200 for 20.0, 215 for 21.5 and so on)

Why overloading again and again the embedded software that runs on a constraint MCU to solve issues in the software that runs on computer with much more ressources?

I'd agree if this wasn't the result of data being sent in an inconsistent way. Thinking about it, maybe it would make sense for sensor data to be included in the result returned by the STATE command, as TELEPERIOD also triggers tele/.../state

[barbudor]

I'm not exactly sure why tasmota sends the data the way it does, the message looks like this:

You get 20.5 for Temp because your TempRes is configured to 2
For Tuya TempSet, the configuration command is TuyaTempSetRes
The TuyaTempSetRes has been added especially for this as Tuya has the golden medal for inconsistency with some devices using different ranges for Temp and TempSet...

I'd agree if this wasn't the result of data being sent in an inconsistent way.

• Telemetry messages tele/../SENSOR and tele/../STATE/ are sent at the telemetry period and can be manually trigger with the appropriate Teleperiod command.
• Status messages stat/../STATUS { StatusXXX: { } } are produced by the command status command StatusXXX. All StatusXXX are consistent.
• STATE command returns a stat/../STATE

Where do you see inconstancy here ?
IMHO, having SO59, to force sending a tele prefix in response to a state request doesn't look very consistent.