Let's Control It

Playing around with multiple timers on ESP_Easy_mega_20210223_normal_ESP8266_4M1M, with MQTT publication of each timer finishing, I find quite some variation in their precision.
E.g. one looptimer is is to 20 seconds, but sometime it publishes at 18 sec, sometimes at 22 seconds. Another timer is set to 5 seconds, but also varies 1-2 seconds. Adding timers, seems to add to the variation.

I know that MQTT and the broker adds some uncertainty, but all MQTT events gets executed near to realtime, so I doubt that plays a significant role.

Using just one timer, seems to be pretty stable

If you're running a "normal" or "custom" build, you can also see the timing stats.
If parts of the code use over 100 msec, they are highlighted.
Those can be a cause for jitter in the processing.

Publishing may also have another delay, as MQTT messages are being put into a queue.
So see the controller settings for "minimal time between messages" etc.

To make sure you're not looking at the delays caused by external factors like WiFi reconnect, etc, you can also send the system time as MQTT message.
Something like:
publish,mytopic,%systime%

Or to get a higher resolution, you may use the %uptime_ms% (only on recent builds)

The loops themselves, seem to draw all the horsepower, if I read the table correctly

loop() is like the 'catch-all', as that's the main loop of ESPEasy.

So that one will probably have the highest max. value, but that doesn't mean it is in ESPEasy code if no other monitored part of the code is getting close to that max.

If you never loaded this page since reboot, the first loop is also included.
Every reload the stats are cleared.

These are very respectable timings.
So like I said, just send a timestamp as MQTT message as you then know when it was sent and the NTP accuracy is very good (order of 10 msec off)

By using this, several times in my rules:
I've found that the timers themselves are pretty ok. It's the MQTT publishing which varies quite a lot.

Thanks for the update.
Good to know the internal timers are 'stable'.
The 'jitter' may still be several 100 msec, but there should be no drift when using loop timers.

Almost forgot.. I do think 'pulse' scews things up for me.
I assume this should work:
But it halts rule execution after a while. Commeting out 'pulse', then it works. I'm testing to see how it affect my MQTT publishing.

That's correct.
You can also use longpulse (or longpulse_ms) to have it non blocking.
What it does is it will schedule a call to end the pulse.