WinNUT ignores Shutdown on FSD Signal option, always shuts down

[MichaelSchemmer]

Hi there,

I've installed NUT on a RPi and connected it to an APC Backups UPS.
For testing purposes I've set override.battery.charge.low = 95 and it shut's down once it hits 95% or lower.
On the WinNut side (running Pre-Release v2.2.8331), I've set a laptop to shutdown once battery drops below 98%. This works.
However, when I plug the UPS back in to grid power, I boot up my laptop and run WinNut. The UPS reports correctly as online and not on battery, but the battery is still obviously below 95%, in my case 91%, so the laptop shuts down again. Shouldn't it be the case that if the UPS is Online, even though the battery is low and charging that the device running Winnut then doesn't shutdown or have I misconfigured something?

Thanks

[gbakeman]

Hi @MichaelSchemmer, thank you for the detailed testing and report. You're right that WinNUT should be staying up if the UPS reports an online status. Would you mind attaching a log, specifically focusing on the point where the UPS is online, but WinNUT initiates a suspend operation anyways?

[MichaelSchemmer]

Thanks for the response, here you go:

WinNUT-Client-2022-11-09.log

[gbakeman]

So just going through the log, here's what I see:

07:36:25: WinNUT starts up.
07:36:25: WinNUT connects and authenticates with UPS.
07:36:40: We refresh variables (currently OL,CHRG,LB), and a Full Shut Down is imposed.
07:36:40: The battery status indicates it's charging, and the shutdown GUI begins counting down.
07:36:55: Status is On Line, and Battery OK, while the shutdown timer continues counting down. This is because the Full Shut Down is still imposed.
07:36:58: WinNUT disconnects and suspends the system.

I'm not sure I see where your system comes back up and suspends again, but I'd be willing to bet this bug is related to gawindx/WinNUT-Client#98. When the UPS triggers a Full Shut Down (FSD), the NUT server is designed to treat that status as a latch, meaning it must go down in order to reset. One thing you may want to consider is having your Pi power cycle or at least restart the NUT server when a FSD is called and the UPS is OL again.

Barring that, WinNUT also has an option to ignore the FSD signal entirely:

I've just realized that the code doesn't respect that option, though. I'm going to have a build up in a few minutes so that WinNUT respects it again.

[gbakeman]

Please test the build here and let me know how it goes.

[MichaelSchemmer]

Hi there,
Thanks for the response. The logfile I attached was a new one created and is only for the timespan when the UPS and RPi comes back up after power has been restored. My Rpi is connected directly to the UPS, so that when the UPS goes down, NUT goes down aswell.

I don't have the 'Shutdown on Nut's FSD Signal' enabled and never have...

I decided to download WinNut v2.0.0.4a from https://code.google.com/archive/p/winnut/downloads and it works like a charm.
I set it to shutdown my laptop once the UPS is on battery for 2 minutes. The laptop shuts down and then after a while the UPS and Pi shutdown. Once I restore power and run WinNut, the laptop doesn't shutdown, so its working as intended.
I've also noticed that WinNut v2.0.0.4a version of WinNut, although old can run is a service, which is a requirement for my setup as I run WinNut on a Windows based fileserver, which I don't always want to have to login to run WinNut.
I find the ability to have WinNut shutdown my server after a period of minutes on battey rather than a percentage of battery power quite beneficial aswell. Will this be included in your version in future?

My original setup was to have the Pi connected to a permanent power source ie LifePo UPS and then monitor the APC unit. I understand that the nut daemon on the Pi does tend to time out if the UPS is off for a while or as you explained it, it does require the Nut services to be restarted. (We have power outages between 2 and 4 hours here in South Africa) I still need to do some further testing regarding this as it is beneficial (having the Pi connected to LifePo UPS), if I wanted to run other services on the RPi during outages and it would seem to be a waste just to run Nut on a Pi.

Thanks

[gbakeman]

Hi there, Thanks for the response. The logfile I attached was a new one created and is only for the timespan when the UPS and RPi comes back up after power has been restored. My Rpi is connected directly to the UPS, so that when the UPS goes down, NUT goes down aswell.

I don't have the 'Shutdown on Nut's FSD Signal' enabled and never have...

Ok, I think I understand. For one reason or another, WinNUT was still receiving the FSD signal from the NUT server when it came back up. I'm guessing it's because the UPS battery charge was below its own threshold. Due to the recently discovered bug of WinNUT not respecting the Shutdown on Nut's FSD Signal option, it would shutdown anyways. The older client you tried probably worked fine either because it does respect that option correctly (and it was unchecked), or it doesn't follow FSD signals at all. I bet if you gave the debug build I linked above a try, the current issue will be resolved.

I've also noticed that WinNut v2.0.0.4a version of WinNut, although old can run is a service, which is a requirement for my setup

WinNUT as a service has been a big item on the wishlist, both in terms of desirability and effort to implement. See #46 and gawindx/WinNUT-Client#42 for discussion. I wasn't sure if that would be in the scope right now since I'm in the process of retiring and remaking WinNUT, but I also understand how important this feature is. Stay tuned on that #46 issue and I may implement it in the future. In the meantime, according to that later discussion there may be some third party tools you could use to "hack" WinNUT into running as a service.

I find the ability to have WinNut shutdown my server after a period of minutes on battey rather than a percentage of battery power quite beneficial aswell. Will this be included in your version in future?

This is actually a feature right now. Referring to the screenshot above, you can set the delay to shutdown option to however long you want WinNUT running on battery before it takes the host down gracefully. Typically WinNUT is designed to start this procedure when either the runtime estimation or battery percentage drop below specified levels, but if you set the battery percentage to 100%, then WinNUT should start the countdown almost immediately when your UPS goes on battery. If it comes back online, then the countdown will be aborted.

My original setup was to have the Pi connected to a permanent power source ie LifePo UPS and then monitor the APC unit. I understand that the nut daemon on the Pi does tend to time out if the UPS is off for a while or as you explained it, it does require the Nut services to be restarted. (We have power outages between 2 and 4 hours here in South Africa) I still need to do some further testing regarding this as it is beneficial (having the Pi connected to LifePo UPS), if I wanted to run other services on the RPi during outages and it would seem to be a waste just to run Nut on a Pi.

Yeah, that sounds like a good idea. I think what might be tripping things up though is using the Full Shutdown Threshold on the UPS to manually trigger a shutdown. My suggestion would be to not override the UPS values, but instead modify the client settings as mentioned previously and that should take care of your immediate needs.

[MichaelSchemmer]

Hi,

So, the build you provided works like a charm! Thanks so much!
I'm going to stick to the older version that can run as a service for now and will subscribe to #46 and follow the progress closely.

There is a reason that I override certain UPS values ie override.battery.charge.low By default the battery.charge.low value is 20 on the UPS and I'm going to set mine to something above 50. Reason for this is the UPS battery longevitiy is severly impacted once it drops below 50% and I have to replace battteries every 3 to 6 months. We have power outages on a daily basis for at least 2 hrs, so if the battery runs all the way down to 20%, it'll need replacement more often.

Thanks for all your hard work!

[gbakeman]

Hey, you're welcome. Sorry about the situation, but I'm glad this program is useful. I'll look into the service mode and see what can be done.