I’m using the UPS service to monitor the state of my UPS from an application — the key at HKLM\SYSTEM\CCS\Services\UPS\Status has all the information you can get from the Power control panel. BUT — I’d like to be able to tell the UPS to shut down from my app as well. I know that the service can tell the UPS to shut down — for instance, after running a set number of minutes on battery — and I’m wondering if there’s some kind of command I can send to the service to initiate a shutdown manually.
I’m having trouble searching for this information — people tend to misspell ‘Uninterruptible’ (hrm, Firefox red-lined that but doesn’t have an alternative) and ‘UPS’ just gets hits for the shipping service. Maybe I can do something through System.ServiceController, or WMI?
CLARIFICATION: Yes, I am talking about powering down the physical UPS device. I know how to stop the service. I figured it would be a common problem — I want my UPS to turn off with the PC. I had an idea I’m going to try, based on this page. You see, APC (and everybody else) has to supply a DLL for the UPS service to call, and since the function calls are well documented, there’s no reason I shouldn’t be able to P/Invoke them. I’ll re-edit this once I know whether or not it worked.
Update: I tried invoking UPSInit, then UPSTurnOff, and nothing happens. I’ll tinker with it some more, but the direct call to apcups.dll might be a dead end.
OK, I have the answer (tested!), but it’s not pretty. My APC UPS communicates using the APC ‘Smart’ protocol (more here). What you need in my case is a ‘soft shutdown’, ‘S’ command. But first you need to make sure it’s in ‘Smart’ mode (‘Y’). Now, if you want to let the Windows UPS service monitor state, the service will have an iron grip on the COM port. So you can either a) let the Windows service turn the UPS off, or b) kill the service and turn the UPS off yourself.
The UPS itself has a ‘grace period’ after it gets the ‘S’ command, giving you time to shut down your OS. This means that to do (a) above, you have to:
I think we’re going to opt for (a), just because (b) involves extra work killing the service and implementing the serial comms.