<br><br><div class="gmail_quote">2012/10/19 Kris Jordan <span dir="ltr"><<a href="mailto:nut.kj@sagebrushnetworks.com" target="_blank">nut.kj@sagebrushnetworks.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Arnaud Quette wrote, On 10/18/2012 11:39 AM:<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Kris,<br>
<br>
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!<br>
</blockquote>
<br></div>
I must have missed that message.</blockquote><div><br>it was in a separate user discussions:<br><a href="http://lists.alioth.debian.org/pipermail/nut-upsuser/2012-October/008011.html">http://lists.alioth.debian.org/pipermail/nut-upsuser/2012-October/008011.html</a><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I saw something about the hosting change, but I saw no reason why.</blockquote><div><br>because of the same kind of reasons mentioned in the above mail:<br>people tended to interpret Eaton logo presence as if Eaton was sponsoring NUT, which was somehow true at some point in the past.<br>
but that's not the case currently, and for some time now.<br>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.<br>which also explains the lag you see in my answers...<br>
<br>that's probably a bit egoist, but giving my *personal* credits to Eaton is not something I want to do anymore!<br>and I can tell you that I've poured <span id="result_box" class="short_text" lang="en"><span class="hps">thousands of hours</span></span> of my personal time in this project, for the past decade, along with money...<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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).<br>
</blockquote><div>
<br>however, note that Eaton is still the only manufacturer supporting NUT!<br>but this support level has slowly been decreasing over the time, and is limited to the windows port and few more things currently.<br><br>I'm still hoping that we're reaching the end of a night, and that the day is coming after.<br>
but I won't be hoping for much more time...<br><br>that said, back to your issue<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
the current Eaton support is limited to Frederic's work on the Windows port, and Vaclav integration works (clock_gettime and monotonic).<br>
<br></div>
2012/10/13 Kris Jordan <<a href="mailto:nut.kj@sagebrushnetworks.com" target="_blank">nut.kj@sagebrushnetworks.com</a> <mailto:<a href="mailto:nut.kj@sagebrushnetworks.com" target="_blank">nut.kj@<u></u>sagebrushnetworks.com</a>>><div>
<br>
<br>
Kris Jordan wrote, On 10/10/2012 11:00 PM:<br>
<br>
Windows 7 Pro x64<br>
<br>
Eaton 3S550 (brand new, battery mfg 8/15/2012)<br>
NUT 2.6.5-3<br>
<br>
<br>
Pretty much done testing this UPS on Windows. I couldn't disable<br>
the beeper using NUT, and even after doing so successfully with<br>
the Solution-Pac, it still says enabled (in NUT). Though I thank<br>
Eaton for not using an obnoxious (loud) beeper.<br>
<br>
<br>
is it actually enabled? i.e, when unplugging the power cord, does it beep or not?<br>
I would like to see a driver debug trace (level 5) when calling 'upscmd ... beeper.off'.<br>
</div></blockquote>
<br>
upscmd -u admin -p password ups beeper.off<br>
<br>
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.</blockquote>
<div><br>quite frankly, I'm puzzled.<br>I would need to test on an actual device... and currently, I can't!<br>that would be worth, with the below (depending on your answer) to contact the official Eaton support.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I also get ERR VAR-NOT-SUPPORTED for input.transfer.low/high. This<br>
is perhaps normal because of the way this UPS sets the value in a<br>
combined fashion. I did not log this happening. If wanted, I can<br>
test it more.<br>
<br>
<br>
strange, the trace clearly state the variable publication.<br>
so, yes, I'm interested in both the exact command used (copy/paste) + the driver trace excerpt around the upsrw call (grep for 'setvar')<br>
</blockquote>
<br></div>
For whatever reason, I no longer get the ERR message, maybe I kept mistyping something.<br></blockquote><div><br>quite probably<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The two values are linked, as long as you use a valid value for low or high, the other value will also change. <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But, there is one that doesn't work, a low value of 75.<br>
<br>
low-high:<br>
84-142 (red light)<br>
96-138 (both lights)<br>
75-144 (green light)<br>
<br>
upsrw -u admin -p password -s input.transfer.high=138 ups<br>
Result: 84-142 --> 96-138<br>
<br>
upsrw -u admin -p password -s input.transfer.low=75 ups<br>
Result: 96-138 --> 84-142<br>
<br>
upsrw -u admin -p password -s input.transfer.low=96 ups<br>
Result: 84-142 --> 96-138<br>
<br>
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.<br></blockquote></div><br>strange! the trace shows no error, but the value is indeed not changed.<br>
and this works with the windows SW?<br clear="all"><br>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...<br>
<br>cheers,<br>Arnaud<br>-- <br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org" target="_blank">http://www.networkupstools.org</a><br>Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>
Free Software Developer - <a href="http://arnaud.quette.fr" target="_blank">http://arnaud.quette.fr</a><br><br>