[Nut-upsuser] possible regression in genericups with Tripplite UPS

[Arjen de Korte]

Arnaud Quette wrote:
> reported through launchpad: https://bugs.launchpad.net/bugs/253999
> the possible regression is between nut 2.0.1 (sarge) and 2.2.1
> (confirmed Jamie?)
>
> @Arjen: it may be related to some of your changes there...
>   
No way. If you don't override in- or output signals, the only relevant 
changes between 2.0.1 and 2.2.1 are the following:
> @@ -116,7 +143,8 @@
>      ret = ioctl(upsfd, TIOCMGET, &flags);
>  
>      if (ret != 0) {
> -        upslog(LOG_INFO, "ioctl failed");
> +        upslog_with_errno(LOG_INFO, "ioctl failed");
> +        ser_comm_fail("Status read failed");
>          dstate_datastale();
>          return;
>      }
> @@ -135,6 +163,10 @@
>          status_set("OB");    /* on battery */
>  
>      status_commit();
> +
> +    upsdebugx(5, "ups.status: %s %s\n", ol ? "OL" : "OB", bl ? "BL" : 
> "");
> +
> +    ser_comm_good();
>      dstate_dataok();
>  }
Neither has any impact on the monitoring of the UPS, the only change you 
might see is that we now use the ser_comm_fail() and ser_comm_good() 
functions, so on the server you might see some activity if the ioctl() 
call is failing (and will be more verbose then).
> @Jamie: we'll need some debug output from the drivers (-DDD)
>   
What would be more interesting here, are the logs from the server. If 
you run the driver at debug level 5 (-DDDDD), you will see what it is 
reporting to the server.

Since 'upsmon' is reporting OL/OB status changes, the ioctl() calls must 
be succesful (it would be complaining about stale data otherwise). Which 
means that the problem is either in the kernel driver for the RS-232 
port, the serial port itself, the cable or the UPS. A serial breakout 
box with colored LEDs indicating the status of the lines would be very 
helpful here to diagnose where things go wrong.

Best regards, Arjen