I’m still getting the dreaded battery drain issue.
how bad?
I wonder if it might be related to the firmware version of the button?
I thought there was a way to see the firmware version of the buttons, but i don’t see it now.
I’m out of the loop on which exact deivce you’re discussing, but I had one Ikea Tradfri dimmer button which would just DEMOLISH 2032 batteries. I’m talking a fresh brand new battery dead in about two days. I spent some time trying to make sense of it and couldn’t - it was on the same firmware as my other buttons which were humming along just fine, closer to my hub with better signal. I tried pairing it to its original Ikea hub, pairing it to a bulb, resetting it 10 times, nothing made a difference. There was no rhyme or reason, so I just labeled it as ‘BAD’ and banished it to the naughty corner.
I had a similar experience with Iris motion sensors a few years back. One device out of ~8 would just eat batteries. In digging through the IDE, the only difference I identified was that this sensor showed a firmware update via ST in its history, while the rest had all (apparently) shipped with the same firmware version. Maybe a bad firmware package on ST’s server, maybe something about the update process - like you, I gave up and tossed that one back in the box.
Like days at best, similar to the post above. 
It could also be what @JDRoberts said about the default wake up interval for edge drivers vs groovy DTH’s
is there the possibility of more than one edge driver per device type?
Yes, multiple drivers can have the same fingerprint.
While SmartThings may be winding down it’s groovy platform, there’s an opensource version of the groovy hub with local processing that’s coming up which should provide API level compatibility for device handlers (DTH’s) and SmartApps. These should run locally and being open source it will allow any and all developers to contribute and build apps/dth’s for it without restrictions
@johnconstantelo @TAustin @orangebucket @JDRoberts @erocm1231 @brbeaird @ygerlovin @mark_cockcroft @philh30 @bendews
If anyone wants to contribute feel free to sign up or message
Very interesting! So the intent here is to create a Pi-based platform to be able to run as-is Groovy DTHs and SmartApps. Do you see this as a semi-permanent solution or a temporary one until those things are ported and available as ‘new platform’ versions?
My first reaction is, if you’re going to go through the trouble of setting this all up, you may has well set up a an environment to run local ‘new platform’ javascript-based SmartApps. The porting from community-written Groovy things should be fairly quick and easy. What’s missing is the local platform to run the new platform stuff. Now that I’ve implemented that myself, my conclusion is that it’s really a ‘packaging’ challenge to make it easy for lots of less technical people to do it. And since once you have an always-on Pi running on your network, the sky is the limit as to what you can do - reproduce all the legacy stuff, plus much more since there are no constraints.
Wow, this would be wonderful! Would it be possible, technically, for this groovy page to be updated to read some routing/signal quality/check-in time data from zigbee/z-wave devices running Edge Drivers? (basically correcting the bug that currently shows Edge Driver devices as ‘placeholder’ and ‘cloud’)
so like an add on hub (raspberry pi ) that will run groovy stuff .
thats groovy.
If you compiled and packaged webCoRE, then name your price, I’m in. 
HA! As @JDRoberts has pointed out elsewhere, there are so many special undocumented hooks into the hold Groovy platform that it wouldn’t be so straightforward. 
is there not a way to convert the groovy smart apps to lua easily ?
why webcore
why not just a pi hosting smart apps that connect to the smartthings hub.
I disagree. It’s very challenging and many of the groovy features/API’s have not been ported to endpoints. It’s something that SmartThings has been promising to bridge the gap for a long time now.
This 
As I mentioned in another thread:
Webcore isn’t just a program written in groovy. It’s a program written to run in the environment of the Samsung-hosted groovy cloud, taking advantage of features and values not all of which were documented and not all of which will be available after the groovy cloud is shut down. The Rules API does not currently have feature parity with Webcore, so there are a lot of things you can do with Webcore that you just can’t yet do with the Rules API.
So just setting up a machine to run groovy and then communicate through the API doesn’t necessarily give you all the functionality you had when the same code ran in the groovy cloud.
I’d love to see somebody succeed at doing this, but if it were simple, it would already exist.
Still I didn’t think @ady624 would succeed in writing Core to begin with, and obviously I was very very wrong on that one. 
This is a very creative and talented community, so who knows? Maybe somebody can make it work.
I should add that thanks to @taustin’s excellent work on an MQTT interface on the new platform, that does open up some additional options, including using MQTT to get to Hubitat (which does run Webcore). But we still run into the issue of the stuff that smartthings does not make available through integrations. Tricky. 
This would be awesome - I’ve already switched all of my automations over, but I believe WebCoRE is one of the most innovative things I’ve ever used with home automation. I did notice I started to lose control of certain devices (Lutron Shades) and never understood that - had to move them over to ST automations many, many months ago. Other than that, WC served me very well.