<p dir="ltr"><br>
On Dec 10, 2012 5:16 AM, "Charles Lepple" <<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>> wrote:<br>
><br>
> [please keep the list CC'd. thanks]</p>
<p dir="ltr">Sorry.  I was new to the list and didn't notice the reply-to wasn't set to the list.</p>
<p dir="ltr">><br>
> On Dec 10, 2012, at 3:31 AM, Dawning Sky wrote:<br>
><br>
> > On Sun, Dec 9, 2012 at 5:30 PM, Charles Lepple <<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>> wrote:<br>
> >> On Dec 7, 2012, at 3:01 AM, Dawning Sky wrote:<br>
> >><br>
> >>> 1. battery.charge doesn't report correct charge level when the UPS is<br>
> >>> On Batter.  It just reports 0.  Even though it will report 100 when on<br>
> >>> line power.<br>
> >><br>
> >> I wonder if this is connected with the following:<br>
> >><br>
> >>> ups.debug.S: 31 34 30 00 64 30 0d '140.d0.'<br>
> >><br>
> >> As I remember it, '4' is the status character representing "self-test status is unknown". You might need to do a deep discharge test first before the state-of-charge constants are programmed into the UPS.<br>

> >><br>
> >> If you can start a deep discharge test from the front panel, I'd try that first. Otherwise, there is a "test.battery.start" command in NUT which might be what you're looking for. However, bear in mind that this driver was written without the benefit of protocol documentation.<br>

> >><br>
> ><br>
> > Charles,<br>
> ><br>
> > Thanks for getting back to me.  I thought I did a battery test from<br>
> > the front panel some time ago.  Just to be sure, I did another test<br>
> > from the panel and a test by test.battery.start.  It doesn't seem to<br>
> > help with the battery.charge.  Part of upsc output is<br>
> ><br>
> > battery.charge: 0<br>
> > battery.test.status: Battery OK<br>
> > battery.voltage: 25.20<br>
> > ...<br>
> > ups.debug.S: 31 30 30 00 00 30 0d '100..0.'<br>
><br>
> OK. Not really sure what to tell you - that 5th byte is what is converted to state-of-charge, and your original post had 64 when battery.charge was 100%.<br>
><br>
> If you have a Windows system handy (might work in VirtualBox or VMWare), you can compare with the regular Tripp Lite software.</p>
<p dir="ltr">I don't have a Windows.  But Tripp Lite claims PowerAlert runs on Linux.   Maybe I'll give it a try when I get a chance.</p>
<p dir="ltr">><br>
> > In any case, I can probably live with this.  But I'm really troubled<br>
> > with the fact that the NUT daemon didn't issue the shutdown command,<br>
> > even though Do you have any thoughts on this?  Is it possible that the<br>
> > user "nut" doesn't have the privilege to shutdown?<br>
><br>
><br>
> I misread the part where you mentioned that you got the low battery signal - I was thinking "on battery".<br>
><br>
> upsmon is designed to be started as root, and when it forks, it leaves behind a parent process that retains root privileges:<br>
><br>
> <a href="http://www.networkupstools.org/docs/man/upsmon.html#_reloading_nuances">http://www.networkupstools.org/docs/man/upsmon.html#_reloading_nuances</a><br>
><br>
> If SHUTDOWNCMD is a script, check permissions on it. (Even root needs execute permissions on scripts - it's only the read/write permissions that it can override.) Also, the next section in the above URL mentions 'upsmon -c fsd', which can be used to test the shutdown sequence without draining the UPS.</p>

<p dir="ltr">The permission is 755 and should be correct.  The shutdown command was the default "/sbin/shutdown -h +0".  I did a FSD test.  The computer was shut down but not the UPS.</p>
<p dir="ltr">><br>
> Are you building from source, or installing a package?</p>
<p dir="ltr">It was installed from Fedora RPMs.</p>
<p dir="ltr">><br>
> --<br>
> Charles Lepple<br>
> clepple@gmail<br>
><br>
><br>
><br>
</p>