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.

Comments

  1. This comment has been removed by a blog administrator.

    ReplyDelete

Post a Comment

Popular posts from this blog

Simple code: Immutability

Immutability is a special thing that in my mind deserves a short explanation and praise. If you're familiar with functional programming you surely recognice the concept of immutability because it's a key ingredient of the paradigm. In the world of object oriented programming it's not as used and as easy to use approach but there are ways to incorporate immutability to parts of the code and I strongly suggest you to do so. Quick intro to immutablity The basic idea of immutability is unchangeable data.  Lets take a example. We have a need to modify a object's property but because the object is immutable we can't just change value but instead we make a copy of the object and while making the copy we provide the new value for the copy. In code it looks something like this. val pencil = Product(name = "Pencil", category = "Office supply") val blackMarker = pencil.copy(name = "Black marker") The same idea can be applied in functions and metho

Simple code: Readability

Readability, understandability, two key incredients of great code. Easier said than done, right? What one person finds easy to read and understand another one finds incomprehensible. This is especially true when programmers have different levels of understanding on various subjects e.g. object oriented vs. functional or Node.js vs. Java. Even though there are obvious differences between paradigms and programming ecosystems there are some common conventions and ways to lower the barrier. Different approaches It's natural that in programming things happen sequentally e.g. you can have a list of objects and you need to do various things to the list like filter some values out and count a sum of the remaining objects based on some property. With the given list const stories = [   {name: "authentication", points: 43},   {name: "profile page", points: 11},   {name: "shopping cart", points: 24},   {name: "shopping history", points: 15},   {name: &qu

Simple code: Unit tests

Unit tests are the developers number one safety net. Let that sink in. This is the number one reason for writing unit tests. Unit tests are written by developers for developers to ensure that the code works as expected and handles happy and sad paths correctly. With enough unit test coverage the tests enable a safe environment for refactoring and rewriting code. Unit test scope Unit test should test a single thing, a method or function call and it should test only one use case within. In other words a unit test should test a function with a single input. This is a important guideline to understand. When a unit test tests a function with single input it makes the test isolated, repeatable and predictable. Example of good tests: @Test fun findsAddress() {   val address = findAddress("Stevens street 35", "Southport", "Australia")   assertThat(address).isNotNull() } @Test fun doesNotFindAddress() {   val address = findAddress("Stevens street 697", &q