Details about keeping void loop() clean

Solved
1

Hi,

Can you provide more info about this best practice of keeping the void loop() clean ?

I understand that one of the main goals of this recommendation is to ensure that we execute the Blynk.run(); often but exactly how often should it run exactly ?

Another question I have is about spamming the Blynk server. Not that I intend to do that of course :wink: What are the limits here ? How often ? how much data ?

Currently I have a working project with a Wemos D1 mini talking via serial to an Arduino Mega that drives a bunch of addressable RGB LEDs and would like to add a fair amount of processing into the wemos sketch and wonder just how much I can do there that will not crash the server and disconnect me.

Thanks for your help.

2

Check this out, lost of info, examples and explanation . . .

cul
billd

3

Thanks.

I actually read that before I posted but it did not provide the answer I am looking for.

I see that I cant do virtualwrites 117K times ( or a gazillion !!) a second and that makes sense but how many could I do is my question.

4

Ok, I dug a bit more and found the following comment concerning doing Blynk.virtualWrites in some sample sketch…

            // Please don't send more that 10 values per second.

Also the App shortest write interval for sending slider widget values is 100 ms which lines-up with above comment.

I was considering sending a bunch of widget property changes (like labels, value, color, limits etc…) and see that my idea might cause some problems if I am limited to 100 ms between virtualWrites.

Is 100 ms between Blynk.virtualWrites a hard limit !

5

It’s a good guide, and although I think you can get away with probably doing a total of 20 virtual writes per second if it’s to different pins, I’d recommend avoiding that - especially if you’re using the Blynk cloud servers.

Maybe you’re approaching the issue from the wrong angle?
The app is really meant to be fairly static and used as a method of controlling your hardware. if you have a hardware device that’s taking readings from a sensor then updating that every 5-10 seconds is typical, and if you start updating the values more than about once per second it doesn’t usually achieve much other than making the data in the app unreadable.

I’d also think about the hardware setup. Having an Arduino talk to a D1 Mini via serial probably isn’t the best approach.

Pete.

6

Thanks for that answer Pete.

This is my 1st project using Blynk and I have my Android Blynk app successfully communicating with the Blynk cloud server and the Wemos D1 mini that relays menu selections, push button presses and a few sliders data on virtual pins only to the Arduino Mega via Serial communication.

I do not have any sensors on my Mega or Wemos. The only task of the Mega is to drive 768 WS2812 style LEDs using the FastLED library. Writing LED data to takes about 23 ms and during that time, the Mega cannot be interrupted. I am still able to update my whole LED display close to 40 times per second basically using a very short time between LED writes to deal with parameter changes coming from the App/Wemos through Serial and updating my LED data.

Apart from a simple echo back of the virtualWrites (via serial) from the Mega towards the Wemos D1 mini ( I use that to update LED widgets on the App to confirm command reception), the Mega does not send any other data.

As of now, my Wemos sketch is quite minimal and lines up with the recommendations. However, I was considering to change ‘on the fly’ the label , color, min-max of a few sliders (4 or 5) based on the selection made on a menu widget and a segmented switch. I think that would be 4 or 5 widget property changes with 100ms between them…

Is that possible ? I am now concerned about the Blynk.run() possibly being delayed too much and causing a disconnect from the cloud Blynk server or erratic operation. How often must the Blynk.run() execute for reliable operation ?

Any suggestion as to a different approach you would recommend ?

Thanks for your help, JP

7

Yes, it’s entirely possible to update some widget properties based on changes to another widget and provided you don’t keep repeating this multiple times within a short period of time you’ll be fine.

The absolute maximum period between hardware and server communications is 10 seconds, unless you change the timeout to something larger.
However, the basic rule is that Blynk.run must be called as often as possible. When Blynk.run executes it preforms some background tasks, one of which is to ask the server if anything has changed since the last time. This is how it knows about, and responds to, widget changes such as button presses, slider movements etc.
If the process of picking-up these changes and actionong them is too infrequent (let’s say once every second) then the app will feel unresponsive, and things will start to get out of sync. Then users start doing multiple button-presses and the hardware is always playing catch-up.
For the app to feel responsive the communication need to be happening at least 5-10 times per second and probably faster.
The real issue is when an app button press is used to trigger a function within your code that takes a long time to execute. You can place Blynk.run commands within this function (they work just as well there as in the void loop), but the better approach is to try to avoid long functions that take a long time to execute - possibly by splitting-up the functionality is some way which allows the code to return to the void loop before doing more work.

Pete.

8

Great reply… exactly what I was hoping for !

I was worried about approx. 500 ms max between execution of the Blynk.run() and, from your detailed answer, it looks like that will not be a problem.

I understand the need to re-enter the main loop and Blynk.run() as often as possible for responsiveness and will definitely keep that in mind when re-designing my sketch.

If you do not mind, one last question on that subject… Could I write to 4 or 5 virtual pins consecutively without any delays ? Something like…

Blynk.setProperty(V0, "labels", "label 1", "label 2", "label 3");
Blynk.setProperty(V1, "labels", "label 1", "label 2", "label 3");
Blynk.setProperty(V2, "labels", "label 1", "label 2", "label 3");
Blynk.setProperty(V3, "labels", "label 1", "label 2", "label 3");
Blynk.setProperty(V4, "labels", "label 1", "label 2", "label 3");
Blynk.setProperty(V5, "labels", "label 1", "label 2", "label 3");

Now that would most likely not repeat within 4-5 seconds and then only following a changed menu selection on the app by the user.

Thanks a lot for an awesome support.

My very best regards, J-P

9

Why don’t you try it and see how it works for you?
To a certain degree, it will depend on the latency of your internet connection, so results will vary from user to user.

Pete.

10

I guess you do not foresee problems with that approach so I will definitely give it a try as you suggested and eventually provide feedback here.

Thanks again Pete,
JP.

1 Like
11

Hi Pete, not sure if you will still be monitoring this post but here’s a quick update on my project using Blynk…

To summarize, I have a Blynk project with 8 sliders, 3 segmented switches and a menu widget that selects 1 of 12 animations for a bunch of addressable RGB LEDs. The sliders have different functions depending on the animation selected.

When a new animation is selected, I may change the label or color properties of some sliders and segmented switches. My worst case scenario does about 20 properties and value changes on a number of different widgets.

I added a delay between each of those 20 changes and have got no problems so far from the Blynk cloud server even when dropping this delay down to 5 millis !

I want to thank you again for your help and guidance.
My best regards, JP

1 Like