[GELÖST] RaspberryMatic + NUT-Server - USV-Reboot

[Toralf]

Vielen Dank für Deine schnelle und die geduldige ausführliche Antwort. Ich werde mich auf die Suche machen. Ich wußte gar nicht das die USV auch abschaltet. Ist aber vielleicht auch vom Hersteller abhängig..? Bei mir ist das Eaton Ellipse Eco 650. Mal gucken.... Die CCU und das ganze Spiel drumherum sind Neuland für mich. Deshalb Danke noch mal für die nette Antwort, ich beiß mich schon noch durch...

[Baxxy]

damit auch andere vielleicht einen Gegencheck machen können.

Ich würde mir das dann definitiv mal anschauen.

Angekündigt hatte ich es ja...
Und da nun endlich meine Wunsch-USV zu einem "normalen" Preis lieferbar war habe ich es auch getan.

Zunächst mal Danke für die gute Step-by-Step Anleitung!

Damit konnte ich das ganze Setup hier recht schnell und relativ problemlos bis zu einem gewissen Punkt umsetzen.
Zusätzlich hat deine Anleitung mich dazu gebracht, mich intensiver mit der Thematik zu befassen.

Deine Anleitung zu den optionalen Sachen (SysVar, EMail usw.) mittels upssched und nut_schedule.sh fand ich aber ziemlich "holprig".
Die war an einigen Stellen auch leider etwas inkonsistent.
z.B.

Doku:
Anpassen der Datei /etc/config/nut/upssched.conf
'CMDSCRIPT' Eintrag ändern in:
CMDSCRIPT /usr/bin/nut_upssched.sh

Optional, wenn in 'upssched.conf' definiert: Anlegen der Datei /etc/config/nut/nut_schedule.sh

Vollständige Konfigurationsdateien:
upssched.conf:
CMDSCRIPT /etc/nut/nut_schedule.sh

Hier verwendest du verschiedene Scriptnamen und Pfade, ich habe mal alles auf /etc/config/nut/nut_schedule.sh gesetzt.

Etwas verwirrend fand ich auch das du upssched (upssched.conf) und nut_schedule.sh beschreibst, diese aber anhand deiner vollständigen Konfigurationsdateien gar nicht zum Einsatz kommen.
Dein Pfad:

Code: Alles auswählen

(upsmon.conf) NOTIFYCMD /etc/config/nut/nut_notify.sh --> (nut_notify.sh) WatchDog-AlarmSysVars / Email-SysVars und Email senden

... lässt upssched und nut_schedule völlig aussen vor.

Da ich nicht auf die Timer von upssched verzichten wollte sieht mein Pfad nun so aus:

Code: Alles auswählen

(upsmon.conf) NOTIFYCMD /usr/sbin/upssched --> (upssched.conf) CMDSCRIPT /usr/local/etc/config/nut/nut_schedule.sh --> (nut_schedule.sh)Info-SysVar beschreiben, Email deaktiviert --> (nut_notify.sh)WatchDog Alarm-SysVar auslösen

Natürlich gilt auch hier, "viele Wege führen nach Rom".

Dann gibt es da noch den Fehler bei der Berechnung der Laufzeit in nut_schedule.sh.
Du hast...

Code: Alles auswählen

RUNTIME_S="$(printf "%02d:%02d:%02d" "$(($RUNTIME / 3600))" "$(($RUNTIME / 60))" "$(($RUNTIME % 60))")"

... korrekt wäre aber:

Code: Alles auswählen

RUNTIME_S="$(printf "%02d:%02d:%02d" "$(($RUNTIME / 3600))" "$(($RUNTIME % 3600 / 60))" "$(($RUNTIME % 60))")"

Zur Veranschaulichung:

Code: Alles auswählen

USV-Detail : Batterie: 99% geladen - Laufzeit: 01:87:07 Stunden
vs.
USV-Detail : Batterie: 99% geladen - Laufzeit: 01:27:07 Stunden

Dann lief bei mir nutshutdown nicht so richtig rund, die USV wollte sich einfach nicht abschalten.
Da habe ich kurzen Prozess gemacht und die Abfrage auf das (in der upsmon.conf deklarierte) POWERDOWNFLAG umgeschrieben.
Sieht dann jetzt so aus (raw-Version zum testen) und funktioniert problemlos.

Code: Alles auswählen

#!/bin/sh

# /usr/local/etc/config/rc.d/nutshutdown
# user-rights: 0755 - root [0]

case "$1" in
""|start)
  # RM Startup 
  ;;
stop)
  # RM Shutdown 
  # NUT-Original: /sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown
  # Test for the UPS shutdown flag
 echo "Test for the UPS shutdown flag"
  #if /usr/sbin/upsmon -K >/dev/null 2>&1; then
 if (test -f /var/tmp/killpower)
 then
    # Stop UPS driver instance
 echo "Stop UPS driver instance"
    /usr/sbin/upsdrvctl stop
    sleep 2
    # Call UPS shutdown
 echo "Call UPS shutdown"
    /usr/sbin/upsdrvctl shutdown
    # Send email 
    # /etc/config/addons/email/email 47
  fi
  ;;
esac

Summa summarum... Läuft hier im Testsetup nun völlig problemlos.

Ich hoffe du siehst mein Geschriebenes nicht als "Gemeckere" sondern als positive Kritik.

Noch kurz zum Testsetup:
Eine RM(Pi2B) ist der NUT-Master, eine andere RM(Pi4B) ein NUT-Client.

[wolwin]

Hallo Baxxy,

Ich hoffe du siehst mein Geschriebenes nicht als "Gemeckere" sondern als positive Kritik.

Ganz im Gegenteil - vielen Dank für Deinen Check und die ausführliche Rückmeldung!

NUT ist eben ein komplexes Werkzeug, das aber 'maximale' Flexibilität je Konfiguration und Einsatzzweck bietet. Und daher ist es auch schwierig 'alle' Aspekte der Konfiguration aufzuschreiben. Genau vor diesem Problem stand ich als ich die Github-Doku schreiben wollte - ich hatte schon alle für mich wichtigen Konfigurationen von NUT im RM-Umfeld mit Email-Addon, Visualisierung, etc. fertig ... und dann alles so strukturiert wieder auseinandernehmen und die einzelnen Themen gegeneinander abzugrenzen, dass es für alle verständlich ist. Da ist mir sicherlich die eine oder andere Nachlässigkeit passiert - aber ich nehme von Deinem Test mit, dass der Weg zur funktionierenden Installation gangbar ist.

Deine Anleitung zu den optionalen Sachen (SysVar, EMail usw.) mittels upssched und nut_schedule.sh fand ich aber ziemlich "holprig".
Die war an einigen Stellen auch leider etwas inkonsistent.

War ein Spagat zwischen allgemeiner Optionsbeschreibung und Umsetzung zur Installation - daher die '__Readme_NutServer.txt' / '__Readme_NutClient.txt' bei den Konfigurationsdateien ...

Habe die von Dir benannte Inkonsistenz in der Zitatbox leider nicht verstanden - was meinst Du damit??

Etwas verwirrend fand ich auch das du upssched (upssched.conf) und nut_schedule.sh beschreibst, diese aber anhand deiner vollständigen Konfigurationsdateien gar nicht zum Einsatz kommen.

Es sollten ja möglichst viele NUT Möglichkeiten - auch der von eigenen Scripten - aufgezeigt werden - an diesen Stellen steht immer 'Optional, wenn in xxx definiert'. Damit man sieht, was man machen kann, habe ich schon mal 'sinnvollen' Code eingetragen ... der aber hier nicht benutzt wird.

Dann gibt es da noch den Fehler bei der Berechnung der Laufzeit in nut_schedule.sh.

Stimmt - wird berichtigt.

Dann lief bei mir nutshutdown nicht so richtig rund, die USV wollte sich einfach nicht abschalten.
Da habe ich kurzen Prozess gemacht und die Abfrage auf das (in der upsmon.conf deklarierte) POWERDOWNFLAG umgeschrieben.
Sieht dann jetzt so aus (raw-Version zum testen) und funktioniert problemlos.

Ich würde vorschlagen, Deine Lösung als Kommentar in nutshutdown als mögliche Alternative zum Herunterfahren der USV mit einzufügen. Wichtig ist ja, dass es nutshutdown im RM-Umfeld überhaupt gibt, damit die USV auch wirklich abschaltet.

So, ich werde demnächst Deine Anmerkungen auf Github einarbeiten (wenn es nicht mehr so heiss ist) ... ich gebe Bescheid. Noch einmal Danke!

EDIT:
Die letzten beiden Punkte sind auf Github eingearbeitet,
https://github.com/wolwin/WW-mySHT/blob ... /README.md

[jmaus]

EDIT:
Die letzten beiden Punkte sind auf Github eingearbeitet,

Wovon redest du konkret? Im RaspberryMatic Wiki bzw. Dokumentation sehe ich dazu keinerlei Änderung/Anpassung.

[wolwin]

Wovon redest du konkret? Im RaspberryMatic Wiki bzw. Dokumentation sehe ich dazu keinerlei Änderung/Anpassung.

Meinte nicht die RM-Doku. Habe meine Link-Adresse zur NUT-Doku noch einmal hinzugefügt.

[jmaus]

Wovon redest du konkret? Im RaspberryMatic Wiki bzw. Dokumentation sehe ich dazu keinerlei Änderung/Anpassung.

Meinte nicht die RM-Doku. Habe meine Link-Adresse zur NUT-Doku noch einmal hinzugefügt.

Verstehe. Aber ich halte das ehrlich gesagt nicht für sinnvoll solche Informationen in einem extra git Repository unterzubringen. Das Schreit förmlich danach das dies in Vergessenheit gerät bzw. nie wieder auffindbar sein wird. Deshalb würde ich dir raten das am besten im RaspberryMatic Wiki unterzubringen bzw. dort zu integrieren. Der Wiki ist dort frei zugänglich und von jedermann anpassbar. Und da es in deinen Hinweisen/Dokumentationen ja um RaspberryMatic geht erscheint es mir nur sinngemäß zu sein das du diese Infos stattdessen dort unterbringst.

[wolwin]

Deshalb würde ich dir raten das am besten im RaspberryMatic Wiki unterzubringen bzw. dort zu integrieren. Der Wiki ist dort frei zugänglich und von jedermann anpassbar. Und da es in deinen Hinweisen/Dokumentationen ja um RaspberryMatic geht erscheint es mir nur sinngemäß zu sein das du diese Infos stattdessen dort unterbringst.

Grundsätzlich gebe ich Dir recht! Wie ich schon geschrieben habe, greifen bei mir neben NUT noch andere Prozesse / Addons ineinander. Genau damit - so finde ich - würde ich das Wiki überfrachten ... nicht jeder möchte z.B. System-Meldungen automatiscch per Email Addon erhalten.

Der Wiki-Leser und Standard-User würde mit meiner NUT-Doku überfordert sein. Das Wiki sollte schon in seinen Unterpunkten klar und deutlich sein - also (nur) definierte Grundlagen enthalten. So, wie das RM-Wiki jetzt ist, finde ich es gut.

Was ich tun könnte, wäre eine abgespeckte, komprimierte NUT Beschreibung erzeugen, in der alle 'externen Erweiterungen' deaktiviert werden. Optimal wäre natürlich, wenn dies einhergehen würde mit Intergration im RM-Quellcode.

[Baxxy]

Habe die von Dir benannte Inkonsistenz in der Zitatbox leider nicht verstanden - was meinst Du damit??

Also ich bin ja die 'RM-NUT_Server.md' durchgegangen.

A:
Im Abschnitt upssched.conf beschreibst du das man den CMDSCRIPT in "/usr/bin/nut_upssched.sh" ändern soll.

Das Problem dabei ist, das diese Datei in diesem Verzeichnis nicht existiert und ich keinen Hinweis gefunden habe dort etwas ab- bzw. anzulegen.

B:
Im nächsten Abschnitt zu nut_schedule.sh heißt es:

"Optional, wenn in 'upssched.conf' definiert: Anlegen der Datei /etc/config/nut/nut_schedule.sh".
Das ist ja soweit korrekt, nur kommt "nut_schedule.sh" nie zum Zuge weil wir ja davor "/usr/bin/nut_upssched.sh" als CMDSCRIPT deklariert haben.

C:
Dann hast du ja noch die vollständigen Konfigurationsdateien (hier für die Servervariante), und da steht in der "upssched.conf" CMDSCRIPT /etc/nut/nut_schedule.sh.

Und jetzt schreibe ich mal alle 3 "Stellen" untereinander:

Code: Alles auswählen

A: /usr/bin/nut_upssched.sh
B: /etc/config/nut/nut_schedule.sh
C: /etc/nut/nut_schedule.sh

Ich würde alles auf "/etc/config/nut/nut_schedule.sh" vereinheitlichen.

[wolwin]

Also ich bin ja die 'RM-NUT_Server.md' durchgegangen.

Danke Dir für die Details - werde das Ganze dann einmal komplett durchsehen ... wird jetzt aber etwas dauern, wg. U...

[wolwin]

Also ich bin ja die 'RM-NUT_Server.md' durchgegangen.

Bin Deine Punkte A, B, C durchgegangen ...
- ja, der CMD-Eintrag in 'upssched.conf' war falsch
- ja, dadurch wurde 'nut_shedule.sh' nicht ausgeführt (war bei meiner persönlichen Installation auch so gewollt )

GITHUB: Ich habe den CMD-Eintrag in 'upssched.conf' jetzt auf '/etc/nut/nut_schedule.sh' korrigiert und bei allen Konfig-Dateiangaben eine Verlinkung auf die Erläuterung der Unterschiede der RaspberryMatic- und Debian-Pfade hinzugefügt.

Danke noch einmal für Deine Unterstützung