I tried your double loop idea using nutdrv_qx. Every iteration failed
(50852 lines of log).
On 26/12/25 21:46, Jim Klimov wrote:
Thanks, yes (now :-} )
So at least the string language index issue is solved, it sees the
common "MEC0003" name.
In the log I see you also setting "subdriver=hunnox" which is not listed
in the HCL comments:
$ git grep -i digitech
data/driver.list.in <http://driver.list.in>:"DigiTECH" "ups" "2"
"Computer 650VA" "USB" "nutdrv_qx port=auto vendorid=0001
productid=0000 protocol=hunnox langid_fix=0x0409 novendor noscanlangid"
# https://github.com/networkupstools/nut/pull/638 <https://
github.com/networkupstools/nut/pull/638> caveats at https://github.com/
networkupstools/nut/issues/674 <https://github.com/networkupstools/nut/
issues/674> (may need longer pollinterval)
Parameter names are a bit messed up historically, "subdriver" in
nutdrv_qx refers to USB connection nuances (vs. serial which has no such
concept), and "protocol" is the actual variant of some dialect derived
from a Megatec Q<x> protocol.
It may be that the USB subdriver for hunnox is in fact not what digitech
wants, and that's why connection setup fails?
One other idea is to make a shell loop trying all protocols and
subdrivers until something returns a reasonable response. You can see
the values to loop over in help message of the driver.
Finally, there is a chance that they released a device not talking
Megatec but something else. You can try `nutdrv_atcl_usb` (at least it
also fits the no-name 0000:0001 IDs), or `usbhid-ups -s test -x
port=auto -x productid=0000 -x vendorid=0001 -DDDDDD -d1`
The I/O error message seems to come out of the blue, so NUT just has it
with little context... You can also try your chances with LIBUSB_DEBUG,
see https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-
debug-verbosity#nut-v283-and-newer <https://github.com/networkupstools/
nut/wiki/Changing-NUT-daemon-debug-verbosity#nut-v283-and-newer> for
details.
Hope this helps,
Jim Klimov
On Fri, Dec 26, 2025 at 12:48 AM Stephen Davies <[email protected]
<mailto:[email protected]>> wrote:
G'day Jim.
Did you receive the following?
I tried running "./drivers/nutdrv_qx -a ups1 -d1 -DDDDDD -x
subdriver=hunnox" after building directly after
./configure --with-all --with-cgi --with-usb=libusb-1.0 --with-
modbus=no --with-gpio=no --with-snmp=no
The output is the the attachment. Doesn't look good.
(I added the three =no bits to configure options because I couldn't
find the relevant dependencies.)
Cheers,
Stephen
On 19/12/25 18:46, Jim Klimov wrote:
> Thanks,
>
> So on one hand that part does not look too promising:
>
> Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.028122#011[D5]
send_to_all: SETINFO driver.state "reconnect.updateinfo"
> Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.028125#011[D3]
send: Q1
> Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.029292#011[D3]
read: Input/Output Error (-1)
> Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.029308#011[D5]
send_to_all: SETINFO driver.state "reconnect.trying"
>
> but on another, NUT v2.8.2.1 along with `nut_libusb_open get
iProduct failed, retrying` indicates that maybe this is a device
with botched retrieval of language-specific strings, so we get part
of that reply and the rest is seen by USB layer as garbage when
asking for Q1. Maybe. At least, the part about iProduct, iVendor,
possibly iSerial was solved about a year ago - so trying a newer NUT
version can help.
>
> Can you please check if you can build the current master branch
per https://github.com/networkupstools/nut/wiki/Building-NUT-for-
in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests <https://
github.com/networkupstools/nut/wiki/Building-NUT-for-
in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests> and run
the driver from the resulting build workspace, if that would fare
better? If yes, you can go on about installing that build over the
packaged version; if no, not much of a change for the existing
system (except added build dependency prerequisite packages).
>
> Specifically, I think these PRs can apply to the situation:
> * https://github.com/networkupstools/nut/pull/2604 <https://
github.com/networkupstools/nut/pull/2604> and maybe https://
github.com/networkupstools/nut/pull/2571 <https://github.com/
networkupstools/nut/pull/2571> (both went into 2.8.3)
> * https://github.com/networkupstools/nut/pull/3211 <https://
github.com/networkupstools/nut/pull/3211> (recently on master, fixes
a string truncation issue possible after #2604 above)
>
> Hope this helps,
> Jim Klimov
>
>
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
