On Dec 28, 2011, at 9:16 AM, Ariel wrote: > On Wed, 28 Dec 2011, Charles Lepple wrote: > >> On Dec 28, 2011, at 3:48 AM, Ariel wrote: [...] >>> 0.022302 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, >>> ReportID: 0x09, Offset: 0, Size: 8, Value: 24.000000 >>> 0.022332 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: >>> 0x0a, Offset: 0, Size: 8, Value: 24.000000 > >> Is it possible that UPS.PowerSummary.Voltage is really an output voltage >> divided by 10? (This has happened on other devices.) > > Well, I have two 12 volt batteries, so 24 volts makes sense, 240 doesn't.
I meant AC output voltage, not DC. There are many interpretations of the HID PDC spec in various UPSes, and most of them are incorrect (or at least, not self-consistent). >> What might be useful (and this applies to your other feature requests as >> well) is to verify that the values change as expected during a deep >> discharge cycle. > > Yes, I intend to do that, once I get everything installed fully so I can test > everything end to end. (Although I won't be able to test the buck/boost till > the summer when my voltage drops a lot.) The code will definitely need to be tested. Let us know when you're ready to do that. >> I have a feeling that we may need to develop a more generic scaling >> capability in some of these drivers. On the other hand, we probably should >> make it obvious that certain values are being modified before being reported. > > I agree - I think the scaling should be configured in ups.conf, and be > general for any field. To make it very easy support +-*/ without precedence - > operations are done strictly left to right. Perhaps 3 fields: operation, min, > max (min/max are applied after scaling, not before). We will need to think about this a bit more to bound the scaling/offset problem. Min and max have traditionally either been reported directly from the UPS (the onboard microcontroller often tracks this), or have been handled by higher-level reporting tools such as RRD (which might miss short transients). Logged in Alioth's feature request tracker: https://alioth.debian.org/tracker/?func=browse&group_id=30602&atid=411545 >> Also, what version of NUT are you using? I seem to remember that we fixed >> the debug output so that it didn't always print values in fixed-point >> notation. > > I'm using 2.4.3 (debian stable - you'll be getting a lot of reports for that > version for the next year or two). I was thinking of installing 2.6.2 if it > had any features I needed. Fortunately, the interface between drivers and upsd hasn't changed much, so it should be possible to configure 2.6.x or a SVN/git checkout to build a driver that will neatly overlay the one from the 2.4.x package. > lsusb -vvv -d 0764:0501 (I find it interesting that this appears to include > all the values the UPS sends, I didn't know the kernel tracks that.) Technically, lsusb is only using the kernel to pass USB requests down to the device - it does not see what the kernel has stored. What usually happens is that the kernel usbhid driver has exclusive access to the HID interface on the USB device, and lsusb can't retrieve the HID report descriptor: HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 33 US bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 387 Report Descriptors: ** UNAVAILABLE ** If you run lsusb with appropriate write permissions (usually as root) *after* NUT's usbhid-ups driver has connected to the device, the kernel usbhid driver will be detached, and lsusb will show the additional information. > Bus 002 Device 007: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0764 Cyber Power System, Inc. > idProduct 0x0501 CP1500 AVR UPS > bcdDevice 0.01 > iManufacturer 1 CP1350PFCLCD > iProduct 2 CRCA102-3I1 > iSerial 3 CPS It looks like the manufacturer, product and serial strings have been permuted. I think we can match on iManufacturer here once we figure out what the scaling should be. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
