Feature Request: Allow Greater Offset for Sun & More Exact Times

[alexyao2015]

There shouldn't be only a two hour limit for sunrise and sunset offsets. Potentially remove the limit all together or make it larger, say 12 hours in either direction?

Another suggestion: Increase the precision of the time to be at a minute level instead of being on tens.

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label enhancement to this issue, with a confidence of 0.93. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[nielsfaber]

There shouldn't be only a two hour limit for sunrise and sunset offsets.

Strong statement, so why not?

Increase the precision of the time to be at a minute level instead of being on tens.

There is no such limit, only a default setting. Did you check the docs?

[alexyao2015]

Strong statement, so why not?

It simply provides more customizability. It seems like there isn't a real reason for this besides just being an artificial limit imposed on the user.

There is no such limit, only a default setting.

Thanks for pointing out that the feature does exist! It would be nice to have that same setting take effect for the draggable markers.

[alexyao2015]

There might have to be some wizardry to do if the offset goes past the end of the day to get it into the next day, but 2 hours seems to be extremely short IMO.

[dj4ngo]

IIUC This is managed by "toggleMode" fonction from src/custom-elements/time-picker.ts.

This is dealing correctly with day changes, I just tested it with 12H as maxOffset.

[nielsfaber]

I'm not convinced at all that changing the offset range helps anyone. Defining a schedule to fire at 5 hours before sunset does not make any sense (it would be the middle of the day). The offset range is chosen with care, I don't see a need/use-case for extending it.

[alexyao2015]

There's really no harm to it. The worst thing that could happen is people just don't go all they way to 12 hours. But allowing for it gives maximum customizability.

[nielsfaber]

I am asking for an example / use-case in which higher offset would be practical, since I don't see any use for it.

Maximum customizability is not what this card is aiming at, I try to keep things minimalistic/simple. I don't want to facilitate creating non-sense rules, such as a timer at 5 hour before sunset.

Please extend your request (and quantify it), or it will be closed/ignored.

[alexyao2015]

Say I want to have something occur at approximately 10pm but adjusted for subset so it's a little bit different each day. I would use 5 hours after sunset but that isn't currently possible.

Sure, adding a randomization feature would be ideal for this but that does not exist currently. If a larger offset were allowed, this could be a workaround.

In many cases, you may not see a reason for something, but this is simply a feature that takes very little effort but has potential for larger gains.

[nielsfaber]

It would be nice to have that same setting take effect for the draggable markers

This is a work-in-progress. I am changing the layout a bit to allow 'finetuning'. The time step configured for the card will be used here as well.

As for:

at approximately 10pm but adjusted for subset so it's a little bit different each day

I don't like it. It seems more of a hack than extra functionality to me. I guess this is where our opinions don't match. Extending it may help you but may raise questions/confusions for others. Like you said, crossing the 00:00 time point is also undesirable, so the increase creates a new issue.

There is an open request for a randomization option. So far there is very little interest shown for this request, so it is low on my agenda as well I would prefer if you add your request / needs there. There are not that many open feature requests so I may pick it up soon.

I will close this request, as my answer to your original request is "won't fix". Hope you can respect it.

[emeyedeejay]

Where I live, the sunrises between 5am and 5:30am in summer. I want to turn my pool pump on a regular 5 hours after sunrise so that it will adjust daily.

Just because you can't see a use case for yourself personally doesn't mean there aren't any.

Awesome integration but the 2 hour limit doesn't make sense. Why not 3? Why not 1? Why not 4?

I came to post this as a bug but it seems to be by design which I cannot fathom.

Hopefully, this will be added one day and I can use this excellent tool instead of clunky automations.

[alexyao2015]

There are things you learn as you are more involved in public projects. Some people may not see how you may see things and that is fine. In this case, there is no true disadvantage in increasing the amount. People use HA for customization, not to be limited by arbitrary rules that were put in place by a developer who believes it "does not make any sense". HA has no limits for the user unless it is a technical limitation.

I've worked on many projects, and there are many things that I would rather not support or work with simply because I don't use them. But it's not something that I outright stop supporting without a technical reason behind it. There is no technical reason behind this other than you "not seeing a use case for it".

Regards

[emeyedeejay]

This is just so frustrating. It's such an awesome add-on etc. but I can't use it for what I want to with that pesky 2 hour limit.

Is there any chance you will re-consider this at all?

[nielsfaber]

Let's please stop discussing how stubborn and narrow-minded I am for creating the 2 hour offset limit and not increasing it on request. This doesn't do me justice and does not create any motivation.

My reasons against extending it (I may be repeating myself):

1. I did a small research at the time about sunrise/sunset times in the world. I saw that some regions (like New Zealand) have sunset at almost 22:00, where other places (canada) have sunrise as early as 03:00. I want to avoid crossing the 00:00 time point since it will give issues, so the 2:00 offset limit seemed a safe choice. (Yes I am aware that there are extreme cases where the sun doesn't come up etc, but I think this covers 99%+ of cases)

2. Sunrise and sunset transitions only last approx an hour from dark->light and vice versa. I believe this is referred to as dawn or twilight (I don't know exactly which is which). What I'm saying here: 2 hours after sunrise, the sun is completely up, so the defined time has nothing to do anymore with sunrise. This feature is really intended for turning on lamps when it gets dark or opening a cover when it gets light, not for adding some randomization to the time.

3. The available offset range seems be in-line with the range that other scheduling GUIs support.
   Apple Homekit, Alexa, Homey offer max. 60 minutes sun offset, philips hue offers 120 mins. etc. It doesn't seem that much of a restricted choice.

4. I want to help users in creating a schedule that makes sense. Since the card doesn't have much whistles and bells or any explanatory text, i tried to make things intuitive (by making some choices here and there, that could also form limitations yes). This is definitely one of such aspects. People might confuse a schedule at "06:00 before sunrise" with "at 06:00". This is also why originally the card didn't allow you to switch to sunrise mode when the current time was out of the offset range (e.g. 12:00).

I'm planning to add the sunrise/sunset option to the timeslot editor as well as soon as I find the time for this. There will be some similar limitations imposed here to ensure that the start time of a timeslot always occurs before the end time (positive length). Item 1. I just mentioned is really critical. I cannot allow people to program a time that could move passed the extends of the day. Currently I don't see a way to get rid of the current limit, other than keeping a list of min/max sunrise/sunset times for various regions and choose the limit based on this.

This is really not just me being stubborn. I just see more limitations than added value to this request. As @emeyedeejay says, if I would stretch the limit to 4 hours, it would be a matter of time before someone asks for a 5 hours limit, etc. My view on the matter hasn't really changed in the meantime.

[alexyao2015]

So far there is very little interest shown for this request, so it is low on my agenda as well

You did mention this earlier, so I believe that the comments may be in reference to this. There is interest in this other than me.

To your note, you bring up some good points about the sunrise issues. I would like to add that it is possible to remove the limitation entirely by using something like a timedelta that will function regardless if it passes the 00:00 mark. Making it hit 12 hours would effectively hit all marks without issues, but some logic would need to be added to subtract 1 day if the time delta is greater than 1.

There are ways around these barriers, but I suppose a randomization option is probably more suited to this.

[nielsfaber]

I would like to add that it is possible to remove the limitation entirely by using something like a timedelta that will function regardless if it passes the 00:00 mark. Making it hit 12 hours would effectively hit all marks without issues, but some logic would need to be added to subtract 1 day if the time delta is greater than 1.

Let's consider the theoretical case of someone living in Christchurch New Zealand who wants to have his curtains close 3 hours after sunrise, every wednesday night. Today sunrise is at 21:13 over there, so it would be at 00:13 on thursday morning.

How the scheduler-component works now, it would get stuck in an endless loop (which is detected, and throws an exception). This is the case because it would:

1. calculate the start of the next wednesday (so 06-01-2021 at 00:00).
2. check the sun.sun component at what time is sunrise and add the offset, gives 24:13 (factually 86413, because it's in seconds) 3 combine the two, gives 07-01-2021 at 00:13
3. find out that the event occurs on a thursday, and the cycle repeats.

In step 2 something could be changed to catch the overflow, and transform it into 00:13. But then the "three hours after sunrise on wednesday" becomes a "three hours after sunrise on thursday" (which is not what the user asked).

IMO the solution is not that trivial, at least not with the way I currently implemented the calculation of next trigger interval (time and day are treated separately). I'm not saying it's impossible, I just see some impact.

Regarding the randomization feature, I think I got requests from like 10 people now, mostly for fooling burglars (turn off lights at irregular times). I do see potential in this feature, but I haven't found the time to work on this or even investigate how much effort it would take. So far I'm advising to solve this by having the schedule trigger a script, which adds a bit of random delay before executing the action. It's not very pretty but should give the same result. There are also components for presence simulation and such, this kind of fancy stuff is definitely out-of-scope for this scheduler.

[alexyao2015]

Well I'm not saying this is the right way to do it, but I've implemented this through the following steps.

1. Use the same 1 and 2 mentioned above.
2. Get the time component and add it to the start of the Wednesday. (06-01-2021 at 00:13)
3. Check to see if this object is less than the sunset time. If it is not, then use this time. (I.e. if it's 06-01-2021 at 23:30, use this object as it's past sunrise).
4. If it's not, add a timedelta of 1 to it. This would give you 07-01-2021 at 00:13.

Sure it's not on the Wednesday that you set, but it makes logical sense to simply flow into the next day since its very close. The day would be the starting point for the calculation rather than the actual day it's executed on.

Perhaps this might need to be implemented regardless of if you decide to increase the 2 hour limit for those edge cases where 2 hours after sunrise would cause an issue in places like Christchurch New Zealand.

[emeyedeejay]

I really hope you don't think that I think that you are stubborn and narrow-minded ... I certainly don't and think that what you have produced and continue to produce is outsanding. My frustration is with the limitation and not you - just wanted to clear that up.

It's your baby and you get to decide what goes in and what does not and seeing all the many many posts over the last couple of weeks, it's obvious that this would be far down the list of priorities.