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@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
<[email protected]> 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
<[email protected]> 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@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
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
