Concurrent BLYNK_WRITE's



Sorry, I missed pasting this part…


and this part…


Not sorry for the “crayon” writing… that was just for my fun :stuck_out_tongue_winking_eye:


2.5 seconds of what? blynking!


Well, I am wasting more time than that, which is “blocking” my own projects, while dealing with this senseless argument :stuck_out_tongue:

Program smarter or complain about the tools provided… I will leave you to your choices.


Wow. Nice.


To those who have read this far, thanks. I am a user, a client and a huge fan of Blynk and am motivated in my discussion only with its improvement.

I created a useful wood stove controller that uses a stepper motor to open/close the air flow. I can set a target room temp, stove temp or just choose the air flow % manually.

Here’s the motor, wearing a stainless hat that plugs the air intake:

Now that it is freezing cold in New Hampshire, I dusted off the equipment added some minor code tweaks and reinstalled the controller. When I went to calibrate the actuator, the “Calibrate” button failed to work because of the change in the Blynk Library. I am sure of that and it’s no big deal - I easily could work around it. I was just looking for advice on the cause before I figured it out through my test script.

What I found was somewhat interesting, more from an academic/design perspective than “Oh my god! Help me fix this!”.

If you use a button to send an event to a device, let’s say “calibrate”, then you want to have another button (or the same button in my case) that sends an event to “confirm” (and then another event that says “goHigherUp”, etc), there are different ways to handle that sequence. One method is to call a calibrate() function right from the BLYNK_WRITE method on the button press.

But while your code is twiddling around with the motor, it is not running… so the device will never receive new events and the device will not get a new signal to “confirm”. So, let’s put into the calibrate() loop, so it can get that “confirm” event (which is received through the same BLYNK_WRITE function and just flags that the button was pressed again). That worked perfectly well for me until the 0.5.* lib, now I see that will only run a single BLYNK_WRITE at a time. I never got that confirmation button press, even while looping on

So, the solution is to leave the BLYNK_WRITE methods in a hurry! You can do that by calling functions using the timer.setTimeout(10,calibrate) technique that I mentioned earlier. This will launch the function through a queue manager and the BLYNK_WRITE function is finished – no strings attached.

Is this the “best practice”? Under these library conditions, I think it is. Can I live with the library change? Sure, now that I know what I am dealing with.

Am I blocking? I don’t think so!

Hope that helps others understand what happens “under the hood”.



OK, I am a bit bored… and loose focus too often sometimes, thus the movie is on pause :stuck_out_tongue_winking_eye:

Here is a nice little sketch with three simultaneously running BLYNK_WRITE() functions, each doing their own thing…

  1. Increment and display a number every 100ms on the Terminal if the White button is ON, reset when OFF.

  2. Flashing one of Blynk’s new large LED’s (BETA App at time of this post) depending on the frequency set by the Slider Widget (AKA my variable timer) 100ms-5000ms range.

  3. Increment/Decrement a number, based on the Step Widget… as fast as you can press.

And as I kept recommending to avoid, wherever possible due to their blocking nature… not a single delay(), for() or while() is to be found… and only one command required… thus no function is blocking the others.

Small Disclaimer… I am messing heavily with Blynktimers here, and not really paying attention to giving each timed action enough ‘time’ to complete, so there can be some slight degradation (AKA slowdown) when running the variable timed function at fast rates.

However, the BLYNK_WRITE() function containing the simple Step Widget and indicating Display widget is completely unaffected by these slight timer degradations.

Yep, with smarter coding practice, multiple BLYNK_WRITE() functions working concurrently as normal :stuck_out_tongue_winking_eye:

#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>

//Blynk setup
char ssid[] = "SSID";
char pass[] = "PASS";
char auth[] = "AUTH";

long variableTime;
int number;
int varTimer;  // Setup Timer ID
int numTimer;  // Setup Timer ID
int flashTimer;  // Setup Timer ID

//  WidgetTerminal blynkTerm(V1);  // Not required as I am using direct Blynk.virtualWrite() commands to the terminal
BlynkTimer timer;

void setup() {
  Blynk.begin(auth, ssid, pass);  // Blynk.begin() is a blocking function until connected, so no need to have extra connection check delays

void loop() {;;


BLYNK_WRITE(V0) {  // Switch Widget for incremental counting to terminal
  if (param.asInt() == 1) { //if button pressed down
    Blynk.virtualWrite(V1, 0);  // Send number to Terminal
    // Timed Lambda Function - LED Flash
    numTimer = timer.setInterval(100L, []() {
      number++; // Increment number
      Blynk.virtualWrite(V1, "-");  // Send number to Terminal
      Blynk.virtualWrite(V1, number);  // Send number to Terminal
    });  // END Timer Function
  } else {
    timer.deleteTimer(numTimer);  // Cancel previous Timeout Timer
    number = 0;  // Reset Number

BLYNK_WRITE(V3) { // Slider Widget for interval timing
  timer.deleteTimer(varTimer);  // Cancel previous Timeout Timer
  Blynk.virtualWrite(V2, 0);  // Turn OFF LED
  variableTime = param.asInt();  // Get new interval time
  if (variableTime <= 100) { // prevents a timer from becoming 100 or less
    variableTime = 100;
  Blynk.virtualWrite(V6, variableTime);
  timerLoop();  // Call your timed loop

BLYNK_WRITE(V4) {  // Increment/Decrement a number, based on the Step Widget
  Blynk.virtualWrite(V5, param.asInt());

void timerLoop() {  // This is my, adjustable, variable timer setup flashing an LED
  timer.deleteTimer(varTimer);  // Cancel existing Timeout Timer
  Blynk.virtualWrite(V2, 255);  // Turn ON LED
  // Timed Lambda Function - LED Flash OFF
  flashTimer = timer.setTimeout(50L, []() {
    Blynk.virtualWrite(V2, 0);  // Turn OFF LED
  });  // END Timer Function
  varTimer = timer.setTimeout(variableTime, timerLoop);  // Set new Timeout timer and call this function again in X seconds

And for others to check out… I have also used various timer methods in many code examples - C++ Blynk - Code Examples for Basic Tasks (Work in Progress)

Led controller disconnects

Just because there’s a mess of crazy going on doesn’t mean any two BLYNK_WRITE’s are running concurrently.

You do know that, right?


Single core MCUs don’t actually multitask like real SOC or computers… they just calculate really fast and give that sense… You know that, right?

My point is that your arguments blaming the library can be proven false when using proper programming methods recommended by Blynk.

If it can calculate faster then I can push buttons, and quick enough to do the job (I have Rovers and other fast motor controlled projects that work just fine)… who cares how the library processes the code.


So what were you try to prove then?! You’re just not following this thread. This is not about multitasking, but you could start a new thread if you want to discuss that instead.

I’m examining the effect of a library update. That’s all. You’re getting all emotional – it’s kind of weird. I am not blaming anyone. Please, go enjoy your movie.

You should close this thread before you embarrass yourself any further.


One that is 11 months old… way to keep current :stuck_out_tongue_winking_eye:

Not as weird as you thinking you know my mood… I CAN (sometimes) multitask and was doing other stuff in-between typing as my thought processes came back to this non-issue… I enjoy the intellectual challenges… PS movie was great :oncoming_police_car::moneybag::moneybag::moneybag::gun:

Not embarrassed at all… I have been doing this forum thing for a long time… and as indicated by the Blynk developers themselves, my explanations were more on-track than yours. Sorry if you can’t get it to work anymore, try some of my programming methods :wink:

But good idea on the thread… it has reached a conclusion, so closing it as requested.