Suncalc - Best practice

[Andreas W.]

Hey,

i just installed the sunrise module.

As it is an inject node, it trigges the next event - and in default, it triggers every 60 seconds the next node with a payload 0 or 1 for sunrise state.

Currently i use sunwait and start it with a cronjob - it waits as process until the sunup or sundown event occurs but it executes the given command just one time

and stop the process after this and has to be restarted with cron to wait again for the given event.

The idea is now to use a function as next step and check if it is an weekday or if its saturday or sunday and send an empty payload to the next node 

until the sundown / up matches.

Maybe it would be better to change the source of the node to prevent polling every 60 seconds - or the very best way would be to

extend the module with cron features like the default inject node with the option 'at a specific time' - in this case the specific time would be the calculated sunup / sundown time

and only fired once this event matches.

Perhaps some else hast the same requirement and solved it already?

kind regards

_andreas

[Andreas W.]

New idea...

 Maybe it is possible to extend the 'Inject' node 'at specific time' feature and replace the 'at' field with sunup and sundown calculated by suncalc function and an

additional field with +/- hours to the sundown /sunup time, that would be a really nice feature as time/sun controlled events are needed everywhere imho.

The 'on' field should be as it is.

:) if i can help in some way let me know - but my javascript knowledge is very basic at the moment...

best regards

[Julian Knight]

The second output only triggers on change so should do what you want.

Also there is a weekday router node available already. combine with the node to insert a timestamp (or my own moment node, freshly minted) should give you most if not everything.

[Julian Knight]

Time calculations nearly made it into my moment node but I thought better of it, keeping it simple.

I'd been thinking about the sunup/down calculation though. I agree that it would be very helpful to have something that could trigger 2 hours before sunrise/set for example. I don't think that is currently easy to do without coding.

If you are wanting to contribute, why not have a go by copying the sunrise node and having a go at extending it. Maybe to add an offset field that allows +/- x number of minutes, that is probably sufficient and should be fairly straight forwards. The original is here: https://github.com/node-red/node-red-nodes/tree/master/time

Maybe you could ask the author if he wanted to combine your changes into the node, if not you could publish a new one.

It turns out to be very straight-forward to create a new node - I know, I published my own first node this morning. :)

[Nicholas O'Leary]

We want to avoid a proliferation of nodes that are simply forks of one-another rather than try to work together to add the right functionality to the nodes that are already there.

If you think a node is missing some functionality, the starting point ought to be a discussion (like this) over whether that functionality really belongs in the node, then if there's general consensus, either an issue on the tracker for us to add it, or a pull-request with the functionality in (keeping in mind our contribution guidelines and prerequisites for raising a PR).

Sometimes it becomes apparent that the proposed functionality doesn't belong in the node. It could be because the functionality is actually best suited to being abstracted into its own node, allowing it to be reused by other nodes. It could be simply that the functionality is trying to address such a specific edge case, that the overhead of adding the functionality and ongoing maintenance cost of code doesn't fit.

Nick

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas W.]

Thank you for the feedback.

From my point of view it should be best placed in the in default 'inject / cron' node as a sub feature of 'reapeat -> at a specific time' with some

additional fields.

I will place it as an issue in git and hope that some other people find it there usefull too.

@Julian Knight: Thanks for the hint with the second output - i havent used it so far and will try it next.

regards

_andreas

[Nicholas O'Leary]

There was a recent discussion about extending the Inject node with more options here: https://groups.google.com/forum/#!msg/node-red/wnCubD2Kw8o/vlTQQZxxKv8J

The conclusion it came to was perhaps a dedicated scheduler node was needed that could offer more comprehensive scheduling options than the basic ones in the Inject node.

[Dave C-J]

You could perhaps also use a trigger for 22 hours from sunrise today... It would approximate to 2 hours before sunrise tomorrow ☺
(OK. Yes I know that will only work once the flow has been running for at least one sunrise... )

[Mark Hindess]

I did write some code in the google calendar input node (in node-red-web-nodes repository) to support triggering messages based on time offsets from the start (or end) of calendar events. If someone was intending to add support for offsets before/after sunrise/sunset then this code might prove a useful starting point.

(I thought of Dave C-J's trick too but didn't like the implications for those. for example, inside the Arctic circle.)

-Mark

On Fri, Jan 30, 2015 at 6:33 PM, Dave C-J <dce...@gmail.com> wrote:

You could perhaps also use a trigger for 22 hours from sunrise today... It would approximate to 2 hours before sunrise tomorrow ☺
(OK. Yes I know that will only work once the flow has been running for at least one sunrise... )

--

http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mark Hindess <mark.h...@googlemail.com>
IBM Java Technology Centre, UK.

[Dave C-J]

Mark, I'm out sure what the implication are ? Other than an extra alarm on the first day the sun never sets and a missing one when it's starts to set again...

[Emil Oberg]

About the proliferation of nodes:

There are a fair share of nodes which all have interval functionality, nodes such as suncalc, email, feed parse, ping, etc. From my (outsider) standpoint, I'd rather see a stronger separation of concerns where a separate node is responsible for trigging those nodes. To replicate today's functionality, that means wiring an inject node to e.g. the suncalc node (which would be extended with an input). But that also means that other nodes can be used to trigger it. 

That should most likely minimize unnecessary proliferation - and enable more exiting flows.

Emil

[Martin Jarvis]

I wrote a wrapper around the SunCalc module to fire timeout events at the appropriate times, then a custom node-red module to listen out for the events I was interested in. I use this along with my RFXCom node in a flow to switch on lights around the house at dusk. I haven't touched the code for about a year so I have not yet created installable npms for these modules, but you can pull them from my github project https://github.com/freakent/freakent-nodes if you are interested. 

Regards

Martin