Get ready to make the switch!

regarding Smart Lighting, and since I love to give my $0.02 (or more), I’d do the following:

  1. Migrate the existing automation creator in the new app to use the Rules API on the backend
  2. Get rules API running locally
  3. Migration tool to convert Smart Lighting installs to Automations

optional, but highly requested:
step 2a) get more devices, including custom DTH, running locally

4 Likes

Hello.
I hope you are doing well
I personally use the “Smappee” energy monitor that used to be on marketplace (Classic ST App) and after contacting smartthings support team, they told me that my energy meter is not officially supported by New ST App

What does it mean?
should I throw away my energy meter and purchase a new one that it’s supported by New SmartThings App?

emphasis added

Just a reminder that the rules API itself cannot be a substitute for smart lighting, because it’s not palatable for nontechies.

I know that’s not what @Automated_House meant, but I just wanted to call that out in the discussion.

The Rules API Might eventually be a replacement for WebCore, that’s a different user base. :sunglasses:

1 Like

You’ll get what you are given so stop dreaming

From the local processing help article:

Smart Home Monitor and Smart Lights are Automations that allow you to configure “child Automations” with the ability to run locally. The SmartThings Home Monitor “child Automations” that can run locally include Alert with Lights, Alert with Sirens, Close Valves (for Leaks), and Unlock doors (for Smoke). SmartThings Home Monitor and Smart Lights are the only Automations with local processing capabilities at this time. We are working on additional local Automation options.

Additionally, mode changes cannot process locally. Using this as a trigger for Smart Lights will prevent the automations from performing without an active internet connection. Use a different trigger, such as At a specific time instead to ensure your Automations can run locally.

One thing that strikes me as odd in that quote is the interchangeable use of “Smart Home Monitor” (SHM) and “SmartThings Home Monitor” (STHM). Perhaps just a typo though?

2 Likes

Almost all of my devices have custom decide handlers with custom smartapps that work with them. If I migrate over using the built in device handlers and things don’t work, can I remigrate over with my custom ones?

I’d like to give the built in ones a chance, but I don’t want to risk it if it could leave me in a broken state without a way to recover.

You can login to NewApp without ‘migrating’ and kick the tires and see how it works/looks/feels. Highly recommend. Just don’t setup STHM or setup presence on both classic and newapp on the same mobile device at the same time.

Migration is a very specific action that makes changes to your location.

1 Like

I think someone updated the support articles and went a little crazy with SHM vs STHM find/replace. STHM doesn’t have child automations nor does it have a concept of child automations for Alert With Lights, etc. Those are legacy Groovy SHM terms.

3 Likes

If SHM automations that ran locally have been converted by the migration tool to STHM automations that do not run locally, that is critical Information for customers to receive since both features are billed as “security“ systems.

5 Likes

I spent a good while trying to wrap my head around the new rule API and it is NOT for me. I’m pretty darn techie but you have to be an outright geek to get a handle on the new rule API while webCoRE, IMHO, can be figured out by most non geeks.

3 Likes

Speaking of security, although I love the custom App “Alarm Server” running on a PI, I really don’t need all of its offerings. I just need to be able to Arm/Disarm the Stay or Away Panels which I can currently do in the New App. Is it safe to say that if something is working now in the New App and is running off of custom code, it will continue to work, after September 8, until “Groovy” is completely retired?

Classic App

New App

I also still have access to my DSC Sensors as well.

Yes. Thats a safe assumption. Actually AlarmServer is closer to thier future paradigm than most because the heavy lifting is off the ST platform. All they need to update is the custom device presentation when the CLI beta finishes (note one of the devs there is already working on a custom ‘stay’ and ‘away’ panel) and move the smartapp control code to the Pi. Id suspect this ome gets updated sooner than most because od how active its dev community is.

1 Like

I’m pretty sure they intend the new Rules API to just be the back-end. They certainly don’t expect users to interact with it by POSTing JSON (at least, I hope not!). In the end, webCoRE will hopefully just be a front-end for the Rules API.

5 Likes

I’m not personally familiar with Smappee (but it looks like a pretty cool set of devices and services). Two options, if their devices can connect to an ST hub, then you can write a DTH using capabilities supported by the new app and get it to work that way. If it requires a connection to their cloud, either you or they could integrate through an ST Schema integration. If the latter, I’d recommend asking them to get in touch with our Works with SmartThings team for help with the integration.

This. Please don’t do this. One or the other for STHM/SHM and presence. I intentionally did this at my home as part of the dogfooding for migration and it was not fun…I’m amazed I’m still married. :slight_smile:

3 Likes

Support is already updating this article to ensure it’s clear which smartapp is being referred to. Thanks for the catch @joshua_lyon

3 Likes

It’s alarming to hear an ST staff member had to inconvenience their family members with beta testing, I thought that’s what ST end users were for?

6 Likes

It’s actually why we work at SmartThings - because we’re really passionate about the platform and making it better and don’t mind intentionally borking some of our own stuff if it helps out our users.

6 Likes

Then please show how passionate you are by providing full, clear, complete, concise, working instructions for the community devs to be able to port over our apps, at the moment they are stuck, and waiting for the custom capabilities to work! And they still don’t work.

4 Likes

Yes - I’d generally encourage you to stick with the ST Approved DTHs unless there’s a specific reason to use a community DTH as a number of the Approved DTHs run locally and we’ll be able to help you out more easily if you run into issues. You can always swap back and forth using the IDE. (For those about to chime in about the IDE going away, there will be a way to do this when the IDE eventually goes away).