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]

Let me know if you me to check stuff on Unraid side.

Sure, will be great. @jimklimov this is the current nut plugin Developer @SimonFair for Unraid

[jimklimov]

Well, the main issue here is to dig down why won't that build of libusb (allegedly a recent 1.0.26) not return the basics on that system, and why not for some other devices. From what I read, the kernel corresponds to unRaid 6.11.x (current is 6.12.2, and the 6.12.x line is weeks old - so 6.11.x is pretty recent), and the system is based on Slackware Linux with kernel modifications.

FWIW I tried locally a "what if" scenario - I try to start a NUT driver against a device which is already monitored by another: its basic data is seen "as is" (from the OS, I previously supposed - but this ticket uproots my beliefs a bit, since lsusb and friends on OP's system report the data successfully); access errors happen later:

# NUT_STATEPATH=/tmp  ~abuild/nut//drivers/usbhid-ups -x explore -DDDDDD -s test -x port=auto -x vendorid=0463 -u root
Network UPS Tools - Generic HID driver 0.49 (2.8.0-2208-g05b7ec52c)
USB communication driver (libusb 1.0) 0.45
   0.000001     [D3] main_arg: var='port' val='auto'
   0.000011     [D6] testinfo_reloadable: var=port, infoname=driver.parameter.port, newval=auto, reloadable=0, reload_flag=0
   0.000017     [D6] testinfo_reloadable: verdict for (re)loading var=port value: 1
   0.000022     [D5] send_to_all: SETINFO driver.parameter.port "auto"
   0.000026     [D3] main_arg: var='vendorid' val='0463'
   0.000032     [D5] send_to_all: SETINFO driver.parameter.vendorid "0463"
   0.000055     [D1] Built-in default or configured user for drivers 'nobody' was ignored due to 'root' specified on command line
   0.000078     [D1] Network UPS Tools version 2.8.0-2208-g05b7ec52c (release/snapshot of 2.8.0.1) built with gcc (Debian 10.2.1-6) 10.2.1 20210110 and configured with flags: --enable-Wcolor --enable-keep_nut_report_feature --with-all=auto --with-cgi=auto --with-serial=auto --with-dev=auto --with-doc=skip --with-nut_monitor=auto --with-pynut=auto --disable-force-nut-version-header --enable-check-NIT --enable-maintainer-mode --disable-silent-rules
   0.000090     [D1] debug level is '6'
   0.000094     [D5] send_to_all: SETINFO driver.debug "6"
   0.000099     [D5] send_to_all: SETFLAGS driver.debug RW NUMBER
   0.000504     [D1] Succeeded to become_user(root): now UID=0 GID=0
   0.000520     [D5] send_to_all: SETINFO device.type "ups"
   0.000525     [D5] send_to_all: SETINFO driver.state "init.device"
   0.000529     [D2] Initializing an USB-connected UPS with library libusb-1.0.24 (API: 0x1000108) (NUT subdriver name='USB communication driver (libusb 1.0)' ver='0.45')
...
   0.069159     [D2] Checking device 5 of 9 (0463/FFFF)
   0.492250     [D2] - VendorID: 0463
   0.492266     [D2] - ProductID: ffff
   0.492273     [D2] - Manufacturer: EATON
   0.492279     [D2] - Product: Ellipse ECO
   0.492285     [D2] - Serial Number: 000000000
   0.492288     [D2] - Bus: 003
   0.492291     [D2] - Device: 005
   0.492299     [D2] - Device release number: 0100
   0.492307     [D2] Trying to match device
   0.492312     [D2] match_function_subdriver (non-SHUT mode): matching a device...
   0.492319     [D3] match_function_regex: matching a device...
   0.492334     [D2] Device matches
   0.492339     [D2] Reading first configuration descriptor
   0.492357     [D3] libusb_kernel_driver_active() returned 0: Success
   0.492365     [D2] failed to claim USB device: Resource busy
   0.492375     [D2] Kernel driver already detached
   0.492382     [D2] failed to claim USB device: Resource busy
   0.492387     [D2] Kernel driver already detached
   0.492390     [D2] failed to claim USB device: Resource busy
   0.492394     [D2] Kernel driver already detached
   0.492398     [D2] failed to claim USB device: Resource busy
   0.492401     [D2] Kernel driver already detached
   0.492407     Can't claim USB device [0463:ffff]@0/0: Entity not found

A similar local attempt from an account without too many OS permissions fails with that explicitly:

$ NUT_STATEPATH=/tmp ./drivers/usbhid-ups -x explore -DDDDDD -s test -x port=auto -x vendorid=ffff
Network UPS Tools - Generic HID driver 0.49 (2.8.0-2208-g05b7ec52c)
USB communication driver (libusb 1.0) 0.45
   0.000000     [D3] main_arg: var='port' val='auto'
   0.000014     [D6] testinfo_reloadable: var=port, infoname=driver.parameter.port, newval=auto, reloadable=0, reload_flag=0
   0.000018     [D6] testinfo_reloadable: verdict for (re)loading var=port value: 1
   0.000031     [D5] send_to_all: SETINFO driver.parameter.port "auto"
   0.000038     [D3] main_arg: var='vendorid' val='ffff'
   0.000046     [D5] send_to_all: SETINFO driver.parameter.vendorid "ffff"
   0.000053     [D1] Network UPS Tools version 2.8.0-2208-g05b7ec52c (release/snapshot of 2.8.0.1) built with gcc (Debian 10.2.1-6) 10.2.1 20210110 and configured with flags: --enable-Wcolor --enable-keep_nut_report_feature --with-all=auto --with-cgi=auto --with-serial=auto --with-dev=auto --with-doc=skip --with-nut_monitor=auto --with-pynut=auto --disable-force-nut-version-header --enable-check-NIT --enable-maintainer-mode --disable-silent-rules
   0.000065     [D1] debug level is '6'
   0.000072     [D5] send_to_all: SETINFO driver.debug "6"
   0.000079     [D5] send_to_all: SETFLAGS driver.debug RW NUMBER
   0.000245     [D1] Can not become_user(nobody): not root initially, remaining UID=399 GID=399
   0.000264     [D5] send_to_all: SETINFO device.type "ups"
   0.000271     [D5] send_to_all: SETINFO driver.state "init.device"
   0.000278     [D2] Initializing an USB-connected UPS with library libusb-1.0.24 (API: 0x1000108) (NUT subdriver name='USB communication driver (libusb 1.0)' ver='0.45')
   0.000285     [D1] upsdrv_initups (non-SHUT)...
   0.003144     [D2] Checking device 1 of 9 (1D6B/0003)
   0.003171     [D1] Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions)
   0.003178     [D2] Checking device 2 of 9 (03F0/0D4A)
   0.003190     [D1] Failed to open device (03F0/0D4A), skipping: Access denied (insufficient permissions)
   0.003196     [D2] Checking device 3 of 9 (1D6B/0002)
   0.003207     [D1] Failed to open device (1D6B/0002), skipping: Access denied (insufficient permissions)
   0.003213     [D2] Checking device 4 of 9 (1D6B/0003)
   0.003223     [D1] Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions)
   0.003230     [D2] Checking device 5 of 9 (0463/FFFF)
   0.003242     [D1] Failed to open device (0463/FFFF), skipping: Access denied (insufficient permissions)
   0.003246     [D2] Checking device 6 of 9 (1D6B/0002)
   0.003257     [D1] Failed to open device (1D6B/0002), skipping: Access denied (insufficient permissions)
   0.003263     [D2] Checking device 7 of 9 (1D6B/0003)
   0.003275     [D1] Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions)
   0.003282     [D2] Checking device 8 of 9 (048D/5702)
   0.003292     [D1] Failed to open device (048D/5702), skipping: Access denied (insufficient permissions)
   0.003295     [D2] Checking device 9 of 9 (1D6B/0002)
   0.003301     [D1] Failed to open device (1D6B/0002), skipping: Access denied (insufficient permissions)
   0.003306     [D2] libusb1: No appropriate HID device found
   0.003310     libusb1: Could not open any HID devices: insufficient permissions on everything
   0.003314     No matching HID UPS found

[masterwishx]

if you mean to run command when nut already running ,im having also unknown and errors at end :

also checked file from above ,when i runned command when nut is stopped :

[masterwishx]

this is also from ( 'usbhid-ups -DDDDD -s test -d2 -x port=auto -u root 2>&1 | tee -a /mnt/user/DiskNas/usbhid-ups.txt') file from above:

[jimklimov]

One wild idea, following up from a post in another issue: did you try physically re-plugging the UPS during the investigation, so the OS would reinitialize relevant structures?

[masterwishx]

Yes , only yesterday i tried another port (USB3) but having same unknown , so i moved back to USB2 ... also author of unraid plugin cant find why its happen , and he asked me to run : "/usr/bin/usbhid-ups -x explore -DDDDDD -s test -x port=auto -x vendorid=0463 -u root"

i runned but at end having : nut_libusb_get_interrupt: Connection timed out 16.881244 [D1] Got 0 HID objects... 16.881250 [D1] Quick update... 18.132278 [D1] upsdrv_updateinfo... 18.882508 [D2] nut_libusb_get_interrupt: Connection timed out

usbhid-ups2.txt

i will try run it again .... to check if will be again "Connection timed out"

The thing is all working fine , excluding those unknown parameters

[masterwishx]

DO you mean replug USB when nut plugin is running or when server is shutdown ?

[jimklimov]

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.

[jimklimov]

Also wondering if using "pollonly" would change something. On one hand, there would be no more timed-out waits for interrupts; but maybe any other effects?..

[masterwishx]

OK i will try . pollonly ?

[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 https://github.com/networkupstools/nut/issues/1925#issuecomment-1562342854

[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"" https://github.com/networkupstools/nut/issues/1925#issuecomment-1630287143

[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 : https://github.com/networkupstools/nut/issues/1925#issuecomment-1528986250

[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: https://github.com/networkupstools/nut/issues/2492#issuecomment-2191108335