In fact it gets worse. Since the times have offsets then I suppose the test will be greater than sunrise + offset and less than sunset + offset, which doesn't sound too bad, but what if someone specifies a +ve offset on sunrise and a -ve offset on sunset such that they cross over? <Insert your Deity here> knows what it should do then.
Don't cross the streams!!!
Hey, what can I say, it's been a long hard day!
Good point, wouldn't want to cause a discontinuity in the space/time continuum. Though with the current state of affairs perhaps that wouldn't be such a bad thing.
1 Like
UPDATE: April-15th V0.6.4
Soon to be updated in NPM (already in github)
Salient points...
- Updated built in help to better describe Timezone
- Added example for demonstrating timezone
- Added option to send command responses to a 2nd output (simplifies separating schedule events from command responses)
- sunrise and sunset now implemented (and dynamic too)
- Map for simplifying sunrise/sunset coordinates is pure CDN (no installation)
- CDN is dynamically loaded ONLY if you open the MAP
- If you are in an offline environment, it will show alternative info
No internet? no problem...
Got internet? cool - heres a map to simplify setting sunrise/sunset location...
3 Likes
What does the dynamic bit mean?
Is there any change to the operation if node red is not running at the moment of sunrise/set? Currently there is not a sunrise event generated if it is switched off before sunrise and switched on after it.
As in you can add one via a command msg.
no, should upgrade without issue.
That is a pity (no change in operation if not running at sunrise/set). It means I think I can't use this node for a particular requirement as I need to set stuff up on startup depending on whether it is day or night.
Colin, perhaps I am misunderstanding - could you re-state your requirement please (there is a lot of info and noise in the thread).
NOTE: I havent published to NPM yet 
(still time to get what you need)
EDIT - ah, i think its this part...
Is that correct?
It is also possible the node already does what I want, I may have misinterpreted it. At sunrise I need to make some adjustments to my video camera and at sunset I need to set them back to the night time settings. For unrelated reasons node red may not actually be running at sunrise, so when it starts up after sunrise I want the camera adjustments to happen then. As I understand it I won't get an event on startup that tells me that sunrise has already happened so I don't get the trigger to adjust the camera.
1 Like
This is a fundamental must. Imagine you are controlling simple lamps (indoor/outdoor whatever). If you start or restart NR you must expect that synchronization is happening.
Bigtimer does this since long, Cron+ HAVE to do it as well,,,awaiting the wrestling to continue 
Of course cron itself doesn't do that, does it?
1 Like
No idea, but the + promises something more
(I would not like to be the guy on the left side)
Haha yeah. I see what you're doing there.
It wasn't developed as a competitor but I see how you could draw that. Cron+ was ultimately / originally intended to generate multiple schedules and be dynamic & automatable. So far so good 
Proposal v1...
So I'm proposing to add a check box option to the sunrise and sunset entries along the lines of [â] Fire on start up
The method I'm floating is...
Sunrise...
- I calculate sunset+offset & if
TIMENOW > (Sunrise+offset) && TIMENOW < (sunset+offset)then fire
Sunset...
- I calculate sunrise+offset & if
TIMENOW > (sunset+offset) && TIMENOW < (sunrise+offset)then fire
Alternative V2...
I add another input parameter that permits a fire on start up if with window minutes
E.g. suppose you enter 60 as the window and sunrise was 07:00, then powering up at 07:59 would fire it but 08:01 would not.
Anyone have a preference or better ideas? (Sorry if they are further up in the thread - please quote them if so)
Thanks for your input and time.
Steve.
Edit...
I think also, it would be prudent to add a flag in the msg to indicate this is NOT the real sunrise/sunset time event but in fact a power up event.
I'm taking suggestions for the flag name (or should it be a value that indicates the time passed since original event? 
)
I like proposal v1 better I think. With the msg.late (or whatever) value, that could be used to get the v2 effect if anybody needed it. If msg.late is zero for normal on the fly operation then that is all you need to identify what has happened I think.
The Sunset calc should be || I think rather than && but even then neither would trigger if the time were exactly on the one of the limits, but perhaps it would then drop through to the normal logic and would trigger then anyway. Can't you just use NOT Sunrise test for the Sunset one? Either way there is an edge case there to watch out for, for the two in however many msec there are in a day times that you exactly hit one of them on startup.
If people start putting silly values in for offsets then the logic might fail, if they make sunset+offset happen before sunrise+offset for example, but provided it doesn't crash then I don't think I would worry about it.
just stirring (slightly).... why is this just related to sunrise/sunset ? Surely the same option is "needed" whatever time I set. If I set a fixed timer for 6am - and happen not to run Node-RED until 7am would I not want it to fire ?
As Colin pointed out this is not something cron does - so even though it's called cron + I'm not sure that the expectation is that it should... there is as someone points out a perfectly good BigTimer... (amongst other options) that are perhaps more timer than cron related 
Good points Dave.
I have put some thought into the same support for the Cron schedule however my head starts spinning when I consider how to handle really small schedules. Unless it's requested and someone has some sound logic to help me understand how it would work, I dont think adding the option to the Cron schedules is feasible.
On the flip side, not adding the option to the sunrise / sunset - I can see the benefit of this and would perhaps use it myself (I don't personally have a use case at this time) but yeah, I'll find a balance and add it in anyhow.
I think the msg could just provide four states, at any time it is one of these; sunrise, sunset, sun_is_up, sun_is_down
When calculating the last two, you need to consider the offset settings. So, as example, if current time is within sunrise+/-offset it could very well be that the msg says sun_is_up even if the real sunrise has not yet happened. Or sun_is_down even though the real sunset has not yet happened. That's fine I think, exactly how it should work
And would it not be possible then to add support also for an input trigger? I mean if I trigger the input with a keyword, the node would respond with either sun_is_down or sun_is_up (current state)?
You would at least want the option.
Well, it was not my intention either, I just joked a bit using that image, I just saw the possibility to improve the usefulness of your node significantly, my personal opinion is that state synchronization many times is vital in the kind of systems built with NR (and in other systems as well)
Using the normal cron scheduling in the node it is possible to configure an event every, for example, 2 minutes between particular times, which provides a similar capability. It is easy if you want every two mins between 06:00 and 18:00 for example. It becomes more complex if you want every two minutes between 06:24 and 18:38 for example but it is still possible. It is not possible to do a similar thing between sunset and sunrise.
