Hallo zusammen,
folgendes REGEX wird m.E. von fhem nicht korrekt ausgewertet:
set .*(?<!^LNA)_Innensteck.*:FILTER=state=off:FILTER=TYPE=FBDECT on
Darauf sollte alles passen, was "_Innensteck" irgendwo im Suchstring hat, vom Typ FBDECT ist und ausgeschaltet ist außer dem Device, welches mit "LNA" anfängt. Laut REGEX-Tester ist das auch so. Fhem spricht jedoch mit diesem Suchstring gar kein Device an.
Mein RegEx Tester springt da nicht an.
https://regex101.com/
Genau den nehme ich auch.
Auf LNA_Innensteckdose springt er nicht an, auf alle anderen (z.B. WZ_Innensteckdose oder BAD_Innensteckdose) schon. Und genau das ist das gewünschte Verhalten, aber fhem tut es nicht.
Man sollte sowas nicht am Tablet testen. Hast Recht. Der regex101 geht in der Tat.
Hast Du mal versucht erstmal ohne Filter zu arbeiten um zu sehen das Dein RegEx in FHEM geht?
Natürlich :)
Ohne Filter gleiches (Fehl-)Verhalten.
Es scheint in der Tat an der RegEx in den () zu liegen. Genaueres kann ich aber nicht sagen. Muss ich erstmal in den Code schauen.
Das "Problem" scheint an dem "<" festgemacht werden zu können; dies wird wohl erst ab Perl 5.30 "... as an experimental feature ..." unterstützt.
http://chris.photobooks.com/regex/ (http://chris.photobooks.com/regex/) liefert
invalid regexp group
https://regex101.com/#p (https://regex101.com/#p) liefert je nach FLAVOR
The preceding token is not quantifiable
Einen reinen perl-Modus bietet keiner dieser Online-Tester ...
Anmerkung: ".*" als Einleitung für den regulären Ausdruck sollte überflüssig sein.
Zitat von: OdfFhem am 02 Januar 2020, 09:48:43
Das "Problem" scheint an dem "<" festgemacht werden zu können; dies wird wohl erst ab Perl 5.30 "... as an experimental feature ..." unterstützt.
http://chris.photobooks.com/regex/ (http://chris.photobooks.com/regex/) liefert
invalid regexp group
https://regex101.com/#p (https://regex101.com/#p) liefert je nach FLAVOR
The preceding token is not quantifiable
Einen reinen perl-Modus bietet keiner dieser Online-Tester ...
Anmerkung: ".*" als Einleitung für den regulären Ausdruck sollte überflüssig sein.
Ich hatte das < Mal weg gelassen. Ging dennoch nicht
Es geht konkret um die Funktion "negative lookbehind", die mit (?<!
Ausschlusskriterium)REGEXP definiert wird. Gematched wird alles, auf was REGEXP passt und dem das Ausschlusskriterium nicht voransteht.
Zitat
Prior to Perl 5.30, it worked only for fixed-width lookbehind, but starting in that release, it can handle variable lengths from 1 to 255 characters as an experimental feature.
Wenn ich das richtig verstehe, kann Perl < 5.30 das bereits mit genau definierten Zeichenfolgen, was erst ab 5.30 geht, ist das Matchen auf Zeichenfolgen mit dynamischer Länge.
A zero-width negative lookbehind assertion. For example /(?<!bar)foo/ matches any occurrence of "foo" that does not follow "bar".
Quellen: https://perldoc.perl.org/perlre.html , http://www.drregex.com/2019/02/variable-length-lookbehinds-actually.html
fhem> { "BAD_Innensteckdose" =~ m/.*(?<!^LNA)_Innensteck.*/ }
1
fhem> { "LNA_Innensteckdose" =~ m/.*(?<!^LNA)_Innensteck.*/ }
fhem> define LNA_Innensteckdose dummy
fhem> define WZ_Innensteckdose dummy
fhem> define BAD_Innensteckdose dummy
fhem> list .*(?<!^LNA)_Innensteck.*
fhem>
D.h. Regexp funktioniert innerhalb von perl gut (wozu verwendet man ueberhaupt Regexp-Tester?), aber devspec2array (und damit list, set, etc) es verbockt.
Und das wiederum liegt daran, dass devspec2array den Ausdruck auf Operatoren (=, <, >, etc) absucht mit
^(.*?)(=|!=|~|!~|<=|>=|<|>)(.*)$und damit den urspruenglichen Parameter in Name:.*(?, Operator:<, und Wert:!^LNA)_Innensteck.* aufteilt.
Ist wohl in diesem Fall falsch, mir faellt aber keine einfache Methode ein es zu fixen, ohne das Feature abzuschaffen.
Nachtrag: ein Workaround ist trivial:fhem> list NAME=.*(?<!^LNA)_Innensteck.*
BAD_Innensteckdose
WZ_Innensteckdose
fhem>
Der Workaround klappt :)
Danke, Rudi, und an alle anderen, die sich hier den Kopf zerbrochen haben!