Metainformationen zur Seite
  •  

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
home_assistant:home_assistant_rezepte:apcusv_einbinden [06.11.2026] – markhome_assistant:home_assistant_rezepte:apcusv_einbinden [07.11.2026] (aktuell) – kolja
Zeile 14: Zeile 14:
 sudo apt update sudo apt update
 sudo apt install -y apcupsd cron sudo apt install -y apcupsd cron
 +
  
 </code> </code>
Zeile 21: Zeile 22:
 <code bash> <code bash>
 sudo nano /etc/apcupsd/apcupsd.conf sudo nano /etc/apcupsd/apcupsd.conf
 +
  
 </code> </code>
Zeile 35: Zeile 37:
 NISPORT 3551 NISPORT 3551
 ONBATTERYDELAY 6 ONBATTERYDELAY 6
-#ACHTUNG: Die Zeiten unbeding an die eigenen Bedürfnisse anpassen. Einige Proxmox Server brauchen realtiv lange zum sicheren Herunterfahren, dort müssen BATTERYLEVEL und MINUTES erhöht werden. 
-#diese beiden sind eine ODER Entscheidung. Je nachdem, elche Kondition zuerst eintritt, also wie hier 10% Batterielevel oder 5 Minuten Restlaufzeit. 
 BATTERYLEVEL 10 BATTERYLEVEL 10
 MINUTES 5 MINUTES 5
Zeile 46: Zeile 46:
 **Begründung:**  ''DEVICE''  bleibt bei USB-Modbus leer. ''POLLTIME 30''  liest die USV ungefähr alle 30 Sekunden aus. ''NISIP 0.0.0.0''  erlaubt Netzwerkzugriffe: Port 3551 nur im vertrauenswürdigen LAN freigeben. Die Batteriegrenzen betreffen apcupsd auf dem Pi; andere Geräte werden dadurch nicht automatisch heruntergefahren. **Begründung:**  ''DEVICE''  bleibt bei USB-Modbus leer. ''POLLTIME 30''  liest die USV ungefähr alle 30 Sekunden aus. ''NISIP 0.0.0.0''  erlaubt Netzwerkzugriffe: Port 3551 nur im vertrauenswürdigen LAN freigeben. Die Batteriegrenzen betreffen apcupsd auf dem Pi; andere Geräte werden dadurch nicht automatisch heruntergefahren.
  
-Bei älteren Installationen ggf. ''ISCONFIGURED=yes''  in ''/etc/default/apcupsd''  setzen.+Bei älteren Installationen ggf. ''ISCONFIGURED=yes''  in ''/etc/default/apcupsd''  setzen.    
 + <font inherit/inherit;;#e74c3c;;inherit>**ACHTUNG:**</font>  Die Zeiten unbeding an die eigenen Bedürfnisse anpassen. Einige Proxmox Server brauchen realtiv lange zum sicheren Herunterfahren.  
 +Dort müssen BATTERYLEVEL und MINUTES erhöht werden.  
 +Diese beiden sind eine ODER Entscheidung. Je nachdem, welche Kondition zuerst eintritt, also wie hier 10% Batterielevel oder 5 Minuten Restlaufzeit.
  
 <code bash> <code bash>
Zeile 52: Zeile 55:
 sudo systemctl restart apcupsd sudo systemctl restart apcupsd
 apcaccess status | grep -E '^(DATE|STATUS|END APC)' apcaccess status | grep -E '^(DATE|STATUS|END APC)'
 +
  
 </code> </code>
Zeile 67: Zeile 71:
 <code bash> <code bash>
 sudo systemctl edit apcupsd sudo systemctl edit apcupsd
 +
  
 </code> </code>
Zeile 80: Zeile 85:
 sudo systemctl daemon-reload sudo systemctl daemon-reload
 sudo systemctl restart apcupsd sudo systemctl restart apcupsd
 +
  
 </code> </code>
Zeile 87: Zeile 93:
 ===== 5. USB-Modbus-Freeze automatisch beheben ===== ===== 5. USB-Modbus-Freeze automatisch beheben =====
  
-**Beobachteter Fehler:**  ''END APC''  zeigt die aktuelle Abfragezeit, aber ''DATE''  bleibt auf der letzten erfolgreichen USV-Datenübertragung stehen. Ein Neustart von ''apcupsd''  stellte die Kommunikation wieder her. **Nicht**  die Netzspannung ''LINEV''  vergleichen: Ein konstanter Messwert ist kein Fehlernachweis.+**Beobachteter Fehler:**''END APC''  zeigt die aktuelle Abfragezeit, aber ''DATE''  bleibt auf der letzten erfolgreichen USV-Datenübertragung stehen. Ein Neustart von ''apcupsd''  stellte die Kommunikation wieder her. **Nicht**  die Netzspannung ''LINEV''  vergleichen: Ein konstanter Messwert ist kein Fehlernachweis.
  
 Der Watchdog läuft **jede Minute**, meldet ein ''DATE''-Alter über **120 Sekunden**, bestätigt den Fehler nach **10 Sekunden**  und startet ''apcupsd''  neu. Zwischen zwei Neustarts liegen mindestens **15 Minuten**. ''LOWBATT''  und ''SHUTTING DOWN''  sind geschützt. Ereignisse werden im Journal protokolliert. Der Watchdog läuft **jede Minute**, meldet ein ''DATE''-Alter über **120 Sekunden**, bestätigt den Fehler nach **10 Sekunden**  und startet ''apcupsd''  neu. Zwischen zwei Neustarts liegen mindestens **15 Minuten**. ''LOWBATT''  und ''SHUTTING DOWN''  sind geschützt. Ereignisse werden im Journal protokolliert.
Zeile 95: Zeile 101:
 <code bash> <code bash>
 sudo nano /usr/local/sbin/apcupsd-watchdog.sh sudo nano /usr/local/sbin/apcupsd-watchdog.sh
 +
  
 </code> </code>
Zeile 189: Zeile 196:
     exit 1     exit 1
 fi fi
 +
  
 </code> </code>
Zeile 199: Zeile 207:
 sudo /usr/local/sbin/apcupsd-watchdog.sh --check sudo /usr/local/sbin/apcupsd-watchdog.sh --check
 sudo crontab -e sudo crontab -e
 +
  
 </code> </code>
Zeile 215: Zeile 224:
 systemctl is-active cron systemctl is-active cron
 sudo journalctl -t apcupsd-watchdog --since "24 hours ago" --no-pager sudo journalctl -t apcupsd-watchdog --since "24 hours ago" --no-pager
 +
  
 </code> </code>
Zeile 220: Zeile 230:
 **Praxisnachweis:**  Am 06.11.2026 erkannte der Watchdog ein ''DATE''-Alter von 164 s, startete ''apcupsd''  neu und stellte die Daten wieder her. Das umgeht den Freeze, beseitigt aber nicht dessen USB-Modbus-Ursache. Die USV-Abschaltung darf nicht allein von möglicherweise veralteten HA-Sensorwerten abhängen. **Praxisnachweis:**  Am 06.11.2026 erkannte der Watchdog ein ''DATE''-Alter von 164 s, startete ''apcupsd''  neu und stellte die Daten wieder her. Das umgeht den Freeze, beseitigt aber nicht dessen USB-Modbus-Ursache. Die USV-Abschaltung darf nicht allein von möglicherweise veralteten HA-Sensorwerten abhängen.
  
-===== 6. Späterer Umstieg auf serielles Modbus (RS-232) =====+. 
 + 
 +---- 
 + 
 +===== Umstieg auf serielles Modbus (RS-232) =====
  
 Bei der SMT1500I sind USB-Modbus-Freezes dokumentiert. **RS-232-Modbus**  vermeidet den betroffenen USB-Modbus-Kommunikationsweg und ist voraussichtlich stabiler, ohne eine absolute Garantie zu bieten. Bei der SMT1500I sind USB-Modbus-Freezes dokumentiert. **RS-232-Modbus**  vermeidet den betroffenen USB-Modbus-Kommunikationsweg und ist voraussichtlich stabiler, ohne eine absolute Garantie zu bieten.
Zeile 232: Zeile 246:
 <code bash> <code bash>
 ls -l /dev/serial/by-id/ ls -l /dev/serial/by-id/
 +
 +
 +</code>
 +
 +Beispiel:
 +
 +<code bash>
 +DEVICE /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0
 +
  
 </code> </code>
Zeile 247: Zeile 270:
 sudo systemctl restart apcupsd sudo systemctl restart apcupsd
 apcaccess status | grep -E '^(DATE|STATUS|END APC)' apcaccess status | grep -E '^(DATE|STATUS|END APC)'
 +
  
 </code> </code>
Zeile 252: Zeile 276:
 **Port 3551, Home-Assistant-Integration und Watchdog bleiben gleich.**  Die serielle Variante muss nach dem Umbau noch praktisch getestet werden. **Port 3551, Home-Assistant-Integration und Watchdog bleiben gleich.**  Die serielle Variante muss nach dem Umbau noch praktisch getestet werden.
  
-===== 7. Fehlersuche =====+ 
 +---- 
 + 
 + 
 +===== 6. Fehlersuche =====
  
 <code bash> <code bash>
Zeile 260: Zeile 288:
 sudo journalctl -t apcupsd-watchdog -n 30 --no-pager sudo journalctl -t apcupsd-watchdog -n 30 --no-pager
 sudo  journalctl -u apcupsd --since "today" sudo  journalctl -u apcupsd --since "today"
 +
  
 </code> </code>
Zeile 267: Zeile 296:
   * Im Test waren Pi-Unterspannung (''throttled=0x0'') und USB-Autosuspend (''power/control=on'') unauffällig.   * Im Test waren Pi-Unterspannung (''throttled=0x0'') und USB-Autosuspend (''power/control=on'') unauffällig.
  
-===== 8. Netzwerk Client anbinden =====+===== 7. Zusätzliche Netzwerk-Clients anbinden (Master/Slave-Betrieb) =====
  
-Wenn an der USV mehrere zu stützende Systeme hängen, sollten auch die üebr einen möglichen Ausfall informiert werden und sicher herunterfahren.+Wenn an der APC Smart-UPS 1500 mehrere Server oder Systeme (z. B. ein Proxmox-Server, ein PC oder ein zweites NAS) betrieben werden, müssen auch diese über einen Stromausfall informiert werden. Da das USB-Kabel physisch im Raspberry Pi (**Master**) steckt, können weitere Systeme als **Netzwerk-Clients (Slaves)**  eingerichtet werden. Diese lauschen über das Netzwerk dem Pi.
  
-Dazu die Instalaltion und bearbeiten der Konfiguration analog zu 1. und 2. hier auf der Seite.+Die Installation von ''apcupsd''  auf dem Ziel-Client erfolgt analog zu den Schritten 1 und 2. In der Konfigurationsdatei des Clients müssen jedoch die Netzwerk-Parameter angepasst werden.
  
-Aber folgende Änderung eintragen:+==== Schritt 1: Konfiguration auf dem Client-System anpassen ====
  
-Folgende Werte setzen; keine doppelten aktiven Einträge stehen lassen:+Datei auf dem zusätzlichen Server öffnen:
 <code> <code>
  
-#wie ist die USV angebunden (direk oder Netzwerk)+sudo nano /etc/apcupsd/apcupsd.conf 
 + 
 +</code> 
 + 
 +Folgende Werte setzen und darauf achten, dass keine doppelten, aktiven Einträge in der Datei stehen bleiben (alte USB-Einträge mit ''#''  auskommentieren): 
 + 
 +<code ini> 
 +# Verbindungstyp auf Netzwerk (Ethernet) umstellen
 UPSCABLE ether UPSCABLE ether
 UPSTYPE net UPSTYPE net
-DEVICE ip-adresse-host:port+ 
 +# IP-Adresse und Port des Raspberry Pi (Masters) eintragen 
 +DEVICE 192.168.10.248:3551 
 + 
 +# Abfrage-Intervall zum Master (in Sekunden)
 POLLTIME 30 POLLTIME 30
-#das Battery Level sollte signifikant höher liegen, da sonst ggf. der Master herunterfährt ohne noch benachrichtigen zu können+ 
 +# Erhöhte Sicherheits-Grenzwerte für den Client
 BATTERYLEVEL 20 BATTERYLEVEL 20
 MINUTES 10 MINUTES 10
  
 </code> </code>
 +
 +Dienst auf dem Client neu starten:
 +
 +<code>
 +sudo systemctl restart apcupsd
 +
 +</code>
 +
 +==== Erklärung der Sicherheits-Grenzwerte (Wichtig!) ====
 +
 +Die Werte ''BATTERYLEVEL''  und ''MINUTES''  wurden auf dem Client bewusst **höher angesetzt**  als auf dem Raspberry Pi (Master):
 +
 +* **BATTERYLEVEL 20:**  Der Client fährt bereits bei **20 % Restkapazität**  kontrolliert herunter. * **MINUTES 10:**  Der Client fährt herunter, sobald die verbleibende Akkulaufzeit unter **10 Minuten**  fällt.
 +
 +**Der Kaskaden-Ablauf im Ernstfall:**  Durch diese Staffelung wird verhindert, dass der Raspberry Pi (Master) zeitgleich mit den Clients herunterfährt. Der Pi bleibt länger aktiv und stellt sicher, dass er die Abschalt-Befehle im Netzwerk erfolgreich an alle Clients senden kann. Erst wenn die Clients sicher ausgeschaltet sind und die USV weiter gegen die kritische 5-%-Marke sinkt, fährt sich der Pi als allerletztes Gerät im Rack herunter.
 +
 +^Parameter^Einstellung^Einfache Erklärung|
 +
 +|**UPSCABLE** |''ether'' |Sagt dem System, dass die USV nicht per Kupferdraht (USB), sondern virtuell über das Netzwerk-Kabel (Ethernet) erreichbar ist.|
 +|**UPSTYPE** |''net'' |Stellt den Treiber in den Client-Modus. Das System sucht nicht nach physikalischer Hardware, sondern lauscht auf USV-Daten aus dem Netzwerk.|
 +
 +----
 +
 +Dokumentation bei Kolja [[:blackout_shutdown_doku_bei_kolja|Link]]
 +
 +----
  
 ===== Quellen und weiterführende Links ===== ===== Quellen und weiterführende Links =====