[Nut-upsuser] Digitech support

[Stephen Davies]

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 <sdavies at sdc.com.au 
> <mailto:sdavies at sdc.com.au>> 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 at ups1[916173]: 0.028122#011[D5]
>     send_to_all: SETINFO driver.state "reconnect.updateinfo"
>      > Dec 19 18:04:56 mustang nut-driver at ups1[916173]: 0.028125#011[D3]
>     send: Q1
>      > Dec 19 18:04:56 mustang nut-driver at ups1[916173]: 0.029292#011[D3]
>     read: Input/Output Error (-1)
>      > Dec 19 18:04:56 mustang nut-driver at 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
>      >
>      >
>