[Nut-upsuser] Digitech support

Stephen Davies
Sat, 27 Dec 2025 03:15:14 -0000

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
>      >
>      >
>