Show normal, civil, nautic and atronomic when using sunset/sunrise

[zwim]

PROBLEM DESCRIPTION

Currently in the schedule you can select sunrise/sunset and depending on the sunset/sunrise setting normal, civil, nautic or atronomic times are used, which is totally correct.

See

As I have some devices using the normal sunset and others using the civil twilight it would be very nice (and make things a bit clearer) to show the type of sunset/sunrise in

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): Nous A1T, Gosund SP112
• Tasmota binary firmware version number used: 13.0.0
  • Pre-compiled
  • Self-compiled
• Flashing tools used: _____
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

  Console output here:

TO REPRODUCE

The information, which type of twilight is used is missing.

EXPECTED BEHAVIOUR

Show type of twilight in the schedule

SCREENSHOTS

Add normal, civil, nautic, atronomic to the schedule (of course not in red)

ADDITIONAL CONTEXT

[sfromis]

In the context of Tasmota, what do you mean by this:

As I have some devices using the normal sunset and others using the civil twilight

Tasmota sunset/sunrise calculation does not worry about twilight, but merely calculates the time of passing the geometric horizon. Sunrise is always the time of sunrise, any twilight is before that, and is outside of what the Tasmota Timers schedule supports.

You can to some extent adjust for twilight by selecting a +/- offset, but that way cannot adjust for the very varying length of twilight when getting far from the equator.

To make sure to config Tasmota devices for your lat/lon, I can recommend using https://tasmota-tz.netlify.app/

[Wintespe]

@sfromis

Tasmota sunset/sunrise calculation does not worry about twilight, but merely calculates the time of passing the geometric horizon. Sunrise is always the time of sunrise, any twilight is before that, and is outside of what the Tasmota Timers schedule supports

From the Tasmota documentation

Sunrise	0 = normal, the moment the sun becomes visible/disappears at the horizon (default) 1 = civil, when it begins to be and stops being possible to work outside without artificial light 2 = nautic, when it begins to be and stops being possible to navigate a ship at sea 3 = astronomic, when it stops being / starts being possible to see all of the stars

.

Could you please give some info about the Sunrise documentation, thx

[sfromis]

Ok, I did not remember the dawn angle and the relatively new Sunrise command to select. 16795

In general, only a small part of available Tasmota features are even visible in the web UI, with the large majority only "visible" as commands, including when the Sunrise command was added. The general idea is that with ESP8266 devices, available space is quite limited, leading to lots of "nice to have" things not being added to the deliberately rudimentary web UI. Would also need i18n translations across languages. While I could see the point of having this detail visible, the logical thing would be to also allow updates, and then more bytes are consumed......

Not sure what you ask about with "some info about the Sunrise documentation"?

[zwim]

Thanks to @Wintespe and @sfromis
I completely understand the rationale for not adding every nice to have feature (because of space).
But on the other hand the (rudimentary) UI should not suffer and be ambiguous (or even worse: show wrong strings)!

• If it is called sunset or sunrise, then the consensus in the community is, that the upper edge of the sun crosses the horizon. (And not something like the end/start of civil twilight 6° down or similar!)
• If I read sunset or sunrise, then it should be what it is called. Start/End of civil twilight is not sunrise nor sunset!

I am completely familiar with the calculations for different types of twilight and so on (see: https://github.com/zwim/suntime, which is used in KOReader).

So I would ask for either rename the "Sunset" and "Sunrise" menu entries to something generic like "End/start of the calculated day according to user settings like normal, civil, nautical or astronomical" (preferable shorter) or do a minimalistic switch case statement
and adding a hint for the user to show
Sun set/End of civil dusk/End of nautical dusk/End of astronomical dusk or
Sun set/End of civil twilight/End of nautical twilight/End of astronomical twilight

and

Sun rise/Sart of civil dusk/Start of nautical dusk/Start of astronomical dusk or
Sun rise/Start of civil twilight/Start of nautical tiwlight/Start of astronomical twilight

Cheers,

[zwim]

Could you please give some info about the Sunrise documentation, thx

@sfromis You can find a very detailed and precise implementation in LUA (incl. citations of relevant papers) in https://github.com/zwim/suntime. For the next few centuries the errors in this implementation are within 90s in mean geographic latitudes (near the poles ((Iceland)) everything gets a bit complicated).

I don't know how much Tasmota follows the scientific consensus, but I can give a leap of faith (as the times I have seen in my Tasmota devices) is not bad (in fact they are quite accurate).

[sfromis]

Sure, I know about how it works, and my home technically has no "night" in the summer, only astronomical twilight. I was not the one asking for any documentation, that was Winterspe.
You can find the calculations Tasmota uses in the driver if you are interested in details:
https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_09_timers.ino

In general, Tasmota is an open source project, with many different people submitting pull requests which are reviewed for merge. If you want to change words in the web UI, long sentences do not work well, but maybe just dusk/dawn.

[Wintespe]

Thanks for the detailed information and links. I will study the documentation

[barbudor]

What about a dropbox matching the Sunrise command:

Values from the dropbox would the one from the doc : Normal, Civil, Nautic, Astronomic

[sfromis]

Normal language usage would be "Nautical/Astronomical" instead of "Nautic/Astronomic", but I can't say that I'm much in favor of adding just one of the settings (excluding Latitude/Longitude) relevant to how the season-related timing variations are controlled. Of course, if the web UI was aimed at being broadly useful without needing to use commands for most things, it would be another matter. Not strongly against, either, but.....

Maybe use words Dusk/Dawn instead of Sunset/Sunrise to avoid the implication of sun-crossing-horizon. And saving 5 bytes 😉

[barbudor]

As usually, if someone wants to make a PR, it will be up to Theo to accept it or not

I find it usefull to be able to configure timers by UI
But that kind of setting which you probably won't change more than twice in the lifetime of the device ....
And the default lat/lon in my case are hardcoded in my self built binaries....

[sfromis]

Yeah, and SUNRISE_DAWN_ANGLE there also, if you want to deviate from "Normal".

[zwim]

Maybe use words Dusk/Dawn instead of Sunset/Sunrise to avoid the implication of sun-crossing-horizon. And saving 5 bytes 😉

Better than misleading sunset/sunrise 💯

[pkkrusty]

Dusk/dawn to replace sunrise/sunset seems the most reasonable suggestion that mostly satisfies the requirements of each community: accuracy, code space, simplicity.

I agree with Barbudor that if you already know about and care about the different definitions of twilight, then you know what you are doing with your devices. But I can see where it's technically not correct to use Sunrise/Sunset in that case.

[Wintespe]

How about setting the Sunrise/Sunset text boxes with a command similar the WebButton command?
This would allow the user to set the state of the selection. It also solve the problem of different languages.

[arendst]

Working on a lowest cost solution:

[arendst]

Try latest dev branch.

[zwim]

@arendst I will test as soon as I am back at home (and have time). Thanks a lot. The screenshot looks exactly what I was asking for.

[Wintespe]

@arendst This looks very good. Please adjust the text as follows;

Sonnenaufgang astronomisch -> Astronomischer Sonnenaufgang
Sonnenuntergang astronomisch -> Astronomischer Sonnenuntergang

[sfromis]

As the strings for sunset/sunrise are separate from the strings for what type of twilight, the i18n support of Tasmota does not facilitate different word order by language. Still, I'd expect "most languages" to benefit from having a comma, like:
"Sunrise Civil" -> "Sunrise, Civil"
I'd expect this to make "grammar nerd" sense

OTOH, swapping word order might make sense across "all" languages? Except for when only first word should be capitalized.

Yeah, i18n is quite a can of worms to dive into 😉

[zwim]

@arendst Thanks! Works.

@Wintespe I don't mind if it is "Sonnenaufgang astronomisch" or "Astronomischer Sonnenaufgang".

[Wintespe]

Please think about these two sentences

I play with a ball red .
versus
I play with a red ball .

[sfromis]

That example so different that it does not even apply here.

From my knowledge of German, "Sonnenaufgang, astronomisch" would be a reasonable grammar.

[arendst]

Let's decide on the comma then. Will change if I find the time (and solve alignment for the extra character used for calculating text field center).

[barbudor]

Not speaking German at all, would parenthesis acceptable?
Sonnenaufgang (astronomisch)

[arendst]

No because the screen would then look like Sonnenaufgang (astronomisch) (06:20). Too many parenthesis.

[barbudor]

Good point 👍

[Wintespe]

A comma is OK.

Just a suggestion:

This is how I solved this kind of problem in my projects:
In the different language files you will find e.g.

joue avec le ballon [1]

I am playing with a [1] ball

Ich spiele mit einem [1] Ball

I call a function that takes the string abobe and a parameter. The parameter can be taken from the language file using a key or is a variable. This function then replaces the placeholder [1] with the parameter if it is found, otherwise it is / can removed. In the real world the number of parameters is variable and there are multiple placeholders.

Maybe this idea is useful for Tasmota.

[sfromis]

That strategy works reasonably well when you do not have to worry about space used. OTOH, Tasmota pushing a lot of features into the tiny ESP8266 has a strong focus on reducing number of bytes used. Hence, i18n elements tend to be short and minimizing repetition.

By repetition I do not only mean of the string words themselves, but the cost of having a function call for string references. That would cost extra bytes each time, and result in longer compiled code. Static string bits which can be resolved during build tend to result in more compact code.

[Wintespe]

@sfromis
I know the "small" flash size of the ESP8266.
The strings are static in an external header file like Tasmota does. You have to extend your files - if needed - with a placeholder. Only the extension is dynamic at runtime. It costs a function to resolve the string. Of course, dynamically - in the stack - it costs some RAM (the size of a string). Only in the case of a placeholder - well known by the designer of the code - you have to call the expansion function. The rest of the code is unaffected.

[stefanbode]

@Wintespe : Please be kind that "wasting" memory just to make it more nice on a webui is not an option. ESP8266 is very limited and if we allow it in german we have to consider other languages, too. I am german and the "," approach is great. All information needed is shown

[arendst]

Final suggested change just made to dev branch. End of discussion ;-)