I agree 100%. I’m having issues getting some of the logic working correctly with some of the automations. It’s definitely very clunky and not nearly as intuitive as in the Classic App.
The ‘while stuff happens’ or if ‘a button is pressed’ or ‘changes state’ or any various permutation subset of the rules in the Classic App would be very helpful going forward.
Once you get it installed in the Classic app, you can use it in the new app. In Automations > If > Add Condition > Device Status (not member location)
If you installed it through IDE, you may want to remove everything you installed in IDE (DTH & smartapp) and go to the Classic app and install it through marketplace > SmartApps > social
Sure, but I’m adding to the list for the dev’s that once again the Classic App is required for basic functionality of many users workflows.
Hello @rontalley,
So - another option when replacing devices
Let’s suppose you are replacing “Window Sensor”
Of course, this won’t work w/ new version, unless they update it to see the SmartApp list for each device.
Anyhow, just sharing a technique that’s worked really well for me.
Best,
Alec
This is what I do but I use screenshot to make it even easier to bounce between windows. However, the point is, this is why we need that function in the New App!
True! Replacement is going to be such a pain otherwise!
Yes you will eventually see a notice in the Classic app regardless.
Thank you Brad !
I found a bug in the history feed.
This bug is being seen on a Galaxy S7 running Android 8 and a Samsung Tab A running Android 9.
If you unselect any device(s) in the “hide or unhide” list then the entire list fails to populate. At this time, the history feed is all or nothing, you can’t set specific devices to populate the feed.
That’s just nature’s (Samsung’s) way of telling you to use Action Tiles! 
Mine is only showing Wattage and KWH. There is no amps or volts or a way to reset the meter. Suggestions?
Too late. I have it on 3 tablets in the house. Been a beta tester for a long time. Love it.
That’s correct behavior for the new app, for now.
For now you can’t do that in the new app. You can still do it via Classic, or a SmartApp like my reset manager (schedules a reset):
I may be missing something, but I’m getting mixed messages. On hand I see that existing (groovy) custom apps will generally work with the new app. But on the other hand, when I follow the links to documentation, the new developer portal seems to very much non-groovy oriented. I can’t seem to find the “Custom UI Metadata” referenced in the FAQ.
I’m having trouble finding basic information on what I need to change in custom handlers to avoid screens like the one below.It seems like an issue with this being a “virtual” door, but I have no clue what needs to change. It sounds like this is part of the new documentation that’s coming, but I don’t know where exactly to find that, either.
See comment from blake.arnold above
I give up. I tried my best to make the switch to the new App, but the conversion from Routines to Automations/Scenes just isn’t possible with all of the rules (or lack of); especially with Smart Home Monitor, presence status, alarm system switches, and other automations.
@fightingmajor - I’m in the same boat as you. Back to Classic and I’ll just wait for them to add in the ruleset for the new app (hopefully) that will allow us to cutover gracefully (and not this hodge-podge workaround with virtual switches and the like).
So I made the switch but had to use webcore to do it. (never used it before). Everyone is saying they can not get webcore to work with STHM and I had no problems with it. So I wanted to show what I did.
In the new smartthings app I made 3 automations, If (Night, Home or Away) change the security mode to the same. So I have one that states if mode is night then change security to night. Makes sense right?
Then in webcore in my Good night routine I made it so it sets the location mode to night. This then triggers my STHM to turn the security to night. My good morning changes it to Home etc.
This has been working flawlessly to have webcore work with the new smartthings app and the new STHM.
Hope this helps.
Technically, Webcore is not controlling STHM. You are using it to control Location which in turn using Automations to control STHM. It has been mentioned a few times as a work-around 
WebCoRE → manage location → automation to manage STHM
Or
Use Automation to do both.
Choice is good!
I had to use 6 automations. I had to add automations so that if I changed alarm mode from the dashboard, then the alarm mode would also change the location mode to match.
The problem with doing this is that while there are some STHM changes that can/could be directly linked to location modes there are times that it doesn’t make sense.
For example… If I wake up in the middle of the night and need to let one of the dogs out… I don’t necessarily want the STHM to stay armed (stay) so I have processes in place to disable the STHM however the home will stay in my sleeping location mode until in the morning.
I’m actually doing something similar to what others have done as well in that I have created virtual switches and have automatons to turn on and off these switches that also control the STHM modes.
I am still doing a lot of my STHM mode changes with WebCore but I’m also still using legacy routines and can control the virtual STHM mode switches.
