Nut upsuser - Jan 2020 - nut on armhf, r-pi4b IOW

On Tuesday 14 January 2020 00:03:09 Gene Heskett wrote:
> On Monday 13 January 2020 22:42:46 Charles Lepple wrote:
> > On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote:
> > >>> (I was looking at the hid-subdrivers.txt file in the
latest NUT
> > >>> tree, which has the command line amended to not generate
that
> > >>> "too many non-option arguments" error. Also, I
wanted it to use
> > >>> the existing cps-hid.c tables, not the generic
"explore"
> > >>> sub-driver.)
> > >>
> > >> Attached, about 30 seconds worth
> > >
> > > Was that enough to get it all?
> >
> > I should probably just ask for 60 seconds in the future :-)
> >
> > There are nearly 30 seconds' worth of "Quick update..."
lines, but
> > because the 30-second timer doesn't start until after everything
is
> > initialized (takes a few seconds at USB 1.1 speeds...), the "Full
> > update..." line isn't there.
> >
> > But no matter, it is quite similar to the CPS SX650g dump - the HID
> > report is byte-for-byte the same. Notably, the
"hidrd-convert" tool
> > fails part of the way through parsing it, which is why I suspect
> > that CPS is not following the HID spec. (That's more applicable
for
> > the high/low transfer voltages.)
> >
> > It does seem to be reporting 0% load, though:
> >
> >    0.094786	Report[get]: (3 bytes) => 13 00 00
> >    0.094875	Path: UPS.Output.PercentLoad, Type: Feature, ReportID:
> > 0x13, Offset: 0, Size: 8, Value: 0 0.094908	Report[buf]: (3 bytes)
> > => 13 00 00
> >    0.095318	Path: UPS.Output.Overload, Type: Feature, ReportID:
> > 0x13, Offset: 8, Size: 1, Value: 0
>
> At this stage, its so much bigger than the load as its just the pi and
> interface logic on it, nothing else. Under 10 watts for sure.
>
> I should for safety's sake rig an advisory circuit from one of the
> motor supplies, to exert an e-stop signal on a power failure, else
> when power comes back it will start moving motors, without knowing
> where they are since theres no real hardware based position feedback
> in stepper driven machinery. Might see if the vfd has a power fail
> alarm, its pretty smart. Nothing is ever done until the paper is
> completed.
>
> Cheers, Gene Heskett
Now I've got another of those WTF questions. This ups doesn't ID itself 
the same to an lsusb as it does to upsc.
From an lsusb:
Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
From a upsc:
device.mfr: CPS
device.model: CP625HGa

????

And while its not your problem, its keyboard and mouse goes away at 
random intervals, and isn't rediscovered by unplugging and replugging 
the hub the dongles are plugged into requireing a powerdown reboot, but 
the reboot isn't needed for an ssh -Y login!  Its the local usb that 
failing? Still scratching head on this, but first move that hubs wall 
wart to the ups. It doesn't need it to run, but...
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

On Jan 21, 2020, at 7:50 AM, Gene Heskett <gheskett at shentel.net>
wrote:
> 
> Now I've got another of those WTF questions. This ups doesn't ID
itself
> the same to an lsusb as it does to upsc.
> From an lsusb:
> Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
The two IDs are vendor (VID) and product (PID). lsusb looks them up in a text
file, typically /usr/share/misc/usb.ids, and concatenates the vendor and product
strings in the short output format that you quoted.

NUT reports those hex numbers as ups.vendorid and ups.productid, respectively,
but doesn't look them up in usb.ids.

> From a upsc:
> device.mfr: CPS
> device.model: CP625HGa
> 
These strings are retrieved from the UPS itself. If you run "lsusb -v -d
0764:0501" as root, you should see output similar to what I got from an
APC:

$ sudo lsusb -v -d 051d:
Bus 006 Device 002: ID 051d:0003 American Power Conversion UPS
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x051d American Power Conversion
  idProduct          0x0003 UPS
  bcdDevice            1.06
  iManufacturer           1 American Power Conversion 
  iProduct                2 Smart-UPS C 1000 FW:UPS 10.0 / ID=1005
...

The strings to the right of iManufacturer and iProduct are what the usbhid-ups
driver returns under device.mfr and device.model. (Sometimes device.model is
trimmed down, as is the case for APC firmware strings.)

lsusb won't show the strings if you don't run it as root, since it needs
privileges to send the request to retrieve the strings. Since NUT drivers need
read/write access to USB devices anyway, the NUT USB code retrieves the full
strings.

On Tuesday 21 January 2020 19:52:01 Charles Lepple wrote:
> sudo lsusb -v -d 0764:0501
copious output, containing this:
  idVendor           0x0764 Cyber Power System, Inc.
  idProduct          0x0501 CP1500 AVR UPS
  bcdDevice            0.01
  iManufacturer           3 CPS
  iProduct                1 CP625HGa

I take it that this is evidence they don't follow the spec to the letter.

Here I get the same output with, or w/o the leading sudo.

Thank you.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>