HA MQTT discovery - implement climate type for eTRV

[Achronite]

Created a separate issue for this as it is a little tricky to do. @djwillis

snip from Achronite/mqtt-energenie-ener314rt#15

It's been a while, but I think something like this would work (assuming that you infill a few vairables obviously), the shorter names will work of course.

The MQTT node/sensor discovery topic would be climate/..../climate and you would reuse a lot of the TARGET_TEMP (and that could also be left as a tempreture sensor I guess).

Fairly sure that this is close, BUT I have done it by butchering up the message for one of my TRV's. I'll check later and update.

{ "min_temp": 5, "max_temp": 40, "temp_step": 0.5, < Not sure if this is true for these TRVs "temperature_state_topic": "~3/7575/TARGET_TEMP/state", "temperature_state_template": "{{ value_json.value }}", "temperature_command_topic": "~3/7575/TARGET_TEMP/command", "device": { "identifiers": [ "ener314rt-7575" ], "name": "Radiator 7575", "model": "Smart TRV", "manufacturer": "mqtt-energenie-ener314rt", "sw_version": "0.0.1" }, "name": "Radiator 7575 climate", "unique_id": "ener314rt-7575-CLIMATE" }

[Achronite]

I've been testing. Example manual setup configuration.yaml:

mqtt:
  climate:
    - unique_id: Climate_Test
      name: "Climate Test"
      current_temperature_topic: "energenie/3/4280/TEMPERATURE/state"
      max_temp: 40
      min_temp: 5
      modes: ["auto","heat","off"]
      mode_command_topic: "energenie/3/4280/VALVE_STATE/command"
      mode_command_template: "{% if value == 'auto' %} Auto {% elif value == 'heat' %} Open {%- else %} Closed {% endif %}"
      temperature_command_topic: "energenie/3/4280/TARGET_TEMP/command"
      temperature_state_topic: "energenie/3/4280/TARGET_TEMP/state"

Is this everything we need?

[djwillis]

This is what I had as a manual setup for testing, but it is definately not quite right and does not work yet as I would expect.

Very similar to yours, I think I was messing with mode state as a way of reading that for changes independant of HA but that only works once the topic is hit once after HA is loaded, playing with retained state and a bit more tracing is something I wanted to get to the bottom of in the next few days.

climate:
  - name: "Dining Room TRV"
    value_template: "{{ value_json }}"
    unique_id: 7575_trv
    max_temp: 40
    min_temp: 5
    current_temperature_topic: "energenie/3/7575/TEMPERATURE/state"
    temperature_state_topic: "energenie/3/7575/TARGET_TEMP/state"
    temperature_command_topic: "energenie/3/7575/TARGET_TEMP/command"
    temperature_unit: "C"
    modes: ["auto","heat","off"]
    mode_command_topic: "energenie/3/7575/VALVE_STATE/command"
    mode_command_template: "{% if value == 'auto' %} Auto {% elif value == 'heat' %} Open {%- else %} Closed {% endif %}"
    mode_state_topic: "energenie/3/7575/VALVE_STATE/command"
    mode_state_template: "{% if value == 'Auto' %} auto {% elif value == 'Open' %} heat {%- else %} off {% endif %}"

I was also looking at a way to fake avalability as I wondered if that had a baring on how HA was reading the subscribed topics, by deriving from existing topics as we don't have a simple online/offline topic to look at.

In fairness, the rules around online/offline for FCK devices, esp TRV's, needs some thought I would guess, I was thinking of faking something up for testing that was 'If no updates in SET_REPORTING_INTERVAL * 2 set to offline until next update' for testing the theory.

[Achronite]

When I coded the OpenThings devices (the eTRV being one of them), I made a couple of design decisions:

1. I only populate the state topic for messages I receive back from a device.
2. I chose not to set the retained flag on messages as I thought they would regularly report and so not need it.

After playing with Home Assistant, I believe that these decisions now have an adverse effect on the irregular (or on-demand) parameters that the eTRV sends out, even the ones that I previously held internally for the node-red module. The problem is also exacerbated by restarts of the node application as it has to 'start again' with the held values.

Now moving the the MQTT implementation, as you know, MQTT can hold state using retained messages. l think that it would be a good idea to set the retained flags on the eTRV values (with maybe the exception of TEMPERATURE, which reports every 5 minutes anyway). This can be done quite quickly, and would serve as a short-term fix until I get time to add regular reporting (#10). Does this seem like a good idea? @djwillis

[Achronite]

Released fix related to above comments into develop branch: _Set irregular reported values to be RETAINED on MQTT 'VALVE_STATE': 'LOW_POWER_MODE': 'REPORTING_INTERVAL': 'TARGET_TEMP': 'ERRORTEXT':

[djwillis]

Thanks, will pull it in and check it out, I suspect this will help a lot. Appreciated.

[Achronite]

I can't seem to group the climate with the other entities. @djwillis Have you managed to get this to group correctly?