@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.
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)
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.
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.
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.
Totally agree. If ST is trying to prompting the hub to be a truly compatible edge Hub for different devices, it’s really a mandatory to have built-in support for these standard discovery protocol.
Back to the original question, since I’m still a novice with ST edge driver, I’m thinking if is possible to create a mdns engine in the driver initialization, and register_channel_handler for the mdns’s sock? Otherwise, the only option is to keep broadcasting mdns querying at a (reasonable?) interval.
Hey there - Hope you’re still around! I’m in the investigation phase of doing an Edge driver for some devices that, according to their documentation, use websockets as their interface. I (re)read through this topic and am grateful to see that there has been some work on a websockets client library for Edge drivers. However it sounded like it wasn’t really fully functional and that the security handshake isn’t working. Is this still the case? I’m not too familiar with the implementation, so is this function exercised even if there is no access authentication defined on the device?
The handshake I was referring too isn’t really authentication, the handshake upgrades the communication from standard http to ws. The good news is the secret that you exchange to do that is almost always fixed. The fact that the crypto libraries needed to do this dynamically are missing/don’t work should be considered an inconvenience but not a blocker.
However, since my implementation I heard Samsung were bringing in an officially supported ws library in the beta program(I’m not part of that). Not sure how that had progressed.
Feel free to have a look at my harmony driver, copy out the ws folder and use the library. You just might need to change the hardcoded handshake lines ( you can figure out the correct values for your device by first using a browser based ws client and looking at the traffic using the console)
Let me know if you need any help, I’m not actively developing in st as I just don’t have enough time. But I still linger. I’m probably going to have to write a few drivers ahead of the groovy switch off for my thermostat system so I’ll be around a bit more at some point.
Thanks for your reply. I read through the ws spec last night so I have a better understanding now. I had to implement an http digest authentication function for an ONVIF driver I did earlier so maybe I can get the handshake bit working in the ws library. I’ll give it a shot!
Yes! That’s the same one I’m using in another driver and it works just fine.
EDIT: Although as I was thinking about this after having read the websockets spec, I didn’t fully understand why this would even be a problem. Afterall it’s the ‘server’ that has to compute the hash and it simply gets sent back to the ‘client’ (in this case the Edge driver). Yes, the client is ‘supposed’ to validate it, but my reading of the spec was that it really doesn’t even have to. All the client really has to do is come up with a random base-64 encoded nonce that it sends with the original http message.
How do you determine online/offline state of your computer? I have a solution that uses PING to report status back to an Edge driver. It requires a couple Python scripts to be running on a separate, always-on computer.
I have two drivers that include the WOL function - my LAN device monitor (which it sounds like you tried), and a standalone WOL driver and works with Alexa.
You probably cannot use this driver to monitor your online/offline status (it is for UPnP devices), but it definitely should work fine for sending WOL command to your computer. You just need to be sure you have the mac address entered correctly.