similar to: How to set a UPS variable

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

Hello Charles, Thank you so much for your help. Just run upsc and it is possible that input.transfer.low is the one because we used power regulator to bring down the power around 84v and then the ups sent the power loss message to PC. Do you think some others may take effect for the low voltage? Just have the upsc result attached. Then I retried input.transfer.low, default.input.transfer.low,

Hey Charles, Latest update. Looks like in ups.conf I setup default.input.transfer.low = 84. After I took that line out, restart upsdrvctl, upsmon, and upsd, the command of sudo upsrw -s input.transfer.low=70 -u * -p * ups return OK. Still need to verify if it works by using voltage regulator and will keep you updated. Thank you for your help Regards Shen On Thu, Jun 5, 2014 at 8:54 AM,

Jim Klimov <jimklimov+nut at gmail.com> > > I believe some fixes were applied to the branch since your report (most visibly, about battery time settings), are you in position to test how it behaves now? :) Hi: I got another ups for testing. so I test the new commit for both APC SRT3000XL and SMT2200RM2U. the results below: 1. I get the new attribute "ups.test.result" for

Jim Klimov <jimklimov+nut at gmail.com> > > I believe some fixes were applied to the branch since your report (most visibly, about battery time settings), are you in position to test how it behaves now? :) Hi: I got another ups for testing. so I test the new commit for both APC SRT3000XL and SMT2200RM2U. the results below: 1. I get the new attribute "ups.test.result" for

I believe some fixes were applied to the branch since your report (most visibly, about battery time settings), are you in position to test how it behaves now? :) Thanks in advance, Jim Klimov On Wed, Nov 22, 2023 at 3:20?PM Jim Klimov <jimklimov+nut at gmail.com> wrote: > Great! Thanks for the info, and hope the driver author can address the > nits (forwarding now...) > > Jim

I believe some fixes were applied to the branch since your report (most visibly, about battery time settings), are you in position to test how it behaves now? :) Thanks in advance, Jim Klimov On Wed, Nov 22, 2023 at 3:20?PM Jim Klimov <jimklimov+nut at gmail.com> wrote: > Great! Thanks for the info, and hope the driver author can address the > nits (forwarding now...) > > Jim

On Jun 7, 2017, at 1:14 PM, Roger Price wrote: > > 2. On the NAS, use command > > upsrw -s battery.charge.low=80 -u upsmaster -s sekret UPS Robbie, The "upsrw" command contacts upsd, so it sounds like you should be able to add a user to upsd.users on the NAS, and then run something like this on the Mac: upsrw -s battery.charge.low=80 -u upsmaster -s sekret UPS at

Hi, I am trying to talk to an MGE Pulsar Extreme UPS over RS232 with the mge-shut driver but I'm having some problems. It appears to init OK but I can't, say, turn the outlets off, eg.. harrow:~>upsc mge@localhost battery.charge: 78 battery.charge.low: 20 battery.runtime: 05760 driver.name: mge-shut driver.parameter.port: /dev/cuad1 driver.version: 2.0.3 driver.version.internal: 0.65

Great! Thanks for the info, and hope the driver author can address the nits (forwarding now...) Jim On Wed, Nov 22, 2023, 15:05 d tbsky <tbskyd at gmail.com> wrote: > Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > > > Got an update for APC Modbus users: a new PR is waiting for real-life > testing for settable variables and instant commands

Great! Thanks for the info, and hope the driver author can address the nits (forwarding now...) Jim On Wed, Nov 22, 2023, 15:05 d tbsky <tbskyd at gmail.com> wrote: > Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > > > Got an update for APC Modbus users: a new PR is waiting for real-life > testing for settable variables and instant commands

I was looking at how other drivers deal with outlet collections, and I noticed some differences between newhidups in 2.0.4 (from Debian's 2.0.4-2.3) and the SVN trunk (rev 723) on an Evolution. Full diff is below, but here are the highlights: * MGE HID 0.9 vs 1.0 * outlet.#.switch seems to have moved to the commands outlet.#.load.{on,off} Then I found this in the ChangeLog: * fix

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Got an update for APC Modbus users: a new PR is waiting for real-life testing for settable variables and instant commands support. > > https://github.com/networkupstools/nut/pull/2184 > > As before, a custom build of libmodbus may be needed for USB support (detailed in the earlier PR), but Serial and

Jim Klimov via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > > Got an update for APC Modbus users: a new PR is waiting for real-life testing for settable variables and instant commands support. > > https://github.com/networkupstools/nut/pull/2184 > > As before, a custom build of libmodbus may be needed for USB support (detailed in the earlier PR), but Serial and

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 5/21/2017 10:39 AM, Charles Lepple wrote: > Mike, > > Thanks for the info. I have enough to add an entry to the DDL, but I have a few more questions inline. > > On May 14, 2017, at 1:21 PM, Mike wrote: >> >> [updated] >> >> OpenBSD 6.1/amd64 >> NUT 2.7.4p0 (from OpenBSD package) >> >> >> Results of upsc: >> >>

Hi! We have two MGE Evolution 1100 here, and I want to make use of the powershare outlets to force a particular boot sequence on the machines powered by them. However I'm not sure how to set those variables upon NUT starting, without having to change the init scripts to call "upsrw". Is there some place where I can set them, where they can be read automatically on startup? One of

Hello, we have a MGE Pulsar Evolution 800 connected to a Fedora Core5 Server using a serial cable. Installed and configured properly are RPM versions of nut-2.0.3-0.1.fc5 nut-client-2.0.3-0.1.fc5 nut-cgi-2.0.3-0.1.fc5 which all work (mostly) fine. The server is connected to outlet.0 and properly shuts down when it's loosing power after around 20 minutes. It also boots up whenever the ups

Hello all, I've got an MGE Pulsar Ellipse Premium 800 powering a couple of FreeBSD systems. Driver used is mge-shut, I don't know what the new mge-shut driver offers, but I follow the "if it works, don't fix it" dogma here. :) I also had a nut server installed on the master, with the /usr/local/etc/rc.d/nut script slightly modified to include a couple of upsrw commands

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"