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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251223/f9e10f30/attachment.sig>
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:> 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251224/291c5369/attachment.htm>
Regarding connection loss as such, ages ago I've had an UPS whose controller rebooted or something like that when inverter went on/off, causing a reconnection and different numbers like (significantly) decreased battery charge and runtime left. This does not quite fit your case of knowing OB state though. Jim On Tue, Dec 23, 2025, 21:54 Michael Hughes via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251224/afeb91d5/attachment.htm>