Unescaped left brace in regex is deprecated ... 33_readingsGroup.pm line 1381

Begonnen von linuzer, 01 Mai 2017, 22:20:57

Vorheriges Thema - Nächstes Thema

linuzer

Hallo Liebe Experten!

Ich habe seit ca. 2 Jahren folgende ReadingsGroup zum Anzeigen der Temperaturen und Heizungswerte im Einsatz:


define Klimawerte readingsGroup <Raum>,<T-ist>,<T-∅>,<H-rel>,<H-abs>,<T-soll>,<Ventil>,<Modus>\
*._Temp:temperature,average-temp,humidity,absHumidity,desired-temp@{$DEVICE=~s/Temp/Heizung_Clima/;;$DEVICE;;},ValvePosition@{$DEVICE=~s/Temp/Heizung_Clima/;;$DEVICE;;},controlMode@{$DEVICE=~s/Temp/Heizung_Clima/;;$DEVICE;;}


Seit einiger Zeit (genau kann ich das leider nicht eingrenzen) habe ich aber tonnenweise diese 3 Fehlermeldungen im Logfile:

Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^controlMode@{ <-- HERE $DEVICE=~s/Temp/Heizung_Clima/;$DEVICE;}$/ at ./FHEM/33_readingsGroup.pm line 1381.
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^desired-temp@{ <-- HERE $DEVICE=~s/Temp/Heizung_Clima/;$DEVICE;}$/ at ./FHEM/33_readingsGroup.pm line 1381.
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^ValvePosition@{ <-- HERE $DEVICE=~s/Temp/Heizung_Clima/;$DEVICE;}$/ at ./FHEM/33_readingsGroup.pm line 1381.


Offensichtlich ist desired-temp@{$DEVICE=~s/Temp/Heizung_Clima/;;$DEVICE;;} dieser Teil des define (und analog bei ValvePosition und controlMode) das Problem. Was mich etwas verwirrt, sind die doppelten Semikolon, die nur direkt in der fhem.cfg angezeigt werden, nicht jedoch im Interface ... aber ich vermute mal, das ist nicht das Problem.

Sehr wahrscheinlich hat das mit einer Codeänderung in FHEM zu tun und ist vermutlich auch bekannt ... alleine, ich habe die Lösung bisher nicht finden können. Kann mir irgend jemand helfen, bzw. auf die richtige Spur bringen? Das wäre echt super!

Vielen Dank!

linuzer

Ich möchte noch ein paar weitere Details hierzu geben:

Ich habe versucht zeitlich einzugrenzen, seit wann dieser Fehler auftritt und ich bin erstaunt, dass das erste Auftreten bereits am 9.1.2017 waren - allerdings in relativ seltener Häufigkeit. Im März (ich habe monatliche Logfiles) hat sich die Größe in etwa verdoppelt (auf 45 MB), im April ist es dann gewissermaßen "explodiert" auf 611 MB(!) Normal wären so um die 20 MB / Monat.

Wenn ich die oben genannten 3 Spalten wegnehme, tritt kein Fehler mehr auf.

Ich habe dann die Spalten umgeschrieben in Anlehnung an das Wiki (https://wiki.fhem.de/wiki/ReadingsGroup#Readings_aus_zus.C3.A4tzlichen_Devices)
...,desired-temp@{valveOfDevice($DEVICE)}

#namen des ventil device aus thermostat device ableiten
sub valveOfDevice ($) {
  my ($DEVICE) = @_;
 
  $DEVICE=~s/Temp/Heizung_Clima/;
  return $DEVICE;
}


Aber der Fehler tritt genauso auf, es wird ja auch die erste "{" angemeckert.

Also, für mich sieht es nach einem Bug in 33_readingsGroup.pm aus ... aber kann das sein?
Wer hat denn noch Werte aus verschiedenen Devices in einer ReadingsGroup? Tritt der Fehler bei Euch auch auf?

Ach und übrigens, die ReadingsGroup scheint tadellos zu funktionieren! Also die Spalten werden korrekt angezeigt! Es ist nur die unglaubliche Masse an Fehlermeldungen im Logfile, die ein Problem sind.

linuzer

Noch eine Beobachtung:

Die Fehlermeldung sagt ja, dass es um die Zeile 1381 in 33_readingsGroup.pm geht, die da lautet:
next if( defined($regex) && $reading !~ m/^$regex$/);

Somit ist offensichtlich die Ursache, dass die Variable $regex (die, soweit ich das sehe, die Spaltendefinition "desired-temp@{valveOfDevice($DEVICE)}" enthält), in einer weiteren Regex eingeschlossen ist. Und da die Spaltendefinition ein unescaped "{" enthält, wird die Meldung ausgegeben.

Also, dachte ich mir, machste halt ein Escape-Zeichen vor die Klammer: "desired-temp@\{valveOfDevice($DEVICE)}"
Und in der Tat, die Fehlermeldung lässt sich dadurch unterdrücken! Der Haken an der Sache: Jetzt wird die Spalte in der ReadingsGroup gar nicht mehr angezeigt  >:(

Also, entweder bin ich hier komplett auf dem Holzweg, oder es ist ein handfester Bug in 33_ReadingsGroup.pm.
Hat denn gar keiner eine ReadingsGroup mit Werten aus unterschiedlichen Devices im Einsatz? Dann muss der Fehler doch auch bei anderen auftreten!

Kann mir wirklich gar niemand weiter helfen?  :'(

supernova1963

Hallo linuzer,

vorab, ich kann dir keine Lösung präsentieren, möchte aber lernen.
Wenn ich deine Funktion richtig lese, wird dem $DEVICE irgendetwas zugeordnet, was das Modul als regex interpretiert. In dem Beispiel aus dem Wiki wird jedoch keine regex sondern jeweils ein gültiger Device-Name für die Funktion [reading]@[device] übergeben.
Ist das ein besonderer Trick das Device durch eine regex zu ersetzen? Wie wird das dann dargestellt, wenn in einer Zelle der readingsgroup Tabelle mehrere Werte stehen?

Entschuldige bitte mein laienhafte Ausführungen.

Gernot

linuzer

Hallo Gernot,

nein, gar kein Problem, ich bin auch alles andere als ein Experte...

Meine RedingsGroup stellt die Temperaturen von meinen Thermometer-Devices (jeder Raum in einer Zeile) dar. In den letzten Spalten möchte ich dazu die Werte der Heizungsventile anzeigen. Dazu muss sich die ReadingsGroup aber dynamisch den Namen des Clima-Devices der Heizungsventile aus dem Namen des Temp-Devices ableiten (weil ja für jeden Raum/Zeile der Name ein anderer sein muss). Das geht, weil die Devices bei mir alle nach dem gleichen Schema benannt sind, und ich nur jeweils im Namen "Temp" durch "Heizung_Clima" ersetzen muss.

Meinen Originalentwurf "desired-temp@{$DEVICE=~s/Temp/Heizung_Clima/;$DEVICE;}" hatte ich vor 2 Jahren irgendwo hier aus dem Forum kopiert. Der Manipuliert den Namen mit einer RegEx direkt.

Im Wiki wird die RegEx in eine Funktion ausgelagert, die genau das selbe macht.

supernova1963

Hallo linuzer,

danke für die Erklärung. Erfolgt durch: $DEVICE =~ m/AZ/ neben der Rückgabe true|false für die "if-Bedingung" auch eine Ersetzung (Funktion aus dem Wiki) ?

Ich muss mich tiefer in die regex Möglichkeiten einarbeiten!

LG

Gernot

linuzer

Zitat von: linuzer am 05 Mai 2017, 01:35:17
Hat denn gar keiner eine ReadingsGroup mit Werten aus unterschiedlichen Devices im Einsatz? Dann muss der Fehler doch auch bei anderen auftreten!

Tut er auch: https://forum.fhem.de/index.php/topic,14425.msg548375.html#msg548375

Und ich vermute, er tritt noch sehr viel häufiger auf, aber da die ReadingsGroup ja soweit funktioniert, wird die Meldung im Log wohl nicht häufig wahrgenommen, oder schlicht ignoriert (...wie ja auch bei mir). Mich würde die Meldung ja auch nicht weiter stören, wenn sie nur nicht mein Logfile so exorbitant zumüllen würde, dass ich in 4 Wochen 600 MB Logfilegröße bekomme...! Und dieses gigantische Wachstum ist erst seit kurzem, so Mitte April etwa...

Es wäre schön, wenn Andre mal was dazu sagen könnte... Vielleicht ist es ja nur eine Kleinigkeit...(hoffe ich!)

LG linuzer

supernova1963

Ich nochmal mit einem laienhaften Vorschlag (weil das abrufen fremder Devices, zwar ohne regex-Funktion, bei mir so funktioniert)

Hast du bereits die Funktion
...,desired-temp@{valveOfDevice($DEVICE)} durch
...,<{ ReadingsVal(valveOfDevice($DEVICE),"desired-temp","na")>
zuersetzen probiert.
Wenn's ohne Fehlermeldung funktioniert, liegt es vielleicht gar nicht an dem readingsGroup Modul?

LG

Gernot

linuzer

Hallo Gernot,

vielen Dank für Deine Mühe! Ich habe das probiert, bekomme aber die gleiche Fehlermeldung, weil ja auch bei Dir eine "{" vorkommt -- die ich im übrigen auch inhaltlich nicht verstehe, denn sie geht ja nicht mehr zu..  ??? Hast Du dieses Konstrukt in der Überschrift, oder in einer Zeile Deiner ReadingsGroup?

Mich würde halt ganz allgemein interessieren, was sich verändert hat, dass plötzlich diese Warnungen in so großer Menge auftauchen. Eines kann ich auf jeden Fall garantieren: Die Definition meiner ReadingsGroup hat sich seit 2 Jahren nicht verändert! Also muss entweder eine Änderung in FHEM "schuld" sein, oder eine Veränderung an meiner Umgebung -- natürlich spiele ich laufend die neuesten Updates ein (sowohl in FHEM, als auch in Linux).

Hier ist meine aktuelle System-Umgebung:
Ubuntu 17.04, neueste Updates, darunter Perl 5.24.1. Wenn noch andere Versionsstände von Interesse sind, bitte Bescheid sagen.

LG linuzer

supernova1963

Entschuldige bitte, korrekt wäre natürlich:
...,<{ ReadingsVal(valveOfDevice($DEVICE),"desired-temp","na")}>
Besser wäre noch vollständig nach perl verlagern:
...,<{ ReadAnderesDev($DEVICE)}>
mit der 99_myUtils Funktion:
sub
ReadAnderesDev($)
{
#Ermittlung des Wertes des Readings "desired-temp" eines anderen Devices
  my ($DEVICE) = @_;
#Die verwendete regex substitution unverändert
  $DEVICE =~ s/Temp/Heizung_Clima;
#Rückgabe Wert des readings des abgeänderten devices
  return ReadingsVal($DEVICE,"desired-temp","na")
}


Damit wollte ich eigentlich nur versuchen auszuschliessen, dass es sich um einen Fehler bei der Interpretation der regex im Modul readingsGroup handelt und die regex in ein perl-Script verlagern.
Das Endergebnis würde komplett in perl dynamisch ermittelt und als [String] mit <[String]> in die readingsGroup eingetragen, meiner Ansicht nach unabhängig von "Überschrift"  (ich weiss garnicht was eine "Überschrift" in readingsGroup definiert).

So, jetzt will ich nicht weiter verhindern, dass sich die Experten deines Problems annehmen, und dich nicht weiter nerven.

LG

Gernot

P.S.: Ich verwende in der Test-Umgebung ubuntu server 17.04 (GNU/Linux 4.10.0-20-generic x86_64) mit perl v5.24.1 und in der Live-Umgebung Ubuntu Server 16.04.2 LTS (GNU/Linux 4.4.0-77-generic x86_64) mit perl v5.22.1

linuzer

Hallo Gernot,

nein, du nervst überhaupt nicht, ganz im Gegenteil! Ich bin ja froh, wenn sich jemand Gedanken macht und mithilft ein Problem einzukreisen, bzw. zu lösen! ...und von den sonstigen "Experten" hat sich bisher ja auch keiner gerührt!

Also, die korrigierte Version hatte ich schon (und habe sie erneut) ausprobiert, aber mit dem gleichen Problem. Er meckert bei mir immer die erste "{" mit obiger Warnung an.
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^<{ <-- HERE $/ at ./FHEM/33_readingsGroup.pm line 1381.

Was ja echt spannend ist, bei Dir erscheint diese Warnung nicht im Logfile? Bei gleicher Ubuntu und Perl-Version! Das ist ja unglaublich! Wie kann das sein?
Welches global verbose-level verwendest Du denn? Ich bin auf 2.

LG linuzer

supernova1963

Hallo linuzer,

ich nutze im Live System 3 und im Test System verbose Level 3..
Hast du auch einmal allen Code in die 99_myUtils verschoben? Kommt der log Eintrag auch, wenn du nur eine Funktion innerhalb < > aufrufst?

LG

Gernot


linuzer

Hallo Gernot,

ich weiss nicht genau, was Du mit den beiden Fragen meinst:
ZitatHast du auch einmal allen Code in die 99_myUtils verschoben? Kommt der log Eintrag auch, wenn du nur eine Funktion innerhalb < > aufrufst?

Welchen Code soll ich verschieben?
Und die 2. Frage: etwa so? <{valveOfDevice($DEVICE)}>
Ja, habe ich probiert. Das Problem ist immer das erste Auftreten von "{".


linuzer

So, ich hab das Problem jetzt gewissermaßen "totgehauen": Ich habe in 33_redingGroup.pm ganz oben "use warnings" auf "no warnings" gesetzt und jetzt ist Ruhe und meine ReadingGroup geht wieder wie immer!  ;D 8)

Warum ich scheinbar der Einzige weit und breit bin, der diese Warnung tonnenweise bekommt ist mir schleierhaft, aber für meine Begriffe ist das Problem, dass 33_redingGroup.pm reguläre Ausdrücke auf eine Art und Weise nutzt, die heute zwar noch funktioniert, aber veraltet ist und in einer zukünftigen Version von Pearl gar nicht mehr gehen wird. Dann wird aus der Warnung ein harter Fehler werden und spätestens dann wird 33_redingGroup.pm überarbeitet werden müssen...

Bis dahin werde ich wohl leider bei jedem Update prüfen müssen, ob ich die Warnungen wieder ausschalten muss... >:(

supernova1963

Zitat von: supernova1963 am 07 Mai 2017, 10:37:37
...
Besser wäre noch vollständig nach perl verlagern:
...,<{ ReadAnderesDev($DEVICE)}>
mit der 99_myUtils Funktion:
sub
ReadAnderesDev($)
{
#Ermittlung des Wertes des Readings "desired-temp" eines anderen Devices
  my ($DEVICE) = @_;
#Die verwendete regex substitution unverändert
  $DEVICE =~ s/Temp/Heizung_Clima;
#Rückgabe Wert des readings des abgeänderten devices
  return ReadingsVal($DEVICE,"desired-temp","na")
}

....