Wenn ich mit folgendem Befehl:
get Wetterdaten - - 2017-06-17_06:00:00 2017-06-18_06:00:01 WH1080:rain_total::delta-h
die stündlichen Regenwerte aus der Datenbank abfrage, bekomme ich auch Werte zurück, die vor dem bei <from> angegebenen Zeitpunkt (2017-06-17_06:00:00) zurück:
2017-06-17_00:30:00 0
2017-06-17_01:30:00 0
2017-06-17_02:30:00 0
2017-06-17_03:30:00 0
2017-06-17_04:30:00 0
2017-06-17_05:30:00 0
2017-06-17_06:30:00 0
2017-06-17_07:30:00 0.3
2017-06-17_08:30:00 0
2017-06-17_09:30:00 0
2017-06-17_10:30:00 0
2017-06-17_11:30:00 0
2017-06-17_12:30:00 0
2017-06-17_13:30:00 0
2017-06-17_14:30:00 0
2017-06-17_15:30:00 0
2017-06-17_16:30:00 0
2017-06-17_17:30:00 0
2017-06-17_18:30:00 0
2017-06-17_19:30:00 0
2017-06-17_20:30:00 0
2017-06-17_21:30:00 0
2017-06-17_22:30:00 0
2017-06-17_23:30:00 0
2017-06-18_00:30:00 0
2017-06-18_01:30:00 0
2017-06-18_02:30:00 0
2017-06-18_03:30:00 0
2017-06-18_04:30:00 0
2017-06-18_05:30:00 0
#WH1080:rain_total::delta-h:
Ich erwarte da eigentlich als ersten Wert die Zeile mi 2017-06-17_06:30:00 als Timestamp!
Der entsprechende Befehl für FileLog:
get FileLog_WH1080 CURRENT - 2017-06-17_06:00:00 2017-06-18_06:00:01 4:WH1080.rain_total\x3a::delta-h
liefert hingegen den richtigen Zeitraum als Ergebenis:
2017-06-17_06:30:00 0
2017-06-17_07:30:00 0.3
2017-06-17_08:30:00 0
2017-06-17_09:30:00 0
2017-06-17_10:30:00 0
2017-06-17_11:30:00 0
2017-06-17_12:30:00 0
2017-06-17_13:30:00 0
2017-06-17_14:30:00 0
2017-06-17_15:30:00 0
2017-06-17_16:30:00 0
2017-06-17_17:30:00 0
2017-06-17_18:30:00 0
2017-06-17_19:30:00 0
2017-06-17_20:30:00 0
2017-06-17_21:30:00 0
2017-06-17_22:30:00 0
2017-06-17_23:30:00 0
2017-06-18_00:30:00 0
2017-06-18_01:30:00 0
2017-06-18_02:30:00 0
2017-06-18_03:30:00 0
2017-06-18_04:30:00 0
2017-06-18_05:30:00 0.0
#4:WH1080.rain_total\x3a::delta-h
Mache ich da irgendwas falsch oder ist das so gewollt? Für Plots ist das so jedenfalls unpraktisch.
lg, Sabine
Hallo Sabine,
die get-Funktion stammt noch aus dem "alten" Modul und ist vermutlich so alt wie das Modul selbst, d.h. fast 10 Jahre.
Ich habe das Design dieser Subfunktion absichtlich so belassen, da es auch keinen Grund gab irgend etwas daran im Zuge der
Weiterentwicklung bzgl. non-blocking zu ändern. (Weiß nicht inwieweit du die Entwicklung mitverfolgt hast)
Mit verbose 4 siehst du dass die Selektion so eingegrenzt wird wie man es im Befehl vorgibt.
Ich gehe also im Moment davon aus, dass der Aufbau des Ergebnisses mit Bedacht so wie von dir beschrieben designed ist und vermag es im Moment nicht zu überblicken welche Folgen etwaige Änderungen an dieser Stelle hätten.
Vielleicht kann Tobias, der das Modul seit 2012 als Maintainer betreut, noch etwas aus der Entwicklungsgeschichte zu diesem Thema beisteuern.
Was stört denn konkret in diesem Fall in einem Plot ?
viele Grüße,
Heiko
naja, ich bin grad dabei, meine Plots auf gnuplot umzustellen (plotmode SVG bietet mir zu wenige Formatierungsmöglichkeiten), und da wird dann offenbar das Ergebnis der SQL-Abfrage so weiter gegeben wie ich es in meinem Beispiel angegeben habe. Man sieht das auch am hier drangehngten Beispielplot der Regenwerte, man sieht, dass der Plot bei 0 Uhr vom Vortag beginnt. Zum Vergleich der Plot der Temperatur zeigt korrekt nur 24h.
Als Alternative wollte ich dann statRain für den stündlichen Regenwert nehmen, aber da bin ich im SVG-Modul auf ein Problem gestoßen (dazu hab ich einen eigenen Thread gestartet).
Eventuell werde ich dann doch ein eigenes Program schreiben, dass sich die Daten aus der MYSQL-Datenbank holt und mit gnuplot die Grafiken erstellt.
Ich benötige die besser aussehenden Grafiken der Wetterdaten für meine Wetterseite.
lg, Sabine
Was mir gerade durch den Kopf geht ...
Du kannst ja auch die Get-Funktion von DbLog für deine Belange anpassen. Wahrscheinlich sich die Anpassungen eher gering.
Dann könnten wir schauen ob sich die Variationen praktisch über ein Attribut umschaltbar gestalten lassen.
Lg
Heiko