<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I removed the usbhid-ups driver from the original NUT package for
Devuan and installed your version in its place. It works fine. Not
sure if there will be any problems because of this. I understand
that with the kernel change, this driver will have to be recompiled
until your version of usbhid-ups reaches the distribution developer.
And this can be a very long time ( But due to the systemd emulation
in Devuan, I could not get your version of NUT to work correctly
when the UPS shutdown procedure (scripts) is started.<br>
<br>
<br>
<div class="moz-cite-prefix">16.05.2025 11:51, Jim Klimov:<br>
</div>
<blockquote type="cite"
cite="mid:CAJYg8vKu3oa6PfP46u+MMw+UHUkcQSornnki=v+YU7Oh5Yjcaw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Thanks for the tip. Feel free to share the details in NUT
Wiki or post a PR for `srcipts/...` (either existing or a new
subdirectory if the init-scripts or equivalent that you have
is rather Devuan-specific).</div>
<div><br>
</div>
<div>Does the distro have any mechanism equivalent to systemd
udev, to assign devfs node permissions as devices are
(re)discovered? NUT sources generate configurations for quite
a few such sub-systems (devd, upower, hotplug, BSD quirks...)
and it may be possible to extend tools/<a
href="http://nut-usbinfo.pl" moz-do-not-send="true">nut-usbinfo.pl</a>
to add more. Some such subsystems are able to also react to HW
changes by running custom handler programs - e.g. a restart of
a NUT driver, which may also help.</div>
<div><br>
</div>
<div>Alternately, IF the problem is just about permissions and
not so much the USB layer, this can be checked (and/or worked
around) by running the driver program as `root` without
dropping privileges (`-u root` or `-x user=root` on command
line, or `user=root` in `ups.conf`). This is not something
normally recommended to keep for a long time (the fewer
privileged processes are running - the better) but can at
least confirm or rule out some failure modes.</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, May 16, 2025 at
10:40 AM Alexey Korobeinikov <<a
href="mailto:alexey@fseafood.com" moz-do-not-send="true"
class="moz-txt-link-freetext">alexey@fseafood.com</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">
<div> I observed this behavior with several Powercom UPSs (BNT
400/600/1000) new and old on different computers. It didn't
matter. Even replacing USB cables or switching to another
port didn't give stable results. Only usbreset and
immediately restarting/starting the service gave about 90%
result. Therefore, I slightly changed the startup script in
the system so that if the required VendorID:DeviceID was
available, this port would be restarted and NUT would be
started immediately.<br>
<br>
<div>16.05.2025 11:16, Jim Klimov:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Well, it is always (quite) possible that the
hardware is... subpar, leading to loss of connection.</div>
<div><br>
</div>
<div>Try a different USB port (maybe on a different MoBo
hub if there's a choice), different cable (check if
you have a shielded/grounded one to minimize EMI
noise), revise if there are any motors (fridges,
dishwashers) or luminescent lighting starters etc.
nearby on the electric line and physically near the
cabling, etc.</div>
<div><br>
</div>
<div>Maybe there is some vendor-provided way to update
the UPS firmware?</div>
<div><br>
</div>
<div>You mentioned the device may be from 2017 - maybe
it collected a lot of dust over time and just
overheats or has random static discharge inside - so
some internal physical maintenance with a toothbrush,
vacuum cleaner, and proper electrotechnical hygiene
for your safety could also do wonders? On similar
note, is the battery also as old? PbAc tend to not
live that long, maybe replacing it could stabilize
things.</div>
<div><br>
</div>
<div>Jim</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, May 16, 2025
at 9:41 AM Alexey Korobeinikov <<a
href="mailto:alexey@fseafood.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">alexey@fseafood.com</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">
<div> On Devuan Linux daedalus (no systemd).<br>
I try to manualy start nut-service or just
usbhid-ups drivers. I have observed such problems
before.<span lang="en"><span><span> They were solved
by usbreset </span></span></span><span
style="font-family:monospace"><span
style="color:rgb(0,0,0);background-color:rgb(255,255,255)">on this
device (0d9f:0004</span>) and</span><span
lang="en"><span><span> immediately launch</span></span></span><span></span>
nut-service/drivers. But sometimes it wasn't
necessary to do that.<br>
<br>
<br>
<div>16.05.2025 00:01, Jim Klimov:<br>
</div>
<blockquote type="cite">
<div dir="auto">Are you on Linux? Did you check if
NDE created a service instance like
`nut-driver@UPS` that starts automatically and
your manually started driver instance tries to
steal from it?
<div dir="auto"><br>
</div>
<div dir="auto">* <a
href="https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)</a></div>
<div dir="auto"><br>
</div>
<div dir="auto">Jim</div>
</div>
</blockquote>
<br>
<pre cols="72">--
З Повагою
Коробейніков Олексій
Системний адміністратор
ТОВ "Флагман Сіфуд"
вул. Броварська 152, смт Велика Димерка
Київська область, 07442
р.+38 044 495-88-00
вн.6101
м.+38 067 994-40-48</pre>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre cols="72">--
З Повагою
Коробейніков Олексій
Системний адміністратор
ТОВ "Флагман Сіфуд"
вул. Броварська 152, смт Велика Димерка
Київська область, 07442
р.+38 044 495-88-00
вн.6101
м.+38 067 994-40-48</pre>
</div>
</blockquote>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
З Повагою
Коробейніков Олексій
Системний адміністратор
ТОВ "Флагман Сіфуд"
вул. Броварська 152, смт Велика Димерка
Київська область, 07442
р.+38 044 495-88-00
вн.6101
м.+38 067 994-40-48</pre>
</body>
</html>