How often does Blynk.run() need to be called?

Need Help With My Project
1

I’ve got two ESP devices connected to the same project.

One was an original ‘hello digital pin’ type thing, and isn’t really doing anything other than pushing a variable that contains the temperature, and responding to a write request on a digital pin defined in the App/Button. It’s fat and happy (or skinny and happy, see below).

The other device is where I’m adding code, sensors-reads from various internet snippets, some with nastier than not delay() calls. I clean up the code, states instead of waits n-stuff, but I’ve noticed Blynk disconnects, I’m assuming disconnects since I see frequent (2-5 in a 10 second span):

[23140] Connecting to cloud.blynk.cc:8442
[23259] Ready (ping: 4ms).

I think my device-wifi->router connection is good enough, but who knows what the full path looks like from devices to Blynk server.

I’ve also noticed that if I reduce/eliminate the code delay() calls, or call Blynk.run() from inside a particularly slow piece of code, along with calling it inside of the main loop(), the disconnect/connect issue goes away.

I only noticed any of this when I saw the app<->device reactions were getting lost or sluggish. Seemed to correlate to the disconnects.

So, what’s the approach? How often does the device need to call run()? How much time can pass before a re-connect is initiated? Which side initiates it? Anything else cause disconnects, or is notorious for temporary sluggishness?

Thanks!
ko

And yeah, being lazy here, I should grab the server side, locally deploy so I can see/control/contribute to both ends (day job priorities though).

2

@vshymanskyy is the best person to answer. He is on vacation currently.

3

Interesting observation I have with ESP8266. I almost lost faith with it using Blynk, as it keeps disconnected. Adding delay in the loop would not help as well. Until I add Blynk.run() after every Blynk.[operation] in the loop. i.e.:

Blynk.run();
Blynk.virtualWrite(V0, (int) sensor.LTC2946_code_to_current(currentCode));
Blynk.run();
Blynk.virtualWrite(V1, (int) sensor.LTC2946_code_to_current(voltageCode));
Blynk.run();
Blynk.virtualWrite(V2, (int) sensor.LTC2946_code_to_current(powerCode));
Blynk.run();
Blynk.virtualWrite(V3, (int) LTC2946_tempCode_to_celcius(tempCode));
Blynk.run();
delay(100);

Is this suppose to be as I did not notice on any example. This put back ESP8266 on my list :smile:

4

This might work, but this is bad idea :slight_smile:
Did you check our examples with SimpleTimer?

5

If I remove Blynk.run() after blynk operation, and just have one for every loop cycle (in that example every 100ms), then the ESP8266 keeps disconnecting. I thought something unstable on ESP8266, but after adding Blynk.run() as above, the disconnection gone.
The timer would not help as I still need to do multiple virtualWrite anyway. I did reduce the write interval on the actual application using change threshold, but just to show the simplified version as above.

6

Adding @vshymanskyy here

7

Are there any new thoughts here?

8

Basically you need to call Blynk.run() as frequently as you may expect messages (actions) arriving from the Phone App.
But no slower than once per 8-10 seconds.

1 Like
9

After further experiment, this is the best way to do the loop for me:

  Blynk.run();

  if (500 < (millis()-lastMillis)) {
    lastMillis = millis();
  
    // Scale and send the value to Apps.
    Blynk.virtualWrite(V0, (int) sensor.LTC2946_code_to_current(currentCode, resistor, LTC2946_DELTA_SENSE_lsb));
    Blynk.virtualWrite(V1, (int) sensor.LTC2946_VIN_code_to_voltage(voltageCode, LTC2946_VIN_lsb));
    Blynk.virtualWrite(V2, (int) sensor.LTC2946_code_to_power(powerCode, resistor, LTC2946_Power_lsb));
    Blynk.virtualWrite(V3, (int) LTC2946_tempCode_to_celcius(tempCode));
  }

Which is good for prototyping where I don’t really care about power consumption at the moment. I suppose rather than sending each values to the Apps using virtual pins on each of them, I should be able to group them, or only sending the new value when it does actually change (with hysteresis), or using Terminal widget.
Using millis() instead of delay will help calling Blynk.run() as often as practically possible.

10

Good point. @vshymanskyy what do you think?

11

Yes, it should be ok. For low-power solutions we need a different approach (and possibly different hardware)!!

12

One way I worked around low power projects, in my case one that collects data from multiple locations, was to mix the Arduino platform with the XBee platform. The Arduino is constantly powered and working as the central station, therefore it can keep running Blynk in the Loop function without disconnections.

Remote Xbee modules collect sensors data in different locations and send it to the Arduino, which then updates Blynk with the newly received values. The Xbee’s can be put to sleep for most of the time and wake up at selected schedules to collect new data, transmit it to the Arduino and go back to sleep. The Xbee power consumption is very low so each data collecting station can be 100% solar powered and made very small. The main limitation of this approach so far the inability to use digital sensors with the Xbee so I had to find analogue options for the sensors I wanted.

Recently I purchased a Particle Photon and while learning how to put it to sleep, I added Blynk to it and observed it disconnecting when the board sleeps and reconnecting / sending new data when it wakes up (as expected). In that cycle, if I have a graph Widget in my Sketch with some data points and I close and reopen the Sketch for instance, I lose all data points as they are not stored anywhere. But since the graph widget only holds a few data points anyway (x axis length not editable by the user), would it take a lot of resources to hold that last few x data points in the Blynk servers so that low power projects can have some kind of continuity when sleep cycles are included ? :grin: