[Nut-upsdev] Constant "on battery" and "on line power" status changes

[Patrick Krepps]

Apologies, I probably should have said not physically at fault, meaning the 
problem is not in what the UPS is doing, but rather in what the UPS is saying 
or how that is being interpreted. This UPS has been rather problematic and it 
was my prime suspect, not NUT. Sorry if that wasn't clear.

As for your "bad news", I been waiting several months to be able to get back 
at this, so one more week is not bad news.

Thanks

On Monday 31 December 2007 06:59, Arjen de Korte wrote:
> [...]
>
> > I believe I have everything set up and (apparently) communicating
> > correctly,
> > but the UPS status constantly flips from "on battery" to "on line power",
> > and
> > upsmon reports a steady stream of these messages. I can also see the
> > changes
> > in the ups.status reported by upsc. I did some reading on the lists, and
> > the
> > only thing I found that sounded like it might help was adding "pollfreq =
> > 5"
> > and "pollinterval = 10" to the ups.conf file. However, this just seems to
> > have decreased the frequency of the alerts.
> >
> > I am fairly sure neither the UPS nor the input power are at fault.
>
> Unfortunately, the UPS *is* at fault. It is the same problem as we've seen
> in Belkin UPS'es before and which was fixed in the 'belkin-hid' subdriver
> and which probably must be solved in a different way for the
> 'tripplite-hid' subdriver.
>
> The debug output you provided conclusively tells this is a problem in the
> UPS. It is reporting two different values for report 32h, the one that
> contains the status bit that tells (amongst other info) whether or not AC
> is present. Unfortunately, it tells two different stories, depending on
> how we receive this report:
>
>     Report[get]: (4 bytes) => 32 00 00 09
>     Report[int]: (4 bytes) => 32 64 00 00
>
> The first [get] is the one we receive when we explicitly ask the UPS for
> report 32h and this is the one that yields correct information. The second
> [int] is the one that is sent by the UPS over the interrupt pipeline (and
> that will be initiated by the UPS). Apparently, the UPS messes this up
> badly internally. Most likely with report 34h that is sent just before
> that one:
>
>     Report[int]: (2 bytes) => 34 64
>
> This violates the USB HID specification, these reports should be the same.
> The reason that this isn't a problem for the USB driver provided by
> Tripplite is most likely that they ignore the reports received over the
> interrupt pipeline, so they will only use the polling mechanism (and those
> reports aren't broken).
>
> The good news is, that we can definitly work around this problem. The bad
> news is, that I'll have to modify the driver for that, there is no quick
> workaround for that (we can't tell the UPS to not sent interrupt reports).
> I'll let you know when I've had the time to fix this, probably somewhere
> by the end of this week.
>
> Best regards, Arjen