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, 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

(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

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

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

Thanks for the info! First, regarding the later detail about starting `usbhid-ups`: the "Resource busy" indicates that likely an earlier instance of the NUT driver (in its own service unit) is still running and holding the device. In a worse case, some other programs might consider this a HID device (same class family as keyboards and mice) and grab it somehow, or it gets passed through

I?m making some progress I believe? I switched off and switched on the UPS further to the laptop having started the daemon and I?m not getting the same error message which is probably due to the server working in the background still locking the device I think the daemon starts but gets into an infinite loop and doesn?t finish and hand back control. Here are the updated traces I got by

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

oh! Ok, I'll go look at all the HID objects reported by the sample code @abratchik has on top-of-tree of his repo and see what makes sense to add to NUT. PR coming this week. On Sun, Nov 12, 2023 at 2:38?PM Jim Klimov <jimklimov+nut at gmail.com> wrote: > Well, the intention generally is to use it as a driver, so the more > abilities the merrier (PR would be welcome) :) >

Jim Klimov <jimklimov+nut at gmail.com> writes: > I don't think there is any particular strategy, at least not one I'd know > of either :) So it is mostly ad-hoc, to keep smaller verbosity numbers > reasonably quiet, and sufficient info to see the logic progression at a > given debug level (e.g. if major milestones of a routine are logged at > level N, further

Further information on this issue, attn. Arnaud Quette: Here is the result of a test I made a few days ago. I've pulled the input plug on the UPS and watched the 3 critical OIDs through a MIB browser: - 1.3.6.1.4.1.232.165.3.4.5.0 goes from 3 (OL) to 5 (OB) (as expected => good) - 1.3.6.1.4.1.232.165.3.7.3.0 stays at 1 (OB) (=> seems meaningless) - 1.3.6.1.4.1.232.165.3.7.4.0