Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[crunchip]

@segway sagte in [gelöst] USV an Proxmox in LXC durchreichen:

separate CT mit einem nut client laufen

Für was?, es reicht doch server und client direkt auf dem host, proxmox fährt dann bei bedarf runter

[Segway]

@crunchip sagte in [gelöst] USV an Proxmox in LXC durchreichen:

Für was?, es reicht doch server und client direkt auf dem host, proxmox fährt dann bei bedarf runter

Siehe hier :point_down:

@segway sagte in [gelöst] USV an Proxmox in LXC durchreichen:

• separate CT mit einem nut client laufen lassen sowie der Gui /Cgi für Browser

[lessthanmore]

@segway Wieso einen Client? Wirst du das nicht über den iob - Adapter machen?
Bei mir läuft der nut server auf dem proxmox host und im iob der Adapter. Zusammen mit dem proxmox Adapter kann ich dann alles sicher runterfahren und monitoren.

[David G.]

@lessthanmore

Über den Client ist der normale Weg.
Falls der iob warum auch immer mal nicht läuft.
Zudem hat ja nicht jeder der Proxmox und eine USV nutzt iobroker am laufen.

Ich mache es aber auch wie du.

[Segway]

@david-g & @lessthanmore
So habe jetzt auf dem PVE-Master den nut server installiert und konfiguriert. Läuft soweit !
Adapter auch installiert und verbindet sich einwandfrei.

Die Hui vom Nut hatte den Vorteil dasss eine fertige Browseroberfläche schon aufrufbar ist. Ich müsste jetzt eine neue Oberfläche in Grafana oder vis erstellen. Habt ihr da eine Vorlage ? Muss ja nicht alles neu erfinden !

Ergänzend noch die Frage:
In der Gui habe ich immer ein Textfeld gehabt, wo die Meldungen standen wann die UPS keinen Strom hatte usw. Wird das auch irgendwo in eine Datenpunkt gespeichert ?

[crunchip]

@segway sagte in [gelöst] USV an Proxmox in LXC durchreichen:

in Grafana

Gibt es schon mehrere Beispiel Dashboards

[Wildbill]

@segway Die Frage von mir wäre jetzt, wofür Du das überhaupt brauchst?! Die USV hat den Auftrag, den Rechner sauber runterzufahren, wenn der Strom weg ist und die Batterie knapp wird. Nicht mehr und nicht weniger. Was braucht es da eine GUI? Wenn ich ab und an mal schauen will, wie es um die USV/Batterie steht, so schaue ich direkt auf den Proxmox-Hosts per

upsc ups

und bekomme die Daten oder ich schaue im iobroker bei den Objekten der Nut-Adapter (für jeden Host einen). Das mache ich eigentlich genau einmal im Monat, nämlich wenn ich den USV-Test durchführe. Sonst sind mir die Werte ziemlich egal.
Wenn Du bestimmte Werte im Auge behalten willst, so würde ich eher history oder influx im iobroker auf diese Werte ansetzen und tracken lassen. Dann hast Du auch eine Historie, was so passiert ist. Aber eine Browser-GUI für sowas wie Nut/USV? Das ist ja fast wie iorboker unter Windows aufsetzen, Hauptsache man hat was zum Klicken… :blush:

Gruss, Jürgen

[lessthanmore]

@segway said in [gelöst] USV an Proxmox in LXC durchreichen:

Habt ihr da eine Vorlage ?

Unzählige. Einfach bei google grafana und nut eingeben.

Es gibt den Datenpunkt unter status "onbattery". Der geht auf true sobald der Strom weg ist.
Ich kenne die Gui nicht, weiß also nicht was du mit Textfeld meinst.

[Segway]

@wildbill
Das sehe ich komplett anders und hat mir vor 6 Jahren auch geholfen.

Dort gab es bei mir in der Strasse einen (heftigen) Stromausfall und beim Zuschalten meiner Stadtwerke hat es meine Alarmanlage zerschossen ! Bei fast allen anderen war die Fritz!Box durchgeknallt.
Zumindest damals gab mir das Stromunternehmen den Hinweis, dass die Beweislast (leider) bei mir liegt.
Ich habe dann damals durch das apcusvd.log nachweisen können, wann der Strom weg war und wieder zugeschaltet wurde (also wann mein System auf USV lief und wann nichtmehr).
Dieses Log wurde vom Stromunternehmen akzeptiert und ich musste eine Schadensanzeige ausfüllen mit dem Log als attachment und habe die nur Platine ersetzt bekommen.

Ergo, ist es mir persönlich wichtig diese Daten zu haben. Das ganze läuft halt jetzt nicht mehr per apcusvd sondern über NUT. Daher möchte ich auf jeden Fall dieses Log wieder haben falls sowas nochmal passiert.

Ich habe es noch nicht gefunden und befürchte, dass nut einfach ins rsyslog schreibt mit nut.
Das wäre nicht so schön.

Daher sind mir persönlich die Daten wichtig und ich möchte sie sehen und nicht immer per Konsole mir alles herfuckeln. Wie ich das machen muss hab ich in 2 Monaten eh wieder vergessen. Daher die GUI.
Das mal so als Erklärung.

Ergänzung:
apcupsd hat immer separat alles in apcupsd.events geschrieben. Dies konnte ich immer gut verwenden.

Hatte jetzt für NUT was gefunden, wo man anscheinend alle Meldungen von NUT in ein separates file schreiben kann. Da kenne ich mich aber nullkommanull aus.
Sähe so aus - war für Ubuntu 18 (aus 2019) :

The default system logger is rsyslog. Add the following to /etc/rsyslog.d/99-nut.conf

:syslogtag,contains,"upsmon" /var/log/nut.log
:syslogtag,contains,"nut" /var/log/nut.log
:syslogtag,contains,"upssched" /var/log/nut.log

touch /var/log/nut.log
chown syslog:adm /var/log/nut.log
chmod 640 /var/log/nut.log
systemctl restart rsyslog

[wendy2702]

Der Beitrag ist zwar schon älter aber ich Frage trotzdem mal hier:

Wenn ich das richtig zusammenfasse:

USV an Proxmox PVE anschließen --> USV an Proxmox durchreichen oder nicht !?
NUT Server auf PVE installieren
NUT Client auf PVE installieren !?
NUT Adapter in iobroker installieren und auf PVE konfigurieren
Logik für shutdown Geräte X in iobroker konfigurieren

Stimmt das so im groben?

[David G.]

@wendy2702

Ich hab die usb am Server stecken und dort auch den Nut Server installiert.
So fährt das System sauber runter. Proxmox fährt dann sauber alle VMs sauber runter.
Der iobroker kann sich per nut auch verbinden und alle Daten abrufen für vis etc.

[wendy2702]

Hast du auch einen NUT client auf dem Server installiert?

Und du hast nichts in die IOB CT oder VM durchgereicht wenn ich das richtig verstehe.

[David G.]

@wendy2702

Ja, am Host nur den Server laufen. An nichts durchgereicht.
Der Nut Adapter kann sich zum nut Server verbinden.

[wendy2702]

Magst du bei Gelegenheit mal deine Konfig files zeigen?

Hat aber keine Eile.

[David G.]

@wendy2702

nut.conf

# 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.
#
# This file try to standardize the various files being found in the field, like
# /etc/default/nut on Debian based systems, /etc/sysconfig/ups on RedHat based
# systems, ... Distribution's init script should source this file to see which
# component(s) has to be started.
#
# 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.
#
# IMPORTANT NOTE:
#  This file is intended to be sourced by standard POSIX shell scripts (so
#  there is no guaranteed `export VAR=VAL` syntax) and by systemd on Linux.
#  You MUST NOT use spaces around the equal sign!

MODE=netserver

# Uncomment this to allow starting the service even if ups.conf has no device
# sections at the moment. This environment variable overrides the built-in
# "false" and an optional same-named default flag that can be set in upsd.conf:
#ALLOW_NO_DEVICE=true
#export ALLOW_NO_DEVICE

ups.conf

# Network UPS Tools: example ups.conf
#
# --- SECURITY NOTE ---
#
# If you use snmp-ups and set a community string in here, you
# will have to secure this file to keep other users from obtaining
# that string.  It needs to be readable by upsdrvctl and any drivers,
# and by upsd.
#
# ---
#
# This is where you configure all the UPSes that this system will be
# monitoring directly.  These are usually attached to serial ports, but
# USB devices and SNMP devices are also supported.
#
# This file is used by upsdrvctl to start and stop your driver(s), and
# is also used by upsd to determine which drivers to monitor.  The
# drivers themselves also read this file for configuration directives.
#
# The general form is:
#
# [upsname]
#       driver = <drivername>
#         port = <portname>
#       < any other directives here >
#
# The section header ([upsname]) can be just about anything as long as
# it is a single word inside brackets.  upsd uses this to uniquely
# identify a UPS on this system.
#
# If you have a UPS called snoopy, your section header would be "[snoopy]".
# On a system called "doghouse", the line in your upsmon.conf to monitor
# and manage it would look something like this:
#
#   MONITOR snoopy@doghouse 1 upsmonuser mypassword primary
#
# It might look like this if monitoring in "secondary" mode (without any
# ability to directly manage the UPS) from a different system:
#
#   MONITOR snoopy@doghouse 1 upsmonuser mypassword secondary
#
# Configuration directives
# ------------------------
#
# These directives are used by upsdrvctl only and should be specified outside
# of a driver definition:
#
#    maxretry: OPTIONAL.  Specify the number of attempts to start the driver(s),
#              in case of failure, before giving up. A delay of 'retrydelay' is
#              inserted between each attempt. Caution should be taken when using
#              this option, since it can impact the time taken by your system to
#              start.
#
#              The built-in default is 1 attempt.
#
#  retrydelay: OPTIONAL.  Specify the delay between each restart attempt of the
#              driver(s), as specified by 'maxretry'. Caution should be taken
#              when using this option, since it can impact the time taken by your
#              system to start.
#
#              The default is 5 seconds.
#
#      chroot: OPTIONAL. Used for securing. See man page for details.
#
#  driverpath: OPTIONAL. Used for custom setups. See man page for details.
#
#      nowait: OPTIONAL. Tell upsdrvctl to not wait at all for the driver(s)
#              to execute the requested command. Fire and forget.
#
# pollinterval: OPTIONAL. The status of the UPS will be refreshed after a
#              maximum delay which is controlled by this setting (default
#              2 seconds). This may be useful if the driver is creating too
#              much of a load on your system or network.
#              Note that some drivers also have an option called *pollfreq*
#              which controls how frequently some of the less critical
#              parameters are polled. See respective driver man pages.
#

# Set maxretry to 3 by default, this should mitigate race with slow devices:
maxretry = 3

# These directives can be set outside and inside a driver definition, with
# slightly different meanings per context:
#
# maxstartdelay: OPTIONAL.  This can be set as a global variable
#                above your first UPS definition and it can also be
#                set in a UPS section.  This value controls how long
#                upsdrvctl will wait for the driver to finish starting.
#                This keeps your system from getting stuck due to a
#                broken driver or UPS.
#                The default is 45 seconds.
#
#   debug_min: OPTIONAL.  Specify a minimum debug level for all driver daemons
#              (when specified at global level), or for this driver daemon
#              (when specified in a driver section), e.g. for troubleshooting
#              a deployment. This does not directly impact the foreground or
#              background running mode. If both the global and driver level
#              `debug_min` are set, the driver-level setting takes precedence.
#              Command-line option `-D` can only increase this verbosity level.
#
# user, group: OPTIONAL. Overrides the compiled-in (also global-section,
#                when used in driver section) default unprivileged user/group
#                name for NUT device driver. Impacts access rights used for
#                the socket file access (group) and communication ports (user).
#
# synchronous: OPTIONAL.  The driver work by default in asynchronous
#              mode (like *no*) with fallback to synchronous if sending
#              fails (i.e *synchronous=auto*).  This means that all data
#              are pushed by the driver on the communication socket to
#              upsd (Unix socket on Unix, Named pipe on Windows) without
#              waiting for these data to be actually consumed.  With
#              some HW, such as ePDUs, that can produce a lot of data,
#              asynchronous mode may cause some congestion, resulting in
#              the socket to be full, and the driver to appear as not
#              connected.  By enabling the 'synchronous' flag
#              (value = 'yes'), the driver will wait for data to be
#              consumed by upsd, prior to publishing more.  This can be
#              enabled either globally or per driver.
#
#              The default is 'no' (i.e. asynchronous mode) for backward
#              compatibility of the driver behavior.
#

# These directives are common to all drivers that support ups.conf:
#
#  driver: REQUIRED.  Specify the program to run to talk to this UPS.
#          apcsmart, bestups, and sec are some examples.
#
#    port: REQUIRED.  The serial port where your UPS is connecte#    desc: optional, to keep a note of the UPS purpose, location, etc.
#
#  nolock: optional, and not recommended for use in this file.
#
#          If you put nolock in here, the driver will not lock the
#          serial port every time it starts.  This may allow other
#          processes to seize the port if you start more than one by
#          mistake.
#
#          This is only intended to be used on systems where locking
#          absolutely must be disabled for the software to work.
#
# ignorelb: OPTIONAL. Ignore low battery condition reported by device,
#           and evaluate remaining battery charge or runtime instead.
#           See man page for details.
#
# usb_set_altinterface(=num): OPTIONAL. Require that NUT calls this method
#           to set the interface, even if 0 (default). Some devices require
#           the call to initialize; others however can get stuck due to it -
#           so it is not called by default. Yet others can be composite
#           devices which use a non-zero interface to represent the UPS.
#
# default.<variable>: OPTIONAL. Set a default value for <variable> which is
#           used in case the UPS doesn't provide a value, but which will be
#           overwritten if a value is available from the UPS, e.g.:
#               default.input.voltage.nominal = 230
#           will report the nominal input voltage to be 230, unless the UPS
#           eventually tells us differently.
#
# override.<variable>: OPTIONAL. Set a value for <value> that overrides
#           (for NUT) any value that may be read from the UPS.
#           Used for overriding values from the UPS that are clearly wrong
#           (e.g. some devices report wrong values for battery voltage):
#               override.battery.voltage.nominal = 12
#           Use with caution!  This will only change the appearance of the
#           variable to the outside world (and NUT calculations), internally
#           in the UPS the original value is used.
#
# Anything else is passed through to the hardware-specific part of
# the driver.
#
# Examples
# --------
#
# A simple example for a UPS called "powerpal" that uses the blazer_ser
# driver on /dev/ttyS0 is:
#
# [powerpal]
#   driver = blazer_ser
#   port = /dev/ttyS0
#   desc = "Web server"
#
# If your UPS driver requires additional settings, you can specify them
# here.  For example, if it supports a setting of "1234" for the
# variable "cable", it would look like this:
#
# [myups]
#   driver = mydriver
#   port = /dev/ttyS1
#   cable = 1234
#   desc = "Something descriptive"
#
# To find out if your driver supports any extra settings, start it with
# the -h option and/or read the driver's documentation.
[ups]
        driver = "usbhid-ups"
        port = "auto"
        desc = "ups"
        pollinterval = 10
        override.battery.charge.low = 35
        override.battery.runtime.low = 600

upsd.conf

# Network UPS Tools: example upsd configuration file
#
# This file contains access control data, you should keep it secure.
#
# It should only be readable by the user that upsd becomes.  See the FAQ.
#
# Each entry below provides usage and default value.
#
# For more information, refer to upsd.conf manual page.

# =======================================================================
# MAXAGE <seconds>
# MAXAGE 15
#
# This defaults to 15 seconds.  After a UPS driver has stopped updating
# the data for this many seconds, upsd marks it stale and stops making
# that information available to clients.  After all, the only thing worse
# than no data is bad data.
#
# You should only use this if your driver has difficulties keeping
# the data fresh within the normal 15 second interval.  Watch the syslog
# for notifications from upsd about staleness.

# =======================================================================
# TRACKINGDELAY <seconds>
# TRACKINGDELAY 3600
#
# This defaults to 1 hour. When instant commands and variables setting status
# tracking is enabled, status execution information are kept during this
# amount of time, and then cleaned up.

# =======================================================================
# ALLOW_NO_DEVICE <Boolean>
# ALLOW_NO_DEVICE true
#
# Normally upsd requires that at least one device section is defined in ups.conf
# when the daemon starts, to serve its data.  For automatically managed services
# it may be preferred to have upsd always running, and reload the configuration
# when power devices become defined.
#
# Boolean values 'true', 'yes', 'on' and '1' mean that the server would not
# refuse to start with zero device sections found in ups.conf.
#
# Boolean values 'false', 'no', 'off' and '0' mean that the server should refuse
# to start if zero device sections were found in ups.conf. This is the default.

# =======================================================================
# STATEPATH <path>
# STATEPATH /var/run/nut
#
# Tell upsd to look for the driver state sockets in 'path' rather
# than the default that was compiled into the program.

# =======================================================================
# LISTEN <IP address or name> [<port>]
# LISTEN 127.0.0.1 3493
# LISTEN ::1 3493
# LISTEN myhostname 83493
# LISTEN myhostname.mydomain
#
# This defaults to the localhost listening addresses and port 3493.
# In case of IP v4 or v6 disabled kernel, only the available one will be used.
#
# You may specify each interface IP address or name that you want upsd to
# listen on for connections, optionally with a port number.
#
# You may need this if you have multiple interfaces on your machine and
# you don't want upsd to listen to all interfaces (for instance on a
# firewall, you may not want to listen to the external interface).
#
# This will only be read at startup of upsd.  If you make changes here,
# you'll need to restart upsd, reload will have no effect.

# =======================================================================
# MAXCONN <connections>
# MAXCONN 1024
#
# This defaults to maximum number allowed on your system.  Each UPS, each
# LISTEN address and each client count as one connection.  If the server
# runs out of connections, it will no longer accept new incoming client
# connections.  Only set this if you know exactly what you're doing.

# =======================================================================
# CERTFILE <certificate file>
# CERTFILE /usr/local/ups/etc/upsd.pem
#
# When compiled with SSL support with OpenSSL backend,
# you can enter the certificate file here.
# The certificates must be in PEM format and must be sorted starting with
# the subject's certificate (server certificate), followed by intermediate
# CA certificates (if applicable_ and the highest level (root) CA. It should
# end with the server key. See 'docs/security.txt' or the Security chapter of
# NUT user manual for more information on the SSL support in NUT.
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.

# =======================================================================
# CERTPATH <certificate file or directory>
# CERTPATH /usr/local/ups/etc/cert/upsd
#
# When compiled with SSL support with NSS backend,
# you can enter the certificate path here.
# Certificates are stored in a dedicated database (split into 3 files).
# Specify the path of the database directory.
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.

# =======================================================================
# CERTIDENT <certificate name> <database password>
# CERTIDENT "my nut server" "MyPasSw0rD"
#
# When compiled with SSL support with NSS backend,
# you can specify the certificate name to retrieve from database to
# authenticate itself and the password
# required to access certificate related private key.
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.

# =======================================================================
# CERTREQUEST <certificate request level>
# CERTREQUEST REQUIRE
#
# When compiled with SSL support with NSS backend and client certificate
# validation (disabled by default, see 'docs/security.txt'),
# you can specify if upsd requests or requires client's' certificates.
# Possible values are :
#  - 0 to not request to clients to provide any certificate
#  - 1 to require to all clients a certificate
#  - 2 to require to all clients a valid certificate
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.

# =======================================================================
# DISABLE_WEAK_SSL <Boolean>
# DISABLE_WEAK_SSL true
#
# Tell upsd to disable older/weak SSL/TLS protocols and ciphers.
#
# With relatively recent versions of OpenSSL or NSS it will be restricted
# to TLSv1.2 or better.
#
# Unless you have really ancient clients, you probably want to enable this.
# Currently disabled by default to ensure compatibility with existing setups.

# =======================================================================
# DEBUG_MIN <Integer>
# DEBUG_MIN 2
#.
# Optionally specify a minimum debug level for `upsd` data daemon, e.g. for
# troubleshooting a deployment, without impacting foreground or background
# running mode directly, and without need to edit init-scripts or service
# unit definitions. Note that command-line option `-D` can only increase
# this verbosity level.
#
# NOTE: if the running daemon receives a `reload` command, presence of the
# `DEBUG_MIN NUMBER` value in the configuration file can be used to tune
# debugging verbosity in the running service daemon (it is recommended to
# comment it away or set the minimum to explicit zero when done, to avoid
# huge journals and I/O system abuse). Keep in mind that for this run-time
# tuning, the `DEBUG_MIN` value *present* in *reloaded* configuration files
# is applied instantly and overrides any previously set value, from file
# or CLI options, regardless of older logging level being higher or lower
# than the newly found number; a missing (or commented away) value however
# does not change the previously active logging verbosity.
LISTEN 0.0.0.0 3493
LISTEN 192.168.99.33 3493
LISTEN 192.168.99.58 3493

upsd.users

# Network UPS Tools: Example upsd.users
#
# This file sets the permissions for upsd - the UPS network daemon.
# Users are defined here, are given passwords, and their privileges are
# controlled here too.  Since this file will contain passwords, keep it
# secure, with only enough permissions for upsd to read it.

# --------------------------------------------------------------------------

# Each user gets a section.  To start a section, put the username in
# brackets on a line by itself.  To set something for that user, specify
# it under that section heading.  The username is case-sensitive, so
# admin and AdMiN are two different users.
#
# Possible settings:
#
# password: The user's password.  This is case-sensitive.
#
# --------------------------------------------------------------------------
#
# actions: Let the user do certain things with upsd.
#
# Valid actions are:
#
# SET   - change the value of certain variables in the UPS
# FSD   - set the "forced shutdown" flag in the UPS
#
# --------------------------------------------------------------------------
#
# instcmds: Let the user initiate specific instant commands.  Use "ALL"
# to grant all commands automatically.  There are many possible
# commands, so use 'upscmd -l' to see what your hardware supports.  Here
# are a few examples:
#
# test.panel.start      - Start a front panel test
# test.battery.start    - Start battery test
# test.battery.stop     - Stop battery test
# calibrate.start       - Start calibration
# calibrate.stop        - Stop calibration
#
# --------------------------------------------------------------------------
#
# Example:
#
#	[admin]
#		password = mypass
#		actions = SET
#		instcmds = ALL
#

#
# --- Configuring for a user who can execute tests only
#
#	[testuser]
#		password  = pass
#		instcmds  = test.battery.start
#		instcmds  = test.battery.stop

#
# --- Configuring for upsmon
#
# To add a user for your upsmon, use this example:
#
#   [upsmon]
#       password  = pass
#       upsmon primary
# or
#       upsmon secondary
#
# The matching MONITOR line in your upsmon.conf would look like this:
#
# MONITOR myups@localhost 1 upsmon pass primary	(or secondary)
#
# See comments in the upsmon.conf(.sample) file for details about this
# keyword and the difference of NUT secondary and primary systems.
[usv]
       password = xxxxx
       actions = SET
       instcmds = ALL
       upsmon master

[wendy2702]

@David-G. Mega, Vielen Dank!

[David G.]

@wendy2702

Bei deiner USV musst du natürlich recherchieren, welchen Treiber man angeben muss.

[wendy2702]

@David-G. Ja.

Das weiß ich noch. Hatte das vor x Jahren mal laufen aber damals nicht unter Proxmox

[wendy2702]

@david-g. Danke nochmal für deine CONF Daten. USV läuft jetzt am ersten Server. Jetzt noch was mit Blockly häkeln damit alles irgenwann runterfährt.

[Negalein]

muss mich auch kurz einklinken.

ChatGPT schlägt mir folgendes vor. Passt da vorallem das wegen Proxmox?

ChatGPT Unterhaltung

Du:
2 usv in 2 räumen

raum 1:
--> Proxmox mit 8 LXC
--> Synology DS718+ --> USV (USV-Server)

raum 2:
--> Proxmox mit 8 LXC
--> Proxmox mit 6 LXC
--> Windows 10 PC mit funktionierendem WinNUT
--> Synology DS918+ --> USV (USV-Server)

bei stromausfall soll alles sicher heruntergefahren werden.
zuerst LXCs, dan Proxmox Host, dann Windows 10 PC.
Jede USV regelt nur ihren Raum.

ChatGPT:
Super – sauberes Setup 👍
Ziel: Jeder Raum fährt sich bei Stromausfall autonom & geordnet herunter.

Shutdown-Reihenfolge je Raum:

LXC Container

Proxmox Host

Windows 10 PC (nur Raum 2)

Und:
➡️ Jede USV steuert nur ihren Raum
➡️ Kein Raum-übergreifendes Chaos
➡️ Kein hartes Power-Off

🔌 Architektur (empfohlen)
Du hast bereits die perfekte Basis:

Raum USV hängt an Rolle
Raum 1 DS718+ NUT Server
Raum 2 DS918+ NUT Server
➡️ Synology spielt jeweils Master (NUT Server)
➡️ Alle anderen Geräte = NUT Clients

🧠 Grundprinzip
Synology erkennt Stromausfall → startet Timer → sendet Shutdown an Clients → Clients fahren sauber runter → Host fährt zuletzt runter

Wichtig:
👉 Proxmox darf nicht sofort runterfahren
→ zuerst müssen die LXCs stoppen

Das lösen wir mit einem Shutdown Script auf Proxmox

🏠 Raum 1 Setup

1. Synology DS718+ (USV Master)
   DSM:

Systemsteuerung → Hardware & Energie → USV
Aktivieren:

✅ USV-Unterstützung aktivieren
✅ Netzwerk-USV-Server aktivieren
IP erlauben:

Proxmox_Raum1_IP
Optional:

👉 „Nach X Minuten herunterfahren“ = z.B. 5 min

2. Proxmox Raum 1 = NUT Client
   Paket installieren
   apt install nut-client
   /etc/nut/nut.conf
   MODE=netclient
   /etc/nut/upsmon.conf
   MONITOR ups@SYNOLOGY_IP 1 monuser secret slave
   SHUTDOWNCMD "/usr/local/sbin/proxmox-ups-shutdown.sh"
   POWERDOWNFLAG /etc/killpower
   /etc/nut/upsd.users
   [monuser]
   password = secret
   upsmon slave
   🧨 Proxmox Shutdown Script (wichtig!)
   nano /usr/local/sbin/proxmox-ups-shutdown.sh
   #!/bin/bash

logger "UPS: Shutdown gestartet - stoppe LXCs"

LXCs sauber stoppen

pct list | awk 'NR>1 {print $1}' | while read id; do
pct shutdown $id &
done

wait

logger "UPS: LXCs gestoppt - fahre Host runter"

sleep 30

shutdown -h now
chmod +x /usr/local/sbin/proxmox-ups-shutdown.sh
🏠 Raum 2 Setup
Hier gleich – aber mit Windows Integration.

1. DS918+ = USV Master
   Wie oben, aber erlaubte IPs:

Proxmox1_Raum2
Proxmox2_Raum2
Windows10_IP
2. Beide Proxmox = gleiche Client Config wie Raum 1
Nur:

SYNOLOGY_IP = DS918+
🪟 Windows 10 PC (WinNUT vorhanden 👍)
In WinNUT:

UPS Mode:

Remote UPS (slave)
UPS IP:

DS918+ IP
Shutdown Delay:

👉 z.B. 180 Sekunden

Damit:

➡️ LXCs fahren zuerst runter
➡️ Proxmox danach
➡️ Windows zuletzt

🧭 Shutdown Reihenfolge ergibt sich automatisch
Synology meldet:

👉 OB LB (On Battery)

Dann:

Proxmox Script stoppt LXCs

Proxmox Host fährt runter

Windows fährt später runter (Delay)

⚡ Wichtig: Synology selbst
DSM Einstellung:

👉 „USV herunterfahren wenn alle Clients offline“

Damit:

➡️ NAS bleibt solange online bis alles safe ist
➡️ Dann erst final shutdown

🔁 Test unbedingt machen!
Test:

USV vom Netz trennen
Check:

✔ LXCs stoppen
✔ Hosts fahren runter
✔ Windows fährt runter
✔ NAS zuletzt

🧱 Ergebnis
Beide Räume sind:

✅ Autonom
✅ Reihenfolge sauber
✅ Kein Datenverlust
✅ Kein Cross-Room Chaos