Nut upsdev - Aug 2007 - Usage of 'alarm_(init|set|commit)'

As can be seen in the trunk, I'm working on the alarm functions in NUT.
Only two drivers actively use these at the moment and I intend to add a
third one to that (usbhid-ups, in an effort to clean up the mess we
created there with undocumented status flags).

At the moment, docs/new-drivers.txt says about the alarm functions the
following:

	"There is no official list of alarm words as of this writing, so
	 don't use these functions until you check with the upsdev list."

So there we go... :-)

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.

Any thoughts?

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57

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?

Best regards, Arjen