We all know everything breaks, just how do I make a backup of my SmartThings Hub programming?

He is describing Hubitat and tbh if they had a useable app i would very much consider that route but for whatever reason they have never bothered with a useable app


There is, of course, a difference between a dump of the entire ST environment and a backup in the sense of something that can be restored. However a dump does at least give you a reminder of what you are aiming for. That’s probably something I ought to do today. I’ve got an encrypted dump online but I need to just add a plain version for download. I’ve not got a massive SmartThings installation so there is actually only about 1Mb of JSON.


I have exactly the same take. I have a Smartthings WiFi hub from 2018, and I’ve been very happy with it. With five years of use from that investment, I’d be quite willing to purchase a new hub for new features (e.g., Matter support and service as a Thread border router), but I’m very frustrated that an upgrade path doesn’t exist.

As jkp mentioned, I do hold out hope that Samsung will address this once the migration is complete, but if my current hub dies before there’s a means to backup / restore to a new hub, there’s no way I’d start over with Smarrthings, despite my overall very good experience with the platform.


He is describing a different brand of hub which allows backups and restores of its own brand of hubs.

There are actually quite a few of those, but none that I know of have the big cloud pieces in their architecture that SmartThings does. All are designed to run primarily locally after initial setup. All allow you to defer or deny updates if you choose.

The SmartThings architecture is very different. Because of the cloud piece individual customers are not allowed to defer or deny updates, because that might mean incompatibility with the cloud in a way that could not be fixed. :thinking:

Similarly, there’s no backup utility probably because of the corporate fear that someone might restore to a previous version that was no longer compatible with the cloud piece, leaving them with a broken system that could not be fixed remotely. A customer service nightmare. :scream:

They did at one point have a migration tool which could only be used by support, and only at the time of moving from one hub to another, but later withdrew it, because it didn’t always work, again, leaving some hubs inoperable with no way of fixing them remotely.

So, yes, there are some brands, including hubitat, Homeseer, and Ezlo Vera, which provide backup and restore capabilities for their own hubs. But while they do provide some cloud services, it isn’t woven into the architecture the way that smartthings is.

That’s why I am not optimistic of ever seeing a smartthings backup and restore utility until there’s a total redesign to remove the dependency on the cloud. It’s not impossible that that will happen in the future if matter turns out to be a big success, but it’s definitely not guaranteed. This isn’t just a matter of not having applied resources to it. It’s an issue of the fundamental architecture.



In addition to @JDRoberts post above, he also provided a very informative & graphic overview in this reply to my similar post/question about backups:

1 Like

@h0ckeysk8er So would the idea be to copy/paste those Routines into a text document to have for future reference (so that you could manually recreate the routines, using the text as a guide to recall what you had done previously) ?


I believe that’s all you can do with them. The problem with saving the text of the routines is that all references to other objects such as devices or scenes is going to be a long hex UUID. So you’d also need to create a list of UUIDs and note what they are.


In light of recent events, I think we can all agree that a backup and restore service is not just a nice to have, but an absolute must. Here’s hoping that some good comes out of this nightmare situation for those affected and ST is spurred on to take action. That might only happen if there is meaningful bad press however

I decided a while back to get into rules, which apart from certain function perks, allows me to save on disk the more complex routines. The learning curve isn’t that bad even for a non- programmer like me and what took maybe quite a lot of thinking is now safe, if something like what happened today occurs. A 80% of routines are easy for me to set up again, and anyway I like the friendly routine interface.
That, and an Excel copied from the excellent API Browser of my installed drivers with their corresponding devices is about all I can see I can do.
Don’t know if I can ask much more from a manufacturer who’s only sold me a hub (second hand in my case) Just a thought.


I desperately hope that as a consequence of the recent events urgent consideration will be given to updating the public version of the Rules API so that Routines are no longer needed for anything, and similarly that an action can be introduced that executes another Rule so Scenes can similarly be junked. I’ve been saying for a long time that Routines and Scenes are an unnecessary risk because of the way they are implemented. It is particularly unacceptable that Scenes are presented as a developer grade tool when they clearly aren’t at the moment. The specific events of the last twenty-four hours may not have been predictable, but the effect they had on Routines and Scenes certainly was and it seemed inevitable it would happen one way or another.


Events? Did I sleep thru some kind of tectonic issue?

Multiple people reporting that all their devices, including their hub, have been deleted from their account, along with all of their rules and routines. Even though some of things still showed up in the IDE.

It has been acknowledged as a known issue caused by a platform operation, but with no available, helpful resolution other than rebuilding everything from scratch. And even then some people are saying that they are not able to rebuild. :scream:

It’s not everybody but it’s more than just a handful. Acknowledged on the official status page now.

The status page says they will give affected users instructions on how to restore functionality, but so far the instructions have been to rebuild from scratch. :disappointed_relieved:

This is the email that some affected users received this morning:

1 Like

Yikes! Making me think very hard about Hubitat or HA!

I’ve lost the best part of a day from the timeline. It was very early morning in the UK when the first dropped b******* were being discovered and I had to wait hours for the next reports.

1 Like

Exactly this.

And yes, this did seem inevitable. I moved away from Routines completely because of the lack of backup capability. The automations I have on SmartThings are all rule-based, except for my scenes (for which I maintain screenshots for reference). My rules are all backed up in Postman, and I can update device IDs throughout them all by simply modifying the appropriate variable(s) in the event a device fails or is inadvertently or even purposely removed. Having an equivalent capability with Scenes would make me very happy.

My more complex SmartThings automations continue to run on webCoRE on HE, and those are backed up along with my hub. (HE also has a convenient tool for swapping devices with apps). I have mixed opinions about both platforms, but HE’s backup capability is undoubtedly superior…because there is one.

1 Like

If anyone isn’t following this:

Rules live on the https://api.smartthings.com/rules endpoint where the mobile apps keep their grubby paws off them, and they aren’t messed around with when devices are deleted. They only care if a device ID is invalid when they are created or updated.

Routines live on the https://client.smartthings.com/rules endpoint and are the plaything of the mobile apps. The developer documentation and the API Reference don’t even acknowledge they exist. They are actually Rules with some extra metadata to help with the presentation. When you edit a Routine it is converted from and back to a Rule and that is why they can get a bit confused by out of spec devices and can’t cope with deleted devices.

Scenes, on the other hand have a foot in both camps. They are acknowledged in the developer documentation and API Reference as types of automations alongside Rules and they appear on the https://api.smartthings.com/scenes endpoint. They are Rules without conditional statements. All great so far, but they are actually managed by the mobile apps in a similar way to Routines and carry extra metadata. So they can’t be managed in the same way Rules are. It doesn’t really make a lot of sense. If there was a way to execute a Rule in the same way a Scene is executed they wouldn’t even need to be a thing outside of the mobile apps.


Great explanation!

Can you elaborate on how one would use “Rules”, rather than Scenes and Routines?

Rules are submitted via the ST API. You write Rules in JSON format and then submit them via the API. There are numerous ways to submit your Rules including tools like Postman.

The easiest way is to use the API Browser+ from @TAustin. It is a web-based interface that allows you to manage the full lifecycle of your Rules including the ability to Execute them. There is also a link to the API Reference documentation that shows you the available options and syntax.


Here’s a general explainer on Rules to get you started.

It should be noted that portions of that discussion are slightly outdated or ignore new options, like the powerful API Browser+ that Bruce mentioned.

Rules can be written in YAML and submitted via the SmartThings CLI (command line interface) , or in JSON and submitted to the API. I personally prefer the Postman/JSON route if only because of my familiarity with both from so many past projects, although I admit that YAML can be easier to grasp, especially with more complex rules.

The whole process can look a bit intimidating at first glance, but there are lots of examples and some incredibly knowledgeable people here in the community that can help when needed.