idee: logProxy device

[justme1968]

hallo rudi,

ich spiele gerade mit dem gedanken eine art proxy device für dblog und filelog zu bauen.

zum SVG modul hin würde sich das device wie ein 'normales' device verhalten das zum
abgefragten zeitraum werte lieftert.

als datenquelle würden dann je nach definition ein oder mehrer filelog, dblog oder konfigurierte regeln dienen.

anwendungsfällen könnten sein:

- daten aus mehreren logfiles in einem plot darstellen
- daten aus filelog und dblog in einem plot darstellen. z.b. nach migration noch altdaten
- einblenden zusätzlicher statischer daten oder daten aus readings wie z.b. das tagesprogramm eines heizungsthermostaten
- einblenden von max oder min linien im plot
- ...

bei den aller ersten tests fallen mir aber leider direkt diverse probleme auf die das ganze nicht umsetzbar machen weil dblog,filelog,SVG und fhemweb funktional nicht genau genug getrennt sind.

der größte stolperstein ist gerade das die #FileLog und #DbLog schlüsselworte im SVG modul anhand des log device typs so ausgewertet werden das sie im log device selber nicht mehr zur verfügung stehen. d.h. ein device vom typ logProxy bekommt keins von beiden mehr zu sehen und kann dann natürlich auch nichts mehr ans tatsächliche log device durchreichen.

du hast mal erwähnt das du die plot darstellung sowieso umstellen möchtest. vielleicht kann man dabei die schnittstelle zwischen frontend und log backend etwas sauberer machen und kapseln so das sonein proxy einfacher zu implementieren ist.

gruss
  andre

ps: bei den tests ist mir aufgefallen das $internal_data niemals zurückgesetzt wird. aus diesem grund führen manche fehler bei der plot definition dazu das statt eines fehlers oder eines leeren plots die daten eines alten plots gezeigt werden.

vielleicht sollte man im SVG modul das $internal_data vor dem aufruf des get löschen.

[rudolfkoenig]

Das SVG/FileLog/.plot Interface ist so definiert: die zum Filtern bzw. nachbearbeiten noetigen Daten sind in der .plot Datei in den #<LieferantTyp> Zeilen enthalten. An einem Mischer, der unterschiedliche LieferantenTypen mischt, habe ich dabei nie gedacht. Eine Moeglichkeit ohne das Interface anzufassen waere zusaetzliche #logProxy Zeilen ins .plot reinzuschreiben. Die zusaetzlichen Linien sind ein weiteres Problem: sie muessen in .plotfile auch deklariert werden (farbe/dicke/plot-typ,etc).

Nicht falsch verstehen, ich habe nichts gegen deinem Vorhaben, ich habe aber noch keine konkrete Idee, wie man es implementieren soll.

Das unfertige jsSVG nutzt das Lieferanten-Get ohne Spalten-Spec, damit bekommt es die Rohdaten fuer den Zeitraum.
Via FHEMWEB wird die .plot-Definitionsdatei ausgelesen. Fuer die Spaltendefinition wollte ich die#FileLog Zeilen verwenden, mit etwas substitute, damit man die $fld Berechnungen uebernehmen kann. Aendert nichts an deinem Problem.

$internal_data sollte vom SVG nach der Verwendung geloescht werden. Habs geaendert und eingecheckt.

[justme1968]

ich habe inzwischen eine version die fast alles macht was ich mir vorgestellt habe:

- unterschiedliche quellen in einem plot mischen (z.b. mehrere fileLogs)
- für festen y werte horizontale geraden einbelden
- das gleiche für dynamische y werte zum beispiel mit dem min, max oder avg wert einer anderen kurve
- beliebige zusätzliche daten wie das wochen profil von heizungs thermostaten oder dem weekday timer ohne über ein log file zu gehen

bevor ich die version für die codeschnipsel fertig mache noch ein paar fragen/anmerkungen:

- das mit den zusätzlichen linien im plot file war klar

- es gibt in 99_Utils ein time_str2num das in SVG nicht verwendet wird sondern SVG_time_to_sec. die time_str2num versteht die plot timestamps nicht wegen dem _. die SVG_time_to_sec versteht scheinbar auch die formate die time_str2num kennt. sollte das nicht alles zu einer einzigen routine vereinheitlicht werden?

- ich habe wieder das problem (das glaube ich schon mal behoben war) das die abfrage der plot daten doppelt passiert. eventuell ist aber auch nur meine installation zu alt. ich prüfe das noch mal.

- zur zeit muss ich auch die fileLog und dbLog teile über #logProxy zeilen laufen lassen weil es in SVG nur ein einziges get gibt dem alle lieferanten zeilen übergeben werden. für die bedienung wäre es einfacher wenn bei mehreren unterschiedlichen Lieferanten im plot file der mehrfache get aufruf schon im SVG modul gemacht wird.dann müssten die fileLog und dbLog zeilen nicht auf logProxy umgeschrieben werden. würdest du einen patch dafür akzeptieren? aber das kannst du eventuell auch das erst entscheiden wenn du das modul gesehen hast.

- würdest du ein paar allgemeine datums und zeit routinen wie z.b. den wochentag eines datums bestimmen, intervalle zu einem datum addieren oder das intervall zwischen zwei terminen bestimmen in 99_Utils mit aufnehmen?

[rudolfkoenig]

bevor ich die version für die codeschnipsel fertig mache

Wieso Codeschnipsel und nicht Frontend?

time_str2num vs. SVG_time_to_sec

Die beiden Funktionen sind fuer unterschiedliche Ziele optimiert und beim nicht spezifizieren der Parameter leifern sie Unterschiedliches zurueck. Insb. Letzteres will ich nicht aufgeben, bzw. alle Faelle testen. Ich schlage vor SVG_time_to_sec kommt unveraendert in 99_Utils.

Schleife in SVG:
Ich bin noch nicht davon ueberzeugt, dass das in SVG besser aufgehoben ist, als in deinem Modul.
Kannst du konkrete Probleme nennen? Und ich habe ein Gegenargument: ich koennte dein Modul auch aus JavaScript aufrufen

Routinen ins 99_Utils: kein Problem

[justme1968]

du hast recht. frontend ist besser.

wenn du das SVG_time_to_sec nach 99_Utils schiebst wäre eventuell auch ein SVG_sec_to_time als gegenstück dazu gut.

wegen der schleife:
die syntax im plot file die ich verwenden muss ist diese:

Code Auswählen Erweitern

#logProxy FileLog:FileLog_<SPEC1>:4:<SPEC1>.consumption\x3a::
#logProxy FileLog:FileLog_<SPEC1>:4:<SPEC1>.power\x3a::
#logProxy FileLog:FileLog_<SPEC2>:4:<SPEC2>.consumption\x3a::
#logProxy FileLog:FileLog_<SPEC2>:4:<SPEC2>.power\x3a::
#logProxy ConstY:$data{avg1}                   
#logProxy ConstY:$data{avg2}
#logProxy Func:logProxy_Heating_Control2Plot("HCB",$from,$to)

d.h. ich muss auch für die fileLog und dbLog zeilen das logProxy davor schreiben damit alles bei mir landet und zusätzlich das log device angeben.

ich dachte wenn das SVG device direkt eine schleife für unterschiedliche quellen hätte könnte man zumindest die einfachen dinge wie die letzten dir zeilen einfach zusätzlich in jedes beliebige plot file schreiben ohne die bestehenden zeilen zu ändern.

aber unabhängig von deinem js argument gegen das ich nicht ankomme geht es sowieso nicht. das svg weiss ja nicht zu welchem device es dann das get durchreichen soll wenn es mehr als eine quelle gibt. hat sich also erübrigt.

[rudolfkoenig]

wenn du das SVG_time_to_sec nach 99_Utils schiebst wäre eventuell auch ein SVG_sec_to_time als gegenstück dazu gut.

SVG_time_to_sec habe ich geschoben, fuer SVG_sec_to_time habe ich selbst kein Bedarf, wenn jemand ein Patch liefert, kann ich es gerne einfuegen.

[justme1968]

eine erste version gibt es hier: http://forum.fhem.de/index.php/topic,26529.0.html.

gruss
  andre

[justme1968]

rudi und tobias: würdet ihr einen patch einbauen der analog zu currdate auch mindate und maxdate bestimmt? dann kann man den zeitpunkt von maximum und minimum auch ausgeben und plotten.

[Tobias]

von mir aus gerne..... es muss nur abwärtskomatibel sein, dh. keine negativen Auswirkungen auf bestehende Definitions haben

[rudolfkoenig]

her damit. ich sehe (noch?) keine Gefahr.

[justme1968]

anbei die drei patches für mindate und maxdate.

[justme1968]

gibt es etwas neues zu den patches ?

[rudolfkoenig]

- SVG.pm: dein Patch verwirrt mich, entfernt etliche Aenderungen der letzten Zeit. Wenn nur Doku fuer mindate/maxdate gemeint ist, das habe ich jetzt selbst hinzugefuegt.
- FileLog.pm: habs hinzugefuegt/eingecheckt.
- DbLog.pm: ist nicht meine Baustelle

[justme1968]

der SVG patch war nur für die doku. mehr sollte da nicht drin gewesen sein.

danke
  andre

[Tobias]

sorry, vergessen....

erledigt.....