similar to: Can this be done with NUT? (ordered shutdown, revisited)

On Oct 6, 2015, at 5:40 AM, Steffen Grunewald <Steffen.Grunewald at aei.mpg.de> wrote: > > What I currently tried: > - I found a longish discussion on this list, dating back to six years > ago: http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-February/004772.html > In particular, Marco's requirements look quite similar to ours, but > there was apparently no

...it was almost midnight, Cinderella became a pumpkin, and NUT was released!.. Trick or treat?! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20231031/f3590340/attachment.htm>

...it was almost midnight, Cinderella became a pumpkin, and NUT was released!.. Trick or treat?! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20231031/f3590340/attachment.htm>

>>gene heskett <gheskett at shentel.net> writes: >>>Which file in the nut I pulled a month ago, should I start with to get >>>the new version actually running? I still get - -V=2.7.4 >On 5/22/23 07:13, Greg Troxel wrote: >>It is likely that you have built new nut but old nut is still on your >>system. I do a 'sudo make install' to write over

On Mon, 2023-05-22 at 15:54:51 +0200, Matus UHLAR - fantomas wrote: > > > gene heskett <gheskett at shentel.net> writes: > > > > Which file in the nut I pulled a month ago, should I start with to get > > > > the new version actually running? I still get - -V=2.7.4 > > > On 5/22/23 07:13, Greg Troxel wrote: > > > It is likely that you have

Carsten Aulbert <carsten.aulbert at aei.mpg.de> writes: > Hi all, > > On 5/19/23 15:11, Greg Troxel wrote: >> LB is baked in to nut behavior. So if a UPS doesn't report LB, then >> it makes sense to synthesize it. Synthetic LB is the cleanest fix at >> the earlier processing point. > > I fully agree and thus this ought to be done in/near uspd

Hi again, On 5/22/23 18:31, Willcox David via Nut-upsuser wrote: > Hmm. Is there maybe something there already that will do this? Maybe > kind of back-handed. > > In drivers/dstate.c, I see: > > 1. In status_init(), if ?driver.flag.ignorelb? is set in the driver > state, the ?ignorelb? flag is set. > 2. In status_set(), if ignorelb is set, and the status being set

Hmm. Is there maybe something there already that will do this? Maybe kind of back-handed. In drivers/dstate.c, I see: In status_init(), if ?driver.flag.ignorelb? is set in the driver state, the ?ignorelb? flag is set. In status_set(), if ignorelb is set, and the status being set (presumably from the UPS) is LB, it?s ignored. In other words, LB reported by the UPS is ignored. In status_commit(),

Reference the repeater mode of the dummy-ups driver used in the way described by Steffen there is a characteristic which needs to be defined better. I could not find any notes on what the driver does in terms of shutdown. If as a result of LB you issue a upsdrvctl shutdown from a secondary server acting as a master for the repeated driver (which is pretending to run out of battery early) you

On December 2, 2018 7:29:38 PM GMT+02:00, raul <raulvior.bcn at gmail.com> wrote: >I have restored original configuration and enabled the ignorelb flag. I > >didn't point out in the original e-mail that after every poweroff the >battery percentage is reported at 40% instead of 100% and charges >slowly again to 100%. Maybe the UPS sends a LB event and shuts down

Hmm, looking at status_commit(), if the UPS actually reported just ?OB", but the ?ignorelb? logic kicked in, wouldn?t status_commit() change it to ?OB LB?? And would clients interpret that correctly? And, assuming status_commit() is called, is the status so saved what?s returned on a future client query? I?m really unsure how all of this works. I don?t suppose there?s some kind of ?general

Linux-2.4.28 libusb-0.1.8 nut-2.6.5 [+most recent drivers from GIT] - from tarball EATON 3S700DIN [mfr.date 09/28/14] ---------------------------------- ISSUES: I) Too many kernel logs: --- In /var/log/kernel.log usbdevfs: usb_submit_urb returned -28 In /var/log/daemon.log: usbhid-ups[744]: libusb_get_interrupt: No error usbhid-ups[744]: libusb_get_interrupt: error submitting URB: No space left

Hi all, On 5/16/23 20:08, Carsten Aulbert wrote: > Idly browsing the client sources, I guess I could try to add our logic > here[1] and use [2] to gather the battery stats from our UPS and then > decide if this UPS is considered critical or not. But for this, I would > need to dust off/excavate my ancient poor C knowledge ;-). > > I guess I will give this a try unless

This is 2nd version of the earlier patch featuring a few new features and fixes to the apcsmart driver, following the remarks in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02294.html Major changes from v1: - handle battery.charge and battery.runtime checks at main.c level - handle "immutable but writable" conflict gracefully at driver level -

On Sun, 2 Jun 2024, chribonn at duck.com wrote: > ? # if the charge is less than 75 percent trigger a LB status > ? override.battery.charge.low = 75 > ? # if the remaining charge is less than 1200s (20 minutes) trigger a low battery status > ? override.battery.runtime.low = 1200 > ? # wait 5 minutes for ups to power off > ? override.ups.delay.shutdown = 300 > ? # Could

> > battery.charge: 3 > battery.charge.low: 10 > battery.charge.warning: 30 > battery.runtime: 93 > battery.temperature: 32.9 > battery.type: PbAC > battery.voltage: 46.4 > battery.voltage.nominal: 48.0 Is it possible that battery.charge is really 30% rather than 3%? The 3016 protocol models have issues with scaling on some of the voltages and frequencies. You can see

Hi all, I've been doing some searching, but I am not able to find what I'm looking for so I'm hoping someone here might be able to help. I have NUT installed and connected to my UPS, although not configured to do anything yet. I have 2 clusters that I need to shutdown in a specific order to make sure it is all powered down correctly - I know it probably needs to happen through the

On Jan 11, 2015, at 11:48 PM, Graham Menhennitt <graham at menhennitt.com.au> wrote: >> The file drivers/usbhid-ups.c is looking for any of the following conditions to declare LB: >> >> ? STATUS(LOWBATT) >> ? STATUS(TIMELIMITEXP) >> ? STATUS(SHUTDOWNIMM) >> >> The mapping to HID Path names will depend on the model, but STATUS(LOWBATT) can come

This patch introduces a handful of new options, I mentioned earlier in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02088.html See the large commit message in the follow-up for the details and rationale. I realize it's a bit larger diff - so if it's required I can split it into few smaller ones. Michal Soltys (1): APC smart driver update and new features.

Hi all, On 5/19/23 15:11, Greg Troxel wrote: > LB is baked in to nut behavior. So if a UPS doesn't report LB, then > it makes sense to synthesize it. Synthetic LB is the cleanest fix at > the earlier processing point. I fully agree and thus this ought to be done in/near uspd IMHO. I glanced over the server/ directory and was not sure where even to begin hooking this