[Nut-upsdev] Liebert PowerSure PSA 500

Wed Sep 7 23:01:36 UTC 2005

Jochen Bern wrote:
> 
> 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:
> <snip>

Yes, that is correct. Most of the information can be read without
actually "opening" the device, and lsusb will always be able to report
that information. However, some of it, such as the report descriptor,
requires opening the device, and you cannot do that while a kernel
driver is attached.

> > 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.)

Yes, thanks. 

> > 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 ... ? :-}

In principle, yes. In practice, your tree looks *extremely* similar to the Belkin tree that Zaid posted on 

http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-August/000018.html

and that Zaid and I subsequently developed newhidups support for. See
my post and patch at

http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-August/000082.html

and the related discussion. 

In fact, it is so similar that I am beginning to suspect Liebert and
Belkin are the same company, or at least they buy their UPSs from the
same supplier.

The "Can't retrieve Report" errors are also something we have seen on
the Belkin. Error 75 is EOVERFLOW or "Value too large for defined
data type" (see errno(3) and /usr/include/asm/errno.h). The subsequent
errors number 71 are "Protocol error" and are caused by the previous error. 
The above-mentioned Belkin patches also tend to fix these problems. 

> > > 	[... 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?

I wasn't aware it was the *POWER* cable you pulled; you had only
mentioned "the cable" and I assumed it was the USB cable you were
talking about. No, if you pull the power cable, the bus ID should not
change. However, the above-mentioned "protocol errors" will probably
have caused your driver to try to reset the device, and that would
have changed the bus ID. It is no problem for the newhidups driver to
reconnect to your device, even after its bus ID has changed. Devices
are identified by their manufacturer/model number, and not by their
bus ID anyway.

> 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
> 