History Adapter - exportieren / migrieren nach InfluxDB

[Einstein67]

@kiste01 said in History Adapter - exportieren / migrieren nach InfluxDB:

Was mache ich da falsch?

Versuche das Script mal mit node zu starten und nicht mit nodejs!

[kiste01]

@einstein67

Super. Das war es schon.

@FredF Kannst du die Beschreibung bitte aktualisieren?

[Davipet]

Hi,

ich versuche grade die Daten von etwa einem Jahr Histroy zu influx zu migrieren.
Es sind wirklich ziemlich viele Daten.

Ich habe die Influx Datenbank ganz frisch aufgesetzt und wollte einfach alle Daten migrieren ohne das Analyse-script durchlaufen zu lassen. Bekomme aber immer nur ein "ignore" bei allen Datenpunkten. Wie kommt das?

Und: Wenn ich das Analyse-script starte bekomme ich:

Do deep analysis to find holes in data
Invalid call

Aber danach keinen Promt. Also passiert irgend etwas?
Es werden in dem Converter-Ordner aber keine Dateien angelegt.
Ich habe das Fenster nun schon fast 48h offen - meint ihr da passiert noch etwas?

Danke!

Gruß

David

[vo5tr0]

@davipet

Stehe gerade vor genau dem selben Problem. Analyse Script gerade eben gestartet und Invalid Call angezeigt bekommen.

Konntest du eine Lösung dafür finden?

[spoeh-man]

Irgendwie schaffe ich es auch nicht meine History Daten zu migrieren es läuft alles durch und endet mit done aber es ist kein einziger wert übertragen worden

Send Data to influxdb.0
Start at 20221221
Use historyDir /opt/iobroker/iobroker-data/history/
earliesDBValues initialized from cache 16
earliesDBValues overwritten with 1671646285896
ExistingDBTypes initialized from cache 16
Started processFiles with 16 known db values
We start earliest at 20221221
DONE

Was mache ich nur Falsch ich habe damit gestartet

node history2db.js influxdb.0 info 20221221 /opt/iobroker/iobroker-data/history/ --ignoreExistingDBValues

[A Former User]

@spoeh-man sagte in History Adapter - exportieren / migrieren nach InfluxDB:

20221221

Hi,

willst Du wirklich nur die Daten von heute?
Soweit ich den Adapter verstanden habe, siehe Doku Datenübernahme kannst Du da 0 oder ein Datum schreiben und ab da werden die Daten Konvertiert. So Du auch die Analyse vorher gemacht hast. Ablauf steht aber im Link gut beschrieben.

VG
Bernd

[spoeh-man]

@dp20eic Es ist tatsächlich egal was ich da eintrage habe es schon mit 0 und auch mit Daten von vor 3 Jahren probiert Ergebnis ist irgendwie immer gleich

[A Former User]

@spoeh-man

Ich habe das noch nicht gemacht, oder gebraucht. Nur nach der von mir verlinkten Seite sind das ja mehrere Punkte, die Du machen musst.
Wenn ich mir die Meldung von Dir, in Rot, anschaue dann hat er nur 16 Werte gefunden und mit einem Wert 1671646285896 Überschrieben, wenn das ein Unix Zeitstempel ist dann liegt der in der Zukunft.

Kannst Du nach dem ersten Schritt, einmal in die erzeugten .json Files schauen was da so drin steht. Ansonsten müsste ich mir mal den history adapter installieren ein paar Stunden Daten sammeln und das dann auch mal versuchen.

Schritt 1

Spoiler

Empfohlene Vorgehensweise bei der Migration

Zur Migration wird folgender Ablauf empfohlen:

    Zuerst die neue Logging Methode aktivieren und alle Datenpunkte richtig konfigurieren. Prüfen, dass alle Werte ankommen wie geplant. Logging erfolgt "doppelt" (in History und im neuen Ziel).
    Analyse-Skripte laufen lassen um den exakten Bereich zu ermitteln, welcher migriert werden soll.
    History Adapter stoppen un die Migration ausführen. Dies kann etwas dauern. Die alten Werte werden hinzugefügt.
    Wenn alles passt (und die Logfiles ausgewertet sind): History Daten löschen und Adapter deaktivieren.

Schritt 1: Aufbereiten und analysieren von vorhandenen Daten

Beim Konvertieren von Daten sollten nur die Daten übertragen werden, die noch nicht in der Zieldatenbank vorhanden sind. Dafür werden je nach gewünschter Zieldatenbank die Skripte analyzeinflux.js oder analyzesql.js genutzt. Hiermit wird zu Beginn einer Datenübernahme geprüft, welche Daten bereits vorhanden sind, um diese lokal in .json Dateien zu speichern. Die .json Dateien werden dann vom eigentlichen Konverter history2db.js Skript verwendet.

Folgende .json Dateien werden erstellt:

    frühester Wert für Datenpunkt-ID Der Zeitstempel des allerersten Eintrags für jeden vorhandenen Datenpunkt wird gespeichert und beim Importieren verwendet, um standardmäßig alle neueren Werte zu ignorieren. Es wird davon ausgegangen, dass die Daten ab diesem ersten Eintrag vollständig ausgefüllt sind und alle früheren Werte ansonsten dupliziert würden. Diese Annahme kann beim Import durch Parameter überschrieben werden.

    vorhandene Werte pro Tag pro Datenpunkt-ID Die vorhandenen Daten werden pro Tag analysiert und an jedem Tag, an dem bereits Daten vorhanden sind, gespeichert. Dies kann alternativ zu den ersten Daten verwendet werden, um auch "Löcher" in die Daten füllen zu können.

analyzeinflux.js

Dieses Skript sammelt die oben genannten Daten für eine InfluxDB-Instanz.

Verwendung:

node analyzeinflux.js [InfluxDB-Instanz] [Loglevel] [--deepAnalyze]

Beispiel:

node analyzeinflux.js influxdb.0 info --deepAnalyze

Parameter:

    Welche InfluxDB-Instanz soll verwendet werden? (Standard: influxdb.0) Wenn benutzt, muss dies der erste Parameter nach dem Skriptnamen sein.
    Loglevel für die Ausgabe (Standard: info). Wenn gesetzt, muss dies der zweite Parameter nach dem Skriptnamen sein.
    --deepAnalyze sammelt auch die vorhandenen Werte pro Tag, standardmäßig wird nur der früheste Wert abgefragt.

Das Skript generiert dann eine oder drei .json-Dateien mit den gesammelten Daten. Diese Dateien werden dann vom eigentlichen Konverter Skript verwendet.

Schritt 2

Spoiler

History-Daten konvertieren

Das Skript history2db.js verwendet die in Schritt 1 generierten .json Dateien um sie in die Zieldatenbank zu konvertieren. Dabei werden die generierten Dateien untersucht um nur nicht bereits vorhandene Daten zu konvertieren.

Das Skript kann auch ohne vorherigen Analyseschritt 1 ausgeführt werden. Dann müssen jedoch die Startdaten [Date-to-start] als Parameter festgelegt werden und alle vor diesem Zeitpunkt liegende Daten werden konvertiert.

Wenn zuvor eine Analyse ausgeführt wurde und die Datei earliestDBValues.json vorhanden ist, werden nur diese Datenpunkte konvertiert, außer es werden Parameter verwendet, um dies abzuändern.

Wenn zuvor eine Analyse ausgeführt wurde und die Datendateien wurden verwendet, werden diese auch mit allen konvertierten Daten aktualisiert, sodass bei einer zweiten Ausführung normalerweise keine Duplikate generiert werden sollten.

Um die Daten zurückzusetzen, sind die Dateien earliestDBValues.json, existingDBValues.json und/oder existingDBTypes.json zu löschen.

Der Konverter durchläuft dann alle als Daten verfügbaren Tage in der Zeit rückwärts und bestimmt, welche Daten an InfluxDB übertragen werden sollen.

    Der Vorgang kann mit "x" oder "Strg-C" abgebrochen werden.

Das Konverter Skript selbst sollte mit allen Verlaufs-Adaptern funktionieren, welche die storeState Methode unterstützen.

    Hinweis: Die Migration vieler Daten führt zu einer bestimmten Systemlast, insbesondere wenn Konverter und Zieldatenbankinstanz auf demselben Computer ausgeführt werden. Die Auslastung und Leistung des Systems während der Aktion sollte überwacht werden und möglicherweise der Parameter delayMultiplicator verwendet werden, um ein verzögertes Abarbeiten der Daten zu nutzen.

Verwendung:

node history2db.js [DB-Instanz] [Loglevel] [Date-to-start|0] [path-to-Data] [delayMultiplicator] [--logChangesOnly [relog-Interval(m)]] [--ignoreExistingDBValues] [--processNonExistingValuesOnly] [--processAllDPs] [--simulate]

Beispiel:

node history2db.js influxdb.0 info 20161001 /path/to/data 2 --logChangesOnly 30 --processNonExistingValuesOnly

Mögliche Optionen und Parameter:

    DB-Instanz: Instanz an die die Daten gesendet werden. Erforderlicher Parameter. Muss direkt nach dem Skriptnamen angegeben werden sein.
    Loglevel: Loglevel für die Ausgabe (Default: info). Wenn gesetzt, muss dies der zweite Parameter nach dem Skriptnamen stehen.
    Date-to-start: Startdatum im Format yyyymmdd (z. B. 20191028). "0" verwenden um erkannte früheste Werte zu verwenden. Wenn gesetzt, muss dies der dritte Parameter nach dem Skriptnamen sein.
    path-to-Data Pfad zu den Datendateien. Standard iobroker-Installationsverzeichnis: /iobroker-data/history-data. Wenn gesetzt, muss dies der vierte Parameter nach dem Skriptnamen sein.
    delayMultiplicator: Ändert die Verzögerungen zwischen den Aktionen im Skript durch einen Multiplikator. "2" würde bedeuten, dass sich die Verzögerungen verdoppeln, die der Konverter berechnet hat. Wenn gesetzt, muss dies der fünfte Parameter nach dem Skriptnamen sein.
    --logChangesOnly [relog-Interval (m)] Wenn gesetzt, werden die Daten analysiert und reduziert, so dass nur geänderte Werte in InfluxDB gespeichert werden. Zusätzlich kann ein "relog-Interval" in Minuten eingestellt werden, um unveränderte Werte nach diesem Intervall neu zu protokollieren.
    --ignoreExistingDBValues: Mit diesem Parameter werden bereits vorhandene Daten ignoriert und alle Daten in den DB eingefügt. Bitte sicherstellen, dass keine Duplikate generiert werden. Diese Option ist nützlich, um unvollständige Daten zu vervollständigen. Standardmäßig werden nur alle Datenpunkte mit mindestens einem Eintrag in der Datenbank gefüllt. Dies kann von --processAllDPs überschrieben werden
    --processNonExistingValuesOnly: Mit diesem Parameter wird die Datei existingDBValues.json aus dem Analyseskript verwendet und für jeden Tag und Datenpunkt geprüft. In diesem Modus werden die vorhandenen Werte in der DB immer ignoriert und auch nicht aktualisiert. Nach Verwendung dieses Modus bitte einen weiteren Analyselauf durchführen!!!
    --processAllDPs Mit diesem Parameter wird sicher gestellt, dass alle vorhandenen Datenpunkte aus den History-Dateien in die DB übertragen werden, auch wenn diese in der DB noch nicht vorhanden sind.
    --simulate: Aktiviert den Simulationsmodus, d.h. es findet kein richtiges Schreiben statt und auch die Analysedatendateien werden beim Beenden nicht aktualisiert.

VG
Bernd

[spoeh-man]

@dp20eic said in History Adapter - exportieren / migrieren nach InfluxDB:

node analyzeinflux.js influxdb.0 info --deepAnalyze

Ja die Dateien sind nahezu leer das heisst dass er die Datenpunkte vom History schon nicht korrekt lesen kann aber im IObroker am Datenpunkt mit dem Zahnrad sehe ich werte ohne ende

[A Former User]

@spoeh-man

Gibt es irgend ein Log-File, das du uns hier zeigen kannst, von den jeweiligen Kommandos?

VG
Bernd

[spoeh-man]

@dp20eic

Klaro

root@ioBroker:/opt/iobroker/node_modules/iobroker.history/converter# node analyzeinflux.js influxdb.0 info --deepAnalyze
Do deep analysis to find holes in data
InfluxDB-Configuration: {"debounce":1000,"retention":0,"dbname":"iobroker","host":"192.168.179.66","protocol":"http","path":"","port":8086,"user":"","organization":"Privat","round":4,"seriesBufferMax":0,"seriesBufferFlushInterval":600,"changesRelogInterval":0,"changesMinDelta":0,"reconnectInterval":10000,"pingInterval":15000,"requestTimeout":30000,"validateSSL":true,"dbversion":"2.x","usetags":false,"pingserver":true,"blockTime":0,"debounceTime":0,"disableSkippedValueLogging":false,"enableLogging":false,"customRetentionDuration":365,"relogLastValueOnStart":true}
Query Data from instance "influxdb.0" (Version 2, Bucket iobroker)
Datapoints found: 16
FirstVal ID: 0_userdata.0.Aquarium.PH_Sollwert, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:37.842243322Z","_time":"2022-12-21T12:42:50.907Z","_value":7.1,"_field":"value","_measurement":"0_userdata.0.Aquarium.PH_Sollwert","ts":1671626570907}] --> Wed Dec 21 2022 12:42:50 GMT+0000 (Coordinated Universal Time)
DayVals ID: 0_userdata.0.Aquarium.PH_Sollwert: [20221222]
ValType ID: 0_userdata.0.Aquarium.PH_Sollwert: "number"
FirstVal ID: 0_userdata.0.Stromzähler.Jahresverbrauch, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:37.99657047Z","_time":"2022-12-21T12:44:03.749Z","_value":3776.586,"_field":"value","_measurement":"0_userdata.0.Stromzähler.Jahresverbrauch","ts":1671626643749}] --> Wed Dec 21 2022 12:44:03 GMT+0000 (Coordinated Universal Time)
DayVals ID: 0_userdata.0.Stromzähler.Jahresverbrauch: [20221222,20221222]
ValType ID: 0_userdata.0.Stromzähler.Jahresverbrauch: "number"
FirstVal ID: 0_userdata.0.Stromzähler.Verbrauch_Abrechnungperiode, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:38.168296659Z","_time":"2022-12-21T12:45:03.386Z","_value":929.594,"_field":"value","_measurement":"0_userdata.0.Stromzähler.Verbrauch_Abrechnungperiode","ts":1671626703386}] --> Wed Dec 21 2022 12:45:03 GMT+0000 (Coordinated Universal Time)
DayVals ID: 0_userdata.0.Stromzähler.Verbrauch_Abrechnungperiode: [20221222,20221222]
ValType ID: 0_userdata.0.Stromzähler.Verbrauch_Abrechnungperiode: "number"
FirstVal ID: Testdatenpunkt, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:38.325955045Z","_time":"2022-12-21T12:14:56.267Z","_value":40,"_field":"value","_measurement":"Testdatenpunkt","ts":1671624896267}] --> Wed Dec 21 2022 12:14:56 GMT+0000 (Coordinated Universal Time)
DayVals ID: Testdatenpunkt: [20221222]
ValType ID: Testdatenpunkt: "number"
FirstVal ID: shelly.0.SHEM-3#84CCA8AD96DA#1.Total.ConsumedPower, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:38.480358464Z","_time":"2022-12-21T12:45:04.531Z","_value":7696383.1,"_field":"value","_measurement":"shelly.0.SHEM-3#84CCA8AD96DA#1.Total.ConsumedPower","ts":1671626704531}] --> Wed Dec 21 2022 12:45:04 GMT+0000 (Coordinated Universal Time)
DayVals ID: shelly.0.SHEM-3#84CCA8AD96DA#1.Total.ConsumedPower: [20221222,20221222]
ValType ID: shelly.0.SHEM-3#84CCA8AD96DA#1.Total.ConsumedPower: "number"
FirstVal ID: shelly.0.SHEM-3#84CCA8AD96DA#1.Total.InstantPower, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:38.638267956Z","_time":"2022-12-21T12:45:24.458Z","_value":436.45,"_field":"value","_measurement":"shelly.0.SHEM-3#84CCA8AD96DA#1.Total.InstantPower","ts":1671626724458}] --> Wed Dec 21 2022 12:45:24 GMT+0000 (Coordinated Universal Time)
DayVals ID: shelly.0.SHEM-3#84CCA8AD96DA#1.Total.InstantPower: [20221222,20221222]
ValType ID: shelly.0.SHEM-3#84CCA8AD96DA#1.Total.InstantPower: "number"
FirstVal ID: sonoff.0.Aquarium_PH.ANALOG_pH0, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:38.857229274Z","_time":"2022-12-21T12:50:25.252Z","_value":7.13,"_field":"value","_measurement":"sonoff.0.Aquarium_PH.ANALOG_pH0","ts":1671627025252}] --> Wed Dec 21 2022 12:50:25 GMT+0000 (Coordinated Universal Time)
DayVals ID: sonoff.0.Aquarium_PH.ANALOG_pH0: [20221222,20221222]
ValType ID: sonoff.0.Aquarium_PH.ANALOG_pH0: "number"
FirstVal ID: sonoff.0.Solaranlage.ENERGY_Power, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:39.023154755Z","_time":"2022-12-21T12:50:42.816Z","_value":2,"_field":"value","_measurement":"sonoff.0.Solaranlage.ENERGY_Power","ts":1671627042816}] --> Wed Dec 21 2022 12:50:42 GMT+0000 (Coordinated Universal Time)
DayVals ID: sonoff.0.Solaranlage.ENERGY_Power: [20221222,20221222]
ValType ID: sonoff.0.Solaranlage.ENERGY_Power: "number"
FirstVal ID: sonoff.0.Solaranlage.ENERGY_Total, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:39.193313178Z","_time":"2022-12-21T12:50:51.15Z","_value":604.922,"_field":"value","_measurement":"sonoff.0.Solaranlage.ENERGY_Total","ts":1671627051150}] --> Wed Dec 21 2022 12:50:51 GMT+0000 (Coordinated Universal Time)
DayVals ID: sonoff.0.Solaranlage.ENERGY_Total: [20221222,20221222]
ValType ID: sonoff.0.Solaranlage.ENERGY_Total: "number"
FirstVal ID: stromzaeler, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:39.346660386Z","_time":"2022-12-21T12:43:52.117Z","_value":47082.578,"_field":"value","_measurement":"stromzaeler","ts":1671626632117}] --> Wed Dec 21 2022 12:43:52 GMT+0000 (Coordinated Universal Time)
DayVals ID: stromzaeler: [20221222,20221222]
ValType ID: stromzaeler: "number"
FirstVal ID: zigbee.0.00158d0001e8a0af.humidity, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:39.50877007Z","_time":"2022-12-21T12:48:43.618Z","_value":51.51,"_field":"value","_measurement":"zigbee.0.00158d0001e8a0af.humidity","ts":1671626923618}] --> Wed Dec 21 2022 12:48:43 GMT+0000 (Coordinated Universal Time)
DayVals ID: zigbee.0.00158d0001e8a0af.humidity: [20221222,20221222]
ValType ID: zigbee.0.00158d0001e8a0af.humidity: "number"
FirstVal ID: zigbee.0.00158d0001e8a0af.temperature, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:39.662470987Z","_time":"2022-12-21T12:48:50.792Z","_value":22.12,"_field":"value","_measurement":"zigbee.0.00158d0001e8a0af.temperature","ts":1671626930792}] --> Wed Dec 21 2022 12:48:50 GMT+0000 (Coordinated Universal Time)
DayVals ID: zigbee.0.00158d0001e8a0af.temperature: [20221222,20221222]
ValType ID: zigbee.0.00158d0001e8a0af.temperature: "number"
FirstVal ID: zigbee.0.00158d00020245b3.humidity, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:39.815973012Z","_time":"2022-12-21T12:49:06.266Z","_value":50.31,"_field":"value","_measurement":"zigbee.0.00158d00020245b3.humidity","ts":1671626946266}] --> Wed Dec 21 2022 12:49:06 GMT+0000 (Coordinated Universal Time)
DayVals ID: zigbee.0.00158d00020245b3.humidity: [20221222,20221222]
ValType ID: zigbee.0.00158d00020245b3.humidity: "number"
FirstVal ID: zigbee.0.00158d00020245b3.temperature, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:39.965729664Z","_time":"2022-12-21T12:49:13.932Z","_value":22.28,"_field":"value","_measurement":"zigbee.0.00158d00020245b3.temperature","ts":1671626953932}] --> Wed Dec 21 2022 12:49:13 GMT+0000 (Coordinated Universal Time)
DayVals ID: zigbee.0.00158d00020245b3.temperature: [20221222,20221222]
ValType ID: zigbee.0.00158d00020245b3.temperature: "number"
FirstVal ID: zigbee.0.00158d00025ea014.humidity, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:40.114570292Z","_time":"2022-12-21T12:49:27.074Z","_value":92.81,"_field":"value","_measurement":"zigbee.0.00158d00025ea014.humidity","ts":1671626967074}] --> Wed Dec 21 2022 12:49:27 GMT+0000 (Coordinated Universal Time)
DayVals ID: zigbee.0.00158d00025ea014.humidity: [20221222,20221222]
ValType ID: zigbee.0.00158d00025ea014.humidity: "number"
FirstVal ID: zigbee.0.00158d00025ea014.temperature, Rows: [{"result":"_result","table":0,"_start":"1970-01-01T00:00:00Z","_stop":"2022-12-22T13:18:40.264161074Z","_time":"2022-12-21T12:49:34.375Z","_value":8.42,"_field":"value","_measurement":"zigbee.0.00158d00025ea014.temperature","ts":1671626974375}] --> Wed Dec 21 2022 12:49:34 GMT+0000 (Coordinated Universal Time)
DayVals ID: zigbee.0.00158d00025ea014.temperature: [20221222,20221222]
ValType ID: zigbee.0.00158d00025ea014.temperature: "number"
Writing files to /opt/iobroker/node_modules/iobroker.history/converter ...
    - saved /opt/iobroker/node_modules/iobroker.history/converter/existingDBValues.json
    - saved /opt/iobroker/node_modules/iobroker.history/converter/existingDBTypes.json
    - saved /opt/iobroker/node_modules/iobroker.history/converter/earliestDBValues.json

[A Former User]

@spoeh-man

Ok, das war die Analyse. Soweit ich das jetzt verstehe, schaut die in die Influxdb Instanz, und Du hast dort nur diese 16 Datenpunkte, welche auch in den .json Files zu finden sein sollten.

Jetzt wäre noch ein Log vom zweiten Schritt hilfreich, denn der sollte ja diese Information aus den drei Files nehmen und alles was noch nicht in der InfluxDB vorhanden ist reinkloppen, jedenfalls die Datenpunkte die dort in den .json Files vorhanden sind.
Frage sind das die 16 Datenpunkte, die Du auch im History Adapter sicherst?

Wie gesagt, ich habe mich nicht mit der Konvertierung beschäftigt, ich habe weggeschmissen und neu angefangen, daher vielleicht auch Dumme Fragen dabei!

VG
Bernd

[spoeh-man]

@dp20eic

Ja das sind die 16 Datenpunkte die ich Im History sichere. Das mit den Json dateien ist eben dass problem dort steht fast nichts drinnen ausser die Datenpunkte wenn ich aber dass 2. script laufen lassen kommt als Ausgabe: (ich habe es extra mal mit möglichst wenigen Parametern laufen lassen) 2. Ausgabe mal mit Datum von 1970

node history2db.js influxdb.0 info 20211201 /opt/iobroker/iobroker-data/history/
Send Data to influxdb.0
Start at 20211201
Use historyDir /opt/iobroker/iobroker-data/history/
earliesDBValues initialized from cache 16
ExistingDBTypes initialized from cache 16
Started processFiles with 16 known db values
We start earliest at 20211201
DONE


node history2db.js influxdb.0 info 19700101 /opt/iobroker/iobroker-data/history/
Send Data to influxdb.0
Start at 19700101
Use historyDir /opt/iobroker/iobroker-data/history/
earliesDBValues initialized from cache 16
ExistingDBTypes initialized from cache 16
Started processFiles with 16 known db values
We start earliest at 19700101
DONE

aber übernommen wird leider nichts

[A Former User]

@spoeh-man

Wenn da nicht mehr an output kommt, dann solltest Du mal auf Github ein Problem aufmachen.
Oder evtl. wenn es gibt mit debug laufen lassen.

VG
Bernd

[spoeh-man]

@dp20eic

Ja debug zeigt den gleichen Inhalt ich hab mal ein Problem in Github eröffnet

[apollon77]

@jensmaehn Das glaube ich eher ... es werden halt viele Daten an den "neuen" adapter gesendet ... das generiert durchaus CPU Last. mehr aber auch nicht

[apollon77]

@davipet Dann zeige bitte mal ein verzeichnislisting (bzw Auszug) von dem angegebenen History Datenverzeichnis. Sie da Verzeichnisse in "Datumsform" drin? yyyymmdd und am besten auch mal den Inhalt von einem davon und dann die zwei json Files die er in der vorbereitung angelegt hat.

Weil an sich sieht der Start des Skripts gut aus ... AM besten ruf es doch jetzt mal ohne einen Datumsparameter im Aufruf auf bzw dort eine 0. Was passiert dann?

PS: Die eine Logzeile "We start earliest at ..." ist am Ende genau falsch ... Die muss "We only process values before ...". Also mit 1970 kommt deshalb nix ...aber mit Datum von heute sollte mehr passieren Am Ende ist da eine "0" aber das beste weil dann ermittelt er den "end wert" aus den gesammelten Daten

[spoeh-man]

@apollon77

Verzeichnislisting vom Datenverzeichnis

root@ioBroker:/opt/iobroker/iobroker-data/history# ls -la
total 28
drwxrwxr-x+ 845 iobroker iobroker 20480 Dec 25 00:01 ' '
drwxrwxr-x+   3 iobroker iobroker  4096 Dec 21 09:17  .
drwxrwxr-x+  10 iobroker iobroker  4096 Dec 25 05:48  ..
root@ioBroker:/opt/iobroker/iobroker-data/history# 

ich glaube da könnte auch schon dass Problem sein aber im iobroker ist genau dieses verzeichnis im Adapter hinterlegt

[apollon77]

@spoeh-man was ist das denn für ein Verzeichnis da mit einem Leerzeichen? Ist vllt in der Konfiguration da auch ein Space am Ende?sind die files dort? Wenn ja setze beim Aufruf den Pfad mal in Anführungszeichen und hänge auch ein Leerzeichen noch an.

[spoeh-man]

@apollon77

Ich glaube das war es woher auch immer dass Leerzeichen stammt hätte nur noch keine Zeit zur Migration musste zur Arbeit