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@agci.com AG Consulting, Inc. (203) 624-9667 440 Prospect Street # 11 New Haven, CT 06511 ----------------------------------------------------------------------
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@agci.com > AG Consulting, Inc. (203) 624-9667 > 440 Prospect Street # 11 > New Haven, CT 06511 > ---------------------------------------------------------------------- > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >
In my opinion, Alfred is right, this is a bug. Status flags should not remain set infinitely after the UPS has reset them. Also, the states CHRG and DISCHRG are not each other's negation. Very conceivably, the UPS could be charging for 1 second at 12:00, and discharging for 1 second at 3:00. Then the CHRG flag would remain set from 12:00-3:00, and the DISCHRG flag would remain set for eternity after that. The situation is similar with OL and OB. There are valid times when the UPS is neither online nor on battery, for example when it is switched off. However, newhidups would continue to report the most recent OL or OB state that it has seen. I think all the flags should be reported exactly as seen from the UPS, and drivers should do no meddling "to avoid inconsistencies", except perhaps to compensate if a specific device is known to be buggy. Any consistency checks, if they are really necessary, really belong in upsmon. If I read the CVS repository correctly, the functions process_status_info() and ups_status_set() were added between version 1.1.1.1 and 1.1.1.1.8.1, in May 2005. Before that, there were just calls to the meta-driver's status_set() and status_commit() functions. However, that earlier solution would also have been buggy: the problem is that each report that arrives from the UPS might contain only a subset of the status flags, so one needs to remember them and send all of them at the same time. I'll work on a solution. -- 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@agci.com > AG Consulting, Inc. (203) 624-9667 > 440 Prospect Street # 11 > New Haven, CT 06511 > ---------------------------------------------------------------------- > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >