How to get the RSSI of the current connection?

Hmm that's interesting, from the documentation

WiFi.RSSI() returns the signal strength of a Wi-Fi network from -127 (weak) to -1dB (strong) as an int. Positive return values indicate an error with 1 indicating a Wi-Fi chip error and 2 indicating a time-out error.

Doesn't that seem to indicate that WiFi.RSSI() returns an int?

You said it right, it seems so, but what the eye sees isn’t always what’s real :wink:

1 Like

It seems to behave like an int in any code I've ever written. I can use it as the return statement in a Particle.function, I can use it in a Particle.variable, and the code that @incorvia posted works fine for me. So, I can't explain why it doesn't work for him. Have you seen this problem if you don't cast to int8_t?

The WiFiSignal object has an overload so that when you assign it to an int8_t or equivalent it does the right thing and returns an integer type. So in your code if you did this it would work:

char rssi[10];
int strength = WiFi.RSSI();
sprintf(rssi, "%i", strength);
Serial.println(rssi);
1 Like

@Ric, since there are only three overloads for Particle.variable() and only one of them takes a parameter that can be matched by the compiler with the available (int8_t) overload it works.
As long the compiler can make a match it will try to, but with sprintf() there is no way to do match against.

So, why does this work for me then. It seems to be the same thing that @incorvia is saying doesn’t work for him,

char rssi[10];

void setup() {
    Serial.begin();
}

void loop() { 
    
    sprintf(rssi, "%i", WiFi.RSSI());
    Serial.println(rssi);
    delay(5000);
}   

I’d have to try it out but I would think it shouldn’t work for you either.
Although, what system version are you running? It might well be that this extra layer of abstraction was introduced more recently.

1 Like

I'm using the default, 0.7.0.

1 Like

For reference I am running PARTICLE_VERSION=0.8.0-rc.4

1 Like

Can you try building against 0.7.0?

1 Like