It’s usually better to use just one timer for all functions. E.g. for 4 functions, run the timer 4 times as fast and then call only one of the functions, in sequence, on each timeout.
You can use a global counter that is incremented on each timeout and then reset to 0 when it goes above 3. Then, use a switch() or set of if()/else if() statements to call one function based on the count value.
could you explain why?
Because then you’re guaranteed that there won’t be overlap, which will happen occasionally with the “staggered timer values” method".
I use staggered timers all the ‘time’ 
and they work beautifully that way. Less need for complex counting coding etc.
On one project alone I have a few timers 
… even have a couple of very short duration ones that are switchable (as in on and off)
// ===== Timer Setup =====
PingTimer = timer.setInterval(510L, PingSensor); // Ping distance routine - switched
timer.disable(PingTimer); // Disable timer until needed
PIRTimer = timer.setInterval(530L, PIRSensor); // PIR motion routine - switched
timer.disable(PIRTimer); // Disable timer until needed
timer.setInterval(500L, CNTRDisplay); // Update Loop counter Widget
timer.setInterval(1000L, timeDisplay); // Update Time Widget
timer.setInterval(1750L, AnalogSensors); // Misc analog sensors on CodeShield
timer.setInterval(2040L, whiteLED); // White LED button monitor on CodeShield
timer.setInterval(4050L, SuperCapVoltage); // Super Cap charge display
timer.setInterval(30000L, DHTSensor); // DHT22 sensor
timer.setInterval(30900L, thermTemp); // Thermistor on CodeShield
timer.setInterval(60000L, sendUptime); // Up Time Widget
timer.setInterval(400090L, dateDisplay); // Update Date Widget
Oh, and did I mention this project is very stable even with all those staggered (and some not) timers?
Well, if it’s true that non-staggered timers will cause problems, then the same problems will occur when the timers occasionally line up. Because of the pseudo-randomness of the timers aligning, this type of problem can sometimes be quite difficult to debug.
Using one timer and your own “scheduler” makes it completely predictable.
afaik, they shouldn’t… as they are executing one after another, not simultaneously. isn’t it?
If the non staggered timers are regularly and frequently occuring at the same time (like this OP), then yes… problems can occur…
But having one or two timers ‘eventually’ coexist for a few ms, once every few hours/days/weeks… well that is not an issue 
No, if 2-4 timers all run every second, then the device will literally try to run all functions at the same time, there will be clashes and things can start degrading. This is a voice of experience before I learned to stagger them a bit.
In your case, maybe, but can you say that this will be true for all cases?
Again, my method prevents it by design.
Yes, yes, I can 
… I use a lot of timers in a lot of projects. One of the keys is to not make any single timed function last too long anyhow, so the rare simultaneous occurrence is not an issue.
As stated, I used to run my timers in ‘clean’ 1 second intervals… (i.e 1000, 2000, 4000, 60000, etc. ) And while things ‘worked’ they didn’t always stay stable, particularly when activating a few extra functions.
Now even with the ‘pseudo random’ staggering, I have much longer undisturbed runtimes.
This timer library was also “designed” to work as required… so nothing wrong with using it with a few layout rules.
Fine. I’ll give you the last word and let the reader(s) decide what they think is best.
@MLXXXp It is not about last words or saying your method is not good (it is fine for those that can do it, and just one of dozens of ways).
It is about supporting and explaining the official timing for Blynk to new users, or even prior users that are unsure of the methods, reasonings, etc. http://docs.blynk.cc/#blynk-firmware-blynktimer
@AdrianStivalet How goes it? I am unsure if your OP issue was only timer related or if you still have other complications with the Advanced Time Input widget?
Hi @Gunner I’m still having issues whit it, hope to find the way to get throug the issues 
still RESERACH, do you have another way?
There are many ways of triggering a relay or something based on time/date/schedule.
The simple Timer
The slightly more advanced Timer inside of the Eventor
And of course the simple to operate in the App, but tricker to code for Time Input that you started this topic about.
And then of course some can make up their entirely different method with other code based timing solutions.
The Time Input Widget is one of the more complicated due to the required coding, but it is also the most flexible. But only by trial and experience with the already supplied info will you figure it all out.
There is rarely any “simple” drop in solution with code, so I am unsure how to assist much further.
Costas has a newer version called EziScheduler.ino that he posted in my virgin thread 
I know… it is referenced in the topic link I posted way above.
I trying to understand your code, but I can’t figure it out some things, in my case, I sense distance with a ultrasonic sensor, temperature with ds18b20, I’m usin 3 pairs of sliders, 2 pairs to control the on/off time for pumps and 1 pair more to control the max/min distance for trigger another pump for refill a watter tank. I trying to adan advanced timer input to control the on/off time for a lamp, in your example you are using this:
PingTimer = timer.setInterval(510L, PingSensor); // Ping distance routine - switched timer.disable(PingTimer); // Disable timer until needed
to sense the distance and this:
PIRTimer = timer.setInterval(530L, PIRSensor); // PIR motion routine - switched timer.disable(PIRTimer); // Disable timer until needed"
to sense movement right? If this is correct can I use it in my sliders routines?
Leaving this kind of timers:
timer.setInterval(500L, CNTRDisplay); // Update Loop counter Widget
for my others routines? This is all conffusing for me
@MLXXXp what’s your suggestion to do about the advanced time input?
If you are referring to my list of timers… that is all it was, a list. Not meant a code you or anyone else to really use. All the code that actually gets called by those timers is something else entirely.
Ok I understand, what I try to say is that doing staggered timers like yours I can solve my conection issues, I think that this probles are like the flood errors because connects and disconects continuosly. Obviously my sensors and virtual pins routines must to be coding as I need. Thanks @Gunner
I still wating for the response of @MLXXXp
@distans and @wanek do you have some suggestions for me, I’m all ears
Thanks to all!