Nut upsuser - Jan 2019 - Just an interesting data point [CyberPower SNMP/USB]

On 1/27/19 9:13 PM, Charles Lepple wrote:
> On Jan 27, 2019, at 2:36 PM, Phil Stracchino <phils at caerllewys.net
> <mailto:phils at caerllewys.net>> wrote:
>> The new Cyberpower PR3000 (also 3KVA), wqhich operates at a 90% power
>> factor, considers this same load to be 43% load.
>>
>> I wasn't expecting that much of a reduction.
> 
> So... 50% load +/- 10% :-)
> 
> (The use of the term "calibration" for an UPS is slightly
unfortunate -
> it's certainly not a traceable metrology-style calibration. I would not
> be surprised if most of the passives were 5-10% tolerance, and not
> temperature compensated.)
Oh, I know.  But it should give the UPS a better idea of how long it can
*actually* support that load, and for this purpose that's good enough
for me.
>> In particular, no load, no input or output voltage.  (And the runtime
>> report is not to be trusted yet until I do a calibration run.)
> 
> I forgot that this landed after 2.7.4: 
> 
>
https://github.com/networkupstools/nut/pull/632/commits/3f5e3728a720aba0be76b2fccb603b04962bb904
> 
> 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.

I would tend to make the same assumption about the RM205 vs. the RM202.
> You can also use snmpwalk to see what other values might be available.
> Since there is already a skeleton MIB mapping in NUT, the only two
> things needed are probably the snmpwalk outputs described at the end of
> this
>
section: https://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#snmp-subdrivers
> 
>> (Also, I can so far connect only using snmpv1, but I don't know
whether
>> I should expect to get any additional data from snmpv3 anyway.)
> 
> Again, not my area of expertise, but as far as NUT is concerned, I think
> the different versions are for authentication methods (SNMPv1 is
cleartext).

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



-- 
  Phil Stracchino
  Babylon Communications
  phils at caerllewys.net
  phil at co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

On Jan 27, 2019, at 9:31 PM, Phil Stracchino <phils at caerllewys.net>
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.

On 1/27/19 9:49 PM, Charles Lepple wrote:
> 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.
> 

Thanks, useful to know.  I'll have to keep a note of that in case
anything starts looking weird.

I'm not 100% certain I'm tracking what you mean by 'scaled to the
transfer voltage range' though.  Could you clarify?


-- 
  Phil Stracchino
  Babylon Communications
  phils at caerllewys.net
  phil at co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958