Preview | SmartThings-managed Edge Device Drivers

Just got a hub firmware update (000.040.00003).

Are there Edge-related updates in this? Can anyone provide details?

Thanks.

Nothing posted yet here Hub Firmware Release Notes - SmartThings Community

What hub type do you have?

hub v2, US customer Rev E

weird, maybe you’re on a special list since you were part of Edge Alpha testing?

A post was merged into an existing topic: [ST Edge] Change Driver Tool in the ST App

A post was split to a new topic: [ST Edge] Issues with the Zigbee motion driver

Is it me or is anybody else worried about the fact that there is no CONVERT tool for legacy Groovy DTH’s and SmartApps. Why is there so much attention of going toward the shiny new (even if performant) when the old faithful, open source, and MANY contributions is being abandoned. I hope that the Samsung acquisition wasn’t the death of this open platform. I just got wind of Groovy/IDE being sunset/deprecated and it scares the you know what out of me. This is multiple years of developing code for myself and the community going down the tubes. It pushes me toward jumping ship onto a hub where the platform is not pulled from under me after hundreds of hours of dedication. Please consider customers and our best interests which consists for a CONVERTER of some sort which prevents the nail on the Groovy coffin. I work for a software company that has done this many times (by really smart people) and we all know anything is possible in computing. Any way to get some attention from Samsung on my point? Just a sad few days for me as I rely on this platform and my extensive code library.

2 Likes

I am fairly relaxed about things. I’ve only been using SmartThings about three and a half years but I’ve been aware from day one that the legacy platform was going. Indeed the worry was that the new platform had an app with near zero functionality and it offered absolutely nothing to community developers at all. Fortunately my phone couldn’t run the new app as if it could I wouldn’t have used SmartThings at all simply because it couldn’t do anything. However the legacy ecosystem, though obviously not really fit for purpose, tided me over until the new ecosystem could be pointed in the right direction, so by the time I replaced my phone a couple of years ago it was possible to start bailing out of legacy.

2 Likes

I’m not sure why this is so often mentioned. This acquisition happened over 7 years ago. It’s certainly changed the direction of what SmartThings is and has grown to be, but it’s not been “the death of this open platform”.

That said, while I still run my SmartThings hub, all of my important home automation is run on a different hub platform (that focuses on local-execution) . The current SmartThings infrastructure is too unreliable and slow, and the newly emerging infrastructure has lots of teething to go through before it will even come close to being a suitable replacement. But eventually I hope their new architecture becomes a solid alternative.

2 Likes

I think many people are apprehensive, but the Samsung acquisition was seven years ago, and isn’t the cause of this current transition. In some ways, smartthings is the victim of its own success, as the groovy platform just doesn’t scale sufficiently for what is needed in 2021 and going forward.

Edge drivers have some really significant advantages over the groovy cloud, the most obvious being that they’ll run locally.

As far as a conversion tool, we don’t really have any idea what will or won’t be provided. :thinking: We’re still in the developers stage of the beta, not even to the consumer stage of the beta. It’s quite likely that for most of the existing stock DTHs there will be a pretty seamless transition to edge drivers.

Custom DTH is an entirely different issue, particularly since we’re going from one language (groovy) to a different one (LUA), but it’s also possible, although not yet promised, that the new stock edge drivers will have more features and remove much of the need for custom DTHs. And matter compatibility may also help.

Meanwhile, there are quite a few community members who have begun writing their own custom edge drivers, mostly for devices where the beta does not yet offer anything. You can find these from the quick browse lists in the community – created wiki if you’re interested in looking at some:

How to Quick Browse the Community-Created SmartApps Forum Section - Things That Are Smart Wiki

So, yes, there are a lot of uncertainties and, yes, smartthings doesn’t have a great history of enabling migration. But I am feeling mildly optimistic. :sunglasses:

1 Like

@orangebucket, @jlv and @JDRoberts thanks for weighing in!

I just keep reading that end of 2021 is the death of Groovy DTH and SmartApps. Just so I’m clear as to what my “custom” needs are and ST handles it like a champ. I have water sensors and light sensors (Xioami Aqara zigbee, which are awesome). I need to know if water or light has NOT come on for X number of hours with a notification. ST has been rock solid for my needs and my SmartApp has a little report showing me last water & last visible light for all sensors I flag as monitored. I can’t stress how easy it was to build in Groovy and how there is zero maintenance of it — just friggin works. Migrating to new ST App had zero negative effect on this functionality.

@orangebucket completely agreed and I have been using Home Assistant and the stuff I need is easily done there with automations or even custom Python (using AppDaemon) if I wanted to go that route. However, managing those configurations at 5 places where I need them is an extreme pain. ST has been awesome for my specific needs.

@jlv I realize how long ago the acquisition happened but the demise is about to happen and if I keep my mouth (well keyboard :slight_smile:) shut, I’ll just be victim to losing the platform that I love and have invested a lot in. I understand that local execution is great but like I said above, rock solid DTH and SmartApp for my need.

@JDRoberts been reading your comments for years, nice to get a response from you! I certainly can understand the scalability aspect. I just wish there was more of a desire not to piss of customers that bought into the platform due to the open aspect. I also see your point that it’s so beta that end of 2021 that I keep seeing everywhere is likely not going to happen anyway. Place I work for wrote a converter from old UNIX Informix 4GL code to C++ for Windows compilation and yes the dude that wrote it spent hundreds of hours and worked at JPL/NASA for years :slight_smile: so pretty damn smart, to say the least. We all know Samsung can hire 10 guys like that to make the conversion happen — if there was enough desire on their end to keep/satisfy legacy customers. I hope that actually happens… or even better have a “run legacy Groovy” ability for folks — don’t kill Groovy though.

All in all I should receive my Hubitat in a few days and have no choice but to research other platforms especially ones that can easily take my current code and specific need, which I described above. Again, I love Home Assistant but it does take more maintenance in the 5 places where I need it.

2 Likes

Its not so much the coding conversion but the testing in “production” environments. Each conversion would require aquiring, debugging and testing each and every device (with different firmwares, etc) is a pretty difficult task, esp for products you don’t have any control over. Never mind all the various implementations people have them in. And as they are no longer in the hardware business, they have to justify those costs with corresponding sales numbers ($0 for other companies products)…

I too purchased a Hubitat last year but so far have not felt it reached the level of sunsetting my ST implementations. ST has a high WAF for me. I’d be interested in hearing your thoughts after you get it up and running.

2 Likes

One observation, unlike the previous groovy dth, where codes are shared and easy for people to learn and customized, the Edge DHT work like a close source project, where people doesn’t share their code, that in a way make the adoption / migration slower.

They don’t have to be, you can post them on git hub. But I agree they should be open source by design.
Closed source drivers means someone could design malicious code.

There are many many more people who are missing out on custom drivers because it involves copy/pasting custom code today. Being able to subscribe and click to install will make it easier for end users to install custom drivers.

Only install drivers from companies or developers you trust. Even with open source, unless an individual/group is reviewing the code, then you can get malware.

2 Likes

How are users going to change to use Edge drivers when Groovy stops working? Will you swap our devices from using DTH’s to Edge drivers automatically, or will we have to manually uninstall and reinstall each device individually?

Right now the beta is focused on developers and building edge drivers. There will be a separate announcement regarding migration/transition at a later date.

4 Likes

Many of us on here not only read, but modified code to suit our own needs.
I can’t help but feel that ‘closed source by default’ is a step backwards.
It should be open source by default, with the option for commercial operations to distribute closed source code.

2 Likes

We are making our drivers available here:

and here

Given that we are no longer hosting the code for community Edge Drivers it is up to each developer as to how they store their code.

4 Likes

My biggest concern about the new Edge platform is, with everyone rushing to just get their driver out, we’ll get a bunch of plain vanilla drivers that lack thoughtful capabilities that make the platform useful.

See my post today regarding changes made to ecobee which deprecated some very desirable capabilities that created a great automation ecosystem with ST and Classic.

3 Likes