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]

pollonly is a setting for some drivers like usbhid-ups, uses a different way to get info and makes some other choices in logical codepath.

[masterwishx]

Oh its a flag ,checking ...

[aquette]

Still puzzled by this.
The failing get string iMfr iProduct... are the point. The strings descriptor should be inspected, lsusb -vvv... will help.
We should also have usb_debug set automatically with -D 5 or 6, to see libusb details

Pollonly won't solve, it's just for using the interrupt channel (like traps in SNMP) and not the control channel

Have you tried other USB cable and ports

[masterwishx]

pollonly is a setting for some drivers like usbhid-ups, uses a different way to get info and makes some other choices in logical codepath.

i should add pollonly=true ?

Have you tried other USB cable and ports

Yes ,only another usb port when server was shutdown.

[masterwishx]

The strings descriptor should be inspected, lsusb -vvv... will help.

i was tested both and sended already please check above ...
lsusb -vvv shows all the info correct

[masterwishx]

@aquette #1925 (comment)

[masterwishx]

When running. A server reboot is sort of equivalent (at least on Linux software side, not sure if UPS chip does something special to process a plug/unplug event) but too heavy-weight :) ...and looking at only the reboot as a "re-plug" may obscure if something happens (runs, etc.) AFTER the system restart that complicates seeing the UPS or USB devices in general.

i will try replug to usb3 when nut is running ...

[masterwishx]

The thing is all working fine exclude unknown (device and model) and no serial ,
if we will not find how to fix it maybe i can use :
default.,override. to change those values ...

[masterwishx]

Pollonly won't solve, it's just for using the interrupt channel (like traps in SNMP) and not the control channel

its becose of connection timeout when runed ""/usr/bin/usbhid-ups -x explore -DDDDDD -s test -x port=auto -x vendorid=0463 -u root""
#1925 (comment)

[masterwishx]

@aquette can it be USB cable problem if all info shown on USB bus ?

[aquette]

@masterwishx I would say no, but these limited I/O errors are puzzling!
I see that it's using the libusb 1.0 mode, that I've never really tried (I developed this driver with 0.1). Worth trying with the 0.1 to see if it's a bug from this. And I'd need a bit of time (I'm really lacking) and a PC (I'm always on my phone to reply), to dig the log. Sorry for the lag and sub-optimal help

[aquette]

I'd need the kernel / libusb verbose info (from /var/log/messages for ex.) Around that nut_libusb_open / get_string
Considering the various info you provided (thx btw!), I tend to think that this is a usbhid-ups bug with 1.0...
Maybe the export USB_DEBUG... works with libusb 1.0

[masterwishx]

Worth trying with the 0.1 to see if it's a bug from this

I was started with v2.7.4 with 0.1 that has same unknown device, only then I moved to 2.8 with 1.0 to try but having same unknown, and staying on it now.

[masterwishx]

now im on 2.8.0.1 ,same here ...

[masterwishx]

Network UPS Tools (NUT) for UNRAID with NUT v 2.8.1 , still same ....

[jimklimov]

Did you have a chance to follow up with Arnaud's suggestions (dmesg dumps near plugging events, trying libusb debug envvars in the driver environment, etc.)?

Also you mentioned that apcd or apcupsd worked for you? Can you please double-check if it still does (or we have some lower-level, maybe hardware, issue)?

[masterwishx]

Did you have a chance to follow up with Arnaud's suggestions (dmesg dumps near plugging events, trying libusb debug envvars in the driver environment, etc.

Sorry, not sure what do you mean? if you can to explane i will try to check

Also you mentioned that apcd or apcupsd worked for you? Can you please double-check if it still does (or we have some lower-level, maybe hardware, issue)?

Yes , befor NUT i checked Unraid native UPS ( APC UPS daemon) and it was worked with all data in it.

Now Unraid NUT Plugin develops by other user and he added some new staff , also new 2.8.1 version (older versions also avalible )

Also the problem is only that (unknown 2000 for device.model,ups.model and no serial number is shown) but all working Fine at all.

[loso2255]

i have a similar problem but works different for me.
little explenation:

i have installed nut server on my rasberry pi 4 with debian 11 (bullseye) so nut server version is 2.7.4 .
the ups attached are eaton 9e3000i and APC back-ups 1400, and works, but some time the connection between my APC back-ups 1400 drop with "driver is stale" i think is usb related because i need to reboot the entire rasberry pi 4.
i switch the port from a usb 2.0 to 3.0 and work fine at the moment.

now the fun part,
i switch my rasberry pi 4 to debian 12 (bookworm) so nut server version is 2.8.0
and now the nut-scanner not showing any info about both UPS.
the nut-scanner find There are 2 ups but no info about it,
and consequently I can't connect them to the nut server

any idea?

[masterwishx]

i have a similar problem but works different for me. little explenation:

i have installed nut server on my rasberry pi 4 with debian 11 (bullseye) so nut server version is 2.7.4 . the ups attached are eaton 9e3000i and APC back-ups 1400, and works, but some time the connection between my APC back-ups 1400 drop with "driver is stale" i think is usb related because i need to reboot the entire rasberry pi 4. i switch the port from a usb 2.0 to 3.0 and work fine at the moment.

now the fun part, i switch my rasberry pi 4 to debian 12 (bookworm) so nut server version is 2.8.0 and now the nut-scanner not showing any info about both UPS. the nut-scanner find There are 2 ups but no info about it, and consequently I can't connect them to the nut server

any idea?

Not sure this same issue, I have no problems with connections or other, the only thing it's shown as "unknown 2000" on upsc but in usb driver all info avaliable...
But at all working fine

Do you have also "unknown 3000" in upsc?

[loso2255]

update

APC back-ups 1400 work

and this is the output from nut-scanner -U for the second UPS

[nutdev2]
driver = "usbhid-ups"
port = "auto"
vendorid = "vendorid"
productid = "FFFF"
bus = "001"

i dont't have any model or serial displayed

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