Nut upsuser - May 2014 - Resetting replace battery status on Pulsar 1500

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)

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.

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 :)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140529/ee09b5bc/attachment.sig>

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

On 29 May 2014, at 13:17, Charles Lepple <clepple at gmail.com>
wrote:
>> 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.
OK.
>> 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.
Yes.
>> 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...
Hah, glad it's not just me then :)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20140529/2c567e10/attachment.sig>