(gelöst) Perl Fehler: String found where operator expected at (eval 2388259)???

[Pfriemler]

Ich bin mal wieder etwas ratlos. Ein eigentlich lange reibungslos funktionierendes DOIF (es ist aber maSgW kein DOIF-Problem, oder etwa doch?) wird im Ausführungsteil regelmäßig diesen Fehler:

Code Auswählen Erweitern

String found where operator expected at (eval 2388259) line 1, near "24." KSZ: ""


Der Ausführungsteil des DOIF bastelt einen String mit Kürzeln und Werten zusammen:

Code Auswählen Erweitern

(setreading intC state {("DZT: ".[FHT_DZ:temperature]." DBT: ".[HKThermostat2_Weather:temperature_av]." OBT: ".[HKThermostat1_Weather:temperature_av]." KBT: ".[KBThermostat_Weather:temperature_av]." KBH: ".[KBThermostat_Weather:humidity_av]." EWZ: ".[CUL_WS_47:temperature]." KSZ: ".[CUL_WS_13:temperature])})


Das sieht dann z.B. so aus:

DZT: 24.9 DBT: 23.2 OBT: 23.7 KBT: 22.8 KBH: 54 EWZ: 24.1 KSZ: 18.9

Die einzige Korrelation, die ich bis jetzt gefunden habe ist die: Wenn [CUL_WS_47:temperature] alias EWZ einen ganzzahligen Wert hat, gibt es den Fehler. Hier ist der Wert bspw. "24" statt "24.0" - alle anderen Sensoren liefern immer mit ".0". Auch [CUL_WS_47:temperature] alias KSZ ist gelegentlich ganzzahlig, das führt aber zu keinem Fehler (wenig überraschend allerdings, nur der Vollständigkeit halber angemerkt).

Habe ich trotz einem Dutzend Kontrollen einen Schreibfehler übersehen oder prinzipiell was falsch?


Was ich nicht verstehe: Wieso führt diese Konstellation zu einem Fehler?

[ToM_ToM]

Zeig mal das gesamte DOIF.

Ich finde den Ausführungsteil etwas merkwürdig.

Code Auswählen Erweitern

setreading intC state...
sagt mir dass dein Device intC heißt und du das Reading state ändern willst.
Ist das dahinter ein langer String den du in das Reading schreiben möchtest?
Wenn ja, dann versuch mal Anführungszeichen mit einem Backslash zu maskieren.

VG, Thomas

[Damian]

Ich bin mal wieder etwas ratlos. Ein eigentlich lange reibungslos funktionierendes DOIF (es ist aber maSgW kein DOIF-Problem, oder etwa doch?) wird im Ausführungsteil regelmäßig diesen Fehler:

Code Auswählen Erweitern

String found where operator expected at (eval 2388259) line 1, near "24." KSZ: ""


Der Ausführungsteil des DOIF bastelt einen String mit Kürzeln und Werten zusammen:

Code Auswählen Erweitern

(setreading intC state {("DZT: ".[FHT_DZ:temperature]." DBT: ".[HKThermostat2_Weather:temperature_av]." OBT: ".[HKThermostat1_Weather:temperature_av]." KBT: ".[KBThermostat_Weather:temperature_av]." KBH: ".[KBThermostat_Weather:humidity_av]." EWZ: ".[CUL_WS_47:temperature]." KSZ: ".[CUL_WS_13:temperature])})


Das sieht dann z.B. so aus:
Die einzige Korrelation, die ich bis jetzt gefunden habe ist die: Wenn [CUL_WS_47:temperature] alias EWZ einen ganzzahligen Wert hat, gibt es den Fehler. Hier ist der Wert bspw. "24" statt "24.0" - alle anderen Sensoren liefern immer mit ".0". Auch [CUL_WS_47:temperature] alias KSZ ist gelegentlich ganzzahlig, das führt aber zu keinem Fehler (wenig überraschend allerdings, nur der Vollständigkeit halber angemerkt).

Habe ich trotz einem Dutzend Kontrollen einen Schreibfehler übersehen oder prinzipiell was falsch?


Was ich nicht verstehe: Wieso führt diese Konstellation zu einem Fehler?

Wenn es im Ausführungsteil von DOIF ist, dann hast du zwei Möglichkeiten:

1. Die Readings in Anführungszeichen zu setzen:

{("DZT: "."[FHT_DZ:temperature]"." DBT: "....

oder

2. Die Readings in Klammern zu setzen:

{("DZT: ".([FHT_DZ:temperature])." DBT: "....

Die zweite Version funktioniert auch bei DOIF-Perl, weil die Readings dort nicht gegen Zahlen, sondern gegen Perl-Funktionen ersetzt werden.

[Pfriemler]

So schnell und zwei Lösungen. Ich werde beides probieren, zur Maskierung muss ich mich nochmal schlaulesen.

@ToM_ToM: Das DOIF wird eigentlich nur zyklisch ausgeführt alle 15min. Den irrelevanten Teil habe ich weggelassen. Ansonsten ist es richtig: ich befülle state von intC mit einem langen String. Irgendwann wurde mir diese Ausführungsart empfohlen, weil das entsprechende Events erzeugt, auf die ein FileLog reagiert (und es reagiert auf weitere drei Hilfsdummys). Die Konstruktion hat sich als platzsparendes noch menschenlesbares Logging bestens bewährt.

Abgesehen davon: wenn das Problem mit Damians Vorschlägen behoben werden kann, wieso hat es bis dahin funktioniert und warum ausgerechnet bei diesen ganzzahligen nicht? Wie gesagt: Ist der Wert "krumm", wird das Reading ohne Fehler gesetzt und damit sauber geloggt.

Und noch ein Randwitz, dessen Erscheinung ich unter "mystisches Grundrauschen" führe - gefunden auf der Suche warum es da überhaupt Unterschiede gibt:

Die Werte von CUL_WS_13 und CUL_WS_47 lasse ich separat loggen, daher habe ich das mit den Ganzzahlen. CUL_WS_13 erscheint auch bei Ganzzahlen mit ".0",

Code Auswählen Erweitern

2018-04-23_18:09:44 CUL_WS_13 T: 18.9  H: 60.6
2018-04-23_18:09:44 CUL_WS_13 temperature: 18.9
2018-04-23_18:09:44 CUL_WS_13 humidity: 60.6
2018-04-23_18:12:40 CUL_WS_13 T: 19.0  H: 60.6
2018-04-23_18:12:40 CUL_WS_13 temperature: 19.0
2018-04-23_18:12:40 CUL_WS_13 humidity: 60.6

CUL_WS_47 hingegen nicht:

Code Auswählen Erweitern

2018-04-23_11:28:27 CUL_WS_47 T: 24  H: 40.7  P: 1005
2018-04-23_11:28:27 CUL_WS_47 temperature: 24
2018-04-23_11:28:27 CUL_WS_47 humidity: 40.7
2018-04-23_11:28:27 CUL_WS_47 pressure: 1005
2018-04-23_12:35:45 CUL_WS_47 T: 23.9  H: 41.6  P: 1005
2018-04-23_12:35:45 CUL_WS_47 temperature: 23.9
2018-04-23_12:35:45 CUL_WS_47 humidity: 41.6
2018-04-23_12:35:45 CUL_WS_47 pressure: 1005

Die zugrundeliegenden Programmzeilen in 14_CUL_WS.pm (btw eine präparierte Version, die die Arten der Sensoren auf mehrere Dekaden mappt und dadurch mehr als 8 Sensoren ermöglicht, daher auch die zweistelligen Indizes) sind aber identisch und sollten immer mit Punkt liefern -> Zeilen "$tmp = " und deren Verwendung später in $val und $NotifyTemperature):

Code Auswählen Erweitern

    if($typbyte == 1 && int(@a) > 8) {           # temp/hum
...
      $tmp = $sgn * ($a[6].$a[3].".".$a[4]) + $hash->{corr1};
...
      $val = "T: $tmp  H: $hum";
      $devtype = "PS50";
      $family = "WS300";
      $NotifyType="T H";
      $NotifyTemperature=$tmp;
      $NotifyHumidity=$hum;
    }
...
    if($typbyte == 4 && int(@a) > 10) {          # temp/hum/press
...
      $tmp = $sgn * ($a[6].$a[3].".".$a[4]) + $hash->{corr1};
...
      $val = "T: $tmp  H: $hum  P: $prs";
      $devtype = "Indoor";
      $family = "WS7000";
      $NotifyType="T H P";
      $NotifyTemperature=$tmp;
      $NotifyHumidity=$hum;
      $NotifyPressure=$prs;
    }

[Damian]

Abgesehen davon: wenn das Problem mit Damians Vorschlägen behoben werden kann, wieso hat es bis dahin funktioniert und warum ausgerechnet bei diesen ganzzahligen nicht? Wie gesagt: Ist der Wert "krumm", wird das Reading ohne Fehler gesetzt und damit sauber geloggt.

Ganz einfach, die Readings werden als Zahlen im Ausdruck ersetzt, der Rest ist der Perl-Interpreter:

"bla".23.3."bla" geht
"bla"."23.3"."bla" geht
"bla".(23.3)."bla" geht

"bla".23."bla" geht nicht -> hier wird der Punkt als Komma mit fehlender Nachkommastelle interpretiert, der Punkt als Konkatenationszeichen fehlt ihm dann
"bla"."23"."bla" geht
"bla".(23)."bla" geht

[Pfriemler]

Perl für Dummies (wie mich). Danke! Jetzt macht das Sinn. Ich komme, da nur Hobby-Informatiker, aus der BASIC-Ecke und da kann es schlecht vorkommen, dass der Interpreter ein Dezimaltrennzeichen mit einem Zeichenkettenoperator verwechselt... 

"bla".23."bla" geht nicht

Nun begreife ich auch die Fehlermeldung  ... near "24."

Wieso jetzt die CUL_WS mal mit und mal ohne Nachkommastelle liefern, kann mir jetzt auch (sch...)egal sein.

DANKE! GELÖST!