Time input, start/stop time to trigger a solid state relay

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.

1 Like

Yes, yes, I can :smile: … 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.

2 Likes

@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 :frowning: 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 :slight_smile:

I know… it is referenced in the topic link I posted way above.

1 Like

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 :frowning:

@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!

1 Like

A post was split to a new topic: I need to set timers for relay with esp-01

Are you asking about more details on how to stagger calls using a single timer, or something else?

For staggering the calls:
Looking at your last code posted, it appears that you want to do 3 actions, each of them once per second, and a fourth every 20 seconds.

You have 4 events to time with a granularity of 1 second so you would have a single timer time out 4 times per second. Then, you would use a global variable as an index to determine which one of the events to call on each timeout. For the 20 second event, you would have another global variable to count 20 seconds.

unsigned char eventNumber = 0;
unsigned char temperaturaCount = 0;

void setup() {
  timer.setInterval(250L, eventTimer);
}

void eventTimer() {
  switch (eventNumber) {
   case 0:
    led_control();
    break;
   case 1:
    MeasureCm();
    break;
   case 2:
    if (++temperaturaCount == 20) {
      temperaturaCount = 0;
      Temperatura();
    }
    break;
   case 3:
    EncendidoSumpLamp();
    break;
  }

  if (++eventNumber > 3) {
    eventNumber = 0;
  }
}
1 Like

WOW @MLXXXp doing this I only use 1 timer for 4 process and all I’ll occur in one sec. very impresive!!! so will never flood the server doing this in 250 mSecs? I’m understanding right

Neat, elegant, simple and wonderful way of staggering timer calls. Everyday brings some good learning here.

1 Like

As long as the longest function called is completed before the 250ms is up… otherwise it is absolutely no different then improperly staggered timers (and no better than properly staggered ones :wink: )

1 Like

@mohan_sundaram I’ll try it, @Gunner I understand what are you talking about, if I have a function that last mor than 250 ms I presume that I can increase that number until get it work right? Indeed everyday brings some good learning here from all of you guys. It’s been a nice learning.

1 Like

It could be better or it could be worse, in terms of code execution efficiency. It depends if, overall, the code to scan, and possibly handle, 4 timers instead of 1, each time timer.run() is called in loop(), takes longer than the switch statement in eventTimer() takes to run only each time the single timer times out. I’d bet on the switch statement taking less time.

The single timer method will probably use less RAM as well, since (in my example) it only needs 2 bytes plus the RAM to allocate 1 timer, instead of the RAM to allocate 4 timers.

Also, the single timer method guarantees that the events will always execute in the same order, which could be important in some cases.

And, the effort to come up with, and possibly have to “tune”, the time values to properly stagger 4 timers isn’t required with the single timer method.

1 Like

Choice comes down to “Six of one, half dozen of the other” :wink:

But I prefer timers for the flexibility… Interval timers (adjustable/countable loops or infinite) and/or Timeout timers, ability to enable/disable, trackable… And so on.

I have 11 constant interval timers, two more set to enable/disable as needed and I can’t remember how many timeout timers for various counting, servo, graphic effects etc… even one lambda function timer just so I can have it in the sketch for easy reference.

None of that could be easily done with switch case or for() loops. And all in a single sketch on my MEGA… all running perfectly and under 44K storage and 2.7K dynamic.

Now this is not saying anyone has to use timers :stuck_out_tongue: Just that they work great, are part of Blynk and should be recommended to new users for continuity sake when learning Blynk.

Yes… same rule applies for most any method used and with any timing sensitive computation on a non-realtime OS… Wherever possible, finish whatever dedicated function you start before moving onto the next… otherwise the MCU will try to do both (probably interlacing between commands), but can cause strange results.