Need help with value_template for MQTT HVAC

  1. you were right, I tried the previous version for one of the climate components for which I didn’t add the mode_command_template
  2. I tried the new version without the mode_command_template and nothing happens (as it should!)
  3. with the right mode_command_template it works fine!

for information, here is an example of the climate component (I have 6)

    name: Chambre d'amis
    unique_id: chambre_d_amis
    current_temperature_topic: homegear/climate/plain/3/1/ACTUAL_TEMPERATURE
    temperature_state_topic: homegear/climate/plain/3/1/SET_TEMPERATURE
    temperature_command_topic: homegear/climate/set/3/1/SET_TEMPERATURE
    min_temp: 10
    max_temp: 30
    temp_step: 0.5
    modes: ["auto","manual","party","boost"]
    mode_state_topic: homegear/climate/plain/3/1/CONTROL_MODE
    mode_state_template:  >-
      {% set values = { '0':'auto', '1':'manual', '2':'party', '3':'boost'} %}
      {{ values[value] if value in values.keys() else 'off' }}
    mode_command_topic: homegear/climate/set/3/1/CONTROL_MODE
    mode_command_template: >-
      {% set values = { 'auto':'0', 'manual':'1', 'party':'2', 'boost':'3'} %}
      {{ values[value] if value in values.keys() else '0' }} 

Could it be that there is an issue with the custom climate.py in version 0.90.1?
Got the following error:
Platform not found: climate.mqtt_custom
Check here:

Great job what you did !

Any idea is it complicated to add a temperature_command_template?

For my Eurotronic Spirit the setpoins needs to be send as json format like this:

temperature_command_template: '{{ value_json.current_heating_setpoint }}'

I’m using it with 0.90.1 and it works without any issues.

The Platform not found message suggests to me that the custom component was not installed in the correct directory.

Here are the installation instructions I posted earlier in this thread:

Create a new directory under custom_components called my_mqtt.

config/custom_components/my_mqtt

Copy the contents of this pastebin link into a new file called climate.py.

config/custom_components/my_mqtt/climate.py

In configuration.yaml, find your existing MQTT climate entity and replace:

platform: mqtt

with:

platform: my_mqtt

The next step is needed ONLY if your climate entity is configured with a unique_id. If it doesn’t then skip the next two bullet-points and go directly to the Config Check step.

  • Use a text editor to modify the following file: config/.storage/core.entity_registry
  • Find your climate entity and replace: "platform": "mqtt" with "platform": "my_mqtt"

Run Config Check and, if no errors are reported, restart Home Assistant.

It’s not very complicated. However, I can’t promise I’ll get around to adding it anytime soon.

As a workaround, you can use an automation.

Example:

In the climate component’s configuration, enter a new topic:

temperature_command_topic: home/setpoint

The automation:

- alias: 'setpoint converter'
  hide_entity: true
  trigger:
    platform: mqtt
    topic: home/setpoint
  action:
    service: mqtt.publish
    data_template:
      topic: eurotronic/setpoint # <-- change this for your Eurotronic thermostat
      payload: "{'temperature': {{trigger.payload}}}" # <-- change this for your needs

How it works:

  • The climate component publishes its setpoint to home/setpoint.
  • The automation is triggered by home/setpoint and re-publishes the payload to eurotronic/setpoint.
  • Assuming the received payload is 22 the format of the re-published payload is in JSON: {'temperature':22}

Adjust eurotronic/setpoint and the payload template to suit your specific needs.

1 Like

Hi @123,

It’s working now. My mistake was to copy init.py also to the custom_mqtt folder.
Tnx

A bit unsure about changing mqtt to my_mqtt in core.entity_registry
Nothing in there related to my HAI thermostats but I have several entries like this of sonoff devices:

            {
            "config_entry_id": "17df94434e514bedbe717c16eb7b5e86",
            "device_id": "339e0abf3fbf4f2dacd5957d5d21ee06",
            "disabled_by": null,
            "entity_id": "sensor.sonoff_ds18b20_temperature",
            "name": null,
            "platform": "mqtt",
            "unique_id": "971098_DS18B20_Temperature"
        },

Does the configuration for your HAI thermostat have unique_id?

If it doesn’t then you don’t need to concern yourself with editing core.entity_registry because the HAI thermostat won’t be in there.

Each HAI theromstat has a MQTT id starting with climate., ie climate.garage_heat or climate.masterbdrmht or climate.guestbdrmht etc.
But none are in the core.entity_registry file with any device_id or anything else. I only see sonoff/tasmota devices and iPhone devices listed there.

Doesn’t look like it is installing correctly. Sure I missed something.
from log file at boot:

2019-04-02 16:08:36 INFO (MainThread) [homeassistant.components.switch] Setting up switch.mqtt
2019-04-02 16:08:42 INFO (MainThread) [homeassistant.loader] Loaded my_mqtt.climate from custom_components.my_mqtt.climate
2019-04-02 16:08:42 WARNING (MainThread) [homeassistant.loader] You are using a custom component for my_mqtt.climate which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-04-02 16:08:42 INFO (MainThread) [homeassistant.setup] Setting up climate
2019-04-02 16:08:43 INFO (MainThread) [homeassistant.components.climate] Setting up climate.my_mqtt
2019-04-02 16:08:43 INFO (MainThread) [homeassistant.setup] Setup of domain climate took 0.3 seconds.
2019-04-02 16:08:43 INFO (MainThread) [homeassistant.loader] Loaded mqtt.climate from homeassistant.components.mqtt.climate
2019-04-02 16:08:43 INFO (MainThread) [homeassistant.components.climate] Setting up climate.mqtt
2019-04-02 16:08:43 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic].
2019-04-02 16:08:43 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic].
2019-04-02 16:08:43 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic].
2019-04-02 16:08:43 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic].
ys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic].
2019-04-02 16:10:28 INFO (MainThread) [homeassistant.setup] Setting up axis

1 Like

The following messages are normal and indicate the my_mqtt custom component was loaded:

2019-04-02 16:08:42 INFO (MainThread) [homeassistant.loader] Loaded my_mqtt.climate from custom_components.my_mqtt.climate
2019-04-02 16:08:42 WARNING (MainThread) [homeassistant.loader] You are using a custom component for my_mqtt.climate which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.

This set of messages (there are several) indicates a genuine problem:

2019-04-02 16:08:43 INFO (MainThread) [homeassistant.components.climate] Setting up climate.mqtt
2019-04-02 16:08:43 WARNING (MainThread) [homeassistant.helpers.config_validation] Your configuration contains extra keys that the platform does not support.
Please remove [temperature_low_state_topic], [temperature_low_command_topic], [temperature_high_state_topic], [temperature_high_command_topic].

You are getting that message because my custom MQTT climate component does not support the following keys you have entered in the configuration file:

  • temperature_low_state_topic
  • temperature_low_command_topic
  • temperature_high_state_topic
  • temperature_high_command_topic

I don’t know why you’ve specified those options but they won’t work with my custom component. Perhaps these are for someone else’s custom climate component.

I just went through every .yaml file I have and nothing related to these temp topics is there.
I thought these started and were related to the install of omnilink-bridge. That they are being reported from the Omni-Pro-II and HA can handle them because of some MQTT protocol issues. Will do more checking tomorrow. I have had this error notice before trying your my.climate change.
Thanks for looking at this. Will let you know what I find.

Thanks a lot for useful modification!
Why not to implement to main branch of HA by pull request? As far as I can consider, nothing can be broken.

Because someone else submitted a PR (several months ago), that would use a new dedicated topic (like activity_state_topic ) to help differentiate between the thermostat’s operating state (i.e. its current activity) and its operating mode. The PR was rejected on the grounds it didn’t conform with the ongoing architectural discussion for climate components (I don’t use the word ‘ongoing’ lightly; the discussion started over a year ago and there doesn’t appear to be any consensus yet).

My custom component uses the same technique as in the rejected PR (so there’s a good reason why I wouldn’t bother submitting it as a PR). I’ve been using it since version 0.80 without any problems. Although I enjoy debating the merits of various technical approaches, this is one situation where I needed a working MQTT climate component sooner (6 months ago) than later.

To everyone who is using my custom component, please be advised that I’ll be making additional changes to it in the near future because of internal changes made in Home Assistant 0.90. Version 0.91 continues to tolerate my custom component (it reports the component is using a deprecated way of calling certain functions) but I know future versions will stop working with it unless I update it.

Woow great thanks for you help!

Any thoughts for the mode_state_template?

I got this:

mode_state_topic: "zigbee2mqtt/bathroom/switch/0003/thermostat"
mode_state_template: '{{ value_json.eurotronic_system_mode }}'  

And 1 is like normal operation, 2 is boost and 3 is child protection

From the documentation for MQTT HVAC, the default modes are:

modes:
  - auto
  - 'off'
  - cool
  - heat
  - dry
  - fan_only

These are the modes Home Assistant understands (and they’re used for Lovelace’s climate card).

Your value_template has to convert the modes reported by your Eurotronic thermostat into modes understood by Home Assistant.

For example, my thermostat reports its modes using a number. Here is each number mapped to one of Home Assistant’s modes.

0 = auto
1 = heat
2 = cool
4 = off

My thermostat’s configuration is like this:

   modes:
     - auto
     - heat
     - cool
     - 'off'
   mode_state_topic: "premise/thermostat/temperaturemode" 
   mode_state_template: >-
     {% set values = { '0':'auto', '1':'heat',  '2':'cool', '4':'off'} %}
     {{ values[value] if value in values.keys() else 'off' }}
   mode_command_topic: "premise/command/thermostat/temperaturemode"
   mode_command_template: >-
     {% set values = { 'auto':'0', 'heat':'1',  'cool':'2', 'off':'4'} %}
     {{ values[value] if value in values.keys() else '4' }}

You said your thermostat also reports its modes as numbers. However, the problem I see is that the modes you mentioned (normal operation, boost, child protection) don’t have direct equivalents in Home Assistant. Perhaps ‘normal’ can be handled as ‘auto’?

Thank you for your reply. Then I will use the Home-Assistant names for it.

How to handle it with mode_state_template: ‘{{ value_json.eurotronic_system_mode }}’

Like you made it like this:

mode_state_template: >-
{% set values = { ‘0’:‘auto’, ‘1’:‘heat’, ‘2’:‘cool’, ‘4’:‘off’} %}
{{ values[value] if value in values.keys() else ‘off’ }}

To help you design the template, I will need more information about the thermostat you are using. Is there documentation available for this thermostat describing its operating modes? Do you have examples of its JSON payloads?

Over MQTT the following message structure is visible over the broker:

zigbee2mqtt/bathroom/switch/0003/thermostat {"occupied_heating_setpoint":21,"unoccupied_heating_setpoint":16,"eurotronic_system_mode":1,"current_heating_setpoint":18.5,"pi_heating_demand":192,"local_temperature":17.7,"eurotronic_error_status":0,"battery":35,"linkquality":60}

System modes, Today I will do some testing which system mode I will receive when I turn on the protection mode by using the keys on the thermostat itself :

1 = (default 1)
2 = Boost
4 = Window open
7 = Child protection

Documentation, if you can read German :slight_smile: :

Only the first one has an equivalent MQTT HVAC mode which is heat. There are no equivalent modes for the other ones.

Hi
I’ve just updated from 0.89 to 0.93 and the custom component is not working anymore: Integration my_mqtt not found when trying to verify its climate platform.
it is located in /home/homeassistant/.homeassistant/custom_components/my_mqtt and there is one file climate.py as in this post Need help with value_template for MQTT HVAC
and the core.entity_registry is edited with my_mqtt instead of mqtt
is there something I’m missing?