[Nut-upsuser] Resetting replace battery status on Pulsar 1500

[Charles Lepple]

On May 28, 2014, at 8:59 PM, Daniel O'Connor wrote:

> On 28 May 2014, at 21:59, Charles Lepple <clepple at 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 at gmail