These are pings.
Ther’s some info about what these codes mean here…
I think the Cmd Error is because the previous data sent by the device was odd…
And the server responded that it didn’t understand. I’m not sure what caused this, but it seems to be device side (outgoing data) rather than a server side issue.
Maybe posting your code would help to identify possible causes.
It seems that you have Blynk debugging enabled, and also core level debugging via the IDE. This is handy for debugging, but probably not ideal for long term use as it adds to the device’s overhead.
I was born and raised around the Derbyshire/Nottinghamshire border and worked as a photographer for British Coal, based out of Bestwood, back in the late 70’s and 80’s. Eventually moved to London in the early 90’s, but still have friends and family in the area, so visit now and again.
I know it well. I had a friend in the 70s who worked at the Bestwood workshops on some pretty heavy electrical control systems. A very useful contact when we need meaty electronic components!
I noticed that the above repeated, and failing, (around every second) IP requests to the cloud would result in a call to my 1 second event.timer subroutine about every 10 seconds.
That routine also toggles the watchdog and would be sufficient to keep it alive and preventing a forced re-boot. After a couple of minutes of failed requests, the below happens and the calls to the event.timer then revert to every second - along with watchdog toggling.
So my strategy fails!
I need to add an if (Blynk.connected) before my watchdog toggling, I think.
[hostByName] Host: blynk.cloud IP: 159.65.55.83
[600917] Connecting to blynk.cloud:8080
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud IP: 159.65.55.83
[606925] Connecting to blynk.cloud:80
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud IP: 159.65.55.83
[612929] Connecting to blynk.cloud:8080
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud IP: 159.65.55.83
[618934] Connecting to blynk.cloud:80
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud IP: 159.65.55.83
[624937] Connecting to blynk.cloud:8080
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud lookup error: No response (-5)!
[624949] Connecting to blynk.cloud:80
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud lookup error: No response (-5)!
[624954] Connecting to blynk.cloud:8080
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud lookup error: No response (-5)!
[629949] Connecting to blynk.cloud:80
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud lookup error: No response (-5)!
[629955] Connecting to blynk.cloud:8080
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud lookup error: No response (-5)!
[634950] Connecting to blynk.cloud:80
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud lookup error: No response (-5)!
[634956] Connecting to blynk.cloud:8080
[hostByName] request IP for: blynk.cloud
[hostByName] Host: blynk.cloud lookup error: No response (-5)!
Yes. That confirms that my original watchdog strategy was flawed.
I only tested it by turning off the hotspot - i.e. the wifi.
This results in continuous attempts to connect the wifi within void loop but NO timer.run().
If I’d tested it like just now with a wifi connection, but no internet, I’d have discovered that time.run() is called (but very much delayed) initially, but then, after the ‘No response (-5)’ event, it is called at full speed. Thus my watchdog is maintained…
So now I know why my remote system was not re-booted and what state it is currently in.
Back to the drawing board…
I’d still like to know why my system, in its original form, would fail occasionally. It seems like Blynk.run() is not entirely bombproof when the internet connection is unreliable.
Here is a shortened version of my code:
#define BLYNK_TEMPLATE_ID ""
#define BLYNK_TEMPLATE_NAME ""
#define BLYNK_AUTH_TOKEN ""
#define BLYNK_PRINT Serial
#define BLYNK_DEBUG //shows comms with wifi/server
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
char auth[] = BLYNK_AUTH_TOKEN;
// Your WiFi credentials.
char ssid[] = "";
char pass[] = "";
// Definitions
float volts = 0;
//On board relays - High to operate
int SolarRlyOff = LOW; //D2 Low = Relays 1&2 OFF N/C used
int BattRlyOff = LOW; //D1 Low = Relays 3&4 OFF N/C used
bool watchdog;
BlynkTimer timer; //create a Blynk Timer object
// This function is called every time a Virtual Pin state changes via app
BLYNK_WRITE(V0) //Battery Switch (1 = off = relay op'd)
{
// Set incoming value from pin V0 to a variable
int BattRlyOff = param.asInt();
if(BattRlyOff==HIGH) //ensure that if batt is disconnected, solar is too
{
digitalWrite (D2,HIGH); //turn off Solar if Battery turned off
}
digitalWrite(D1,BattRlyOff); //and set Battery relay
}
BLYNK_WRITE(V3) //Solar Switch (1 = off = relay op'd)
{
int SolarRlyOff = param.asInt();
digitalWrite(D2,SolarRlyOff);
}
}
void myTimerEvent() //Called every second
{
volts = analogRead(A0); // reading the analog i/p every second
Blynk.virtualWrite(V6,volts*12/786); // volts=786 @12v
BattState = digitalRead (D1); //0 = relay off on main board = solar/batt ON (n/c contacts)
SolarState = digitalRead (D2); //current state of solar and battery relays
if(BattState==HIGH) //ensure that if batt is disconnected, solar is too
{
digitalWrite (D2,HIGH);
}
//Watchdog
if (WiFi.status() == WL_CONNECTED) // Toggle D8 every second to keep Watchdog fm forcing reset
{
watchdog = !watchdog;
digitalWrite (D8,watchdog);
}
Blynk.virtualWrite(V1, !BattState); //can't find a way of inverting LED state on app
Blynk.virtualWrite(V4, !SolarState);
}
void setup()
{
Serial.begin(115200);
Serial.print("Restart Hougham23a... "); // Version *****************************
Blynk.begin(auth, ssid, pass);
timer.setInterval(1000L, myTimerEvent);
pinMode(D1,OUTPUT); //Battery
pinMode(D2,OUTPUT); //Solar
pinMode(D7,INPUT_PULLUP); //Volts
pinMode(D8,OUTPUT); //Watchdog
digitalWrite(D1,LOW);
digitalWrite(D2,LOW);
}
void loop()
{
Blynk.run();
timer.run();
}
Just noticed I had included a check for wifi connected prior to toggling the watchdog! So timer.run() may well be being called in both scenarios, after all. So will try adding a check for Blynk connection as well.
TBH, because Blynk.begin() is a blocking function, I think you’d be better managing your WiFi connection manually then using Blynk.config to define your Auth token, server, port etc and Blynk.connect(timeout) to initiate the Blynk connection.
Here’s a bit of code that I created for something else, but that shows how the process works…
/* Fill-in information from B;ynk Web Console > Device > Device Info here..
These three lines of code MUST be at the top of your sketch */
#define BLYNK_TEMPLATE_ID "REDACTED"
#define BLYNK_TEMPLATE_NAME "REDACTED"
#define BLYNK_AUTH_TOKEN "REDACTED"
#define BLYNK_PRINT Serial
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
// Your WiFi credentials.
// Set password to "" for open networks.
char ssid[] = "REDACTED";
char pass[] = "REDACTED";
// ADJUST THESE SETTINGS TO SUIT YOUR NEEDS:
// The longer you wait between WiFi connection attempts and the more attempts you have,
// the more time your device will be tied-up if the WiFi network is down.
// The longer the Blynk timeout is, the more time your device will be tied-up if the Blynk server can't be reached
// The more frequently you check if your devoice is connected to WiFi and/or Blynk then the more frequently the
// situations described above will occur if the device is not currently connected to WiFi and/or Blynk
int wait_between_wifi_attempts_millis = 750;
int max_wifi_connect_attempts = 20;
int blynk_timeout_millis = 2500;
int check_connections_frequency_seconds = 30;
BlynkTimer timer;
void setup()
{
Serial.begin(74880);
Blynk.config(BLYNK_AUTH_TOKEN);
connect_to_wifi();
connect_to_blynk();
timer.setInterval(check_connections_frequency_seconds * 1000,check_connections);
}
void loop()
{
if(Blynk.connected())
{
Blynk.run();
}
timer.run();
}
void connect_to_wifi()
{
int wifi_attempt_count=0;
Serial.println(F("Connecting to Wi-Fi..."));
WiFi.mode(WIFI_STA);
if (WiFi.status() != WL_CONNECTED)
{
WiFi.begin(ssid, pass); // connect to the network
}
while (WiFi.status() != WL_CONNECTED && wifi_attempt_count < max_wifi_connect_attempts) // Loop until we've connected, or reached the maximum number of attempts allowed
{
delay(wait_between_wifi_attempts_millis);
wifi_attempt_count++;
Serial.print(F("Wi-Fi connection - attempt # "));
Serial.print(wifi_attempt_count);
Serial.print(F(" of "));
Serial.println(max_wifi_connect_attempts);
}
// we get to this point when either we're connected to Wi-Fi, or we've tried too many times. We need to do different things, depending which it is...
if (WiFi.status() == WL_CONNECTED)
{
WiFi.mode(WIFI_STA);
Serial.println(F("CONNECTED TO Wi-Fi"));
Serial.print(F("Local IP Address = "));
Serial.println(WiFi.localIP());
Serial.println();
}
else
{
// we get here if we tried multiple times, but can't connect to WiFi...
Serial.println(F("CONNECTION TO WiFI FAILED - IN STAND-ALONE MODE"));
// find failure reason and add in here?
}
}
void connect_to_blynk()
{
if (WiFi.status() == WL_CONNECTED)
{
Serial.println("Connecting to Blynk...");
Blynk.connect(blynk_timeout_millis); // Try to connect to Blynk, but timeout after pre-defined time
if(Blynk.connected())
{
Serial.println("CONNECTED TO BLYNK");
}
else
{
Serial.println("FAILED TO CONNECT TO BLYNK - IN STAND-ALONE MODE");
}
}
}
void check_connections()
{
if (WiFi.status() != WL_CONNECTED)
{
connect_to_wifi();
}
if(WiFi.status() == WL_CONNECTED && !Blynk.connected())
{
connect_to_blynk();
}
}
The code doesn’t do anything other than connect to WiFi and Blynk and check those connections on a regular basis.
If you wanted to throw-in an ESP.restart() at the point when you hit “standalone mode” then that might help in your case.
The Blynk.connected() test in the void loop is to prevent the device constantly trying to re-connect to Blynk if it’s in standalone mode, but may not be needed for you if you do a restart in that situation.
The workshops at Bestwood were quite impressive. Some very heavy duty equipment was overhauled there, and it’s amazing how many ways the pits would find to break things
Thank you Pete.
I live in an ex-pit village.
All villages are required to have two sources of electrical power for redundancy, but a pit village would have one source for domestic and the other solely for the pit.
Normally motor sizes are restricted to 100hp direct-on-line (DOL) starting, but the NCB were permitted to start heftier motors DOL.
If our normal supply was interrupted, we’d be switched to the pit supply. You always knew when this happened as the lights would regularly dim as those big motors spun up.
And yes, a breakdown was a great excuse for a break (except for the maintenance crew…).
Hi Pete, Thanks for your help. I integrated your connection checking code into mine and, so far, no problems after a week. I see one 6 minute off-line reported over the week, but it recovered okay.
I can only assume that the problems occur due to the relative unreliability (ping times can vary up to a second and longer, on occasions) of the 3G data link. This seems to be the only variable that is random and completely unpredictable. Seems like the Blynk libraries might not be100% bombproof in these situations?
I’ll continue to monitor the situation and report here if I learn anything new.
Thanks again (your help here on the forum is absolutely invaluable - I hope our Blynk people recognise this).
Dave
Glad to hear that things are more reliable. Whilst I’m sure that the Blynk libraries aren’t perfect, I suspect that the issues you’re experiencing are more to do with your mobile ISP than Blynk.
Yes, I get a free PRO subscription for the work I do on the forum, which is fine by me.
I’ve marked this as “Solved” (but the topic is still open) as I think your initial problem is now solved. Feel free to add more feedback or issues in future.
'Appen…
Soon after my previous tiding of good news, there was a break of a few hours.
But the better news is that it did eventually recover. (By itself.)
I did go on site on Sunday and discovered more anomalies - but mainly with the router.
It is forced into 3G mode (after confirming that 4G is worse in every respect).
Whilst attempting to perform Speedtests, it would often often fail either to initially connect to the test server, or perform a satisfactory download speed test, then crash out before the upload test.
There was an internet connection - I could download video and my cameras were successfully uploading video - but Speedtest would fail.
At the same time, IoT was in a reset loop, successfully connecting to the WiFi, but when requesting the Blynk IP address on port 80, then port 8080, no response was forthcoming.
Eventually, there would be a response and comms would resume.
When I look at the Timeline on my Blynk App, I can see periods of off-line, but always resuming on-line at xx:21. This corresponds to my last boot-up at 15:21 on Sunday - I check for good connection every hour! It must be doing a full reset at that point as it will be failing the WL_CONNECTED bit in both the hourly called check_connections, and subsequently in connect_to_blynk, when I do a software reset (and the hour timer is also re-initialised).
So, many thanks for your excellent help, and your correct assumption that it is my router which is at fault.
Cheers, Dave
