Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Argon/Boron] Particle.connect() doesn't call WiFi./Cellular.on() #1631

Open
ScruffR opened this issue Dec 9, 2018 · 2 comments

Comments

@ScruffR
Copy link
Contributor

commented Dec 9, 2018

On Photon/P1/Electron Particle.connect() implicitly also powered up the radio module when it was off.
That's currently (0.8.0-rc.25) not happening for the Argon (Boron not tested but probably too)

@avtolstoy

This comment has been minimized.

Copy link
Member

commented Dec 10, 2018

I would appreciate if you could provide a minimal example app showcasing the issue. Was WiFi/Mesh.disconnect() or WiFi/Mesh.off() called as well? Is the device in AUTOMATIC or some other mode?

We have multiple network interfaces on Gen 3 devices and in order to simplify the manual management of cloud and network connections the current behavior is for the user application to explicitly enable the necessary network interfaces.

@avtolstoy avtolstoy added the mesh label Dec 10, 2018

@ScruffR

This comment has been minimized.

Copy link
Contributor Author

commented Dec 10, 2018

I can do.
WiFi.off() was called, but not Mesh.off() in AUTOMATIC mode.
No x.disconnect() was explicitly called.

However

We have multiple network interfaces on Gen 3 devices and in order to simplify the manual management of cloud and network connections the current behavior is for the user application to explicitly enable the necessary network interfaces.

Since there usually is only one cloud radio (WiFi or Cellular) on each device and Particle.connect() requires the cloud radio to be on, an implicit on() call to the one and only radio that relates to it doesn't appear to impair the managability of the connections (same would go for Mesh but that's not focus of the issue, but rather the discrepancy between Gen1&2 vs. 3 behaviour in respect of common cloud radio behaviour).
Needing to call additional functions in order to achive one goal doesn't really seem to be simplifiying things - rather the opposite IMO.
Also, having Gen3 devices behave differently than Gen1 & 2 on intersecting matters seems more confusing than simplifying too IMO.
Imagine taking a Photon sketch one-to-one to a standalone Argon (e.g. in a Classic Adapter, no mesh required) as a drop-in replacement and then the previously running code doesn't anymore (for something that needn't behave differently).

One may argue that a Argon/Boron in an Ethernet shield doesn't need to power on the cloud radio, but that should rather be treated as edge case which should be addressed separately - after all it already has its special treatment in the app and currently concurrency between Ethernet and radio isn't addressed at all AFAICT.

ScruffR added a commit to particle-iot/docs that referenced this issue Jan 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.