Skip to main content

DIY home automation, new generation

I've had my DIY home automation system for controlling outlets and reading sensor data running for about two years now. The system has been working fine and I haven't had any need to touch the code since I added the sensor reading to it, until a few months back.

Need for new functionality


Few months ago I got a new IoT toy for a lend from a friend until I'd get my own toys, a ruuvitag sensor beacon. Ever since I found the ruuvitag for the first time from kickstarter I had the idea of getting a bunch of ruuvitags and adding their weather station sensor readings as part of my home automation system.

The original home automation backend included only tellstick compatible devices and was written in Python, and in my mind it was kind of a hack. The ruuvitag beacons communicate via BLE i.e. Bluetooth Low Energy and that meant that I needed to add functionality to read the beacon data via bluetooth.

I found a ruuvitag Python library and initially thought that I'd just use that and extend the existing backend. As I started looking more into the ruuvitag and BLE beacon possibilities I came accross Node.js implementation that would be able to read the beacon data. As I started looking deeper and extended my search within Node.js libraries I also found a telldus library.

I've done some work with Node.js and even though it's not my first go-to choise it seemed that with it I could simplify my existing backend a lot and add the new functionality quite easily.

Backend rewrite


I'm not going to get in details of the backend code as it's basically a REST API that reads sensor data and controls outlets just like the original implementation but here's a link to the backend code and just a few notes about the backend.

The Node.js telldus library uses the native telldus library and is compiled with node-gyp so it needs to compiled on same architecture where the backend is going to be running. The compile time on my original Raspberry Pi was quite long.

The beacon library uses bluetooth library and it has the same restriction as the telldus library.

The readme file contains more information and instructions in case you're interested.

Refresing the UI


The UI of the original home automation system was a vanilla JavaScript experiment and I thought that I should also update that as I already rewrote the backend. This time I chose Vue.js as it's something on the rise and I haven't used it before. Just like with the backend I'm not getting in the details of the code but here's a link to the code and a screenshot.



Wait, what, no tests!


I made a conscious decision not to write any unit or integration tests for this project as without all the hardware (tellstick duo, controllable outlets, bluetooth, ruuvitag) I'd have to mock them and I'm not a big fan of mocks.

Sure i could have written a unit test for parsing the sensor data from the beacon URL but it just didn't seem worth the time and effort as I have manually tested the implementation for hundreds of times while developing.

Integration testing has also been manual while developing and continues to be manual as we use this system daily so I didn't see the need for automating that.

Final thoughts


The rewritten backend of the home automation system seems to be working as reliably as the first generation and I'm really pleased how much cleaner code I got with Node.js.

Vue.js seems to be a viable option at least for small projects like this one.

I already have some ideas how to do some actual automation and analytics based on the sensor data but that's another story.

P.S. I wish my ruuvitags had a light sensor as that would extend the automation possibilities even more.
Labels:

Popular posts from this blog

Simple code: Naming things

There are two hard things in programming and naming is one them. If you don't believe me ask Martin Fowler https://www.martinfowler.com/bliki/TwoHardThings.html . In this post I'll be covering some general conventions for naming things to improve readability and understandabilty of the code. There are lots of things that need a name in programming. Starting from higher abstractions to lower we need to name a project, API or library, we probably need to name the source code repository, when we get to the code we need to name our modules or packages, we give names to classes, objects, interfaces and in those we name our functions or methods and within those we name our variables. Overall a lot of things to name. TLDR; Basic rule There's a single basic convention to follow to achiveve better, more descriptive naming of things. Give it a meaningful name i.e. don't use shorthands like gen or single letter variables like a, x, z instead tell what it represents, what it does...
Read more

Simple code: Version control commits

Currently the most popular version control system is git and I'll be writing this based on git and it's functionalities and capabilities. Git is often seen as a way to enable distributed programming i.e. multiple programmers can work on the same code repository quite easily without disturbing each others work (much). In addition to that just like other VCS's it's also a log of work but to my experience that part is often unfortunately neglected. What I will be focusing this time is the log part because I think it deserves more attention. Why to create a meaningful log? The git log should consist from small meaningful changesets where each commit addresses a single problem. By dividing the log to small commits it enables resilient way of working. Being resilient enables simple and fast procedures to rollbacks, reviews, tags, branching etc. Lets say that a developer is implementing a REST API. The API needs a web layer that receives the HTTP requests, it probably has some...
Read more

Simple code: Simplicity

Simplest solutions are usually the best solutions. We as software developers work with hard problems and solve a lot of small problems every day. Solving a hard problem itself is a hard job. Though in my opinion it's not enough to solve a hard problem in any possible way but a hard problem should be solved with a simple solution. When a developer comes up with a simple solution to a hard problem then they can declare the problem solved. First a disclaimer. Coming up with a simple solution to a hard problems is itself a very hard problem and takes a lot of time, effort and practice. I've seen my share of "clever" solutions for hard problems and the problem with those is that usually the solution itself is so hard to understand that depending on the size of the problem it may take a developer from hours to days or even weeks to understand how that "clever" solution works. It's a rare occasion when a developer has come up with a simple solution to a hard pr...
Read more