<div dir="ltr"><div>Thanks, yes (now :-} )</div><div><br></div><div>So at least the string language index issue is solved, it sees the common "MEC0003" name.</div><div><br></div><div>In the log I see you also setting "subdriver=hunnox" which is not listed in the HCL comments:</div><div><br></div><div>$ git grep -i digitech<br>data/<a href="http://driver.list.in">driver.list.in</a>:"DigiTECH"  "ups"   "2"     "Computer 650VA"        "USB"   "nutdrv_qx port=auto vendorid=0001 productid=0000 protocol=hunnox langid_fix=0x0409 novendor noscanlangid"      # <a href="https://github.com/networkupstools/nut/pull/638">https://github.com/networkupstools/nut/pull/638</a> caveats at <a href="https://github.com/networkupstools/nut/issues/674">https://github.com/networkupstools/nut/issues/674</a> (may need longer pollinterval)</div><div><br></div><div>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.</div><div>It may be that the USB subdriver for hunnox is in fact not what digitech wants, and that's why connection setup fails?</div><div><br></div><div>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.</div><div><br></div><div>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`</div><div><br></div><div>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 <a href="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</a> for details.</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 26, 2025 at 12:48 AM Stephen Davies <<a href="mailto:sdavies@sdc.com.au">sdavies@sdc.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">G'day Jim.<br>
Did you receive the following?<br>
<br>
I tried running "./drivers/nutdrv_qx -a ups1 -d1 -DDDDDD -x subdriver=hunnox" after building directly after<br>
<br>
./configure  --with-all --with-cgi --with-usb=libusb-1.0 --with-modbus=no --with-gpio=no --with-snmp=no<br>
<br>
The output is the the attachment. Doesn't look good.<br>
<br>
(I added the three =no bits to configure options because I couldn't find the relevant dependencies.)<br>
<br>
Cheers,<br>
Stephen<br>
<br>
On 19/12/25 18:46, Jim Klimov wrote:<br>
> Thanks,<br>
> <br>
> So on one hand that part does not look too promising:<br>
> <br>
> Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.028122#011[D5] send_to_all: SETINFO driver.state "reconnect.updateinfo"<br>
> Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.028125#011[D3] send: Q1<br>
> Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.029292#011[D3] read: Input/Output Error (-1)<br>
> Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.029308#011[D5] send_to_all: SETINFO driver.state "reconnect.trying"<br>
> <br>
> 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.<br>
> <br>
> Can you please check if you can build the current master branch per <a href="https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests</a> 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).<br>
> <br>
> Specifically, I think these PRs can apply to the situation:<br>
> * <a href="https://github.com/networkupstools/nut/pull/2604" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/2604</a> and maybe <a href="https://github.com/networkupstools/nut/pull/2571" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/2571</a> (both went into 2.8.3)<br>
> * <a href="https://github.com/networkupstools/nut/pull/3211" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/3211</a> (recently on master, fixes a string truncation issue possible after #2604 above)<br>
> <br>
> Hope this helps,<br>
> Jim Klimov<br>
> <br>
></blockquote></div>