Adapter history.0 auswerten für 16 Datenpunkte und 12 Monate

[legendary83]

@paul53

Hier mal ein Flot aus dem Zeitraum.
Das Object ist die Grüne Anlage.

Da der Erfassungszeitraum auf 1 Jahr gestellt ist, ist der Zeitraum am Anfang wohl schon nicht mehr verfügbar.
Die Daten liegen also vor.
Und wie aus dem Diagramm hervorgeht, ist die Anlage schätzungsweise in dem Monat bei einer Betriebsdauer von sagen wir mal 40-45% gewesen.

Man sieht da auch sehr schön die Stillstände vom Wochenende

EDIT:
@paul53

Ich muss für heute leider mal einen Break einlegen.
DANKE schon mal für Deine Hilfe!
Wenn es um Skripte geht, da hab ich noch VIEL Nachholbedarf....

Wenn Du möchtest, können wir morgen wieder hier anknüpfen
Komm gut in die Waagrechte!

@david-g

Ich hab mal Dein Script von ganz zu anfangs getestet.
Auf den Monat angewandt der oben im Flot zu sehen ist (01.03.2024-31.03.2024)

Der Zähler gibt 1767 aus

Wenn ich das Script korrekt lese, wird jedes true gezählt das er in diesem Zeitraum vorfindet.
Wenn 1True = 10 Sekunden dann wären das 4,983 Betriebsstunden.

Bei angenommenen 40% Betriebszeit auf den Zeitraum müssten es ca. 107000 Trues sein.

EDIT:
@paul53

Ich denke ich habe es lösen können, ich werde das morgen noch mal verifizieren.
ich habe an der Anweisung gethistory die Aggregation auf Maximum gestellt.
Dann habe ich für heute 11,7 Betriebsstunden erhalten.
Dann habe ich mir den Flot von heute angesehen und es händisch rausnotiert(so genau es halt bei einem 24h flot geht), da kam ich auf 11 Stunden und 42 Minuten

11,7 Betriebsstunden sind 11 Stunden und 42 Minuten

Jetzt müsste man nur noch wissen, was gethistory mit Aggregation auf Maximum den genau bedeutet.

EDIT aus er Zukunft

Aggregation auf Maximum gibt einen zu hohen Wert aus.
Aggregation auf Minimum gibt einen zu niedrigen Wert aus.

Für den kleinen Zeitraum den ich betrachtet habe (24h) ist die Abweichung aber fast nicht vorhanden.

Beispiel:

Ich hatte die Monatswerte ermittelt.
Alle Werte summiert und sagen wir mal 4500h erhalten.
Lasse ich das Skript den ganzen Zeitraum betrachten, kommen über 6000h raus.

[David G.]

Ich habe das Blockly für mich modifiziert.
Ich nutze es, um zu schauen wie lange Fenster offen waren oder sind.

Um zu schauen wie lange sie offen SIND füge ich am Ende der Liste einen Eintrag hinzu, dass ich es schließe. So wird die Zeit auch korrekt berechnet, falls es noch nicht geschlossen wurde.

Leider finde ich keinen Ansatz es korrekt zu berechnen, falls das Fenster zum Zeitpunkt von Beginn der histoty Abfrage geöffnet war.
Mit fällt nur ein, einen noch größeren Zeitraum abzufragen um zu schauen ob vor dem ersten "false" im result ein "true" stand.

[legendary83]

@david-g

Auf Wertänderung, bzw. mit steigender und fallender Flanke zu arbeiten führt definitiv dazu das man Zeiträume ignoriert.

Ich bin den ganzen Vormittag dran gesessen jetzt.

Die Erkenntnis ist:

Je länger der betrachtete Zeitraum ist, umso größer ist die Abweichung vom tatsächlichen Wert.
Das ist genau das Gegenteil von dem was ich erwarten würde.
Das kann ich mir nur erklären, das gethistory im Hintergrund tatsächlich tageweise auswertet.

Ich habe einen Tag, da weicht Soll ist um 5 Stunden ab.
Der Tag hat mit 5 Minuten True begonnen - dazwischen mehrere Zustandswechsel - endet dann mit 4 Stunden 55 Minuten True.
Das sind relativ exakt die 5 Stunden die fehlen.

Ich müsste sozusagen den Zustand am Start und am Ende für je einen Indexeintrag False setzen, sodass er den Wechsel von False auf True erkennt um Zeit korrekt zu bestimmen.

[paul53]

@legendary83 sagte: Das kann ich mir nur erklären, das gethistory im Hintergrund tatsächlich tageweise auswertet.

Ich vermute eher, dass die Anzahl der eingelesenen Werte (Objekte) auf ca. 2000 begrenzt ist.
Welchen Grund gibt es, alle 10 s zu historisieren und das ein ganzes Jahr? Zu viel Massenspeicher vorhanden?

[legendary83]

@paul53

Ich wusste es schlicht damals nicht besser.

@legendary83 said in Adapter history.0 auswerten für 16 Datenpunkte und 12 Monate:

Die Erfassung in so kurzen Abständen war notwendig, da wir mehrere Hallenabschnitte weiter für die Maschinen Betriebsleuchten installiert haben.
Der Wechsel des Maschinenzustands sollte Verzögerungsfrei angezeigt werden.

[paul53]

@legendary83
Logge mal die Anzahl der Werte in result.

[paul53]

@legendary83 sagte: Aggregation auf Maximum gibt einen zu hohen Wert aus.
Aggregation auf Minimum gibt einen zu niedrigen Wert aus.

In Beispielen verwendet, aber nicht dokumentiert ist Aggregation auf "onchange". Blockly bietet es nicht - deshalb teste es mal als Javascript:

getHistory('history.0',
    {
        id:         'node-red.0.Halle5.Linie1.120er',
        start:      new Date('2024-10-01 00:00').getTime(),
        end:        new Date('2024-11-01 00:00').getTime(),
        aggregate:  'onchange'
    },
    (err, result) => {
        if (err) console.error(err);
        if (result) {
            for (let i = 0; i < result.length; i++) {
                log(result[i].val + ' ' + new Date(result[i].ts).toISOString());
            }
        }
    }
);

[legendary83]

@paul53
Zeitraum 1 Monat
Das gleiche wie oben - ca. 100 indexzeilen +1900more

Und das Skript:

getHistory('history.0',
    {
        id:         'node-red.0.Halle5.Linie1.120er',
        start:      new Date('2024-10-01 00:00').getTime(),
        end:        new Date('2024-11-01 00:00').getTime(),
        aggregate:  'onchange'
    },
    (err, result) => {
        if (err) console.error(err);
        if (result) {
            for (let i = 0; i < result.length; i++) {
                log(result[i].val + ' ' + new Date(result[i].ts).toISOString());
            }
        }
    }
);

Gibt mir exakt 2000 Zeilen in den log.

Ich fürchte fast das Du da recht hast.
Es werden demnach in der Schleife auch nur 2000 Zeilen ausgewertet.

Man könnte getHistory in Schleife bearbeiten, bis alle Werte vorliegen.

Ich werd mal herumtesten, sollte sich was neues ergeben, meld ich mich.

[Homoran]

@legendary83 sagte in Adapter history.0 auswerten für 16 Datenpunkte und 12 Monate:

Ich wusste es schlicht damals nicht besser.

Dann würde ich es jetzt umstellen und nur noch die Laufzeiten loggen, die per Skript aus der Timestamp Differenz auf Änderung des Switches gerechnet werden.
Womöglich sogar nur einmal täglich in einen DP schreiben.

Ein sekündlicher Trigger ist Blödsinn, Javascript arbeitet eventbasiert

[OliverIO]

@legendary83

ich würde immer den Statuswechsel aufzeichnen. also AN mit uhrzeit und AUS mit uhrzeit,
dann lassen sich die daten auch nachträglich noch plausibilisieren (bspw wenn sich eine längere betriebszeit ergeben würde, weil einmal ein statuswechsel nicht aufgezeichnet wurde.
Die Daten dazwischen sind nicht wirklich notwendig.

wenn immer gleich aufsummiert wird, kann man das nachträglich nicht machen.
uhrzeit muss man nicht explizit aufzeichnen, da der datenpunkt ja immer mit timestamp aufgezeichnet wird.

Nachtrag:
Du kannst auch dein bestehendes Skript aus Sicherheitsgründen so lassen, falls mal irgendwann aus irgendwelchen Gründen nicht registriert wird.
Du musst nur in den Dantenpunkteinstellungen einfach nur "Nur Änderungen aufzeichnen" ankreuzen.

[legendary83]

@homoran

Das habe ich bereits umgesetzt.
Es läuft ein Betriebsstundenzähler (1DP) und bei Monatswechsel wird der aktuelle in den historischen (1DP) kopiert.
Der aktuelle wird geleert. Der Historische Zählstand wird in der History mit Haken Wertänderung auf 2 Jahre aufgehoben.

In diesem Thema ging es ja nur darum, die bis dato aufgelaufenen Werte auszuwerten.

@OliverIO

Ja das ist korrekt.
Mehr braucht es nicht.

[paul53]

@legendary83 sagte: Gibt mir exakt 2000 Zeilen in den log.

Versuche es mal mit "limit":

getHistory('history.0',
    {
        id:         'node-red.0.Halle5.Linie1.120er',
        start:      new Date('2024-10-01 00:00').getTime(),
        end:        new Date('2024-11-01 00:00').getTime(),
        aggregate:  'none',
        limit:      267840
    },
    (err, result) => {
        if (err) console.error(err);
        if (result) {
            for (let i = 0; i < result.length; i++) {
                log(result[i].val + ' ' + new Date(result[i].ts).toISOString());
            }
        }
    }
);

EDIT: Wenn es mit dem großen Limit funktioniert, Blockly aber die Option nicht bietet, kannst du mal native.limit im Objekt "system.adapter.history.0" anpassen.

  "native": {
    "maxLength": "100",
    "limit": 2000,
    "storeDir": "/opt/iobroker/iobroker-data/history",
    "debounce": "1000",
    "retention": "604800",
    "storeFrom": true,
    "storeAck": true,
    "changesRelogInterval": 86400,
    "changesMinDelta": "0",
    "writeNulls": false,
    "blockTime": 0,
    "debounceTime": 0,
    "disableSkippedValueLogging": false,
    "enableLogging": false,
    "round": "",
    "customRetentionDuration": 365
  },

[legendary83]

@paul53 said in Adapter history.0 auswerten für 16 Datenpunkte und 12 Monate:

@legendary83 sagte: Gibt mir exakt 2000 Zeilen in den log.

Versuche es mal mit "limit":

Danke danke! Das war es. Nach dem ersten Tests ohne Aggregation an getHistory hat das in vielen Fällen schon korrekte Ergebnisse gezeigt.

EDIT: Wenn es mit dem großen Limit funktioniert, Blockly aber die Option nicht bietet, kannst du mal native.limit im Objekt "system.adapter.history.0" anpassen.

Ich hab das jetzt direkt im Adapter eingetragen. Herzlichen Dank für den Hinweis!

Tatsächlich hab ich nun wirklich nur noch ein kleines Problem.
Wie ich weiter oben zu davig-g geschrieben hatte:

Ich habe einen Tag, da weicht Soll ist um 5 Stunden ab.
Der Tag hat mit 5 Minuten True begonnen - dazwischen mehrere Zustandswechsel - endet dann mit 4 Stunden 55 Minuten True.
Das sind relativ exakt die 5 Stunden die fehlen.

Das ist nicht ganz richtig.
Wenn der DP zu beginn des betrachteten Zeitraum schon True ist, wird dieser korrekt gezählt.
Wenn der Datenpunkt zum Ende des betrachteten Zeitraums True ist, wird der komplette Abschnitt am Ende nicht gezählt.

Hier mal 2 Flots die je einen Tag zeigen, es geht nur um den grünen DP:

Ist: 18h 49m Script: 11h 30m - letzter Abschnitt fehlt

Ist: 11h 6m Script: 11h 6m - korrekt

Für Interessierte, hier das Script von @paul53 um das es geht:

Könnte man nicht vor der Schleife über result ermitteln was der größte index ì in result ist und diesen für die Schleife FALSE setzen, sodass der letzte Zeitraum auch erfasst wird?
In meinem Fall würden dann halt 10 Sekunden Betrieb im Ergebnis verloren gehen, was völlig ok ist.

DANKE

[David G.]

@legendary83

Hier der Vollständigkeit halber meine aktuelle Version.
Ich frage erst noch ab, ob überhaupt ein Ergebnis in der Abfrage ist, da es sonst eine Fehlermeldung gibt.

Dann füge ich der Liste am Ende noch ein false mit der aktuellen Zeit ein, falls das Fenster grad noch offen ist.

Wenn man Daten in der Vergangenheit abfragt, muss man in das letzte Element den Zeitstempel zum Ende der Abfrage eintragen, damit das letzte true erfaßt wird (hab ich nicht eingebaut).

[legendary83]

@david-g

Danke Dir,

ich hab Dein script dementsprechend angepasst indem ich mir das letzte Element aus result hole und in variable letzte schreibe.
Dann setze ich das value auf False und füge letzte wieder an das Ende der liste.
Nun wird mein Problemfall von oben wo der Tag mit True endet, auch korrekt ermittelt.

[paul53]

@legendary83 sagte: Dann setze ich das value auf False und füge letzte wieder an das Ende der liste.

Das Einfügen ist nicht nötig, da die Änderung auf false direkt im letzten Objekt erfolgt: Objekte / Arrays werden per Referenz (Zeiger) übergeben. So sollte es genügen:

Wozu soll das Objekt jetzt gut sein?

[legendary83]

@paul53

Das Objekt jetzt macht in meinem Fall keinen Sinn mehr.
Ich passe das noch an Danke

EDIT:

Das einzige was ich jetzt noch fehlt und das konnte ich noch nicht ganz ergründen.

Mutmaßlich in Abschnitten wo es keine Werte gab, ich sag mal iobroker Neustart oder Stromausfall.

Da gibt mir das Skript NaN als Ergebnis aus.
Ich denke ich müsste die Werte in result noch auf Plausibilität prüfen...

[paul53]

@legendary83 sagte: Da gibt mir das Skript NaN als Ergebnis aus.

NaN kann nur dann das Ergebnis sein, wenn ts keine Zahl enthält oder nicht vorhanden ist. Gibt es solche Objekte in result?

Versuche es mal so:

[legendary83]

@paul53

Ich habe einen eingegrenzt und gefunden:

Ein Timestamp des DP war weder True noch False

In 12 betrachteten Monaten ist das 2 mal vorgekommen.

Finale Version:

var ed, obj, result, lastValue, onTime, i, value, ts;


getHistory({
  id: 'ID auswählen',
  start: getDateObject('2025-09-01 00:00').getTime(),
  end: getDateObject('2024-03-01 00:00').getTime(),
  aggregate: 'none',
  removeBorderValues: true,
}, async (err, result) => {
  if (err) {
    console.error(err);
  } else {
    ed = 0;
    if (result.length > 0) {
      ((obj) => { if (typeof obj === 'object') { obj['val'] = false; } })((result.slice(-1)[0]));
      obj = result[0];
      lastValue = getAttr(obj, 'val');
      if (lastValue) {
        onTime = getAttr(obj, 'ts');
      }
      var i_end = result.length;
      var i_inc = 1;
      if (2 > i_end) {
        i_inc = -i_inc;
      }
      for (i = 2; i_inc >= 0 ? i <= i_end : i >= i_end; i += i_inc) {
        obj = result[(i - 1)];
        value = getAttr(obj, 'val');
        ts = getAttr(obj, 'ts');
        if ((typeof value == 'boolean') && (typeof ts == 'number') && (value != lastValue)) {
          lastValue = value;
          if (value) {
            onTime = ts;
          } else {
            ed = (typeof ed === 'number' ? ed : 0) + (ts - onTime);
          }
        }
      }
    }
    console.info((Math.round(ed / 360000) / 10));
  }
});

Für größere Zeiträume muss der Parameter limit von getHistory vergrößert werden.
Im Standard liest getHistory 2000 Timestamps für den Datenpunkt ein.
Die Erweiterung des Limits ist nicht im Skript darüber enthalten, sondern wurde im Objekt von getHistory eingetragen.

Das Skript funktioniert nun einwandfrei!
Ich möchte mich bei allen Herzlich bedanken für den Support!

Insbesondere bei @paul53 und @David-G