[Nut-upsuser] Eaton 3S550

[Arnaud Quette]

2012/10/19 Kris Jordan <nut.kj at sagebrushnetworks.com>

> 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.


it was in a separate user discussions:
http://lists.alioth.debian.org/pipermail/nut-upsuser/2012-October/008011.html


> I saw something about the hosting change, but I saw no reason why.


because of the same kind of reasons mentioned in the above mail:
people tended to interpret Eaton logo presence as if Eaton was sponsoring
NUT, which was somehow true at some point in the past.
but that's not the case currently, and for some time now.
and this forces me to assume more and more things on my personal time. and
I can tell you that I've many other caps to assume.
which also explains the lag you see in my answers...

that's probably a bit egoist, but giving my *personal* credits to Eaton is
not something I want to do anymore!
and I can tell you that I've poured thousands of hours of my personal time
in this project, for the past decade, along with money...

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

however, note that Eaton is still the only manufacturer supporting NUT!
but this support level has slowly been decreasing over the time, and is
limited to the windows port and few more things currently.

I'm still hoping that we're reaching the end of a night, and that the day
is coming after.
but I won't  be hoping for much more time...

that said, back to your issue


>  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@**
>> sagebrushnetworks.com <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.


quite frankly, I'm puzzled.
I would need to test on an actual device... and currently, I can't!
that would be worth, with the below (depending on your answer) to contact
the official Eaton support.


>
>
>>     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.
>

quite probably


> 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.
>

strange! the trace shows no error, but the value is indeed not changed.
and this works with the windows SW?

the code for input.transfer.* is still a pass-through: NUT only send the
value to the device, without any specific processing or enforcement
(conversely to output.voltage.nominal for example). this is still part of
Eaton TODO list...

cheers,
Arnaud
-- 
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121025/9de4bffd/attachment-0001.html>