https://wiki.fhem.de/wiki/Notify ist überholungsbedürftig und ich brauche Ideen/Mitschreiber/Antreiber/Hilfe/...
Gruß, Christian
Hab mal angefangen :) .
Fragen:
- Soll das mit dem Regex-Wizzard so stehen bleiben? (ich habe den bisher weitestgehend ignoriert und müßte erst prüfen, ob die Darstellung und Funktionalität noch einigermaßen aktuell ist). Wenn es aktuell ist: Auslagern oder an dieser Stelle belassen?
- Kann ich "EIB" einfach durch "KNX" ersetzen?
"Hinten raus" wird es in den Beispielen auch immer spezieller, aber eigentlich sind die ganz ok (wenn auch teilweise die syntax vermutlich verbesserungsfähig ist). Auf den ersten Blick neige ich dazu, das einfach redaktionell zu überarbeiten. Andere Meinungen?
Hi,
mir fällt da gerade ein: Sowas muss da eigentlich mit rein: Mein notify geht nicht - wie kann ich mir selbst helfen?
siehe -> https://forum.fhem.de/index.php/topic,89169.msg816584.html#msg816584
Das der Wiki Artikel komplett mit EIB KNX aufgebaut ist stört mich irgendwie. Als Anfänger der ein Problem hat und kein KNX hat würde ich den Artikel nicht lesen.
Die Beispiele sind nicht schlecht aber den direkten Produktbezug würde ich im Wiki komplett weglassen.
Gruß Otto
Danke für die Anmerkungen.
Einen Abschnitt mit "Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging" zu benennen ist m.E. nicht schlecht, da könnte dann die "trigger"-Darstellung drin aufgehen. Das leitet Anfänger dann ggf. mehr.
Beim Thema Produktbezug bin ich sehr hin- und hergerissen. Einerseits fand ich den Artikel als HM- und MySensors-Nutzer an der Stelle "schon immer" nicht ganz soooo interessant (weswegen ich das auch nicht mehr so in den Vordergrund stellen würde wo möglich), andererseits benötigt man für derart konkrete Beispiele eben Devices. Und da finde ich es nicht schlecht, dass "mal was anderes" dargestellt ist als HM o. FS20. Dummy wäre die Alternative, aber da ist man dann zum einen sehr nahe an den "Ersten Schritten" und zum zweiten finde ich das mit den "vielen Dummies" kontraproduktiv (pers. Meinung, hatte ich an anderer Stelle ja schon ausgeführt).
Die Alternative wäre, das weniger konkret zu machen. Die Frage wäre dann, ob es dann noch "Anfänger"-interessant ist - ich fürchte nein, weil eben dann abstrakt.
Gruß, Beta-User
Hi,
sieht doch schon einmal richtig gut aus :-) - Danke -
ich würde gerne noch ein paar Beispiele mehr haben - die auch "etwas" komplexer sind
define schalter123 notify Schalter(1|2|3)...
define dimmerAbove75percent notify dimmer:pct:.(100|7[6-9]|[89][0-9])
die Probleme mit $EVENTPARTx wenn nicht so viele Elemente vorhanden sind
my @Parameter = split(/ /, $EVENT);
# Workaround, da $EVTPART1 nur definiert ist, wenn das Event mehre Elemente hat
# $Parameter[0] = $EVTPART0
# $Parameter[1] = $EVTPART1
# ...
und vielleicht noch als Codeschnippsel 2 Fensterkontakte geben den Status des Fensters an (Open|Closed|Tilted) (geht auch kürzer ist aber so verständlicher)
define statusFenster notify fensterKontakt(Oben|Unten):(open|closed) {
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' &&
ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')
{ fhem 'set Terrassentuer open' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' &&
ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')
{ fhem 'set Terrassentuer closed' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' &&
ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')
{ fhem 'set Terrassentuer tilted' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' &&
ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')
{ fhem 'set Terrassentuer undef' }
}
das wären so meine ersten Ideen
Danke für die Beispiele und die Rückmeldung.
Die beiden Regex-Beispiele sind jetzt oben drin, ebenso der Code-Schnipsel zu dem doppelten Fensterkontakt als neues Beispiel.
Zu dem EVTPART[1]-Thema fehlt mir etwas mehr an praktischem Hintergrund, wann das konkret auftritt, außerdem ist das etwas, was ggf. dann eigentlich zu komplexeren Fragestellungen gehört. Das würde dann besser in myUtils-Beispiele passen, oder?
Es gibt jetzt auch den separaten Abschnitt "Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging (https://wiki.fhem.de/wiki/Notify#Mein_notify_geht_nicht_-_wie_kann_ich_mir_selbst_helfen:_Debugging)". Allerdings taucht der "gefühlt" sehr weit unten auf, aber einfach so wollte ich den wizard auch nicht auslagern.
Dann habe ich nach kurzer Konsultierung der commandref einfach mal behauptet, dass EIB durch KNX ersetzt werden kann.
Zitat von: Beta-User am 10 Juli 2018, 14:56:24
- Soll das mit dem Regex-Wizzard so stehen bleiben? (ich habe den bisher weitestgehend ignoriert und müßte erst prüfen, ob die Darstellung und Funktionalität noch einigermaßen aktuell ist). Wenn es aktuell ist: Auslagern oder an dieser Stelle belassen?
Aktuell sollte das noch sein oder ich habe eine Änderung von Rudi verpasst.
Den Abschnitt dazu kann man aber auch auslagern, wenn Du meinst, dass das besser separat/irgendwo anders stehen sollte.
Das von mir gewählte Beispiel und die Screenshots dazu sind sowieso nicht so dolle.
Zitat- Kann ich "EIB" einfach durch "KNX" ersetzen?
Keine Ahnung, aber wenn Du es kontrolliert hast. :)
Umstellung auf ein anderes System ist natürlich auch möglich.
Zitat von: Beta-User am 10 Juli 2018, 14:56:24
Zu dem EVTPART[1]-Thema fehlt mir etwas mehr an praktischem Hintergrund, wann das konkret auftritt, außerdem ist das etwas, was ggf. dann eigentlich zu komplexeren Fragestellungen gehört. Das würde dann besser in myUtils-Beispiele passen, oder?
es sollte imho auch in diesen Eintrag ...
das EVTPART Problem kannst Du ganz einfach nachvollziehen :-)
Erstelle ein notify für irgendwas was nur On@Off hergibt und nutze dann im Noty z.b. $EVTPART5 und schaue was passiert ;-)
Danke an Christian für den netten Zaunpfahl ::) .
Ich habe das eben mal weitestgehend "entKNXt" und bei dem verbliebenen Beispiel ziemlich unten dann ein paar willkürliche :dtp1 verteilt - wer es besser weiß, mag das korrigieren oder gegen was anderes ersetzen, was er kennt, aber nicht HM ist (dafür will ich nicht verstärkt Werbung machen...).
Und wer die MiLight-Devices gegen was besseres ersetzen kann: gerne ;) (ich habe die Dinger mittlerweile via MQTT am laufen, aber da ist mir auf die Schnelle keine knackige Darstellung eingefallen und das wirkt ggf. auch etwas exotisch).
Mit den EVTPART-Dingen konnte ich mich nicht durchringen, das zu erweitern, das ist ja auch nur das letzte Beispiel überhaupt relevant. Und wer mag, kann sich gerne den anderen Artikel vornehmen oder das hier ergänzen. Wege, mein FHEM abzuschießen bzw. das WEB-Interface kenne ich auch so schon genug 8) .
Der Wizard darf nun m.E. auch bleiben, wo er ist :) .
Vielleicht mag jemand noch nicht betriebsblindes nochmal nachsehen, wie viele Schreibfehler und optische Verbesserungsmöglichkeiten er entdeckt, aber ich wäre für's erste eigentlich ziemlich durch - Anregungen sind selbstredend weiter willkommen.
ich habs gerade mal überflogen :)
aufgefallen ist mir im Beispiel
Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird (https://wiki.fhem.de/wiki/Notify#Einschalten_von_mehreren_Ger.C3.A4ten.2FLampen.2C_wenn_das_Licht_eingeschaltet_wird)
das bei den geräten einmal was von steckdosen und einmal von stehlampen steht.
soll das so sein?
und auch gerade gesehen bei der definition für Stehlampe1 steht noch was von KNX
thx, ist korrigiert...
Ich arbeite momentan an dem Abschnitt debugging. Ich habe dort schon etwas ergänzt und umgestellt - aber es gefällt mir noch nicht. Also schaut bei Gelegenheit mal drauf - ich gebe eine Fertigmeldung ab der dann gemeckert werden kann/darf/soll :)
Gruß Otto
So - Feuer frei :)
https://wiki.fhem.de/wiki/Notify#Mein_notify_geht_nicht_-_wie_kann_ich_mir_selbst_helfen:_Debugging
ich war mutig und habe es ziemlich komplett verändert. Bei jedem Lesen fällt mir noch was auf, aber ich nehme jetzt mal Abstand.
Schönes Wochenende
Otto
In der Einführung gibt es einen Satz, der einfacher und klarer formuliert werden könnte.
ZitatDas Hilfsmodul notify dient dazu, Aktionen abhängig vom Eintritt bestimmter Bedingungen - in FHEM als [Event] bezeichnet - auszulösen bzw. zu prüfen, ob diese ausgelöst werden sollen.
Ein notify reagiert nicht auf das Eintreten bestimmter Bedingungen, sondern auf Ereignisse (Events) und löst dann Aktionen aus, abhängig von abgefragten Bedingungen.
Daher mein Vorschlag:
ZitatDas Hilfsmodul notify dient dazu [[Ereignis|Ereignisse]] über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen.
Desweiteren sollte eine Besonderheit des Suchmusters nicht unerwähnt bleiben, da das Suchmuster häufig mit einem Regulären Ausdruck gleichgesetzt wird. In einem notify wird das Suchmuster ergänzt um ein Beginnzeichen ^ und ein Endezeichen $.
In einer üblichen Mustersuche mit einem Regulären Ausdruck, wie er z.B. in https://perldoc.perl.org/perlre.html beschrieben wird, funktioniert folgendes
Wenn der Reguläre AusdrucK
lampe ist und das Ereignis
tischlampe dann passen
tischlampe und
lampe zueinander.
Im notify
Wenn das Suchmuster
lampe ist und das Ereignis
tischlampe dann passen
tischlampe und
lampe nicht zueinander, weil das Suchmuster zu
^lampe$ ergänzt wird.
Edit: Wiki ergänzt.