DeviceDiscovery - Discover IoT devices on the local Network

This video shows a early stage demo of my IOT Dash app (WPF) on Windows. The app discovers all devices via UDP on the local network, gets the system properties of each device and the available commands. The commands are not hardcoded within the app - they are downloaded form each device separately. It supports secure (SSL) connections and non-secure connections (plain TCP sockets). After the discovery it is switching to a command server.

Could not make the secure server work on the netmf side, but working on it :slight_smile:


Very nice. So, are you using a custom protocol for the command discovery or one of the developing standards?

1 Like

I have three same question @ ianlee74 asked.

Custom, simple JSON. First discovery via UDP, sending an “device string” like 0x50 (Edison) for example.
After discovery sending two types of information:

-Basic device-info’s
-Available commands

Then switching over to a socket-server. That server receives and executes the commands. With node.js I can do a complete SSL based encryption. Could not make it work with netmf.

Will publish the source shortly. Have to package the netmf part into a dll and add parameters. A bit GUI polishing as well :slight_smile:

I want to use the WPF app as “proxy” that has way more power. Looking forward adding diagrams and a kind of push as well.

@ AWSOMEDEVSIGNER - Very interesting!

1 Like

Have you considered WS-Discovery? It’s simple to implement, uses UDP multicast or TCP, and is fairly widely used already (it’s been an OASIS standard since 2009, and it’s enabled by default in network-enabled HP printers since 2008).

On the desktop side, the .NET framework has great support built-in. On the device side, it might already be implemented in the DPWS stuff, but I’m not sure. If it’s not, it’s pretty easy to implement.

1 Like

@ Architect - Thanks :slight_smile: Adding a “back-channel” today to receive “events” from the devcies, like sensor data.

@ godefroi - Thanks for the tip :slight_smile: And no, I have not considered that. I was thinking about trying something using AllJoin later:

Because this will be built into Windows 10 as well ( I know it from Justin Angel (Twitter), he’s dissecting all the DLL’s on Windows 10). If I am not wrong, AllJoyn has a very tiny C-Library for embedded devices. Maybe this can be ported to NetMF ?

But I have not seen the source so far.

@ godefroi - Looks like node.js libraries are also available for WS:

Will try that as well :slight_smile: Maybe a good point to start.

PiWi has pointed me to uPNP as well:

Important is, to implement this as easy as possible so that you can use it without studying manuals for hours.

I am thinking about a Linux-GUI based on Mono as well.

@ AWSOMEDEVSIGNER - The nice thing about uPnP, sending the gena discovery (accompanied with the proper device/service server(s)) it directly shows up in windows and probably other upnp saffy equipment as well. Plus you can re-direct to an admin page (url) we you are directly on the devices web page for whatever you get to do. Pretty much the same as with those (web pages) you probably know from various printers etc.

The device(if complaint with uPnp) picks up the IP-Address without users intervention needed (even without DHCP), sets up its internal UDP, TCP servers, broadcasts a GENA discovery packet, and your device should be enlisted in your windows devices, if coded correctly, right mouse click on device and goto to the your defined admin site and off you go …

In the services, you report your methods and parms you support, it will be discoverable by the other devices … with events if need be …

Maybe this is old stuff, and alljoin is the more modern way of treating these matters … donno …

Edit: my ios and androids discovered the UPnP devices I’ve got at home as well, so it is not limited to windows

1 Like

@ godefroi - Can confirm that it is available within the DPWS namespace:

And if I am not wrong, this could be used on the desktop (did WCF, but not this):

All in all I have to say that the effort implementing these “standards” is still very high for netmf based platforms. From an interoperability standpoint I simply have to say that JSON, TCP and UDP combined with security are still my top-notch candidates.

That way I can use nearly any platform and exchange data. Easy without loosing the interest - and most important - the fun factor :slight_smile:

I’ve developed a UPnP API (controller that is - not device) in C# using a common source and three projects which use that source to build a Desktop, Store and Phone version of the assemblies. UPnP is frustrating with inconsistencies in the “specs”, manufacturer deviations and hacks and so on, its quite challenging getting something solid running.

To my knowledge mine is the only non-trivial implementation of UPnP in C#, most examples you’ll see rely on some old COM/C++ code that <S released years ago.

I originally created this to be able to control my Sonos devices from my (then new) Windows Phone, at the time I had no idea just how involved the work would get with a large number of specs and so on.

Devices contain (sometimes) sub devices and these all contain services, some are optional some are obligatory, each service is self describing via an XML blob that defines SOAP calls, args, arg types etc, its all pretty involved.

What’s frustrating is that many manufacturers - Sonos included - deviate from the specs/standards and make it necessary to actually reverse engineer network traffic to see what’s actually going on, I’ve found and reported several such deviations but it is what it is!

The Intel tools are superb and without these I’d never have gained the insights I did, many times these tools were the only way to resolve some vagueness or error in the published specs, Intel did a good job on these.

One example of a deviation is the way Sonos controls internet radio services, their devices do not respond as the standards say they should in some cases and a traffic sniffer was the only way to get at this.

These deviations mean its essential to include “hacks” into the design without breaking the integrity of the design, having a policy for “Sonos do this this way and XYZ do this that way” etc is a pain.

I did an immense amount of work on this but put it aside like two years ago due to other demands on my time, but I want to dust it off and finish the controller perhaps as an app in a store or something, the controller app amounts to like 10% of the code, the other 90% is the implementation of the processing for SSDP, SOAP, devices, services etc etc.

The reason I’m laboring this is that I think UPnP is [em]no good[/em] at all as a standard for .Net MF/Gadgeteer (unless specifically aimed at supporting existing UPnP systems).

I’ve just been reading about DPWS which is supported (UPnP isn’t - other than what I have there’s almost no managed code out there that does anything serious).

For an example of just how involved all this can get just peruse this - it’s just one of the many documents that pertain to UPnP.

AllJoyn showed off a .NetMF library at BUILD this year. I believe it’s available for folks to use. I have always used mDNS for device discovery. You can add custom attributes in mDNS for your client apps to parse and make use of.

Yup - the AllJoyn Tiny Core is in NetMF 4.4, though I haven’t had time to play with it.