[gelöst] DOIF Perl mit Template - Do (not) always und initialize

Begonnen von bismosa, 30 Juni 2022, 12:14:26

Vorheriges Thema - Nächstes Thema

bismosa

Hallo!

sorry, muss hier doch noch einmal ein paar fragen loswerden. Ich konnte dies nicht mit den Hilfeseiten beantworten.
Ich habe ein Test-DOIF:

defmod du_test_Sonne DOIF if ($::init_done) {                        ## Bei Änderung der Definition werden alle erfoderlichen Readings erstellt und vorbelegt\
    fhem("deletereading $SELF State_.*");;  ## alle Readings des Moduls löschen\
    set_State("init_done");;              ## Status setzen\
}\
\
DEF TPL_RolloAutomatik ({\
if ([du_Sonnensensor_Test:DiffTemp] < 20\
and [$SELF:State_$1] ne "cmd1")\
{\
set_State ("cmd1");;\
set_Reading("State_$1","cmd1", 1);;\
}\
elsif ([du_Sonnensensor_Test:DiffTemp] > 20\
and [$SELF:State_$1] ne "cmd2")\
{\
set_State ("cmd2");;\
set_Reading("State_$1","cmd2", 1);;\
}\
})\
\
TPL_RolloAutomatik(MeinDevice)\
TPL_RolloAutomatik(MeinDevice2)\

attr du_test_Sonne room Rolläden

setstate du_test_Sonne cmd1
setstate du_test_Sonne 2022-06-30 11:23:14 26020 2022-05-03 16:28:02State init
setstate du_test_Sonne 2022-06-30 11:23:14 26020 2022-05-03 16:28:02State init
setstate du_test_Sonne 2022-06-30 11:44:13 Device du_Sonnensensor_Test
setstate du_test_Sonne 2022-06-30 11:44:08 State_MeinDevice cmd1
setstate du_test_Sonne 2022-06-30 11:44:13 State_MeinDevice2 cmd1
setstate du_test_Sonne 2022-06-30 11:44:13 block_02 executed
setstate du_test_Sonne 2022-06-30 11:44:14 block_03 executed
setstate du_test_Sonne 2022-06-30 11:44:13 e_du_Sonnensensor_Test_DiffTemp 16.0
setstate du_test_Sonne 2022-06-30 11:44:08 e_du_test_Sonne_State_MeinDevice cmd1
setstate du_test_Sonne 2022-06-30 11:44:14 e_du_test_Sonne_State_MeinDevice2 cmd1
setstate du_test_Sonne 2022-06-30 11:42:17 mode enabled
setstate du_test_Sonne 2022-06-30 11:24:49 scState init
setstate du_test_Sonne 2022-06-30 11:44:13 state cmd1

und ein dummy zum testen:

defmod du_Sonnensensor_Test dummy
attr du_Sonnensensor_Test readingList state DiffTemp Temp2
attr du_Sonnensensor_Test room Rolläden
attr du_Sonnensensor_Test setList state:on,off DiffTemp:slider,7,0.5,70,1 Temp2:slider,7,0.5,70,1
attr du_Sonnensensor_Test webCmd state:DiffTemp:Temp2
attr du_Sonnensensor_Test webCmdLabel state\
:DiffTemp\
:Temp2

setstate du_Sonnensensor_Test 2022-06-30 11:44:13 DiffTemp 16.0


1.) "if ($::init_done)" wird nur bei einem (Neu-)Start von FHEM aufgerufen? Wie kann ich auch bei einer Änderung der definition die entsprechenden Readings löschen?
Kann man auch ein "set initialize" mit einem Perl-DOIF umsetzen?

2.) Ich habe ein erneutes Triggern unterbunden, indem ich mir Readings erzeuge mit "State_$1" und diesen dann Abfrage. (eigentlich sollte dies das gleiche Prinzip sein, wie ohne das attribut "Do Always") ?

3.) Beim testen ist mir aufgefallen, dass bei einer Temperaturänderung nur "MeinDevice" eine Zustandsänderung macht. "MeinDevice2" erst nach einer weiteren Temperaturänderung. Warum? Es müssten doch beide gleichzeitig die Zustandsänderung machen?

Danke für die Geduld  :)

Gruß
Bismsoa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Damian

Zu 1

if ($::init_done) bedeutet, dass das System schon läuft - es ist eine reine Abfrage einer globalen Variablen, sie triggert nicht. Es macht eigentlich nur im subs-Block Sinn. Beim Hochfahren des Systems ist es im subs-Block nicht gesetzt, bei defmod (wenn das System läuft) aber schon.

Zu 2

ja, man kann sich in einem Reading pro Szenario merken in welchem Zustand man ist und diese abfragen

Zu 3

Da mehrere Szenarien unabhängig voneinander laufen, sollten sie sich gleich verhalten, wenn sie das nicht tun, dann stimmt da etwas nicht.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

bismosa

Hallo,

das "($::init_done)" habe ich aus dem Beispiel
https://wiki.fhem.de/wiki/DOIF/Automatisierung#Helligkeitsabh.C3.A4ngige_Zeitsteuerung_f.C3.BCr_mehrere_Szenarien_mit_tabellarischer_.C3.9Cbersicht
Zitat
## Bei Änderung der Definition werden erfoderliche Readings erstellt und vorbelegt\
Auch wenn es in DOIF subs ist, wird dies nicht nach einer Definitionsänderung aufgerufen?

Zu 3.) Dann stimmt irgendwas nicht. Aber ich kann meinen Fehler hier einfach nicht finden. Sorry.  :(
Ist ja eigentlich nur ein sehr einfaches Beispiel...aber es ist reproduzierbar, das immer nur einer triggert...

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Damian

Zitat von: bismosa am 30 Juni 2022, 13:57:04
Hallo,

das "($::init_done)" habe ich aus dem Beispiel
https://wiki.fhem.de/wiki/DOIF/Automatisierung#Helligkeitsabh.C3.A4ngige_Zeitsteuerung_f.C3.BCr_mehrere_Szenarien_mit_tabellarischer_.C3.9CbersichtAuch wenn es in DOIF subs ist, wird dies nicht nach einer Definitionsänderung aufgerufen?

Zu 3.) Dann stimmt irgendwas nicht. Aber ich kann meinen Fehler hier einfach nicht finden. Sorry.  :(
Ist ja eigentlich nur ein sehr einfaches Beispiel...aber es ist reproduzierbar, das immer nur einer triggert...

Gruß
Bismosa

subs wird immer bei der Definition per def/defmod aufgerufen. Beim Hochfahren ist aber $::init_done nicht wahr, weil das System noch nicht komplett initialisiert wurde, wenn das System läuft und man die Definition per defmod ändert, ist $::init_done dagegen wahr, weil dann das System bereits initialisiert wurde.

Du kannst dir im Event-Monitor die Ereignisse anschauen, um zu schauen, was wann passiert.

Mit list kannst du dagegen sehen, wie deine Ausführungsblöcke per Templates tatsächlich erzeugt wurden.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

bismosa

Hallo!

dann sehe ich wohl den Wald vor lauter Bäumen nicht.
Nehme ich die Bedingung "and [$SELF:State_$1] ne "cmd1"" raus, funktioniert es.

Diese Zeile wird übersetzt mit

...
condition:
     0   
...
and ::ReadingValDoIf($hash,'du_test_Sonne','State_MeinDevice') ne "cmd1"
...
and ::ReadingValDoIf($hash,'du_test_Sonne','State_MeinDevice') ne "cmd2"
...
1
...
and ::ReadingValDoIf($hash,'du_test_Sonne','State_MeinDevice2') ne "cmd1"
...
and ::ReadingValDoIf($hash,'du_test_Sonne','State_MeinDevice2') ne "cmd2"
...

somit erklärt sich das Verhalten für mich nicht. Beide Readings standen auf "cmd1". Gewechselt haben diese aber nur nachdem ich zwei mal getriggert habe.

Auch mit dem löschen der Readings bei Änderung der Definition komme ich nicht voran.

DOIF subs {
if ($::init_done) {                        ## Bei Änderung der Definition werden alle erfoderlichen Readings erstellt und vorbelegt
    fhem("deletereading $SELF State_.*"); ## alle Readings des Moduls löschen
    set_State("init_done");              ## Status setzen
}
}

So werden bei der Änderung der Definition die Readings auch nicht gelöscht.
Ein Neustart kann ich derzeit im laufenden System nicht machen und testen. Dafür laufen zu viele andere Dinge.

Ich brauche dann wohl noch ein Wink mit dem Zaunpfahl. Da habe ich wohl noch viel zu lernen.

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Damian


Zitat von: bismosa am 30 Juni 2022, 15:03:40

DOIF subs {
if ($::init_done) {                        ## Bei Änderung der Definition werden alle erfoderlichen Readings erstellt und vorbelegt
    fhem("deletereading $SELF State_.*"); ## alle Readings des Moduls löschen
    set_State("init_done");              ## Status setzen
}
}

So werden bei der Änderung der Definition die Readings auch nicht gelöscht.

Bei mir schon :)

Zum Rest kann ich nichts sagen, da nicht alle Informationen vorliegen.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

bismosa

Hallo!

Ups. Wenigstens einen Fehler endlich gefunden.
Ich muss mich unbedingt mehr an die RAW-Definition gewöhnen.  :)
DOIF DOIF subs {
kann natürlich nicht funktionieren.  :)

Zum Rest...
Ich habe zwei Test-Devices. Einen Dummy mit einem Slider zum testen:

defmod du_Sonnensensor_Test dummy
attr du_Sonnensensor_Test readingList state DiffTemp Temp2
attr du_Sonnensensor_Test room Rolläden
attr du_Sonnensensor_Test setList state:on,off DiffTemp:slider,7,0.5,70,1 Temp2:slider,7,0.5,70,1
attr du_Sonnensensor_Test webCmd state:DiffTemp:Temp2
attr du_Sonnensensor_Test webCmdLabel state\
:DiffTemp\
:Temp2

setstate du_Sonnensensor_Test 2022-06-30 15:48:28 DiffTemp 12.5

Und mein DOIF zum testen:

defmod du_test_Sonne2 DOIF subs {\
if ($::init_done) {                        ## Bei Änderung der Definition werden alle erfoderlichen Readings erstellt und vorbelegt\
    fhem("deletereading $SELF State_.*");; ## alle Readings des Moduls löschen\
    set_State("init_done");;              ## Status setzen\
} \
}\
\
DEF TPL_RolloAutomatik ({\
if (\
[du_Sonnensensor_Test:DiffTemp] < 20\
and [$SELF:State_$1] ne "cmd1"\
)\
{\
if (ReadingsAge('$SELF','$1_Alter',999999) > 10){\
set_State ("cmd1");;\
set_Reading("State_$1","cmd1", 1);;\
}\
}\
elsif (\
[du_Sonnensensor_Test:DiffTemp] > 20\
and [$SELF:State_$1] ne "cmd2"\
)\
{\
set_State ("cmd2");;\
set_Reading("State_$1","cmd2", 1);;\
}\
})\
\
TPL_RolloAutomatik(MeinDevice)\
TPL_RolloAutomatik(MeinDevice2)
attr du_test_Sonne2 room Rolläden

Bei einer Temperaturänderung auf kleiner oder größer 20 erwarte ich eigentlich, das die Readings
State_MeinDevice
State_MeinDevice2
gleichmäßig sich verändern.
Die Bedingung
and [$SELF:State_$1] ne "cmd1"
soll dabei verhindern, dass in dem Beispiel die readings bei jeder Änderung der Temperatur erneut gesetzt werden. (Gleiches verhalten wie beim "FHEM DOIF" ohne "Do Always")


Vielleicht ist es heute auch einfach wieder zu warm  :) Danke für die Geduld mit mir!

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Damian

Du setzt den Status mit Trigger set_Reading("State_$1","cmd2", 1) und reagierst auf den Status mit Trigger [$SELF:State_$1] - das ist keine gute Idee, zumal Selbsttriggerung im Perlmodus vom Modul selbst nicht unterbunden wird.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

bismosa

Oh mann...da wäre ich ja nie drauf gekommen! DANKE!  :)

Den Trigger hatte ich gesetzt, da mir sonst die Readings erst nach einem manuellen reload der Seite angezeigt worden sind.
Da kann ich ja froh sein, dass FHEM sich dabei nicht in einer endlosschleife verabschiedet hat  :) Wäre irgendwie toll, wenn es dann einen Hinweis in der Log-Datei geben könnte.  ;)

Ein simples Fragezeichen in der Bedingung tut es dann auch:

...
and [?$SELF:State_$1] ne "cmd1"
...


Danke für den tollen und superschnellen Support!

Gruß
Bismosa
1x nanoCUL 433MHz (SlowRF Intertechno) für Fenstersensoren
1x nanoCUL 868Mhz für MAX (9x HT 1xWT)
1x ZigBee CUL
Weiteres: Squeezebox server, Kindle Display, ESP8266, Löterfahrung, ...

Damian

Zitat von: bismosa am 30 Juni 2022, 17:19:28
Oh mann...da wäre ich ja nie drauf gekommen! DANKE!  :)

Den Trigger hatte ich gesetzt, da mir sonst die Readings erst nach einem manuellen reload der Seite angezeigt worden sind.
Da kann ich ja froh sein, dass FHEM sich dabei nicht in einer endlosschleife verabschiedet hat  :) Wäre irgendwie toll, wenn es dann einen Hinweis in der Log-Datei geben könnte.  ;)

Ein simples Fragezeichen in der Bedingung tut es dann auch:

...
and [?$SELF:State_$1] ne "cmd1"
...


Danke für den tollen und superschnellen Support!

Gruß
Bismosa

Es gibt eine Meldung beim Abbruch einer Endlosscheife vom System, die käme aber erst beim zweiten Durchlauf, den du ja dann aber schon durch die if-Bedingung unterbunden hast.

Das Fragezeichen ist die Lösung oder einfach: get_Reading("State_$1") ne "cmd1" nutzen, das kann nicht triggern.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF