[Nut-upsuser] IBM 5396-1Kx ups nearly recognised.

[Andy R]

On 17/04/2016 21:49, Charles Lepple wrote:
> On Apr 16, 2016, at 9:08 PM, Andy R - (NUT-List)
> <spinner+NUTlist at 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.