Paulus Schoutsen
Paulus Schoutsen
We should not add `SUPPORT_TARGET_HIMIDITY_RANGE` as we're in the process of removing that flag for temperature too: #264.
Just an update on this, we have introduced a device registry that holds entities. This will better map to the data model as set forth by Web Things.
Device classes describe the state, not what measures/causes the state.
max temp and min temp are the maximum and minimum supported values to be set. target_temp_high, target_temp_low are the current set temperatures if it's a range, otherwise use target_temp.
If cooling with a range, does that mean that if it's too hot, no cooling is done ?
How are you going to keep track of the template changing the trigger values? Do you suggest to re-attach the trigger on every state change? What if the state change...
Right… so you actually want to propose we support templating for `wait_for_trigger` and not all triggers everywhere in Home Assistant. That's a lot smaller scope. How do you propose the...
How would it work? A config either takes templates and it is processed or it doesn't. When it does, we should also allow passing in variables.
But templates can also be dynamic, like `{{ states.light.kitchen.state == states.input_select.hello.state }}`. That wouldn't work as the template won't be re-evaluated on each change.
Please give a YAML example how you think this should work.