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.
-
Hi @Martijn-Hemeryck,
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
-
@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.
-
Hi @Martijn-Hemeryck,
I checked your other posts and have some notes on the Software part:The Evok is planned (well, maybe "wished" is a better word:)) to be rewritten to Python 3 and to a multithreaded application. Along with that, major changes to the API will happen. We will abandon some of the less used APIs (RPC and SOAP probably) and definitely add native MQTT support since it is a driving force in the industry.
The missed state changes of the DI can be detected by checking the state of the DI counter. The counter is implemented in the HW and can count as fast as 10kHz signals.
And a bit of explanation of the low level communication:
- The HW boards are connected over SPI
- The protocol on the SPI level is modified ModbusRTU
- The Unipi kernel module (part of the unipi-kernel-modules package) exposes this communication channe as /dev/unipispi device
- The Unipi ModbusTCP server (part of the unipi-modbus-tools) exposes this as a ModbusTCP server running on TCP/502
- The rest is correct. Evok polls the ModbusTCP server as fast as it can. And creates a "system image" of the HW state.
Best regards,
Martin -
And in the firmware of the IOs we plan to introduce a "latching" state of the DIs. Those will be registers and coils which will hold the leading edge of the DIs until they are read from the software. That will prevent the losing of the edge altogether.
M.
-
Thanks a lot for the feedback!
Hi @Martijn-Hemeryck,
I checked your other posts and have some notes on the Software part:I think it's really nice you took this effort, tbh :)
The Evok is planned (well, maybe "wished" is a better word:)) to be rewritten to Python 3 and to a multithreaded application. Along with that, major changes to the API will happen. We will abandon some of the less used APIs (RPC and SOAP probably) and definitely add native MQTT support since it is a driving force in the industry.
How far along is this idea? Would you also be taking PRs? I mainly develop in python3 for my job and have some experience with asyncio (see e.g. https://github.com/mhemeryck/covers), so I might be interested to have a look at that.
The missed state changes of the DI can be detected by checking the state of the DI counter. The counter is implemented in the HW and can count as fast as 10kHz signals.
I wasn't aware of this polling speed!
And a bit of explanation of the low level communication:
- The HW boards are connected over SPI
- The protocol on the SPI level is modified ModbusRTU
- The Unipi kernel module (part of the unipi-kernel-modules package) exposes this communication channe as /dev/unipispi device
- The Unipi ModbusTCP server (part of the unipi-modbus-tools) exposes this as a ModbusTCP server running on TCP/502
- The rest is correct. Evok polls the ModbusTCP server as fast as it can. And creates a "system image" of the HW state.
I obviously did get some of details wrong, so thanks for pointing this out!
Would you mind if I did include your comments in an edit on this blog post?
I really appreciate this kind of feedback; I never really did ask for your permission to publish on your product in the first place, so I am glad to see your reaction like this.
