This project is read-only.

Dealing with Gadgeteer device IP and connecting to the driver

Dec 2, 2013 at 11:03 PM
Edited Dec 2, 2013 at 11:04 PM
Hi,

I am wondering how does the device IP is set to the gadgeteer device. Following the example provided in Lab_of_Things_Gadgeteer.pdf I can log something like:

{"light" : 387.09677419354836
"DeviceIP" : "192.168.173.91", "DeviceId" : "HomeOSGadgeteerDevice_LightSensor_MicrosoftResearch_43965876879683988593", }

(BTW: In this document is written that "The Gadgeteer device will also log its IP address", but it won't. I addedd that information above because in the example in the documentation there isn't any)

Unfortunatelly after restarting AllDevices solution and deploying it again I get different DeviceIP and Devices.xml config file is not up to date without possibility to connect to this device properly.

Two things:

1) Is it OK? Is the doployment only the beginning step for doing it only once after which we have to scan for devices again and change Devices.xml file?

2) When I do the steps:
  • connect the gadgeteer device through USB to the computer
  • run AllDevices solution and deploy my module to the gadgeteer device
  • save DeviceIP address that was logged and change the IPAddress attribute in the Devices.xml config file to that one
  • stop the AllDevices solution
  • run the platofm
  • connect the gadgeteer device to the power somewhere else (not to computer through USB)
...should it work properly and still connect with the platform? I mean - should the scout find it or should I do anything more?

Thanks in advance,
Kamil
Dec 3, 2013 at 6:18 PM
Kamil -

The IP in Devices.xml is updated automatically through the scout. If your device gets a different IP, the scout will find the new IP and update Devices.xml. You can verify that this is happening. The scout fires off discovery every 30 seconds I believe, so give it at least that much time. You don't need to manually change Devices.xml.

Let us know if what you are seeing a different behavior.

Cheers.
Dec 3, 2013 at 7:02 PM
Edited Dec 3, 2013 at 7:12 PM
Hi,

Thanks for the answer, unfortunatelly the behavior is different...

a) In case there is IPAddress attribute set in Devices.xml it always returns it in method
DriverGadeteerBase::GetDeviceIp(string deviceId)
and tries to use it in my WorkerThread at the beginning

string url = string.Format("http://{0}/light", deviceIp); // without result of course when the IP of the device have been changed.

b) In case there isn't any IPAddress set in Devices.xml file the DriverGadgeteerBase (in Start() method) just logs:
     //get the IP address
        deviceIp = GetDeviceIp(deviceId);
       if (deviceIp == null)
        {
            logger.Log("{0} did not get a device ip for deviceId: {1}. Returning", base.moduleInfo.BinaryName(), deviceId.ToString());
            return;
        }
and doesn't start WorkerThread at all.
In fact at the end in WriteDeviceList() method the Devices.xml config file is finally written again but with the empty IPAddress....so you say it should find the right IP? from where?
Dec 3, 2013 at 7:21 PM
Edited Dec 3, 2013 at 7:40 PM
According to my last question: should it be found in GadgeteerScout::ScanWifi() method by
                       SocketFlags socketFlags = SocketFlags.None;
                        EndPoint endPoint = new IPEndPoint(IPAddress.Any, 0);
                        IPPacketInformation packetInfo;
                        byte[] buf = new byte[2000];
                        int bytesRead = client.Client.ReceiveMessageFrom(buf, 0, 2000, ref socketFlags, ref endPoint, out packetInfo);
??
Unluckily I get exception every time here:

"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"

so I suppose something is wrong, because from the DeviceAll solution (run in another Visual Studio) there is logged:

"Sending UDP broadcast on port 48467 in response to UDP packet from 192.168.173.1:48468"
and
"Sending unsolicited UDP beacon since we're on a setup network"
Dec 3, 2013 at 7:45 PM
Yeah, that (not being able to discover the device in ScanWifi) seems to be your problem.
  1. The first thing I would check is if the gadgeteer device and the hub are on the same wireless network. Are they?
  2. If it is not joining the wireless network, you'd need to debug that. If you are playing with a USB-based gadgeteer devices, then the wireless credentials are sent by the hub to the device when connected over USB (see ScanUSB), then the device joins the wireless network, and then it is discovered over WiFi.
  3. If the device is successfully joining the wireless network, you'd need to understand why it is not responding to discovery probes.
Hope this helps. Keep us posted as you make progress or get stuck.
Dec 3, 2013 at 8:38 PM
Edited Dec 3, 2013 at 8:39 PM
Ad.1 - Device is surely hosted 'setup' wifi network because I got messages in AllDevice solution log:

Joining WiFi network setup rssi 62
WiFi up with AP setup

the same is with Hub (I think!) because I changed even in Settings::AssignDefaultValues() the credentials from

WifiSsid = String.Empty;
WifiKey = String.Empty;

to those standard (held in starthostednetwork.bat).

Should I bother and do anything else?

Ad.2. I have my device connected throught USB but it contains also Wifi module. Should it still find anything in ScanUSB method? Unfortunatelly I figured out that SerialPort.GetPortNames() function does not return anything...(an empty list of portName and it seems not OK for the first look..;/)
Dec 3, 2013 at 9:38 PM

Sorry, I misled you a bit. I was assuming that you are using the USB-based method for pairing the gadgeteer device, but no, you are using the WiFi-only method.

In this method, the Hub hosts a “setup” network. The gadget joins this network. The hub discovers the gadget on this network, and then sends it the credentials of the home wifi network. The gadget disconnects from the setup network and joins the home network. The hub discovers the gadget on the home network. Pairing is now complete and the driver can use it. Part of this process is driven through the dashboard. The gadgeteer documentation explains it in more detail.

It seems that your hub is hosting the setup network and the gadget is joining it. Please make sure there aren’t two such hubs in the vicinity.

You shouldn’t change the credentials in AssignDefaultValues. Those credentials are for the home wifi network, not the setup network.

Can you please try the following, after the gadet and hub have been completely reset?

1. Start platform

2. Go through dashboard and setup the home wireless network

3. Power on the gadget, wait for it to join the setup network.

4. Go to Add Devices in the Dashboard

Do you see the gadget in the list there, after the scan is complete?

Marked as answer by kamilhawdziejuk on 12/4/2013 at 2:24 PM
Dec 4, 2013 at 9:38 AM
Hi,

A few notes. While I didn't write the Gadgeteer scout, whenever we've demoed it we have nto manually specified any IP addresses (for the WiFi-based setup network association method OR the USB serial-based association method). So either something's become broken with the latest release, or that should work.

The USB association method will only work if there is a serial-USB Gadgeteer module in the device, and that module is plugged into the PC. It seems you are only plugging in one USB connection to the PC, which is the USB client module, for programming/debug. So you should not expect USB serial association to work (but you should be able to get the WiFi association to work hopefully!)

To verify that the Gadgeteer devices and the hub are on the same network, you can try pinging the Gadgeteer IP from the hub, it should respond. Then I suggest using a network sniffer (e.g. http://www.microsoft.com/en-us/download/details.aspx?id=4865 ) to see what the behaviour of the UDP packets is - is the scout sending them? Is the Gadgeteer device responding?

You should be able to tell if the Gadgeteer device is receiving any UDP traffic through the debug output. Can you share the debug output?

Ta
James
Marked as answer by kamilhawdziejuk on 12/4/2013 at 2:24 PM
Dec 4, 2013 at 6:15 PM
Edited Dec 4, 2013 at 7:49 PM
Firstly - thanks a lot for the support! I am widening my knowledge about a system much faster now...

Ratul -

I made the steps and I haven't seen the gadgeteer device on the list BUT I figured out that I made implicitly a step nr 0. which was running 'starthostednetwork', so I did it in another order and then I finally saw the gadtheteer device on the list :). This order was:

1A. StopTheHostedNetwork.
1.-4. The same steps as you described them

here I got in log:

{"light" : 320.62561094819154
"DeviceIP" : "0.0.0.0", "DeviceId" : "HomeOSGadgeteerDevice_LightSensor_MicrosoftResearch_43965876879683988593", }
wifiTimer start - currentAP (null) wifiUp False

and (of course) still wasn't able to search device by a scout

4B. I run StartTheHostedNetwork.

then I got in log:

Web server started at http://192.168.173.206:80/

{"light" : 317.69305962854349
"DeviceIP" : "192.168.173.206", "DeviceId" : "HomeOSGadgeteerDevice_LightSensor_MicrosoftResearch_43965876879683988593", }
wifiTimer start - currentAP setup wifiUp True IP 192.168.173.206

and finally I got it.

But it took me some time to stop the hosted network (the step 1A) ;] Maybe I haven't focused on it during reading documentation but I don't know why the order matter here...


OK, but I have stucked just in another step because the page with setting credential showed up:
"Gadgeteer Setup: Determining next setup step"
"Please enter secret key:"
and nothing happens when I enter my passwords (NetworkWifi, helloworld or even my homeID password). Now I am trying to find...what is needed here??
Dec 4, 2013 at 7:45 PM
Edited Dec 4, 2013 at 7:48 PM
James -

When I do the steps decribed above I can ping 192.168.173.206 from the Hub (e.g. from GadgeteerScout::ScanWifi() method) with the result OK but in this method later on I get errors with sending UDP packages because
                        int bytesRead = client.Client.ReceiveMessageFrom(buf, 0, 2000, ref socketFlags, ref endPoint, out packetInfo);
ends with the exception that I mentioned before:
"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"

I fired Wireshark soft to sniff the packages and it seems like there are some tries:
(TIME , SOURCE , DESTINATION , INFO) ---> columns
96 27.035311000 192.168.173.206 255.255.255.255 UDP 114 Source port: patrolview Destination port: 48469
98 28.511713000 192.168.0.15 255.255.255.255 UDP 44 Source port: 48468 Destination port: 48468
99 28.510235000 192.168.173.1 255.255.255.255 UDP 44 Source port: 48468 Destination port: 48468
102 28.556611000 192.168.173.206 255.255.255.255 UDP 114 Source port: patrolview Destination port: 48467
109 30.481758000 192.168.173.1 192.168.173.255 UDP 82 Source port: 49152 Destination port: sentinelsrm
110 32.035429000 192.168.173.206 255.255.255.255 UDP 114 Source port: patrolview Destination port: 48469


I think that the problem is just about the credentials becase in GadgeteerScout::SendWifiCredentials method I got ERRORauthKey as a result of entering those passwords I descibed in earlier post...
Dec 4, 2013 at 8:23 PM
Edited Dec 4, 2013 at 8:24 PM
OK, I figured it out that this credential should be those set in HomeOSGadgeteerDevice constructor..."abcdefgh" ;)
Marked as answer by kamilhawdziejuk on 12/4/2013 at 2:24 PM
Dec 4, 2013 at 9:16 PM
I think you figured it out! Let us know if you run into anything more. Thanks for posting your updates.
Dec 4, 2013 at 10:15 PM
Edited Dec 4, 2013 at 10:16 PM
Yes :) and it is just great!

After deploying it again I got automatically in log:

{"light" : 190.61583577712611
"DeviceIP" : "192.168.0.10", "DeviceId" : "HomeOSGadgeteerDevice_LightSensor_MicrosoftResearch_43965876879683988593", }
wifiTimer start - currentAP UPC0047455 wifiUp True IP 192.168.0.10

and now the device is achievable from anywhere in home without running AllDevices solution (just a platform);) Thanks a lot!