I'm working on v3 of node-red-contrib-cron-plus and before I get too far down the road I'd like some opinions on the headline feature.
v3 itself brings a swap of the underlying solar library (which is why it's a major version, computed solar event times shift by a few seconds (more accurate)) and includes lunar rise/set features. But the thing I want feedback on is a second node being added to the package: Cron Filter (see item 4 at the end).
What it does
It sits after a cronplus node (or TBF, any node you desire) and allows or blocks messages based on a time based condition. Output 1 is for "allowed" messages, output 2 is "blocked" messages (so you can set a sensible text condition and the 2nd output is the natural negation - also useful for logging!). So you can run a schedule every 5 minutes and only let messages through "when the moon is visible", or "on weekends or after sunset", or "between 15 and 30 minutes past the hour". Things cron syntax can't say, or can't say without mucho pain.
The interesting part is how you enter the condition.
There are no dropdowns.
You type what you mean:
As you type, a line under the field shows exactly how your words were understood. If it can't make sense of the input it says so and suggests examples. This is a plain parser, by the way. No AI, no cloud, nothing leaves your machine. It's a tokeniser / grammar parser, so the same text always parses the same way, offline.
Why free text instead of form fields
I did sketch the "proper" UI first. Day of week checkboxes, week of month selectors, month pickers, year ranges, sun elevation min/max, moon phase dropdowns, and/or/not group builders... it turned into a wall of widgets before it covered half the cases. Every condition type multiplied the dialog. And honestly, nobody (well me) wants to click through 10 fields to say "weekdays between 9am and 5pm".
Free text turned out to be easier from both ends. Easier to build (and maintain ) than that form & quicker for users, because you already know how to say what you want.
Examples
These are real inputs and the actual "understanding" text the editor shows for each:
| You type | It understands |
|---|---|
on saturdays only |
day is Saturday |
weekdays between 9am and 5pm |
day is a weekday (Monday to Friday) and time is between 09:00 and 17:00 |
1st day of the month |
day of the month is 1 |
3rd tuesday of the month |
day is the third Tuesday of the month |
last month of the year |
month is December |
christmas eve |
date is 24 December (christmas eve) |
quarter past five |
time is 05:15 |
ten past |
the minute is 10 past the hour (every hour) |
is night |
it is night (sun below -18 degrees) |
2 hours after sunset |
more than 2 hours after sunset |
sun above 30 degrees |
sun altitude is above 30 degrees |
moon is high |
the moon is high (above 45 degrees) |
moon is 90% illuminated |
the moon is at least 90% illuminated |
on weekends or after sunset |
day is a weekend, or after sunset |
(last day of the month or wednesday) and after 10pm |
(day is the last day of the month, or day is Wednesday) and time is after 22:00 |
odd months |
the month number is odd |
even days in janury |
the day of the month is even and month is January - assumed 'january' for 'janury' |
weekends after 10pm when the moon is visible |
day is a weekend and time is after 22:00 and the moon is above the horizon (visible) |
Conditions combine with and, or, not, except and brackets. Without brackets, and binds tighter than or, and the understanding line always shows the grouping it settled on, so mixed conditions are never a silent surprise. Minor typos get corrected ("saterday" works, with a note saying what was assumed).
Knowing what will happen before you deploy
Next to the understanding line there's a "details & upcoming matches" popout. It breaks the condition down (days, dates, months, years, times, sun, moon) and previews the next few periods when messages would actually pass, computed for your location and timezone:
Once deployed, the node status shows the current decision and when it will next change:
The practical bits
- Sun and moon conditions need a location. The node takes it from the incoming message (
msg.location, or the schedule location a cronplus solar/lunar event already carries), or from a fixed/env setting on the node with the same map picker as cronplus. - Messages are judged by their own timestamp when they carry one (
msg.tsor the cronplus trigger time), otherwise by arrival time. Handy for testing: inject a message with a Tuesday timestamp and watch it route. - The condition itself can come from a fixed string, an env var, or a message property, so different messages can carry different conditions.
- Output message adds
msg.filterwith the decision (the parsed description and a per clause explanation of why).
What do you all think 
- Does the natural language input feel right or would you rather have had the form fields after all? (ps, I am unlikely to waver here, but asking to get feelskis)
- What phrases would you expect to work that might not?
- some examples of what you would hope to enter (and be understood) would be great!
- nothing too wacky and must be time/date/solar/lunar relevant!
- A couple of judgement calls I made (argue with me): "the sabbath" means Saturday, "last day of the week" means Sunday (weeks start Monday, ISO style), and "moon is 90% illuminated" reads as at least 90%. Each is spelled out in the understanding line so nothing is hidden, but the defaults are debatable.
- The name of the node: "Cron Filter". Yeah, I hate it too! Any thoughts? "Time Gate", "Time Filter", "Temporal Switch", "cron router" other?
Does what it says on the tin.
) but you can be explicit too:
