Go Down

Topic: How to reconnect the MKR to WIFi (Read 9383 times) previous topic - next topic

D6equj5

@ D6equj5

Did you do the firmware update ?

That fixes almost all the connection issues.Even my BETA version MKR is exceptionally stable since the upgrade.



Excellent, thank you. No I did not "do the firmware upgrade" (presumably not a dance). 
I gave as much info, to go on, as was necessary. Usually I found giving lots of unnecessary code, distracts the helper into critisising the coding style and belittling the requester so I tend not to give code where not necessary.
Thanks again.
Thank you
D6

ballscrewbob

It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

Hoffmakl

I don't understand how you solve the problem.


I'm using:
  • - MKR1000 - ATMEL 2015 AMW25-MR510PB Rev.R3
  • - IDE 1.8.10.0
  • - WiFi101 Firemware WINC 1501 Model B (19.5.2)  - current available firmware


I have found that the status (status = WiFi.begin(ssid, pass);) always remains in the staus == WL_CONNECTED.
(as described by Aquaponics2016)

When I reboot my Router (WiFi - Access Point for the MKR1000) - the status is "WL_CONNECTED"  and will not changed to WL_CONNECT_FAILED, or WL_CONNECTION_LOST or WL_DISCONNECTED.

After the reboot of the router the WiFi connection will not be re-established.
Is that works as designed?
- no experience with C++, my first steps with MKR1000 -

iirArduino

Hi,
I'm having a very similar problem. I have 2 MKR Wifi 1010 and 2 ESP8266 communicating through my WiFi.
I have a Mosquitto MQTT broker in my Raspberry Pi to exchange messages between the MKRs and ESPs.
The 2 ESP8266 work without any problems, but the 2 MKRs get blocked after a few hours.
The MKRs are sometimes able to reconnect, but after some hours in the end they fail and get blocked. It's not anly that they don't reconnect, but the also stop working with the rest of the code.
I've updated the firmware in both MKRs, but no improvements.

Has anybody found a way to reconnect always?


Code: [Select]

#include <WiFiNINA.h>                          // For the ESP8266 I've used ESP8266WiFi.h
#include <PubSubClient.h>


const char* ssid = "CASA4";
const char* password = "mypassword";
const char* mqtt_server = "192.168.0.192";
const int LED_VERDE = 7;                          // Pin for LED green.
const int LED_ROJO = 8;                           // Pin for LED Red.
const int PULSADOR = 9;                          // Pin for the pushbutton.
unsigned long instante = 0;                       // For the debounce.
boolean gatillo = LOW;
int veces = 0;                                    // To count the times I connect to the WiFi.
long lastReconnectAttempt = 0;

WiFiClient espClient;
PubSubClient client(espClient);                

char msg[50];                                     //************--------------do I need this? ***
String clientId = "mkr01";          

void basculo() {
  digitalWrite(LED_ROJO, gatillo);
  if (gatillo == HIGH) {
    client.publish("mkr01/pulsador", "1");       // Publish "1" in "mkr01/pulsador" topic
  }
  else {
    client.publish("mkr01/pulsador", "0");       // Publish "0" in "mkr01/pulsador" topic
  }
  Serial.println(gatillo);
  gatillo = !gatillo;
}

void setup_wifi() {                      // Connect to WiFi.
  delay(10);

  Serial.println();
  Serial.print("Conectando a ");
  Serial.println(ssid);

  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  randomSeed(micros());

  Serial.println("");
  Serial.println("WiFi connected");
  Serial.println("IP address: ");
  Serial.println(WiFi.localIP());
}

void callback(char* topic, byte* payload, unsigned int length) {    
  Serial.print("Incoming message: [");
  Serial.print(topic);
  Serial.print("] ");
  for (int i = 0; i < length; i++) {
    Serial.print((char)payload[i]);
  }
  Serial.println();

  // Switch on the green LED if a 1 was received as first character
  if ((char)payload[0] == '1') {
    digitalWrite(LED_VERDE, HIGH);
  }
  else {
    digitalWrite(LED_VERDE, LOW);
  }
}

boolean reconnect() {
  if (client.connect("mkr01")) {    
    // To see how many times do I re-connect:
    veces++;
    Serial.print("Veces re-conectado: ");            
    Serial.println(veces);                          

  // Once connected, publish an announcement...
    client.publish("mkr01/pulsador", "MKR01 connected ");
    // ... and resubscribe
    client.subscribe("+/pulsador");          // Subscribe to all topics that contain "pulsador".
  }
  return client.connected();
}


void setup() {

  pinMode(LED_VERDE, OUTPUT);
  pinMode(LED_ROJO, OUTPUT);
  pinMode(PULSADOR, INPUT_PULLUP);
  Serial.begin(115200);
  setup_wifi();
  client.setServer(mqtt_server, 1883);
  client.setCallback(callback);
  client.subscribe("+/pulsador");
}

void loop() {
    //  ***********This comes from the example 'mqtt_reconnect_nonblocking'
    if (!client.connected()) {
      long now = millis();
      if (now - lastReconnectAttempt > 5000) {
        lastReconnectAttempt = now;
        // Attempt to reconnect
    reconnect();
    if (reconnect()) {
          lastReconnectAttempt = 0;
        }
      }
    }


 client.loop();                                                    

  if (millis() > instante + 250) {                      // wait 250 ms for debounce.
    if (!digitalRead(PULSADOR)) {
      basculo();
    }
    instante = millis();
  }
}

gbafamily

Code: [Select]
if (client.connect("mkr01")) {

Every mqtt client must use a different/unique client name. mosquitto blocks clients with duplicate names. This is true for ESP and MKR.

iirArduino

Yes, this I know. I have different names: mkr01, mkr02, esp03 and esp04.

clambert68

#21
Apr 20, 2019, 09:29 am Last Edit: Apr 20, 2019, 09:30 am by clambert68
Hello guys,


there is a "problem" in the documentation.

if you try to reconnect with this code :

Code: [Select]

while ( status != WL_CONNECTED) {
   Serial.print("Attempting to connect to WEP network, SSID: ");
   Serial.println(ssid);
   status = WiFi.begin(ssid, keyIndex, key);

   // wait 10 seconds for connection:
   delay(10000);
 }



it will never reconnect.
- While status is different of WL_CONNECTED, it try to connect. The status connection is stocked in "status" variable.
- When connected, this status will be WL_CONNECTED forever, because you will never enter in this loop again to change the variable value

The solution may be to add this line after the loop to update the wifi status.

Code: [Select]

while ( WifiStatus != WL_CONNECTED ) {

   Serial.print("Connexion au SSID : ");
   Serial.println(ssid);

   WiFi.begin(ssid, pass);
   delay(10000);
 }
 WifiStatus = WiFi.status();


If you don't want to check the WiFi.status(); every time arduino run the loop, you can check every X second.

Globaly =

Code: [Select]

int WifiStatus = WL_IDLE_STATUS;
int lastNetworkCheck = millis(); // Now
int networkCheckInterval = 1 * 60 * 1000; // 1 minute


And in your connect function :

Code: [Select]

 while ( WifiStatus != WL_CONNECTED ) {

   Serial.print("Connexion au SSID : ");
   Serial.println(ssid);

   WifiStatus = WiFi.begin(ssid, pass);
   delay(10000);
   lastNetworkCheck = millis(); // Reset the last check time at Now
 }
 if (lastNetworkCheck + networkCheckInterval < millis()) {
   WifiStatus = WiFi.status();
   lastNetworkCheck = millis();

   if (WifiStatus == WL_CONNECTED) {
     Serial.println("Checking WiFi Network... The connection status is OK !");
   }
   else {
     Serial.println("Checking WiFi Network... The connection status is BAD... :(");
   }
 }



We will check every 1 minutes the connection status and then, print the result to the Serial.
If the status changed, the code enter in the while loop and try to reconnect.

This connect funciton is trigger in setup() and loop() function.


Code: [Select]

09:23:08.501 -> Valeur : 0.00
09:23:08.501 -> Intensity : 0 > 0
09:23:18.615 -> Checking WiFi Network... The connection status is OK ! <<<<<<<<<<<<<<
09:23:24.128 -> 1191.71 Lux
09:23:24.128 -> Prise de luminosité suite au PIR
09:23:24.128 -> Valeur : 0.00
09:23:24.128 -> Intensity : 0 > 0
09:23:41.073 -> 1165.22 Lux
09:23:41.073 -> Prise de luminosité suite au PIR
09:23:41.073 -> Valeur : 0.00
09:23:41.073 -> Intensity : 0 > 0
09:23:53.011 -> GAZ BURN
09:23:53.389 -> GAZ BURN
09:23:53.763 -> GAZ BURN
09:23:54.138 -> GAZ BURN
09:23:54.513 -> GAZ BURN
09:23:54.854 -> GAZ BURN
09:23:55.232 -> GAZ BURN
09:23:55.609 -> GAZ BURN
09:23:55.983 -> GAZ BURN
09:23:56.358 -> 1218.81 Lux
09:23:56.358 -> Prise de luminosité suite au PIR
09:23:56.358 -> Valeur : 0.00
09:23:56.358 -> Intensity : 0 > 0
09:23:56.358 -> GAZ BURN
09:23:56.736 -> GAZ BURN
09:23:57.110 -> GAZ BURN
09:23:57.486 -> GAZ BURN
09:23:57.864 -> GAZ BURN
09:23:58.205 -> GAZ BURN
09:23:58.583 -> GAZ BURN
09:23:58.959 -> GAZ BURN
09:23:59.339 -> GAZ BURN
09:23:59.714 -> GAZ BURN
09:24:00.088 -> GAZ BURN
09:24:00.461 -> GAZ BURN
09:24:00.836 -> GAZ BURN
09:24:01.214 -> GAZ BURN
09:24:01.555 -> GAZ BURN
09:24:01.934 -> GAZ BURN
09:24:02.312 -> GAZ BURN
09:24:02.688 -> GAZ BURN
09:24:03.065 -> Read module...
09:24:03.065 ->  ##################  Free RAM =
09:24:03.065 -> 24663
09:24:03.065 -> 1191.71 Lux
09:24:03.443 -> Temperature = 22.59 *C
09:24:03.443 -> Pressure = 985.45 hPa
09:24:03.443 -> Humidity = 42.43 %
09:24:03.443 -> Gas = 309077.00 KOhms
09:24:03.443 -> Gas Baseline :250000.00
09:24:03.443 -> Temperature = 22.59 *C
09:24:03.443 -> Humidity = 42.43 %
09:24:03.443 -> Pressure = 985.45 hPa
09:24:03.443 -> Gas = 309077.00 KOhms
09:24:03.443 -> Gas Baseline :250000.00
09:24:03.443 -> IAQ = 98.99
09:24:03.443 -> Reply : date:201904192026;pir:1804874lum:1191.71tmp:22.59hm:42.43pr:985.45gas:309077.00iaq:98.99
09:24:03.443 ->  ##################  Free RAM =
09:24:03.443 -> 24639
09:24:03.443 ->  ##################  Free RAM =
09:24:03.443 -> 24663
09:24:11.352 -> 1218.81 Lux
09:24:11.352 -> Prise de luminosité suite au PIR
09:24:11.352 -> Valeur : 0.00
09:24:11.352 -> Intensity : 0 > 0

<<<<<< Here i cut the Wifi

09:24:18.604 -> Checking WiFi Network... The connection status is BAD... :( <<<<<<<<<<<<
09:24:18.604 -> Connexion au SSID : Synology <<<<<<<<<<<<
09:24:31.129 -> Connexion au SSID : Synology <<<<<<<<<<<<
09:24:43.641 -> Connexion au SSID : Synology <<<<<<<<<<<<

<<<<<< Here i switch on the wifi

09:24:56.188 -> Connexion au SSID : Synology <<<<<<<<<<<<
09:25:16.193 -> 1246.53 Lux
09:25:16.193 -> Prise de luminosité suite au PIR
09:25:16.193 -> Valeur : 0.00
09:25:16.193 -> Intensity : 0 > 0
09:25:31.207 -> 1218.81 Lux
09:25:31.207 -> Prise de luminosité suite au PIR
09:25:31.207 -> Valeur : 0.00
09:25:31.207 -> Intensity : 0 > 0

ela55

Hello,
I have been experiencing the MRK1000 losing its connection. Varies between every 2 to 4 days.
I have read many posts about this issue and upgrading the firmware.
  I came across this post and clambert68 has said makes the most sense to me.  After reviewing the wifi101 example code I have been using it only connects during setup.  There is nothing in the main loop to reconnect?

I intend to try what clambert68 has suggested.  I am very curious now to understand how this code could ever have expected to have stayed connected without something in the main loop to reconnect?
Is it assumed that the wifi will never drop out?

voske65

Im experienced same problems with re-connecting the MKR1000.
The while loop (WifiStatus != WL_CONNECTED), seems not always to work, as WL_CONNECTED stays active (3) even when the wifi connection is gone.
I have 2 suggestions:
1. : Add a Rssi (signal strength) in your check. Rssi is normaly -30 to -80, if disconnected it returns 0 or -100 out of experience...
2. : Add a timer to your while loop to prevent for-ever-while behavior (general recommendations to avoid while loops)


Code: [Select]
 
       byte t=0;
       while ( status != WL_CONNECTED) || (WiFi.RSSI() <= -90) || (WiFi.RSSI() ==0) ) { 
       // attempt to connect to WiFi network:
       status = WiFi.begin(ssid, pass);     // Connect to network.
       delay(4000);                                // wait 4 seconds for connection:
       if( t++ < 5) break;                        // try-counter 5 times max
  }


The problem I still face is that my WebServer  (defined as WiFiServer server(80);) is not activated after a reconnect,  using server.begin(); does not help.  Is there a statement to re-activate your server(80) ?

Fyi: When running this code on a Wifi1010 (NiNa board), the reconnect always works incl server.

ela55

I am still having the reconnect issue as well. I was waiting to post, after having made changes to include attempts to reconnect from within the main loop.  I am using the technique Clalmbert68 mentioned.   This time it ran 8 days before dropping out.  But did not re-establish itself from within the main loop.

I also had the concern that Voske65 did - not knowing of the Wifiserver(80) would need to be re-established.

Anyone here with good Ethernet protocol knowledge that can help with what the solution to this issue may be?

clambert68

@ela55 I'm sorry that my code doesn't resolve your issues.

In my case, the arduino mkr1010 is up for 1 month without any problem.

What about your logs ? Let the arduino connected to you computer and try to look at your log.
Print all information about wifi every 10min for exemple, and print the connection status, and reconnect tries.

The problem is the wifi connection only ? Or there is a webserver or something like this ?

ela55

Hello Clambert68,
Thank you for your input.  By logs to you mean serial output?
The issue has been that my project is not located near a computer so I have been unable to access serial debugging capability.
    I have not had time to address this  issue since a reboot will reconnect and so I have been rebooting about once every 8 days or so.

I understand that I will need to get more serious in my debugging of the issue.    When I can I will move the project to a location that will allow me to connect to the computer and print out serial debugging information. I will then experiment with interfering with the  wifi signal in order to force a reconnect.

I guess I should try updating the firmware also.


ela55

I am still fighting this issue.   Finally got around to putting in serial debug code and monitoring that way.
I have two MKR1000 units exhibiting this issue.   One had been firmware upgraded and the other was not.  Upgraded both to 19.5.2.   Both still exhibited issue.
     I had already added a reconnect attempt in the main loop.
When a dropout occurred the status went to 6 and the unit did indeed reconnect.  Status was now 3.
I could look in the router and MKR1000s were both online.  Yet I could not connect via the web server on either.  Could ping them both.
     Was also monitoring signal strength and it never went to 0 or <-90.

So it looks like having the main loop check is a must so that it does at least reconnect but the web sever still did not work.   I added the  server.begin();    after the main loop check to reconnect and will continue to monitor.
I will see if I have any better luck than you Voske65.

ela55

After adding the server.begin() to the main loop recovery routine I purposely rebooted the router to test and the reconnect routine worked fine.

I have been running now for 13 days on two different MKR1000's with no disconnects.

    While it would seem things are now fixed I figured I would jinx it by posting. :)

I was monitoring via serial for 10 days and never experienced any reconnect attempts.  I have debug variables that would tell me if a reconnect had happened and none have occurred.  These variables show in both the serial and wifi debug printouts.
Until I see that variable change I am still unsure all is fine. I do now feel that the code will be robust in reconnecting - as long as the wifi status changes away from 3 at some point.
     I am also monitoring and reporting an rssi debug variable.   RSSI never dipped below -81 on either device thus far.

In addition to retries (in the 10 second loop) I also added a 30 minute reset to the retries counter.  This was  so that if the router is down for a while, that the retries will get reset every 1/2 hr.

Hopin for the best now.


ela55

I did indeed jinx it. A day later one of the 2 stopped working. Debug showed status was  still at 3 and rssi was 0.
I was only monitoring rssi and not acting on it as part of the reconnect routine.  And so no reconnect of course.  Did add that now.

If Voske65 is still checking in... have you had some luck?   I now fear the that server.begin() may not work under this unusual condition of rssi = 0, whatever it is.   As you had encountered.

Next time it happens it sure would be great to have an additional thing to try or something else  to monitor. 

Go Up