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

[apollon77]

Aktuelle Test Version	2.0.0
Veröffentlichungsdatum	14.04.2022
Github Link	https://github.com/ioBroker/ioBroker.history

Hallo lieber Tester,

ich habe mit in den letzten Tagen mal die Zeit genommen und so ein paar Themen bei den History-Adaptern anzuschauen und in dem Zuge habe ich jetzt ein seeeehr großes Update für History zum testen für Euch. Wenn das soweit passt wird das "gleiche" auch für sql und InfluxDB noch kommen.

Diese neue (Major!) Version des History Adapters räumt einige Dinge auf und sorgt bei einigen Themen für mehr transparent und Klarheit und bringt noch dazu einige Features mit. Der Adapter wird sich an einigen Stellen was die aufgezeichneten Daten angeht künftig anders verhalten als bisher!
Ebenso haben sich Einstellungen geändert - es sollten die Einstellungen der alten Version übernommen werden und sollten auch bei einem Downgrade noch vorhanden sein wie vorher eingestellt, dennoch ist diese Version ein Breaking change. Also stellt bitte sicher Backups der Datenfiles und des Systems zu haben!

Da dies jetzt einiges an Änderungen ist starten wir erst einmal mit einem Alpha Test von GitHub. Bitte als im Admin den Expertenmodus aktivieren und vom GitHub installieren.

Bei Fehlern bitte ggf hier schreiben und dann GitHub Issues anlegen.

Auf die wichtigsten Änderungen will ich gern jetzt noch genauer eingehen.

Wichtige Änderungen erklärt

Konfiguration ausschliesslich in der neuen Admin UI verfügbar!

Die Konfiguration ist ausschliesslich in der neuen Admin5 UI verfügbar

Debounce vs "Aufzeichnung zeitlich blockieren"

In der Konfiguration kann man eine sog. "Debounce-Zeit" angeben. Debounce bedeutet an sich, dass ein neuer Wert erst dann als "stabil" gilt wenn er sich für die angegebene Zeit nicht geändert hat. So war es auch (von komischen Effekten mit "Nur Änderungen aufzeichnen mal abgesehen", dazu später mehr) implementiert. Leider hat die Readme davon gesprochen das der Wert sofort geloggt wird aber dann für die angegebene Zeit kein weiterer Wert. Hier herrschte also Verwirrung.

Mit dieser Version gibt es jetzt zwei Werte die man setzen kann:

• Debounce-Zeit: Der Wert wird wirklich erst aufgezeichnet, wenn er sich für die hier angegebene Zeit nicht geändert hat! Wird hier also ein Wert eingetragen der höher ist als die übliche Änderungsfrequenz des States, dann wird faktisch NIE etwas geloggt! Also Achtung hier!
• Block-Zeit: Dieser Wert entspricht dem was die Doku bisher zum "Debounce" gesagt hat und erlaubt es, erst frühestens nach Ablauf dieser Zeit neue Werte zu loggen. Wichtig hier ist das die obige "Debounce-Zeit" vorher geprüft wird, und auch das ein "Gleiche Werte nochmals loggen" diesen Check nicht macht.

Aus Kompatibilitätsgründen wird der frühere "debounce"-Wert als "Block-Wert" übernommen. Also bitte die Einstellungen prüfen falls dies keinen Sinn macht!

"Nur Änderungen aufzeichnen" vs "Debounce"

In dieser Kombination hatten sich einige Bugs und Effekte eingeschlichen, welche dafür gesorgt haben das teilweise Werte geloggt wurden die nicht den Regeln entsprachen. Dies ist jetzt aufgeräumt.

"Nur Änderungen aufzeichnen" und Aufzeichnung zusätzlicher Werte zur besseren Grafischen Darstellung

Ein weiterer großer Verwirrungspunkt war öfters, warum denn noch zusätzliche Werte aufgezeichnet werden, die an sich durch die Regeln (vor allem "Minimale Differenz") gar nicht hätten aufgezeichnet werden dürfen. Dies kam daher, dass der Adapter versucht die Werte so aufzuzeichnen das eine Grafische Darstellung sinnvoll möglich ist, weil in vielen Fällen die Werte nur zur grafischen Darstellung genutzt werden. Vor allem dabei ist es aber ein potentiell größerer Unterschied ob ein Wert der sich mit 1h Abstand geändert hat sich zu einem Zeitpunkt schlagartig geändert hat oder über die gesamte Zeit langsam geändert hat. Die automatisch gewählten zusätzlichen Werte stellen hier eine bessere Darstellung sicher.

Die neue Version nutzt diese darstellungsoptimierte Aufzeichnung immer noch standardmäßig, kann allerdings pro Datenpunkt deaktiviert werden! Dann werden nur wirklich die Werte aufgezeichnet die laut den angegebenen Regeln definiert waren.

Neue Features

Zusätzlich zu den oben genannten Änderungen gibt es einige neue Features in der neuen Version:

• Mittels zwei neuer Einstellungen pro Datenpunkt ("Nicht loggen wenn kleiner als" und "Nicht loggen wenn größer als") können noch besser Fehlerwerte ausgeklammert werden. Die Einstellung "Nicht loggen wenn kleiner als" ersetzt das vor kurzem hinzugefügte "Keine Werte kleiner als 0 loggen", die Einstellung wird aber automatisch konvertiert.
• Eine Einstellung pro Datenpunkt ist dazugekommen, mit der man angeben kann auf wie viele Stellen nach dem Komma die Werte beim lesen (GetHistory) gerundet werden.
• Neue Aggregationsmethoden "percentile" und "quartile" wurden hinzugefügt, um das n-te Percentile bzw. das 0.x Quartile zu ermitteln. Ohne weitere Infos wird das 50er Percentile bzw. das 0.5er Quartile (Mean) zurückgegeben, was ein besserer Average ist.
• Neue Aggregationsmethode "integral" wurde hinzugefügt, um das Integral (Fläche unter den Werten) zu errechnen. Im Standard ist die Integral-Unit 1s und eine schrittweise Interpolation wird genutzt (also quasi keine, weil die werte für die ganze Zeit konstant berechnet werden). Alternativ kann eine lineare Interpolation genutzt werden. Mit einem Integral und zB Unit von 3600s kann man aus einem Stromverbrauch in Watt die Wh ermitteln,
• Standardmäßig ermitteln die Aggregationsmethoden immer auch zwei Randwerte und geben diese im Ergebnis zurück um die grafische Darstellung zu optimieren. Mittels der neuen Option "removeBorderValues" bei einem GetHistory Aufruf können die zurückgegebenen Werte so limitiert werden wie Sie per step bzw. count angefordert wurden und diese Randwerte entfernt werden. Dies ist vor allem Hilfreich wenn ein Skript die Daten verarbeiten soll. Mit dem (kommenden!) Admin 5.3.8 ist auch die Darstellung der Werte bei den Datenpunkt-Einstellungen wieder korrekt, wenn man Zeitbereiche von mehr als 24 gewählt hat und mehr als 500 Werte in dem Zeitraum geloggt wurden.
• Da das schreiben von Debug Logs vor allem bei schwächeren Systemen ziemlich auf die performance drückt und auch ein Debug Log immer sehr unübersichtlich wurde, weil alles oder nichts geloggt wurde, kann nun zusätzliches Debug pro Datenpunkt aktiviert werden! Dies wird aber nur dann ausgegeben wenn der Loglevel der Instanz auch auch Debug steht.
• Bei storeState kann nun mittels dem Parameter "rule=true" festlegen das die Daten nicht direkt geloggt werden sondern alle Rules angewendet werden wie für jeden normalen Wert - inkl. Debounce u.ä. Bitte vorsichtig nutzen das nicht unabsichtlich Werte nicht geschrieben werden!
• Die Aufbewahrungszeit kann nun neben vorgegebenen Optionen auch als eigene Dauer in Tagen angegeben werden

Die neuen Aggregationsmethoden sind (natürlich) noch nicht in flot oder echarts verfügbar und können daher nur in Skripten genutzt werden. Hierzu müssten, wenn alles geht dann noch Issues an den relevanten Stellen angelegt werden.

Die neuen Optionen für getHistory sind in https://github.com/ioBroker/ioBroker.history/blob/master/docs/en/README.md#access-values-from-javascript-adapter auch alle erklärt

Weitere Änderungen

Weiterhin gibt es folgende relevante Änderungen im Verhalten

• GetHistory-Anfragen müssen nun bei start/end Angaben in ms erfolgen! Zeitangaben in Sekunden werden nicht mehr umgerechnet! Bitte sicherstellen das alle UIs und Charting-Adapter aktuell sind!
• Die Objekt-ID wird nun immer wenn angefordert mit in den Ergebnissen von GetHistory zurückgegeben
• Spezielle Behandlung von früher aufgezeichneten Daten mit Timestamps in Sekunden bzw. Logiken die verhindert haben Werte vor 1.1.2010 zu verarbeiten wurden entfernt.

Neue Aufzeichnungslogik erklärt

Am Ende gilt jetzt folgende Reihenfolge der Checks:

• Ein Wert ist erst nach Debounce-zeit stabil. Unstabile werte werden nicht aufgezeichnet
• Wenn die Blockzeit seit dem zuletzt regulär aufgezeichneten Wert nicht erreicht ist, wird der Wert nicht aufgezeichnet
• Wenn "Null-Werte" ignoriert werden und der Wert 0 ist, dann wird der Wert nicht aufgezeichnet
• Wenn Grenzen der Werte definiert sind (Nicht loggen wenn kleiner/größer als) und der Wert ist ausserhalb der Grenzen, wird der Wert nicht aufgezeichnet
• Wenn "Nur Änderungen aufzeichnen" definiert ist:
  • Wenn der Wert seit letzter Aufzeichnung unverändert war und "gleichen Wert aufzeichnen" deaktiviert ist, wird der Wert nicht aufgezeichnet. Der Wert wird ggf. erinnert für spätere Aufzeichnung zur Darstellungsoptimierung.
  • Wenn der Wert seit letzter Aufzeichnung unverändert war und "gleichen Wert aufzeichnen" aktiviert ist und das angegebene "Nochmals Aufzeichnen Interval" noch nicht erreicht ist, wird der Wert nicht aufgezeichnet. Der Wert wird ggf. erinnert für spätere Aufzeichnung zur Darstellungsoptimierung.
• Wenn der Wert eine Zahl ist und eine "Minimale Differenz" definiert ist, diese aber nicht erreicht ist, wird der Wert nicht aufgezeichnet. Der Wert wird ggf. erinnert für spätere Aufzeichnung zur Darstellungsoptimierung.

Der zuletzt erinnerte Wert wird geschrieben sobald auch der nächste reguläre Wert geschrieben wird, allerdings mit seinem alten Zeitstempel - und nur wenn die Darstellungsoptimierung nicht deaktiviert wurde..

Vielen Spass beim testen und vielen Dank für Euer Feedback und Eure Erfahrungen,

Ingo

[sigi234]

@apollon77

Test:

Installation ok mit Code 0
Keine Fehlermeldungen und Log Ok.

Werde weiter testen. Windows System

[Feuersturm]

@apollon77 Dann starten wir mal mit dem testen Danke für deine Arbeiten schon einmal Vorab.

Erstes Feedback: Vereinheitlichung der Konfiguration von der history Instanz und vom Datenpunkt
In den Einstellungen der History Instanz können ja Defaultwerte vorgegeben werden. Ich finde es intuitiver, wenn dieser Konfigurationsblock auch beim Datenpunkt dann genau so wieder auftaucht. Daraunter kann dann der Bereich kommen, wo es um Einstellungen speziell für den einen Datenpunkt gibt.
Aufgefallen ist es mir, weil z.b. die Konfiguration "Schreibe NULL-Werte an Start-/Stop-Grenzen" nur bei den Einstellungen in der Instanz aber nicht beim Datenpunkt vorhanden ist.

[apollon77]

@feuersturm an sich sollten alle die bei den instanzeinstellungen unter „defaulteinstellungen“ sind die default Werte sein. Vllt ist da was durchgerutscht was da nicht hingehört. Checke ich nachher nochmal. Danke

[apollon77]

@feuersturm habe alles gecheckt. Auf GitHub ist nun "write Nulls" auf den Main Settings Tab gewandert. Der hatte sich wohl verirrt

[Feuersturm]

@apollon77 sagte in Test Adapter History 2.0.0:

@feuersturm habe alles gecheckt. Auf GitHub ist nun "write Nulls" auf den Main Settings Tab gewandert. Der hatte sich wohl verirrt

Top.
Dafür hat sich jetzt diese Checkbox etwas verlaufen

Beim Loggen von einem Datenpunkt und etwas spielen mit dem Minimum Werte und der Blockzeit sind bisher noch keine Probleme aufgefallen.

[apollon77]

@feuersturm Auf GitHub hab ichs eingefangen. tssstss diese Checkboxen immer

[Feuersturm]

@apollon77 sagte in Test Adapter History 2.0.0:

@feuersturm Auf GitHub hab ichs eingefangen. tssstss diese Checkboxen immer

Jetzt ist sie da wo sie hingehört

[Thomas Braun]

@apollon77

Hab jetzt auch mal die Alpha installiert.

iobroker.history@2.0.0 (git+ssh://git@github.com/ioBroker/ioBroker.history.git#9fcc35069de7b11cbf1d6a134d648940e64a15e8)

Da ich aber nur zwei Datenpunkte (für echarts) logge ist mein Setup überhaupt kein Maßstab. Aber es funktioniert noch alles. Ist ja vielleicht auch eine Info.

[Feuersturm]

@apollon77
Aufbewahrungsdauer
Ich hab bei meinem Testdatenpunkt einmal eine Aufbewahrungsdauer von 1 Tag eingestellt

Obwohl die 24h schon überschritten sind tauchen die ersten Datenpunkte von gesternabend 18:55 noch in den Verlaufsdaten auf:

Datumseinstellung ioBroker Slave wo history Adapter läuft

proxmox@ioBrokerNew:~$ date
Fri Apr 15 19:39:43 CEST 2022

Datumseinstellung ioBroer Master:

proxmox@ioBrokerTestsystem:~$ date
Fri Apr 15 19:45:15 CEST 2022

[apollon77]

@feuersturm aufgeräumt wird immer dann wenn auch was neues ins file geschrieben wird. Ergo: wie lange braucht er bis er 960 Einträge gesammelt hat und schreibt? ;-)) alternativ mal Adapter testen dann wird auch geschrieben und er sollte auch aufräumen. Und dann räumt er glaube tageweise auf.

Am Ende hab ich daran nichts geändert aber ja wenn was wäre fixen wir das natürlich

[apollon77]

@feuersturm also check für aufräumen erfolgt frühestens alle 6h, dann wird aufgeräumt nur ganze tage ab dem tag "vor" ablauf der retention
generell gilt: speichern alle 10 mins ODER wenn die anzahl erreicht ist

[Feuersturm]

@apollon77 Dann warte ich nochmal etwas ab.

Hab gerade einmal mit diesem kleinen Codeschnipsel etwas mit min, max, average, percentile, quantile herumgespielt und auf dem ersten Blick kamen da plausible Werte raus

var end = Date.now();
sendTo('history.1', 'getHistory', {
    id: 'proxmox.0.lxc_ioBrokerTestsystem.cpu',
    options: {
        start:      end - 3600000,
        end:        end,
        count: 1,
        aggregate: 'percentile',
        addId: true,
        percentile: 50
    }
}, function (result) {
    console.log(JSON.stringify(result))
    console.log(result.result[0].val);

});

[SBorg]

Good job, läuft auf Anhieb
Von meinen rund 30 Einträgen liefen sofort fast alle. Die die nicht wollten musste ich neu speichern, danach ging es. Leider bin ich eben erst auf die Idee gekommen ob es nicht auch einfach ein iob restart (oder nochmaliger Adapterrestart) getan hätte?

[apollon77]

@sborg hatten die „die nicht wollten“ denn was besonderes? Wurden sie beim start mit aufgelistet? An sich wäre überraschend wenn einer „nicht will“ der vorher tat es sei denn es sind relevante settings Jetzt beachtet - dann hätten sie aber nach nur neu speichern sich nicht tun sollen. Strange und ohne Infos schwierig zu beantworten

[SBorg]

@apollon77 Angelegt wurden sie, aber immer mit Wert "0" geschrieben.
Keine ganz speziellen Eigenschaften, aber trotzdem habe ich eine Gemeinsamkeit gefunden (siehe Pixelmatsch):

Alle nutzen einen Alias

[apollon77]

@sborg sehr interessant. Kannst du bitte mal checken ob es nach einem restart vom Adapter wieder so ist? Und wenn bitte debug log vom Adapter und bei so einem relevanten state aktiviere und dann mal log senden vom Start und von wenn du es dann speicherst.

Ich versuche es nachher auch mal nachzustellen

[SBorg]

@apollon77 sagte in Test Adapter History 2.0.0:

Kannst du bitte mal checken ob es nach einem restart vom Adapter wieder so ist?

Ja und Nein. Einmal gespeichert überlebt es auch einen Adapterneustart:

• gestern 14:00 Uhr Update (+ vergessen zu kontrollieren, da anderes wichtigeres da zumindest lief )
• heute ~ 07:30 Uhr den Peak (warum auch nur einer?) verstehe ich nicht so ganz...
• kurz vor 10:00 Uhr die Fehler bemerkt und testweise mal an einem gespielt (dann 15 Minuten bis zum nächsten Update warten; wie üblich dabei "gestört" worden und vergessen...)
• 11:00 Uhr Yeah, geht und die restlichen 4 neu gespeichert...
• ab > 15:00 Uhr nichts mehr ersichtlich und funktioniert trotz erfolgtem Adapterrestart

Die restlichen 20 (habe in Summe doch nur 25 ) laufen bis dato anstandslos (selbe Einstellungen, nur halt alle ohne Alias)

[apollon77]

@sborg aber waren alle mit nem alias betroffen korrekt? Oder auch nur einige?

[SBorg]

@apollon77 Alle 5 "defekten" nutzen einen Alias. Hier geht es wie man unschwer erkennen kann um Benzinpreise. Da der Tankerkönig dann die Stationen nur durchnummeriert ist es nicht gerade sehr intuitiv und ich nutze dort die Aliase. Bei den restlichen nehme ich dann die Standardnotation des DPs.

Den einzelnen Peak verstehe ich dabei überhaupt nicht...

Hier mal der passende JSON:

Spoiler

[
 {
   "val": 0,
   "ack": true,
   "ts": 1650081015052,
   "q": 0,
   "from": "system.adapter.tankerkoenig.0",
   "user": "system.user.admin",
   "lc": 1650053174973
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650081722077,
   "q": 0,
   "user": "system.user.admin",
   "from": "system.adapter.history.0"
 },
 {
   "val": null,
   "ts": 1650081722078,
   "lc": 1650081722078,
   "q": 64,
   "from": "system.adapter.history.0"
 },
 {
   "val": null,
   "ts": 1650081751008,
   "ack": 1,
   "q": 64
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650081976296,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650085816292,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 2.129,
   "ack": 1,
   "ts": 1650085816295,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650086776277,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650087736269,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650088696281,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650089656281,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650090616274,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650091576277,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650092536283,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 0,
   "ack": 1,
   "ts": 1650093496298,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.989,
   "ack": 1,
   "ts": 1650094456295,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 2.039,
   "ack": 1,
   "ts": 1650095416305,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.989,
   "ack": 1,
   "ts": 1650096376288,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.989,
   "ack": 1,
   "ts": 1650098296310,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.979,
   "ack": 1,
   "ts": 1650099256305,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.979,
   "ack": 1,
   "ts": 1650101176306,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.969,
   "ack": 1,
   "ts": 1650102136301,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.969,
   "ack": 1,
   "ts": 1650103096315,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.959,
   "ack": 1,
   "ts": 1650104056345,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.959,
   "ack": 1,
   "ts": 1650105016328,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.999,
   "ack": 1,
   "ts": 1650105976352,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.999,
   "ack": 1,
   "ts": 1650106936321,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.959,
   "ack": 1,
   "ts": 1650107896372,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.959,
   "ack": true,
   "ts": 1650112696363,
   "q": 0,
   "from": "system.adapter.tankerkoenig.0",
   "user": "system.user.admin",
   "lc": 1650107896372
 },
 {
   "val": 1.959,
   "ack": 1,
   "ts": 1650113463498,
   "q": 0,
   "user": "system.user.admin",
   "from": "system.adapter.history.0"
 },
 {
   "val": null,
   "ts": 1650113463499,
   "lc": 1650113463499,
   "q": 64,
   "from": "system.adapter.history.0"
 },
 {
   "val": 1.959,
   "ack": 1,
   "ts": 1650113480027,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.959,
   "ack": 1,
   "ts": 1650116536346,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.999,
   "ack": 1,
   "ts": 1650117496345,
   "q": 0,
   "user": "system.user.admin"
 },
 {
   "val": 1.959,
   "ack": 1,
   "ts": 1650118456349,
   "q": 0,
   "user": "system.user.admin"
 }
]

wobei er da lt. Einstellungen "0" und "Null" eigentlich gar nicht hätte loggen dürfen?