[Nut-upsuser] Tripp-Lite BCPERS450 shutdown/restart problems

[Charles Lepple]

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: https://github.com/networkupstools/nut/blob/v2.7.2/drivers/tripplite-hid.c#L394 (IIRC it's the first match, otherwise it would be https://github.com/networkupstools/nut/blob/v2.7.2/drivers/tripplite-hid.c#L397 )

That sends a value of 10 (likely corresponding to the 10-second delay) to UPS.OutletSystem.Outlet.DelayBeforeReboot

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 "*.DelayBeforeShutdown").

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.