UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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 :smiley:.
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.

[afuerhoff]

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

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

Was wäre dein Vorschlag? Ich wollte mir keine eigene History Funktionalität einbauen.

[paul53]

@afuerhoff sagte: Was wäre dein Vorschlag?

Ich kann erst etwas vorschlagen, wenn ich weiß, was Du vorhast.

[afuerhoff]

@paul53
siehe hier -> Adapter ist fb-checkpresence gemeint.
Da bin ich gerade am optimieren.

[paul53]

@afuerhoff sagte: Adapter ist fb-checkpresence

Den Adapter kenne ich nicht. Geht es hierum?

Objekt member.history, member.historyHtml
Hier finden Sie Informationen zur Historie des aktuellen Tages.

Die paar Werte kann man auch in einem Array-Datenpunkt speichern.

[afuerhoff]

@paul53

Nein, darum nicht. Ich bin allerdings ganz zufrieden mit dem History Adapter.
Nur die oben beschriebene spezielle Funktionalität würde mir das Leben einfacher machen.

Das eigene Array müsste auch nach Adapter Stopp noch verfügbar sein. Damit würde ich einen kleinen History Adapter nachbauen. Das möchte ich mir nicht antun. Außerdem kann der Anwender die History Werte auch zu anderen Zwecken noch nutzen.

Danke für deinen Vorschlag.

[paul53]

@afuerhoff sagte: die oben beschriebene spezielle Funktionalität würde mir das Leben einfacher machen.

Wenn die Werte aus der History vom Typ "boolean" sind und nur bei Änderung aufgezeichnet werden, weiß man, dass wenn der erste Eintrag true ist, der Wert vorher false gewesen sein muss (und umgekehrt). Diese Tatsache kann man im eigenen Adapter berücksichtigen. Die Chart-Adapter tun es allerdings nicht.