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

[Arjen de Korte]

>> > 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.
> the point was mainly to avoid confusion for users of multiple UPS vendors.

Ah, now I understand this point. I thought you meant trying to prevent
displaying the same message twice in one alarm report. Since we're dealing
with a potentially huge set of alarm messages, it will be difficult to
prevent this. It's not a real option to set bitmaps like for the status
messages in usbhid-ups, which are then parsed later. On the other hand, I
don't see a problem either of providing alarm messages for a couple of
common problems (replace battery, over temperature, shutdown imminent) in
usbhid-ups. This would still allow for subdriver specific messages though,
if the default message would not be convenient. I will commit my changes
to usbhid-ups over the next couple of days (I cleaned up the
upsdrv_updateinfo() and hid_ups_walk() functions in the process).

[...]

>> 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).
> in the light of this last point, the free format suits me fine.
> I would prefer the term "opaque" or "manufacturer specific" to "free
> format", though it's exactly the same thing. The only difference is
> that we explicitly mention that we refer to the manufacturer's own
> naming, not NUT's or any other one.

Good, an opaque string it is and preferably something that relates to the
manual of a given UPS/vendor. It may still be usefull to list the messages
reported somewhere, so that if there are none described in the manual,
people can the same messages that other authors came up with.

By the way, I couldn't find anything like that in the manuals of the
Evolution 650, although looking at the HIDpaths learned that it supports
quite a few reports that may provide useful alarm messages. Isn't this in
the supplied documentation? I'm a bit reluctant to force the UPS to spit
out these messages (connecting a worn out battery for instance, to see how
the bundled Windows software responds to that).

Best regards, Arjen