Mir ist gerade mal aufgefallen, daß motd mir folgendes anzeigt:
Messages collected while initializing FHEM:
configDB: 1487662379.76583
Was will mir FHEM damit sagen? Soweit ich weiß, werden über motd ja eigentlich nur Sicherheitswarnungen ausgegeben
Zitat von: mahowi am 21 Februar 2017, 12:51:35
werden über motd ja eigentlich nur Sicherheitswarnungen ausgegeben
falsch. Über motd kann man ausgeben, was man möchte. Im Regelfall Fehlermeldungen beim Start von FHEM.
Warum configDB Dir einen timestamp ausgibt - keine Ahnung, ist bei mir noch nie aufgetreten und spontan wüßte ich auch nicht, an welcher Stelle das passieren sollte.
Lösche die Meldung mit "attr global motd none", mache ein "save config" und einen FHEM Neustart. Wenn die Meldung dann wieder erscheint, nochmal hier melden.
Ok, war vielleicht falsch ausgedrückt. Klar kann ich mit motd alles Mögliche ausgeben. Ich meinte eigentlich, daß ohne irgendwelche Definitionen normalerweise Meldungen zur Sicherheit von FHEM darin ausgegeben werden. Zumindest hab ich bei mir noch nix anderes darin gesehen.
Nach Neustart bekomme ich nur einen Timestamp ohne Angabe von Modul oder sonstwas im Log:
2017.02.21 13:50:40.255 3: 1487681560.25566
Und motd gibt auch an:
Messages collected while initializing FHEM:
configDB: 1487681560.25566
"attr global motd none" und "save" habe ich natürlich vorher gemacht.
Lustig :)
Muss ich mir anschauen. Spontan fällt mir dazu nix ein.
Fand ich auch. :)
Wäre mir auch gar nicht aufgefallen, wenn ich nicht zufällig gerade ein "list global" gemacht hätte. Wenn sich daraus irgendwie 42 ableiten lässt, beantwortet configDB vielleicht gerade die Suche nach der großen Frage. ;D
Ich vermute, Du hast in Deiner Konfiguration irgendwo eine Stelle verbaut, die einen Timestamp zurückliefert.
Das kann in
- define ...
- attr ...
- oder im statefile (vielleicht ein (user)reading)
sein.
Der Timestamp entspricht übrigens 21.02.2017 um 13:52:40 Uhr und scheint sich somit bei jedem FHEM Start zu ändern.
Hm, nicht, das ich wüsste. Ich habe in letzter Zeit nichts neues eingebaut. Und vor kurzem stand immer nur eine Meldung über telnet in motd.
Der Timestamp taucht wohl seit dem gestrigen Update auf:
pi@raspberrypi:~ $ grep 3\:\ 14 /opt/fhem/log/fhem-2017-02.log
2017.02.20 07:58:41.346 3: 1487574041.34653
2017.02.20 19:12:49.500 3: 1487614489.50067
2017.02.20 19:14:41.405 3: 1487614601.40548
2017.02.20 19:23:09.958 3: 1487615109.95842
2017.02.20 19:24:58.518 3: 1487615218.51817
2017.02.21 08:30:59.766 3: 1487662379.76583
2017.02.21 13:50:40.255 3: 1487681560.25566
Der erste Eintrag kam beim Restart nach dem Update.
An configDB hat sich diesbezüglich nichts geändert.
Und die Meldung trat bei mir auch noch nicht auf, das wäre mir aufgefallen.
Naja, FHEM funktioniert einwandfrei und ich kann außer dem Timestamp im Log beim Start nichts Ungewöhnliches beobachten. Und ohne Not setze ich nur ungern ein globales "verbose 5", um der Sache auf den Grund zu gehen. Von daher belasse ich es erstmal dabei, solange es sonst keine Fehler gibt.
Was Du aber testen könntest:
Einmal Dein FHEM mit einer leeren configDB starten, um zu testen, ob motd dann auch mit einem Timestamp zurückkommt.
Ansonsten sollte man mit verbose=5 tatsächlich rausfinden, woher der Zeitstempel kommt.
Ok. Ich werde heute abend mal testen.
Wäre halt schön, wenn ich eingrenzen könnte, woher es kommt. Mit "attr global verbose 5" wird das Log nämlich ziemlich unübersichtlich.
mich interessiert ja auch, woher das kommt. Deshalb würde mir das verbose=5 helfen.
Du brauchst das ja auch nur für einen Systemstart einschalten, sobald FHEM läuft, kannst Du es wieder abschalten.
Mit leerer configDB.db bekomme ich nur folgendes im Log:
2017.02.21 20:14:53 3: telnetPort: port 7072 opened
2017.02.21 20:14:54 3: web: port 8083 opened
2017.02.21 20:14:54 0: Featurelevel: 5.8
2017.02.21 20:14:54 0: Server started with 4 defined entities (fhem.pl:13447/2017-02-19 perl:5.020002 os:linux user:fhem pid:18238)
2017.02.21 20:15:31 3: web_192.168.1.1_39590: unsupported HTTP method ^V^C^A^B^@^A^@^A<FC>^C^C^AD<D2><F1><E5>pxa/<97>O<D9>^HESC<<CF>'J<B3><AB>[#<D2>,T, rejecting it.
Also kein Timestamp.
Log mit "verbose=5" bis zum Eintrag mit dem Timestamp habe ich angehängt.
Edit: Log gelöscht.
Sehr beruhigend: Die Meldung hat nichts mit der configDB zu tun :)
Da ist der Übeltäter:
2017.02.21 20:48:41.231 5: Cmd: >attr LMS alivetimer 120<
2017.02.21 20:48:41.232 4: SB_SERVER_Attr(LMS): called with alivetimer 120
2017.02.21 20:48:41.233 3: 1487706641.2333
Der Timestamp kommt aus der Funktion sub SB_SERVER_Attr( @ ) aus 97_SB_SERVER.pm.
Du kannst testweise in der Moduldatei die mit +++ markierte Zeile einfügen (ohne die +++ natürlich) und schauen, ob der Timestamp dann verschwindet.
sub SB_SERVER_Attr( @ ) {
my $cmd = shift( @_ );
my $name = shift( @_ );
my $hash = $defs{$name};
my @args = @_;
Log( 4, "SB_SERVER_Attr($name): called with @args" );
if( $cmd eq "set" ) {
if( $args[ 0 ] eq "alivetimer" ) {
# CD 0021 start
RemoveInternalTimer( "SB_SERVER_Alive:$name");
InternalTimer( gettimeofday() + $args[ 1 ],
"SB_SERVER_tcb_Alive",
"SB_SERVER_Alive:$name",
0 );
# CD 0021 end
}
# CD 0015 bei ƒnderung des Ports diesen an Clients schicken
if( $args[ 0 ] eq "httpport" ) {
SB_SERVER_Broadcast( $hash, "SERVER",
"IP " . $hash->{IP} . ":" .
$args[ 1 ] );
}
}
+++ return;
}
Ich habe zwar die Version von github, die etwas anders aussieht, aber ein "return;" am Ende der Sub behebt den Fehler. Ich geb's im entsprechenden Thread weiter.
Danke!