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 <[email protected] <mailto:[email protected]>>

    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!

Attachment: Logs.7z
Description: Binary data

_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Reply via email to