Ventilsteuerung (Bewässerung) mit vier Kreisen und HM-LC-SW4-SM-2

[remo]

Wurde fhem.save denn zum reboot Zeitpunkt geschrieben?

Nein.

Reboot: 2021-08-02 20:30:00

Code Auswählen Erweitern

{qx(ls -lha ./log/fhem.save)}
--> -rwxrwxrwx 1 fhem dialout 103K Aug  2 15:16 ./log/fhem.save

Code Auswählen Erweitern

date unter Debian
--> Mo 2. Aug 20:31:50 CEST 2021 (passt)

[remo]

Code Auswählen Erweitern

list global statefile
--> global                   ./log/fhem.save

[Otto123]

Das ist unschön, da hast Du mal über überbügelt

-rwxrwxrwx

x - ist sinnlos
w -schreiben muss nur fhem können

Aber das ist nicht der Fehler. Ich habe keine Ahnung wer verhindert, dass Dein statefile beim reboot geschrieben wird.
Mach mal einen normalen shutdown reboot in FHEM und kontrolliere danach.

[remo]

Das ist unschön, da hast Du mal über überbügelt

Ist ein Relikt aus einem alten Tutorial von vor x Jahren.

Mach mal einen normalen shutdown reboot in FHEM und kontrolliere danach.

Code Auswählen Erweitern

{qx(ls -lha ./log/fhem.save)}
--> -rwxrwxrwx 1 fhem dialout 104K Aug  2 20:42 ./log/fhem.save (ok)

Code Auswählen Erweitern

save config
bewirkt übrigens dasselbe. Zeit auch ok.

Code Auswählen Erweitern

save config
rufe ich ja auch während der Bewässerung auf

direkt nach

Code Auswählen Erweitern

set dummy_Bewaess_lief on

Code Auswählen Erweitern

define at_BewaesserungAuto at *{(ReadingsVal('dummy_Bewaesserung_aktiv','start','19:19'))} { \
my $next = (ReadingsVal('dummy_Bewaesserung_next','state',''));; \
my $dauer_VorneSeite = (ReadingsVal('dummy_BewaesserungAuto_VorneSeite','state','') * 60);; \
my $dauer_Hinten1 = (ReadingsVal('dummy_BewaesserungAuto_Hinten1','state','') * 60);; \
my $dauer_Hinten2 = (ReadingsVal('dummy_BewaesserungAuto_Hinten2','state','') * 60);; \
my $dauer_HeckeBeet = (ReadingsVal('dummy_BewaesserungAuto_HeckeBeet','state','') * 60);; \
my $dauer_total = ($dauer_VorneSeite + $dauer_Hinten1 + $dauer_Hinten2 + $dauer_HeckeBeet);; \
if ($next eq 'heute') \
{ fhem (" \
set schalter_Pumpe off;; \
set schalter_Ventil.* off;; \
set dummy_Bewaess_lief on;; \
save config;;
set at_Bewaesserung_next execNow;; \
set schalter_Pumpe on-for-timer $dauer_total;; \
set schalter_Ventil4 on-for-timer $dauer_Hinten2;; \
sleep $dauer_Hinten2;; \
set schalter_Ventil3 on-for-timer $dauer_Hinten1;; \
sleep $dauer_Hinten1;; \
set schalter_Ventil1 on-for-timer $dauer_VorneSeite;; \
sleep $dauer_VorneSeite;; \
set schalter_Ventil2 on-for-timer $dauer_HeckeBeet;; \
")};;}

--> Das war ja mein Versuch aus Verzweiflung.
Das funktioniert auch Tag für Tag tadellos (auch wenn nicht ganz so elegant gelöst), aber wehe der Server macht seinen reboot am Montagmorgen um 01:00 Uhr, dann ist auf einmal das "alte" statefile wieder da....

[Otto123]

Was gibt das zurück?

Code Auswählen Erweitern

list global autosave
Du sagst ja indirekt er ändert beim reboot die Datei?
Also mach mal alle Schritte zur Kontrolle das save config funktioniert und dann ein reboot und danach wieder Kontrolle?
Irgendwie klingt es mystisch ...

[remo]

Code Auswählen Erweitern

list global autosave
--> global                   0

Du sagst ja indirekt er ändert beim reboot die Datei?

So stellt sich das zumindest dar.

Also mach mal alle Schritte zur Kontrolle das save config funktioniert und dann ein reboot und danach wieder Kontrolle?

Das war letzten Montag der Fall - dadurch bin ich dann bei save config gelandet.
Das statefile hat anfangs den manuellen reboot überlebt.
Daher war ich glücklich save config "entdeckt" zu haben.

Bis heute morgen.
Das manuelle sudo reboot lässt das statefile in Ruhe - nach wie vor und gerade getestet
(grep dummy_Bewaess_lief /opt/fhem/log/fhem.save)

Das geplante sudo reboot lädt anscheinend eine "alte Version" des statefile.

Verwirrend. Ich weiß 


EDIT:
Jetzt mal ne ganz blöde Frage und nicht hauen:
Benötigt das statefile die Log-Datei aus dem selben Verzeichnis?
Also: /opt/fhem/log/fhem-YYYY-MM.log
oder die aus /var/log/ ?

[Otto123]

Daher war ich glücklich save config "entdeckt" zu haben.

Ich denke ja diese Entdeckung ist völlig unnütz. Die Verwendung in Scripten wird eigentlich nicht empfohlen.

autosave
Der Standardwert 1 aktiviert einige Module nach einer Konfigurationsänderung automatisch zu speichern z.B. wenn ein neues Gerät erstellt wurde. Treten beim FHEM Start Konfigurationsfehler auf wird diese Funktion automatisch deaktiviert (0).

Bei der Einstellung autosave 0 wird ein save config im Code / Script nicht funktionieren.

Das statefile ist eine Textdatei die geschrieben wird, die "braucht" keine andere Datei.

Du verschweigst etwas?

[remo]

Code Auswählen Erweitern

attr global autosave 0
So steht's in meiner FHEM.cfg

Bei der Einstellung autosave 0 wird ein save config im Code / Script nicht funktionieren.

Gut zu wissen. Also keine Entdeckung

Du verschweigst etwas?

In meinem wöchentlichen reboot-Skript lasse ich Log-Dateien löschen, auch die von FHEM.

[Otto123]

Dann sage ich mal: überprüfe dieses Script! Du sagst ja schlussendlich selbst, das macht was mit dem fhem.save File.

Ich habe keine Vorstellung was.

Zum Nachweis würde ich als erstes nur ein geplantes reboot ohne alles weitere testen

[remo]

So weit war ich schon.
Das einzige was dort drin steht und Einfluss auf FHEM haben könnte ist das Löschen der Logs.
Der Rest bezieht sich auf andere Dinge.

Führe ich das Skript manuell aus funktioniert alles seit der save config-Entdeckung.
Läuft das Skript geplant (cronjob) tritt dieses Verhalten auf.
Per cronjob läuft aber auch nichts weiter vor, zu oder nach diesem Zeitpunkt.
Der cronjob läuft schon seitdem ich FHEM verwende.

Ich hatte bisher keine Probleme mit dem statefile oder ,,eigenartigem" Verhalten.
Zumindest fällt mir das erst jetzt mit meinem dummy auf.


Was aus FHEM heraus noch NACH dem cronjob (01:00) läuft, fällt mir gerade ein, ist um 03:15:

Code Auswählen Erweitern

{ fhem ("save config;; sleep 5;; update all;; sleep 300;; shutdown restart;;");; }

Das statefile hat aber nie den Stempel 03:15 - habe ich jedenfalls noch nicht beobachtet.

UND:
Otto, vielen Dank bisher für deine Unterstützung!!!
Ich weiß deine Geduld und Mühe sehr zu schätzen!!!

[Otto123]

naja save config ist ohne Wirkung, weil autosave auf 0 steht. save config ist aber auch nicht nur save fhem.save

Kannst Du Das Log von FHEM kontrollieren, ob es bei deinem cronjob ordentlich beendet wird? Also die gleiche Sequenz als wenn Du den reboot interactiv machst.

Ich denke ja nach wie vor: Du machst irgendwas "böses" in deinem Script, FHEM wird nicht ordentlich beendet, ein watchdog schlägt zu und killt den Prozess.

Aber wenn ich richtig liege, hast Du noch was anderes behauptet? Nachdem die fhem.save Datei schon richtig war, holt Dein cronjob ein altes File hervor!? Wenn das wirklich so ist, hast Du entweder einen Kobold im System oder Du kennst Dein Script nicht komplett.

[remo]

Gut. Reicht für heute 
Danke für deine Zeit.
Ich melde mich..

[remo]

Geheimnis gelüftet.
Kein Kobold. Und mein Skript kenne ich auch, weil selbst geschrieben 

Dass das statefile beim manuellen reboot mal intakt blieb und mal nicht ließ sich nicht zuverlässig reproduzieren.
Ich vermute eine ungünstige Konstellation/Abfolge von set dummy_Bewaess_lief on automatischer statefile-Speicherung durch FHEM und reboot .

Der geplante reboot hingegen, also der Aufruf des Skriptes (auch über cron), holte ja jedesmal ein "altes" statfile wieder hervor.

Beim manuellen Ausführen von systemctl stop fhem dauerte es einen Moment (ca. 5 Sekunden) bis der Befehl durch war.
Das ließ mich nachdenken.



grep shutdown /opt/fhem/log/fhem-2021-08.log
zeigte mir, dass der Shutdown in ca. 10 Sekunden stattfinden wird.

Da ein reboot, ob automatisch oder manuell, das System umgehend und ohne Verzögerung neustartet,
scheint systemctl stop fhem nicht stattzufinden.

Heißt: systemctl stop fhem + reboot = statefile ok

Ich habe systemctl stop fhem in mein Skript, vor reboot, mit aufgenommen.
Mehr nicht --> alles gut.



Otto, danke für das Weisen in die richtige Richtung.