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