Well, CPU performance is the same. It’s just the amount of loops you have.
You can control the maximum amount of messages it allows per second: https://github.com/blynkkk/blynk-library/blob/master/src/Blynk/BlynkConfig.h#L42
But, keep in mind that in your Mega+ESP configuration, it takes a lot of time event to send bytes to the ESP via AT commands, and in this case it’s even a lower rate.
“Oh, your engine revs just as high as before, but you can’t have, and don’t really need, 2nd, 3rd, 4th gear, etc…” 
Been there tried that… it is because of these settings that I am getting the amazing rates listed above 
And I just tried my Wemos… and at best so far with Blynk, I get a strange flip-flop between around 96 and 22000 per second with the void loop()… not always disconnecting, just stalling out. and this is with the timer set to 500ms and just those 6 total Blynk commands.
So far I have to say I am not impressed 
… I can’t keep some of my heavier processing projects running smoothly… my RGB LED strip lighting tends to have a flickers and skittering in many patterns as the stalling occurs and speaking of the stalls… well very disconcerting watching up time (and other) displays click smoothly along, then halt for about 2-3 seconds, jump to catch up and continue on until it stalls out again, even when it doesn’t result in a disconnect/reconnect cycle.
Hey, I would really be happy to hear that kind of report when we did a beta release, not now 
I really have to understand the issue completely (I don’t, at the moment).
And unfortunately I don’t have much time right now to investigate such bugs… I’ll ping you back when I get to it.
I understand… but I can only think when clear headed and drool when under the dreaded brain fog … and that can last for weeks/months at times.
The past few days I have been clear headed and focusing this issue, programming Blynk in NodeJS and setting up a RPi Wordpress Web Server (well, trying to at least 
)… as for later, well…we will see 
Thanks for looking into it this far at least.
1 Like
@vshymanskyy OK, goodish news… I was running into WiFi interference that was compounding the issues with my tests… the RV park shifted their channel to where mine was, and even though my devices and router are only a few meters apart from each other, it was causing some issues on my setup.
Anyhow, that did show that the new library seems more susceptible to network lag then previous versions… possibly due to additional overhead?
So, avoiding the whole “Arduino & ESP shield too slow” issue… it’s not really… so far 
… considering the massive code and concurrent sensor activities I am running on mine; It is back to working OK for now… averaging around 70-80 void loops() / second under “normal” load: about 16+ blynk commands a second constantly, and many more called as required.
Meanwhile, I noticed that Blynk Libraries can now be installed directly in the IDE library manager 
Yay… makes for very easy, back and forth, library version changes and testing!
So I rigged up two ESP8266 devices running the same sketch & sitting the same distance from the router… One running 0.5.0 and the other 0.4.8.
Each timed loop is pushing 6 blynk commands out per second. 4 setProperty commands for the LED’s and 2 display updates for the counters.
Even with this simple test, I notice that the 0.5.0 version takes about 20-30% more overhead out of the void loop() processing cycles.
This seems negligible for 80MHz ESP’s running just Blynk commands, but starts digging into performance when also running "background’ processing for sensors and/or things like RGB Strip lighting etc. But I guess that’s the price for progress…
I hope Blynk doesn’t follow the path I have seen some other developers follow, wherein the bloat gets so big that you always need next gen hardware to run it.
For example… even on ESP8266 - I have one Blynk project running simple weather monitoring, solar charger monitoring and simultaneously controlling a couple of RGB strip lights with fast patterns. I need to keep it on 0.4.8 in order to maintain full stability. It seems 0.5.0 keeps rebooting it every few hours…
I think the “emergency” is over, so I will switch this to “need help” category for now… until you can look into it a bit closer… if you feel it necessary
2 Likes
since the latest lib update i have also observed reboots on random intervals on my devices (say every 2-3 days).
the sketch didn’t was modified, only the lib updated. i monitor the restart cause in my firmware, there are categories like:
- remote restart (from app)
- over the internet firmware update performed
- wifi / server timeout
- balckout / other
all restarts are labeled as “blackout / other”, and i know for sure there wasn’t any blackouts in our area since a long time ago. so, maybe there is something to look into with the new lib…
eventually, i will try to downgrade to the previous lib, and compare the results.
could anyone find a solution how to disable Anti-flooding (anti -anti-flooding method) in the BLYNK library code?
1 Like
if it is a big problem for the cloud server, it can allow “flooding” for the local server only
Sorry we had to add this hard limit as many users just put Blynk.virtualWrite() in a loop.
2 Likes
I understand that. But maybe you can remove this limitation for the local server?
2 Likes
I assume we may need to do it by ourselves, and as the Blynk library is open source (Thanks to Blynk Team!) it shouldn’t be that hard for some skilled coder (well, I’m not the one!). Perhaps comparing files in 0.4.8 with affected (new library) ??
of course. But we need a hint of the author where to look for it, not to waste time
Somewhere near Blynk.virtualwrite() ?? No time for now, but as a challenge - I may look at sources. Who knows…
Quick search, probably a blind shot, but… What will happen, IF we define following:
#define BLYNK_MSG_LIMIT 0
??? Anybody dare to try?
Really no time for more
add: there is the following:
#if defined(BLYNK_MSG_LIMIT) && BLYNK_MSG_LIMIT > 0
and then some time countdowns. So probably it needs to be ZERO… (or…I’m totally wrong… probably :P)
3 Likes
As for me, sending data is again as fast as in 0.4.8So to confirm… all I have done is add #define BLYNK_MSG_LIMIT 0 to one of my fast processing RGB sketches… and it seems to have less issues, allowing me to push the timer to 10ms (sending two Blynk commands each loop) without seeing ‘as much’ pausing in my running project… but still happens every so often (App just pauses for almost 2-3 seconds, then seems to play rapid catch up and carry on smoothly for another 30+ seconds or so)
I used to be able to drop the timer to 8ms… So, anything else I need to do to revoke the governor nanny oversight?
3 Likes
How exactly it pauses? Freezez? And how many commands do you send at the time?
Yes… just stops all action on the App… then 2-3 seconds later it acts like it is on fast forward for perhaps a second then normal operation. The length of time for normal operation seems random. The sketch itself keeps running smoothly as I am also controlling a physical RGB with same loop and values.
2 commands each timed loop: both Blynk.setProperty() One for the random LED on my matrix and one for a button on another tab that flashes rapidly like my physical LED.