DOIF neue Features: Generalisierung, $DEVICE, $EVENT, Attribut notexist

Damian · 03 Januar 2016, 21:02:14

Zitat von: cruser1800 am 03 Januar 2016, 19:04:08
Hallo Domain,

Fehlermeldungen sind weg. Mit

Code Auswählen Erweitern
trigger Haustuer battery: low

wollte ich jetzt testen. Es reagiert aber leider nicht. Steht weiter auf initialized. Habe das Beispiel wie vorne beschrieben kopiert.

Kannst du mir mal auf die Sprünge helfen!

Danke

Lutz

Mit trigger kann man es schon testen. So wie es aussieht, habe ich in meinem Beispiel den obligatorischen Doppelpunkt vergessen, der im Eventmonitor sichtbar das Reading vom Wert trennt.

Daher müsste die Angabe in meinem Beispiel wohl so aussehen ([":battery: low"], dann sollte dein Test funktionieren.

Edit: Der Doppelpunkt ist beim DOIF ein Trenner, daher muss man wohl erstmal statt Doppelpunkt einen Punkt für ein beliebiges Zeichen angeben, daher:
[":battery. low"]

Gruß

Damian

moonsorrox · 04 Januar 2016, 00:43:37

ZitatEdit: Der Doppelpunkt ist beim DOIF ein Trenner, daher muss man wohl erstmal statt Doppelpunkt einen Punkt für ein beliebiges Zeichen angeben, daher:
[":battery. low"]

ich hatte das die Tage auch mal ausprobiert mit der Batterieanzeige und habe mich gewundert warum nichts kam...
Mit obiger Änderung im DOIF werden jetzt die Readings des Dummy gefüllt, aber das State vom Dummy hat weiterhin

drin

Damian · 04 Januar 2016, 07:29:00

Zitat von: moonsorrox am 04 Januar 2016, 00:43:37
ich hatte das die Tage auch mal ausprobiert mit der Batterieanzeige und habe mich gewundert warum nichts kam...
Mit obiger Änderung im DOIF werden jetzt die Readings des Dummy gefüllt, aber das State vom Dummy hat weiterhin drin

Der Status wird in meinem Beispiel auch nicht belegt. Es ist ja auch nur ein Beispiel. Du kannst aber die Herausforderung annehmen und das Bespiel bei dir so anpassen, dass z. B. im Status das Device der letzten Änderung drin steht.

Gruß

Damian

cruser1800 · 04 Januar 2016, 21:29:35

Hallo,

jetzt funktionierts!

Klasse Arbeit!

Gruß Lutz

Per · 05 Januar 2016, 10:39:24

Zitat von: ujaudio am 31 Dezember 2015, 11:45:06Ich erlaube mir hier zwischendurch mal ein ganz großes Lob an die Macher von DOIF auszusprechen.

Dem muss ich mich, trotz nachfolgender Kritik (ja, ich nenne es so und dazu stehe ich!), vorbehaltlos anschließen.

Punkt 1:

Zitat von: ujaudio am 31 Dezember 2015, 11:45:06Keine Kritik, sondern ur eine Frage: warum sind die vielen guten Beispiel in der Commandref und nicht im Wiki geschrieben? Da ich mittlerweile immer beides lese, ist es letztendlich egal, aber gefühlsmäßig würde ich Beispiele immer im Wiki suchen, während die Commandref nur die "trockene" Theorie beschreibt - und ggf. auf das Wiki verweist

Zitat von: Damian am 31 Dezember 2015, 13:20:52Wiki-Beiträge kann jeder ergänzend erstellen, ich möchte dagegen nur eine Quelle mit gut ausgewählten Beispielen pflegen und auf dem aktuellen Stand halten und nicht mehrere.

Im Wiki steht es auf einer Seite und man kann gut navigieren (Pos1, Ende), in der Commandref ist es ein Punkt unter vielen, nimmt aber gefühlte 10% der Ref ein. Damit ist nicht nur das Navigieren innerhalb von DOIF schwer, sondern auch um DOIF herum.
Ich als Verantwortlicher würde in der Commandref eh nur interne Sachen auflisten. Externe Module (und noch

ist DOIF eins) alle extra (Wiki).

Zitat von: ujaudio am 31 Dezember 2015, 11:45:06Der Preis dafür: quasi eine weitere Syntax lernen.

Ein Punkt, mit dem DOIF aber nicht alleine steht. Warum gibt es so viele verschiedene Trennzeichen (z.B. in den Attribs): Doppelpunkt (wait) und Pipe (cmdState), von extern (z.B. floorplan) kommen noch Komma, Leezeichen dazu? Auch Klein- und Gemischtschreibung muss nicht sein: "timerWithWait" aber "cmdpause" und "wait"!
Trotz dieser Kritkpunkte werde ich jetzt weitere notifys durch neue DOIFs (mit .*

) ersetzen, das ist besser zu lesen und viel übersichtlicher.

Damian · 05 Januar 2016, 15:01:28

Zitat von: Per am 05 Januar 2016, 10:39:24
Dem muss ich mich, trotz nachfolgender Kritik (ja, ich nenne es so und dazu stehe ich!), vorbehaltlos anschließen.

Punkt 1:Im Wiki steht es auf einer Seite und man kann gut navigieren (Pos1, Ende), in der Commandref ist es ein Punkt unter vielen, nimmt aber gefühlte 10% der Ref ein. Damit ist nicht nur das Navigieren innerhalb von DOIF schwer, sondern auch um DOIF herum.
Ich als Verantwortlicher würde in der Commandref eh nur interne Sachen auflisten. Externe Module (und noch ist DOIF eins) alle extra (Wiki).
Ein Punkt, mit dem DOIF aber nicht alleine steht. Warum gibt es so viele verschiedene Trennzeichen (z.B. in den Attribs): Doppelpunkt (wait) und Pipe (cmdState), von extern (z.B. floorplan) kommen noch Komma, Leezeichen dazu? Auch Klein- und Gemischtschreibung muss nicht sein: "timerWithWait" aber "cmdpause" und "wait"!
Trotz dieser Kritkpunkte werde ich jetzt weitere notifys durch neue DOIFs (mit .* ) ersetzen, das ist besser zu lesen und viel übersichtlicher.

ja, das Problem mit der wachsenden Dokumentation des Moduls wurde in der letzten Zeit öfters diskutiert, was ich auch gut nachvollziehen kann. Es sind z. Zt. übrigens nur 5 % der gesamten Commandref

Ich habe kein Problem, die Dokumentation anders zu gestalten, allerdings sollten folgende Punkte aus meiner Sicht Berücksichtigung finden:

1. Der Ausgangspunkt der Doku eines jeden FHEM-Moduls, sollte immer die Commandref sein, da man dort zuerst nachschaut.

2. Dokumentation für den FHEM-User sollte verständlich mit typischen Beispielen versehen sein, nach denen man nicht lange suchen sollte.

Der typische FHEM-User dürfte inzwischen kein Informatiker sein, der gewohnt ist z. B. UNIX-Referenzbücher zu lesen, Perl ist für die meisten hier schon Zumutung genug, auch wenn ich die Programmiersprache gut finde.

3. Es muss sichergestellt sein, dass die Dokumentation vom Autor 100 prozentig kontrollierbar ist. Sie muss immer stimmen, sie darf nicht veraltet sein, Bespiele müssen geradlinig sein, Sachverhalten dürfen nicht unnötig komplizieren dargestellt werden. All das trifft z. Zt. nicht auf die beiden Einträge der Wiki-DOIF-Seite zu (die nicht von mir stammen).

Für alles Weitere, was über die Dokumentation hinausgeht, sind Wiki-Beiträge eine sehr gute Bereicherung.

4. Die Dokumentation muss für den Autor (Entwickler) einfach zu pflegen sein und nur aus einer Dokumentationsquelle stammen.

Für alles andere habe ich keine Zeit.

Wenn jemand eine Lösung parat hat, die die obigen Punkte abdeckt, bitte schön ...

Zu der Schreibweise der Syntax: zum Zeitpunkt der Definition, war es eine schlüssige Entscheidung, die man später nicht mehr ohne Weiters ändern kann

Gruß

Damian

krikan · 05 Januar 2016, 17:16:25

Hallo Damian!

zu 1.
Ja.

zu 2.
Ja. Deshalb ist es gut, wenn die Doku mit den Beispielen nicht überall verstreut ist. Lästig ist es mMn in commandref, Wiki, Forum und einer/mehreren Pdf(s) zu suchen. UliM hat bspw. vor Kurzem sein FLOORPLAN-Pdf ins Wiki überführt. Für mich ist es dann einfacher zu lesen/suchen, als in einer Pdf.

zu 3.
Die Beispiele auf der Wiki-Seite wurden in Absprache entfernt.
Auch jetzt gibt es schon Wiki-Seiten, die ausschließlich von einem eingeschränkten Personenkreis (bspw. http://www.fhemwiki.de/wiki/Erste_Schritte_in_fhem) oder durch den Entwickler (http://www.fhemwiki.de/wiki/SONOS) gepflegt und bearbeitet werden. Also dort gibt es sicherlich Lösungsmöglichkeiten.

zu 4.
Was für Dich einfach zu pflegen ist, kannst nur Du beurteilen. Dazu gibt es keine allgemeine Lösung. Das darfst (musst) Du für Dich entscheiden.

Gruß, Christian

FunkOdyssey · 05 Januar 2016, 17:22:16

Ich bevorzuge die CommandRef. Es gab doch auch vor wenigen Wochen einen Thread, wo man über die theoretische Umstrukturierung der CommandRef gesprochen hatte. Ich habe aber keine Ahnung, wie da der letzte Stand ist.

Damian hat es mit der Pflege der CommandRef sicherlich auch einfacher, da er seine bisherigen Entwicklungstools (Editor, SVN/Git, etc.) weiternutzen kann. Man muss auch keine neue Wiki-Syntax lernen.

ujaudio · 05 Januar 2016, 18:25:41

Ich wollte keine OT-Diskussion in diesem Thread lostreten, ich hatte eine Frage, die ist auch gut beantwortet worden und gut ist es. Bitte entschuldigt, dass ich als Urheber dies hier hineingebracht habe. Ich werde zukünftig bei Fragen, die nicht direkt zu Thread passen immer einen neuen aufmachen.

Nebenbei: irgendwie veringert sich die Anzahl meiner notify in den letzen Tagen

und jetzt weiter mit den neuen Features

Damian · 05 Januar 2016, 18:44:28

Zitat von: ujaudio am 05 Januar 2016, 18:25:41
Ich wollte keine OT-Diskussion in diesem Thread lostreten, ich hatte eine Frage, die ist auch gut beantwortet worden und gut ist es. Bitte entschuldigt, dass ich als Urheber dies hier hineingebracht habe. Ich werde zukünftig bei Fragen, die nicht direkt zu Thread passen immer einen neuen aufmachen.

Nebenbei: irgendwie veringert sich die Anzahl meiner notify in den letzen Tagen

und jetzt weiter mit den neuen Features

Die Doku gehört genauso zum Modul wie auch seine Features, daher finde ich die Diskussion gar nicht so falsch an dieser Stelle.

Ich habe bereits im August hier http://forum.fhem.de/index.php/topic,39854.msg320662.html#msg320662 einen Vorschlag genau zum Thema Commandref-Darstellung gemacht. Es sind auch ein paar vernünftige Vorschläge gekommen (inkl. globaler Suche innerhalb der Commandref). Die Diskussion ist dann wohl im Sande verlaufen - schade.

Die Sache liegt nicht in meiner Hand, sonst hätte ich schon längst eine hierarchische Darstellung der Commandref umgesetzt.

Gruß

Damian

l2r · 19 Januar 2016, 14:57:58

@Damian: gibt's schon einen Zeitplan, wann die neuen Funktionen die Testphase verlassen und "scharf" geschaltet werden? Oder habe ich da was nicht mitbekommen?

Damian · 19 Januar 2016, 15:50:13

Zitat von: l2r am 19 Januar 2016, 14:57:58
@Damian: gibt's schon einen Zeitplan, wann die neuen Funktionen die Testphase verlassen und "scharf" geschaltet werden? Oder habe ich da was nicht mitbekommen?

Wahrscheinlich Mitte Februar, ich betreibe noch Feintuning und habe gerade wenig Zeit zum Programmieren.

Gruß

Damian

Damian · 23 Januar 2016, 20:59:18

Version 0.4 im ersten Post:

Folgende Schlüsselwörter werden in der Bedingung sowie im Ausführungsteil ersetzt:

$DEVICE (wie bisher)
$EVENT passendes Event, welches zu Regex-Angabe passt. (wie bisher)
$EVENTS alle Events des Triggers (neu)

daneben gibt es jetzt äquivalent "echte" Perlvariablen, die in der gewohnten Perl-Syntax in der Bedingung abgefragt werden können:

$device
$event
$events

In der Regexp kann jetzt auch ein Doppelpunkt angegeben werden.

Doku muss ich noch anpassen.

Gruß

Damian

Damian · 24 Januar 2016, 18:27:05

Ich habe fertig!

Ich habe die Doku aktualisiert und noch ein paar Korrekturen vorgenommen. Beim Attribut notexist sollte man den Default-Wert in Anführungszeichen setzen. Damit lässt sich auch 0 und leere Zeichenkette definierten, Angaben, die man ja häufiger benutzt

@Ellert

Ich habe die Kurzreferenz angepasst und ans Ende der Inhaltsübersicht gelegt, da es ja in erster Linie Nachschlag-Referenz für DOIF-Nutzer ist. Anfänger sollten erst mal vorne anfangen, bevor sie in der Kurzreferenz nachschlagen.

Wenn keiner mehr was meldet, checke ich diese Version in den nächsten Tagen ein.

Aktuelle Version 0.5 befindet sich im ersten Post.

Edit: In der Doku habe ich zu neuen Features ein Beispiel für: "Loggen aller Events in FHEM" und "Batterie-Warnung per E-Mail" hinzugefügt.

Gruß

Damian

Ellert · 24 Januar 2016, 20:14:03

Hallo Damian,

ich habe kleine Änderungen vorgenommen, Basis ist Version 0.5:
Da $device,$event und $events nur in den Bedingungen gültig sind, habe ich sie in der Kurzreferenz unter die Überschrift "Operanden in der Bedingung" verschoben.

Einmal "&" bei "nbsp;" ergänzt, bei der Überschrift "Filtern nach Zahlen".

Das Ende der Kurzreferenz markiert mit ""

Da es kein $EVTPART gibt, würdest Du ein Beispiel für sinnvoll halten, wie man es nachbilden kann?

Code Auswählen

((set einDummy {(my @evt = split(" ","$EVENT");; return $evt[<Nummer des Eventparts>])}))

Gruss
Ellert