The End of Groovy Has Arrived

Thank you, now everything is clear. Everything was correct, my attempts to connect new hues just for testing, made me activate the cloud unnecessarily. Thank you

1 Like

Oh my… This means that even if the Smart Lighting replacement is made available to us in Europe (yeah, fat chance, I guess) I still can’t address the buttons on the multitude of multi-channel switches that I have. There’s simply no way I will be able to fit all of my automations into the 200 limit for Routines.

And yet, no one knows why this limit exists. My guess is that it’s because of the mobile app - more routines to be loaded means an even clunkier app, but there could have been so many ways to avoid that.


Thank you @nayelyz
Obviously if we can know the plans as soon as possible it would help people make their decisions regarding Sharptools, IFTTT etc, or jumping to Hubitat to continue to use webcore.



I just did exactly what you described mate, sorry.
What driver was it you installed?

Hi @nayelyz

I don’t want to bug you but since I am testing - with some successes and some failures, I want to ask you for a clear answer on this one:

If a device has always been added for me from a stock DTH, and I have always used the stock DTH without any problem, is that device still going to work?

I am concerned about a specific device (though am afraid there could be others) which I use to control 12 of my blinds, a Philio Pan-08 which always worked with the Z-Wave Window Shade stock DTH.

My question is not about this single device, though. My question is whether we should expect **any ** device that used to include in the Zwave network with a stock DTH (and worked flawlessly without intervention) to continue being supported post 30 September.

What then do we do if the fingerprint of that device is not found in any of your fingerprint.yml files please? Looking forward to receiving your response to this.

1 Like

Probably “very little”, and “none at all”, no matter how unprepared this all seems, and no matter how much of a setback this overall change is for power users.


I’m the author of the edge harmony hub plugin, I want to support multiple hubs but i don’t currently have that setup myself.

I’m looking for volunteers to test an experimental version that supports multiple harmony hubs (connected to the same st hub), please head over to [EDGE DEVICE] Simple Harmony Bridge **Alpha Testing** - #48 by lmullineux to see if you can help. If you can, drop me a message.


Hi, @Shanapadila

Thanks for reporting this issue. Let us take a look at it. We will let you know as soon as we have an update.

Hi, @mzp
What @orangebucket is saying here is correct.

I’ve read some of this thread, not all.
What I have taken from it is that devices using custom th may or may not work post groovy shutdown.
Am I right in saying that to establish compatibility I need to look in the groovy ide and the device details listed against the device, then search for these in a fingerprints file for the appropriate standard edge driver.

  • application: 44
  • endpointId: 01
  • manufacturer: _TZ3000_dx5pruwr
  • model: TS0012
  • onOff: catchall
  • zigbeeNodeType: SLEEPY_END_DEVICE

If I can find it that means the device won’t work post groovy shutdown?

Surely there ought to be a tool to trawl through your devices and report those which will migrate, those that won’t, and those which will be less functional… eg multi switches where only the master switch is controllable from Alexa?

In the example above should I be looking in

If so I can’t find it, does this mean my multi switch won’t work on edge?


I agree, it’s much too difficult right now to find candidate edge drivers.

We’ve started a table in the community-created wiki so people can add entries there to make it easier for others. But it’s going to take a lot of community participation to build this up to where it’s really useful.

If smartthings comes up with an official tool, or online list instead, that would be great.


That’s the step I was missing. Once I deleted the DTH it paired up properly using the edge driver. Thanks!


Sadly, you are right. Samsung TNT’ing a product is an every other day event.

FWIW The “power users” aren’t the problem, it is the user who bought a device/had-a-need, and then copy/pasted their solution into place. They haven’t given the issue a second thought, but have been relying on their solution.

Recommending SmartThings has been a no-brainer for me when people have asked home automation and wanted something flexible.

Oh well, it pretty much now comes down to, “Do you have an iPhone? Buy an AppleTV and use Homekit. Are you after lights? Buy Hue. Do you have an Android device? If you use Alexa, go with that… otherwise? Don’t bother with anything unless you are willing to throw the device away <3 years.”


Not sure it is editable @JDRoberts - or I could not find how.

It should be editable by anyone. :thinking:

  1. If you don’t already have an account on the wiki, request one on the homepage. You will have to wait to get an approved email.

  1. once you have an account, log in and then go to the page you want to edit.

  2. choose the “edit” tab.

Well, here’s one stock Edge driver that didn’t work well for me: I had a perfectly functioning Aeotec Nano Dimmer, and I excluded and re-included it after installing the Zwave Switch Edge driver in the Beta. It was correctly included as an Edge device. Started testing, and the lights seem to flicker, a lot… Especially when dimming up or down. I don’t mean a little - this was a very noticeable flicker like the light was going to near maximum and near minimum intensity very rapidly. I then used the Edge drivers sent to me by Aeotec - whilst testing their Shutter switch, as it was in the same channel. The code, I believe, is the same except that Aeotec has added all the parameters supported by their switch. The result, however, is still the same. The flickering is very obvious and annoying. Sometimes it keeps going on even when you are not dimming up or down - and to get rid of it you might need to completely dim up to 100%. My conclusion, though I cannot prove it, is that the Edge driver, upon loading, changed one of the many parameters supported by the switch which resulted in this extreme change in behaviour.

This morning (about 36 hours later), I woke up to find the Dimmer offline. I have no idea how or why that happened, but the Dimmer is now completely unreachable from Smartthings, and turning on or off from the switch manually has zero effect on Smartthings.

So - yes, something wrong with that one I believe.

I will exclude it and re-include it once again to see what happens. If anyone has any input on this one, please let me know. Also - it is still not clear to me where to report any bugs or flaws during this beta stage.

Ok, yes, I didn’t get an account, hence not seeing the Edit. Will do…

1 Like

Would this be a good summary of the rules for migration of Z-Wave and ZigBee devices as we understand it? Listed in order of priority for evaluating how to migrate devices.

Driver Before MIgration After Migration Notes
Edge no change Migration process skips any device already backed by Edge driver.
Built-in “local” Driver Edge Edge drivers are being provided 1:1 for existing built in hub drivers.
Custom DTH Edge If custom Edge driver already installed that matches fingerprint
Custom DTH Edge Fallback to “base” driver that matches fingerprint
Custom DTH Edge Fallback to “base” driver based on capabilities (ie, switch type device to use Edge based Switch driver)
Custom DTH Edge “Thing” If all else fails, switch to Edge based “Thing” driver.

You can view the parameter settings for a device using a groovy DTH via the groovy Zwave Tweaker.

You can view the parameter settings for a zwave device using an Edge Driver using @Mariano_Colmenarejo ’s new zwave configuration edge driver if the original driver doesn’t expose them.

In both cases you temporarily have the device use the reporting version, then switch it back to its regular for everyday use.

What you are seeing could be caused by a parameter setting change, or by too frequent polling. :thinking: