Plot "vergisst" Daten darzustellen

[Puschel74]

Hallo zusammen,

blöder Titel - ich weiß.
Die 4 Screenshot zeigen aber was ich meine.

Die ersten beiden Screenshots wurden um 17:15 Uhr aufgenommen.
Man sieht schön das die Temperaturkurven im zweiten Screenshot gezeichnet werden im ersten aber nur bis 1 Uhr.

Die letzten beiden Screenshot wurden um 17:21 gemacht.
Die 15-Minuten-Kurve fehlt am dritten Screenshot auch grösstenteils und am 4. sieht man wieder alle Werte.

In der Detailansicht des Plots werden teilweise auch die Kurven nicht fertig gezeichnet.
Nach einem erneuten anklicken des Plots klappt es dann.

Browser FF26.0 am PC/Laptop und WebViewControl am Tablet zeigen die selben Symptome.
Update wurde gestern gemacht.

2013.12.26 19:27:26 0: Server started with 427 defined entities (version $Id: fhem.pl 4451 2013-12-24 09:10:26Z rudolfkoenig $, os linux, user fhem, pid 20499)

Jemand eine Idee wo ich ansetzen könnte?

Grüße

[rudolfkoenig]

Ich vermute, dass DbLog die Daten nicht oder nicht korrekt liefert.

Aus einem erhoehten verbose muessten die "get DbLog ..." ersichtlich werden, und dann muesste man das per Hand nachbauen, und die gelieferten Daten anschauen. Damit koennte man feststellen, ob man in der SVG oder im DbLog Modul weitersuchen muss.

[Puschel74]

Hallo,

danke für den Tipp Rudi.
Ich werd mich heute abend mal dran setzen und schauen was ich im Logfile finde nachdem verbose gefühlvoll aufgedreht wurde 

Grüße

[Puschel74]

Hallo,

mit meinem bescheidenen Nichtwissen vermute ich mal das die Daten in der DB korrekt angefordert werden:

2013.12.28 19:39:29 5: plotcommand: get myDbLog CURRENT INT 2013-12-28_00:00:00 2013-12-29_00:00:01 Eingang_aussen:temperature:: Eingang_aussen:humidity::
2013.12.28 19:39:29 5: Cmd: >get myDbLog CURRENT INT 2013-12-28_00:00:00 2013-12-29_00:00:01 Eingang_aussen:temperature:: Eingang_aussen:humidity::<
2013.12.28 19:39:29 5: Executing SELECT
          TIMESTAMP,
          VALUE
         
        FROM history
        WHERE
          DEVICE  = 'Eingang_aussen'
          AND READING = 'temperature'
          AND TIMESTAMP > '2013-12-28 00:00:00'
          AND TIMESTAMP < '2013-12-29 00:00:01'
        ORDER BY TIMESTAMP
2013.12.28 19:39:29 5: Executing SELECT
          TIMESTAMP,
          VALUE
         
        FROM history
        WHERE
          DEVICE  = 'Eingang_aussen'
          AND READING = 'humidity'
          AND TIMESTAMP > '2013-12-28 00:00:00'
          AND TIMESTAMP < '2013-12-29 00:00:01'
        ORDER BY TIMESTAMP

Nun werd ich mal schauen wie ich DBLog auf die Finger schauen kann was an Daten so ausgeliefert wird.

Grüße

[rudolfkoenig]

Mit

Code Auswählen Erweitern

get myDbLog CURRENT - 2013-12-28_00:00:00 2013-12-29_00:00:01 Eingang_aussen:temperature:: Eingang_aussen:humidity::


muesste es in der Ausgabe direkt erscheinen.
Es kann auch sein, dass die Daten von der vorherigen Abfrage abhaengig sind, damit wird es schwieriger.

[Puschel74]

Hallo,

ähem ja. Danke Rudi.
Mit schauen meinte ich eigentlich in meinen Unterlagen schauen 
Aber nett das du mir den richtigen Code gepostet hast - ich hab gesehen das ich meine Unterlagen nachführen sollte 

Ein

Code Auswählen Erweitern

get myDbLog CURRENT - 2013-12-27_00:00:00 2013-12-28_00:00:01 Keller_Heizung_Vorlauf:temperature:: Keller_Heizung_Ruecklauf:temperature::
für einen HM-WDS30-OT2 liefert mir gesamt 1084 Zeilen in dieser Form:

2013-12-27_00:20:28 45.4

für die Vorlauftemperatur und im zweiten Abschnitt dann für die Rücklauftemperatur übermittelt (ich werde jetzt aber nicht alle posten - keine Angst).
Ich sehe nur das ich im Schnitt 23 Einträgen pro Stunde habe (bei diesem Sensor).

Die Abfrage auf Eingang_aussen:temperatur und Eingang_aussen:humidity haben 193 Einträge gebracht aufgeteilt in temperatur und humiditiy - logischerweise.
Da das aber ein S300TH im Freien ist kommen bei tieferen Temperaturen weniger bis gar keine Werte mehr an - auch eine neue Batterie hält bei unter 0°C nicht sehr lange durch.

Da aber anscheinend immer wieder ein anderer Plot "betroffen" ist gestaltet sich die Suche natürlich nicht sehr leicht.

Die Datenbank (sqlite3 auf dem RasPi lt. Wiki installiert) liegt auf einer USB-HDD an einem aktiven Hub des RasPi.
An diesem USB-Hub ist auch nur diese Festplatte mittels Y-USB-Kabel angeschlossen (500mA-Grenze/Port, HDD hat beim Anlauf gerne etwas mehr Strom).
Der Plattenplatz auf dieser Platte ist zu 1% belegt - eine 2GB-Datenbank für sqlite3.

dass die Daten von der vorherigen Abfrage abhaengig sind,

Naja. Manchmal klappt es ja einwandfrei mit der Darstellung und manchmal fehlen Teile der Kurven (und manchmal eben nicht).
Aber es sind immer wieder andere betroffen davon - oder auch nicht 

Wenn ich einen Raum aufrufe mit weniger Plots klappt es eigentlich immer zu 100% (ich muss da mal mehr drauf achten).
Nur wenn ich "einiges" an Plots habe hängt es zwischendurch.
18 Kurven verteilt auf 7 Plots in einem Raum macht ab und zu Probleme
11 Kurven verteilt auf 4 Plots macht so gut wie immer Probleme (das sind einige Daten die sysmon liefert - die Werte selbst sind aber in der DB durchgehend vorhanden)
12 Kurven verteilt auf 6 Plots klappt eigentlich jedesmal ohne Probleme - wie gesagt, ich werd da mal mehr drauf achten.

Grüße

[rudolfkoenig]

Ist plotfork gesetzt?

[Puschel74]

Hallo,

ähem, zum Glück ist der Beitrag dazu bereits auf Seite 2 gerutscht 
Ich muss mich auch mal selbst an der eigenen Nase nehmen.
Obwohl es in dem anderen Beitrag ja Fehlermeldungen im Logfile gab - die habe ich ja nicht.

plotfork soeben ausgeschaltet und die ersten Tests sehen gut aus - die grösseren Räume zeigen alle Kurven an.

Danke für den Hinweis und die Hilfe.
Eigenartigerweise hatte ich mit plotfork noch nie Probleme.

Grüße

[justme1968]

sqlite (und jede db) verträgt einfaches forken nicht. such mal nach 'sqlite fork' hier im forum .

man muss im child eine neue verbindung zur db aufmachen damit es sauber ist genau so wie man die logfiles neu auf machen muss.


gruss
  andre

[Puschel74]

Hallo,

den Beitrag im Development-Bereich meinst du sicher nicht, oder?
Dann hat es noch einen im Server-Linux Bereich und diesen hier 

Der Beitrag im Server-Linux Bereich ist vom März/April und tetzlav hatte Fehlermeldungen im Log - die habe ich ja nicht.

Allerdings habe ich mir auch deine Antwort darauf durch gelesen 
d.h. für mich das ich dort wohl eher nichts umbauen kann - ich weiß ja nocht nichtmal wo 

Aber dennoch Danke für den Hinweis.

Grüße

[rudolfkoenig]

FileLog macht fuer das get die Datei neu auf. Koennte man das fuer DbLog nicht genauso handhaben?
Oder falls $$ sich aendert.

[justme1968]

ja. das müsste gehen.

[justme1968]

ich hab rudis vorschlag mal eben probiert und es schaut bei mir mit sqlite gut aus. der patch findet sich hier: http://forum.fhem.de/index.php/topic,18061.0.html.

gruss
  andre

[Puschel74]

Hallo,

erste Tests mit der gepachten 93_DbLog.pm sind bei mir auch am laufen und sehen gut aus.

Vielen Dank Andre (und Rudi).

Grüße

P.S.: Ja plotfork ist wieder eingeschaltet