<div dir="ltr">Hi Andy,<br><div class="gmail_extra"><br></div><div class="gmail_extra">trying to catch my late here and there, keep in mind that my below comments may be missing things...<br><br></div><div class="gmail_extra"><div class="gmail_quote">2016-04-24 23:30 GMT+02:00 Andy R <span dir="ltr"><<a href="mailto:spinner+NUTlist@delphinidae.org.uk" target="_blank">spinner+NUTlist@delphinidae.org.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 17/04/2016 21:49, Charles Lepple wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Apr 16, 2016, at 9:08 PM, Andy R - (NUT-List)<br>
<<a href="mailto:spinner%2BNUTlist@delphinidae.org.uk" target="_blank">spinner+NUTlist@delphinidae.org.uk</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It looks like you were right. I've tried building both the patch<br>
against the stable 2.7.4 source and using the latest source tarball<br>
you've just created. The builds both went fine and seem to run as<br>
they should. The Arch source build scripts are pretty clear to<br>
manipulate at least.<br>
</blockquote>
<br>
If there are any URLs that you found particularly helpful for getting<br>
started with that, let me know. These sorts of test scenarios pop up<br>
every now and then.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The udev rules work fine now, and  upsc/upscmd both return<br>
promising looking responses. I can't actively test switching the<br>
UPS right now as it's a bit late here for alarms to go off, however<br>
if there is anything more to try then please let me know.<br>
<br>
I have attached a copy of the upsc/upscmd responses to querying the<br>
UPS, and the debug output of usbhid-ups from the new build in case<br>
there are any anomolies that stand out.<br>
</blockquote>
<br>
It's going to be a little while before I can get back to this, but<br>
maybe one of the other NUT developers can help. One thing I did not<br>
do is try to map this to an equivalent Eaton model[*]. There might be<br>
additional features or fixes if someone knows the exact equivalent.<br>
<br>
[*]:<br>
<a href="https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c#L89" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c#L89</a><br>
<br>
 This part looks weird, but maybe I am not used to seeing the status<br>
of a larger UPS: "ups.status: OL CHRG OFF" (maybe<br>
"battery.charger.status: floating" means float charging, rather than<br>
resting.)<br></blockquote></div></div></blockquote><div><br></div><div>yup, nothing but normal.<br></div><div>OL is simply that the input power is fine.<br></div><div>OFF means that the UPS doesn't power its output.<br><br></div><div>the CHRG flag should however not be published since ABM (advanced battery monitoring, publication of charger specific info into battery.charger.status) is enabled:<br><br>
<a href="https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt#L356">https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt#L356</a><br>
<a href="https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt#L393">https://github.com/networkupstools/nut/blob/master/docs/nut-names.txt#L393</a><br><br></div><div>and crunchy tech details here:<br><a href="https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c#L135">https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c#L135</a><br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If it really is off, then ups.load, ups.power and output.voltage seem<br>
reasonable. Otherwise, we might have an issue with scaling the<br>
values. (That sort of error is not common on MGE/Eaton units, but you<br>
never know.)<br></blockquote></div></div></blockquote><div><br></div><div>indeed ;)<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My personal recommendation is to do as much shutdown testing as you<br>
can before hooking up critical loads. It looks like<br>
"outlet.1.autoswitch.charge.low: 0" is off, so that should simplify<br>
testing. Also, try a battery test to see what messages you get in<br>
syslog. There are some procedures listed in the NUT User Manual for<br>
how to test shutdowns without accidentally cutting power if things<br>
are not configured correctly.<br>
<br>
</blockquote>
<br></div></div>
Hi,<br>
<br>
Just thought I'd send an interim followup to this, as I haven't<br>
forgotten it, just been a little busy.<br>
<br>
Firstly you were exactly right about the charging status. The ups does a<br>
base fast charge to get the battery up to speed at 90% or so, then a<br>
slow float charge from 90% to full where it then rests the battery and<br>
disconnects the charging circuit. I recall it then just giving a plain<br>
"OL OFF" message there then.<br>
<br>
I've not had any luck in testing it for power handling as the batteries<br>
are toasted. Unplugging it at idle load (PC was plugged direct to the<br>
wall with just usb to the UPS) caused it to fall flat on its face with<br>
an instant shutdown. Plugging back in went back to the "can't power-up<br>
due to not having enough battery to complete the self-testing" that I<br>
had when I first got the unit. New batteries on order now.<br></blockquote><div><br></div><div>good. PbAc battery generally lives ~4 years.<br>It then depends on the operating temperature, and the power quality...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The actual control software seems to be operating ok. Having got a<br>
simple configuration running it operates as expected with "upsmon -c<br>
fsd". The machine stops, and the UPS is triggered to go to standby and<br>
then restart when power comes back, well it comes straight back after 10<br>
seconds as the power never goes away in the test.<br></blockquote><div><br></div><div>indeed, default behavior (10 sec after the power comes back)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I've also tripped over a libc-2.23 issue that may or may not be either<br>
something due to the build used by arch, systemd or something in libc<br>
itself. But if you try to set SHUTDOWNCMD to the old reboot/shutdown<br>
commands that have been trampled and swallowed by systemd then you get a<br>
libc segfault. Using 'systemctl shutdown' as the SHUTDOWNCMD does work<br>
ok though. Someone else on arch has already posted a bug to systemd<br>
(<a href="https://github.com/systemd/systemd/issues/2796" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/issues/2796</a>)<br>
<br></blockquote><div><br></div><div>I'm still puzzled if it works or not in the end?<br><br></div><div>as a side note, on a Debian Jessie (8)<br><br>$ file /sbin/shutdown <br>/sbin/shutdown: symbolic link to /bin/systemctl<br><br></div><div>so theoretically, the behavior of SHUTDOWNCMD=/sbin/shutdown and SHUTDOWNCMD="systemctl shutdown" should be the same<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
About the Arch Build System (ABS), if I'm understanding what you want to<br>
know, and not feeding you a bunch of things you've already seen (if I<br>
am, apologies in advance) then most of what you want is probably here<br>
(<a href="https://wiki.archlinux.org/index.php/Arch_Build_System" rel="noreferrer" target="_blank">https://wiki.archlinux.org/index.php/Arch_Build_System</a>). It's meant to<br>
be the main document source, but it's still a wiki..so..hardhats on, I<br>
guess :).<br>
<br>
The actual PKGBUILD scripts are simple beasts, just a list of commands<br>
to step through the process of config/make/install and to put everything<br>
into an arch installer package for the package manager (Pacman -<br>
<a href="https://wiki.archlinux.org/index.php/pacman" rel="noreferrer" target="_blank">https://wiki.archlinux.org/index.php/pacman</a>). As an example here is the<br>
one for NUT<br>
(<a href="https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=network-ups-tools" rel="noreferrer" target="_blank">https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=network-ups-tools</a>).<br>
All I had to do was change the version numbers, the path to the source<br>
tarball and add an extra patch line at the beginning and then the smoke<br>
and mirrors did all the rest.<br>
<br>
The AUR package for the CK kernel is a useful patching example<br>
(<a href="https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-ck" rel="noreferrer" target="_blank">https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=linux-ck</a>) with<br>
extra info from (<a href="https://www.archlinux.org/pacman/PKGBUILD.5.html" rel="noreferrer" target="_blank">https://www.archlinux.org/pacman/PKGBUILD.5.html</a>) and<br>
(<a href="https://wiki.archlinux.org/index.php/Patching_in_ABS" rel="noreferrer" target="_blank">https://wiki.archlinux.org/index.php/Patching_in_ABS</a>)<br>
<br>
The AUR is the Arch User Repository, where addon packages can be listed<br>
for users to add to their systems via planting the build-package<br>
tarballs on their systems and hitting them with the proper tools<br>
('tar-unzip' and 'makepkg' mainly)<br>
<br>
<br>
Anyway. thats the story so far, hope that is what you were looking for.<br>
If not, I'll have another run at it. I'll keep poking the UPS when the<br>
new batteries come in.<span class=""><font color="#888888"></font></span><br></blockquote></div><br></div><div class="gmail_extra">any news on this front?<br></div><div class="gmail_extra">Once good, we'll merge the IBM branch to have these units recognized by the driver.<br></div><div class="gmail_extra">I'm also checking on my side to get a hand on a similar IBM unit, to do some checks.<br></div><div class="gmail_extra">AFAICT, there should be no difference in terms of HID data.<br><br></div><div class="gmail_extra">cheers,<br></div><div class="gmail_extra">Arno<br></div><div class="gmail_extra">-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Eaton Data Center Automation Solutions - Opensource Leader<br>NUT (Network UPS Tools) 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></div></div></div></div>
</div></div>