[Nut-upsdev] A newhidups question

Alfred Ganz alfred-ganz+nut at agci.com
Sat Aug 13 01:26:15 UTC 2005


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 this element isn't defined in apc-hid.h, so nothing is
     done here.
 (2) a (4 bytes) => 0C 46 BE 05 notification that provides two items:
	UPS.PowerSummary.RunTimeToEmpty and
	UPS.PowerSummary.RemainingCapacity
     Note that apc-hid.h specifies no translations for these values,
     which leads to another question, addressed separately!
 (3) a (5 bytes) => 16 0D 00 00 00 notification that provides nine status
   items:
	UPS.PowerSummary.PresentStatus.Charging
	UPS.PowerSummary.PresentStatus.Discharging
	UPS.PowerSummary.PresentStatus.ACPresent
	UPS.PowerSummary.PresentStatus.BatteryPresent
	UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit
	UPS.PowerSummary.PresentStatus.ShutdownImminent
	UPS.PowerSummary.PresentStatus.RemainingTimeLimitExpired
	UPS.PowerSummary.PresentStatus.NeedReplacement
	UPS.PowerSummary.PresentStatus.OverLoad
Note that these are all events that appear through HIDGetEvents() in 
upsdrv_updateinfo(), and all relevant elements are updated there.

Here is my puzzlement: If I run with the default poll_interval (which 
first applies to dstate_poll_fds(), but indirectly also controls the 
upsdrv_updateinfo() frequency), there are updates roughly every 2 sec,
as expected, and the three forms seem to cycle like this:
	(1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (3) ...
which has the effect that I might not get a status change for close to
30 sec, which doesn't seem very nice while we switch to LB (but which is
what I have observed when running with the full set of processes).
However, if I run with a poll_interval of 1 sec, there are about 45
updates per minute, and the three forms cycle nicely like this:
	(1) (2) (3) ....
This seems to indicate that at this speed everything produced by the UPS 
may actually be read, and the read delay is on the order of 250 ms. 

My question is, what happens in the HID world if the UPS generates several
different messages, and more messages than newhidups is prepared to read, 
and what would be a good way to handle such cases? What are the HID protocol
rules here, and what are the rules for the HID (or actually USB) API? Lots
of questions about which I know almost nothing!

This applies of course mainly to the case where the UPS generates multiple 
different messages, because otherwise we could probably just ignore some 
messages. However, if there are different messages, we ignore messages at 
our own peril, as the first example shows. Also note that my "fix" will 
no longer work if a UPS sends more than one message a second!

Sorry Arnaud for causing trouble again! AG

-- 
 ----------------------------------------------------------------------
   Alfred Ganz					alfred-ganz at agci.com
   AG Consulting, Inc.				(203) 624-9667
   440 Prospect Street # 11
   New Haven, CT 06511
 ----------------------------------------------------------------------



More information about the Nut-upsdev mailing list