I’ve been automating my home probably since the day I moved in, and it’s always been a challenge to choose which technology stack to go with for such a task.
At the time, there was only a few options that supported both Zigbee and Z-Wave smart home devices, and at the time, SmartThings had the widest range of device support, largely thanks to it’s community device handlers and smartapps, written in groovy.
I didn’t really know groovy when I got started, but essentially it’s like a runtime-less java, and if you can get along with python, ruby, php, or any of those languages, groovy should come fairly easily.
The first thing was dimmer switches, outlets. Next, was alarm system, motion and contact sensors. There was some existing stuff out there for this, but I quickly realized it lacked a majority of the alarm panel features. I decided to start a fork, and with that became my DSCAlarm project:
I could probably write an entire article just about that – but, to continue the more general theme of this, it didn’t stop there. Leak detection, garage door, presence sensors, and integration with Alexa. I’ve even done some integration into my aquariums – controlling some lights or this or that. Though – i try not to rely too much on smartthings for anything life-support related, as it is a cloud service, and still pretty heavily tied to the internet to function correctly.
And perhaps that is the one biggest disadvantages. There’s even been a few start-up smart home projects specifically around solving that problem. It’s just not a local hub. The second version of the hub was supposed to bring local application abilities, but really, it’s been limited to their own internally written apps and native devices, so it’s been practically useless for all intents and purposes. For the majority of us, we just deal with the limitations for now, and hope that some day they’ll be able to truly “internet-outage-proof” more of the platform. Though, with all the interaction into cloud services, it’s easy to understand that this will never be feature complete no matter what, and any good future smart home system will need to have some notion of a “limp home mode” when the cord is cut….
I spoke a little about lack of autonomy being one of the main disadvantages of cloud services in the past, and it’s easy to see how this can almost be a design issue, as much as an issue with the cloud topology itself. You want connectivity, but you also want it to know what to do when that connectivity is not there. Right now, many of these smart home devices only can go half-way in that regard, so we still have a long ways to come. I think these smart home devices and cloud-enabled devices in some ways has let internet application design bleed through into the appliance / device design world, for better or worse. The true test to this will be the lifespan of the products born from it.
Right, now, as-is, it’s not terrible, just don’t use it for your life support system, haha. I always try to have a backup plan for when the internet is down, but otherwise, it will usually work pretty well. Things like my smart power strips can be difficult to turn on manually during an outage, but most things like my z-wave light switches or the like, you couldn’t tell any difference. And ultimately – for most things, that how it should be.