I pretty much remember reading something about Edge drivers being able to be installed from the CLI. This involves creating a channel and then selecting a LUA package (directory of source) which I guess means it is first uploaded to ST cloud:
smartthings edge:drivers:package [path_to_dir]
and then back down to your hub:
smartthings edge:drivers:install [ID]
So if the dev supplies the source, you could examine it before going through this process to install it?
Sure if some dev just wants to share their code, you can create your own channel and use it that way. But then you donât get automatic updates, and I donât think most devs are doing that.
A lot of developers have welcomed the change because it gives them a way to get compensated for all the hours theyâve put in. But there are always some who are open source all the way.
Ok⌠I guess I get it. They designed it purposefully to be opaque so devs no longer need to share their code, hence making their work more profitable if they so desire. But they take NO responsibility for vetting that opaque code! Way to go SmartThings!
Both iOS and Android app stores vets submitted apps. Both may be more effective than the other under different circumstances, but both make the effort. Due to the channel dist process, SmartThings has the SOURCE CODE (which is way more than Apple or Android has), but theyâre too lazy to vet any of it?!
Plus if I have/wrote the source, why is the whole cloud thing even necessary then? Why canât the CLI just do the compile and install. Way too many pieces of junk here⌠possibly the worst UX I have seen in recent years (decades in fact) for drivers and rules⌠it all just wreaks of laziness. I wonder if it will get better, but my money is on it just continues to get worse.
Sorry for the rant⌠weâll soon see whether ST is worth keeping (but it is Samsung, and theyâve shown the middle finger to their customers way too often).
There is an entire framework that the driver compiles against that the CLI does not have or need. A driver is just a small component of the whole system. Youâre not building an entire hub image. Youâre uploading a sandboxed element that will be linked against the rest of the world at a later stage.
Iâm not sure i get the outrage against community drivers. If you donât like the model (canât read the code, worried about bad actors, want Samsung have an acceptance process, whatever the case) then donât use community drivers. Theyâre optional. If thats the case and the stock/supported/clean drivers wonât cover your devices at this stage, its time to switch platforms. Life goes on.
My outrage is due to a platform that was founded on open source now being closed. I get that some devs want money for their contributions⌠thatâs ok, provided they take responsibility for their code. Sadly, that is not the case here (or doesnât seem to be).
For community members that want to donate their work, bless them⌠but Iâd like to look at their code before installing it. What ensured SmartThings current success WAS the community⌠and members sharing code that could be used/leveraged by other members. That is all gone now.
Understandable. I look at Edge as a new platform utilizing the existing hardware. With cloud dependency you canât run the old platform unfortunately but thats no different than any other.
| DTH | Edge | |
|---|---|---|
| Maintentance | Web portal (IDE) | CLI on local computers / API |
| Language | Groovy | lua |
| Community Drivers | IDE source with optional GitHub sync | Subscription/Channel model with forced update |
| SmartApps | Groovy based, hosted for free in SmartThings cloud | API connected (create in any language) but no hosting provided |
| Local processing | limited to âbuilt inâ drivers only | All installed drivers run local |
| Local protocols supported | Zwave, Zigbee, a few specific LAN integrations | Zwave, Zigbee, LAN, WiFi via Matter, Thread via Matter, MQTT via custom Edge Driver and local server |
| Support costs | Free | Free |
| Lifecycle | 2013 - 2023 (estimated) | 2020 and beyond |
| Hardware | V1, V2, V3 hubs | V2, V3 hubs |
I, for one, welcome our new Edge overlords.
Iâve been with ST from the very beginning, and I also welcome the change, even though itâs been a little rough. Change can be a little hard to deal with , but Iâm good with itâŚ
I would add local protocols:
DTH
Zwave, Zigbee, a few specific LAN integrations
Edge
Zwave, Zigbee, LAN, WiFi via Matter, Thread via Matter, MQTT via custom Edge Driver and local server
Can anyone tell me how to determine a deviceâs fingerprint after it has been converted to using an edge driver? Perhaps via the CLI?
I just realized that I might need this info for some of my devices after the transition (to find a working alternate edge driver, for example), but it is only reported in the IDE for devices with a legacy DTH installed.
Yep. The âdevicesâ command will show you the details, including fingerprint data.
smartthings devices <num> -y
Use without <num> and -y to get the list of devices by number.
For example, this Zigbee device shows the manufacturer name and model used as the fingerprint for this device:
Zwave device showing the MSR used for a fingerprint:
Has anyone seen an answer to this? Assuming there is no replacement, anyone have a suggestion on where I can get half decent free brightness info I could build into my routines? Sans that, whatâs a decent not overly high priced device I could try and use? My fear on a device is it will be impacted by the lights turning on wherever I place it (unless outside and I imagine a weather resistant one is even more expensive) and off in what ever room it is in. For a single room that would be fine, but I really want ambient light outside so I can build automations in different rooms off of it.
If a developer submits a device/driver for WWST certification it is inspected and tested.
Does the documentation of how the WWST certification process working available publicly? And of course the Terms and Services agreement?
Once I asked about it, but it wasnât publicly available. And support for any reason was not giving out for project management purposes to calculate with required times⌠
Rate limitsâŚ
The drivers cannot communicate outside of the network as I understand.
You need a man-in-the-middle, like a RaspberryPi running some code for the driver. But then why waste effort with the driverâŚ
Same as the previous one.
This is the most plausible use case.
I think this would fall under the previous category. But still plausibleâŚ
Thanks @jody.albritton!
It is nice to have it finally publicly available. What would be more amazing if those documentation pages would have a revision date and a list of changes of each revision, like Wiki pages usually do. Just to be transparent on the subject
Otherwise has this changed as well?
Due to the constant changes that the platform is experiencing, Certification Team is only accepting fingerprint updates on top of the already published DTHs.
(post deleted by author)
Very good question, but off topic here. Please start your own topic in the following section of the forum and someone should be able to help you there:
I Have the very first smarthings hub⌠will it work with this new edge migration? or do i need to buy a new one?
What country are you in? 
and whatâs the model number of the hub? (It should be on a sticker on the bottom.)
The very first SmartThings hub, the V1 in the US, was discontinued last year and doesnât work with the SmartThings app any more, old or new architecture. So if you have a never-used one sitting in a box somewhere, youâre out of luck. It wonât work now and it wonât work in the future.
The first hub for the UK was the same as the V2 in the US. It should work fine with these changes.
Hereâs the thread that discusses the hardware requirements for the new platform.