[please keep the list CC'd. thanks] On Dec 10, 2012, at 3:31 AM, Dawning Sky wrote:
> On Sun, Dec 9, 2012 at 5:30 PM, Charles Lepple <clep...@gmail.com> wrote: >> On Dec 7, 2012, at 3:01 AM, Dawning Sky wrote: >> >>> 1. battery.charge doesn't report correct charge level when the UPS is >>> On Batter. It just reports 0. Even though it will report 100 when on >>> line power. >> >> I wonder if this is connected with the following: >> >>> ups.debug.S: 31 34 30 00 64 30 0d '140.d0.' >> >> 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. >> >> 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. >> > > Charles, > > Thanks for getting back to me. I thought I did a battery test from > the front panel some time ago. Just to be sure, I did another test > from the panel and a test by test.battery.start. It doesn't seem to > help with the battery.charge. Part of upsc output is > > battery.charge: 0 > battery.test.status: Battery OK > battery.voltage: 25.20 > ... > ups.debug.S: 31 30 30 00 00 30 0d '100..0.' 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%. If you have a Windows system handy (might work in VirtualBox or VMWare), you can compare with the regular Tripp Lite software. > In any case, I can probably live with this. But I'm really troubled > with the fact that the NUT daemon didn't issue the shutdown command, > even though Do you have any thoughts on this? Is it possible that the > user "nut" doesn't have the privilege to shutdown? I misread the part where you mentioned that you got the low battery signal - I was thinking "on battery". upsmon is designed to be started as root, and when it forks, it leaves behind a parent process that retains root privileges: http://www.networkupstools.org/docs/man/upsmon.html#_reloading_nuances 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. Are you building from source, or installing a package? -- 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