search for: hu_walkmode_quick_upd

...n't handle requests from clients when we're talking/listening to the UPS. > - If the UPS sends reports on the interrupt pipeline, we consider that enough proof that it is still there. At the same time, we assume that it keeps us 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 o...

Gentlemen, I think this question is mainly for Arnaud again: When I run my UPS directly with newhidups -D -D -D, with no data changes, and I then observe the interaction with my UPS (still Back-UPS ES 650 FW:818.w1.D USB FW:w1), I see the updateinfo cycle through 3 different forms: (1) a (2 bytes) => 06 08 notification that provides one item: UPS.PowerSummary.APCStatusFlag Note that

...tinue; > + /* ...this one doesn't exist yet... */ > + if (dstate_getinfo(item->info_type) == NULL) { > + break; > } > > - break; > + /* ...but this one does, so don't use it! */ > + item->hiddata = NULL; > + continue; > > case HU_WALKMODE_QUICK_UPDATE: > /* Quick update only deals with status and alarms! */ > @@ -1058,7 +1089,7 @@ > fatalx(EXIT_FAILURE, "hid_ups_walk: unknown update mode!"); > } > > - retcode = HIDGetDataValue(udev, item->hiddata, &value, 2); > + retcode = HIDGetDataValue(u...