On Dec 20, 2017, at 10:32 AM, Ken Olum wrote:
>   0.090564    find_nut_info: unknown info type: load.on.delay
>   0.090577    find_nut_info: unknown info type: load.on.delay
>   0.090585    Initiating UPS shutdown
>   0.090593    upsdrv_shutdown...
>   0.090601    instcmd(shutdown.return, [NULL])
>   0.090614    find_nut_info: unknown info type: shutdown.return
>   0.090624    instcmd(load.on.delay, [NULL])
>   0.090633    find_nut_info: unknown info type: load.on.delay
>   0.090641    instcmd: info element unavailable load.on.delay
>   0.090649    instcmd(shutdown.reboot, [NULL])
>   0.091107    upsdrv_cleanup...

Sorry, I missed this part from the "-k" output. This at least seems to explain 
the 10-second delay. Here's what I think is going on:

NUT looks up the "shutdown.return" ("Turn off the load and return when power is 
back") command, and finds nothing that matches your UPS. Then it tries 
"load.on.delay" - same problem. It then finds the path for "shutdown.reboot", 
which is most likely mapped to this line: 
(IIRC it's the first match, otherwise it would be 

That sends a value of 10 (likely corresponding to the 10-second delay) to 

The fact that there is not a "UPS.OutletSystem.Outlet.DelayBeforeStartup" or 
"UPS.OutletSystem.Outlet.TLDelayBeforeStartup" in the debug output for your UPS 
means that the "wait for power" functionality is probably hidden behind 
something else, possibly another vendor-specific item (see, for instance, 
"UPS.OutletSystem.Outlet.ffff00bc" and the other ffff* names after 

To be honest, if you can set up the Tripp-Lite software somewhere temporarily 
(possibly an older laptop, or maybe even in a VM - though VMs have their own 
issues), that might be the quickest way to get the behavior you are looking 
for. You could set absurdly large shutdown timers, and fire up usbhid-ups in 
debug mode to watch the counters. I think that would be safer than trying to 
set various vendor-specific items to random values.
Nut-upsuser mailing list

Reply via email to