Updates to the SmartThings Platform

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ā€¦ @Automated_House, 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:

4 Likes

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.

@philh30

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.

4 Likes

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.

2 Likes

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.

6 Likes

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:

7 Likes

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.

https://smartthings.developer.samsung.com/docs/smartapps/smartapp-basics.html

No, Iā€™m not signing up to do it. :slight_smile: Azure CosmosDB on the other handā€¦ Maybe.

3 Likes

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ā€¦

4 Likes

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:

17 Likes

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.

2 Likes

Yep - thatā€™s exactly why I started reading the docs top to bottom, to see if I could unwind best direction for that kind of device. May be worth asking @jody.albritton for a pointer in the right direction (low priority Jody, go fix the other stuff first) :slight_smile:

2 Likes