MQTT HVAC config

Configuration
1

I have an MQTT controlled heating controller that publishes the following state topics for each room:

heating/living/valve_state [0 or 1]  // Current state of valve
heating/living/enabled [0 or 1]  // Generally enabled
heating/living/temp 19.50  // Target temp
heating/living/valve_level [0-255]  // How open the valve is

All channels have corresponding …/set command topics. valve_level isn’t particularly important to me, but if there is place, why not add it. In the old style, this was working:

- platform: mqtt
  name: living
  modes:
    - "1"
    - "0"
  power_command_topic: "heating/living/enabled/set"
  power_state_topic: "heating/living/enabled"
  mode_command_topic: "heating/living/valve_state/set"
  mode_state_topic: "heating/living/valve_state"
  temperature_command_topic: "heating/living/temp/set"
  temperature_state_topic: "heating/living/temp"
  current_temperature_topic: "livingroom/thermostat/temp"
  temp_step: 0.1
  precision: 0.1

In the new style, e.g. power_state_topic isn’t documented anymore?

Optimally, I would just like to send a discovery message but am unsure how to do that.

2

Okay, it seems that while power_state_topic is not in the doc, it seems to be supported? At least check_config does not complain?

I got up to here:

power_command_topic: "heating/living/enabled/set"
payload_on: 1
payload_off: 0
power_state_topic: "heating/living/enabled"
power_state_template: >-
  {% set values = { '0':'off', '1':'on'} %}
  {{ values[value] if value in values.keys() else 'off' }}

but the power_state_topic is not read correctly. The power button is always grey, but power_command_topic still always sends “0”.

Any ideas?

3

Hi,

Could you please report the message received under power_state_topic ?

Just to check if your template condition is correct.

4

power_state_topic just reports back the value from power_command_topic, so it is “0” or “1”. I don’t like optimistic modes but want real feedback from the device.

Here is the mosquitto_sub output from a switch-off event:

heating/living/enabled/set 0    // Event coming in
heating/living/valve_state 0    // From device: Valve closed
heating/living/valve_state/set 0    // From device: Valve set state for persistence
heating/living/enabled 0    // From device: Disabled
heating/living/enabled/set 0    // From device: Disabled set state for persitence

I have modified ll504+ in components/mqtt/climate.py to

if self._topic[topic] is not None:
                _LOGGER.info(
                    "Subscribe %s",
                    self._topic[topic],
                )
                topics[topic] = {
                    "topic": self._topic[topic],
                    "msg_callback": msg_callback,
                    "qos": qos,
                    "encoding": self._config[CONF_ENCODING] or None,
                }

but I only get subscriptions to

livingroom/thermostat/temp
heating/living/temp
heating/living/valve_state

reported, so if power isn’t managed by something else, there might be the issue. Still don’t understand why the power button from state OFF issues 0, not 1.

5

The behavior is the same when power_state_template is completely removed. Originally, I would have though that the payload covered both, but as that did not work, I added that template because the rest of the component seems to like strings more.

6

Did you check the log ? I think there should be an error or a warning reported there.
It is located in Settings → System → Logs

7

No, I don’t see any warning or error that could match this.

This is my only entry

Logger: homeassistant.helpers.template
Source: helpers/template.py:589
First occurred: 10:04:30 AM (7 occurrences)
Last logged: 10:04:30 AM

Template variable warning: ‘dict object’ has no attribute ‘action’ when rendering ‘{{ value_json.action }}’

Any thoughts on the fact that the subscription is not listed?

As I said initially power_state_topic also does not seem to be listed in the docs, but is accepted.

hass --script check_config also runs without issues.

8

There might be multiple causes here.
Could you please share your full new mqtt hvac configuration ?

9

Thanks for looking into this.
Here is my complete config:

mqtt:
  climate:
    name: Livingroom heating
    unique_id: home-uk_heating_living_climate
    modes:
      - "off"
      - "heat"
    mode_state_topic: "home-uk/heating/living/valve_state"
    mode_state_template: >-
      {% set values = { '0':'off', '1':'heat'} %}
      {{ values[value] if value in values.keys() else 'off' }}
    mode_command_topic: "home-uk/heating/living/valve_state/set"
    mode_command_template: >-
      {% set values = { 'off':'0', 'heat':'1'} %}
      {{ values[value] if value in values.keys() else 'off' }}
    power_command_topic: "home-uk/heating/living/enabled/set"
    payload_on: 1
    payload_off: 0
    power_state_topic: "home-uk/heating/living/enabled"
    temperature_command_topic: "home-uk/heating/living/temp/set"
    temperature_state_topic: "home-uk/heating/living/temp"
    current_temperature_topic: "home-uk/livingroom/thermostat/temp"
    temp_step: 0.1
    precision: 0.1
10

Your configuration seems good to me.

Just had a closer look at the code and it looks like the power state is retrieved from the mode_state.

Either the documentation is incomplete or there is a code issue.
And you’re right that the power_state_topic is never subscribed.

You may have to open an issue on github. At least for documentation clarification.

EDIT
It seems that it is just about the climate card.
Pressing the power button seems to be only to turn off the hvac.
Pressing the heat button turns on the hvac.
:confused:

11

You are right, that seems to be the behavior … I could account for that, as I have another binary_sensor for the mode anyway, but I find it rather unfortunate …

I opened an issue here.