similar to: Question about hardware failures / FSD

On Tue, 29 Sep 2020, João Luis Meloni Assirati wrote: > The UPS I am developing a driver to is able to report several flags for > critical hardware conditions, like overheat, overload, inverter failure, > output short etc. What should be the correct policy of operation when such a > condition occurs? I think that the an UPS in such a condition is not reliable > and therefore a

Arjen de Korte wrote: > > + * drivers/apc-hid.c: > + - Commented out the 'fullycharged' status. If anyone can explain the > + use of this, please step forward. This flag is defined on p.36 of the "Universal Serial Bus Usage Tables for HID Power Devices", Release 1.0 November 1, 1997, a USB standards document available on the web. The document defines this

Hello Daniel! On Tue, Sep 29, 2020 at 6:23 PM Daniel F. Dickinson <cshore at thecshore.com> wrote: > > Hello joão, > > To get more responses you should plaintext email (standard for open source development mailing lists) instead of HTML mail. I just can't believe that I was sending HTML e-mail. Thank you very very much for bringing this to my attention. I hope it is ok now.

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

Peter, Here are the transitions that I have tested with your latest changes (on the APC/Back-UPS ES 650): 1) OL ==> OB DISCHRG followed by OB DISCHRG ==> OL (no CHRG inbetween) 2) OL CHRG ==> OL 3) OL CHRG ==> OL CHRG LB (by manipulating battery.charge.low) 4) OL CHRG LB ==> OL CHRG (i.e. transition from below) 5) OB DISCHRG ==> FSD OB DISCHRG LB followed by proper shutdown In

Hello joão, To get more responses you should plaintext email (standard for open source development mailing lists) instead of HTML mail. >The UPS I am developing a driver to is able to report several flags for critical hardware conditions, like overheat, overload, inverter failure, output short etc. What should be the correct policy of operation >when such a condition occurs? I think that

Hello, I am developing a new NUT driver for brazilian UPS brand "Ragtech" by reverse engeneering. I have never been involved in NUT driver development, so I wish to ask some basic questions. Any help will be much appreciated! 1. Is there a mandatory C code style? I mean, any strong recommendation? If there are none, I prefer to keep mine. 2. What are the purposes of "instant

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

Can one have a single UPS powering multiple servers and have them all shutdown in an orderly fashion pending a power loss? It seems as though this is possible from what I gathered from the docs, but I've yet to make this work on an OpenBSD and FreeNAS machine that are powered from the same UPS. The master server that the UPS is connected to via USB receives messages from the UPS, but

An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200217/b486de30/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: usbhid.zip Type: application/zip Size: 4031 bytes Desc: not available URL:

Arnaud, > first, even if your battery is full, and your ups is online, there is a > small amount of power drawn. So having always is CHRG status is normal. > In fact, these complementary status are more interesting for higher end > UPSs. > > second, these status need not to be handled like LB, as each one clears the > other. While LB had no pending event (!LB) before... >

First of all, please forgive me is this question has already been covered in these mailing lists; the "Search mailing list" link is dead, and I've only read the most recent monthly archives. I often have a situation where, for one of many possible reasons, the UPS always thinks that its battery is critical. And I'm even fine with a situation when it's an emergency

On 23/06/14 04:32, Stan Gammons wrote: > Can one have a single UPS powering multiple servers and have them all > shutdown in an orderly fashion pending a power loss? It seems as > though this is possible from what I gathered from the docs, but I've yet > to make this work on an OpenBSD and FreeNAS machine that are powered > from the same UPS. The master server that the UPS

hi: my testing server has two power supply and attach to two ups. one of the ups is connect to the server with usb. my upsmon.conf like below: # for two ups MONITOR ftups at localhost 1 monmaster nutmaster master MONITOR ftups at 10.1.1.2 1 monslave nutslave slave MINSUPPLIES 1 # for early shutdown NOTIFYFLAG ONBATT EXEC+WALL+SYSLOG NOTIFYFLAG ONLINE EXEC+WALL+SYSLOG NOTIFYCMD

I have the latest version of the Windows port of NUT installed on my Windows?7?machine. The UPS is connected via serial cable to the Windows machine. I also have my Synology NAS (which uses NUT) connected over the local network as a slave to the Windows NUT master. The Synology slave is configured to immediately go into "safe mode" whenever an FSD or OB+LB indication is received from the

>> But I noticed two other details: >> 1. I was a bit wrong with step 7 and 8 - Looks like the UPS is "OL CHRG" (according to display) at first but goes to battery ("OL DISCHRG" according to nut) right when the RasPi (and nut) is booting. >> 2. When I pull the plug of the RasPi after UPS went down before main power comes back (so between step 5 and 6), the UPS

On Sat, Jun 27, 2020, at 23:11, Manuel Wolfshant wrote: > On 6/28/20 5:54 AM, Scott Colby wrote: >> >> I'm not convinced this is the problem; I think that pfSense has an alternative way of running the NUT components: # ps aux | grep ups root 45456 0.0 0.1 6796 884 - Is 02:22 0:00.01 /usr/local/sbin/upsmon uucp 45751 0.0 0.1 6796 772 - S 02:22

One disadvantage of handling it through a script is that is will not be done by default. Most users probably don't know about the problem of burning batteries, as it is not very common. A potential problem with Eric Wilde's patch is that it is not general enough; some UPS models have an boolean OVERHEAT flag although they don't report the actual temperature. So the UPSOVERTEMP

Hi, this does sound like a useful idea - although for the principle of least surprise and for variation in deployments, I'd rather have it as a (non-default state of a) configuration toggle that can be set via `upsmon.conf`: whether this particular client exits after processing FSD or not. The onus for the rest would be on general systems integration - e.g. ensure that init scripts `K*`ill the

fredag 27 oktober 2023 20:07:58 CET skrev Jim Klimov: > Hi, this does sound like a useful idea - although for the principle of > least surprise and for variation in deployments, I'd rather have it as a > (non-default state of a) configuration toggle that can be set via > `upsmon.conf`: whether this particular client exits after processing FSD or > not. The onus for the rest