History 2.0.0 verfügbar - eine Zusammenfassung

[Marty56]

@paul53

Danke für den Hinweis.
Ich habe den Source Analytics Adapter ausprobiert.

Er passt für mich nicht. Unterstützt keine Zählerwechsel weil keine negativen Jahres/Monatszähler. Mit Workaround könnte da was machen.
Ich wüsste auch nicht, wie ich meine 12 jährigen historischen Daten einpflegen könnte.
Abgeleitete Zähler wie Eigenverbrauch und Gesamtverbrauch funktionieren auch nicht.
Ein Flot Diagram mit History DB geht auch nicht direkt, sondern nur per Script und speziellen Diagramm Datenpunkten, die man sich aus den Daten des Source Analytics Adapter per Script generieren müsste und dann per send(history.... einpflegen müsste.

Das wäre deutlich komplizierter als das kleine Skript, was ich jetzt habe und das bis auf das History Issue gut funktioniert.

[apollon77]

Hallo alle zusammen,

mit dem Feedback hier und auf GitHub und noch ein paar Sentry Fehlermeldungen, gibts jetzt hier die 2.1.0 mit noch ein paar Neuerungen:

Die wichtigste Neuerung ist das storeState und auch GetHistory jetzt auch für "unbekannte Objects-IDs" geht. Es fehlen natürlich sämtliche Filteroptionen und alles was man pro Datenpunkt einstellen kann, aber das sollte klar sein

• (Apollon77) Fix several crash cases reported by Sentry
• (Apollon77) Make sure disabling "Log changes only" also really do not log the changes anymore
• (Apollon77) Allow storeState and GetHistory also to be called for "unknown ids"

Das Update sollte im Laufe des Abends im latest Repo aufauchen,

Viel Spass damit.

Ingo

[apollon77]

Und damit es nicht ganz langweilig wird hier noch ein kleines Update auf die 2.1.3 ... Ich habe nochmal in so einige Performancethemen vor allem bei GetHistory reingeschau und optimiert.

Wenn alles klappt geht das dann demnächst auch in Stable.

[afuerhoff]

@apollon77
Hallo, ich habe da mal eine Frage zu den zusätzlichen Werten.

Ich logge einen Boolean Wert und möchte mit einem Script immer den aktuellen Tag auslesen.
Aggregat Funktion = onchange

Hier mal ein paar Beispiel Werte aus dem Script (inklusive den beiden Randwerten):

10:53:03.221	info	javascript.0 (1622) script.js.Haus.Skript_2: history: Sun Jun 19 2022 00:00:00 GMT+0200 (Central European Summer Time)false
10:53:03.221	info	javascript.0 (1622) script.js.Haus.Skript_2: history: Sun Jun 19 2022 10:51:11 GMT+0200 (Central European Summer Time)false
10:53:03.221	info	javascript.0 (1622) script.js.Haus.Skript_2: history: Sun Jun 19 2022 10:52:22 GMT+0200 (Central European Summer Time)true
10:53:03.221	info	javascript.0 (1622) script.js.Haus.Skript_2: history: Sun Jun 19 2022 10:53:03 GMT+0200 (Central European Summer Time)true

Im Historydiagramm des Adapters sieht es so aus.

Der Boolean Wert war seit Mitternacht auf TRUE und hat dann um 10:51 nach FALSE und wieder nach TRUE gewechselt.
Jetzt würde ich erwarten, das der erste zus. Wert ebenfalls auf TRUE ist. Gelesen wird aber mit dem Script FALSE. Der letzte Wert passt.
Falls kein Wert für den Tag in der History gelogged wurde, gibt es auch keine zus. Werte. Da würde ich erwarten, das es ebenfalls zwei zus. Werte gibt.

Habe ich da einen Denkfehler?

[apollon77]

@afuerhoff Da müsste man jetzt exakt auch Deine Einstellungen kennen. Am allereinfachsten aktiviere doch mal das zusätzliche Debug für den relevanten Datenpunkt und liess Dir durch was er loggt bzw poste es hier. Da steht quasi exakt drin warum ein Wert geloggt wird oder verspätet geloggt wird oder verworfen wird.

[afuerhoff]

@apollon77
Die zusätzlichen Werte werden doch vom History Adapter ermittelt. Die werden doch dann nicht gelogged.

[apollon77]

@afuerhoff zusätzliche Werte sind anmelde nur werte Wonder adapter entscheidet sie nicht jetzt zu loggen aber ggf später. Und das sieht man im log.

[apollon77]

Hey all,

von History gibts jetzt die 2.1.6 mit letzten Fixes. Wenn keiner mehr was meldet wäre das die Version die die Tage in Stable geht.

Bitte checkt es nochmal

Ingo

[afuerhoff]

@apollon77
Ich habe jetzt nochmal einen Test gemacht. Betrachtungszeitraum "dieser Tag".
Der Datenpunkt war von gestern 22:15 bis heute 19:36 false. Erst um 19:36 wurde er auf true gesetzt. Wie man im Bild sehen kann.

In der Grafik wird der Datenpunkt aber als true dargestellt. Das ist falsch.

Wählt man einen größeren Zeitbereich, wo der Wechsel um 22:15 nach false enthalten ist wird es richtig dargestellt.

History Einstellungen sind folgende:

Aus meiner Sicht wird nicht der richtige History Wert zur Darstellung herangezogen.

[paul53]

@afuerhoff sagte: Betrachtungszeitraum "dieser Tag".

Dann holt sich das Chart-Programm auch nur diesen Zeitraum aus der History, das den alten Wert nicht enthält. Wenn Änderungen seltener sind als der zu betrachtende Zeitraum, muss man zusätzliche Einträge erzeugen lassen mit "trotzdem gleiche Werte aufzeichnen": 43200 (12 h).

[afuerhoff]

@paul53
Wofür gibt es dann diese Funktionalität "AUFZEICHNUNG ZUSÄTZLICHER WERTE ZUR BESSEREN GRAFISCHEN DARSTELLUNG" ?

Der History Adapter müsste für die Darstellung ja nur in die Vergangenheit schauen und den letzten Wechsel suchen und in der Darstellung berücksichtigen. Das gleiche wäre auch beim auslesen per Script sinnvoll wenn zusätzliche Werte mit ausgegeben sollen.

[paul53]

@afuerhoff sagte: "AUFZEICHNUNG ZUSÄTZLICHER WERTE ZUR BESSEREN GRAFISCHEN DARSTELLUNG" ?

Wo gibt es das? Ist das neu?

[apollon77]

@afuerhoff So funktioniert diese Funktion nicht. Diese Loggt zusätzliche Daten nwenn es sinn macht - hat mit der Darstellung an sich nichts zu tun. Normalerweise wird auch für Admin immer noch ein Wert an den "Rändern" gelesen, aber am Ende ist es immer eine Frage wie weit so ein Wert "weg" ist ...

Aber Paul hat recht - die einzig sinnvolle Variante um "immer" eine sinncolle grafische darstellung zu bekommen ist Werte öfters zu loggen

[apollon77]

@paul53 Siehe ganz obe - das "neue" ist aber das man das Loggen dieser zusätzlichen Werte deaktivieren kann (war bisher immer schon da, nur halt Defaultmäßig). Jetzt kann man sagen "Ich will nur die echten/Raw Werte haben"

[afuerhoff]

@apollon77
Das loggen zusätzlicher Werte wollte ich gerade vermeiden.

Die Frage ist, kann man nicht grundsätzlich bei Boolean Werten davon ausgehen, dass ein Wert, der im Betrachtungszeitraum z.B. irgendwann auf true gewechselt hat, außerhalb des Betrachtungszeitraum dann false gewesen sein muss. also findet ein Wechsel von false nach true statt und nicht von true nach true. Es wird ja generell durch die jetzige Darstellung etwas falsches dargestellt.

[apollon77]

@afuerhoff Das ist aber wen ein Admin Thema und keins vom Adapter! ich weiss gerade nicht wie Admin genau Abfragt und was es dann wie darstellt. Müsste man exakt mit Debug Log und so reinschauen. Bitte ggf Admin Issue erstellen

[afuerhoff]

@apollon77
Das verstehe ich gerade nicht. Der History Adapter müsste doch die richtigen Werte für die Darstellung im Admin liefern. Admin stellt doch nur dar. Müsste ja auch beim Auslesen mit einem Script mit den "Zusatzwerten" richtig vom History Adapter zurückgegeben werden.

[apollon77]

@afuerhoff Naja dann müssten wir erstmal schauen was Admin genau abfragt ... und dann kann man dazu was sagen. Also dann schauen wir mal rein:
1.) Den ausgewählten Datenpunkt in den Settings das enhanced Logging einschalten
2.) History Instanz auf Debug Loglevel setzen
3.) Log posten und sagen welche Datenpunkt es war
4.) Dann nehmen wir die Abfrage die Admin gesendet hat und du sendest Sie als Skript und wir sehen welche Daten zurückkommen

[afuerhoff]

@apollon77
Hallo, hier mal das Log. Gefiltert nach dem Datenpunkt. Passt das so oder benötigst Du etwas anderes?

2022-07-02 00:10:57.242 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134570680.4469083272847678 after getFileData: cacheData.length = 1, fileData.length = 1
2022-07-02 00:10:57.243 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134570680.4469083272847678 pre-cut data to 1 oldest values
2022-07-02 00:10:57.243 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134570680.4469083272847678 Beautify: 1 results
2022-07-02 00:10:57.243 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134570680.4469083272847678 after beautify: options.result.length = 1
2022-07-02 00:10:57.243 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134570680.4469083272847678 Send: 1 values in: 175ms
2022-07-02 00:10:57.764 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134577640.9211639891185686 getHistory message: {"id":"fb-checkpresence.0.familyMembers.Achim.presence","options":{"instance":"history.0","start":1656712800000,"end":1656713460000,"from":false,"ack":false,"q":false,"addID":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}}
2022-07-02 00:10:57.764 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134577640.9211639891185686 getHistory options final: {"id":"fb-checkpresence.0.familyMembers.Achim.presence","path":"/opt/iobroker/history/","start":1656712800000,"end":1656713460000,"step":null,"count":2000,"from":false,"ack":false,"q":false,"ignoreNull":false,"aggregate":"none","limit":2000,"addId":false,"returnNewestEntries":true,"percentile":null,"quantile":null,"integralUnit":null,"integralInterpolation":null,"removeBorderValues":false,"logId":"fb-checkpresence.0.familyMembers.Achim.presence16567134577640.9211639891185686","round":null,"debugLog":true}
2022-07-02 00:10:57.764 - debug: history.0 (31885) getOneCachedData: got 1 datapoints for fb-checkpresence.0.familyMembers.Achim.presence
2022-07-02 00:10:57.764 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134577640.9211639891185686 after getCachedData: length = 1, isFull=false
2022-07-02 00:10:57.782 - debug: history.0 (31885) getOneFileData: 20220702 -> 20220702 for fb-checkpresence.0.familyMembers.Achim.presence
2022-07-02 00:10:57.782 - debug: history.0 (31885) handleFileData: 20220702 -> /opt/iobroker/history/20220702/history.fb-checkpresence.0.familyMembers.Achim.presence.json
2022-07-02 00:10:57.783 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134577640.9211639891185686 after getFileData: cacheData.length = 1, fileData.length = 0
2022-07-02 00:10:57.783 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134577640.9211639891185686 Beautify: 1 results
2022-07-02 00:10:57.783 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134577640.9211639891185686 after beautify: options.result.length = 1
2022-07-02 00:10:57.783 - debug: history.0 (31885) fb-checkpresence.0.familyMembers.Achim.presence16567134577640.9211639891185686 Send: 1 values in: 19ms

[apollon77]

@afuerhoff SO und damit hast Du mit

{"id":"fb-checkpresence.0.familyMembers.Achim.presence","options":{"instance":"history.0","start":1656712800000,"end":1656713460000,"from":false,"ack":false,"q":false,"addID":false,"aggregate":"none","returnNewestEntries":true,"user":"system.user.admin"}}

den gehHistory call ... Das jetzt mal in nem Javascript Skript mit "sendTo" zum history.0 instanz senden. Und dann Zeig mal das Ergebnis - dann weisst Du was zurückkommt