DOIF setzt THRESHOLD beim Start immer auf "external"

Paul Panther · 10 März 2019, 11:28:17

Hallo zusammen,

seit ich FHEM nutze nervt mich ein Problem bei allen DOIF-Steuerungen bei denen ich den THRESHOLD nach Zeitvorgaben setze :
Folgende Beispiel-Konfiguration:

Code Auswählen


define Strg_DG_Afr DOIF ([Anwesend_xx:state] eq 0 and [Anwesend_yy:state] eq 0) (set THRES_DG desired 16)
DOELSEIF (([xx:state] eq 1 or [yy:state] eq 1) and ([18:00-20:00|12345] or [15:00-17:00|60])) (set THRES_DG desired 19)
DOELSEIF (([xx:state] eq 1 or [yy:state] eq 1) and [17:00-23:00|60]) (set THRES_DG external)
DOELSE (set THRES_DG desired 18)
attr Strg_DG_Afr checkall all
attr Strg_DG_Afr disable 0
attr Strg_DG_Afr do always
attr Strg_DG_Afr room DG
attr Strg_DG_Afr startup set Strg_DG_Afr checkall

Die Steuerungen funktionieren im Betrieb einwandfrei (external-Temperatur wir über ein notify definiert).
Wenn ich aber FHEM neu starte wird THRES_DG immer auf external gesetzt, obwohl ich jetzt bei den Attributen do always, checkall und startup definiert habe.
Ich hätte nämlich gerne, das DOIF beim Start getriggert wird und das richtige Kommando an THRESHOLD schickt.
set Strg_DG_Afr checkall setzt nach Definition von attr do always immerhin schon mal den richtigen THRESHOLD. Wenn das jetzt noch beim Restart funktionieren würde...
Freue mich über jeden Vorschlag!

Damian · 10 März 2019, 13:41:03

siehe: https://fhem.de/commandref_DE.html#DOIF_startup

Paul Panther · 10 März 2019, 14:52:58

Vielen Dank für die schnelle Antwort!
Ja, hatte ich gelesen und getestet. Nach restart kam allerdings wieder THRESHOLD auf external.
Auch diesmal war es nach dem 1. Restart wieder so.
Erst nachdem ich noch 3x gestartet habe scheint es zu funktionieren.
Werde es jetzt mal bei allen anderen analogen DOIF's versuchen.

Paul Panther · 10 März 2019, 15:14:20

Sorry, zu schnell geantwortet...
Negativ, Damian, da schein ein "Zufallsgenerator" am Arbeiten zu sein:
Habe es für 3 analoge DOIF's ausprobiert und mehrfach gestartet. In jedem Fall ist das DOIF-cmd richtig gesetzt, aber nach jedem Start habe ich unterschiedl. Ergebnisse. Mal passt es, mal passt es nicht, ganz unterschiedlich. Zuletzt wieder 2 auf external, 1 auf initialized, weil der Sensor wohl noch kein Signal geliefert hat.

Ich werd' zum Hirsch!
Gibt's noch 'ne Idee?

Damian · 10 März 2019, 17:52:46

Zitat von: Paul Panther am 10 März 2019, 15:14:20
Sorry, zu schnell geantwortet...
Negativ, Damian, da schein ein "Zufallsgenerator" am Arbeiten zu sein:
Habe es für 3 analoge DOIF's ausprobiert und mehrfach gestartet. In jedem Fall ist das DOIF-cmd richtig gesetzt, aber nach jedem Start habe ich unterschiedl. Ergebnisse. Mal passt es, mal passt es nicht, ganz unterschiedlich. Zuletzt wieder 2 auf external, 1 auf initialized, weil der Sensor wohl noch kein Signal geliefert hat.

Ich werd' zum Hirsch!
Gibt's noch 'ne Idee?

Es wird nichts dem Zufall überlassen, es funktioniert alles wie programmiert. Ohne präzise Angaben - keine Aussage möglich.

Paul Panther · 10 März 2019, 20:07:52

Ok, die Zuversicht freut mich!
Daher noch ein Anlauf. Hier die aktuelle Konfiguration von DOIF und THRESHOLD:

Code Auswählen

define Strg_DG_Afr DOIF ([Anwesend_xx:state] eq 0 and [Anwesend_yy:state] eq 0) (set THRES_DG desired 16)
DOELSEIF (([Anwesend_xx:state] eq 1 or [Anwesend_yy:state] eq 1) and ([18:00-20:00|12345] or [15:00-17:00|60])) (set THRES_DG desired 19)
DOELSEIF (([Anwesend_xx:state] eq 1 or [Anwesend_yy:state] eq 1) and [17:00-23:00|60]) (set THRES_DG external)
DOELSE (set THRES_DG desired 18)
attr Strg_DG_Afr checkall all
attr Strg_DG_Afr disable 0
attr Strg_DG_Afr do always
attr Strg_DG_Afr startup set $SELF checkall

define THRES_DG THRESHOLD TS_D1_Mini_115_DS18B20_115:Temperature:0:TempDes_DG_Afr:state D1_Mini_115_Rel_115|set D1_Mini_115_Rel_115 Aus|set D1_Mini_115_Rel_115 An|
attr THRES_DG comment Format: _m _dv _s1v _sc
attr THRES_DG number_format %.1f
attr THRES_DG state_cmd1_gt Aus
attr THRES_DG state_cmd2_lt An
attr THRES_DG state_format _m _dv _s1v _sc

Damit 7x shutdown restart ergibt folgende Ergebnisse:

Vor shutdown restart:
set Strg_DG_Afr checkall --> cmd_4 --> THRESH_DG active 18.0 19.2 Aus --> Passt!
Save config

shutdown restart 1:
--> cmd_4 --> THRESH_DG external 19.0 19.2 Aus --> Passt nicht!
shutdown restart 2:
--> cmd_4 --> THRESH_DG active 18.0 19.2 Aus --> Passt!
shutdown restart 3:
--> cmd_4 --> THRESH_DG external 19.0 19.2 Aus --> Passt nicht!
shutdown restart 4:
--> cmd_4 --> THRESH_DG active 18.0 19.2 Aus --> Passt!
shutdown restart 5:
--> cmd_4 --> THRESH_DG external 19.0 19.2 Aus --> Passt nicht!
shutdown restart 6:
--> cmd_4 --> THRESH_DG external 19.0 19.2 Aus --> Passt nicht!
shutdown restart 7:
--> cmd_4 --> THRESH_DG active 18.0 19.2 Aus --> Passt!

Liefere gerne weitere Info's, weiß nur nicht was noch. Bin leider kein Programmierexperte....

Damian · 10 März 2019, 20:20:48

Für eine Analyse braucht man immer die Ausgabe von list <das betroffene Modul>

Bei checkall werden einfach der Reihe nach die Bedingungen geprüft, falls die geprüfte Bedingung wahr ist, wird der Zweig ausgeführt und die Abarbeitung beendet.

Es kann natürlich auch beim Hochfahren des Systems zusätzlich Trigger der abgefragten Anwesend-Devices geben, die zu einer Ausführung eines Zweiges führen. All das lässt sich in den Readings und in den Interna des DOIF über list erkennen.

Paul Panther · 10 März 2019, 22:39:42

Ok, danke vielmals für den Hinweis!
Anbei die list.txt für das relevante DOIF.
Ich gestehe aber, daß mir das nicht weiterhilft bezüglich der Problematik.
Ich habe natürlich auch das Logfile analysiert. Da steht dann auch genau bei den Restarts, die den THRESHOLD richtig geschalten haben, "set THRES_DG desired 18". Dieser cmd_4 fehlt im Log entsprechend bei den fehlerhaften Restarts. Mehr kann ich da bei der Standardeinstellung verbose 3 nicht erkennen. Die Frage ist, warum der "startup"-Befehl manchmal "unterschlagen" wird, bzw. alternativ dann automatisch cmd_3 "set THRESH_DG external" gesetzt und ausgeführt wird?
Die Anwesend-Dummies werden natürlich auch von den anderen, analog aufgebauten DOIF's genutzt. Wie schon geschrieben habe ich auch dort diese "zufälligen" Effekte beim Restart.
Nochmals, über die Jahre hatte ich keine grundsätzlichen Probleme mit THRESHOLD im FHEM-Betrieb (nur selbstverschuldete Fehler eines Nicht-Experten). Nur das ständige Korrigieren der THRESHOLDS nach restart war/ist nervig. Da habe ich mich über das neue Feature "startup" gefreut, zumal ich die Steuerungen ausweiten möchte. Es ist auch kein gravierendes Problem, da die TRESHOLDS nach den Zeit-Triggern immer richtig gesetzt werden. Es heizt halt im schlimmsten Fall ein paar Stunden ungewollt.

amenomade · 10 März 2019, 23:22:01

Da hat aber das DOIF nichts getan: er steht noch auf cmd 0, Initialized.

Damian · 10 März 2019, 23:23:58

Das ist ein list von einem DOIF, wo nichts passiert ist cmd 0. Du musst ein list nehmen, wo ein vermeintlicher Zweig ausgeführt wurde.

Paul Panther · 11 März 2019, 10:19:57

Tut mir wirklich leid, wenn ich Dich spät nachts noch mit Anfängerfehlern genervt habe!
Nachstehend 2 Listings.
list2.txt, aufgenommen nach Abschaltvorgang heute morgen
list_restart_iO.txt, aufgenommen nach 2. Restart der dann das richtige THRESHOLD-Kommando brachte. Davor brachte der 1. Restart wieder den falschen external-Befehl, aber das Listing war exakt gleich.

Damian · 11 März 2019, 10:54:01

Zitat von: Paul Panther am 11 März 2019, 10:19:57
Tut mir wirklich leid, wenn ich Dich spät nachts noch mit Anfängerfehlern genervt habe!
Nachstehend 2 Listings.
list2.txt, aufgenommen nach Abschaltvorgang heute morgen
list_restart_iO.txt, aufgenommen nach 2. Restart der dann das richtige THRESHOLD-Kommando brachte. Davor brachte der 1. Restart wieder den falschen external-Befehl, aber das Listing war exakt gleich.

in list2.txt steht:

2019-03-11 09:00:00 cmd_event timer_6

Damit ist klar, was zur Ausführung von cmd 4 geführt hat.

Beim list_restart_io.txt steht:

2019-03-11 10:00:39 cmd_event Strg_DG_Afr

damit wurde dieser Zustand durch checkall ausgelöst

Paul Panther · 11 März 2019, 16:54:09

Ok, das habe ich schon auch verstanden. timer_6 war korrekt nach Definition im DOIF, cmd_event Strg_DG_Afr war ebenfalls korrekt. Nur dass halt im THRES_DG danach unterschiedliche Anweisungen stehen, das ist das Problem.
Die Listings haben beide die Zustände ausgewiesen, die i.O. waren.
Damit ist aber die Ursache für die willkürlich unterschiedlichen Settings des THRESHOLDS nach restart nicht erklärt.
Ich hatte heute morgen - wie beschrieben - wieder 2 unterschiedliche Zustände: external (falsch) und desired 18 (richtig) diese Listings waren allerdings identisch!
Habe deshalb nur Letzteres angehängt.
Werden im Listing auch die jeweiligen Zustände nach restart angezeigt? Oder die gespeicherten vor shutdown?
Ich bin mir nicht sicher, ob die Ursache für das merkwürdige Verhalten bei der Übergabe des Steuerungsbefehls an den THRESHOLD nach startup im Listing erkannt werden kann. Wie gesagt, im Betrieb läuft Alles einwandfrei, da tut der THRESHOLD das, was ihm das DOIF vorgibt.