You have SmartThings automations that have been running for years. One day, several of them stop working. Your motion-triggered lights do nothing. Your nightly door check does not run. The devices themselves still respond to manual taps in the app, but the automations are silent. The most likely cause: SmartThings migrated your hub’s device drivers from the legacy Groovy framework to the newer Edge framework, and some of your automations did not survive the migration cleanly.
What the Edge migration is
SmartThings has been migrating away from the legacy Groovy-based SmartApp framework to the newer Edge framework that runs locally on the hub. The migration is good for users (faster, more reliable, works without the cloud) but the transition has been disruptive.
The most common breakage: devices that were using a Groovy device handler get migrated to an Edge driver that exposes slightly different capabilities. Automations that referenced the old capabilities silently break because the new driver does not present them.
Identify the affected automations
Open the SmartThings app, go to Routines (the new name for automations). Look for routines with a warning icon or that show “missing condition” or “missing action”.
Each broken routine usually references either a device that no longer exists or a capability that the migrated driver does not expose. Open the routine and look at what is grayed out or marked as unavailable.
The capability mismatch
Old Groovy handlers and new Edge drivers can present different capability sets for the same physical device. Examples:
- A Z-Wave switch may have had an “energy reporting” capability in Groovy that the Edge driver does not expose.
- A Zigbee multi-sensor may have had separate motion, temperature, and humidity entities in Groovy, and the Edge driver presents them as a single combined entity.
- Some custom Groovy handlers had non-standard capabilities that no Edge driver matches.
If your automation depended on a capability the new driver does not present, you have to either find an Edge driver that does (community drivers often exist), or rebuild the automation differently.
Check for community Edge drivers
The SmartThings community has built Edge drivers for many devices that the official drivers do not fully support. Search the SmartThings community forum for your device model. If a community driver exists, install it:
- Find the community driver’s channel invitation link.
- Open the link to subscribe to the channel.
- In the SmartThings app, go to Hub, Driver, browse available drivers.
- Install the community driver.
- Switch your device to use the new driver.
The device’s capabilities will refresh based on the new driver. Verify in the app that the capabilities you need are present.
Rebuild affected automations
For each broken automation:
- Note what it was supposed to do (the trigger, the conditions, the actions).
- Delete the broken automation.
- Rebuild it using the current device capabilities.
- Test by manually triggering the condition.
Sometimes the rebuild is straightforward (the new driver has the same capability, just named differently). Sometimes it requires creative restructuring (using a virtual switch as an intermediary).
The cloud-to-local transition
Automations that previously ran in the SmartThings cloud are now expected to run locally on the hub through Edge. The transition is mostly seamless but introduces a few constraints:
- Automations involving cloud-only services (weather, sunrise, location) still require cloud connectivity.
- Local automations are limited in complexity compared to what was possible in the cloud.
- Certain conditional logic that worked in Groovy SmartApps may not have a direct Edge equivalent.
If your automation hits a constraint, the workaround is often to split it into a simpler local routine plus a cloud-triggered companion.
The race condition trap
Edge drivers execute faster than the old cloud framework. This sometimes exposes race conditions in your automation logic. An automation that previously ran sequentially in the cloud may now run in parallel locally, with actions completing in unexpected orders.
If you notice your automation working differently after the migration (the same trigger produces different results), look for sequencing dependencies. Add explicit Wait steps where needed.
Custom SmartApps
If you used the legacy custom SmartApp framework (Groovy code you wrote or installed from the community), those SmartApps stopped working when the Groovy platform was retired.
For each retired SmartApp, you need to find an Edge equivalent. The community has been porting many popular SmartApps to Edge. Search the forum for the SmartApp name. If a port exists, install it. If not, you have to live without the functionality or rebuild it as a series of routines.
The deleted device problem
If a device was migrated to an Edge driver but later removed (corrupt migration, intentional removal), all automations that referenced it break. The reference to the deleted device shows as “missing” in the routine editor.
To restore: re-add the device using its current Edge driver. The automation may auto-link, or you may need to edit each automation to re-select the device.
Test after migration
After dealing with broken automations, test all of them. The SmartThings app does not auto-detect all migration-related breakages. An automation that looks fine in the editor may still fail at runtime if a subtle capability issue exists.
For each automation, manually trigger its condition (open a door, walk in front of a motion sensor, fast-forward to a scheduled time). Verify the action runs. Fix or rebuild any that fail.
What if your device cannot be migrated cleanly
A small number of devices have no working Edge driver, official or community. For these, the device may be functionally orphaned in SmartThings.
Options:
- Wait for an Edge driver to be developed (some are years late)
- Use the device through a different hub (Hubitat, Home Assistant) that supports it
- Replace with a newer device that has better support
Backups before changes
Before making major changes (installing new drivers, switching device drivers), back up your hub’s configuration through SmartThings if available. If a driver change breaks things, you can revert.
The Edge transition lesson that keeps applying
Even after the initial Edge migration settled, SmartThings continues to retire individual cloud-based handlers over time. An automation that survived the main migration may still break a year later when its specific handler is finally retired. Each breakage feels random because the migration was supposed to be done.
Build a quarterly review habit: open each automation, verify it still works as intended. The first time you catch a silent breakage early enough to fix before it affects you, the habit justifies itself. The broader pattern of routines silently breaking is in our routine recovery guide.
