Re: [Nut-upsuser] Generic UPS driver
On Dec 21, 2013, at 11:36 PM, Ariel Wainer wrote: On 21/12/13 21:31, Ariel Wainer wrote: Ok, I did this, here is how it went (approximately): t=0 power on the UPS, with some load. t=2 min unplug the UPS from mains, alarm goes off. t=33 min low battery alarm goes off. t=35 min ups powers down. Ok, trying to make sense of the capture (again: it's all guessing, I have no experience with usb protocol): Up until packet #255/131 seconds in the pcap file, the payload is 0x03, then it changes to 0x01 , and then it changes again to 0x02 at packet #3975/2081 seconds. It seems like: 0x01 = AC failed 0x02 = Battery low. 0x03 = AC is ok Also, there is an Interrupt Out transfer at #4115/2154 (repeated at #4117) that sends a 0x01 down to the UPS. I assume it turns off at that point, or shortly thereafter? It looks simillar to the UPS implementation example from http://www.usb.org/developers/devclass_docs/pdcv10.pdf Well... the first few pages of Appendix A are boilerplate USB descriptors. The report descriptor (A.6) is where things start to differ. Your UPS doesn't have Usage Page 0x84, 0x85 or 0x86 in its report descriptor - it only has 0xFFA0, which is in the vendor-specific range, and the two Usage fields are just 8-byte unstructured buffers (also with vendor-specific IDs). It might be possible to tell usbhid-ups to match on the 0xFFA0 usage page, and ignore all of the other HID PDC definitions. I'll poke around the code. -- 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] (newb) Installing on windows w/Eaton 5110.
On Dec 17, 2013, at 12:45 PM, Bruce Bowler wrote: upsdrvctl stop and start don't complain... C:\Program Files (x86)\NUT\binupsdrvctl stop Network UPS Tools - UPS driver controller 2.6.5-3723:3731M C:\Program Files (x86)\NUT\binupsdrvctl start Network UPS Tools - UPS driver controller 2.6.5-3723:3731M C:\Program Files (x86)\NUT\binNetwork UPS Tools - BCMXCP UPS driver 0.26 (2.6.5 -3723:3731M) USB communication subdriver 0.21 - I'm not sure how this works on the Windows port, but you also need upsd running. This diagram shows how the pieces go together: http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html#_the_layering But many other commands complain... - C:\Program Files (x86)\NUT\binupsc nutdev1 Error: Connection failure: Unknown error - upsdrvctl seems to have successfully started the bcmxcp_usb driver, but for upsc to get data from the driver, it needs to go through upsd. If you have a TCP port listening on 3493, then upsd is running. For what it's worth, the 'system' is a host with several 'vmware player' VMs running on it. The eventual goal would be to have the host running as a nut server and have each of the VMs running a nut client so they can shut themselves down gracefully in the event of a longer power outage. Makes sense. Depending on how long a shutdown/startup cycle takes, it could be useful to suspend the VMs. -- 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] APC Smart-UPS 1500; system shutdown is not initiated.
On Dec 17, 2013, at 6:10 AM, Christian wrote: Charles, the unit has two redundant power supplies, with only one hooked up to the UPS. So I should be able to do a deep test with the machine itself, right? I have tried it, but it aborts at some point... It should work, but depending on how the current draw is split between the two supplies, the UPS might not see a constant load (which it needs to conduct an accurate calibration). For the quick test, it discharges the battery a bit, then recharges, but once it is back to 100%, upsc still gives me: ups.test.result: No test initiated Is that expected? Not sure. The quick test might be just verifying that the battery capacity hasn't changed much. (I only have a small Back-UPS, which I don't think has two test modes.) Best, Christian Am 17.12.2013 03:55, schrieb Charles Lepple: On Dec 8, 2013, at 10:41 PM, Christian wrote: test.battery.start.deep - Start a deep battery test test.battery.start.quick - Start a quick battery test Ideally, you would want to do a deep test with a dummy load, like a lamp, so as not to put your server in danger of getting cut off again. You can probably do the test.battery.start.quick test with the server still plugged into the UPS, though. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS 1500; system shutdown is not initiated.
On Dec 8, 2013, at 10:41 PM, Christian wrote: test.battery.start.deep - Start a deep battery test test.battery.start.quick - Start a quick battery test Ideally, you would want to do a deep test with a dummy load, like a lamp, so as not to put your server in danger of getting cut off again. You can probably do the test.battery.start.quick test with the server still plugged into the UPS, though. -- 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] APC Smart-UPS 1500; system shutdown is not initiated.
On Dec 7, 2013, at 2:38 PM, Christian wrote: Dear list, I have an APC Smart-UPS 1500 hooked up via the USB port. Recently, when we had a power outage, the only entry in the logs was: Dec 3 14:43:43 afs1 upsmon[3035]: UPS apc@localhost on battery and then the machine seems to have run until the battery was empty. It only notices the battery low after I turn the system back on: [...] Occasionally, i get these in daemon.log: Dec 4 03:11:54 afs1 usbhid-ups[21973]: libusb_get_interrupt: could not claim interface 0: Device or resource busy This isn't great, but I don't think it's related. It is normal to get a could not claim interface 0 error once after the USB cable is first plugged into a Linux box. When usbhid-ups starts up, if it gets that error, it has to detach the kernel HID driver. After that point (until the USB cable is unplugged or the box is rebooted), you shouldn't see that error. I don't think you should see it from the libusb_get_interrupt function, either. I'd check the logs here, but the usbhid-ups driver is running on a BSD box at the moment, which doesn't have the same problem as Linux. How often do you see it? Is there a possibility of another program trying to access the UPS? Dec 6 11:50:55 afs1 usbhid-ups[21973]: libusb_get_interrupt: error sending control message: Connection timed out We increased the USB timeout in 2.7.1, so this should go away after upgrading. These sorts of transient errors are not a problem unless you get several in a row, and the driver should log a different message at that point. afs1:/var/log# upsc apc@localhost battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 50 battery.mfr.date: 2008/05/22 ^ If this date is accurate (and I don't know for sure if our code can reliably update this), then you may want to consider a new battery. Although an UPS battery doesn't see the extreme temperature cycling that a car battery does, it does typically run a few degrees above ambient, and the lead-acid chemistry is only good for 3-5 years of reliable service. [...] ups.test.result: No test initiated ^ Occasional battery tests are needed to ensure that the calibration values can predict when the battery is about to run out. Some info is here: http://forums.apc.com/thread/8669 If you post the output of 'upscmd -l apc', we can try to figure out which calibration command would be the best to try. -- 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] new related project nutdown: https://github.com/arwarw/nutdown
On Dec 6, 2013, at 8:21 AM, Alexander Wuerstlein wrote: I'd like to announce nutdown, a nut client written using perl UPS::Nut. Thanks for posting this. One thing that I would consider changing is to treat ups.status as a set (splitting on whitespace, if any), and to not rely on the order of the status flags. Actually, splitting ups.status into an array of strings should probably be done in UPS::Nut, but that module doesn't look like it has been updated in a while. -- 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] Plea for a more loquacious nut [short power events]
On Dec 7, 2013, at 12:06 AM, Kris Jordan wrote: apcsmart quick power cuts @ 20 30 usbhid-ups @ 30 40 The APC unit logs alert_handler: OB. usbhid-ups isn't so obvious, so I'm not sure. $ grep send_to_all usbhid-ups.log|grep ups.status 10.538414 send_to_all: SETINFO ups.status OL CHRG 30.912005 send_to_all: SETINFO ups.status OB DISCHRG 32.585047 send_to_all: SETINFO ups.status OL CHRG 40.667472 send_to_all: SETINFO ups.status OB DISCHRG 43.223281 send_to_all: SETINFO ups.status OL CHRG At least the apcsmart driver is reacting immediately, but upsmon reports nothing unless I cut power long enough. upsmond has noticed quick power cut, but I think that's because It happened at the same time as the normal check interval. I'm using defaults here, as far as poll intervals. Maybe upsd is getting the message, does it push upsmon? Good point. It's polling, at a default interval of 5 seconds: https://github.com/networkupstools/nut/blob/v2.7.1/clients/upsmon.c#L2010 Adding something like the IMAP IDLE command to the NUT protocol should enable pushing messages, but would require the client polling loops to be reworked. In the short term, decreasing the upsmon.conf POLLFREQ and POLLFREQALERT settings should catch the shorter events. I thought to try upsd at full debugging to see if it says anything, but it appears that nothing special is shown for UPS/driver events. I added the upsd case to https://github.com/networkupstools/nut/issues/79 -- 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] Plea for a more loquacious nut
On Dec 4, 2013, at 3:52 PM, Kris Jordan wrote: Roger Price wrote, On 12/4/2013 12:35 PM: I would like nut to become more loquacious, and to log a much more complete report of its activity. At present nut reports that its components have started operation but does not automatically log their activity when UPS's switch between OB and OL. I believe that this under-reporting of important facts is too minimalist - it would be better for system administrators and for the nut support team if a much more complete report were available of all OB/OL activity by each component. I've noticed that NUT doesn't notice short power outages or glitches like previous setups (APC Smart-UPS+Apcupsd) I've had. I do miss that. I thought NUT supported UPS notifications/interrupts so that it can know of power events that happen in-between the regular poll interval. But I don't how much the lack of reporting is due to NUT or the Eaton UPS's I am using now. The default setting in upsmon.conf for ONLINE/ONBATT is SYSLOG+WALL. If those events aren't being logged, we would need to trace further upstream and see if the driver is generating the events. Kris: I don't know the various debug levels off the top of my head, but if you want to manually start the driver with a few -D flags and log the resulting output, we can see whether or not your UPS is sending the notifications the way that the driver is expecting them. -- 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] Plea for a more loquacious nut
On Dec 4, 2013, at 3:35 PM, Roger Price wrote:
I would like nut to become more loquacious, and to log a much more complete
report of its activity. At present nut reports that its components have
started operation but does not automatically log their activity when UPS's
switch between OB and OL. I believe that this under-reporting of important
facts is too minimalist - it would be better for system administrators and
for the nut support team if a much more complete report were available of all
OB/OL activity by each component.
In principle, more logging sounds like a good idea. What syslog level
adjustments would you propose?
Looking at the source code, it seems that much of what is needed is already
in place, but behind if conditions that ensure that little or nothing gets
through. Long ago I wrote software, including a compiler, but my C
programming is limited to a class exercise many many years ago, and its based
on this experience that I'm guessing that in upssched.c function exec_cmd
the code
snprintf(buf, sizeof(buf), %s %s, cmdscript, cmd);
err = system(buf);
if (WIFEXITED(err)) {
if (WEXITSTATUS(err)) {
upslogx(LOG_INFO, exec_cmd(%s) returned %d, buf,
WEXITSTATUS(err));
}
attempts to send a command to the operating system, possibly to execute a
Bash script. If system(buf) fails, the tests block the error message. Surely
the error message is essential. An unattended box is now in an emergency
situation. After the inevitable IT failure the system should be auditable to
discover what went wrong and what should be done to prevent it happening in
the future. Such an audit expects to find exec_cmd(%s) returned %d in the
log.
Are you looking for:
* more diagnostics depending on the value of err,
* logging of all return codes, even success
or both?
But these problems should be found by testing!, one might argue. Firstly,
the testing would be facilitated by this error message, and secondly, no
amount of testing will ever cover every situation met in the real world.
I believe nut would be improved by
1. Logging a summary of the state of the nut system and the UPS's every 24
hours.
I would personally prefer that NUT didn't do this by default. (Then again, I
don't do a lot of sysadmin work for critical systems, so take that with a grain
of salt.) To me, this seems like a call to 'upsc' should be placed in a nightly
cron job. If you have multiple UPSes, you can iterate over them. We could add
an example script to the NUT source tree for that.
2. Automatically logging a record of driver, upsd, upsmon and upssched
activity for each OB/OL change.
Fair point. I don't think logging at every single point is necessary, but if
it's configurable, that would work.
3. Replacing the upsmon NOTIFYFLAG SYSLOG by NOSYSLOG. All notifications
are logged unless the sysadmin explicitly calls for no logging.
I suspect I am missing something here. The default upsmon.conf logs everything
to syslog (and wall) by default. Unless that part is broken (and I confess I
haven't thoroughly tested it recently), wouldn't the defaults work without
breaking existing installations? I agree that it is better to err on the side
of logging more information, but I don't think we need to break the existing
syntax to do that.
If anything, I would want finer-grained control over the syslog level for some
of these events.
--
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] Installing NUT for PowerWalker VI 1500 LCD
On Dec 3, 2013, at 12:06 PM, Danijel Šili wrote: OK, but since I moved the cable around its now 3/2: crw-rw-r-- 1 root nut 189, 257 Dec 3 18:04 /dev/bus/usb/003/002 ... which is what the MODE=664 udev rule set. Is there by chance some other udev rule which might match your ups? (There are a number of devices out there which use Cypress chips - maybe another package changed the permissions as well.) On Tue, Dec 3, 2013 at 1:54 PM, Charles Lepple clep...@gmail.com wrote: On Dec 3, 2013, at 1:10 AM, Danijel Šili wrote: On Tue, Dec 3, 2013 at 2:52 AM, Charles Lepple clep...@gmail.com wrote: On Dec 2, 2013, at 11:01 AM, Danijel Šili wrote: Since the permission change helped, I can now continue with the configuration. Thanks for the help :) What are the final permissions? Don't know which permissions are being checked. Can you tell me where to check the permissions? Using the output of lsusb, such as your example before: Bus 004 Device 006: ID 0665:5161 Cypress Semiconductor USB to Serial ls -l /dev/bus/usb/004/006 -- 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] Installing NUT for PowerWalker VI 1500 LCD
[Please subscribe to the mailing list:
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser ]
On Nov 28, 2013, at 4:10 PM, Danijel Šili wrote:
Since the provided drivers come with absolutely no installation instructions,
I turned to NUT.
The compatibility list says blazer_usb should be used for PowerWalker's
devices, so that's what I put in my conf:
[pwvi]
driver = blazer_usb
port = auto
desc = PowerWalker VI 1500 LCD
The configuration file looks good.
Since I use Ubuntu Server 13.10 so I installed nut from apt.
What is the exact NUT package version (including the Ubuntu-specific version
number)?
The product information PDF for the device in quesetion is
http://www.powerwalker.com/datasheet/Line-Interactive/PowerWalker%20VI%201500%20LCD.pdf
[...]
$ lsusb
[...]
Bus 004 Device 006: ID 0665:5161 Cypress Semiconductor USB to Serial
^ This is most likely your UPS.
Josu Lazkano just emailed this list last month with a similar problem (NUT
2.6.4 on Debian):
http://thread.gmane.org/gmane.comp.monitoring.nut.user/8180
There should be an entry in /lib/udev/rules.d/52-nut-usbups.rules for
0665:5161, but apparently the one in the Debian 2.6.4 package wasn't working:
ATTR{idVendor}==0665, ATTR{idProduct}==5161, MODE=664, GROUP=nut
Josu said that creating this udev rule solves the issue:
SUBSYSTEM==usb, ATTRS{idVendor}==0665, ATTRS{idProduct}==5161, GROUP=nut
But given the additional goto statements in the NUT udev file, those should
be equivalent.
What version of udev and the Linux kernel do you have on your system?
--
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] upsmon error: Unable to call shutdown command
On Dec 1, 2013, at 8:46 AM, Roberto Martelli wrote: If you call /usr/sbin/pm-hibernate from the command line, does it execute correctly? Roger Obviously. You would be surprised how many times people forget things like #! or the execute bit in their shell scripts... Also thi command doesn't works with upsmon (but works from command line): /usr/sbin/hibernate That is odd. We aren't doing anything special to execute the command, just a system(2) call: https://github.com/networkupstools/nut/blob/v2.7.1/clients/upsmon.c#L1683 I'll admit that there could be better error reporting. I added an issue on GitHub, but if you built from source, you can extend the upslogx() command line to see why system() is failing. -- 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] upsmon error: Unable to call shutdown command
On Dec 1, 2013, at 8:19 AM, Roberto Martelli wrote: My nut version is 2.7.1 (autocompiled) Is it safe to assume you are using Linux (given the pm-hibernate command)? Are there any access control systems such as SELinux or AppArmor that might be interfering with the system() call? -- 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] Installing NUT for PowerWalker VI 1500 LCD
On Dec 2, 2013, at 11:01 AM, Danijel Šili wrote: Since the permission change helped, I can now continue with the configuration. Thanks for the help :) What are the final permissions? If possible, we would like to fix the NUT package so that it works out of the box. Removing the MODE= line seems like it should either fail due to more restrictive default permissions, or it would work due to less-restrictive and possibly less secure permissions. -- 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] NUT-HAL (for use with USB UPS's and Gnome)
On Nov 22, 2013, at 1:32 PM, Ben Kamen wrote: Will nut's UPS driver happily coexist with the GNOME's UPS stuff? Or do I need to disable GNOME from sticking its fingers into NUT's control of the UPS? usbhid-ups might handle that for you. The NUT HID drivers detach the kernel usbhid driver from the UPS, and that is probably what Gnome is using. But I haven't really looked at Gnome power management in a while. -- 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] NUT-HAL (for use with USB UPS's and Gnome)
On Nov 18, 2013, at 10:39 AM, Ben Kamen wrote: My first attempt to post this bounced -- this is a 2nd try. Sorry about that - Alioth, the server that hosts the lists, was down due to disk failure: http://lists.debian.org/debian-infrastructure-announce/2013/11/msg1.html I've recently installed a CyberPower OR500 on a CentOS 6.4 system. nut comes RPM'd as nut-hal -- and I've played a little with it - but I'm trying to figure out just what it provides at that point. (looking at the docs, I'm not quite sure) The idea was that the HAL-based drivers would make the UPS appear like a battery to the GNOME power management software, but then HAL was deprecated. So we never really finished the documentation. I'd like NUT on this system to allow my NUT master server to just monitor and email notification as the system NUT-HAL is running on is standalone on its UPS and that's fine with me. I just want to know when the system has power issues and work NUT's monitoring in with my Munin master server as well. Should I move to the full NUT version on this system (and switch to Serial and not USB?) No need to switch to serial if USB is working - there should be a nut-usb package or similar. You will probably have to remove nut-hal to install nut-usb. The nut+upsd+upsmon solution is mutually exclusive with nut-hal, but they use the same device-specific code, and it sounds like your device is compatible. -- 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] Salicru SPS One in Debian
On Nov 8, 2013, at 3:23 AM, Josu Lazkano wrote: Hello, I have a Salicru SPS One 700VA device, I want to manage it with Debian Whezzy. I read some information in the net about how to configure but I can not get it working. I'm assuming you mean this blog post? http://blog.ciberterminal.net/2013/04/28/ups-salicru-en-nut/ Could you help with this? This is the log when I connect the USB: [ 3194.688204] usb 4-4: new low-speed USB device number 2 using ohci_hcd [ 3194.857239] usb 4-4: New USB device found, idVendor=0665, idProduct=5161 [ 3194.857250] usb 4-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 3194.857258] usb 4-4: Product: USB to Serial [ 3194.857264] usb 4-4: Manufacturer: INNO TECH [ 3194.997545] generic-usb 0003:0665:5161.0001: hiddev0,hidraw0: USB HID v1.00 Device [INNO TECH USB to Serial] on usb-:00:12.0-4/input0 [ 3194.997596] usbcore: registered new interface driver usbhid [ 3194.997601] usbhid: USB HID core driver OS name and version: Debian Whezzy (3.2.0-4-amd64 kernel) NUT version: 2.6.4-2.3 NUT installation method: apt-get install nut exact device name and related information: Salicru SPS One 700VA I try with this configuration: nut.conf: http://paste.debian.net/plain/64527 It's really not necessary to use a pastebin for a one-line configuration file... ups.conf: http://paste.debian.net/plain/64528 upsd.conf: http://paste.debian.net/plain/64529 upsd.users: http://paste.debian.net/plain/64530 I would recommend changing the password once you put this system into production. upsmon.conf: http://paste.debian.net/plain/64531 When I try to get the device info, I get this: # upsc salicru Error: Driver not connected What other startup and debugging steps did you take? For testing on Debian, I would try 'sudo /lib/nut/blazer_usb -a salicru -DDD' If that works, you can ^C that and run 'sudo /etc/init.d/nut-server start'. -- 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] Is UPSD necessary for average users?
On Nov 3, 2013, at 11:33 PM, David N Melik wrote: I would still like to know if running UPSD on a port is essential, rather than not having a port... crond and atd, for example, do not need ports, so why would UPSD? We are talking about the *Network* UPS Tools here... No, upsd does not strictly *need* a network port. You could rewrite things to talk directly to the Unix-domain socket that the drivers typically use to talk to upsd. When I cited the FAQ before, I incorrectly stated that you wouldn't be able to connect multiple clients to such a server. I must have been confusing named pipes and Unix-domain sockets. An alternative Unix-domain socket upsd would need a maintainer, and I think most people wouldn't mind spending the extra time to lock down the existing TCP-based implementation rather than writing and maintaining a parallel daemon. But as I mentioned earlier, there was work done on a HAL alternative to upsd. That used D-BUS instead of a TCP socket, and integrated better with the desktop. However, HAL has been deprecated, and the developer who did the NUT+HAL integration hasn't had time to work on a follow-on system that would interface to UPower. Would you be interested in helping out with this? -- 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] Is UPSD necessary for average users?
On Oct 7, 2013, at 4:48 AM, David N Melik wrote: What are you trying to optimize? nothing, but I just did not want another daemon running, or at least I do not want a port open that can access the UPS, because I will not be using it; it is more of a minor security issue than anything. The instructions I read said to set up that port in NUT configuration, but I would rather not set that. I forgot to mention: by default, NUT listens on localhost. If you are using Linux, you could add a -m owner --uid-owner rule to iptables to only match the UID for the NUT system user. -- 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] Is USBD necessary for average users?
On Oct 1, 2013, at 11:58 PM, David N Melik wrote: I followed the NUT instructions that are on the projects site, I think, ^ The official NUT site? Feel free to post the URL. and they said to set up USBD, so I did. Is that necessary for average users using one PC (rather than servers), or will something not work right if I reread and turn off USBD? I think Alexander explained upsd well, but here's some additional history and explanation. Question 10, Answer 2 of the FAQ http://www.networkupstools.org/docs/FAQ.html points out that it is possible to customize the NUT code, and combine upsmon and upsd into a single daemon that talks to a driver. The disadvantage is that you wouldn't be able to connect more than one client at a time, so debugging the driver with upsc would no longer be possible. Arnaud also experimented with writing a freedesktop.org HAL version of the usbhid-ups driver. This was more suited to a single PC, and worked much like the laptop battery power monitors, but HAL is deprecated now. We could certainly use more help in this area - I think a lot of the people who have contributed to NUT over the years have needed more of the data center functionality. What are you trying to optimize? -- 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] How to find out the output of upsc for each UPS model supported by NUT ?
On Sep 19, 2013, at 2:19 PM, Alf Høgemark wrote: Just to let you know, I am looking at various wiki software, and aim to set up a wiki where we all can document the output from our different UPSes with different drivers, I think it will help people who are looking to buy UPS and want to use it with NUT. I hope to have the wiki up during October, but cannot promise anything. Just thinking out loud - if none of the wiki packages have anything that would be easy to customize (such as my previous suggestion of filtering based on needed features), there is always the GitHub wiki component. -- 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] UPS compatibility list
On Sep 19, 2013, at 12:11 PM, Paul O'Rorke wrote: So where does this leave things regards Eaton and shut down? Has anyone managed graceful shut down from an Eaton unit with either of the ushhid or bcmxcp drivers? Generally speaking, the UPS will signal when it reaches a low battery state, regardless of whether the UPS publishes runtime statistics, battery percentages, or any other such values. The real difference between a smart and dumb UPS is not just the protocol, but how advanced the battery monitoring and charging circuitry is. I have an old MGE UPS that uses the usbhid-ups driver, and I have no problems shutting down the system via the LB signal in NUT. The non-Powerware-based Eaton units can be considered descendants of this hardware, from what I understand, and provide similar variables. (Note that I am not affiliated with Eaton. Along those lines, the developers of NUT would not know if a new Eaton model would not work with NUT until someone reports it to the mailing list, but that has not been an issue to date.) Alf has already commented on the bcmxcp side. -- 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] Liebert PSA UPS problem.
On Sep 10, 2013, at 9:30 AM, Paul Smith wrote: Hi all, Sorry for the delay - three business trips abroad and LOTS of head scratching with USB Keys and DVD's of SuSE and FreeBSD... The question about the USB reports from Windows is still unanswered (I am abroad again !), but *think* the Liebert driver had been stopped. I'll be honest, I don't really want to speculate on all of the possible things that might be going on in the background in Windows. A potentially useful trace (and I can't guarantee it will prove anything) would be to disable the Liebert driver, shut everything down (including powering off the UPS, and unplugging it from the wall for a few seconds to clear any potential saved state), and trace what Windows does at boot time. Then we would compare that to what the driver does (probably one of the older traces). My concern is that there is something being sent to the UPS in Windows, but not in FreeBSD. Given that the virtual environments are not yielding correct results, I am not sure exactly how we compare these traces to FreeBSD. I can report the following updates for my linux setups; SuSE/FreeBSD/FreeNAS [remember here I am trying to make nut work for a physical machine running FreeNAS]: * SuSE Live CD will successfully obtain descriptors. Hurrah! * I am not sure how being able to build NUT for a SuSE environment may help, but I think I am in a situation where I can do it. - I now have a 'Live' USB stick and a partition on it that is persistent. This also reads the descriptors. I think this was to make sure that we didn't break anything after the 2.6.5 release, but also to possibly add in any extra USB code to emulate what Windows is doing. * my NAS box has now been updated to FreeNAS 9.1 ... but there is no change to UPS behaviour - still can't obtain descriptors. * I now also have FreeBSD 9.1 (not FreeNAS, but the 'base' of it) running as a VM, not as a 'Live' install - this includes nut sources which I believe I can build for my NAS box. * Both implementations of nut : FreeBSD 9.1 in a VM environment and FreeNAS 9.1 as a physical standalone machine behave in the same way...i.e. can't obtain the descriptors properly, even though the same SuSE version of nut can. Unfortunately, this doesn't narrow things down much. I am at a loss here. * I am now stuck again - my FreeBSD ports collection for nut does not seem to be the latest source - it reports Network UPS Tools - Generic HID driver 0.37 (2.6.4) ... my NAS box and SuSE implementations both report 2.6.5 These page indicate that the ports tree is now at 2.6.5, since November 2012: http://www.freshports.org/sysutils/nut/ http://svnweb.freebsd.org/ports/head/sysutils/nut/ There are several tools for updating the ports tree, after which you would need to rebuild the port. * Finally my FreeBSD VM output is only as follows - I am not sure why it is not finding the UPS: 0.00debug level is '5' 0.024036upsdrv_initups... 0.025984No appropriate HID device found 0.026251No matching HID UPS found Network UPS Tools - Generic HID driver 0.37 (2.6.4) USB communication driver 0.31 I was hoping to be able to report back that my FreeBSD implementation was working in the same way as my FreeNAS, but this seems to have a more fundamental reason for not wanting to play. I really need to collect all of our *BSD/USB wisdom in one spot, but off the top of my head, I think this is a permissions issue. If NUT (libusb, really) doesn't have permission to scan the USB bus (which I think requires write permission to *several* /dev nodes), it won't report any USB devices at all. This is, of course, assuming the USB device for the UPS has been passed through to the VM guest. You can get a list of the basic /dev nodes with 'usbconfig' run as root. More info: http://lists.alioth.debian.org/pipermail/nut-upsuser/2006-May/00.html -- 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] UPS repeater configuration using localhost
On Sep 12, 2013, at 7:47 PM, Derek Rachul drac...@gmail.com wrote: I tried reversing the order of the definitions in the config file, and it does seem to change the order in which they're loaded (at least according to the system logs) however the error remains. I don't have any experience using the dummy-ups driver on the same host as the real UPS driver, so this is a shot in the dark. Can you manually run upsdrvctl start qnapups? If it works that way, we may have a race condition in dummy-ups. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] infosec e4
On Aug 31, 2013, at 9:09 PM, James HORLEY wrote: I'm using upssched to shutdown computer after 15mn when on battery. Should I trigger upsmon -c fsd with my script? I mean, is it the normal way to shutdown both computer and ups. Yes, if you are shutting down the UPS early: http://www.networkupstools.org/docs/man/upsmon.html#_forced_shutdowns -- 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] infosec e4
On Sep 3, 2013, at 8:16 AM, Goslawski, Dawid (NSN - PL/Wroclaw) wrote: Oh, so this means that FCD will really send shutdown command to ups (so turn off working on battery) or only to upsmon ? I will also use upssched cause our systems need approx 15min to shutdown gracefully and I want to know how to properly do it. I don't use upssched myself, I'm just pointing out the relevant sections of the documentation. I'm pretty sure it explains this. The right way to do this is to use an UPS which implements battery.runtime.low, and let the UPS start the shutdown when less than 15 minutes of power (plus a safety factor) are available. -- 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] Question marks in Broadcast Messages
On Aug 28, 2013, at 6:05 PM, John Thurston wrote: I'm setting up a NUT server. During testing, I have deployed it on both CentOS and SUSE. I have both servers looking at two physical UPSs and two dummy UPSs. My NUT client is running on Solaris and is rigged to look at the dummy UPSs. As I toggle states on the dummy UPSs, the client correctly detects the changes and throws a message of the type: Broadcast Message from ups (???) on nut Wed Aug 28 13:57:08... UPS dummy@upsmon on line power The messages are of the same form regardless of the source server. What is the meaning of the (???) in that message? Is it a place holder for some value or attribute in the UPS driver I have not configured correct? I think that part of the output is controlled by the 'wall' command. If you run 'wall' from a command line, does it display your current TTY? The current TTY isn't defined once a process daemonizes. The wall output is optional, especially if you have your own NOTIFYCMD defined in upsmon.conf. http://www.networkupstools.org/docs/man/upsmon.conf.html -- 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] Slave only configuration
On Aug 28, 2013, at 8:03 PM, John Thurston wrote: It appears that, without munging the startup scripts, it isn't possible to create a slave-only configuration. The scenario is this: My NUT server doesn't need to turn off, it isn't allowed to turn the UPS off, and it isn't authoritative to turn any other server off. Its only job is to make UPS status available to NUT clients. My NUT clients are independent of the NUT server. Each is its own business case and will independently decide if the shutdown criteria has been met. The questions are: Why am I required to run upsmon on the NUT server? Is there a way to achieve this configuration without munging the startup scripts? The short answer is no, not currently. If I understand correctly, you just want to run upsd and the driver on the NUT server. Adding something like upsdrvctl start upsd to the equivalent of rc.local should work, although this could get messy with newer distributions that use things like systemd, if rc.local doesn't implicitly depend on networking. (I don't know what CentOS or SUSE use for their init process.) If your distributions are reading nut.conf, you would probably need MODE=none to prevent extra copies of upsd, the driver and upsmon. Creating a dummy upsmon.conf that can't log status or shut down the server is also a possibility. It's certainly possible for us to add an option like MODE=netdriver to nut.conf. (slave only has a bit of a namespace collision with the description for MODE=netclient, since that client logs into the server as a slave.) Then, we would need to get the various distributions to adopt that additional mode in their init scripts. I'm concerned that something that was meant to be a shortcut for specifying common sets of NUT processes is creating more problems that it solves. Right now, we have four modes to cover three daemons, and this use case introduces a fifth mode. I can't help but wonder if there is a better way to represent these configurations. -- 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] Opti-UPS Value Series 575C
On Aug 26, 2013, at 3:10 PM, Florian Bruhin wrote: queequeg Subtlety is key :-) It came with some Sentinel software for Windows. Hmm, not sure if this is similar to software we have seen before. Also, what does the red color mean in the compability table? Anything that's not supported, or is it just you have to solder your own cable but then you should be okay? Technically, one star is protocol based on reverse engineering (key is at the top of the page) but the ratings are somewhat subjective beyond that (some protocols are easier to understand than others). On the other hand, if it doesn't work, I might just start trying to reverse-engineer the protocol. Sounds like a nice way to get started with reverse-engineering :) There are some pointers in the list archives (also check nut-upsdev). It's certainly up to you as to how you want to approach this, but we do see a lot of commonality in the protocols - so feel free to post updates as you go along. There is a good chance that the protocol is similar to another driver, but that driver may have failed to detect that protocol variant. -- 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] infosec e4
On Aug 26, 2013, at 6:22 AM, James HORLEY wrote: I've download again nut source today from https://github.com/networkupstools/nut/tree/voltronic-driver; and try compiliing the voltronic-driver. This branch has been merged in, and will be part of 2.7.1 when it is released. The drivers is working fine (ie computer is shutting down) except for the shutdown of the ups. I can shutdown the ups by sending the command shutdown.return but standard shutdown doesn't work. upsmon -K return: upsmon -K is for use inside a shutdown script. (See the man page for details.) I think you want upsmon -c fsd, which triggers the entire shutdown sequence. -- 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
[Nut-upsuser] Fwd: NUT under NAS4Free config issue
[forgot to include the list] Begin forwarded message: From: Charles Lepple clep...@gmail.com Subject: Re: [Nut-upsuser] NUT under NAS4Free config issue Date: August 26, 2013 9:03:35 AM EDT To: Incze Andras andrisga...@gmail.com On Aug 26, 2013, at 8:08 AM, Incze Andras wrote: Here is the result with the code inserted into script and the modified script too I didn't realize that the xml command didn't add a trailing newline, and I should not have indented the [monslave] line. The attached script should work better. -- Charles Lepple clepple@gmail nut Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT under NAS4Free config issue
On Aug 23, 2013, at 12:49 PM, Incze Andras wrote:
There is some problem with formatting :(
If I paste how was written, the structure is wrong formatted, is putted
somewhere right after the end of 1st part with master in the generated file.
Can you be more specific? You can attach text files if needed.
On Thu, Aug 22, 2013 at 3:32 PM, Charles Lepple clep...@gmail.com wrote:
On Aug 22, 2013, at 5:15 AM, Incze Andras wrote:
Thanks, the strange is that I could set in this way the master user.
That is odd. The development version of NAS4Free seems to be regenerating the
entire upsd.users file:
http://sourceforge.net/p/nas4free/code/848/tree/trunk/build/ports/nut/files/nut.sh.in
To address your original concern (adding remote users for monitoring), I
would edit the RC file, which is probably /usr/local/etc/rc.d/nut, to include
something like this at the end of the nut_mkconf() function:
cat __EOF__ ${nut_upsd_users}
[monslave]
password = abcd
upsmon slave
__EOF__
(Be sure to add it after the line containing ... ${nut_upsd_users})
Of course, this will be lost when you upgrade NAS4Free, but maybe you can
convince one of the developers to add this as a core feature, such that the
list of slave users can be read from the XML configuration file.
--
Charles Lepple
clepple@gmail
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
--
Charles Lepple
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT under NAS4Free config issue
On Aug 22, 2013, at 5:15 AM, Incze Andras wrote:
Thanks, the strange is that I could set in this way the master user.
That is odd. The development version of NAS4Free seems to be regenerating the
entire upsd.users file:
http://sourceforge.net/p/nas4free/code/848/tree/trunk/build/ports/nut/files/nut.sh.in
To address your original concern (adding remote users for monitoring), I would
edit the RC file, which is probably /usr/local/etc/rc.d/nut, to include
something like this at the end of the nut_mkconf() function:
cat __EOF__ ${nut_upsd_users}
[monslave]
password = abcd
upsmon slave
__EOF__
(Be sure to add it after the line containing ... ${nut_upsd_users})
Of course, this will be lost when you upgrade NAS4Free, but maybe you can
convince one of the developers to add this as a core feature, such that the
list of slave users can be read from the XML configuration file.
--
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] NUT under NAS4Free config issue
On Aug 22, 2013, at 10:09 AM, Incze Andras wrote: Two questions - Do I need separate users for each WinNUT client or they can use the same user for monitoringshutdown client machines ? You can reuse the same username/password on each client machine. Think of it like a Unix login - you can have two or more SSH simultaneous sessions using the same login and password. Not sure about the second question. -- 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] NUT under NAS4Free config issue
On Aug 21, 2013, at 10:41 AM, Incze Andras wrote: Having the next problem, manually adding via WinSCP in the upsd.users file the user for remote monitoring, saving the file, WinNUT client connects after upsd -c reload in NAS4Free console, but if I restart the NAS4Free system, the slave user disappears from upsd.users and remains only the master user. NAS4Free is version 9.1.0.1 rev 724 and NUT is the version what is included. You will probably need to check with the NAS4Free folks - if it is similar to the latest FreeNAS, some of the NUT configuration files are generated from configuration databases that are outside the scope of NUT. (I assume this is to make it easier to modify permissions from the web GUI.) Let us know what you find out. -- 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] Liebert GXT3 ID 10af:0000 Not working
[please keep the list CC'd.] On Aug 20, 2013, at 12:50 AM, Korviakov Andrey wrote: Yes, it's my mistake: UPS used USB cable for communication, but i think that it's simple usb-com cable because nut work with liebert driver on ttyS0 port. If that is the case, I doubt that usbhid-ups will be able to retrieve any additional information. In ups.conf i tried: [liebert] driver = usbhid-ups port = auto vendorid = 10af explore but got error: Can't claim USB device [10af:]: could not detach kernel driver from interface 0: Operation not permitted Driver failed to start (exit status=1) Usually the simpler reason is that the driver does not have permission to detach the kernel driver. If an UPS is not listed as supported by NUT, then the udev rules have not been applied to that device. This problem described at this page: http://belgorod.lug.ru/wiki/index.php/%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_UPS if you got this error check kernel config… CONFIG_USB_HID=y CONFIG_USB_EHCI_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set They suggested disable CONFIG_USB_DEVICE_CLASS option and rebuild kernel. Now i rebuilding kernel, and try again. 20.08.2013, в 6:21, Charles Lepple clep...@gmail.com написал(а): On Aug 19, 2013, at 9:10 PM, Charles Lepple wrote: On Aug 19, 2013, at 12:58 PM, Korviakov Andrey wrote: I have Liebert GXT3 UPS connected to CentOS Linux with kernel 2.6.32-131.0.15.el6.x86_64 and nut version 2.6.5-2. lsusb: Bus 002 Device 003: ID 10af: Liebert Corp. UPS And this UPS detected only with this section in ups.conf: [liebert] driver = liebert port = /dev/ttyS0 I am confused. Are you using a serial cable with the liebert driver, or a USB cable with the usbhid-ups driver? Actually, for the serial 'liebert' driver, it will only detect OL/OB/LB. We haven't had much luck with the USB firmware on other Liebert units, but if it's anything like some of the other UPSes out there, you may need to power the UPS completely off (unplug from the wall, no LEDs on, etc.) before switching between USB and serial. Also, running the usbhid-ups driver with debugging enabled may shed some light on the problem. -- 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] APC Back-UPS CS and ES series
On Aug 18, 2013, at 8:59 AM, Charles Lepple wrote: On Aug 18, 2013, at 12:14 AM, Lyndon Drake wrote: I'm happy to test an updated build, but have no idea about how to go about doing a build in the first place. Could someone help me in the process of creating a snapshot build for FreeNAS? I am not familiar with the specifics of building for FreeNAS, but our BuildBot instance is making source snapshots again: http://buildbot.networkupstools.org/public/nut/waterfall?show=Debian-x64-gcc On the Uploading... step, there is currently a link to nut-2.7.1-pre1.tar.gz - that can be built just like 2.6.5. Somewhere in the FreeNAS source is the command line that you would use to configure NUT to put all of its binaries in the same place that FreeNAS does. Someone asked for that in the second forum link, but there wasn't an answer in that thread. I also didn't see that in a quick search of the NUT archives (we've done this a few times to test out similar in-place upgrades in Linux.) I think I see where FreeNAS is getting their copy of NUT. They use a ports tree, so I tried building the latest NUT tarball in /usr/ports/sysutils/nut on a FreeBSD 9.1 box (in place of 2.6.5). http://www.freshports.org/sysutils/nut/ The port build system doesn't like our intermediate version number (2.7.1-pre1), so I hacked that to be 2.7.0. There are also some patches which don't apply, so I blindly removed them. I suspect they will need to be regenerated by the port maintainer. None of this should stop you from building a copy of just one driver, and copying it over the 2.6.5 driver. (The version number doesn't matter there.) I haven't tried this in my FreeNAS VM yet, but I think you can download the snapshot (see buildbot URL above), and configure it like so: ./configure --sysconfdir=/usr/local/etc/nut --program-transform-name= \ --localstatedir=/var/db/nut --datadir=/usr/local/etc/nut \ --with-drvpath=/usr/local/libexec/nut --with-statepath=/var/db/nut \ --with-altpidpath=/var/db/nut --with-pidpath=/var/db/nut \ --with-pkgconfig-dir=/usr/local/libdata/pkgconfig \ --with-user=uucp --with-group=uucp --with-dev --without-cgi \ --with-drivers=usbhid-ups \ --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ \ --build=amd64-portbld-freebsd9.1 Then cd drivers; make usbhid-ups, and copy usbhid-ups to /usr/local/libexec/nut -- 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] Problems with a Tripplite Smart150LCD UPS
On Apr 5, 2013, at 11:08 PM, Randy Philipp wrote: I am currently running FreeNAS-8.3.1-RELEASE-x64 (r13452) using the packaged version of NUT, 2.6.5, using the usbhid-ups (Generic HID driver 0.37). Here is the output of /usr/local/libexec/nut/usbhid-ups -D -D -D -D -D -D -a tripplite: Network UPS Tools - Generic HID driver 0.37 (2.6.5) USB communication driver 0.31 0.00send_to_all: SETINFO driver.parameter.port auto 0.27send_to_all: SETINFO driver.parameter.productid 3016 0.44debug level is '6' 0.000510upsdrv_initups... 0.000884Checking device (09AE/3016) (/dev/usb//dev/ugen1.3) Randy, were you ever able to get this working? One thing I didn't think of at the time is checking the permissions on /dev/ugen*. The dev nodes should be writable by the uucp user (which is the default system user for NUT on *BSD). -- 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] Liebert GXT3 ID 10af:0000 Not working
On Aug 19, 2013, at 12:58 PM, Korviakov Andrey wrote: I have Liebert GXT3 UPS connected to CentOS Linux with kernel 2.6.32-131.0.15.el6.x86_64 and nut version 2.6.5-2. lsusb: Bus 002 Device 003: ID 10af: Liebert Corp. UPS And this UPS detected only with this section in ups.conf: [liebert] driver = liebert port = /dev/ttyS0 I am confused. Are you using a serial cable with the liebert driver, or a USB cable with the usbhid-ups driver? -- 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] Liebert GXT3 ID 10af:0000 Not working
On Aug 19, 2013, at 9:10 PM, Charles Lepple wrote: On Aug 19, 2013, at 12:58 PM, Korviakov Andrey wrote: I have Liebert GXT3 UPS connected to CentOS Linux with kernel 2.6.32-131.0.15.el6.x86_64 and nut version 2.6.5-2. lsusb: Bus 002 Device 003: ID 10af: Liebert Corp. UPS And this UPS detected only with this section in ups.conf: [liebert] driver = liebert port = /dev/ttyS0 I am confused. Are you using a serial cable with the liebert driver, or a USB cable with the usbhid-ups driver? Actually, for the serial 'liebert' driver, it will only detect OL/OB/LB. We haven't had much luck with the USB firmware on other Liebert units, but if it's anything like some of the other UPSes out there, you may need to power the UPS completely off (unplug from the wall, no LEDs on, etc.) before switching between USB and serial. Also, running the usbhid-ups driver with debugging enabled may shed some light on the problem. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Back-UPS CS and ES series
On Aug 18, 2013, at 12:14 AM, Lyndon Drake wrote: I'm happy to test an updated build, but have no idea about how to go about doing a build in the first place. Could someone help me in the process of creating a snapshot build for FreeNAS? I am not familiar with the specifics of building for FreeNAS, but our BuildBot instance is making source snapshots again: http://buildbot.networkupstools.org/public/nut/waterfall?show=Debian-x64-gcc On the Uploading... step, there is currently a link to nut-2.7.1-pre1.tar.gz - that can be built just like 2.6.5. Somewhere in the FreeNAS source is the command line that you would use to configure NUT to put all of its binaries in the same place that FreeNAS does. Someone asked for that in the second forum link, but there wasn't an answer in that thread. I also didn't see that in a quick search of the NUT archives (we've done this a few times to test out similar in-place upgrades in Linux.) -- 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] Fwd: Liebert PSA UPS problem.
On Aug 11, 2013, at 12:04 PM, Paul Smith wrote: Anyone have any advice what I need to do next? A while back, you sent me the pcap file from the Windows side, but there was an open question as to whether the USB requests were standard Windows HID driver requests, or whether the Liebert software was still running in the background. Also, the SuSE Live CD seems to be the only non-Windows system which can successfully retrieve all of the necessary descriptors for this UPS. How easy would it be for you to build NUT in that environment? Do they provide an easy way to save things off to a non-volatile directory? We have the NUT tarball generation part of our Buildbot setup working, so I suspect you will only need a compiler and libusb devel files. -- 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] N-Power MEV-3000LT compatibility report and problem
On Aug 11, 2013, at 2:12 PM, Александр Безруков wrote: I see no problem with how the device communicates the Blazer/Megatec protocol. I must have found a bug in the driver. It is possible that the shutdown was tested with a different implementation of the protocol. What do you get from the I command? On Aug 11, 2013, at 11:25 AM, Александр Безруков wrote: So I believe the compatibility list deserves two new lines. Probably best to delay adding this to the HCL until we can get the driver to shut down the UPS properly. # /lib64/nut/blazer_ser -amv -k -DDD Network UPS Tools - Megatec/Q1 protocol serial driver 1.55 (2.6.5-Unversioned directory) 0.00debug level is '3' 0.108370Initiating UPS shutdown 0.108561send: 'C' 0.150967read: 'NAK' 0.151021instcmd: command [shutdown.stop] failed 0.151162send: 'C' 0.193506read: 'NAK' 0.193598instcmd: command [shutdown.stop] failed 0.193725send: 'C' 0.236016read: 'NAK' 0.236093instcmd: command [shutdown.stop] failed 0.236127Shutdown failed! This behavior (where any previous pending shutdown is cancelled first) was introduced here: https://github.com/networkupstools/nut/commit/0eef5be7 I wonder if other Megatec-based units don't send a NAK if there is no shutdown pending? Also, maybe we can just attempt the 'C' command up to three times, then send the shutdown command outside that loop. Unfortunately, my Best Power UPS is not available to see how it handles this. Also, I am not at all familiar with the runtime calibration config variables. -- 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] NUT on openSUSE 12.3 requires additional systemd service unit
On Aug 10, 2013, at 5:43 PM, Roger Price wrote: OpenSUSE 12.3 has fully embraced systemd, but to get NUT working correctly now requires some further systemd engineering in addition to the usual NUT configuration files. A new systemd service unit is needed to power off the UPS. The service unit consists of a new file /etc/systemd/system/ups-delayed-shutdown.service [Unit] Description=Initiate delayed UPS shutdown Before=umount.target DefaultDependencies=no [Service] Type=oneshot ExecStart=/usr/lib/ups/driver/upsdrvctl shutdown [Install] WantedBy=poweroff.target This service unit should be enabled with root command systemctl --system reenable /etc/systemd/system/ups-delayed-shutdown.service I have tested this setup with 64 bit openSUSE 12.3 and NUT 2.6.5 using an Eaton Ellipse ASR 1500 USBS. 9 seconds after server poweroff, the UPS powers off. When wall power returns the server restarts correctly. I still haven't messed with systemd yet, so I am in over my head here. Is this similar to what Kjell posted about? Or is it in addition to that? http://www.kepstin.ca/blog/networkupstoolsnutandsystemd/ -- 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] FreeNAS , NUT and APC BK500EI problem.
On Wed, Aug 7, 2013 at 11:12 AM, Huryn Adrian a...@i-pi.pl wrote: Hello to All. OS : FreeBSD NAS 9.1-STABLE FreeBSD 9.1-STABLE [uname -a] Version : Network UPS Tools upsd 2.6.5 [upsd -V] Installation method : build into FreeNAS 9 UPS : APC Back-UPS 500 BK500EI USB Today i install FreeNAS and try to connect to it my UPS APC Back-UPS 500 BK500EI via USB with no luck;/ [...] 1.146989 libusb_get_report: Unknown error 1.147004 Can't retrieve Report 46: Input/output error 1.147031 Can't initialize data from HID UPS This sounds familiar: http://thread.gmane.org/gmane.comp.monitoring.nut.user/7420/focus=7422 A modified version of this patch has been incorporated into the development version of NUT, which will become 2.7.1. -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] infosec e4
On Jul 31, 2013, at 9:07 AM, James HORLEY wrote: I’m wondering if what I have done is good : # get the source from github on my computer # autogen.sh # name=nut # ./configure --prefix=/ --sysconfdir=/etc/$name --mandir=/usr/share/man --libdir=/usr/lib --includedir=/usr/include --datadir=/usr/share/$name --with-statepath=/var/run/nut --with-altpidpath=/var/run/nut --with-drvpath=/lib/nut --with-pidpath=/var/run/$name --with-user=$name –with-group=$name --without-ssl If these are the same parameters as are used to build the .deb, then that should owrk. There was an error : ./configure: line 7079: syntax error near unexpected token `CPPUNIT,' ./configure: line 7079: `PKG_CHECK_MODULES(CPPUNIT, cppunit, have_cppunit=yes, have_cppunit=no)' Do you have pkg-config installed? I put in commentary the line PKG_CHECK_MODULES(CPPUNIT, cppunit, have_cppunit=yes, have_cppunit=no) then # make # make install I took the driver voltronic_ser then from my workstation put it in the server, change the ups.conf and try it. The command “upscmd –u admin myups shutdown.return” now work (shutting down server then ups). Unfortunately, when I do “shutdown –h +0”, the ups is never shut down. After a little research, it appears that the line “upsmon –K /dev/null 21” in ups-monitor always return 1 so the line “exec /etc/init.d/nut-server poweroff” is never execute. For initial shutdown testing, I would recommend using a dummy load (such as a lamp) and plug the server into another UPS or directly to line power. Then, you can remove power from the UPS and run upsmon -K from the command line (without redirection) to see why it is failing. I’m ussing upssched in upsmon.conf, do I need to create the flag with my script before calling the shutdown –h +0? How (it’s supposed to be set automaticaly)? or maybe I’m missing something. I don't recommend configuring upssched until basic shutdowns work. Did I do the right thing by getting only the driver from my computer and put it on the server? Or should I do a package of the whole nut (binary, conf etc...) This is not guaranteed to work, but when the version numbers are close enough (2.6.4, 2.6.5, 2.7.1/master), it usually does work. The network protocol is more stable than the upsd/driver interface. -- 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] infosec e4
On Aug 1, 2013, at 8:15 AM, Charles Lepple wrote: On Jul 29, 2013, at 7:12 AM, James HORLEY wrote: There’s a software advised by the constructor that work on linux (http://www.power-software-download.com/viewpower.html), unfortunately it’s heavy (tomcat and java) and I don’t find it as flexible as NUT. We have a development branch called voltronic-driver which might work better than the blazer* for UPS models which are meant to work with ViewPower. Have you rebuilt a .deb package before? Oops, just noticed the new thread where /dan replied: http://thread.gmane.org/gmane.comp.monitoring.nut.user/8023 -- 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] infosec e4
On Aug 1, 2013, at 8:21 PM, James HORLEY wrote: I compile nut with the voltronic-driver on my computer then I've copy the driver /lib/nut/voltronic_ser on the server. I can now shutdown the ups using upscmd -u admin myups shutdown.return. Good to know. My first question is, is it really ok to only take the driver whithout taking the whole package? It's not a long-term solution. In your case, since it's a new driver, it won't get overwritten. However, as mentioned in another email, the structures that are used to communicate between upsd and the drivers haven't changed much recently, and happen to be the same for the two versions you are using. If you really wanted to, you could recompile the entire .deb package. I'm using upssched to shutdown server after 15mn on battery, the shutdown -h +0 isn't enough to shutdown ups. It used to work in stock Debian. I haven't tried it myself recently - I think the only system that was up during our last power outage here was a FreeBSD system. Do I need to use upscmd in order to shutdown ups, or is there another way? The system shutdown scripts should call upsdrvctl shutdown for you. If not, I would file a bug against the distribution package. -- 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] NUT on Linux, pid related errors
On Aug 1, 2013, at 1:34 AM, Kris Jordan wrote: The kill error is coming from this line: https://github.com/networkupstools/nut/blob/master/common/common.c#L263 Which is called from: https://github.com/networkupstools/nut/blob/master/client/upsmon.c#L1930 In which case would you need to see if this is going to work first? Agreed, the first kill(pid, 0) is redundant in that case. https://github.com/networkupstools/nut/blob/master/clients/upsmon.c#L1930 -- 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] NUT on Linux, pid related errors
On Jul 30, 2013, at 1:36 PM, Kris Jordan wrote: upsd removes its pid files when it's stopped, upsmon does not. Hmm, interesting observation. Offhand, I think both should remove the PID files, but the way that upsmon drops root privileges might make this difficult. If I remove upsmon's manually after stopping it, I get a different message for it when I start it back up... fopen /var/run/nut/upsmon.pid: No such file or directory I can see the fopen errors happening because of the pre-existing process check. But for the first upsmon case, what is it trying to kill? When you say the first upsmon case, do you mean this line? https://github.com/networkupstools/nut/blob/master/clients/upsmon.c#L1923 If this is normal operation, maybe they shouldn't be printed to the console? Agreed. It would probably involve adding another parameter to the sendsignal() calls, indicating whether the kill() function call is expected to fail or not. Patches welcome :-) -- 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] nut package with Riello UPS support
On Jul 30, 2013, at 3:28 AM, Pavel Potcheptsov (EKTOS) wrote: another attempt: # upsd Network UPS Tools upsd 2.6.5 fopen /var/db/nut/upsd.pid: No such file or directory listening on 127.0.0.1 port 3493 listening on ::1 port 3493 Can't connect to UPS [senpro] (riello_ser-senpro): No such file or directory We need to determine whether upsd and the driver are using the same path for the socket. Is the driver still running when you get the no such file or directory message? The socket should be in /var/state/ups. -- 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] nut package with Riello UPS support
On Jul 29, 2013, at 7:56 AM, Charles Lepple wrote: On Jul 29, 2013, at 6:43 AM, Pavel Potcheptsov (EKTOS) wrote: Hello list, I have explored https://github.com/networkupstools/nut repository and found that Riello UPS added into list of supported UPS. But current package for most distribution it's nut-2.6.5 which doesn't have Riello's models. Do we need to wait next upcoming nut release to get start with Riello? We're not too far away from a release: https://github.com/networkupstools/nut/issues/37 I tried to install from source but stuck: [...] Using existing nut.conf.5 manual page, since 'asciidoc' was not found. We don't check the generated man pages into the Git repository, so the easiest way to get around this is probably to just install asciidoc. At some point I will fix the Buildbot step which generates snapshot tarballs with the generated man pages included. http://buildbot.networkupstools.org/public/nut/waterfall?show=Debian-x64-gcc http://buildbot.networkupstools.org/~buildbot/cayman/snapshot/ra074844f88ca352780dd881b5fa3c435832d165e-36/nut-2.7.1-pre1.tar.gz -- 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] nut package with Riello UPS support
On Jul 30, 2013, at 10:39 AM, Pavel Potcheptsov (EKTOS) wrote:
Is this a trouble? Driver use path /var/state/ups/ but upsd use path
/var/db/nut/upsd.pid
Yes, the driver and upsd need to agree on the path to the socket.
From the FreeBSD ports tree:
/usr/ports/sysutils/nut/Makefile:
STATEDIR?= /var/db/nut
[...]
CONFIGURE_ARGS= --sysconfdir=${PREFIX}/etc/nut \
--program-transform-name= \
--localstatedir=${STATEDIR} \
--datadir=${PREFIX}/etc/nut \
--with-drvpath=${PREFIX}/libexec/nut \
--with-statepath=${STATEDIR} \
--with-altpidpath=${STATEDIR} \
--with-pidpath=${STATEDIR} \
--with-pkgconfig-dir=${PREFIX}/libdata/pkgconfig \
--with-user=${NUT_USER} \
--with-group=${NUT_GROUP} \
--with-dev
I think you need to re-run ./configure in the source tree with the driver,
using the arguments above. Then 'cd drivers; make clean; make riello_ser' and
install the new copy of the driver.
--
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] nut package with Riello UPS support
On Jul 29, 2013, at 6:43 AM, Pavel Potcheptsov (EKTOS) wrote: Hello list, I have explored https://github.com/networkupstools/nut repository and found that Riello UPS added into list of supported UPS. But current package for most distribution it's nut-2.6.5 which doesn't have Riello's models. Do we need to wait next upcoming nut release to get start with Riello? We're not too far away from a release: https://github.com/networkupstools/nut/issues/37 I tried to install from source but stuck: [...] Using existing nut.conf.5 manual page, since 'asciidoc' was not found. We don't check the generated man pages into the Git repository, so the easiest way to get around this is probably to just install asciidoc. At some point I will fix the Buildbot step which generates snapshot tarballs with the generated man pages included. -- 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] nut package with Riello UPS support
On Jul 29, 2013, at 8:16 AM, Pavel Potcheptsov (EKTOS) wrote: I also could built the driver that I need # make riello_ser That should work, from the driver directory. It shouldn't depend on the man pages. The master branch in Git and 2.6.5 are close enough that you should be able to just copy the riello_ser driver into the directory where the 2.6.5 drivers were installed. but I don't know is there way to include it in 2.6.5. That is left as an exercise for the reader... you could collect all of the patches for Riello support, and apply them to the 2.6.5 tree. As for asciidoc, you might need some additional dependencies. I think it's actually the a2x script in the asciidoc package: http://www.methods.co.nz/asciidoc/a2x.1.html#X1 -- 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] HP R12000/3 UPS reports status as OL DISCHRG OB
Nice, that MIB fills in a few details.
.1.3.6.1.4.1.232.165 is cpqPower.
.1.3.6.1.4.1.232.165.3 is cpqPower.ups.
On Jul 16, 2013, at 10:25 PM, Charles Lepple wrote:
Here's the first update of ups.status:
0.102449getting data: ups.status (.1.3.6.1.4.1.232.165.3.4.5.0)
0.102546su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.4.5.0
0.102646nut_snmp_get(.1.3.6.1.4.1.232.165.3.4.5.0)
0.104539SNMP UPS driver : entering su_status_set()
0.104641su_find_infoval: found OL (value: 3)
0.104730= value: 3
0.104823getting data: ups.status (.1.3.6.1.4.1.232.165.3.2.5.0)
0.104919su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.2.5.0
0.105028nut_snmp_get(.1.3.6.1.4.1.232.165.3.2.5.0)
0.107134SNMP UPS driver : entering su_status_set()
0.107231su_find_infoval: found DISCHRG (value: 2)
0.107319= value: 2
0.107412getting data: ups.status (.1.3.6.1.4.1.232.165.3.7.3.0)
0.107507su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.7.3.0
0.107616nut_snmp_get(.1.3.6.1.4.1.232.165.3.7.3.0)
0.109529SNMP UPS driver : entering su_status_set()
0.109630su_find_infoval: found OB (value: 1)
0.109720= value: 1
The first one (...3.4.5.0) is labeled in the driver as
CPQPOWER_OID_POWER_STATUS. I checked around for this, and didn't find a good
definition, but that seems to match the OL state.
Confirmed by the MIB:
upsOutputSource OBJECT-TYPE
SYNTAX INTEGER {
other(1),
none(2),
normal(3), -- normal, single UPS module output
bypass(4),
battery(5),
booster(6), -- Single or Double Boost,
line-interactive UPSs only
reducer(7), -- Buck, line-interactive UPSs only
parallelCapacity(8),-- normal enhanced by Parallel for
Capacity operation
parallelRedundant(9), -- normal enhanced by Redundant
Parallel operation
highEfficiencyMode(10) -- normal enhanced by High Efficiency
mode
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
The present source of output power. The enumeration
none(2) indicates that there is no source of output
power (and therefore no output power), for example,
the system has opened the output breaker.
::= { upsOutput 5 }
The second one seems specific to the battery:
static info_lkp_t cpqpower_battery_abm_status[] = {
{ 1, CHRG },
{ 2, DISCHRG },
/* { 3, Floating }, */
/* { 4, Resting }, */
/* { 5, Unknown }, */
{ 0, NULL }
} ;
I could see the battery monitoring circuit discharging the battery
occasionally for maintenance, but is there a separate front-panel indicator
for this mode?
The MIB suggests that the discharge state is part of normal battery
management:
upsBatteryAbmStatus OBJECT-TYPE
SYNTAX INTEGER {
batteryCharging(1),
batteryDischarging(2),
batteryFloating(3),
batteryResting(4),
unknown(5)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
Gives the status of the Advanced Battery Management;
batteryFloating(3) status means that the charger is temporarily
charging the battery to its float voltage; batteryResting(4) is the
state when the battery is fully charged and none of the other actions
(charging/discharging/floating) is being done.
::= { upsBattery 5 }
The third one is CPQPOWER_OID_ALARM_OB. This definitely doesn't make sense,
since things with alarm in the name are usually pretty direct.
I looked up the third OID, and it does not seem to map to that alarm status.
Instead, it is upsTestTrap and while the MIB calls it read-write, the only
defined action is for writing a startTestTrap to start a test.
Arnaud: the CPQPOWER_OID_ALARM_OB entry looks like it was a guess [*]. Do you
know of any units which require this? Otherwise, I think we should take it out.
[*]
https://github.com/networkupstools/nut/commit/c1b83e7d40083263719de13e631a72dfc96961a9
--
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] What current UPS can I buy?
On Jul 17, 2013, at 11:27 AM, Matt Ivie wrote: I'm really just looking for a UPS that might run a couple of small servers and other small devices(routers or switches). Good call on including the network gear in the power budget. NUT isn't much use to the slave systems if the network connection between master and slave goes down. If I could get 15-30 minutes of runtime from the batts and o course run the automated shutdown and reboot sequence through nut that would be great. The server I'm looking at has a PSU capable of 200W but I don't expect to be maxing out the system capabilities at all. I'll be running either Debian Wheezy(most likely) or Trisquel 6.0 and I'd like to just use the pre-packaged version of NUT rather than building a new package if I can. It doesn't look like I can just copy-and-paste the link to the exact result, but if you go to the UPS selector on the Eaton Power Quality page, they will recommend a few models: http://powerquality.eaton.com/ The NUT HCL spells out Powerware 9130/9140, but the Eaton pages refer to PW9130 and PW9140. Pretty sure they are the same unit with a different name. Debian wheezy has NUT 2.6.4, which should cover most of the units that Eaton's selector would recommend. You could also go with a Tripplite rack-mount UPS, but a lot of the low-end ones use a proprietary protocol that seems to change between model years. -- 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] HP R12000/3 UPS reports status as OL DISCHRG OB
Here's the first update of ups.status:
0.102449 getting data: ups.status (.1.3.6.1.4.1.232.165.3.4.5.0)
0.102546 su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.4.5.0
0.102646 nut_snmp_get(.1.3.6.1.4.1.232.165.3.4.5.0)
0.104539 SNMP UPS driver : entering su_status_set()
0.104641 su_find_infoval: found OL (value: 3)
0.104730 = value: 3
0.104823 getting data: ups.status (.1.3.6.1.4.1.232.165.3.2.5.0)
0.104919 su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.2.5.0
0.105028 nut_snmp_get(.1.3.6.1.4.1.232.165.3.2.5.0)
0.107134 SNMP UPS driver : entering su_status_set()
0.107231 su_find_infoval: found DISCHRG (value: 2)
0.107319 = value: 2
0.107412 getting data: ups.status (.1.3.6.1.4.1.232.165.3.7.3.0)
0.107507 su_ups_get: ups.status .1.3.6.1.4.1.232.165.3.7.3.0
0.107616 nut_snmp_get(.1.3.6.1.4.1.232.165.3.7.3.0)
0.109529 SNMP UPS driver : entering su_status_set()
0.109630 su_find_infoval: found OB (value: 1)
0.109720 = value: 1
The first one (...3.4.5.0) is labeled in the driver as
CPQPOWER_OID_POWER_STATUS. I checked around for this, and didn't find a good
definition, but that seems to match the OL state.
The second one seems specific to the battery:
static info_lkp_t cpqpower_battery_abm_status[] = {
{ 1, CHRG },
{ 2, DISCHRG },
/* { 3, Floating }, */
/* { 4, Resting }, */
/* { 5, Unknown }, */
{ 0, NULL }
} ;
I could see the battery monitoring circuit discharging the battery occasionally
for maintenance, but is there a separate front-panel indicator for this mode?
The third one is CPQPOWER_OID_ALARM_OB. This definitely doesn't make sense,
since things with alarm in the name are usually pretty direct.
The big question in my mind is, where did the NUT definitions come from?
Did your UPS come with a CD that might contain a SNMP MIB definition file? Or
is there an area on the HP support site? (All I saw was a firmware update .EXE)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] What current UPS can I buy?
On Jul 16, 2013, at 11:30 AM, Matt Ivie wrote: I'm sure this has been asked before and I did search the list archives but anything I did find looked to be older. I'm looking at buying some UPS and I'm not sure how to tell which currently sold models are supported by NUT. I know that not every new model will be supported but there has to be some right? Generally, we find this out when someone posts to the list asking for help with a new UPS. Is there a specific designation I can look for in the technical specs that should help me determine this? Here are some general thoughts on why this is a difficult question to answer: http://article.gmane.org/gmane.comp.monitoring.nut.user/7987 Are there some manufacturers that are friendly to the project and make devices that work well with NUT? This is a little easier to answer. For the Eaton and Powerware brands, we can often ask the company to help out with technical information. Several other companies have provided tech support or protocol information. Some of this is visible if you choose either or * from the Support Level dropdown on this page: http://www.networkupstools.org/stable-hcl.html (Sorry, the 4-star rating is strictly 4-star, and does not include 5-star by default. JavaScript help is welcome here.) On the other hand, I personally can't recommend new APC equipment now that they have started using a proprietary protocol that several customers have been unable to obtain documentation for. I have an old APC USB HID UPS, and it works well, but their new equipment is apparently more limited in what it can monitor. Any help on this would be great because the worst thing would be to buy a nice new UPS for a server and then find out that it is not supported by NUT. Short answer: buy from a distributor that allows open-box returns. The NUT project can't be liable for recommendations based on old information. If you can provide a little more information about the kind of UPS that you are looking for, I'm sure we could narrow things down a little. Are you protecting desktops or small servers? A whole machine room? -- 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] How to find out the output of upsc for each UPS model supported by NUT ?
On Jul 7, 2013, at 6:09 AM, Alf Høgemark wrote: Do other NUT users miss knowing exactly how the upsc output will look for a UPS model ? Does anyone have opinions on where we could record such information ? Should it be one page per model, or one page per driver with a section for each model ? It would be nice to collect this information somehow. At the moment, we only really have upsc information for the UPS models which have been problematic, plus a few more emails where users have sent HCL updates. The exact organization of the content probably doesn't matter, so long as the output is cross-referenced with a driver. (In the Thinkwiki example, their use of categories seemed backwards to me at first. However, it is useful to know whether a given laptop supports a particular feature, and the category listing at the bottom provides that nicely.) I would be curious to hear what others think about a wiki or similar user-editable resource. The NUT HCL was never meant to fill that role, but a completely free-form wiki might not be as useful as a custom web site. In either case, we would need to have some decent spam protection. The NUT Trac instance was hit fairly hard a while ago. Mike brings up an important point, in that NUT can only relay the information that the UPS provides. If that information is incorrect, this sort of repository could flag those variables or instant commands as being improperly implemented by the UPS. Perhaps we could do something like those online UPS sizing wizards: ask the user which features matter most, and show a filtered list of suggested UPS models. The biggest issue in my mind is that UPS vendors frequently change things out under the hood without changing the model name. Sometimes it is for the better - Powercom shifted to a standard USB HID PDC interface (which was easier to support in NUT). However, APC apparently dropped support for a lot of variables from their HID PDC interface in favor of their proprietary Microlink protocol (see apcupsd.com for more information). Maybe we can steer people away from bad UPS models or vendors, but in the end, if I were purchasing a new UPS, I would want a no-questions-asked, open box refund policy from the distributor. Alf: I like this idea, but I don't have the free time to help with this for a while. (We still need to get the first Git-based source release out the door.) Feel free to take this idea and run with it. -- 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] Server 2012 - 64bit UPSD Crash
On Jun 28, 2013, at 7:40 AM, Ge-org Brohammer wrote: 0.046800 Connected to UPS [sspro]: blazer_usb-sspro 0.046800 Can't open c:\Program Files (x86)\NUT\sbin\..\etc/upsd.users: No such file or directory [...] ←--- Connecting with upsc at this moment 46.238943 Out of memory: No such file or directory [The system detected an invalid pointer address in attempting to use a pointer argument in a call. ] These things shouldn't be connected, but what happens if you create an empty upsd.users file in the etc directory? I'm grasping at straws here. Unfortunately, our Windows branch maintainer has been MIA for a bit. Maybe someone else with a similar system can offer some more debugging suggestions. -- 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] upsrw doesn't set variable
On Jun 29, 2013, at 9:45 AM, Mike. wrote: On 6/29/2013 at 9:14 AM Mike. wrote: |NUT 2.6.5 on FreeBSD 9.1 | | |Why isn't the variable outlet.1.delay.shutdown set with the following |command? | | | |# upsc PW5125@localhost | grep outlet.1.delay.shutdown |outlet.1.delay.shutdown: -1 | |# upsrw -u au -p ap -s outlet.1.delay.shutdown PW5125@localhost |Enter new value for outlet.1.delay.shutdown: 10 |OK | |# upsc PW5125@localhost | grep outlet.1.delay.shutdown |outlet.1.delay.shutdown: -1 | | | | |Am I missing something obvious? = Forgot to add ups.conf: [PW5125] driver = bcmxcp port = /dev/cuau0 baud_rate = 9600 desc = PW 5125 - 1500 I was just going to gripe about the lack of driver information :-) Sounds similar to Pascal's question: http://lists.alioth.debian.org/pipermail/nut-upsuser/2013-June/008462.html Do you see anything from syslog at LOG_NOTICE? In theory, the bcmxcp driver should log a message if the parameter change is refused by the UPS. If not, you could try re-running the driver with a few -D flags. That will show some information on the commands and responses. We also have a bcmxcp branch that has a few fixes beyond v2.6.5, but none of them seem particularly relevant. Arnaud mentioned that some of the PowerWare devices have a USB HID interface that may be more fully mapped out. If you have a USB port on the UPS, you could try changing the parameter with usbhid-ups, then switching back to bcmxcp for long-term monitoring. -- 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] Help to configure NUT on Win 8
Follow-up from Massimo: Additional info: I followed this and NUT should be configured: http://forum.qnap.com/viewtopic.php?f=151t=47493#p213186 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] help creating custom genericups configuration - RNG only!
On Jun 21, 2013, at 9:39 AM, Reed Hedges wrote: OK, I'll try none and see what happens. Also, depending on what other tools are accessing the serial port, you may need to add the nolock option to ups.conf. -- 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] Help to configure NUT on Win 8
On Jun 21, 2013, at 4:23 PM, Massimo Savazzi wrote: Sorry to bother, but I tried to solve the issue without success. Here is my configuration UPS – NAS I have configured the UPS to send the power messages to my clients: image001.png Can you describe this a little more? What kind of NAS? What version of NUT is it running? The part that seems odd is that the screenshot says Allows the following IP addresses to be notified in the event of power failure. NUT clients connect to the NUT server, so the server shouldn't need to know the IP addresses of the clients in advance (unless this refers to some sort of firewall). I cannot understand how to configure NUT to be the client, receive the messages and suspend/shutdown the PC if needed. The PC runs Win8 64bit You will probably want to read this: http://www.networkupstools.org/docs/user-manual.chunked/ar01s02.html#_monitoring_client http://www.networkupstools.org/docs/user-manual.chunked/ar01s06.html#UPS_shutdown Please subscribe to continue this discussion: Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser -- 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] help creating custom genericups configuration - RNG only!
On Jun 20, 2013, at 9:48 PM, Reed Hedges wrote: UPSPORT=/dev/ttyS0 # type cablep kill t powerok battok cableok robot --- RI0 /RI --- --- … Is there an equivalent of “---“ in genericups? I think it's pretty much any value other than a valid signal name. The man page mentions none and ??? in various places. What about something like this? [robot] driver = genericups port = /dev/ttyS0 upstype = 9 CP = none SD = none OL = -RNG LB = RNG (The upstype setting is arbitrary in this case, as all of the settings get overridden.) -- 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] Cannot connect to a Eaton Ellipse Pulsar ASR/6000VA usbs [solved] but new problem surfaces.
On Jun 20, 2013, at 10:35 AM, Louis Chaillet wrote: With respect clarification of the documentation (and reference to your question Charles). The documentation does suggest that you can shutdown the ups by the upsdrvclt shutdown [ups] command. Specifically in http://www.networkupstools.org/docs/man/upsdrvctl.html; in the section commands under warning. In the Network UPS Tools User Manual (pdf) under section 6.3.2 in the last paragraph it is suggested to first test the /usr/local/ups/bin/upsdrvctl -t shutdown and then upsmon -c fsd. Also this section suggests that under some circumstances you cannot rely on the shutdown sequence to issue this command. Thanks, noted. However the real reason I tried upsdrctl -c shutdown (not the test) is that I already tested the setup with the upsmon -c fsd. The results is that the server closes down, as expected, but ups does not shutdown, and so there is no restart of the server. I was guessing it has to do with the particular shutdown command of the server I have, which was SHUTDOWNCMD /usr/lib/web-admin/backend.pl power_off. And I was trying to fix that by calling the upsdrvctl shutdown command directly from a script. As I do not use the packaged (debian) shutdown script (/sbin/shutdown) do I need to tell the ups to power down myself, as suggested in the documentation (configuration notes, see reference above)? I haven't traced through the Debian shutdown sequence recently, but I think that they call upsdrvctl shutdown after the rest of the system processes have shut down (including the NUT driver). That should avoid the device or resource busy error - only one process can open the UPS USB device node at a time. -- Charles Lepple A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] several problems with Powercom BNT-500AP
[I am CC'ing Alexey from Powercom in case he has seen any of these issues with the Raspberry Pi hardware.] On Jun 10, 2013, at 1:05 PM, Mārtiņš Puķītis wrote: I took the log. Here's what happened. Broadcast Message from nut@rasp (somewhere) at 16:18 ... UPS BNT500AP@localhost battery needs to be replaced occurred when for the first time value 1 was read as UPS.PowerSummary.PresentStatus.NeedReplacement, on this line: 6409.240690 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Input, ReportID: 0x0a, Offset: 6, Size: 1, Value: 1 It happened for 9 times, but the message appeared only on first. Correct, upsmon throttles the REPLBATT event: http://www.networkupstools.org/docs/man/upsmon.conf.html (search for RBWARNTIME) Broadcast Message from nut@rasp (somewhere) at 17:33 ... UPS BNT500AP@localhost on battery occurred when UPS.PowerSummary.PresentStatus.ACPresent turned to 0 on this line: 10921.069403 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x0a, Offset: 2, Size: 1, Value: 0 If you turn up the debugging level from 2 to 3, the driver will do a hex dump of the report buffer. Offset and size are bits, so if the ACPresent bit is 0, that's what the driver reports. Here I also see a suspisious frequency value 70. How is this possible? 43194.046966 Path: UPS.Input.Frequency, Type: Feature, ReportID: 0x1e, Offset: 0, Size: 8, Value: 70 Similar situation to ACPresent - if those are the bits coming in, that's what the driver reports. Granted, there are cases where usbhid-ups might be misinterpreting those bits, but as you can imagine, it is hard to test all of the corner cases. We should be getting an error message from usbhid-ups if the USB reply is not long enough. At 2:58: 44790.984549 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, ReportID: 0x0a, Offset: 2, Size: 1, Value: 0 Here all voltages and frequencies are OK, so I don't understand why ACPresent is 0. usbhid-ups does not look at voltage and frequency to determine whether AC is present. Voltage and frequency values can be averages over time (with the averaging being performed in the UPS microprocessor), so the driver simply trusts the ACPresent bit returned by the UPS. I'm starting to wonder if the USB controller or driver in the Raspberry Pi is flaky. We have seen odd issues with other ARM/Linux boards, and none of the symptoms are the same as on x86 PCs. Do you have a desktop or laptop Linux system where you can test this? -- 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] cannot update battery.date value of APC ups battery
On Jun 7, 2013, at 4:43 AM, Vieri wrote: # upsrw -s battery.date=2013Jun7 -u ups-mon-IT IT-APC-BOTTOMRIGHT@127.0.0.1 Have you tried using the DD/MM/YY format? On APC UPS models with USB ports, the date is stored as a packed integer, so if the firmware does support changing the date, it might expect it to be in the same format. On the other hand, there has been discussion in the past that it is not possible to change this through the NUT interfaces, e.g.: http://thread.gmane.org/gmane.comp.monitoring.nut.user/7786 -- 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] (in)compatible UPS via network
On Jun 3, 2013, at 9:35 AM, Matus UHLAR - fantomas wrote: when I have UPS connected to NUT server, does it matter if the NUT client (running a different version) supports that UPS? In other words, does the NUT protocol require the UPS being supported by the client in addition to the server? As far as drivers are concerned, no. The client simply asks the server for either a specific variable, or a list of all variables. There were some new features introduced in 2.6.4, and I can't imagine that anyone is still running a version older than 2.0. Those changes are documented here: http://www.networkupstools.org/docs/developer-guide.chunked/ar01s09.html#_revision_history -- 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] nut client config?
On Jun 3, 2013, at 12:21 PM, Matus UHLAR - fantomas wrote: It would be easier to configure UPSes for upsc, upsmon and nut-monitor with client config file. Maybe ups.conf ? If you are looking for a simpler way to set up NUT in general, there is the nut-scanner tool. I don't use it, but others on the list might be able to help. The separation between clients and server is to allow processes like upsmon and the drivers to run as different users. There are also passwords in some of the configuration files. Aside from that, what do you suggest that we combine? -- 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] APC AP9617 SNMP returns strange errors
On May 15, 2013, at 4:16 AM, lutz.niede...@gmx.net wrote: root@abex:/etc/nut# upsdrvctl - shutdown apc10001 Network UPS Tools - UPS driver controller 2.6.4 0.00 If you're not a NUT core developer, chances are that you're told to enable debugging [...] 0.000280 Shutdown UPS: apc10001 0.000304 exec: /lib/nut/snmp-ups -a apc10001 -k The message that you trimmed was intended to explain that if you want more debug messages, you need to call the driver directly with the -D flags, e.g. /lib/nut/snmp-ups - -a apc10001 -k. Unfortunately, I am not familiar with the inner workings of the SNMP driver. -- 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] APC AP9617 SNMP returns strange errors
On May 15, 2013, at 8:18 AM, lutz.niede...@gmx.net wrote: So maybe a problem with 90 vs 90 ? Probably. I don't have an SNMP-capable UPS here, so if you could send the logs from passing the debug flags the driver directly (/lib/nut/snmp-ups - -a apc10001 -k), it would be easier for me to follow along in the code. I recommend saving the log to a file (via 'script' or 'tee') and compressing it to keep the list post to a reasonable size. I suspect that the type is coming from the SNMP MIB definition. Could you also send the ups.conf file contents? -- 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] APC AP9617 SNMP returns strange errors
On May 15, 2013, at 8:50 AM, lutz.niede...@gmx.net wrote: I tried to set Minimum battery level for restart after power off (percent) to 90. And this gave 90 as mentioned below. I saw in apc-mib.c that the type for this is declared as ST_FLAG_STRING. This is abolutely no string (so no 's' but 'i' would be correct). I agree with that assessment, but what about the error for the following call? 0.055771 entering nut_snmp_set (.1.3.6.1.4.1.318.1.1.1.6.1.1.0, i, 2) 0.098838 [apc10001] nut_snmp_set: can't set .1.3.6.1.4.1.318.1.1.1.6.1.1.0: Error in packet: (genError) A general failure occured That seems to be specifying an integer, which agrees with this: http://www.mibdepot.com/cgi-bin/getmib3.cgi?win=mib_ai=1n=PowerNet-MIBr=dellf=powernet.mibv=v1t=scao=upsBasicControlConserveBattery Does this call to nut_snmp_set() not result in a proper packet as seen in tcpdump? Since you're using Debian, and this bug would be present in the latest package version as well, I would recommend filing a bug there (and post a link to the bug here). That will make sure it doesn't fall through the cracks. We can continue to debug here as well. It is also possible to compile NUT from source with the same options that Debian uses, and just swap in the snmp-ups driver for testing. -- 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] APC AP9617 SNMP returns strange errors
On May 15, 2013, at 10:15 AM, lutz.niede...@gmx.net wrote: I will post the changed apc-mib.c here. Ok? Or shall I send it to someone else? This list is fine. Would you please post a unified diff (diff -u) instead of the whole file? Thanks, -- 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] Error Result
On May 15, 2013, at 6:50 PM, Jason D'Rion wrote: From the following webpage - http://packages.debian.org/wheezy/all/nut/download After installing it I now get: I am running 10.04 LTS server While Debian and Ubuntu use the same package format, there is no guarantee that they split the files up the same way between sub-packages. If you continue with Debian packages, you probably need to grab both nut-client and nut-server: http://packages.debian.org/wheezy/nut -- 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
[Nut-upsuser] Looking for volunteers to test nut-scanner against APC USB UPSes
From https://github.com/networkupstools/nut/issues/26 : Unfortunately I have only this UPS for testing purposes right now. It might makes sense to ask people on the nut mailinglist if they can send the result nut-scanner -qU if they have the same APC UPS. If you have a USB-based APC UPS, could you please send the list the output from nut-scanner -qU? You can remove the serial numbers if you like, but if you do, just mention if you saw any extra spaces after the letters and numbers. Also, please include: * version of NUT (2.6.x / SVN / Git) * OS * Version of libusb (libusb-0.1.12 or libusb-1.0 + libusb-0.1-compat) We have a workaround committed in Git, but I would like to get to the root of the problem. -- 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] Best Ferrups (bestfcom patch)
On May 11, 2013, at 12:04 PM, Bo Kersey wrote: I propose the following patch to fix the battery.charge (% battery full) reading. Committed. Thank you for an easy-to-apply patch with a helpful explanation. Thanks for your consideration. I know this is an old UPS (1995) but it still works and I'd like to keep using it :) Agreed, we don't want to make a working UPS obsolete. Honestly, part of the reason why this project takes a more conservative approach to change is that we know there are a lot of older yet reliable serial UPSes out there that don't require as much care and feeding on the software side as the USB UPSes do. If we ever inadvertently break support for one of the serial models, please let us know. -- 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] Error Result
On May 14, 2013, at 8:57 PM, Jason D'Rion wrote: Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 This TrippLite device (09ae:2010) is not (or perhaps not yet) supported by usbhid-ups. Please make sure you have an up-to-date version of NUT. If this does not fix the problem, try running the driver with the '-x productid=2010' option. This was fixed in the version just after 2.4.3 (2.6.0). -- 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] Powercom BNT-1500AP serial config
On May 1, 2013, at 5:45 PM, Bill Carlson wrote: Finally got around to hooking up my Powercom BNT-1500AP to nut. It's the old serial interface. Connects okay and gets most information, but a couple of data are way off. Any config recommendations or upgrade recommended? I've played with config a little, but no hits yet. It looks like the BNT-other defaults were updated after 2.4.3, specifically to address the BNT-1500AP. I think you can just add the following BNT-other values to ups.conf: http://www.networkupstools.org/docs/man/powercom.html#_bnt_other You might also need an explicit type = BNT-other (which I think is no longer needed in the latest version). If not, we can try recompiling the powercom driver. References: https://github.com/networkupstools/nut/commits/master/drivers/powercom.c https://github.com/networkupstools/nut/commit/ecaee22189ca4add854c7fc0d5aca1e4ee4bfe2d#drivers/powercom.c -- 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] ippon back power pro 700 on FreeBSD 9.1-R
On Apr 28, 2013, at 1:10 PM, Alexander Lunev wrote: I can't move to blazer_ser - computer have no COM port. What can be done in this situation? If you need to get this up and running quickly, I would recommend getting a USB-to-serial port that is well supported by FreeBSD. The values you are getting with blazer_usb don't follow the same pattern as some of the other USB issues seen on older versions of FreeBSD, so debugging that could take a while. -- 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] Not receiving real data from a Eaton E series DX 1000H UPS
[original message was too long; forwarding.] From: Pladi Computers Ltd. pl...@lovechnet.com Subject: Not receiving real data from a Eaton E series DX 1000H UPS Date: April 23, 2013 8:46:06 AM EDT To: Arnaud Quette aquette@gmail.com, nut-upsuser@lists.alioth.debian.org It works with blazer_ser. Thank you for your help. On 23.4.2013 г. 13:27 ч., Arnaud Quette wrote: Please try blazer and tell us back how it goes. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] can't find UPS on openwrt/arm
On Apr 14, 2013, at 2:02 PM, Matus UHLAR - fantomas wrote: On 13.04.13 14:58, Matus UHLAR - fantomas wrote: as seen on my home PC: http://test.fantomas.sk/pc_lsusb-vvv-d_0463: I will try to get output on my home NAS (ARM architecture) here it is: http://test.fantomas.sk/nas_lsusb-vvv-d_0463 While it seems that the USB data are broken, both QNAP NAS firmware and debian squeeze can handle it. But that is still an issue of libusb,not NUT, correct? I can upgrade openwrt on my router ... It does seem that it is a libusb-1.0 issue, yes. They may not be aware of it, though (since it probably only comes up when dealing with broken USB descriptors like on your UPS). Before bothering to upgrade, check to see if they have a newer libusb-1.0, and then we can see if they might have fixed this. Are there any test tools that come with libusb-1.0? The libusb-0.1 source tree had a tool that was like a miniature lsusb: it would print some descriptor information, but not much else. I don't know if many distributions packaged that. If there is such a tool for 1.0, that would make a great test case to confirm that the problem is in libusb-1.0. -- 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] can't find UPS on openwrt/arm
On Apr 14, 2013, at 2:02 PM, Matus UHLAR - fantomas wrote: here it is: http://test.fantomas.sk/nas_lsusb-vvv-d_0463 BTW, looks like that URL got truncated: http://test.fantomas.sk/nas_lsusb-vvv-d_0463: -- 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] can't find UPS on openwrt/arm
On Apr 6, 2013, at 10:08 AM, Matus UHLAR - fantomas wrote: On Apr 5, 2013, at 3:04 AM, Matus UHLAR - fantomas wrote: libusb: 0.00 error [get_config_descriptor] short output read 0/8 On 05.04.13 20:39, Charles Lepple wrote: Reading the config descriptor is a pretty basic operation. What does lsusb -vvv -d 0463: return? too much of output to send here: http://test.fantomas.sk/tplink2543nd_lsusb-vvv-d_0463: Hmm, perhaps Arnaud can ask someone what the other five configurations are: idVendor 0x0463 MGE UPS Systems idProduct 0x UPS bcdDevice1.00 iManufacturer 1 EATON iProduct2 Protection Station iSerial 4 AN2E49008 bNumConfigurations 6 Is there any way you can build against the real libusb-0.1, versus the compatibility layer from 1.0? They may have different error checking strategies when reading descriptors. -- 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] CP1000PFCLCD really high output voltage
On Apr 5, 2013, at 12:03 PM, jalano wrote:
battery.voltage: 16.0
battery.voltage.nominal: 24
^ This also seems a bit odd.
Really high -- output.voltage: 136.0
The problem with correction factors is that we need to know how to apply them.
Most of the other corrections are obvious scaling errors (e.g. multiplying by
100,000,000). Smaller corrections may be temperature-dependent.
Here's the line in drivers/cps-hid.c:
{ output.voltage, 0, 0, UPS.Output.Voltage, NULL, %.1f, 0, NULL },
There is, of course, a non-zero chance of a bug somewhere in the driver, but
most of the other HID subdrivers use UPS.Output.Voltage as well. Assuming NUT
is parsing this value correctly, it should show up in the vendor software. Can
you try loading the software in a VM?
--
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] can't find UPS on openwrt/arm
On Apr 5, 2013, at 3:04 AM, Matus UHLAR - fantomas wrote: libusb: 0.00 error [get_config_descriptor] short output read 0/8 Reading the config descriptor is a pretty basic operation. What does lsusb -vvv -d 0463: return? -- 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] can't find UPS on openwrt/arm
On Apr 4, 2013, at 5:38 PM, Matus UHLAR - fantomas wrote: libusb-1.0 - 1.0.9-1 libusb-compat - 0.1.4-1 Does libusb-compat have an equivalent to the USB_DEBUG that was present in libusb-0.1? Also, the drivers drop privileges when run as root. Try -u root to see if it is a permissions problem. -- 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] usb disconnects
On Apr 4, 2013, at 5:10 PM, White Dorian wrote: Apr 4 14:40:37 ubuntu kernel: [ 1613.949140] hub 1-1:1.0: port 2 disabled by hub (EMI?), re-enabling... Is this an external hub, or the virtual root hub (that is, ports on the motherboard)? In either case, shortening the length or possibly re-routing the USB cable should help. -- 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] blazer driver: Possible bugs with battery packs
On Apr 3, 2013, at 1:05 AM, Michail Pappas wrote:
Thank you Charles, that is what I was looking for. One more question. Do you
what is the difference between an override.* and a default.* configuration.
Say, default.battery.voltage.nominal and override.battery.voltage.nominal?
Although the (for example) blazer man page shows that these directives do the
same thing, in main.c there seems to be some difference:
140/* cram var [= val] data into storage */
141static void storeval(const char *var, char *val)
142{
143 vartab_t*tmp, *last;
144
145 if (!strncasecmp(var, override., 9)) {
146 dstate_setinfo(var+9, %s, val);
147 dstate_setflags(var+9, ST_FLAG_IMMUTABLE);
148 return;
149 }
150
151 if (!strncasecmp(var, default., 8)) {
152 dstate_setinfo(var+8, %s, val);
153 return;
154 }
ST_FLAG_IMMUTABLE means that the variable can't be changed later by the driver
or upsrw.
Unfortunately, I am not familiar with the rest of the driver - perhaps
someone else can comment on recommended values.
I also hope so :)
Remember to keep the list CC'd :-)
--
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] UPS don't reset
On Mar 28, 2013, at 4:35 PM, Bzzz wrote: Debian sid package v. 2.6.4-2.3 UPS nitram elite 2002 700VA (serial port) MOBO A7V8X-X Hi list, Everything work fine, except after an AC supply shortage: the UPS don't come back to a normal behavior, it stays on battery (of course, it works right w/o any cable). I assume (based on the HCL) that you are using genericups, type 16? From the man page: 16 = Nitram Elite 2002 [CP=DTR+RTS] [OL=CTS] [LB=-DCD] [SD=???] This means that the driver does not know how to shut down the UPS when it sees the LB signal. Do you have any documentation or manufacturer's software for the UPS? -- 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] Controlling an APC 9210 with nut
On Mar 27, 2013, at 7:29 AM, Graeme Hilton wrote: I've checked out the source code and generated the powernet386-mib.c and .h files; edited the snmp-ups.c and Makefile.am according to the process in that linked document. Hmm, the *.c/*.h files seem to be mostly comments. What was the command line you used? Also, I don't know whether this is related, but it looks like you might need to specify the path to the MIB file differently. The -n argument seems to be used to create a name for the SNMP subdriver, and at the moment that name has slash characters in it (which won't work in C). I suspect the command line should contain -M /usr/share/snmp/mibs -n powernet386.mib. The build process appears to get to make and then throws this error: ... Using existing blazer.8 manual page, since 'asciidoc' was not found. For now, the easiest way is build only the SNMP driver: $ cd drivers; make snmp-ups I need to finish the Buildbot code to upload the auto-generated tarball which includes the output of asciidoc. -- 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] Controlling an APC 9210 with nut
On Mar 26, 2013, at 12:19 PM, Graeme Hilton wrote: What's the upsc output that the developers want? I have a MIB file supplied from APC, but is there a way I can give this to upsd to use? The process isn't automatic yet: http://buildbot.networkupstools.org/~buildbot/cayenne/docs/reb1f01ed6f0e3844d00876b748287976b7c2478a-343/website/output/docs/developer-guide.chunked/ar01s04.html#snmp-subdrivers We have a script to generate a stub SNMP driver, but it requires a bit of work to merge that back into the existing driver. The author of the snmp-ups driver doesn't have a lot of free time at the moment, but if you follow those directions and post results to the list (either this one, or nut-upsdev), I'll see what I can do. -- 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] Tripp-Lite OMNI750ISO
On Mar 25, 2013, at 2:34 AM, David Vree wrote: Got one of these up and running with the tripplite_usb driver on Ubuntu Server 12.04 x64. This particular model has product code 0x1000. I haven't run across a product code on these units before (just the USB VID, PID, and a Tripp-Lite specific protocol, which appears to be 2001 in your case). Setup and installation was pretty standard. The only hiccup was I had to create a udev rule to give the nut group access to USB devices. Did you install via the official .debs, or source? The Ubuntu .debs should set everything up with udev - if not, please file a bug: https://launchpad.net/ubuntu/+source/nut If anyone has any questions let me know. Here's what I am got back from the upsc command: battery.charge: 100 battery.test.status: Battery OK battery.voltage: 14.75 battery.voltage.nominal: 36 device.mfr: Tripp Lite device.model: UPS device.type: ups driver.name: tripplite_usb driver.parameter.pollinterval: 2 driver.parameter.port: /dev/usb/hiddev0 driver.version: 2.6.3 driver.version.internal: 0.20 input.voltage: 106.97 input.voltage.nominal: 120 output.voltage: 114.0 ups.debug.load_banks: 0 ups.debug.V: 31 30 36 30 58 58 0d '1060XX.' ups.delay.shutdown: 64 ups.firmware: F1247.A ups.firmware.aux: protocol 2001 ups.mfr: Tripp Lite ups.model: UPS ups.power.nominal: 750 ups.productid: 0001 ups.status: OL ups.vendorid: 09ae One question I have thought is this: What triggers the drive to send the shutdown command? As Doug mentioned, by default NUT shuts down when the UPS signals LB (low battery). If there is no upsrw variable available to adjust, it means one of two things: the UPS can't adjust this limit, or we don't know how to adjust it. [update: I see that this is not listed in the upsrw output. bummer.] It is worth pointing out that the serial and non-PDC Tripp-Lite UPSes are all based on reverse-engineered protocols. Only the Tripp-Lite models supported by usbhid-ups are based on an open standard protocol (HID Power Device Class), and even then, some experimentation was needed. -- 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] Tripp-Lite OMNI750ISO
On Mar 25, 2013, at 9:20 AM, David Vree wrote: [ups.delay.shutdown] Interval to wait after shutdown with delay command (seconds) Type: STRING Value: 64 There is nothing apparently settable about its LB point via the driver. BTW -- What do you think ups.delay.shutdown means? ups.delay.shutdown is the number of seconds between when the driver (in response to LB) sends the UPS the shutdown command, and when the UPS should actually pull power. This delay is meant to account for the time it takes to shutdown a single OS (since the OS often shuts down the USB stack at some point), but you might be able to stretch things a bit (that delay is a 16-bit integer that gets passed straight to the UPS, for a potential range of 65,535 seconds). The alternative, if you are not as concerned about maximizing runtime, is to start a timer with upssched when the UPS first loses power, and cancel the timer if the power returns before the LB threshold is hit. I would advocate the belt-and-suspenders approach of doing both, just in case your battery starts to weaken, and you hit the LB threshold before the timer expires. The upssched approach has the disadvantage of being time-based rather than percentage-based, but it should get the job done. -- 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] How to shutdown the system and put UPS in stayoff status rather than in return status
On Mar 15, 2013, at 11:58 AM, Roberto Martelli wrote: My only problem is that I would like to change the behavior of the NUT driver blazer_ups when you turn off the system but I do not know how to do. Not all hardware supported by the blazer_* drivers will accept this command. Try setting things up so that you can send a shutdown.stayoff command with upscmd (preferably when the computer is *not* plugged into that UPS). Note any delays that occur (check the man page, I think the default is 3 minutes). If that works, you can manually send this as part of the shutdown sequence, but timing might be interesting. -- 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] Middle Atlantic SNMP UPS
On Feb 28, 2013, at 1:39 PM, Will Sutton wrote: I am working with a Middle Atlantic IP controllable UPS. I have found that it is made by CyberPower and is controlled via SNMP. There are some controls using the auto SNMP driver that do not show up with uspcmd -l $UPSNAME. Is there a way to use a manufacturer supplied .mib file to control this piece? The SNMP driver maintainer is swamped at the moment, but we have some documentation on this: http://buildbot.networkupstools.org/~buildbot/cayenne/docs/latest/developer-guide.chunked/ar01s04.html#snmp-subdrivers As I understand it, if you have a separate MIB file, you need to find a way to put it on the MIB path for snmpwalk, otherwise tools which use snmpwalk (such as the NUT SNMP subdriver generation script) will only have numeric IDs for the extra features. In order to do this, you will need a post-2.6.5 snapshot of the NUT source code, which you can get from Github: https://github.com/networkupstools/nut Feel free to post any questions you encounter. Even if you just have a sysOID for your UPS, we can compare it to the others in the tree, and see if it is similar. -- 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] Startproblems - Settings for ups.conf
On Mar 7, 2013, at 6:48 AM, Gregor Burck wrote: 0.199391 Checking device (06DA/0003) (005/003) 0.199409 - VendorID: 06da 0.199415 - ProductID: 0003 0.199420 - Manufacturer: unknown 0.199425 - Product: unknown 0.199430 - Serial Number: unknown 0.199436 - Bus: 005 0.199440 Trying to match device 0.199451 Device matches 0.199460 failed to claim USB device: could not claim interface 0: Operation not permitted Any of those configurations should work, but there seems to be a permissions problem. This is odd, since there is a udev rule in the Ubuntu package on 12.04 which should match this device. What does 'ls -l /dev/bus/005/003' return? (adjust the 005/003 to match the last part of the Checking device line for the UPS) You can also see if '/lib/nut/blazer_usb -DDD -u root -a powerwalker1' works temporarily. -- 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] Power ware 5110 not the right sequence received
On Mar 6, 2013, at 10:23 PM, Paul Barber wrote: Does anyone know if there is a fix for the 2.524187 Communications with UPS lost: get_answer: not the right sequence received 19!!! error? I am not very familiar with this driver, but it does seem like this has been patched in the development codebase after 2.6.5 was released: http://article.gmane.org/gmane.comp.monitoring.nut.user/7302 (with a bugfix for that patch later) A number of additional BCM/XCP fixes have been rolled into this branch: https://github.com/networkupstools/nut/tree/bcmxcp You can grab a snapshot from that page, or clone via git. Let us know if you need a snapshot which does not require autoconf and automake. -- 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] false low battery alarm
On Feb 28, 2013, at 4:10 AM, Vieri wrote: input.transfer.reason : simulated power failure or UPS test Sounds like it was the UPS self test? ups.mfr.date : 01/10/06 If this is the original battery, it is certainly possible that it has built up enough internal resistance that the voltage reads normal when idle, but it dips too low during a test. ups.test.interval : 1209600 1209600 seconds = 14 days, so if it does it again in two weeks... -- 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
