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:"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 caveats at 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 for details. Hope this helps, Jim Klimov On Fri, Dec 26, 2025 at 12:48 AM Stephen Davies <[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 > 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 and maybe > https://github.com/networkupstools/nut/pull/2571 (both went into 2.8.3) > > * 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
