alte Plotdaten nach Neustart nicht mehr in der Anzeige

[gelbwichtel]

Hi,
da ich z.Z am Testen bin, kommt es immer mal wieder vor, dass ich FHEM neu starten muss.
Meine Temperaturdaten stehen derzeit je Tag in einem separaten File.
Jetzt stelle ich ab und zu nach dem Neustart fest, dass die Plodaten nicht mehr vom Tagesanfang, sondern nur noch vom Zeitpunkt des Reboots angezeigt werden. Die Logdatei hat aber immer noch die Daten von vorher.
Hat jemand vielleicht eine Idee dazu ?

cfg:
define weblink_Solar weblink fileplot Log_Temperatur:_Solar:CURRENT
attr weblink_Solar label "Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_Solar room Solar

lg
Gelbwichtel

[Rohan]

Hallo Gelbwichtel,

sieh bitte in dem Verzeichnis nach, in dem die LOG-Dateien stehen und achte genau auf die Schreibweise der Namen der Log-Dateien. Vergleiche diese mit den Namen in der FHEM-Web-Anzeige von z.B. http://fhem-Rechner:8083/fhem?room=all . Da muss (sollte?) es einen Unterschied geben.

Hat dein FHEM-Rechner das richtige Datum?

Wie lauten deine entsprechenden "define FileLog..."-Einträge in deiner fhem.cfg genau? Bitte copy&paste.

Gruß
Thomas

[gelbwichtel]

Hi Rohan,
die Idee mit den Dateinamen kann es nicht sein. Alle Sensoren loggen immer in die gleiche Datei.

define BrauchwasserVL ECMDDevice ONEWIRE  281472880400002c
attr BrauchwasserVL room Heizung
#attr BrauchwasserVL IODev NETIO01
define 1W_BrauchwasserVL at +*00:01 set BrauchwasserVL messen;; sleep 2;; get BrauchwasserVL temp
define Log_Temperatur FileLog /var/InternerSpeicher/fhem/log/Heizung-%Y%m%d.log BrauchwasserVL:(temp).*

define SolarVL ECMDDevice ONEWIRE  102146720108007d
attr SolarVL room Solar
define 1W_SolarVL at +*00:02 set SolarVL messen;; sleep 2;; get SolarVL temp
define Log_Temperatur07d FileLog /var/InternerSpeicher/fhem/log/Heizung-%Y%m%d.log SolarVL:(temp).*

define SolarRL ECMDDevice ONEWIRE  10c948ca010800da
attr SolarRL room Solar
define 1W_SolarRL at +*00:02 set SolarRL messen;; sleep 2;; get SolarRL temp
define Log_Temperatur0da FileLog /var/InternerSpeicher/fhem/log/Heizung-%Y%m%d.log SolarRL:(temp).*

define weblink_Solar weblink fileplot Log_Temperatur:_Solar:CURRENT
attr weblink_Solar label "Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr weblink_Solar room Solar

Je Tag gibt es ein eigenes Log. HIer nochmal mein Problem anders formuliert.
Ich gehe z.B. in Room Solar und sehe dort um 16:00 Uhr den Plot vom Vor- und Rücklauf von 0:00-16:00 Uhr.
Jetzt starte ich z.B. fhem um 16:00 Uhr neu. Die Logwerte werden wie vorher auch in der gleichen Datei Heizung-201202xx.log geschrieben. D.h. Die Werte von 0:00 bis 16:00 und ab 16:00 Uhr stehen drin. Lediglich auf der Oberfläche beginnt der Plot jetzt nicht mehr um 0:00 Uhr , sondern esrt ab 16:00 Uhr. Davor gibts keine Linie.
Auch wenn ich jetzt z.B. einen kompletten Reboot mache, beginnt der Plot wie gehabt um 16:00 und nicht um 0:00, wo doch alle Werte im Log stehen.
Als würde 16:00 jetzt als Initialwert stehen und Daten nur ab dann berücksichtigt werden.
Hat es ev. was mit dem CURRENT zu tun ? Hab's auch mal mit fixedrange probiert, bringt aber das gleiche Ergebnis.

[Rohan]

... in der gleichen Datei Heizung-201202xx.log geschrieben ...

Ist das mit dem 2012 statt 2013 oben jetzt nur ein Schreibfehler?

Mach doch mal bitte in deinem log-Verzeichnis ein:

Code Auswählen Erweitern

# ls --full-time Heizung*

und danach ein

Code Auswählen Erweitern

# ls --full-time -u Heizung*

und danach ein

Code Auswählen Erweitern

# date

und poste die Ausgaben.

Gruß
Thomas

[gelbwichtel]

Hallo Thomas,
vielen Dank dafür, dass du dich meines Problems angenommen hast. Ja, das war natürlich ein Tippfehler im Post. War 2013 und nicht 2012.
Leider muss ich die Analyse des Plotproblems auf später verschieben bzw. neu angehen, da ich zum einen das Logging neu aufgebaut habe, zum anderen Probleme mit dem FHEM Server auf dem Raspberry habe. Obwohl im Hintergrund sauber in die Log-Datei geloggt wird, ein init.d/fhem Status sagt, dass FHEM am Laufen ist, ich auf der Raspberry-Console ohne Probleme arbeiten kann, habe ich im Broser (egal, ob Chrom, FF, IE) immer wieder sehr lange Aufbau-/Antwortzeiten, wo ich momentan nicht sehe, wo die herkommen.
Falls später meine Plotprobleme nochmal auftauchen, werde ich wieder posten.
cu
gelbwichtel

[Rohan]

Hallo gelbwichtel,

hmmm.... du beschreibst ein Problem, welches ich auch durchlaufen habe.

Bedenke: Dein RPi hat keine RTC, dass heißt, dass er nach einem Neustart keine gültige (im Sinne von aktuell) Systemzeit hat, sondern ein Datum in der Vergangenheit. Dies umgeht man sinnvollerweise mit einer NTP-Konfiguration.

Dabei muss man aber Sorge tragen, dass der ntpd schon einen Datums- / Zeitabgleich gemacht hat, bevor man FHEM startet. Geschieht der Abgleich nicht vorher, sondern erst nachdem FHEM schon läuft, stellt FHEM die Logs zwar um auf das nun aktuelle Datum (die "alten" Logs mit dem eigentlich ungültigen Datum werden natürlich behalten), aber irgendetwas scheint FHEM dabei so zu belasten, dass es einen "load" von über 0.8 bis 0.9 erzeugt. Diese Last besteht auf Dauer und verschwindet erst, wenn man das ganze sauber durchkonfiguriert und FHEM neu gestartet hat. Die hohe Systemauslastung zeigt sich auch in einem sehr trägen Laden der FHEM-Web-Seiten.

Gruß
Thomas

[gelbwichtel]

Danke Thomas für die ausführliche Erläuterung.
Vielleicht gelingt es mir ja jetzt 2 Fliegen mit einer Klappe zu erschlagen.
Das mit der RTC stimmt nicht so ganz, denn ich habe das COC-Board mit RTC drauf, wenngleich ich mich noch nicht darum gekümmert habe, wann wie die Zeitsynchronisation erfolgt.
Ich muss mir mal das Staren des Pi genauer ansehen.
Gibt es dazu eigentlich ein Log auf dem PI, oder muss ich mir das auf der Console ansehen ?
cu

[Rohan]

Wenn du dich um die RTC der COC-Erweiterung noch nicht gekümmert hast, wird mir nach überfliegen der COC-Anletung einiges klarer. Ohne dieses "Problem" zu lösen wirst du dir womöglich noch andere Datum-/Zeit-Probs einfangen.

Die Bootmeldungen sieht man durch Eingabe von

Code Auswählen Erweitern

dmesg

Gruß
Thomas

[gelbwichtel]

Hallo Thomas,
muss mich mal wieder etwas revidieren. Zwar hab ich die Anpassung lt. busware.de in der sbin/fake-hwclock vorgenommen, aber vergessen, dass bei neueren PI's sich die Adressen zur RTC geändert haben.
Ich hab die fake-hwclock jetzt mal so angepasst, dass bei dem fehlenden Device dieses erst mal angelegt wird.

____save)
________date -u '+%Y-%m-%d %H:%M:%S' > $FILE
________if [ ! -e /dev/rtc0 ]; then
____________echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device;
____________sleep 1;
________fi
________if [ -e /dev/rtc0 ]; then hwclock -w; fi
________;;

Aber kannst du mir noch einen Hinweis geben, wie ich checken kann ob jetzt bei mir die Zeitsync vor oder nach fhem passiert. Ne Suche nach time, clock bzw. ntp in der Ausgabe der dmesg hat mir keinen Hinweis darauf gegeben.
cu

[Rohan]

Hallo gelbwichtel,

sorry, aber ein RPi ist z.Zt. als Raspbmc im Einsatz und den anderen jetzt mit raspbian zu bespielen, dazu fehlt mir die Zeit. Starte den RPi aber doch einfach mal (ruhig mehrfach (incl. stromlos!)) neu (ohne FHEM zu starten). Wenn dir dann die Ausgabe von

Code Auswählen Erweitern

date

vernünftige Daten liefert, ist das schon die halbe Miete.

Zum ntpd auf Debian hatte ich einen Einstiegslink gepostet. Ob, wann und wie der jetzt bei Debian bzw. raspbian gestartet wird... im Moment keine Ahnung mangels System. Aber normalerweise hinterlässt der auch in /var/log entsprechende logs. Gibt ja hier noch reichlich andere RPi-Anwender, ich hab mein FHEM auf einem BeagleBoard-xM am lüppen (mit einer Opensuse-ARM-Distri) und da sehe ich die Startreihenfolge an Hand des Dateinamens (a la S10* bis S90* usw.). Bei Debian wird das aber iirc anders gesteuert.

Gruß
Thomas