Why is jinja2 usage within the .yaml configuration limited?

I’am fairly new to HA (1-2months). Due to continued suffering with other smarthome solutions (zipato, homee, openhab2), I am now migrating all my devices to HA step by step. Roughly I am talking about ~45 z-wave nodes + 15+ wifi-connected devices (including media_players and stuff)…

Most of the things are pretty smooth, impressive (startup/restart/running) performance (especially compared to openhab2), at least for me there is nothing I miss from the other systems—plus appdaemon fullfils all my nerd-dreams for automation and beyond that.

So never the less I am constantly annoyed by a “feature” in HA. Due to the amount of the Z-Wave devices I have to include, I find myself doing an awful lot of copy&paste, for 3-liners, 10-20 times the roughly same stuff, e.g. this:

    input_number:                                                                    
         base_cover: &base_cover                                                        
           min: 0                                                                                                                                                                    
           max: 100                                                                     
           step: 1                                                                      
           unit_of_measurement: '%'                                                     
         bad_eg_rollo:                                                                  
           <<: *base_cover                                                              
           name: Bad (EG)                                                               
         wohnzimmer_rollo:                                                              
           <<: *base_cover                                                              
           name: Wohnzimmer         

Here the target is to replace all the roller-shutter z-wave nodes I have within the frontend with a slider, thus input_number will be used, which is working fine with some python-glue using appdaemon.

This leads me to the following questions:

  • Why can’t I use jinja2 to have a far more generalized/abstract version, which might then even scale with(out) minimal effort? I had something like this in mind:
{% for item in states.cover %}                                                   
   {{ item.entity_id }}:                                                          
     min: 0                                                                       
     max: 100                                                                     
     step: 1                                                                      
     unit_of_measurement: '%'                                                     
     name: {{ item.friendly_name }}                                               
{% endfor %}
  • Is this somehow possible with other methods I’ve haven’t seen yet ?
  • Or am I just not aware of an underlying design/architecture decision ?
  • It’s likely not just me thinking generalization might start from n=2 ? Is there some blocking point behind that or whatever?

For my setup some major impact on additional effort is needed for an initial setup, not talking about introducing changes and adaptions. I would really like to know why not, or when(?) and finally maybe also: how a best practice for these things might look like.

Frankly speaking, I would even vote for having jinja2 available within the whole file. But very likely only because I do not see the full picture (yet) …

Thanks,
best wishes

1 Like