Get ready to make the switch!

Pretty soon v3 will be new classic

I have also done a “soft migration” this weekend, by deleting the SHM settings and routines in classic, and rebuilding it in the new app. I still have both apps installed, and haven’t pushed the migration button.
So far everything works more or less as expected
 :crossed_fingers:

I do have on issue/question though:
Every time i receive a notification (push message) from WebCoRe or the new STHM, i receive two messages - one from the Classic app and one from the new app.
Is this to be expected or is there anyway to disable messages from the Classic app?

Yes, it is to be expected and you should have the option in your phone to turn off notifications for various apps installed on your phone including ST. Applies to Android and iOS.

1 Like

Thx @rontalley

Yes - i did that
 :+1:
The Classic app doesn’t have an option to disable messages like the new one does, and i was just nervous that i had forgot to remove something in the old app


Wonder if hitting the big Migrate button would disable messages in the Classic
? :thinking:

Nope
 I recently discovered that!

2 Likes

On iOS, under settings and notifications, you can disable notifications from any app installed on the phone. I’m sure that this is also true for Android. It’s not located in the App itself.

1 Like

It is also true on Android. I disabled my notifications from Classic this Monday.

1 Like

Reassuring; that’s my plan, I’ve replaced SHM with STHM (only using it for leaks) and start recreating one of my more complicated routines each day, which usually turns into an hour or so of troubleshooting. So far I’ve had a lock that doesn’t offer to unlock (resolved by changing to a stock DTH) and virtual presence sensors that don’t show up under presence (they’re devices). Who knows what surprises tonight will hold


1 Like

As mentioned before I manually migrated. Last night I pushed the migrate button and in seconds I received the notice that I was I fully migrated. :slight_smile: The app now shows "This location has migrated to the new ST:

One interesting item I did notice in the classic app I was listed twice as owner to my location but only once under the new app?

1 Like

If you used to have a SmartThings account that was migrated to a Samsung ID thats where that came from. I THINK the migration also disassociates old SmartThings IDs

1 Like

@nathancu, that make sense as I was an original ST used before Samsung, I just never noticed that before.

1 Like

@blake.arnold Is there some reason STHM isn’t exposed via the API as SHM was? I just converted to the Connect app and I use Sharptools dashboards as a primary means of interaction. Arming and disarming SHM via Sharptools was easy. With STHM, it’s only semi-doable and awkward because STHM is apparently not exposed. Even with a hack, there is no way to “externally” confirm the STHM setting.

2 Likes

I manually migrated months ago also. Still had the classic app but hadn’t opened it in at least 3 months.

So I triggered the migration for whatever it does as far as marking accounts or any such :laughing:

Yes - we looked into opening up STHM via the API before we started first rolling out migration and determined that doing so would present an unacceptable security risk to our users. I can’t go any further into the details than that, but it was an intentional decision, not an oversight.

4 Likes

I understand the reasons for this, it’s what most security systems do. However, there is a big missing piece, which is a locally processed keypad and a locally processed key fob which can both change the security.mode so that you can arm or disarm STHM even when the smartthings cloud is not available. The dual logo ADT/SmartThings system had this, and it is very much missed in STHM.

7 Likes

At a minimum scenes should be able to control STHM and the API should at least be able to read status.

Piling on to what JD said, if you are going to limit it to native automations, those also need to be rock solid and local (neither of which is true today).

5 Likes

Was SHM in Classic/Groovy ever officially documented to work with third party SmartApps? Or was it reverse engineered and then widely spread through the community? From what I remember, I don’t think it it was ever officially documented in the developer docs.

Worried about a security risk for access to STHM so no API accesz, I get that. I used the work around of creating a virtual switch to control STHM. And them smartthings automatically exposes that to Alexa without my permission and someone can stand outside my door and ask Alexa to turn STHM off. How is that secure??? I did rename and disable the virtual switch in Alexa, but anyone can re enable it
 how is that secure???

5 Likes

It would probably have been easy enough to reverse engineer as it was really just the alarmSystemStatus attribute of the location and the events would have been flying around, but I seem to recall seeing that it was is in documentation that was never officially published. The equivalent of reading development code in a branch of a Github repository.

The basic details do now appear in the Rest API as the AlarmSystem capability but I don’t recall any official endorsement.

The API does include a SecuritySystem capability that looks very STHM like, subscriptions to the status of security systems, and mention of security authorization scopes, but it just seems an inherently more secure implementation. Or it did until it became available in Automations. I guess it depends on what it is meant to be secure against.

3 Likes

This please.

1 Like