Below is an excerpt from the debug output for a Tripplite UPS: HIDGetEvents: too many events (truncated) Got 16 HID objects... Report[get]: (4 bytes) => 32 00 00 09 Path: UPS.PowerSummary.PresentStatus.00000000, Type: Input, ReportID: 0x32, Offset: 0, Size: 1, Value: 0.000000 NUT doesn't use this HID object The 'Path' reported here looks like this (one bit) variable isn't used. Of the possible 24 bit positions in this report, only 9 appear in the output from HIDDumpTree(). After a lot of head scratching, I found out that paths with more than six consecutive zero's in the hexadecimal notation of the node number in them (anywhere in the path) are disregarded by the HIDDumpTree() debugging function (see below). /* FIXME: enhance this or fix/change the HID parser (see libhid project) */ if (strstr(path, "000000") != NULL) { continue; } Would there be anything against skipping these reports while parsing the report descriptor, instead of ignoring them in HIDDumpTree()? In theory, this might break subdrivers where the nodes 0x000000??, 0x?000000? and 0x??000000 are used, but so far I have not seen any that does (if it is allowed at all). For the moment, I think skipping reports that end in node 0x00000000 (0) is sufficient. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57