openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.88k stars 3.59k forks source link

[mqtt.homeassistant] Unsupported climate properties of some thermostatic radiotor valves #17632

Open VasekCejka opened 2 weeks ago

VasekCejka commented 2 weeks ago

Hello, I have couple of different thermostatic radiator valves based TS0601 tuya model (e.g. TRV602). All of them use some properties defined in homeassistant climate component, that are not discovered as channels on OpenHAB. For my situation there are for example MQTT topics related to preset_mode (preset_modes, preset_mode_command_template, preset_mode_command_topic, preset_mode_state_template, preset_mode_value_template), but there are others related to humidity... I'm not for long here and I don't know the history - maybe they are part of newer specification of climate component, maybe there was some reason not to implement it i OpenHAB. Can the climate component in mqtt.homeassistant be enhanced by adding support to them?

My motivation: all valves I have have more "mode" properties for different use cases. Mode property (in MQTT system_mode) supported by OpenHAB for my valves has values auto, heat, off. The most convinient auto state means, that PID control of valve position focused on desired temperature is in operation. But it does not speak about the way, how the desired temperature is set: manually (rotating the knob by hand or set by the OpenHAB Item) or automatically using predefined per-day schedules. For this setup there is another property, preset_mode. At this moment it is not part of Climate.java definition, so it is not linked to OpenHAB during discovery. My experience tells, that it is much more safer to use auto schedules built in valves than controling the temperature using some scheduling SW mechanism in OpenHAB. There are many situation of communication failures between valves (battery based, weak signals...), coordinator and OpenHAB. But the trouble is, that whenever someone touches the valve's knob, it switches from preset_mode = auto to manual. I'd like to check it and in some moments (e.g. on midnight) reset it to auto.

My suggestion: add all properties currently defined in homeassistant Climate component, so that OpenHAB is fully compatible with any device suporting this component.

My configuration: OpenHAB 4.2.2 stable, Zigbee2MQTT 1.40.2 commit: [e06848d] Example of MQTT climate config topic:

{
  "action_template": "{% set values = {None:None,'idle':'idle','heat':'heating','cool':'cooling','fan_only':'fan'} %}{{ values[value_json.running_state] }}",
  "action_topic": "zigbee2mqtt/Termostat005",
  "availability": [
    {
      "topic": "zigbee2mqtt/bridge/state",
      "value_template": "{{ value_json.state }}"
    },
    {
      "topic": "zigbee2mqtt/Termostat005/availability",
      "value_template": "{{ value_json.state }}"
    }
  ],
  "availability_mode": "all",
  "current_temperature_template": "{{ value_json.local_temperature }}",
  "current_temperature_topic": "zigbee2mqtt/Termostat005",
  "device": {
    "identifiers": [
      "zigbee2mqtt_0xa4c1384e18af9a28"
    ],
    "manufacturer": "Tuya",
    "model": "Thermostatic radiator valve. (TRV602)",
    "name": "Termostat005",
    "via_device": "zigbee2mqtt_bridge_0xe0798dfffe9ca9e8"
  },
  "json_attributes_topic": "zigbee2mqtt/Termostat005",
  "max_temp": "35",
  "min_temp": "5",
  "mode_command_topic": "zigbee2mqtt/Termostat005/set/system_mode",
  "mode_state_template": "{{ value_json.system_mode }}",
  "mode_state_topic": "zigbee2mqtt/Termostat005",
  "modes": [
    "auto",
    "heat",
    "off"
  ],
  "name": null,
  "object_id": "termostat005",
  "origin": {
    "name": "Zigbee2MQTT",
    "sw": "1.40.2",
    "url": "https://www.zigbee2mqtt.io"
  },
  "preset_mode_command_topic": "zigbee2mqtt/Termostat005/set/preset",
  "preset_mode_state_topic": "zigbee2mqtt/Termostat005",
  "preset_mode_value_template": "{{ value_json.preset }}",
  "preset_modes": [
    "auto",
    "manual",
    "off",
    "on"
  ],
  "temp_step": 0.5,
  "temperature_command_topic": "zigbee2mqtt/Termostat005/set/current_heating_setpoint",
  "temperature_state_template": "{{ value_json.current_heating_setpoint }}",
  "temperature_state_topic": "zigbee2mqtt/Termostat005",
  "temperature_unit": "C",
  "unique_id": "0xa4c1384e18af9a28_climate_zigbee2mqtt"
}

I can be part of implementation / testing process. I have quite good coding experiences, but not in in java and not OpenHAB. Thanks for the great SW! Vasek

lsiepel commented 2 weeks ago

In 4.3 the binding has had a lot of work. you could check the daily snapshot build. The climate component is supported, but I’m not sure into what extend. Feel free to create a PR if something is missing, might be useful to discuss the suggested changes first.

VasekCejka commented 2 weeks ago

I have made PR (d0b964d4524af099eeea67bc1ed96562711ea4d0). Basically preset_modes and humidity related properties are missing.

lsiepel commented 2 weeks ago

That is a commit, but not yet a PR to the openhab main branch.

FYI @ccutrer

ccutrer commented 2 weeks ago

I can't say for sure if it's just that Home Assistant evolved and added more, or if the original openHAB implementation simply neglected them. It's just as likely to be either. In the end, it doesn't really matter... we're not matching the current spec, and it needs to be corrected. I have been going through some of the older component implementations lately, and bringing them up to current spec, but had not yet gotten to climate, so thank you. I'd be happy to review it once you send it as a proper PR.

VasekCejka commented 2 weeks ago

Sorry, I do it all for the 1st time. So I tried to make PR #17659 . Please, have a look at it.