We need a standards-based solution for smart home device and automation backups

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?