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

[GrahamS (Graham Smith)]

I am now at HA 0.97.1 and using MQTT HVAC to replace a custom component for the Mitsubishi Heatpump. It works well but the pop-up history graph does not show a green fill when operating ie. hvac_modes is cool (or something other than off)
operation_mode was recently renamed to hvac_modes so maybe that is the problem?

Here is my configuration code:

climate:
 - <<: &mitsu_platform
      platform: mqtt
      modes:
        - "off"
        - heat
        - dry
        - cool
        - fan_only
        - auto
      fan_modes:
        - AUTO
        - QUIET
        - "1"
        - "2"
        - "3"
        - "4"
      swing_modes:
        - AUTO
        - "1"
        - "2"
        - "3"
        - "4"
        - "5"
        - SWING
      current_temperature_template: "{{ value_json.roomTemperature }}"
      temperature_state_template: "{{ value_json.temperature }}"
      swing_mode_state_template: "{{ value_json.vane }}"
      fan_mode_state_template: "{{ value_json.fan }}"
      mode_state_template: >
        {% if value_json.power == "OFF" %}
          off
        {% elif value_json.mode == "FAN" %}
          fan_only
        {% else %}
          {{ value_json.mode|lower }}
        {% endif %}
  - <<: *mitsu_platform      
    name: "Mitsubishi Heatpump"
    current_temperature_topic: "heatpump/status"
    temperature_command_topic: "heatpump/_set/temperature"
    temperature_state_topic: "heatpump"
    swing_mode_command_topic: "heatpump/_set/vane"
    swing_mode_state_topic: "heatpump"
    fan_mode_command_topic: "heatpump/_set/fan"
    fan_mode_state_topic: "heatpump"
    mode_command_topic: "heatpump/_set/mode"
    mode_state_topic: "heatpump"

I am not sure what

- <<: &mitsu_platform

does as I copied this code from here
I just stripped it down for one heatpump. There is the following automation that goes with this.

  - alias: 'Redirect all MQTT HVAC set commands to the heatpumps'
    trigger:
      - platform: mqtt
        topic: heatpump/_set/+
    action:
      - service: mqtt.publish
        data_template:
          topic:  '{{ "heatpump/set" }}'
          payload: >
            {% if trigger.topic.split("/")[-1] == "mode" %}
              {% if trigger.payload|upper == "OFF" %}
                {"power":"OFF"}
              {% elif trigger.payload == "fan_only" %}
                {"power":"ON","mode":"FAN"}
              {% else %}
                {{ "{\"power\":\"ON\",\"mode\":"|safe + trigger.payload|upper|tojson + "}" }}
              {% endif %}
            {% else %}
              {{ "{" + trigger.topic.split("/")[-1]|tojson + ":" + trigger.payload|tojson + "}" }}
            {% endif %}

[123 (Taras)]

@GrahamS

using MQTT HVAC

Are you using my customized version of MQTT HVAC? Because this thread is dedicated to discussing the customized, not standard, version of MQTT HVAC.

[GrahamS (Graham Smith)]

Sorry, I am trying to use the standard MQTT HVAC and avoid a custom component. Seems that a fix has been merged here. I will have to wait for it to be released and the MQTT HVAC documentation updated.

[123 (Taras)]

@GrahamS

I will have to wait for it to be released

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.

[GrahamS (Graham Smith)]

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.

[123 (Taras)]

@GrahamS

attribute called hvac_action which is either “ON” or “OFF”

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.

[GrahamS (Graham Smith)]

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" %}
        cooling
      {% else %}
        idle
      {% 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.

[majdzik84]

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)

[123 (Taras)]

@majdzik84

cannot import name ‘ATTR_OPERATION_MODE’

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.

[RezzZ (ReneS)]

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?

[123 (Taras)]

@RezzZ

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
  trigger:
    platform: mqtt
    topic: temp/climate/hvac_mode
  action:
    service: mqtt.publish
    data_template:
      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.

[RezzZ (ReneS)]

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 .

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.

[123 (Taras)]

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

[RezzZ (ReneS)]

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

Add missing _template variables for mqtt climate components

I like the fact that I can register mqtt climate components in HA (in my case fibaro heat controllers that are connected to a separate zwave2mqtt docker container), but right now the component available is only usable as a read-only component in case the supported modes of your device does’t conform to the default modes that HA offers: [“auto”, “off”, “cool”, “heat”, “dry”, “fan_only”] There is a cool feature to create a template for mapping actual modes to these modes in HA via the mode_sta…

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

[lhanneus (Luc Hanneuse)]

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

[SteveDinn]

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?

[123 (Taras)]

@SteveDinn

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

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:

@SteveDinn

my MQTT climate devices not showing the green filled-in part of the history graph …
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.

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 %}
        off
      {% 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.

[SteveDinn]

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’.

Thanks!

[123 (Taras)]

Exactly.

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.

[SteveDinn]

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’.