The Inject node was failing in advanced time settings. That's why projects had to install external cron packages.
I used the cronti package to set up a advanced cron. The cronti package converts the timing expressions used in daily life into crontime expression. The inject node needed such a package. With the cronti package, you can develop an interface quite easily.
Cronti briefly, it translates daily expressible recipes on the calendar into crontime expression. Produces a valid crontime expression. Link for detail.
What's New?
Create cron of the spesific day of date
Create the cron for the week the date is in
Create a cron that will run at regular intervals between two dates
Create cron with various combinations of month, week, weekdays, hours, minutes and tick
Hi,
Not sure I understand some of those extra options... what do day of date, week of date, intervals two dates do ? It seems like you pick that - but I can't then see what time of the day it would then fire, Is it multiple times between the dates etc ? And how are some of these different from the existing at a specific time that lets you specify a day or days of the week ?
As (has been pointed out) the cron-plus node does a great job of handling much more complex cron constructions with its built in explainer... but this is probably too complex for most users - so yes there is certainly a debate about which simpler options could enhance the inject node - but probably needs some thought as to what exactly those are.
Also I notice the cronti library is released under a GPL license which makes it less attractive to any users that may wish to create derivative works, so certainly it is unlikely we would want to adopt it into the core of Node-RED when other options like cronstrue (used by cron-plus node) are available.
Also, the inject node follows the "golden" rule set by yourself and Nick of doing a job simply and well and not over-reaching. Adding more complex scheduling to it would surely "break" that rule
Personally, I wouldn't want to see it get any more complex since we have lots of useful alternatives anyway for more complex scheduling. I use it for simple flow entry points.
If I want to have a complex scheduled start-point for a flow, I wouldn't want to use inject because it might be hard to spot which flows were using complex schedules. I would prefer to use a node that is more focused on that job.
Well the inject node does use cron under the covers for some modes... so there has always been the thought as to whether to expose that (ie let someone just type in the cron expression) and indeed so far the answer has always been no - too complex/error prone. But there are possibly some other really simple options that may be of use... (though I can't think of one right this second).. but yes I tend to agree - even the "simple" ones tend to stray into being complex when you try to make them "generic" - and then yes we have lots of other nodes for that.
IMO the balance is good at the moment;
Inject node for basic everyday use, and Cron+ for more advanced users or special cases.
I don't see the case for enhancing the inject node, we would just end up with both nodes with similar capabilities, and make the learning curve a little steeper for new users.
These extra features do not prevent the inject node from being simple and well. Rather, they are features added to make it more functional while maintaining its simplicity. The alternatively offered cron-plus package is yes very complex. If I had integrated the cron-plus package, I would have broken the "golden" rule
I would like to explain the new features a little more.
Create cron of the spesific day of date: This feature is used when you want it to be triggered once every year on the same calendar day. For example, on June 4, 2022, on June 4, 2023, on June 4, 2024... By default, the time is set to 12:30. Time can be entered wherever the date is entered (datetime type)
Create the cron for the week the date is in: This feature is used when you want the week of the specified calendar day to be repeated every year, triggering every day of the week. For example, the days to trigger for June 4, 2022 are May 30, May 31, June 1, June 2, June 3, June 4, and June 5, 2022, 2023, 2024... By default, the time is set to 12:30. Wherever the date is entered, the time can be entered (datetime type). In addition, the starting day of the week may differ depending on the country. In the example I gave, the day of the week is Monday.
Create a cron that will run at regular intervals between two dates: This feature is used when you want it to be triggered every day or at certain periods, repeating every year between two specified calendar days. For example, it can be triggered every day from June 4, 2022 to July 10, 2022... In a different alternative example, it can be triggered every 2 days between June 8, 2023 and July 5, 2023... Years don't matter here. For ease of use, the selection screen can be simplified to select the day, month, hour, minute and period. By default it is set to 12:30. Time can be entered wherever a date is entered (datetime type)
Create cron with various combinations of month, week, weekdays, hours, minutes and tick: This feature takes shape when fully triggered. Each entry is optional. Some can be filled if desired. All can be filled if desired. If desired, only 1 can be filled. All are left blank if desired. By default, the time is set to 12:30. Time can be entered wherever the date is entered (datetime type)
More Examples:
If only the month(0..11) and week(0,1,2,-1) parameter is filled, the crontime expression that will be triggered every day from the first day of the week to the last day of that week is returned.
If only the month(0..11), week(0,1,2,-1) and weekdays(0..6) parameters are populated, the crontime expression for that weekday is returned.
If only the week(0,1,2,-1) parameter is populated, the crontime expression that will be triggered every day during that week is returned. Except for the last week of the month(-1).
If only the month(0..11) parameter is populated, the crontime expression is returned for each day in that month.
If only the weekdays(0..6) parameter is populated, the crontime expression is returned for this weekday every month.
If only the month(0..11) and weekdays(0..6) parameters are populated, the crontime expression is returned for these weekdays of this month.
If no parameters are filled in, the crontime expression is returned for each day of each month.
Enter valid cron expression: For people who know how to use crontime expressions, it is a feature used to schedule from a shortcut. For example 0 2 * * *...
Create cron of the spesific date: This feature is used when the selected day is desired to be repeated every month and every year. By default, the time is set to 12:30. Time can be entered wherever the date is entered (datetime type). For example, June 4th, July 4th, August 4th, September 4th 2022, 2023, 2024...
All these features can be achieved by offering only a few input fields. Yes, the inject node is a powerful node with its simplicity. I'm aware of this so I didn't want to use more extensive but more complex packages.
Instead of the datetime input fields, which include the year entry, only input fields with the used values can be put. That way you get a friendly interface.
There is a lack of information in its current state. I will add information sections for this.
In general English, day would refer to the day of the week (Monday, Tuesday, etc) rather than the date which is what you are referring to here (e.g. June 4th 2022). So the phrase "day of date" would probably be taken as something like "run on the given day of the week closest to the given date" - however, the phrasing is ambiguous.
In any case, there are already a plethora of nodes that will trigger on a given date & time. No need to add code or user input complexity to inject.
Indeed, there are nodes that will trigger on "the 3rd Tuesday of June" or similar style date specifications.
Now that might occasionally be useful. I can't find a CRON recipe for that. But it is clearly rather niche. Might be best to hassle the author of CRON+ to add something there
I think that the consensus here seems to be that nobody else wants the inject node to get more complex.
If you have seen a need for something that nothing else covers, it would possibly be best to work with the author of an existing node that is close or to create a new node.
Given how many scheduling nodes already exist, it would be really good not to have another but, if there is a real need for something different then that is absolutely the path to follow.
Thanks for the more detailed explanations of your thinking, certainly the current node is lacking some of the longer timescale option you are talking about. However I think the GPL license is going to be a sticking point.
Thanks everyone for the feedback. The GPL license makes it mandatory to publish only free software, open source code. Node-red is an open source project and has a free software philosophy.
Why would the GPL license be the sticking point? There may be a detail about this that I don't know. I am the owner of the cronti package. I can change the certificate.
It is a restrictive license that some commercial organisations can't or won't work with. Apache 2, MIT and other open source licenses allow commercial derivatives and there are a lot of companies using Node-RED in that way. Indeed, Node-RED originated inside IBM before it was donated to the JavaScript Foundation and IBM don't allow the use of GPL.
That isn't the case. It just takes more approvals to include GPL (and similar) licenses - so you have to be certain it's worth the effort. if there are equivalent, more widely used libraries that have a more friendly OSS license, then it just makes sense to consider them first.
