[Nut-upsuser] POWERCOM UPS USB : UPS Shutdown

[Alexey Korobeinikov]

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.


16.05.2025 11:51, Jim Klimov:
> 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).
>
> 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/nut-usbinfo.pl <http://nut-usbinfo.pl> 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.
>
> 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.
>
> Hope this helps,
> Jim Klimov
>
>
>
> On Fri, May 16, 2025 at 10:40 AM Alexey Korobeinikov 
> <alexey at fseafood.com> wrote:
>
>     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.
>
>     16.05.2025 11:16, Jim Klimov:
>>     Well, it is always (quite) possible that the hardware is...
>>     subpar, leading to loss of connection.
>>
>>     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.
>>
>>     Maybe there is some vendor-provided way to update the UPS firmware?
>>
>>     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.
>>
>>     Jim
>>
>>
>>     On Fri, May 16, 2025 at 9:41 AM Alexey Korobeinikov
>>     <alexey at fseafood.com> wrote:
>>
>>         On Devuan Linux daedalus (no systemd).
>>         I try to manualy start nut-service or just usbhid-ups
>>         drivers. I have observed such problems before.They were
>>         solved by usbreset on this device (0d9f:0004) andimmediately
>>         launchnut-service/drivers. But sometimes it wasn't necessary
>>         to do that.
>>
>>
>>         16.05.2025 00:01, Jim Klimov:
>>>         Are you on Linux? Did you check if NDE created a service
>>>         instance like `nut-driver at UPS` that starts automatically and
>>>         your manually started driver instance tries to steal from it?
>>>
>>>         *
>>>         https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)
>>>
>>>         Jim
>>
>>         -- 
>>         З Повагою
>>         Коробейніков Олексій
>>         Системний адміністратор
>>
>>         ТОВ "Флагман Сіфуд"
>>         вул. Броварська 152, смт Велика Димерка
>>         Київська область, 07442
>>         р.+38 044 495-88-00
>>         вн.6101
>>         м.+38 067 994-40-48
>>
>
>     -- 
>     З Повагою
>     Коробейніков Олексій
>     Системний адміністратор
>
>     ТОВ "Флагман Сіфуд"
>     вул. Броварська 152, смт Велика Димерка
>     Київська область, 07442
>     р.+38 044 495-88-00
>     вн.6101
>     м.+38 067 994-40-48
>

-- 
З Повагою
Коробейніков Олексій
Системний адміністратор

ТОВ "Флагман Сіфуд"
вул. Броварська 152, смт Велика Димерка
Київська область, 07442
р.+38 044 495-88-00
вн.6101
м.+38 067 994-40-48
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20250516/e07b266e/attachment.htm>