[Nut-upsuser] New intermediate Windows binaries release - 2.6.5-2

[Denis Serov]

Hello Frederic!

>> 2. I've found a strange warning in Event Log:
>> "usbhid-ups - libusb_get_interrupt: libusb0-dll:err [submit_async] submitting request failed, win error: The device does not recognize the command."
>> Here is more details from UBSHID-USB output:
>>    0.468000     libusb_get_report: libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is not functioning.
>>    0.468000     Can't retrieve Report 48: Input/output error [A device attached to the system is not functioning. ]

>> I think it is related to issue with APC Back ES UPS (there was no such error in private binary you sent to me).

> This is very strange.
> I see two report ID raising a libusb error in your logs: 48 and 62. They contains non standard, APC specific, HID data and strange value (as I see them on the old binary logs you have sent me).
> I am not sure what are the differences between the released binary and the one that I sent to you. That's because the one I send to you was just an experimental thing to see if I was searching in the right direction, and I have lost its sources now. But from what I remember I don't see what could have changed its behavior the way it is now.
> Anyway, from what you are reporting this is only "cosmetic" issue. Just one thing that still bothering me is that you have mentioned that it "repeats iteratively". Do you mean that the libusb error repeats regularly when the usbhid-ups driver is running ? If it is the case, can you send us usbhid-ups logs on a longer run (the attached one is stopped just after the init), please ?

I didn't spot different error codes and I thought that this is reiteration of the same error. I've just tested private build of UPSHID-UPS and 2.6.5-2 one. The behavior is equal: "report 48" is logged firstly, "report 62" - after that and no errors afterwards. So, there is no problem.

Sorry for misleading...

Thanks,
Denis