Updates to the SmartThings Platform

@jody.albritton
I didn’t see any discussion about this point here or anywhere else. Is there details on what will and won’t work after this change? Will this change with custom capabilities or is this something that is intentionally unavailable for custom capabilities?

This migration to a new app/platform should have never started until a backup/restore/migration process was in place.

7 Likes

The migration should have never started until there was parity between the old and the new. The New App is missing some HUGE functionalities that the Classic App has and without theses, navigating through this “New” app is a complete fail.

I’m getting more and more frustrated.

8 Likes

Im pretty sure just about everyone here (that’s left) feel the same way. Samsung just does not get it right when it comes ro.software…never did & I think never will. Not knocking the software engineers for smartthings but this whole migration was botched to put it nicely & in the end all these decisions being made lay squately at the hands of management.

One very noticable thing was how things started getting quit when hubitat came out & now. I’m afraid things will get even more quiet after this debacle. I just wonder if someone from amazon is paying any attention to this :thinking:.

That is very true also.

it will be great to have filtering capabilities on automation screen. I have more than 50 automations. scrolling down becomes difficult at times.

2 Likes

This is the point. The previous version covered all of those concerns and probably more you’re unaware of. Not one of those options covers my specific need, but all of them have not been an issue for me thanks to the way the old version works. I can’t understand why your team would be considering creating a fix that targets just one of those concerns, leaving some others in the cold, when you could create a fix that solves all of them in one hit?

2 Likes

@blake.arnold

I mentioned this in a different thread today, but I wanted to put it here as well.

It appears that when changing from the classic app to the new app the old method of handling devices which supported central scenes with multiple taps has changed.

It used to be that each tap pattern was spoofed with a different button number. So, for example, for the remotec ZRC90 which has eight buttons each with press, long press, and double tap, the DTH would say that there were 24 buttons.

IMG_2378

[OBSOLETE] Remotec ZRC-90 Scene Master - Button Device Supporting 24 Unique Button Commands (see post 177 for 2021 app version)

The same method was used for many different devices, including the aeotec Walmote quad, The Homeseer dimmer and switch, The inovelli red series, And even the newest GE switch (46201).

This change causes multiple problems. Mirroring no longer works in smart lights, and the devices can go into a feedback loop, which I believe is causing some of the on/off/on/off/reports.

A lot of the button press controls don’t work.

Again, I could be totally wrong on this, but it looks to me like it’s occurring when the DTH spoofed the central scenes by making them look like separate buttons.

FWIW…

@Kianoosh_Karami @Eric_Inovelli

8 Likes

I migrated this past week and my most important smart app “Routine Director” which dictates what mode my house is in based on time of day and presence stopped working. I have spent 3 days now trying to write WebCore pistons to try and replicate this and I’m still debugging. Shouldn’t something like this have been offered in the new app?

Yeah, I can’t answer the technical side of this as @erocm1231 handles it, but it appears to be related to this answer: Problem with Inovelli RED Series Switch/Dimmer Scene capability in NEW ST App

"the SmartLighting app is now looking for the “supportedButtonValues” attribute. If it doesn’t find it then it causes an error. So the value needs to be populated. For example:

sendEvent(name: “supportedButtonValues”, value:JsonOutput.toJson([“pushed”,“held”]), displayed:false)"

Again, I’m not entirely sure what it means, but I’m guessing this is related to this thread where the new platform is looking for a different attribute than the old platform was and therefore if you have an existing DTH applied written for the old platform (before the update), it will throw an error.

1 Like

Big Tech doesn’t like giving users choices. That’s what happened to Google (can’t even count the number of neat services they killed), Apple (the old Mac, and even early MacOS X machines were a tinkerer’s dream, but the iPhone is a walled garden). So it’s not too surprising that it’s happening to SmartThings, now that they are owned by a large corporation.

Actually, it’s a miracle that the customization, coding, and the like have lasted this long under new corporate ownership. Samsung has done surprisingly well in this regard. But I guess all good things have to end.

That said, I think I can live without the old app. I really like SmartThings and I’d like to stay as long as I can. But the moment I can’t write my own custom DTH (and use them with newly-added devices), custom SmartApps, and of course use WebCoRE, is the moment I switch to Hubitat or Home Assistant.

1 Like

Hi @blake.arnold

Thanks for reaching out to us - we’ve spoken before, I believe. I have a home with about 240 active devices. The migration to the new app has been far from smooth, to the point where I am concerned about the security of my home - happy to talk about that in another thread, but let’s discuss my use case.

My home consist of multiple services, but let’s just focus on four: smartthings, Google home, lifx and Hue. Prior to the switchover, smartthings was controlling about 70% of my devices and sensors directly. The rest were controlled by the OEM’s cloud services. Smartthings and those lighting services interacted fine, but I found that voice control was better handled by GH talking directly to the other services. It was faster connection/response time, and allowed me to have the lighting features more easily controlled by voice.

If I wanted to control a smartthings scene that contained a hue or LIFX light by voice, GH would talk to smartthings, and the scene would run.

Now, however, smartthings is running the show directly. Lights react slower, and I have lost the ability to access all of the attributes of the lifx and hue services by voice. The new smartthings app also stops device connections as a matter of course. (at any point in time, roughly 5% of my devices are “offline” according to smartthings (I assure you they are not), if a hue or LIFX bulb is one of those 5% GH will not control it.

What has made this worse is that I am no longer able to edit, create or delete scenes in the smartthings app if those scenes contain a light that has dimming capability.

Essentially, I went from 240 devices operating in relative harmony (since each was controlled by the service that made the most contextual sense to control it) to 240 devices that may or may not work as intended, or - in many cases - work at all.

6 Likes

None of my Alexa routines using virtual or phisical smartthings devices work with this migration but Alexa does see the device change status. Maybe she just got lazy?

1 Like

I’m sorry if I missed this… does STHM now run locally (for example if a Samsung water sensor triggers will if close the water valve even if internet is down). The SHM worked that way. This is a deal breaker. Where is the official information on this ?

1 Like

I’ve been a software developer and project manager for over 30 years. If I presided over a migration like this, I would be in the unemployment line.

Stupidly, I updated the Alexa integration and immediately ended up with tons of duplicate devices. Why couldn’t upgrading the Alexa integration prevent duplicates? Maybe there’s some valid technical reason, but I’m skeptical. In any case, things seemed to work so it wasn’t the end of the world.

Later that day, Alexa started telling me that almost every device is offline, even though NOTHING is offline and every device is working correctly. So I disabled the Alexa skill, deleted every ST-connected device and enabled the skill again. Still, it’s reporting everything is offline. Fantastic.

Then I remembered something about device status being changed, and hubs with pre- 0.32 firmware “will use hub connectivity status to determine status for hub-connected devices”. Crystal clear what what really means, right? Well, I’m one of the saps that bought the Nvidia Shield ST Link that Samsung has abandoned. It’s at firmware version 020.00012. I assume this is why Alexa now thinks that every device is offline. Fantastic programming and QA.

It’s bad enough that these changes were pushed with little warning, and it’s bad enough that existing functionality is being removed, but surely ST knows who has these NVidia ST links. They could have sent out an email warning us that things were going to stop working.

I used to be a big fan of Samsung products, and I’m not willing to condemn the entire company for the actions of one product group but I’ve really lost confidence in ST. We’re all human but they have a lot of work to do to make this right. If I had the time I’d seriously consider migrating to a different platform, but I don’t, I just need things to work.

I’ve got a V3 hub sitting in a box so looks like I need migrate everything away from the abandoned Shield Link onto the V3 hub. But hey, that shouldn’t be a problem because we have a great migration utility, right?

12 Likes
2 Likes

Thanks @uberrob - this is helpful information. The team is working on an option to allow for selection of devices that are shared with GH and Alexa which sounds like it should resolve most of the issues you’re having by being able to point GH to the other native services for full functionality and lower latency with those devices. I really appreciate the detailed use case and constructive feedback.

15 Likes

I know timelines are hard, but is the expectation that this will be live before the old Alexa skill is deprecated?

3 Likes

There are a number of different ways to go about fixing the problem, each has tradeoffs in terms of dev time, efficiency, cost, UX, etc. Having more granular information from our users about what their top priorities are helps us determine how to balance each of those possible fixes and the tradeoffs they require.

6 Likes

So Smartthings support initially asked me for a video showing the errors in-app regarding my previous post, but after I sent them a video they basically replied with “sorry, that’s using a custom handler we can’t help you” (paraphrased). To some extent I understand, but this functionality was working in the new app not that long ago, and now I have corrupted lighting automations that I can’t delete and the app just crashed when I try to go in to them. Seems like at least some of this is a Smartthings issue and not a problem with the custom handler. This is frustrating. (anyone from Smartthings, the ticket is 1015107 )