search for: belkinstatus

...e it is ignored (the special case in usbhid-ups.c) and even after that it looks like there are still some problems with it: http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-July/003014.html Wouldn't it be an option to just to ignore this completely and instead use bit 2 from 'UPS.BELKINStatus.BELKINBatteryStatus'? It looks like the battery low status is duplicated there. Another thing that puzzles me, is why we use two ways to set the online status of the UPS (through 'UPS.PowerSummary.ACPresent' and bit 5 of 'UPS.BELKINStatus.BELKINBatteryStatus'). Is this because...

....beeper.status: enabled ups.delay.restart: 0 ups.delay.shutdown: 0 ups.devicechemistry: PbAc ups.firmware: -16 ups.load: 43 ups.mfr: Belkin ups.model: UPS ups.power.nominal: 550 ups.serial: unknown ups.serial.internal: ups.status: OL CHRG ups.test.result: No test initiated ups.type: offline zzz.ups.belkinstatus.belkinbatterystatus: 00000010 zzz.ups.belkinstatus.belkinpowerstatus: 0000c000 zzz.ups.powersummary.capacitygranularity1: 1 zzz.ups.powersummary.capacitygranularity2: 1 zzz.ups.powersummary.capacitymode: 2 zzz.ups.powersummary.configvoltage: 12 zzz.ups.powersummary.current: 0 zzz.ups.powersummary.d...

...informed of *all* important status changes, so that doing a HU_WALKMODE_QUICK_UPDATE is redundant then. This latter assumption is probably not valid in all cases. For example, since the interrupt value of UPS.PowerSummary.BelowRemainingCapacityLimit was broken on Belkin, we decided to go with UPS.BELKINStatus.BELKINBatteryStatus instead, which is a variable that is *not* sent on the interrupt pipeline. In general, not every UPS that uses the interrupt pipeline can be trusted to send all important values on it. -- Peter > - Added a ups_infoval_set() function that is doing the actual setting of va...