Now that we have connected our project to the local network, we are immediately faced with another challenge: how can we reach it? Using WPS/SmartConfig means we force the unit into DHCP settings mode, IP address is auto assigned by the router in that case. You may not have access to the router’s settings to force static IP leases. Finding your connected project’s IP address isn’t exactly trivial and certainly not something we expect from the end-users to be capable of doing themselves. What we need is to simply type the product hostname and it should show up, something like typing “fridge.local” or “garage-door.local” to your phone’s browser should bring you to the device control UI.
It seems that there is no solution that “just works”, it pretty much depends on the setup that you have. iOS supports mDNS/DNS-Sd/ZeroConf out of the box, Windows uses NetBIOS and more recently (from Vista onwards) LLMNR and with Linux you have to take care to install the respective protocol yourself. I’m not sure about local hostname resolution on Android, I wasn’t able to get it running on my Android devices. Setting DHCP hostname option doesn’t seem to be universal solution either and only works in some cases, if the router supports it.
I’ve included mDNS, NetBIOS and DHCP hostname support in my latest ESP8266 projects, but am still looking for universal solution.
Most things seem to just use broadcast UDP to discover devices in their apps.
upnp will get things listed in the network section of recent windows versions. Infact even XP would do that once you added something. That means you can see the device, and if you broadcast that it has a web page, it will open it when you click on it. All my wemo’s show as devices, but as they have no web page, I cant actually do anything with it in there.
UPnP is nice to have as well indeed, I’m not sure how “universal” it is though, if it works on all OS-es without additional setup. I’ll explore further, it indeed makes sense to consider it as an option.
How about this:
– device ‘registers’ with a public server. A simple GET request that includes the LAN address of the device will do.
– Server records an association between the public address and LAN address.
– user visits a public URL of that server.
– server responds with a redirect to the LAN IP of the device.
Of course this method only works if there is a single instance of a given device behind the public IP.
Also assumes that both the devices requests will get presented with the same external IP address.
With the exhaustion of IPv4 and IAP’s charging additional for a non-natted connection you cannot count on the presented IP to the web server being the same or consistant for devices on the same network. That is before you add in load ballancing to the mix.
The thing is, an IOT device is almost never going to be used with a web browser, it will be driven by apps or cloud services. finding devices on the LAN is a small thing to overcome with apps, assuming that the user doesnt have wireless isolation enabled, and once they can see the internet then a server is the obvious way to control them so that status of the device is syncronised between all the devices that are controlling it, both on LAN and external to it.
I have yet to encounter a situation where two devices on the same residential LAN present a different public IP address to external servers within a reasonable time window.. Further, the instances of any ‘office’ based LAN performing that way are rather rare and would involve multiple uplink providers and/or segmented LANs where most (all?) forms of UDP discovery would fail anyway.
I would solve the dynamic IP problem by having the IoT device re-register at some predetermined interval, likely with a GUID, that will update the mapping with the new public IP. BTW, this approach also handles the issue of the device itself having dynamic LAN IP assignments.
That said, of course having the device managed through an external server removes the problem entirely but I was under the impression that the question at hand was how to find a device with a built-in management interface on your local LAN if the IP device of the device was not known.
I thought about this a bit more… If there are multiple devices behind the LAN the public server could just return a list of links to the individual devices. Also, if the ‘registration’ process included a friendly name that name could be used to generate the list.
I could throw together the service side of this in a few minutes — if anyone is interested in giving it a try drop me a msg.