I am using HA for a long time and it seems, I got lost a bit, so perhaps someone can help me structuring my config in the right way.
First of all, I got all my configs defined in YAML and arranged it into seperate files and defined as follows in configuration.yaml:
# Components
switch: !include_dir_merge_list components/switches
sensor: !include_dir_merge_list components/sensors
climate: !include_dir_merge_list components/climate
notify: !include_dir_merge_list components/notify
mqtt: !include_dir_merge_named components/mqtt
Of course, I noticed, more and more configs moved to the UI, completely understandable for less technical users. I must say, I often have the feeling that this gives me less controll over de configuration. For example: If one of my ONVIF camera;s get’s a different IP address, I can’t just hange that, but have to completely remove and reinstall that camera, and probably adjust all of the scripting and UI stuff. However, this is just a little sidestep from this topic.
I do use a lot of templates. These where defined in seperate yaml files, for example, like this climate.yaml:
- platform: buienalarm
timeframe: 5
name: buienalarm
monitored_conditions:
- temperature
- precipitation
- precipitation_forecast_average
- precipitation_forecast_total
- next_rain_forecast
- platform: template
sensors:
weater_hot:
friendly_name: "Warme Dag"
value_template: >
{{ states("sensor.buienradar_temperature_1d") | int(0) > 22 }}
weather_hot_cooling:
friendly_name: "Zet het raam open om af te koelen"
value_template: >
{{
(states("sensor.smoke_detector_air_temperature_bedroom") | float(0) + 0.5 >
states("sensor.pir_motion_sensor_with_temperature_sensor_air_temperature_2") | float(0))
and states("sensor.smoke_detector_air_temperature_bedroom") | float(0) > 21
}}
- platform: statistics
name: humidity bathroom avg
entity_id: sensor.humidity_bathroom
state_characteristic: average_linear
max_age:
hours: 24
As you can see, I grouped different climate stuff togehter, like a buienalarm platform, template sensors and statistics.
However it seems there is a ‘new’ notation for templates and somehow I have the feeling this is the recommended way. Let’s take for example de configuration for the ‘weather_hot’ sensor from the example above. This could also be defined in the new way as:
template:
- unique_id: 490d20e7-29ae-49da-86e9-dc3f410cb300
name: 'warme_dag'
icon: mdi:weather-sunny
device_class: binary_sensor
state: >-
{{ states("sensor.buienradar_temperature_1d") | int(0) > 22 }}
It gives some extra options, like a unique_id, icon, device_class but the friendly_name seems to be gone. Notice that the platform statement seems to be gone too. If I want to store my templates as seperate files, I remove the template:
statement and move that to configuration.yaml like this: template: !include_dir_merge_list components/template
. However, I cannot combine it with other platform types anymore, leaving the buienalarm integration seperated from other climate stuff (untill the buienalarm integration gets converted to the UI).
It gets more complicated when I look at a switch template. As you can see in my configuration.yaml it points to a folder where I could define switches:
# Components
switch: !include_dir_merge_list components/switches
Then one of the switches could be defined like this:
- platform: template
switches:
alarm:
friendly_name: "Alarm ingeschakeld"
icon_template: mdi:alarm-light
value_template: "{{ states.variable.alarm.state }}"
turn_on:
service: variable.set_variable
data:
variable: 'alarm'
value: 'on'
turn_off:
service: variable.set_variable
data:
variable: 'alarm'
value: 'off'
In the ‘new’ way, it seems I cannot define the turn_on and turn_off anymore, so I have to maintain separate automatons for them.
Finally we have the growing set of helpers. switches can be defined as helpers. Like the ‘new notation’ I cannot add simple automations to the turn_on and turn_off events in helpers though. Templates cannot be defined as helpers, although more and more kinda predefined templates become available, like threshold sensor.
Of course this is great for less technical people, but somewhat limted. Unfortunately, it is not possible to switch from GUI to YAML mode like in lovelance.
So what are the best practices here:
- Do I need to convert all templates to the new template notations because the ‘old’ notation will become obsolete?
- Do I need to use the helpers as much as possible?
- How about packages?
- Is there another elegant way?
And:
a. I would love to see an option to switch edit the helper and device configs to yaml mode like in lovelance
b. I would love to see the option to define simple automatons like switch on and of in the helper
c. I would love to see the helpers completed with binary sensors