History Adapter - exportieren / migrieren nach InfluxDB
-
@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
-
Gibt es irgend ein Log-File, das du uns hier zeigen kannst, von den jeweiligen Kommandos?
VG
Bernd -
@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 -
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
.jsonFiles 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
.jsonFiles 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 -
@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 DONEaber übernommen wird leider nichts
-
Wenn da nicht mehr an output kommt, dann solltest Du mal auf Github ein Problem aufmachen.
Oder evtl. wenn es gibt mitdebuglaufen lassen.VG
Bernd -
@dp20eic
Ja debug zeigt den gleichen Inhalt ich hab mal ein Problem in Github eröffnet
-
@jensmaehn Das glaube ich eher ... es werden halt viele Daten an den "neuen" adapter gesendet ... das generiert durchaus CPU Last. mehr aber auch nicht
-
@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 -
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
-
@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.
-
Ich glaube das war es woher auch immer dass Leerzeichen stammt hätte nur noch keine Zeit zur Migration musste zur Arbeit
-
@spoeh-man also alle Speiseöle oben sind ohne Anführungszeichen um den odad und ohne Leerzeichen am Ende beim Aufruf des convert Skripts.
-
Was für Speiseöle?. Irgendwie kann ich es trotz mehrmaligen Lesens nicht genau deuten was die frage ist aber das script tut gerade seinen dienst. Vielen Lieben dank für eure Hilfe
-
Ohje Handy mal wieder ... Screenshots war das wort :-)) Aber wenn es jetzt tut ist ja alles super
-
Hallo zusammen,
ich wollte meine Datenbank auch zu Influx migrieren.
Habe die Skripte soweit befolgt. Die laufen auch ohne Fehlermeldung durch. Allerdings werden keine Daten aus dem Datenbestand vom History Adapter kopiert.
Meine Vermutung liegt im Timestamp der Daten im History Adapter.
Beim Blick in die .json-Datei vom Analyse-Skript werden für die frühesten Datensätze allesamt Timestamps angezeigt, die weit in der Zukunft liegen. Beim Durchlaufen des Migriervorgangs kann er dann natürlich keine Daten finden, die zwischen dem frühesten Timestamp und heute liegen.Nachfolgend noch der Inhalt aus der earliestDBValues.json
Bei Diagrammen, die ich mit Flot oder ECharts erstelle passen die Zeiten. Auch die Ordnerstruktur im History Ordner auf dem Pi passt. Da ist für jeden Tag ein Ordner nach dem muster YYYYMMDD erstellt.
Habt ihr ne Ahnung woran das liegen könnte und wie man das abstellen kann?
Vielen Dank schonmal
Edit wegen Typo
-
@saarlanduhu Wenn ich einen mit history erzeugten timestamp in https://www.epochconverter.com/ gebe und "timestamp to human date" drücke, kommt die richtige Zeit raus mit dem Hinweis "assuming timestamp in ms".
Lösche ich die letzten 3 Stellen, dann kommt auch wieder das gleiche Datum raus mit dem Hinweis "assuming timestamp in s".
Es scheinen also 2 Formate für epoch üblich zu sein, im ms und in s.
Vielleicht gibt es da Misverständnisse bei der konvertierung? -
@klassisch, danke dir.
das erklärt zumindest mal warums an den anderen Stellen dann passt.
Leider bringt mich das bei der Migration der Daten nicht weiter. Bzw. Zumindest weiß ich nicht wie ich die Info für mein Problem nutzen könnte.
-
@saarlanduhu sagte in History Adapter - exportieren / migrieren nach InfluxDB:
Zumindest weiß ich nicht wie ich die Info für mein Problem nutzen könnte.Ich leider auch nicht. Vielleicht kann man bei InfluxDB (was ich nicht habe und nicht kenne) etwas konfigurieren?
-
Ookkk.die timestamps sollte er selbst behandeln. Also. Bitte zeig mal wie du es ausführst und was die Ausgabe ist.
