I’ve given this some thought just now and it’s not that trivial.
I got to the point of adding a dummy command_line
switch for the heater
component of the generic thermostat, which uses the value_template
of my central heater state. Toggling does nothing (so climate.turn_on
and off
just don’t do anything). All radiators and thermostats can use this same switch. Additionally, each thermostat/radiator needs a custom sensor that sets its state to the radiator/therostats current_temperature
attribute.
But the problem arises when you want two-way sync between the generic thermostat component and a homematic radiator/thermostat. It can be done, but you need platform: state
automations in both directions, which is prone to looping. Imagine you have a generic thermostat and a homematic radiator; when you use two automations, one to change the generic target_temperature
with the homematic temperature
attribute, and another in the exact opposite direction - when you change one, the state gets set to the other, which will replicate the state back - ad infinitum.
There is a sort of workaround with the custom component variable
, where both the generic thermostat and the homematic thermostat state changes propagate to that variable, and then the variable propagates back to the thermostats. but it’s still pretty ugly.
So I canned it and decided this wasn’t worth the trouble. I think it should at least be possible to set the radioator/thermostat temperatures directly, but seems even that’s not working at the moment.
I’ve resorted to IFTTT currently, with an IFTTT applet per radiator/thermostat where i can say “set [room] temperature to [value]”.