<div dir="ltr"><div>Hello,</div><div><br></div><div> You mention that you've tried restarting the "nut-server" - I suppose you mean literally, the service unit by such name - of the NUT data server. Did you try restarting the unit for the NUT driver (e.g. `systemctl restart nut-drvier@upsname` with NUT v2.8.x and newer)?</div><div><br></div><div> You did not mention the driver used, but I wonder if that driver program "latches" the RB value when it goes bad and never updates it?.. This could make sense when UPS battery replacement means server downtime, but that is just a subset of real-life cases - so generally can be just an oversight. For example, `bcmxcp` code seems to only set `bcmxcp_status.alarm_replace_battery=1` (oddly neither the field nor struct is ever initialized to 0, so might be garbage on some systems/compilers that do not zero-out aggregate types by default).</div><div><br></div><div>Jim</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jun 30, 2025 at 7:53 PM Vyasa via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net">nut-upsuser@alioth-lists.debian.net</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"><u></u>
<div>
<p>Hello,</p>
<p>CONFIGURATION:<br>
</p>
<p>I am using a Powerware PW9120 3000i, on a network configuration
with a server and a couple of slaves. <br>
</p>
<p>The nut-server OS is <i>Debian 12 (6.1.0-37-amd64)</i>. Nut was
installed from the Debian repo with version <i>2.8.0-7 amd64</i>,
and client has the same version.</p>
<p>UPS is connected with a standard RS232 serial connection, and
works with all standard commands and functionality.</p>
<p>Command "<i>upscmd -l upsname</i>" provides the following, where
I have successfully used <i>test.battery.start</i> and <i>test.system.start</i>:</p>
<p>beeper.disable - Disable the UPS beeper<br>
beeper.enable - Enable the UPS beeper<br>
beeper.mute - Temporarily mute the UPS beeper<br>
load.on - Turn on the load immediately<br>
outlet.1.load.off - Turn off the load on outlet 1 immediately<br>
outlet.1.load.on - Turn on the load on outlet 1 immediately<br>
outlet.1.shutdown.return - Turn off the outlet 1 and return when
power is back<br>
outlet.2.load.off - Turn off the load on outlet 2 immediately<br>
outlet.2.load.on - Turn on the load on outlet 2 immediately<br>
outlet.2.shutdown.return - Turn off the outlet 2 and return when
power is back<br>
shutdown.return - Turn off the load and return when power is back<br>
shutdown.stayoff - Turn off the load and remain off<br>
test.battery.start - Start a battery test<br>
test.system.start - Start a system test<br>
</p>
<p>ISSUE:</p>
<p>Every couple of years when I have to replace batteries in the
UPS, I get an issue with not being able to clear the REPLBATT
alert. That is not until I reboot the server running NUT-SERVER.
This might seem as not a big deal, but becomes a hassle when
batteries haven't quite failed yet and are still good after a ups
battery test.</p>
<p>The UPS itself reports OK after battery replacement or battery
test, and clears alarm on its LCD. But when I poll the UPS data
using "upsc upsname" I still see the RB or REPLBATT and this will
not clear until I reboot the server. So without reboot the alert
will then be generated based on RBWARNTIME in upsmon.conf, which
is as per nut design.<br>
</p>
<p>So without reboot I always get the RB flag with status:</p>
<i>Alert type: REPLBATT</i><br>
<i>............</i><br>
<i>ups.status: OL RB</i><br>
<i>ups.test.result: Done and passed</i><br>
<p>After reboot of server the alert is cleared:</p>
<i>Alert type: COMMOK<br>
............<br>
ups.status: OL<br>
ups.test.result: Done and passed</i><br>
<p>So my question becomes, why is this reboot required and it
doesn't seem to make any sense? I can't understand why the polled
data from a UPS would change after a reboot, while on the UPS LCD
its reporting all OK? I tried restarting NUT-SERVER to see if it
would make any difference. Also, the command test.battery.start
will clear the alarm on the UPS if battery test good.</p>
<p>The only explanation that I have come up with is that the
persistent RB/REPLBATT is latched to this condition and is an
artifact of UPS to NUT handshaking.<br>
</p>
<p>Any feedback would be kindly appreciated, as I have searched and
searched.</p>
<p>Thank you!<br>
</p>
Vyasa<br>
</div>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>