drivers/mge-hid.c, NEWS.adoc: try to recognize Eaton 9E model and info #2562

jimklimov · 2024-07-28T16:16:39Z

Also handle "unknown 2000" assuming it is a mis-read "Eaton 9E 2000(i?)" which refused to tell libusb its vendor/product/serial strings. Although note that if we were not able to read basic identification data, chances of really interacting with the device are... sketchy.

This may be the answer to such issues as #1925, #2380 (re-opened), #2492

To recap, reported issues were (at least):

"unknown 2000" as the device.model and ups.model
missing serial number info
...which may be due to inability to get identification data from nut_libusb_open(), even when NUT runs as root (but maybe is somehow restricted being in a container?)
...which is discovered by lsusb on the same box, by udevadm info, and by apcupsd it seems
battery.type is present but has no value
not sure if it is only seen on Unraid?
not getting battery.voltage per usbhid-ups: Eaton battery.voltage value is missing #2380 (comment) and usbhid-ups: Eaton battery.voltage value is missing #2380 (comment) (originally discussed for 5P/5S series)

The PR is more or less a guess-work based on earlier comments from @arnaudquette-eaton in those issue discussions.

CC @masterwishx @loso2255 @lemeshovich : would you be able to try a custom build of NUT following https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests to see if it handles the devices better? A couple of things I'd be interested in is if it can recognize the device properly (as "9E2000" or "9E2000i", not "9E2000 (presumed)"), and if it serves the battery.voltage (current and nominal).

For the git checkout, use this PR's source branch:

:; git clone https://github.com/jimklimov/nut -b usb-eaton-ids nut
:; cd nut
...

networkupstools#1925] Also handle "unknown 2000" assuming it is a mis-read "Eaton 9E 2000(i?)" which refused to tell libusb its vendor/product/serial strings. This may be the answer to such issues as networkupstools#1925, networkupstools#2380 (re-opened), networkupstools#2492 Signed-off-by: Jim Klimov <[email protected]>

masterwishx · 2024-07-28T19:41:06Z

I will try, not shure how to use it in Unraid maybe @desertwitch can help with it.
But will check it, Also Unraid 7 beta1 use newver version of libusb than using now 6.12.11.

jimklimov · 2024-07-29T07:37:43Z

Converting to draft while this is being tested, so NUT CI won't rebuild it in vain against newer target branch as it evolves.

masterwishx · 2024-07-30T07:10:49Z

@jimklimov i tryed compile for Unraid plugin (slackware) but missed some config file for the plugin but @desertwitch the current plugin maintainer was kindly say he can compile for me the test package , so waiting :)

desertwitch · 2024-07-31T12:10:21Z

Thanks Jim!
I compiled a package for @masterwishx (and it's looking positive), they said they'll report back here with their findings.

masterwishx · 2024-07-31T12:17:08Z

@jimklimov Thanks a lot for your PR ,also Thanks a lot for @desertwitch for kindly compiled for me the package for his plugin.

So i can see now :
9E2000 (presumed) for device.model and ups.model , but i have 9E2000i
Also battery.voltage = 83.0 and battery.voltage.nominal = 72 now available but not serial number

masterwishx · 2024-07-31T12:28:23Z

in case needs test output:

battery.capacity: 7.00
battery.charge: 100
battery.charge.low: 20
battery.charge.restart: 0
battery.protection: yes
battery.runtime: 3389
battery.runtime.low: 180
battery.type: 
battery.voltage: 83.0
battery.voltage.nominal: 72
device.mfr: Eaton
device.model: 9E2000 (presumed)
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.2.1
driver.version.data: MGE HID 1.48
driver.version.internal: 0.55
driver.version.usb: libusb-1.0.26 (API: 0x1000108)
input.bypass.frequency: 50.0
input.bypass.voltage: 232.0
input.frequency: 50.0
input.frequency.nominal: 50
input.transfer.high: 300
input.transfer.low: 100
input.voltage: 232.0
input.voltage.nominal: 232
outlet.1.status: on
outlet.desc: Main Outlet
outlet.id: 0
outlet.switchable: no
output.current: 1.70
output.frequency: 50.0
output.frequency.nominal: 50
output.voltage: 229.0
output.voltage.nominal: 230
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 
ups.load: 21
ups.load.high: 105
ups.mfr: Eaton
ups.model: 9E2000 (presumed)
ups.power: 423
ups.power.nominal: 2000
ups.productid: ffff
ups.realpower: 298
ups.realpower.nominal: 1600
ups.shutdown: enabled
ups.start.auto: yes
ups.start.battery: yes
ups.start.reboot: yes
ups.status: OL
ups.temperature: 24.9
ups.test.interval: 604800
ups.test.result: Done and passed
ups.timer.shutdown: -1
ups.timer.start: -1
ups.type: online
ups.vendorid: 0463

masterwishx · 2024-07-31T12:38:17Z

if i understood right it still not recognized good as 9E2000 (presumed) ? btw not sure if related but Unraid 7 beta2 use newer version of libusb

masterwishx · 2024-07-31T14:50:22Z

Also found battery.type = blank still blank instead of PbAc

jimklimov · 2024-07-31T15:31:14Z

And thanks back for the reports! I'll update the "9E2000" vs. "9E2000i" part, but the "presumed" is what is critical there - libusb and NUT were not able to see the actual model name as per original reports' analysis, assigned "unknown" into that string, and "2000" into the other (seemingly from ConfigApparentPower, which is in your usbhid-ups.txt log), as seen at

nut/drivers/mge-hid.c

Lines 1584 to 1609 in 4cd226a

    
           static const char *mge_format_model(HIDDevice_t *hd) { 
        
           	char	product[SMALLBUF]; 
        
           	char	model[SMALLBUF]; 
        
           	double	value; 
        
           	/* Dell has already a fully formatted name in iProduct */ 
        
           	if (hd->VendorID == DELL_VENDORID) { 
        
           		return hd->Product; 
        
           	} 
        
           	/* Get iProduct and iModel strings */ 
        
           	snprintf(product, sizeof(product), "%s", hd->Product ? hd->Product : "unknown"); 
        
           	HIDGetItemString(udev, "UPS.PowerSummary.iModel", model, sizeof(model), mge_utab); 
        
           	/* Fallback to ConfigApparentPower */ 
        
           	if ((strlen(model) < 1) && (HIDGetItemValue(udev, "UPS.Flow.[4].ConfigApparentPower", &value, mge_utab) == 1 )) { 
        
           		snprintf(model, sizeof(model), "%i", (int)value); 
        
           	} 
        
           	if (strlen(model) > 0) { 
        
           		free(hd->Product); 
        
           		hd->Product = get_model_name(product, model); 
        
           	} 
        
           	return hd->Product;

Eaton 9E2000I unknown device and ups model #1925 (comment) => https://github.com/networkupstools/nut/files/11561663/usbhid-ups.txt

   4.052224	[D1] Path: UPS.Flow.[4].ConfigApparentPower, Type: Feature, ReportID: 0x74, Offset: 16, Size: 16, Value: 2000

And then my PR changes that discovery into the pretty name of "9E2000 (presumed)" at

nut/drivers/mge-hid.c

Line 1155 in 4cd226a

    
           { "unknown",  "2000",  EATON_9E, "9E2000 (presumed)" },	/* https://github.com/networkupstools/nut/issues/1925#issuecomment-1609262963 */

So the root-cause problem is still there, this part from the older log:

   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
   0.481350	[D2] match_function_subdriver (non-SHUT mode): matching a device...
   0.481358	[D3] match_function_regex: matching a device...
   0.481364	[D2] Device matches

As you noted time and again, lsusb does see the identifying information, per https://github.com/networkupstools/nut/files/11561823/lsusb.txt (although with a little hiccup at the start - can it be related to ours?):

can't get debug descriptor: Resource temporarily unavailable

...
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 GE...

masterwishx · 2024-07-31T15:47:03Z

As you noted time and again, lsusb does see the identifying information, per https://github.com/networkupstools/nut/files/11561823/lsusb.txt (although with a little hiccup at the start - can it be related to ours?):

Yes, that is what i got back then i can run thouse commands again ? i think nothing changed but like i said befor libusb has newver version in Unraid 7 beat1 or i can maybe compile for my 6.11.12 ?

masterwishx · 2024-07-31T15:54:26Z

@jimklimov @desertwitch
i runned again lsusb -vvv and it show info :

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 GE0xxxx   hidden by me was included previosly
  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

jimklimov · 2024-07-31T15:58:39Z

Also battery.voltage = 83.0 and battery.voltage.nominal = 72 now available

So that seems like 6 batteries at 12V PbAc nominal, charged to 13.8V which sounds normal. At least the bit from #2380 (comment) is resolved by this change :)

I've posted the recap of original complaints in top of this ticket, are those all the missing data points or were there more?

jimklimov · 2024-07-31T16:07:39Z

I've also noted that our earlier exchanges about the udev implications did not mention "packaged" locations under /usr like:

/usr/lib/udev/rules.d/52-nut-ipmipsu.rules
/usr/lib/udev/rules.d/62-nut-usbups.rules

Does your installation have those, and is 0463 listed there? e.g. on my box:

# grep 463 /usr/lib/udev/rules.d/62-nut-usbups.rules
ATTR{idVendor}=="0463", ATTR{idProduct}=="0001", MODE="664", GROUP="nut"
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664", GROUP="nut"

And I am still a bit unsure if all the reports from different users were from Unraid, or other systems too? Is container approach somehow implicated (e.g. should such udev rules appear in the host system or not?)

Also wondering if the distribution has "quirks" set up which for a long time included 0x0463 identifier (older models had certain communicative issues so much that they earned a place in a kernel table of several unrelated OS platforms), see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1875532 or https://forum.netgate.com/topic/183961/nut-package-2-8-1-and-above/3

Adding the kernel parameter usbhid.quirks=0x0463:0xffff:0x08 resolves the issue and was taken from this bug which was never addressed:
https://bugzilla.redhat.com/show_bug.cgi?id=1715504

masterwishx · 2024-07-31T16:10:09Z

Also battery.voltage = 83.0 and battery.voltage.nominal = 72 now available

So that seems like 6 batteries at 12V PbAc nominal, charged to 13.8V which sounds normal. At least the bit from #2380 (comment) is resolved by this change :)

I've posted the recap of original complaints in top of this ticket, are those all the missing data points or were there more?

Yes , 9E2000i have 6 batts x 12V PbAc nominal, charged to 13.8V ,so now it show right battery.voltage and battery.voltage.nominal that was missing befor.
battery.type is still blank instead PbAc

I think recap is OK , cant remember more at now .
just wonder maybe @desertwitch can say if newver version of libusb in Unraid 7 beta 2 can change something here or not ?

…ools#2562] I did not find any actual mentions of plain "9E2000" without an "i", only these: https://www.eaton.com/tr/en-gb/skuPage.9E2000I.html Also prepared for "9E3000i" models while here. Signed-off-by: Jim Klimov <[email protected]>

masterwishx · 2024-07-31T16:16:39Z

I've also noted that our earlier exchanges about the udev implications did not mention "packaged" locations under /usr like:
/usr/lib/udev/rules.d/52-nut-ipmipsu.rules
/usr/lib/udev/rules.d/62-nut-usbups.rules
Does your installation have those, and is 0463 listed there? e.g. on my box:
# grep 463 /usr/lib/udev/rules.d/62-nut-usbups.rules
ATTR{idVendor}=="0463", ATTR{idProduct}=="0001", MODE="664", GROUP="nut"
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664", GROUP="nut"
And I am still a bit unsure if all the reports from different users were from Unraid, or other systems too? Is container approach somehow implicated (e.g. should such udev rules appear in the host system or not?)

Also wondering if the distribution has "quirks" set up which for a long time included 0x0463 identifier (older models had certain communicative issues so much that they earned a place in a kernel table of several unrelated OS platforms), see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1875532 or https://forum.netgate.com/topic/183961/nut-package-2-8-1-and-above/3

Adding the kernel parameter usbhid.quirks=0x0463:0xffff:0x08 resolves the issue and was taken from this bug which was never addressed:
https://bugzilla.redhat.com/show_bug.cgi?id=1715504

i think @desertwitch as current plugin developer can say more for it?

i got : for #grep 463 /usr/lib/udev/rules.d/62-nut-usbups.rules

grep: /usr/lib/udev/rules.d/62-nut-usbups.rules: No such file or directory```

masterwishx · 2024-07-31T16:21:10Z

I've also noted that our earlier exchanges about the udev implications did not mention "packaged" locations under /usr like:
/usr/lib/udev/rules.d/52-nut-ipmipsu.rules
/usr/lib/udev/rules.d/62-nut-usbups.rules
Does your installation have those, and is 0463 listed there? e.g. on my box:
# grep 463 /usr/lib/udev/rules.d/62-nut-usbups.rules
ATTR{idVendor}=="0463", ATTR{idProduct}=="0001", MODE="664", GROUP="nut"
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664", GROUP="nut"
And I am still a bit unsure if all the reports from different users were from Unraid, or other systems too? Is container approach somehow implicated (e.g. should such udev rules appear in the host system or not?)

Also wondering if the distribution has "quirks" set up which for a long time included 0x0463 identifier (older models had certain communicative issues so much that they earned a place in a kernel table of several unrelated OS platforms), see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1875532 or https://forum.netgate.com/topic/183961/nut-package-2-8-1-and-above/3

Adding the kernel parameter usbhid.quirks=0x0463:0xffff:0x08 resolves the issue and was taken from this bug which was never addressed:
https://bugzilla.redhat.com/show_bug.cgi?id=1715504

OK i got for :

#grep 463 /lib/udev/rules.d/62-nut-usbups.rules
ATTR{idVendor}=="0463", ATTR{idProduct}=="0001", MODE="664", GROUP="root"
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664", GROUP="root"

jimklimov · 2024-07-31T16:24:14Z

battery.type is still blank instead of PbAc

In your older debug-data dump from usbhid-ups, that data point could not be read:

   5.557866	[D2] Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, ReportID: 0x10, Offset: 0, Size: 8, Value: 5
   5.579083	nut_libusb_get_string: Input/Output Error
   5.579102	[D5] send_to_all: SETINFO battery.type ""

The "PbAc" string is not hard-coded in any USB HID driver, but comes from the mapping table pointing to stringid_conversion and that presumably leads to usbhid-ups.c method stringid_conversion_fun and further to https://github.com/networkupstools/nut/blob/master/drivers/libhid.c#L548-L551

So here the query failed for some reason (entry-level device as @arnaudquette-eaton mentioned?) and the HIDGetIndexString() method returned "empty if not found". Not sure 100% that this is what happens, but matches the symptoms at least.

jimklimov · 2024-07-31T16:27:03Z

OK i got for :

#grep 463 /lib/udev/rules.d/62-nut-usbups.rules
ATTR{idVendor}=="0463", ATTR{idProduct}=="0001", MODE="664", GROUP="root"
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664", GROUP="root"

Assuming the NUT drivers run as root (did in older screenshots), this should suffice, if the OS does not get into way (containers, quirks...)

jimklimov · 2024-07-31T16:29:00Z

As a random thought, we do get a lot of info from the device successfully, after assuming it is ours (here by numeric IDs alone) and claiming it:

   0.481358	[D3] match_function_regex: matching a device...
   0.481364	[D2] Device matches
   0.481369	[D2] Reading first configuration descriptor
   0.481386	[D3] libusb_kernel_driver_active() returned 0
   0.481412	[D2] Claimed interface 0 successfully
   0.481418	[D3] nut_usb_set_altinterface: skipped libusb_set_interface_alt_setting(udev, 0, 0)
   0.512218	[D3] HID descriptor, method 1: (9 bytes) => 09 21 10 01 21 01 22 05 08
   0.512240	[D3] HID descriptor length (method 1) 2053
...

Perhaps, if the claim did succeed and ID data are NULL, we can retry getting them?

masterwishx · 2024-07-31T16:33:45Z

Assuming the NUT drivers run as root (did in older screenshots), this should suffice, if the OS does not get into way (containers, quirks...)

I think when back then just opened issue the developer for NUT plugin for unraid was other than now @desertwitch that he made a lot for the NUT Plugin

masterwishx · 2024-07-31T16:36:32Z

As a random thought, we do get a lot of info from the device successfully, after assuming it is ours (here by numeric IDs alone) and claiming it:
   0.481358	[D3] match_function_regex: matching a device...
   0.481364	[D2] Device matches
   0.481369	[D2] Reading first configuration descriptor
   0.481386	[D3] libusb_kernel_driver_active() returned 0
   0.481412	[D2] Claimed interface 0 successfully
   0.481418	[D3] nut_usb_set_altinterface: skipped libusb_set_interface_alt_setting(udev, 0, 0)
   0.512218	[D3] HID descriptor, method 1: (9 bytes) => 09 21 10 01 21 01 22 05 08
   0.512240	[D3] HID descriptor length (method 1) 2053
...
Perhaps, if the claim did succeed and ID data are NULL, we can retry getting them?

if you need i can run some commands for checks ?

masterwishx · 2024-07-31T16:39:00Z

this is for : udevadm info /dev/bus/usb/003/002

P: /devices/pci0000:00/0000:00:14.0/usb3/3-3
N: bus/usb/003/002
E: BUSNUM=003
E: DEVNAME=/dev/bus/usb/003/002
E: DEVNUM=002
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-3
E: DEVTYPE=usb_device
E: DRIVER=usb
E: ID_BUS=usb
E: ID_FOR_SEAT=usb-pci-0000_00_14_0-usb-0_3
E: ID_MODEL=Eaton_9E
E: ID_MODEL_ENC=Eaton\x209E
E: ID_MODEL_ID=ffff
E: ID_PATH=pci-0000:00:14.0-usb-0:3
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_3
E: ID_REVISION=0202
E: ID_SERIAL=EATON_Eaton_9E_GE#hidden_by_me_can_post_if_needed
E: ID_SERIAL_SHORT=GE#hidden_by_me_can_post_if_needed
E: ID_USB_INTERFACES=:030000:
E: ID_VENDOR=EATON
E: ID_VENDOR_ENC=EATON
E: ID_VENDOR_ID=0463
E: MAJOR=189
E: MINOR=257
E: NVME_HOST_IFACE=none
E: PRODUCT=463/ffff/202
E: SUBSYSTEM=usb
E: TAGS=:seat:
E: TYPE=0/0/0
E: USEC_INITIALIZED=26231253

masterwishx · 2024-07-31T16:43:54Z

@jimklimov oh now i remember some values from #2492 like UPS.PowerConverter.Output.LowVoltageEcoTransfer , or maybe better to leave them in related issue ?

…or, Product, Serial if NULL, after claiming it by other criteria [networkupstools#2562] Signed-off-by: Jim Klimov <[email protected]>

…Product, Serial if NULL, after claiming it by other criteria [networkupstools#2562] Signed-off-by: Jim Klimov <[email protected]>

masterwishx · 2024-07-31T16:54:12Z

Also wanted to mention the NUT plugin working in plain unraid not in container

jimklimov · 2024-07-31T17:03:17Z

Also wanted to mention the NUT plugin working in plain unraid not in container

Aha, I must have mixed it up with HomeAssistant plugins which are delivered as containers. So, Unraid ones run on same bare-metal as their host OS environment, with no further layers? Good to know :)

Posted #2571 with speculative changes for retrying the Vendor, Model and Serial fetching after claiming a device. Can you please give that branch a spin?

desertwitch · 2024-07-31T17:13:49Z

Also wanted to mention the NUT plugin working in plain unraid not in container

Aha, I must have mixed it up with HomeAssistant plugins which are delivered as containers. So, Unraid ones run on same bare-metal as their host OS environment, with no further layers? Good to know :)

Posted #2571 with speculative changes for retrying the Vendor, Model and Serial fetching after claiming a device. Can you please give that branch a spin?

Hello again!
Sorry I'm not much of a help here, my bandwidth's a bit limited at the moment.
NUT runs as root and bare metal w/ no additional layers on Unraid (Slackware), the "plugin" part just adds a web GUI.

masterwishx · 2024-07-31T17:59:20Z

Also wanted to mention the NUT plugin working in plain unraid not in container

Aha, I must have mixed it up with HomeAssistant plugins which are delivered as containers. So, Unraid ones run on same bare-metal as their host OS environment, with no further layers? Good to know :)

Posted #2571 with speculative changes for retrying the Vendor, Model and Serial fetching after claiming a device. Can you please give that branch a spin?

Do you mean to compile and check it?

jimklimov · 2024-07-31T19:27:29Z

Do you mean to compile and check it?

Yes :)

masterwishx · 2024-07-31T19:38:20Z

Do you mean to compile and check it?

Yes :)

Sure, just I need to wait for @desertwitch will kindly compile for me or will provide me config file for I will try to compile myself

…networkupstools#2562] According to networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>

…ixl"/"ixlau" [networkupstools#2562] Per networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>

…networkupstools#2562] According to networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>

…ixl"/"ixlau" [networkupstools#2562] Per networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>

desertwitch · 2024-08-06T12:57:00Z

Making sense and seems to show improvement, as reviewed in conjunction with proposed changes in #2571.

…Vendor, Product, Serial if NULL, after claiming it by other criteria [networkupstools#2562]" This reverts commit ad83b70. Signed-off-by: Tormod Volden <[email protected]>

…ce->Vendor, Product, Serial if NULL, after claiming it by other criteria [networkupstools#2562]" This reverts commit ea99f96. Signed-off-by: Tormod Volden <[email protected]>

…Vendor, Product, Serial if NULL, after claiming it by other criteria [networkupstools#2562]" This reverts commit ad83b70. The reverted commit attempted to workaround a string descriptor retrieval issue by retrying after claiming an interface on the device. However, this did not help, and it was later found out that a broken langid descriptor was the root issue all along. Signed-off-by: Tormod Volden <[email protected]>

…ce->Vendor, Product, Serial if NULL, after claiming it by other criteria [networkupstools#2562]" This reverts commit ea99f96. The reverted commit attempted to workaround a string descriptor retrieval issue by retrying after claiming an interface on the device. However, this did not help, and it was later found out that a broken langid descriptor was the root issue all along. Signed-off-by: Tormod Volden <[email protected]>

jimklimov added Eaton USB Incorrect or missing readings On some devices driver-reported values are systemically off (e.g. x10, x0.1, const+Value, etc.) labels Jul 28, 2024

jimklimov added this to the 2.8.3 milestone Jul 28, 2024

jimklimov added need testing Code looks reasonable, but the feature would better be tested against hardware or OSes unraid Integration of NUT into unraid OS labels Jul 29, 2024

jimklimov marked this pull request as draft July 29, 2024 07:36

jimklimov mentioned this pull request Jul 31, 2024

drivers/libusb{0,1}.c: {,nut_}libusb_open(): try to re-fetch curDevice->Vendor, Product, Serial if NULL, after claiming it by other criteria #2571

Merged

jimklimov added a commit to jimklimov/nut that referenced this pull request Jul 31, 2024

drivers/mge-hid.c: add Eaton 9E1000* models, and "ir" suffix for rack […

0cb24fc

…networkupstools#2562] According to networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>

jimklimov added a commit to jimklimov/nut that referenced this pull request Jul 31, 2024

drivers/mge-hid.c: add Eaton 9En000 models "iau" suffix, and 9E3000 "…

649dac1

…ixl"/"ixlau" [networkupstools#2562] Per networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>

jimklimov added 2 commits August 1, 2024 00:23

drivers/mge-hid.c: add Eaton 9E1000* models, and "ir" suffix for rack […

57906c8

…networkupstools#2562] According to networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>

drivers/mge-hid.c: add Eaton 9En000 models "iau" suffix, and 9E3000 "…

c4bea54

…ixl"/"ixlau" [networkupstools#2562] Per networkupstools#2571 (comment) Signed-off-by: Jim Klimov <[email protected]>

desertwitch approved these changes Aug 6, 2024

View reviewed changes

masterwishx mentioned this pull request Aug 7, 2024

nut_libusb_open get some values failed, retrying... libusb/libusb#1548

Open

jimklimov marked this pull request as ready for review August 11, 2024 18:13

jimklimov merged commit 63d90eb into networkupstools:master Aug 11, 2024
22 checks passed

jimklimov deleted the usb-eaton-ids branch August 11, 2024 18:13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

drivers/mge-hid.c, NEWS.adoc: try to recognize Eaton 9E model and info #2562

drivers/mge-hid.c, NEWS.adoc: try to recognize Eaton 9E model and info #2562

jimklimov commented Jul 28, 2024 •

edited

Loading

masterwishx commented Jul 28, 2024

jimklimov commented Jul 29, 2024

masterwishx commented Jul 30, 2024

desertwitch commented Jul 31, 2024 •

edited

Loading

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024 •

edited

Loading

jimklimov commented Jul 31, 2024

masterwishx commented Jul 31, 2024 •

edited

Loading

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024

jimklimov commented Jul 31, 2024

jimklimov commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024

desertwitch commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024

masterwishx commented Jul 31, 2024

desertwitch commented Aug 6, 2024

drivers/mge-hid.c, NEWS.adoc: try to recognize Eaton 9E model and info #2562

drivers/mge-hid.c, NEWS.adoc: try to recognize Eaton 9E model and info #2562

Conversation

jimklimov commented Jul 28, 2024 • edited Loading

masterwishx commented Jul 28, 2024

jimklimov commented Jul 29, 2024

masterwishx commented Jul 30, 2024

desertwitch commented Jul 31, 2024 • edited Loading

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024 • edited Loading

jimklimov commented Jul 31, 2024

masterwishx commented Jul 31, 2024 • edited Loading

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024

jimklimov commented Jul 31, 2024

jimklimov commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024

desertwitch commented Jul 31, 2024

masterwishx commented Jul 31, 2024

jimklimov commented Jul 31, 2024

masterwishx commented Jul 31, 2024

desertwitch commented Aug 6, 2024

jimklimov commented Jul 28, 2024 •

edited

Loading

desertwitch commented Jul 31, 2024 •

edited

Loading

jimklimov commented Jul 31, 2024 •

edited

Loading

masterwishx commented Jul 31, 2024 •

edited

Loading