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.

Beyond those simple use-cases, other apps are made available that do more complex actions. If you have a knock sensor and a contact sensor, the doorKnock app can intelligently differentiate between someone knocking on a door and someone jiggling their keys before entering. Other convenience apps can turn on your hall light when you arrive home, notify you if any specific sensors are triggered while you’re away from home (a push notification security system), trigger macros based on sun states or turn off your thermostat if a window is left open too long.

So far, I’ve discussed the simple and the not-so-simple apps. The others are much more advanced and offer additional functionality to specific devices. Two of these examples include the foscamDvr app which can act as a DVR recorder for the very inexpensive Foscam FI8910W wifi camera (and possibly others). You’re able to configure it with a specific maximum space you’d like for it to make use of, whether to generate gif thumbnails and how long each video section should run.

The other advanced app is Gerty. Gerty is a device controller that makes heavy use of additional apps to compliment it’s core features. The Gerty app is a delegated app - meaning it’s executed on any event firing of any other (specified) device on the system. Most apps do not require this level of holistic data exposure - but Gerty is made to act based on many inputs. You’re able to speak to Gerty and he will execute commands that are entered in plain English. “Turn on the hall light and the office switch”, for example. He is visually represented as an emoji - the emotional value of that emoji is dictated based on many parameters based on any incoming commands. Gerty is also the device controller that executes machine learning commands - and logs any valuable information in a friendly “chat log”, letting you go back and see interesting events and their times.

The finaly type of apps are conditional apps. Common apps are sent the device state after a command has executed. In some instances, this is too late to be useful. To protect my Hunter Douglas blinds from being lowered onto an opened window and causing damage, conditional apps are able to see the inputted command and, depending on the apps logic, determine that that command should be aborted - or possibly replaced by another. For my blinds, if they are above a threshold, they will only allow you to lower them as far as is safe to do so with an open window. If they are extended below the safe limit and the window is open, they will simply refuse to close - as this would cause serious damage. As these actions may be helpful - they may also be confusing at first. For this reason, they are also able to notify the user in any number of methods (voice, push notification, sms, desktop notifications, etc). Similarly, a Nest conditional app was made to prevent your thermostat from turning on if a window is currently open, presumably wasting power. Without this being in a conditional app, the air conditioner may come on briefly before a normal app would be able to turn it off. Although a system being on briefly isn’t particularly wasteful of electricity, that start-up of the compressor can result in more wear. It’s just a nice thing to do.

Why build them out as apps if some of this functionality could be built into the device controllers themselves. The simple answer is that it makes things much more portable. Some apps don’t care what device controller calls them - making them more widely useful. The other major reason is that device controllers should be the distillation of device interface without logic determining their specific use. If you look at, say, the Nest device controller - it has all the code available to send commands and retrieve data - providing it to SwitchBoard in a clean and tidy object. That’s all. Parsers are responsible for taking that tidied data and presenting them to the UI - and apps are responsible for taking any automatic actions based on any criteria.