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

Hello! I'm a total noob in the NUT world, and have 0 experience dealing
with Linux distributions. Since NUT is poorly ported to Windows it's
driving me crazy, I hope you can help me.

I have, after 3 days of painful reading, testing and failing, successfully
set up NUT to communicate with my cheap-ass line-interactive 1000VA Chinese
UPS (just no brand at all, it is a locally rebranded UPS, i'm from
Argentina). Its a basic setup of an UPS powering a desktop PC which needs
to be shut down in case of a power failure, and I would like the UPS to
power off as well the preserve battery life as much as possible (via
shutdown.return).

My set up uses the blazer_usb driver and the Megatec protocol. I'm using
latest NUT port for Windows; 2.6.5-3.

I've successfully configured UPSMON to monitor the UPS status, and do the
shutdown procedure by calling the SHUTDOWNCMD on a simple bat file I've
made. This bat file is as follows:

cd C:\Program Files (x86)\NUT\bin
blazer_usb -a HAMUPS -k
pause

So this should send the shutdown command to the UPS and start the shutdown
timer (I've not added the Windows shutdown part to the bat file yet). The
problem is that BLAZER_USB sends the command "shutdown_stop" three
times to
the router and then reports a SHUTDOWN FAILED:

Initiating UPS shutdown
instcmd: command [shutdown.stop] failed
instcmd: command [shutdown.stop] failed
instcmd: command [shutdown.stop] failed
Shutdown failed!

This problem has already been addressed and supposedly corrected in latest
builds, as seen in here:
http://t38832.monitoring-nut-development.monitoringtalk.info/problems-with-blazer-usb-driver-will-not-shut-down-myups-t38832.html

So, how can I solve this? Is there a way to tell BLAZER_USB to only send
the command "SHUTDOWN.RETURN"? How can I get or build the latest
version of
BLAZER_USB for the windows port?

Thank you so much!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150403/622fef88/attachment.html>

On Apr 3, 2015, at 1:54 PM, Humberto M?ckel <hamberthm at gmail.com>
wrote:
> I've successfully configured UPSMON to monitor the UPS status, and do
the shutdown procedure by calling the SHUTDOWNCMD on a simple bat file I've
made. This bat file is as follows:
> 
> cd C:\Program Files (x86)\NUT\bin
> blazer_usb -a HAMUPS -k
> pause
> 
> So this should send the shutdown command to the UPS and start the shutdown
timer (I've not added the Windows shutdown part to the bat file yet). The
problem is that BLAZER_USB sends the command "shutdown_stop" three
times to the router and then reports a SHUTDOWN FAILED:
> 
> Initiating UPS shutdown
> instcmd: command [shutdown.stop] failed
> instcmd: command [shutdown.stop] failed
> instcmd: command [shutdown.stop] failed
> Shutdown failed!
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.
> This problem has already been addressed and supposedly corrected in latest
builds, as seen in here:
http://t38832.monitoring-nut-development.monitoringtalk.info/problems-with-blazer-usb-driver-will-not-shut-down-myups-t38832.html
> 
> So, how can I solve this? Is there a way to tell BLAZER_USB to only send
the command "SHUTDOWN.RETURN"?
Rather than calling the driver with "-k", you can leave upsd and the
driver running, and call "upscmd -u user -p pass HAMUPS
shutdown.return". You may want to test this with the computer powered from
another source, since this might not have a delay before the power is removed.
> How can I get or build the latest version of BLAZER_USB for the windows
port?
I seem to recall that NUT for Windows was built with mingw before. If you can
get that set up, we could probably help backport the changes, but note that the
blazer* driver is no longer actively maintained (replaced by nutdrv_qx, which I
do not believe was ever ported to Windows).

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150403/0e20de1a/attachment-0001.html>

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),
NOTIFYMSG ONBATT "battoff", and NOTIFYFLAG ONBATT SYSLOG+EXEC.
NOTIFYCMD
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*
shutdown.stayoff
*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.

Cheers!

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>