[Nut-upsuser] POWERCOM UPS USB : UPS Shutdown

Fri May 16 10:53:15 BST 2025

I remembered that this also applied to CentOS 6.10 and the NUT version 
was older. This is how the system works now:
$ upsc bnt400 at localhost
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 30
battery.date: 2014/01/15
battery.runtime: 800
battery.type: PbAc
device.mfr: POWERCOM Co.,LTD
device.model: HID UPS Battery
device.serial: 004-0D9F-000
device.type: ups
driver.name: usbhid-ups
driver.parameter.offdelay: 20
driver.parameter.ondelay: 30
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.vendor: 0d9f
driver.version: 2.6.5
driver.version.data: PowerCOM HID 0.3
driver.version.internal: 0.37
input.frequency: 50.0
input.voltage: 228.0
input.voltage.nominal: 220
output.frequency: 50.0
output.voltage: 228.0
output.voltage.nominal: 220
ups.beeper.status: enabled
ups.date: 2014/01/15
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 17
ups.mfr: POWERCOM Co.,LTD
ups.model: HID UPS Battery
ups.productid: 0004
ups.serial: 004-0D9F-000
ups.status: OL
ups.test.result: Done and passed
ups.timer.shutdown: 0
ups.timer.start: 0
ups.vendorid: 0d9f
But there is one with the same settings and it doesn't work right now 
(NUT ) (
But on these systems I did not make any changes to the NUT startup 
script settings.

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/02dd3a68/attachment.htm>