On Aug 11, 2013, at 2:12 PM, Александр Безруков wrote: > I see no problem with how the device communicates the Blazer/Megatec protocol. > I must have found a bug in the driver.
It is possible that the shutdown was tested with a different implementation of the protocol. What do you get from the "I" command? On Aug 11, 2013, at 11:25 AM, Александр Безруков wrote: > So I believe the compatibility list deserves two new lines. Probably best to delay adding this to the HCL until we can get the driver to shut down the UPS properly. > # /lib64/nut/blazer_ser -amv -k -DDD > Network UPS Tools - Megatec/Q1 protocol serial driver 1.55 (2.6.5-Unversioned > directory) > 0.000000 debug level is '3' > 0.108370 Initiating UPS shutdown > 0.108561 send: 'C' > 0.150967 read: 'NAK' > 0.151021 instcmd: command [shutdown.stop] failed > 0.151162 send: 'C' > 0.193506 read: 'NAK' > 0.193598 instcmd: command [shutdown.stop] failed > 0.193725 send: 'C' > 0.236016 read: 'NAK' > 0.236093 instcmd: command [shutdown.stop] failed > 0.236127 Shutdown failed! This behavior (where any previous pending shutdown is cancelled first) was introduced here: https://github.com/networkupstools/nut/commit/0eef5be7 I wonder if other Megatec-based units don't send a NAK if there is no shutdown pending? Also, maybe we can just attempt the 'C' command up to three times, then send the shutdown command outside that loop. Unfortunately, my Best Power UPS is not available to see how it handles this. Also, I am not at all familiar with the runtime calibration config variables. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
