Experimentation
At some point in my career I had to pick up Java and since I was taking the time I figured it might as well be interesting while I did so.
Dark Ages
I used to have shell scripts sitting on my server that I would remote in and run or have an Android app automate. It worked for sure and got me interested in home automation, but otherwise there was nothing particularly great about it. Security, functionality…
Zephyr
My first home automation system was born, called Zephyr. It consisted mostly of a Java web service with a MySQL backend holding configuration/automation. I could hit my web service and get it to execute sequences of steps. It was fairly hard-coded at first just to get a sense for the setup, the frameworks I was using, etc. Once I got more comfortable it became more generic and adding functionality was just adding additional classes and using them in the configuration.
It worked for sure. At the time I really didn’t have many IoT devices, no real sensors or anything, just my Philips Hue lights. This is actually where I first dipped my toes into AWS and built my first Alexa Skill just for my own use, so I could control my lights and automations by voice. Zephyr is the west wind, which I’m sure at the time I thought was more interesting, and more importantly it was two syllables, uncommon, and still easy for the Echo mic to pick up!
SmartThings
The first product I bought a hub for and bought into the ecosystem. I still actually have an open/close sensor somewhere I think? It gave me more functionality in a sleeker package than I was willing to put the time into building back then.
As always, though, I immediately encountered limitations I didn’t like. The automations were fairly barebones and didn’t support more complex logic. I discovered I could write my own Groovy scripts and run those. They provided access to the sensor data and some actions that could be taken on them, and it was enough. It was definitely pain to write, but it worked! Debugging was all done through their web portal and it wasn’t full-featured.
At some point in beating my head against the wall on some code that just refused to work I discovered someone published a whole suite of automations I could hook into and use, so I did that. That worked very well and I’m ashamed I can’t remember what it was called. My entire system worked off of it for almost a year. And then…
Samsung purchased it and stripped away the functionality I was using, so that was that. I needed to go back to my own system. Back to /r/selfhosting. The only system you truly can control is your own.
Enlightenment
Novellus
Novellus is the name of my current system. The name started from experiments I was doing to add novelty or whimsy to my system. One of the things about building your own system is that it won’t ever surprise you. Very much a good thing when it comes to your fans turning on when you want them! But I wanted to expand and was attempting to add essentially semi-controlled random events based on time, weather, etc. That never really went anywhere because as it turned out I didn’t actually want to live in a randomized trial chamber.
The name stuck, though, three syllables but still quick to say and felt new.
My system is now entirely Python and exists as a set of Dockerized microservices that I can call from elsewhere. Mainly Home Assistant. I used FastAPI because it was the closest to other framework styles I have used in the past, was fast, had decorator-based routing I enjoyed, and it was just easy to work with.
PyScript in HomeAssistant gave me exactly what I wanted: the ability to write my own scripts and get sensor data. I still abhor Django templates. I use them where I have to, and I’m 100% sure that if I buckled down and used them more I could one-line away entire scripts that I have, but I like writing code, so be it. Now with PyScript I can write very sensor-dependent scripts right inside Home Assistant, and for more complex tasks call the Novellus microservice that applies.
One of the benefits of Home Assistant is running code-server so I can pop in and tweak the code on the fly. Something horrific to do in a real production application, but at home the worst I can break is my fan never turning on and I get too hot. One of of the issues with PyScript, though, is wrapping all web calls, for example, in it’s task.executor which makes it annoying to test code locally and debug. I have to maintain two bodies of the code if I’m testing locally. Enter AirFlow.
AirFlow is admittedly overkill for my use case, but that’s what life is about, isn’t it? I have several DAGs for tasks that used to be scheduled in Home Assistant, such as checking for weather alerts, checking for an update NWS briefing package for my area (think snow and hurricanes), checking for updated RSS feeds for things I like reading right away, etc. The benefit of AirFlow for my workflow is being able to test it locally and just deploy it. I have to jump through far less hoops.