Support variables in offset before/after sun times

[qistoph]

As mentioned in pimatic/pimatic#901, this PR makes pimatic-sunrise support variables in the before/after rules.

Examples:
when $early-on minutes before sunset then turn living-light on

when time is $delay minutes after sunrise then turn bedroom-light off

I use this to have lights turn on before sunset, depending on the cloudiness.
Using pimatic-openweather to get the cloudiness. The percentage of clouds is used to set $early-on to that percentage of 60 minutes.
50% clouds => 30 minutes
75% clouds => 45 minutes

Variables
$max-early-on = 60 (unit: minutes)
$early-on = round($weather-home.clouds * $max-early-on / 100) (unit: minutes)

Rules
when $early-on minutes before sunset then turn living-light on

[alainlecluse]

This would be extremely useful. Why is this pull request still pending?

[qistoph]

I don't know... Maybe no one is reviewing PRs on this repo...

[alainlecluse]

@sweetpi Could you tell us the status of this repo?

[mwittig]

Sorry guys, I have missed this one. I'll take care of this soon.

EDIT: I have just quickly reviewed the code. It will take some time for me to review and cleanup the contributed code as more than necessary changes have been done.

EDIT2: I'll also need to do some tweak to ensure backwards compatibility. Thus we need to keep "its" with a number which is ugly, but I don't think it possible to fully resolve the conflict with pimatic-cron at this point.

[qistoph]

Thanks mwittig for taking a look at this PR.

Is there anything I could do to help speed up the process?
Which "more than necessary changes" do you mean? If I remember correctly this PR contains only necessary changes to support variables for sun times...

[mwittig]

See my "edit" comments included in my previous post. This needs further thought. One way of solving the ambiguity is to limit variable support to using the "at" keyword.

[kmulder53]

Is there any progress on this topic?

[mwittig]

No, there has not been progress so far. Having the revisited the matter I think the best approach is to implement a new predicate provider for "time is" which then can coexist with legacy predicate provider.