similar to: System with MGE UPS shuts down too early

On January 11, 2020 1:18:27 PM GMT+02:00, "Georgi D. Sotirov" <gdsotirov at gmail.com> wrote: >Hello, > >I'm experiencing a strange early shutdown behavior with the following >system: > > * */OS/*: Slackware Linux 14.2 x86_64 > * */NUT/*: 2.7.4 (from my own package > <https://sotirov-bg.net/slackpack/pack.cgi?id=4083>) > * */UPS/*: MGE

On January 11, 2020 3:42:15 PM GMT+02:00, Roger Price <roger at rogerprice.org> wrote: >On Sat, 11 Jan 2020, Georgi D. Sotirov wrote: > >> Jan 11 11:49:15 sotirov-bg upsmon[2677]: UPS mgeups at localhost on >battery >> Jan 11 11:49:15 sotirov-bg upssched[29746]: Executing command: >ups-on-battery >> Jan 11 11:49:15 sotirov-bg upssched-cmd: Unrecognized command:

On 1/25/20 10:53 AM, Georgi D. Sotirov wrote: > OK, so yesterday evening I done a real test cutting of the power to > the UPS. And it went good... the UPS supported my server for 28:50 > minutes (i.e. the expected runtime with this load), before forcing > shutdown. The batteries could still hold as charge was 30 % with about > 15 minutes run time. And the UPS did hold for

On January 24, 2020 6:13:31 PM GMT+02:00, "Georgi D. Sotirov" <gdsotirov at gmail.com> wrote: >OK, my UPS turned out to be older that I thought. I apparently bought >and installed it in September 2016 (not 2017 as I initially wrote). >That >makes for over 3 years of work, which is over the life expectancy of >the >batteries, Good batteries can last 4-5 years.

Roger, here is my output of ps -elf |grep upssched root at nutpi:~# ps -elf |grep upssched 0 S root 1242 1191 0 80 0 - 1834 pipe_w 05:23 pts/0 00:00:00 grep upssched No timer, just the grep of upssched.. On Mon, Jan 27, 2020 at 4:27 AM <nut-upsuser-request at alioth-lists.debian.net> wrote: > Send Nut-upsuser mailing list submissions to >

On Sat, 11 Jan 2020, Georgi D. Sotirov wrote: > Jan 11 11:49:15 sotirov-bg upsmon[2677]: UPS mgeups at localhost on battery > Jan 11 11:49:15 sotirov-bg upssched[29746]: Executing command: ups-on-battery > Jan 11 11:49:15 sotirov-bg upssched-cmd: Unrecognized command: ups-on-battery These lines say that you have something like AT ONBATT mgeups at localhost EXECUTE ups-on-battery

On Fri, 14 Aug 2020, Todd Benivegna wrote: > https://forum.synology.com/enu/viewtopic.php?f=19&t=73960&hilit=ups+slave  > > I have the latest version of the Windows port of NUT (A UPS management package) installed on my Windows 7 machine. The UPS I am using is a > very old APC BK650M which is controlled and sends its status via a special serial cable to the Windows

I've setup nas4free (latest version 11.0.0.4, which has NUT 2.7.4) in a VM and configured it via webinterface to my APC UPS and set "shutdown mode" to "UPS goes on battery" with a timer of 30s. Then I started runtime calibration on the UPS and after 30s nas4free has shut down! I think this is not the correct behavior, since the status was "OB CAL". The system

Thanks Larry, no problem. I appreciate the input. Whenever you get a chance I’d really like to compare notes with someone who has NUT and a Synology to see why the heck mine doesn’t work! ;). I’m also using my Pi as the master like you. Thanks. Todd -- Todd Benivegna // todd at benivegna.com On Aug 14, 2020, 11:55 AM -0400, Larry Fahnoe <fahnoe at fahnoetech.com>, wrote: > On Fri, Aug

On Jun 8, 2019, at 4:16 PM, Roger Price wrote: > > Is your System Shutdown Plan to shut down using upsmon or using the script upsched-cmd? In upssched.conf you do not have a line > > AT LOWBATT ups at ... EXECUTE lowbatt > > and in upssched-cmd there is nothing to shut down the system. Joe, Roger has a good point - the SHUTDOWNCMD should work as long as the master system

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

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

Hi, recently I observed that during a power outage, my NUT setup doesn't shutdown properly. Indeed it never reaches the LowBattery state to notify and initiate shutdown on clients. Reviewing my setup and logs I think I'm facing multiple problems and I'm unable to point to real root cause. First, let me focus on my scenario and current setup: In normal status (ONLINE, fully charged)

Hello, 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 system shutdown should be called. However, the developer's manual and

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

Dear list, Can't make upssched notify me on event occured. OS: Debian, 2.6.26-1-amd64 Nut: 2.4.3-1.1squeeze1 UPS: Ippon Smart Winner 3000 connected via COM On event ( plug out the cord from UPS ) upsmon detect's status change to OB and gives WALL and syslog notify, but no script starting. In syslog no errors and no upssched process occured, just upsmon. There're no PIPE and LOCK

Dear List, I thought it might be useful if I wrote up my notes on getting an MGE UPS to work with NUT and openSUSE. The MGE UPS (an Ellipse 1500 USB) will work well with NUT and openSUSE 10.2, but not "out-of-the-box": there are some things you need to do: Intro. MGE have built rpms of NUT which greatly simplify installation. Merci MGE. I used the rpm's for nut-2.0.5 and the

Hello. I sometimes encountered batteries that were ok, but at times one of the cells would develop a random short/open, therefore reducing the real capacity even if voltage reading was ok. In the absence of a battery load tester i would suggest running multiple tests with a load (car headlight bulb or similar) on the battery outside the ups. This is to eliminate the suspicion of a software or UPS

OK, so yesterday evening I done a real test cutting of the power to the UPS. And it went good... the UPS supported my server for 28:50 minutes (i.e. the expected runtime with this load), before forcing shutdown. The batteries could still hold as charge was 30 % with about 15 minutes run time. And the UPS did hold for another full 10 minutes before powering off. These are the relevant lines

Hi, I have been running nut successfully for a long time with my Debian 11 server. I upgraded my server to Debian 12 today, which upgraded nut also from 2.7.4-13 to 2.8.0-7. I noticed that after upgrade there was a upssched process running and taking 100% cpu time. I checked if there were any changes to configuration file formats with nut upgrade and only differences I noticed were a terminology