[Nut-upsdev] Usage of 'alarm_(init|set|commit)'

[Arjen de Korte]

> Hi Arjen,
>
> 2007/8/10, Arjen de Korte <nut+devel at de-korte.org>:
>> Replying to myself... :-)
>>
>> > I think the alarm_* functions are an excellent way to convey
>> informative
>> > messages about UPS status/problems to an operator (a human, if we
>> > disregard the trained monkeys some people may use). Therefor, I want
>> to
>> > propose that we use a free format here and not a list of predefined
>> status
>> > words for the following reasons:
>> >
>> > 1) Situations that need to be dealt with immediately (in a matter of
>> > seconds) are dealt with through 'ups.status'. This requires automatic
>> > parsing and therefor we are restricted here to a fixed set of status
>> > words.
>> >
>> > 2) Alarms typically can't be solved without intervention of an
>> operator
>> > and don't require *immediate* action. This means they don't need to be
>> > parsed automatically, hence we're not restricted by a fixed set of
>> status
>> > words.
>> >
>> > 3) We don't want to loose information by grouping similar, but not
>> > entirely identical situations under one alarm report. Instead, we want
>> to
>> > be as precise as possible, in order to help the operator resolve the
>> > problem.
>>
>> The above also formalises the existing implementation in the 'bcmxcp'
>> and
>> 'gamatronic' drivers. As can be seen there, both have a wide variety of
>> alarms, which supports the idea that we should keep this a free format
>> (there probably aren't that many common alarms between drivers anyway).
>>
>> Again, any thoughts?
>
> as always, I'm all for standardizing, and I'm sure that something can
> be done for the alarm names (at least, a first pass of naming
> consolidation should be done).

Question is *why* we need standardization? Assuming alarms only need to be
interpreted by a human, I don't see a reason.

> This would at least allow:
> - to avoid alarm duplication,

That would be inconvenient, but I'd rather see the same alarm mentioned
twice than not at all.

> - to help developers implementing alarm support,

I'd rather help the operator who has to fix the problem, by sticking as
close as possible to the operational manual of the UPS. See also the reply
from Kjell, I think that is the most convincing reason *not* to
standardize.

> - to have something like the cmdvartab (friendly alarm names) that can
> be used to display something less cryptic than the raw alarm name.

The problem still remains that this will need to be a *huge* list (to
support all different notifications). The bcmxcp driver alone uses over
200 different alarm messages. I'd rather keep this driver specific (free
format).

Best regards, Arjen