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

[remo]

Guten Abend.

Ich habe soeben einen Logikfehler in meinem at gefunden.

{$yday%$tage}

Ist falsch - in meinem Fall zumindest.
Der dummy ..._next zeigt nach dem ganzen Zeit-TamTam ,,heute" an, weil seit der letzten Wässerung 2 Tage vergangen sind, aber es schaltete heute nicht, weil $yday%$tage != 0 ist.

Werde das if rest==0 aus dem at durch ..._next eq ,,heute" ersetzen.
Somit würde tatsächlich alle x Tage seit der letzten Wässerung wieder gewässert werden und nicht in Abhängigkeit von $yday.

Wird getestet und dann gibt's ein sauberes Update.

Schönen Abend.

[remo]

Alles aktualisiert und getestet.
Läuft.

Siehe meinen ersten Post auf Seite 1 - dort ist, falls Bedarf ist, meine komplette Bewässerung zu finden.


Schönen Sonntag.

[vencam]

@remo: Hab gesehen du arbeitest mit sleep Befehlen, bleibt da FHEM nicht komplett stehen?

Thema Pumpe:

Ich schalte meine Tauchpumpe (Zisterne), welche an einem Schütz hängt, mittels sonoff basic (tasmota).
Mit der Firmware hat man auch die Möglichkeit einen Timer zu setzen "pulsetime"  ...

Wird die Pumpe angeschalten, läuft der Timer und sie geht nach vorgegebener Zeit wieder aus.
Während der Bewässerung trigger ich die Pumpe alle paar Minuten, damit sie an bleibt. Also der Timer wird ständig neu gestartet.

Sollte FHEM aus welchem Grund auch immer, während der Bewässerung abstürzen, dann schaltet sich die Pumpe trotzdem selbständig ab. 

[Otto123]

@remo: Hab gesehen du arbeitest mit sleep Befehlen, bleibt da FHEM nicht komplett stehen?

er arbeitet mit fhem sleep Befehlen, die blockieren fhem nicht!

[MadMax-FHEM]

@remo: Hab gesehen du arbeitest mit sleep Befehlen, bleibt da FHEM nicht komplett stehen?

Wenn danach ein fhem-Befehl folgt: nein
(so ich das schnell überflogen habe passt das hier wohl)

EDIT: war ja klar -> zu langsam

Gruß, Joachim

[remo]

@vencam:
Danke für den Hinweis.

@Otto:
Also doch ok?

Ein komplettes Schlafen kann ich wie genau testen?
Habe gerade während eines sleep mal einen anderen Aktor geschaltet und eine Berechnung durchführen lassen - hat funktioniert. FHEM hat sich wie erwartet verhalten. Hat also nicht den Eindruck eines Einfrierens gemacht.

[Otto123]

@Otto:
Also doch ok?

Ein komplettes Schlafen kann ich wie genau testen?
Habe gerade während eines sleep mal einen anderen Aktor geschaltet und eine Berechnung durchführen lassen - hat funktioniert. FHEM hat sich wie erwartet verhalten. Hat also nicht den Eindruck eines Einfrierens gemacht.

Sebstverständlich ist das ok
vencam redet von/denkt an Perl sleep!
FHEM Sleep kann übrigens viel mehr als einfach nur ein Wartzeit:

sleep gefolgt von weiteren Befehlen ist vergleichbar mit einem namenlosen at oder notify Kommando, es führt die nachfolgenden Befehle aus, nachdem es die spezifizierte Zeitspanne gewartet hat bzw. ein Event welches dem <suchmuster> entspricht aufgetreten ist. Die verzögerung kann
in Sekunden (Millisekunden genau, da man Nachkommastellen spezifizieren kann)
als timespec (HH:MM or HH:MM:SS oder {perlfunc})
oder als suchmuster (Gerätename oder Gerätename:Event)
angegeben werden.

@Joachim Es freut mich immer, wenn wir zwei an verschiedenen Orten auf der Welt, die gleiche Frage lesen, fast die gleiche Antwort schreiben und nur mit Sekunden Unterschieden den Schreiben Knopf drücken. Ist doch völlig egal wer früher oder später ist

[MadMax-FHEM]

[remo]

Gut. Dankeschön 

[remo]

Hallo zusammen,

so richtig rund läuft die Sache doch noch nicht.

Mein Dummy, der den Timestamp der letzten Bewässerung speichern soll, verliert den allerletzten Timestamp nach Neustart des physischen Servers.

Beispiel:

set dummy_Bewaess_lief on;; wird bei jeder Bewässerung ausgeführt.
ReadingsTimestamp('dummy_Bewaess_lief', 'state', '') ergibt dann danach z.B. 18:00:00

Dann passiert in  at_Bewaesserung_next etwas Zahlenspielerei, um den nächsten Zeitpunkt relativ zum letzten zu errechnen.

So weit, so gut. Läuft.

Findet jetzt die nächste Bewässerung statt, fängt der Spaß von vorne an und
ReadingsTimestamp('dummy_Bewaess_lief', 'state', '') ergibt dann z.B. 18:10:00

Nun startet der physische Server (Debian 10) neu und
ReadingsTimestamp('dummy_Bewaess_lief', 'state', '') ergibt dann wieder 18:00:00

Mittels geplantem save config habe ich versucht mir zu behelfen - aber das bringt leider nichts.
Mein Debian startet jeden Montagmorgen um 01:00 Uhr neu - seit gut vier Montagen bin ich nun ratlos.
FHEM scheint jedes Mal ds statefile vom letzten Speichern VOR dem Neustart auszulesen...

Hat vielleicht jemand eine Idee?

Schönen Wochenstart.

[Otto123]

Hallo remo,

statefile wird beim ordentlichen Shutdown neu geschrieben. Da musst Du Dich nicht kümmern.
Entweder "ziehst Du den Stecker" oder mit der Zeit stimmt was nicht, oder "du selbst" manipulierst etwas ohne es zu wissen.
Einen statefile-1 gibt es mW nicht.

Was im statefile steht ist relativ leicht zu kontrollieren. Mach

Code Auswählen Erweitern

systemctl stop fhem
Und dann

Code Auswählen Erweitern

grep dummy_Bewaess_lief /opt/fhem/log/fhem.save

Wenn FHEM wieder läuft kannst Du auch reinschauen:

Code Auswählen Erweitern

{qx(grep dummy_Bewaess_lief ./log/fhem.save)}

Gruß Otto

[remo]

Hallo Otto.
Gut. Danke. Probiere ich aus. Vielleicht bringt mich das etwas näher an den Ursprung des Fehlers.
Aber sonderlich elegant ist mein Ansatz nicht, oder?
Eine dummy ,,on" schalten um mir dann später den Timestamp des ,,set xxx on" zu holen...?!
Wäre es vielleicht besser in den dummy dummy_Bewaesserung_aktiv ein Reading lief mit aufzunehmen welches dann im at den aktuellen Zeitstempel als Wert erhält?

EDIT:
,,Stecker ziehen" kommt dem schon recht nahe wenn ich FHEM den Server unterm hintern weg neustarte.
reboot  steht im Script.
systemctl reboot wäre doch dann abgebrach, oder?

[Otto123]

Nach Eleganz hast Du aber nicht gefragt

reboot ist eigentlich ok, Du kannst Doch schauen ob fhem.save zu diesem Zeitpunkt geschrieben wurde.
reboot vom System sendet ein entsprechendes Signal an die Dienste, die werden ordentlich beendet, danach das System. Es sei denn, irgendwelche Wachhunde schlagen zu schnell zu, Timeouts werden überschritten o.ä.
on systemctl reboot was anderes ist als reboot weiß ich spontan nicht.

[remo]

Nach Eleganz hast Du aber nicht gefragt

Stimmt

Code Auswählen Erweitern

grep dummy_Bewaess_lief /opt/fhem/log/fhem.save
--> setstate dummy_Bewaess_lief 2021-07-29 21:00:01 state on

Code Auswählen Erweitern

{(ReadingsTimestamp('dummy_Bewaess_lief', 'state', ''))}
--> 2021-07-29 21:00:01 (Ok, beide identisch)

Code Auswählen Erweitern

set dummy_Bewaess_lief on   // inzwischen wurde bewässert

Code Auswählen Erweitern

grep dummy_Bewaess_lief /opt/fhem/log/fhem.save
--> setstate dummy_Bewaess_lief 2021-07-29 21:00:01 state on (falsch)

Code Auswählen Erweitern

{(ReadingsTimestamp('dummy_Bewaess_lief', 'state', ''))}
--> 2021-08-02 20:15:12 (richtig)

Code Auswählen Erweitern

systemctl stop fhem
systemctl start fhem

Code Auswählen Erweitern

grep dummy_Bewaess_lief /opt/fhem/log/fhem.save
--> setstate dummy_Bewaess_lief 2021-07-29 21:00:01 state on (falsch, alter Wert)

Code Auswählen Erweitern

{(ReadingsTimestamp('dummy_Bewaess_lief', 'state', ''))}
--> 2021-07-29 21:00:01 (falsch, alter Wert)

[Otto123]

Wurde fhem.save denn zum reboot Zeitpunkt geschrieben?

Code Auswählen Erweitern

{qx(ls -lha ./log/fhem.save)}
Was steht in global?

Code Auswählen Erweitern

list global statefile