Frage zum History-Adapter
-
In meinem Verständnis wurden gleiche Werte unterdrückt außer es wird nach der (gleiche Daten aufzeichnen nach..) Zeit ein weiterer gleicher Wert geliefert. `
Wenn "nur Änderungen aufzeichnen" aktiv ist, werden gleiche Werte, bei denen nur der Zeitstempel aktualisiert wird (Beispiel: Temperatur aus HM-Wandthermostat alle 2,5 min) unterdrückt. Ohne den Haken werden Werte aus dem WT alle 2,5 min aufgezeichnet.Die Option "Gleiche Werte aufzeichnen" erzeugt durch History selbst generierte Einträge im vorgegebenen Abstand (dort, wo es funktioniert).
Mein Anwendungsfall: Meine Flot-Charts zeigen meist einen Zeitraum von 48 h. Für die Darstellung von Auf-/Zu-Ventilen, die im Sommer nur einmal pro Woche für 5 Minuten öffnen, lasse ich gleiche Werte alle 24 h aufzeichnen. Das funktioniert unter Raspbian Jessie.
Schönes Weihnachtsfest
-
Vielen Dank,
ich habe nun die alte ioBroker-Version, die ich auf den debian-PC kopiert hatte, Adapter für Adapter geupdatet.
Jetzt macht die fast ganz neue Version was sie soll - aber ich durfte history nicht von 1.6.1 auf 1.6.3 updaten, dann loggte es die gleichen Werte nicht mehr.
Da ich nach jedem Update eine Kopie des Ordner /opt/iobroker gezogen habe und nach jedem Update ein reboot des PCs und dann mind. drei gleiche Werte haben loggen lassen - hat das Ganze "ewig" gedauert. Aber jetzt sieht es so weit gut aus - jetzt heißt es rebooten und beobachten.
Ein Problem bleibt:
Ich habe 300s zum Speichern gleicher Werte in den Objekteinstellungen eingegeben - ich habe 6min im km200-Adapter in seinen Adaptereigenschaften eingeben - ich habe 300s für gleiche Daten im history-Adapter 1.6.1 eingestellt - geloggt wird alle 10 min … aber das passt mir für die Heizung auch.
-
Dann kommen wir ja (fast) zu einer Lösung.
Die Info mit den selbst generierten Werten für History ist mir neu (passt aber zu dem log, dass obwohl keine echten Werte bei km200.0 zu sehen waren etwas in history geschrieben wurde - auch wenn man es in der Liste nicht sah - das ist ggf. ein anderer Bug)
Für mich war daher primär wichtiger wieso der km200.0 keine Werte bei pressure abholte.
Schöne Weihnachten
Rainer
-
Habe gerade History Version 1.6.1 unter Win 7 getestet: Die Option "Gleiche Werte aufzeichnen" funktioniert in dieser Version. Allerdings werden die Zeitstempel in History gleichgeschaltet (immer die letzte Zeit).
-
sie passt nicht zu dem log, denn das log war ja von der nicht-funktionierenden Version mit history1.6.3 erzeugt.
In neueren Versionen - also ab 1.6.3 sollte das dann so gehen:
"Log unchanged values any(s) - When using "log changes only" you can set a time interval in seconds here after which also unchanged values will be re-logged into the DB"
siehe https://github.com/ioBroker/ioBroker.hi … /README.md
Aber bei mir passierte das nach dem Update auf 1.6.3. nicht - es wurde nicht geloggt
-
"Log unchanged values any(s) - When using "log changes only" you can set a time interval in seconds here after which also unchanged values will be re-logged into the DB" `
… und genau das verstehe ich eben so, dass es auch einen neuen (gleichen) Wert geben muss, bevor dieser geloggt werden kann.Gruß
Rainer
-
Jetzt History Version 1.6.6 (von github) unter Win 7 getestet: Die Option "Gleiche Werte aufzeichnen" funktioniert wie erwartet. Es stimmen jetzt auch die Zeitstempel und der Zeitabstand in der History-Tabelle.
Die Einträge unter dem Wert null stammen von History 1.6.1. -
Vielen Dank an @paul53 - mit der history 1.6.6. aus GitHub geht es jetzt auch miz der frisch installierten neusten ioBroker-Version - und es wird auch alle 5 min geloggt.
Vielen Dank an @Homoran für die "Wie installiere ich aus Git-Hub" Erklärung in einem anderen Thread - mittlerweile muss man in dem Fenster nur noch den Adapter auswählen - und bis ich diesen Kreis als "Koffer" erkannt hatte ….
Beobachten muss ich noch ob, außer zu Beginn, weitere "null" Werte auftauchen:
Ansonsten scheint es zu laufen:
die Lücke am Anfang durch den null-Wert in der history
Dank an @ruhr70 für seine Java-Scripte zum Hardware auslesen, deshalb hab ich jetzt auch eines für die Temperatur gebastelt.
-
Nun ist das Problem der neuen History 1.6.6, dass sie dieses null rein schreibt, dass zu Lücken im Grafen in VIS führt:
History-Tabelle mit null-Einträgen - VIS mit Linien - VIS mit Splines
Ich habe da zwischenzeitlich gebastelt, iobroker gestoppt, restartet, etc …
Man kann nun den Graph als Spline darstellen lassen - aber: a) experimentell und b) braucht Rechenleistung.
Besser wäre es, wenn die "null" - Elemente nicht in die history geschrieben würden …
-
Jetzt sind wir bei dem dritten Punkt aus deinem Ausgangsthread - der Umgang mit null-Werten
Dazu gibt es in flot bei den Datenpunkten unter dem Zahnrad
@[url=http://www.iobroker.net/docu/?page_id=198⟨=de#Datenpunktparameter:Doku"]NULL als: Hier wird festgelegt wie die Linie gezeichnet werden soll, wenn keine Daten vorliegen.default: keine Linie;
null-Werte ignorieren: Linie wird horizontal weitergeführt
0 statt null benutzen: die Linie wird auf den Wert 0 gezogen. `
Gruß
Rainer
-
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.
