The inject node is well designed as the element that is often the start of code functions. It is pretty versatile and provides pretty much all the topic / payload options one could need to send.
I'm sure many however, like me, who use a significant number of inject nodes in their projects, often find a 'desire' for more "trigger" options. So I thought I'd offer a suggestion for discussion. Often timing is critical and I must use 1 sec inject nodes to trigger code in a function node. There can be a lot of these around and when trying to do something (as example) right on an hour change, it can be hard to get consistent (or accurate) results.
For example, currently the interval between times option is handy but it is limited to only 12 timing options to a max of 60 minutes, no seconds or hours. But even if those options were there, it is still fairly specific in what it'd do AND, one cannot tell it to sync up exactly on the hour change.
My question is - Would it be much work to create an inject mode option whereby the inject node would send the payload at a specific time, and then every x seconds, minutes or hours afterward (based on the initial inject timing)?
Or, actually, even better would be the ability to enter short trigger defining code to make this really flexible. As example: if (hour % 4 === 0) (IE: every 4th hour, including 0:midnight).
This is just a suggestion meant to open dialogue about possibly enhancing the inject node. I get it tho that keeping things simple is important and this might cross that bar.
The core nodes aim to do one thing and do it both well and be easy to use for everyone. So adding more features isn't necessarily a benefit for the majority.
In addition, there are numerous timing/scheduling nodes because different people find different ways of doing things beneficial. So for that reason also, I'm not certain that adding more features to inject would be a good idea.
One other thing to note is that node-red, as a node.js based platform running on a non-realtime OS is rarely going to achieve perfect timings since there are too many things that can interrupt the execution loop. So it is always good to be cautious when trying to rely on exact timings. Best to move such things onto dedicated hardware running a real-time OS.
I hear you TotallyInformation. I don't require enormous accuracy on this, I just know the inject node will provide more consistently accurate timing then triggering code written in a function node every 1 second.
Have you tested that? I'd be surprised if a setInterval loop is less accurate than the inject node for 1sec intervals. Though maybe inject uses a library that corrects for drift?
It is what drove me to create my initial message. I find the inject node is accurate enough for my needs and more consistently accurate (enough) then tickling a function node every second.
Additionally, and I forgot to include this in my earlier message, there is no way to trigger two nodes at exactly the same time (at an exact specific time and interval) using the 1 second tickle method.
That uses setTimeout with timestamp comparisons to stop drift as expected. So I'd expect that for sub-second use, eventually setInterval would become better simply because it has less to do - cronosjs has to constantly check whether a job should run and creates a new setInterval each time. The more ticks that takes, the less accurate sub-second accuracy would be. When I say sub-second, we would probably be looking down at the few hundred ms level.
and don't forget that nodejs is at heart a single threaded event loop. So in reality no two event will ever be processed at the "same time", one node will always get handled first.
I'll go ahead and use Steve's suggestion. It would be nice however to consider implementing something in the core node. The inject node is by far the most heavily used node and somehow my library of nodes just keeps growing .... lol.
Last (important) point. I note that Node-red-contrib-cron-plus has no inject once after ___ seconds upon initialization. So, still 2 nodes required (core + contrib) to manage inject in many (not all) cases.
I have mulled that over for some time but never reached a sensible solution (considering there could be 0, 1 or many schedules)
But, as the mantra (and Dave) goes, do one thing & do it well - suggests I shouldn't. So for now, until I have a lightbulb moment, everyone will have to continue to use an inject for the init startup pulses.
No it's not hard (messier maybe). My initial message was just a suggestion, to open a discussion regarding whether this was of interest for others. It was never meant to be criticism of anyone or anything. For me this was solved with the contrib suggestion . My last point was, well, just a point. I get the preference to not over complicate the core nodes.
I was more thinking that there might be something in having a 3 days, 2 hours and 45 minutes after start type option? I don't think you can do that with the inject without using multiple nodes.
However, I don't know how often it would be used.
But it feels like it would be fairly easy to add into the drop-down list along side cron, date sequence and solar events.
. I shall consider it 
