Fehler in fronthem Plot bei negativen Werten (smartVISU 2.9)

[Romoker]

Ein smartVISU-Plotdiagramm wird nicht erstellt, wenn ein Log-Wert negativ ist.

Meine fronthem-Item-Definition au.carport.temp.plot:

Code: [Auswählen]

mode: plot
device: TmpHumCarport
reading: temperature
converter: Plotfile FileLog_TmpHumCarport
cmd set:
führt mit diesen Filelogdaten:

Code: [Auswählen]

2018-12-28_00:33:13 TmpHumCarport temperature: -0.2
2018-12-28_16:28:14 TmpHumCarport temperature: 1.4

zu folgender FHEM-Log-Fehlermeldung:

Code: [Auswählen]

2018.12.28 17:34:42.774 1: pc1: error doing $result = fronthem::Plotfile($param); Month '-1' out of range 0..11 at ./FHEM/99_fronthemUtils.pm line 38.und der Graph wird in smartVISU nicht gezeichnet.

Mache ich aus den negativen einen positiven Wert:

Code: [Auswählen]

2018-12-28_00:33:13 TmpHumCarport temperature: 0.2
2018-12-28_16:28:14 TmpHumCarport temperature: 1.4
ist alles gut und der Graph wird korrekt gezeichnet.

Meine smartVISU-Plot-Definition: {{ plot.period('', 'au.carport.temp.plot', 'raw', '3d', 'now', -10, 30) }}

Ich nutze den angepassten fronthem-Code von raman: https://forum.fhem.de/index.php/topic,86584.msg790077.html#msg790077
Das sollte sich der Entwickler @raman mal anschauen.

P.S.: Funktionieren hier im Forum Mentions oder sollte man in solch einem Fall eine PN schreiben?

Viele Grüße

[Chris46]

Bis auf den negativen Wert ist die Abfrage komplett gleich? Die Fehlermeldung moniert nämlich nicht den negativen Wert, sondern einen negativen Wert von Month, welcher nur einen Wert von 0-11 annehmen kann.

Da ich im Moment unterwegs bin, habe allerdings nicht in den Code geschaut.

[Romoker]

In meinem Testfall wurde nichts geändert als der Log-Wert. Die Log-Datei wird zeilenweise eingelesen. Das geht bis vor dem ersten negativen Wert gut, dann  kommt der Fehler. Offenbar wird eine Zeile mit negativem Wert nicht sauber in die Variablen übernommen. Dann stimmt der TIMESTAMP nicht usw.

[Romoker]

Ich bin in der Fehleranalyse etwas weiter gekommen.

Code in 99_fronthemUtils.pm Zeile 774/775 :

Code: [Auswählen]

        $resonse[$i] =~ /([0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{2}:[0-9]{2}:[0-9]{2})\s+([0-9\.]+)/;
        push(@{$data[0]->{plotdata}[$i]}, main::fronthem_TimeStamp($1));
Dort wird mit $1 das erste Ergebnis der vorherigen Regex an die Sub fronthem_TimeStamp übergeben. Im Fall einer Zeichenkette '2018-12-28_00:15:13 -1.0' wird $1 nicht gefüllt. Damit kann die Funktion keinen Timestamp ermitteln, was zu einem Fehler und Abbruch führt.

Das Verhalten kann ich in FHEM mit einer einfachen Funktion, z.B. in einem Notify, reproduzieren:

Code: [Auswählen]

Test:.* {
my $msg = '2018-12-28_00:15:13 -1.0';
$msg =~ /([0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{2}:[0-9]{2}:[0-9]{2})\s+([0-9\.]+)/;
Log 3, ("msg: $msg, 1: $1, 2: $2")
}
Das führt zu folgenden FHEM-Fehler-Log-Einträgen:

Code: [Auswählen]

2018.12.29 13:51:34.430 1: PERL WARNING: Use of uninitialized value $1 in concatenation (.) or string at (eval 34321) line 4.
2018.12.29 13:51:34.430 3: eval: my $EVTPART0='off';my $NAME='Test';my $SELF='n_test';my $TYPE='dummy';my $EVENT='off';{
my $msg = '2018-12-28_00:15:13 -1.0';
$msg =~ /([0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{2}:[0-9]{2}:[0-9]{2})\s+([0-9\.]+)/;
Log 3, ("msg: $msg, 1: $1, 2: $2")
}

2018.12.29 13:51:34.431 1: PERL WARNING: Use of uninitialized value $2 in concatenation (.) or string at (eval 34321) line 4.
2018.12.29 13:51:34.431 3: eval: my $EVTPART0='off';my $NAME='Test';my $SELF='n_test';my $TYPE='dummy';my $EVENT='off';{
my $msg = '2018-12-28_00:15:13 -1.0';
$msg =~ /([0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{2}:[0-9]{2}:[0-9]{2})\s+([0-9\.]+)/;
Log 3, ("msg: $msg, 1: $1, 2: $2")
}
Das sieht irgendwie nach einem Perl-Problem aus. Ab hier bin ich mit meinem Latein am Ende. Vielleicht kann jemand das Verhalten in seiner Installation überprüfen. Ich habe Perl v5.24.1 installiert.

Update: Ich habe die Regex in 99_fronthemUtils.pm von

Code: [Auswählen]

$resonse[$i] =~ /([0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{2}:[0-9]{2}:[0-9]{2})\s+([0-9\.]+)/;nach

Code: [Auswählen]

$resonse[$i] =~ /([0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{2}:[0-9]{2}:[0-9]{2})(.*)([0-9\.]+)/;geändert. Damit werden die Rückreferenzen der Regex korrekt gefüllt - und das Problem ist weg.

Ein kleines Problem bleibt: das neue Regex schneidet die Dezimalstelle des $2-Wertes ab (aus -1.0 wird -1.).
Vielleicht hat hier ein Regex-Experte noch einen besseren Vorschlag.

Viele Grüße

[Romoker]

Manchmal ist die Lösung doch einfacher als man denkt:

Die Original-Regex wird um ein Minuszeichen ergänzt,

Code: [Auswählen]

$resonse[$i] =~ /([0-9]{4}-[0-9]{2}-[0-9]{2}_[0-9]{2}:[0-9]{2}:[0-9]{2})\s+([0-9\.-]+)/;und schon ist der zweite Rückgabewert auch korrekt und vollständig.

Viele Grüße

[Huntercover]

@Romoker: Danke Dir für den Fix. Ich hatte mich schon gewundert warum mein Außentemperatur-Plot immer wieder aussetzt.