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

Thu Jun 9 14:47:25 UTC 2016

Quick additional feedback:

2016-06-08 15:01 GMT+02:00 Arnaud Quette <arnaud.quette at 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+NUTlist at 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+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.)
>>>
>>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160609/6aa66ad9/attachment.html>