Hi Tarik,

I’m not entirely sure about the implications, limitations, or risks. However, from what I’ve seen in some older code, I got the impression that in the past it was necessary to explicitly start timers because they were stopped by default, or at least that was the convention at the time.

Nowadays, since the DIS sets timers with initial = true by default, I generally don’t see those actions being used as much, nor the need to manually start timers.

That said, they can still be useful in certain scenarios. For example, if you want to guarantee that one timer starts before others, you can set all timers with initial = false, and then start them only after a specific condition is met.

A practical example I worked on some time ago involved a slow timer responsible for maintaining a valid token with a device. It only made sense to poll data from faster timers once that token was valid. So I ensured the communication timer started first, established a valid token, and only then triggered the other polling timers to start. This avoided having to add extra logic in the on startup QAction.

Of course, you could also add conditions to the groups (it’s generally not recommended to put them on timers), but I felt this approach was cleaner and avoided having timers constantly trying to execute groups when it didn’t make sense.

I think those actions help give you full control over your timers and can be useful in scenarios where the device becomes overloaded and you need to reduce or stop data polling in certain situations.

Kind regards,