Home Assistant

Hardware options

Home Assistant software has very minimal hardware requirements, which makes it ideally suitable for a power-starved environment like an RV. There are various options to consider:

  • Raspberry Pi 3 or 4: This is the most popular option. It’s cheap, has low power requirements and available in a variety of RAM and CPU configurations. It uses an SD card for storage which is both a benefit (cheap, high capacity, easy to swap) and a liability (can get corrupted on power loss).
  • Odroid N2+: This is the hardware used by Home Assistant Blue, an all-in-one bundle that combines hardware and software and makes it super easy to configure and manage. The bundle is no longer available, but the hardware is. It just takes a bit more effort to install Home Assistant on this hardware. The big advantage is that Odroid N2+ has a built-in eMMC module that allows you to avoid using SD cards.
  • Raspberry CM4: This is the newest child on the block and the basis for Home Assistant’s new bundle ‘Yellow‘. It has an M.2 slot supporting terabytes of extra storage and is future proof with support for Thread and Matter.

Yellow was not available when we made our decision, so we went with the Odroid N2+, specifically to avoid having to use SD cards. As mentioned above, SD cards get easily corrupted on loss of power. And being installed in an RV, loss of power is a rather common occurence.

For our next iteration, we would probably go with Yellow, not only because of the expanded SSD options, but also because the device can be PoE powered. Our main ethernet switch is PoE enabled and already powers our Unifi WiFi hotspot.

Software options

There are various ways to install Home Assistant on your preferred hardware. We go through the options:

  • Home Assistant OS: The easiest option is to install HassOS. This bundles the installation of the operating system with the Home Assistant software and provides a single interface to manage the entire system.
  • Home Assistant Container: In this case, you have to install your preferred OS as well as the Docker container software. The HA software will run in a dedicated Docker container. This will give you far more control over the entire system and also isolates the HA software from the rest of the system. It gives you the most flexibility but comes at a cost of have to manage all the parts separately.
  • Home Assistant Core: This will install the core Home Assistant software in a Python virtual environment. It is the most manual process and does not include the Supervisor. The advantage is that you have full control over the install and upgrade process and avoid issues when the Supervisor occasionally breaks things (it happens!). The disadvantage is that you don’t have access to Add-Ons and Snapshots (HA backup software).

Read more about the various options in this Installation Guide.

After experimenting with all options above, we decided to go with the easiest version …. the Home Assistant OS. We didn’t feel like we needed any of the advanced control features and were happy for Home Assistant to do most of the work for us.

Installation

Installing Home Assistant OS on the Odroid N2+ is pretty straightforward and explained well here. Just follow the step-by-step instructions and you’ll be up and running in no time.

We installed several additional software packages to fit our needs. An overview:

1. Add-ons

Add-ons extend the Home Assistant functionality and can be installed directly from the HA interface. We use following add-ons:

  • Mosquitto Broker: All communication between the sensors and HA happens over MQTT. So, this is our most critical add-on. Without MQTT, there is not communication between sensors. Learn more.
  • Terminal & SSH: This allows you to remotely access HA’s command line interface. We find this far more convenient to update configuration files, instead of using the UI.
  • HA Google Drive Backup: We use this add-on to upload a weekly snapshot of our HA installation to our Google Drive account. These snapshots are close to 1GB in size, so be careful with how frequently you upload these, especially over a metered cellular connection.
2. Integrations

Integrations with 3rd party devices are often handled through the Home Assistant Community Store (HACS). Installing HACS for the first time is a bit of a pain, but once installed, updates are easy to manage.

  • Sonoff LAN: This is our only HACS integration. It enables communication between Sonoff devices and HA. We use Sonoff IW100 smart wall socket switches around the cabin for our 110V outlets. These are the only devices that run proprietary Sonoff software and haven’t been flashed with ESPhome (yet).
3. Lovelace Plugins

Plugins allow you to extend the default Lovelace UI with additional custom functionality. Plugins are also installed through HACS. We use a whole range of plugins to make our dashboard visually more interesting and compelling.

  • Flexible Horseshoe Card: used to display battery status
  • Bar Card: used to display tank levels
  • Button-Card: used to display Home/Away and other automations.
  • Multiple Entity Row: used to display multiple data points on a single line (e.g. pressure, temp, and alarm status for the tires)
  • Simple Thermstat: self explanatory
  • card-mod: helps us customize the appearance by applying any CSS style to any card (e.g. tire values that are out of bounds show up in red)
  • auto entities. allows you to automatically populate a card with entities that match certain criteria (e.g. show top 5 energy consuming devices, ranked by declining wattage)
  • Config Template Card. enables you to use any JS in your UI (e.g. change the tire icon to a different icon when there is an alarm)

Configuration

One of the beauties of HA is that everything is configurable. One of the difficulties of HA is … you guessed it … that everything is configurable. You can spend countless hours/days/months configuring. There is always one more thing to get right.

Entire books are written on configuration. We’ll just limit ourselves to the most important elements of the configuration; the ones we spent most time on. Some of the configuration items are described in more detail on other pages.

First, one important note, some of the configuration can be done through the UI. However, we found this way too limiting. Instead we decided early on to learn YAML and configure everything through the command line interface and our favorite editor. I’m old school and use ‘vi’, but you do you.

1. Configuration.yaml

This is where you configure most of the items under the ‘settings’ menu of Home Assistant. It’s where you set up the integrations to be loaded along with their configurations. It’s also the place where you can find all automations, custom entities and templates, services, scenes, etc. This file can become unwieldy very quickly. To prevent this from happening, I split up the file in multiple files, and the configuration.yaml file just becomes a pointer, or aggregator of all the sub files, each one dedicated to a specific goal (e.g. automation.yaml or victron_sensors.yaml)

2. Custom (MQTT) entities

As mentioned, we use MQTT for (nearly) all communication between sensors and Home Assistant. Sensors that run on ESPhome don’t require any Home Assistant configuration. Sensors that don’t, need to be set up manually in Home Assistant so that HA can decode the MQTT message properly and map the data to the proper entities. In our configuration, this is mainly the case for Victron messages. We also use custom entities to track the health of our Odroid server (CPU and disk usage, temperature, memory). Learn more.

3. Automations

Most of our automations currently involve the Victron system. Examples are:

  • Request updated values from Victron every 30 seconds
  • Update inverter max. input amps based on UI change
  • Update inverter mode based on UI change
  • Update HA home location when new GPS coordinates are received from the Peplink router.
4. Lovelace Configuration

This is the area where you can spend (waste?) most time. The options are endless, especially after adding plugins that allow for unrestricted CSS styling or use of Javascript in the Lovelace YAML files. As with the main configuration.yaml, I split up the Lovelace UI file into multiple files, each one covering a specific ‘tab’ in the dashboard.

Leave a Reply

Your email address will not be published. Required fields are marked *