similar to: AP9630 AES Support

On Mar 30, 2014, at 10:39 PM, Shade Alabsa wrote: > Hello again! Your suggestions the other day did work so thank you! I do have one more question for you guys though. APC AP9630 SNMP monitoring card is listed in the HCL and next to it there is privProtocol = AES. Does this mean only AES works or AES doesn't work? I saw the archived mailing lists were it looked like it only worked with the

Updating an old thread. History here. http://lists.alioth.debian.org/pipermail/nut-upsdev/2013-January/006391.html http://lists.alioth.debian.org/pipermail/nut-upsdev/2013-February/006394.html http://lists.alioth.debian.org/pipermail/nut-upsdev/2013-February/006398.html On Fri, 1 Feb 2013, Tim Rice wrote: [snip] > > In all my testing I discovered the APC AP9630 is kind of flaky when >

Hello: I have APC AP9630 UPS, use nut, but the execution failed, my ups.conf setting right? thank! nut2.7.3 net-snmp5.2.1 openssl0.9.8 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20160419/032eedd5/attachment.html> -------------- next part -------------- A non-text attachment was

Hello, i'm trying to monitor a APC Smart-UPS 1000 behind a APC AP9630 Network Management Card via SNMPv3 using the AES Privacy Protocol. * OS name and version: Debian 10.1 * exact NUT version: 2.7.4 * NUT installation method: from debian package 2.7.4-8 * exact device name and related information * Model Number AP9630 * Hardware Revision 08 * Manufacture Date

nut-2.6.5 Scientific Linux 6.3 APC AP9630 management card My basic question is, does nut's SNMPv3 implementation work? I have this in /etc/ups/ups.conf ...... [tfapc01] driver = snmp-ups port = tfapc01.testfest.ixorg.org mibs = apcc snmp_version = v3 secLevel = authPriv secName = tfsnmpprof1 authPassword = ralow6moHet7zoboP8 privPassword = tuseL8Pakaz9degim7 authProtocol=MD5

Hi All! Just an update! The snmp driver seems quite happy with an APC AP9618 managment card in an APC Smart-UPS RT 5000 XL UPS. I have an APC AP9630 to test in the near future so will give and update on that one too! Cheers Ang -- Angela Williams angierfw at gmail dot com Linux/Networking Hacker Blog http://angierfw.wordpress.com Smile! Jesus Loves You!

Hello all, I was asked about a proper way to ensure powerfail shutdown of a blade server fed off an APC SmartUPS, which is monitored by all hosts over SNMP. In particular, they'd like to avoid the "untimely" return of utility power - when the OSes are already shutting down, and would stay down because the UPS is well-fed now and thus won't power off and later power on to boot

Hello, I am using an APC UPS (Smart-UPS 2200 RM) to secure my SAN. The SAN runs on FreeBSD 9.1-RELEASE-p5 and is using NUT 2.6.5 version 2. Since the UPS has also a Network card AP9630 I am using the snmp-ups driver to connect the SAN to the UPS for signaling. Last week I need to change the battery pack and then I needed to perform a runtime calibration. I used the web interface of the AP9630

Soon as I get back to that computer I will let you know which kernel version. Both were just recently installed, Fedora was installed specifically for this actually, though updates have been applied. I've tried it with other USB ports already across 5 different machines. I've also swapped out the USB cable for another one that I knew worked fine. I'll see what I can do about

On Sep 29, 2014, at 12:50 PM, Shade Alabsa <shade34321 at gmail.com> wrote: > The lsusb command did not trigger a disconnect. The output of that > command is below. If you run lsusb several times, does it still work? The exact output of lsusb isn't as important as whether anything gets logged by the kernel. Running lsusb shouldn't cause any extra kernel messages such as

Hi Jim, On Tue, 18 Feb 2014, Jim Klimov wrote: > Hello all, > > I was asked about a proper way to ensure powerfail shutdown of a blade > server fed off an APC SmartUPS, which is monitored by all hosts over > SNMP. In particular, they'd like to avoid the "untimely" return of > utility power - when the OSes are already shutting down, and would > stay down

On Sep 22, 2014, at 11:14 AM, Shade Alabsa <shade34321 at gmail.com> wrote: > These machines are exact replicas of each other and are fairly old and have a Core 2 Duo E8400 CPU in them. Is there anything else you need or anything I can do to help fix this? Thanks! Also, Barry Skrypnyk mentioned that Fedora was one of the Linux distributions that Tripp Lite claims to support. I recommend

(Note that I mentioned this *was* previously working with an older version of Nut). [irs2-ups1] driver = snmp-ups port = irs2-ups1.sum.naoj.org mibs = auto community = private irs2-ups1.sum.naoj.org responds to pings. On Tue, Oct 8, 2013 at 3:55 PM, Tim Rice <tim at multitalents.net> wrote: > On Tue, 8 Oct 2013, Philip Tait wrote: > > > Here is the upsc

Charles, So I installed a minimal CentOS 6.5 installation on the Fedora box this morning and I got the same issue. Below are the kernel versions used. CentOS 6.5 Minimal - [root at nemo tmp]# uname -a Linux nemo 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root at nemo tmp]# rpm -qa | grep nut nut-2.6.5-2.el6.x86_64 nut-client-2.6.5-2.el6.x86_64

Charles, > If you run lsusb several times, does it still work? The exact output of lsusb isn't as important as whether anything gets logged by the kernel. Running lsusb shouldn't cause any extra kernel messages such as the disconnection/reconnection messages shown here: Running lsusb seveeral times works just fine and no disconnects are observed. > This

I'm in the process of trying to get NUT to manage an APC SmartUPS. Monitoring of the UPS is working fine: $ upsc nutdev1 at localhost Init SSL without certificate database ambient.1.humidity.alarm.high: 60.00 ambient.1.humidity.alarm.low: 30.00 ambient.1.temperature.alarm.high: 40.00 ambient.1.temperature.alarm.low: 10.00 battery.charge: 94.00 battery.charge.restart: 0 battery.current: 0.00

All, We think we found something that is causing the problem but as of right now we are unsure as to why it might be causing the issue. Recently I had to restart testing this to figure it out and for some odd reason I wasn't able to reproduce it with any system but our own custom system. I then noticed that in ups.conf I did not set the pollinterval, we normally set it to 15, so I set it to

Hi All, I'm trying trying to draw a colour wheel (a slice of hcl space) in R. Running the code below doesn't give me what I expect - there's some oddly bright colours of the wrong hue around c(0, 0) and I see three coloured circles (a small magenta, a medium sized yellow and a large cyan). Am I doing something wrong or is there a bug in the hcl code? (Also any suggestions for

Here is the upsc output: # /usr/local/ups/bin/snmp-ups -DD -a irs2-ups1 Network UPS Tools - Generic SNMP UPS driver 0.68 (2.6.5) 0.000000 debug level is '2' 0.000327 SNMP UPS driver : entering upsdrv_initups() 0.000341 SNMP UPS driver : entering nut_snmp_init(snmp-ups) 0.056112 SNMP UPS driver : entering load_mib2nut(auto) 0.056126 trying the new

Hi everyone, I wanted to draw your attention to a new post on the developer.R-project.org blog: https://developer.R-project.org/Blog/public/2019/04/01/hcl-based-color-palettes-in-grdevices/ A new function grDevices::hcl.colors() greatly extends the color palette functionality available in base R. Also, the defaults in the heatmap functions image() and filled.contour() have been adapted