On Jan 27, 2019, at 9:31 PM, Phil Stracchino <[email protected]> wrote: > > On 1/27/19 9:13 PM, Charles Lepple wrote: >> I forget, is your copy of NUT built from an RPM? If so, it shouldn't be >> too hard to add that patch to get load, charge, input voltage/frequency >> and output voltage (assuming the RM205 is a superset of the RM202). > > This is Gentoo Linux so it's built from the latest source version in the > repository.
If it is still showing version 2.7.4, then Gentoo must be picking up the latest tag, which is probably why that change isn't showing up on your system. 2.7.5 has been held up due to some gridlock related to libusb-0.1/1.0 support. > I actually switched to the usbhid-ups driver, and it is working far > better than the snmp driver did. I just need a small USB hub now, > because there's only two back-panel USB ports on this server and I now > need three (KVM, GPS receiver, and UPS). You might be lucky with this particular model, but definitely beware of the USB issues I mentioned in another thread: https://github.com/networkupstools/nut/issues?q=is%3Aissue+is%3Aopen+label%3A%22CyberPower+%28CPS%29%22 The output of upsc is sorted alphabetically by key, so it isn't immediately obvious which values come from earlier in the report descriptor. However, after the values for input.transfer.low and input.transfer.high, the other values might end up being scaled to the transfer voltage range. Hence, I would treat a lot of the values from usbhid-ups on CyberPower hardware (including writable thresholds) as suspect. The USB HID report descriptors are hierarchical, which enables cascading errors like these. We do have a debug procedure that can get to the bottom of that if something comes up. _______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
