Is there a best practice as to how I should be setting intervals for my timers? I feel like I should stagger them so they’re not interfering with each other - but is that necessary? In other words, is this:

Actually, I have found great benefits in staggering them (as needed), since while these are not multitasking systems, timers are based on interrupts… so multiple timers all set for 1000ms (1 second) WILL try to process their respective functions in a pseudo simultaneous method… and this can really mess up longer functions.

If you need something(s) to happen all at “the same time”, and as long as they are fast enough functions, then simply lump them all into a single timer control.

Otherwise, if you just need them to keep their own schedule, then stagger them so as to not “correspond” with each other to many times over a period. E.g. Timer1 @ 1000ms and Timer2 @1500ms WILL try to process at the same “time” once every 3000ms. so I usually just add or subtract 10 - 20ms here and there to minimise that happening.

It is mostly based on my experience in testing many functions, all running with their own independent purpose, on my Blynk testbench project. Arduino Mega with diYode Codeshield, and more… formerly running via USB and now connecting via ESP-01.

When everything is running smoothly the LED tends to have a fairly consistent flicker… but when something is getting bogged down, it tends to stay ON or OFF for extended periods (1/2-2 seconds at times). and if that happens too often, then I fiddle around with the timer offsets and check results.

I have another quick question @GunnerTechTools@distans - I’m trying to make a physical LED stay lit while I’m connected to Blynk. It’s working - but it turns off for about a second or two every now and again - it doesn’t follow a strict pattern. Here’s the code:

but it turns of for about a second or two every now and again - it doesn’t follow a strict pattern

See my post just prior… that is the same idea I had… works quite well actually… and the longer pauses are simply something blocking/delaying the primary loop (in my case) or blocking/delaying your checkConnection() loop.

I set my LED in the main loop as follows… Combined with the WDT in the void setup() it is currently set to reset the Mega if disconnected from Blynk for 8 seconds.

I think I found the culprit for the high latency! Since the sensors are very popular and widely used, others may find this to be of interest. If you Google DHT22, chances are you’ll end up at Adafruit’s homepage and consequently pick their library.
In the DHT.cpp from their library you find this:
`pinMode(_pin, INPUT_PULLUP);`
and
// Go into high impedence state to let pull-up raise data line level and
// start the reading process.
digitalWrite(_pin, HIGH);
delay(250);
This doesn’t…

I only have 6 timers in my sketch and the fastest interval is 1 second. But you have a lot going on at a fast rate so I can understand why it gets bogged down now and then. I haven’t experienced any problems but will add a LED and change the timers a bit.

Yes, I am but I only call that sensor every 30 seconds (and get data from a bridged, outside one, every 5 min)… and only that fast as I am testing stuff and don’t want to wait 5-10 minutes to see if the display changes… 1/4 second per read isn’t that bad for a sensor that shouldn’t be read more than once every 2-5 seconds in the first place.

distans:

But you have a lot going on at a fast rate

…primarily becasue it is my testbench setup. Mostly independent routines; testing code snippets for flashing, latching, sweeping, bridging, etc. Absolutely noting is critical… but it is where I determine if a code routine can survive here, it should work just fine in a separate project Problem is I rarely remove the test afterwards… as it is also my goto for stored snippets since I can’t remember how to spel, let alone remember code syntax

1/4 second per read isn’t that bad for a sensor that shouldn’t be read more than once every 2-5 seconds in the first place.

True, but I have always wondered why everyone want to read their temp sensors so frequently. It might be critical if you cook meth or something (guessing, don’t really know) but for normal in/outdoor temperature it seems excessive.

Still, 6 ms with Arduino’s recommended lib must be tempting to use instead

@GunnerTechTools do you have any definitive test that timer intervals really matter? I’m not convinced it makes any difference. With all the hardware you have hooked up I don’t think you would know one way or another if it’s timer related.

Perhaps just run 2 functions both set at 1000L to see if there is any clash.

Definitive… no, mainly because I am just not feeling that methodical most of the time

But the fact that I can have so much happening, and on a slow 16MHz Arduino, without total system uselessness is primarily becasue I started modifying how I set the timers. Before I started doing that I couldn’t activate certain functions like the PIR or Ultrasonic scanners (they are the first two timers in my post… and are set so as they can be enabled only when required) without commenting everything else out… But now I can run them and not have immediate issues.

No one in their right frame of coding sense would have a project that runs like my testbench… Everything works, but can get sketchy if I activate to much at once, and there is a little bit of jerkiness in some of the actions that would normally be smooth if running alone, (like the timer based slow motion servo sweep)… but then thats not the purpose of this project… testing and code retention is

Costas:

Perhaps just run 2 functions both set at 1000L to see if there is any clash.

Easy (I think)… but add in 14 more and you might have a different story Unless the functions are dirt simple and not time critical.

The other possible issue that I have a hard time confirming or denying, is WiFi interference and network overload. Most of my testing at my workbench, at the back of the RV, while my server and router is at the front… and I am running many, many, much things 24/7/365