The End of Groovy Has Arrived

My understanding of this is.

When I want to try another developer’s Edge driver when my device is running on the automatically installed ‘production’ driver, I can simply select the other developer’s Edge driver on the list of available Edge drivers (easy enough).

However, if I then want to switch back to the ‘production’ driver, I will have to REMOVE the device and re-onboard it, correct?

If I have to REMOVE the device to get it back on the ‘production’ driver, then this is the part I really do not care for when it comes to Edge! Why can’t SmartThings just make their ‘production’ drivers available on the list like the SmartThings DTH drivers are in the IDE? That being said, is there a way to change the device’s Edge driver to the SmartThings ‘production’ driver using the new CLI somehow?

  1. The only functionality that should go missing is custom capabilities that don’t map from a custom Groovy DTH to the Edge version. I suspect there aren’t a lot of cases where simple capabilities that Alexa supports like contact, motion, etc. will go missing.
  2. The alexa integration swtiched away from Groovy a while ago. I don’t think changing from Groovy to Edge will re-add the device in Alexa since SmartThings still has the same device ID

One big problem with the SmartThings Alexa integration will be it still doesn’t support multi-component devices. Multi-switches, power strips, etc. will only expose the main switch to Alexa and not the individual ones.

3 Likes

Driver change tool in the app can swap back to the production drivers as well, so long as the production driver is still installed.

4 Likes

Interesting. They said in the Beta thread otherwise.

I just tested this and was able to change a newly connected Edge smartbulb from the default ‘production’ Edge driver to the Beta Edge driver, and then change it back to the Edge ‘production’ driver. The only difference between the two Edge drivers was the ‘version’ information. So maybe SmartThings should consider putting a description on their Edge drivers.

However, if I have only one thing of a certain device type (like say a thermostat), and I’m running the Beta Edge driver or another developer’s driver on it now, then without ever having on-boarded the device natively to get the Edge ‘production’ driver installed on my Hub, I would then need to remove the device and re-onboard it so I could get the ‘production’ driver installed on the Hub then. This only affects devices on-boarded with the Hub before the ‘production’ driver was available for the device then. Got it!

1 Like

Correct. I haven’t seen any way to get a production driver installed except by onboarding a new device that doesn’t match an installed driver. The production drivers don’t even seem to have a channel to enroll in. Hopefully we end up with some way of manually installing those.

6 Likes

That’s what I’ve noticed as well.

I wonder if unenrolling from the SmartThings Edge Beta channel would automatically bring down the Production driver…

To unenroll from a channel, I think you first need to uninstall all of its drivers. You can’t uninstall a driver if it’s in use by any device. I don’t think there’s a workaround there.

1 Like

Is there a place to see all our driver installed on our hub

Is there a place to search on those driver for fingerprints devices to see if we are all set for the migration ?

In the ST app, go to your hub device, hit the three dots in the top right, and select Driver. It will show all of your installed drivers

Or, in the CLI, run smartthings edge:drivers:installed

Not in the ST ecosystem. Your best bet will be to search the driver’s fingerprints.yml file, but that’s only possible if the developer has posted their code somewhere like on GitHub.

Also since you are limited to a total of 200 devices in the ST app and 99 routines in the Alexa app, the virtual switch per button approach to get around this issue can use up a lot of your quota. :disappointed_relieved:

I really hope they fix this issue before September 30th.

1 Like

Maybe I’m just feeling pessimistic this morning, but reading the questions and answers here it feels like SmartThings is going from being the most friendly home automation environment for power users who are not actually programmers to one of the least.

I understand the business necessity for dropping the groovy cloud, and I know there’s hope that Matter will fill in a lot of the gap for WiFi and Thread devices (at least multi button light switches and scene controllers should work out of the box with the voice assistants), but if ST is really going to require that customers have a laptop (for the CLI and the Rules API) and do a lot of work to get a 4 button zwave scene controller working, including working with voice assistants and IFTTT, well…

image

How is that going to match up to the competition? :thinking:

12 Likes

Do you think the CLI would work if an Android device had Linux installed?

I’m not finding it at the moment, but I believe I saw there was a Linux option for installing.

Just don’t know, but had me wondering…

Either way, that wouldn’t be considered so user friendly, I suppose.

Does anyone know if the ikea buttons will work and not drain batteries after Sep 30th?
Particularly the on off button and the 5 button

2 Likes

This is accurate IMO.

This is the interesting part. I think it aligns MORE with their big, corporate competitors. Apple Home, Alexa, etc. It obviously aligns LESS with smaller platforms like Hubitat and Home Assistant. Will be interesting to see in the future if this changes at all in either direction.

4 Likes

I’m using both of those buttons with the Beta drivers created by SmartThings, so they should continue to work very well after September 30th.

1 Like
1 Like

No battery issues? Did you have battery issues prior?

I think it aligns more with the big corporate competitors as far as Matter devices go. Except for not being a matter bridge, we’ll just have to see how that plays out in the marketplace.

But as far as the “works with X” logos other than Matter, I think smartthings has created this huge gap for itself with regard to Z-Wave multicomponent devices.

Apple doesn’t put its “works with” logo on anything that isn’t really easy to add through its official app. Same with Alexa. And Hue.

But Aeotec is a smartthings partner and uses the “works with ST” logo on both zwave and zigbee multicomponent devices and those are going to be really hard to setup through ST to work with voice assistants come October unless they fix the multicomponent issues before then. :thinking:

image

2 Likes

I do not completely agree, or I did not understand well and I explain my situation: I have 6 hue lights connected with their Bridge and I see them in SmartThings I assume with DH. If I now try to add new device and search by hue brand, I still find 6 more double lights and I think these will be the ones managed with edge (maybe). My fear is that on September 30th this will happen by keeping only the new lights and thus losing all the automations connected to the Hue who currently use DH. I hope I was clear (I don’t speak English well, I know and I apologize)

1 Like

When I used those devices with Home Assistant and zigbee2mqtt, I was going through batteries like crazy.

Similarly when I was using the Tradfri Shortcut Button with Hubitat and a community driver, it also went through batteries quickly.

SmartThings with the Zigbee Button Edge driver has been the only platform (other than the Ikea one) where I’m not having battery problems with the on/off button or the 5 button remote.
I’m using a community Edge driver for the Shortcut Button, but also not having battery issues.

2 Likes