10

Recently I bought a couple of wifi relays from Xiaomi. While they have been solid so far, I really dislike Xiaomi's app. But, I do like the idea that it actually works both in LAN and over the internet. When in LAN they are very quick to turn on and off, considering Xiaomi's servers are in China.

So I want to roll my own ESP8266 based relay (I know I can get the hardware ready made, so that's a bonus). My issue is, how can I automatically detect the relays on my network from a web page?

From an "App" I could use SSDP, mDNS-SD or UPNP to detect things. But I haven't found info on wether this is possible from the web browser (Chrome on Android basically). Since I changed my weather station web page to be a Progressive Web App, I've been hooked. I really like the idea of things just being webpages and not apps you have to install. And PWAs fill the gap with offline mode too.

It's strange though, that the "difficult" part (turning the relays on and off from outside the LAN) is trivial to solve via a MQTT server. But I'd prefer not to rely on the external MQTT server. If I'm on the LAN, I want to talk to the relays directly. If not, then send the command through MQTT.

I could, of course, rely on the server to query the relays, but in that case I'd need an internet connection (if my MQTT server is on the "cloud"), or a home hosted server. I do have a server at home, and even if I didn't, a raspberry pi could easily fill the gap. But the ideal would be not to even need a server when talking to the devices over LAN (Wifi in this case). I prefer to keep it P2P as much as possible, and only use MQTT as a fall back for when i'm on WAN (MQTT solves the problems of CG-NAT and port forwarding).

  • 1
    Welcome to the site, hjf! Currently, your question is quite broad. It would help if you could be a bit more specific: for instance, what languages are you currently using, and what errors / specific issues are you running into? – anonymous2 Mar 7 '18 at 2:23
  • 1
    @anonymous2 well it's a very general question. I don't want to ask specifically "can I make mDNS queries directly from the browser?" because the answer is NO. There is a standard about that but no implementation. I'm looking for alternatives or similar functionality. – hjf Mar 7 '18 at 2:38
  • Known MDNS hostnames work fine from a browser running on an operating system like OSX or most Linuces which support them, though browsing probably does not work. And of course they don't work on an operating system like Windows or Android which do not support them, unless additional capability is installed. – Chris Stratton Mar 8 '18 at 4:19
6

I'm not aware of any generic local discovery capability built in to a browser. In fact I would consider any capability to be a security venerability as it would allow attackers to profile the your network remotely unless it had a manual interaction step to start it, which would really slow down the workflow I think you are aiming for.

I can think of 2 things that come close:

  1. The Chromecast discoverability baked into the Chrome. This used to be a separate plugin before it was rolled in. But this still requires a manual step to where the user triggers a search and then a manual selection the device details to be passed back to the page/javascript. (this uses SSDP under the covers iirc)

  2. The WebBluetooth scan support. This follows a similar model to the Chromecast discovery, The user has to initiate the scan, then they have to manually pick from the devices found by the browser which details get passed back to the javascript in the page.

I have used the WebBluetooth approach to discover a local light switch (I have a BLE app on a pi zero controlling a Belkin WeMo bulb https://github.com/hardillb/physical-web-lightswitch). It works but it's not seamless as it requires at least 2 user interactions to discover a single device.

While it doesn't meet your all local requirement I think using the cloud broker approach even for when operating locally it will be a smoother user experience.

  • Nice answer. It wasn't was I was looking for, but it's what I was expecting I guess. There is the NSD API from the W3C but the only implementation is for Google Chrome Apps. I – hjf Mar 7 '18 at 15:01
  • It looks like the NSD API has been killed from the doc: w3.org/TR/discovery-api – hardillb Mar 7 '18 at 17:54
  • The security theory proposed here has things backwards: if there's an issue, it's not with the thing doing the discovering (browser) but rather the thing which is making itself discoverable. You're welcome to your own opinion on the wisdom of discoverability but it's worth noting that is is extremely common default behavior of many personal computers, printers, and other devices. The willingness of a browser operated by an authorized party to find something (or not) says nothing about the ability of an unauthorized party to discover devices. – Chris Stratton Mar 8 '18 at 4:15
2

If you have a web interface on a device, and configure it to have an MDNS hostname via an MDNS responder service such as bonjour or avahi, then from featureful operating systems you can just point your browser at

https://livingroomlight.local

Or whatever you configured it to call itself.

This will work out of the box with browsers running on OSX, iOS and most Linuces, all of which support MDNS hostname resolution at system level.

However, this will not work from Windows unless you install add-on MDNS support, and it will not work with stock Android browsers though it is possible to make custom browser apps for Android which support it.

Discovering unknown instances on the network is not typically supported by a browser, but is typically supported via operating system APIs and command-line tools like dns-sd (OSX) and avahi-browse (Linux).

So while it doesn't appear obvious that a browser can find your devices, if you can simply remember what you called one of them you can connect to it, and it could potentially show you links to all of its peers, by doing an MDNS search itself.

Or you can fire up a terminal and get yourself an answer. For that matter you could run a local daemon which would do an MDNS search and show you the result as a page of links served only on the loopback interface, and thus not accessible to any other machine.

  • 1
    Such a shame. This could be an alternative if supported. I wonder what the rationale of not supporting mdns-sd in browsers is? Anyways, I think the only way for things to work reliably would be to just use MQTT as a discovery method. Have some sort of "announce" endpoint where devices would report themselves, and cache those answers. – hjf Mar 8 '18 at 11:59
  • It's not the browser doing any of this - it is the operating system's extended implementation of DNS, which means that a browser (or anything else) can use a name like livingroomlight.local MQTT won't really help you - something is going to have to collect results and present them, regardless if it is a hardware box, a daemon on the PC, or a human. – Chris Stratton Mar 8 '18 at 17:46
  • 1
    But android supporst mDNS in "apps". It's possible to send mDNS queries through apps, and get responses. How come no one is implementing mDNS-SD and exposing it to JS? There was a standard that was pulled and only implemented partially, specifically to detect Chromecast. – hjf Mar 8 '18 at 20:52
  • 1
    Again, because no one deals with MDNS in web browsers; it works for known hostnames where the underlying operating system's DNS is extended to support it. Android's is not, though it offers MDNS capabilities to apps through a separate, Android-unique API having nothing to do with how it resolves domain names. – Chris Stratton Mar 9 '18 at 0:49
  • 1
    That's my point. Why is no one pushing for this? With IoT becoming more and more common, how is it possible that this sort of APIs are vendor specific locked-in and the W3C has pulled the standard? – hjf Mar 9 '18 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.