Support for Websockets in Edge

Hi Gol & Louis,

Glad to hear someone were trying to do something similar. Just want to know if you can share with what issues did you encounter and make you decide to pause at present?

@taustin has a couple of working websocket projects for Edge. They are still in beta because Edge itself is still in Beta, but you can take a look. you can find them (and any future offerings) from the quick browse lists in the community-created wiki:

1 Like

FYI, my drivers usually don’t use any third party libraries. My webhook, RESTful interfaces are implemented with vanilla sockets.


I guess the driver isn’t open sourced? Since I can’t seem to find link to source.

Which driver are you looking for? I have several Edge drivers in my public github repositories.


I have posted about the driver I am working on here, I was able to get websockets working but had to change the library @gol shared and even hardcode some of the handshake behaviour as i was unable to get that bit to work in ST edge driver


Great! Thanks.


@lmullineux Hi, I tried your driver’s websocket to a ws server, but got hand shake failure. The error was due to wrong Sec-Websocket-Accept header. Since I was able to connect to the ws server via a standard websocket client, I believe the server part should be fine.
Do you think is possible the ws lua client was the culprit?

Hi, I skimmed through your repos, could not find a websocket client, can you point me to a driver used the websocket?
Also, I used mdns for service discovery. It’s sort of working in my environment (thanks to MDNS failure - #2 by erickv), but do you know is there a way to keep the mdns running in a dedicated thread so that our driver can be notified anytime a service is online or offline.

It’s almost certainly the client yes.

As I said in my post getting the handshake to work was the exact problem I was getting.

I ended up hardcoding the expected response because I couldn’t get sha1 working.

I was able to do this because the device I was using always sends the same value, and the guid was fixed.

You should be able to do the same approach if the value sent is always the same. Have a look at the sec_websocket_accept function of the handshake file within the websocket folder. ( If the value changes though you will need to try and get sha1 working on the hub)


Thanks for the update.

I found out the cuase (possibly), the server was returning a plain http response because the ws request isn’t allowed. So, I guess the problem is not with the lua ws client. I’ll investigate more and let you know if it still not work.


What are you trying to communicate with?

Have you figured out what sort of ws client you need? I was using sync client so have only tested/fixed that client

I’m trying to support Terncy hub (

The problem was I passed a wrong authentication code while connecting to the hub. After I corrected it, it worked fine.


Great - I hope you get it all working

Try scheduling your service discovery via driver:call_on_schedule( [seconds, callback, label] ).

Also, I’d recommend you scheduling single-action callbacks by time instead of loops, tho.

1 Like

I don’t have one, sorry, but sounds like you’ve got the 3rd party library working anyway.

I see Erick respsonded, but I’ll add a couple thoughts: Do you really want to continuously monitor mDNS for new devices? I think the SmartThings approach is to let the user decide when they want to search for devices, so in that model, you’d only sent out an mDNS query when your driver’s discovery lifecycle is invoked.

That said, for fully robust device health maintenance there is value in having a continuous watch on the multicast which would have to track the TTL (time-to-live) of each device, and watch for goodbye messages to know when devices are going offline. This is exactly what my UPnP Edge library does, and I am in the process of developing an equivalent mDNS Edge library, although I’m not yet certain how far I’ll go with it in terms of the continuous monitoring. If you’re interested in this, DM me and we can discuss and I can share my progress with you.


It’s true. Just one thing, if the hub we’re communicating with is rebooted for whatever reason, our edge driver should be able to discover the hub is back online without requiring user to perform searching again.
That’s why I need to keep monitoring the mdns online message. In principle, it’s quite to similar to what the ssdp is doing in upnp.

Yes, I agree! The only way to avoid a polling approach is to keep listening!

1 Like

It is really accurate what Todd mentions, that discovery should be an on-demand action, instead of having the driver broadcasting at any time.

I had that same thought when I worked out the lightbulb-lan-esp8266, and for that, I implemented a “port acknowledgment” flow (driver to device) for cases when the device drained its battery and cache was deleted.

In an ideal world, Edge would provide an SSDP and mDNS discovery capability built-in to the API. But I suspect their focus will be on Matter instead and that there will be some kind of built-in Matter-based discovery capability in the future. Otherwise driver developers keep implementing their own code and it leads to a lot of duplicate function across LAN drivers as well as inefficient utilization of the platform.

1 Like