HUEDevice Log vernünftig einstellen

[Beta-User]

Das Stichwort ist NOTIFYDEF. Den Unterschied sieht man aber nur, wenn wirklich ein Device vorhanden ist, das paßt, sonst nicht.

Und die Regex ist "o" gefolgt von entweder beliebig vielen "f" oder "n". Wie du auf "ok" kommst, ist mir nicht klar.

Siehe auch (Kurzfassung): https://forum.fhem.de/index.php/topic,116701.0.html, und (Langform) Grundsätzliche Codingfragen / Performance: https://forum.fhem.de/index.php/topic,117075.0.html

[CoolTux]

Habe das bei regex101 getestet, aber mein altes Tablet hat da einen Streich gespielt und nicht korrekt angezeigt. Ich schaue mir die Threads gerne an.

[Beta-User]

Dann mal viel Spaß beim Stöbern.

Der "ausführliche" Thread ist btw. der Anlaß, warum ich so nachdrücklich hinter diesen vermeintlichen "Kleinigkeiten" her bin wie unsaubere Trigger bei allen möglichen Event-Handlern und fehlenden trigger-Angaben bei userReadings.
Wie man in diesem "Performance"-Thread erkennen kann, gibt viel Kleinzeug am Ende halt ein komplett unperformantes System (OT: ich glaube nicht, dass andere Lösungen die zugrundeliegenden Themen besser lösen, sondern ggf. nur besser verstecken).

Von daher:

Wie gesagt, du hast mit keiner Zeile geschrieben das der Vorschlag schlecht oder falsch ist !
Und jetzt sprichst du von "Mogeleien" ?
Warum hast du denn nicht einfach dazu gesagt: Achtung! Was der da geschrieben hat ist bullshit, wenn du das machst stürzt FHEM ab und wir haben Klimawandel !
[...]
Ok...vielleicht bist du gerade genervt, wovon auch immer. Kommt vor, dafür kann ich aber nichts.   

Zwei Dinge nerven mich tatsächlich:
a) dass allgemein (auch in Entwicklerkreisen) diese Themen eher weniger bekannt sind
b) dass User wie du nicht "freundliche Schubser" ernster nehmen und gleich irritiert sind, wenn man nicht gleich "bullshit" ruft. Das wäre nämlich sachlich falsch, auch die "unsaubere Fassung" funktionier ja.

Daher "lieber"...

Ansonsten hätte ich mir ja die Mühe sparen können, überhaupt was zu schreiben .

Schönes entspanntes WE allen,

Beta-User

[CoolTux]

Dann mal viel Spaß beim Stöbern.

Der "ausführliche" Thread ist btw. der Anlaß, warum ich so nachdrücklich hinter diesen vermeintlichen "Kleinigkeiten" her bin wie unsaubere Trigger bei allen möglichen Event-Handlern und fehlenden trigger-Angaben bei userReadings.
Wie man in diesem "Performance"-Thread erkennen kann, gibt viel Kleinzeug am Ende halt ein komplett unperformantes System (OT: ich glaube nicht, dass andere Lösungen die zugrundeliegenden Themen besser lösen, sondern ggf. nur besser verstecken).

Von daher:Zwei Dinge nerven mich tatsächlich:
a) dass allgemein (auch in Entwicklerkreisen) diese Themen eher weniger bekannt sind
b) dass User wie du nicht "freundliche Schubser" ernster nehmen und gleich irritiert sind, wenn man nicht gleich "bullshit" ruft. Das wäre nämlich sachlich falsch, auch die "unsaubere Fassung" funktionier ja.

Daher "lieber"...

Ansonsten hätte ich mir ja die Mühe sparen können, überhaupt was zu schreiben .

Schönes entspanntes WE allen,

Beta-User

In der Tat ist dieses Thema zu ganze an mir vorbei gegangen. Liegt wohl daran das dies eine allgemeine Eigenart von FHEM ist.
Ich bin aber nun gerade dabei dies auf zu arbeiten. Werden wohl noch Fragen aufkommen mein lieber Jörg. Ich melde mich 

[Beta-User]

In der Tat ist dieses Thema zu ganze an mir vorbei gegangen. Liegt wohl daran das dies eine allgemeine Eigenart von FHEM ist.
Ich bin aber nun gerade dabei dies auf zu arbeiten. Werden wohl noch Fragen aufkommen mein lieber Jörg. Ich melde mich 

Gerne.

Bei der Gelegenheit noch ein mysteriöser Hinweis auf eine weitere "Kammer der Mysterien" - das "Reihenfolgeproblem" bei mehreren voneinander abhängigen Eventhandlern. Startpunkt wäre hier: https://forum.fhem.de/index.php/topic,124813.0.html

[CoolTux]

Und da ist er schon.

Nur damit ich das mal verstehe. Die Aussagen im ersten von Dir verlinkten Thread das der Parser nur dieses und jenes aber nicht solches versteht führt mich zu der Annahme das ich einen erheblichen Mehraufwand beim erstellen von Notifys (RegEx) habe. Aber das kann man sich ja dann mal anschauen.
Nun erstmal ein einfaches Beispiel.
Wenn ich das richtig verstanden habe listet mir ein:

Code Auswählen Erweitern

list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF
alle Notifys auf welche eine nicht optimale RegEx besitzen, korrekt?

Ein

Code Auswählen Erweitern

r(r|g)_\w+:location:.Haustuer
ist also dabei. Wenn ich nun Deinem Beispiel von oben folge sollte ein

Code Auswählen Erweitern

r[rg]_\w+:location:.Haustuer
besser sein.

Dennoch wird nach einem

Code Auswählen Erweitern

list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF
wieder dieses Notify gelistet. Scheint also noch nicht korrekt zu sein. Interessant wird es für mich bei so einem Beispiel.

Code Auswählen Erweitern

Fensterkontakt.*(_F[1-4]|Dachfenster):(open|closed)

oder

Code Auswählen Erweitern

HandyMarko:batteryPercent:.(100|9[0-9])

Auf was genau kann ich meine RegEx strecken bei einer Aussage wie

Der Parser  versteht nur sowas wie dev1 oder dev1:event1 oder dev1:event1|dev2:event2. Folgendes kapiert er nicht: dev:(event1|event2), und sowas wie dev.*event schon gar nicht. Nicht exisitierende dev's oder "Teilprobleme" fuehren auch zu einem "unoptimierten" Regex.

dev1:event1 oder dev1:event1|dev2:event2

kann kaum Zielführend sein. Dann kann ich gleich alle events einzeln aufzählen.

Code Auswählen Erweitern

r[rg]_\w+:location:.Haustuer
Das hier scheint zu mindestens laut regex101 zu matchen


Ja das mit dem "Reihenfolgeproblem" bei mehreren voneinander abhängigen Eventhandlern hatte ich mitgelesen. Anstrengend 


Nur mal so am Rande. Das ganze Notify RegEx Dingens schreit förmlich nach einem Webinar 

[Beta-User]

Generell: Rudi hatte mich wegen meiner "tiefergelegten regexe" auch mal auf's Glatteis geführt. Da habe ich gelernt: der interne Parser ist deutlich was anderes wie normale regex...

Du solltest dich in Martins Thread im Developer-Bereich einklinken .

Auf die Schnelle erst mal:
\w+ kann man sich sparen, weil Devicenamen nie Leerzeichen enthalten => .* oder .+;

Immer, wenn runde Klammern und Pipes zusammenkommen, ist das "tödlich" => Bandwurm (ja, meine <trigger> sehen zwischenzeitlich wirklich so aus...).

Das ist alles nicht sonderlich schön, lustig oder intuitiv. Daher: Martins Thread...

[CoolTux]

Meinst Du mit Martins Thread den 2. von Dir verlinkten weiter oben?

[Beta-User]

Nein, den "Attribute für notify+at"-Thread

[CoolTux]

Nein, den "Attribute für notify+at"-Thread

Ah den. Ja den habe ich etwas mitgelesen. Danke Dir.

[CoolTux]

Bin gerade echt geplättet

Code Auswählen Erweitern

rr_.*:location:.Haustuer|rg_.*:location:.Haustuer
Schön das dieses hier akzeptiert wird verliert aber jegliche Flexibilität.
Gerade bei meinen virtuellen Fensterkontakten reichte es einfach einen neuen anzulegen und mehr musste ich nicht machen. Wenn ich nach dieser Methode hier gehen würde müsste ich jedesmal das Notify erweitern. Sorry aber das ist doch "krank". Es muss besser gehen 

[CoolTux]

Aus einem einfachen

Code Auswählen Erweitern

Fensterkontakt.*(_F[1-4]|Dachfenster):(open|closed)

muss ein

Code Auswählen Erweitern

Fensterkontakt.*:open|Fensterkontakt.*:closed

Und das wäre unglaublich ungenau. Ausserdem kann man nach ansetzen einer RegEx anscheinend keinen weiteren RegEx Teil mehr einsetzen

Code Auswählen Erweitern

{notifyRegexpCheck('Fensterkontakt.+')}

Code Auswählen Erweitern

Fensterkontakt.+: devspec FensterkontaktBadezimmer_F1,FensterkontaktDachfenster,FensterkontaktSteven_F1,FensterkontaktSteven_F2 (OK)

Code Auswählen Erweitern

{notifyRegexpCheck('Fensterkontakt.+zimm.*')}

Code Auswählen Erweitern

Fensterkontakt.+zimm.*: no match (ignored)

Sorry aber das absolut inakzeptabel.

[justme1968]

ihr verrennt euch glaube ich gerade etwas.

notifyRegexpCheck ist nicht dazu da die regex wirkich zu prüfen. das wäre garnicht möglich ohne sie wirklich auszuführen.

es ist dazu da eine version zu finden die man schneller prüfen kann um möglichst viele falsche matches zu erkennen und die eigentliche regex in der device NotifyFn so selten wie möglich auszuführen. aber ohne das aus versehen ein richtiger match übersehen wird.

es geht hier darum einfach fälle zu erkennen ohne die echte regex bemühen zu müssen. deshalb ist es hier völlig ok wenn ein event durchgelassen wird das eigentlich nicht matched. so lange es nicht zu oft passiert. das wird dann später in der echten regex prüfung abgefangen. umgekehrt wäre es aber ein problem.

wenn man notifyRegexpCheck genauer machen würde (was beliebig kompliziert werden kann) wäre es auch langsamer und somit sinnlos da man dann auch gleich die richtige regex prüfen könnte.

das bedeutet umgekehrt auch das man sich bei der eingabe für notifyRegexpCheck nicht verkünsteln sollte um die aufgabe nicht noch schwerer zu machen als sie schon ist.

[CoolTux]

Es wird immer schlimmer

Code Auswählen Erweitern


(AnniKraussStr|r(r|g)_.*):(home|absent|gone)


Wird zu

Code Auswählen Erweitern

AnniKraussStr:home|AnniKraussStr:absent|AnniKraussStr:gone|rr_.+:home|rr_.+:absent|rr_.+:gone|rg_.+:home|rg_.+:absent|rg_.+:gone


Von dem ganzen mal ob. @Andre Ich glaube ich stehe gerade alleine da mit dem verrennen.

Also was ich verstehe, es macht Sinn die RegEx so zu wählen das NOTIFYDEV funktion hat. Also lediglich auf die tatsächlich gemeinten Devices die NotifyFn aufzurufen. Aber alles andere kann doch meiner Meinung nach Flexibel bleiben.

So kann ich meiner Meinung nach aus

Code Auswählen Erweitern

AnniKraussStr:home|AnniKraussStr:absent|AnniKraussStr:gone|rr_.+:home|rr_.+:absent|rr_.+:gone|rg_.+:home|rg_.+:absent|rg_.+:gone

Doch noch ein

Code Auswählen Erweitern

AnniKraussStr:(home|absent|gone)|rr_.+:(home|absent|gone)
machen können. So das vernünftig die Devices erkannt werden. Aber das funktioniert leider nicht.

[Beta-User]

Na ja.

Ausgangspunkt war: Einfacher Eventhandler, nicht optimierter <trigger>.

Sollte man ab einem bestimmten Level "ja klar" rufen, wenn da der Vorschlag zur Optimierung kommt.

Es ist aber auch "nur" eine Option, wie man Dinge optimieren kann.

Bei deinen "Kopfzerbrechern" ist es vielleicht so, dass eine "if"-Abfrage nach dem Event und direktes Rausspringen effizient wäre, wenn es "das falsche" ist.

Bei anderen "Sammel-Regexen" ist es besser, einen "Global-Handler" ohne NOTIFYDEV zu haben wie viele kleine (nicht optimierte) Event-Handler.

Kurz: Man muss es im Einzelfall entscheiden, welcher Weg der passende ist, und (v.a.) man sollte alle Wege kennen.

That's all...

(Ansonsten wäre es besser, grundlegende Design-Fragen im Developer-Bereich zu diskutieren, auch wenn das Niveau da so hoch ist, dass ich auch den Eindruck habe, nicht qualifiziert genug zu sein, um da was substantielles beizutragen).