Synology als NUT-server meldet Lowbatt

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

4--motion

Benutzer
Registriert
28. Juni 2009
Beiträge
11
Reaktionspunkte
0
Punkte
1
Hallo,

ich habe ein Problem mit der Synology DS 720+. An diese ist per USB eine USV angeschlossen und der NUT-Dienst aktiviert. Die Kombi DS720 und USV arbeitet einwandfrei zusammen, d.h., in der DSM sehe ich die USV, den Ladezustand und die ca. Batterielaufzeit. Der Ladezustand ist zwischen 99 und 100%.
Als NUT-Client ist eine Raspberrymatic mit Homematic angeschlossen. Nun meldet die Synology in unregelmäßigen, aber kurzen Abständen (zwischen 20 Minuten und 2 Stunden) , dass die USV geringe Batteriekapazität hat (LOWBATT). Das löst in meiner Homematic einen Alarm aus. Wenn ich in die DSM schaue, ist die Batteriekapazität aber voll geladen.

Kann mir da jemand weiterhelfen, woran das liegen kann?

Danke und viele Grüße

4--motion
 
Ich nutze meine Synology auch als USV Server und meinen Proxmox als NUT Client. Vielleicht schaust du mal die Batterien an. Wie lange sind die schon drin? Nicht das dennoch die Spannung recht schnell abfällt, wenn Last drauf ist? Oder ggf. mal die NUT Client config posten, nicht das hier evtl. ein anderer Zeitwert drin steht. Ist sonst noch was an der USV (welche?)?
 
vielen Dank für die Info. Die ganze USV ist nagelneu Mitte Januar 2025 reingekommen. Es ist eine APC Back UPS 750.

Wenn die Synology "LOWBATT" meldet, könnte es sein, dass so eine Meldung auch in einem LOG der Synology abgespeichert wird und wenn ja, wo?

Hier ist die NUT.conf auf dem Raspi.


# Network UPS Tools: example nut.conf
#
##############################################################################
# General section
##############################################################################
# The MODE determines which part of the NUT is to be started, and which
# configuration files must be modified.
#
# The values of MODE can be:
# - none: NUT is not configured, or use the Integrated Power Management, or use
# some external system to startup NUT components. So nothing is to be started.
# - standalone: This mode address a local only configuration, with 1 UPS
# protecting the local system. This implies to start the 3 NUT layers (driver,
# upsd and upsmon) and the matching configuration files. This mode can also
# address UPS redundancy.
# - netserver: same as for the standalone configuration, but also need
# some more network access controls (firewall, tcp-wrappers) and possibly a
# specific LISTEN directive in upsd.conf.
# Since this MODE is opened to the network, a special care should be applied
# to security concerns.
# - netclient: this mode only requires upsmon.
#
MODE=netclient
 
Ich habe folgende Dateien auf meinem Proxmox angepasst:

upsmon_conf
upssched_cmd
upssched_conf

Oben ist ja alles aus kommentiert, außer MODE=netclient. Da ist ja gar nichts festgelegt, oder?
 
In der upsmon.conf habe ich anfangs gar nichts geändert (war die Anleitung für Rsapberrymatic).
Jetzt habe ich allerdings die Zeile mit dem "LOWBATT" auskommentiert, weil mich der Alarm auf dem Raspi nervt. Ich weiß, dass das nur ein Taschentuch ist, also nur die Symptome bekämpft und nicht die Ursache. Die möchte ich aber gerne finden.

upsmon.conf
MONITOR ups@192.xxx.xxx.xxx 1 monuser secret slave
MINSUPPLIES 1
SHUTDOWNCMD /sbin/poweroff
NOTIFYCMD /etc/config/nut/nut_notify.sh
POLLFREQ 10
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /var/tmp/killpower
NOTIFYFLAG ONLINE SYSLOG+EXEC
NOTIFYFLAG ONBATT SYSLOG+EXEC
# NOTIFYFLAG LOWBATT SYSLOG+EXEC
NOTIFYFLAG FSD SYSLOG+EXEC
NOTIFYFLAG COMMOK SYSLOG+EXEC
NOTIFYFLAG COMMBAD SYSLOG+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+EXEC
NOTIFYFLAG REPLBATT SYSLOG+EXEC
NOTIFYFLAG NOCOMM SYSLOG+EXEC
NOTIFYFLAG NOPARENT SYSLOG+EXEC
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5


In der upssched.conf habe ich lt. Anleitung nichts geändert. Hier ist auch alles auskommentiert, bis auf die CMD-Zeile.

upssched.conf

# Network UPS Tools - upssched.conf sample file
#
# ============================================================================
#
# CMDSCRIPT <scriptname>
#
# This script gets called to invoke commands for timers that trigger.
# It is given a single argument - the <timername> in your
# AT ... START-TIMER defines.
#
# *** This must be defined *before* the first AT line. Otherwise the
# program will complain and exit without doing anything.
#
# A shell script with a big case..esac construct should work nicely for this.
# An example has been provided to help you get started.

CMDSCRIPT /usr/bin/upssched-cmd

# ============================================================================
#
# PIPEFN <filename>
#
# This sets the file name of the FIFO that will pass communications between
# processes to start and stop timers. This should be set to some path where
# normal users can't create the file, due to the possibility of symlinking
# and other evil.
#
# Note: if you are running Solaris or similar, the permissions that
# upssched sets on this file *are not enough* to keep you safe. If
# your OS ignores the permissions on a FIFO, then you MUST put this in
# a protected directory!
#
# Note 2: by default, upsmon will run upssched as whatever user you have
# defined with RUN_AS_USER in upsmon.conf. Make sure that user can
# create files and write to files in the path you use for PIPEFN and
# LOCKFN.
#
# My recommendation: create a special directory for upssched, make it
# owned by your upsmon user, then use it for both.
#
# This is commented out by default to make you visit this file and think
# about how your system works before potentially opening a hole.
#
# PIPEFN /var/state/ups/upssched/upssched.pipe

# ============================================================================
#
# LOCKFN <filename>
#
# REQUIRED. This was added after version 1.2.1.
#
# upssched needs to be able to create this filename in order to avoid
# a race condition when two events are dispatched from upsmon at nearly
# the same time. This file will only exist briefly. It must not be
# created by any other process.
#
# You should put this in the same directory as PIPEFN.
#
# LOCKFN /var/state/ups/upssched/upssched.lock

# ============================================================================
#
# AT <notifytype> <upsname> <command>
#
# Define a handler for a specific event <notifytype> on UPS <upsname>.
#
# <upsname> can be the special value * to apply this handler to every
# possible value of <upsname>.
#
# Run the command <command> via your CMDSCRIPT when it happens.
#
# Note that any AT that matches both the <notifytype> and the <upsname>
# for the current event will be used.

# ============================================================================
#
# Possible AT commands
#
# - START-TIMER <timername> <interval>
#
# Start a timer called <timername> that will trigger after <interval>
# seconds, calling your CMDSCRIPT with <timername> as the first
# argument.
#
# Example:
# Start a timer that'll execute when any UPS (*) has been gone 10 seconds
#
# AT COMMBAD * START-TIMER upsgone 10

# -----------------------------------------------------------------------
#
# - CANCEL-TIMER <timername> [cmd]
#
# Cancel a running timer called <timername>, if possible. If the timer
# has passed then pass the optional argument <cmd> to CMDSCRIPT.
#
# Example:
# If a specific UPS (myups@localhost) comes back online, then stop the
# timer before it triggers
#
# AT COMMOK myups@localhost CANCEL-TIMER upsgone

# -----------------------------------------------------------------------
#
# - EXECUTE <command>
#
# Immediately pass <command> as an argument to CMDSCRIPT.
#
# Example:
# If any UPS (*) reverts to utility power, then execute
# 'ups-back-on-line' via CMDSCRIPT.
#
# AT ONLINE * EXECUTE ups-back-on-line


Auch in der upssched-cmd habe ich nichts geändert:


#! /bin/sh
#
# This script should be called by upssched via the CMDSCRIPT directive.
#
# Here is a quick example to show how to handle a bunch of possible
# timer names with the help of the case structure.
#
# This script may be replaced with another program without harm.
#
# The first argument passed to your CMDSCRIPT is the name of the timer
# from your AT lines.

case $1 in
onbattwarn)
# Send a notification mail
echo "The UPS has been on battery for awhile" \
| mail -s"UPS monitor" bofh@pager.example.com
# Create a flag-file on the filesystem, for your own processing
/usr/bin/touch /some/path/ups-on-battery
;;
ups-back-on-power)
# Delete the flag-file on the filesystem
/bin/rm -f /some/path/ups-on-battery
;;
upsgone)
logger -t upssched-cmd "The communication with UPS has been gone for awhile"
;;
*)
logger -t upssched-cmd "Unrecognized command: $1"
;;
esac

Danke für die Hilfe
 
Hallo,
siehe Beitrag #3.

Gruß Götz
 
Es ist eine APC Back UPS 750
@goetz: Ja, ich hatte es schon geschrieben. Ist aber kein Problem. Ich überlese auch manchmal Dinge.
@Ronny1978: Nochmal danke für die Hilfe. Ich werde mich in die beiden Links mal einlesen, komme aber nicht gleich dazu. Wo könnte ich denn in der DS nachschauen, um den Fehler nachzuvollziehen? Die Auswirkung der Meldung bekomme ich ja erst auf meiner Homematic zu spüren. Interessant wäre in der Tat, wo die Meldung generiert wird. Meldet die USV schon "LOWBATT" an die Synology und die gibt es nur weiter? Oder erzeugt die Synology die Meldung, ohne dass die USV etwas meldet? Wie kann man das herausfinden?
 
Achso, ob ich die DS neu gestartet hatte, kann ich nicht mehr sagen. Ich mache jetzt gerade mal einen Neustart und mal sehen, ob sich etwas ändert. Ich berichte wieder.
 
Also, der Neustart der DS hat nichts gebracht. Es kamen wieder "LOWBATT"-Meldungen. Die beiden Links haben leider auch nicht weitergeholfen. Ich habe jetz erst einmal wieder die "LOWBATT"-Zeile in der upsmon.conf auskommentiert. Vielleicht hat ja noch einer eine Idee, wer die Meldung erzeugt.
Viele Grüße
 
Eigentlich solltest du im Protokollcenter der Synology Meldungen finden wenn die USV sich meldet.
Ich habe bei mir Librenms als Docker laufen, das überwacht u.a. auch meine USV (Eaton) per SNMP Ladezustand,Spannung,Last.
Ist das USB-Kabel direkt angeschlossen oder hast du ein USB-HUB o.ä. dazwischen ?
 
  • Like
Reaktionen: plang.pl
Aber heißt "battery needs to be replaced" nicht Austausch? Vielleicht stimmt ja was mit der Batterie nicht?
 
Hab die USV lt. Anleitung einen Selbsttest machen lassen. Alles o.k. Dann habe ich den Stecker gezogen. DIe USV hat nach einer knappen Stunde die Synology und den Raspi runtergefahren. Also auch hier alles, so wie es sein soll.
Was mich an den Meldungen im Protokollcenter wundert, ist der Eintrag unter "Host" als "Raspberrymatic". Seit ich in der upsmon.conf bei "LOWBATT" das "+EXEC" entfernt habe, gibt es im Protokollcenter der Synology keinen Eintrag mehr und auch im Raspi keinen Alarm mehr. Die upsmon.conf auf dem Raspi hat ja eigentllich keinen Einfluss auf die Verbindung USV zur Synology. Ich denke eher, dass dieser Eintrag im Protokollcenter der Synology vom Raspi an die Synolgy gegeben wird. Es gibt ja auch andere EInträge vom Raspi im Protokollcenter der Synology. Warum allerdings der Raspi eine "LOWBATT"-Meldung von der Synology bekommt, bleibt ein Rätsel. Eigentlich müsste ja im Prokollcenter der Synology zuerst ein Eintrag stehen, dass die USV "LOWBATT" an die Synology meldet. Und die Synology müsste dann als NUT-Server diese Meldung an den angeschlossenen NUT-Client "Raspi" geben. Vielleicht hat ja noch jemand eine Idee. Vielen Dank jedenfalls schonmal an die guten Hinweise und Überlegungen.
 
MONITOR ups@192.xxx.xxx.xxx 1 monuser secret slave
Ich denke da müsste stehen MONITOR ups@192.xxx.xxx.xxx 1 upsmon secret slave

Generell würde ich dir bei dem Setup empfehlen, den USV-Server lieber auf den Raspberrymatic zu verlegen. Die Synology dann als Client anbinden. Andersherum hatte ich es in der Vergangenheit auch versucht und dabei habe ich ähnliche Erfahrungen gemacht. Du kannst die USV dann sogar per SNMP exposen und eine kleine Web-UI drüberlegen. Hab mich da entlanggehangelt: https://technotim.live/posts/NUT-server-guide/#nut-ups-server
APC Back UPS 750.
Mit der solltest du auch einen Selbsttest der USV über den NUT-Server auf dem Raspberrymatic triggern können: upscmd -u upsmon -p secret ups@localhost test.battery.start.deep für einen erweiterten Test und upscmd -u upsmon -p secret ups@localhost test.battery.start.quick für einen Schnelltest. Kann man dann auch per cron automatisieren.
 
  • Like
Reaktionen: ctrlaltdelete
Generell würde ich dir bei dem Setup empfehlen, den USV-Server lieber auf den Raspberrymatic zu verlegen
Naja, ich fahre das Setup Synology als USV Server -> Proxmox als USV Client seit 2 Jahren und hatte bis jetzt keine Probleme. Aber es gibt je verschiedene Wege ;-)
 
Ja, die gibt es :)
Ich habe es bei mir dann auf dem Linux-Server gelassen und nicht mehr auf der DS versucht, weil ich für mich folgende Vorteile gesehen hab:
-mehr Möglichkeiten bezüglich USV-Steuerung
-leichtere Integration mit ansible / gotify
-leichteres Monitoring mit Prometheus / grafana (könnte vielleicht auf der DS genauso gut gehen)
-freigeben der USV per SNMP
Man kann nicht verleugnen, dass der Weg m.E. der Weg aufwändiger ist als der mit der DS als Server.
 
  • Like
Reaktionen: Ronny1978
Danke für deine Hinweise. Soweit "ran gewagt" habe ich mich noch nicht. Ich glaube auch, ich benötige die Funktionen auch nicht wirklich. Für mich reicht die DS als USV Server und der Proxmox als Client, sodass Proxmox alles ordentlich beenden kann. Per Home Assistant und der NUT Integration habe ich auch verschiedene Werte der USV die ich (optisch) auswerten kann, was wahrscheinlich Grafana schon recht nahe kommt. Dabei lasse ich Home Assistant schon selbstständig herunterfahren, wenn die USV auf Batterie Betrieb geht, bevor Proxmox den Befehl gibt. Ich hatte bei einem einstündigen Stromausfall nachts nämlich das Problem, dass Proxmox fast alle Maschinen heruntergefahren hat, aber sich am HA "verschluckt" hatte. Problem: Plötzlich gingen die Lichter im Schlafzimmer an und nicht wieder aus, weil HA im "Notfallmodus" war. Meine Frau war "not amused", als nachts 3 Uhr das Schlafzimmer beleuchtet war. 🤣

Aber wie du es schon gesagt hast:
der Weg aufwändiger ist als der mit der DS als Server
Und man wahrscheinlich etwas mehr Linuxkenntnisse benötigt. Aber jedem seinen Weg...
 
  • Like
Reaktionen: plang.pl

Additional post fields

 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat