Nut upsuser - Aug 2013 - N-Power MEV-3000LT compatibility report and problem

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 at gmail

Hello,
> What do you get from the "I" command?
A string of 8 spaces.
>> 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.
I debugged the problem. From the source, drivers/blazer.c:418

                /*
                 * If a command is invalid, it will be echoed back
                 */
                if (blazer_command(buf, buf, sizeof(buf)) > 0) {
                        upslogx(LOG_ERR, "instcmd: command [%s]
failed", cmdname);
                        return STAT_INSTCMD_FAILED;
                }

I see the following differences from the protocol implemented in the driver.

1. Instead of echoing back the command on failure, the UPS does the following:
 a. Returns " \r" (space, then CR) if the command was not recognized.
    This is where echo is expected.
 b. Returns "NAK\r" in the case where command was recognized but
failed. By the
    way, according to my records my old Ippon behaved the same way.
 c. Returns "ACK\r" on success.

2. It doesn't support the Q (toggle quiet) command, it always returns
"NAK\r"

3. On Q1, it doesn't reset the second number (the voltage when failure last
sensed).
Probably it does once the voltage is normal again but I live in a place where it
is never
normal, otherwise I were not be using such an expensive UPS, so I don't have
a
practical way to check this.

For my UPS, the existing code misinterpret any "ACK\r" response as
failure
(the blazer_command() function normally returns the number of octets received).
And the
 calling function doesn't attempt to continue, drivers/blazer.c:777

void upsdrv_shutdown(void)
{
        int     retry;

        for (retry = 1; retry <= MAXTRIES; retry++) {

                if (blazer_instcmd("shutdown.stop", NULL) !=
STAT_INSTCMD_HANDLED) {
                        continue;
                }

                if (blazer_instcmd("shutdown.return", NULL) !=
STAT_INSTCMD_HANDLED) {
                        continue;
                }

                fatalx(EXIT_SUCCESS, "Shutting down in %d seconds",
offdelay);
        }

        fatalx(EXIT_FAILURE, "Shutdown failed!");
}

In order to support this flavor of protocol, a response "ACK" to a
command should be considered
valid.

Regards,
Alexander.

Hello,

the code below the failing part mentions this flavor of protocol,
drivers/blazer_ser.c:463
        /*
         * If a command is invalid, it will be echoed back.
         * As an exception, Best UPS units will report "ACK" in case
of success!
         */

I prepared a patch, it adds a similar check and also checks (in both
occurencies) for
blazer_command()<0, the latter condition indicates a communication error). I
have yet
no chance to try it, I have a RAID controller which does a live rebuild and I
find too risky to
combine my experimentation with this operation. Once rebuild is finished I will
try and
if no other problems found will send the patch.

Regards,
Alexander.