Enhanced version of MQTT HVAC (Climate platform) with proper History Chart

It’s already released in version 0.97.

MQTT HVAC now has an optional action_topic. It permits MQTT HVAC to receive the device’s current operating status (hvac_action). I’ve tested it in my system and it works.

I added this to configuration.yaml:

action_topic: "heatpump"
action_template: "{{ value_json.power }}"

It works in that I now get an attribute called hvac_action which is either “ON” or “OFF”.
How do I get the hvac_action attribute to control the green fill in the UI pop-up?

There is something that I need to update in my Climate integrations since HA 89.1
I have also noticed that the green fill does not work for my generic thermostat either.

I don’t think a value of on or off will be used to create the green shaded area of the chart.

Here are the relevant recent changes made to the charting code. In a nutshell, it looks for hvac_action to be either heating or cooling.

Thanks you your help, slightly off topic. ( This probably affects your custom component too.)
I replaced my configuration.yaml code with

    action_topic: "heatpump"
    action_template: >
      {% if value_json.power == "ON" %}
      {% else %}
      {% endif %}

The hvac_action attribute is now either “cooling” or “idle” but I am still not seeing the green fill. Seems like a bug was introduced in HA0.96 that has been reported here.

Hi. an error pops up when checking the configuration. What can I do?

Platform error climate.my_mqtt - cannot import name 'ATTR_OPERATION_MODE' from 'homeassistant.components.climate.const' (/usr/src/homeassistant/homeassistant/components/climate/const.py)

Which version of Home Assistant are you using?

In Home Assistant version 0.96, the climate component’s architecture was modified (“Climate 1.0”) and this custom component has not been updated to work with it.

The architectural changes implemented, since 0.96, now provide many of the features found in my custom component. Therefore it is no longer necessary for me to maintain a customized version of MQTT HVAC.

Hi guys, do I still need the enhanced hvac component or should I be able to set my mqtt hvac when I use the mode_state_template to translate my hvac modes?

Right now my hvac (fibaro heat controller uses ‘Heat’ or ‘Off’ (start with capital letter), so I set the state template to:

mode_state_template: >-
    {% set values = { '"Heat"':'heat', '"Off"':'off' } %}
    {{ values[value] if value in values.keys() else 'off' }}

This only fixed the mode_state_topic translation. Is the current mqtt.climate component so limited that it can’t reverse the same for the mode_command topic? Or am I missing something here?

No, you understand it correctly. It doesn’t have a mode_command_template to allow you to convert from Home Assistant’s states to your device’s states.

My custom MQTT HVAC component supported a mode_command_template but I’m no longer maintaining it. Here’s how I do it now using the stock version of MQTT HVAC (since version 0.97).

Set mode_command_topic not to the command topic used by your device but some other ‘middleman’ topic.

    mode_command_topic: "temp/climate/hvac_mode"

Create an automation that subscribes to the ‘middleman’ topic, transforms the payload, and publishes it to your device’s command topic. For my device, I need to transform Home Assistant’s text-based states into numeric states.

- alias: hvac_mode controller
    platform: mqtt
    topic: temp/climate/hvac_mode
    service: mqtt.publish
      topic: premise/command/home/thermostat/temperaturemode
      payload: >
        {% set values = { "auto":"0", "heat":"1", "cool":"2", "off":"4"} %}
        {{ values[trigger.payload] if trigger.payload in values.keys() else "4" }}

I do the same for fan_mode_command_topic and hold_command_topic.


hi Taras, thanks for the tip! that will definitely work!
Can’t believe they created a mode_state_template but not a command_state_template… They made it a read-only mqtt_climate component that way :face_with_raised_eyebrow:.

I will request this to be added later today when I have more time. I’ll post the link here so people can upvote it.

I’m not sure what the thinking was but it’s been that way since at least when I first started using it (a year ago). That’s why I had created a custom component, notably to address the History Chart but also to add the three additional command_templates:

  1. mode_command_template
    Convert mode with a template for publishing to MQTT
  2. fan_mode_command_template
    Convert fan_mode with a template for publishing to MQTT
  3. hold_command_template
    Convert hold with a template for publishing to MQTT
1 Like

Feature request created. Lets see and wait what happens. Please comment there if you would like to see this fixed as well!

edit: created a new feature request as the github issue has been closed.

1 Like

temperature_command_template would be usefull,
I have to use @123 workaround to template it with an alias Need help with value_template for MQTT HVAC

Is the purpose of this custom component just to have the abililty to interpret more values with templates?

I’m having a problem with my MQTT climate devices not showing the green filled-in part of the history graph ever since the climate component re-vamp. I assmed that was because of the action_topic/action_template parameters of the built-in component. My device doesn’t support these, but I’ve hacked them in to simply read the same topic/template as ‘mode’ but I still don’t see any green on my graphs.

What needs to happen for me to get my green graphs back?

It was that and to correct the way it displayed the green-shaded area. Originally, MQTT HVAC graphed whenever the HVAC system was in ‘heat’ or ‘cool’ mode. In other words, the green-shaded area didn’t just show when my furnace was actively heating but the entire time it was just in ‘heat’ mode. So in winter it would show an endless, day after day, green-shaded area because, of course, the furnace is in heat mode all winter. Not a very useful or informative graph.

The way I fixed it (full disclosure: I borrowed the idea and code from a rejected PR created by definitio) was to change the value stored in the MQTT HVAC’s state. Traditionally it stored the operation mode (heat, cool, auto, off, etc) and that’s what the frontend UI uses to produce the graph. I changed it to store its activity (heating, cooling, idle). This is what definitio’s PR did but was rejected by balloob. He didn’t like the idea of changing the state’s purpose and there was an architectural review underway. All this happened a year ago and the review was already months in progress. I couldn’t wait for the official solution (which, for MQTT HVAC, came out last August), so I created a custom component.

I also added several command_templates because there’s no means of converting the climate component’s values into the form needed by the physical device.

Enough about ancient history and now to your issue:

These are several accepted values the action_template should produce but the two used for creating the green-shaded area are: heating and cooling. If your template is generating heat and cool it will fail to be rendered in the graph. If you’ve tied it to the mode, you’ll need to create a map to convert the mode to an acceptable action (i.e. convert heat to heating).

My physical thermostat does report its activity but not as a numerical value. The following template converts those values and perhaps you can use it (with some modification) for your needs:

    action_topic: "premise/home/thermostat/heatingstatus"
    action_template: >-
      {% if states('climate.thermostat') != off %}
        {% set actions = { '1':'heating', '2':'cooling', '4':'idle'} %}
        {{ actions[value] if value in actions.keys() else 'idle'}}
      {% else %}
      {% endif %}

That seemingly superfluous if-else test is there because the physical device doesn’t use the activity_topic to report when it is off. If it did, then the if-else becomes unnecessary and the template reduces to just two lines.

Ah! I am missing the ‘ing’ on the action. My templates were setting action and mode to both be ‘heat/cool’, when action actually needs to be ‘heating/cooling’.



If you can, try to incorporate the idle state as well. Without it, the Lovelace UI uses the word Off to indicate two possible states:

  1. When the HVAC system is truly off.
  2. When the HVAC system is in heat/cool mode but not actively heating or cooling at the moment.

The backend of my MQTT climate component is an infra-red remote-controlled heat pump. I don’t have real state information for it. So in my case, I have no way to determine ‘idle’. ‘Off’ really means ‘off’.

Hi Taras

i have a problem with the mqtt hvac because i have a danish nilan Compact s heatpump/ventilationsystem also with hot water and i would like to have the system actual running mode shown i ha i can get the state witch i a number between 0 -16 but during to the Hvac mqtt climate template it only accepts these modes
- “off”
- heat
- dry
- cool
- fan_only
- auto
and i have all theese
0 : Off
1 : Shift
2 : Stop
3 : Start
4 : Standby
5 : Ventilation stop
6 : Ventilation
7 : Heating
8 : Cooling
9 : Hot water
10 : Legionella
11 : Cooling + hot water
12 : Central heating
13 : Defrost
14 : Frost secure
15 : Service
16 : Alarm

Is there a easy way around that

best regards kdy

I don’t think you’ve posted your question in the correct topic. This topic is about a custom MQTT HVAC component that I no longer support.

Your question appears to be about the standard MQTT HVAC integration. According to its documentation, here are the modes it supports:

A list of supported modes. Needs to be a subset of the default values.
Default value:
[“auto”, “off”, “cool”, “heat”, “dry”, “fan_only”]

and here are the actions it supports (equivalent to what you called the “actual running mode”):

The MQTT topic to subscribe for changes of the current action. If this is set, the climate graph uses the value received as data source. Valid values: off , heating , cooling , drying , idle , fan .

Your HVAC system can only be represented by these modes and actions. MQTT HVAC can’t use any other modes/actions that your HVAC system may have.

All I can suggest is that you create a Template Sensor to report the whatever MQTT HVAC cannot.

Yes you are right

i am currios to why it is not possibel to modify the mqtt hvac is it hardcoded or does it use some template and who do i have to ask to get more modes

sorry if i ask stupid questions i am new to Ha how i make a template sensor that will show modes acording to a state number from 0-16

thanks in advance