Device auto-discovery

[325xi]

[quote=“micasaverde, post:11, topic:164599”]Assuming the device in question is not UPnP, like the IP cameras we’re using, there’s no ‘official’ way to find them on the network. So, what we’ve done with Vera is add a low-level LAN monitor that listens for all IP requests (ie DHCP) whether or not Vera is the DHCP server. When this monitor determines a new IP device is on the network, it calls /usr/bin/cmh_PnP. This is a simple ‘brute force’ script that does wget’s on the IP address to match against known patters for devices. You’ll see right now we have pattern matching for the Panasonic cameras, the GC100, and the D-Link. If you want to add a device and make it plug and play, send us the ‘if’ statement we should add to the check portion, like this:

        if curl -o /tmp/$IP.temp.gc100 -k -s -S --fail --connect-timeout 1 --max-time 1 "http://$IP/index.html" --stderr $err_file && grep GC-100 /tmp/$IP.temp.gc100 ;then
			log "It's a gc-100"
			IsGC100=1
			break;
		else
			log "It isnt a gc100"
        fi

and the device creation line, like this:

curl -o /tmp/$IP.temp "http://127.0.0.1:49451/data_request?id=lu_action&$SERVACT&deviceType=urn:schemas-upnp-org:device:DigitalSecurityCamera:1&
UpnpDevFilename=D_DigitalSecurityCamera1.xml&UpnpImplFilename=I_PanasonicPTZ.xml&IpAddress=$IP&MacAddress=$MAC&StateVariables=
urn:micasaverde-com:serviceId:Camera1,Username=dceadmin%0Aurn:micasaverde-com:serviceId:Camera1,Password=dcepass&output_format=xml"

We’ll add this to the cmh_Pnp script for the next release.[/quote]

This is great, but as it is now it can’t be deployed (or removed) as part of a plugin.
Could you guys consider making this script pluggable - something that can be deployed as part of plugin installation? For example put new additions of the script into sequentially numbered files cmh_Pnp001, cmh_Pnp002, etc - and concatenate them on restart?

There are many devices that will benefit from LAN auto discovery. For example my lovely EtherRain sprinkler controller has dedicated auto-discovery service:

[quote=“www.quicksmart.com”]If the device was configured to receive a dynamic address using the DHCP protocol, the
address will generally not be known so the address can be found by using EtherRain’s
built-in discovery function.

EtherRain listens on port 8089 for UDP broadcasts containing the keycode string:

eviro_id_request1

When this keycode is detected EtherRain returns a confirming UDP packet to the sender. [/quote]

[micasaverde]

I came up with the following plan…

We implemented in Luup the concept of stateless, or event UPNP variables. UPNP doesn’t really have this concept since variables always model a current state, or value. There are a lot of circumstances where this isn’t enough. For example, with the ‘Device Discovered’ events. You need the event to “fire” whenever a device is discovered, and there has to be parameters with the event (IP, Mac Address, PCI bus, USB bus for usb devices, etc.). So the way stateless events work is that there’s a traditional UPNP event, but the value is a string, and the string contains XML tags. Your Luup plugin can use the ‘watch_variable’ hook to watch a variable.

I’m going to have the dhcp pnp script raise the event. Then your plugin can handle it. So the code would basically be that you register with ‘watch_variable’ for a ‘device detected’ variable. When a device is detected, your function is called and passed the ip/mac/etc. Then you can check the mac range, ping the device, etc., to decide if it’s something you want to handle, and if so, you can call the ‘create device’ action.

From a user perspective, say I buy a new IP camera. I go to ‘plugins’, add the plugin, then connect the camera and when the camera requests an IP, it will be added automatically.

[325xi]

@micasaverde

We implemented in Luup the concept of stateless, or event UPNP variables. UPNP doesn’t really have this concept since variables always model a current state, or value. There are a lot of circumstances where this isn’t enough. For example, with the ‘Device Discovered’ events. You need the event to “fire” whenever a device is discovered, and there has to be parameters with the event (IP, Mac Address, PCI bus, USB bus for usb devices, etc.). So the way stateless events work is that there’s a traditional UPNP event, but the value is a string, and the string contains XML tags. Your Luup plugin can use the ‘watch_variable’ hook to watch a variable.

Sounds interesting… ‘watch_variable’ hook is not documented yet if I’m not mistaken… a little example would be nice too

@micasaverde

I’m going to have the dhcp pnp script raise the event. Then your plugin can handle it. So the code would basically be that you register with ‘watch_variable’ for a ‘device detected’ variable. When a device is detected, your function is called and passed the ip/mac/etc. Then you can check the mac range, ping the device, etc., to decide if it’s something you want to handle, and if so, you can call the ‘create device’ action.

I wouldn’t bind it to DHCP… What about those users who don’t want to give up their trusty router? Most won’t, given that Kamikaze isn’t exactly the most user friendly UI out there.

@micasaverde

From a user perspective, say I buy a new IP camera. I go to ‘plugins’, add the plugin, then connect the camera and when the camera requests an IP, it will be added automatically.

Well, if not DHCP, the simplest way to trigger LAN scan for new devices would be a plain old button, somewhere in Devices page context - “Scan for new devices”. It would be fairly natural for most users as it would resemble Scan for hardware changes option in Windows Device Manager.
So user would connect whatever devices he wants, click on “Scan”, which would run the curl script, and if a new device is discovered it could trigger ‘Discovered’ event, and plugin would have to handle it just as you explained…

What do you think?

[micasaverde]

I wouldn't bind it to DHCP...

We modified the openwrt dhcp server and always listen for dhcp requests even if we’re not the dhcp server, and we always fire an ‘ip address’ detected when the device gets an IP address, whether we’re the dhcp server or not. If we’re not the dhcp server, we just listen passively without interfering. I think this is actually the only reliable way of finding new ip devices plug and play.

How would the ‘scan’ for new hardware work exactly? If the user is on a 192.168.x.y network you have either 256 or 65,000 possible IP addresses to search depending on the netmask. It can take 10 seconds or so to timeout on a ping or http request. So, even if the netmask is 255.255.255.0 it would still take around 40 minutes to scan. And what are you scanning for? Some devices don’t respond to ping. Others don’t respond to port 80 requests, and so on. So I don’t think there’s a really a way to scan a network for devices. When windows does it, it’s using WINS name resolution or UPNP. But that only picks up devices that listen to those 2 types of broadcast packets. Windows ‘network scanner’ won’t find, for example, a Panasonic camera. The only way to do that, I’ve found, is to listen for DHCP requests.

[325xi]

Great!
If it doesn’t require being THE dhcp server, this is by far the most elegant solution I could thing about.
I didn’t know passive DHCP sniffing possible on this platform…

Now if you could post (or wiki) the smallest example of use of this event…