Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[DS_Starter]

bei mit wird die Grünlandtemperatursumme täglich immer nur größer und hat bei "0" angefangen:

Ja, so soll es auch sein. 

Hier nochmal die Definition für diese Kennzahl:

Die Grünlandtemperatursumme (GTS) ist eine Spezialform der Wachstumsgradtage, die in der Agrarmeteorologie verwendet wird. Sie wird herangezogen, um in Mitteleuropa den Termin für das Einsetzen der Feldarbeit nach dem Winter zu bestimmen.
Es werden ab Jahresbeginn alle positiven Tagesmittel erfasst. Im Januar wird mit dem Faktor 0,5 multipliziert, im Februar mit dem Faktor 0,75, und ab März geht dann der ,,volle" Tageswert (mal Faktor 1) in die Rechnung ein.
Wird im Frühjahr die Summe von 200 überschritten, ist der nachhaltige Vegetationsbeginn erreicht. Hintergrund ist die Stickstoffaufnahme und -verarbeitung des Bodens, welcher von dieser Temperatursumme abhängig ist. In mittleren Breiten wird das meist im Laufe des März, an der Wende von Vorfrühling zu Mittfrühling erreicht.
(siehe auch Grünlandtemperatursumme in Wikipedia)

Das kannst du auch nachlesen mit "get <> versionNotes 5" bzw. bei https://de.wikipedia.org/wiki/Gr%C3%BCnlandtemperatursumme.

[kobi1980]

Alles klar.. mein Fehler.
Dann stimmen die Werte ja..

wie gehts mit Schritt 2 weiter

writeToDb kann in diesem Fall nicht verwendet weren, da es nur ein Zusatz zu avgDailyMeanGWS ist. Aber auch dafür gibt es eine Lösung. Aber das im zweiten Schritt.

[DS_Starter]

Ok, also wir können ja nicht wirklich die entstehenden Events aus der Berechnung in der DB speichern, weil der Timestamp des berechneten Readings nicht den wirklichen Bezug zum Zeitpunkt des berechneten Ergebnisses wiedergibt, z.B.:

Code Auswählen Erweitern


2021-02-21__MyWetter__temperature__GrasslandTemperatureSum   69.8


sagt aus dass der GTS-Wert für den 21.02.2021 gilt, wobei dieser Wert mit dem Zeitpunkt in der DB landen würde der dem DbRep Lauf entspricht, also jetzt zum Beispiel.

Man kann folgendermaßen vorgehen:

1. definieren eines Notify welches den Event des DbRep-Devices und dem Reading .*GrasslandTemperatureSum.* abgreift
2. In dem Notify das relevante Datum extrahieren (steht ja am Anfang des Readings) und in die geforderte Zeitform für eine
    Speicherung in der DB überführen, d.h. in die Form "YYYY-MM-TT hh:mm:ss"
3. Im DbLog-Device einen Cache Eintrag erstellen, der dann in die DB geschrieben wird. Es gibt dazu einen addCacheLine Befehl
    im DbLog (set <dblog> addCacheLine YYYY-MM-DD HH:MM:SS|<device>|<type>|<event>|<reading>|<value>| )

DbLog muß dafür im asynchronen Mode laufen, aber das sollte ohnehin so sein.

Willst du dich mal an einer solchen Umsetzung versuchen ?

LG,
Heiko

[kobi1980]

hi
danke für die Unterstützung, aber ich habe leider nicht mehr die Zeit, mich in das einzulesen, Foreneinträge und Wikieinträge querzulesen.
Mir reicht es dann per Knopfdruck die Daten zu erstellen und mir diese dann in Klartext und nicht per Plot anzuschauen.

VG Kobi

[DS_Starter]

Na vielleicht schreibe ich einen Wiki-Beitrag (DbRep) der genau dieses Szenario beschreibt.
Möglicherweise interessiert das auch andere User. Mal schauen.
Ist nicht so sehr umfangreich.

VG

[ch.eick]

Hallo Heiko,
hattest Du schon mal Zeit Dir das hier anzuschauen?
https://forum.fhem.de/index.php/topic,53584.msg1132896.html#msg1132896
Da sind noch ein, zwei Merkwürdigkeiten.

1.) Die Abfrage eines definierten Wertes, wenn dieser nicht in der Datenbank ist.
  Dann wird ein Werte in der Nähe geliefert, der aber auch sehr weit zurück liegt, anstatt der Default Wert, der beim Abruf mitgeliefert wurde.

2.) Bei Abruf mit sqlCmdBlocking hat sqlCmdVars keine Wirkung.


Gruß
   Christian

[DS_Starter]

Hallo Christian,

1.) Die Abfrage eines definierten Wertes, wenn dieser nicht in der Datenbank ist.
  Dann wird ein Werte in der Nähe geliefert, der aber auch sehr weit zurück liegt, anstatt der Default Wert, der beim Abruf mitgeliefert wurde.

Ja, das ist so gewollt. Der nächstliegende Wert soll geliefert werden. Der Standardwert wird zurück gegeben, wenn es keinen Wert der angefragten Device/Reading Kombination in der DB gibt.

2.) Bei Abruf mit sqlCmdBlocking hat sqlCmdVars keine Wirkung.

Ja das kann sein. Muss ich schauen. Die sqlCmdVars hatte ich vor nicht allzu langer Zeit eingebaut, vllt. hab ich es vergessen dort nachzuziehen.

Grüße,
Heiko

[ch.eick]

Ja, das ist so gewollt. Der nächstliegende Wert soll geliefert werden. Der Standardwert wird zurück gegeben, wenn es keinen Wert der angefragten Device/Reading Kombination in der DB gibt.

Danke für die Rückmeldung.
Gibt es denn noch eine andere Möglichkeit, mit einer Funktion exact nach einem Wert abzufragen?
Momentan gehe ich den Umweg mit einem SELECT über das DbRep Device

Code Auswählen Erweitern


$Solar_Correction_Faktor_auto = CommandGet(undef, $logdbrep." sqlCmdBlocking SELECT VALUE FROM history WHERE DEVICE='".$logdevice."' AND READING='Solar_Correction_Faktor_auto' AND TIMESTAMP='".sprintf("%4d-%02d-%02d %02d:00:00",$year,$mon,$mday,$i)."';") ;

if($Solar_Correction_Faktor_auto eq "") { $Solar_Correction_Faktor_auto = 1; };  ## hier wird der Default gesetzt, wenn nichts zurück kommt.


VG und danke für den unermüdlichen Support
       Christian

[DS_Starter]

Hallo kobi, @all,

im Wiki habe ich eine Beitrag erstellt wie man die ermittelte Grünlandtemperatursumme in die Datenbank zurückspeichert und daraus dann eine SVG-Grafik erstellt.
Das Verfahren kann natürlich für andere, ähnlich gelagerte Aufgabenstellungen adaptiert werden.

@Christian,in meinem contrib liegt eine neue DbRep-Version zum Testen. Das  sqlCmdBlocking sollte nun ebenfalls das Attr sqlCmdVars berücksichtigen.Versuchs mal bitte.
Grüße,Heiko

[kobi1980]

Moin Heiko

verrückt.. vielen Dank, es funktioniert!

Hallo kobi, @all,

im Wiki habe ich eine Beitrag erstellt wie man die ermittelte Grünlandtemperatursumme in die Datenbank zurückspeichert und daraus dann eine SVG-Grafik erstellt.
Das Verfahren kann natürlich für andere, ähnlich gelagerte Aufgabenstellungen adaptiert werden.

[ch.eick]

verrückt.. vielen Dank, es funktioniert!

Das ist nicht verrückt, der Heiko kann was

[ch.eick]

@Christian,in meinem contrib liegt eine neue DbRep-Version zum Testen. Das  sqlCmdBlocking sollte nun ebenfalls das Attr sqlCmdVars berücksichtigen.Versuchs mal bitte.

Es hat funktioniert. Ich habe es nun eingebaut und würde mich bei Problemen melden.

- Die sqlCmdHistory ist auch nur beim sqlCmd vorhanden. Würde das beim sqlCmdBlocking auch Sinn machen?
- Mein SQL ist wie immer recht lang könnte man das im sql[Cmd|CmdBlocking] eventuell mehrzeilig umbrechen?
- Kann man beim sql[Cmd|CmdBlocking] auch kleine Skripte mit mehreren SQL Kommandos verarbeiten?

Vielen Danke für Deinen tollen Support
   Christian

[DS_Starter]

Moin Christian,

gerne .

Die sqlCmdHistory ist auch nur beim sqlCmd vorhanden. Würde das beim sqlCmdBlocking auch Sinn machen?

Weiß nicht. sqlCmdBlocking ist eher für Ausführungen in einem Script gedacht und nicht für den Dialogbetrieb (wegen Blocking).

Mein SQL ist wie immer recht lang könnte man das im sql[Cmd|CmdBlocking] eventuell mehrzeilig umbrechen?

Versuch doch  mal:

Code Auswählen Erweitern


attr <> widgetOverride sqlCmdBlocking:textField-long sqlCmd:textField-long


Kann man beim sql[Cmd|CmdBlocking] auch kleine Skripte mit mehreren SQL Kommandos verarbeiten?

Momentan dürfte es nicht gehen, aber wäre einbaubar.

LG,
Heiko

[ch.eick]

Weiß nicht. sqlCmdBlocking ist eher für Ausführungen in einem Script gedacht und nicht für den Dialogbetrieb (wegen Blocking).

Das leuchtet ein, man könnte dann jedoch sehen, was als letztes so alles aufgerufen wurde und für Tests dieses dann wiederholen.

Versuch doch  mal:

Code Auswählen Erweitern


attr <> widgetOverride sqlCmdBlocking:textField-long sqlCmd:textField-long


Jetzt ist es schon zum sqlCmdBlocking gerutscht

Dann habe ich noch folgende Meldungen, muss ich mir da Sorgen machen?
Bekomme ich die noch weg? Außer dem global attr verbose 3 habe ich im Device kein verbose gesetzt.

Code Auswählen Erweitern


2021.02.27 14:00:00.120 3: DbRep LogDBRep_PV_Forecast_SQL - WARNING - old process 31994 will be killed now to start a new BlockingCall
2021.02.27 14:00:00.121 1: DbRep LogDBRep_PV_Forecast_SQL -> BlockingCall  pid: Timeout: process terminated
2021.02.27 14:00:00.136 2: DbRep LogDBRep_PV_Forecast_SQL - Database command aborted due to "Timeout: process terminated"
2021.02.27 14:00:01.460 3: DbRep LogDBRep_PV_Forecast_SQL - Number of entries processed in db fhem: 11 by INSERT


Gruß
   Christian

[DS_Starter]

Die Meldungen sind nicht so gut.
Es bedeutet folgendes. Du startest eine Aktivität und während die läuft (und noch nicht fertig ist) startest du mit dem gleichen Device wieder eine neue Aktion. Das Device bricht daraufhin seine laufende Aktivität ab was zu der Meldung führt "WARNING - old process 31994 will be killed now to start a new BlockingCall".

Da solltest du mal schauen wieso diese Überschneidungen auftreten und ggf. die Abläufe ändern oder verschiedene DbReps nutzen wenn möglich.