On May 28, 2014, at 8:59 PM, Daniel O'Connor wrote: > On 28 May 2014, at 21:59, Charles Lepple <clep...@gmail.com> wrote: >>> What would log it? >> >> The driver. > > OK. > >>> I could try running the driver with debugging and see if that shows >>> anything of interest. >> >> That should help. Unfortunately for non-debug operation, it appears that >> most of the usbhid-ups instcmd messages are buried at debug level 3 or 5. >> That should probably be addressed when we increase the verbosity for OL/OB >> events. (Github issue #79) The syslog() level LOG_INFO should show up in >> most syslog configurations. > > FYI is the mge-shut driver (over RS232)
Ah, right. The "MGE HID" part threw me off. Bear in mind that the rest of this email is conjecture. > I ran the driver at debug level 5 (ie sudo /usr/local/libexec/nut/mge-shut -a > ups1 -D -D -D -D -D -u uucp |& tee /tmp/mge-shut.log) and issued the deep & > quick battery test commands. looks like the instcmd()s are at 61.999 and 82.685 seconds. > The log file is at http://www.gsoft.com.au/~doconnor/mge-shut.log > >>>> These commands should result in a self-test similar to the periodic one >>>> (the Evolution 500 does it every two weeks), but the "OK" from upscmd >>>> doesn't actually wait for the command to be executed. >>> >>> I think the new batteries will have been in for 2 weeks in a day or 2 so it >>> will be interesting to see if anything changes. >> >> Definitely let us know. It is certainly possible that we are not sending the >> battery test command correctly, or that something is preventing it from >> being sent. > > OK, hopefully you can glean some intelligence from the log :) It's pretty cryptic... 84.418555 Path: UPS.BatterySystem.Battery.Test, Type: Feature, ReportID: 0x24, Offset: 0, Size: 8, Value: 1 84.418557 hu_find_infoval: found Done and passed (value: 1) That part seems to contradict the following: 32.407365 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Feature, ReportID: 0x02, Offset: 8, Size: 8, Value: 0 32.407367 hu_find_infoval: found !replacebatt (value: 0) 32.407369 process_boolean_info: !replacebatt There is also this LCM (Life Cycle Monitoring) part: 22.677035 hid_lookup_path: 00840004 -> UPS 22.677037 hid_lookup_path: ffff0018 -> LCMSystem 22.677039 hid_lookup_path: ffff001a -> LCMAlarm 22.677045 hid_lookup_path: 00ff0001 -> not found in lookup table 22.677049 hid_lookup_path: 00840002 -> PresentStatus 22.677052 hid_lookup_path: ffff0093 -> TimerExpired 22.677055 Path: UPS.LCMSystem.LCMAlarm.[1].PresentStatus.TimerExpired, Type: Feature, ReportID: 0x5d, Offset: 0, Size: 8, Value: 1 This seems to be setting the RB flag: 65.871141 Path: UPS.LCMSystem.LCMAlarm.[2].PresentStatus.TimerExpired, Type: Feature, ReportID: 0x5d, Offset: 8, Size: 8, Value: 1 65.871143 hu_find_infoval: found replacebatt (value: 1) Unfortunately, the LCM stuff isn't documented. Arnaud, any ideas? -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser