@TAustin why don’t you share your virtual device driver? I would like to test it.
1 Like
That requires a hub, right?
At this point, the vast majority of SmartThings users (including me) run in a hub-optional configuration, which still allows Samsung smart appliances and TVs, and cloud to cloud integrations. I run Meross, Philips Hue, SwitchBot, Ring, and virtual devices, among others, for example.
@jody.albritton , So I guess I need to be more specific and go back to my original question and note that I use virtual groovy devices that are BOTH a switch and a sensor for integration with Alexa routines, but I don’t have a hub, so I’m not sure Edge is going to fill the gap for me. 
Well yes, this is an Edge topic after all. 
But I appreciate your point about so many users without hubs!
1 Like
Well, it may be that once the transition is complete the only way to use virtual devices is to have a hub and use Edge drivers. But that’s not true now, so it would be a pretty big change. 
It’s better than not having virtual devices at all, and someone like me might still go that route, but it is something to be aware of.
2 Likes
Will do! I’ll start a separate topic for it. Have to run out in a bit but will get posted by this evening.
2 Likes
I’m hoping variables make their way over. My “coolest” webcore piston is random greetings when certain people arrive or leave home 
Not really smart house related but cool nonetheless.
1 Like
@TAustin there’s is a topic from couple days ago, that has solution with groovy, but nothing with new Edge drivers or maybe is more smart app, than device.
Virtual Thermostat
This is more challenging as groovy solution created virtual Thermostat that has settings for temperature sensor and for switches/power outlets.
What is your opinion @TAustin is this doable?
In my case just aware virtual ones could still to be created …
Will there be any kind of metrics available for shared channels? For example, I’d like to see the number of installs & uninstalls by driver by channel.
1 Like
I’ll record this feature request for our product team. This is something we considered during requirements design for driver sharing but dropped from the MVP release for beta. Any statistics would need to be fairly high level to protect user privacy but it does seem very reasonable to provide at least the channel enroll and install counts for publishers.
EDIT: Oops, wasn’t meant as a reply to you @fido, must have hit reply earlier and started the message to @TAustin off that 
. Anyway, submitted the feedback internally.
7 Likes
@posborne, I am just shooting into the blind, but as the new Edge drivers are utilising LUA, what is the chance that the Hub could run an MQTT Client written in LUA as well and pass information to a broker? I know this is not a local API solution, but could make connectivity with other systems easier.
I have seen in other bridges/hubs similar setup where a local MQTT client connects to a server to publish and subscribe for topics, but the option could be local access as running a local LUA code.
Is there any chance for this in the “near” future?
1 Like
Yep, writing an MQTT client should be perfectly possible today. Since drivers are for the implementation of devices, this could be used to convert data from topics on a broker and expose them to SmartThings and to publish to topics in order to control devices.
MQTT is simply a bus and doesn’t define the application layer (topics/paylods/etc.) itself so that bit would vary per-integration writing the client itself should be very possible. Our APIs are based on luasocket and luasec so it may be possible (though we haven’t tested) to integrate a dependency like GitHub - xHasKx/luamqtt: luamqtt - Pure-lua MQTT v3.1.1 and v5.0 client into a driver.
I’m personally currently working on a side project to expose data from an ESP32 micro running Arduino via CoAP to be consumed by an edge driver.
5 Likes
That sounds interesting. That could open up the possibility to integrate locally Philips Air Purifiers or some Tado products. (Maybe an IKEA bridge…) Just from the top of my head what devices use CoAP.
Regarding the MQTT client. Would be possible to expose other Edge device state changes to an MQTT broker? Or would that require really a SmartApp?
I was really thinking of sharing device events and react on those through an MQTT broker.
Is there any plan to bring the LUA environment for SmartApps as well? Or would this be possible through the Rules API?
By design, the scope of data to drivers is limited to those devices associated with the driver and you cannot subscribe to device events or access device state for devices not owned by a given driver. Use of the sandbox for executing smartapps is something we have considered but raises a variety of concerns related to hybrid execution, data privacy/security, etc.
One should be able to build something like you suggest by setting up behaviors that would take specific events from devices and forward them on to an edge driver device that would act as a client to an MQTT broker. The specifics of how this would work are left as an exercise to the reader but at least in theory such a thing should be possible and, depending on how the rules are setup, would work for both hub-connected and cloud-connected devices with the rule executing locally if possible according to the normal restrictions.
Logging of data to a local database (e.g. InfluxDB) on the network is a similar sort of problem that both our engineers and product teams have been discussing some. The “Rules → Edge Driver Proxy” solution described above does seem at least feasible but probably would be difficult to put together, manage, and scale. I’m not aware of anyone as of yet building something like this so your mileage may vary and this isn’t any kind of official recommendation, just an idea of what I think could be composed with what is provided today. For now the primary focus for this beta remains on hub-connected device/driver story.
3 Likes
That was in my mind actually as local logging, or a local dashboard.
Thanks for all the answers. I am just playing with some ideas what could be possible with LUA Edge drivers.
It was really a bold idea, just thinking about possibilities. Managing and scaling would be a nightmare. A SmartApp would be the right solution if local execution would be possible.
Regarding scaling, I think the Rules limit would be an issue, if the 200 still applies. I haven’t followed lately how those limits have changed.
I really appreciate your answers.
Do devices using Edge drivers run on their own Z-wave/Zigbee network or is it the same as Groovy devices? I have a couple zigbee motion sensors that were very stable using Groovy DTHs but have been problematic running Edge drivers.
@Automated_House The network is the same and core network management features and things like device health use the same core code past the “application level” bits done by the respective dth/driver. The isolation provided by edge drivers is enforced at the sandbox egress. So, for Zigbee, if a request to send a message to a device short address not belonging to that driver it will be rejected.
That being said, I don’t want to sweep issues under the rug as we want to identify any potential problems with the new edge drivers. Are the problems you are seeing with devices falling off the network, increased rates of failed control or report, something else?
1 Like
Totally falling off the network. So far a Sonoff SNZB-02 and Iris iL07/iMagic by GreatStar/1117-S that were previously very reliable have been dropping off frequently and having to be reset/rejoin to get them back online. Shoot me a DM here or Slack and let me know how I can help you troubleshoot.
1 Like