20 things I wished I knew when I started with Home Assistant

Installation
, ,
8

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
10

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
12

And sometimes it’s an illusion. Four automations are crammed into one, but automations.yaml is acutally longer because of all the conditions etc. :grinning_face_with_smiling_eyes:

2 Likes
13

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
14

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
15

Great write-up with a lot of useful information! :slight_smile: :+1:

I just wanted to add another possibility on your #14. You should really think about using packages. :smiley:

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:

ha_230529_packages_01
ha_230529_packages_01339×920 17.8 KB

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
16

I would say that this is a nice write up and will receive plenty of responses, but…

  1. 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
17

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
18

I didn’t know about them indeed, will pay a look definitely :slight_smile:

19

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
20

You really should. :smiley: :rofl: But pe prepared, it is like doing it all over again. :rofl: If you want to add something about packages to your really great guide, let me know, I can write up some lines to add. :wink:

21

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.

22

sure, that’d be helpful I think

23

I realised very late the power of calling scripts from automation (and, since 2023.4, macros).

  1. 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

  1. create scene
  2. unmute speaker
  3. set volume
  4. say something (where the parameters are used)
  5. wait for TTS to end (speaker back to idle)
  6. restore scene

This script is called from multiple automations.

2 Likes
24

What is the add on “check home assistant config” ?

1 Like
25

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.

26

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
27

+1 for Packages. I use them for everything.

eg:
image

Where for example, the front_house_lights.yaml file has everything for that ‘device’ all in one place.

image
image299×642 20.2 KB

2 Likes
28

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?

29

Yes. It’s why there have been so many requests to have the UI improved so that things can be grouped in the same way we do in Packages. If we could group all the relevant input_booleans, scripts, automations etc. where the UI shows the related bits in one place I would migrate to full UI, but until then I’ll stick with neatly organised YAML.

2 Likes