You could feed them via a trigger node set to send nothing then send last received. That way it would just send the last one it should have sent so the blinds etc should be set correctly for the current time.
Update V0.6.1 in GIT (not yet published to NPM) - need beta testers
Installation...
Install from GIT
npm install Steve-Mcl/node-red-contrib-cron-plus
Info...
Announcing large(ish) update. As well as several bug fixes and documentation improvements, the following is now supported...
- sunrise and sunset events (with +/- offset) by location with a popup map to simplify entering coordinates
- Support for cron special symbol
? - new msg flags
scheduledEventandcommandResponseto clarify what the output msg is - added option to direct command response messages to a separate (2nd) output
Some graphics might help...
New features in action...
Updated built in help now describes special commands and lists support of ?...
New version has msg.scheduledEvent flag for scheduled events and msg.commandResponse for ... you get the idea 
Done
Done.
? now also supported (the author of the cron library I use was kind enough to add support)
3 Likes
Nice, though the map is a little over the top - love it!
Perhaps 
Don't forget, not everyone is online all the time, so loading maps may not work. Hopefully it fails gracefully.
1 Like
Yeah, at some point I intend to put a "no internet" message or something when I figure a nice way of handling that. Any pointers?
Hello Can possible to send payload as Object or set flow
I try with object message but show me the type message not a value in object
Change type from str to json
Hi Steve,
Tested your latest where you have sunset/sunrise and offset options available, works fine
Just one thing I miss; to allow synchronization of attached services or devices, it would be useful if it could be possible to set a repeat time of last output message. Like once a minut or every 30 second etc, you know what I mean
Currently, in my test setup, I made this "helper flow" around to let the last message be repeated every 60 second to sync a LED on a GPIO output. It works fine but would be nice if I could get rid of it
This is a useful node for repeating messages at defined intervals. I use it a lot.
2 Likes
Thanks. I'm in the last stages of publishing the finished article soon.
As you know a Cron entry can do that already. Additionally, the dynamically programmed Cron entry can have a limit set
But...
Do you mean an option to accompany sunrise/sunset that would permit x amount of resends at t intervals?
I'm willing to explore additional options if they make sense but in truth, there is a node like @Colin suggests - if it does this well then perhaps it's better outside of this node?
Yep, exactly that functionality but as you say, the recommendation by @Colin (I was not aware of that node) will do it. So does my simple "helper flow". Anyway, fine, might be better not to make the node "too fat", it's anyway easy enough to configure the functionality if required
Is there a way when using sunrise/sunset to get it to send the appropriate value on deploy? That is a bit of an issue for me if node red is not running at that time.
1 Like
Yes, that would be really good
I'm sure I can sort that bit could you give a little detail please.
E.g. suppose you have a sunrise for NE England set (let's say that's 6:43am tomorrow) and your box is off until 13:00 - what would you expect to happen?
Suppose you have a sunrise +60m offset event called "kids bed time alarm" and the box is powered on at 3am?
Let me know your logic - I'll be happy to add small tweaks like this.
...a wish, also if that could be triggered by an input command?
sorry interferring, it was for @Colin I know, but is it ok to give an opinion on this?
I think,,,,in the example you give, the sun will be up at 1:00 pm so I would expect to get the "sunrise" schedule to send out its configured payload on the output
In any moment, whenever deployed (or triggered if you accept that idea) the node should send out either the sunrise or sunset configured payload depending on the actual sun state at that specific moment (in that geo location). EDIT: And if you have multiple sunrise/sunset entries of the same sort fulfilling that rule, I would expect payloads from all of them being sent out
@krambriw's suggestion would work well for me, but I can see there is some subtlety required in the algorithm. I suppose the test is whether it is after sunrise and before sunset, or vice versa, allowing for wraparound into the next day.
Always nice to see other people tying themselves in logic knots for a change 
1 Like
