[patch] 93_DbLog.pm - add FW_detailFn und SVG_sampleDataFn

[betateilchen]

Damit man, wie hier im Screenshot zu sehen, künftig auch aus der Detailansicht eines DbLog direkt in den SVG Editor springen kann

(http://up.picr.de/18166379qb.png)

schlage ich folgenden Patch vor:

EDIT: patch entfernt, neue Version im nächsten Beitrag

• die erforderliche Vorlage templateDB.gplot wurde von mir bereits eingecheckt
• die Funktion für die Bereitstellung von Beispieldaten wird nachgereicht, wobei deren Sinnhaftigkeit bei DbLog noch nicht richtig abschätzen kann

[betateilchen]

Hier noch die Erweiterung für die sampleData

(http://up.picr.de/18169033jn.jpg)

[Pnemenz]

Hallo betateilchen,

Danke für diesen Patch. Ich halte es für sehr Sinnvoll, zur Kontrolle auch die Sampledata zu sehen. 

Was ich noch nicht verstanden habe, ist eine bestimmte Spalte aus der Ergebniszeile auszuwählen.

Ich will die sysmon Daten auf DbLog umstellen und komm da nicht weiter.

Wie muss ich die #DbLog Zeile in der gplot Datei anpassen um z.B. aus der Zeile 'Total: 3745.44 MB, Used: 572.84'  den Totalwert bzw den Used Wert zu bekommen?
Wenn ich aus dem dropdown 'Device:Reading' auswähle kommt immer eine 0-Linie. Außer ich wähle ein Reading aus das in der ersten Spalte numerische werte stehen hat (auch da kann ich nur die erste Spalte auswählen)

Peter

[betateilchen]

Du solltest in DbLog die Einzelreadings "Total" und "Used" verwenden und nicht mit Spalten arbeiten - da ist etwas Umdenken angesagt. Falls das Modul solche Einzelreadings nicht bereitstellt, sollte der Modulautor das nachholen.

DbLog versucht bereits beim Loggen, aus den generierten Events die Werte "reading" "value" "unit" zu trennen, sodass Du dann in #DbLog nur noch die <device>:<reading> Kombination angibst, um den entsprechenden Wert zu plotten.

[Tobias]

Hi  Udo,

folgendes Statement im diff würde bei den meisten für die nächsten minuten bis Stunden, je nach DB-Größe und CPU den FHEM-Server lahmlegen:
select device,reading,value from history where device <> '' group by device,reading order by timestamp desc
Hier erfolgt faktisch ein "full table scan"

Mindestens ein Device und ein Zeitintervall muss angegeben werden.
Bei mir zb. würden 11Mio Datensätze selektiert werden. Ev. wäre es besser die Tabelle current zu nutzen.. Da steht alles drin, aber nur 1 sample. Dafür aber nach ein paar Millisekunden....

[betateilchen]

ja, ich weiss, dass das select problematisch ist. aber eine richtig gute Lösung ist mir noch nicht eingefallen. Die current scheidet aus Logikgründen genauso aus wie eine beliebig gewählte Eingrenzung. Aber ich werde nochmal zwei andere Ansätze testen. Den ersten Teil kannst Du aber ja schon übernehmen. übrigens: bei den Datenmengen, mit denen ich in meiner täglichen Arbeit zu tun habe, sind 11 Mio Datensätze geradezu lächerlich

[Tobias]

bei mir sind berufsbedingt 11Mio auch übelst lächerlich, aber da ist auch kein RPI bzw eine IConnect mit 1Ghz ARM CPU im Einsatz

[betateilchen]

Nun habe ich drei weitere Varianten für die Beschaffung von Beispieldaten getestet, keine davon hat mich richtig glücklich gemacht. Ich habe mich nun dazu durchgerungen, doch die current zum Lesen zu verwenden. Das bedeutet natürlich, dass in dem Fall, wo ein Anwender sein DbLog so attributiert hat, dass nur History geschrieben wird, keine sample data zur Verfügung stehen. In dem Fall wird eine Zeile zur freien Eingabe der device:reading Parameter angeboten und ein entsprechender Hinweis ausgegeben:

(http://up.picr.de/18192293wh.png)

Das ist für mich ein vertretbarer Kompromiss und dem Anwender wird eindeutig signalisiert, warum er keine Beispieldaten und keine Dropdownliste zur Auswahl hat.

Einverstanden? Wenn ja, baue ich später nochmal ein diff. Muss dazu erst noch ein bisschen Debugging-Code aus meinem Coding entfernen.

[Tobias]

Bin zufrieden

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

[betateilchen]

Hier kommt der versprochene patch

Ich habe gleich noch zwei Dinge eingebaut:

• Umstellung auf generisches FileRead, d.h. man muss im Modul nicht mehr auf configDB oder Konfigurationsdatei unterscheiden
• Das Splitten des Events kann nun im zugehörigen Gerätemodul erfolgen, sofern dieses Modul eine $hash->{DbLog_splitFn} bereitstellt

Zu Punkt 2:

Der entscheidende Vorteil von DbLog_splitFn ist, dass ich bereits als Modulautor dafür sorgen kann, dass 93_DbLog die Daten "meines" Moduls richtig loggt und nicht bei jedem neuen Modul / Readingtyp das DbLog modifiziert werden muss, um das Splitten durchzuführen. Bei der aktuell anhaltenden inflationären Modulflut wird nämlich 93_DbLog irgendwann in diesem Punkt völlig unwartbar. Vermutlich wird diese Möglichkeit auch noch im Zusammenhang mit der aktuell von Boris stattfindenden Entwicklung RTypes hilfreich werden.

[Tobias]

Kann das sein das du schon in einem Patch vorher den Status des defines von "active" auf "connected" gesetzt hast?
Bin gerade drüber gestolpert da einige Abfragen darauf nicht mehr funktionieren...

[betateilchen]

Jetzt nochmal mit einer richtigen Tastatur, auf dem Handy zu schreiben ist einfach eine Strafe ...

Die Änderung in "state" kam im Zusammenhang mit dem "Warten auf die Verbindung". Es ging darum, einen tatsächlich aussagekräftigen Inhalt in "state" zu haben. Das DbLog_Define() setzt den state ausschließlich auf "waiting for connection", bevor es die Kontrolle dann an DbLog_Connect() übergibt und sich danach nicht mehr um state kümmert.

In DbLog_Connect() wird der state auf "connected" gesetzt, sobald die Verbindung zur Datenbank erfolgreich hergestellt wurde.

Die blosse Anzeige "active" im state ist einfach nicht mehr korrekt interpretierbar, denn auch das Warten auf die Verbindung ist ein Zustand, in dem das definierte Device aktiv ist.

[Tobias]

eingecheckt, sollte morgen dann verfügbar sein...

[betateilchen]

danke.

Bei der SVG_sampleDataFn besteht noch Optimierungspotenzial, aber für den Anfang funktioniert sie erstmal, und das war mir die Hauptsache.

[Tobias]

Ist auch hier ergänzt:
http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#X_DbLog_splitFn