Board ready not firing

[cat-haines]

My photon board seems to consistently timeout after the 'connection' event, but before the 'ready' event.

Here is the error I am getting:

[~/src/nodebots/johnny-five-build-light]$ node ./scripts/indicator.js
1458496181118 Device(s) particle-io  
1458496181719 Connected particle-io  
1458496191725 Device or Firmware Error A timeout occurred while connecting to the Board. 

Please check that you've properly flashed the board with the correct firmware.
See: https://github.com/rwaldron/johnny-five/wiki/Getting-Started#trouble-shooting

If connecting to a Leonardo or Leonardo clone, press the 'Reset' button on the board, wait approximately 11 seconds for complete reset, then run your program again.  
events.js:146
      throw err;
      ^

Error: Uncaught, unspecified "error" event. ([object Object])
    at Board.emit (events.js:144:17)
    at Board.log (/Users/cathaines/src/nodebots/johnny-five-build-light/node_modules/johnny-five/lib/board.js:630:8)
    at Board.(anonymous function) [as error] (/Users/cathaines/src/nodebots/johnny-five-build-light/node_modules/johnny-five/lib/board.js:641:14)
    at Board.<anonymous> (/Users/cathaines/src/nodebots/johnny-five-build-light/node_modules/johnny-five/lib/board.js:418:14)
    at Timer.listOnTimeout (timers.js:89:15)

This is the code producing the error:

var five = require("johnny-five");
var Particle = require("particle-io");

var board = new five.Board({
  io: new Particle({
    token: process.env.PARTICLE_TOKEN,
    deviceId: process.env.PARTICLE_DEVICE_ID
  })
});

board.on("ready", function() {
  console.log("Ready...");
});

I've verified the environmental variables are set (and the board doesn't connect if they're not set). I also checked that I'm running the latest version of Johnny-Five and voodoospark:

[~/src/nodebots/johnny-five-build-light]$ npm list --depth=0
johnny-five-build-light@1.0.0 /Users/cathaines/src/nodebots/johnny-five-build-light
├── johnny-five@0.9.34
└── particle-io@0.12.0

And that my device is connected, and running voodoospark:

[~/src/nodebots/johnny-five-build-light]$ curl https://api.particle.io/v1/devices/$PARTICLE_DEVICE_ID/endpoint\?access_token\=$PARTICLE_TOKEN
{
  "cmd": "VarReturn",
  "name": "endpoint",
  "result": "10.10.120.131:48879",
  "coreInfo": {
    "last_app": "",
    "last_heard": "2016-03-20T17:50:46.178Z",
    "connected": true,
    "last_handshake_at": "2016-03-20T17:48:57.079Z",
    "deviceID": "2e0030000547343232363230",
    "product_id": 6
  }
}%   

Not sure where to go from here. This might be related to #56, but I wasn't sure if the proper etiquette was to open a new issue, or comment on an old one so I did this (sorry if it's wrong).

[rwaldron]

Thanks for filing this, I will try to look at it later today, if not tomorrow!

[rwaldron]

I think this might have been caused by a recent change to the timeout handling, so that's where I'm going to start

[rwaldron]

I actually have a brand new, unopened Photon, so I will use that for testing.

[rwaldron]

Unfortunately, I'm unable to connect the new Photon (or an older one, or a Sparkfun Photon RedBoard) to the network in our office. Usually I work from home, but not today. I will have to wait until I'm back home to try this again. Sorry for the further delay :\

[cat-haines]

No worries!! Let me know if there's anything I can do on my end to help diagnose the issue :)

[Resseguie]

I have a new Photon I need to break out and test, too. So I'm happy to assist here as well. Likely will be tomorrow though before I can jump in.

[rwaldron]

@Resseguie thanks, that would definitely be appreciated.

@cat-haines something that crossed my mind... When you hit this issue, what was different about the environment that you were in? I had seen your tweets, and also from the workshop you gave, which I hope meant this was successful—so I wonder what changed? Anything you can think of might be useful :)

[cat-haines]

@rwaldron - I actually ran the workshop with arduinos and just talked about what would be different with a Photon. This was my first attempt at getting it to work :)

I was at a coffee shop with open wifi when I was experiencing the issues.. though I had no problem connecting to the device to flash firmware or make basic requests.

[rwaldron]

I was at a coffee shop with open wifi when I was experiencing the issues..

I believe this is actually the issue—I've had people describe similar scenarios in the past. I will do some digging and follow up. Thanks again for the additional details (and your patience)

[rwaldron]

After consulting with @gnarf, I'm now confident in my previously hinted at suspicion:

I believe this is actually the issue

The issue is that particle-io and voodoospark eliminate the cloud service once the board has been "located" and create a direct TCP client/server socket to eachother. It's very likely that the coffee shop that you were at has their wifi network configured to block devices from talking directly to each other. This is likely done in the name of security (and probably for good reason). Unfortunately, the cloud service is unacceptable for our data transfer needs, as it incurs an insuperable latency cost (and simply doesn't support streaming to the node.js program).

[creationix]

Is there a way to run the board in AP mode and skip the cloud alltogether? Your laptop could then just connect directly to the board on a well known IP address (though this would mean no internet while developing).

[cat-haines]

@rwaldron: Cool - I'll verify this when I get home this evening, and submit a PR with additional information in the Getting Started section since it sounds like a few people have encountered this issue before :)

[rwaldron]

@creationix direct connections via access point support would be nice, but I don't presently have time to work on that.

[rwaldron]

and submit a PR with additional information in the Getting Started section

Awesome!!

[cat-haines]

Sorry for the delay on my end - I can confirm this was an issue with the WiFi network.. so I'll go ahead and submit a PR for a docs change!

[rwaldron]

This issue actually lead to a bunch of maintenance on the network configs at both @bocoup offices, so thanks for dragging it out into the light :)