ME81H set command sometimes doesn't work

[roleoroleo]

ME81H.16 with 1.20n.

This is the strange behavior:

• I set a parameter sending an mqtt command with MQTT Explorer (for example targetTemperature): {"targetTemperature":21.0}
• The thermostat understands the command
• The thermostat replies with the state in the "properties" topic where I can see the parameter correctly changed (targetTemperature = 21.0
• After a second, the thermostat sends another state message where the parameter comes back to the previous value.

If I try to set the value 2 or 3 times, finally it works.

Anyone have the same problem?

[roleoroleo]

This is a set command example and the log. Topic: climate_general/thermostat/set Payload: {"schedulesMode": "off"}

Log of a subscribed client:

root@mqtt:~# mosquitto_sub -v -h 127.0.0.1 -t climate_general/#
climate_general/thermostat/set {"schedulesMode": "off"}
climate_general/thermostat/properties {"idx":"climate_general","ip":"192.168.1.227","alive":true,"firmware":"1.20n","temperature":20.50,"targetTemperature":20.00,"deviceOn":true,"schedulesMode":"off","locked":false,"state":"heating","systemMode":"heat","sensorSelection":"internal"}
climate_general/thermostat/properties {"idx":"climate_general","ip":"192.168.1.227","alive":true,"firmware":"1.20n","temperature":20.50,"targetTemperature":20.00,"deviceOn":true,"schedulesMode":"auto","locked":false,"state":"heating","systemMode":"heat","sensorSelection":"internal"}

Same problem if I use Topic: climate_general/thermostat/set/schedulesMode Payload: off

[MrNomNom]

I can confirm that I am experiencing same behaviour.

[fraintt]

Hello, I can confirm that I have also the same issue, sometimes its firing on the first command, sometimes I need to send the MQTT 3-4 times. If I can help debug it somehow let me know!

[PhilipTS]

Hello,

I have a ME102H.31 thermostat that came with a WBR3 module that I swapped with an ESP module & with WThermostatBeca 1.24beta.

I can confirm that I also have this problem. Sometimes I have to send the set command 2-3 times for it to stay. This is for both set/targetTemperature and set/deviceOn.

Maybe related to something @AlbertWeterings mentioned in the below link ... https://github.com/klausahrenberg/WThermostatBeca/issues/246#issuecomment-1002149625

"undoable with this flood on data being send from the mcu. I noticed in a curtail WiFi switch a year ago that the wifi module has to send some kind of acknowledge message back to the MCU to stop it from repeating the same transmission over and over again."

Maybe the newer MCUs send to much data to the ESP module and overload it/slow it down?

[PhilipTS]

Small video of the issue ... very apparent after 2:00

philip-table_20211229_2018.zip

[AlbertWeterings]

This issue can be solved by changing two interval times in WTuyaDevice.h `

• define HEARTBEAT_INTERVAL 10000

• Changed to #define HEARTBEAT_INTERVAL 20000

• define MINIMUM_INTERVAL 2000

• Changed to #define MINIMUM_INTERVAL 10000 ` HEARTBEAT_INTERVAL is being send to the MCU to tell the TUYA device is still alive, I doubled the time as it still seems enough for the MCU to know the TUYA device is still alive. MINIMUM_INTERVAL is querying the MCU for settings. It is useful to have this at a 2 second interval during debug activities but it is meaningless during normal operation.

@PhilipTS You can test this binary

P.S.:You can't change target temperature over MQTT when scheduler is on Auto.

[PhilipTS]

@AlbertWeterings

The WiFi icon is now constantly flashing (with WThermostat_1.0.2_alpha.bin) Maybe HEARTBEAT_INTERVAL 20000 is to high?

[PhilipTS]

@AlbertWeterings

After power cycling the thermostat everything is working fine with WThermostat_1.0.2_alpha.bin Will now test to see if the SET value problem is solved :)

As a future enhancement maybe you could do GPI0 2 & 14 go low together? In order not to need the extra wire ... for our next ME102Hs :)

[PhilipTS]

@AlbertWeterings

I managed to reproduce the problem. I assume that if we send the set command while the ESP is querying the MCU this set gets lost/reverted? And from the tasmota web log that I attached in issue #246 I can see that the MCU sends a lot when queried. What if some logic was implemented to hold the set command and send it after the query, or resend it if not set?

[AlbertWeterings]

@PhilipTS Yes you are right the problem can be reproduced. I also see that when the MCU is being queried when the set target temperature is being send it doesn't pickup the new value. I can make the command send twice by the WIFI module that is not a nice solution but might help. An other option is to do this in for example Node-Red.. We can compare there the value being send from the device with the entered value and resend if there is a mismatch

[PhilipTS]

@AlbertWeterings Now that is a good idea. Resend from Node-Red or in my case with an Automation from HA. But we will have to monitor all set values ... but I guess it will work ...

[AlbertWeterings]

@PhilipTS I tried for the past hour several way's to get this work correctly nothing does. I also noticed that a lot of times the MCU is not executing commands being send. So I give up I think the best way is to check the status messages and resend commands if they where not executed right.

[PhilipTS]

I spent the whole day trying to figure out automations in HA and after many hours of reading and trying I finally fixed the automation. And I tested it and it would catch and fix this error. BUT ... big BUT When I changed the temperature from the thermostat ... my automation detected that THIS is not the value that was set by HA and returned it to the previous value !!! ARGGHHH

Guess i have to to make a time window in which the correction will happen. Something for 2022

[AlbertWeterings]

@PhilipTS i think if you put in a time Windows of 2 to 3 seconds you are safe. The thermostat sends 1 message when the new temperature is set. I noticed it sends two messages right after each other when if puts the temperature back to previous value.

[PhilipTS]

For anybody that has this problem and uses HA below is a dirty fix. It works with both @klausahrenberg and @AlbertWeterings firmware.

The first automation saves the sent targetTemperature in a Helper. The second one compares any received (within 3 second) targetTemperature properties to the Helper. If the values are different it resends the set command.

Update: After testing I made some changes in the Automations (and increased to 9 secs)

In configuration.yaml

climate:
  - platform: mqtt
    unique_id: central_thermostat_ME102H
    name: Central Thermostat
    current_temperature_topic: "AVATTO_ME102H/thermostat/properties/Temperature"
    temperature_state_topic: "AVATTO_ME102H/thermostat/properties/TargetTemperature"
    temperature_command_topic: "AVATTO_ME102H/thermostat/set/TargetTemperature"
    modes: [ "heat", "off" ]
    mode_state_topic: "AVATTO_ME102H/thermostat/properties/deviceOn"
    mode_state_template: >-
        {% if value == 'false' %}
            off
        {% else %}
            heat
        {% endif %}
    mode_command_topic: "AVATTO_ME102H/thermostat/set/deviceOn"
    mode_command_template: >-
        {% if value == 'off' %}
            false
        {% else %}
            true
        {% endif %}
    min_temp: 5
    max_temp: 35

Create a Number Helper with

Name: TargetTemperature
Entity ID: input_number.targettemperature

First Automation

alias: Save Target Temperature
description: 'Save Target Temperature with Helper'
trigger:
  - platform: event
    event_type: call_service
    event_data:
      domain: climate
      service: set_temperature
      service_data:
        entity_id: climate.central_thermostat
condition: []
action:
  - service: input_number.set_value
    target:
      entity_id: input_number.targettemperature
    data:
      value: '{{ trigger.event.data.service_data.temperature }}'
mode: single

Second Automation

alias: Check Target Temperature
description: 'Check Target Temperature with Helper'
trigger:
  - platform: mqtt
    topic: AVATTO_ME102H/thermostat/properties/TargetTemperature
condition:
  - condition: and
    conditions:
      - condition: template
        value_template: >-
          {{ states('input_number.targettemperature')|float != trigger.payload|float }}
      - condition: template
        value_template: >-
          {{ as_timestamp(now()) - as_timestamp(states.input_number.targettemperature.last_changed) <= 9 }}
action:
  - service: mqtt.publish
    data:
      topic: AVATTO_ME102H/thermostat/set/TargetTemperature
      payload: '{{ states(''input_number.targettemperature'') }}'
mode: single

[PhilipTS]

This MCU is ... stubborn ... I increased the time window to 60sec,

In the image below I set the target to 8 and the MCU changed it back 6 times !!! This was going on for 33sec !!!

[PhilipTS]

And very reproducible, but this fix is more stubborn than the MCU and in the end it sets the target temperature.

[AlbertWeterings]

@PhilipTS just a long shot can you try to change only 1 degree at the time and then see what happens?

[PhilipTS]

@AlbertWeterings That is what I did above, I would increase by 1 degree and wait 2-3 sec and then increase and then the up-down began down from the MCU up from HA. when it stabilized I started increasing again by 1 degree. All the decreases are from the MCU.

[AlbertWeterings]

@PhilipTS ah that is bad luck I was hoping for the mcu to be less going it’s own way by only 1 degree move at the time. I think we need data logging from the original tuya module to figure out if we are missing something or this same behavior is there to.

[PhilipTS]

Out of curiosity I Googled for Logic Analyzer and I could NOT believe what I found !!! SparkFun USB Logic Analyzer ... 20 Euros ... 20 Euros for an 8 channel Logic Analyzer !!! I've been out of the game for a long time ... and I like these new toys ... I ordered one :) Now I have to find the courage to swap back the WBR3 module. Or just order a second ME102H.31 for tracing the WBR3 module.

[AlbertWeterings]

@PhilipTS You could just use any TTL to RS232 interface to log the communication between MCU and WBR3 with the free software package Realterm It is indeed needed to return to the WBR3 WIFI module.

[AlbertWeterings]

Before I forget one important notice DO NOT power the thermostat from its own supply when you connect it to your PC it will blow your mainboard. You need to power it from a separate 12 and 5 volt supply

[PhilipTS]

Will be careful, Thanks for the warning. I might also try something else when I find some time. I downloaded the Tuya SDK and it has an MCU emulator. so I thought I might connect the WBR3 to my PC and run the MCU emulator and see how that works. Maybe it will give us some clues. And then I might even connect an ESP on the emulator.

[AlbertWeterings]

@PhilipTS that is a good idea. I also had one, I flashed my esp12 in a way the there is only wifi and ota updates. I can now connect the wbr3 module in parallel and see what is going on on the serial port

[fraintt]

@PhilipTS Hello, thank you very much for your setup, this is very helpful for setting the thermostate "manually" from the UI.

I have created myself some scripts which I could use in Automations:

This is for setting a temperature: (it checks if in auto mode, if yes, first runs "set manual mode" script and afterwards the temp)

alias: "Thermostate - Set 19 °C" 
sequence:
  - choose:
      - conditions:
          - condition: state
            entity_id: sensor.thermostat_schedulesmode
            state: auto
        sequence:
          - service: script.thermostate_set_manual_mode
          - repeat:
              until:
                - condition: state
                  entity_id: sensor.thermostat_target_temp
                  state: '19.0'
              sequence:
                - service: mqtt.publish
                  data:
                    topic: thermostat_15633253/thermostat/set/targetTemperature
                    payload: '19.0'
                - delay:
                    seconds: '{{ range(8, 11)|random|int }}'
      - conditions:
          - condition: state
            entity_id: sensor.thermostat_schedulesmode
            state: 'off'
        sequence:
          - repeat:
              until:
                - condition: state
                  entity_id: sensor.thermostat_target_temp
                  state: '19.0'
              sequence:
                - service: mqtt.publish
                  data:
                    topic: thermostat_15633253/thermostat/set/targetTemperature
                    payload: '19.0'
                - delay:
                    seconds: '{{ range(8, 11)|random|int }}'
    default: []
mode: single

This is a Script for setting Manual Mode (you can create the same for "auto/schedules" mode)

alias: Thermostate - Set Manual Mode
sequence:
  - repeat:
      until:
        - condition: state
          entity_id: sensor.thermostat_schedulesmode
          state: 'off'
      sequence:
        - service: mqtt.publish
          data:
            topic: thermostat_15633253/thermostat/set/schedulesMode
            payload: 'off'
        - delay:
            seconds: '{{ range(8, 11)|random|int }}'
mode: single

As you can notice I have created a random delay as I noticed that the MCU behaves differently when you send the command in different times, If i send the command exactly every 10 seconds it did not work, afterwards when pressing it 4 seconds later manually it worked, so thats why I used the random delay.

I also expose the states with an mqtt sensor as from the climate entity these are not propagated with the attributes.

Hope it helps as well.

[PhilipTS]

@fraintt A repeat with until and a random delay !!! Very nice ... very very nice ... this was my first automation and I see I have much to learn :) Thanks for sharing.

[fraintt]

Welcome to HomeAssistant ;) I suggest you to join also the community here , where you can get a lot of informations and/or help.

[PhilipTS]

@AlbertWeterings The emulator approach was not very helpful. I could not figure out a way to connect the WBR3 module to my WiFi network. I would only get the same over and over in the emulator. And some of the elements in the GUI are only in Chinese.

[AlbertWeterings]

@PhilipTS This is fun ;-) well with my WBR3 module connected in parallel no luck, then i tried the MCU emulator and with under protocol selected WIFI locked I was able to connect with my phone to my fake thermostat... And there it stopped. So I will try to put the WBR3 back in my thermostat and then try to debug. I hope my PCB will survive as I already have soldered and de-soldered the modules a lot of time.

[PhilipTS]

@AlbertWeterings ... May the force be with you ... I have plugged my soldering iron 3 times today ... But as i would approach the module I would get panic attacks and unplugged my soldering iron. I think I am also starting to accept the not so elegant solution with the HA automation. But I think when the Logic Analyzer gets here, I might get the courage to swap back the WBR3 to play :)

[AlbertWeterings]

@PhilipTS Well I'm done playing my WBR3 broke I lost the solderpad of RX. So I placed my ESP12 back on the board. We need someone with a original thermostat with this WBR3 module in it that can log communication for a longer time while playing with it.

The only thing I can do is extend the keep alive time and check if that works.

[PhilipTS]

@AlbertWeterings And I managed to splash solder on the MCU pins ... will try to clean up the mess tomorrow :( I have a Tuya i8H Thermostat coming from China but I am not spending any more money an anything that has a Tuya MCU. Already started to work on plan B (Sonoff Dual R3 with Tasmota and a Fire HD 8 tablet on the wall)

i8H

[AlbertWeterings]

@PhilipTS We spent some time here to solve the issue and this build I released is looking promising. I do not see any failures now.

[AlbertWeterings]

https://user-images.githubusercontent.com/36169962/147988181-a1a6c63f-29b3-44c9-9c4d-13e7541193f0.MOV @PhilipTS here we go

[PhilipTS]

@AlbertWeterings Look promising ... as soon as I clean up my MCU and put back the module I will try the new firmware. This time I will use wires for the module for easy future swaps.

[AlbertWeterings]

What I did to solve the issue is the following: In the original code our WIFI module is sending a query request to the MCU with an interval defined in QUERY_INTERVAL this interval needs to be at least the defined MINIMUM_INTERVAL after the lastheartbeat to be initiated. From there it is reinitiated every QUERY_INTERVAL. The transmission time of the query is roughly 1.5 to 2 seconds.

So what happens is this: A heartbeat is send with an interval of 10 seconds (org. code) after 2 seconds a query request is send by the MINIMUM_INTERVAL 2 seconds and repeated every QUERY_INTERVAL 2 seconds. So for 8 seconds there is a constant train of query requests being done. It takes roughly 1.5 seconds to send the date from the MCU to the WIFI module and in this time if we send a command to the MCU it is not listening.

I found that the MCU is sending a status message every 1 minute triggered by it's own clock and direct when a value is changed. This means for at least in the ME102H.WIFI with WBR3 we don't need to initiate a query request. As we send a status message over MQTT every 5 minutes the WIFI module is being updated already 5 times. If this is working for all thermostats needs to be tested.

If for some thermostats querying the MCU is needed then we can enable/disable the mechanism with a variable set for every thermostat separately and make sure the query request is not being repeated unnecessary

[AlbertWeterings]

@PhilipTS Can you try this build? It has an option in the web config to enable and disable the querying of the MCU by the WIFI module. Basically it is just switching between the code of @klausahrenberg and my modification

[PhilipTS]

@AlbertWeterings Just finished cleaning up the solder splash from my MCU and everything seems to be working fine without any module on. So now I will have to solder cables on the PCB an I will put a connector on the other end in order to be able to swap the modules without any risk of damaging the PCB. As soon as I finish I will test your new binary.

[PhilipTS]

@AlbertWeterings Wired up the WBR3 as I was curious to see the Tuya App (first time using it). Everything is working fine so I guess I did not damage anything :) Taking a break and later today I will wire up the ESP.

[AlbertWeterings]

@PhilipTS Looking nice, and this way you can easy swap modules. I'm curious how you like my latest build above it is at home running now and changing target temperature randomly every second in between 5 and 35 degrees, the result transmitted is put in a database and from here I do not see anything going wrong. The moment I switch on in the web interface "QueryMCU Actively" it is starting to get a big mess, but with the modified code I see no issues.

b.t.w. I found also an other good side effect of the fix. Previous storing scheduler was also not working flawless that is now also going right.

Next step is adding a temperature sensor like 18B20 to get temperature readings with a higher resolution as I don't want my room temperature swing around by roughly 1degree.

[PhilipTS]

@AlbertWeterings just flashed 1.0.5 alpha and will start testing.

How would you add a 18B20, the sensor is under the MCU control ... i don't think we could set the room temperature from the ESP module could we?

[PhilipTS]

@AlbertWeterings Me likes, me really likes this new version :) I changed 1oC at a time from 5 up to 35 and down to 5 again and everything worked fine. No DBs or anything advanced/scientific stuff like that ... but I do have a very nice graph from MQTT Explorer :)

[AlbertWeterings]

@PhilipTS Adding a 18B20 can be done by including the onewire and dallas library to and write some code to read the temperature with a interval lets say every 10 seconds and then take the average of it and replace the result Temperature in the MQTT message with this value. The sensor can be connected to one of the unused io pins of the ESP12. The temperature on the display is then still measured by the original sensor. It will be a lot of work to integrate this but it is doable.

Did you also toke a test run with QueryMCU enabled in the web config? Then you can see the difference in code.

[PhilipTS]

@AlbertWeterings That was my point. The display will show the temperature from the internal sensor, and the relay will be controlled from the internal sensor. If you target is to get a more precise temperature over MQTT why bother doing it from the thermostat. Just get a Sonoff Basic R2 and flash tasmota-sensors and hook-up an I2C sensor. I have 5 such devices in my house, very simple, low risk, easy soldering.

[AlbertWeterings]

@PhilipTS I know the concept of a Sonoff with temperature sensor I use them with ESPURNA. The reason for including it in the thermostat is having everything in one device. From the thermostat we now also have min and max heater temperature, I use these together with current temperature, target temperature to modulate my central heating device. Do i need to bridge a big gap in between current and target the goal is to start with a relatively high water temperature and lower that when the gap gets smaller to prevent overshoot. Then when target temp. is reached keep the heater on the lowest possible temp. to maintain target temp. and keep current and target temp as close as possible together. That is the reason I need to sense with a higher resolution. b.t.w may I ask you where you are located? I'm from the Netherlands.

[PhilipTS]

@AlbertWeterings :) :) :) I am located in Greece and the current temperature outside is 17C. Might go down to 5C at night. As you understand our heating needs are really REALLY very different. Congrats on your setup, It is very advanced and very smart. Controlling the temperature of the water that flows in the radiators!!! So the ME102H will be a small control panel, very nice.

[PhilipTS]

@AlbertWeterings This looks interesting, ESP32-C3 Module that is pin compatible with ESP-12F. I think i will leave my ME102H as is for easy swapping of modules. Will order another ME102H to put on the wall.

https://templates.blakadder.com/ESP-C3-12F.html

[AlbertWeterings]

@PhilipTS Ah from Greece, yep then you have a different expectation from the heating system ;-) Never the less you are in a great country with good food, I like the Greece kitchen.

What is you're goal putting a ESP32 in the thermostat? It is more expensive and has more processing power, but I think it is a total overkill for what we want it to do.

[PhilipTS]

@AlbertWeterings The ESP32-C3 variant has is a single core RISC-V cpu and is very cost-effective. It has more RAM/FLASH so it has more potential. And in the back of my mind I always have Tasmota. I have been using Tasmota for some time and i like the rules/scripting/logging/modules.

https://www.aliexpress.com/item/1005002760799398.html?spm=a2g0o.9042311.0.0.5b7a4c4dxB3sO9