logProxy modul zum manipulieren und ergänzen von SVG plots

[frank]

Das mit dem event-min-interval würde wieder in ein elendes Gefummel ausarten :>

es gibt auch was neues:

event-aggregator

@andre
könnte man nicht die option "extend=0" ändern, sodass die den ersten "normalen" plot-wert nach hinten verlängert. oder als extra option, falls extend im angegebenen zeitraum nichts findet. zb für langsame, kontinuierliche änderungen: batteryVoltage, kellerfeuchte, wasserstand, ...

[gero]

Hallo,

ich habe gestern seit etwas längerer Zeit mal wieder ein Update gemacht.
Leider funktioniert seitdem das Plotten der Heating_Control Profile nicht mehr.
Statt dessen bekomme ich im log folgende Fehlermeldung:

Code Auswählen Erweitern

logProxy_WeekProfile2Plot: no profile hash given

Das Profil ist im Ploteditor wie folgt eingetragen:

Code Auswählen Erweitern

logProxy_WeekProfile2Plot("OG.EZ.MAX.HCB",$from,$to)

Hier noch ein list OG.EZ.MAX.HCB:

Code Auswählen Erweitern

Internals:
   COMMAND    {if(ReadingsVal("ecostate","state",0) != 1) {fhem("set @ desiredTemperature %")}}
   DEF        OG.EZ.MAX.WT Mo-So|05:30|21.0 Mo-So|18:00|17.0 {if(ReadingsVal("ecostate","state",0) != 1) {fhem("set @ desiredTemperature %")}}
   DEVICE     OG.EZ.MAX.WT
   GlobalDaylistSpec
   LANGUAGE   de
   NAME       OG.EZ.MAX.HCB
   NR         407
   Profil 0: Sonntag 05:30:00 21.0, 18:00:00 17.0
   Profil 1: Montag 05:30:00 21.0, 18:00:00 17.0
   Profil 2: Dienstag 05:30:00 21.0, 18:00:00 17.0
   Profil 3: Mittwoch 05:30:00 21.0, 18:00:00 17.0
   Profil 4: Donnerstag 05:30:00 21.0, 18:00:00 17.0
   Profil 5: Freitag 05:30:00 21.0, 18:00:00 17.0
   Profil 6: Samstag 05:30:00 21.0, 18:00:00 17.0
   STATE      21.0
   TYPE       Heating_Control
   CHANGETIME:
   Helper:
     Dblog:
       Nextupdate:
         Mydblog:
           TIME       1427859000.12439
           VALUE      18:00:00
       Nextvalue:
         Mydblog:
           TIME       1427859000.12439
           VALUE      17.0
       State:
         Mydblog:
           TIME       1427859000.12439
           VALUE      21.0
   Readings:
     2015-04-01 05:30:00   nextUpdate      18:00:00
     2015-04-01 05:30:00   nextValue       17.0
     2015-04-01 05:30:00   state           21.0
   SWITCHINGTIMES:
     Mo-So|05:30|21.0
     Mo-So|18:00|17.0
   Timer:
     Og.ez.max.hcb_05:30:00:
       HASH       OG.EZ.MAX.HCB
       MODIFIER   05:30:00
       NAME       OG.EZ.MAX.HCB_05:30:00
     Og.ez.max.hcb_18:00:00:
       HASH       OG.EZ.MAX.HCB
       MODIFIER   18:00:00
       NAME       OG.EZ.MAX.HCB_18:00:00
     Og.ez.max.hcb_settimerofday:
       HASH       OG.EZ.MAX.HCB
       MODIFIER   SetTimerOfDay
       NAME       OG.EZ.MAX.HCB_SetTimerOfDay
   Daynumber:
     !$we       8
     $we        7
     di         2
     do         4
     fr         5
     mi         3
     mo         1
     sa         6
     so         0
   Helper:
     DESIRED_TEMP_READING
     daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
     daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
   Longdays:
     de:
       Sonntag
       Montag
       Dienstag
       Mittwoch
       Donnerstag
       Freitag
       Samstag
       Wochenende
       Werktags
     en:
       Sunday
       Monday
       Tuesday
       Wednesday
       Thursday
       Friday
       Saturday
       weekend
       weekdays
     fr:
       Dimanche
       Lundi
       Mardi
       Mercredi
       Jeudi
       Vendredi
       Samedi
       weekend
       jours de la semaine
   Profil:
     05:30:00:
       NEXTPARA   17.0
       NEXTSWITCH 18:00:00
       PARA       21.0
       TIM        1427859000
       TAGE:
         0
         1
         2
         3
         4
         5
         6
     18:00:00:
       NEXTPARA   21.0
       NEXTSWITCH 05:30:00
       PARA       17.0
       TIM        1427904000
       TAGE:
         0
         1
         2
         3
         4
         5
         6
   Shortdays:
     de:
       so
       mo
       di
       mi
       do
       fr
       sa
       $we
       !$we
     en:
       su
       mo
       tu
       we
       th
       fr
       sa
       $we
       !$we
     fr:
       di
       lu
       ma
       me
       je
       ve
       sa
       $we
       !$we
Attributes:
   room       2.00_Heizung


Eine erste Fehlersuche hat ergeben, dass die Funktion logProxy_Heating_Controll2WeekProfile in Zeile 124

Code Auswählen Erweitern

  return undef if( !defined($defs{$d}->{helper}{SWITCHINGTIME}) );
ein undef zurückliefert.

Vor dem Update funktionierte noch alles. Im svn log habe ich allerdings keine offensichtliche Änderung gesehen, die zu dem Problem führen könnte.

Hat jemand ein ähnliches Problem, oder einen Tipp woran es liegen könnte?

Gruß,
Gero

[justme1968]

die internals von WeekdayTimer haben sich mit dem update geändert. ich muss mal schauen wie ich jetzt an die daten komme.

gruss
  andre

edit: ich habe mal bei dietmar nachgefragt ob wir das vielleicht über eine feste schnittstelle hin bekommen.

[vbs]

Hi Andre,

ich hab da so eine fixe Idee bzgl. des Problems, dass oft links im Plot bis zur Y-Achse eine Lücke entsteht, da dort keine alten Daten vorhanden sind. Man kann dem Problem ja beikommen, indem man bei logProxy "extend" angibt und damit den angefragten Datenbereich vergrößert.

Die Idee wäre jedoch, dass logProxy sich einerseits (zeitlich) genau die Daten zum plottenden Bereich holt (ohne extend zu nutzen). In den Daten wird nun der Zeitbereich von der linken Y-Achse bis zum ersten Datenwert fehlen (mehr oder weniger große Lücke). Jetzt würde logProxy eine zweite Anfrage stellen und sich den gesamten Bereich zeitlich VOR dem Plotbereich holen. Um die Datenmenge gering zu halten, würde man die Anfrage jedoch SQL-LIMIT auf einen einzelnen Record beschränken (und mit ODER DESC entsprechend sortieren). Damit hätte man dann in jedem Fall genau einen passenden Datenpunkt, um die Lücke im Plot nach "links" zu füllen.

Man müsste dazu nur DbLog_Get anpassen, so dass man einen weiteren Parameter für LIMIT angeben kann. Und dann eben aus logProxy eine zweite Anfrage starten, die sich per LIMIT=1 genau einen Datenpunkt holt.

Was hältst du von der Idee? Denkst du, dass da so machbar wäre? Mir ist klar, dass du besseres zu tun hast als Feature-Requests von irgendwelchen Leuten einzubauen. Daher würde ich mich daran auch selbst versuchen wollen. Ich würde jedoch erstmal abfragen wollen, was du generell davon hältst, bevor ich mir die Arbeit mache.

Ich hoffe, ich konnte das jetzt einigermaßen verständlich erklären.

[justme1968]

ich weiß was du meins aber ich habe das gefühl das es unterm strich dadurch nicht effizienter wird.

statt einer anfrage an die db sind es zwei und dann muss der zusätzliche wert auch noch in die erste liste eingebaut werden. zumal die daten vor dem anfang für das limit 1 ja auch noch umgekehrt sortiert werden müssen.

das ganze würde so einfach auch nur für dblog funktionieren. bei filelog ist das deutlich aufwändiger.

ich bin bis jetzt der meinung das sich der extend zeitraum recht gut abschätzen lässt und der zusätzliche bereich die eigentliche db anfrage nicht merklich verzögert. für den fall das man auf tages oder stunden ebene ist ist die gesamt menge inklusive extend immer noch klein. auf monats und jahresebene fallen die werte die über extend dazukommen nicht wirklich ins gewicht.

bevor du das angehst und die zusätzliche komplexität ins spiel kommt solltest du versuchen nachzumessen welches verhältnis die db abfrage zur gesamtzeit zum darstellen eines plots hat und welcher teil davon auf extend entfällt.

dieser teil ist theoretisch alles was sich durch deinen vorschlag optimieren ließe.

ich habe das gefühl das sich mit dem gleichen aufwand an zeit an anderen stellen in fhem deutlich mehr herausholen lässt.

du hättest damit übrigens nur den anfang des plots repariert. am ende musst du gleiche machen sobald zurück geblättert wird. das wären dann schon drei abfragen und werte sammeln.

wenn du die gesamtzeit für dblog und filelog wirklich merklich verbessern kannst nur zu.

gruß
  andre

[justme1968]

ich weiß was du meins aber ich habe das gefühl das es unterm strich dadurch nicht effizienter wird.

statt einer anfrage an die db sind es zwei und dann muss der zusätzliche wert auch nich in die erste liste eingebaut werden.

das ganze würde so einfach auch nur für dblog funktionieren. bei filelog ist das deutlich aufwändiger. zumal die Daten vor dem anfang für das limit 1 ja auch noch umgekehrt sortiert werden müssen.

ich bin bis jetzt der meinung das sich der extend zeitraum recht gut abschätzen lässt und der zusätzliche bereich die eigentliche db anfrage nicht merklich verzögert. für den Fall das man auf tages oder stunden ebene ist ist sie gesamt menge inklusive extend immer noch klein. auf monats und jahresebene fallen die werte dir über extend dazukommen nicht wirklich ins gewicht.

bevor du das angehst und die zusätzliche komplexität ins spiel kommt solltest du versuchen nachzumessen welches verhältnis die die db abfrage zur gesamtzeit zum darstellen eines plots hat und welcher teil davon auf extend entfällt.

dieser teil ist theoretisch alles was sich durch deinen vorschlag optimieren ließe.

ich habe das gefühl das sich mit dem gleichen aufwand an zeit an anderer stelle deutlich mehr herausholen lässt.

du hättest damit übrigens nur den anfang des plots repariert. am ende musst du gleiche machen sobald zurück geblättert wird. das wären dann schon drei abfragen und werte sammeln.

wenn du die gesamtzeit für dblog und filelog wirklich merklich verbessern kannst nur zu.

gruß
  andre

ps: ein beispiel das mindestens 1-2 grössenordnungen mehr optimierung bietet ist beim raus zoomen von den echten messwerten auf stunden oder tages mittelwerte umzuschalten.

das reduziert z.b. die gesamt datenmenge mancher plots auf jahresebene von mehreren zehn tausend auf ein paar hundert.

das habe ich hier schon testweise laufen und es macht richtig spaß

[vbs]

Also mir gehts da eigentlich nicht um die Performance, sondern eher um die Benutzbarkeit. Ich bin nicht sicher, ob man diesen extend-Zeitraum immer so problemlos festlegen kann. Wenn ich beispielsweise desired-temp eines Thermostates plotten möchte, dann kann es ja sein, dass der sich auch mal monatelang nicht ändert. Trotzdem würde ich gerne im Plot den letzten Wert sehen.
Abgesehen davon, ist es einfach nicht sehr elegant, per extend einen per Daumen abgeschätzten "großen" Wert einzutragen, der dann hoffentlich jetzt und in Zukunft ausreichend ist. Fühlt sich irgendwie "unschön" an... :/

Aber das mit der rechten Seite beim Zurückscrollen ist natürlich ein guter Punkt... müsste man auch machen :/

Wenn du Bedenken wegen der mehrfachen SQL-Anfragen hast, könnte man das evtl auch per UNION in eine einzige vereinen. Würde das ganze aber wahrscheinlich wesentlicher komplizierter machen, da dann viel mehr Logik direkt in DbLog rein müsste.

[justme1968]

wenn es einfach und transparent sein soll muss es denn dblog mit sqlite und mysql sowie für filelog gleichermaßen funktionieren.

wenn du das hin bekommst ohne das langsamer und überkompliziert wird versuch es.

dann würde ich es aber eher direkt in dblog und filelog oder svg einbauen und für diesen fall ganz ohne
logoroxy arbeiten.

mit einem attribut global oder pro plot eingeschaltet wäre das die einfachste variante für die anwender.

[vbs]

Hm, naja, ich denke mal, dann bin ich raus... Klingt natürlich gut, aber ich fürchte, mit so einer Hochglanz-Lösung werde ich leider nicht dienen können. 

[justme1968]

nicht so schnell aufgeben. das macht es doch nicht komplizierter...

[justme1968]

mit den letzten WeekdayTimer und Heating_Control update sollte es keine probleme mit logProxy mehr geben.

die werte für die neuen tage 7 und 8 (wochenende und wochentags) werden auch automatisch richtig mit angezeigt.

gruss
  andre

[igami]

Mir ist noch eine Kleinigkeit aufgefallen.
Wenn am aktuellen Tag noch kein Ereignis aufgetreten ist, dann wird die Linie trotz predict bis zum Tagesende durchgezogen.

Gibt es hierfür mittlerweile ein Lösung?

[justme1968]

sorry. das ist untergegangen.

mein entwicklung rechner ist gerade zur reparatur.

hast du eine plotdefinition und ein log file mit dem das reproduzierbar ist?

gruss
  andre

[igami]

Hallo andre,

hier mein .gplot file:
SVG_21Flur_1.gplot

Code Auswählen Erweitern


# Created by FHEM/98_SVG.pm, 2015-05-14 20:41:25
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '2.1:Flur'
set ytics
set y2tics
set grid
set ylabel "oE"
set y2label "state"
set yrange [0:200]
set y2range [-5:105]

#logProxy DbLog:DbLog,predict,extend=24*60*60:HM_29F65B:brightness
#logProxy DbLog:DbLog:HM_29F65B:state:::$val=$val=~"motion"?50:0
#logProxy DbLog:DbLog,predict,extend=4*7*24*60*60:HM_24C9DA:state:::$val=$val=~"open"?100:0
#logProxy DbLog:DbLog,predict,extend=4*7*24*60*60:di_psc_2.1Flur:state:::$val=$val=~"present"?100:$val=~"absent"?0:50
#logProxy DbLog:DbLog,predict,extend=4*7*24*60*60:HM_24074C:state:::$val=$val=~"on"?100:0

plot "<IN>" using 1:2 axes x1y1 title 'Helligkeit <L1> oE' ls l6fill lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'Bewegung' ls l1 lw 1 with points,\
     "<IN>" using 1:2 axes x1y2 title 'Tür <L3>' ls l6 lw 1 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'Bewohner <L4>' ls l1fill lw 1 with steps,\
     "<IN>" using 1:2 axes x1y2 title 'Beleuchtung <L5>' ls l3 lw 1 with steps


Eine log file habe ich leider nicht, da ich nur DbLog verwende, es sollte aber auch mit einem Dummy funktionieren. Problem ist immer dann, wenn ich hier morgens mal ins Plot gucke bevor die Tür das erste mal geöffnet wurde, die linie geht dann bis zum Ende durch, obwohl ja mit predict nur bis zum aktuellen Wert gehen sollte.

grüße
igami

[DerFrickler]

Hallo zusammen,

besteht hier auch die Möglichkeit einen Bereich horizontal zu kennzeichnen? Z.B. einen Bereich innerhalb dessen die Luftfeuchtigkeit optimal ist?

Im Grunde währe das so etwas wie
ConstY:<value>[,<from>[,<to>]]
nur dass from und to sich nicht auf die x-Achse beziehen, sondern einen Bereich auf der y-Achse einschliessen.

Gruß!