History 2.0.0 verfügbar - eine Zusammenfassung

[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

[afuerhoff]

@apollon77
ich bekomme genau einen History Eintrag zurück geliefert für den aktuellen Tag. Das ist der Zeitpunkt wo der Datenpunkt nach true gewechselt hat. Die Grafik sagt etwas ganz anderes aus.

2022-07-02 00:33:30.396 - info: javascript.0 (31943) script.js.Haus.Skript_3: history cntActualDay: 1
2022-07-02 00:33:30.397 - info: javascript.0 (31943) script.js.Haus.Skript_3: history: Sat Jul 02 2022 00:10:13 GMT+0200 (Central European Summer Time) value: true

[apollon77]

@afuerhoff naja mit exakt einem Datenpunkt kann ein charting jetzt zwei Dinge tun:

• annehmen das es davor true war und danach ists unbekannt (scheinbar ist das das was die admin charting lib tut)
• vorher unbekannt und true dann ab Zeitpunkt x bis Ende darstellen. Wenn vorher auch true war ist’s indirekt auch falsch. Aber ggf richtiger als oben

Und daher wie gesagt. Bitte ein Admin issue anlegen. Der Adapter kann nicht mehr Daten zurückgeben wenn in dem Zeitraum nicht mehr da ist. Wenn es am gleichen Tag noch vorher oder nachher was gegeben hätte wäre das mit dabei gewesen (ich meine: wenn du das jetzt ausführst dann könnten 3 werte zurückkommen) - er ließt aber nicht über tagesgrenzen hinaus zusätzliche Daten … die würden ggf nur komme wenn sie in den eh gelesenen Daten mit drin wären.

[afuerhoff]

@apollon77
Ich erstelle einen Issue im Admin.
Es wäre ja sehr einfach den Vorgänger Wert außerhalb des Betrachtungszeitraum zu ermitteln. Man müsste erstens die Anzahl der Werte im Betrachtungszeitraum ermitteln und dann die Anzahl erhöhen und erneut einlesen. Dann hätte man den Wert außerhalb des Betrachtungszeitraum, den man nutzen könnte. Hier müsste man natürlich noch Null Werte abfangen.

Es wäre aber schön, wenn der History Adapter dies schon so liefern könnte, dann hätte man auch den Benefit in Scripten und müsste das nicht selber programmieren. Dann wäre das auch für den Admin so verfügbar. So hatte ich eigentlich die zusätzlichen Werte verstanden. Denn was nützen diese, wenn sie nicht wirklich richtig sind. Der History Adapter hat ja alle Werte vorliegen. Das Verhalten kann dann über die Aggregat Funktion beeinflusst werden. Nur mal als Anregung.

[apollon77]

@afuerhoff naja wie bereits gesagt. Der History Adapter tut genau das … wenn es am gleichen Tag einen Vorgänger Bzw Nachfolger wert gab.

Was er nicht tut ist extra den Vortag auch noch komplett einzulesen nur um ggf den vorwert zu bekommen (und wenn da keiner ist den Vortag und den Vortag …….).

Die Alternative im bei charting besser zu sein ist genannt worden: auch unveränderte Werte regelmäßig zu loggen. So umgehst du das issue.

[afuerhoff]

@apollon77
Hallo, ich habe mal eine Frage zum Parameter "ignoreNull".
Wenn ignoreNull=true, count =10, end = die aktuelle Zeit und in den Historydaten in dem Bereich 2 Null werte enthalten sind, werden 8 Werte zurück geliefert. Ich hätte jetzt erwartet, dass es 10 sind. Mit ignoreNull=false würden ja 10 Werte zurück geliefert.

Ist das ein korrektes Verhalten oder ein Fehler?

[apollon77]

@afuerhoff Im aktuellen Code ist es korrekt ... ob es so sein sollte ist ne andere Frage ... leg gern mal ein Issue an, muss ich mal drüber meditieren

[afuerhoff]

@apollon77
Mach ich.

Würde das leben erleichtern, wenn man den aktuellen Tag abfragt und den letzten Wert davor ebenfalls abfragen möchte. Dann käme man mit zwei History Abfragen aus.
Die erste um den Count des aktuellen Tages zu bekommen und die zweite um den Count + 1 zu lesen.
Im aktuellen Zustand des Adapters müsste man auf Verdacht mehr als einen zusätzlichen Wert einlesen (aufgrund möglicher Null Werte) und dann noch schauen, ob ein gültiger Wert dabei ist.

[apollon77]

@afuerhoff Die Null werte werden erst beim Aggregieren aussortiert. Es werden also count Werte gelesen und dann darauf aussortiert. Was man faktisch ändern müsste ist mir schon klar ...

AM Ende kann der Adapter nur versuchen das sinnvollste aus den Daten zu machen. Wenn diu spezielle Anforderungen hast dann schreib die Abfrage so das es klappt und prozessiere die Daten ggf danach selbst nochmal Auch eine Option wenn es zu speziell wird.

ALso wegen deinen "Auch letzten Tag vom Vortag" zu nehmen ist einfach: setze Start nicht auf "Tag 0:0:0" sondern auf "Vortag 23:59:59" und du solltest noch einen Wert mehr bekommen (Wenn da einer war)

[afuerhoff]

@apollon77
Das ist genau das Problem. Ich weiß nicht, ob es einen Wert am Vortag gab. Daher möchte ich ja auch den count vom aktuellen Tag um eins erhöhen und dann erneut einlesen. Dann ist es egal, wann der Wert gesetzt wurde. Feature Request habe ich eingestellt.

Nach altem Verhalten kann man aber nicht davon ausgehen, dass dann auch ein korrekter Wert zurück geliefert wird, da es ja auch ein Null Wert sein könnte. Es ist dann wesentlich aufwändiger den letzten gültigen Wert zu ermitteln.

[apollon77]

@afuerhoff naja jetzt sind wir aber am Knackpunkt. Wieviel Magie soll der Adapter tun bei allem Millionen möglichen Fällen?

Du entscheidest sich nur sehr rar ändernde Werte zu loggen und erwartest das der Adapter immer weiss wann/ob ein Wert davor geloggt wurde um den auch zurückzugeben wenn ein Zeitraum A bis B abfgefragt wird. Das ist grenzwertig weil halt immer noch ein Datenfile mehr gelesen werden müsste ...

Wenn Du das willst kennst Du die empfohlene Lösung ("gleichen Wert zusätzlich loggen") in einem sinnvollen interval ... dann hast du in der Praxis das Problem nicht/selten.

Ja rest muss ich überlegen

[afuerhoff]

@apollon77

Ich weiß, dass es schon speziell ist was ich machen möchte .
Ich rechne darüber die Anwesenheit und Abwesenheit (Einheit Minuten) in meinem Adapter. Wenn ich jetzt jede Minute einen Wert loggen lassen würde, dann hätte ich keine Probleme allerdings viele unnütze Werte in der Datenbank. Ist das Intervall größer, dann habe ich einen Fehler in der Berechnung. Daher nützt mir das loggen gleicher Werte nichts.

[apollon77]

@afuerhoff sagte in History 2.0.0 verfügbar - eine Zusammenfassung:

allerdings viele unnütze Werte in der Datenbank

Das ist die krux beim "Data logging" ... zuviel vs zu wenig ... Ich persönlich bin bei "Finde den Sweet spot zwischen unnötig und für den Usecase/Anwendungsfall angemessen" Und Speicherplatz ist billig heutzutage

[paul53]

@afuerhoff sagte: Ich rechne darüber die Anwesenheit und Abwesenheit (Einheit Minuten)

Mittels History? Nach dem Motto: Weshalb einfach, wenn es auch kompliziert geht.