[Nut-upsdev] [EXTERNAL] Fixing Drops With SMART1500LCDXL & USB-HID Driver
David Zomaya
David_Zomaya at tripplite.com
Fri Jun 21 19:54:12 BST 2019
Ok, so I have made some progress that seems to suggest the initial “fix” I stumbled upon isn’t required. I haven’t yet worked backwards to figure out reasons why our customers have had similar complaints or solve the problem on the CentOS VM yet, but that is on the todo list. I am hoping it ends up just being not enabling the service on startup, but I can’t say that explains away all the symptoms just yet.
For now, below is where I am at after testing with CentOS 7.6 and the same SMART1500LCDXL (SM886B) UPS on an HP Compaq Pro 6305.
· No special udev rules seemed to be needed.
· I did not need to add “pollinterval = 1” to the ups.conf.
· It seemed that starting upsd and the driver would fix the drops, but they would return after reboots of the operating system.
· Enabling NUT to start with:
$ sudo systemctl enable nut-server.service
$ sudo systemctl enable nut-monitor.service
Seemed to make the drops go away completely.
These leaves me with the questions of “why are we dropping in the first place?” (obviously not a NUT problem and maybe not as big a deal now that it seems to work) and “why has it been impacting users ability to use this model and a similar model?”. I am hoping to better understand this as I go back and dig into the other issues. Any inputs are appreciated.
Below are the details from the system, UPS, and version of NUT.
Kernel:
3.10.0-957.el7.x86_64
CentOS info:
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
Network UPS Tools (installed from EPEL repo using “yum install nut”) version:
Network UPS Tools upsd 2.7.2
Messages in /var/log/messages when UPS was dropping (note that you were correct about the serial number reporting “0”):
Jun 21 11:34:49 localhost kernel: usb 8-2: USB disconnect, device number 103
Jun 21 11:34:49 localhost kernel: usb 8-2: new low-speed USB device number 104 using xhci_hcd
Jun 21 11:34:49 localhost kernel: usb 8-2: New USB device found, idVendor=09ae, idProduct=2012
Jun 21 11:34:49 localhost kernel: usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 21 11:34:49 localhost kernel: usb 8-2: Product: Tripp Lite UPS
Jun 21 11:34:49 localhost kernel: usb 8-2: Manufacturer: Tripp Lite
Jun 21 11:34:50 localhost kernel: hid-generic 0003:09AE:2012.1027: hiddev0,hidraw0: USB HID v1.10 Device [Tripp Lite Tripp Lite UPS ] on usb-0000:00:10.1-2/input0
Jun 21 11:35:04 localhost kernel: usb 8-2: USB disconnect, device number 104
Jun 21 11:35:04 localhost kernel: usb 8-2: new low-speed USB device number 105 using xhci_hcd
Jun 21 11:35:05 localhost kernel: usb 8-2: New USB device found, idVendor=09ae, idProduct=2012
Jun 21 11:35:05 localhost kernel: usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 21 11:35:05 localhost kernel: usb 8-2: Product: Tripp Lite UPS
Jun 21 11:35:05 localhost kernel: usb 8-2: Manufacturer: Tripp Lite
Jun 21 11:35:05 localhost kernel: hid-generic 0003:09AE:2012.1028: hiddev0,hidraw0: USB HID v1.10 Device [Tripp Lite Tripp Lite UPS ] on usb-0000:00:10.1-2/input0
Jun 21 11:35:19 localhost kernel: usb 8-2: USB disconnect, device number 105
Jun 21 11:35:19 localhost kernel: usb 8-2: new low-speed USB device number 106 using xhci_hcd
Jun 21 11:35:20 localhost kernel: usb 8-2: New USB device found, idVendor=09ae, idProduct=2012
Jun 21 11:35:20 localhost kernel: usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 21 11:35:20 localhost kernel: usb 8-2: Product: Tripp Lite UPS
Jun 21 11:35:20 localhost kernel: usb 8-2: Manufacturer: Tripp Lite
Jun 21 11:35:20 localhost kernel: hid-generic 0003:09AE:2012.1029: hiddev0,hidraw0: USB HID v1.10 Device [Tripp Lite Tripp Lite UPS ] on usb-0000:00:10.1-2/input0
/etc/ups/ups.conf
[TrippLiteUPS]
driver = usbhid-ups
port = auto
desc = "SMART1500LCD"
sudo lsusb –v output for UPS
Bus 008 Device 098: ID 09ae:2012 Tripp Lite
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x09ae Tripp Lite
idProduct 0x2012
bcdDevice 0.09
iManufacturer 1 Tripp Lite
iProduct 2 Tripp Lite UPS
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 662
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 40
Device Status: 0x0001
Self Powered
****************************
On a related note:
Charles,
This
“I keep meaning to put together a diagram to help with this, but in the mean time:
UPS <-- driver <-- upsd <-- clients (upsc, upsmon, NUT Monitor GUI, etc.)
"upsc -l" is making a TCP connection to upsd localhost:3493 (no sudo needed here), so a "Connection refused" is likely due to upsd not running. (If it were over the network, I'd recommend first logging into the master system and running "upsc" there, then check for the LISTEN address in upsd.conf, and any firewalls in between the systems running upsd and upsc.)
You should be able to get it working for testing with a quick "sudo upsd", though it is probably some sort of startup script issue. I do not know exactly how openSUSE's packages interact with their init system- maybe others on the list can help. (A quick search of nut-upsuser indicates that 42.3 is using systemd, so if 15.1 does as well, maybe "systemctl | grep ^nut" will show a unit that just needs to be restarted.)”
Was very helpful in conceptualizing and working through the setup. Thank you.
****************************
Thank you,
David Zomaya
Tripp Lite
-----Original Message-----
From: Charles Lepple <clepple at gmail.com>
Sent: Thursday, June 20, 2019 7:47 AM
To: David Zomaya <David_Zomaya at tripplite.com>
Cc: nut-upsdev at alioth-lists.debian.net; Jonathan Manzanilla <Jonathan_Manzanilla at tripplite.com>; Eric Cobb <Eric_Cobb at tripplite.com>
Subject: Re: [EXTERNAL] [Nut-upsdev] Fixing Drops With SMART1500LCDXL & USB-HID Driver
On Jun 19, 2019, at 4:16 PM, David Zomaya wrote:
>
> Interestingly, I did some tinkering with openSUSE 15.1 Leap on a physical box and saw the same drops there, but was able to get them to stop after installing NUT and just doing the “standard” configuration. However, I ran into some connection refused messages, e.g.:
>
> user at linux-nxmm:/dev/bus> sudo upsc -l
> Error: Connection failure: Connection refused
>
I keep meaning to put together a diagram to help with this, but in the mean time:
UPS <-- driver <-- upsd <-- clients (upsc, upsmon, NUT Monitor GUI, etc.)
"upsc -l" is making a TCP connection to upsd localhost:3493 (no sudo needed here), so a "Connection refused" is likely due to upsd not running. (If it were over the network, I'd recommend first logging into the master system and running "upsc" there, then check for the LISTEN address in upsd.conf, and any firewalls in between the systems running upsd and upsc.)
You should be able to get it working for testing with a quick "sudo upsd", though it is probably some sort of startup script issue. I do not know exactly how openSUSE's packages interact with their init system- maybe others on the list can help. (A quick search of nut-upsuser indicates that 42.3 is using systemd, so if 15.1 does as well, maybe "systemctl | grep ^nut" will show a unit that just needs to be restarted.)
________________________________
This message is for the addressee's use only. It may contain confidential information. If you receive this message in error, please delete it and notify the sender. Tripp Lite disclaims all warranties and liabilities, and assumes no responsibility for viruses which may infect an email sent to you from Tripp Lite and which damage your electronic systems or information. It is your responsibility to maintain virus detection systems to prevent damage to your electronic systems and information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20190621/352cbf9d/attachment-0001.html>
More information about the Nut-upsdev
mailing list