UPDATE: V1.2.1 node-red-contrib-cron-plus scheduler (incl solar events and Timezone support)

I get the idea.

I've been working on adding multiple schedules (via UI) and for the most part it's working.

Should be able to add additional ones via input. Just need to figure out the means of control

E.g. when an input is received with a topic of "add" and a payload object containing something like...

  • name (the key)
  • expression (Cron expression)
  • topic (to send in output)
  • payload (to send in output - applicable when payload type is string/number/Boolean/buffer/JSON)
  • payloadtype (flow/global/str/bool/buf/json/etc)

Good? Bad? Anyone suggest something simpler?

Other thoughts....

  • Handle other inout topics? "Pause"? "Stop"? "remove"? "humanise expression"?
  • Should there be a 2nd output for some of these control topics to respond on?

I'm a bit late to this party but this looks good and in line with some thinking I'd been doing but have had no time to do anything about.

A few thoughts from me though I think most have already been covered.

  • Definitely need the ability to at least run on UTC not just local time.
  • Definitely needs the ability to have multiple schedules in a single node to cover complex requirements.
  • I think that, when adding new jobs via an input message, the topic name should include a prefix so that things aren't accidentally triggered - maybe something like "cron-add" rather than just "add"?
  • Following on from that, "cron-change-n" could change a specific entry programatically?
  • Will output topics/payloads be set by job or globally? Maybe that could be a choice? Take a default global setting if not set for a specific job, leave the global blank if you don't want that?
  • Have you thought about an input trigger that would send out the next "n" job triggers? Perhaps to a 2nd output?
1 Like

Some good input for consideration. Thanks.

Hi all. V0.2.0 in github now.

If you wish to try it out, cd into your .node-red folder then...

npm install Steve-Mcl/node-red-contrib-cron-plus

src: https://github.com/Steve-Mcl/node-red-contrib-cron-plus

Features...

  • Evaluate CRON expressions
    • Human readable CRON descriptions
  • Send timestamp, string, number, boolean, flow variable, global variable, JSON, Buffer or Env variable as the output.
  • Settable output variable (normally msg.payload but it is up to you)
  • Multiple schedules can be entered by the UI
  • Ability to add, remove, list, stop, start, pause schedules by a payload input permitting full flexability & dynamic control
  • An optional limit can be set per schedule. This permits you to limit how many times it will trigger.
  • Full demo flow provided in node-red editors menu > import > examples.
  • Optional timezone setting suppoting UTC and Region/Area (e.g. Europe/London)

Some screen shots...

Updated built in help detailing how to perform dynamic operations...

The UI for adding multiple schedules...

Dynamic operations...

2 Likes

Done in V0.2.0. You can inject a payload = {"control":"pause","name":"my-cron"} or payload = {"control":"pause-all"}. There are accompanying control types of "add", "remove", "remove-all", "stop", "stop-all", "start", "start-all", "describe" and some others i forget right now. Essentially, its now a bit more dynamic.

That has been shortened somewhat. Still toying with a checkbox to enable/disable.

NOTE: V0.2.0 is not yet in NPM

1 Like

This is fantastic work Steve, nicely done.

One point though. You have the name going through as the topic which is confusing and not in line with other nodes. Could you add a topic field to bring it into line? I think that generally, nodes will pass through topics from input to output where that makes sense and will be overridden by the topic field if present.

The name field is generally used to make flows clearer (self-documenting).

2 Likes

Hi @TotallyInformation - its really just a visual thing. I can rename "name" to "topic" but the effect is the same.

As you likely realise, the reason the "name" comes through as topic is to let a user know which schedule has triggered & also why it is enforced (topic is almost always optional)

I can of course change it to topic on the UI & internally but it feels a bit weird addressing the schedule by "topic" when performing control.

e.g this ...

{
    "command": "remove",
    "name": "my schedule",
}

feels better than this ...

{
    "command": "remove",
    "topic": "my schedule",
}

and while I could leave it as the "name" in the control JSON, it then wouldn't match up with the UI field.

I suppose the solution is to actually ADD another field to the UI and separate name from topic - but it seems superfluous to me.

The documentation does indicate the name will be used as the topic.

NOTE: This is not a pass through node so I didnt think it would be such an issue as it wont be overwriting someones topic.

If you guys feel strongly enough - I will amend.

Let me know your thoughts please.

Perhaps the placeholder could say "topic/name"?
or I could permit the control JSON to address a schedule by either "name" or "topic"?

Thoughts?

My point was that both name and topic are useful. Name to enable users to give a sensible name to that point in the flow and topic for a machine parsable identifier.

All Nodes should have a name field and all nodes that want to pass forward a sensible identifier (as you've correctly said this one does) also have a topic.

While the word topic might feel slightly strange if only considering this Node, when you take into account the wider architecture of Node-RED, topic becomes much more understandable. But even if it didn't, topic is the field that is very common, works seamlessly with the internal nodes and with MQTT and other databases. If you don't use topic, people will only end up having to put in another change node to convert it.

That is reasonable and I think you are right not to worry about passing topic.

Ill have a think. I believe it is something I can add without causing compatibility issue with current version.

Appreciate the feedback.

In the meantime, the node is now published in NPM and is in the library...

1 Like

Update time - just published V0.30.

New Feature - use Dates as well as CRON

This adds the ability to not only schedule events via CRON like syntax but by a date or sequence of date.

e.g. you can enter 1609459200000, 2021-12-31 00:00, 2022-12-31 08:00 GMT+8 and it will figure out what you want.

Additionally, you can send (via payload) a date object, a timestamp , a string or an array of mixed items (if you wish) to create schedules.

No fancy update gifs this time i'm afraid.

4 Likes

Nice ! (need 9 characters to post!)

1 Like

I suggest changing the name of the node to "node-red-contrib-cron-plus-the-swiss-army-knife-of schedule-nodes" :slight_smile:

Great stuff!

3 Likes

Haha. I aim to please.

Tbh, Cron syntax is very useful but sometimes you just want something to happen at a particular time.

I often see questions like how to I set a time for something to happen. Usually it's via dashboard.

So I plan to at some point make an example flow that does the following...

  • Lists existing schedules
  • Permit user to add a Cron schedule and by using the describe command tell them how it'll work
  • permit user to add 1 or more specific dates

All of this via a dashboard sample.

1 Like

I must admit that despite my long, ongoing love of Linux I never used cron very much. You have re-awakened my interest!

1 Like

Sorry Steve. I'm stupid.
Worked it out - typically: after posting.

Um, looking at the example, I am seeing something I don't understand.

I know/get that things can be ZERO COUNTING, but . . . . that can't work here.

See picture.

I have started and enquired about the "every 8" so why are there "every 7" events happening?

Ok, so I had to have a look at the demo flow to jog my lousy memory.

If you scroll down a bit on the demo flow (or click the debug entries link to take you there) you will see a comment above a part flow labeled "Demonstrating 1 schedule creating another". This part shows how one schedule (every minute) can create another. Its aim was to show how to achieve the peculiar pattern of 2 triggers, 7 seconds apart, every minute. Admiringly it is a more advanced example.

Watch the GIF below - it shows there are indeed 2 distinct triggers ("Every 8 sec" AND "Every 7 secs"). I get it is a bit of a melon twister but it's designed to demonstrate the crazy flexibility of this node!

1 Like

Thanks Steve.

Hi Steve, I installed the latest version from the palette earlier and saw a few things.

  • day of week in the help text shows as “0-7” but is still zero-indexed. Accidentally typing “7” when meaning Saturday shows in the yellow explanation note as Sunday. Should “7” even be a valid option in the first place, as well as presented that way in the help text?
  • (lack of) presence of the year in the cron format will have the explanation preview sometimes explain hour as day.

I’ll try to record those later, typing from my phone now. First time using your node, working great in combination with my Pushcut notifications :slight_smile:

1 Like