[Nut-upsuser] Digitech support

[Jim Klimov]

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 <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
> 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
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251226/519f5d5c/attachment.htm>