Quick additional feedback: 2016-06-08 15:01 GMT+02:00 Arnaud Quette <arnaud.que...@gmail.com>:
> 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. > I did some quick tests with the same unit (UPS LI T 1000): - "ups.status: OL CHRG OFF" when the UPS is not started (and so the output values "0") - once you press the power button, "ups.status: OL CHRG" - same when issuing upscmd load.{on,off} on ups.status, along with validating the shutdown behavior. I also took the opportunity to test in serial mode (using mge-shut), and everything is fine. I've completed and merged the branch into our master, so this will be available in our next release (2.7.5). Side note: the patch completion includes a bump of the MGE HID subdriver version to 1.41, along with the addition of two entries in the drivers.list, for USB and serial communication Thanks a lot to Charles for taking care of... so many things! 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
