Eaton 9E2000I unknown device and ups model

[masterwishx]

Using Unraid apcd working fine , but tryed plugin -NUT - Network UPS Tools by SimonFair . and having some valus unknow like model and device and missing serial number ...

[masterwishx]

https://github.com/SimonFair/NUT-unRAID/

[jimklimov]

Looking at that repo, "3 weeks ago" they added commits for a nut-2.8.0 bump, and https://github.com/SimonFair/NUT-unRAID/blob/master/packages/nut-2.8.0-x86_64-1.txz which contains files time-stamped 2022-04-30 (so same week as NUT 2.8.0 release). Your screenshots indicate a much older 2.7.4 NUT baseline. Wondering if an update can provide a quick fix, or if something remains to solve in the core.

Also, looking at integration changes like https://github.com/dmacias72/NUT-unRAID/pull/1/files I suppose there is a lot of unRAID-specific voodoo that is maintained outside of NUT and without cross-coordination as the two evolve (which could be welcome). In NUT, each driver and sub-driver has a lot of changes over time and is responsible for the info it publishes - doing this job well or poorly is another matter, to solve in NUT. External projects are sort of expected to use NUT-provided data "as is", or if they know there's a specific issue to solve - to update NUT and have good inputs this way. Changes like that PR do make sense technically, but I'm afraid can sum up to something less maintainable over time.

[jimklimov]

BTW, did apcd report anything about this device, that you don't see with NUT - e.g. the serial number? It may well be that the device does not serve it, or serves a useless value like a dozen of zeroes.

The device.model: unknown 2000 suggests to me that in fact the driver did get some string from libusb which talks to the actual device, so either some info got lost along the way or the device firmware was not sure what to say (the same firmware builds may be applied to different hardware, so maybe that box could not be identified by its controller for whatever reason).

[jimklimov]

CC @aquette @dzomaya : any ideas here? :)

[masterwishx]

that you don't see with NUT - e.g. the serial number

Yes it was show all data also serial number. But here no serial number and ups.productid=ffff

This is my first expirience of UPS so I'm little confused, I was thinking will be opposite, that apcd was not sure, but it found device and show all info.

[masterwishx]

they added commits for a nut-2.8.0 bump

i will check it,Thanks

[masterwishx]

Checked nut 2.80 ,but still unknown

[jimklimov]

Product ID may be ffff validly, if that's what the vendor put into the chip. I don't see Vendor ID in your screenshots (should be 0x0463). Some vendors put bogus values into the latter (0000, 0001, FFFF) which indeed do not help discern expected supported protocols etc. for those devices.

I can only guess that this device serves its serial number (and possibly correct name) on different USB report identifiers than its siblings... the mapping in NUT can be updated, but gotta figure out to what.

Are you in position to run NUT from command line on that system? (Or attach the UPS to another system temporarily for debugging?)

[masterwishx]

@jimklimov do you mean if I can run command line in Unraid? Sure I can. Or you mean install nut from command line? it's more complicated becose after reboot it's gone, so there is plugins that installs every boot, but it's possible in also in script I think.

I can switch back to apcd and get all info needed. I also have slave machine I need to connect, Main pc with Win11.

[masterwishx]

So I can connect to Main pc with Win11 if need, or just get all data from apcd in Unraid?

[jimklimov]

I think all the bits of info would help, and also an attempt to start the driver with higher debug verbosity -DDDDDD on command line, which should print out many "Path" lines from basic USB report descriptors that it finds. From those we can try to estimate IDs that are missing in current driver.

If it is possible to try building NUT from source to the extent of trying to make an usb-hid subdriver (see docs directory in github), that would even parse such findings into C mapping tables that we can merge with existing subdriver.

[masterwishx]

@jimklimov This is from default UPS in Unraid APCUPSD: Also found that remain time is more acurate here

if serial is needed i can send you in pm ...

[masterwishx]

Also much less details here ...

[masterwishx]

@jimklimov tryed to launch in command line in Unraid but having some errors, maybe you can help with this, if will not succeed with command line will try maybe build and connect in VM if possible...

[jimklimov]

FYI: I'll be mostly offline till mid-May. Good luck on your quest!

On Fri, Apr 28, 2023, 11:19 DaRK AnGeL @.***> wrote:

@jimklimov https://github.com/jimklimov tryed to launch in command line in Unraid but having some errors, maybe you can help with this, if will not succeed with command line will try maybe build and connect in VM if possible...

— Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/1925#issuecomment-1527252848, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFEY4O2DBTATHBWHA7TXDODSZANCNFSM6AAAAAAXIRS3LM . You are receiving this because you were mentioned.Message ID: @.***>

[masterwishx]

At all it's working fine, the only problem it's shows unknown 2000 ups.model,device.model and no serial number...

[aquette]

Hey I assume it's usbhid-ups which, as noted by Jim, can't retrieve all strings. Could you share a debug log of the driver? Using something like this should do it usbhid-ups -DDDDD -s test -d2

Also, an lsusb -vv as root could help

[masterwishx]

usbhid-ups -DDDDD -s test -d2

Sure I can, I will try...

[masterwishx]

runned 'lsusb -vv' it shows all info also serial number !

Bus 003 Device 002: ID 0463:ffff MGE UPS Systems UPS
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0463 MGE UPS Systems
  idProduct          0xffff UPS
  bcdDevice            2.02
  iManufacturer           1 EATON
  iProduct                2 Eaton 9E
  iSerial                 4 Gxxxxxxxxxx7  ( hiden by me can send in pm if needed)
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               20mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength    1014
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              20
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

[masterwishx]

@aquette is it enough ?

[aquette]

I also need the output of usbhid-ups, to see what's wrong

[masterwishx]

also need the output of usbhid-ups, to see what's wrong

Ah OK, it should be run when nut is running? I tryed but having some errors..

[aquette]

First, stop the real driver, then launch the above command as root

[masterwishx]

@aquette tryed 'usbhid-ups -DDDDD -s test -d2 -x port=auto -u root 2>&1 | tee -a /mnt/user/DiskNas/usbhid-ups.txt' usbhid-ups.txt lsusb.txt

[masterwishx]

@jimklimov @aquette please check the files above .... let me know if this is enough ?

[masterwishx]

@jimklimov @aquette did you had time to check files maybe ?

[masterwishx]

@jimklimov @aquette is any news maybe ?

[jimklimov]

Sorry about the delay. The reports do indeed look puzzling a bit: while lsusb seems to say a lot (including the device iProduct and iSerial fields), the driver does not see them from get-go:

   0.289960	[D2] Checking device 8 of 9 (0463/FFFF)
   0.311147	[D1] nut_libusb_open get iManufacturer failed, retrying...
   0.332348	[D1] nut_libusb_open get iManufacturer failed, retrying...
   0.353600	[D1] nut_libusb_open get iManufacturer failed, retrying...
   0.374780	[D1] nut_libusb_open get iProduct failed, retrying...
   0.395962	[D1] nut_libusb_open get iProduct failed, retrying...
   0.417222	[D1] nut_libusb_open get iProduct failed, retrying...
   0.438631	[D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.460000	[D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.481267	[D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.481286	[D2] - VendorID: 0463
   0.481291	[D2] - ProductID: ffff
   0.481296	[D2] - Manufacturer: unknown
   0.481301	[D2] - Product: unknown
   0.481306	[D2] - Serial Number: unknown
   0.481311	[D2] - Bus: 003
   0.481316	[D2] - Device: unknown
   0.481321	[D2] - Device release number: 0202
   0.481344	[D2] Trying to match device

which I am not sure why happens. But maybe it is this "unknown" string that leaks into the dstate collection about the device:

   4.052224	[D1] Path: UPS.Flow.[4].ConfigApparentPower, Type: Feature, ReportID: 0x74, Offset: 16, Size: 16, Value: 2000
...
   5.509746	[D2] get_model_name(unknown, 2000)
   5.509752	[D2] comparing with: ellipse 300
...
   5.510187	[D5] send_to_all: SETINFO ups.mfr "Eaton"
   5.510194	[D5] send_to_all: SETINFO ups.model "unknown 2000"
   5.510202	[D5] send_to_all: SETINFO ups.vendorid "0463"
   5.510209	[D5] send_to_all: SETINFO ups.productid "ffff"
   5.510214	[D2] Report descriptor retrieved (Reportlen = 2053)
   5.510219	[D2] Found HID device
   5.510227	[D1] Detected a UPS: unknown/unknown 2000
...
   6.669136	[D5] send_to_all: SETINFO device.mfr "Eaton"
   6.669144	[D5] send_to_all: SETINFO device.model "unknown 2000"

UPDATE: yep, the method is unique to mge-hid.c and all the implicated logic is here:

• https://github.com/networkupstools/nut/blob/3a8deafcac9fbb755e3e9ec0cee2c13ca5dca39a/drivers/mge-hid.c#L1545-L1558

So the problem is very likely due to that original "libusb can't get the details", which may be a permissions problem or the device being busy due to someone else grabbing it with higher priority (hypervisor, OS drivers and daemons, etc.)

[jimklimov]

Just in case: are the udev.rules (or udev.hwdb) issues ruled out? Does the OS know to not grab certain VID:PID pairs and/or to re-own them to nut:nut or similar accounts?

[masterwishx]

Just in case: are the udev.rules (or udev.hwdb) issues ruled out? Does the OS know to not grab certain VID:PID pairs and/or to re-own them to nut:nut or similar accounts?

Thanks a lot for answer. about label you gave , im running and tested on v2.8.0 not v2.7.4 in unraid .

from usbhid-ups.txt:

So the problem is very likely due to that original "libusb can't get the details", which may be a permissions problem or the device being busy due to someone else grabbing it with higher priority (hypervisor, OS drivers and daemons, etc.)

The strange thing i can see all info when running ' lsusb -vv ' :

Just in case: are the udev.rules (or udev.hwdb) issues ruled out? Does the OS know to not grab certain VID:PID pairs and/or to re-own them to nut:nut or similar accounts?

i will try to check or will ask developer of plugin for Unraid ...