I have been using the node node-red-contrib-cron-plus for a little while now, converting all of my flows over to this node... All is going well, but I have run into my "skill limit" -
Is there any way that cron-plus can be sent a command to trigger the "Currently Active" job?
eg: Most of my cron-plus jobs are "dynamic schedules" - they have two or more events that are generally "solar scheduled" ... One event would be a "Off" job, turning off a pump etc 8hrs after sunrise, another event in that timer would be a "On" job, turning on the pump 3hrs after sunrise...See Below:
Power failures are a VERY real part of life where I live, so more than occasionally, a start or a stop job gets missed by a power outage...
What I would like to occur, is that on restart of node-red/reboot of pi, any current cron-plus job gets triggered by a inject node(ie the previous job, not the forthcoming one) - Trying the "trigger-active" command sends the result of all dynamic schedules sequentially, not just the "forthcoming" or the "just past" event...
This is something I have thought about several times however never came to a suitable solution. For example, how far back would you go?
Consider this, if a schedule was 0 0 0 1 * * * (midnight on the 1st of month) and the system restarted at 23:59:59 on the 30th Apr, should I trigger that one?
That is only one very simple / basic scenario.
In short, I am sorry to say, it doesnt support that out of the box.
However, you can manually achieve what you need.
Here is a demo...
[{"id":"8f1c9aed5c0928fd","type":"function","z":"553814a2.1248ec","name":"build describe command","func":"var now = new Date();\nvar yesterday = new Date(now);\nyesterday.setDate(yesterday.getDate()-1);\n\nmsg.payload = [{ \n \"topic\": \"off\",\n \"payload\": false,\n \"command\": \"describe\", \n \"expressionType\": \"solar\", \n \"solarType\": \"selected\", \n \"solarEvents\": \"sunrise\", \n \"location\": \"55.48508207711703 -1.7572036385536194\", \n \"offset\": \"480\", \n \"time\": yesterday\n },\n { \n \"topic\": \"on\",\n \"payload\": true,\n \"command\": \"describe\", \n \"expressionType\": \"solar\", \n \"solarType\": \"selected\", \n \"solarEvents\": \"sunrise\", \n \"location\": \"55.48508207711703 -1.7572036385536194\", \n \"offset\": \"180\",\n \"time\": yesterday\n }]\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1610,"y":540,"wires":[["4fa9e3765c8ca157"]]},{"id":"bc294209f6b40241","type":"inject","z":"553814a2.1248ec","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":true,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":1570,"y":500,"wires":[["8f1c9aed5c0928fd"]]},{"id":"4fa9e3765c8ca157","type":"cronplus","z":"553814a2.1248ec","name":"","outputField":"payload","timeZone":"","persistDynamic":false,"commandResponseMsgOutput":"fanOut","outputs":4,"options":[{"name":"schedule1","topic":"off","payloadType":"default","payload":"","expressionType":"solar","expression":"0 0 0 1 * * *","location":"55.48508207711703 -1.7572036385536194","offset":"480","solarType":"selected","solarEvents":"sunrise"},{"name":"schedule2","topic":"on","payloadType":"default","payload":"","expressionType":"solar","expression":"0 * * * * * *","location":"55.48508207711703 -1.7572036385536194","offset":"180","solarType":"selected","solarEvents":"sunrise"}],"x":1560,"y":600,"wires":[[],[],[],["635b1f73672c2e3f"]]},{"id":"635b1f73672c2e3f","type":"join","z":"553814a2.1248ec","name":"","mode":"custom","build":"array","property":"payload","propertyType":"msg","key":"payload.command.topic","joiner":"\\n","joinerType":"str","accumulate":false,"timeout":"","count":"2","reduceRight":false,"reduceExp":"","reduceInit":"","reduceInitType":"","reduceFixup":"","x":1730,"y":617,"wires":[["878c90c061024172"]]},{"id":"878c90c061024172","type":"function","z":"553814a2.1248ec","name":"","func":"var data = msg.payload;\nfunction compare(a, b) {\n a = new Date(a.result.nextDate);\n b = new Date(b.result.nextDate);\n if (a < b) return -1;\n if (a > b) return 1;\n return 0;\n}\nvar sorted = data.sort(compare);\nmsg.sorted = sorted;\nmsg.topic = sorted[0].command.topic\nmsg.payload = sorted[0].command.payload;\n\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":1860,"y":617,"wires":[["bf1ac1b2e6dfd3b1"]]},{"id":"bf1ac1b2e6dfd3b1","type":"debug","z":"553814a2.1248ec","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":1990,"y":617,"wires":[]}]
In my twisted logic, I would only look at deploying the previous job - (Un)fortunately, your cron-plus is so versatile, you can have a single timer node with a host of events all pointing to different topics for outside sorting.... this is not what I am doing, I am dedicating timers to a particular device.... But yeah... with the versatility comes complexity, flexibility and sometimes inflexibility at the same time!! It's all good!
I will take a look at your manual demo and come back to you!
Another alternative, particularly if you are already using MQTT, is do everything through MQTT topics that trigger an action. So the cron event, rather than directly triggering the action, publishes to an MQTT topic. Then have a flow subscribing to the topic that runs the action when it sees the appropriate message. If you make the topic Retained then on startup the previous value of that topic will get sent to the action flow, so restarting the action on a node-red restart.
That is a neat way of doing it... I have a "bit much" happening on the mqtt side of things, as well as a good few goodies on solar timers.... My old brain will get (more) addled, methinks, if I do it this way though.... (Much easier for me to see it all on a single flow and go: "Ah - that's where I screwed it up"...)
