I recently recompiled an unchanged Wemos D1mini sketch (which has been running for years) noticing it immediately crashes after the connection with Blynk becomes active.
Changing:
timer.setInterval(0000L, whatever);
by
timer.setInterval(1L, whatever);
solved the issue.
The original reason for having 0000L was because the function “whatever” needs to run continuously.
Is this a recent change in behaviour of Blynk or have I been lucky up till now?
thanks,
piet.
I’m surprised that the new 1ms timer works, let alone the 0ms timer.
Pete.
It’s probably due to updated routines on the ESP platform, not Blynk, or the SimpleTimer library.
If you need a 0ms timer I think you need to rethink your code.
Can you explain what you want to achieve en what kind of project it is? Maybe we can think along 
Thanks for your feedback, same for yours Pete.
There was no compelling reason for using 0, it mainly comes from a straightforward conversion of an old program to Blynk where I simply moved all the code of the main loop into a 0sec timed function (I believe I came across an example that was using 0).
The behaviour of the program will be ok even when timed at 100ms. One second would require moving things into interrupt routines.
The reason for asking was the perceived change in behaviour and an explanation might be of help to other users.
Thanks,
Piet.
P.S. The (small) project itself consists of a homebrewn powerplug controlled by Blynk. I found it much more fun building one myself iso buying a commercial one.
But of course it’s much more fun building it yourself!
I’m still not sure why you would need such an exact timer for a power plug.
There is absolutely no need for an “exact” timer, but a short one is expected.
This is my configuration:
The push button and led both are part of the mobile device controlling the plug.
When the plug state, as visualised on the led, lags too long behind the push action (e.g. one second), I noticed that people start hitting the push button many times creating more and more traffic on the network and making the plug flip-flopping before it reaches its intended state. That was no problem when the mobile device was directly connected to my local Wifi network sending UDP commands to the plug. Now having introduced blynk for access to the plug over the internet, it looks as if having a receiving function timed at 1 sec is just too slow leading to the above behaviour of the users. I am currently running it OK at 100 ms without any problems and without complaints of the family members.
I might also move the receiving function back in the main loop as it does not do a lot and would not hurt blynk.run but I was merely following the advice to keep the main loop as clean as possible ;-).
Do you see a better way of handling this case?
regards,
piet.
The normal way would be to have your Blynk button widget attached to a virtual pin, and when it’s pressed it triggers the BLYNK_WRITE(vPin) callback function.
With this approach, no ‘polling’ of a digital pin is required.
If you also have a physical button attached to the device then you should probably be using interrupts and a debounce routine, or you could poll the switch using a timer.
The code in this topic uses the polling option for the physical button, and to be honest 10ms is a bit of an overkill.
Pete.
thanks for the suggestions, there are indeed quite some cases where I can move the code that provides feedback into the BLYNK_WRTITE(vPin) of the button (e.g. those relays that are directly connected to the blynk ESP8266).
Some other relays are connected further down in the local network (on ESPs that are not connected to blynk). Including in the BLYNK_WRTITE(vPin) function the code that gets status info from these devices might not be a good idea.