Frage zum History-Adapter
-
Jetzt sind wir bei dem dritten Punkt aus deinem Ausgangsthread - der Umgang mit null-Werten `
nicht ganz - bisher hatte ich nie null-Werte …die treten (bei mir) erst seit history 1.6.6 auf.
Deine Lösung laut doku ist auch keine schöne, denn
null als 0 (rot) ist nicht sinnvoll und null ignoriern (gelb) zeichnet Linien in die Zukunft ...
Die einzig sinnvollen "Lösungen" sind entweder das Verwenden von history 1.6.3 in der keine null-Werte auftreten/geloggt werden: (hier wurde nur alle 10 min geloggt - scheinbar ein Problem des history 1.6.3 - Daten vom Pi1B)
oder das Verwenden von Splines (experimentell in flot 1.7.0):
Mir würde die Behandlung von "null-Werten" wie in history1.6.3 aber mit korrekten Zeitstempeln wie in history1.6.6 am Besten gefallen.
Aber das wird nur bluefox regeln können.
PS.: wenn ich den ioBroker in Ruhe lasse und nichts daran neu starte etc. dann kommen wahrscheinlich auch keine null-Werte …
-
Wieso reden wir eigentlich immer aneinander vorbei??
nicht ganz - bisher hatte ich nie null-Werte … `
doch und das dachte ich als eine Möglichkeit dass du das bemängelt haben könntest. Mit der jetzigen Aussage:
@MeisterF:null ignoriern (gelb) zeichnet Linien in die Zukunft … `
Weiss ich jetzt, dass du das jedenfalls nicht wolltest.Aber ich bin mir immer noch sicher, dass dein Problem NICHT in history liegt, sondern in deinem Adapter/Heizung wo auch immer.
Irgendwo müssen ja diese NULL-Werte herkommen. Und das sollten sie nicht. Dann gäbe es auch nicht die Folgeprobleme.
Gruß
Rainer
-
Wieso reden wir eigentlich immer aneinander vorbei?? `
keine Ahnung :?:Aber ich bin mir immer noch sicher, dass dein Problem NICHT in history liegt, sondern in deinem Adapter/Heizung wo auch immer.
Irgendwo müssen ja diese NULL-Werte herkommen. Und das sollten sie nicht. Dann gäbe es auch nicht die Folgeprobleme. `
history 1.6.1 - es wird geloggt, es wird ordentlich dargestellthistory 1.6.3 - es wird weder geloggt und dadurch werden konstant bleibende Werte nicht dargestellt
history 1.6.6 - es wird geloggt, auch alle 5 min, nur wenn (irgendwas) nicht bereit ist, wird auch mal ein null-Wert geschrieben
float kann die null-Werte, die (bei mir zum ersten Mal mit hostory 1.6.6 auftraten) geloggt werden nicht so behandeln, wie ich es gerne hätte
Die null-Werte treten bei history 1.6.6. dann auf, wenn ich zwischenzeitlich ioBroker beende, neu starte, adapter installiere und restarte oder eben auch einzelne Adapter restarte.
-
Irgendwo müssen ja diese NULL-Werte herkommen. `
Nein, die erzeugt History 1.6.6 selbst bei (Re-)Start der Instanz oder bei Aktivierung der Aufzeichnung des Datenpunktes. -
die erzeugt History 1.6.6 selbst bei (Re-)Start der Instanz oder bei Aktivierung der Aufzeichnung des Datenpunktes. `
Das sollte history 1.6.6 aber ganz schnell mal wieder lassen :roll: -
Warum?
DIe Idee ist das beim Beenden und Starten des Adapters "null" Werte geschrieben werden,damit man in Graphen sehen kann das Daten "nicht da sind". Wenn die einfach nur fehlen dann wird es in Graphen standardmäßig "verbunden" wenn es im Darstellungszeitraum ist. "Null" heisst eindeutig "nicht da".
Was ist schlimm daran?
Habe oben geschaut aber so wirklich das Problem aus den Graphen nicht finden können.
-
Naja, es gibt immer mehrere Sichtweisen.
Ich hätte gerne durchgehende Graphen, die am Zeitpunkt der letzten Datenaufnahme enden.
ein eingetragener Wert "null" führt im float mit Linie:
Standard: zur Lücke (gefällt mir nicht)
beim Ignorieren: zu einer Geraden in die Zukunft
bei = 0: zu Zacken zur Null
bei spline wird durchgezogen - da kubische Splines die umgebenden Punkte verwenden und die "null" ausblenden, würde ich mich eben freuen, wenn das bei linie ebenso gehandhabt würde
Dies könnte erreicht werden, wenn history die "null" nicht schreibt oder wenn float die "null" bei Linie so behandeln würde, wie bei Spline.
Ich nehme aber an, dass linie einfach nur die beiden letzten Punkte verbindet, was es bei einem "null"-Wert nicht kann, spline verwendet hier ja mindestens drei Punkte (Werte)
Eine Änderung in history zu dem nicht "null" in die Daten schreiben würde keine Änderung an float bedeuten.
Aber auf PC-Hardware kann ich auch mit spline leben (höherer Rechenaufwand) - und wenn man den Adapter oder ioBroker nicht neu startet, dann erscheinen diese null-Werte auch nicht.
Aber genau das ist der Punkt - wenn die tatsächlich nur geschrieben werden, wenn history1.6.6. beim Start noch einen Wert bekommen kann, dann müsste es die auch nicht schreiben.
-
Naja, das einfachster wäre also da mit dem „null schreiben“ konfigurierbar zu machen … mach mal ein github issue als feature request auf und ich schaue bei Gelegenheit was ich tun kann. Der Aufwand ist halt etwas größer weil wir versuchen History, sql und InfluxDB was Features abgeht wenn möglich in Sync zu halten ...
-
Ich finde das aussetzen der Linie bei null extrem hilfreich.
Dann sieht man wenn ein Gerät null statt eines wertes liefert.
-
Ich finde das aussetzen der Linie bei null extrem hilfreich.
Dann sieht man wenn ein Gerät null statt eines wertes liefert. `
Schließe mich dem an. Bei einem 24/7 Produktivsystem tritt der Fall auch nur selten ein. -
Gestern war mein MQTT-Broker ausgefallen, habe ihn komplett neu aufgesetzt,
und einzelne Subscriptions liefen heute noch nicht korrekt.Das habe ich dann hier sehen können:
…und korrigiert
Gruß
Rainer
-
Der Aufwand ist halt etwas größer weil wir versuchen History, sql und InfluxDB was Features abgeht wenn möglich in Sync zu halten … `
ok - wenn alle drei history-Adapter gleich funktionieren sollen, dann ist der Aufwand bei diesen Adaptern größer.
Dann wäre es wohl besser, ggf. in float eine weitere Behandlungsmöglichkeit von null-Werten anzubieten, die auch bei "null" Linien durchzieht.
(für Leute wie mich)
Mein Problem sind/waren ja nicht die "null"-Werte an sich, sondern nur die, die beim ersten Start / restart von history 1.6.6 aufgetreten sind. Das waren für mich unnötige Lücken im Graph. Sollte die Verbindung zum Adapter oder zur Hardware oder die Hardware ausfallen, dann sind fehlende Werte etc. natürlich sinnvoll.
