[gefunden] Warnung durch SVG.pm oder DbLog.pm??

Begonnen von franky08, 05 Juli 2015, 16:48:37

Vorheriges Thema - Nächstes Thema

franky08

Hallo, seit geraumer Zeit habe ich folgende Perl Warnung, massenweise, im Log:

2015.07.05 16:43:10 1: PERL WARNING: Argument "1.62 M-BM-0C" isn't numeric in numeric gt (>) at (eval 12565) line 1.
2015.07.05 16:43:10 3: stacktrace:
2015.07.05 16:43:10 3:     main::__ANON__                      called by (eval 12565) (1)
2015.07.05 16:43:10 3:     (eval)                              called by ./FHEM/93_DbLog.pm (1038)
2015.07.05 16:43:10 3:     main::DbLog_Get                     called by fhem.pl (3040)
2015.07.05 16:43:10 3:     main::CallFn                        called by fhem.pl (1585)
2015.07.05 16:43:10 3:     main::CommandGet                    called by fhem.pl (1037)
2015.07.05 16:43:10 3:     main::AnalyzeCommand                called by fhem.pl (908)
2015.07.05 16:43:10 3:     main::AnalyzeCommandChain           called by ./FHEM/01_FHEMWEB.pm (2049)
2015.07.05 16:43:10 3:     main::FW_fC                         called by ./FHEM/98_SVG.pm (1115)
2015.07.05 16:43:10 3:     main::SVG_getData                   called by ./FHEM/98_SVG.pm (1083)
2015.07.05 16:43:10 3:     main::SVG_doShowLog                 called by ./FHEM/98_SVG.pm (959)
2015.07.05 16:43:10 3:     main::SVG_showLog                   called by ./FHEM/01_FHEMWEB.pm (659)
2015.07.05 16:43:10 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (433)
2015.07.05 16:43:10 3:     main::FW_Read                       called by fhem.pl (3040)
2015.07.05 16:43:10 3:     main::CallFn                        called by fhem.pl (646)
2015.07.05 16:43:10 1: PERL WARNING: Argument "1.63 M-BM-0C" isn't numeric in numeric gt (>) at (eval 12566) line 1.
2015.07.05 16:43:10 3: stacktrace:
2015.07.05 16:43:10 3:     main::__ANON__                      called by (eval 12566) (1)
2015.07.05 16:43:10 3:     (eval)                              called by ./FHEM/93_DbLog.pm (1038)
2015.07.05 16:43:10 3:     main::DbLog_Get                     called by fhem.pl (3040)
2015.07.05 16:43:10 3:     main::CallFn                        called by fhem.pl (1585)
2015.07.05 16:43:10 3:     main::CommandGet                    called by fhem.pl (1037)
2015.07.05 16:43:10 3:     main::AnalyzeCommand                called by fhem.pl (908)
2015.07.05 16:43:10 3:     main::AnalyzeCommandChain           called by ./FHEM/01_FHEMWEB.pm (2049)
2015.07.05 16:43:10 3:     main::FW_fC                         called by ./FHEM/98_SVG.pm (1115)
2015.07.05 16:43:10 3:     main::SVG_getData                   called by ./FHEM/98_SVG.pm (1083)
2015.07.05 16:43:10 3:     main::SVG_doShowLog                 called by ./FHEM/98_SVG.pm (959)
2015.07.05 16:43:10 3:     main::SVG_showLog                   called by ./FHEM/01_FHEMWEB.pm (659)
2015.07.05 16:43:10 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (433)
2015.07.05 16:43:10 3:     main::FW_Read                       called by fhem.pl (3040)
2015.07.05 16:43:10 3:     main::CallFn                        called by fhem.pl (646)


Hatte die Frage nach dem Fehler schon einmal im Anfängerbereich gestellt aber ohne stacktrace. Was ist mein Fehler. hat jemand einen Tipp zur Beseitigung der Warnmeldung?

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

vbs

Sieht so aus, als wollte SVG Daten aus der DB plotten, aber die Daten sind unerwartet nicht-numerisch ("1.62 M-BM-0C"). Vielleicht findest du die Daten in der DB und kannst rausfinden, wie die da reinkommen.

franky08

Ja, ist klar, ich grüble nur wo das herkommt? Tritt erst seit heuete Mittag auf, bis dahinn war alles OK und was der nicht numerische Ausdruck ist, ist mir ein Rätsel.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

vbs

In der Datenbank wird ja stehen, von welchem Device und von welchem Reading usw. das kommt.

franky08

Ja, nur wenn ich mit get myDbLog - - 2015-07-05 in die Datenbank sehen will, brauch ich ja das device und das Reading nach dem ich suchen will. So viel Ahnung von Datenbanken hab ich nicht um mir das ausgeben zu lassen. Die DB ist eine sqlite.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

vbs

Gibt da verschiedene Tools, mit denen du die sqlite-Datei direkt öffnen und reingucken kannst. Kann jetzt keins konkret empfehlen, aber sowas hier in der Richtung: http://sqlitebrowser.org/
Vielleicht gibts aber auch noch einfachere Wege, um raus zu finden, wo das herkommt...

franky08

Das blöde an den Tool ist, das die wahrscheinlich auf dem Host laufen müssen auf dem auch die Datenbank ist. Hatte schon einmal versucht mit sqlite Studio vom PC aus auf die DB (über Netzwerk) zuzugreifen, dass funktioniert leider nicht. Es muss doch irgenwie möglich sein mit einem Statment/Befehl sich z.B. Alle Datensätze von heute anzeigen zu lassen, nur leider weis ich nicht wie.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

franky08

#7
So, jetzt hab ich die DB mal heruntergeladen und mit SQLite Studio angesehen. Das merkwürdige ist, dass es für den Timestamp, wo die Warnung auftritt, keinerlei Eintrag in der DB vorhanden ist???
2015-07-05 16:43:10 kein Eintrag vorhanden
2015.07.05 16:43:10 1: PERL WARNING: Argument "1.62 M-BM-0C" isn't numeric in numeric gt (>) at (eval 12565) line 1.
2015.07.05 16:43:10 3: stacktrace:
2015.07.05 16:43:10 3:     main::__ANON__                      called by (eval 12565) (1)
2015.07.05 16:43:10 3:     (eval)                              called by ./FHEM/93_DbLog.pm (1038)
2015.07.05 16:43:10 3:     main::DbLog_Get                     called by fhem.pl (3040)
2015.07.05 16:43:10 3:     main::CallFn                        called by fhem.pl (1585)
2015.07.05 16:43:10 3:     main::CommandGet                    called by fhem.pl (1037)
2015.07.05 16:43:10 3:     main::AnalyzeCommand                called by fhem.pl (908)
2015.07.05 16:43:10 3:     main::AnalyzeCommandChain           called by ./FHEM/01_FHEMWEB.pm (2049)
2015.07.05 16:43:10 3:     main::FW_fC                         called by ./FHEM/98_SVG.pm (1115)
2015.07.05 16:43:10 3:     main::SVG_getData                   called by ./FHEM/98_SVG.pm (1083)
2015.07.05 16:43:10 3:     main::SVG_doShowLog                 called by ./FHEM/98_SVG.pm (959)
2015.07.05 16:43:10 3:     main::SVG_showLog                   called by ./FHEM/01_FHEMWEB.pm (659)
2015.07.05 16:43:10 3:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (433)
2015.07.05 16:43:10 3:     main::FW_Read                       called by fhem.pl (3040)
2015.07.05 16:43:10 3:     main::CallFn                        called by fhem.pl (646)


Und nun?

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

vbs

Der Timestamp in der DB ist ja der Zeitpunkt, an dem der Datensatz angelegt wurde. Der Zeitstempel in deinem Logfile ist ja jedoch der Zeitpunkt, als irgendjemand auf FHEM zugegriffen hat und ein Plot generiert werden sollte. Die beiden Zeitstempel haben also erstmal nicht viel miteinander zu tun. Die fehlerhaften Daten können ja uU. schon vor Urzeiten in die DB reingekommen sein.
Ich kenne das Programm jetzt nicht, aber man kann da sicherlich auch in den Daten suchen bzw. mal alle Zeilen anzeigen lassen, in denen "1.62 M-BM-0C" drin vor kommt. Oder (je nach Datenmenge) mal die letzten 48h durchklicken. Vielleichtz spring ja etwas ins Auge.

franky08

#9
Habe ich schon versucht, da wird nichts angezeigt. Gesucht nach 1.62 M-BM-0C liefert nichts. Habe jetzt erst einmal global verbose auf 0 nehmen müssen, da der Log "überläuft".

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

franky08

Mit der:
# $Id: fhem.pl 8810 2015-06-23 18:40:53Z rudolfkoenig $

werden die Logeinträge weniger, sind aber noch vorhanden. Langsam habe ich keine Idee mehr, wo ich noch suchen soll.
Die DbLog ist:
# $Id: 93_DbLog.pm 8779 2015-06-19 16:43:37Z tobiasfaust $
und die restlichen Module

# $Id: fhem.pl 8810 2015-06-23 18:40:53Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 8887 2015-07-05 05:05:40Z martinp876 $
# $Id: 57_Calendar.pm 8687 2015-06-04 13:29:42Z borisneubert $
# $Id: 93_DbLog.pm 8779 2015-06-19 16:43:37Z tobiasfaust $
# $Id: 66_ECMD.pm 7510 2015-01-10 20:20:34Z borisneubert $
# $Id: 67_ECMDDevice.pm 7698 2015-01-24 19:02:54Z borisneubert $
# $Id: 70_ENIGMA2.pm 8297 2015-03-27 14:31:15Z loredo $
# $Id: 72_FB_CALLMONITOR.pm 7367 2014-12-30 17:04:00Z markusbloch $
# $Id: 93_FHEM2FHEM.pm 8416 2015-04-11 10:46:08Z rudolfkoenig $
# $Id: 01_FHEMWEB.pm 8878 2015-07-03 13:55:28Z rudolfkoenig $
# $Id: 95_FLOORPLAN.pm 8752 2015-06-15 17:10:54Z ulimaass $
# $Id: 92_FileLog.pm 8738 2015-06-13 14:02:11Z rudolfkoenig $
# $Id: 00_HMLAN.pm 8885 2015-07-04 08:45:34Z martinp876 $
# $Id: 98_HMinfo.pm 8847 2015-06-27 18:34:45Z martinp876 $
# $Id: 70_PIONEERAVR.pm 8612 2015-05-20 22:13:38Z hofrichter $
# $Id: 71_PIONEERAVRZONE.pm 7365 2014-12-30 15:42:43Z hofrichter $
# $Id: 73_PRESENCE.pm 8638 2015-05-26 19:34:04Z markusbloch $
# $Id: 99_SUNRISE_EL.pm 6765 2014-10-14 18:24:29Z rudolfkoenig $
# $Id: 98_SVG.pm 8882 2015-07-03 18:47:02Z rudolfkoenig $
# $Id: 42_SYSMON.pm 8856 2015-06-28 19:34:09Z hexenmeister $
# $Id: 98_Text2Speech.pm 8886 2015-07-04 11:56:30Z tobiasfaust $
# $Id: 99_Utils.pm 7914 2015-02-08 11:14:10Z rudolfkoenig $
# $Id: 70_VIERA.pm 6347 2014-08-02 16:25:27Z teevau $
# $Id: 59_Weather.pm 8688 2015-06-04 13:37:22Z borisneubert $
# $Id: 90_at.pm 8326 2015-03-29 13:30:57Z rudolfkoenig $
# $Id: 98_autocreate.pm 8758 2015-06-16 17:12:39Z rudolfkoenig $
# $Id: 98_average.pm 5443 2014-04-05 06:37:49Z rudolfkoenig $
# $Id: 98_dewpoint.pm 6757 2014-10-12 18:58:57Z joachim09876 $
# $Id: 98_dummy.pm 8809 2015-06-23 18:02:33Z rudolfkoenig $
# $Id: 99_myUtilsTelefon.pm 1932 2012-10-06 20:15:33Z ulimaass $
# $Id: 91_notify.pm 8800 2015-06-22 18:24:59Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 7406 2015-01-02 15:02:11Z justme1968 $
# $Id: 98_statistics.pm 8783 2015-06-20 12:55:28Z tpoitzsch $
# $Id: 98_telnet.pm 8229 2015-03-17 09:00:27Z rudolfkoenig $
# $Id: 91_watchdog.pm 7108 2014-12-01 08:11:34Z rudolfkoenig $
./FHEM/95_webViewControl.pm: No such file or directory
# $Id: 98_weblink.pm 5608 2014-04-23 10:57:16Z rudolfkoenig $


Bis heute früh war das alles ohne Fehler, dann ein update und siehe das Resultat.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

franky08

#11
So, nach langer suche bin ich auf die wahrscheinlich fündig geworden. Gibt man im Plotteditor Range as [15:30] bei den RT´s an, dann kommen die Warnungen. Völlig logisch, da die Thermostate im Sommer bei mir auf 5°C stehen, also unterhalb von Range min. Bleibt das Feld Range [min:max] leer, sind die Warnungen (bis jetzt) weg.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

rudolfkoenig

ZitatBleibt das Feld Range [min:max] leer, sind die Warnungen (bis jetzt) weg.
Das ist mAn noch lange kein Grund, und passt auch nicht zum angezeigten Fehler.

Die Ursache des Problems ist, dass SVG von DbLog get Daten bekommt, was nicht ausschliesslich aus Zahlen besteht. FileLog Get filtert so'n "Muell" raus, deswegen macht SVG das nicht nochmal, SVG erstellen ist ja eh schon langsam genug. DbLog Get filtert mWn sowas nicht, da muss der Benutzer dafuer sorgen, dass die Daten "sauber" in der DB landen. Die manuelle Suche nach dem Muell ist einfach (die Datenbank besteht aus einer Datei die man beliebig kopieren kann, und z.Bsp. mit der sqlite3 Programm oeffnen kann) allerdings braucht man elementare SQL Kenntnisse.

Ich wundere mich, dass es ein Beduerfnis besteht Technologien (in diesem Fall Datenbank) zu verwenden, die man nicht versteht/beherrscht, wenn einfachere Alternativen (FileLog) existieren.

franky08

#13
Hallo Rudi, hab ich gestern schon gemacht aber in der DB ist der "Mülleintrag" nicht zu finden. Habe die DB auf dem Mac und mit SQLite Studio nach dem Eintrag gesucht, ohne Ergebnis! Wie das mit Range min zusammenhängt, kann ich nicht beurteilen aber nachdem ich das rausgenommen habe, sind die Einträge definitiv weg.

ZitatIch wundere mich, dass es ein Beduerfnis besteht Technologien (in diesem Fall Datenbank) zu verwenden, die man nicht versteht/beherrscht, wenn einfachere Alternativen (FileLog) existieren.

Weil vor ca. einem Jahr ständig propagiert wurde doch auf DbLog zu setzen und das Frontent "Neues Charting Frontend" DbLog voraus setzt.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1