Adding a "bypassCloud" parameter?

[BrianGenisio]

I'm thinking of adding a opts.bypassCloud configuration parameter. When set, it will use the opts.host and opts.port parameters instead of retrieve it from the cloud endpoint. I'll write the PR, but I wanted to talk about it first.

The goal is to allow for devices that have a predictable enough IP address on the local network (due to MAC address reuse at the router) to not need the internet to get the local address. I'm thinking of this as a way to solve unreliable internet connections at conferences.

The opts.bypassCloud option isn't specifically necessary. The presence of opts.host and opts.port should be enough. I can see pros and cons to having the opts.bypassCloud option.

In addition, I'll probaby add an event to the IO class that tells us the host/port when it DOES get it from the cloud so that the user store it.

Thoughts?

[dtex]

In the event that the device is unreachable using opts.host and opts.port will it:

1. Fail and notify user of the likely cause

or

2. Automatically hit the cloud for the new host info and warn the user (and emit the event).

Both seem reasonable, just wondering.

[BrianGenisio]

Here is what I think:

If we go with the explicit bypassCloud: true, then failure will be failure.
If we go with the implicit {host, port}, then failure will try to get it from the cloud endpoint

The code currently makes it seem like you can define the host and port, but right now, it doesn't actually use the user-supplied values. The more I think about it, the more I like the implicit mechanism.

[BrianGenisio]

To argue with myself, this feature could create chaos.

Scenario: The internet becomes unreliable at an event, and the organizer tells them to use the known IP address. The IP addresses change for some reason. People are now controlling each others' bots.

I can see that being a pretty big problem. A deviceId/handshake could help with that... but now it gets complicated.

[dtex]

Whoah! I didn't know that. You don't need some kind of key or unique identifier to connect to a device via VoodooSpark?

[BrianGenisio]

No. If you have the IP:Port, that is all you need to know to control the device. You need the deviceID/accessToken in order to retrieve the IP:Port from the cloud endpoint... but not to connect to the device on the local network. So the bypassCloud option could solve one problem, and create another at a big event.

[rwaldron]

If...

new Particle({
  host: ...,
  port: ...
});

Can that imply "bypass the cloud"?

[dtex]

No. If you have the IP:Port, that is all you need to know to control the device.

I wish I had known this when battling @makenai in Sumobots

[BrianGenisio]

@rwaldron Most definitely. I'm just trying to figure out if we want an implicit or explicit interface. Or if this is something I should do at all.

[rwaldron]

@BrianGenisio got it. It's definitely worth investigating

[canda]

Perhaps we may use the cloud service to confirm the ip address if
available, or add a new function to the firmware to get the device id

El lun, 28 de septiembre de 2015 12:21, Rick Waldron <
notifications@github.com> escribió:

@BrianGenisio https://github.com/BrianGenisio got it. It's definitely
worth investigating

—
Reply to this email directly or view it on GitHub
#67 (comment)
.

[tylergraf]

How do I get the port of my photon on a local cloud? Is it the CoAP port defaulting to 5683?