Wenn ich mir die Diagramme für die Ventilöffnung anschaue, dann wird nicht der Zeitpunkt der letzten 0% Stellung als Startpunkt genommen ( Ventil öffnet sich um X % ) sondern der erste Zeitpunkt, wo das Ventil auf 0% gesetzt worden ist:
Eigentlich muss hier der Grapf auf der 0 Linie (ab dem Zeipunkt 0) verlaufen und beim nächsten Heizen ein steiler Anstieg zu sehen sein.
Ja, das ist ein kleines Problem. Das habe ich auch schon an anderen stellen gesehen.
Wenn der Thermostat eben nur diese Werte liefert, kann dabei nichts anderes rauskommen.
Nehmen wir mal an, folgende Punkte werden vom Thermostat gesendet:
8:00:00 - 10%
8:00:10 - 0%
8:50:00 - 30%
8:50:10 - 31%
8:50:20 - 33%
8:50:30 - 35%
Dann zeiht die Kurve so aus:
homee kann/darf ja keine Punkte einfach so dazumogeln.
Ich weiß, was du dir vorstellst. homee soll ja nur einen Punkt dazumoglen, damit es „schön“ aussieht. Doch was ist das Kriterium für das dazumogeln?
Dann würde es so aussehen:
Aber WANN soll homee was dazumogeln. Das ist nicht ganz so einfach.
Nehmen wir mal an, wir erheben das Dazumogeln in den Olymp und sagen, das homee jedes mal den alten Wert wiederholen soll.
Dann sieht das ganze so aus:
Ist das nun schöner? Es würde nicht der Realtät entsprechen, denn so ein Thermostat schaltet ja nicht sprunghaft.
Außerdem müsste homee dann zwei Arten von Diagrammen supporten: Einmal mit Punktewiderholung und einmal ohne Punktewiderholung.
Wenn wir diesen Gedanken weiterspinnen, führt das tatsächlich zu einer zweiten Art von Diagrammen, nämlich dem Balkendiagramm.
Was macht man dann allerdings mit Werten, die nicht zyklisch (also nicht alle 10 s) kommen.
Dann ist das Diagramm wieder lückenhaft und führt wieder zur Kritik (die Balken, die fehlen, sind die nun 0?.
Dann müsste man wieder Balken dazumogeln, damit es einigermaßen „schön“ aussieht.
Das mit dem „dazumogeln“ ist immer so ne Sache. Man zeigt etwas, was nicht der Wahrheit entspricht.
Der Punkt auf einem Balken kann z.B. einen Messwert anzeigen, ein Balken ohne Punkt ist dazugemogelt.
Die Farbgebung muss man ja auch nicht so krass machen, wie ich sie jetzt gewählt habe.
Aber vielleicht findet jemand anderes noch eine andere Idee, um dieses Problem zu lösen
In der DB ist vermutlich der erste Zeitpunkt „0“ (Anfang) gespeichert. Wenn nun weitere „0“ ankommen, werden diese wohl nicht in der DB gespeichert. Hier sollte jedoch eine zweite „0“ mit dem letzte Zeitpunkt vorhanden sein. Kommt einen weitere Null, wäre nur der Zeitpunkt in der DB zu aktualisieren.
Damit hätten wir dann 2 x den Wert „0“ zum Anfang und vom zuletzt gemeldeten Zeitpunkt und das Diagram wäre korrekt
Und genau hier liegt der argumentative Fehler. Es gibt einen definierten Zeitpunkt an dem sprunghaft der Zielwert erhöht wird. Genau die Punkte dazwischen sind interpoliert und in der Realität nicht existent, weil ein Diagramm eben genau „sprunhaft“ schaltet! Deswegen muss man bei der Datenanalyse haargenau auf die verwendete Art achten - ein Treppendiagramm ist hier die richtige Diagrammart.
Ich möchte jetzt nicht streiten, aber meines Wissens sind in den Thermostatventilen Motoren verbaut, die die Ventilstellung motorisch (also in der Zeit) verstellen. Ich gebe dir recht, das die Zeit des Verstellens natürlich deutlich kleiner ist als die Zeit, in der die Stellung statisch ist. So könnte man einen quasi Sprung vermuten.
Mir persönlich wäre so ein Treppendiagramm auch sympathisch.
Aber letztendlich müssen das die Entwickler von homee entscheiden.
Meine Thermostate sind so eingestellt, dass Sie eine Zeitlang arbeiten und dann wird die Solltemperatur runter gefahren…Also so wie Stosslüften… 30Min an und dann erst mal z.B. für 3 Stunden Pause… Da hilft ein Diagramm welches über die 3 Stunden eine lineare Öffnung der Ventile oder anderen Funktionen anzeigt, nicht viel…da es nicht passt und es reine Annahme sind, das es a) ein Problem der Ansteuerung oder b) die falsche Darstellung des Diagrammes sind. Ab der umstellung der DB kann ich ja auch nicht mehr dem Batteriestand der Geräte vertrauen. Einzig die Stände nach einem gewollten Reboot sind glaubwürdig … Leider werden den HiH auch nur die „gemittelten Werte“ übergeben, so dass ein Fehler in der Mitte in der Kette voll weitergereicht werden…Und keine Änderung in Sicht???.
Wo sollen denn die weiteren Nullen herkommen? Das Thermostat wird ja nicht ständig oder ausgerechnet vor einer Verstellung eine Null senden, sondern nur den aktuellen Wert, wenn sich etwas verändert hat.
Nun gut wenn dass so ist, dann gilt die erste Null in der DB eben solange bis ein weiterer Wert kommt… Dann ist es ein Logikfehler bei den Diagrammen. Dies gilt übrigens auch für andere WErte.
Beispiel:
Zeitpunkt 123 => Wert 0
Zeitpunkt 456 => Wert 1
Zeitpunkt 789 => Wert 2
Wenn das Diagramm Wert 0 sieht, dann ist dieser Wert so lange gültig bis Wert 1 gültig wird, ebenso ist Wert 1 gültig solange bis Wert 2 gültig wird. Wenn zwischen Wert 1 und Wert 2 eine Woche liegt, bedeutet das doch nicht bei einem Steller, das dieser die Woche über die Zwischenwerte ( Zwischen Wert 1 und Wert 2) angenommen hat. Die wäre in Ordnung wenn ich einen Temperatur-, Spannungsverlauf etc darstellen möchte. Jedoch nicht bei Actoren, welche ihren Status wechsel (Stellung ) melden. Bei einem Ventil sind solange 50% bis es sich ändert und den neuen Wert übermittelt… Hier ist keine Verlauf anzugeben, sondern Sprunghaft…
Steller-Verlauf :
1 Tag 50% (in der DB)
2 Tag 50 % (nicht in der DB)
3 Tag 50 % (nicht in der DB)
4 Tag 50 % (nicht in der DB)
5 Tag 75% (in der DB
Steller: Da muss Tag 1,2,3 und 4 eine Gerade bei 50% sein und am 5 Tag der sprunghafte Anstieg nach 75%
Verlaufskurven (Bei Spannung, Temperatur…)
Hier ist der Ansatz der Diagramme richtig gewählt, da man davon ausgehen kann, das der Wert sich von Tag 1 bis Tag 5 kontinuierlich von 50 auf 75% erhöht hat und eine Meldung nur in 25% Schritten passiert oder in der DB aufgenommen wird.
Jap, und ich denke @TheDamned hat das super erklärt und gezeigt, wie man es mit einem anderen Diagrammtyp lösen könnte 
und der Algorithmus wäre auch einfach:
if(neuer Wert)
{
sende(alter Wert);
sende(neuer Wert);
alter Wert = neuer Wert;
}
