[Nut-upsuser] Eaton 3S550

[Kris Jordan]

Arnaud Quette wrote, On 10/18/2012 11:39 AM:
> Hi Kris,
>
> as told in a separate mail on the list, I will there be acting as an 
> individual, since Eaton current stance is to not allow me to support 
> NUT users nor to do my NUT leader tasks on my working hours for a few 
> weeks now!

I must have missed that message. I saw something about the hosting 
change, but I saw no reason why. Part of my reason to go Eaton was 
because of their support for Open Source and NUT (or at least I thought 
because they were hosting).

> the current Eaton support is limited to Frederic's work on the Windows 
> port, and Vaclav integration works (clock_gettime and monotonic).
>
> 2012/10/13 Kris Jordan <nut.kj at sagebrushnetworks.com 
> <mailto:nut.kj at sagebrushnetworks.com>>
>
>     Kris Jordan wrote, On 10/10/2012 11:00 PM:
>
>         Windows 7 Pro x64
>
>         Eaton 3S550 (brand new, battery mfg 8/15/2012)
>         NUT 2.6.5-3
>
>
>     Pretty much done testing this UPS on Windows. I couldn't disable
>     the beeper using NUT, and even after doing so successfully with
>     the Solution-Pac, it still says enabled (in NUT). Though I thank
>     Eaton for not using an obnoxious (loud) beeper.
>
>
> is it actually enabled? i.e, when unplugging the power cord, does it 
> beep or not?
> I would like to see a driver debug trace (level 5) when calling 
> 'upscmd ... beeper.off'.

upscmd -u admin -p password ups beeper.off

I always test. Beeper still beeps while on-battery. Using Eaton's 
software, it can disable the alarm just fine. I re-enabled the alarm 
before I ran the above command. My previously attached logs included me 
running every command including upsc.

>
>     I also get ERR VAR-NOT-SUPPORTED for input.transfer.low/high. This
>     is perhaps normal because of the way this UPS sets the value in a
>     combined fashion. I did not log this happening. If wanted, I can
>     test it more.
>
>
> strange, the trace clearly state the variable publication.
> so, yes, I'm interested in both the exact command used (copy/paste) + 
> the driver trace excerpt around the upsrw call (grep for 'setvar')

For whatever reason, I no longer get the ERR message, maybe I kept 
mistyping something.

The two values are linked, as long as you use a valid value for low or 
high, the other value will also change. But, there is one that doesn't 
work, a low value of 75.

low-high:
84-142 (red light)
96-138 (both lights)
75-144 (green light)

upsrw -u admin -p password -s input.transfer.high=138 ups
Result: 84-142 --> 96-138

upsrw -u admin -p password -s input.transfer.low=75 ups
Result: 96-138 --> 84-142

upsrw -u admin -p password -s input.transfer.low=96 ups
Result: 84-142 --> 96-138

I've tested it a bunch of times, low=75 is the only one giving me 
troubles. The other way to get 75-144 is to use high=144, which works fine.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Logs.7z
Type: application/octet-stream
Size: 25781 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121018/12d51777/attachment-0001.obj>