similar to: PR to change logging of OL+DISCHRG UPS state combo

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

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

Hi. Back before Christmas Arnaud sent me a patch for the snmp-ups driver for my HP R12000/3 UPS. Unfortunately shortly after I had to take quite a lot of sick leave so wasn't able to progress it, but I'm working on it again now. I'm at the point where I can start the driver with upsdrvctl and start the daemon with upsd. When I check the UPS status though it shows as OL DISCHRG OB,

On Jul 15, 2013, at 6:17 AM, Pratt Chris wrote: > Hi. > > Back before Christmas Arnaud sent me a patch for the snmp-ups driver for my HP R12000/3 UPS. Unfortunately shortly after I had to take quite a lot of sick leave so wasn?t able to progress it, but I?m working on it again now. Hi Chris, Is this the patch you are referring to?

Hello Jim, That?s a great help for me. You?re a so kind person ~ Our engineer download the branches f17d9f5 as below and repackage it for test. After testing, The Beta NUT works well with ST VID "0x0483", PID "0xA430. Please tell me how to speed up for merging this to formal version. May I have your predict schedule if possible? Thanks.

So, NUT v2.8.3-rc1 is out. I first thought it was the release, but some CI runs convinced me otherwise, so there would be a bit of back and forth on the master branch as some recipes get fixed. Apparently, some parallel runs stepped onto each other's toes sometimes, but coinciding the wrong way just once in a few hundred builds. Hopefully I found why and will re-publish in a few hours. Jim

So, NUT v2.8.3-rc1 is out. I first thought it was the release, but some CI runs convinced me otherwise, so there would be a bit of back and forth on the master branch as some recipes get fixed. Apparently, some parallel runs stepped onto each other's toes sometimes, but coinciding the wrong way just once in a few hundred builds. Hopefully I found why and will re-publish in a few hours. Jim

Hello, Just wanted to clarify: what sort of issues did you have with the APC? Since last year there have been several posts such as https://github.com/networkupstools/nut/issues/2347 about BX****MI (3-4 digits for wattage) series built (or flashed with firmware?) roughly in 2023-2024 as frequently reporting low-battery/replace-battery/all-good events in a short timeframe, both with NUT and

So... April 1st came and went, busy with last-minute warnings from a newly set-up NetBSD build agent for the NUT CI farm, as Greg-inspired warnings exposed by the stricter platform kept popping up and biting. Led to some discoveries in toolkits and standards I thought I knew for decades, too. So it was a tad bit annoying, but good overall :) But now we are a day over the hopeful "not more

So... April 1st came and went, busy with last-minute warnings from a newly set-up NetBSD build agent for the NUT CI farm, as Greg-inspired warnings exposed by the stricter platform kept popping up and biting. Led to some discoveries in toolkits and standards I thought I knew for decades, too. So it was a tad bit annoying, but good overall :) But now we are a day over the hopeful "not more

(was: false alerts/shutdown) 2007/6/18, Arjen de Korte <nut+devel at de-korte.org>: > > > 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

Hello, and thanks for the clarifications. As described, the change does not seem to be too complex on the NUT project's side, the PR posted below took about an hour with some research and this write-up, so I'm not sure I can put a price tag on it :) A donation at https://opencollective.com/networkupstools or https://github.com/sponsors/networkupstools would be welcome though, more so a

Kicking the old tyre a bit once more: In my recent reading I saw "float charge", "float mode", "float voltage" etc. Maybe that is what I meant in the earlier discussion - similar concept, similar word. In case of PbAc per https://chargetek.com/basic-information.html : "Float mode is where the voltage on the battery is maintained at approximately 2.25 volts

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, ?Thank you for your prompt response! The problem I had with my BX950MI unit was that it was frequently reporting off-line, on batt and often not responding to requests from apcupsd (apcaccess) and then going back online again. However, the warranty replacement was prompted by a failed battery, apparently leaking acid, after around ten months use.? As a matter of interest, I had a

Hello all, During discussion for development of a new driver, an old thought came to my attention that we have a potentially insecure approach with some parts of the codebase working with string and "var arg list" manipulation, which use dynamic `char *` variables instead of fixed strings (or macros that expand to those). There are typically good reasons in code to do so, such as

Hello all, During discussion for development of a new driver, an old thought came to my attention that we have a potentially insecure approach with some parts of the codebase working with string and "var arg list" manipulation, which use dynamic `char *` variables instead of fixed strings (or macros that expand to those). There are typically good reasons in code to do so, such as

Jim Klimov <jimklimov+nut at gmail.com> writes: >> "battery voltage is unreasonably high" is a reasonable concept. <...> I >> would not call it HB, though because that makes it sound parallel to LB, >> which is about believed remaining capacity, not detection of overcharging >> failure. > > Well, given that a "battery.charge.high" is

Thanks again. So one more bit (other than indeed different libusb versions) that could potentially come into play is bitness - armv7l builds are 32-bit, right? One idea from here is to have you run the driver programs directly with high debug verbosity, e.g. `usbhid-ups -DDDDDD -s Liebert` to compare the two walls of text (at some debug level it spews byte data seen from libusb); this might

Hi! Have a similar issue with one of our customers having HP R12000/3 UPS with AF430A card. Upsmon shows the UPS as Online, on Battery and Battery discharging at the same time: [root at smrsrvslv06 lib64]# upsc hpups at localhost ambient.temperature: 19.0 ambient.temperature.high: 0.00 ambient.temperature.low: 0.00 battery.charge: 94.00 battery.current: 0.00 battery.runtime: 4620.00