RE: [hobbit] hobbit-alerts.cfg: behaviour of TIME and DURATION together

["SebA" <spa (at) syntec.co.uk>]

Bizarrely and somewhat contradictory to the behaviour below is the behaviour
of DURATION well inside of the times specified with the TIME rule.  Is
DURATION not reset when the colour of the alert changes???  That seems to be
the only explanation for what I'm seeing (though it is early days to be
certain).  Or, to put it another way, is DURATION the non-green DURATION,
rather than the duration of being in a certain colour?
 
The config I currently have is:
 
$pg-sebsms=me AT mysms2emailprovider.com TIME=W:0845:2355
 
HOST=DbR1 SERVICE=Special
     MAIL me AT work.co.uk COLOR=red DURATION>2 REPEAT=30 RECOVERED
     MAIL $pg-sebsms COLOR=red DURATION>15 REPEAT=300 RECOVERED
 
I was hoping (and expecting) the above rules to only alert after 2 minutes
and 15 minutes repectively of being red, given that COLOR=red is part of the
rule.  I do, however, acknowledge that there may be (rare) cases where you
would want to include the yellow time in the DURATION.  In which case, we
really need REDDURATION, YELLOWDURATION and PURPLEDURATION rules.  Or
perhaps just a way of specifying how you want the DURATION to be calculated
in that rule: DURATIONTYPE=<NONGREEN|LASTCHANGE> (that's either or).  Or
even more powerfully: DURATIONCALC=color[,color] (adds up the duration of
being in these colour states).  (However, this could become resource
intensive if you specify DURATIONCALC=red,yellow,purple,green or something!
On the other hand, one only needs to check back as far as DURATION, rather
than calculate the total time in these colour states.)
 
I am using Hobbit 4.3 (trunk) from Dec 9 2008.
 
Looking carefully at 'man hobbitd_alert' this appears to be most relevant
part:
'When a status first goes to one of the ALERTCOLORS, hobbitd_alert is
notified of this change. It notes that the status is now in an alert state,
and records the timestamp when this event started, and adds the alert to the
list statuses that may potentially trigger one or more alert messages.'
I do not, however, think that this timestamp should be what is used by the
DURATION rule (it being far too simplistic), but it looks like it may very
well be.  Maybe this explains the behaviour I have with Big Brother's rules
that I always considered a weird bug:  sometimes the 'initial page delay' is
not respected.  This actually happened twice today and I got SMSes
simultaneously from BB and Hobbit when they had 5 minute and 15 minute
initial page delays respectively, and I got the SMS immediately after the
red.  It had however been yellow for some time before, but on BB my
pagelevels is set to "red purple", so the yellow should have been ignored
and not come into the equation.  How frustrating!  One of the main reasons I
wanted to move to Hobbit was to eliminate this 'bug' in Big Brother!
 
Still awaiting a reply on my message below BTW.  Given my unfortunate
theory, above, on what is going here, I suspect the TIME rule is causing
this magic timestamp to never be recorded!  Somehow it appears to be taking
precedence over the DURATION rule when I wish the DURATION rule to take
precedence (and I think that is more logical: if I wanted to mark it as
downtime, I'd have put the TIME rule into bb-hosts not hobbit-alerts.cfg!).
;)
 
'man hobbitd_alert' could be clearer, e.g. on how rules interact with each
other!
 
Many thanks,
 
SebA



  _____  

From: SebA [mailto:spa (at) syntec.co.uk] 
Sent: 27 January 2009 14:35
To: hobbit (at) hswn.dk
Subject: [hobbit] hobbit-alerts.cfg: behaviour of TIME and DURATION together



It seems the combination of TIME=W:0845:2355 and DURATION>15 in
hobbit-alerts.cfg means the earliest an alert can be sent out is 9 am.  Is
this what you would expect?  I would have expected these two rules to mean
the test should be in an alarm colour for more than 15 minutes and be
between the times of 08:45 and 23:55, weekdays.  Instead it seems to be
relating the DURATION with the time such that the DURATION only applies
_during_ the TIME.

If the current behaviour is intended, than will using EXTIME instead of TIME
be what I want?  Oh!  There is no EXTIME?!  I assumed there was but I see no
documentation for it apart from Henrik's suggestion that he might add it:

 <http://www.hswn.dk/hobbiton/2006/06/msg00417.html>
http://www.hswn.dk/hobbiton/2006/06/msg00417.html 

Kind regards, 

SebA