I have a setup of 6 thermostats to control a floor heating system and one electric heater. All of a sudden the electric heater thermostat has started to behave very strange. It turns the heater on and off in 10 minutes intervals. The set point is stable and the measured temperature is also fairly stable. At least it does not explain this behaviour. I attach a screendump of the log book. It is the service.home_assistant.turn_off that turns off the switch and 4 minutes later the switch is turned on again. Unclear what triggers this.
The switch is a zigbee switch controlled by MQTT. All other thermostats (that are stable) are implemented with GPIO over MQTT. Looking at the zigbee2mqtt log, I see MQTT payload commands changing the switch states.
Has anyone seen a thermostat behaviour like this? Since it just one out of six thermostats that screws up and this is based on zigbee devices, it easy to draw the conclusion this is related to zigbee. However, all thermostat devices are controlled by MQTT, so the physical interace should not have any impact on Home Assistant.
Edit: Added this view of the climate entity. The strange behaviour is cleary visible in this picture. The switch turns on periodically even if the target temperature is well below the actual temperature.
Well, I have just figured out this problem is most likely related to MQTT, not HA. It looks like there is something else than the thermostat that changes the status of the switch that turns on the heater. I disconnected the switch from the thermostat, and the switch still goes on after a few minutes.
When the thermostat is configured with this switch, it will notice the on state and turns it off. Then “someone else” turns it on again. This explains the error.
I just wonder who plays this game. I can see the payload command in the zigbee2mqtt log, but I can’t see from where it originates. I don’t think HA is responsible for this. This switch is not used by any automation or script. Looking at the MQTT debug info (in HA) I can see the following:
zigbee2mqtt/Sovrum_plan2_el
10 most recently received message(s)
Received 15:23:00
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:25:17
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:29:16
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:33:00
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:33:00
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:33:16
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:37:15
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:41:14
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:43:00
QoS: 0
Payload: linkquality: 81
state: 'ON'
Received 15:43:00
QoS: 0
Payload: linkquality: 81
state: 'ON'
So I must find out who sends those commands…
Edit: I have two challenges with this. First one - how do I specify a client id the HA MQTT client? The GUI based configuration for the MQTT is very limited, so I guess I need to add the config i YAML. But what is the format ?
Second one - I need to configure logging of my mosquitto MQTT broker (I have a standalone broker on a separate RPI, not the HA addon) so id is included in the logs. -v option? Tried this without success.
I can’t figure out who is responsible for sending this payload ‘on’ command. There are no other MQTT clients on my network than HA and zigbee2mqtt. I can change switch status to ‘off’ on both (HA on HASSIO/RPi 1 and zigbee2mqtt frontend on my second RPi) clients, but after a few minutes status is ‘on’ again.
I think I’ve found a solution of this problem now. In my initial setup I had my original MQTT broker (mosquitto) on a remote RPi together with two MQTT clients, zigbee2mqtt and MQTT IO.
Yesterday night I replaced the broker with the HA addon and reconfigured my clients to use this one instead. It looks like my switch output is stable after this move.
Still I have no explanation what caused the problem with my initial setup. But the symptom seems to be gone. I cross my fingers the switch remains stable. I’ll come back within a few days with a report.
