[Nut-upsuser] mge-shut and hardware error on MGE Pulsar Evolution 800

[Arjen de Korte]

> On Mon, Sep 10, 2007 at 09:12:36PM +0200, Arjen de Korte wrote:
>>
>> > My MGE Pulsar Evolution 800 had some hardware troubles (it may be the
>> > batteries according to the manual). The fault was not detected so the
>> > power was cut to the load and nothing appears in the log files.
>>
>> Please be as specific as possible to describing what kind of problem you
>> had. Which driver (and interface) are you using and which NUT version
>> are
>> we talking about.
>
> I am on Debian unstable and have official  Nut 2.2.0 package installed.

That's useful information.

> I use the mge-shut driver (serial as that is what the s in shut means).
> This is historical on my part as I was the original author of the driver
> when it was still called mge-ellipse.

In that case, you might want to try the newmge-shut driver. Especially if
you use the version from the trunk, you'll find that it supports far more
UPS variables. Since it shares much of the code of the usbhid-ups driver
(except for the low level communications stuff) this will probably replace
the existing mge-shut driver somewhere in the future.

> When I got home after work, my computer was off and my UPS was beeping
> with the fault led blinking.

When was the last time you ran a battery test?

> I tried to reset the UPS by powering it off and disconnecting it from
> the wall but when I switched it back on and powered up the display it
> would start beeping again and the fault led started to blink again.

Could you still communicate with it?

> That seems likely to be a hardware problem. As the UPS is already 4
> years old batteries are a likely candidate (and seems to be what the
> beeping and led blinking means according to the manual).

Batteries are by far the most vulnerable part of a UPS. Some faults will
only show up under load and if you never run battery tests, they may only
surface when the power goes out. So chances are that the UPS itself would
not have noticed something was wrong, before it really became a problem.
In order to prevent this, running a (weekly/monthly) battery test, even if
it is just for a couple of seconds, is absolutely needed. A decent UPS
will notice that the batteries are bad, abort the test and raise an alarm
without interrupting power.

[...]

>> Note that the only *automatic* shutdown NUT supports, is for a low
>> battery
>> situation, since that might not need user intervention to clear. Chances
>> are that there are ways to detect the problem you're having (depending
>> on
>> what driver you're using), but I doubt that this will result in NUT
>> initiating a shutdown. It might throw an alarm, but this usually means
>> that it still requires user intervention to deal with/correct the
>> situation.
> Yes I understand only LB condition initiates the shutdown sequence. I
> don't know if the protocol contains any provision to inform the computer
> a hardware problem has occured, that was the meaning of my question
> because if it is available some support for it would be great.

The HID Power Devices specification provides many ways to inform about
(potential) problems. The nice thing about the newmge-shut driver is that
if you run it in debug mode, it will show all the variables the UPS
supports. You can then lookup the meaning in this specification and see if
that's what you need.

> I would have liked to fine something in my log files. I know the
> problem occured between 14:15 and 14:29 but not much :(

I guess it was a power outage and the battery failed the moment it really
had to provide power. Regarding the age of the battery, this is quite a
likely failure mode.

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