notifyRegexpChanged() mit devspec in NOTIFYDEV

[Markus Bloch]

Hallo Rudi,

anbei ein Patch, der notifyRegexpChanged() um folgende Expressions erweitert:

Code Auswählen Erweitern

NameA.*
NameA.+
NameA.*|NameB.*
(NameA.*|NameB.*)

Da in NOTIFYDEV nun devspecs erlaubt sind, sind dies valide Angaben, die man in NOTIFYDEV verwenden kann. Da NOTIFYDEV eine devspec ist, muss man auch nicht mehr jedesmal auf $defs{$name} prüfen, da dies in createNtfyHash() bzw. devspec() bereits geprüft wird.

Viele Grüße

Markus

[rudolfkoenig]

Da NOTIFYDEV eine devspec ist, muss man auch nicht mehr jedesmal auf $defs{$name} prüfen, da dies in createNtfyHash() bzw. devspec() bereits geprüft wird.

Der Haken damit ist, dass falls bei dieser Regexp-Pruefung etwas faelschlicherweise akzeptiert wird, aber bei devspec2array nicht, dann wird NotifyFn nicht aufgerufen. Andersrum ist der Schaden geringer, es ist in bestimmten Faellen halt nicht optimiert.

Da mein Bauchgefuehl protestiert (auch wenn ich kein Gegenbeispiel finden konnte), haette ich gerne einen Dritten, der dein Regexp versteht, und auch der Ansicht ist, dass es gutgeht.

[Markus Bloch]

Den einzigen Negativ-Fall der mir hierzu einfällt ist, wenn man ein Doppelpunkt mit einem einzelnen Punkt maskiert und damit den Eventteil reinschummelt:

Code Auswählen Erweitern

LampeWohnzimmer.on

In dem Falle würde mit meinem Patch dies als devspec in NOTIFYDEV gesetzt, obwohl es kein Ergebnis liefern würde. Ich könnte ähnlich wie zuvor prüfen, ob diese devspec zu einem Ergebnis führen würde (!= undef && != $1)

[justme1968]

der fall ist aber recht häufig. ich mache das und habe das auch schon mehrfach empfohlen weil es (zumindest) früher (in bestimmten fällen) nötig war.

nebenbei finde ich es auch übersichtlicher wenn man den : auf den ersten blick nur als trenner zwischen device und reading sieht. 

[rudolfkoenig]

Ein Lob auf mein Bauchgefuehl

[Markus Bloch]

Mit der Prüfung auf Resultate durch devspec2array() würde in diesem Fall kein Ergebnis kommen, wodurch @list != @list2 ist und dann kein NOTIFYDEV gesetzt werden würde. Damit wäre dieser Fall ausgemerzt und es würde weiterhin funktionieren.

[Markus Bloch]

Anbei nochmal eine überarbeitete Version.

Es wird NOTIFYDEV nur gesetzt, wenn das jeweilige Pattern aus Buchstaben/Zahlen/Unterstrich/Punkt nur am Ende optional mittels .* oder .+ endet und devspec2array ein Ergebnis liefert oder $defs{...} existiert.

Dabei werden nur Patterns akzeptiert (also für NOTIFYDEV verwendet), welche mit normal Zeichen beginnen und optional mit .*/.+ (nur die beiden Varianten!) enden. Somit ist ausgeschlossen, dass evtl. das Pattern für den Event-Teil gedacht ist und nicht für den Devicenamen. Dadurch werden Patterns die mit Wildcards beginnen, oder evtl. welche in der Mitte besitzen nicht als NOTIFYDEV benutzt. Bspw:

Code Auswählen Erweitern

NAME.on
.*NAME.*
NAME.*on
NAME..+


Im Gegenzug werden Patterns erkannt wie bspw:

Code Auswählen Erweitern


DefinitionA.*
DefinitionA.*:on
(DefinitionA.*:on|DefinitionB.*:off)



Ich habe desweiteren nach reichlicher Überlegung die Limitierung auf max. 10 Elemente in NOTIFYDEV entfernt. Primärer Grund war die Übersichtlichkeit in FHEMWEB. Da NOTIFYDEV auf einer Regexp beruht, welche durch den Nutzer als Define-Argument oder Attribut gesetzt wird, taucht diese eh in der Oberfläche auf. Da die Regexp i.d.R. länger sein wird als der Inhalt von NOTIFYDEV, macht es keinen Unterschied. Man kann es desweiteren nicht an einer Zahl fest machen, ob NOTIFYDEV merklich Performance bringt oder nicht, da das sehr von der Größe der Installation und der HW-Performance abhängt.

Da notifyRegexpChanged() nun auch in watchdog benutzt wird, kommt es dort gerne mal vor, dass 2mal der selbe Definitionsname in NOTIFYDEV steht, daher werden bei mehrfachen Einträgen in NOTIFYDEV vorher Duplikate entfernt.

Hab es bei mir ausgiebig getestet.

Gruß
Markus

[rudolfkoenig]

Ich muss mein Bauchgefuehl doch weniger loben: Dein Beispiel mit  LampeWohnzimmer.on haette in deinem ersten Beispiel zum Loeschen der NOTIFYDEV gefuehrt, da du nur .+ am Ende zugelassen hast.

Ich habe jetzt das "Wesentliche" von deinem Patch uebernommen (den Abschnitt mit dem map), und den Rest (auch meins) entfernt. Damit bleibt nur die aufwendige Pruefung, das sollte alle Faelle abdecken, und der Code ist einfacher verstaendlich. Habs auch etwas ausgiebiger getestet, und eingecheckt.

Damit sollten folgende Regexps (bzw. alle moeglichen Kombinationen davon) abgedeckt sein:
dev
dev.*
dev:event
dev.*:event
(dev1)
(dev1|dev2)
(dev1:event1)|(dev2:event2)

Event darf ein beliebiger Regexp oder auch plain-text sein. Und statt .* geht auch .+.
Was (unter anderem) nicht funktioniert ist (dev1|dev2):Event. Bin aber nicht traurig drueber.

[Loredo]

Seit der Revision 13141 erhalte ich beim starten von Fhem leider nur noch diese Fehlermeldung auf meinen Mac mit Perl 5.24.0:

Code Auswählen Erweitern


Experimental keys on scalar is now forbidden at fhem.pl line 4531.


[rudolfkoenig]

Danke, habs gefixt.

[Loredo]

Merci