Edge/Lua Roadmap for 2023 (and beyond)?

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?

1 Like

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

1 Like

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).

1 Like

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

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.

1 Like

@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.

1 Like

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

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.


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.


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.


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.

1 Like

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.