History 2.0.0 verfügbar - eine Zusammenfassung

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

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

[afuerhoff]

@paul53
Hab ich auch schon dran gedacht. Problem könnte nur sein, wenn der Anwender das Verhalten am Datenpunkt dass ich vorgebe verstellt hat, dann passt das auch nicht.

[paul53]

@afuerhoff sagte: wenn der Anwender das Verhalten am Datenpunkt dass ich vorgebe verstellt hat, dann passt das auch nicht.

Dann sollte man den Anwender deutlich darauf hinweisen, dass er dies zu unterlassen hat.

[afuerhoff]

@paul53
Die andere Vorgehensweise ist universeller bzgl. der History Einstellungen. Ich möchte die Anwender nicht einschränken.
Ich weiß, mir ist nicht zu helfen

[Frank579]

@apollon77 Bin schon länger auf der 2.1.4 äuft auch stabil wollte heute dann mal auf die 2.1.7 gehen . ca alle 15min Starte mein IOBroker danach neu. Habe mal den Auszug aus dem Log wenn er neustartet angefügt.
Admin version ist 5.4.9 / Node.js 16.15.1

2022-07-04 17:52:28.587 - info: history.0 (2043) enabled logging of Außentempeatur (Count=2), Alias=true
2022-07-04 18:06:03.587 - error: host.IOBroker uncaught exception: null must be RESP Buffer value
2022-07-04 18:06:03.588 - error: host.IOBroker TypeError: null must be RESP Buffer value
at Function.encodeArray (/opt/iobroker/node_modules/respjs/index.js:62:45)
at RedisHandler._sendExecResponse (/opt/iobroker/node_modules/@iobroker/db-base/lib/redisHandler.js:452:62)
at RedisHandler._handleMultiResponse (/opt/iobroker/node_modules/@iobroker/db-base/lib/redisHandler.js:472:18)
at RedisHandler.sendInteger (/opt/iobroker/node_modules/@iobroker/db-base/lib/redisHandler.js:326:22)
at RedisHandler. (/opt/iobroker/node_modules/@iobroker/db-objects-jsonl/lib/objects/objectsInMemServerRedis.js:734:33)
at RedisHandler.emit (node:events:527:28)
at RedisHandler.emit (node:domain:475:12)
at Immediate. (/opt/iobroker/node_modules/@iobroker/db-base/lib/redisHandler.js:145:37)
at processImmediate (node:internal/timers:466:21)
2022-07-04 18:06:03.599 - info: telegram.0 (1907) Got terminate signal TERMINATE_YOURSELF

Bin jetzt wieder auf die 2.1.4 und läuft wieder ....
Hast du oder wer anders eine Idee

[apollon77]

@frank579
Welcher js-controller ist das?

kannst Du es versuchen bitte nochmals zu reproduzieren? Wir kennen diesen Fehler aus Logs vom js-controller konnten Ihn aber noch nie nachvollziehen und auch in verbindung mit History mir bisher unbekannt. Falls es wieder passsiert bitte setze mal das Loglevel des Hosts (/opt/iobroker/iobroker-data/iobroker.json) auf "silly" und poste mal das log - aber am besten in nem anderen Thread weil für hier an sich off topic

EDIT Und bitte zeige mal was in

/opt/iobroker/node_modules/@iobroker/db-objects-jsonl/lib/objects/objectsInMemServerRedis.js in Zeile 734 steht

UND was in /opt/iobroker/node_modules/@iobroker/db-base/lib/redisHandler.js Zeile 326 steht

[Thomas Braun]

@frank579
Welche Version vom
js-controller
läuft?

Vielleicht mal 'alles' anschauen.

iobroker update -i
sudo ln -s /usr/bin/node /usr/bin/nodejs
uname -m && which nodejs node npm && nodejs -v && node -v && npm -v && whoami && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs