Up to now, everything has been pretty much getting COTS (Commercial of the Shelf) components and installing them. There hasn’t been any “automation” in my home automation project.Therefore, I’ve been digging around on the internet to find which solution is most adequate for me.
Main Server
What I am NOT looking for? Easy, closed solutions are not suitable for me, as most of them will only work with devices from the same brand.
I want something customizable, open to any brand of home automation, with a wide community, and as cheap as possible! The two main projects that made sense were OpenHab and HomeAssistant. Both of which can run on a Raspberry Pi. What really tipped the scale was that HomeAssistant is written in Python which I know some of . OpenHab however used a mix of languages I really don’t have a clue about (Apache?! I thought that was a native indian-american tribe! or an attack helicopter!).
Home assistant it was! I chose the Hass.io flavour as it really comes in a closed package
Device connection
Ok, so we now have a set of blinds and sun shades that are controlled by two remotes, and a headless server on a wired network that could run more automation scripts than I could imagine.
My idea for system setup is the following, lets assume i wanted to control the blinds over the internet the command would follow the following path
Internet <-> router <-> raspberry pi <-> unknown device <-> RF signal <-> blinds
Notice something wrong in the previous schematic? I don’t have a way of sending an RF signal from Home assistant! It’s worse than that! I do not know nor the encoding of my remotes, nor the frequency they operate in. I will have to write a post about it!
How about the communication channel between the main server and the “unknown device”. Fortunately, I do have that answer. MQTT is a lightweight communication protocol based on a publish-subscribe pattern, wich really fits well with home automation projects. Link to wikipedia. However, an executive decision must be now made.
Using MQTT requires a message broker to handle the client subscriptions and message delivery. This task can be easily handled by our Pi, however, there are many web services that provide this service for a low cost or even free.
MQTT broker Pro’s:
| Pros | Cons |
| Unlikely it will be down | Privacy of messages; the service could suffer a hack, exposing all my messages |
| Some are free (cloudMqtt is free up to 10 clients) | If my ISP goes down I lose connection between servers and blinds |
| Server is kept updated | Terms of service my change unexpectedly |
Pros & cons of a local MQTT broker
| Pros | Cons |
| The broker doesn’t rely on an internet connection | Server troubleshooting relies on me |
| No client limit | If I don’t know my ip address I cannot access it remotely |
| I completely manage the broker |
Fortunately my ISP provides FTTH service therefore internet cutouts are really not a thing. Furthermore I replaced my ISP’s default AP with an ASUS router therefore I can confidently say, I have a reliable internet connection.
As for now, I will only have a maximum of three devices connected to the broker, the home server, “unknown device”, and the computer/phone I will be testing with. I have chosen CloudMQTT as the service that will host my broker, however, if I ever want to change is really an easy task. As MQTT servers don’t really store messages it’s just a matter of setting up the publish – subscribe clients to the new server address.