Change Sunrise/Sunset calculation from actual to civil

[freedomlives]

For a year I've been using Tasmota to control the streetlights in our village. I've been bothered by the fact that the sunrise and sunset times available are the actual ones -- meaning, when the sun falls below or rises above the horizon. It remains light enough to see by for some time after and before these events, respectively. So I apply an offset on the timer, but the amount changes by season a bit, so not a nice solution. I was thinking to modify the code of Tasmota, till a few days ago, when for an ESP8285 device I needed to compile firmware with TLS support, and noticed that the sunset/sunrise type is a compile time option in my_user_config.h: SUNRISE_DAWN_ANGLE
Possible values are:

• DAWN_NORMAL (default) the moment the sun becomes visible/disappears at the horizon
• DAWN_CIVIL when it begins to be / stops being possible to work outside without artificial light
• DAWN_NAUTIC when it begins to be / stops being possible to navigate a ship at sea (by looking on the coastline?)
• DAWN_ASTRONOMICwhen it stops being / starts being possible to see all of the stars

I'd be willing to bet that most people using the sunrise / sunset times are trying to control lights, and civil sunrise/sunset is the time that is most relevant for them. And therefore this ought to be the default in the pre-compiled Tasmota binaries.

It would also be good to mention in the documentation for Tasmota that this a compile time option, just as the need to compile in support for TLS one ESP8266 is mentioned in the documentation. Perhaps someone is automating an astronomical observatory, and DAWN_ASTRONOMIC would be more useful for them.

[sfromis]

Anyone can propose edits to the docs, when "weak spots" are noticed. Edit link is the pencil near the top/right part of the text.

While I do understand the point of changing the default, it would be a breaking change with the risk of existing users getting "surprised".

[arendst]

We won't change the default for obvious reasons. I will investigate the SetOption option.

[s-hadinger]

I didn't know this option. This feels like it should be a SetOption rather than a compile time option. Thoughts?

[barbudor]

There is never enough setoptions

[s-hadinger]

The advantage of SetOption is that they are low touch low code impact, but create documentation complexity.

[sfromis]

With the SetOption synonyms, they act pretty much like other settings commands (people do in principle not even need to know that some setting is also available as a SetOption number), but without needing code to match each added string constant, still lower code impact than other commands.

[joba-1]

Given the original usecase I would invest in a light sensor and base switching lights on or off based on the sensor value.

Citizens need light based on darkness, not on time. If seasonal changes of dusk and dawn duration already matter, then a light sensor will be better, since on a day with heavy clouds it will be on the desired darkness level much earlier than on a bright full moon evening.
And you are already prepared for the next solar eclipse :)

[arendst]

Totally agree. That's how I manage my lights too. But will add the SetOption anyway :-)

[freedomlives]

Indeed, a light sensor is on the todo list, when I replace the Yeelight relay with a RobotDyn one.

[arendst]

In latest dev release introduced new command Sunrise 0..3 to select between Normal, Civil, Nautical or Astronomical dawns.

Another "useful" 200 bytes solution....

[freedomlives]

@arendst great! Thanks!

[barbudor]

@freedomlives could you please take care of updating the doc?
Thanks

[freedomlives]

Sure! I'll do that tonight (central European time)

[cybermaus]

So I see this is now a run option rather then compile time option. For years, this is one of the settings I change at compile time.
However, I change it to half of CVIL, so only 3 degrees

The use case is, I run these devices very far up north, and over there the difference between normal and civil can be very long. Hours even.
We found 3 degrees the best value, better then hardcoding an offset in the timer, and also better then using either straight CIVIL or straight NORMAL.

My current compile time mod

#undef  SUNRISE_DAWN_ANGLE 
#define SUNRISE_DAWN_ANGLE DAWN_CIVIL/2          // Half-Civil is better then fixed time in timer

Given that this is a brand new command option, would everyone and especially @freedomlives as you are likely the only current user of this, be OK if the values of Sunrise 0..3 be changed to actual degree values Sunrise 0..18
Where therefore, if you want to set regular CIVIL, instead of Sunrise 1 you'd do Sunrise 6. Only 0 would remain 0.8333 (which is the width of the radius of the sun for those interested)

In a compromise, in case we worry people are already using Sunrise 1 (civil, it is very unlikely people use the other ones) we could also have 1 remain the meaning of civil (6 degrees) because 1 degee is soo close to 0.8333 degrees, the 1 degree in itself would not have a lot of use.

reference:

// Sunrise and Sunset DawnType
#define DAWN_NORMAL            -0.8333
#define DAWN_CIVIL             -6.0
#define DAWN_NAUTIC            -12.0
#define DAWN_ASTRONOMIC        -18.0

[freedomlives]

@cybermaus I have no problem with this, having finer control seems like a good idea.

[DragonWork]

+1 this. Sunrise should be a value between 0 and 18 (degrees elevation under the horizon) instead of hard coded. Tagging @arendst as he implemented the option. Would be a breaking change. Maybe diffentiate between positive (0 to 3) and negative integers (-1 to -18) and assume the latter as degrees.

[cybermaus]

That seems like a reasonable method to make sure there are no braking changes. I still just hard code at compile time, so not a very urgent change to me, but it seems like there are at least 1 or 2 others who would like a finer control.

[sfromis]

There is no "should" about how to implement the feature, but of course angle selection instead of the common words for twilight zones would provide a bit of flexibility. The reasoning behind the implementation with 4 values to pick from is that the saved value for the Sunrise command is a 2-bit value, as the fixed space in the settings data structure is managed very carefully to be parsimonious about any "waste" of space.

It would be feasible, without any cost in space usage, to open up the constants to build-time configuration, allowing to override the values in the source code.
https://github.com/arendst/Tasmota/blob/development/tasmota/include/tasmota.h#L272-L276