So, I got to a computer tonight to check for a bit more detail:
* 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.
* 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)
* 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
https://github.com/networkupstools/nut/blame/master/clients/upsmon.c#L1544-L1548
and dig history from there to your installed NUT version
** Message introduced at
https://github.com/networkupstools/nut/commit/2647f026f7f0c856926da67cec845a09bed2a5d1
for https://github.com/networkupstools/nut/issues/2104 and released in NUT
v2.8.1
** Changed to current in several PRs and commits, finally in
https://github.com/networkupstools/nut/commit/82e5932d9c4b589856746d31835ee50da3185ce8
for https://github.com/networkupstools/nut/issues/2454 I think, and
released in NUT v2.8.3
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.
Jim
On Wed, Dec 24, 2025 at 3:39?PM Michael Hughes via Nut-upsuser <
nut-upsuser at alioth-lists.debian.net> wrote:
> On Wed, 24 Dec 2025 12:02:15 +0100
> Jim Klimov <jimklimov+nut at gmail.com> wrote:
> > > I'm having problems with one of my UPS (BEST MD500), the upsd
has
> > > stale data, we get a power hit and upsmon give the following
> > > message:
> > >
> > > upsmon[918]: UPS [UPS1 at localhost] was last known to be not
fully
> > > online and currently is not communicating, assuming dead
> > >
> > > upsmon starts a shutdown and then upsd gives a data is no longer
> > > stale, but the shutdown still happens. Or a way to have upsmon
> > > wait awhile before starting the shutdown?
> > >
> > > Is there someway to stop the shutdown when this happens? I'm
still
> > > debugging why the driver is loosing communication with the UPS.
> > > --
> > > Michael
> > > _______________________________________________
> > > Nut-upsuser mailing list
> > > Nut-upsuser at alioth-lists.debian.net
> > >
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
> > >
> > Cheers, and happy holidays.
> >
> > I am not sure your logs here show the whole picture. For upsmon to
> > behave this way, thee must have been a power event and the driver
> > told the data server the UPS is on battery. Pollfreq increases too
> > (time delay decreases). If the UPS connection gets lost then, this is
> > deemed immediately critical as we don't know how long the system
can
> > be up. Maybe battery is old and does not fit its spec or latest
> > calibration. So we issue FSD to save as much as we can ASAP.
> >
> > Need to check in code if there are now any throttle toggles for
> > this.
> >
> > And then if shutdown did begin, generally the only way to bring the
> > system back up consistently is to reboot it one way or another. Your
> > custom SHUTDOWNCMD implementation may do whatever fits your case
> > though.
> >
> > Hope this helps,
> > Jim Klimov
> >
> >
> > On Tue, Dec 23, 2025, 21:54 Michael Hughes via Nut-upsuser <
> > nut-upsuser at alioth-lists.debian.net> wrote:
> >
>
> Jim,
> Yes, there was a power outage message before the lost communication.
>
> I had thought about changing the poll interval since the communication
> is done through RS-232.
>
>
> --
> Michael
> _______________________________________________
> 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/20251224/38449dca/attachment.htm>