Relative at command yields wrong absolute time
Dr. Boris Neubert
I have been a proud owner of automatic shutters for just one week now.
Enough time to get even more out of fhem.
I want the shutters on the first floor to open at sunset plus half an
hour, but not before my regular waking time at 06:10. The respective
command is in the commandref. It worked well on the first and second day
but since then shutters open before 06:10. And here is why:
list at.sunrise.2
Internals:
DEF +*{max(abstime2rel("06:10"),sunrise_rel(1800))} set
2.sz.roll,2.kiz.roll,2.bad.roll,2.og.roll on
NAME at.sunrise.2
NR 117
NTM 05:59:06
REP -1
STATE Next: 05:59:06
TRIGGERTIME 1243569546.3687
TYPE at
Attributes:
==> Next is 05:59.
At 21:05 I tried { abstime2rel("06:10") } which yields 09:04:51, correct.
What's the best way to debug this?
Regards,
Boris
Rudolf Koenig
06:10 is 00:00, to the next sunrise is 23:something, max() takes the
next sunrise. The same happens if sunrise is before 06:10. Better is
to use absolute times: max("06:10", sunrise_abs(1800)) and forget the
+ in the at definition.
But there is a generic problem with repetitive sunrise dependent at
commands: All absolute sunrise/sunset commands will be executed twice
each day, relative commands are just a little bit better: sunrise_rel
is executed twice in the spring, and sunset_rel twice in the fall.
Proposal: The at command should set a global flag when computing the
repetition (not the first event), and the sunrise/sunset is computed
for the following day if this flag is set (and not just the next
event, which can be on the same day), and add 24:00:00 to the returned
time. Ugly: The problem above can only be solved by integrating a min/
max in sunrise.
As this is a quite ugly hack, I'd like to hear some better ideas.
Dr. Boris Neubert
> As this is a quite ugly hack, I'd like to hear some better ideas.
what about repeatedly dynamically generating single sunrise/sunset at
command at midnight?
define at.generator at *00:01 define at.sunset at max("06:10",
sunrise_abs(1800)) set 1.sz.roll on
BTW, is the at definition a perl command? Would max(if($we) { "07:30" ;;
} else { "06:10" ;; }) work as a time spec?
Boris
Rudolf Koenig
your command as:
define at.sunrise.2 at *{sunrise(1800, "6:10"))} set 2.*roll on
> BTW, is the at definition a perl command?
perl expression, your example is probably still wrong. The timespec
calculates the _next_ event,
so it will be 7:30 for sunday and monday.
Boris Neubert
> > As this is a quite ugly hack, I'd like to hear some better ideas.
>
> Ugly hack implemented, documented and checked in. You shall define
> your command as:
>
> define at.sunrise.2 at *{sunrise(1800, "6:10"))} set 2.*roll on
define at.sunrise.1 at *{ sunrise(1800, "05:30") } set blabla on
gives me
Wrong timespec {: either HH:MM:SS or {perlcode}
because
{ sunrise(1800, "05:30") }
yields
29:30:00
> perl expression, your example is probably still wrong. The timespec
> calculates the _next_ event,
Oops, and I did not even mention that the windows should open later not only
on weekends but also on holidays. As far as I see the holiday get function
must be extended to check whether _tomorrow_ is a holiday. This becomes quite
complex.
The problem seems to be in the head of the user (me). The at command does what
the at command does on unix systems: execute a command at a specified time in
the future (and optionally reschedule another at command at the time of
execution). What the user expects is functionality like cron: execute a
command on a given time schedule (open shutters not before 07:30 on weekends
and holidays). I have to think about it before I can come up with a intuitive
solution.
Regards,
Boris
Boris Neubert
> define at.sunrise.1 at *{ sunrise(1800, "05:30") } set blabla on
>
> gives me
>
> Wrong timespec {: either HH:MM:SS or {perlcode}
Postscriptum: the problem is not the timespec but the parsing of the timespec
in fhem.pl, sub GetTimSpec($), line 1765.
The pattern ^{(.*)}$ seems to match the timespec only up to the first blank.
If I omit the blank after the comma between the parameters of the subrise
function, the define works.
Boris
Maz
> The problem seems to be in the head of the user (me). The at command does what
> the at command does on unix systems: execute a command at a specified time in
> the future (and optionally reschedule another at command at the time of
> execution).
1. Define an at-command that executes at 1:00 O'Clock of every night.
Within this at-Command check for subsequent events that need to be
scheduled for the day and schedule them.
This will lead into a fairly big at-bloc.
So maybe you will write your own module and just call the method out
of the at command?
2. To solve your problem (after sunrise but not before 7:30):
Define an at-Commenad at 7:30 and check if sunrise will still happen
or already happened and either switch on the devices directly or set
an onetime at command for the time of sunrise.
What do you think?
greetings
Maz
Boris Neubert
thank you for your suggestions!
Am Sonntag, 31. Mai 2009 schrieb Maz:
> 1. Define an at-command that executes at 1:00 O'Clock of every night.
> Within this at-Command check for subsequent events that need to be
> scheduled for the day and schedule them.
> This will lead into a fairly big at-bloc.
> So maybe you will write your own module and just call the method out
> of the at command?
That sounds similar to my idea in the post from 2009-05-30 09:37 (repeatedly
dynamically generating single sunrise/sunset at command at midnight)
> 2. To solve your problem (after sunrise but not before 7:30):
> Define an at-Commenad at 7:30 and check if sunrise will still happen
> or already happened and either switch on the devices directly or set
> an onetime at command for the time of sunrise.
I am still wondering whether I will change my configuration according to the
above suggestions or implement a cron-like command into fhem. The latter
needs quite some thinking about.
define sunriseaction cronjob day timespec command
day= a function that evaluates to false or true depending on whether the
command is to be executed today or not
timespec= when should the command be executed
example:
define openshutters_workday cronjob { !$we || $holiday } {
sunset(1800,"07:30") } set 2.sz.roll on
Regards,
Boris
Rudolf Koenig
> sunset(1800,"07:30") } set 2.sz.roll on
one for the working days?
define he holiday
attr global holiday2we he
define rollon_wd at *{sunrise(1800,"06:10")} { fhem("set 2 sz.*roll
on") if(!$we) }
define rollon_we at *{sunrise(1800,"07:30")} { fhem("set 2 sz.*roll
on") if($we) }
This is how I do it since 2 years now (well, up till now without
holidays and for fixed times).
Dr. Boris Neubert
>> define openshutters_workday cronjob { !$we || $holiday } {
>> sunset(1800,"07:30") } set 2.sz.roll on
>
> Why don't you just define two at jobs, one for weekend/holiday, and
> one for the working days?
I slept the night over it and I came to the conclusion that it would be
best to resort to what is already available. I will follow your suggestion.
I just saw that you already implemented an extension of the notion of
$we depending on whether the global attribute holiday2we is set or not.
I missed that completely.
So the new sunset command combined with the perl special $we will do it!
Thank you very much.
Best regards,
Boris