Update: OK I need put a prominent clarification here. Since writing this reply I have realised that the original post in this project does indeed wrap the Rules API running locally up as part of SmartThings Edge along with the Edge Device Drivers. However everywhere else Edge only seems to be used in the context of Edge Device Drivers.
Nothing needs setting up.
No. Edge is purely for integrating hub connected devices. It replaces the Groovy DTH.
While in beta āstockā drivers can be installed in the same way as community developed ones. Eventually they will be installed transparently to the user as stock DTHs currently are.
See next ā¦
Edge is purely for hub connected device integrations.
You are thinking more generally of the shutdown of the legacy platform which webCoRE runs on.
The Rules API should eventually be able to implement many of the webCoRE capabilities. Whether there will be a migration path isnāt clear. It was once suggested there would be a migration tool of sorts but plans may have changed. I see differences in the way webCoRE and Rules behave so I will be pleasantly surprised if there is one.
WebCoRE is an independently developed app that is still in beta and hasnāt seen significant development for years now. The webCoRE community donāt seem to have been proactive in preparing for the sunset of the legacy platform. Rather they seem to be relying on SmartThings to dig them out of a hole.
Any stock handlers running locally can continue as they are as they are part of the hub firmware. Whether they actually do is up to ST.
Presumably any other stock devices will be replaced by Edge drivers.
Devices with custom handlers will need replacing with Edge drivers.
I canāt answer that for you.
No because that is the latest hub.
Not really. The IDE was itself a development environment.
Iām not a developer, nor an advanced user. Iāve been seeing a lot of threads referring to development and eventual migration to SmartThings Edge, and have a question. As a user, once the migration to SmartThings Edge has happened, will there be any benefits, enhancements, or new features for me as a user?
All of your hub connected devices will be running locally which might show itself as sharper performance and may also be of benefit should your home internet connection fail occasionally.
If you wish to use community written device drivers, either because a device isnāt supported by stock drivers or a community drivers does something a bit different, you will able to do so as an end user using simple web pages to install drivers, rather than having to mess around with code as you do currently. The drivers will also update automatically.
Edge drivers can do an awful lot more on the LAN than Groovy DTHs. That could open things up for some interesting new integrations with LAN based devices.
Migrating to Edge drivers may mean more of the legacy platform can be switched off, or at least remove a major obstacle. Hopefully that will improve the stability of the platform.
Understood. But for me this might not be much of an Edge enhancement since all of my Hub Zigbee and Z-Wave connected devices are already running locally except for one, the thermostat. And with the exception of the thermostat, all of them are respond instantaneously. However, the BIG thing thatās really annoying are time involved Routines (Automations not Smart Lighting) do not run local. Hopefully time involved Routines for local devices will run local in the Edge world?
This sounds interesting. So in the Edge world, I will see a list of available drivers in the app, so that I can select which driver I want to use?
That sounds cool.
Stability??? I guess time will tell.
So will the Edge world have the ability to backup/restore SmartThings Hub configurations?
Also, will the Edge world allow moving my Hub connected devices to another Hub (aka migrating, upgrading, disaster recovery from a failed Hub) perhaps?
Since Webcore now also runs on Hubitat, I believe some of their most active developers are now using that platform. So not relying on ST at all. Beyond that, youāre right: they arenāt collectively going to provide an alternative hosting solution, so I donāt see a lot being done. For those who want more details, thereās a discussion in their forum, which I know you already participated in.
Also the original primary author was hired by SmartThings a couple of years ago to work on the Rules API and other official features, which probably explains the timeline break in rapid Webcore development.
I have a couple other questions as it seems some are able to test Edge in Beta.
Is it known if the Edge Drivers will correct some issues with the registration of the Z-Wave Device?
For exampleā¦
Some of my devices (even though they are identical in model number) arrived to the HUB as ānon-secureā while the other(s) arrived as āsecureā. I ignored because it isnāt important to me, but just curious if this is corrected?
Some of the Fan Controllers suffer from the āLED Indicatorā issue. The Plus models donāt illuminate the LED regardless of the switch position. The ānon-Plusā models do illuminate blue when on (or off).
These are all GE Jabsco Enbrighten switches - which I have seen will be included.
Iām just curious if these new drivers are able to fix odd issues like above?
Youād be surprised at how many model #s theyāve come out with. I had a greater variety than I expected when I inventoried mine, including some being different models that I thought were the same. The secure/non-secure happens at joining. It could be that some of your models canāt connect secure, or that the secure joining just didnāt work. Thereās a whole body of thought on whether you should try to get your devices to join non-secure to reduce network traffic. Edge vs DTH wonāt impact that, and it would likely only matter if you were setting up z-wave association between different security levels.
Yes, but you have to run devices with the -y or -j flags, same as finding z-wave node IDs.
One caveat - IF the device supports changing the setting. AFAIK, there was one or more early models of the fan controller that you had to use the paddles to switch. But in short if it worked with a DTH it should work with a driver. If a feature DIDNāT work with a DTH, a driver wont magically give a device new features.
For instance, if your device doesnāt support central scene control, (*cough GE Motion Switch) a driver canāt suddenly give you multi tap scene activation because the device simply doesnāt do itā¦ And I absolutely pile on Philās comment about be very careful on model numbers - thereās TONS of models, and sub models, and sometimes firmware revisions matter.
Well, now that Edge is nativity available on my SmartThings v2 Hub, Iāve taken SmartThings Edge out for a spin.
The first thing I did was join the SmartThings developer channel to Enroll the SmartThings Edge created drivers with my Hub. I installed the SmartThings channel Zigbee Switch driver, the Z-Wave Button driver, and the Zigbee Thermostat driver.
When I added a new Osram Zigbee Smartbulb to SmartThings, it was added using the SmartThings Edge Zigbee Switch driver. It seems that all of the features of the Smartbulb are available and work fine.
When I deleted my Aeon Minimote and re-added it, it was added using the SmartThings Edge Z-Wave Button driver. It works fine too and now is nativity running local in Automation Routines instead of using Smart Lighting Routines for local execution of button presses. However, the device handler page shows a ton of various button features available, but most of them did not work with the Aeon Minimote.
I also tried using the SmartThings channel Zigbee Thermostat driver since it would make my Zen Thermostat run local, but it didnāt work well at all with my Zen Thermostat, so I went back to the SmartThings native driver.
I also Enrolled with @TAustin channel to install the Virtual Drivers V2. I ended up changing all of my DTH Alexa Virtual Switches (except for two that are controlled by Webcore) over to various styles of this driverās Edge Virtual Switches. Half of my Alexa virtual switches maintained the contract Open/Close feature, but for the other half I went with motion virtual switches since Alexa Routines can be triggered by either motion or contract. I also combined one Virtual Switch and one Alexa Virtual Switch together into one Edge Virtual Switch contact since it runs local, and deleted the miror Smart Lighting routine I was using to keep them in sync.
As for all my other Zigbee/Z-Wave devices and virtual switches that are already running local, Iām not going to waste time manually migrating them over and just wait for SmartThings to hopefully migrate all of them over at some point in the future.
