Blynk.virtualWrite taking a long time (~200ms per write)

Thanks, but beg to differ, as you will see with the remaining code. Each iteration takes only a handful of milliseconds to run, except for those when the temperature update timer triggers. If I disable the virtualWrite (specifically by commenting out the virtualwrite command), the iterations run smoothly, consistently, and quickly. The pause only occurs with a virtualWrite.

Edit: Added that info to the original post to clarify that the issue is specific to the virtualWrite, NOT the rest of the code. I’ll try to test it later using a totally blank sketch to avoid the distraction.

Okay, have it your way.


clean your loop

void loop() {;

I have commented out everything in the main loop except blynk run and the timer. The timer only runs the virtual write. The problem as described still happens. Iterations with the virtualwrite triggered (and ONLY those) take a long time.

How are you measuring this “Iteration Time”?
Your void update_mon_blynk() function is being called once per second, but you’re saying that this is taking around 200ms to complete the write. I don’t see how you can know precisely when the virtualWrite in that loop is being triggered, to then know how long it’s taking to execute.


I am using the serial monitor (removed from the code above) to monitor the iteration times. Not at home right now so I can’t show it, but measured the delay by printing the time at every iteration from the main loop, and confirmed that the delay was occurring only when the timer triggered by inserting an additional Serial.print in the update_mon_blynk().

Off the top of my head, I don’t remember the exact # of additional milliseconds occurring on the delay, only that it was on the order of around 200 additional ms.

I first noticed the issue when I was trying to update 6 vpins through virtualwrite each second (was not using serial monitor), which as you might expect, caused an endless cycle of updating at each iteration. Commenting out the virtualwrites relieved the issue roughly proportionately by the number of virtualwrites commented out.

Which makes it difficult for others to help/recreate this issue.

Do you have any other hardware (a NodeMCU for example) that you could try the same tests with?
If you do, then try with the standard and optional higher processor speeds to see if this has any impact.


I may be new to Blynk, but I am far from new to coding/debugging. I will strip away extraneous code in future asks for help. I realize that the standard “this is slow” issue on Blynk is usually people putting delays in and things in their main loops, though that’s not the case for me, as noted above.

No other hardware available, unfortunately.

I had previously thought the problem was with communication w/ the cloud server, but the problem does not seem to resolve with the local server.

Working with Blynk and other IoT systems is very different to debugging other systems, because of all the stuff that’s happening in the background to make the ‘magic’ happen.
Actually, very few people complain about Blynk speed/latency, and those that do are generally suffering issues caused by their network or internet.

When people use delays, or call functions that starve the process of processor time, the result is generally disconnections or WDT resets rather than speed issues.

If your system could operate with the fewer number of GPIO pins offered by a NodeMCU compared to Arduino; and operate with 3.3v rather than 5v logic levels then you’d be better going for a NodeMCU.
They’re much cheaper, smaller and more powerful than the Arduino/ESP combination and have a number of advantages such as the ability to do OTA wireless updates.



Actually, it is one of the leading causes of issues here… Blynk, and other IoT based applications that need exactly timed processes do not work well with standard Arduino style “Run everything fast as possible in the main loop, except when we want to wait, which then stops everything else as well” coding practice.

Unlearn old ways and look to the separate timed functions that more advanced programming uses.

Blynk functions and commands, properly utilised, can and will run as fast as the minimum network lag will allow… I have pushed limits inside a Local network with Local Server to the low ~15ms between groups of Blynk.virtualWrite() commands…


I get that. However, in my case we can eliminate that issue. The problem is apparently occuring between Arduino and app, which may or may not be exacerbated by a problem between chair and computer. I am using the blynk “run loop as fast as possible no matter what with no stops and delays” style, and the ONLY delay of any note between iterations is the virtualwrite command itself.

Any ideas on what else might be going wrong? I too would like 15ms read/writes, and am very confused why I am not getting them.

I may just kill this thread and start over, since the main loop distraction has thrown off this conversation too much to be useful at this point.

@shoo post the bare minimum sketch that exhibits your problem.

Don’t bother, I will just merge it back :stuck_out_tongue: This is all the same forum, and the format is such that it is best to keep your same issue in same topic with current updates bringing it to the forefront.

As for your issue and as has already been recommended… post your demonstrating code and details, otherwise you might as well be asking rhetorical questions.

Ha, fair enough.

Minimal code to reproduce problem below:

// Libraries
  #include <ESP8266_Lib.h>
  #include <BlynkSimpleShieldEsp8266.h>

// Variable declaration
  // Blynk and network authentication
    char ssid[] = "ssid";
    char pass[] = "pass";
    char auth[] = "token";
    char IPaddress[] = "";
    #define EspSerial Serial1
    #define ESP8266_BAUD 115200
    ESP8266 wifi(&EspSerial);
  // Set update timer for updating monitored values
    BlynkTimer update_temp_timer;
    long update_mon_interval = 1000;
void setup()
  // Start serial console
  // Start blynk
    Blynk.begin(auth, wifi, ssid, pass, IPaddress, 8080);
  // Start temp update timer
    update_temp_timer.setInterval(update_mon_interval, update_mon_blynk);
  // Start timer
    timer_start = millis();

// Main Loop
void loop()
  // Update temp readouts (push to arduino);
  // Run Blynk;

void update_mon_blynk()
    long VW_timer = millis();
    Blynk.virtualWrite(V111, 12);
    Serial.print("Time for virtualwrite: ");

Sample output showing 80-150ms per virtualwrite after it has stabilized (note: print ONLY for virtualwrite, each regular iteration is just a few ms. Earlier ones start are a bit noisier. Admittedly when I look at this now it’s less than the 200 claimed, but still far higher than I would like).

21:35:38.764 -> Time for virtualwrite: 95
21:35:39.738 -> Time for virtualwrite: 99
21:35:40.753 -> Time for virtualwrite: 99
21:35:41.731 -> Time for virtualwrite: 83
21:35:42.732 -> Time for virtualwrite: 87
21:35:43.741 -> Time for virtualwrite: 87
21:35:44.717 -> Time for virtualwrite: 89
21:35:45.740 -> Time for virtualwrite: 89
21:35:46.730 -> Time for virtualwrite: 85
21:35:47.810 -> Time for virtualwrite: 150
21:35:48.738 -> Time for virtualwrite: 97
21:35:49.755 -> Time for virtualwrite: 99
21:35:50.728 -> Time for virtualwrite: 85
21:35:51.751 -> Time for virtualwrite: 88
21:35:52.743 -> Time for virtualwrite: 88
21:35:53.754 -> Time for virtualwrite: 105
21:35:54.738 -> Time for virtualwrite: 91
21:35:55.758 -> Time for virtualwrite: 100
21:35:56.734 -> Time for virtualwrite: 98
21:35:57.753 -> Time for virtualwrite: 100
21:35:58.727 -> Time for virtualwrite: 86
21:35:59.732 -> Time for virtualwrite: 89
21:36:00.749 -> Time for virtualwrite: 88
21:36:01.756 -> Time for virtualwrite: 85
21:36:02.737 -> Time for virtualwrite: 90
21:36:03.754 -> Time for virtualwrite: 85
21:36:04.745 -> Time for virtualwrite: 83
21:36:05.738 -> Time for virtualwrite: 89
21:36:06.753 -> Time for virtualwrite: 85
21:36:07.740 -> Time for virtualwrite: 84
21:36:08.745 -> Time for virtualwrite: 82
21:36:09.752 -> Time for virtualwrite: 83
21:36:10.772 -> Time for virtualwrite: 82
21:36:11.753 -> Time for virtualwrite: 84
21:36:12.752 -> Time for virtualwrite: 83
21:36:13.737 -> Time for virtualwrite: 82
21:36:14.763 -> Time for virtualwrite: 84
21:36:15.771 -> Time for virtualwrite: 81
21:36:16.743 -> Time for virtualwrite: 84
21:36:17.762 -> Time for virtualwrite: 84
21:36:18.765 -> Time for virtualwrite: 87
21:36:19.742 -> Time for virtualwrite: 81
21:36:20.753 -> Time for virtualwrite: 85
21:36:21.787 -> Time for virtualwrite: 81
21:36:22.759 -> Time for virtualwrite: 83
21:36:23.769 -> Time for virtualwrite: 82
21:36:24.750 -> Time for virtualwrite: 87
21:36:25.790 -> Time for virtualwrite: 82
21:36:26.764 -> Time for virtualwrite: 82
21:36:27.797 -> Time for virtualwrite: 85
21:36:28.788 -> Time for virtualwrite: 91
21:36:29.760 -> Time for virtualwrite: 81
21:36:30.789 -> Time for virtualwrite: 86
21:36:31.759 -> Time for virtualwrite: 82
21:36:32.762 -> Time for virtualwrite: 83
21:36:33.786 -> Time for virtualwrite: 109
21:36:34.819 -> Time for virtualwrite: 105
21:36:35.763 -> Time for virtualwrite: 85
21:36:36.780 -> Time for virtualwrite: 83
21:36:37.790 -> Time for virtualwrite: 99
21:36:38.824 -> Time for virtualwrite: 114
21:36:39.801 -> Time for virtualwrite: 81
21:36:40.822 -> Time for virtualwrite: 97
21:36:41.796 -> Time for virtualwrite: 95
21:36:42.799 -> Time for virtualwrite: 97
21:36:43.804 -> Time for virtualwrite: 100
21:36:44.825 -> Time for virtualwrite: 100
21:36:45.831 -> Time for virtualwrite: 107
21:36:46.802 -> Time for virtualwrite: 92
21:36:47.806 -> Time for virtualwrite: 84
21:36:48.787 -> Time for virtualwrite: 97
21:36:49.820 -> Time for virtualwrite: 82

I just noticed… you are running this on an Arduino at 16Mhz as opposed to a standalone ESP8266 at 80Mhz (default)… big difference in processing power there :stuck_out_tongue:

Add in the possible further bottleneck of the Serial to WiFi link for the ESP as Shield, again as compared to the direct WiFi of a standalone ESP8266

1 Like

Nodemcu @160 Mhz :rofl:


Mowr PAWAR!! :zap: “Hit the turbo boost KITT”

1 Like

Yup, main processor involved is the 16MHz arduino one. So current thinking is that this is just a raw processing power bottleneck, correct? Sadly I need all those beautiful Arduino mega pins, so I’m stuck with it at the moment. It’s plenty powerful to run my scripts, but sadly not powerful enough for fast read/writes from Blynk, I suppose.

Good to know now before I put the effort into all the workarounds. Main workaround is probably just going to make sure I am staggering my writes so they don’t pile up. I also have at least one process that can freak out with long pauses, so possibly temporarily shut that one down while a read/write is happening. Not ideal, but can definitely make it work.

I’ve thought about doing something crazy and having the arduino handle all the IO and a pi zerow or something handle the UI and communication over serial/WIFI. That’re similar(ish) to my current strategy, which is also why I have all that “extra” in the main loop. The arduino is effectively running the automation scripts, and I have Blynk to tell it what mode to be in and monitor the various sensors of interest.

Also, before someone says it, the automation scripting is far, far more complicated than eventor widgets can handle.

Yep, eventor is mainly for simple tasks.

The ESP32 has the most I/O of the ESP family… and you can also consider multi-device scenarios… One App project with many devices, that can even easily share info across if needed via Bridge Widget or other methods.

I have also used a multi-device situation with the Arduino blissfully running non-Blynkified fast code in the loop() while monitored and controlled by an ESP that runs a Blynk sketch.

Thanks! If I were doing it again (and who knows, maybe I will), ESP32 or NodeMCU might have been the way to go, though worth noting that limits my expandability somewhat.

I think your latter scenario might be the way to go in the long run. I more or less have the hardware to do it already, technically, since I already have an esp01, and all signaling is handled by vpins anyway. Will probably do the clunkier software-only solution first just to get things running, since the main goal of this particular project is a hardware proof-of-concept demo anyway.