Autor Thema: Unescaped left brace in regex is deprecated ... 33_readingsGroup.pm line 1381  (Gelesen 2640 mal)

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
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!

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
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.

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
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?  :'(

Offline supernova1963

  • Full Member
  • ***
  • Beiträge: 323
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
Fhemserver: Mac Mini - Parallels Desktop mit Ubuntu Server 18.04,
Module: Harmony, fakeRoku, FBAHA, Fritzbox, MQTT + espBridge + TASMOTA_DEVICE, HMCCU, Nmap, ...

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
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.

Offline supernova1963

  • Full Member
  • ***
  • Beiträge: 323
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
Fhemserver: Mac Mini - Parallels Desktop mit Ubuntu Server 18.04,
Module: Harmony, fakeRoku, FBAHA, Fritzbox, MQTT + espBridge + TASMOTA_DEVICE, HMCCU, Nmap, ...

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
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

Offline supernova1963

  • Full Member
  • ***
  • Beiträge: 323
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
Fhemserver: Mac Mini - Parallels Desktop mit Ubuntu Server 18.04,
Module: Harmony, fakeRoku, FBAHA, Fritzbox, MQTT + espBridge + TASMOTA_DEVICE, HMCCU, Nmap, ...

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
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

Offline supernova1963

  • Full Member
  • ***
  • Beiträge: 323
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
Fhemserver: Mac Mini - Parallels Desktop mit Ubuntu Server 18.04,
Module: Harmony, fakeRoku, FBAHA, Fritzbox, MQTT + espBridge + TASMOTA_DEVICE, HMCCU, Nmap, ...

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
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

Offline supernova1963

  • Full Member
  • ***
  • Beiträge: 323
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

Fhemserver: Mac Mini - Parallels Desktop mit Ubuntu Server 18.04,
Module: Harmony, fakeRoku, FBAHA, Fritzbox, MQTT + espBridge + TASMOTA_DEVICE, HMCCU, Nmap, ...

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
Hallo Gernot,

ich weiss nicht genau, was Du mit den beiden Fragen meinst:
Zitat
Hast 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 "{".


Offline linuzer

  • New Member
  • *
  • Beiträge: 49
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... >:(

Offline supernova1963

  • Full Member
  • ***
  • Beiträge: 323
...
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")
}
....
Fhemserver: Mac Mini - Parallels Desktop mit Ubuntu Server 18.04,
Module: Harmony, fakeRoku, FBAHA, Fritzbox, MQTT + espBridge + TASMOTA_DEVICE, HMCCU, Nmap, ...

Offline l2r

  • Sr. Member
  • ****
  • Beiträge: 536
ich habe das Problem auch
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Offline linuzer

  • New Member
  • *
  • Beiträge: 49
... für meine Begriffe ist das Problem, dass reguläre Ausdrücke auf eine Art und Weise benutzt werden, 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 ...
Ich glaube, das ist jetzt passiert! Habe deswegen einen neuen Thread aufgemacht: https://forum.fhem.de/index.php/topic,78034.0.html

Offline sfancy

  • New Member
  • *
  • Beiträge: 13
Ich habe die Warnung auch seit längerer Zeit.
2018.04.15 11:22:55 1: PERL WARNING: Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^desired-temp@{ <-- HERE $DEVICE.'_Clima'}$/ at ./FHEM/33_readingsGroup.pm line 1383.
2018.04.15 11:22:55 1: PERL WARNING: Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^controlMode@{ <-- HERE $DEVICE.'_Clima'}$/ at ./FHEM/33_readingsGroup.pm line 1383.

Die Definition dazu ist:
defmod Einzelne_Heizkoerper readingsGroup <%sani_heating@black>,<Ist>,<Soll>,<Ventil>,<Mode>,<Set>,<Batterie>,<Aktiv> model=HM-CC-RT-DN:FILTER=chanNo=^$:measured-temp,desired-temp,actuator,controlMode@{$DEVICE.'_Clima'},desired-temp@{$DEVICE.'_Clima'},state,batteryLevel,Activity
attr Einzelne_Heizkoerper commands {'desired-temp'=>'desired-temp:', 'state.CMDs_pending'=>'set $DEVICE burstXmit'}
attr Einzelne_Heizkoerper nameStyle style="font-weight:bold"
attr Einzelne_Heizkoerper notime 1
attr Einzelne_Heizkoerper room Heizkoerper
attr Einzelne_Heizkoerper valueColumns {'Set'=>'colspan="2"'}
attr Einzelne_Heizkoerper valueFormat {\
  if($READING =~ /temp/ && $VALUE =~ /(\d+)/)\
  {\
    return sprintf('%.1f °C', $VALUE);;\
  }\
  elsif($READING =~ /actuator/ && $VALUE =~ /(\d+)/)\
  {\
    return sprintf('%.0f %%', $VALUE);;\
  }\
  elsif($READING =~ /battery/ && $VALUE =~ /(\d+)/)\
  {\
    return '0' if($VALUE =~ /(\d+)/ && $VALUE < 2.1);;\
    return '25' if($VALUE =~ /(\d+)/ && $VALUE < 2.3);;\
    return '50' if($VALUE =~ /(\d+)/ && $VALUE < 2.5);;\
    return '75' if($VALUE =~ /(\d+)/ && $VALUE < 2.7);;\
    return '100' if($VALUE =~ /(\d+)/ && $VALUE >= 2.7);;\
    return '100' if($VALUE eq 'ok');;\
  }\
}
attr Einzelne_Heizkoerper valueIcon {\
  'state.CMDs_done' => '&nbsp;; &nbsp;; &nbsp;; &nbsp;;',\
  'state.CMDs_pending' => 'hourglass',\
  'state.CMDs_processing...' => 'refresh',\
  'batteryLevel.100' => 'measure_battery_100@green',\
  'batteryLevel.75' => 'measure_battery_75@green',\
  'batteryLevel.50' => 'measure_battery_50@green',\
  'batteryLevel.25' => 'measure_battery_25@darkorange',\
  'batteryLevel' => 'measure_battery_0@red',\
  'Activity.alive' => 'it_wifi@green',\
  'Activity.dead' => 'it_wifi@red',\
  'Activity' => 'it_wifi@darkorange'\
}
attr Einzelne_Heizkoerper valueStyle {\
  if($READING eq 'measured-temp' && $VALUE =~ /(\d+)/)\
  {\
    if($VALUE > 23) { 'style="color:red"' }\
    elsif($VALUE > 21.5) { 'style="color:darkorange"' }\
    elsif($VALUE > 20) { 'style="color:green"' }\
    elsif($VALUE <= 20) { 'style="color:blue"' }\
  }\
}

Problem ist die laut Doku vorgesehene "unescaped" Nutzung der geschweiften Klammer im Regex. Aus der Doku: "Regex kann die Form <regex>@{perl} haben, um Readings von einem anderen Gerät zu verwenden".

Ich habe etwas nachgeforscht. Laut https://unix.stackexchange.com/questions/238539/automake-error-unescaped-left-brace-in-regex-is-deprecated ist das seit Perl v5.22 deprecated und ab Perl v5.26 ein Syntax Error.

Geht dem Problem schon jemand nach?

 

decade-submarginal