Home Assistant Best Practices

Configuration
1

I have been thinking of starting this thread for awhile now. After a year using Home Assistant I have a few things that I wish I would have known along the way. I figure collectively this community can make a pretty good thread on this topic.

Lets try to keep this to ideas only and limit the discussion so it can be read through without scrolling through a hundred pages to find the good stuff. If you have a question or want to know how to implement something start a thread and ask on the forum. Googling always works to.

So to kick things off…

Place any item connected to Home Assistant on a static IP Address

Most of the time your hardware will maintain the same internal/local IP address. However, this is not guaranteed as your router is the controller of what addresses are handed out. Setting up fixed IPs allows your Home Assistant connected devices to always have the same address. One time this can become an issue is after a power outage when everything is requesting a new IP from the router again. This allows Home Assistant to always be able to find that device and can help during troubleshooting.

If you don’t know how to setup static IPs on your router good some combination of your router model and IP reservation / static IP and you will likely find a how to. It quick and easy and has saved me a lot of headaches.

Keep items that don’t need a internet connection from phoning home

This is more of a security item than anything. My edimax switches and yeelights both work over wifi and have an phone app for remote control. This requires that the item have a connection back to the server that provides the connection to your phone. Beyond initial setup and connection to Home Assistant these devices no longer need that connection to function.

Using your router/firewall block these devices from outside communication. This allows them to still function within your network but doesn’t allow them to connect to the internet. This lowers the attack profile of your network and keeps your data local. With the recent rise in attacks on home automation devices this is really something that needs to be taken seriously.

Most routers have this functionality. Some may present it as parental controls. Treat that wifi automation device like a kid that didn’t eat its broccoli and cut off its internet privileges. If you have a more advanced router you likely know how to do this already.

Keep device names generic - Customize the name through…Customize

When I first started I would name a bulb so the resulting entity ID was “light.front_porch” which works just fine. However, when I moved that bulb from the front porch light to another location it doesn’t really make since. If you rename the light in the basic config it has to be carried through everything.

I now use generic names so I get “light.yeelight1”, I then mark a 1 on the back of that bulb so I can identify it later. Now if I move that bulb I simply update it location in groups (copy/paste not typing a new name) and change the friendly name in customize. When working with automations changing all the 1s to 2s at the end of yeelight is also easy to do.

Backups, Backups, Backups. Did I mention backups?

Your SD card, hard drive or whatever you keep your configuration files on, is going to die. Keep a backup of your configuration files somewhere. The .yaml files are tiny and take up little space. Put them on a USB drive, upload to github, upload to google drive, move them to another drive. Search any storage device and you will find someone who has had one die and lost data. There are a number of Home Assistant method provided which I will link to below. Having a known ‘good’ version of your files is also helpful when you really screw up. I used to back up before I started working on my HA setup before I got more comfortable with troubleshooting. It was nice when I screwed something up and didn’t want to troubleshoot to just load my good config back in and restart Home Assistant.

2 Likes
2

Another couple I thought of.

Plan for Internet outages and Power outages

These things happen. How will your home automation system react when the power or internet goes out. What if you are out of town or unreachable after an outage and your automation system is going crazy. Plan for devices that don’t need an internet connection. You should be able to control everything locally with out the internet (and even WiFi really). Automations may not work but at least anyone else living with you can still live in the house without walking around in the dark or having major systems not functioning.

Use a good text editor

I know some people like using editors via ssh or a command prompt it just doesn’t work for me. Having copy paste functionality, color coding and linters built into a text editors makes things much easier for me.

https://notepad-plus-plus.org/ and https://atom.io/ are two I use. Both have a side bar with the current folder structure so you can launch files from within the program. I think both have yaml support ( I haven’t used notepad++ in a bit).

3

My suggestion would be to use packages where possible. It’s much easier to keep configs for specific functions all in one file rather than spread across multiple files.

Also. Entity_namespace

As your environment grows with wifi devices hubs etc it can get difficult to track what devices comes from where. By using entity name space all my wink devices start with wink. And following the suggestion above keep the names simple and customize.

Light.wink_cree1

4 Likes
4

First of all, I like the idea, and I see a great value in having a dedicated thread. I agree with @rabittn on the Packages. I am like most of the folks here, started with one or two smart bulbs or switches, and ended up with hundreds of smart devices in a very short time. My repository exploded all of a sudden, and I realized I need a “better” way to manage, maintain the devices and its corresponding configuration and code. In that context, I’d like to share that I rely heavily on “Packages”. I know it is a personal preference, and I am also aware that there are folks who haven’t really bought into the idea of it yet. Here is my 2 cents on the Packages for what it is worth.

A “Package” is a concept where you group all the logical items together into one file. The advantage of that is that you don’t have to modify 10 different files when adding or modifying device specific entries. It really makes sense to keep all the things together and also makes it easier for sharing the code and reusing the code (by copy and paste). If things are done right, things could be as simple as just dropping the package, make minor changes and you are good to go with all the customizations, group management, automations and sensors…etc in place.

Given the number of devices, I cannot think of any better way other than Packages as of today. Yes, the Packages are just another way on how you organize the code at the moment, but the concept is something that could eventually morph into “true” reusable components.

One of the common drawback that people talk about the Packages is that they are not very developer/user friendly when it comes to troubleshooting issues. But if you are smart enough to narrow down the problem using various techniques, this is no longer a problem. There is not a single problem that I had to pull my hair because of Packages :slight_smile:

The intent is not to spark arguments on which one is better, it is just my preference at this time, and you can find so many packages in my repository. Just something to think about.

5

I can totally agree on those two topics. And here is how I handled it. Instead of doing with my router (neither the Frontier Router nor the Apple Airport Extreme are really satisfying), I decided to set up a (another) Pi and installed DNSMASQ on this Pi.

With this configuration I have full control over my internal DHCP and DNS. With some basic subnetting, I also have full control over which device can access the internet or even communicate with other internal devices.

For example: My default “subnet” is only allowed to talk to devices within this subnet and access the internet. So whenever a new device connects to my (W)LAN, it is assigned to the default subnet and cannot access any other internal device. My “configured” devices are assigned to different subnets and those subnets control if there is only internal communication or external communication allowed.

It probably took half a day to design the config and install the Pi (with dnsmasq) but it’s totally worth it.

3 Likes
6

So this past weekend we had a bad winter storm, icy rain during the day and snow at night combined with high winds. Lots of power outages and before it actually went out it flickered on and off alot. The flickers were not enough to make the room go dark but enough to make electronics reset.

Luckily I have all my networking/ha stuff on a UPS. It caught every flicker and kept things running and powered everything through the ~3 hour power failure. My wife enjoyed being able to continuing watching netflix as the laptop stayed powered and everything else was backed up.

I have to imagine that my SD card would have been fried by all the power failures. Frequent loss of power is not friendly to Pi based systems. As a Pi auto boots when power is restored Im sure it would have lost power during boot up a number of times due to the frequency of the flickers.

You don’t need a UPS to power you through an outage but something to catch the flickers and given you time to shut things down really is worth the money. Given that a lot of people are on a Raspberry Pi, a small UPS will do wonders to prevent a huge headache.

1 Like