[vmtl gelöst] DOIF reagiert auf Verzögerung nicht

Begonnen von andies, 14 März 2020, 20:34:07

Vorheriges Thema - Nächstes Thema

andies

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
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Damian

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 ;)
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

andies

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
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Damian

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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ellert

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.

andies

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?
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Ellert

#37
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.

andies

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).
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Ellert

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.