Thanks @Steve-Mcl and @dceejay ... just wondering why it couldn't be part of the default Inject node? I know there are cases where more advanced handling is needed, but I think having these for a simple Inject could be extremely useful. It would (of course) rely on the suncalc library. I could work on a PR for it if there is interest.
That always then leads to the inevitable request to add just one more of those features.
We have to strike a balance with the amount of functionality we pile into any one node. Whilst I'm not necessarily saying this applies here, if a node has too many features it becomes harder to use because there are so many options for a user to wade through.
This is why nodes like cronplus, schedex, suncalc, bigtimer have all cropped up. They all are variations on the same theme, each offering a slightly different opinion on how it should be done.
We know from those nodes that adding suncalc-like timings introduces a whole host of further inevitable options. I'd prefer purpose-built nodes for those cases rather than a half-hearted feature in the core set.
We have to strike a balance with the amount of functionality we pile into any one node. Whilst I'm not necessarily saying this applies here, if a node has too many features it becomes harder to use because there are so many options for a user to wade through.
I get it. I'm not sure in this case it would be too much though? Just to show you what I was thinking:
Additional "sun phase" option in dropdown
Options of: Lat, Lon, and Offset + dropdown list with sun event (sunrise, sunset, etc.)
Understand though if you'd rather keep it unconnected, I just feel there are a lot of simplistic cases where a user only wants an event to fire at a specific time.
@dceejay well, maybe it's my misunderstanding of the suncalc node then, but here was my confusion with it:
It forces the user to select both a "start" and "end". It's unclear how to use this as a trigger for a single, daily event (e.g., each "sunrise" or each "sunset").
The options are built so that the early (sunrise, etc.) events are in the start box, and the late (sunset, etc.) events are in the end box. What if a user wants exactly the opposite behavior... or they want it triggered from the beginning of sunset to the end of sunset?
There is only a single "offset" selection, except there are 2 choices (start/end). Does the offset apply to both? How could independent offsets be chosen?
There are no checkboxes for which weekday to use (not a big deal)
Hi -
It sends 1 when at the start time and 0 when you set end. so if you only want getting light look for the 1 - if getting dark just look for the 0. Likewise it's up to you to interpret whether 1 means active or inactive ie the opposite behaviour. A following change node can change the 1 to something more meaningful etc.
For beginning of sunset to end of sunset - indeed it wouldn't - but neither would a single inject node. In both cases you would need two nodes.
The offsets apply to each transition - you can move the 0/1 and 1/0 transition either before the real time or after. Would a simple inject node offer this... we now have to add lat, lon, offset ... getting more options by the minute...
No checkboxes... well we assume the sun rises everyday
@dxdc having been working on adding solar events to cron-plus over the course of a couple of months I can say - "adding the UI options" are easy however handling everything else under the hood is far from straight foward.
For example, "at specific sun phase" implies 1 event (like sunrise or sunset) - then before you know it there is a request for "at sunrise and sunset" then the user wants "at sunrise and sunset offset by 30 mins".
Then beyond that, you're asked to output things like isDay or isNight - sounds easy? Until your user enters coordinates with a low latitude (where there is no "day" period) or high latitude (where there is no "night" period. Do we scan backwards and forwards to determine state & next solar occurrence?
Then there is the issue of accuracy - most of the libs are approximations (and they all give slightly differing results across the whole gamut of astrological/nautical/civil/dawn/dusk) and some use different sun angles for golden hour, sunrise end etc. I know, i've tried about 7 of the more popular ones - verifying with suncalc.org, timeanddate.com and esrl.noaa.gov/gmd/grad/solcalc/
There is more more to this conundrum but I've said enough
This is the nightmare i am working through now. As it stands, I have worked though all of the above (plus more) & I am now (2 months in) nearly happy with it.
And as Nick and Dave have alluded to, there are many choices & soon - another (cron-plus) will have too (once I've worked out all the kinks)
And lastly, when cron-plus has one entry, you get inject like functionality...
Thanks, was thinking about this approach too. I guess it makes sense, but if I only want a trigger at sunset + 4 hours it seems a little confusing that there is also a trigger at sunrise + 4 hours.
but neither would a single inject node
You're right, but I find the single inject node more intuitive. I don't need so many triggers and it seems unintuitive to use an arbitrary value for start (like sunrise) if it's not being used. It also makes me wonder what exactly happens if a flow is re-deployed in the middle of the day. I think it can have a lot of unintended side effects from this kind of dual start/end behavior.
Meanwhile this node has just been released
I've looked at this node before, will give it another go
In cron-plus, i have to scan back through solar events until I determine if the users offset is a future event.
As i attempted to allude to above, there is a whole raft of considerations
I am not too far of finishing cron-plus updates - perhaps 1 week.
The benefits I see over other nodes are - the multiple schedules, true timezone support and 100% fully dynamic nature of the node (everything can be automated via msgs)
I'm quite familiar with some of these challenges. I've run into a number of problems with plugins with the logic of sunset + 4 hours where this amounts to the following day because sunset is after 8pm - and causes problems upon defining the next repeat interval.
As far as the accuracy, sure, it's confusing. I've read through a lot of that code myself for different reasons. A lot of it has to do with the choice of things like the radius of the earth (for which it seems there is no exact agreement??). We need a consensus between astronomers to gain some agreement on their own calculations And, what surprised me more is that reading through the NOAA code, which I had expected would be high quality, was anything but. There's also a lot of rounding for simplicity (e.g., round to the nearest minute) which can produce different results.
The definition of the angles is another issue, but I feel like that is a little easier to deal with since it's just a number at the end of the day - so it's a definitional disagreement as opposed to anything else.
And lastly, when cron-plus has one entry, you get inject like functionality...
I presume it's only injecting during the defined solar events? If so, keep me posted once cron-plus is updated, would love to test it.
Whereas for suncalc it is "easy" - the node has two outputs... one that only has the transitions when they occur - so if you've missed it, you have to wait for the next one... and one output that repeats the current state every minute - so if you restart in the middle of the night it will then turn the lights back on (or whatever)
If you manually inject, it fires but you can use the output status to determine if it's a manual injection and the solar state of "now" is provided along with the time of the next event(s)
The reason for this is so a user can request through a msg for twilight/isDay/isNight etc at any point in time for any location in the world - 100% dynamic without a 2nd output firing every minute for example.
When an actual solar event occurs, output only occurs for the selected solar events