Perl Warnung in Zusammenhang mit 98_SVG.pm

[franky08]

Hallo, heute mal wieder einen Blick in´s Log geworfen und dort tauchen zu Hauf folgende Meldungen auf:

Code Auswählen Erweitern

PERL WARNING: Argument "--.-" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1520.

sowie

Code Auswählen Erweitern

PERL WARNING: Argument "--.-" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1169.

Leider weis ich nicht so recht, wo ich ansetzen soll. Könnte es mit einer gplot Zusammenhängen oder wo könnte ich suchen?

VG
Frank

[betateilchen]

Diese Fragestellung haben wir doch schon 728 Mal hier im Forum stehen - wozu jetzt noch einen Thread zum gleichen Thema?

[franky08]

Da ich zur Zeit ziemlich viel auf Arbeit bin, bin ich in letzter Zeit nur selten hier im Forum unterwegs.
Ist mir scheinbar entgangen, dass es da schon Beiträge gibt.

VG
Frank

[franky08]

Scheinbar hängt es mit dem über F2F verbundenen Raspi zusammen, auf dem läuft fows und liefert die Wetterdaten von einer USB Wetterstation.
Die Perl Warnung wird nur ausgegeben, wenn ich die Seite mit den Plot´s von der Wetterstation aufrufe. Die DEF/regex hatte ich schon auf 192.168.2.54:7072 LOG:myWS1080.* angepasst.

Leider erschließt sich mir aus den anderen Beiträgen nicht, wo ich das ändern kann!

Hat vielleicht jemand eine konstruktive Idee, wo ich suchen soll?
Bis ich eine Lösung gefunden habe, hab ich global verbose auf 0 gesetzt, der Log wächst sonst ins unermessliche.
VG
Frank

[det.]

Diese Fragestellung haben wir doch schon 728 Mal hier im Forum stehen - wozu jetzt noch einen Thread zum gleichen Thema?

Ja, die Frage ist nicht neu, aber eine Antwort gab es auf eine ähnlich Frage meinerseits z.b. leider bis heute nicht.
auch wenn ich jetzt einen shitstorm auslöse - es kommt derzeit alles zusammen: schlecht funktionierendes webinterface seit iOS 8 - Schuld ist Apple und nicht die FHEM Entwickler! Aber fast zeitgleich fühlt sich die Schar der FHEM Entwickler ermutigt, so was wie stacktrace einzubauen - "Leute, wir treiben Euch mal die bislang gut versteckten Perl Fehler aus Euren bis dato. gut funktionierenden Konfigurationen aus, ob Ihr gerade dazu Zeit und Lust habt oder nicht". - müllen wir Euch mal die Logs voll, damit Ihr seht, was bisher im Verborgenen schief ging.
So etwas kann man auf Testsystemen machen, mit entsprechender Vorwarnung, aber die meisten von uns setzen Ihr FHEM produktiv ein und updaten trotzdem regelmäßig. Da sollte so etwas nicht einfach eingespielt werden ohne von allen Modulautoren vorher auf Nebenwirkungen getestet zu werden.

[franky08]

Am Besten ist wahrscheinlich sich die updates zu verkneifen. Ich kann nicht jeden Tag zig Stunden mit Fehlersuche verbringen, da ich arbeitsmäßig z.Zt. ziemlich ausgelastet bin. Habe im Backup noch eine Version von Ende September die werde ich dann zurückspielen, die bringt keine Meldungen.

VG
Frank

[rudolfkoenig]

die meisten von uns setzen Ihr FHEM produktiv ein und updaten trotzdem regelmäßig.

Das ist zwar lieb, aber dann bitte nicht beschweren. Wer update durchfuehrt, der hilft dem Projekt, indem er das Testen mit uebernimmt.
Wer keine Ueberraschungen will oder gar FHEM produktiv einsetzt, der fuehrt update nur dann durch, wenn es Probleme zu beheben gibt. Und das sicher nicht automatisch. Bei allem Vertrauen in die FHEM Entwickler, keiner schafft es alle Kombinationen an Geraeten zu testen.

Wg. dem urspruenglichen Warnung: die selektierte Spalte (bzw. Log-Datei) enthaelt Muell, und der Zahlen-Filter-Regexp in FileLog hat es nicht erwischt. Ich meine die Ursache des Muells sollte behoben werden, und dementsprechend ist so eine Warnung ok.

[Puschel74]

Hallo,

...
So etwas kann man auf Testsystemen machen, mit entsprechender Vorwarnung, ...

Genau - deshalb spiele ich updates erst auf meinem Testsystem ein.
Und ein "Vorwarnung" gab es doch - Dietmar63 hat den Einbau von stacktrace mit Rudi besprochen (wenn ich den zugehörigen Beitrag noch richtig im Kopf habe).

Ihr dürft nicht nur eure 2 oder 3 abonnierten Beiträge im Auge behalten - ihr dürft schon auch ab und zu mal über den Tellerrand hinausschauen und mal in anderen Forenbereichen in den Beiträgen stöbern.
Dann gibt es solche "Überraschungen" nicht 

Grüße

P.S.: Wer die Meldungen nicht sehen will kann stacktrace mittlerweile per Attribut wieder abschalten.

[franky08]

Hatt übrigends NICHTS mit staktrace zu tun! Das steht nähmlich auf 0. Das Problem wahr wahrscheinlich, dass die Wetterstation gestern von 0:00 Uhr bis 15:30 Uhr keine Daten geliefert hat (Batterien im Transmitter leer). Kann ich jetzt aber nicht nachstellen, da ich meine alte Version zurückgespielt habe.

VG
Frank

[rudolfkoenig]

Ganz korrekterweise sollte man solche Felder dem SVG gar nicht anbieten, und den Filter im .gplot oder FileLog anpassen.
Da das haeufiger auftritt als man denkt, versucht FileLog solche Werte zu filtern. Da der Filter sehr haeufig durchgefuehrt wird, habe ich dazu nicht den perfekten Regexp genommen (ziemlich komplex), sondern was einfaches: ^[-\.\d]+$, was aber leider deine Werte durchlaesst.
Ich habe es leicht modifiziert, deine Werte sollten nicht mehr dabei sein: ^-?[.\d]+$

[franky08]

Wenn man die ganzen, unzähligen Probleme mit Perl Warnungen hier im Forum sieht, verkneife ich mir für die nächsten Monate irgendwelche updates! Erst wenn alle Module wieder "Perl konform" sind, gibt es für mich das nächste update.

VG
Frank

[franky08]

@rudi

Gilt der Filter auch für DbLog?

VG
Frank

[rudolfkoenig]

Nein, der Filter gilt nur fuer den FileLog.

Die Warnungen gabs in der alten Version auch, wurden nur bei den meisten offensichtlich ins Nirvana geschrieben (verstehe noch nicht, wieso, ich dachte ich habe STDERR ins FHEM-log umgeleitet). Eine Warnung bedeutet einen vom Entwickler nicht vorgesehenen Fall. Das default-Verhalten von Perl kann richtig sein, muss aber nicht.

[det.]

jedenfalls haben all diese neuerlichen Änderungen bei meinem System dazu geführt, dass ich verbose auf 0 gestellt habe und nun so gut wie gar nichts mehr im LOG sehe. Ob das das Ziel der Entwicklergemeinde war?