Ankündigung

**bmx** · 21.11.2016, 19:34

Du hast vermutlich zuviele Datensätze. Im Graph sind IMHO derzeit via widget.js der SmartVISU max. 100 Punkte pro Serie zugelassen. Du kannst mal schauen, ob Du das erweitern kannst indem Du in der Datei smartvisu/widgets/widget.jsZeile 921 statt count=100 eben mal count=1000 schreibst. Allerdings mußt Du dann dafür sorgen, das auch die widget.js genutzt wird. Dazu mußt Du in der config.php define('config_js', 'min.js'); ändern in define('config_js', 'js');

**schloessl** · 22.11.2016, 14:26

Hallo Bernd,

danke für Deine Antwort!

Leider verstehe ich nicht was ich mit dieser Lösung erreichen würde. Ich verschiebe doch nur das Problem um einige Tage und hätte bei jedem Update wieder eine Baustelle.

Ich glaube letztlich die Paramter für den Plot noch nicht richtig zu interpretieren.
In einem Zip.File habe ich noch einmal meine Problemstellung mit Code auszügen und Bildern dargestellt und einige Fragen hinzugefügt.

Vielleicht sollte ich auch einmal die fleißigen DB-Entwickler rund um @psilo999 ,@Foxi352 @ohinckel @onkelandy
ansprechen! Wenn das Problem mit der kommenden Version gelöst ist, kann mein post in die Mülltonne!

Bitte die Zip über folgenden Link ziehen, da die Größe hier Probleme machte! Danke!
http://www.hart21.de/support/plot_period.zip

**smai** · 22.11.2016, 14:51

Es gab da mal eine sehr lange Diskussion auf Gitter wegen 0 vs '0' vs 'now' beim tmax. Ehrlich gesagt weiss ich nicht genau, was die Quintessenz war.
Versuch doch mal im fünften Parameter statt der '0' (nach den '10d') entweder ein 'now', einen Leerstring (also zwei Hochkommas) oder eine 0 ohne Hochkommas einzusetzen.

Was mich auch noch irgendwie irritiert ist die linke Achse: Du gibst ja -10 als Minimum an, trotzdem geht sie bis -20. Keine Ahnung ob dies zusammenhängt oder noch ein anderer Fehler ist.

Noch zu deiner letzten Frag im Word:

Pro Meldesatz der Temperaturen werden 3 Temperaturwerte gespeichert. Oft ist der erste Wert als Exponentialwert, die folgenden als Dezimalwert gespeichert. Liegt das an der Aufzeichnung in der DB oder bei mir?

Die drei Werte sind Durchschnitt, Min und Max der Periode. Da der Durchschnitt als berechneter Wert viele Nachkommastellen hat, wird er wohl als Exponentialwert geschrieben. Min und Max haben ja nur genau soviele Nachkommastellen wie der Eingangswert.

**smai** · 22.11.2016, 15:02

Eben ist mir noch etwas anderes aufgefallen. Wenn man die Linien genau anschaut, sieht man, dass es vor den 10 Tagen zwei blaue hat.
Ausserdem hört wahrscheinlich die rote gleich wie die gelbe korrekt vor 10 Tagen auf (ausser sie würde tatsächlich in jeder Grafik genau ab da von der blauen überdeckt).

**schloessl** · 22.11.2016, 15:37

smai Danke für die prompte Antwort.

Anbei die Tests. Da scheint zum Glück kein Unterschied zu sein.

Ich forsche gerne weiter! Leider habe ich keine Ahnung wo ich ansetzen kann.
Zu 15:02 Es ist tatsächlich nur die blaue Linie, aber irgendwie mit einem Bauch. Es sieht aus wie doppelt gezeichnet.
Es wär so schön die Kurve nur ab dem gewünschten Zeitpunkt zu sehen!

Nachtrag:
'max', '7d', '', -10, '', 100,
bringt das gleiche Biild. Hier nur ein Zoom der blauen(doppelten) Linie.
Plot3.jpg
Now_Versuch.jpg

**bmx** · 22.11.2016, 18:57

Was ich oben geschrieben habe mit den 100 Werten trifft hier vermutlich nicht zu. Wer lesen kann ist klar im Vorteil...

Schau mal ob du feststellen kannst, ob die Werte überhaupt zum gewünschten Zeitraum passen. Also: liefert SmartHomeNG Wertepaare von zu frühen Zeitpunkten?
Hast Du statt 10d einfach spaßeshalber einen ansonsten identischen Plot dargestellt mit 240h?

**Tontechniker** · 23.11.2016, 10:22

Beispiel 1.jpg Beispiel 2.jpg

Habe die gleichen Probleme mit "plot.period".
Die Geraden dürften nicht dargestellt werden. Wo kommen die entsprechenden Werte her?
Habe von "d" auf "h" umgestellt - keine Veränderung.
Gruß Hans

Angehängte Dateien

**smai** · 23.11.2016, 11:02

schloessl
Kannst du irgendwie alle Daten aus der DB für das Item eg.gast.heizung.soll dumpen? Das Zip beinhaltet ja nur den letzten Eintrag.

Der Filter für die Dauer wird in SH.py angewendet, die smartVISU reicht diese 10d nur durch. Deshalb ist nun die Frage, ob SH.py die falschen Daten liefert oder die SV die richtigen Daten falsch anzeigt.

Da es anscheinend nur mit dem Soll-Wert Probleme gibt, mach doch mal den Plot nur für dieses Item:

HTML-Code:

{{ plot.period('eg.gast.plotHz',['eg.gast.heizung.soll'], 'max', '10d', '0', -10, '', 100, ['Soll'], ['#00f' ], '', ['Zeit','Temperature/°C'], '1h') }}

Debuggen der empfangenen Werte auf Seite der SV:
Und zu debuggen kannst du den von bmx erwähnten Eintrag in der config.php ändern: define('config_js', 'js');
Wenn du nun ein deinem Browser die Konsole aufrufst (z.B. F12 drücken), werden alle Daten, welche von SH.py übertragen werden, aufgelistet.
Da steht dann sowas wie [plot.period] update 'eg.gast.plotHz', das sich aufklappen lässt.

Je nach Browser ist es nun aber etwas kompliziert, diese Daten zu kopieren.

Für Chrome:
1. Rechtsklick auf [Array[...
2. "Store as global variable" auswählen. Es sollte temp1 auf der Konsole erscheinen.
3. Folgendes eintippen: copy(temp1) + Enter
4. Nun hast du die Daten in der Zwischenablage und kannst sie in ein Textfile einfügen.

Für Firefox mit Firebug:
1. Da steht sowas wie "[[[1479883402203, 117.79], [...". Da genau auf das zweite [ klicken.
2. Firebug springt ins Register DOM und Listet die Werte auf.
3. Dort drückst du Ctrl+A um alles zu markieren.
4. Danach Ctrl+C um zu kopieren.
5. Nun hast du die Daten in der Zwischenablage und kannst sie in ein Textfile einfügen.

Für Internet Explorer habe ich auf die Schnelle keine Lösung gefunden.

Debuggen der gesendeten Werte in SH.py
Soweit ich weiss, werden die gesendeten Werte ins Log geschrieben, wenn du SH.py von der Konsole mit -d startest (vorher natürlich den SH.py Service beenden).
Vielleicht kann da bmx genauer Auskunft geben.

Tontechniker du kannst das natürlich sinngemäss machen, ich kenne nur deine Item-Namen nicht.

**schloessl** · 23.11.2016, 11:48

Es wird immer undurchsichtiger!

<div data-role="collapsible" data-collapsed="false">
<h3>Verlauf Heizung</h3>
{{ plot.period('og.sued.plotHz', ['aussen.mdt.tempsun', 'og.sued.heizung.ist', 'og.sued.heizung.soll'], 'max', '10d', '0', 0, '', 100, ['Außen Ter.', 'Ist', 'Soll'], ['#ff0', '#f00', '#00f' ], '', ['Zeit','Temperatur/°C'], '1h') }}
{{ plot.period('aussen.plottmps', ['wugro.Temperatur', 'aussen.mdt.tempsun', 'wire.temp_r2'], 'max', '10d', '0', -10, '', 100, ['Vorschau', 'Sonne', 'Schatten'], ['#ff0', '#f00', '#00f' ], '', ['Zeit','Temperature/°C'], '1h') }}

</div>

Ich habe jetzt einmal 2 plots mit dem gleichen Zeitraum und der gleichen Auflösung eingebunden. Siehe Bild!
Gerade kam die Nachricht von smai 11:02 herein. Ich werde es versuchen, mit Firefox kann ich dienen!

Das in 4 plots jeweils die Sooltemperatur spinnen sollte, scheint mir etwas unwahrscheinlich. Evtl. habe ich in den Items noch ein Problem. Ich füge einmal den entsprechenden Bereich bei, der in allen 4 Räumen gleich aussieht.

[og]
[[sued]]
[[[heizung]]]
name = OGsued Heizung
type = foo
[[[[ist]]]]
type = num
sqlite = yes
# sv_widget = {{ device.rtr('item', 'item.name', 'item.ist', 'item.soll', 'item.komfort', 'item.nacht', 'item.frost', 'item.status') }} | {{ plot.period('item-plot', 'item', 'avg') }}
visu_acl = rw
knx_dpt = 9
knx_cache = 2/1/20
[[[[soll]]]]
type = num
visu_acl = rw
enforce_updates = yes
sqlite = yes
knx_dpt = 9
knx_send = 2/1/27
knx_cache = 2/1/29
[[[[modus_komfort]]]]
type = bool
knx_dpt = 1
visu_acl = rw
enforce_updates = yes
knx_cache = 2/6/16
knx_send = 2/6/16

Wohlgemerkt die Zeitachse ist 10d !!! i beiden Plots
plot4.jpg

**schloessl** · 23.11.2016, 12:08

Kleiner Nachtrag für smai

{{ plot.period('og.sued.plotHz', ['aussen.mdt.tempsun', 'og.sued.heizung.ist', 'og.sued.heizung.soll'], 'max', '10d', '0', 0, '', 100, ['Außen Ter.', 'Ist', 'Soll'], ['#ff0', '#f00', '#00f' ], '', ['Zeit','Temperatur/°C'], '1h') }}
{{ plot.period('aussen.plottmps', ['wugro.Temperatur', 'aussen.mdt.tempsun', 'wire.temp_r2'], 'max', '10d', '0', -10, '', 100, ['Vorschau', 'Sonne', 'Schatten'], ['#ff0', '#f00', '#00f' ], '', ['Zeit','Temperature/°C'], '1h') }}
{{ plot.period('eg.gast.plotHzt',['eg.gast.heizung.soll'], 'max', '10d', '0', 0, '', 100, ['Soll'], ['#00f' ], '', ['Zeit','Temperature/°C'], '1h') }}

Neue Interpretation der Zeitachsen!
10. Nov könnte für den Beobachtungszeitraum passen. Die Striche zuvor sind wohl Unsinn.
Mit -10 sind es genauso aus, zur besseren Darstellung 0 als Basis gewählt.

Übrigens, nach dem Löschen der Datenbank ist immer alles sauber, bis !! der Beobachtungszeitraum überschritten ist, dann beginnen die wilden Darstellungen.
plot5.jpg

**smai** · 23.11.2016, 13:12

Ich glaube nicht, dass du etwas falsch definiert hast.
Mein Verdacht ist, dass die Daten falsch gefiltert bzw. sortiert. Weshalb das nur bei der Solltemperatur geschieht, weiss ich aber auch nicht.

Wenn wir die letzte Grafik betrachten sieht man, dass die Linie eigentlich am richtigen Ort beginnt, nämlich am 13. Nov., 10 Tage vor Ende der Grafik.
Danach gibt es aber einen (falschen?) Punkt weit in der Vergangenheit und ab 10. Nov. dann zwar korrekte Punkte, die aber gar nicht angezeigt werden sollten.

Wenn korrekt sortiert würde, dürfte die Linie ja gar nie von rechts nach links springen.
Deshalb glaube ich, dass der erste Punkt richtig geholt wird, danach get es aber wegen falscher oder fehlender Sortierung in die Vergangenheit.

Wie erwähnt ist mir noch nicht klar, ob der Fehler in SH.py oder in der smartVISU geschieht.

Nachtrag:
Mir ist eben aufgefallen, dass du auf der Soll-Temperatur ein enforce_updates = yes hast. Ist das tatsächlich notwendig/sinnvoll?
Ich frage mich, ob das Problem damit zu tun hat, auf der Ist-Temperatur hast du dieses ja nicht. Wäre natürlich trotzdem ein Bug.

Interessant wäre ein kompletter DB-Dump deiner Daten von Soll- und Ist-Temperatur.

**schloessl** · 23.11.2016, 19:32

smai

Ich habe mich durchgekämpft.
In Transaction.docx findest Du alle *soll-Sätze aus dem smarthomedb.dump
Natürlich auch den .dump selber
das -d log
und in date_SV.txt den (gescheiterten ??) Versuch Deiner Anleitung zu folgen, Kommentar im Text,

Grob gesehen sieht bei den *.soll-Sätzen alles vernünftig aus. Durch die schwer nachvollziehare Datumsdarstellung ist ein direkter Vergleich schwierig.

Vermutung:
Die Sollwerte werden in meinem Energiesparhaus selten, wenn nicht garnicht geändert. Die Istwerte ändern sich natürlich mehrmals täglich.
Beim Lesen der Daten zum gewünschten Datum findet die DB keinen Sollsatz, jedoch die Ist.Sätze. Beim Lesen der Sollsätze ist das Ergebnisfeld nicht sauber gelöscht oder abgefragt. Irgendwelche Restdaten werden interpretiert und als Gerade bis zum gewünschten Datum gezeichnet.
Die These ist zwar gewagt, aber die Erscheinung lässt die Vermutung zu! ?

Mit dem DOM ist mir unklar. Gib mir bitte noch einmal einen Hinweis.(Firefox)
Ich freue mich direkt, daß es noch andere betrifft. Ich hatte schon 2mal entsprechende Beiträge ins Forum gestellt. Leider gab es keine verwertbare Hinweise.
Einmal hatte ich Entwarnung gegeben, aber es war verfrüht, da die 10d noch nicht überschritten waren.

Ich bin für Deine Hilfe sehr dankbar und werde Dich gerne weiter unterstützen!

Bitte die Zip über folgenden Link ziehen,Danke!
http://www.hart21.de/support/plot_dump.zip
plot_dump.jpg

**smai** · 23.11.2016, 20:54

Die Dateien sehen von weitem schonmal hilfreich aus, auch die date_SV.txt. Da deine Serie nicht so viele Punkte hat, werden sie anscheinend direkt angezeigt und nicht "zusammengeklappt". Ich hatte es mit 100 Pumkten getestet.

Ich versuche die Daten zu analysieren und melde mich wieder.

**smai** · 24.11.2016, 01:15

So, nach 2 Stunden Suche und kurz vor der Verzweiflung habe ich nun zumindest gesehen, dass der Fehler in den SQL-Daten liegt. Die Ursache dafür kenne ich aber leider nicht.

Im Anhang ist ein Excel, welches den Auszug aus der DB zeigt, welcher auch im Chart erscheint.
Die Daten sollten meines Erachtens eigentlich so aussehen, wie sie dies beim "ist" tun: An den Endzeitpunkt eines Eintrages sollte jeweils der Startzeitpunkt des nächsten anknüpfen.
Beim "soll" tun sie das überhaupt nicht, da gibt es wilde Überschneidungen.

Der extremste hat einen Start von 1'477'872'001'262 (= 31.10.2016 00:00:00) und eine Dauer von 2'180'617'704, was einem Ende am 25.11.2016 05:43:38 entspricht - also in der Zukunft.
Ein anderer mit Start 1478304001331 geht von 05.11.2016 00:00:00 bis 13.11.2016 20:22:49. Dieser Eintrag ist es dann auch, der im Plot diesen weiten Sprung in die Vergangenheit macht.

Wie gesatgt habe ich aber keine Ahnung, wie dies zustande gekommen ist.
Vielleicht können die SH.py Entwickler da etwa zu sagen.

Angehängte Dateien

SV_vs_DB_klein.zip (81,3 KB, 0x aufgerufen)

Ankündigung

Plot.period und Zeitachse

Plot.period und Zeitachse

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar