History2DB converter

apollon77

Soooo , neue version vom ganzen gibt es jetzt im History-Github und wurde etwas umgebaut. Siehe Github README.md, da ist Doku drauf :-)

apollon77

Update: History-Adapter und SQL-Adapter vom Github nehmen und dann gibt unter https://github.com/ioBroker/ioBroker.history in der Readme unter "Data converter" auch Infos und den aktuellen Stand. Ich habe es rudimentär mit SQLite getestet und klappte soweit … jetzt wären freiwillige gefragt :-)

Was noch fehlt für SQL ist das selektieren auf Tagesebene für welche Tage schon Daten vorliegen und für welche nicht, aber da müsste man für alle 4 Datenbanktypen die Queries zusammenbasteln -da fehlt mir aktuell ehrlich gesagt die Zeit. Aber auch so sollte es gehen das alle Daten die älter sind als der älteste vorhandene Eintrag nur aingefügt werden was schonmal gut für ne Umstellung ist.

GerdSo

Ich bekomme es nicht zum Laufen. Er bricht bei mir beim Übertragen in eine mysql immer ab:

c:\Program Files\ioBroker\node_modules\iobroker.history\converter>node history2db.js sql.0 debug 20170202 "c:\history"
Send Data to sql.0
Start at 20170202
Use historyDir c:\history
2017-02-12 16:32:57.693  - debug: history.20170202 objectDB connected
2017-02-12 16:32:57.865  - debug: history.20170202 statesDB connected
2017-02-12 16:32:58.021  - info: history.0 starting. Version 1.5.2 in c:/Program Files/ioBroker/node_modules/iobroker.history, node: v4.6.2
No stored earliesDBValues found
No stored existingDBTypes found
started processFiles with 0 known db values
We start earliest at 20170202
Day 20170202 - history.hm-rega.0.10529.json
  datapoints reduced from 1 --> 1
Invalid call
DONE

Meine mySQL-DB läuft seit ca. 1.2.2017 und history.0 hat Daten seit dem 25.3.2016. was mache ich falsch?

Aus Sicherheitsgründen läuft weiterhin die history.0 parallel, d.h. derzeit werden die Daten in history.0 und sql.0 gespeichert.

apollon77

Hey,

jippie, das Skript wird mal benutzt :-))

Welche sql-Adapter-Version läuft? Bitte schauen das das aktuell ist.

Dann erstmal schauen das das Skript an sich läuft- Starte es mal noch zusätzlich mit "–simulate" und schau was dann so geloggt wird.

Der "Invalid call" sagt an sich das die Message falsch wäre die gesendet wird. Komisch.

Wenn bei "simulate" alles sinnvoll aussieht, dann bitte sql-Adapter vom Github drüber installieren. Da sollte dann bei "Invalid call" mehr Debug sein. Das dann nochmal schicken. Danke

GerdSo

Hi,

` > Welche sql-Adapter-Version läuft? Bitte schauen das das aktuell ist.

Dann erstmal schauen das das Skript an sich läuft- Starte es mal noch zusätzlich mit "–simulate" und schau was dann so geloggt wird.

Der "Invalid call" sagt an sich das die Message falsch wäre die gesendet wird. Komisch.

Wenn bei "simulate" alles sinnvoll aussieht, dann bitte sql-Adapter vom Github drüber installieren. Da sollte dann bei "Invalid call" mehr Debug sein. Das dann nochmal schicken. Danke `

–simulate erzeugt sinnvolle Ausgaben. Kleiner Auszug:

Day 20170131 - history.hm-rpc.0.MEQ1555921.4.MANU_MODE.json
  datapoints reduced from 1 --> 1
  SIMULATE: Not really writing ... 1 values for hm-rpc.0.MEQ1555921.4.MANU_MODE
Day 20170131 - history.hm-rpc.0.MEQ1555921.4.PARTY_MODE_SUBMIT.json
  datapoints reduced from 1 --> 1
  SIMULATE: Not really writing ... 1 values for hm-rpc.0.MEQ1555921.4.PARTY_MODE_SUBMIT
Day 20170131 - history.hm-rpc.0.MEQ1555921.4.PARTY_START_DAY.json
  datapoints reduced from 3 --> 3
  SIMULATE: Not really writing ... 3 values for hm-rpc.0.MEQ1555921.4.PARTY_START_DAY
Day 20170131 - history.hm-rpc.0.MEQ1555921.4.PARTY_START_MONTH.json
  datapoints reduced from 3 --> 3

Ist der aktuelle sql-Adapter 1.4.3. Habe es mit github gegengeprüft und es scheint die identische Version zu sein.

Viele Grüße Gerd.

apollon77

Installier trotzdem mal von Github drüber. Ich hab exakt eine Zeile geändert und die Version erstmal noch gleich gelassen …

Und dann starte nochmal ohne simulate und wir sehen weiter

GerdSo

Keine Besserung, identisches Verhalten:

c:\Program Files\ioBroker\node_modules\iobroker.history\converter>node history2db.js sql.0 debug 20170202 "c:\history"
Send Data to sql.0
Start at 20170202
Use historyDir c:\history
2017-02-13 22:22:27.651  - debug: history.20170202 objectDB connected
2017-02-13 22:22:27.713  - debug: history.20170202 statesDB connected
2017-02-13 22:22:27.839  - info: history.0 starting. Version 1.5.2 in c:/Program Files/ioBroker/node_modules/iobroker.history, node: v4.6.2
No stored earliesDBValues found
No stored existingDBTypes found
started processFiles with 0 known db values
We start earliest at 20170202
Day 20170202 - history.hm-rega.0.10529.json
  datapoints reduced from 1 --> 1
Data stored but dbDB not available anymore, break.
DONE

2.Durchlauf

c:\Program Files\ioBroker\node_modules\iobroker.history\converter>node history2db.js sql.0 debug 20170202 "c:\history"
Send Data to sql.0
Start at 20170202
Use historyDir c:\history
2017-02-13 22:26:47.355  - debug: history.20170202 objectDB connected
2017-02-13 22:26:47.386  - debug: history.20170202 statesDB connected
2017-02-13 22:26:47.433  - info: history.0 starting. Version 1.5.2 in c:/Program Files/ioBroker/node_modules/iobroker.history, node: v4.6.2
No stored earliesDBValues found
No stored existingDBTypes found
started processFiles with 0 known db values
We start earliest at 20170202
Day 20170202 - history.hm-rega.0.10529.json
  datapoints reduced from 1 --> 1
2017-02-13 22:28:18.915  - warn: history.0 Reconnection to DB.
2017-02-13 22:28:18.931  - warn: history.0 Reconnection to DB.
Invalid call
DONE

Evtl. war das der Grund weshalb bei meiner ersten Fehlermeldung auch der invalid call aufgetaucht ist

apollon77

Versuch mal den laufenden history.0 auszuschalten und starte dann das Skript. Nicht das sich zwei laufende "history.0" (weil das Skript registriert sich quasi auch als "history.0" in die quere kommen …

Und zusätzlich hab ich non nen Fehler gefunden (Gründe für die "DB ist weg"-Meldung in deinem ersten Lauf von oben).

Bitte SQL vom Github aktualisieren. Dann sollte der Fehler weg sein. Nach github update neustart der sqlInstanz nicht vergessen.

Dann bitte nochmal logs :-)

GerdSo

Leider ohne Erfolg (history.0 ausgeschaltet)

C:\Program Files\ioBroker>node node_modules/iobroker.js-controller/iobroker.js stop
Stopping iobroker controller daemon...
iobroker controller daemon stopped.

C:\Program Files\ioBroker>npm i https://github.com/ioBroker/ioBroker.sql/tarball/master
-
> sqlite3@3.1.7 install C:\Program Files\ioBroker\node_modules\iobroker.sql\node_modules\sqlite3
> node-pre-gyp install --fallback-to-build

[sqlite3] Success: "C:\Program Files\ioBroker\node_modules\iobroker.sql\node_modules\sqlite3\lib\binding\node-v46-win32-ia32\node_sqlite3.node" is installed via remote
iobroker.sql@1.4.3 node_modules\iobroker.sql
├── mysql@2.13.0 (sqlstring@2.2.0, bignumber.js@3.1.2, readable-stream@1.1.14)
├── sql-client@0.7.0 (argf@0.0.1, inote-util@0.8.1)
├── pg@6.1.2 (packet-reader@0.2.0, pg-connection-string@0.1.3, buffer-writer@1.0.1, semver@4.3.2, pg-types@1.11.0, pg-pool@1.6.0, pgpass@1.0.1)
├── mssql@3.3.0 (generic-pool@2.5.4, promise@7.1.1, tedious@1.14.0)
└── sqlite3@3.1.7 (nan@2.4.0)

C:\Program Files\ioBroker>iobroker start

C:\Program Files\ioBroker>node node_modules/iobroker.js-controller/iobroker.js start
Starting iobroker controller daemon...

c:\Program Files\ioBroker\node_modules\iobroker.history\converter>node history2db.js sql.0 debug 20170202 "c:\history"
Send Data to sql.0
Start at 20170202
Use historyDir c:\history
2017-02-14 20:49:09.831  - debug: history.20170202 objectDB connected
2017-02-14 20:49:09.847  - debug: history.20170202 statesDB connected
2017-02-14 20:49:09.878  - info: history.0 starting. Version 1.5.2 in c:/Program Files/ioBroker/node_modules/iobroker.history, node: v4.6.2
No stored earliesDBValues found
No stored existingDBTypes found
started processFiles with 0 known db values
We start earliest at 20170202
Day 20170202 - history.hm-rega.0.10529.json
  datapoints reduced from 1 --> 1
Data stored but dbDB not available anymore, break.
DONE

apollon77

Ok, bitte jetzt auch history vom Github aktualisieren, auch Debug drin. Jetzt bin ich gespannt was rauskommt :-)

GerdSo

~~@apollon77:~~

Ok, bitte jetzt auch history vom Github aktualisieren, auch Debug drin. Jetzt bin ich gespannt was rauskommt :-) `

Ergebnis:

c:\Program Files\ioBroker\node_modules\iobroker.history\converter>node history2db.js sql.0 debug 20170202 "c:\history"
Send Data to sql.0
Start at 20170202
Use historyDir c:\history
2017-02-14 21:47:29.548  - debug: history.20170202 objectDB connected
2017-02-14 21:47:29.580  - debug: history.20170202 statesDB connected
2017-02-14 21:47:29.611  - info: history.0 starting. Version 1.5.2 in c:/Program Files/ioBroker/node_modules/iobroker.history, node: v4.6.2
No stored earliesDBValues found
No stored existingDBTypes found
started processFiles with 0 known db values
We start earliest at 20170202
Day 20170202 - history.hm-rega.0.10529.json
  datapoints reduced from 1 --> 1
Data stored but db not available anymore, break. {"success":true}
DONE

Bis auf das {"success":true} gibt es anscheinend keine Änderung :cry:

apollon77

Grrrrrrrrrr… der Push der Änderung von sql hatte nicht geklappt ... jetzt aber. Bitte neu sql installieren, dann sollte es laufen oder sinnvolle ausgaben geben :-)

GerdSo

~~@apollon77:~~

Grrrrrrrrrr… der Push der Änderung von sql hatte nicht geklappt ... jetzt aber. Bitte neu sql installieren, dann sollte es laufen oder sinnvolle ausgaben geben :-) `
Das erklärt meine Aussage, dass sich nichts geändert hat zwischen meinem Rechner und der github-Version ;)

Jetzt passiert mehr bei der Ausgabe und er läuft aktuell immer noch, allerdings wird laut Ausgabe nahezu alles ignoriert. Ab und zu wird ein Datenpunkt am Tag übernommen:````
Day 20170122 - history.yr.0.forecast.day2.temperature_min.json
Ignore ID history.yr.0.forecast.day2.temperature_min.json: yr.0.forecast.day2.temperature_min
Day 20170122 - history.yr.0.forecast.day2.text.json
Ignore ID history.yr.0.forecast.day2.text.json: yr.0.forecast.day2.text
Day 20170122 - history.yr.0.forecast.day2.wind_direction.json
Ignore ID history.yr.0.forecast.day2.wind_direction.json: yr.0.forecast.day2.wind_direction
Day 20170122 - history.yr.0.forecast.day2.wind_speed.json
Ignore ID history.yr.0.forecast.day2.wind_speed.json: yr.0.forecast.day2.wind_speed
Day 20170122 - history.yr.0.forecast.diagram.json
Ignore ID history.yr.0.forecast.diagram.json: yr.0.forecast.diagram
Day 20170122 - history.yr.0.forecast.html.json
Ignore ID history.yr.0.forecast.html.json: yr.0.forecast.html
Day 20170122 - history.yr.0.forecast.object.json
Ignore ID history.yr.0.forecast.object.json: yr.0.forecast.object
Day end
Day 20170121 - history.admin.0.info.updatesList.json
Ignore ID history.admin.0.info.updatesList.json: admin.0.info.updatesList
Day 20170121 - history.admin.0.info.updatesNumber.json
Ignore ID history.admin.0.info.updatesNumber.json: admin.0.info.updatesNumber
Day 20170121 - history.dwd.0.warning.begin.json
Ignore ID history.dwd.0.warning.begin.json: dwd.0.warning.begin
Day 20170121 - history.dwd.0.warning.description.json
Ignore ID history.dwd.0.warning.description.json: dwd.0.warning.description
Day 20170121 - history.dwd.0.warning.end.json
Ignore ID history.dwd.0.warning.end.json: dwd.0.warning.end
Day 20170121 - history.dwd.0.warning.headline.json
Ignore ID history.dwd.0.warning.headline.json: dwd.0.warning.headline

apollon77

Jetzt kommen wir zu den zusätzlichen Parametern :-)

Entweder du lässt vorher "analyzesql.js" laufen damit alle aktuell in sql existierenden Datenpunkt-IDs gesammelt werden und auch nur die konvertiert werden.

Alternativ –ignoreExistingDBValues setzen beim import-Skript dann sollte das egal sein und alles wird konvertiert - aber dann musst DU beim abbrechen aufpassen das du nicht doubletten erzeugst!

GerdSo

~~@apollon77:~~

Jetzt kommen wir zu den zusätzlichen Parametern :-)

Entweder du lässt vorher "analyzesql.js" laufen damit alle aktuell in sql existierenden Datenpunkt-IDs gesammelt werden und auch nur die konvertiert werden.

Alternativ –ignoreExistingDBValues setzen beim import-Skript dann sollte das egal sein und alles wird konvertiert - aber dann musst DU beim abbrechen aufpassen das du nicht doubletten erzeugst! `

Ich bin davon ausgegangen, dass ohne die zusätzlichen Parameter die Dubletten vermieden werden und er alle Datenpunkte übernimmt.

Das passt aber nicht mit dem ignore, dass aktuell protokolliert wird, überein, da er jetzt sehr viele Datenpunkte übernehmen müsste oder verstehe ich da etwas falsch. "analyzesql.js" hatte bei mir bisher eine nahezu leere Datei erzeugt und –simulate protokolliert ja, dass Daten übernommen werden können. Bin etwas ratlos.

apollon77

Aaaaalso … die Idee war das man nur das nach sql konvertieren will was man auch mit sql loggt. Daher gibt es diese "analyze"-Skripte. Die suchen aus der sql-DB alle Datenpunkte raus die geloggt werden und speichert diese quasi in einer "white-list" für das Konverterskript weil dann auch nur die genommen werden.

Daher auch der Effekt, wenn Du ohne dieses analyze und daher mit leerem "welche Datenpunkte gibt es denn"-File den konverter startest, das alles ignoriert wird.

"--ignoreExistingDBValues" sagt dem Skript das er genau diese Whitelist ignorieren soll. Damit nimmt er dann alles was im History gefunden wurde egal ob es schon in sql da ist oder nicht.

Daher wenn es immer noch komisch ist: Was ist denn der Output vom analyze-Skript?

GerdSo

~~@apollon77:~~

Daher wenn es immer noch komisch ist: Was ist denn der Output vom analyze-Skript? `
Ergebnis mit gestopptem history.0, damals lief history.0 noch. Ergebnis ist aber identisch:

c:\Program Files\ioBroker\node_modules\iobroker.history\converter>node analyzesql.js
Query Data from sql.0
2017-02-15 08:03:11.425  - info: history.0 starting. Version 1.5.2 in c:/Program Files/ioBroker/node_modules/iobroker.history, node: v4.6.2
Send
{"succes":true,"result":{"undefined":{"type":"undefined","ts":1970000}}}
Datapoints found: undefined
{"undefined":{"type":"undefined","ts":1970000}}

Ergebnis earliestDBValues.json````
{"undefined":1487142206553}

Ergebnis existingDBTypes.json````
{}

apollon77

Was sagt denn das iobroker.Log von sql.0 zu dein zeitunkt? Da sollt auch was geloggt werden. Und schau bitte das sql auf loglevel "info" steht das Du diese Logs siehst.

Query result <json>Nochmal zur Klarstellung: sql.0 läuft und es sind Datenpunkte definiert die da hin loggen?!</json>

GerdSo

~~@apollon77:~~

Was sagt denn das iobroker.Log von sql.0 zu dein zeitunkt? Da sollt auch was geloggt werden. Und schau bitte das sql auf loglevel "info" steht das Du diese Logs siehst.

Query result <json>Nochmal zur Klarstellung: sql.0 läuft und es sind Datenpunkte definiert die da hin loggen?!</json> `
sql.0 läuft und es sind Datenpunkte definiert. Über die Adminoberfläche wurde das logging für sql.0 und history.0 identisch eingestellt, alle Datenpunkte loggen. Ich habe auch ein flot Diagramm auf sql.0 umgestellt und dort werden die Kurven korrekt angezeigt, daher sollten die Werte im sql.0 vorhanden sein.

log zum Zeitpunkt der Analyse (history.0 gestoppt)

<code>2017-02-17 23:37:54.844  - [31merror[39m: WARNING: cannot find logs with id = 96467210
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467638
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467639
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467640
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467641
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467642
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467643
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467644
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467645
2017-02-17 23:37:55.782  - [31merror[39m: WARNING: cannot find logs with id = 96467646
2017-02-17 23:37:55.797  - [31merror[39m: WARNING: cannot find logs with id = 96467647
2017-02-17 23:37:55.797  - [31merror[39m: WARNING: cannot find logs with id = 96467648
2017-02-17 23:37:55.797  - [31merror[39m: WARNING: cannot find logs with id = 96467649[/code]</code>

apollon77

Während der Analyse oder auch beim History-Übertragen kann es zu solchen Logs kommen. Da kommt ein Log-Teilprozess nicht hinterher. Gefühlt nicht so schlimm.

Hat deine sql-Instanz Loglevel info?

Community Forum

NEWS

History2DB converter

Support us

510

32.4k

81.4k

1.3m