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
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
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]”.