I’ve made an industrial style machine that streams it’s process to an external MQTT server. I’m using SYSTEM_MODE(MANUAL) so I can turn on important devices such as display and fans before I allow the P1 module to connect to the internet. This all works fine, but if the machine looses connection during it’s process - it will block application code while reconnecting.
I know that SYSTEM_THREAD(ENABLED); can resolve this (with some caveats), but I would much rather just get notified that the connection dropped (via an event) so that I can handle the reconnection at a time it suits me and the process.
I am sure that this is an option that many others also could benefit from. From that I understand this should be a fairly simple thing to implement?
Why do you not want to use SYSTEM_THREAD(ENABLED)? What do you see as the caveats?
I use SYSTEM_MODE(SEMI_AUTOMATIC) and SYSTEM_THREAD(ENABLED). I then have complete control to Particle.connect() and Particle.disconnect() or WiFi.connect() and WiFi.disconnect(). Particle.connected() will tell if the cloud connection is active.
I’d second an option to opt-out of auto-reconnect like WiFi.connect(bool autoReconnect = true) or Particle.connect(bool autoReconnect = true) - independent of SYSTEM_MODE.
When explicitly calling on of these with false a droppen connection should get terminated gracefully and no auro-reconnect should follow.
Instead of a bool this could also be a number of seconds for resuscitation attempts after which the connection is just terminated.
What @ScruffR describes sounds the ideal way to me, we should be able to focus on our application and not managing the wireless connection. Mind you I also think the default should be that the device run user code regardless of whether WiFi is operational.
For this we'd have SYSTEM_THREAD(ENABLED) and non-AUTOMATIC modes and we have to accept that this is a single core controller where some elaborate tasks will demand some considerable time.
And for the majority of users, the fire-and-forget default as it is now is what they want. The others with higher demands need to walk the extra mile but are usually also capable to.
It's always a compromise tho'
That's a very good approach and it's very easy to make it backward compatible also since it's an optional parameter that defaults to the current behaviour.
Any idea how we could make this option a reality? Is it something I could implement myself that I could hand off to Particle as a pull request? I have a product that is almost ready for certification, but I cannot deliver something for testing that just stops to do it’s task because the Wifi is dodgy.
@ScruffR I found a way to solve this! Upon detecting a loss of connection, I can turn the Wifi module off. I can then just turn it back on at a time it suits my software. Here is a sketch that shows this working: https://go.particle.io/shared_apps/5980b8dc3863f75737001080
Do you see any reason that this is a “bad way” of doing this?
Not “a bad” way per se, but in some circumstances (especially with Electrons) the radio module might get stuck in a limbo state if you turn the module off at a bad point.
This should be fixed in 0.7.0 tho’
If you can file an issue and a PR on github, Particle might pick up on the reconnect flag.
@jenschr, your “TRY_TO_CONNECT” state will try forever from what I see. You may want to create your FSM with a switch() statement and create a millis() timer for states to timeout. I’m not sure but if the Photon attempts a certain number of retries, does it not do System.reset()… @ScruffR?
Yup, that’s what I’ve also done for other projects.
Try to reconnect a few times, on frequent fail power down radio module (after clean disconnect), wait and repower/reconnect, after some more failures disconnect, power down radio and System.reset() and as last instance, try a disconnected deep sleep for a longer time (in case the previous reconnect attempts upset the WiFi AP or cellular provider).
AFAIK, the device doesn’t do a System.reset() by itself anymore - there were versions where this happened or Listening Mode was entered.