Guten Abend, ich möchte gern, wenn das Garagentor länger als ca 10 Minuten offen ist und mein Thermometer draussen weniger als 7 Grad meldet eine Nachricht bekommen. Der Zustand des Garagentors wird minütlich mitgeteilt, dennoch bekomme ich manchmal nach zehn Minuten eine Nachricht, obwohl das Tor nachweislich zu ist. Wie kann ich hier mit der Fehlersuche beginnen?
Internals:
DEF (([Garagensensor:Tor]==1) and ([BresserTemeo_1:temperature]<7) ) (set TelegramBot _msg Garagentor seit 10 Minuten *offen* und außen sind [BresserTemeo_1:temperature]°C! Schliessen mit /kurz1)
FUUID 5e5a3fb3-f33f-1115-ae59-8c293d56143bba20
FVERSION 98_DOIF.pm:0.212240/2020-02-18
MODEL FHEM
NAME GarageOffenDOIF2
NOTIFYDEV Garagensensor,BresserTemeo_1,global
NR 388
NTFY_ORDER 50-GarageOffenDOIF2
STATE cmd_1
TYPE DOIF
VERSION 21224 2020-02-18 18:45:49
READINGS:
2020-03-14 20:29:44 Device Garagensensor
2020-03-14 12:56:44 cmd 1
2020-03-14 12:56:44 cmd_event Garagensensor
2020-03-14 12:56:44 cmd_nr 1
2020-03-14 20:24:08 e_BresserTemeo_1_temperature 3.5
2020-03-14 20:29:44 e_Garagensensor_Tor 0
2020-03-10 15:10:51 mode enabled
2020-03-14 12:56:44 state cmd_1
2020-03-14 12:56:44 wait_timer no timer
Regex:
accu:
cond:
BresserTemeo_1:
0:
temperature ^BresserTemeo_1$:^temperature:
Garagensensor:
0:
Tor ^Garagensensor$:^Tor:
attr:
cmdState:
wait:
0:
600
waitdel:
condition:
0 (::ReadingValDoIf($hash,'Garagensensor','Tor')==1) and (::ReadingValDoIf($hash,'BresserTemeo_1','temperature')<7)
do:
0:
0 set TelegramBot _msg Garagentor seit 10 Minuten *offen* und außen sind [BresserTemeo_1:temperature]°C! Schliessen mit /kurz1
1:
helper:
DEVFILTER ^global$|^Garagensensor$|^BresserTemeo_1$
NOTIFYDEV global|Garagensensor|BresserTemeo_1
event Temperatur: 15.5,Tor: 0,Humidity: 27.1,HumidityNachLueften: 26.3648899975215
globalinit 1
last_timer 0
sleepdevice Garagensensor
sleepsubtimer -1
sleeptimer -1
timerdev Garagensensor
timerevent Temperatur: 14.0,Tor: 1,Humidity: 23.5,HumidityNachLueften: 35.2615508909737
triggerDev Garagensensor
timerevents:
Temperatur: 14.0
Tor: 1
Humidity: 23.5
HumidityNachLueften: 35.2615508909737
timereventsState:
Temperatur: 14.0
Tor: 1
Humidity: 23.5
HumidityNachLueften: 35.2615508909737
triggerEvents:
Temperatur: 15.5
Tor: 0
Humidity: 27.1
HumidityNachLueften: 26.3648899975215
triggerEventsState:
Temperatur: 15.5
Tor: 0
Humidity: 27.1
HumidityNachLueften: 26.3648899975215
internals:
readings:
all Garagensensor:Tor BresserTemeo_1:temperature
trigger:
uiState:
uiTable:
Attributes:
do always
wait 600
Baue ein doelseif ein.
Bedingung Tor zu.
ohne Auscuhrungsteil.
Gesendet von meinem S68Pro mit Tapatalk
habe ich, danke! Ich kapiere zwar, wieso das jetzt klappt - mir ist aber nicht klar, wieso meine Lösung vorher den Fehler produzierte. Kannst Du mir das irgendwie erklären oder mir einen Tipp geben?
Na klar, das offene tor startet den Timer.
Aber du hattest nichts zum stoppen.
Setze mal noch dass attribut do resetwait.
Gesendet von meinem S68Pro mit Tapatalk
und das geschlossene tor stoppt den nicht?
Gesendet von iPad mit Tapatalk Pro
In deinem doif nicht.
Gesendet von meinem S68Pro mit Tapatalk
dann kapiere ich das mit dem do always doch nicht. Ich dachte, es ist so:
*) Öffnet sich das Tor, wird der timer gestartet. Bevor gesendet wird, muss das device 10 Minuten warten.
*) Wenn in den 10 Minuten kein Statuswechsel erfolgt, wird die Nachricht gesendet - weil das Tor (immer noch) offen ist.
*) Schliesst man das Tor, so findet ein Statuswechsel statt. Wegen do always müsste aber auch nach einem Statuswechsel die Bedingung erfüllt sein, damit die Nachricht raus geht - da bei geschlossenem Tor das nicht der Fall ist, sollte es meiner Mein7ng nach keine Nachricht geben.
Wo habe ich denn da einen Fehler in meinem Gedankengang?
Gesendet von iPad mit Tapatalk Pro
2 und 3 stimmen so nicht.
Einen Statuswechsel des doif gibt es ja nicht.
Du sagst deinem doif nur wenn auf und kalter als dann...
Den statuswechsel hast nicht drin (doelseif)
Gesendet von meinem S68Pro mit Tapatalk
ohne do always hätte es schon funktioniert ;)
dann wird nämlich, der Sonst-Fall (DOELSE) automatisch gesetzt
Zitat von: Damian am 14 März 2020, 22:03:44
ohne do always hätte es schon funktioniert ;)
dann wird nämlich, der Sonst-Fall (DOELSE) automatisch gesetzt
Das sind die Dinge an Doif wo ich mir nie sicher bin, daher baue ich das immer selbst ein.
Der TE Ersteller hatte übrigens kein do always gesetzt laut seinem List.
Gesendet von meinem S68Pro mit Tapatalk
doch, das hatte ich!
Gesendet von iPad mit Tapatalk Pro
Zitat von: andies am 14 März 2020, 23:00:40
doch, das hatte ich!
Gesendet von iPad mit Tapatalk Pro
Ok, mein fehler.
Weiter oben im List ist nochmal "Attr"
Das hatte mich auf die falsche Fährte geleitet.
Geht es denn jetzt?
Gesendet von meinem S68Pro mit Tapatalk
Gerade getestet: es geht leider nicht. Garage seit 15' offen und keine Nachricht. Da ist immer noch was faul.
Ich verwende jetzt mal Damians Variante ohne do always.
Gesendet von iPhone mit Tapatalk Pro
Es wäre sinnvoll wenn du die getestete version als list (im Fehlerzustand) dazu postest. [emoji6]
Gesendet von meinem S68Pro mit Tapatalk
Ich habe jetzt diese Version am Laufen und die scheint zu gehen
defmod GarageOffenDOIF2 DOIF (([Garagensensor:Tor]==1) and ([BresserTemeo_1:temperature]<7) ) (set TelegramBot _msg Garagentor seit 10 Minuten *offen* und außen sind [BresserTemeo_1:temperature]°C! Schliessen mit /kurz1)
attr GarageOffenDOIF2 wait 600
Allerdings verstehe ich jetzt die Erläuterung https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF) nicht mehr:
- Das startende Ereignis ist [Garagensensor:Tor]==1 (unter der Bedingung, dass [BresserTemeo_1:temperature]<7 erfüllt ist)
- Da die Bedingung wahr ist, wird Befehl ausgeführt und Status aktualisiert
- Danach Stop.
So weit, so gut. Nun will ich aber 10 Minuten vor Ausführung des Befehls warten. Da erscheint jetzt
Statuswechsel als entscheidender Begriff in der Beschreibung. Nur wird der vorher nicht definiert (Ereignis, Auslöser, DOIF-Prozess dagegen schon). Was genau ist ein Status? Und wann genau wechselt der Status? Denn daraus kann ich folgern, inwieweit dieser Statuswechsel durch do always bzw do resetwait beachtet, nicht beachtet, ausgelöst oder was auch immer wurde.
Zitat von: andies am 16 März 2020, 08:42:34
Ich habe jetzt diese Version am Laufen und die scheint zu gehen
defmod GarageOffenDOIF2 DOIF (([Garagensensor:Tor]==1) and ([BresserTemeo_1:temperature]<7) ) (set TelegramBot _msg Garagentor seit 10 Minuten *offen* und außen sind [BresserTemeo_1:temperature]°C! Schliessen mit /kurz1)
attr GarageOffenDOIF2 wait 600
Allerdings verstehe ich jetzt die Erläuterung https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF) nicht mehr:
- Das startende Ereignis ist [Garagensensor:Tor]==1 (unter der Bedingung, dass [BresserTemeo_1:temperature]<7 erfüllt ist)
- Da die Bedingung wahr ist, wird Befehl ausgeführt und Status aktualisiert
- Danach Stop.
So weit, so gut. Nun will ich aber 10 Minuten vor Ausführung des Befehls warten. Da erscheint jetzt Statuswechsel als entscheidender Begriff in der Beschreibung. Nur wird der vorher nicht definiert (Ereignis, Auslöser, DOIF-Prozess dagegen schon). Was genau ist ein Status? Und wann genau wechselt der Status? Denn daraus kann ich folgern, inwieweit dieser Statuswechsel durch do always bzw do resetwait beachtet, nicht beachtet, ausgelöst oder was auch immer wurde.
Mit Status ist ganz einfach der Status des DOIF-Moduls gemeint. Wann der Status wechselt: initialized -> cmd_1->cmd_2->cmd_1->... muss jeder aufgrund seine Definition gedanklich durchspielen oder ausprobieren.
In deinem Fall wird der Wait-Timer für cmd_1 gestartet. Solange kein Ereignis zu einer vorzeitigen Zustandsänderung kommt, wird nach 10 Minuten cmd_1 ausgeführt. Kommt innerhalb der Wartezeit von 10 Minuten ein Ereignis, welches zu der Ausführung von cmd_2 führt, dann wird der Timer unterbrochen. Cmd_1 kommt nicht zu Ausführung, weil sich eben der "beabsichtigte" Status des Moduls, besser gesagt der Zustand des Moduls (Ausführung von cmd_1 in Ausführung von cmd_2) geändert hat.
Ist Status der Wahrheitsgehalt einer Bedingung? Oder ist Status ein Event? Oder ist Status ein Command?
Zitat von: andies am 16 März 2020, 18:47:42
Ist Status der Wahrheitsgehalt einer Bedingung? Oder ist Status ein Event? Oder ist Status ein Command?
Status des DOIF-Moduls: Reading
state
Jetzt fällt langsam der Groschen. Kann man das so beschreiben: Das Kommando, das im Reading state steht, ist das Kommando, welches ausgeführt werden soll. wait bedingt dann beispielsweise, dass die Ausführung verzögert wird. Alle Attribute wie do always/do resetwait haben dann eine bestimmte Wirkung darauf, wie sich das reading state verändert? Durch diese Veränderung macht dann das DOIF mal dies und mal das?
Zitat von: andies am 16 März 2020, 18:52:36
Jetzt fällt langsam der Groschen. Kann man das so beschreiben: Das Kommando, das im Reading state steht, ist das Kommando, welches ausgeführt werden soll. wait bedingt dann beispielsweise, dass die Ausführung verzögert wird. Alle Attribute wie do always/do resetwait haben dann eine bestimmte Wirkung darauf, wie sich das reading state verändert? Durch diese Veränderung macht dann das DOIF mal dies und mal das?
Im Reading state steht viel mehr der aktuelle Zustand, also der Zweig der zuletzt ausgeführt wurde und abhängig davon wird entschieden, ob der Zweig noch mal ausgeführt werden darf (do always) oder eben nicht.
Hinzukommt kommt die Geschichte mit wait-Timern, wie schon beschrieben.
Ist ein "Zweig" das, was eine Zeile in dem Bild in https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF) darstellt? Oder ist ein Zweig das zuletzt ausgeführte Kommando?
Zitat von: andies am 16 März 2020, 19:13:44
Ist ein "Zweig" das, was eine Zeile in dem Bild in https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF) darstellt? Oder ist ein Zweig das zuletzt ausgeführte Kommando?
Mit Zweig ist jeweils Zeile im Diagramm gemeint.
Ich habe mal versucht, meine Erkenntnisse in der Wikiseite zu verewigen. Vielleicht schaust du mal, ob ich da was falsch gemacht habe: https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF)
Zitat von: andies am 17 März 2020, 09:32:44
Ich habe mal versucht, meine Erkenntnisse in der Wikiseite zu verewigen. Vielleicht schaust du mal, ob ich da was falsch gemacht habe: https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF (https://wiki.fhem.de/wiki/DOIF/Einsteigerleitfaden,_Grundfunktionen_und_Erl%C3%A4uterungen#Struktur_und_Verhalten_des_DOIF)
Ich habe keine Einwände.
Zitat(sich also der Status oder der Inhalt des Readings ändert)
Halte ich für falsch, da der Status für Sequenzen keinen Statuswechsel im beschriebenen Sinne (ohne Attribute, z.B. do resetwait) darstellt.
Neu:
ZitatEin '''Statuswechsel''' liegt vor, wenn das device in einen anderen Zweig wechselt
Diese Aussage gibt's jetzt 2x im Text
Alt:
ZitatEin '''Statuswechsel''' findet statt nachdem ein anderer Bedingungszweig '''wahr''' wurde und die zugehörigen '''Befehle''' ausgeführt worden sind.
hier würde ich
ZitatZweig entspricht einer Zeile in dem obigen Diagramm.
platzieren dann ist es näher am zu erläutenden Text, oder man lässt es weg, denn
Zitatund die zugehörigen '''Befehle''' ausgeführt worden sind
erläutert ja schon, wann ein Statuswechsel erfolgt ist.
Zitat von: Ellert am 17 März 2020, 19:02:36
Halte ich für falsch, da der Status für Sequenzen keinen Statuswechsel im beschriebenen Sinne (ohne Attribute, z.B. do resetwait) darstellt.
ja, an die Zwischenzustände habe ich nicht gedacht. Es gilt nur für Endzustände wie cmd_1, cmd_2 usw.
Vielleicht finden wir noch eine Formulierung, die den Statuswechsel präziser definiert. Offenbar war andies nicht klar, was mit Statuswechsel ursprünglich gemeint war.
Vielleicht:
ZitatEin Zweig oder Bedingungszweig wird im DOIF von einem DOIF-Schlüsselwort (DOIF, DOELSEIF, DOELSE) eingeleitet.
Das ist dann unabhängig von einer grafischen Darstellung oder Zeilenumbrüchen in der Gerätedefinition.
Das habe ich jetzt mal eingetragen. Ich hätte gern noch eine bessere Formulierung für "Status", da scheine ich nicht den Nagel auf den Kopf getroffen zu haben. Wo ist denn das zweite Mal "Ein '''Statuswechsel''' liegt vor, wenn das device in einen anderen Zweig wechselt", dann können wir das ja löschen oder umformulieren.
Noch eine Frage zu Zweig: Klar ist, wie er eingeleitet wird. Wie endet er? Zeilenende im Diagramm?
<edit> eingearbeitet
Zitat von: andies am 17 März 2020, 19:39:09
Noch eine Frage zu Zweig: Klar ist, wie er eingeleitet wird. Wie endet er? Zeilenende im Diagramm?
Genau, wie der Zweig am Baum :)
Ellerts Beitrag:
ZitatDas ist eine schwierig zu beantwortende Frage. Der Zweig endet spätestens vor dem Beginn des nächsten Zweiges oder im Falle des Fehlens eines solchen, am Ende der Definiton. Wobei noch zu klären wäre, ob vor oder nach dem zweigtrennenden Leerzeichen. Hierbei ist natürlich zu erwägen ob das Leerzeichen als Präprozessorsteuerzeichen zu werten ist oder zum Schlüsselwort gehörend gerechnet wird.
Damians Beitrag:
Und ich dachte er bezieht sich auf deine Abbildung im Einsteigerleitfaden - dort kann ich keine Leerzeichen erkennen ;)
Edit: Ich habe leider wieder den Zitat- mit dem Änderungsknopf verwechselt und kann den ursprünglichen Beitrag nicht wiederherstellen.
ja, bloß so kapiert man das doch nicht. Man muss den Text ,,von oben nach unten" schreiben. Zuerst die einfache (vereinfachende, also in ihrer Gesamtheit eigentlich falsche) Erklärung, die danach im nächsten oder gar übernächsten Satz so lange weiter erklärt wird, bis alle Fälle drin sind.
Wenn da nun steht ,,zB Reading oder Internal" dann frage ich ich sofort: gibt es noch mehr als die beiden? Wenn nur die beiden: welche ist die wichtigere? Oder sind die gleichberechtigt? Wenn nicht: wann wählt man welches der beiden?
Könnt ihr mal Beispiele angeben? Vielleicht verstehe ich das dann und kann eine bessere Formulierung vorschlagen.
Gesendet von iPad mit Tapatalk Pro
Wie am Anfang im Einsteigerleitfaden steht, war am Anfang alles einfacher, es gab nur den Status cmd_1, cmd_2 ..., es gab nur eine Status- bzw. Reading-Abfrage und Zeittrigger.
Dann kamen Zeitintervalle, Sequenzen mit Zwischenzuständen, reine Ereignistrigger, Attribut checkall, das alles auf den Kopf stellt usw. und schon wird die Erklärung für Einsteiger nicht mehr so einfach. Aber jeder nutzt etwas davon und wehe es würde etwas nicht mehr da sein ;)
Zitat von: andies am 17 März 2020, 20:18:21
ja, bloß so kapiert man das doch nicht. Man muss den Text ,,von oben nach unten" schreiben. Zuerst die einfache (vereinfachende, also in ihrer Gesamtheit eigentlich falsche) Erklärung, die danach im nächsten oder gar übernächsten Satz so lange weiter erklärt wird, bis alle Fälle drin sind.
Wenn da nun steht ,,zB Reading oder Internal" dann frage ich ich sofort: gibt es noch mehr als die beiden? Wenn nur die beiden: welche ist die wichtigere? Oder sind die gleichberechtigt? Wenn nicht: wann wählt man welches der beiden?
Könnt ihr mal Beispiele angeben? Vielleicht verstehe ich das dann und kann eine bessere Formulierung vorschlagen.
Gesendet von iPad mit Tapatalk Pro
Wir reden hier vom Einsteigerleitfaden, er sollte korrekt sein, aber es kann nicht den Anspruch einer vollständigen Beschreibung aller Features haben, dafür ist die Commandref da.
Zitat von: Damian am 18 März 2020, 08:14:48
Wir reden hier vom Einsteigerleitfaden, er sollte korrekt sein, aber es kann nicht den Anspruch einer vollständigen Beschreibung aller Features haben, dafür ist die Commandref da.
OK, dann aber sollte ein ,,grober Klotz" (vielleicht mit einem Hinweis am Ende) ausreichend sein. Das spricht dann aber für meine Variante, eventuell mit einem Zusatz.
Gesendet von iPad mit Tapatalk Pro
Zitat von: andies am 18 März 2020, 08:16:50
OK, dann aber sollte ein ,,grober Klotz" (vielleicht mit einem Hinweis am Ende) ausreichend sein. Das spricht dann aber für meine Variante, eventuell mit einem Zusatz.
Gesendet von iPad mit Tapatalk Pro
Am besten stimmst du dich mit Ellert ab, er hat den Einsteigerleitfaden verfasst und kennt sich mit DOIF gut aus.
Unter
Voraussetzungen ist beschrieben, was zum Verständnis des Artikels vorausgesetzt wird, das sollte im Artikel nicht beschrieben werden.
Deshalb muss nicht beschrieben weden wodurch der Status eines Gerätes beschrieben wird.
ZitatStatus des DOIF ist der Inhalt des Readings state.
ist daher zu löschen.
ZitatStatuswechsel können sehr komplex sein.
hat keinen informativen Wert und sollte entfallen.
ZitatFür das erste Verständnis genügt es zu wissen, dass das device in einen anderen Zweig wechselt (sich also der Status oder der Inhalt des Readings ändert).
halte ich für zu umständlich formuliert
Vorschlag: Die vollständige Abarbeitung eines Bedingungszweiges bewirkt einen Statuswechsel.
Ein Statuswechsel, so wie er im Artikel verwendet wird, ist damit hinreichend beschrieben. Der Sachkundeanteil der in der Anmerkung ist nicht notwendig und sollte entfallen.
Zitat von: Ellert am 18 März 2020, 13:44:56
Die vollständige Abarbeitung eines Bedingungszweiges bewirkt einen Statuswechsel.
Das klingt sehr schön klar, aber da muss ich nachfragen. Eine nicht vollständige Abarbeitung ist dann kein Statuswechsel, richtig? Auch ist mir nicht klar, was "abarbeiten" heißt - die Grundbegriffe, die in diesem Abschnitt stehen, kennen "abarbeiten" nicht und abarbeiten kann sein: ausführen oder unterlassen - und sind beide gemeint? Oder nur eines?.
Dann würde ich doch sagen
ZitatStatuswechsel findet statt, nachdem/wenn die Bedingungen eines Zweiges geprüft und entsprechende Befehle des Zweiges entsprechend ausgeführt oder unterlassen wurden.
Oder ist das wieder sachlich falsch?
Ich habe den Artikel angepasst, er beschreibt damit ausreichend das Verhalten eines attributlosen DOIF als Ergänzung zum DOIF-Teil der Befehlsreferenz. Der ist allerdings schon so ausgereift, dass er eigentlich keiner Ergänzung mehr Bedarf.
ZitatAuch ist mir nicht klar, was "abarbeiten" heiß
Dann solltest Du davon Abstand nehmen Wörter zum Artikel hinzuzufügen ohne DOIF ausreichend zu verstehen..
Da es um ein attributloses DOIF, ist die Beschreibung von checkReadingEvent überflüssig und verwirrend
ZitatAuslöser sind Zeitpunkte, Gerätenamen(bei checkReadingEvent 0, voreingestellt bis Version 16651 2018-04-23 06:28:53Z Damian) oder die Kombination von Gerätename:Reading(bei checkReadingEvent 1, voreingestellt nach Version 16651 2018-04-23 06:28:53Z Damian) und reguläre Ausdrücke, die auf Gerätenamen oder ein Ereignis passen.
Zitat von: Ellert am 18 März 2020, 14:13:51
Dann solltest Du davon Abstand nehmen Wörter zum Artikel hinzuzufügen ohne DOIF ausreichend zu verstehen..
Was soll das? Ich habe Fragen und das Forum ist doch dazu da, sich dazu zu verständigen und nicht, sich gegenseitig Vorwürfe zu machen. Ich weiß weniger als Du, weil ich nicht vom Fach bin. Ich schreibe auch anderen nicht, dass sie zu doof sind sich auszudrücken (sondern behalte solche Gedanken bestenfalls für mich, wenn ich sie denn habe).
Ich möchte nicht, das halbgare Aussagen die Zielsetzung des Artikels unterlaufen.
Präzisierungen und Ergänzungen sind willkommen, sofern sie richtig und zielführend sind und die Struktur des Artikels nicht durchbrechen.
Daher habe ich Deine Anregungen bezüglich Statuswechsel und Bedingungszweig in die Struktur eingearbeitet.
Wenn Du der Meinung bist, dass es ein Glossar zu Begriffen des DOIF geben sollte, dann kannst Du es selbstverständlich anlegen und die Begriffe beschreiben, aber bitte nicht in dem Artikel, dort sollten dann nur Verknüpfungen erscheinen.
Ansonsten gilt der gleiche Änderungsvorbehalt, wie er im Artikel Erste Schritte in FHEM Bestand hat.
Und glaube mir es ist wirklich frustrierend, wenn jemand an einem Artikel herumbastelt und ich hinterher ausputzen muss.