similar to: [RFC] Support of ranges of values for writable variables

Here are the results from the output of upsc under different conditions from my Debian Test system with NUT 2.7.2 : Normal: ups.status: OL No wall power: ups.status: OB Runtime calibration (started from AP9630 web interface): ups.status: OB CAL So at this stage there is a difference! I then connected to my QNAP and set the UPS settings on the web interface to "Shutdown server if power

On 7/6/06, Arnaud Quette <aquette.dev@gmail.com> wrote: > just in time, since I'm finishing 2.0.4-pre1. > I'll release it tomorrow, and I'll check to include your patch. One more thing: the patch changes the solis driver language to Portuguese. Are these units sold outside of Brazil? At some point, if we start supporting more drivers that are sold regionally, it might be

Denny, The first three commands had outputs but the "clog /var/log/system.log | grep -i ups” didn't output any. Did I do anything wrong? This is the output without the grep: can't allocate llinfo for <Public IP> on igb0 Aug 14 18:14:59 pfSense kernel: arpresolve: can't allocate llinfo for <Public IP> on igb0 Aug 14 18:15:00 pfSense kernel: arpresolve: can't

I have a SmartUPS 750 (SUA750) which has the temperature and humidity SmartSlot card installed. When NUT 2.2 communicates with this UPS over /dev/ttyS0 using apcsmart, using the APC Smart cable connected to the SUA750 serial port, and this ups.conf: [su700] driver=apcsmart port = /dev/ttyS0 I can see the ambient temperature and humidity data with "upsc su700 at

This is the patch to include SVN revision level in version number displays. There should be two enclosures; the patch itself and a new source file. common/upsversion.c. upversion.c defines a single function. upsversion(), that returns a version string for display. Some Makefile trickery ensures that this file will be recompiled whenever the project's SVN revision level has changed since it

> On Aug 13, 2018, at 06:17, Charles Lepple <clepple at gmail.com> wrote: > > On Aug 12, 2018, at 11:03 PM, Kevin Mychal M. Ong <kevindd992002 at yahoo.com> wrote: >> >> Hi, >> >> I installed apcupsd through pfsense and noticed some discrepancy with the NUT package. I'm not sure if this is a bug regarding the BATTDATE (apcupsd) and battery.date

01.12.2014, 14:50, "Charles Lepple" <clepple at gmail.com>: > On Dec 1, 2014, at 4:11 AM, Victor Porton <porton at narod.ru> wrote: >> ?battery.voltage: 13.70 >> ?battery.voltage.high: 13.00 >> ?battery.voltage.low: 10.40 > > These are the voltage thresholds for the UPS, so theoretically the UPS will send the LB signal when the battery voltage goes

> If you have any more questions regarding this, please use the nut-upsuser > mailinglist instead. Redirected to the appropriate list, sorry. > > Is there a place in the upsmon.conf (or elsewhere) > > file where one may enter something like: > > > > OVERRIDE_BATTERY_CHARGE_LOW 20 > > OVERRIDE_BATTERY.LOW 240 > > > See 'man 8 upsrw'.

Great, thanks! Two questions: * what is a domain literal? Is this something like 192.168.0.1? In this case, the '[]' are probably unnecessary. * are you sure you want to use fprintf(stderr, ...) in a library? This doesn't seem like a good idea to me. Wouldn't it be more consistent to extend upscli_errlist[] ? -- Peter Arjen de Korte wrote: > > Author:

On 1/13/07, Peter Selinger <selinger@mathstat.dal.ca> wrote: > > The question is when exactly this should be converted to a number. > > Should this be done in upscli_splitname() or in upscli_connect()? The > > latter would require a change in the prototypes of upscli_splitname() > > and upscli_connect(), and an attendant change in all the existing > > clients.

Here is patch 1 of 2. Roger diff -rup nut-2.7.4.orig/clients/upsmon.c nut-2.7.4.dev/clients/upsmon.c --- nut-2.7.4.orig/clients/upsmon.c 2015-12-29 13:08:34.000000000 +0100 +++ nut-2.7.4.dev/clients/upsmon.c 2016-07-01 09:46:21.567766415 +0200 @@ -525,6 +525,18 @@ static int get_var(utype_t *ups, const c numq = 2; } + /* Subcommands for polling SIGUSR1, SIGUSR2 RP */ + if (strcmp(var,

Hi Folks, I'm wondering if there's a secret trick to achieve the following. I have some big code for analysis related to a named variable, which will be one of several in the columns of a dataframe, and I would like to be able to choose between a run for just one of these variables, or a run which loops over them all. So, for a single run, I could have the following kind of thing in a

So... determining that FD is to be reaped proved hard. Internet lore suggests fcntl() and poll() on the FD, but it just seems valid to them. The errno is also usually not raised (once I saw a "111: Connection refused" though). So the best dumb idea so far is to bail out if we spent the whole loop (128 attempts) and only got zero-sized read replies and no errors.

So... determining that FD is to be reaped proved hard. Internet lore suggests fcntl() and poll() on the FD, but it just seems valid to them. The errno is also usually not raised (once I saw a "111: Connection refused" though). So the best dumb idea so far is to bail out if we spent the whole loop (128 attempts) and only got zero-sized read replies and no errors.

Until the release of nut-2.0.5 it was possible to have a working configuration without configuring anything in 'ups.conf'. Since then, this no longer works, as the server will only look for driver sockets for UPSes that have been configured in 'ups.conf' (since the socket is named after the UPSname). Drivers will use the old naming scheme '<driver>-<port>' if

On 9/16/08 3:35 PM, "Arjen de Korte" <nut+users at de-korte.org> wrote: > Citeren tarbeite <tarbeite at fit.edu>: > >> Running opensuse 11 with two ups that can be seen via web interface and post >> messages on the console. > > Please post the contents of /etc/ups/upssched.conf here. Also make > sure that the directory mentioned in PIPEFN and

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, Great work Jim! I?m glad you could reproduce the problem and found a potential culprit. Just for my own interest I restored upsshed from my backups (version 2.7.4-13) and it seems to running ok, so no big runtime changes regarding that with Debian 12. It is not hogging CPU. From the daemon log the heartbeat seems to be working ok. Only difference between the old logs (pre Debian 12 update)

Hi, Great work Jim! I?m glad you could reproduce the problem and found a potential culprit. Just for my own interest I restored upsshed from my backups (version 2.7.4-13) and it seems to running ok, so no big runtime changes regarding that with Debian 12. It is not hogging CPU. From the daemon log the heartbeat seems to be working ok. Only difference between the old logs (pre Debian 12 update)

After launching the command several times, with debug (posted by new code in a new branch for the investigation) confirming that the same daemon handles operations from the new client instances, its strace now has numerous FDs to report after select() - so I guess it is a problem of detecting an exit of the counterpart. 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT