[Nut-upsdev] Re: apc-hid tests, ups_status updates

[Peter Selinger]

OK, I have fixed this now, I think. Actually, I redesigned the way
status flags are handled in newhidups. The new concept is that we
distinguish more carefully between device status flags and NUT status
flags. Device flags are actual states reported by the device, such as
"lowbatt" or "shutdownimm". Importantly, several different device
flags can map to the same NUT flag; for example, both "lowbatt" and
"shutdownimm" are mapped to "LB". Thus, NUT flags are more abstract
than device flags.

In the old way of doing things, device flags were converted to NUT
flags right away, and stored in memory as NUT flags. The problem was:
if two device flags map to the same NUT flag, and one is set and the
other not, then depending on the order in which they are read, one
could overwrite the other. The old solution was: many flags were never
cleared.

In the new way of doing things, we store the device flags directly.
process_status_info() no longer interprets these values; it just
remembers them. The interpretation (i.e., mapping to NUT flags) is now
done only on demand, i.e., by ups_status_set(). In this way,
ups_status_set() can look at all the different flags, e.g. "lowbatt"
and "shutdownimm", and decide to take their logical "or" or whatever
to create sensible NUT flags.

I also made a few other minor changes: I added added NUT status flags
OVERHEAT, COMMFAULT, DEPLETED; these are used by Belkin and already
exist in the belkinunv driver.

I also updated the Belkin subdriver to calculate OL/OB in a more
sensible way.

This update lives between the following tags:

  cvs diff -u -r before_PSE_10 -r after_PSE_10

-- Peter

Alfred Ganz wrote:
> 
> Arnaud,
> 
> > first, even if your battery is full, and your ups is online, there is a
> > small amount of power drawn. So having always is CHRG status is normal.
> > In fact, these complementary status are more interesting for higher end
> > UPSs.
> >
> > second, these status need not to be handled like LB, as each one clears the
> > other. While LB had no pending event (!LB) before...
> >
> > or did I get you wrong?
> First, I fully understand that a UPS may report "Charging" because of a
> small amount of power drawn. However, in that case I would expect the UPS
> to report PowerSummary.PresentStatus.Charging with a value of one, and that
> should then show in ups_status.
> 
> Second, I have encountered at least one situation in which the UPS reports
> "OL DISCHRG", but then immediately reports both Discharging and Charging
> as zero, and ups_status is therefore never cleared. I don't know the details
> of timing that lead to this situation, but it reproducibly exist, and I
> think the status should be cleared even though "Charging" never showed.
> 
> I guess my real question would be, are the variables Discharging and
> Charging of the PowerSummary.PresentStatus as reported by the UPS, Boolean
> variables according to the HID prototcol? If they are, then ignoring any
> value reported as zero seems to me to be a mistake.
> 
> Thanks, AG
> 
> -- 
>  ----------------------------------------------------------------------
>    Alfred Ganz					alfred-ganz at agci.com
>    AG Consulting, Inc.				(203) 624-9667
>    440 Prospect Street # 11
>    New Haven, CT 06511
>  ----------------------------------------------------------------------
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>