<div dir="ltr"><div>So, I got to a computer tonight to check for a bit more detail:<br><br></div><div>* the higher-frequency polling is POLLFREQALERT setting. By built-in default (if not configured) it is actually same as POLLFREQ default, both at 5 sec.</div><div>* the FSD upon connection loss is issued in several cases, some unilaterally, others can be managed by options like ALARMCRITICAL 0 (UPS lost while an ALARM of whatever nature was raised)</div><div>* the message wording "was last known to be not fully online and currently is not communicating, assuming dead" is not present in current NUT code base; instead it now reports waiting for DEADTIME to expire - see <a href="https://github.com/networkupstools/nut/blame/master/clients/upsmon.c#L1544-L1548">https://github.com/networkupstools/nut/blame/master/clients/upsmon.c#L1544-L1548</a> and dig history from there to your installed NUT version</div><div>** Message introduced at <a href="https://github.com/networkupstools/nut/commit/2647f026f7f0c856926da67cec845a09bed2a5d1">https://github.com/networkupstools/nut/commit/2647f026f7f0c856926da67cec845a09bed2a5d1</a> for <a href="https://github.com/networkupstools/nut/issues/2104">https://github.com/networkupstools/nut/issues/2104</a> and released in NUT v2.8.1 </div><div>** Changed to current in several PRs and commits, finally in <a href="https://github.com/networkupstools/nut/commit/82e5932d9c4b589856746d31835ee50da3185ce8">https://github.com/networkupstools/nut/commit/82e5932d9c4b589856746d31835ee50da3185ce8</a> for <a href="https://github.com/networkupstools/nut/issues/2454">https://github.com/networkupstools/nut/issues/2454</a> I think, and released in NUT v2.8.3</div><div><br></div><div>By cursory look, maaaybe those issues discuss the problems you saw, from another point of view. At least if you have NUT v2.8.1 or v2.8.2 there.</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 Wed, Dec 24, 2025 at 3:39 PM Michael Hughes 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">On Wed, 24 Dec 2025 12:02:15 +0100<br>
Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" target="_blank">jimklimov+nut@gmail.com</a>> wrote:<br>
> > I'm having problems with one of my UPS (BEST MD500), the upsd has<br>
> > stale data, we get a power hit and upsmon give the following<br>
> > message:<br>
> ><br>
> > upsmon[918]: UPS [UPS1@localhost] was last known to be not fully<br>
> > online and currently is not communicating, assuming dead<br>
> ><br>
> > upsmon starts a shutdown and then upsd gives a data is no longer<br>
> > stale, but the shutdown still happens. Or a way to have upsmon<br>
> > wait awhile before starting the shutdown?<br>
> ><br>
> > Is there someway to stop the shutdown when this happens? I'm still<br>
> > debugging why the driver is loosing communication with the UPS.<br>
> > --<br>
> > Michael<br>
> > _______________________________________________<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>
> > <br>
> Cheers, and happy holidays.<br>
> <br>
> I am not sure your logs here show the whole picture. For upsmon to<br>
> behave this way, thee must have been a power event and the driver<br>
> told the data server the UPS is on battery. Pollfreq increases too<br>
> (time delay decreases). If the UPS connection gets lost then, this is<br>
> deemed immediately critical as we don't know how long the system can<br>
> be up. Maybe battery is old and does not fit its spec or latest<br>
> calibration. So we issue FSD to save as much as we can ASAP.<br>
> <br>
> Need to check in code if there are now any throttle toggles for<br>
> this.<br>
> <br>
> And then if shutdown did begin, generally the only way to bring the<br>
> system back up consistently is to reboot it one way or another. Your<br>
> custom SHUTDOWNCMD implementation may do whatever fits your case<br>
> though.<br>
> <br>
> Hope this helps,<br>
> Jim Klimov<br>
> <br>
> <br>
> On Tue, Dec 23, 2025, 21:54 Michael Hughes via Nut-upsuser <<br>
> <a href="mailto:nut-upsuser@alioth-lists.debian.net" target="_blank">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br>
> <br>
<br>
Jim,<br>
Yes, there was a power outage message before the lost communication.<br>
<br>
I had thought about changing the poll interval since the communication<br>
is done through RS-232.<br>
<br>
<br>
-- <br>
Michael<br>
_______________________________________________<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>