[Nut-upsuser] Wrong battery.date variable value [APC, usbhid-ups]

[Ong, Kevin]

I don't think the UPS mfr date is accurate also but I'm not a 100% sure. APC replaced my old BR1500GI unit with a brand new one (the one I have now) back in 2015 and this model was one of the newer models back then. So I'd say 2014 to 2015 is more reasonable for the UPS mfr date.

Sorry, I'm more of a PowerShell guy so I don't know much with Linux commands. I tried removing the 2>&1 and it did produce an output. What I noticed is that while the debug is running, the driver starts automatically after a few seconds and when I terminate it using Ctrl+C, it stops it on its own. The debug text file is produced but doesn't have any info in it aside from these:

Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33

So I think it's not redirecting the output text properly or something.

Thank you.

Regards,

Kevin Mychal M. Ong
Sr Infrastructure Engineer, Microsoft Technology Services - Messaging
Global Infrastructure Operations

Ingram Micro Inc.
4F Three World Square, 22 Upper McKinley Hill, Fort Bonifacio
Taguig City, Philippines 1634

Direct     +1-716-633-3600 ext. 33996
Mobile    +63-917-511-0251

 : kevin.ong at ingrammicro.com


-----Original Message-----
From: Charles Lepple <clepple at gmail.com>
Sent: Thursday, August 30, 2018 10:27 PM
To: Ong, Kevin <Kevin.Ong at ingrammicro.com>
Cc: nut-upsuser at alioth-lists.debian.net
Subject: Re: [Nut-upsuser] Wrong battery.date variable value [APC, usbhid-ups]

On Aug 30, 2018, at 10:05 AM, Ong, Kevin wrote:
>
> The battery.mfr.date is actually the correct value I'm looking for. That is the exact date the battery was last replaced. And yes, it is the correct value displayed in apcupsd.

I think we're on the same page for the battery date. What about the date of manufacture for the UPS - does 2012 seem reasonable?

>
> For the debug commands, is there a line break between "upsdrvctl stop" and "/usr/local/libexec/nut/usbhid-ups -a APC_BR1500GI -DDDDD 2>&1 | tee /tmp/APC_BR1500GI.debug.txt"? Well, I tried both ways and I come up with an "Ambiguous output redirect." error message.
>

yes, line break, and each of the commands you put in quotes should all be on one line. What does "echo $SHELL" say? (I'm assuming something like /bin/sh or /bin/ksh, but it might be csh-based.)

You can also try without the "2>&1" - I forget which parts go to stdout and which go to stderr (that attempts to redirect stderr to stdout, which then gets piped to tee).


This email may contain material that is confidential, and proprietary to Ingram Micro, for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[Ingram_2818e5de]