[P043] Add support for %sunrise% and %sunset% based time-values

[tonhuisman]

Resolves #4901
Resolves this forum request

Features:

• Add support for time configurations using %sunrise% and %sunset% instead of explicit HH:MM format, including the possible offsets like +1h, -20m and +13200s (220 minutes...)
• For non-LIMIT_BUILD_SIZE builds a list of a separate Day selector (All, Sun,Mon-Fri,Sat, Wrk = Workday, Wkd = Weekend) and predefined Time configurations with 00:00, %sunrise% and %sunset% that can be selected and then edited
• The number of Day,Time settings can be selected between 1 and 16 (default 8)
• Change layout, showing Value X input on same line as Day,Time X input, like the On/Off combobox
• Add support for the config command: config,task,<taskName>,SetTime,<timeIndex>,<timeString>[,<value>]
  • <timeIndex> is in range 1..Nr. of Day,Time fields
  • <timeString> can be quoted like "All,12:34" or unquoted
  • <value> is optional, won't be updated if not provided
• Add support for getting the configured time strings and values via [<taskName>#GetTimeX] and [<taskName>#GetValueX] where X is the Day,Time line in the configuration, limited by the configured 'Nr. of Day,Time fields' setting.
• (Temporarily) disabled a few build envs for size reasons, as they have been disabled or changed in another pending PR [ESP_IDF 5.1] Add support for ESP_IDF 5.1 (ESP32 Arduino SDK 3.x) #4841

TODO:

• Add documentation
• Tested locally
• Testing by requester (confirmed)
• Testing config command and get values by @chromoxdor (Forum requester)

[chromoxdor]

Ok.. i´ll add this here again also to clarify what i mean:
It would be nice, if people with a port extender have for consistency the same "old"-layout since they can not choose a gpio from the list.
There is still a need for adding a rule but also adding an extra trigger and choosing a number instead of just an "on" or "off" add complexity and can easier lead to incorrect entries...

[tonhuisman]

There is still a need for adding a rule but also adding an extra trigger and choosing a number instead of just an "on" or "off" add complexity and can easier lead to incorrect entries...

I don't yet see what you are trying to say here; the 'old functionality' is still in place, I only moved the Value input to the same line in the UI as the Day,Time input to make it more clear where it is related to, similar to the ""/No/Yes combobox, IMHO making the UI more consistent. 🤔
The rest of the 'How to use this' will be handled in the documentation I'll be writing to complete this PR 😉 (I almost wrote a comment in the other thread on how to use a rule to handle a single MCPGPIO pin..., until I re-read how you intend to switch all/many relays at the same event 😃)

[chromoxdor]

the 'old functionality' is still in place

but not when you have no gpio selected...and right now no gpio of a port extender is selectable (would also be difficult to implement i guess) so either i sacrifice an internal gpio or i have to live with the "new" layout

Edit: and yes the "new" layout looks consistent but does not behave the same which can lead to:

also adding an extra trigger and choosing a number instead of just an "on" or "off" add complexity and can easier lead to incorrect entries...

[chromoxdor]

But don´t get me wrong. I am totally happy with your changes and really appreciate your work! I don´t mind if you don´t want to add this. Sacrificing an GPIO is most of the time an option to get the ON/OFF behavior.
Maybe I should say that in my former life i was a occupational therapist with specialization in electronic helping aids. Thats why i maybe sometimes a bit picky. 🙂

[tonhuisman]

but not when you have no gpio selected

The only thing I changed in this area is the UI, not the behavior.

Entering wrong values has been possible for a long time, that wasn't 'introduced' by me 😅

I assume the author of this code intended to use message numbers or such, as these can be transferred via a Controller, when the Number Output Values is (at least) set to Dual (Triple and Quad don't matter, as the 3rd and 4th value are never set). So for backward compatibility, we'll have to keep the regular Value inputs.

---

to get the ON/OFF behavior.

💡 That's the missing remark, I didn't, until now, understand you wanted the On/Off behavior only, without a GPIO to switch On or Off, duh 🤦
I'll think of how to implement that, either (probably) by a checkbox or some other way. But not today anymore 😴

[chromoxdor]

💡 That's the missing remark, I didn't, until now, understand you wanted the On/Off behavior only, without a GPIO to switch On or Off, duh 🥇

I am also specialized in describing problems and making explanations in a way that nobody understands. 🤪
Good night...

[TD-er]

Do you mean you also want to be able to specify what GPIO you like to switch? Not limited to onboard GPIOs?

[chromoxdor]

Do you mean you also want to be able to specify what GPIO you like to switch? Not limited to onboard GPIOs?

I personally don’t need this option and i don’t see how it would be accomplished other than adding a extra textfield where you enter a command like mcpgpio,1,x

[tonhuisman]

I am also specialized in describing problems and making explanations in a way that nobody understands. 🤪

You're not unique in that, I know someone... 😛

So this would be more like what you tried to explain:

[chromoxdor]

short feedback about set and get then i have to leave:

1. The behavior seem to have changed when an event is happening? Didn´t the output state in "on/off" mode behave the same as when a gpio was selected? (value 1 is either set to 0 or 1)
   Now value 2 is set to 1 or 0 when in "on/off" and no gpio is selected (like it does in the "value" mode)

2. Getting the time should contain the value in my opinion

3. Thanks a lot :)

[chromoxdor]

Getting the time should contain the value in my opinion

Ahh i see.. GetValueX does the trick

[chromoxdor]

Command unknown: All,21:57
could be something like
<taskname>X: All,21:57

[tonhuisman]

Command unknown: All,21:57 could be something like <taskname>X: All,21:57

Nope, only the actual data is made available in the [<taskName>#GetTimeX] get config value 'command', any surrounding texts should be added by the user. 😺

[tonhuisman]

1. The behavior seem to have changed when an event is happening? Didn´t the output state in "on/off" mode behave the same as when a gpio was selected? (value 1 is either set to 0 or 1)
   Now value 2 is set to 1 or 0 when in "on/off" and no gpio is selected (like it does in the "value" mode)

That should be fixed now, a previous build had that, but it should have been 0/1 when in 'simple' mode.

[chromoxdor]

That should be fixed now, a previous build had that, but it should have been 0/1 when in 'simple' mode.

Nope... just tried again and in 'simple' mode (and no gpio is selected) still only value 2 changes and value 1 shows the timeslot...

can be quoted like "All,12:34" or unquoted

And here only quoted works for me...

[chromoxdor]

And here only quoted works for me...

This has been solved by a factory reset

[chromoxdor]

Found the issue:

for consistency, it should be:

[chromoxdor]

for consistency, it should be:

Btw: if you wonder why i didn´t directly made a PR instead of sending a picture of the changes... I simply don't know how to contribute to a already existing PR... 🤷‍♂️

[TD-er]

for consistency, it should be:

Btw: if you wonder why i didn´t directly made a PR instead of sending a picture of the changes... I simply don't know how to contribute to a already existing PR... 🤷‍♂️

Not sure if you can (due to permissions), but in principle you could checkout the branch of this PR.
This then needs to have its remote origin set to Ton's fork.
So the remote branch is then : tonhuisman:feature/P043-support-sunrise-and-sunset-in-settings

If you then make a commit to it and push it, you will probably end up with an error due to permissions.
I can do it (unless the user explicitly prohibits this) as I'm the owner of the original project which Ton has forked.
But to be honest this is something which has the potential to cause issues so I rarely use it and for sure not on PRs of inexperienced Git users.

So the correct way would be for you to create a new branch on top of the last commit of Ton's branch of this PR.
Then make a commit and push it.
Then try to make a pull request for it, but make sure not to make a pull request to the letscontrolit repo, but to Ton's fork.

[tonhuisman]

I'll fix it, later today 😊

[chromoxdor]

@TD-er as always, thank you very much for your extensive explanation!
@tonhuisman thank you for doing it!