home assistant DIY setup blog
While building our new house, I did spend a lot of time on designing and later building a home automation system, with home assistant + MQTT at its core.
Today, I did post the first of a series of blog posts on this topic: https://blog.mhemeryck.com/2021-06-15/home_automation_why
The first post is mostly about explaining the rationale behind it as well as the series of posts I have actually planned over the course of the following weeks.
At this stage, it does not mention any unipi product yet, but as the series unfolds, it should be clear that my unipi neuron units are really essential in the overall setup :)
Hope you might enjoy it!
Update: here's the second post in the series: https://blog.mhemeryck.com/2021-06-22/home_automation_architecture
This post outlines the architecture and the framework I did use while modelling the overall setup.
thanks for these posts, I enjoy going through them, it's a well written documentation of the process.
You mention the single-point-of-failure problem which this kind of setup poses. Have you considered / thought about some sort of redundancy of the system? Maybe not in a way of direct redundancy, but something like hot backup maybe...?
@Martin-Kudláček thanks for the feedback.
For the redundancy: I think there's multiple ways in which to add some safeties, some I have already implemented:
- 24VDC UPS: pretty much everything that I have on the 24VDC side is secured by a battery + UPS. In the event of power failure, my unipi units will not directly lose power. The UPS has a dry contact to indicate its loss of power, so I'm thinking of also adding a controlled shutdown in this event.
- additionally, all network hardware I have is also protected with batteries.
- home assistant container orchestrator: I run the home assistant instance using https://k3s.io/ which is a low-memory footprint version of kubernetes (the de-facto industry standard for running containerized workloads). The advantage is that it should auto-recover the home assistant instance in case of failure. I particularly like the feature that in case of updates, it will try to run the new version alongside the old one and only if the new one is confirmed up and running, it will kill of the old version. Another feature is that you can run it in a high-availability (HA) mode, i.e. over multiple nodes (e.g. raspberry pis) such that if one nodes fails, it automatically distributes the load to another node. For quick provisioning: check https://k3sup.dev/
- home assistant config: the entire config is kubernetes yaml manifest files, so in case of failure, I could easily redeploy the entire thing.
- MQTT broker in HA mode: there's apparently another MQTT broker out there that you can in HA mode, see https://www.emqx.io/blog/emqx-mqtt-broker-k8s-cluster
- home assistant backups: currently, all logical links between MQTT topics is done using the home assistant automations, but at some point I did think to add another service in the network that could do something similar. My shades control actually works in such a way, that it handles some more involved logic for translating MQTT events between the home assistant instance and the unipi unit: https://github.com/mhemeryck/covers (probably deserves its own blog post to really explain :))
- on the network level: most of the setup relies on a wired network setup, but I also did consider to maybe have a wireless failover (not implemented yet though).
Maybe this list is also a great topic for a future post :)
Update: to keep the habit of posting new posts: here's the post on wiring: https://blog.mhemeryck.com/2021-06-29/home_automation_wiring
Another update on the mains voltage wiring: https://blog.mhemeryck.com/2021-07-06/home_automation_schematics
Keeping it with my weekly tradition: https://blog.mhemeryck.com/2021-07-13/home_automation_cabinet
This one might be a bit more interesting in that it gives some more details on the actual wiring I did.