Preview | SmartThings-managed Edge Device Drivers

@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

Once you are installing the code by subscribing to someone else’s channel, there’s no way to know for sure what’s in it, just like downloading an app from an App Store. you have to trust the persons reputation.

The only way around this is if the person makes the code available and you put it into your own channel. But that’s a lot more work than most customers want to do.

So I think closed by default is how most people get most software. Like over 90% of phone apps. You may prefer the other way, but I don’t see anything unusual in smartthings having that architecture. FWIW…

Edge is not for C2C integration such as ecobee. Edge is for devices that are paired to SmartThings with protocols such as zwave and zigbee…

2 Likes

Hi Caleb, Can you fix my account too?

I’m still just getting the spinning icon after clearing cache, and trying the incognito window.

Thank you!

@caleb.varberg

If you’re trying right now, AWS is having some issues impacting samsung login to driver channels
Https://status.smartthings.com

I added the driver for the vent (Keen) but when I paired them they did not pair with the driver.

Does your device’s manudacturer and model corresponds to the ones of this fingerprint?

- id: "keen/sv01-610-mp-1.1"
    deviceLabel: Keen Home Vent
    manufacturer: Keen Home Inc
    model: SV01-610-MP-1.1
    deviceProfileName: vent-profile-1

Nope. Didn’t think to check that. Here is what I have.

SV01-410-MP-1.0
SV02-410-MP-1.2
SV02-410-MP-1.3
SV01-410-MP-1.5

Yeah there’s a whole host of IDs the Keen vents show up as - depending on which version the vent is. AFAIK they’re all functionally identical. How do we get multiple fingerprints added?

Wonder what they’re going to do about Peanut plugs. Half the time they don’t properly respond with an ID when queried.

Edit - just checked mine - they’re all ‘SV01-612-MP-1.1’ units. I’ve also seen ‘611’ variants in the wild as well. Also, from what I’ve seen in researching the issue (had to do this research to make mine work with Homeassistant - Zigbee2MQTT didn’t recognize mine either.) when you see 1.x it is a fair assumption that you also need all ids that include integers between .0 and .x

So while they have: SV01-610-MP-1.1
THey also need:
SV01-610-MP-1.0
SV02-610-MP-1.0
SV02-610-MP-1.1
SV01-410-MP-1.0
SV02-410-MP-1.0
SV01-410-MP-1.1
SV02-410-MP-1.1
SV01-410-MP-1.2
SV02-410-MP-1.2
SV01-410-MP-1.3
SV02-410-MP-1.3
SV01-410-MP-1.4
SV02-410-MP-1.4
SV01-410-MP-1.5
SV02-410-MP-1.5
etc.

I have not seen any difference in functionality. The newer versions will indicate when the signal is weak, or if it is disconnected, with a double flashing yellow light.

A post was split to a new topic: [ST Edge] Ïssue with the Zigbee Power Meter driver