[Nut-upsuser] Problems with APC Smart-UPS Series

[Jim Klimov]

Cheers,

  Regarding new SNMP mappings - yes, you can also do it yourself and post a
PR (see NUT docs about adding a subdriver for snmp-ups).

  On other points:

* "OB" was the default value in that driver until told otherwise, fixed
after 2.8.4
* You might have some luck with apc_modbus, but you would need a custom
build of NUT against a custom  build of libmodbus from our fork (see wiki),
and there are raised tickets (#2609 notably) that it did not work for
everyone and every case.

Hope thia helps,
Jim


On Mon, Jan 12, 2026, 23:46 Sebastian Holzapfel via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:

> Ok, so I ask for help.
> I was able to configure through usbhid-ups driver my APC Smart-UPS SRT
> 3000XLA, however the driver reports that the UPS is on-baterry all the time
> despite that it's actually on-line. Searching over the internet I have
> found that actually drivers for APC usually use proprietary power flags and
> fails to refresh the standard powerflags used by NUT.
> For example this is an actual capture of the state that NUT reports that
> the UPS is:
> # upsc ups at A.B.C.D
> device.mfr: American Power Conversion
> device.model: Smart-UPS SRT
> device.serial: AS183929XXXX
> device.type: ups
> driver.debug: 0
> driver.flag.allow_killpower: 0
> driver.name: usbhid-ups
> driver.parameter.interrupt_pipe_no_events_tolerance: -1
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.synchronous: auto
> driver.state: quiet
> driver.version: 2.8.4
> driver.version.data: APC HID 0.100
> driver.version.internal: 0.67
> driver.version.usb: libusb-1.0.27 (API: 0x0100010A)
> ups.firmware: UPS 06.0 / ID=1010
> ups.mfr: American Power Conversion
> ups.model: Smart-UPS SRT
> ups.productid: 0003
> ups.serial: AS183929XXXX
> ups.status: OB
> ups.vendorid: 051d
>
> See, there is not even any power information, and it says that is
> on-battery where actually it isn't.
> Now, this is a common problem known with this UPS's. Mostly, everyone who
> has faced this problem has resorted to buying the SNMP network module of
> the UPS, but the problem is that this optional unit isn't available on my
> country so I'm out of luck with that and forced to still use the USB
> interface.
> Now, the new version of the original software that manages this UPS,
> called PowerChute Serial Shutdown, actually may act as an SNMP server but
> uses its own sets of OID's rather than the universally standard ones. I
> don't know how it can manage Synology but it's able to actually
> understand the SNMP OID's that PowerChute servers and can get the true info
> of the probable battery backup time, the load and almost everything;
> despite that Synology DOES use under the hood NUT too but with some major
> modification (the service is not officially called NUT but it is NUT given
> the hidden config that is under /usr/syno/etc/ups/ is the same structure as
> is), maybe this modifications that they do are able to make this units
> compatible with PowerChute Serial Shutdown, who knows? Probably it is,
> since I tried to configure NUT to get the states through PowerChute using
> the snmp driver but it was unsuccessful to read what the software reported.
> Anyways, if I do an snmpwalk to get the PowerChute OID's of the SNMP
> server that has and I can provide what the values stands for, can the MIB's
> be added to the SNMP driver on NUT for a newer release?
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20260113/c2c91998/attachment-0001.htm>