similar to: CHRG / DISCHRG status

Hi Charles, 2015-03-29 0:44 GMT+01:00 Charles Lepple <clepple at gmail.com>: > On Mar 25, 2015, at 4:11 AM, Arnaud Quette <arnaud.quette at gmail.com> > wrote: > > > 1) Keep the legacy CHRG / DISCHRG status bits for ups.status, along with > the complementary ones for battery.charger.status. And advocate (document) > for the use of / switch to the latter, that is

Hi NUT developers, part of the 2.7.3 release, we are about to merge the below branch / PR for the bcmxcp drivers family: https://github.com/networkupstools/nut/pull/158 https://github.com/networkupstools/nut/tree/pull_158_bcmxcp_rebased It has introduced the battery.charger.status variable, which is something I wanted to implement since around 2007. However, while considering a similar

On Mar 25, 2015, at 4:11 AM, Arnaud Quette <arnaud.quette at gmail.com> wrote: > 1) Keep the legacy CHRG / DISCHRG status bits for ups.status, along with the complementary ones for battery.charger.status. And advocate (document) for the use of / switch to the latter, that is more suitable for publishing such information. All that with an impact on all the NUT driver, and a transition

> driver.name: newhidups [...] > ups.status: OL CHRG Euhm, there is no status 'CHRG' according to 'docs/new-drivers.txt' folks. If you feel the need to create new status flags, at the very least mention them in the section 'Status data' in this file. Unless you document it somewhere, it's of no use to clients. [soapbox] Before doing so, ask yourself (and

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

I'm running nut 2.0.1 with an MGE pulsar evolution 3000 with the mge-utalk (serial) driver on NetBSD 3.1 . I had a very strange occurance in my basement datacenter this early AM. the following was logged by upslog: 20080219 023452 100.0 123.0 049.0 [OL CHRG] NA 60.00 20080219 023522 100.0 122.8 049.0 [OL CHRG] NA 60.00 20080219 023552 098.0 123.0 049.0 [OL DISCHRG] NA 60.00 20080219 023622

I am having an issue running NUT and using an TrippLite OMNI900LCD. When I run ./upsdrvctl start I get : [player@V0002-S002 bin]$./upsdrvctl start Network UPS Tools - UPS driver controller 2.1.0 Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) Detected a UPS: Tripp Lite /TRIPP LITE UPS Using subdriver: TrippLite HID 0.1 (experimental) dstate_setflags: base variable

Hi, This might be a simple thing to fix, but I can?t figure it out. We replaced the battery for the first time in our Eaton 5PX a couple of weeks ago, but we haven?t been able to clear the ?ups.alarm: replace battery!? status. Details of our installation are: OS: Debian 6 NUT version: 2.7.4 Installation method: from source tarball UPS device: Eaton 5PX2000IRT, 240V, 1800W, 2000VA, bought in

Arjen de Korte wrote: > > + * drivers/apc-hid.c: > + - Commented out the 'fullycharged' status. If anyone can explain the > + use of this, please step forward. This flag is defined on p.36 of the "Universal Serial Bus Usage Tables for HID Power Devices", Release 1.0 November 1, 1997, a USB standards document available on the web. The document defines this

Peter, Here are the transitions that I have tested with your latest changes (on the APC/Back-UPS ES 650): 1) OL ==> OB DISCHRG followed by OB DISCHRG ==> OL (no CHRG inbetween) 2) OL CHRG ==> OL 3) OL CHRG ==> OL CHRG LB (by manipulating battery.charge.low) 4) OL CHRG LB ==> OL CHRG (i.e. transition from below) 5) OB DISCHRG ==> FSD OB DISCHRG LB followed by proper shutdown In

On 2/18/20 9:34 AM, Stefan Schulze wrote: > Hi Roger, Hi all, > >> Does upsmon.conf specify a shutdown on LB? > I think so. You mean SHUTDOWNCMD? > The relevant parts of my upsmon.conf (notifications removed): > > MONITOR ups at localhost 1 upsmaster secret master > MINSUPPLIES 1 > SHUTDOWNCMD "/sbin/shutdown -h +0" > POLLFREQ 5 > POLLFREQALERT 2

Charles Lepple wrote: > On 8/2/06, Didrik Pinte <dpinte@itae.be> wrote: > > Le mercredi 02 ao=FBt 2006 =E0 08:08 -0400, Charles Lepple a =E9crit : > > > On 8/2/06, Didrik Pinte <dpinte@itae.be> wrote: > > > > Can you start the driver like this: "/sw/bin/newhidups -u root -DDD" > > > and paste some of the output? > > > > Here

>> But I noticed two other details: >> 1. I was a bit wrong with step 7 and 8 - Looks like the UPS is "OL CHRG" (according to display) at first but goes to battery ("OL DISCHRG" according to nut) right when the RasPi (and nut) is booting. >> 2. When I pull the plug of the RasPi after UPS went down before main power comes back (so between step 5 and 6), the UPS

Sorry about that! Chris. Chris Pratt Development Infrastructure Manager T: +44 118 929 4176 | M: +44 7979 854 307 | F: +44 118 929 4001 -----Original Message----- From: Charles Lepple [mailto:clepple at gmail.com] Sent: 16 July 2013 00:32 To: Pratt Chris Subject: Re: [Nut-upsuser] HP R12000/3 UPS reports status as OL DISCHRG OB On Jul 15, 2013, at 9:35 AM, Pratt Chris wrote: > Debug output

Arnaud, > first, even if your battery is full, and your ups is online, there is a > small amount of power drawn. So having always is CHRG status is normal. > In fact, these complementary status are more interesting for higher end > UPSs. > > second, these status need not to be handled like LB, as each one clears the > other. While LB had no pending event (!LB) before... >

On Tue, 29 Sep 2020, João Luis Meloni Assirati wrote: > The UPS I am developing a driver to is able to report several flags for > critical hardware conditions, like overheat, overload, inverter failure, > output short etc. What should be the correct policy of operation when such a > condition occurs? I think that the an UPS in such a condition is not reliable > and therefore a

This took a long time because I had problems with my system. After I reloaded my operating system several times I found I had a bad memory module. Here is the output from newhidups for my Geek Squad GS1285U. It just kept repeating until I hit ctl-z. I think that this means nut will work for this ups. My computer is not powered by the ups yet. I did not want it to be powered down by accident.

Gentlemen, This is probably for Arnaud, since he has already addressed a somewhat similar problem. I am running newhidups from the development tree (actually everything is from there). However, I have observed the same problem with a 2.0.2 system as well. Here is what I observe: * upsc shows the ups.status: is "OL" * there is a very short interruption of power * upsc shows the

Hi Roger, Hi all,   > Does upsmon.conf specify a shutdown on LB? I think so. You mean SHUTDOWNCMD? The relevant parts of my upsmon.conf (notifications removed): MONITOR ups at localhost 1 upsmaster secret master MINSUPPLIES 1 SHUTDOWNCMD "/sbin/shutdown -h +0" POLLFREQ 5 POLLFREQALERT 2 HOSTSYNC 15 DEADTIME 40 POWERDOWNFLAG /etc/killpower RBWARNTIME 43200 NOCOMMWARNTIME 1800

On June 21, 2017 11:03:00 AM GMT+02:00, Roger Price <roger at rogerprice.org> wrote: >On Tue, 13 Jun 2017, Charles Lepple wrote: > >> On Jun 9, 2017, at 10:16 AM, Roger Price wrote: >>> To address this, I propose a "NUT configuration for Noobs" which is >>> called "Configuration Examples". > >> I am also curious whether you tried to