Hi,
es gab ja ein paar Hinweise auf diese Warnung hier im Forum, nach aktuellem Update habe ich es immer noch und stacktrace sagt:
2017.10.06 14:54:29 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at FHEM/TimeSeries.pm line 265.
2017.10.06 14:54:29 1: stacktrace:
2017.10.06 14:54:29 1: main::__ANON__ called by FHEM/TimeSeries.pm (265)
2017.10.06 14:54:29 1: TimeSeries::elapsed called by fhem.pl (4491)
2017.10.06 14:54:29 1: main::readingsBulkUpdate called by fhem.pl (4322)
2017.10.06 14:54:29 1: main::readingsEndUpdate called by ./FHEM/10_CUL_HM.pm (8662)
2017.10.06 14:54:29 1: main::CUL_HM_UpdtReadBulk called by ./FHEM/10_CUL_HM.pm (3678)
2017.10.06 14:54:29 1: main::CUL_HM_pushEvnts called by ./FHEM/10_CUL_HM.pm (2928)
2017.10.06 14:54:29 1: main::CUL_HM_Parse called by fhem.pl (3644)
2017.10.06 14:54:29 1: main::Dispatch called by ./FHEM/00_HMUARTLGW.pm (1387)
2017.10.06 14:54:29 1: main::HMUARTLGW_Parse called by ./FHEM/00_HMUARTLGW.pm (1490)
2017.10.06 14:54:29 1: main::HMUARTLGW_Read called by fhem.pl (3448)
2017.10.06 14:54:29 1: main::CallFn called by fhem.pl (692)
Ich hatte die Warnung auf zwei Systemen mit einem Homematic IO, auf meinem Hauptsystem ist er noch, auf dem anderen ist er nach dem Update heute verschwunden. Er kam mit dem Update vor ein paar Tagen, allerdings waren die Systeme davor schon ein paar Wochen "alt" ;)
Zur Vollständigkeit
Latest Revision: 15204
File Rev Last Change
fhem.pl 15182 2017-10-03 10:45:29Z rudolfkoenig
57_ABFALL.pm 11019 2016-02-16 01:55:00Z uniqueck
90_at.pm 14995 2017-09-03 14:23:14Z rudolfkoenig
98_autocreate.pm 15038 2017-09-10 10:00:18Z rudolfkoenig
57_Calendar.pm 14832 2017-08-01 18:36:03Z neubert
98_cmdalias.pm 15161 2017-10-01 10:17:28Z rudolfkoenig
10_CUL_HM.pm 15170 2017-10-02 08:11:26Z martinp876
98_dewpoint.pm 6757 2014-10-12 18:58:57Z joachim09876
98_DOIF.pm 14790 2017-07-26 10:27:41Z Damian
98_dummy.pm 12700 2016-12-02 16:49:42Z rudolfkoenig
70_ENIGMA2.pm 14985 2017-09-01 11:18:48Z loredo
91_eventTypes.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
72_FB_CALLMONITOR.pm 14988 2017-09-02 14:17:46Z markusbloch
93_FHEM2FHEM.pm 15006 2017-09-05 09:37:33Z rudolfkoenig
01_FHEMWEB.pm 15185 2017-10-03 15:46:09Z rudolfkoenig
92_FileLog.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
72_FRITZBOX.pm 15153 2017-09-30 08:48:53Z tupol
98_HMinfo.pm 14608 2017-07-01 04:53:04Z martinp876
00_HMLAN.pm 14073 2017-04-22 13:45:25Z martinp876
00_HMUARTLGW.pm 14899 2017-08-14 16:49:04Z mgernoth
95_holiday.pm 15042 2017-09-10 13:59:16Z rudolfkoenig
98_HTTPMOD.pm 15035 2017-09-09 12:02:21Z StefanStrobel
No Id found for 99_myUtils.pm
91_notify.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
73_PRESENCE.pm 15194 2017-10-04 16:26:36Z markusbloch
33_readingsGroup.pm 15100 2017-09-19 21:21:27Z justme1968
33_readingsHistory.pm 15100 2017-09-19 21:21:27Z justme1968
93_RFHEM.pm 15058 2017-09-12 19:30:29Z chris1284
02_RSS.pm 14405 2017-05-28 17:30:51Z neubert
91_sequence.pm 14996 2017-09-03 15:20:42Z rudolfkoenig
00_SONOS.pm 15151 2017-09-28 21:49:20Z Reinerlein
21_SONOSPLAYER.pm 14715 2017-07-14 10:39:57Z Reinerlein
98_structure.pm 15129 2017-09-24 08:58:57Z rudolfkoenig
99_SUNRISE_EL.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
98_SVG.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
42_SYSMON.pm 14823 2017-07-31 16:53:41Z hexenmeister
98_telnet.pm 15006 2017-09-05 09:37:33Z rudolfkoenig
98_Text2Speech.pm 13704 2017-03-14 19:33:42Z Tobias.Faust
98_THRESHOLD.pm 14179 2017-05-03 20:10:16Z Damian
59_Twilight.pm 14039 2017-04-19 19:59:56Z orti-otto
99_Utils.pm 13259 2017-01-28 17:39:39Z rudolfkoenig
98_version.pm 15140 2017-09-26 09:20:09Z markusbloch
91_watchdog.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
98_weblink.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
98_WOL.pm 10595 2016-01-22 17:05:38Z dietmar63
Blocking.pm 15200 2017-10-05 08:27:30Z rudolfkoenig
Color.pm 11159 2016-03-30 16:08:06Z justme1968
Common.pm 10759 2016-02-07 20:00:12Z rleins
ControlPoint.pm 14715 2017-07-14 10:39:57Z Reinerlein
DevIo.pm 14933 2017-08-20 14:21:58Z rudolfkoenig
FritzBoxUtils.pm 14541 2017-06-19 09:13:10Z rudolfkoenig
HMConfig.pm 15086 2017-09-17 18:01:08Z martinp876
HttpUtils.pm 15041 2017-09-10 13:52:34Z rudolfkoenig
Info.pm 28 2008-11-09 01:08:44Z dsully
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm 12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm 14862 2017-08-07 15:16:03Z rudolfkoenig
TimeSeries.pm 10907 2016-02-21 17:38:02Z borisneubert
Ist nicht so schlimm, aber bin ich der Einzige?
Gruß Otto
Ich habe den selben Fehler im Log sobald ich ein "shutdown restart" mache. Bei mir taucht der aber seit vielen Wochen im Logfile auf und ich update eigentlich regelmäßig alle 1-2 Wochen. Eingrenzen konnte ich das Problem bisher leider auch nicht, hatte aber immer den event-aggregator im Verdacht (ist aber nur eine Vermutung).
Hallo,
bei mir sieht es nach dem heutigen update wie folgt aus, es sihet eher nicht nach Homematic-Komponenten aus:
2017.12.30 12:54:02 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at FHEM/TimeSeries.pm line 265.
2017.12.30 12:54:02 1: stacktrace:
2017.12.30 12:54:02 1: main::__ANON__ called by FHEM/TimeSeries.pm (265)
2017.12.30 12:54:02 1: TimeSeries::elapsed called by fhem.pl (4531)
2017.12.30 12:54:02 1: main::readingsBulkUpdate called by .//FHEM/14_SD_WS09.pm (412)
2017.12.30 12:54:02 1: main::SD_WS09_Parse called by fhem.pl (3684)
2017.12.30 12:54:02 1: main::Dispatch called by .//FHEM/00_SIGNALduino.pm (3139)
2017.12.30 12:54:02 1: main::SIGNALduno_Dispatch called by .//FHEM/00_SIGNALduino.pm (3630)
2017.12.30 12:54:02 1: main::SIGNALduino_Parse_MU called by .//FHEM/00_SIGNALduino.pm (3843)
2017.12.30 12:54:02 1: main::SIGNALduino_Parse called by .//FHEM/00_SIGNALduino.pm (2671)
2017.12.30 12:54:02 1: main::SIGNALduino_Read called by fhem.pl (3488)
2017.12.30 12:54:02 1: main::CallFn called by fhem.pl (687)
2017.12.30 12:54:02 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at FHEM/TimeSeries.pm line 265.
2017.12.30 12:54:02 1: stacktrace:
2017.12.30 12:54:02 1: main::__ANON__ called by FHEM/TimeSeries.pm (265)
2017.12.30 12:54:02 1: TimeSeries::elapsed called by fhem.pl (4531)
2017.12.30 12:54:02 1: main::readingsBulkUpdate called by fhem.pl (4362)
2017.12.30 12:54:02 1: main::readingsEndUpdate called by .//FHEM/14_SD_WS09.pm (443)
2017.12.30 12:54:02 1: main::SD_WS09_Parse called by fhem.pl (3684)
2017.12.30 12:54:02 1: main::Dispatch called by .//FHEM/00_SIGNALduino.pm (3139)
2017.12.30 12:54:02 1: main::SIGNALduno_Dispatch called by .//FHEM/00_SIGNALduino.pm (3630)
2017.12.30 12:54:02 1: main::SIGNALduino_Parse_MU called by .//FHEM/00_SIGNALduino.pm (3843)
2017.12.30 12:54:02 1: main::SIGNALduino_Parse called by .//FHEM/00_SIGNALduino.pm (2671)
2017.12.30 12:54:02 1: main::SIGNALduino_Read called by fhem.pl (3488)
2017.12.30 12:54:02 1: main::CallFn called by fhem.pl (687)
2017.12.30 13:09:14 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at FHEM/TimeSeries.pm line 265.
2017.12.30 13:09:14 1: stacktrace:
2017.12.30 13:09:14 1: main::__ANON__ called by FHEM/TimeSeries.pm (265)
2017.12.30 13:09:14 1: TimeSeries::elapsed called by fhem.pl (4531)
2017.12.30 13:09:14 1: main::readingsBulkUpdate called by .//FHEM/14_SD_WS09.pm (413)
2017.12.30 13:09:14 1: main::SD_WS09_Parse called by fhem.pl (3684)
2017.12.30 13:09:14 1: main::Dispatch called by .//FHEM/00_SIGNALduino.pm (3139)
2017.12.30 13:09:14 1: main::SIGNALduno_Dispatch called by .//FHEM/00_SIGNALduino.pm (3630)
2017.12.30 13:09:14 1: main::SIGNALduino_Parse_MU called by .//FHEM/00_SIGNALduino.pm (3843)
2017.12.30 13:09:14 1: main::SIGNALduino_Parse called by .//FHEM/00_SIGNALduino.pm (2671)
2017.12.30 13:09:14 1: main::SIGNALduino_Read called by fhem.pl (3488)
2017.12.30 13:09:14 1: main::CallFn called by fhem.pl (687)
2017.12.30 13:09:14 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at FHEM/TimeSeries.pm line 265.
2017.12.30 13:09:14 1: stacktrace:
2017.12.30 13:09:14 1: main::__ANON__ called by FHEM/TimeSeries.pm (265)
2017.12.30 13:09:14 1: TimeSeries::elapsed called by fhem.pl (4531)
2017.12.30 13:09:14 1: main::readingsBulkUpdate called by .//FHEM/14_SD_WS09.pm (419)
2017.12.30 13:09:14 1: main::SD_WS09_Parse called by fhem.pl (3684)
2017.12.30 13:09:14 1: main::Dispatch called by .//FHEM/00_SIGNALduino.pm (3139)
2017.12.30 13:09:14 1: main::SIGNALduno_Dispatch called by .//FHEM/00_SIGNALduino.pm (3630)
2017.12.30 13:09:14 1: main::SIGNALduino_Parse_MU called by .//FHEM/00_SIGNALduino.pm (3843)
2017.12.30 13:09:14 1: main::SIGNALduino_Parse called by .//FHEM/00_SIGNALduino.pm (2671)
2017.12.30 13:09:14 1: main::SIGNALduino_Read called by fhem.pl (3488)
2017.12.30 13:09:14 1: main::CallFn called by fhem.pl (687)
2017.12.30 13:09:14 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at FHEM/TimeSeries.pm line 265.
2017.12.30 13:09:14 1: stacktrace:
2017.12.30 13:09:14 1: main::__ANON__ called by FHEM/TimeSeries.pm (265)
2017.12.30 13:09:14 1: TimeSeries::elapsed called by fhem.pl (4531)
2017.12.30 13:09:14 1: main::readingsBulkUpdate called by .//FHEM/98_dewpoint.pm (294)
2017.12.30 13:09:14 1: main::dewpoint_Notify called by fhem.pl (3488)
2017.12.30 13:09:14 1: main::CallFn called by fhem.pl (3408)
2017.12.30 13:09:14 1: main::DoTrigger called by fhem.pl (3766)
2017.12.30 13:09:14 1: main::Dispatch called by .//FHEM/00_SIGNALduino.pm (3139)
2017.12.30 13:09:14 1: main::SIGNALduno_Dispatch called by .//FHEM/00_SIGNALduino.pm (3630)
2017.12.30 13:09:14 1: main::SIGNALduino_Parse_MU called by .//FHEM/00_SIGNALduino.pm (3843)
2017.12.30 13:09:14 1: main::SIGNALduino_Parse called by .//FHEM/00_SIGNALduino.pm (2671)
2017.12.30 13:09:14 1: main::SIGNALduino_Read called by fhem.pl (3488)
2017.12.30 13:09:14 1: main::CallFn called by fhem.pl (687)
Viele Grüße Gisbert
Hallöchen,
Ich grab mal den Beitrag aus, weil es für mich am wahrscheinlichsten ist, hier das gleiche Problem zu haben:
Habe im global Device stacktrace auf 1 gestellt (weil ich das in einem anderen Beitrag gelesen hab und auch mal Probleme hatte einen Fehler zuzuordnen - was damit einfacher ist ) und werde seit dem im Log, mit dieser Meldung alle xx min / sek zugespamt. Hat jemand eine Idee woran das liegen könnte ?
2020.03.27 14:47:55.534 1: PERL WARNING: Argument "86400⍭\0¬" isn't numeric in numeric lt (<) at fhem.pl line 4861.
2020.03.27 14:47:55.534 1: stacktrace:
2020.03.27 14:47:55.535 1: main::__ANON__ called by fhem.pl (4861)
2020.03.27 14:47:55.535 1: main::readingsBulkUpdate called by ./FHEM/10_CUL_HM.pm (9499)
2020.03.27 14:47:55.535 1: main::CUL_HM_UpdtReadBulk called by ./FHEM/10_CUL_HM.pm (3795)
2020.03.27 14:47:55.536 1: main::CUL_HM_pushEvnts called by ./FHEM/10_CUL_HM.pm (3049)
2020.03.27 14:47:55.536 1: main::CUL_HM_Parse called by fhem.pl (3968)
2020.03.27 14:47:55.536 1: main::Dispatch called by ./FHEM/00_CUL.pm (954)
2020.03.27 14:47:55.536 1: main::CUL_Parse called by ./FHEM/00_CUL.pm (832)
2020.03.27 14:47:55.537 1: main::CUL_Read called by fhem.pl (3772)
2020.03.27 14:47:55.537 1: main::CallFn called by fhem.pl (757)
(habs erstmal deaktiviert, weil sonst der Log voll läuft ;) )
Grüße
Andreas
Nein, ich glaube eher nicht, dass das etwas mit diesem Problem zu tun hat. Jedweder Fehler in einzelnen Komponenten ist ja optisch ähnlich - hier ging es um TimeSeries als Verursacher des Fehlers (mit wechselnden Ursachen, aber immer "PERL WARNING: Argument "" isn't numeric in numeric..."
Ich tippe auf einen Fehler in einer readingsGroup - im Zusammenhang mit einem HM-Gerät. __ANON__ kommt mir sehr bekannt vor. Ist jedenfalls kein spezifisches HomeMatic-Problem, und ich bin kein readingsGroup-Experte.
Die erste Zeile der Fehlermeldung solltest Du aber so oder so immer im Log haben. Vielleicht hilft das bei der zeitlichen Eingrenzung ...
Und "86400⍭\0¬" ist kein numerischer Ausdruck, da hat perl schon recht. Ein verunglücktes RegEx?
Der nächste (Helfer) bitte! :-)
die warning kommt von readingsbulkupdate in fhem.pl
4858 my (undef, $minInt) = split(":", $v[0]);
4859 my $now = $hash->{".updateTime"};
4860 my $le = $hash->{".lastTime$reading"};
4861 if($le && $now-$le < $minInt) {
das könnte mit "attr event-min-interval" zusammen hängen.
ich würde mal alle min-interval attribute von cul_hm devices kontrollieren. vermutlich ist im betreffenden attribut die zahl "86400" (ein tag in sek) enthalten.
im eventmonitor mit option fhem.log sollten auch die auslösenden events zeitnah vor oder hinter der warning auftauchen.
events eventuell noch "geschickt" filtern.
Die Idee von Frank mit list umgesetzt:
list TYPE=CUL_HM event-min-interval
Aloha,
sorry für die späte Antwort.... Ihr seid ja wirklich die Geilsten :)
Zitat
Der nächste (Helfer) bitte! :-)
...
das könnte mit "attr event-min-interval" zusammen hängen.
...
list TYPE=CUL_HM event-min-interval
Genau diese Zusammenarbeit wünsche ich mir immerwieder bei den Fragen im Forum.
Diese hat dazu geführt, dass ich wusste
was (frank und Pfriemler) und
wie (Otto) genau 10 Sekunden gebraucht habe um den Übeltäter zu finden. Ich hatte in einem Device ein event-min-interval:86400 drin und warhrscheinlich war am Ende einfach nur ein Leerzeichen oder sonst was drin. Ich war leider zu voreilig und hab das gelöscht. Danach war der Fehler weg.
Jetzt hab ich das Ganze einfach neu angelegt und seitdem habe ich keine Probleme mehr mit dieser Meldung ;)
Vielen herzlichen Dank Euch dreien
Viele Grüße, bleibt vor allem gesund und zu Hause :)
Andreas
p.s. Jetzt bekomme ich eine ähnliche Warnung in einem Zusammenhang mit meinem eigenen Script und die nur jedes 100te mal Ausführen, auftritt aber so habe ich wieder wa zu suchen :D
Zitatwarhrscheinlich war am Ende einfach nur ein Leerzeichen oder sonst was drin
du hast doch wohl nicht die fhem.cfg editiert?
Zitat von: frank am 28 März 2020, 17:28:14
du hast doch wohl nicht die fhem.cfg editiert?
DAS hab ich tatsächlich glaube ich nie mehr seit der ersten Woche in der ich mit FHEM zu tun hatte.... danach hab ich ein paar mal "Kein Support für fhem.cfg editierer" gelesen und das war mir Warnung genug ;) ;D
Man braucht es ja auch zu 99,9999999 % nicht in der Config zu machen...
Viele Grüße
Andreas
eigentlich gut gemacht.
andererseits bleibt es dann ein rätsel.
oder anzeichen einer defekten sdcard?
Bitte nicht :o :'(
Bin eh dabei, es langsam aber sicher von nahezu allen schreibvorgängen auf die sd Karte zu trennen....
Kurz weil mobiles Mäusekino.....
Grüße
Andreas
Zitat von: frank am 28 März 2020, 20:32:05
eigentlich gut gemacht.
andererseits bleibt es dann ein rätsel.
oder anzeichen einer defekten sdcard?
war auch mein erster Gedanke ;)
Ein backup jetzt, solange es hoffentlich noch geht, ist möglicherweise die nicht komplett allerschlechteste Idee..
Zitat von: herrmannj am 28 März 2020, 22:32:47
war auch mein erster Gedanke ;)
Ein backup jetzt, solange es hoffentlich noch geht, ist möglicherweise die nicht komplett allerschlechteste Idee..
Aaahhh jetzt macht ihr ich aber schön wuschig :o ::)
OK ihr würdet es tun, wenn ich nicht vor einiger Zeit (als ich mich immer mehr mit Fhem beschäftigt habe), so oft von sterbenden SD Karten gelesen hätte und für meinen Fall etwas eingerichtet hätte
Jeden Tag wird n Fhem Backup gezogen (extern)
Alle 3 Tage ein Fullbackup von der SD Karte gezogen, (sprich wenn es so funktioniert wie beim letzten Test, dauert es nur die Zeit des wieder aufspielens auf die neue Karte, bis es wieder läuft)
Jede Woche werden die config Dateien von zigbee2mqtt gesichert (extern)
99 %der logs landen bereits auf der SQL Datenbank (extern)
Nur noch testlogs und cfg (noch nie dran getraut es auf dbconfig umzustellen) schreiben effektiv (neben dem Betrieb) auf die sd Karte.....
Aber cfg umstellen und Backup frisch einspielen, kommt wohl morgen auf die ToDo Liste für den Tag ;D 8)
Viele Grüße
Andreas
Ich nochmal kurz:
Zitat von: flummy1978 am 28 März 2020, 23:27:11
Jeden Tag wird n Fhem Backup gezogen (extern)
Alle 3 Tage ein Fullbackup von der SD Karte gezogen, (sprich wenn es so funktioniert wie beim letzten Test, dauert es nur die Zeit des wieder aufspielens auf die neue Karte, bis es wieder läuft)
Der letzte Testlauf mit einer Kopie ist ja schon ein wenig her gewesen. In der Zwischenzeit ist einiges dazu gekommen, ich muss aber sagen das oben Zittierte hat sich komplett bewährt. Damit dauerte vorhin die Umstellung von alt auf neue SD Karte insg. ca 15 Min: Image auf die Karte spielen + Shutdown und Karte wechseln ... das wars 8)
Sollte der Fehler also nochmal auftauchen, ist es schon mal zu 100% nicht die SD Karte ;)
Vielen Dank nochmal Euch allen
Grüße
Andreas