Hi all,
For those interested, there is an ongoing discussion about Mitsubishi heatpumps and HA auto config.
Head to :
However I’m still using a variant of the first post here but with an old HA (0.8xx something).
Thanks, got it working! Great work on this.
I can almost get rid of my separate “status message” entities, I’m wondering if there is a way to get my “Status” messages to be displayed / logged in the thermostat entity. I have a few additional messages such as compressor delay, anti-freeze active and system error. My thermostats are built in Node-Red.
Are you aware of any problems in 0.96.+? I had this working in 0.95.4 but in 0.96.3 the entity doesn’t come up anymore.
I haven’t been able to find any error messages related to it other than "Platform not found: climate.my_mqtt" . The log does show the component being loaded, but I can’t find the entity listed.
Edit: I just found your post in the update blog from 4 days ago. I see that you are already on top of this issue. I’ll be checking back here to see if you have been able to sort out a solution.
I can confirm that the latest version of my custom component, designed for use with 0.93+, does not work with 0.96. Underlying changes introduced by ‘Climate 1.0’ have rendered it incompatible.
The enhancements I created can be summarized as follows:
activity_state_topic).mode, fan_mode, and hold.‘Climate 1.0’ supports the first two features. However, they are not yet fully implemented in MQTT HVAC 0.96.0 (nor in 0.96.3).
I raised the issue that the History Chart still graphs operation mode , not operating state, plus there’s no topic for receiving the operating state.
action_topic and action_template was done by @definitio via PR 25260. I don’t know when it will be implemented. It’s not in 0.96.3. Maybe it will be released in 0.96.4 or possibly 0.97.0.Whenever a release version containing definitio’s changes becomes available, two out of the three features offered by my custom component will be available in the release version. What won’t be available are the three command_templates. However, this functionality can be gained by using automations.
My plan going forward is to wait until definitio’s changes become available and then test that version. If all is well, I will no longer use nor maintain my custom component and switch to using the stock MQTT HVAC component.
Ideally, it should also support command_templates. However, until that’s implemented (if ever) I will use automations to transform the mode, fan_mode, and hold commands. It’s not as neat as native command_templates, but it’s a lot less work for me than maintaining a custom component.
I’ll post my test results after the new version becomes available.
It’s the command template that I needed most of all, too.
I did give it a whack with the 0.97.0-dev and as of last night’s build, no love.
Fortunately the heater I’m working with is only “on” and “off” and instead of trying to transform “heat” to “on” I am using the power on/off topic (since that gives you custom payload options). The alternative was to rewrite my controller’s firmware to accept “heat” instead of “on”.
I don’t know why a state template was implemented in the stock climate control but not a command template.
Here’s my workaround for the lack of a command_template. This example is for mode_command_topic but it is the same principle for fan_mode_command_topic and hold_command_topic.
Set mode_command_topic to a ‘middleman’ topic like this:
mode_command_topic: 'temp/climate/hvac_mode'
Create an automation that subscribes to the ‘middleman’ topic, converts the received payload for use with your thermostat, and publishes it to your thermostat’s command topic.
- alias: 'hvac_mode controller'
trigger:
platform: mqtt
topic: temp/climate/hvac_mode
action:
service: mqtt.publish
data_template:
topic: 'premise/command/thermostat/temperaturemode'
payload: >
{% set values = { 'auto':'0', 'heat':'1', 'cool':'2', 'off':'4'} %}
{{ values[trigger.payload] if trigger.payload in values.keys() else '4' }}
However, I agree with you, it would be preferable if the stock MQTT HVAC included support for the three command_templates. The needed code-changes are trivial (just a bit tedious). However, the submission process is a step beyond my current skills so it’s not likely I’ll be doing it any time soon.
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 %}
Are you using my customized version of MQTT HVAC? Because this thread is dedicated to discussing the customized, not standard, version of MQTT HVAC.
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.
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" %}
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.
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
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.
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.
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:
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.