ESP8266 hangs in Cayenne.loop when WiFi Connection is lost

i am not sure where you are going wrong. @rsiegel can you help here with this.

I think I got it. There is a much simpler solution. All I need is this:

if (WiFi.status() == WL_CONNECTED) { Cayenne.loop(); }

This works for me now!

No - I need to take that back. It does not work reliably. Sometimes it works, sometimes it does not. I guess it only works, if the WiFi is lost, while the ESP8266 executes outside of the Cayenne.loop. If WiFi is lost, while ESP8266 executes already inside the Cayenne.loop it still hangs. Also using ticker and interrupt does not work, because after executing the ISR routine, the control is simply returned to the Cayenne.loop, and the system continues to hang…Any other ideas?

My suggestion would be to start a millis timer and reset the timer every loop. if it hangs for more than x seconds call a reset for the board.

Tried this already. Does not work either, as the “Cayenne.begin” routine, which is executed during setup is also written in a way, that it hangs up indefinitely, if no WiFi is present. Besides that, I found that the ESP8266 does not reset reliably neither with ESP.restart() nor with ESP.reset() - there are several discussions of this problem in various forums.

I examined the Cayenne libraries. In the CayenneArduinoMQTTClient.h, there is a function “connect()”, which contains a do/while loop, that looks like the one causing the problem:

do {/ attempt to connect; delay(1000); /}
while (error != MQTT_SUCCESS);

it looks to me, that if I could replace this with an equivalent for-loop, which counts up to 10 executions, this could work as some timeout, if after 10 seconds there is still no connection possible. I just have not figured out, how to jump out of the Cayenne.loop function in that case. Would be grateful, if anybody has an idea here - unfortunately I am not very skilled in programming…

I will take a look at it and see what I can come up with. I modified the blynk connection method to do that over here so it should be possible.

Yes, I have seen a few people posting about this. Might be better to just put the ESP is deep sleep mode (also in the link above)

This must be an MQTT issues since I don’t remember seeing that behavior in the blynk connection method. Again, I’ll take a look and see if I can get it working.

I really need to update the battery powered ESP project page so maybe I’ll take some time to update it to the officially supported MQTT connection method while I’m testing these things.

Any progress, I’m working a esp8266 project and worried about the same issue …

Hello community. Im from Russia. At first sorry for my english.
Now i working at my project - smart fan with remote control on esp8266 node mcu 12e. Fan relay controls at main (loop) of sketch.
I planned to use cayenne for remote monitoring.

But faced with problem:

When internet - is ok, everything is ok. But when internet connection is lost, all sketch is freezing.

After many trying i understand that freezed cayenne.loop.

I try to use enable flag ( ping - is a little better. But sometimes freze still.

Is anybody knows how solve this problem?
Is anybody knows alternative method to sent information to cayenne server.
Because problem with looping in checking internet connection in cayenne loop.

Internet is the most important when doing IOT project. So when the internet is lost, you cannot remote monitor your project.

I have solved this with an Interrupt Service Routine (ISR), which is executed every 2 seconds. If the system is hung up in the Cayenne loop, a watchdog counter is incremented each time the ISR is called. After the counter reaches 4 (means the system hangs in the Cayenne loop for 8 seconds), key variables are written to the EEPROM and the ESP8266 executes a reset by software. If the internet still is not available after restart, at least the setup code gets executed, before the system again hangs in the “cayenne.begin” loop and 8 seconds later another reset occurs. This game is continued until the internet comes back and normal execution resumes. The problem with the hung up Cayenne loop is, that it never recovers, even when the internet connection comes back. This ISR solution solves that problem. Credit for that solution goes to Andreas Spiess ( Here are the relevant code pieces:

#include <CayenneMQTTESP8266.h>
#include <EEPROM.h>
#include <Ticker.h>  // Watchdog timer

// other definitions
volatile int watchdogCount = 0; 
Ticker secondTick;

void setup() {
  EEPROM.begin(16); // Reserviere 16 bytes EEPROM
  // further setup code
  secondTick.attach(2, ISRwatchdog); // Call Watchdog ISR every 2 seconds
  Cayenne.begin(username, password, clientID, ssid, wifiPassword);

void loop() {
  watchdogCount = 0;
  // Program Loop code //

void ISRwatchdog() {
  if ( watchdogCount >3 ) {
     EEPROM.end(); // commits write to EEPROM
     ESP.reset(); // resets ESP8266
1 Like

Great work @mike2506red and the guy with swiss accent. though how can the project run locally?

Well, as you say, @shramik_salgaonkar, it makes no sense to run an IOT project without internet connection. However, often there are situations in which the WiFi connection fails for just a few minutes. And there the solution has 2 benefits:

  1. Even though the internet hangs, the ESP8266 can execute some critical code in the first part of the init-routine (before the cayenne.begin statement). In my case reading a temperature value and taking action to keep that temperature, even though there is no internet connection. Of course I cannot manipulate the temperature target through the Cayenne interface nor monitor the actual temperature, but at least the value is kept within the target range during the internet downtime.

  2. And this is the more important part: Usually the WiFi connection just fails for a few minutes - either there is a router problem or the signal becomes weak for some reason. However, once the internet connection is lost, the cayenne.loop will hang indefinitely - even after the WiFi connection recovers. The only way to get the program back running is to physically press the reset button on the ESP8266 - not a good solution. First, it can potentially take a long time, until the user notices the hangup, second some important variables might get lost and third the ESP8266 might not be easy to reach.


Thank you very much for you answer. But i dint understand. This method only for restarting. But how control ( read sensor and control relay) in period from 0-8 sec. it is not imposible ind this method?
I didnt understand…

Ok i have lost_internet_key_var , why i can not put cayenne.begin() in IF(lost_internet_key_var =1) statement?

And i worried about session writing Eeprom memory? After 2 seconds? Lifetime esp will be not more 1 year… am i right?

not possible in this method.

what do you mean by this?

yes, with 100,000 write cycles. it will eventually die.

Just to clarify the last point: I am not writing to EEPROM every two seconds.If you check the code, you will see, that it only writes to the EEPROM when the system hangs up and needs to be reset - which happens in my configuration about once or twice per week.

he meant to say if there is no connection for a longer time, it will keep on writing.

Yep. If connection lost for a long time.
Wil be better if will be possible to send request to mqtt broker like udp. Without confirm. Without loop function. But as is…

In this case at this moment for my application ( fan cooling the basement) cold better than warm. Because my gadget turns to on before winter manually (220 power plug).

Method with resetting i already made at last winter. But in my case reseting will be every 10 seconds and after resetting push fan pin to 0 - signal to turn on the Fan. ( push gadget to safety position without any controls) Now i decide to upgrade before next winter. Because winter is coming © ))

I thinking about that after half-year cayenne guys update lib and solve this problem. But… no way…

you can add your sensor and actuator control in the ISR if it something small control you are doing.

Read date from 18ds20 and control relay? I think this spent more time than cycle of watchdog timer…