I have noticed the “Online since” statistics in the app are showing that all of my devices are reconnecting fairly often. I am using mostly Nodemcu esp8266 devices on the public Blynk servers. I have devices both at home and at our cabin and would be using different ISP providers. The devices are not rebooting and are generally extremely stable. It doesn’t matter what code I am running I see the same thing. It isn’t causing any data issues as there dont appear to be any data gaps. Would changing the BLYNK_MSG_TIMEOUT help?
Same here. They know about it. I am sure will be fixed
It is already fixed. New release will be available soon.
Thanks for the info. No action required on my part then?
Correct. No action from your side.
Thank you Dmitriy.
I am still seeing this behavior on my devices. What was going to change? And has that change happens yet?
I know this is an old topic but for me this was never fixed and is still happening today as we speak. I am using esp core 2.4.2 and Blynk 0.5.4 libraries connected to blynk cloud.
What App version?
Dont think it matters but I am using app 2.27.1 on Android 8.1.0.
Since Blynk functions with all three, App, Server and Library… then yes, in operation and troubleshooting, ALL the info matters.
And on that note…
…how are you determining that the device is in fact NOT losing momentary communication to the server? I believe this online stat refers to the device’s last connection (probably to Server, but possibly to App, perhaps via heartbeat?) Not just whether the device has rebooted or looses stability or not. You could simply be seeing networking issues?
I am fairly confident the devices ARE losing contact with the server. The devices are not rebooting as I monitor the last reboot reason and it remains as hardware reset which is the reset button. I get the same behavior at both my locations that are running different wifi equipment (telus modem and orbi) and different providers(telus and show)
Ummm…OK so what is the issue? I understood that you thought that the online indicator was incorrectly showing disconnected even when devices were stable… but now you say that you do believe they are losing connection… which means the indicator is doing it’s job.
PS I just checked, and most any WiFi based device I have shows “disconnected” in last hour… while they themselves have not actually rebooted, nor is my WiFi / network connection showing any issue… I conclude that my heavily congested WiFi is simply burping and the indicators are indicating as such. I use Local Server.
So is this a “incorrect online indicator issue”, in which case I will just leave you (and the developers) to your topic or a “why are they ‘losing’ connection” issue, in which case we can try other troubleshooting.
The issue is why are the devices losing contact with the server so often? It is causing Blynk.connected() to fire everytime it happens and causes needless additional traffic when it resyncs various virtual pins.
OK, so nothing like your OP title and indicated as possibly faulty “Online since” statistics issue…
Well, the “why” could be local interference. I see similar when it is heavily raining… go figure (yes, I know how 2.4GHz can be affected by humidity ), but also my microwave and even neighbouring WiFi can cause statistically notable issues (if not practically notable). Heck I have even see sympathetic reconnection issues from nearby ESP8266 devices when manually resetting one of my more troublesome (always disconnecting and not reconnecting) ESP32 devices.
As long as it is not a constantly repeating many times in a short span type thing, I suspect you are just seeing the reality of wireless and internet connectivity. That is WHY we recommend reconnection routines and other failsafe coding… we can’t control the airwaves and 3rd party networks like we may wish too.
No arguments here but I suspect wifi drop out issues should be effectively handled at the hardware layer. It is interesting to hear you are experiencing this even with a local server. I will run a test with a local machine and a local esp8266 device that simply moves data around using TCP and UDP transport layers and monitor to see if there are any issues. If I were to guess there wont be any but I will report back. To me this seems like a blynk issue, albeit very minor as it doesn’t affect the devices in pushing or pulling data.
Like saying rush hour traffic slowdowns should be resolved by faster cars
I don’t actually see it in normal operation (using Blynk, thanks to its built-in connection protocols, as well as my added in ones)… I just know it is there from this and other topics that had me looking closer…
And NO it is not a Blynk specific issue, I also see it with more intrusive results on my Virtuino sketches, and on some of my WiFi based IP cameras.