[Nut-upsdev] Liebert PowerSure PSA 500

Peter Selinger selinger at mathstat.dal.ca
Sun Sep 25 16:23:59 UTC 2005


Jochen,

have you been able to get your Liebert UPS to work? If I am correct,
it should work with the newhidups Belkin subdriver. Could you please
post your results? I am curious to know if this works or doesn't - and
if yes, we should add permanent support for Liebert into NUT. 

Thanks, -- Peter

Jochen Bern wrote on Sept 8:
> 
> Update from Liebert: They referred me to an external service company
> where I talked to someone who actually writes purpose built monitoring
> software for (the more expensive) Liebert UPSes. He commented that
> a) even in Liebert's own MultiLink software, communication via USBHID
> is not quite polished, nor currently a top priority of their developers,
> to say it politely; and b) the communication option bound to offer the
> most data is neither USB nor SNMP (where supported), but RS232.
> 
> (Unfortunately, when I try the RS232 cable and the liebert driver, it
> never even gets aware of the (simulated) power outages, much less nets
> loads of information ...)
> 
> Peter Selinger wrote:
> > Jochen Bern wrote:
> > > -- lsusb -v claims it "cannot get report descriptor".
> > This is because the kernel driver is attached, and lsusb can't attach
> > itself to this device. 
> 
> Sorry, I should've included a larger part of the output; it's *only* the
> report descriptor that lsusb cannot access/read, as in:
> 
> | # lsusb -v -s 2:21 | grep -A 1 -B 2 -i ' descriptor'
> | Bus 002 Device 021: ID 10af:0001
> | Device Descriptor:
> |   bLength                18
> |   bDescriptorType         1
> | --
> |   bNumConfigurations      1
> |   Configuration Descriptor:
> |     bLength                 9
> |     bDescriptorType         2
> | --
> |     MaxPower               20mA
> |     Interface Descriptor:
> |       bLength                 9
> |       bDescriptorType         4
> | --
> |       iInterface              0
> |         HID Device Descriptor:
> |           bLength                 9
> |           bDescriptorType        33
> | --
> |           wDescriptorLength     602
> | cannot get report descriptor
> |       Endpoint Descriptor:
> |         bLength                 7
> |         bDescriptorType         5
> 
> > and then you should also add a line under "Supported Nanufacturers
> > IDs" in drivers/newhidups.h:
> > #define LIEBERT                   0x10af          /* All models */
> 
> (There's a separate set of "#define"s in drivers/libusb.c that needed a
> similar update.)
> 
> > At this point, at least your device should be opened, although not
> > much useful will happen yet. If you run your "bin/newhidups -DD -a
> > PowerSure", at least you should get a listing of the UPS's Usage Tree. 
> 
> Output at the end of this email.
> 
> > Then you also need to add a
> > new file drivers/liebert-hid.h, modeled on drivers/apc-hid.h, changing
> > APC to LIEBERT everywhere, and making sure this new file is also
> > #include'd in drivers/newhidups.c. Then you have to customize that file.
> 
> Umh ... I suppose that's the part where I'm supposed to pull a Liebert
> internal tech manual, listing their vendor-specific encodings, out of
> some pocket ... ? :-}
> 
> > > 	[... pulling mains cable]
> > > -- UPS has changed bus ID from 2:2 to 2:6 after the experiment. (Note
> > >     that I pulled the cable *twice* to verify some detail ...)
> > That is normal. When you unplug and re-plug the UPS, it gets assigned
> > a new bus ID. This can also sometimes be caused by software that
> > "resets" the device.
> 
> I'm sorta stumped. If it's normal that the USB communication gets
> reset when I yank the *POWER* cable (to simulate an outage), and also
> (I assume) normal that the driver cannot keep talking to the hiddev
> device it has open()ed because of the reset, how will the USBHID drivers
> *ever* be able to detect online <--> on battery switchovers without
> throwing an I/O error message?
> 
> Charles Lepple wrote:
> > For the record, the problem with the kernel HID interface is that it
> > does not allow access to nested HID elements as seen in many high-end
> > HID UPSes. (I think this has been fixed in later 2.6.x kernels, but
> > don't quote me on that.)
> 
> (Will try a newer kernel version as soon as time permits.)
> 
> Regards,
> 								J. Bern
> 
> # bin/newhidups -DD -a PowerSure
> debug level is '2'
> Opening new device (0000/0000)
> Opening new device (0000/0000)
> Opening new device (0000/0000)
> Opening new device (10AF/0001)
> Found 0x10af
> failed to claim USB device, trying 2 more time(s)...
> detaching kernel driver from USB device...
> trying again to claim USB device...
> - Manufacturer : Liebert
> - Product      : Liebert PSA 500 FW:09
> - Serial Number: 0507600440BA069
> HID descriptor retrieved (Reportlen =   602)
> Report descriptor retrieved (Reportlen = 602)
> found 1 (602)
> Network UPS Tools: New USB/HID UPS driver 0.27 (2.1.0)
> 
> Report Descriptor size = 602
> Detected an UPS: Liebert/Liebert PSA 500 FW:09
> 
> Manufacturer not supported!
> Contact the driver author <arnaud.quette at free.fr / @mgeups.com> with the below information
> Path: UPS.00860026.00860042, Type: Feature
> Path: UPS.00860026.00860043, Type: Feature
> Path: UPS.00860026.00860044, Type: Feature
> Path: UPS.00860029.00860075, Type: Feature
> Path: UPS.00860029.BUPDelayBeforeStartup, Type: Feature
> Path: UPS.00860029.0086007c, Type: Feature
> Path: UPS.00860027.00860058, Type: Feature
> Path: UPS.00860027.0086005a, Type: Feature
> Path: UPS.00860027.00860057, Type: Feature
> Path: UPS.00860027.00860056, Type: Feature
> Path: UPS.00860027.00860080, Type: Feature
> Path: UPS.00860027.00860081, Type: Feature
> Path: UPS.00860027.00860082, Type: Feature
> Path: UPS.00860027.00860083, Type: Feature
> Path: UPS.00860027.00860084, Type: Feature
> Path: UPS.0086002a.0086001a.00860030, Type: Feature
> Path: UPS.0086002a.0086001a.00860032, Type: Feature
> Path: UPS.0086002a.0086001a.00860036, Type: Feature
> Path: UPS.0086002a.0086001c.00860030, Type: Feature
> Path: UPS.0086002a.0086001c.00860032, Type: Feature
> Path: UPS.0086002a.0086001c.00860035, Type: Feature
> Path: UPS.BUPSelfTest.00860030, Type: Feature
> Path: UPS.BUPSelfTest.00860039, Type: Feature
> Path: UPS.00860028.00860021, Type: Feature
> Path: UPS.00860028.00860022, Type: Feature
> Can't retrieve Report 40 (-75/75)
> Path: UPS.PowerSummary.iProduct, Type: Feature
> Can't retrieve Report 41 (-71/71)
> Path: UPS.PowerSummary.iSerialNumber, Type: Feature
> Can't retrieve Report 42 (-71/71)
> Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature
> Can't retrieve Report 43 (-71/71)
> Path: UPS.PowerSummary.iOEMInformation, Type: Feature
> Can't retrieve Report 44 (-71/71)
> Path: UPS.PowerSummary.Rechargeable, Type: Feature
> Can't retrieve Report 45 (-71/71)
> Path: UPS.PowerSummary.Charging, Type: Input
> Can't retrieve Report 45 (-71/71)
> Path: UPS.PowerSummary.Charging, Type: Feature
> Can't retrieve Report 46 (-71/71)
> Path: UPS.PowerSummary.Discharging, Type: Input
> Can't retrieve Report 46 (-71/71)
> Path: UPS.PowerSummary.Discharging, Type: Feature
> Can't retrieve Report 48 (-71/71)
> Path: UPS.PowerSummary.ConfigVoltage, Type: Feature
> Can't retrieve Report 49 (-71/71)
> Path: UPS.PowerSummary.Voltage, Type: Feature
> Can't retrieve Report 50 (-71/71)
> Path: UPS.PowerSummary.Current, Type: Feature
> Can't retrieve Report 51 (-71/71)
> Path: UPS.PowerSummary.CapacityMode, Type: Feature
> Can't retrieve Report 52 (-71/71)
> Path: UPS.PowerSummary.RemainingCapacity, Type: Input
> Can't retrieve Report 52 (-71/71)
> Path: UPS.PowerSummary.RemainingCapacity, Type: Feature
> Can't retrieve Report 53 (-71/71)
> Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input
> Can't retrieve Report 53 (-71/71)
> Path: UPS.PowerSummary.RunTimeToEmpty, Type: Feature
> Can't retrieve Report 54 (-71/71)
> Path: UPS.PowerSummary.DesignCapacity, Type: Feature
> Can't retrieve Report 55 (-71/71)
> Path: UPS.PowerSummary.FullChargeCapacity, Type: Feature
> Can't retrieve Report 56 (-71/71)
> Path: UPS.PowerSummary.WarningCapacityLimit, Type: Feature
> Can't retrieve Report 57 (-71/71)
> Path: UPS.PowerSummary.CapacityGranularity2, Type: Feature
> Can't retrieve Report 58 (-71/71)
> Path: UPS.PowerSummary.RemainingCapacityLimit, Type: Feature
> Can't retrieve Report 59 (-71/71)
> Path: UPS.PowerSummary.CapacityGranularity1, Type: Feature
> Can't retrieve Report 60 (-71/71)
> Path: UPS.PowerSummary.ACPresent, Type: Feature
> Can't retrieve Report 60 (-71/71)
> Path: UPS.PowerSummary.ACPresent, Type: Input
> Can't retrieve Report 61 (-108/108)
> Path: UPS.PowerSummary.BelowRemainingCapacityLimit, Type: Input
> Can't retrieve Report 61 (-19/19)
> Path: UPS.PowerSummary.BelowRemainingCapacityLimit, Type: Feature
> Can't retrieve Report 62 (-19/19)
> Path: UPS.PowerSummary.ShutdownImminent, Type: Input
> Can't retrieve Report 62 (-19/19)
> Path: UPS.PowerSummary.ShutdownImminent, Type: Feature
> Path: UPS.PowerSummary.0085006c, Type: Feature
> Aborting
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
> 




More information about the Nut-upsdev mailing list