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.)
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.)
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.
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.
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)
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.
Andy R.
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
