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?
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.
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).
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.
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.
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!
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
