Can anyone tell me why this message is issued. Under what circumstances? And what the impact is of the message being issued?
Just so I know where to start looking.
I have a complex sketch which as it grew it issued the error more often and started missing stuff i.e. widget updates. The main loop is simple! I am using simpletimer
I then cut it right down so it was just looping with one timer on 10sec and that code I cut out so it was just executing a blank procedure. I got the message before it entered the first running of the timer procedure. Then not issued again.
I still had quite a few BLYNK_WRITE’s - 18. When I cut those out then the message went away entirely
Is there some way of increasing the tolerance for the test for disconnect so it is not so fussy?
I’m using a sonoff power device with android phone.
If you are seeing that message in the app (lower part of screen in orange) then I believe it is it is referring to the server loosing link to the device. Impact is simple… no connection no worky
Admittedly, I don’t have the resources to acquire any Sonoff or other ESP devices, to be sure on comparison, but I believe the Sonoff is probably a very basic ESP and may not be up to the tasks you are giving it, thus causing an interruption in it’s internal WiFi connection loop - thus the disconnect.
I suggest that you post your full complex sketch so we can look it over, as able, and perhaps suggest pointers for better efficiency.
Is this happening when the Sonoff is connected to mains power, or when you’re powering it through your 3.3v FTDI interface?
I found that my standard USB FTDI wasn’t up to the job of powering the Sonoff, so had to add a separate 3.3v supply and connect the ground wire across to the FTDI to be able to program it.
If your serial interface is borderline with the amount of current it can supply then you might have some issues.
I also had one Sonoff that regularly dropped the Wi-Fi connection when powered by mains power, but worked perfectly when powered by 3.3v through the programming pins. The Sonoff had a slightly burnt smell to it, so I think one of the power supply components had failed. I consigned it to the bin and it’s replacement is working fine - for now!
Remember, never connect mains and the FTDI connector at the same time!
It’s with both connections. I’m still investigating as to whether it is sonoff scenario or not. The first message is happening during the synch all. on my 18 odd blynk_writes. If I disable the synch all then I don’t get the message. Still plenty of testing iterations to do to try to see exactly where the message is being triggered.
What I would like to know though is where in the device code it knows to issue the message and how the android app knows that the device is “disconnected”. When I hit the device status button on the app it says it is connected.
How does the server know the connection is dropped. Is it because the device is not communication an “i’m here” message often enough because it is busy doing other things - like a delay - not that this is the reason as we all know not to use delays in the main loop ?
As per above - I get the first device not connected message during the synch all command for my 18 blynk_writes. This I can demonstrate by removing the synch all command.
I’m going to try the code on a wemos and yun to see if I have the same issue or it just my sonoff.
The synch all is done just the once at the very start using the standard method:
BLYNK_CONNECTED() {
if (isFirstConnect) {
// Request Blynk server to re-send latest values for all pins
Blynk.syncAll();
isFirstConnect = false;
}
}
Hi @Dmitriy. Would you be able to answer the question in the first para above - how does the server know…?. Just to give me some context to my testing. Thanks.
In the case connection is closed correctly server receives tcp/ip event and sends the message. In case connection closed not correctly server waits for “heartbeat” interval and after that sends message.
@koaiwi you will be missing the 10 or 15 second heartbeat because syncing any more than 3 or 4 virtual pins will generally crash an ESP. If you really need to sync 18 pins you should sync 3 or 4 wait say 200ms and then do another 3 or 4 until you have done them all.
Hi @Costas. That’s good experiential advice and good to know as a starter. So I probably shouldn’t do the auto synch as per normal.
Sometimes I do other stuff like http data requests and saves which also may take some time and I’ve noticed that this can cause some disconnect issues.
Is there a way in the device side code in the libraries I can extend the tolerance of the heart beat or force the heat beat in my device code to avoid this situation? If so are there any pros or cons?
I’m just exploring some options here as the synching is not the only time I get this issue. It’s just a simple case I can evidence to you guys.
Also, perhaps I am also getting it when I do a stack of virtalwrites. Would this also perhaps cause the devise to “go off line”?
I never use syncall because I never need to know the status of all my pins. Normally 3 or 4 is all I need but if I need more I use a timer to call subsequent sync’s.
Do you have your Sonoff “hooked up” to Serial Monitor as there are lots of reasons for them crashing, especially if you are doing http data requests.
Try using Webhook for data requests as it reduces a regular http call from 6s to 1.5s.
@koaiwi just had a quick look at the xively API and it doesn’t look anything special. Do you have a sample call together with the headers you are providing?
