<div dir="ltr"><div>Thanks,</div><div><br></div><div>So on one hand that part does not look too promising:</div><div><br></div><div>Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.028122#011[D5] send_to_all: SETINFO driver.state "reconnect.updateinfo"<br>Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.028125#011[D3] send: Q1<br>Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.029292#011[D3] read: Input/Output Error (-1)<br>Dec 19 18:04:56 mustang nut-driver@ups1[916173]: 0.029308#011[D5] send_to_all: SETINFO driver.state "reconnect.trying"<br><br></div><div>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.<br><br></div><div>Can you please check if you can build the current master branch per <a href="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</a> 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).</div><div><br></div><div>Specifically, I think these PRs can apply to the situation:</div><div>* <a href="https://github.com/networkupstools/nut/pull/2604">https://github.com/networkupstools/nut/pull/2604</a> and maybe <a href="https://github.com/networkupstools/nut/pull/2571">https://github.com/networkupstools/nut/pull/2571</a> (both went into 2.8.3)</div><div>* <a href="https://github.com/networkupstools/nut/pull/3211">https://github.com/networkupstools/nut/pull/3211</a> (recently on master, fixes a string truncation issue possible after #2604 above)</div><div><br></div><div>Hope this helps,</div><div>Jim Klimov</div><div><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 19, 2025 at 8:42 AM Stephen Davies <<a href="mailto:sdavies@sdc.com.au">sdavies@sdc.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I set debug_min to 6 as suggested in your referenced doco.<br>
<br>
The resulting log is attached.<br>
<br>
Cheers and thanks,<br>
Stephen<br>
<br>
On 17/12/25 20:33, Jim Klimov wrote:<br>
> > Can't open /run/nut/nutdrv_qx-ups1: No such file or directory<br>
> <br>
> That's the driver checking if another instance of it is running. Newer <br>
> releases should log it less frighteningly.<br>
> <br>
> > ... but nut-driver complained so...<br>
> <br>
> The `nut-driver@upsname` is a systemd instance wrapping an execution of <br>
> a NUT driver program as a daemon. It is the driver program that actually <br>
> complains, and its debug logs we want to see to figure out what puzzle <br>
> pieces did not fit together.<br>
> <br>
> For an in-vivo debug bump (so the detailed logs end up in systemd <br>
> journal) you can also temporarily set `debug_min` in the `ups.conf`, see <br>
> <a href="https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-</a> <br>
> verbosity <<a href="https://github.com/networkupstools/nut/wiki/Changing-NUT-" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/wiki/Changing-NUT-</a> <br>
> daemon-debug-verbosity> for more details (they varied from one NUT <br>
> release to another).<br>
> <br>
> Jim<br>
> <br>
> <br>
> <br>
> On Wed, Dec 17, 2025 at 9:45 AM Stephen Davies <<a href="mailto:sdavies@sdc.com.au" target="_blank">sdavies@sdc.com.au</a> <br>
> <mailto:<a href="mailto:sdavies@sdc.com.au" target="_blank">sdavies@sdc.com.au</a>>> wrote:<br>
> <br>
> Thanks for the feedback.<br>
> <br>
> The NUT vwersion is 2.8.2.1.<br>
> <br>
> I am in the process of building a new Rocky Linux 10 server after my<br>
> old<br>
> Centos 7 server died.<br>
> <br>
> The old box used upsSmart to access the UPS but that relies on an X<br>
> server and does not work on ocky 10.<br>
> <br>
> One of the errors from your suggested test is:<br>
> <br>
> Can't open /run/nut/nutdrv_qx-ups1: No such file or directory<br>
> <br>
> I had "langid_fix=0x0409" in ups.conf but nut-driver complained so I<br>
> removed it.<br>
> <br>
> Cheers,<br>
> Stephen<br>
> <br>
> On 17/12/25 18:47, Jim Klimov wrote:<br>
> > Cheers,<br>
> ><br>
> > What NUT version is involved? Per `nut-driver@ups1` I suppose<br>
> it is<br>
> > some v2.8.x, and reports like <a href="https://github.com/networkupstools/" rel="noreferrer" target="_blank">https://github.com/networkupstools/</a><br>
> nut/ <<a href="https://github.com/networkupstools/nut/" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/</a>><br>
> > pull/638 <<a href="https://github.com/networkupstools/nut/pull/638" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/638</a><br>
> <<a href="https://github.com/networkupstools/nut/pull/638" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/638</a>>> and https://<br>
> > <a href="http://github.com/networkupstools/nut/issues/674" rel="noreferrer" target="_blank">github.com/networkupstools/nut/issues/674</a> <<a href="http://github.com/" rel="noreferrer" target="_blank">http://github.com/</a><br>
> networkupstools/nut/issues/674> <<a href="https://github.com/" rel="noreferrer" target="_blank">https://github.com/</a> <https://<br>
> <a href="http://github.com/" rel="noreferrer" target="_blank">github.com/</a>><br>
> > networkupstools/nut/issues/674> suggest the needed support was<br>
> merged<br>
> > before v2.8.0, so that should suffice.<br>
> ><br>
> > It may well be that the manufacturer moved on and stamped the<br>
> same<br>
> > label onto a completely unrelated device (or firmware), these things<br>
> > sadly tend to happen as products evolve.<br>
> ><br>
> > One of those discussions starts with a "|Device not supported|"<br>
> > initially, but then it gets found "after opening and then closing<br>
> the<br>
> > OEM software" (UPSmart), and apparently by the end of the ticket<br>
> they<br>
> > got it working right away. The new hunnox subdriver introduced in<br>
> PR 638<br>
> > changed the initialization to work with that, per https://<br>
> <a href="http://github.com/" rel="noreferrer" target="_blank">github.com/</a> <<a href="https://github.com/" rel="noreferrer" target="_blank">https://github.com/</a>><br>
> > networkupstools/nut/pull/638#issuecomment-443558510 <https://<br>
> <a href="http://github.com/" rel="noreferrer" target="_blank">github.com/</a> <<a href="https://github.com/" rel="noreferrer" target="_blank">https://github.com/</a>><br>
> > networkupstools/nut/pull/638#issuecomment-443558510> - notably<br>
> there's a<br>
> > sleep involved before the device returns valid info; maybe your<br>
> device<br>
> > or its firmware needs a longer one or something?<br>
> ><br>
> > Compared to settings in those tickets and HCL, your setup<br>
> misses a<br>
> > `langid_fix=0x0409` line, not sure if that makes the difference.<br>
> This<br>
> > seems to be a hardcoded default in hunnox_protocol() initializer at<br>
> > <a href="https://github.com/networkupstools/nut/pull/638/changes#diff-" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/638/changes#diff-</a><br>
> <<a href="https://github.com/networkupstools/nut/pull/638/changes#diff-" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/638/changes#diff-</a>><br>
> ><br>
> cb890ac7b82cb7a4f861284bcf39cc4f168312b61cb9455eb2755e345c0aa627R692-<br>
> > R696 <<a href="https://github.com/networkupstools/nut/pull/638/" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/638/</a><br>
> changes#diff- <<a href="https://github.com/networkupstools/nut/pull/638/" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/pull/638/</a><br>
> changes#diff-><br>
> ><br>
> cb890ac7b82cb7a4f861284bcf39cc4f168312b61cb9455eb2755e345c0aa627R692-R696><br>
> ><br>
> > Can you start the driver with higher verbosity to collect<br>
> what/how it<br>
> > probes of the device, and how that fails (with what errors), e.g.<br>
> ><br>
> > |nutdrv_qx -a ups1 -d 1 -DDDDDD|<br>
> ><br>
> > If there would be a long wall of text, maybe follow up with<br>
> that as a<br>
> > new GitHub issue?<br>
> ><br>
> > Hope this helps,<br>
> > Jim Klimov<br>
> ><br>
> ><br>
> ><br>
> > On Wed, Dec 17, 2025 at 8:23 AM Stephen Davies via Nut-upsuser <nut-<br>
> > <a href="mailto:upsuser@alioth-lists.debian.net" target="_blank">upsuser@alioth-lists.debian.net</a> <mailto:<a href="mailto:upsuser@alioth-" target="_blank">upsuser@alioth-</a><br>
> <a href="http://lists.debian.net" rel="noreferrer" target="_blank">lists.debian.net</a>> <mailto:<a href="mailto:nut-upsuser@alioth-" target="_blank">nut-upsuser@alioth-</a> <mailto:<a href="mailto:nut-" target="_blank">nut-</a><br>
> upsuser@alioth-><br>
> > <a href="http://lists.debian.net" rel="noreferrer" target="_blank">lists.debian.net</a> <<a href="http://lists.debian.net" rel="noreferrer" target="_blank">http://lists.debian.net</a>>>> wrote:<br>
> ><br>
> > According to the support list, the Digitech 650VA UPS is<br>
> supported but<br>
> > when I try to connect to my unit, I get:<br>
> > nut-driver@ups1[357464]: Device not supported!<br>
> ><br>
> > My ips.conf has:<br>
> > [ups1]<br>
> > driver = nutdrv_qx<br>
> > port = auto<br>
> > vendorid=0001<br>
> > productid=0000<br>
> > protocol=hunnox<br>
> > novendor<br>
> > noscanlangid<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Nut-upsuser mailing list<br>
> > <a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a> <mailto:<a href="mailto:Nut-upsuser@alioth-" target="_blank">Nut-upsuser@alioth-</a><br>
> <a href="http://lists.debian.net" rel="noreferrer" target="_blank">lists.debian.net</a>> <mailto:<a href="mailto:Nut-upsuser@alioth-" target="_blank">Nut-upsuser@alioth-</a> <mailto:<a href="mailto:Nut-" target="_blank">Nut-</a><br>
> upsuser@alioth-><br>
> > <a href="http://lists.debian.net" rel="noreferrer" target="_blank">lists.debian.net</a> <<a href="http://lists.debian.net" rel="noreferrer" target="_blank">http://lists.debian.net</a>>><br>
> > <a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-</a><br>
> upsuser <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/</a><br>
> nut-upsuser><br>
> > <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/</a><br>
> nut-upsuser <<a href="https://alioth-lists.debian.net/cgi-bin/mailman/" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/</a><br>
> listinfo/nut-upsuser>><br>
> ><br>
> </blockquote></div>