Andy R - (NUT-List)
2016-Apr-17 01:08 UTC
[Nut-upsuser] IBM 5396-1Kx ups nearly recognised.
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: NUT_out.text.gz Type: application/gzip Size: 1023 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160417/0e7d3ad0/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: NUT_usb_out.text.gz Type: application/gzip Size: 10217 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20160417/0e7d3ad0/attachment-0001.bin>
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. -- Charles Lepple clepple at gmail
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.