I have 2 template binary_sensors defined in YAML (in a templates file ‘included’ in configuration.yaml). They are identical apart from 1 or maybe 2 variables (DEFANGLE and CLOUDY) that I set. I would like to create the code once and then re-use that YAML with differing values for 1 or 2 of those variables.
I’ve looked at ‘includes’ and ‘anchors’, but the former seems to not be usable in this case and the latter is not clear to me.
The following works as I want, but with much duplicated code and I’m a DRY lover so would like to coalesce the basic code into one ‘block’ and re-use that in the 2 sensors, but varying only by 1 or 2 variable values.
Currently I’ve been unable to figure out a solution to this, so am hoping someone more expert in YAML can offer some guidance.
I don’t think there is a solution because when you start Home Assistant the configured sensors are created. You can’t change the sensor configuration dynamically.
I often wish HA were a little bit more friendly to DRY.
In any event, another option here is to define custom Jinja macros, but then you still end up with having to duplicate the import/call-macro code.
A more radical option is to create just one sensor, but for each desired variant thereof (DEFANGLE and CLOUDY in this instance), have a label and use it as a key in a dictionary in an attribute.
For example, in my setup, rather than having a separate sensor entity for each room in my house, I have a single sensor entity where a “temperatures” attribute is a dictionary with room_name/temperature pairs. It does make the template code a little bit more convoluted, but it can avoid a lot of repetition.
I had thought of using a single sensor, with attributes to return the lighting up times for inside and outside, but on the whole wanted the simplicity of using binary sensors.
In any case, that would involve duplicating most of the calculations to arrive at the different values, so wouldn’t actually save anything.
In theory, once I’ve got DEFANGLE and CLOUDY set to suitable values, it shouldn’t then need messing with, so being WET (I.e. not DRY ) won’t present a huge maintenance problem.
OTOH, I could just use light sensors inside and outside to indicate when lights should turn on, but where’s the fun in that.
I actually don’t read the documentation to limit variables blocks to trigger-based entities only.
On that page, the variables map is not restricted to trigger-based entities only. Compare the spec for auto_off, which expressly says a trigger is required.
It is a little confusing, though, because the binary_sensor part of this documentation also has indented fields. But that is clearly not a comprehensive list of what’s supported by binary_sensor; for example, unique_id is discussed only at the top level.
Yeah, the first many times I looked at this document I also was confused by that and thought that entire section was just for “trigger-based” templates, but it applies to all.
I’m not trying to nit-pick, just making sure if someone finds this post who is confused by this they can get the info they need.
Funny fact: the “configuration reference” some time ago was INSIDE the “Trigger-based template” section - and then I proposed this PR to move this “configuration reference” part on a higher level ))).
Seems that some more clarifications should be added here to clarify which options may only be used for trigger-based templates.
dedicated to blueprints.
And before some HA update this “variables” option worked inside “action” part - and I am not sure that it worked as a standalone.
) won’t present a huge maintenance problem.
