similar to: UPS not Shutting Down

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

Hi Charles, The posting at https://github.com/networkupstools/nut/issues/432#issuecomment-405371395 references ups.delay.start and suggests setting it to -1. upsrw -l pve1 at localhost listed this as modifiable but any attempt at modifying the value failed. I used the *override.ups.delay.start = -1* in nut.conf and this is now being reported. Two observations are that once a variable setting

Hello, I am a new user of NUT and trying to wrap my ahead around a couple of things. I installed NUT 2.7.4-13 from package on RasPi 4, running Raspbian Linux 11 (bullseye). I have Cyberpower SL700U connected to it. For testing I set battery.charge.low to 90, so I wouldn't have to wait a long time. See all relevant config below. First of all, what seems to happen is that UPS gets to the low

Hi, I tried your suggestions on another Proxmox environment with the following ups.conf: # Wait 10 seconds for the driver to finish starting. maxstartdelay = 10 # Try 3 times to start the driver, before giving up. maxretry = 3 # Wait 5 seconds between attempts to start the driver. retrydelay = 5 # Poll the ups every 5 seconds pollinterval = 5 [pve1] # Cyber Power Systems, Inc driver =

> Unfortunately, the SUCCESS response is just saying that upsrw was able to send that request to upsd (i.e. the username/password were correct). As you saw, the real proof is in what you read back from upsc. Ah, gotcha. > Have you tried any other values? 3600 is hex 0xe10, and 16 is 0x10, so it is quite possible the UPS is using an 8-bit field to store battery.runtime.low. I'm guessing

I'm not sure I understand your question. The UPS was running for more than 15 minutes before it went below the battery.charge.low: of 70. Below is my /etc/nut/nut.conf. My goal is that when the UPS report a battery.charge.low of < 70 (or, if possible has been running for 5 minutes) it starts the shutdown process. The shutdown process should take 15 minutes so that proxmox can shutdown

I have an HP T1000 G3 for looking after three desktop PCs, a switch and a router. The batteries seem to be fine (battery tests, charge levels), but when I'm testing a power-failure, the UPS starts the FSD much too soon (judging by the battery charge level monitored with upsc). The load is about 300W, less than half nominal load, so despite the batteries not being brand new, it ought to keep

Hi Charles, > Sigh, I wish the vendors wouldn't change operation without changing identifiers. > > Do you have any recommendations on how the driver should decide whether it is an old 0x0004 or new 0x0004 device? No-no, there is no an old 0x0004 or new 0x0004 device, I guess that we have to handle general case for all 0d9f:0x0004 devices. From PCM_USB_LIST_device2014.pdf attached

On Dec 29, 2015, at 6:33 AM, Jonah Naylor <jonahnaylor at gmail.com> wrote: > > HI thanks for replying and helping. > > I've now ran the UPS down a few times from full charge to test and I don't think it's the batteries or a problem with the UPS itself. I can watch it go from 100% right down to 1% over 20 minutes etc and then the power gets so low that everything

My bad. I'll check it out. On Sun, 2 Jun 2024 at 08:14, Roger Price < roger_at_rogerprice.org_chribonn at duck.com> wrote: > On Sat, 1 Jun 2024, Alan via Nut-upsuser wrote: > > > root at proxmox-01:~# cat nano /etc/nut/ups.conf > > If you send us hundreds of lines of comments it makes your post difficult > to > understand. Could you trim out the comments with

On Nov 12, 2014, at 3:53 AM, Maksym Bodaniuk <max.bodaniuk at gmail.com> wrote: > Hi Charles, > >> Sigh, I wish the vendors wouldn't change operation without changing identifiers. >> >> Do you have any recommendations on how the driver should decide whether it is an old 0x0004 or new 0x0004 device? > > No-no, there is no an old 0x0004 or new 0x0004

----- Mensagem Original -----=20 Eu boicotaria estas empresas s=F3 pelo fato de financiarem os enjoativos e = rancentos Cassetas, mas me surpreendi ao descobrir que tantos produtos que = eu costumo comprar s=E3o transg=EAnicos. Fui conferir no site do greenpeace= e =E9 verdade!!!!!!!!!!!!! Boicote neles! ----- Original Message -----=20 C A M P A N H A=20 N A T A L S E M B A I X A R I A

Hi all, Apparently some people had trouble joining today. I also had trouble using the attendee ID provided by webex. I've canceled the meeting series and will be scheduling a new one with an updated link. Please remember to update your calendars with the new invite. My apologies to those who couldn't join today, and to everyone for the churn. Today's Meeting Minutes:

Hello All, I'm trying to establish a MASTER SLAVE configuration of UPS using NUT Driver. I'm able to shutdown the master after UPS is on BATTERY ( POWER BLACKOUT) .However I'm trying to shutdown the other SLAVE MACHINES BEFORE MASTER. But at the remote side ( Slaves ) shutdown after UPS blackout does not happen. My configuration in Master are /usr/etc/upsd.users

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

Hi Everyone, I recently bought a Tripp-Lite SMART1500LCD for my Linux Mint 19.3 machine, connected via a USB cable. I installed Nut 2.7.4 from the Mint package repository via sudo apt update && sudo apt install nut. Everything works great: NUT issues low battery warning when it reaches the set low battery point and then issues shutdown commands...computer shuts down..then the UPS shuts

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 immediatly as suggested in the manual. But the UPS powered off again. The variables reported by upsc can be found

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

Hello nuters, FreeBSD, Ellipse USBS 800, serial line, nut 2.02 everything works fine. But I'm only able to get an automatic shutdown when reaching the built-in 30% level. I the "lowbatt parameter" is set to anything, it's simply ignored. This is a problem as I want to shutdown around 90% to avoid the battery to drain out when multiple shutdowns occur. Any idea ?

On Mon, 17 Feb 2020, Stefan Schulze wrote: > So currently the sequence is: > 1. Main power goes off > 2. UPS and nut goes "OB DISCHRG" > 3. I enter `upsmon -c fsd` Does upsmon.conf specify a shutdown on LB? What happens if you let the battery power the system until LB is reached? You could set LB to say 85% for more rapid testing with upsrw -s battery.charge.low=85