similar to: questions re. patching bcmxcp.c and choosing variable names

This UPS is already listed in the compatibility list. But I wanted to add the instant commands supported by upscmd: ============================ Instant commands supported on UPS [PW5125]: beeper.disable - Disable the UPS beeper beeper.enable - Enable the UPS beeper beeper.mute - Temporarily mute the UPS beeper load.on - Turn on the load immediately outlet.1.load.off - Turn off the load on

NUT 2.6.5 on FreeBSD 9.1 Why isn't the variable outlet.1.delay.shutdown set with the following command? # upsc PW5125 at localhost | grep "outlet.1.delay.shutdown" outlet.1.delay.shutdown: -1 # upsrw -u au -p ap -s outlet.1.delay.shutdown PW5125 at localhost Enter new value for outlet.1.delay.shutdown: 10 OK # upsc PW5125 at localhost | grep "outlet.1.delay.shutdown"

Also works if you want to shutdown one segment/outlet early in the power failure. It should stay off until utility power returns and then apply the configured delay - although I haven't tested this aspect. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bcmxcp.c.diff Url:

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 at localhost | grep "outlet.1.delay.shutdown" > |outlet.1.delay.shutdown: -1 > | > |# upsrw -u au -p ap -s

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 at localhost | grep "outlet.1.delay.shutdown" |outlet.1.delay.shutdown: -1 | |# upsrw -u au -p ap -s outlet.1.delay.shutdown PW5125 at localhost |Enter new value for outlet.1.delay.shutdown: 10 |OK | |# upsc PW5125

l?rdagen den 29 juni 2013 15.22.44 skrev Mike.: 8<-------------snip----------------- Sorry for the delay. > Here is the console output of bcmxcp with -DDD specified: > > > [snip] > 13.721204 Auto delay on: 2 > > 13.721243 send_command: (4 bytes) => ab 01 35 1f > 13.821127 send_command: (4 bytes) => ab 01 33 21 > 13.920982

On 6/29/2013 at 9:59 AM Charles Lepple wrote: |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 at localhost | grep "outlet.1.delay.shutdown" |>

l?rdagen den 29 juni 2013 11.28.14 skrev Mike.: 8<------------------snip--------------------- Hi Mike, > > Thanks for the quick reply. > > I checked the log file (which, admittedly, I should have done before I > posted about the problem :) ). > > Here's the command and the corresponding log message: > > # upsrw -u au -p ap -s outlet.1.delay.shutdown=12

On 6/29/2013 at 6:16 PM Kjell Claesson wrote: |l??rdagen den 29 juni 2013 11.28.14 skrev Mike.: |8<------------------snip--------------------- |Hi Mike, |> |> Thanks for the quick reply. |> |> I checked the log file (which, admittedly, I should have done before I |> posted about the problem :) ). |> |> Here's the command and the corresponding log message: |>

On 2/21/2017 8:34 AM, Charles Lepple wrote: > On Feb 20, 2017, at 11:19 AM, Mike <the.lists at mgm51.com> wrote: >> >> This UPS is already listed in the compatibility list. But I wanted to >> add the instant commands supported by upscmd: >> > ... >> and note that a delayed shutoff command is not available. >> >> (NUT 2.7.4 on OpenBSD 6.0)

Hi, I've been getting emails from upsmon saying: Subject: UPS PW5125 at localhost notification: ONBATT UPS PW5125 at localhost on battery But then the machines on the UPS stay on for hours; we haven't got that kind of runtime, more like 10-20 minutes. After a few occurrences, it now happened at a time where I could log in to see in real time what is happening and: $ upsc PW5125 |

Hi Kjell, a few notes: - you should bump the DRV_VERSION upon every change - you should track the drivers TODO list in a comment header (such as "implement smart load segment detection" completed with your info, ...). That would help to bootstrap new contributors. - you can also use the alioth trackers (features request, or task) to give some external visibility on what remains to be

I have setup nut-2.4.1 with the bcmxcp driver for my HP R3000 XR unit and although it appears to work, I receive the following sorts of errors in syslog: Aug 27 10:33:05 sv18 bcmxcp[6373]: Communications with UPS lost: Receive error (data): got 0 bytes instead of 64!!! Aug 27 10:33:15 sv18 bcmxcp[6373]: Communications with UPS lost: Receive error (data): got 0 bytes instead of 64!!! Aug 27

Greetings, I have been using the bcmxcp_usb driver heavily over the last two years as part of a very successful product, first from NUT 2.4.1 and now from NUT 2.6.0. Now I have a need to do setvar of the outlet.n.delay.start variables, so recently I modified bcmxcp.c to do that. I've tested it and it works well for my purposes. My plans are to begin shipping that modified driver as part

I ran into a portability issue with drivers/bcmxcp.c in nut-2.4.1 on my UnixWare 7.1.4 machine. The error I get is ..... UX:acomp: ERROR: "/opt/src/utils/nut-2.4.1/drivers/bcmxcp.c", line 835: integral constant expression expected ..... Looking at the code we see ..... int init_outlet(unsigned char len) { unsigned char answer[len]; ..... Although gcc can handle it, it's not

Hi, I'd like to inform You that this UPS communicates well via the serial port. I haven't tested USB, and no shutdown testing so far, however, I hope it will run well. HP R5000 upsc output: ambient.temperature: 27.4 ambient.temperature.high: 45 battery.charge: 99.0 battery.runtime: 536 battery.voltage: 236.3 device.mfr: Eaton device.model: HP R5000 5000i device.serial: 3C81520083

Hi all, I just acquired a new UPS and have been trying to get it to work with NUT. It's an Eaton/Powerware 9120 700i with both USB and RS-232 interfaces. I first tried the USB interface (using bcmxcp_usb) and found that the UPS worked fine for a few minutes but then NUT lost communication and didn't get it back. In addition the UPS itself seemed to lock up at one point such that the

On Jul 2, 2013, at 5:16 PM, Kjell Claesson wrote: >> I hope other people can also test this. >> >> Regards >> Alf Hogemark > > Due to some crashes on the disks and lack of time I don't have the git on the > pc now. But maybe some other can commit this. I'd like to ask people to specifically try the bcmxcp branch on GitHub - it includes some changes

1 - its on load blinking battery LEDs and not giving proper back up time . APC sua1000i nut-upsdev-request@lists.alioth.debian.org wrote: Send Nut-upsdev mailing list submissions to nut-upsdev@lists.alioth.debian.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev or, via email, send a message with subject or body

Hi Here is a very minor patch for the bcmxcp.c driver, mainly fixing the function name used in debug statement, and at the same time fix indentation. Regards Alf Hogemark From 86c7940d0ea11b5b38a7f4518095ee2428d658c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alf=20H=C3=B8gemark?= <alf at i100.no> Date: Mon, 1 Jul 2013 21:11:40 +0200 Subject: [PATCH] bcmxcp: Fix method name outputted in