[Nut-upsuser] Digitech support
Jim Klimov
jimklimov+nut at gmail.com
Fri Dec 19 08:16:17 GMT 2025
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
On Fri, Dec 19, 2025 at 8:42 AM Stephen Davies <sdavies at sdc.com.au> wrote:
> I set debug_min to 6 as suggested in your referenced doco.
>
> The resulting log is attached.
>
> Cheers and thanks,
> Stephen
>
> On 17/12/25 20:33, Jim Klimov wrote:
> > > Can't open /run/nut/nutdrv_qx-ups1: No such file or directory
> >
> > That's the driver checking if another instance of it is running. Newer
> > releases should log it less frighteningly.
> >
> > > ... but nut-driver complained so...
> >
> > The `nut-driver at upsname` is a systemd instance wrapping an execution of
> > a NUT driver program as a daemon. It is the driver program that actually
> > complains, and its debug logs we want to see to figure out what puzzle
> > pieces did not fit together.
> >
> > For an in-vivo debug bump (so the detailed logs end up in systemd
> > journal) you can also temporarily set `debug_min` in the `ups.conf`, see
> > https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-
> > verbosity <https://github.com/networkupstools/nut/wiki/Changing-NUT-
> > daemon-debug-verbosity> for more details (they varied from one NUT
> > release to another).
> >
> > Jim
> >
> >
> >
> > On Wed, Dec 17, 2025 at 9:45 AM Stephen Davies <sdavies at sdc.com.au
> > <mailto:sdavies at sdc.com.au>> wrote:
> >
> > Thanks for the feedback.
> >
> > The NUT vwersion is 2.8.2.1.
> >
> > I am in the process of building a new Rocky Linux 10 server after my
> > old
> > Centos 7 server died.
> >
> > The old box used upsSmart to access the UPS but that relies on an X
> > server and does not work on ocky 10.
> >
> > One of the errors from your suggested test is:
> >
> > Can't open /run/nut/nutdrv_qx-ups1: No such file or directory
> >
> > I had "langid_fix=0x0409" in ups.conf but nut-driver complained so I
> > removed it.
> >
> > Cheers,
> > Stephen
> >
> > On 17/12/25 18:47, Jim Klimov wrote:
> > > Cheers,
> > >
> > > What NUT version is involved? Per `nut-driver at ups1` I suppose
> > it is
> > > some v2.8.x, and reports like https://github.com/networkupstools/
> > nut/ <https://github.com/networkupstools/nut/>
> > > pull/638 <https://github.com/networkupstools/nut/pull/638
> > <https://github.com/networkupstools/nut/pull/638>> and https://
> > > github.com/networkupstools/nut/issues/674 <http://github.com/
> > networkupstools/nut/issues/674> <https://github.com/ <https://
> > github.com/>
> > > networkupstools/nut/issues/674> suggest the needed support was
> > merged
> > > before v2.8.0, so that should suffice.
> > >
> > > It may well be that the manufacturer moved on and stamped the
> > same
> > > label onto a completely unrelated device (or firmware), these
> things
> > > sadly tend to happen as products evolve.
> > >
> > > One of those discussions starts with a "|Device not supported|"
> > > initially, but then it gets found "after opening and then closing
> > the
> > > OEM software" (UPSmart), and apparently by the end of the ticket
> > they
> > > got it working right away. The new hunnox subdriver introduced in
> > PR 638
> > > changed the initialization to work with that, per https://
> > github.com/ <https://github.com/>
> > > networkupstools/nut/pull/638#issuecomment-443558510 <https://
> > github.com/ <https://github.com/>
> > > networkupstools/nut/pull/638#issuecomment-443558510> - notably
> > there's a
> > > sleep involved before the device returns valid info; maybe your
> > device
> > > or its firmware needs a longer one or something?
> > >
> > > Compared to settings in those tickets and HCL, your setup
> > misses a
> > > `langid_fix=0x0409` line, not sure if that makes the difference.
> > This
> > > seems to be a hardcoded default in hunnox_protocol() initializer
> at
> > > https://github.com/networkupstools/nut/pull/638/changes#diff-
> > <https://github.com/networkupstools/nut/pull/638/changes#diff->
> > >
> > cb890ac7b82cb7a4f861284bcf39cc4f168312b61cb9455eb2755e345c0aa627R692-
> > > R696 <https://github.com/networkupstools/nut/pull/638/
> > changes#diff- <https://github.com/networkupstools/nut/pull/638/
> > changes#diff->
> > >
> >
> cb890ac7b82cb7a4f861284bcf39cc4f168312b61cb9455eb2755e345c0aa627R692-R696>
> > >
> > > Can you start the driver with higher verbosity to collect
> > what/how it
> > > probes of the device, and how that fails (with what errors), e.g.
> > >
> > > |nutdrv_qx -a ups1 -d 1 -DDDDDD|
> > >
> > > If there would be a long wall of text, maybe follow up with
> > that as a
> > > new GitHub issue?
> > >
> > > Hope this helps,
> > > Jim Klimov
> > >
> > >
> > >
> > > On Wed, Dec 17, 2025 at 8:23 AM Stephen Davies via Nut-upsuser
> <nut-
> > > upsuser at alioth-lists.debian.net <mailto:upsuser at alioth-
> > lists.debian.net> <mailto:nut-upsuser at alioth- <mailto:nut-
> > upsuser at alioth->
> > > lists.debian.net <http://lists.debian.net>>> wrote:
> > >
> > > According to the support list, the Digitech 650VA UPS is
> > supported but
> > > when I try to connect to my unit, I get:
> > > nut-driver at ups1[357464]: Device not supported!
> > >
> > > My ips.conf has:
> > > [ups1]
> > > driver = nutdrv_qx
> > > port = auto
> > > vendorid=0001
> > > productid=0000
> > > protocol=hunnox
> > > novendor
> > > noscanlangid
> > >
> > >
> > >
> > > _______________________________________________
> > > Nut-upsuser mailing list
> > > Nut-upsuser at alioth-lists.debian.net <mailto:Nut-upsuser at alioth-
> > lists.debian.net> <mailto:Nut-upsuser at alioth- <mailto:Nut-
> > upsuser at alioth->
> > > lists.debian.net <http://lists.debian.net>>
> > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-
> > upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> > nut-upsuser>
> > > <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/
> > nut-upsuser <https://alioth-lists.debian.net/cgi-bin/mailman/
> > listinfo/nut-upsuser>>
> > >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251219/be96f470/attachment.htm>
More information about the Nut-upsuser
mailing list