Defer Writes

[wanek]

honestly, for me, one of the greatest “feature” of blynk is that super fast (realtime) speed.

when you send something - it is sent - instantly. why it should be sent with delay??? the power of hardware and mcu is the super fast speed. imagine if your keyboard or lamp switch or volume control would respond with delay:

@BoogaBooga

virtualwrite() calls to write to memory (i.e. queue the data) and then when the next blynk.run() comes around, all the data is queue is sent in one go.

that would be pretty annoying - or even completely unusable…

blynk virtualwrites quite often are used to give feedback to the user: you do something in the hw, and expect some feedback in the app. for a great user experience, this is best to happen asap.

the idea with deferring writes it is quite simply implementable by anyone, without slowing down the basic blynk functionality:

just create a blynk.timer instance and put all blynk virtualwrites you wish to defer into the callback function. this way, you can defer all writes as much as you like (seconds, hours, days, etc) - and they will be “sent in one go”.

as for your original idea, to making ALL blynk virtualwrites any slower / delayed… give me just one reason, why it would be better from the end user pov?

[BoogaBooga]

I guess I am used to using RTOSes where everything is made to be deterministic.

I was just suggesting an approach to make blink more deterministic; but as was said, maybe this is a need for the business side of blynk.

It is not truly implementable by us because it needs to go inside the blynk state machnine where the data can be packed,scheduled and sent correctly; one payload.

Yes you can do this on the outside (store data yourself and call a bunch of writes at one time) but you’d still end up doing the same amount of calls (many payloads) which will take the same amount of time. The benefit happens when you do one bigger send to the blynk server.

I would love to hear the devs thoughts on scalability. I mean, there is support dozens of Virtual pins (128 max?). How do you get all that data back in a reasonable amount of time?

If i use my metrics (i.e. 0.15ms per virtual write x 128 = 192.s) is a long time to spend transferring a few hundred bytes.

[wanek]

you can enable the serial debug in blynk, than you can study how and what happens in the background. or, for even more detail, you can take a look into the source code.

@BoogaBooga

blynk.run() does nothing? If the magic happens in the write functions, what does blynk.run() actually do?

i didn’t study this in detail, but, as the docs says, blynk.run is for housekeeping (it maintains the connection with the server), and you can have as much blynk.run in your code as you like.

for better understanding how it works, you can compare with the serial communication protocol:

blynk.virtualwrite is like serial.println: it sends the data to the serial monitor - immediately.

i never done any scientific measurements about how long it takes 1 virtual write (and, i’m sure it is pretty much dependent on your local network, distance to the nearest blynk server, wifi signal, etc), but in some of my projects i use 30-40 virtual pins, without any issues / delays. the only problem i’ve got, only once, it was because of a bug in the old (2.3) esp core, which caused crash - after updating to 2.4, it works ok.

if indeed takes 0.15 milliseconds, as you say, for 1 virtualwrite, than for all the 128 pins it would take 19.2 milliseconds… or maybe more, i do not know.

but simultaneously updating all 128 virtual pins is quite uncommon, i see no practical reason for doing that. it is like a car, it can do 8000 rpm, but no reason for using on such high rpm.

@BoogaBooga

make blink more deterministic

for me, if i know that when i send data - it is indeed sent asap - that is pretty deterministic. wish, it could be so deterministic the postal service in my country

[BoogaBooga]

I am not sure if the network was the problem. I use a local server on the same network and i get 10ms ping usually.

I am also not saying make blynk slower. I am asking for a mechanism that allows me to schedule the writes better. Allow for a queue that can be sent during some spare CPU cycles or send it whenever you want in the code.

Determinism has a whole other context when talking about real-time processes. In this context, sending asap is not a sufficient condition to be deterministic.

I guess whether blynk should be considered real-time is a whole other argument.

Thank you all for the discussion, and I hope we can continue it to improve blynk.

Again I am not asking to up-end blynk. If it works for you, great. I am putting forward an idea for improvements. We are all trying to squeeze the most out of our little microcontrollers and the team has created a great product towards that. There is lots more that can be optimized toward scalability and performance. Just because its good enough now, does not mean there is no room to improve.

[Costas]

@BoogaBooga

i.e. 0.15ms per virtual write x 128 = 192.s

If you put new batteries in your calculator the 192s will become 19.2s.

Nobody uses all 128 virtual pins and Blynkers don’t normally pause for 0.15ms between each write so it’s all done in a fraction of a second.

[BoogaBooga]

good catch.

Altho the application code does stop for 0.15ms during the blynk write. I am not sure what you mean

[Costas]

@BoogaBooga

Altho the application code does stop for 0.15ms during the blynk write.

Are you using version 0.5.0 of the Blynk library?

[BoogaBooga]

Yes I am. I will post an example of what I am seeing in the next few days. Maybe I am doing something wrong.

Edit: using v0.5.0 on ESP8266 (ESP-12E)

[Costas]

I believe v0.5.0 is still officially a beta release and all previous versions operated without any delays between each virtualWrite().

For beginners to Blynk, that didn’t read the docs, and tried to throw everything into a messy loop(), as they did when they were using Arduino’s, this created problems.

One of the biggest issues was caused by all the bugs in the Arduino ESP core that still hasn’t seen an official update for 18 months, although there are recent staging versions with hundreds of bug fixes.

[BoogaBooga]

I agree. I am not a fan of the arduino-isms either.
I have seen stability improvements with 0.5. I agree with the rate-limiting. I think it would be even more efficient if they can pack the data better before each send.

And another thing, the way things are now, you can send duplicate data if your value does not change. I think there should be the capability to transmit on change instead. This is a trivial thing to fix in the sketches (i.e our code), but it would be nice if the blynk library did this behind the scenes. It would also help with the flooding and reduce bandwidth (for those that are on GSM/cellular)

Sigh. Maybe i have to write a big wrapper to blynk and do my own scheduling.

[Costas]

@vshymanskyy how many ms have you set the delay at in 0.5.0?

@BoogaBooga are you using ESP in standalone mode with 2.4.0-rc2 core?

[BoogaBooga]

I am using ESP in standalone mode with ESP Arduino Core 2.3.0 release.

[BoogaBooga]

For those interested, here is what I am seeing. about 175ms for one call, and 1.7s for 10 (10 before another blynk.run()).

/*************************************************************
  Download latest Blynk library here:
    https://github.com/blynkkk/blynk-library/releases/latest

  Blynk is a platform with iOS and Android apps to control
  Arduino, Raspberry Pi and the likes over the Internet.
  You can easily build graphic interfaces for all your
  projects by simply dragging and dropping widgets.

    Downloads, docs, tutorials: http://www.blynk.cc
    Sketch generator:           http://examples.blynk.cc
    Blynk community:            http://community.blynk.cc
    Follow us:                  http://www.fb.com/blynkapp
                                http://twitter.com/blynk_app

  Blynk library is licensed under MIT license
  This example code is in public domain.

 *************************************************************
  This example runs directly on ESP8266 chip.

  Note: This requires ESP8266 support package:
    https://github.com/esp8266/Arduino

  Please be sure to select the right ESP8266 module
  in the Tools -> Board menu!

  Change WiFi ssid, pass, and Blynk auth token to run :)
  Feel free to apply it to any other example. It's simple!
 *************************************************************/

/* Comment this out to disable prints and save space */
#define BLYNK_PRINT Serial


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

// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "****";

// Your WiFi credentials.
// Set password to "" for open networks.
char ssid[] = "***";
char pass[] = "***";
char server[]= "***";

void setup()
{
  // Debug console
  Serial.begin(115200);

  Blynk.begin(auth, ssid, pass, server, 8442);
}
bool value = false;
void myTask(void){
  Blynk.virtualWrite(V1, value);
  value = !value;
}

unsigned int t0, t1;

unsigned int process_time = 0;


void loop()
{

  t0 = micros();
  myTask();
  process_time = micros() - t0; 
  Blynk.run();

  Serial.println(process_time);
  yield();
}

[zodiac]

@BoogaBooga

I am using ESP in standalone mode with ESP Arduino Core 2.3.0 release.

WPA2 Compromised: Upgrade all hardware

We still have some Blynkers running the old 2.3.0 core. Not only is WPA2 compromised, it’s old rubbish. Do yourselves a favour and get on to 2.4.0-rc2.

[Costas]

@BoogaBooga

Arduino Core 2.3.0 release

DO NOT USE THAT WITH BLYNK.

[wanek]

@Costas

i.e. 0.15ms per virtual write x 128 = 192.s

If you put new batteries in your calculator the 192s will become 19.2s.

Nobody uses all 128 virtual pins and Blynkers don’t normally pause for 0.15ms between each write so it’s all done in a fraction of a second.

guys, i do not know how you’re calculating, but for me, 0.15 ms X 128 is 19.2 ms, not 19.2 sec!

[BoogaBooga]

For the record, its 150ms * 128 writes = 19.2 seconds…

Anyway. 2.4.0rc2 gives about 60-75ms per write; about 3 times better than 2.3.0

Edit:

increasing the message limit (#define BLYNK_MSG_LIMIT 100) reduces the delay in the blynk calls. I can reliably get 10ms updates now. Please do not do this unless you’re on a private server.

[Costas]

@BoogaBooga unless version 0.5.0 has changed the message limit then Blynk’s cloud server can in theory handle 100 messages per second. That is if the hardware you are using can handle it but an ESP with 2.3.0 core can’t and requires 2.4.0-rc2.

What are you trying to do that needs so many virtualWrite() calls?

[BoogaBooga]

@Costas

I also increased the limit on the server side (default is 100 messages/second, as you said). Not that you’d be able to reach their default limit anyway.

Its not so much needing that many writes, my current application has about a dozen. What caught me off guard is the amount of delay required to service such a small pay load. I was using a timer of 1 second (not unreasonable IMO) and it was executing less frequent than that. Granted that this was made worse by 2.3.0 (which is still the ‘latest’ release )

I understand why they implemented the rate limit but I think its a poor implementation. Its just sitting there burning CPU cycles making the entire program slow; and I am not sure that this behavior is documented (other than ‘we fixed the flood error’).

Anyway, thanks for the help.

[vshymanskyy]

Let me remind you that the library is open-source and you’re free to adjust it to your needs.