HA resetting Thermostats to 16°C frequently

Hi all,

long time HA user here. I keep getting a very annoying problem with ZHA. I have 3 Thermostats from HAMA https://www.amazon.de/Hama-Heizkörperthermostat-Heizungssteuerung-programmierbarer-Heizungsthermostat/dp/B08GSRV3PB?th=1 and am controlling those via Zigbee. I am using a Tasmota flashed Sonoff Zigbee Bridge, which works like a charm with all my lights. Thermostats work also, although I got some connection issues sometimes which make the Thermostat show up as unavailable for a few seconds.

A big problem however is that sometimes I notice the flat get cold and true enough, when I go to HA the thermostat is set to 16°C. I feel like this doesn’t have to do with the Thermostat being unavailable, as sometimes the previous temperature is retained after it comes back.

Already thinking about switching back to manual thermostats :frowning:

Any ideas?

I’d check the log.

Look for automations, temp changes, mode changes, presence changes etc. All are possible triggers to change temp.

Thanks for your reply! I deactivated all automations days ago to counter this possible reason. Logbook for a thermostat entity:

Here you can see the graph which shows a lot of drops to 16 °C. Nothing shows up in the logs:

Unclear we have enough information for a prime suspect. What heater device is being used? Can you confirm that it is functioning as expected? Wiring is ok…?

The next area to confirm is the thermostat itself. ZigBee thermostats can have their own local programming that is adjustable. Often via ZigBee attributes.

Sorry for my late reply, our daughter was born, so I was a bit preoccupied with other things :smiley:

I did a reset of some stuff and checked again with the automations and indeed, whenever an automation is activated involving a thermostat entity the problem occurs.

On such automation looks like this:

- alias: 'Badezimmer: Nachts aus'
  trigger:
    platform: time
    at: "20:00:00"
  action:
    - service: climate.set_temperature
      target:
        entity_id: climate.tze200_yw7cahqs_ts0601_thermostat
      data:
        temperature: 15
        hvac_mode: heat
- alias: 'Badezimmer: Morgens an'
  trigger:
    platform: time
    at: "05:00:00"
  action:
    - service: climate.set_temperature
      target:
        entity_id: climate.tze200_yw7cahqs_ts0601_thermostat
      data:
        temperature: 22
        hvac_mode: heat

Hi, i have the same issue. Could you solve it?

I have HAMA thermostats as well and I believe this happens when the default (factory) time schedule is activated.
Please check if youre thermostat show a little clock icon next to the network symbo. if it is lit press the rotary again to deactivate it. this solved the issue on mine - until someone accidentaly activates it again by double pressing the rotary.

I think the correct solution would be to remove the schedule by connecting the thermostat to the hama cloud and remove the schedule in there.
My only concern is that the thermostat might get an update which might render it useless to home assistant afterwards.
Has anyone of you successfully switched back and forth between using the hama app and home assistant?

1 Like

I have the same problem with my Hama thermostats. I have two thermostats and no automatisations confogurated yet. I just noticed this 16C change at one of my thermostates and I checked for the symbol. And really: The one who changed had the symbol, the other one not. So this might solve the problem.

Seems like it haven’t solved the problem. Today it just happened again with one of my thermostats:

Changed to Auto
17:10:11 - 1 hour ago

Maybe I will try the hama cloud connection to remove the programmed shedule inside.

EDIT:

I just did.
The firmware shown for my thermostat was the newest avilable one (ZigBee Module: V1.1.5, MCU Module: V1.0.0). Withing the Hama app I turned off the pre defined program (heating plan) and also several options like Limescale protection and anti frost protection.

Then I paired it again with my HomeAssistant/Zigbee2MQTT. That worked fine. But it seemed like all options set before where resetet in that process. In state menu of the device the parameter frost_detection is set back to ON.

I can also not find any setting inside Zigbee2MQTT to turn of Limescale protection and Anti freeze protection.

Under state the following is shown:

{
    "anti_scaling": "ON",
    "away_mode": "OFF",
    "battery_low": false,
    "child_lock": "UNLOCK",
    "current_heating_setpoint": 5,
    "frost_detection": "ON",
    "linkquality": 129,
    "local_temperature": 22.1,
    "local_temperature_calibration": 0,
    "preset_mode": "none",
    "system_mode": "heat",
    "window_detection": "OFF"
}

I’m wondering what the anti_scaling parameter is , maybe Limescale protection? The documentation is unfortunately not covering this parameter.

I’m also wondering about the system_mode with value heat. It is definitely not heating right now. Or is this just indicating the thermostat isn’t off and also not in auto mode?

Thanks for trying.
It looks like the Zigbee2MQTT way of integration is providing all the stuff I’m missing from the HA zigpy integration. I’m tempted to switch but I’m unsure if my pi3 can handle it.
btw. there is a quirk for the missing parts but it is not really working yet. [Device Support Request] Saswell Tuya Thremostat Family Improved Quirk · Issue #1189 · zigpy/zha-device-handlers · GitHub
I might give it another try and dust of my python knowledge but for now I want to keep my setup stable for a few weeks to im prove the WAF of my current home assistant setup :wink:

I tried around a bit the last days and I’m pretty sure now that the anti_scaling is the internal field for Limescale protection. Also after testing around I thing the system_mode with value heat just indicates that the thermostat will start heating when the defined current_heating_setpoint isn’t reached.

The Zigbee2MQTT GUI doesn’t let you set the values for anti_scaling and frost_detection, but it is possible to set this values over mosquitto_pub.

Short instructions to turn off anti scaling in Home Assistant OS:

  1. Log in to your device via SSH (SSH module has to be installed)
  2. Send message to your mqtt broker, changing the value (Mqtt broker like Mosquitto broker has to be installed):
mosquitto_pub -h 192.168.30.28 -u mqtt-user -P "PASSWORD" -t "zigbee2mqtt/Firendly Name/set" -m "{\"anti_scaling\": \"OFF\"}"

Where 192.168.30.28 has to be replaced by the local IP Address of the HomeAssistant device and mqtt-user and password by the MQTT user data. “Firendly Name” has to be replaced by the friendly name of the thermostat.

Now the value should have changed. For turning of frost detection it’s gpoing analog, just with frost_detection in payload.

But I’m wondering if there is any way to set how much open the valve is inside the thermostat when heating and if there is a way to store heating plans on the device (as it is possible with the official app). Any ideas are welcome.

This was the solution to my problem, that drives me crazy since days!
2 simple presses on the weel…

On one I needed to do a hart reset, taking out the battery for a few minutes. Because the clock was just blinking constantly after a while…

Thank you.

Heating state just means it’s on.
There is PID addon Thermostat with PID controller - #2 by mengine
Where you can track the “real” heating state.

But I haven’t figured it out yet.

Where is it fetching the data from?
Under ‘state’ in Zigbee2MQTT I only have the follwoing values:

{
    "anti_scaling": "OFF",
    "away_mode": "OFF",
    "battery_low": false,
    "child_lock": "UNLOCK",
    "current_heating_setpoint": 5,
    "frost_detection": "OFF",
    "linkquality": 84,
    "local_temperature": 19.8,
    "local_temperature_calibration": 0,
    "preset_mode": "none",
    "system_mode": "off",
    "window_detection": "OFF"
}

I was thinking only those values are useable?

Hello, I have the same topic. I was trying to follow your instruction, because my status of Anti scaling is still ON. My Problem is, that I get the Answer Error: Unknown option '“OFF”}

I am not really experienced.So any Idea what I can do?

Just a quick update:
The quirk seems to work in the latest version although I have never checked the additional switches.
One thing that is cool is the ability to verify if the TRV is actually heating the room / the valve is open.

I also tried zigbee2mqrt but the valve state is not working with zigbee2mqttt.

Overall I really saved money by using smart TRVs and the Hama ones are better than others like the Fritz Dect (slow response times to ha commands) or a Tuya TV02 (big hysteresis)

I‘ve still one question: Is it normal that if the battery is empty the valve stays open? I‘ve had this twice and find it very annoying.