Open VasekCejka opened 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.
I have made PR (d0b964d4524af099eeea67bc1ed96562711ea4d0). Basically preset_modes
and humidity
related properties are missing.
That is a commit, but not yet a PR to the openhab main branch.
FYI @ccutrer
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.
Sorry, I do it all for the 1st time. So I tried to make PR #17659 . Please, have a look at it.
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 MQTTsystem_mode
) supported by OpenHAB for my valves has valuesauto
,heat
,off
. The most convinientauto
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 ofClimate.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 frompreset_mode = auto
tomanual
. I'd like to check it and in some moments (e.g. on midnight) reset it toauto
.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:
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