networkupstools
UPS Logicpower UL850VA (USB) not supported
Hi!
I've recently installed the driver richcomm_usb for UPS Logicpower UL850VA. Other drivers I tried didn't work except this one.
The main problem is , that the status of the battery is shown as ups.status: OB LB but UPS is on power and battery charge level is 100%. So, when I run upsmon - it shutdown the system.
Below are outputs of the commands:
root@mapstorage:~# upsc logicpower@localhost
Init SSL without certificate database
device.mfr: Richcomm dry-contact to USB solution
device.model: UPS USB MON V1.4
device.serial: unknown
device.type: ups
driver.name: richcomm_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.7.1
driver.version.internal: 0.04
ups.mfr: Richcomm dry-contact to USB solution
ups.model: UPS USB MON V1.4
ups.productid: 1234
ups.serial: unknown
ups.status: OB LB
ups.vendorid: 0925
root@mapstorage:~# upscmd -l logicpower
Instant commands supported on UPS [logicpower]:
root@mapstorage:~#
UPS is recognised by lsusb as Lakeview Research:
root@mapstorage:~# lsusb | grep Lakeview
Bus 001 Device 002: ID 0925:1234 Lakeview Research
root@mapstorage:~#
root@mapstorage:~# upsrw logicpower
root@mapstorage:~#
Please let me know what can be done to fix the ups battery status issue.
Thank you.
Do the bits for ups.status change when you unplug the input power? If not, it might just be coincidence that the driver was able to attach to the UPS.
0925:1234 is an example USB ID from Jan Axelson's "USB Complete" book, so it is no more descriptive than the 0001:0000 IDs that pop up from time to time.
What does lsusb -vvv -d:0925 return? You will need to run it as root.
While deeper investigation, I found that the status is cnanging from time to time from "OB LB" to "OB". It does not matter is UPS plugged-in or unplugged. The statuses are always the same and changing from time to time every several seconds.
root@mapstorage:~# upsc logicpower@localhost | grep ups.status
Init SSL without certificate database
ups.status: OB LB
root@mapstorage:~# upsc logicpower@localhost | grep ups.status
Init SSL without certificate database
ups.status: OB LB
root@mapstorage:~# upsc logicpower@localhost | grep ups.status
Init SSL without certificate database
ups.status: OB
root@mapstorage:~# upsc logicpower@localhost | grep ups.status
Init SSL without certificate database
ups.status: OB
lsusb command gives nothing:
root@mapstorage:~# lsusb -vvv -d:0925
root@mapstorage:~#
but I ran lsusb -vvv and took the strings related to Lakeview Research only:
Bus 001 Device 002: ID 0925:1234 Lakeview Research
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0925 Lakeview Research
idProduct 0x1234
bcdDevice 0.01
iManufacturer 1 Љ
iProduct 2 UPS USB MON V1.4
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
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.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 78
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 0x0006 1x 6 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
My mistake, I meant lsusb -vvv -d0925: - but what you have is fine.
What software does the vendor recommend using? Maybe we can match that up with another UPS/driver combination in NUT.
Maybe try the nutdrv_qx driver? (@zykh, do you remember if we ever got this USB adapter working in non-contact closure mode? I saw a few threads from ~ 10 years ago but no resolution.)
The drivers for the UPS are older than mammoth (2005 year). The drivers/documentation links I found match the drivers that were provided with UPS:
https://logicfox.ua/podderzhka/drivers/ups/LPM-U.rar https://logicfox.ua/manuals/ups/lp_650_850_1200_1500%20.pdf
I tried them, but the drivers even could not start (I have Ubuntu 14.04)
Tried nutdrv_qx driver, but it is not working.
Output of the command (just to have all info ) is below:
root@mapstorage:~# lsusb -vvv -d0925:
Bus 001 Device 002: ID 0925:1234 Lakeview Research
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0925 Lakeview Research
idProduct 0x1234
bcdDevice 0.01
iManufacturer 1 Љ
iProduct 2 UPS USB MON V1.4
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
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.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 78
Report Descriptor: (length is 78)
Item(Global): Usage Page, data= [ 0xa0 0xff ] 65440
(null)
Item(Local ): Usage, data= [ 0x01 ] 1
(null)
Item(Main ): Collection, data= [ 0x01 ] 1
Application
Item(Local ): Usage, data= [ 0x02 ] 2
(null)
Item(Main ): Collection, data= [ 0x00 ] 0
Physical
Item(Global): Usage Page, data= [ 0xa1 0xff ] 65441
(null)
Item(Local ): Usage, data= [ 0x03 ] 3
(null)
Item(Local ): Usage, data= [ 0x04 ] 4
(null)
Item(Local ): Usage, data= [ 0x05 ] 5
(null)
Item(Local ): Usage, data= [ 0x06 ] 6
(null)
Item(Local ): Usage, data= [ 0x07 ] 7
(null)
Item(Local ): Usage, data= [ 0x08 ] 8
(null)
Item(Global): Logical Minimum, data= [ 0x80 ] 128
Item(Global): Logical Maximum, data= [ 0x7f ] 127
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff ] 255
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x06 ] 6
Item(Main ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile Bitfield
Item(Local ): Usage, data= [ 0x09 ] 9
(null)
Item(Local ): Usage, data= [ 0x0a ] 10
(null)
Item(Global): Logical Minimum, data= [ 0x80 ] 128
Item(Global): Logical Maximum, data= [ 0x7f ] 127
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff ] 255
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x02 ] 2
Item(Main ): Output, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile Bitfield
Item(Local ): Usage, data= [ 0x0b ] 11
(null)
Item(Local ): Usage, data= [ 0x0c ] 12
(null)
Item(Global): Logical Minimum, data= [ 0x80 ] 128
Item(Global): Logical Maximum, data= [ 0x7f ] 127
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0xff ] 255
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Report Count, data= [ 0x02 ] 2
Item(Main ): Output, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile Bitfield
Item(Main ): End Collection, data=none
Item(Main ): End Collection, data=none
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0006 1x 6 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
For future reference, it looks like the vendor software package is called PowerManagerII, and the *nix variants are called upsmanager1G.0v and upsmanager1.0v.
(I changed the issue title because I use the keyword "HCL" to indicate compatible hardware that we need to add to the compatibility lists.)
If you want to try to get the vendor software working (in order to trace the USB comms), you can try the solution here: https://askubuntu.com/questions/454253/how-to-run-32-bit-app-in-ubuntu-64-bit#454254
@clepple: no... but the Quary_F, Quary_I and Quary_Q1 routines in that software are somewhat revelatory...
@pavloivanets: what's the output of the richcomm_usb driver when launched with a debug level of 3 (i.e. /path/to/richcomm_usb -a logicpower -DDD)?
Hi!
@zykh Here is the output of the driver:
root@mapstorage:~# /lib/nut/richcomm_usb -a logicpower -DDD
Network UPS Tools - Richcomm dry-contact to USB driver 0.04 (2.7.1)
Warning: This is an experimental driver.
Some features may not function correctly.
0.000000 debug level is '3'
0.241285 send: (4 bytes) => 01 00 00 30
0.242480 read: (6 bytes) => 80 00 00 00 00 00
1.242983 send: (4 bytes) => 01 00 00 30
1.243473 read: (6 bytes) => 01 00 00 02 86 00
2.243981 send: (4 bytes) => 01 00 00 30
2.244469 read: (6 bytes) => c0 00 00 00 00 00
3.245009 send: (4 bytes) => 01 00 00 30
3.245473 read: (6 bytes) => 80 00 00 00 00 00
4.245982 send: (4 bytes) => 01 00 00 30
4.246466 read: (6 bytes) => 01 00 00 02 86 00
5.247009 send: (4 bytes) => 01 00 00 30
5.247463 read: (6 bytes) => c0 00 00 00 00 00
5.247502 dstate_init: sock /var/run/nut/richcomm_usb-logicpower open on fd 5
5.247939 send: (4 bytes) => 01 00 00 30
5.248459 read: (6 bytes) => 01 00 00 02 06 00
5.948662 new connection on fd 6
7.249264 send: (4 bytes) => 01 00 00 30
7.250463 read: (6 bytes) => 01 00 00 02 06 00
9.251283 send: (4 bytes) => 01 00 00 30
9.252482 read: (6 bytes) => 01 00 00 02 06 00
11.253274 send: (4 bytes) => 01 00 00 30
11.254466 read: (6 bytes) => 01 00 00 02 06 00
13.255354 send: (4 bytes) => 01 00 00 30
13.256475 read: (6 bytes) => 01 00 00 02 06 00
15.256590 send: (4 bytes) => 01 00 00 30
15.257465 read: (6 bytes) => 01 00 00 02 06 00
17.258613 send: (4 bytes) => 01 00 00 30
17.259514 read: (6 bytes) => 01 00 00 02 06 00
19.260850 send: (4 bytes) => 01 00 00 30
19.261491 read: (6 bytes) => 01 00 00 02 06 00
21.262029 send: (4 bytes) => 01 00 00 30
21.262496 read: (6 bytes) => 80 00 00 00 00 00
23.264004 send: (4 bytes) => 01 00 00 30
23.264475 read: (6 bytes) => 01 00 00 02 86 00
25.266028 send: (4 bytes) => 01 00 00 30
25.266472 read: (6 bytes) => 01 00 00 02 86 00
27.268062 send: (4 bytes) => 01 00 00 30
27.268489 read: (6 bytes) => 01 00 00 02 86 00
29.269019 send: (4 bytes) => 01 00 00 30
29.269530 read: (6 bytes) => 01 00 00 02 86 00
31.270980 send: (4 bytes) => 01 00 00 30
31.271491 read: (6 bytes) => 01 00 00 02 86 00
33.273006 send: (4 bytes) => 01 00 00 30
33.273507 read: (6 bytes) => 01 00 00 02 86 00
35.274999 send: (4 bytes) => 01 00 00 30
35.275487 read: (6 bytes) => c0 00 00 00 00 00
37.277027 send: (4 bytes) => 01 00 00 30
37.277527 read: (6 bytes) => 80 00 00 00 00 00
39.278917 send: (4 bytes) => 01 00 00 30
39.279513 read: (6 bytes) => 01 00 00 02 86 00
41.281034 send: (4 bytes) => 01 00 00 30
41.281485 read: (6 bytes) => 01 00 00 02 86 00
43.282975 send: (4 bytes) => 01 00 00 30
43.283509 read: (6 bytes) => 01 00 00 02 86 00
45.285098 send: (4 bytes) => 01 00 00 30
45.285505 read: (6 bytes) => 01 00 00 02 86 00
47.287094 send: (4 bytes) => 01 00 00 30
47.287515 read: (6 bytes) => 01 00 00 02 86 00
49.289160 send: (4 bytes) => 01 00 00 30
49.289499 read: (6 bytes) => c0 00 00 00 00 00
51.291140 send: (4 bytes) => 01 00 00 30
51.291489 read: (6 bytes) => 80 00 00 00 00 00
53.293178 send: (4 bytes) => 01 00 00 30
53.293508 read: (6 bytes) => 01 00 00 02 86 00
55.295128 send: (4 bytes) => 01 00 00 30
55.295511 read: (6 bytes) => c0 00 00 00 00 00
57.297220 send: (4 bytes) => 01 00 00 30
57.297497 read: (6 bytes) => 80 00 00 00 00 00
After further inspection, I came to this..
Apparently there are (at least) 3 protocols used by devices using those richcomm serial/usb things (all should identify themselves as 0925:1234):
- USB devices supported by PowerManagerLite:
- those are only contact closure devices -- the protocol is the one currently implemented in
richcomm_usbdriver... (they should only support the1and2'commands', and probably the30in01 00 00 30should not be needed),
- those are only contact closure devices -- the protocol is the one currently implemented in
- USB devices supported by PowerManagerII:
- Q1 devices (
Q1,I,F,S<n>commands should be supported, possibly others), with commands simply sent to the device as they are (split in 4 byte packets, with the first byte used to store the length of the bytes to follow, i.e. max 3), - other devices with a protocol somewhat similar to the dry-contact one, with 'commands' at least from
1to17(the meaning is not the same of the dry-contact protocol, though, so1!= status flag and2!= shutdown).
- Q1 devices (
Now, @pavloivanets, at first glance, the output you posted doesn't look like the dry-contact one... I'll try to implement the other two (starting from the Q1 one), and come back here when ready...
So, @pavloivanets... here I am, a (no longer) young man, a crashing computer program.
First try here: https://github.com/zykh/nut/tree/poorcomm
I amended the richcomm_usb driver to also try the other -ahem- 'commands' (excluding 2 and 17, which should be the shutdowns in the two protocols), in order to gather some data to work with... so (best scenario) the driver will still behave as before...
While in nutdrv_qx, I added a new USB subdriver that could (could) actually work, if your device is of the right type, and my assumptions are right...
Please, post the output of:
nutdrv_qx, launched with a debug level of 5 and using protocol 'megatec' (/path/to/nutdrv_qx -a <upsname> -DDDDD -x protocol=megatec),richcomm_usb, launched with a debug level of 3 (let it run for a couple of minutes or so).
I'd try them with only a dummy load on the UPS, in case it's actually of the contact closure type and/or the things the drivers do mean something unexpectedly wrong for it... Also, your computer may explode.
Same issue with LogicPower U650VA-P and richcomm_usb:
device.mfr: Richcomm dry-contact to USB solution device.model: UPS USB MON V1.4 device.serial: unknown device.type: ups driver.name: richcomm_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.version: 2.7.4 driver.version.internal: 0.04 ups.mfr: Richcomm dry-contact to USB solution ups.model: UPS USB MON V1.4 ups.productid: 1234 ups.serial: unknown ups.status: OB ups.vendorid: 0925
ups.status changes between "OB" and "OB LB" randomly and nothing indicates if UPS works on battery.
Same for me. Should you be aware of any fix for this please kindly reply (this issue is 2 years old. I can't believe that a custom driver isn't available. :( )
Sadly, no progress that I'd be aware of. Did you check if the branch @zykh posted above works for your devices?
I did the protocol of power manager ii in this issue: https://github.com/networkupstools/nut/issues/1238
By reading the comments i believe it supports this ups and this could be closed (maybe hw compat tested and list updated)
Guys, at this point, should this bug be closed, after the merged https://github.com/networkupstools/nut/pull/2005 ?
Or is this waiting more testing?
Did anyone test it with LogicPower though? Your latest test was with Vultech AFAIK?
If it works with LogicPower I'd add some model to description of driver and certainly close it.
Did anyone test it with LogicPower though? Your latest test was with Vultech AFAIK?
If it works with LogicPower I'd add some model to description of driver and certainly close it.
My test was with the Vultech indeed, and no, I do not have specifically this Logicpower up, so well, let's ping @pavloivanets and see if this model can be tested against master branch.
I'm using also the Vultech usv (1400VA-lfp) and I managed to have a python example capable of reading the information out of the ups:
from datetime import datetime
from pprint import pprint
from time import sleep
from usb import util
import usb.core
import usb.util
dev = usb.core.find(idVendor=0x0925, idProduct=0x1234)
pprint(dev.get_active_configuration())
try:
pprint(dev.detach_kernel_driver(0))
except:
pass
# Request the HID Report Descriptor
bmRequest = usb.util.build_request_type(
direction=usb.util.CTRL_IN,
type = usb.util.CTRL_TYPE_STANDARD,
recipient=usb.util.CTRL_RECIPIENT_INTERFACE
)
pprint(
dev.ctrl_transfer(
bmRequestType=0x21,
bRequest=0x09, # GET_DESCRIPTOR
wValue=0x200, # Input Report Type
wIndex=0,
data_or_wLength=([0x80,0xd0,0x00,0x00])
)
)
requests = (
( 0xa3, 0x51, 0x31, 0x0d ),
)
i = 0
while True:
sleep(59)
dev.ctrl_transfer(
bmRequestType=0x21,
bRequest=0x09, # GET_DESCRIPTOR
wValue=0x200, # Input Report Type
wIndex=0,
data_or_wLength=(requests[i]) # Q1\r
)
i = (i +1) % len(requests)
last = 0x00
relink = 0
pprint("start reading")
value = ''
while True:
try:
result = dev.read(0x81,6, 1000)
breaker = result[0] // 16
if result[0] % 16 >0:
s = chr(result[1])
if s == '\r':
relink += 1
if breaker != last:
last = breaker
if s != '\r':
value += s
if result[0] % 16 == 0 and relink > 2:
parsed = value[value.rfind('(')+1:]
pprint(
{"changed": datetime.now().isoformat(timespec="seconds") + "Z",
"value": {
"V_in": float(parsed[0:5]),
"V_err": float(parsed[6:11]),
"V_out": float(parsed[12:17]),
"load": int(parsed[18:21]),
"freq": float(parsed[22:26]),
"vbat": float(parsed[27:31]),
"temp": float(parsed[32:36]),
"no AC": parsed[37],
"lowbat": parsed[38],
"bypass": parsed[39],
"err": parsed[40],
"status": parsed[41],
"testing": parsed[42],
"shutdown": parsed[43],
"beeper": parsed[44],
}
}
)
break
except:
break
@kes31 : did you have a chance to check with NUT v2.8.0 or newer (master-branch builds) if the device is "just supported" nowadays by NUT?
Also, would you care to post a PR with your script as an example for quick investigation prototypes, e.g. into scripts/usb_exploration? And if you have some experience and notes on command-line (or on-line) tools to investigate data dumps (hex HID reports), etc. into words humans can understand, some write-up nearby would be great (or into docs/hid-subdrivers.txt if it is about usb-hid devices) :)
Tried LogicPower LPM-UL1100VA with completely the same "result" :(
sudo upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic Q* USB/Serial driver 0.32 (2.8.0)
USB communication driver (libusb 1.0) 0.43
Using protocol: Megatec 0.06
No values for battery high/low voltages
Using 'guesstimation' (low: 20.800000, high: 26.000000)!
Battery runtime will not be calculated (runtimecal not set)
Would be happy to have it working. Please let me know if I can help with it somehow. My env: Ubuntu 23.10, NUT 2.8.0-7, driver nutdrv_qx. With richcomm_usb have initial post issue, 0B..LB..
@jimklimov In the meantime I had the chance to compile and test the code of version v2.8.2 on my system. The driver nutdrv_qx works with the give device with a sufficient set of values. I used the parameters set given in this issue #2219 .