Wifi.on or Wifi.connect?

photon
Tags: #<Tag:0x00007fe21ecd36a8>

#1

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 ?


#2

Would be helpful if you stated what device OS version you are targeting?
I’ve definetly not seen this in the past.


#3

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


#4

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);
    }
}

#5

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.


#6

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.


#7

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;
}

#8

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