If you have no contact to the cloud you need to run a non-AUTOMATIC SYSTEM_MODE and not try to Particle.connect() but only WiFi.connect() - after switching the WiFi module on via WiFi.on().
Yes! I want a solution for this as well. I use the photon with a local server. If there’s no Internet, it should still work with the local server and not keep resetting its WiFi.
I'd dare to contradict. That's a solution, you just have to lay out the rest of your project right.
My original statement states a prerequisite and is not a fix in its own righ and it doesnot break local network use cases by itself either.
You check for internet connection (or loss thereof) and act accordingly before the "safety net" hits.
When you look at the log timestamps you get a feeling about the time you've got to take matters in your own hand before the system jumps in.
BTW, the OP has stated his network has NO internet connection, so for his demand that also is the solution, I'd think.
Am running in SEMI_AUTOMATIC_MODE, but I am calling Particle.connect() within setup() and in loop() as part of the @rickkas7 strategy described within my ticket:
I had added Particle.connect(); to this block (not realising the WiFi disconnect side effect until your comments above).
case WIFI_STATE_CONNECTED:
// Do any one-time initialization here like calling udp.begin() or tcpServer.begin()
Log.info("WiFi connected");
// Also connect to the Particle cloud
Particle.connect(); // <=== I added this....
wifiState = WIFI_STATE_RUNNING;
break;
So, a solution is, as you said, don't call Particle.connect() for this use case. Too easy!
That said, @Elco's point regarding "great to have Particle cloud when it is there" is also a very good point, so it would be nice to solve that problem.
@Elco, wondering if this sorts out your request: pinging some external IP and only if you get a successful return, call Particle.connect()? Something like this:
if (!Particle.connected())
{
int rc = WiFi.ping(IpAddress(8,8,8,8));
if (rc > 0)
Particle.connect();
}
@UMD, your ping approach would have been the way on my mind too.
You just also need to monitor the cloud connection and issue a Particle.disconnect() as soon you see a “persistent” loss of connection to prevent the system from trying to reestablish the desired (connected) state over and over eventually running into the failsafe which assumes the WiFi module must have some issue and resetting it to cure this “non-issue” (which the system doesn’t really know is not the cause).
Update:
I just read up on that “old” thread and as it turns out @rickkas7’s solution from back then silently accepts the fact that consistently failing cloud-connection attempts will eventually also reset the WiFi module. But since his client/server combo seems to not rely on persistent connections that’s fine for that use case.
But if you require a persistent connection or have any other reason to avoid a WiFi disconnect at all cost, extra work will be needed.
BTW, since actual WiFi outages have to be considered inevitable, explicit, graceful management of these situations may also need some thought. Just as with the cloud connection silently accepting the loss of WiFi connection is possible since the system does have some “brute force” failsafe in place, but then you may need to put up with the side effects of that too.
Funny thing is that the reason for the ticket was because of UDP listener issues I was having (going away and not coming back). Research revealed another @rickkas7 gem:
The reason is that when WiFi disconnects, all of the listeners are removed
So, this underlying problem has been solved.
Am going to mark this ticket as solved because you have ably answered the "how to stop" question. Agree, further work could be done.
Sorry, that could indeed be a solution for his issue.
My point should be that the solution Particle chose "reset the entire WiFi stack if there is no cloud connection" will make the device go haywire when the LAN loses Internet. What I'd like to have is a solution that connects to the Particle cloud if possible but doesn't go haywire if it can't.
Wow, this might explain my problems with the TCP server. My system can go into a state where the TCP server is not accepting new connections. I have set it up to listen for new connections and drop the existing connection on a new connect. But I see a problem with the connection being refused or time out after a while, even though the device still responds to ping. Perhaps the WiFi reset is related.
Would it be possible to handle wifi disconnects with system event hooks?
Letting the particle system thread handle it in the background doesn’t seem to work.
With an event hook I could:
Completely destroy the TCP server and clients and recreate them when wifi comes back
Possibly prevent the system thread from blocking the whole system. (Why is this even the case, damn).
I have spent my entire weekend debugging Particle WiFi again. This shouldn’t be my job Particle, it should be yours. Please take over.
Here is a bug report that contains my test code, which prints out a lot of helpful system state to debug WiFi issues. It is also my best effort yet to maintain a TCP in bad conditions.
And here is a new issue for the topic of this thread:
I am trying to build a demo application that:
Communicates over TCP without the Particle cloud
Doesn’t crash when WiFi goes down temporarily
Reconnects when WiFi is back up
Doesn’t stop working when there is no cloud connection
Can use a cloud connection when it is available.
Doesn’t block the application loop under any circumstances
Direct link to the code:
If others want to join me in my battle, I can split off the code from the BrewPi repo into its own repository so it is easier to fork. The current version works fine on Intranet only, but as soon as a Particle.connect() call is added, the system will keep resetting WiFi until the cloud is back (issue #1491 above)