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.

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

(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

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

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

Hello all, I think I've found the "regression" in Belkin/Liebert USB HID support which worked for NUT v2.7.4 and reports zero voltages in 2.8.0 -- it was actually caused by a bug fix: practically the only functional difference per `git diff v2.7.4..v2.8.0 drivers/belkin-hid.c` is a change from `abs()` to `fabs()` in order-of-magnitude comparisons like `if( abs(value - 1e-7) <

Hello all, I think I've found the "regression" in Belkin/Liebert USB HID support which worked for NUT v2.7.4 and reports zero voltages in 2.8.0 -- it was actually caused by a bug fix: practically the only functional difference per `git diff v2.7.4..v2.8.0 drivers/belkin-hid.c` is a change from `abs()` to `fabs()` in order-of-magnitude comparisons like `if( abs(value - 1e-7) <

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

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

Cheers all, Per https://github.com/networkupstools/nut/pull/2480 there seems to have been a byte-order bug in usbhid-ups subdriver for Powercom that precluded it from shutdowns. I am not fully certain if the problem (or the fix) are endianness-dependent, so would welcome testing of that PR from various platforms (x86, arm, ...) As usual, I hope

Cheers all, Per https://github.com/networkupstools/nut/pull/2480 there seems to have been a byte-order bug in usbhid-ups subdriver for Powercom that precluded it from shutdowns. I am not fully certain if the problem (or the fix) are endianness-dependent, so would welcome testing of that PR from various platforms (x86, arm, ...) As usual, I hope