News this week of Comcast shutting down Stringify has surely upset the service’s user base. Granted it’s a small group of affected users – Stringify had 100,000+ downloads in the Google Play Store compared to more than 5 million IFTTT installs, for example— but it has left Stringify users out in the cold. Why? Because all of those advanced custom smart home routines and device connections have to be moved to another platform.
That platform could be IFTTT or Yonomi, both of which are web- and app-based, or a completely different DIY hub solution such as OpenHAB or Home Assistant. I’d say the most comparable solution to Stringify is Node-RED, although that requires both new hardware and some minimal programming chops.
Regardless of these choices, there’s a big problem facing Stringify users. There’s no way to export the existing flows or automations into any of these other platforms. For example, any existing automations such as turning on a light when a person opens a door has to be re-created in whatever new platform that the user selects.
It seems kind of strange to me, but I see why such a backup or export/import feature doesn’t exist for these services: They all have their own interfaces and approach. IFTTT, for example, makes routine setup the easiest in my opinion: Pick a supported service, set up a trigger event and then an action you want to happen. It’s simple, but a little constrained: You can’t have multiple triggers or actions in a single routine, or recipe, as IFTTT calls these functions.
So why is it strange that there’s no backup or import/export? Because all of these services have different front-end solutions that generally use the same back-end technology. What I mean by that is the IFTTTs and Yonomis of the world are connecting things with APIs, many of them being the same or similar to each other, regardless of the platform.
Sure, there are likely some other custom APIs or code that’s being used by these third-parties for connecting devices and creating automations. I’m not thinking there’s a 100 percent effective solution that can be easily created for backup purposes. Surely it shouldn’t be too hard to get 60 or 70 percent of the way there, however.
This is a problem too from a smart home hub standpoint. Want to switch from a Wink to a SmartThings hub, or vice versa? Device discovery generally works the same but running through the discovery process doesn’t take too long, so creating a way to back up your home’s devices before switching hubs may not be worth the effort. Once the devices are recognized by the hub though, why do all of the alerts and automations need to be recreated again?
Programmatically I understand why, but I’m looking at this from the end user perspective: These devices use standard radios and wireless protocols, and they generally have the same capabilities (with a few exceptions) regardless of the hub that’s controlling them. So why is it such a hassle to deal with when switching out hubs, automation platforms or moving to a new home?
Frankly, I see a huge opportunity here for the right developer or development team: Build a service that reduces the time of setting up a hub, devices or automations when needed to eliminate this consumer pain point.
By building upon the device and radio standards currently used in the smart home, even if it such a service could eliminate half of the setup time by providing a backup or import/export feature, I’d willingly pay $10 or $20 whenever I had need of this. I think many other smart home owners would as well. Would you?
I think the reliance on cloud-connected devices is at the heart of this. If your devices have open APIs or standard protocols like Z-wave or ZigBee and that can be accessed locally there is no reason to have a service like IFTTT (which originally was something you could host at home). If a device needs an app, it is probably connected to the cloud. I truly believe there is a market to be won in locally connected doorbells, security cameras, thermostats and the like.
This is one of the main reasons I tell people to get a Hue hub instead of linking the devices directly to your automation hub. Going between models of SmartThings and Lowes Iris hubs required you to start over from scratch. Compare this to upgrading your TiVo. You can selectively move everything (other than losing the “non-transferable” programs) onto the new box via a web interface. There too modular is they way to go to keep your options open and recovery as painless as it can be. We learned this with our entertainment systems. Or at least should have.
And this is also why you should avoid devices that require cloud services in general. Especially if they do not have a large user base. For instance Facebook and Google have both yanked some linkages to IFTTT lately. On top of that several IFTTT linkages have been iffy for awhile. So IFTTT is not looking that good as an option. Google is downright getting a rep for shutting down services and half “upgrading” them before leaving them leaving them half done. G+, Inbox and Google Drive for examples. Microsoft is walking away from digital books leaving customers high and dry. MySpace just lost a good percentage of user data. Flikr made people pay or scramble to move their images. And so on. It just keeps coming while the biggies like Amazon, Google and Microsoft keep saying the cloud and digital ownership is the future. Amazon is still selling and suggesting the Wand despite the servers seeming to be down more often than up. How do they expect anyone to keep buying in when you might lose or have to scramble to port your content at any given moment? Or lose a service that was a critical link in your framework? I feel a HUGE cut back coming as people rethink dependance on these fickled companies.