Edge/Lua Roadmap for 2023 (and beyond)?

[DigitalDan (Dan)]

I have been working hard to port over as many of my devices to Edge drivers as I can. The latest one I was trying to implement was this Alarm.com driver and the author says that Edge drivers are unable to talk to the cloud - which seems like a big oversight in our modern world. I know @RBoy has been waiting for certain drivers to me made available as well.

I have been looking around the forums and can’t find any roadmap for where the Edge driver architecture will be moving, or what features they expect to implement when. Does such a roadmap exist and I’ve just missed it?

[JDRoberts]

Nothing public has been announced as far as a roadmap beyond the fact that there will be edge drivers for matter devices pretty soon.

[schwark]

I think what he is talking about is that LAN edge drivers that need to communicate with a web API on the internet cannot do so today - only can communicate with IP addresses on the LAN (Groovy drivers could talk to the internet) - nothing to do with whether or not Samsung providers a free cloud (it is an arbitrary restriction that has been introduced - most likely to improve security, but is a classic example of throwing the baby out with the bathwater).

Https url: host or service not provided, or not known

I have tried this code in Lua on my Mac and it is working. I only changed local https = socket.http to local https = cosock.asyncify 'ssl.https' to move it on the hub. I also tried: local https = cosock.asyncify 'socket.http' with the same result result, code, rheaders, status = https.request { url = url, method = method, headers = headers, source = source, sink = ltn12.sink.table(response_list) } Now code that was working on my Mac is reporting this error: host or service not provided, or not known url is a public https site - no funky certs or intranets. hub firmware version v44… since it looks like something changed around this stuff in 43…

[JDRoberts]

@schwark

I think what he is talking about is that LAN edge drivers that need to communicate with a web API on the internet cannot do so today - only can communicate with IP addresses on the LAN (Groovy drivers could talk to the internet)

Thanks— I removed the confusing stuff from my post above. I appreciate the clarification.

[DigitalDan (Dan)]

@schwark

I think what he is talking about is that LAN edge drivers that need to communicate with a web API on the internet cannot do so today - only can communicate with IP addresses on the LAN

That is exactly what I was referring to, thanks for clarifying. I agree it seems like throwing the baby out with the bathwater and will break a lot of the most useful integrations. Thanks for linking that thread, I’ll explore it as well.

[h0ckeysk8er (Bruce Pinsky)]

@DigitalDan

@schwark

I think what he is talking about is that LAN edge drivers that need to communicate with a web API on the internet cannot do so today - only can communicate with IP addresses on the LAN

That is exactly what I was referring to, thanks for clarifying. I agree it seems like throwing the baby out with the bathwater and will break a lot of the most useful integrations. Thanks for linking that thread, I’ll explore it as well.

@TAustin has developed a driver to support doing local HTTP/S Put and Get commands from the hub. In conjunction with that, he has created a bridge/proxy that you can run locally that supports doing the requests outside the local LAN.

[ST Edge] Web Requestor: a driver to issue local POST and GET HTTP requests

I have a new Edge driver to share that provides the ability to issue POST and GET web requests to a specified URL. This functionality can help users that may today depend on webCoRE or other cloud-based means to do a similar task. Of course being an Edge driver it enables you to have fast & local automations. There are two ways this driver can be used: Pre-configure up to 50 different POST/GET URL strings, which can then be individually triggered through Automations/Rules or via a button in the mobile app. Issue custom URL POST/GET commands from within a Rule >>>>>UPDATE: Please go to this readme file for the latest instructions Limitations Although GET method is supported, it currently does not actually do anything with the returned data from the server. I’m open to ideas he…

[schwark]

Yes, I use the same method, and created a proxy as well.

GitHub - schwark/stproxy: SmartThings Edge Proxy

But that is a really hacky way of doing things and this proxy should not exist and just complicates things for users to use it.

[csstup (Corey Stup)]

I actually appreciate a model where hub drivers are sandboxed to LAN only.

I can also appreciate how some functionality that the Groovy environment allowed is lost, but keep in mind that it was Samsung cloud services talking to internet resources (like alarm.com), not your hub.

So technically the hub is doing what it could do before. Communicate with LAN and the Samsung cloud only.

[orangebucket (Graham)]

@csstup

I actually appreciate a model where hub drivers are sandboxed to LAN only.

I’m glad I’m not the only one who thinks that.

Over the last year or so I’ve seen a lot of Edge drivers described that seem to me to be doing the job of cloud integrations or apps. Just because Edge drivers can do certain things doesn’t mean they should.

[veonua (Andrew Me)]

Mobile apps solve this via permission schema. Which kind of exists on the ST as well. I believe it would be better to have a “this driver can make web requests” warning,

instead of just buying RPI as a proxy for weather or MyQ apps.

[DigitalDan (Dan)]

@veonua

Mobile apps solve this via permission schema. Which kind of exists on the ST as well. I believe it would be better to have a “this driver can make web requests” warning,

I agree. The power of SmartThings is it can be different things for different people. Some of us want the ability to let our device call out to the web, some of us don’t - and a permissions model of some kind can allow the best of both.