I migrated my classic Smartthings into the new Smartthings app and have noticed one thing that I relied on for trouble shooting in the classic app that isn’t in the new app. Detailed history in the classic app. It would tell me what webcore piston, routine, or command triggered what, and various other info. With the new app all it lists is on or off and the time.
The detailed history should have made the port over to the new app. I like being able to look at the detailed history and figure out if something went wrong, or what turned something on or off.
I hope they plan on bringing this over into the new Smartthings app soon.
This is currently a known limitation for the new app. If you feel its an important feature (as a lot of us do) please log a feature request ticket with the official SmartThings support by sending them an email to firstname.lastname@example.org.
Don’t just wait for someone else to do it either, the more feedback we as the community give them through official channels on any given item the more likely it is to make the bar for a change of the product.
People have reported it as a significant missing feature for over a year. Don’t count on “soon”.
(my reports of it are more recent, because I didn’t even try using the “new” app until a few months ago)
As noted here, the data to display this data may not even be available in the APIs the new app is using, so it just might not be possible.
Also, the history the new app displays is created by a back-end service that mirrors the data from one database to another (earlier this year that back-end service was broken, so the history was missing in the new app for a few weeks).
Totally agree with the OP on the best feature of ST Classic which was tracing which Apps used a device, and which event was caused by what part of the system. It is SO frustrating beyond words to troubleshoot now.
However, I am noticing now history issues within devices themselves. For example, I have an ecobee thermostat, and the history does not show all the events that webcore itself even receives. For example, it missed logging two entire heat cycles this morning in my history, and the logging in WC clearly indicated that the events occurred!
I currently have a few different pistons and a routine that can trigger my front porch light. and the light is getting triggered randomly very often. It is a pain to figure out what is triggering this light so I can change the sensitivity or move whichever motion sensor or camera is triggering it so often. It has gotten to a point that I just leave the light on all night long until I get some time off to trouble shoot what’s going on.
Put log statements into your pistons that control it, so you can at least rule out WC.
The only randomness I’ve seen recently is that some of my dimmers seem to turn themselves on at like 2% or so every couple of weeks, and WC sees this as them being on and takes an action. They are old GE Zwave (non-plus) dimmers doing this. I created a WC piston that monitors if any switches come on at <5% and stay on and logs it, as an example, just to trace it, because I only occasionally trip over it looking at device logs.