UPDATE: V1.2.1 node-red-contrib-cron-plus scheduler (incl solar events and Timezone support)

Share Your Nodes
163

You can still feed a schedule into the node.

determine sunrise/sunset for today -/+ x minutes --> cronplus schedule.

I see your point though, would be nice to apply cron scheduling on sunrise/sunset times, but might become complex.

164

@Steve-Mcl - may I have one suggestion:

Currently when entering a cron expression, it starts with an error "invalid or unsupported expression", would it be nicer to show examples instead of an error ?

165

Already considered this & I'm definitely adding that now (as maxims go... great minds think alike)

I've toying with adding an auto complete list of sample expressions but could never reconcile in my head how best to do this. Also been considering having a default Cron entry but couldn't bring myself to choose a default as IMO, the initial error forces the user to enter a value.
How would you handle this?
Opinions welcome.

166

I wasn't meaning that the node could provide that feature between sunset and sunrise, but that a similar effect (state initialisation on restart) can be achieved with normal cron scheduling by using the 'every 2 mins' technique, but state initialisation cannot be achieved where sunrise/sunset determine the required state.

167

I thought cron+ already had the command : status to report the state of any of the schedules ?

168

Yes status & status_all commands but the sunrise/sunset thing is a bit different (I need to add something to its status output to fulfil some of the requirements)

169

In fact I think maybe it is not necessary to do any more than add something to the status output for sunrise and sunset. Just providing the current condition, whether currently day or night based on the settings for the cron schedule, would be good enough, for my purposes at least. I could trigger a status on startup and use that to set my state.

3 Likes
170

I'd vote for that also.

1 Like
171

As I started modifying the UI for adding extra options - thats exactly the conclusion I came to.

I will do some testing and examples & feedback here - see if it fits your needs.

172

sorry - now confused... I think we are advocating NOT changing the ui... just adding the "daytime" true/false to the control status instead.

173

Thats how I'm handling it for first iteration Dave.

I was responding to this ^

Once I have satisfied users base requirements (ability to know if it is currently sunrise/sunset & fire an event at startup) & I have more time, I am going to re-arrange the UI (schedules list part) to make it easier to graphically add options - as it stands, its a major chore.

1 Like
174

While being fancy, instead of sunrise-sunset - use suncalc.js instead and expose all available properties :grimacing:

175

there are of course multiple nodes for that already....

176

Sure, but Steve is doing the same right :wink:

177

well people are trying to make him do it... not quite the same thing.

as we always said - each node should do it's job and do it well... not try to do everything...

eg https://flows.nodered.org/node/node-red-node-suncalc - already provides two outputs - one every minute and one on the actual transitions.

178

I mostly agree with the atomic approach but in the case of cron-plus node, the sunrise and sunset fall under the umbrella of its primary function to schedule events (dynamically) - sunset and sunrise being valid schedules.

Perhaps i should have named it scheduler-plus :wink:

179

convincing him to,,,rather

Many nodes may/are overlapping each other in terms of functionality, like also NR does overlap other applications trying to do similar stuff (who is overlapping and who is overlapped, well it's like the hen & the egg, who came first). I believe, at the end, nodes that best provide most useful functions in an easy to understand & configurable way will be used by most users. In balance with the visibility of the flow. I mean, I node packed with settings and features looks simple from the outside and makes the flow cleaner but may make it more difficult to understand what's going on under the hood if you are just looking at the flow in the editor

180

sunset and sunrise being valid schedules.

So are:

sunriseEnd
goldenHourEnd
solarNoon
goldenHour
sunsetStart
dusk
nauticalDusk
night
nadir
nightEnd
nauticalDawn
dawn

For me personally you can leave it all out including sunrise/sunset, because as said, there are dedicated nodes available to produce this information.

181

and...
civil dawn
civil dusk
astronomical dawn
astronomical dusk
tea time
bed time
hammer time

the list goes on - but it doesnt make the addition of sunrise / sunset any less useful.

Additionally, many of those can be approximated as offsets of location+sunrise / location+sunset.

Lastly, sunrise / sunset is not that expensive to include (in terms of calculation time) so no great shakes.

182

Updated to V0.6.5 (github only - need testers)

Key points...

  • triggered schedules, "status" and "status-all" now provide additional info

    • in particular, any sunrise or sunset schedule now has a sun object with properties including .state (will be "rise" or "set" depending on location, offset and time)

  • ability to perform "describe" command on a sunrise/sunset for location - meaning you can ask for sun state at any time for any location

  • Demo ...
    image

  • status object
    image

This gives you the ability to trigger a "status" command on node-red start & understand if you need to take action.

Acknowledgements - yes there is a fair few properties in there - use what you need, ignore the rest. My personal take on this is - if i dont include things like the timeZone of the server or the offset applied etc, debugging is a pain AND if i DO need that info downstream, i have to jump through hoops (or should i say change nodes, flow/global context) to tack the info onto the object. Context is king.

1 Like