I had an older Neato Botvac that recently died. The brushless motor that powers the LIDAR it uses for navigation finally wore out. I was really happy with the device and used it regularly for several years. It was time for an upgrade anyway.

I’ve been happily using the Yahoo Weather API for quite a while now. Yahoo has been pretty unreliable for long-term use. I suppose this should be a lesson to those that depend on third party APIs anywhere. Several years ago, Yahoo shut down their Stocks API - which I had integrated into SwitchBoard for quite a while. They’ve now shut down the last API of theirs that I was actively using: their Weather API.

After my Foscam camera gave up, I was on the lookout for a new camera I could use with SwitchBoard. It needed to be a pan / tilt camera, so I could make sure it was staring at a wall when not armed (because I’m paranoid). It needed to support MJPEG or some other means of rendering live video to a wide set of browsers without a plugin. And, finally, it needed to not be crappy. Something built by a reputable manufacturer that was easily found. I landed on the D-Link DCS-5222LB. It can be had for about $85 right now on Amazon and other models that may or may not work can be found for less.

The other week, the Foscam I’d been using for a number of years blew up. It had an audible “pop” as something inside decided to give up. I went on the hunt for a camera I could replace it with and found it to be pretty difficult. Most are now using h.264 since it has much better quality than mjpeg - but it comes at the cost of compatibility. For web stuff, mjpeg is pretty tough to beat, as long as you don’t care too too much about the quality - so I figured that was what I was aiming for. Foscam - and their new company Amcrest - both have switched over entirely to h.264. So that’s not a great option for this use-case.

I’ve been making a lot of use from the machine learning aspects of SwitchBoard lately. It’s been pretty handy (and sometimes borderline spooky) when a light turns on the second you think you want it on, without any explicit interactions at all. While the good outweigh the bad actions by a fair margin, there have been a few notable “oh, that’s not good” moments. Specifically when someone is asleep and a light turns on because Sunday is a weekend, I stay up late on weekends, and it’s 11:30pm…a work night. Not good.

I haven’t posted anything for a while, so thought I’d give a quick update. A lot of the latest changes are pretty limited to just bug fixes and updating of dependencies. Much of my time is now spent trying to get the machine learning parameters tweaked so they are the most effective and minimizing inconvenient actions. So far, I’ve been pretty happy with how things are working - but trying to teach new behaviors takes a bit more time than I’d like. Otherwise, I’ve just been trying to address any of the little bugs that crop up.

I’ll be honest. I’ve got a touch of paranoia. With everyone with their newfangled Google Alexas and whatnot, I just want to go back to a simple home automation like my forebears built with their bare hands. With that, I’ve lately been spending more time trying to minimize outside exposure. This comes in a few areas: creating devices that don’t require APIs so I can, for example, ween off SmartThings. Although SmartThings is a great product for what it is, I think it’s fair to say that if you’re compiling node.js on your Pi in pursuit of a home automation system - it might not be exactly what you’re looking for.

Running a bunch of data on a low power system with limited disc space is an exercise in balance. When I first started building the machine learning component of SwitchBoard, I had made the assumption that four time categories (dawn, morning, afternoon, evening) would be sufficient to find some usefulness. And this was true. But, in an effort to make it more precise (thus, more useful), I’ve decided to experiment with upping the time categories to six (midnight, dawn, morning, afternoon, evening, night). Since behaviors in your home are tied closely to time - you likely don’t have your kitchen light on as much at 3am than you would at 5pm - I’m going to try and see if the predictions are more accurate.

I’d recently taken the training wheels off my machine learning home automation system. For quite a while, it was quietly collecting data and logging when it thought it had high enough confidence to actually take action. Since that time, I’ve made some changes to the way things are executed - but they’ve all been relatively small changes. I’ve also made some observations I thought might be worth sharing.

I had posted before about the Machine Learning incorporated into SwitchBoard. At that time, I was still collecting data and wasn’t able to fully test every part of the functionality. I now have that data.

I’m not a big fan of “always on” smart speakers such as Google Home, Alexa, etc. To me, it’s just too creepy to have a speaker closely tied to the Internet, built by companies with a vested interest in knowing more about you that’s always on and listening. If you’re paranoid like me, here are some steps to get on-demand (ie: requiring a button press) voice recognition on your smart phone that will work with SwitchBoard.

A big reason I build SwitchBoard is so I can do things the way I think they should be done. I like having my data be within my walls as much as possible. For external APIs, you often have little choice in rely on those outside data points, but if they’re varied, you at least lessen your exposure. My personal setup consumes a decent number of APIs and no single one has any real useful bits - they’re tied together and the logic to act upon them remains within my network. Maybe I’m paranoid, but that seems like a good default starting place when building something that deals with so much personal information.

I Need Help!

Having trouble getting SwitchBoard set up? Are you just interested in asking some questions to know if it’ll fit your needs? Maybe you only care about part of the code and want to repurpose it for some other project - or just have some general home automation questions totally unrelated to this code. Regardless, I’m happy to help as much as I’m able. The best places to reach out are:

I’ve been trying to keep updating SwitchBoard with features and bug fixes. There are a few things that seem logical to add that I’ve avoided - and there are a few that seem illogical that I have prioritized higher. I thought I’d share a bit of what I have on my current “todo list” - and a few items that I probably will not be working on soon (and why).

If you’re reading this, you’re probably already sold on the benefits of home automation. You’re also, statistically, probably not disabled. Those with accessibility needs have the most to gain from many newer technologies. While having a home automation system is handy when I’m too lazy to get off the couch to turn off a light or turn on the air conditioner, the cost of those interactions saved are relatively minor, they may be much more expensive - or even impossible for others.

One of the most powerful features of any home automation system is the ability to trigger specific actions based on a device event that has fired. There have been a number of custom apps built within SwitchBoard to offer some handy functionality right out of the box. Many offer ways to simply “announce” a specific action or state. As these may change between different devices, they’ve been made specific in use, but all share some common code. Maybe you’d like to get an SMS when your 3d print finishes, get a desktop notification when there’s a new article posted on a blog or give a voice alert if your Travis CI build fails. They’re all in there.

When I speak to people about getting into home automation, one of their first responses is that they don’t want to go through all the expense to buy smart devices. Maybe they rent their home and don’t want the hassle of setting things up to only have to tear it out later.

Sometimes, maintaining a complex piece of code that relies on third parties for code dependencies, APIs or software support can come with some significant risks and disadvantages. Some of these can be mitigated while others must be either addressed or abandoned.

Is this thing on?

Several years ago, I gave a talk about Home Automation and the very beginnings of SwitchBoard (before that’s what it was called). Many of my initial beliefs still stand true as a direction and aims for the project.

To use SwitchBoard, you’ll need a working version of node.js and npm. As node.js can run on a wide variety of platforms, I won’t go into the specifics of getting that set up. There’s documentation available for most platforms that can do a better job of describing all the details there. If you do have issues, I’m happy to try and point you in the right direction, though.

There was some interest in following development progress. This is the first step in setting that up.