When the photon has credentials executing WiFi.on the devide tries to connect automaticaly (mode SEMI_AUTOMATIC).
Shouldn’t this be only done after a WiFi.connect ?
Would be helpful if you stated what device OS version you are targeting?
I’ve definetly not seen this in the past.
I am with the 1.1.0.
It also, despite system thread is enabled, blocks for several seconds the code execution when loses connection/tries to reconnect
0000437484 [hal.wlan] INFO: Using internal antenna
0000437510 [hal.wlan] INFO: Joining TEST
0000437511 [hal.wlan] TRACE: Free RAM connect: 46064
0000444516 [hal.wlan] ERROR: wiced_join_ap_specific(), result: 1024
0000444516 [hal.wlan] INFO: Joining TEST
0000444517 [hal.wlan] TRACE: Free RAM connect: 46064
0000451632 [hal.wlan] ERROR: wiced_join_ap_specific(), result: 1024
0000451632 [hal.wlan] INFO: Joining TEST
0000451633 [hal.wlan] TRACE: Free RAM connect: 46064
0000458748 [hal.wlan] ERROR: wiced_join_ap_specific(), result: 1024
Can you provide a minimal test sketch that exhibits this behaviour on your devices?
When I try this with 1.1.0 on a Photon mine comes up only breathing blue (=WiFi on but not connected).
I've seen this too and AFAICT that's expected behaviour with the SEMI_AUTOMATIC/SYSTEM_THREAD combo (although I don't like it either - see this PR comment).
Can you try whether SYSTEM_MODE(MANUAL) behaves any different.
I tested with this and see the expected behaviour
#include <Particle.h>
SYSTEM_THREAD(ENABLED)
SYSTEM_MODE(SEMI_AUTOMATIC)
void setup() {
WiFi.on();
}
void loop() {
if (!Particle.connected() && !digitalRead(BTN)) {
Particle.connect();
waitUntil(Particle.connected);
}
}
I think I discovered the reason.
If I turn wifi off when the device loses connection (it is trying to reconnect) when I turn wifi module on, it continues with the routine of trying to connect.
And since its not attached to any wifi the command wifi.disconnect doesnt do anything.
Not exactly. When using SYSTEM_MODE(SEMI_AUTOMATIC) without SYSTEM_THREAD(ENABLED) once connected the system will behave just the same as in AUTOMATIC mode. It will stop executing your code entirely and try to reestablish the connection before doing anything else (including calling WiFi.disconnect()).
So it's not that
but WiFi.disconnect() is just not called.
However, if this was what you did to "provoke" the issue, the opening post did not disclose any of that but set a "misleading" context for anybody to advise. That's never helpful.
But I am using SYSTEM_MODE(SEMI_AUTOMATIC) with SYSTEM_THREAD(ENABLED)
The code is here.
Wifi.on() on the loop work as Particle.connect()
#include <Particle.h>
SYSTEM_THREAD(ENABLED)
SYSTEM_MODE(SEMI_AUTOMATIC)
void Second(void);
Timer second(1000, Second ,false );
int conect_counter=0;
int actual_counter=0;
bool disc=false;
SerialLogHandler logHandler(LOG_LEVEL_ALL);
void setup() {
WiFi.on();
Particle.connect();
second.start();
}
void loop() {
if (conect_counter!=actual_counter){
actual_counter=conect_counter;
Serial.println(actual_counter);
}
if (conect_counter==20){
conect_counter=0;
if(!WiFi.ready()|| disc ) {
disc=false;
WiFi.on();
Log.info("Wifi on");
}
else {
WiFi.off();
disc=true;
Log.info("Wifi off");
}
}
}
void Second(void){
conect_counter+=1;
}
1 Like
Yup, with this code I can confirm that this is not an expected behaviour.
At least in previous versions WiFi.off() did roll back the entire connection and a subsequent WiFi.on() did only that - switch on the WiFi module but no more.
I’d consider this an issue worth reporting on GitHub
However, in such cases it’s also advisable to test against the most recent pre-release version too to see whether this issue was already caught and fixed.
For the time being, you need to call Particle.disconnect() to prevent the auto-reconnect.
For some strange reason you don’t need to call WiFi.disconnect() tho’ - another indication that the behaviour is not intended this way.
I’ve now filed an issue
https://github.com/particle-iot/device-os/issues/1845
Interestingly, I’ve been just caught by something similar.
Semi auto mode, system thread. Device with no wifi creds, ie something sitting at the factory trying to be flashed.
We had a timer that would wait for 10s before calling particle.connect. This is because particle firmware/cloud used to (probably still does) have race conditions with setting particle.variable and function and calling particle connect. It worked seamlessly for years until somewhere after 1.1.0 (which works). 1.3.1 was the midway point I was testing after seeing 1.4.2 not working.
Connecting via serial yielded no debug output, guessing there is some code issue, possibly with calling System.on(network_status_connected, resetGetListenTimeout); when wifi isn’t on…
Solution, simply calling wifi.on() at the top of the setup block.
I wish the stuff they’re racing out for gen3 was a separate software train rather than coupling everything together and crossing fingers that the rush to fix gen3 issues won’t cause regression errors.
To be fair the documentation does say that you need to call WiFi.on() after changing system mode... which you did here
ref: https://docs.particle.io/reference/device-os/firmware/argon/#on--2
This is behaviour I still don’t agree with and hence have filed an issue a long time ago
I also added the respective notes in the reference docs to make people aware of the discrepancy between the behaviour known from Gen1&2 where WiFi.connect() and Particle.connect() ensured that all prerequisites would be taken care of implicitly.
I’d still rather have the “legacy” behaviour across all boards but lack of supporting comments of other users on that issue seems to send the signal that this might be not acually be impacting anybody than just the geekiest of nerds 
Hi ScruffR, I did see your threads here and on github. Life imitating art, code being change to reflect incorrect documentation.
What I understand to be facts:
- Post 1.1.1 the system has changed. Why break what wasn't broken?
- There are a medley of hard fault conditions when you mix wifi.on/connect and particle.connect sitting in a timer. In the main setup thread you can simply call particle.connect but that may not suit your use case. Either way its a major bug if the red lights start flashing.
- The clear documentation that particle.connect wraps the other wifi functions is wrong. See https://docs.particle.io/reference/device-os/firmware/photon/#particle-connect-
Sweet jesus. Can someone please fire the person who updated the argon documentation re particle.connect but not the Photon/P1 docu?
Note: Due to an open issue the automatic activation of the Wi-Fi connection is currently not working as expected. If the Wi-Fi module is not already powered up, your code needs to explicitly call
WiFi.on()before callingParticle.connect().
https://docs.particle.io/reference/device-os/firmware/argon/#particle-connect-
Nope, they can't fire me as I'm not an employee 
Also, prior that change (I wasn't aware that it also hits Gen2 devices now - let alone since when 
) the statement was entirely true and the note only valid for Gen3.
I added that note after I filed above issue as a heads-up for people who wouldn't expect the discrepancy between known/legacy behaviour and Gen3, anticipating this to be fixed and rendering that node null and void soon after.
I'd never have thought that the "felt to be wrong" behaviour would be promoted to become the new standard at any time.
Update:
I now also found your GitHub issue about this and respect your passionate stance and freedom to word it however you want but I also want to say I don't agree with the attitude
https://github.com/particle-iot/device-os/issues/1958
1 Like
You edited the argon docu? Ah wow, I’ve just spotted the edit button. Wish I’d known about that years ago, I’d have added the documentation the particle team never did on their nonsense way of their webhooks handing return http codes.
Re my github issue, what attitude? Ah, I know, the kid who still smells of uni textbooks who didn’t read the code and wanted to patronise me about thread safety? Yep, I spotted it.