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>
Curiouser and curiouser!
I changed the driver line in ups.conf to nutdrv_atcl_usb but still get
the below:
./drivers/nutdrv_atcl_usb -a ups1 -d1 -DDDDDD
0.000000 [D5] send_to_all: SETINFO driver.state "init.starting"
Network UPS Tools 2.8.4.983-983+ge439012cd (development iteration after
2.8.4) - 'ATCL FOR UPS' USB driver 1.22
Warning: This is an experimental driver.
Some features may not function correctly.
0.000246 [D5] do_upsconf_args: confupsname=(null), var=maxretry, val=3
0.000263 [D5] do_upsconf_args: call do_global_args()
0.000268 [D3] do_global_args: var='maxretry' val='3'
0.000389 [D5] do_upsconf_args: confupsname=ups1, var=driver,
val=nutdrv_qx
0.000397 [D5] do_upsconf_args: call main_arg()
0.000407 [D3] main_arg: var='driver' val='nutdrv_qx'
0.000412 [D5] do_upsconf_args: not a main_arg()
0.000416 [D5] do_upsconf_args: this is a 'driver' setting, may we
proceed?
0.000424 [D6] testval_reloadable: var=driver,
oldval=nutdrv_atcl_usb, newval=nutdrv_qx, reloadable=0, reload_flag=0
0.000429 [D1] testval_reloadable: setting 'driver' exists and
differs: new value 'nutdrv_qx' vs. 'nutdrv_atcl_usb'
0.000434 [D6] testval_reloadable: verdict for (re)loading var=driver
value: 1
0.000439 [D3] do_upsconf_args: collected 1 bad hits and 0 good hits
for 'nutdrv_qx' in 'nutdrv_atcl_usb'
0.000447 Error: UPS [ups1] is for driver 'nutdrv_qx', but I'm
'nutdrv_atcl_usb'!
0.000466 [D5] send_to_all: SETINFO driver.state "cleanup.exit"
Then:
usbhid-ups -s test -x port=auto -x productid=0000 -x vendorid=0001
-DDDDDD -d1
0.000004 [D5] send_to_all: SETINFO driver.state "init.starting"
Network UPS Tools - Generic HID driver 0.54 (2.8.2.1)
USB communication driver (libusb 1.0) 0.48
0.000093 [D1] upsdrv_makevartable...
0.000127 [D5] send_to_all: SETINFO driver.version.usb "libusb-1.0.28
(API: 0x100010a)"
0.000140 [D1] Using USB implementation: libusb-1.0.28 (API: 0x100010a)
0.000151 [D3] main_arg: var='port' val='auto'
0.000163 [D6] testinfo_reloadable: var=port,
infoname=driver.parameter.port, newval=auto, reloadable=0, reload_flag=0
0.000171 [D6] testinfo_reloadable: verdict for (re)loading var=port
value: 1
0.000180 [D5] send_to_all: SETINFO driver.parameter.port "auto"
0.000190 [D3] main_arg: var='productid' val='0000'
0.000200 [D5] send_to_all: SETINFO driver.parameter.productid
"0000"
0.000206 [D3] main_arg: var='vendorid' val='0001'
0.000215 [D5] send_to_all: SETINFO driver.parameter.vendorid
"0001"
0.000220 [D1] Network UPS Tools version 2.8.2.1 (release/snapshot of
2.8.2.1) built with gcc (GCC) 14.2.1 20250110 (Red Hat 14.2.1-7) and
configured with flags: --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
--sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-all --without-modbus --without-gpio
--without-powerman --with-libltdl --without-wrap --with-cgi
--with-python=/usr/bin/python3 --with-python3=/usr/bin/python3
--without-python2 --datadir=/usr/share/nut --with-user=nut
--with-group=dialout --with-statepath=/run/nut --with-pidpath=/run/nut
--with-altpidpath=/run/nut --sysconfdir=/etc/ups
--with-cgipath=/var/www/nut-cgi-bin --with-drvpath=/usr/sbin
--with-systemdsystemunitdir=/usr/lib/systemd/system
--with-systemdshutdowndir=/lib/systemd/system-shutdown
--with-pkgconfig-dir=/usr/lib64/pkgconfig --disable-static
--with-udev-dir=/usr/lib/udev --libdir=/usr/lib64
0.000269 [D1] debug level is '6'
0.000277 [D5] send_to_all: SETINFO driver.debug "6"
0.000286 [D5] send_to_all: SETFLAGS driver.debug RW NUMBER
0.001493 [D1] Succeeded to become_user(nut): now UID=57 GID=57
0.001508 [D1] Signalling UPS [test]: driver.exit (quietly, no fuss
if no driver is running or responding)
0.001526 Can't open /run/nut/usbhid-ups-test: No such file or directory
0.001531 [D1] Request for other driver to exit returned code -1
0.001535 [D1] Socket dialog with the other driver instance (may be
absent) failed: No such file or directory
0.001541 [D5] send_to_all: SETINFO device.type "ups"
0.001546 [D5] send_to_all: SETINFO driver.state "init.device"
0.001549 [D1] upsdrv_initups (non-SHUT)...
0.001553 [D2] Initializing an USB-connected UPS with library
libusb-1.0.28 (API: 0x100010a) (NUT subdriver name='USB communication
driver (libusb 1.0)' ver='0.48')
0.006084 [D2] Checking device 1 of 8 (1D6B/0003)
0.006104 [D1] Failed to open device (1D6B/0003), skipping: Access
denied (insufficient permissions)
0.006108 [D2] Checking device 2 of 8 (17EF/6190)
0.006114 [D1] Failed to open device (17EF/6190), skipping: Access
denied (insufficient permissions)
0.006116 [D2] Checking device 3 of 8 (17EF/608D)
0.006121 [D1] Failed to open device (17EF/608D), skipping: Access
denied (insufficient permissions)
0.006124 [D2] Checking device 4 of 8 (0001/0000)
0.007337 [D1] nut_libusb_open get iProduct failed, retrying...
0.008513 [D1] nut_libusb_open get iProduct failed, retrying...
0.009670 [D1] nut_libusb_open get iProduct failed, retrying...
0.009675 [D2] - VendorID: 0001
0.009678 [D2] - ProductID: 0000
0.009681 [D2] - Manufacturer: unknown
0.009683 [D2] - Product: unknown
0.009685 [D2] - Serial Number: unknown
0.009688 [D2] - Bus: 003
0.009690 [D2] - Bus Port: 006
0.009693 [D2] - Device: 008
0.009695 [D2] - Device release number: 0100
0.009697 [D2] Trying to match device
0.009702 [D2] match_function_subdriver (non-SHUT mode): matching a
device...
0.009708 [D2] match_function_subdriver (non-SHUT mode): failed to
match a subdriver to vendor and/or product ID
0.009711 [D2] Device does not match - skipping
0.009723 [D2] Checking device 5 of 8 (0BDA/4853)
0.009738 [D1] Failed to open device (0BDA/4853), skipping: Access
denied (insufficient permissions)
0.009742 [D2] Checking device 6 of 8 (1D6B/0002)
0.009747 [D1] Failed to open device (1D6B/0002), skipping: Access
denied (insufficient permissions)
0.009750 [D2] Checking device 7 of 8 (1D6B/0003)
0.009756 [D1] Failed to open device (1D6B/0003), skipping: Access
denied (insufficient permissions)
0.009759 [D2] Checking device 8 of 8 (1D6B/0002)
0.009764 [D1] Failed to open device (1D6B/0002), skipping: Access
denied (insufficient permissions)
0.009768 [D2] libusb1: No appropriate HID device found
0.009779 libusb1: Could not open any HID devices: insufficient
permissions on everything
0.009785 No matching HID UPS found
0.009798 [D5] send_to_all: SETINFO driver.state "cleanup.exit"
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
>
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 > > > > >