[Nut-upsuser] MGE EllipseMAX 1500 shuts down after a few hours
raul
raulvior.bcn at gmail.com
Sun Dec 2 17:29:38 GMT 2018
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>
More information about the Nut-upsuser
mailing list