Node-Red looks like it’s way outside my capabilities to configure.
Yes! This is what I do. It does take some technical abilities but certainly no more than if you were to move to Home Assistant!
You can run SmartApps on your Pi, or use something like MQTT or other methods to integrate locally with Edge drivers.
EDIT: To be clear, you’re not simply running existing groovy stuff on your Pi, but rather you are able to implement new or ported SmartApps written in javascript and using the new SDK. OR use any language such as Python to talk directly to an Edge driver. So this gives you a way to implement pretty much anything without SmartThings constraints, but still be perfectly integrated with SmartThings going forward.
There is Homebridge that uses API, not ideal but it works okayish for me
iOS to ST devices are functional - switches, dimmers, locks, and shades.
other direction (motion, contact, and presence sensors, buttons) needs the notifications, which requires running HTTPS server and ST approvals
Also using http requests might be solution for you. I use Node Red and Web Requestor Edge driver to connect Panasonic airpump to SmartThings. Bit of a mix but it works and that’s all that matters.
This may not be the right place to ask, and it may be a dumb question that I just can’t figure out, but after Groovy is gone, and so are the Rboy apps (i.e., LUM), how do we program or change lock codes in our Zwave locks using SmartThings? Thanks.
This tool will be migrated, this info is included in the FAQ page about the platform transition.
Also, I previously mentioned the following:
The team is working on a separate plugin for the SmartLighting app:
- The automation created there will use the Rules engine.
- It will support the mirror feature.
Make sure a tablet ypu buy will run the SmartThings app. Not even all Samsung tablets meet the requirements to operate the SmartThings app. I got burned with that when they did the last big app update.
Sorry, I didn’t reply to your previous comment about this. I already raised this question with the internal team but there’s no feedback yet. I’ll keep you posted.
What do you mean by “contacts” and what happens with Alexa routines? This is to understand the behavior.
Can’t you just install ST APP to Android Emulator, there are many emulators available today.
The virtual switches created in Labs don’t show up in Alexa routines to use as inputs OR outputs (by default).
- To be used as inputs (“when this happens”) in Alexa routines, it has to be a sensor of some kind (temp/motion/contact).
- To use as an output (“action”), you need to go into the Alexa app (under Devices) and change it from a switch to a light. Then you can control it.
At the present time, an Alexa routine (not a smartthings routine, but rather one created in Amazon‘s Alexa app) can only be triggered from a contact sensor, motion sensor, lock, flic button, or echo brand button. It cannot be triggered by a switch of any kind.
https://www.amazon.com/gp/help/customer/display.html?ref_=hp_bc_nav&nodeId=GCCRGDPHL7L9W7TJ
So many people use a virtual device which is both a contact sensor and a switch. Alexa routines can be triggered when the contact sensor opens or closes. And you can use the switch from a smartthings routine or other smartthings automation, or by voice. So the virtual device has both the capability switch and the capability contact sensor. When you turn on the switch, the sensor opens. When you turn off the switch, the sensor closes. This turned out to be a great way to integrate smartthings automations and Alexa routines.
For this reason, most of the community created Edge Driver virtual devices have both a switch and a sensor capability.
See the community FAQ for more details:
FAQ: Can I trigger an Echo Action without Speaking to It?
Use Cases
As far as use cases: using this method, you can take any command that you would speak to an echo device and instead automate it from smartthings. For example, suppose you have a sprinkler system which doesn’t have any integration method with smartthings but which does work with Alexa.
If you create a virtual device which is both a contact sensor and a switch, you can have whatever logic you want on the smartthings side (Check temperature, weather, time of day, whether you are home, whether the pet door is closed, etc.) and use that to create an automation which turns on the switch part of your virtual device in order to trigger an Alexa routine to start the sprinkler.
So Alexa becomes an intermediary between SmartThings and a third-party device which does integrate with Alexa but doesn’t normally have an integration with smartthings. Very useful.
It’s also a good way to create a simple smartthings integration for echo devices, including fire TV devices. And it’s also a popular way to have an echo device make an announcement or play a chime when a door is opened or a particular person arrives home.
Basically almost anything you could say to an echo can instead be added to a smartthings integration via a virtual device of this type.
To trigger an Alexa routine you need a contact sensor, motion sensor, lock, time or voice. You cannot use an ordinary switch.
To get around this Alexa limitation community members have developed virtual switches with contact sensor capabilities. These are some times refered to as simulated Alexa switches.
One of my key uses of Webcore is to control my Ecobee thermostat. I use it to send an instruction, via community custom handler, to set the thermostat to a specific comfort setting when all the motion sensors on a floor register no motion for a while. I think I could handle the motion side easily via a routine, but last time I checked, the stock handler for ST couldn’t set a specific comfort setting. . . .or couldn’t do it choosing till x hours, next schedule, until change. . .or maybe both. Will Ecobee be supported after the transition and does anyone know if I could control the comfort setting and duration? I assume it will be supported since it’s a cloud to cloud connection. I know I could just try out the native connection and swap back if it didn’t work, but getting the custom handler up and running was kind of involved and I haven’t kept it up to date in a long time so wary of tinkering with it if I don’t have to for fear of not being able to make it work again.
I know Ecobee has a similar built in process, but its only after 2 hours, so I wanted to shorten that time and figured I have motion sensors all over so might as well.
If the Device Type displays Placeholder for it in IDE… it will continue to work.
I’m honestly so deep down this ST rabbit hole that I don’t even know where to begin to make sure everything works fine come Sep 30th. I don’t even know if it’s possible.
I’ll end up just waiting for the date and then see what’s working and what’s not. From there, who knows.
Genuinely don’t even know where to begin.
Apologies if this has been discussed elsewhere but when the (automatic) migration of Smart Lighting to routines takes place, will these migrated routines be in addition to the 200 limit (as Smart Lighting is now)?
If not, and the routine count is already at 200 or the addition of Smart Lighting migrated routines breaks this limit, will the migration effectively become a full (or partial) discard?
Or have I missed something around the Smart Lighting status post edge?

I don’t even know where to begin to make sure everything works fine
I think the best place to start solving doubts is the FAQ questions page about the platform transition.
There are different things that will be automatically migrated. This shouldn’t need the intervention of users unless they’re using custom DTHs, please check this post:
If your Zigbee or Z-Wave device is currently backed by a Custom DTH (not published in the ST repo) and you have a replacement community Edge Driver on your hub, ST will migrate those devices for you to the installed community driver (What is highlighted in Option 4 from the FAQs). Please note this will not work for Lan devices. Also, because we don’t know the entirety of the custom DTH was and what it’s replacement driver is, we cannot guarantee the expirence will be exactly the same (as we haven’t reviewed the code of either and it isn’t in our repo). When in this situation, I recommend to please check the name of your preferences between the Customer DTH and the Non SmartThings owned Driver. If they are not the same, preferences will not migrate. I don’t know the previous communicat…
They won’t be converted to Routines, there will be a separate plugin/feature for the SmartLighting app. I provided little more info in this post:
This tool will be migrated, this info is included in the FAQ page about the platform transition. Also, I previously mentioned the following: The team is working on a separate plugin for the SmartLighting app: The automation created there will use the Rules engine. It will support the mirror feature.
Yea I have many custom DTHs so I’ll likely run into issues come Sep 30th.
I have so many automations and so many things interconnected through Alexa etc that my head hurts even thinking about it.
Amen to that. Who has time to reprogram their lives all the time?