You know what I always say… rip the bandage off quickly… get it over with.
1 Like
That thought hadn’t escaped me. It would have been handy to have had the thought a few months ago though.
1 Like
So it seems like I have found another thing about the migration to the new app that is creating something that I don’t desire: Smart Lock Guest Access.
I am suddenly getting notifications each time someone unlocks the door. I do not want to know when or who unlocks the door. There does not appear to be any way to disable these notifications (at least that I’ve been able to find). Does anyone have a work around or solution to stop the notifications whenever someone unlocks the door?
I don’t think it is possible to disable notices for smart locks guest access. You would need to look into the LUM app from @RBoy
Check out this all which allows your customize notifications (and actions) for each user
1 Like
Here are the instructions on setting up virtual switches as a wirk around for using STHM with action Titles until native API works. If ever.
Mine works flawless. Fingers crossed. 
While I appreciate the suggestion to look at another app, I’m not very interested in spending money on an app that should not be necessary for the function I’m requesting. While I’m sure Rboy’s apps are great and provide needed functionality and value to certain users, I would not be one of them.
Why are we going backwards instead of forward? Why can’t I have the option to not have notifications when someone unlocks the door. I hate to be a complainer because I like SmartThings, but it just seems like everything is being dumbed down just because some people might not know how to do certain things. Why force me into notifications I don’t want? Just give me the option. It can’t be more than 5-10 lines of extra code.
1 Like
Ok, I’m now having the same on/off looping problem with these switches once I set them up and test them. They all start randomly turning on and off and I can’t stop it unless I remove the rules. I had to literally remove all of the rules to make it stop.
This is my setup:
I have four physical light switches. I want to make it so that I can go any one of the four switches and either turn it on or off, and the other three switches will follow suit. Sounds easy enough, right? I installed the Smart App called Smart Lighting. In there I made one rule for each light and it controlled the other three. This leaves me with four rules. Maybe this is my problem and they are feeding back into each other causing all this chaos. How do I set this up so that they work together and not in 4 separate rules that can cause each other to trigger? The way I did it before only allows you to monitor a single switch at a time which is what caused me to make four versions of the rule - one for each switch.
I’m still confused as hell as to what I should be doing before I migrate - does anyone have any tips?
Before clicking the migrate button, can anyone help with the below questions?
-
Should I remove my old presence sensors from classic which are my phone, my wife’s phone, a simulated presence and ST presence sensor (I only use our phones to control home/away SHM states and the simulated sensor for when we have a babysitter)?
-
Will all of my day/night/hello/goodbye etc. etc. routines just transfer over and I won’t need to update my WebCore routines that use these states as condition triggers?
-
What do I need to do to my webcore routines that set SHM status to away etc? Do I need to create virtually switches in the new app, then new app automations that say ‘set scene = away’ when they are switched on, then control these switches with webcore? Is that right?
-
What do I do with my wifes phone (I’m on android she is apple)? Do I need to delete her classic app first, then just invite to the new one from my new app? Do I also need to univite her from the classic app before I do anything?
-
Do I need to delete everything from my old SHM setup? There was talk that if you didn’rt do this SHM would still run in the cloud and you would no longer have any way to stop it as SHM would be disabled - is that still the case?
So many questions (and worry that the architecture I’ve built over the years is just going to die a death at a time when I could really do with out this - as if people haven’t got enough to worry about with COVID-19), so would really appreciate any answers from those that have gone through this. TIA.
3 Likes
Nope - wasn’t dropped. That’s what was holding us up from opening migration to the most complicated tier of users. You can do this through the CLI and custom capabilities/device presentation which abstracts much of the UI metadata generation. We ran into some problems right as we launched migration due to some underlying changes to the device plugin…there was a plugin hotfix late last week and we’re verifying that it got us back to where we need to be with the new functionality. Will keep everyone posted on that thread.
1 Like
Speaking of which, can someone from SmartThings investigate whether this hotfix has anything to do with the new app displaying all temperatures in celsius since last week?
5 Likes
You don’t have to - but you will have to change the old ‘phone’ ones after each device gets upgraded. The babysitter situation is unique because the new presentation of the simulated presence sensor does not allow manual control in NewApp - it’s read only from a UI perspective. So you’ll need something - like a v-switch or a webcore piston to set it present or away.
Routines become a combination of Automations (the triggers / if/then) and Scenes. Unlike Routines, WebCore cannot determine if a NewApp Scene has run. What most of us have been doing is create a virtual switch for each scene that falls in this category and add it to the scene that is executed - turning the switch ‘on’ so instead of:
IF Routine X executes THEN…
is now
IF VSwitchX changes to on THEN… Turn Off VSwitchX and … whatever you did before
Basically yes, see this article as it’s how most seem to be doing it.
https://support.actiontiles.com/knowledge-bases/8/articles/8170-how-to-use-new-smartthings-home-monitor-with-actiontiles
Migrate happens once per location. So do yours first (Manually, automatically, or otherwise) then after you’ve done your phone and then done the dance of replacing your old presence sensor with the newapp equivalent on your phone, login to newapp on her phone and do the presence sensor dance there too. Wash Rinse Repeat.
If you do the migration from SHM to STHM yourself, yes, make sure you clear any notices and remove all the sensors yourself. If you’re going to use the migration tool - it will do this for you.
And IMHO if you do the migration manually by yourself by transitioning the routines, scenes, SHM>STHM and Smart Locks to SmartLocks Guest Access I’d STILL run the migration routine after your done because it seems to permanently mark your location as done, and you wouldn’t want to have your location be out of spec later when you can’t get back into classic and run migration after you’ve uninstalled it and can no longer install it.
4 Likes
Yes, as of today the useful event history is being turned off and replaced with the not-useful version as shown in the comparison images:
3 Likes
Wow, many thanks for taking the time to reply @nathancu - but my word, I can’t believe what I’m reading and the fact I’m going to be forced into this… 
This is a ton of work to fix around my job and family within such a short timescale and for what? Oh yes, the joy of half my devices not responding properly, both of my Samsung Smartcams dying with Smartthings and being lumbered with a significantly less flexible system.
What an utter shower this entire ‘migration’ is…
Samsung should at least push the timescales back into 2021, particularly considering the COVID crisis at the moment, I genuinely can’t think of a worse time to force this onto people (when we’re all relying on our smart homes more than ever), and I can’t believe no-one at Samsung has stood up and said “hang on everyone, perhaps this isn’t the best time to enforce such a dramatic change on our user base?” Honestly… 
5 Likes
I’m on Classic 2.17 and seemingly it still works, I’m avoiding upgrading the old classic app until I have to for exactly this type of reason - Samsung 's last couple of updates have basically been designed to force you away from the Classic app by fair means or foul…
3 Likes
History is still working for me on both 2.17 and 2.19 of the Classic App (I checked when I saw his post). I suspect it’s a back-end change rolling out and it will affect both when it gets applied to your account.
3 Likes
Ugh, more good news… This is just getting tiresome now.
3 Likes