You’re absolutely correct sir. Great Thinking.
I’m just unsure of one point: I need that automation to run at 00 and 30, not anywhere based on latest HA reboot spaced by 30 mins. I was wondering if the /30 time pattern takes as a starting point the exact hour or the moment where HA started? Likewise, hours: “*/2” would trigger every 30 mins or exactly at 30 & 00 in your experience?
Very nice, thanks for taking the time!
I don’t follow all that advice myself, but there’s a lot of good info there. Just figure out which ones apply to your own use case and environment.
I’m glad the issue of “minifying” came up again. That one really hit home. I think we (coders and tinkerers, collectively) love to seek the most “compact” solution. If we can cram all the logic on one line, we will. I’m learning to embrace white space and wordiness. Makes it so much easier to figure out when you come back to it later. Not to mention debugging.
2 Likes
I’ll say I’m extremely grateful for this. I’m a recent Hubitat convert and am finding there’s different thought processes to doing similar things. Especially when it comes to automations.
Finding something to manage cloud backups has been on my to-do list, so definitely appreciate that tip.
1 Like
And sometimes it’s an illusion. Four automations are crammed into one, but automations.yaml is acutally longer because of all the conditions etc. 
2 Likes
Some asked for the Apex chart code on the dashboard:
type: custom:apexcharts-card
chart_type: donut
update_interval: 10min
apex_config:
dataLabels:
enabled: true
dropShadow:
enabled: true
formatter: |
EVAL:function(value) {
return value.toFixed(0) + " %";
}
plotOptions:
pie:
customScale: 0.9
donut:
size: 35%
background: transparent
labels:
show: true
total:
show: true
label: kWh
formatter: |
EVAL:function(w) {
return Math.round(w.globals.seriesTotals.reduce((a, b) =>
{ return (a + b) } , 0)) }
header:
show: false
title: Daily energy used
show_states: false
colorize_states: true
series:
- entity: sensor.daily_ev_charge_energy
transform: return x/1000;
name: EV cars
color: green
unit: kWh
show:
datalabels: percent
legend_value: false
- entity: sensor.daily_baloon_energy
transform: return x/1000;
name: Baloon
color: rgb(135, 221, 66)
unit: kWh
show:
datalabels: percent
legend_value: false
- entity: sensor.daily_pac_consumption
name: PAC1
color: rgb(245, 221, 66)
unit: kWh
show:
datalabels: percent
legend_value: false
- entity: sensor.daily_pac2_consumption
name: PAC2
color: orange
unit: kWh
show:
datalabels: percent
legend_value: false
- entity: sensor.daily_it_bay
name: IT bay
color: rgb(255, 105, 0)
unit: kWh
show:
datalabels: percent
legend_value: false
- entity: sensor.daily_heater_energy
name: Heaters
color: rgb(255, 0, 90)
unit: kWh
show:
datalabels: percent
legend_value: false
- entity: sensor.daily_office_consumption
name: Office
color: rgb(169, 60, 244)
unit: kWh
show:
datalabels: percent
legend_value: false
- entity: sensor.daily_pool_consumption
transform: return x/1000;
name: Pool
color: rgb(70, 10, 186)
unit: kWh
show:
datalabels: percent
legend_value: false
- entity: sensor.energy_various
name: Other
color: gray
unit: kWh
show:
datalabels: percent
legend_value: false
And as well for the Tesla style graph:
- type: custom:tesla-style-solar-power-card
house_icon: mdi:home
battery_icon: mdi:battery
generation_icon: mdi:solar-power-variant
grid_icon: mdi:transmission-tower
show_w_not_kw: 1
grid_to_house_entity: sensor.teleinfo_power
grid_extra_entity: sensor.teleinfo_periode_tarifaire
house_extra_entity: sensor.daily_energy_cost_euro
generation_extra_entity: sensor.solar_spot_percentage_tesla_graph
generation_to_house_entity: sensor.solar_spot_production_watts_filtered
appliance1_consumption_entity: sensor.wallbox_charger_wh
battery_extra_entity: sensor.imeon_battery_charge
generation_to_battery_entity: sensor.imeon_power_to_battery
1 Like
For “once a day” values, you can avoid the repeated time patterns completely, by triggering triggering when HASS has been restarted on event_template_reloaded:
# templates.yaml
# no "template:" here as in configuration.yaml
- trigger:
- event: start
platform: homeassistant
- platform: event
event_type: event_template_reloaded
- platform: time_pattern
# only needs to change once a day
hours: 05
minutes: 05
unique_id: 1234567890
sensor:
- name: Date in Text
#description: "Date in text format suitable for TTS"
state: >
{% set dayofweek = ['Monday','Tuesday','Wednesday','Thursday','Friday','Saturday','Sunday'][now().weekday()] %}
{% set day = ['1st','2nd','3rd','4th','5th','6th','7th','8th','9th','10th','11th','12th','13th','14th','15th','16th','17th','18th','19th','20th','21th','22th','23th','24th','25th','26th','27th','28th','29th','30th','31th' ][ now().day-1] %}
{% set month = ['January','February','March','April','May','June','July','August','September','October','November','December'][now().month-1] %}
{{ dayofweek +', '+ day + ' ' + month + ' '+ now().strftime('%Y') }}
icon: "mdi:CalendarRange"
3 Likes
Great write-up with a lot of useful information! 
I just wanted to add another possibility on your #14. You should really think about using packages. 
What you’re doing with directories and organization can be done much easier with packages. What you’re doing here, is dividing everything into files depending on the type, whereas packages are a more logical approach to divide things. Like into rooms or areas, or even with some specific things, like window covers.
The idea behind packages is the combination of all different things like sensors, groups, automations, scripts or whatever into one logical structured file. Let me give you an example: I’m using a few modes for our home, like “bed_mode” (when we are going to bed, turning this mode on turns off the lights, sets the blinds to specific positions, arm the alarm and so on) or “work_mode” (for the work-from-home office set the volume of the private telephone to 0, turn off the door bell while having a Zoom or Teams meeting…).
To make use of these modes, one needs a few helpers and automations:
As you can see, everything is in one shiny, nice place, ready to be maintained. In the end, there might be some more files with this way, but it is easier than working with a whole different files.
And one thing I like most about packages, you don’t need to setup the different integrations. Just set a sensor in a package file, and the sensor integration is called automatically.
If something new comes up in term of devices, you just need to add either a new file or put it in an already there package file. For example, I’m currently trying to build a new dashboard, and as it turns out, I needed an input_select to change the views. So it is just the creation of one file, “frontend_package.yml”, and in there are all the needed input helpers.
To be fair, packages are not the one-thing-fits-all approach, but they are worth mentioning, as they are a very underestimated and underrated component in HA.
5 Likes
I would say that this is a nice write up and will receive plenty of responses, but…
- Look at supporting the future development of HA and use Nabu Casa, especially for the simplicity for new and veteran users.
I myself use it… why? Because it’s one important thing I don’t have to mess with
3 Likes
From the Time Pattern Trigger’s documentation:
With the time pattern trigger, you can match if the hour, minute or second of the current time matches a specific value. You can prefix the value with a / to match whenever the value is divisible by that number.
In other words, when the value is evenly divisible by a number from 0 to 59. For /30 that means on the hour and half-hour.
0/30
30/30
2 Likes
I didn’t know about them indeed, will pay a look definitely
I learned a whole lot from this so thank you for writing it all up.
My one addition to this from experience is to diversity your container platform. You have a whole lot of services running within HA and it sounds like it’s working well, but what happens if HA crashes? Now your nginx, crowdsec and potentially other services are down. If you are home no biggie, but outside the home that might be a problem.
I’ve seen a lot of people rely on HA to host their VPN or reverse proxy (I did this to start) and it can cause all sorts of headaches.
Moving a handful of those services over to a simple docker install on another Pi or Ubuntu (or my fave proxmox) on a mini pc can grant a lot more flexibility, fault tolerance and room to grow both home assistant and other services.
1 Like
You really should. 
But pe prepared, it is like doing it all over again. If you want to add something about packages to your really great guide, let me know, I can write up some lines to add. 
Then it may have been poorly designed/consolidated.
Consolidating multiple related automations into one ought to result in something that’s more streamlined, concise, efficient, and easier to read and debug (pick any three). If the result is the opposite then it was either poorly done or there was no good reason for consolidation.
sure, that’d be helpful I think
I realised very late the power of calling scripts from automation (and, since 2023.4, macros).
-
Code refactoring
Use macros for repetitve templates (introduced in 2023.4.x)
And
For repetitive set of action, like TTS on a speaker, use a script with parameters and call from the automation (synchronous or asynchronous)
I have a script to do TTS
- create scene
- unmute speaker
- set volume
- say something (where the parameters are used)
- wait for TTS to end (speaker back to idle)
- restore scene
This script is called from multiple automations.
2 Likes
What is the add on “check home assistant config” ?
1 Like
I think it’s default now, it’s the button that allows you in the dev tool tab to check the configuration before reloading. It tells you if there are syntax problems.
Not quite. The check config add-on checks against the breaking changes of the next HA version.
So after HA 2023.5 comes out you can scan your config (still on 2023.5.x) and the add-on should tell you if there are issues you need to fix to remain compatible
1 Like
+1 for Packages. I use them for everything.
eg:
Where for example, the front_house_lights.yaml file has everything for that ‘device’ all in one place.
2 Likes
Some people contributing to this thread are promoting the use of packages. I can see the advantages in terms of organisation but I have a question:
An I right in thinking that having automations in packages prevents the use of the automation editor UI?