Nut upsuser - Dec 2018 - MGE EllipseMAX 1500 shuts down after a few hours

> If there is no message to NUT, I would consider opening a trouble 
> ticket with Eaton. It is possible that there is a known issue and/or 
> a firmware upgrade.
What kind of message to NUT? In the log (syslog) there is no other 
message registered. In nut.log only this appears:
> Dec  1 08:10:54 openmediavault upsd[5284]: Data for UPS [ellipsemax] 
> is stale - check driver
> Dec  1 08:10:56 openmediavault upsmon[5313]: Poll UPS 
> [ellipsemax at localhost] failed - Data stale
> Dec  1 08:10:56 openmediavault upsmon[5313]: Communications with UPS 
> ellipsemax at localhost lost
> Dec  1 08:10:56 openmediavault upssched[10965]: Executing command: 
> notify
> Dec  1 08:10:56 openmediavault upssched-cmd: Communications with the 
> UPS ellipsemax at localhost are lost
> Dec  1 08:10:58 openmediavault upsd[5284]: UPS [ellipsemax] data is 
> no longer stale
> Dec  1 08:11:01 openmediavault upsmon[5313]: Communications with UPS 
> ellipsemax at localhost established
> Dec  1 08:11:01 openmediavault upssched[10998]: Executing command: 
> notify
> Dec  1 08:11:01 openmediavault upssched-cmd: Communications with the 
> UPS ellipsemax at localhost are established
> Dec  1 13:02:51 openmediavault upsd[2185]: fopen 
> /var/run/nut/upsd.pid: No such file or directory
> Dec  1 13:02:51 openmediavault upsd[2185]: listening on 0.0.0.0 port 
> 3493
[...]


Note the time lapse from 08:11 to 13:02. The UPS shutdown at 08:11. 
These shutdowns only happen when the UPS has the USB cable connected 
and being monitored. I have not tested with the serial port. At least 
the times I have checked, the UPS shuts down after those messages 
appear.

The UPS is EOL (is quite old), so there is no support from them. This 
UPS was working but something has been changed in NUT that now the 
device turns off.
I have increased pollfreq value in the driver to 45 seconds. In 
upsmon.conf POLLFREQ is set to 10 seconds, POLLFREQALERT 10 seconds, 
HOSTSYNC 15, DEADTIME 30. MAXAGE is 60 seconds. This has turned into an 
earlier shutdown. Instead of around 6 hours it cut the power in 45 
minutes. Previous values were POLLFREQ 5, POLLFREQALERT 5, HOSTSYNC 15, 
DEADTIME 15 and MAXAGE 15.
> Also, given that the load is only 12%, double-check that the UPS is 
> not configured for any power saving features that might cause the 
> shutdown ("ECO mode" or similar). NUT does not get a notification
for
> that event the way that it gets a normal LB shutdown notification.
Are you referring to NUT (ups.conf) or to the UPS itself? I have 
checked the instruction manual and it says nothing about ECO modes. It 
talks only about disabling alarms or changing sensitivity to source 
voltage variations.

Thanks.


En ds., 1 de de des. 2018 a les 11:48 P. M., Charles Lepple 
<clepple at gmail.com> ha escrit:
> On Dec 1, 2018, at 3:45 PM, raul <raulvior.bcn at gmail.com> wrote:
>> 
>>  The UPS is connected to the following environment:
>>  OS: Debian GNU/Linux 9.6 (stretch)
>>  NUT version: 2.7.4-5
>>  Device output from lsusb: 0463:ffff MGE UPS Systems UPS
>>  Model name: MGE EllipseMAX 1500
>>  URLs:
>>  
>>
http://powerquality.eaton.com/Products-services/Backup-Power-UPS/Ellipse-MAX-eol.aspx?cx=97&GUID=7BB6CD53-9F6D-4D62-B326-1099F137BF8D
>>  http://powerquality.eaton.com/68558.aspx?cx=97
>> 
>>  The problem is that at some point, after being online for a while, 
>> the UPS shuts down, cutting the power of all devices without sending 
>> any command. The log of the master monitor registers a USB error 
>> before the events of the OS booting process after turning on again 
>> the UPS. I have attached the output
>> 
>>  Dec  1 21:35:18 openmediavault kernel: [19503.643123] usb 3-2: 
>> usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 6 ret 
>> -110
>>  Dec  1 21:35:26 openmediavault kernel: [19511.835644] usb 3-2: 
>> usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 5 ret 
>> -110
> 
> "ret -110" is a timeout, and on other MGE models, I see those 
> sporadically throughout the day. Those might even correspond to the 
> "libusb_get_interrupt: Connection timed out" lines in the debug
log.
> 
> If there is no message to NUT, I would consider opening a trouble 
> ticket with Eaton. It is possible that there is a known issue and/or 
> a firmware upgrade.
> 
> Also, given that the load is only 12%, double-check that the UPS is 
> not configured for any power saving features that might cause the 
> shutdown ("ECO mode" or similar). NUT does not get a notification
for
> that event the way that it gets a normal LB shutdown notification.
> 
> --
> Charles Lepple
> clepple at gmail
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20181202/4923192d/attachment.html>

I have restored original configuration and enabled the ignorelb flag. I 
didn't point out in the original e-mail that after every poweroff the 
battery percentage is reported at 40% instead of 100% and charges 
slowly again to 100%. Maybe the UPS sends a LB event and shuts down 
immediatly as suggested in the manual. But the UPS powered off again.
The variables reported by upsc can be found here: 
https://pastebin.com/JWmnp8iW
Graphs plotting the battery charge can be found here: 
https://screenshots.firefox.com/iyTY8fAIB2MjXMV5/openmediavault.local
The battery charge drops suddenly when the UPS shuts down. When I power 
it on again, the batter starts charging from there.
In the same instant of time, the USBDEVFS_CONTROL messages appear in 
the log:
> Dec  2 18:39:59 openmediavault postfix/qmgr[2088]: 9E9F65001EB: 
> from=<xxxxx at gmail.com>, size=509, nrcpt=2 (queue active)
> Dec  2 18:40:00 openmediavault postfix/smtp[22067]: 9E9F65001EB: 
> replace: header Subject: UPS notification from openmediavault: 
> Subject: [openmediavault.local] UPS notification from openmediavault
> Dec  2 18:40:05 openmediavault kernel: [51569.428523] usb 1-2: usbfs: 
> USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 6 ret -110
> Dec  2 18:40:12 openmediavault upsd[20509]: Data for UPS [ellipsemax] 
> is stale - check driver
> Dec  2 18:40:13 openmediavault kernel: [51577.620729] usb 1-2: usbfs: 
> USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 5 ret -110
> Dec  2 18:40:14 openmediavault upsmon[20537]: Poll UPS 
> [ellipsemax at localhost] failed - Data stale
> Dec  2 18:40:14 openmediavault upsmon[20537]: Communications with UPS 
> ellipsemax at localhost lost
> Dec  2 18:40:14 openmediavault upssched[22118]: Executing command: 
> notify
> Dec  2 18:40:14 openmediavault postfix/pickup[19654]: 9F43D5001EB: 
> uid=111 from=<nut>
> Dec  2 18:40:14 openmediavault postfix/qmgr[2088]: 9F43D5001EB: 
> from=<xxxxx at gmail.com>, size=502, nrcpt=2 (queue active)
> Dec  2 18:41:24 openmediavault kernel: [    2.353259] ACPI: bus type 
> USB registered

UPS communication is lost, upssched notifies, postfix sends email. The 
last message belongs to the next boot (kernel time 2.35).
Any other suggestions? UPS is EOL. It does not have ECO mode. Ignorelb 
didn't work.
> En ds., 1 de de des. 2018 a les 11:48 P. M., Charles Lepple 
> <clepple at gmail.com> ha escrit:
>> On Dec 1, 2018, at 3:45 PM, raul <raulvior.bcn at gmail.com>
wrote:
>>> 
>>>  The UPS is connected to the following environment:
>>>  OS: Debian GNU/Linux 9.6 (stretch)
>>>  NUT version: 2.7.4-5
>>>  Device output from lsusb: 0463:ffff MGE UPS Systems UPS
>>>  Model name: MGE EllipseMAX 1500
>>>  URLs:
>>>  
>>>
http://powerquality.eaton.com/Products-services/Backup-Power-UPS/Ellipse-MAX-eol.aspx?cx=97&GUID=7BB6CD53-9F6D-4D62-B326-1099F137BF8D
>>>  http://powerquality.eaton.com/68558.aspx?cx=97
>>> 
>>>  The problem is that at some point, after being online for a while,
>>> the UPS shuts down, cutting the power of all devices without 
>>> sending any command. The log of the master monitor registers a USB 
>>> error before the events of the OS booting process after turning on 
>>> again the UPS. I have attached the output
>>> 
>>>  Dec  1 21:35:18 openmediavault kernel: [19503.643123] usb 3-2: 
>>> usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 6 
>>> ret -110
>>>  Dec  1 21:35:26 openmediavault kernel: [19511.835644] usb 3-2: 
>>> usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 5 
>>> ret -110
>> 
>> "ret -110" is a timeout, and on other MGE models, I see those
>> sporadically throughout the day. Those might even correspond to the 
>> "libusb_get_interrupt: Connection timed out" lines in the
debug log.
>> 
>> If there is no message to NUT, I would consider opening a trouble 
>> ticket with Eaton. It is possible that there is a known issue and/or 
>> a firmware upgrade.
>> 
>> Also, given that the load is only 12%, double-check that the UPS is 
>> not configured for any power saving features that might cause the 
>> shutdown ("ECO mode" or similar). NUT does not get a
notification
>> for that event the way that it gets a normal LB shutdown 
>> notification.
>> 
>> --
>> Charles Lepple
>> clepple at gmail
>> 
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20181202/b326e6cd/attachment.html>

On December 2, 2018 7:29:38 PM GMT+02:00, raul <raulvior.bcn at gmail.com>
wrote:
>I have restored original configuration and enabled the ignorelb flag. I
>
>didn't point out in the original e-mail that after every poweroff the 
>battery percentage is reported at 40% instead of 100% and charges 
>slowly again to 100%. Maybe the UPS sends a LB event and shuts down 
>immediatly as suggested in the manual. But the UPS powered off again.
>The variables reported by upsc can be found here: 
>https://pastebin.com/JWmnp8iW
>Graphs plotting the battery charge can be found here: 
>https://screenshots.firefox.com/iyTY8fAIB2MjXMV5/openmediavault.local
>The battery charge drops suddenly when the UPS shuts down. 
Maybe I am completely wrong but this behaviour rhymes quite well with a faulty
(old) battery which reports being charged but actually cannot really hold the
charge. I suggest taking it off and verifying it with a voltmeter , preferably
while having a consumer connected as well ( like a good old 12V incandescent
light bulb, as those used for cars i.e. 25-45W or so )

Wolfy

On Dec 1, 2018, at 10:08 PM, raul <raulvior.bcn at gmail.com>
wrote:
> 
>> Also, given that the load is only 12%, double-check that the UPS is not
configured for any power saving features that might cause the shutdown
("ECO mode" or similar). NUT does not get a notification for that
event the way that it gets a normal LB shutdown notification.
> 
> Are you referring to NUT (ups.conf) or to the UPS itself? I have checked
the instruction manual and it says nothing about ECO modes. It talks only about
disabling alarms or changing sensitivity to source voltage variations.
> 
I was referring to a setting on the UPS (which NUT can change). It would look
like this in the upsc output, so I don't think you have it:

outlet.1.autoswitch.charge.low: 0

I have taken out the batteries and measured them with a multimeter. 
They put out 13V (they are rated 12V 9Ah).
Putting them back again and disconnecting the UPS from the mains it is 
kept on, powering all the connected devices.
The shutdowns only occur when the UPS is being monitored. Are you sure 
it's a battery problem? Do UPS perform further tests when they are 
being polled for data? I'll check with newer batteries then. I bought 
these one year ago :S

En dg., 2 de de des. 2018 a les 11:53 P. M., Charles Lepple 
<clepple at gmail.com> ha escrit:
> On Dec 1, 2018, at 10:08 PM, raul <raulvior.bcn at gmail.com> wrote:
>> 
>>>  Also, given that the load is only 12%, double-check that the UPS 
>>> is not configured for any power saving features that might cause 
>>> the shutdown ("ECO mode" or similar). NUT does not get a 
>>> notification for that event the way that it gets a normal LB 
>>> shutdown notification.
>> 
>>  Are you referring to NUT (ups.conf) or to the UPS itself? I have 
>> checked the instruction manual and it says nothing about ECO modes. 
>> It talks only about disabling alarms or changing sensitivity to 
>> source voltage variations.
>> 
> I was referring to a setting on the UPS (which NUT can change). It 
> would look like this in the upsc output, so I don't think you have it:
> 
> outlet.1.autoswitch.charge.low: 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20181203/22b552b6/attachment-0001.html>