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 <#1925 (comment)>, 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]

@loso2255 : Does it literally say vendorid = "vendorid" and not the numbers (likely vendorid = "0463")?

[loso2255]

@loso2255 : Does it literally say vendorid = "vendorid" and not the numbers (likely vendorid = "0463")?

no no it's the eaton vendor id it say: vendorid = "0463"
i put vendorid before send it to internet XD

this is the full output
[nutdev2]
driver = "usbhid-ups"
port = "auto"
vendorid = "0463"
productid = "FFFF"
bus = "001"

[masterwishx]

i dont't have any model or serial displayed

do you have blank for ups model and ups device ? not "unknown 3000" ?
if you run " upsc 'name' "

also no serial displayed , but all info available if i run "lsusb -vvv" check the posts above : #1925 (comment)

[masterwishx]

Still same issue on 2.8.2

[masterwishx]

i have a similar problem but works different for me.

Do you also have unknown 3000 for device.model and ups.model ?

[jimklimov]

@masterwishx : following the fruitful discussion in libusb tracker (thanks for starting), can you please search NUT docs/sources about "(no)langid(fix)" - I remembered there are some keywords about some such concept(s?), but during travels can't easily check what it was about. Maybe NUT already has a fix about this situation already?

[tormodvolden]

Indeed blazer_usb.c and nutdrv_qx.c makes use of "langid_fix" and "noscanlangid" options. Maybe those are not needed if #2604 works around their issues in a more general manner.

Note some devices actually need a specific langid_fix that is not en_US (0x0409), see data/driver.list.in

[masterwishx]

@jimklimov @tormodvolden
Interested if other (more from (mge-hid) usbhid) values can be added after fix for libusb? Like ECO and other...
As they avaliable in udbhid debug list:
#2492 (comment)