[Nut-upsuser] I'm new to NUT in Windows, having problems with blazer_usb doing an UPS shutdown

Humberto Möckel hamberthm at gmail.com
Sat Apr 4 03:58:56 UTC 2015

Hi Charles, thank you SO MUCH for your answer! *Today I got the system
running OK with PC & UPS shutting down normally!! :*

One caveat with running "<driver> -k" from a SHUTDOWNCMD is that the
> existing driver will probably still be running. I don't know how the
> Windows port of NUT handles exclusive access to USB devices, but it is
> possible that this is causing the failure.

Nope. I'm pretty sure the UPS gets the shutdown.stop command the driver
sends. I know that because I can successfully send a shutdown.stayoff
command via UPSCMD, as you said. That would power off the UPS after the
delay time, but it will cancel if I make a force shutdown via "upsmon -c
fsd", because UPSMON uses the driver's shutdown process and submits the
shutdown.stop after setting the shutdown flag file.

I erased the shutdown flag file config in the upsmon.config file and since
then I can force shutdown UPSMON without it setting the shutdown flag file
and thus making the driver shutdown that cancels the UPS timer.

This is what I mean:

· Submit "upscmd -u *user* -p *pass* HAMUPS shutdown.stayoff" > Wait delay
time > UPS shuts down immediately and suddenly powers off PC. (For some
reason, shutdown.return doesn't work in my UPS)
· Submit "upscmd -u *user* -p *pass* HAMUPS shutdown.stayoff" > "upsmon -c
fsd" with shutdown flag setting on > upsmon creates the flag file, shuts
services down and then do the driver shutoff sending the "shutdown.stop"
three times > UPS cancels shutdown timer > System shuts down via
SHUTDOWNCMD > UPS will stay ON until battery dies
· Submit "upscmd -u *user* -p *pass* HAMUPS shutdown.stayoff"  > "upsmon -c
fsd" with shutdown flag file setting OFF > upsmon won't plant the flag file
and won't make a driver shutdown, but closes services and runs
SHUTDOWNCMD > System shuts down > UPS shuts down after delay time.

I managed to get the third behavior as follows:

Having POWERDOWNFLAG setting off (no line written in upsmon.conf),
and SHUTDOWNCMD point to two separate BAT scripts on my drive. Using
upscmd, this is my shutdown design (early shutdown following ONBATT event):

1- Power goes off. Upsmon does a* onbatt notify *event calling my 1st bat
file, with *"battoff"* as an argument.
2- 1st bat file contains a DOS script that compares the received argument
to "battoff" string. If it's other than "battoff" it ignores it (to
avoid notify events other than ONBATT to trigger the shutdown). If the
parameter equals to "battoff" it firsts switches to *bin* directory
and sends the "upscmd -u *user* -p *pass* HAMUPS shutdown.stayoff" command
starting the UPS's timer. Then it switches to *sbin* directory and submits
"upsmon -c fsd".
3- Upsmon receives the force-shutdown command. Since POWERDOWNFLAG is not
specified, it won't set it or do a driver UPS shutdown that cancels the
timer (nevermind because the timer is already going thanks to the*
*command submitted by first bat file). Upsmon closes services, and uses
SHUTDOWNCMD that calls my 2nd bat script.
4- 2nd bat script is a simple one; it calls Windows *shutdown *command with
an specified delay time and an user message.
5- System shuts down, followed by the UPS after the timer ends.
6- The entire system and UPS remain off until power goes up again. For some
reason my UPS will turn on after power restores, thus acting like it has
received the "shutdown.return" instead of the "shutdown.stayoff" command.
This is the behavior I was looking for anyway!

So, it has been an adventure searching a workaround for the driver shutdown
failure. I hope I was clear enough and that this will help other people
with the same problem. Please correct me if i'm wrong at something, as I
don't know very well how NUT behaves on all situations.


PS: Only one issue is left: If you use NOTIFYCMD to send messageboxes to
the user, it won't work, because Windows services don't have an UI layer
and wont be visible. This is also a known issue as I read somewhere else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150404/1b94f056/attachment.html>

More information about the Nut-upsuser mailing list