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

[Arnaud Quette]

Quick additional feedback:

2016-06-08 15:01 GMT+02:00 Arnaud Quette :

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

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

[Arnaud Quette]

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 :

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

Re: [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)
 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

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

[Charles Lepple]

On Apr 16, 2016, at 9:08 PM, Andy R - (NUT-List) 
 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.

-- 
Charles Lepple
clepple@gmail




___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

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

[Andy R - (NUT-List)]

On 17/04/2016 00:50, Charles Lepple wrote:

[as this list does not set or alter the Reply-To header, please use "reply 
all". Thanks!]


On Apr 16, 2016, at 5:14 PM, Andy R - (NUT-List) wrote:

I'm currently using the usbhid-ups driver but as the ups usb-ID isn't recognised in the udev rules 
I run it as root. Running usbhid-ups gives a "device not recognised" error but using '-x 
explore' gives a huge pile of information back. Though this could mean anything from just a small 
change needed all the way to "good luck" though.

So, what can I do to get my ups to work with NUT?


The debug output looks reasonable - I think you are close to getting this 
working. (If you have any other debug output to send, feel free to gzip the log 
file and it should get through to the list automatically, if less than 40kB 
when MIME-encoded.)

We can probably just add the IBM VID to the list of supported devices.

I am not familiar with Arch Linux. What is the easiest way for you to rebuild 
the package? I attached a patch file to add your device to both the driver and 
udev rules (diffed from master, but should work against 2.7.4).

I also kicked off a build, which generated this source tarball: 
http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/Eaton_IBM_VID/ra7f4858f1d220b4c10bf5afb51071ff174f7e4a8-548/nut-v2.7.4-20-ga7f4858.tar.gz
 (The tarballs don't require autotools or some other dependencies, but they 
would need a compiler and all of the relevant lib*-devel packages.)

It is possible that you could just change one of the Arch build scripts from "nut-2.7.4.tar.gz" to 
"nut-v2.7.4-20-ga7f4858.tar.gz" and rebuild, but I am totally speculating. (Note the extra 
"v" before the version number - I need to fix that...)



Hello Charles Lepple,


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.


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.


What a brilliantly quick response :).


Many thanks,

Andy R


NUT_out.text.gz
Description: application/gzip


NUT_usb_out.text.gz
Description: application/gzip
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

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

[Charles Lepple]

[as this list does not set or alter the Reply-To header, please use "reply 
all". Thanks!]

> On Apr 16, 2016, at 5:14 PM, Andy R - (NUT-List) wrote:
> 
> I'm currently using the usbhid-ups driver but as the ups usb-ID isn't 
> recognised in the udev rules I run it as root. Running usbhid-ups gives a 
> "device not recognised" error but using '-x explore' gives a huge pile of 
> information back. Though this could mean anything from just a small change 
> needed all the way to "good luck" though.
> 
> So, what can I do to get my ups to work with NUT?

The debug output looks reasonable - I think you are close to getting this 
working. (If you have any other debug output to send, feel free to gzip the log 
file and it should get through to the list automatically, if less than 40kB 
when MIME-encoded.)

We can probably just add the IBM VID to the list of supported devices.

I am not familiar with Arch Linux. What is the easiest way for you to rebuild 
the package? I attached a patch file to add your device to both the driver and 
udev rules (diffed from master, but should work against 2.7.4).

I also kicked off a build, which generated this source tarball: 
http://buildbot.networkupstools.org/~buildbot/docker-debian-jessie/snapshot/Eaton_IBM_VID/ra7f4858f1d220b4c10bf5afb51071ff174f7e4a8-548/nut-v2.7.4-20-ga7f4858.tar.gz
 (The tarballs don't require autotools or some other dependencies, but they 
would need a compiler and all of the relevant lib*-devel packages.)

It is possible that you could just change one of the Arch build scripts from 
"nut-2.7.4.tar.gz" to "nut-v2.7.4-20-ga7f4858.tar.gz" and rebuild, but I am 
totally speculating. (Note the extra "v" before the version number - I need to 
fix that...)

-- 
Charles Lepple
clepple@gmail




Eaton_IBM_VID.diff
Description: Binary data
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser