Get ready to make the switch!

You are going to see the workspace align more with the CLI, which will become the primary way that developers interface with the platform. As others have noted the CLI is open to everyone. We are building tools that will allow larger companies with many collaborators to publish their devices/apps AND those same tools can be accessed by individuals. This work is not being done to exclude anyone.


The point is that I didn’t join an organisation. I AM the organisation. I did create it using a second Samsung account but I can’t remember if I actually NEEDED to do that. It is more likely that I was a) curious to see how it would work, and b) quite liked the idea at the time.

I don’t have any fear for the future of individual community developers. I just think that the Developer Workspace isn’t a particularly comfortable place for them quite yet.


Thanks Jody, appreciate that info. I installed the CLI and watched your video. Got it running, it wouldn’t authentic my account, but got it working with a token in the config file.

I’m just an amateur, and am trying to update a dimmer switch DTH. I figured I should be able to figure out the CLI to at least display the dim level on the main screen of the app. But the DTH itself seemed like it would need a lot of rewriting to even work with the CLI. Plus the whole CLI process is bulky with running the commands in Python, creating the JSON file, then updating the IDE. I just can’t see amateurs figuring that out, and experienced coders that have been on here for years can’t.

Plus, this is an Alpha release, not even Beta. I don’t know if I’m doing something wrong (likely the case) or if it’s the CLI? I can’t see developers investing time to rewrite code in this when there is so much uncertainty.

It’s encouraging to hear moving towards an open developer space, but it’s just not ready yet. Hopefully it will all be before the IDE is gone, but a lot of us are still a little shell shocked about the sudden changes. Appreciate all your hard work with this and posting here though.


As for the Migration support page missing, as Jimmy put it, ‘he got receipts’ (smile)

1 Like

All the feedback is appreciated. The CLI is just a convenience tool built on top of our open and documented APIs. The CLI and SDK source are both available on github as well. Technically everything the CLI does could be done with direct API calls today, we created the CLI to make it easier for developers to build integrations on the platform.

It is going to be a learning curve, but it is worth remembering that the groovy IDE while it did serve us well, had not been updated in some time and also had its own share of limitations. The CLI is built on top of an open source framework (OCLIF) and this is a giant departure from the IDE. Once developers are more familiar with our APIs and frameworks they will be able to add their own convenience plugins to the CLI. As a developer tool, this sets the CLI up to be not only used by but enhanced by our community of developers.

I understand that this departure creates a learning curve, but want to reassure everyone that this is a brand new world of opportunity that enables some things that have been asked for going back to before I joined the company as an employee. I still consider myself a “community developer” and a “hobbyist” so I am always looking for ways to enhance the developer experience for those adventurous tinkers out there. The next thing I will be talking about is the new direct connected devices SDK that will allow developers to create their device and connect it directly to the SmartThings platform without a hub or a cloud to support it. I am looking forward to the future of the SmartThings developer community. I know things are a bit rough around the edges now, but the groundwork we are laying today will open many more doors than were previously available.

Final thoughts,
Everyone keep providing feedback and help us get to where we all want to be. A healthy and happy developer community.


A post was merged into an existing topic: Alternative Hubs

After migrating I have lots of things that no longer work.

For axample i have an old core piston that has a restrictions to only run when in mode (armed stay) that will no longer run.

Dose core and are webcore nolonger see modes?

I know it can’t see STHM status but I thought modes should still worked!

There are two different kinds of modes: location modes and security modes. STHM (The feature in the new V3 app which is similar to the old SHM) uses security modes. But the STHM security modes are not exposed to Webcore or Core.

People are using to workarounds for this.

  1. if you only use the default location modes, you may be able to just make the security mode mirrored the location modes. But that generally doesn’t work for people who have custom location modes.

  2. alternatively, you can create a virtual switch for each security mode and turn it on and off as STHM changes the security mode. Then you can trigger your piston off of the virtual switch.

It’s annoying, but it works.


Thanks for replying @JDRoberts
I am using the location mode and not the security mode/status.

I have just been looking at some Webcore pistons and Webcore does seem to still be working with Location Modes.
But apparently the original Core is no longer seeing location modes.

The question is, is it worth rewriting all my old core pistons in Webcore are is webcore just going to be killed soon too?

Webcore has a tail. A long one.

First the IDE already has a declared life of about a year.

Second, Ady has already stated he has plans to upgrade WebCoRE to use the RulesAPI when RulesAPI supports variables.

CoRE has been unsupported for over a year.

So yes. Uograde yiur pistons.


I’m getting a bit confused here because ‘armed stay’ isn’t one of the default location modes, it is an SHM alarm system status.


I migrated Friday and finally got my things ‘mostly’ working again today on Sunday.

So I have around 130~ devices. Mostly a mix of GE Zwave wall switches, Ecolink Zwave tilt and contact sensors, a few iris contact sensors a water cop Zwave valve and then a bunch of SmartThings branded zigbee devices, including water, outlet and multipurpose sensors. I also have a modified contact sensor as smoke with a kiddie relay as well as a bunch of ‘cloud’ devices including those from alarmserver, ring, honeywell and myq.

All of my physical devices migrated as well as automations using those devices.

However, I make use of alarmserver - envisalink- DSC to get my alarm and it’s sensors into SmartThings as well as Lock Manager and that’s where things went south immediately.

I purposely remove lock manager prior to the migration because I wanted to try out the new SmartThings lock solution.

  1. the migration screwed the pooch on all on all of my ‘scenes’ that utilized those alarmserver ‘cloud’ devices that alarmserver brings in. I called Samsung for support because they were just ‘missing’ from the new app, but still showed in the old and in IDE. They told my they’d re-migrate me in 24 hours… been 48 and nothing.

Finally gave up and manually deleted all of the DSC devices that come in from alarmserver via IDE, then reran alarmserver to get them recreated - they then showed up in the new app and I was able to recreate my automations that use the devices

Support = 0, me = 1

  1. SmartThings Smart lock guest access… I’m just going to say what a total piece of crap. It sends notifications any time someone enters a code and that notification setting tied to STHM security settings - so if you want to get an alert when you alarm goes off, you also have to get a notification any time someone entered a code?? Who though that was a good idea?? Next issues, when I rename the code slots, SmartThings immediately resets them to code 1, code 2 the moment they are used. - under history, this should be able to list ‘who’ open the lock and whether it was manual code entry or via app like the old system- fail. Oh and I can’t forget that code management is ‘per lock’ without any synchronization options… seriously!? These devs are just lazy or stupid - not sure which.

Stupid decisions.

SmartThings devs = -3

Fortunately Lock Manager still works for now though it all has to still be managed via the old app.

  1. STHM has zero integration with 3rd party smart apps effectively making my alarmserver setup useless without a workaround… and the workaround isn’t fully baked but it will do for now.

Come on Devs!!! You call this a production ready release ???

What a joke.


People keep mentioning things like this. The migration does nothing to those devices, or other SmartApps. Before the migration they would have worked in both apps and after the migration they would continue to work in both apps.



As I mentioned, my PHYSICAL devices were fine. However, my CLOUD devices were hosed. I understand that they were not SUPPOSED to be screwed, but they were in fact SCREWED.

I’ve deleted EchoSpeaks and Alexa. Installed the New Alexa App after deleting everything in the old App. Actually went pretty smooth. Had to rename a couple of things but all in all, wasn’t that bad.

As of now, I am going through all of my virtual switches created by a couple of Apps and recreating those in the IDE to be Simulated Switches. Tedious process but making it through.

The timeline given, IMHO, has been enough to make needed transitions. Hate I have to go through all of this but hopefully, the future will be promising.

Good note, Alexa is much faster now!

Bad note, this process would have been impossible without knowing which Apps were tied to which Devices. ST needs to FIX THIS ISSUE ASAP!


It may not be a ‘default mode’, I had probably created it years ago for only god knows why!
That’s the biggest problem I am having with this whole mess is trying to remember what did what and why.


Fair enough. I sometimes wonder if the ability to control SHM from third party apps has ultimately caused more harm than good.

This is why I use webCoRE for most of my Rules. I use easy to understand titles and put a (webCoRE) behind the Rule name.

The “New” App gives you nothing. You are just up s**t’s creek without a pedal. :man_shrugging:t5:


Its not just the risk of things breaking, its also the fact that there will be NO support whatsoever to help you out afterwards.

I have made the switch 2-3 weeks ago, and have YET to receive any form of support. Either I am being ignored (from within the app), or the Samsung Support doesnt know what to do (“because we are sperated from smartthings”).

Its a nightmare.


Support has thrown in the towel… I’ve had a ticket open for 2 months, just to have a smartapp removed that was inaccessible.

I’ve lot count of how many times they asked me to reinstall the new app :joy: