Just to note, I still wouldn't personally wish to see this in the core inject node.
1 Like
I also wouldnāt want to see it in the inject node.
How do we try this PR? it's easy with contrib nodes, but sadly not obvious with core nodes 
I assume it would be backward compatible, without breaking existing flows.
Although I favour leaving the core inject node as it is currently, @buglss has committed a lot of work to this submission, and at least we should try it first to get a feel how it fits into the node-RED schema.
2 Likes
The easiest thing would be for it to be converted to a contrib node but not published to npm. Then anyone can try it out who wants to by installing from GitHub.
Just remember to change the name of the node throughout so that it doesn't clash with the built-in inject node.
1 Like
Try this version of core inject node with cronti from github package.
Node-Red Package: GitHub - buglss/node-red-clone-inject-with-cronti: It is an extended clone of core inject node with cronti package.
1 Like
Thanks, I'll certainly try it tonight when I get home.
1 Like
I think it's a necessary extension because it's simple and easy.
Thank you @buglss
1 Like
I added some new features and push(pull request) node-red:dev from buglss:inject-node-with-cronti.
Updated node-red-clone-inject-with-cronti package. Please use the latest version.
Latest Node-Red Package For Demo: GitHub - buglss/node-red-clone-inject-with-cronti: It is an extended clone of core inject node with cronti package.
Not certain how much benefit fixed dates in the inject node offer.
Also, how does a flow differentiate which of the "two dates" is the "start" and which is the "end" event?
Lastly, the underlying library supports more than the generic 5 position CRON....
* * * * * * * Field Allowed values Special symbols
| | | | | | | ----------------- --------------- ---------------
`-|-|-|-|-|-|-> Second (optional) 0-59 * / , -
`-|-|-|-|-|-> Minute 0-59 * / , -
`-|-|-|-|-> Hour 0-23 * / , -
`-|-|-|-> Day of Month 1-31 * / , - ? L W
`-|-|-> Month 1-12 or JAN-DEC * / , -
`-|-> Day of Week 0-7 or SUN-SAT * / , - ? L #
`-> Year (optional) 1970-2099 * / , -
1 Like
The intervals 2 dates didn't work as expected.
I set it to inject every minute between 22:10hrs & 22:13hrs, so I expected that I would get 3 payloads starting at 22:10hrs.
However, as can be seen, it began outputting at 22:00hrs, and continues even after 22:13hrs.
Perhaps I've misunderstood the notes in the post above.
1 Like
Thanks for your feedback.
Not certain how much benefit fixed dates in the inject node offer.
This need is often encountered in cronjobs. There is a need for transactions in periods such as monthly, weekly, daily, hourly. A few examples of benefit scenarios:
- Sending data saving or sending on the 1st of each month on a monthly. For example, it can be used to send data from system A to system B, or vice versa, to pull data from system B and save it to system A. In this case, the "date" property can be used. Of course, within the framework of this feature, this process can be done once a year. (just for month of date propery)
- An sms or e-mail can be sent to the consumer every day for 1 week, repeating every year. In addition, it may be requested to be discarded especially in the week that this day is in. An example of this is a birthday. A campaign valid for the week of the consumer's birthday is organized and a reminder can be sent every day. In this case, the "week of date" property can be used.
- With a temporary agreement, it may be requested to collect and save data in company A. For example, in a tender process, information about the tender may be requested between the tender start and end date. This cronjob need not continue as the bidding data will never change after the end date. In this case, the "intervals two dates" property can be used.
- SMS or e-mail can be sent for campaign announcement or congratulatory wishes at Christmas. In this case, the "date" property can be used.
- When a 1-month camp is organized, the program for that day can be shared every day. In this case, the "advanced" property can be used.
- In a 1-month project plan, an sms or email can be sent for feedback on Monday every week. For example, in agile project management, scrum teams hold a sprint evaluation meeting every week. In this case, the "advanced" property can be used.
- A coordination meeting can be held on the 3rd Friday of every month on a regular basis. For this, an analysis report can be drawn and prepared before the meeting. In this case, the "advanced" property can be used.
These are just a few examples that come to mind. In these example scenarios, I mentioned "date", "week of date", "intervals two dates" and "advanced" options. These scenarios can of course be increased. My purpose here is to explain what benefits these new scheduling options can have.
I didn't give an example of the "crontime" property because it's the basis of it all. All scenarios can be realized using this feature 
Also, how does a flow differentiate which of the "two dates" is the "start" and which is the "end" event?
Yes, you are right. I'll definitely take care of this tonight. I'll fix this omission.
Lastly, the underlying library supports more than the generic 5 position CRON....
Yes, it's something I'm aware of. I specifically limited it to 5 options. Other options are already optional and I thought they would not be used.
Thanks for your feedback. Yes, I hadn't noticed this error. As @Steve-Mcl said, when it will end is not implemented. I'm definitely going to fix this bug tonight.
It's actually very nice and useful, adding it might be helpful to our team, thanks @buglss
2 Likes
I want to explain a little more.
The cronti package has no dependencies if you are concerned about dependency management. Written directly in spaghetti javascript. Since I use the cronti package in my development for the Node-red core inject node, there is never any problem with dependencies.
Why extend to the core package with this feature instead of using similar additive node packages?
- Since the cronti package is used, it does not break the simplicity of the core inject node in the frontend. By expanding the scope of simply and well, there will be no need to install additional packages and accordingly increase the dependencies in the projects.
- You will not lose anything when you expand the core inject node with this enhancement. There will be no clutter of code side and no clutter on the frontend. The core inject node will not become heavy, it will remain slim.
- One more dependency that you have to check will not be added. On the contrary, it will be an additional feature that you can easily include and exclude without any effort.
Sorry, I was not clear, I meant within the context of node-red and the inject node, how much benefit is a "fixed date"
(of course I understand the benefits of a job being scheduled for a particular day in the year but thank you for the extensive examples)
Any how, my point is moot - I looked closer at your GIF and see that you simply ignore the year part meaning it repeats on that date every year (I initially read this option as a "one time fixed date")
But upon closer inspection I see 
that the cron you generate excludes the year and will indeed repeat every year.
1 Like
But it does. In 2 ways. Firstly it adds user input complexity. Secondly, it adds a dependency on another 95kB package that won't be used for 99.9% of the time.
I'm not really sure why you want to push so hard to get this into the core inject node?
I'm not trying to put down your work by the way, it seems to me to be a great contrib node for those who want it. I can certainly see that it covers a couple of edge cases that perhaps other scheduling nodes don't. But why have it in the core inject when most people won't be using it most of the time? It isn't hard to create a new node after all.
Thanks for your feedback. Also, thank you very much for your compliments about the package I developed.
This is subjective. Not everyone may agree. I expect many people to benefit from these new features as well.
Because I really believe it will be useful to people.
I have this deficiency in my projects and I'm sure others have this problem as well. I think there are many people who don't want to install complex packages like cron+ for simple additions.
1 Like
It is only as complex as you need it to be.
As you said it is subjective.,
1 Like
Some 2 cents, you also just publish it as a contrib node āadvanced inject nodeā and leave it up to people to decide to use it, if the download numbers reflect the needs, it could still end up in the core.
2 Likes
Thank you for everyone's feedback. Please experience my demo node. I would be very grateful if you try my node and give your positive or negative feedback.
A new version has been released for the non-stop cronjob from node-red-clone-inject-with-cronti - pushed to node-red:dev from buglss:inject-node-with-cronti branch for pull request.
Release Note For Demo Package: Release v1.0.12 Ā· buglss/node-red-clone-inject-with-cronti Ā· GitHub
Summary:
