Updates to the SmartThings Platform

Works fine for me on iOS

1 Like

Just another little problem to to the growing list. If you create an automation that turns a device on with a Turn Off After delay set, you cannot then edit that automation and adjust the delay. The option is grayed out. You have to delete the action and recreate it with the new delay. iOS and Android.

1 Like

Yes, that ‘long press’ does work as you stated and is the same function as ‘Move Devices to another room’ in the 3 dot menu when in a room where the device exists…

But what does NOT work is trying to assign a NEW device to a room that is NOT in a room from the devices view, which is the only place one can find a NEW device that is not assigned to a room. No long press in that view as shown below and therefore one has to press on the device and begin the process of several clicks to assign each NEW device to a room… @prjct92eh2, am I missing something here?

@kurtsanders There’s a section at the very bottom of the dashboard that will show up devices not in a room:

If you use that button at the very bottom of the screen, you get a pretty handy interface to move them all to different rooms at once:


As noted there is the “No room assigned” room.

An interesting (odd) design choice in the new app is that it won’t let you create devices without putting them in a room. It forces this. That there are still ways to create a device not in a room (IDE, other SmartApps) make the new app a little annoyed.


That ‘No Room Assigned’ room no longer shows up in my rooms view, perhaps the dreaded 20 room limit should either exempt that special ‘no room assigned’ room from the 20 total, or allow the legacy feature to bring in new devices unassigned to a room to an existing room …

Otherwise we highly compulsive organized room users are OOL. :hot_face:

1 Like

@kurtsanders Did you have unassigned devices when you looked for it? The unassigned room goes away once I’ve put everything in a room. I just added two more rooms to get up to the cap, then added a device through the IDE, and I still see the unassigned room popping up at the bottom. Whole lotta scrolling to get there though. I do have to kill the app and reopen to get it to show, but maybe I’m just impatient.

1 Like

That could be it. :face_with_head_bandage: perhaps dynamically created child devices are an issue?.

But when I executed the new SmartApp that created the new devices, I scrolled to see that special room and I could not find it. I suspect that I might have to hard exit the new STApp and come back in to see that room. What a &&@.

How hard would it have been for the ST developers to bring that old feature back which we used to add new Unassigned devices to a room from a room.

At the first place, there should have not be any trade off by removing (not implementing) this feature.

At the moment it is quite clear, that people generally want to have control over the shared devices. It doesn’t matter for what reason and for what category of devices.


I used both the new and old app to transition from Konnected smartapp to the Konnected cloud. I transitioned one board, then a week later did the remaining two. It wasn’t too bad. I had trouble deleting some devices that were via the old smartapp unless I removed them from certain other smart apps (like smart lighting or old SHM). Just make sure you document what automations you had before, so you can redo them.

Now I need to tackle moving SHM Delay 2.0 to the new STHM. Not looking forward to that. Entry/exit delay should be built in. :slight_smile:

Entry delay is built in…

True, but not as robust as I’m used to with a smartapp.


This should of been done in January.
You have no qualms of getting 50 users to sign up for a questionnaire, but not to test the new app? This whole mess could of been easily avoided. Which would of given you 8 months to fix all these problems with the new app, instead of less than 2 months. I can’t think what the industry term is for this practice at the moment. Why you’ve chosen the hardest possible experience for users is beyond me, a home automation app transition should be treated with more care and attention, as it deals with people’s homes, it’s not a picture sharing site.


While I don’t disagree with your point of view, one must not fail to recognize that there is no other industry that has more impact to our homes as this gadget has, for which many of us paid, years ago, less than a bucket of paint and expect not only to last forever, but to improve overtime. #skewedExpectations :slight_smile:


One app I will really miss when the time comes is InfluxDB Logger. I log all my sensors, switches, etc into influx database to visualize on a dashboard.

Any dev type folks run this and could see how to keep it working once Groovy goes away?

The new paradigm for Smartapps are Webhook endpoints (meaning you can basically write it in anything you want or AWS Lambda functions. This one is actually going to be fairly straightforward to port it looks like - it’s just a data pipeline.

No, I’m not signing up to do it. :slight_smile: Azure CosmosDB on the other hand… Maybe.


I haven’t taken the plunge on trying to learn anything about those yet… Am I right in thinking those are for cloud to cloud integrations? The influxDB runs on LAN, so I’ve been thinking that there’s not currently anything that can be done with it.

1 Like

the hub is perfectly capable of HTTP POST on the local LAN. WebCoRE makes use of this feature in it’s HTTP POST function… In fact, I have a piston doing it now to control my Fully browser that drives my ActionTiles Tablet.

(EDIT: I’m also reading a few ways to do this as a ‘direct connect device’ which connects through MQTT - in any case there appears to be a few ways to slice it… Everything else is still valid though)

I’ll have to dig in to the docs - but that leads me to assume you could use webhooks to a Pi - or anything else on the local segment. The way I read the docs, they don’t care where you put the compute / logic portion of your app, it’s just not going to be inside the ST compute cluster. Which makes sense considering they’re (ST) probably paying a TON for compute to drive the back end of the Groovy IDE (how many shards were there at last count?) and as end-users writing and executing Groovy code, we’re getting Platform as a Service (PaaS) cycles basically for the price of a one-time free subscription (get the app only, there’s a lot more of these than I even realized) or a Hub…

(EDIT 2: Read that last paragraph again if you’re skeptical about SmartThings having a vested interest in local processing… it’s ABSOLUTELY in their best interest to offload as MUCH as possible to your personal hub. They need to save compute. There’s an army of underutilized compute devices at the client sites…)

Basically, last call - you don’t have to go home, you just can’t stay here…


I understand what you’re saying, but I do disagree.

I have used the smoke alarm example before. I can pick up a $30 smoke alarm in any drugstore and expect It to work reliably and consistently, OK, not forever, but with an industry standard of 10 years. And that’s literally a life and death product.

And I don’t think most people expect most individual home automation devices to “improve over time.“ They recognize that new models will have new features.

What they do expect Is that if they don’t themselves make any changes, then what worked on Monday will work on Tuesday, at least for about 5 years. I know there’s no industry standard on this, and the warrantees are ridiculously short (1 year in most cases). But I do think that’s the expectation that most people have.

As I’ve mentioned before, I myself adjusted my expectations back in 2015 and put home automation in the same bucket as mobile phones, with a typical three year replacement cycle. if an individual device lasts longer than that, that’s great, but I don’t buy anything if I won’t get my money’s worth out of it in three years. And that includes a hub.

But in exchange, I do expect manufacturers to deliver a MFOP (maintenance free operating period) Of at least six months and preferably 12. Twelve months when everything that works on Monday still works on Tuesday, no maintenance required. :sunglasses:

The MFOP expectation works for most of my home automation stuff, including the Phillips hue bridge, Apple HomeKit, Echo plus, even cameras and backup systems. But it doesn’t work for smartthings. Things keep changing, things keep breaking. And I don’t think my disappointment is because of skewed expectations, which is where you and I disagree on this particular set of posts.

I think from the beginning, smartthings has intentionally tried to be a black box service, “protecting” Customers from having to know what’s happening in the cloud. So we don’t get change logs and we don’t get diagnostic tools and they even take away device history. Which would be fine if what worked on Monday still works on Tuesday.

But they also seem to be a “run fast and break things“ development culture and those two just don’t go together for some thing as critical as home automation.

JMHO, of course. :wink:


I can see the writing on the wall that that’s where we’re headed, so I’m fully expecting to have to work on my alarm, ST_Anything devices, influxDB, and a few other random things that are talking over the LAN. So far though, everything that I’ve seen has been that the new developer workspace is for cloud integrations, and that everything local (zigbee/zwave/LAN) is coming later. I haven’t bothered to log in to the new workspace since I have no intention of putting that stuff on the cloud, and all my efforts to transition right now are just to get the Groovy code to play nice with the new app.

If webhooks to a Pi are possible right now then that’s something I need to go ahead and learn. I’m lucky to have time now to work on this stuff. I won’t have that luxury if they drop Groovy on a similarly quick timeline at some other time in the year.