Open mickeyreg opened 3 months ago
Hello, just in case: did you check also with nutdrv_atcl_usb
and for kicks with usbhid-ups
(probably need to do some guesswork about subdriver
option there)?
I tested all subdrivers from nutdrv_qx
changind options like norating and novendor if applicable. I tested also: blazer_usb
, usbhid-ups
and nutdrv_atcl_usb
- all without success.
As I found there is a lot 0001/0000 UPSes, which theoretically should work with NUT, but does not work :(
In the NUTDRV_QX documentation can be read:
norating Some UPSes will lock up if you attempt to read rating information from them. Setting this flag will make the driver skip this step. novendor Some UPSes will lock up if you attempt to read vendor information from them. Setting this flag will make the driver skip this step.
What means "UPSes will lock up"? Do I have to disconnect/reconnect USB to unlock?
Well, with vendors not even caring to identify their devices properly (so you get a proverbial "cat in a sack"), the "theoretically should work with NUT" part is a big leap of faith :\
I believe "UPSes will lock up" means that unexpected input can wedge their on-board controller. Whether it un-freezes after some time or requires some replug or even UPS power-cycling to clear this up, wholly depends on the firmware (and bugs of its particular build, possibly).
Well, with vendors not even caring to identify their devices properly (so you get a proverbial "cat in a sack"), the "theoretically should work with NUT" part is a big leap of faith :\
After reading above I think I understood the nature of the problem. We have a lot of devices, which identifies itself as 0001/0000 and uses unidentified protocol. VID & PID is not enough to recognize the type of the protocol :(
Some of these 0001/0000 devices have software for Windows or Linux. It is possible to record USB communication between this software and the device? On Linux? On Windows? Can such a recording be useful in extending the capabilities of the specific driver in NUT?
Yes, some platforms have native tools like usbdump
, others have modules for WireShark and relatives. I suppose that some drivers were written by reverse-engineering, where sniffing the protocol of vendor's software could play a part.
Unfortunately, this would likely need a programmer ready to dig into the USB protocol (or serial-over-USB) and make sense of it, which I myself am not. I'll post a query on the mailing list, perhaps someone would have at least suggestions about this...
Just in case, did you check https://github.com/networkupstools/nut/issues?q=label%3AViewPower for other devices supported by ViewPower - if those discussions led to a working driver?
Hi,
I have the "no name" device, called "MicroUPS 3000": https://voltpolska.pl/zasilanie-awaryjne/micro-ups-3000-4x9ah-1800-3000w-komputerowy-zasilacz-awaryjny.html
According to product information it is supported by ViewPower software, so it is possible, that it should be supported by nutdrv_qx. But I have an info "Device not supported!" :(
Maybe somebody can take a look in below logs to check if the support is possible.
After testing in NUT from pkg on FreeBSD 14.0 I downloaded the latest mater from GitHub, compiled and tested: git clone -b master https://github.com/networkupstools/nut
Scanner shows:
So in the ups.conf I have:
Log from nutdrv_qx:
I've also run usbdump in the same time and it showed:
Regards, Mickey