History2DB converter

GerdSo

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?

moebius

Als ich mit iobroker angefangen hab, hat bei mir die Übernahme von history nach sql auch nicht geklappt.

Hab dann mit diesem flow improvisiert. Man muss vorher schon den sql adapter einschalten, damit er

die DP's anlegt.

! [
! {
! "id": "361523f4.0693fc",
! "type": "tab",
! "label": "Sql import historic data"
! },
! {
! "id": "54117af8.894304",
! "type": "file in",
! "z": "361523f4.0693fc",
! "name": "",
! "filename": "/opt/iobroker/iobroker-data/history/20170106/history.admin.0.ws333.Temp3.json",
! "format": "utf8",
! "x": 459,
! "y": 95,
! "wires": [
! [
! "ade70e93.59ded"
! ]
! ]
! },
! {
! "id": "42a18a7e.9e2744",
! "type": "debug",
! "z": "361523f4.0693fc",
! "name": "",
! "active": true,
! "console": "false",
! "complete": "true",
! "x": 1240,
! "y": 331,
! "wires": []
! },
! {
! "id": "ade70e93.59ded",
! "type": "json",
! "z": "361523f4.0693fc",
! "name": "",
! "x": 818,
! "y": 171,
! "wires": [
! [
! "2005b14d.5c492e"
! ]
! ]
! },
! {
! "id": "2005b14d.5c492e",
! "type": "function",
! "z": "361523f4.0693fc",
! "name": "Add timestamp",
! "func": "//var dp = msg.filename.match(/[-\w]+[.][\w]+$/i)[0]\nvar dp = msg.filename.match(/^.\/(.)\.(.*)$/i)[1]\n\nvar ma = []\n\nfor (i=0; i<msg.payload.length; ++i)/{\n/ma.push({topic:"insert/into/ts_number/set/id="(select" id/from/iobroker.datapoints/where/type="0" and/name=""+ dp +"" )/,/ts=""" +/msg.payload<i="">~~[i]~~.ts + ",val=" + msg.payload__.val + ",ack=0,_from=2,q=" + msg.payload__.q, payload: ""})\n ma.push({topic:"insert into ts_string set id=(select id from iobroker.datapoints where type = 1 and name = '"+ dp +"') , ts=" + msg.payload__.ts + ",val=" + msg.payload__.val + ",ack=0,_from=2,q=" + msg.payload__.q, payload: ""})\n ma.push({topic:"insert into ts_bool set id=(select id from iobroker.datapoints where type = 2 and name = '"+ dp +"') , ts=" + msg.payload__.ts + ",val=" + msg.payload__.val + ",ack=0,_from=2,q=" + msg.payload__.q, payload: ""})\n}\nreturn [ma];",
! "outputs": "1",
! "noerr": 0,
! "x": 962,
! "y": 223,
! "wires": [
! [
! "6d4c858b.8562cc"
! ]
! ]
! },
! {
! "id": "6d4c858b.8562cc",
! "type": "mysql",
! "z": "361523f4.0693fc",
! "mydb": "c5d28ccd.2882a",
! "name": "",
! "x": 1102,
! "y": 286,
! "wires": [
! [
! "42a18a7e.9e2744"
! ]
! ]
! },
! {
! "id": "8b3dd54e.fdff98",
! "type": "inject",
! "z": "361523f4.0693fc",
! "name": "",
! "topic": "",
! "payload": "",
! "payloadType": "date",
! "repeat": "",
! "crontab": "",
! "once": false,
! "x": 93,
! "y": 36,
! "wires": [
! [
! "54117af8.894304"
! ]
! ]
! },
! {
! "id": "c5d28ccd.2882a",
! "type": "MySQLdatabase",
! "z": "",
! "host": "big",
! "port": "3306",
! "db": "iobroker",
! "tz": ""
! }
! ]_______________</msg.payload.length;> 1803_clipboard05.jpg

GerdSo

~~@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? `

Ja, hatte Loglevel Info. Ich habe Dir gerade per PN das Logging mit Level Debug zugesendet, vielleicht kannst Du damit mehr anfangen.

Ich habe mal in der sql-DB nachgesehen und die kennt ca. 500 Datenpunkte die auch vom Namen her gut aussehen, d.h. sehen so aus wie in admin bzw. die history-Dateinamen

GerdSo

~~@moebius:~~

Als ich mit iobroker angefangen hab, hat bei mir die Übernahme von history nach sql auch nicht geklappt.

Hab dann mit diesem flow improvisiert. Man muss vorher schon den sql adapter einschalten, damit er

die DP's anlegt. `
Was macht man mit den Infos im spoiler text? Wo muss ich das importieren?

moebius

~~@GerdSo:~~

Wo muss ich das importieren? ` im adapter node-red. Wenn du 500 DP's importieren willst, muss man noch 2 nodes dranmachen um über das Verzeichnis zu wandern.

GerdSo

~~@GerdSo:~~

~~@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? `

Ja, hatte Loglevel Info. Ich habe Dir gerade per PN das Logging mit Level Debug zugesendet, vielleicht kannst Du damit mehr anfangen.

Ich habe mal in der sql-DB nachgesehen und die kennt ca. 500 Datenpunkte die auch vom Namen her gut aussehen, d.h. sehen so aus wie in admin bzw. die history-Dateinamen `

Hallo apollon77, danke für die Rückmeldung per PN. Deine neue Version 1.4.5 erzeugt jetzt vernünftige Ergebnisse bei analyze.js. Allerdings scheint die Übertragung mit history2db.js weiterhin nicht zu laufen:

c:\Program Files\ioBroker\node_modules\iobroker.history\converter>node history2db.js sql.0 debug
Send Data to sql.0
Use historyDir c:\Program Files\ioBroker\iobroker-data\history-data
2017-02-18 20:46:28.224  - debug: history.0 objectDB connected
2017-02-18 20:46:28.255  - debug: history.0 statesDB connected
2017-02-18 20:46:28.333  - info: history.0 starting. Version 1.5.2 in c:/Program Files/ioBroker/node_modules/iobroker.history, node: v4.6.2
EarliesDBValues initialized from cache 667
ExistingDBTypes initialized from cache 720
started processFiles with 667 known db values
We start earliest at 20170218
DONE

apollon77

Da fehlen Parameter! Da muss noch Das Datum und vor allem der Pfad dran!

node history2db.js sql.0 debug 20170218<pfad></pfad>

GerdSo

~~@apollon77:~~

Da fehlen Parameter! Da muss noch Das Datum und vor allem der Pfad dran!

node history2db.js sql.0 debug 20170218<pfad></pfad> `

Hi, stimmt. Derzeit ist er beim Übertragen und es sieht gut aus. Dauert noch etwas, da er etwas über 10 Monate übertragen muss. Danke für Deine Hilfe!

GerdSo

Gibt doch noch Probleme. iobroker.log meldet dauernd Fehler:

sql.0	2017-02-18 22:49:53.292	error	sql.0 Error: ER_CON_COUNT_ERROR: Too many connections
sql.0	2017-02-18 22:49:53.292	error	sql.0 Error: ER_CON_COUNT_ERROR: Too many connections
sql.0	2017-02-18 22:49:53.292	error	sql.0 Error: ER_CON_COUNT_ERROR: Too many connections
sql.0	2017-02-18 22:49:53.292	error	sql.0 Error: ER_CON_COUNT_ERROR: Too many connections
sql.0	2017-02-18 22:49:53.292	error	sql.0 Error: ER_CON_COUNT_ERROR: Too many connections
sql.0	2017-02-18 22:49:52.636	error	sql.0 Cannot insert INSERT INTO `iobroker`.ts_bool (id, ts, val, ack, _from, q) VALUES(547, 2017001, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '547-2017001' for key 'PRIMARY'
sql.0	2017-02-18 22:49:52.636	error	sql.0 Cannot insert INSERT INTO `iobroker`.ts_bool (id, ts, val, ack, _from, q) VALUES(547, 2017000, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '547-2017000' for key 'PRIMARY'
sql.0	2017-02-18 22:49:52.261	error	sql.0 Cannot insert INSERT INTO `iobroker`.ts_bool (id, ts, val, ack, _from, q) VALUES(529, 2017001, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '529-2017001' for key 'PRIMARY'
sql.0	2017-02-18 22:49:52.261	error	sql.0 Cannot insert INSERT INTO `iobroker`.ts_bool (id, ts, val, ack, _from, q) VALUES(529, 2017000, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '529-2017000' for key 'PRIMARY'
sql.0	2017-02-18 22:49:51.917	error	sql.0 Cannot insert INSERT INTO `iobroker`.ts_bool (id, ts, val, ack, _from, q) VALUES(545, 2017001, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '545-2017001' for key 'PRIMARY'
sql.0	2017-02-18 22:49:51.917	error	sql.0 Cannot insert INSERT INTO `iobroker`.ts_bool (id, ts, val, ack, _from, q) VALUES(545, 2017000, false, 1, 3, 0);: Error: ER_DUP_ENTRY: Duplicate entry '545-2017000' for key 'PRIMARY'

apollon77

Kleiner Tipp,

beobachte mal die iobroker logs.

Wenn Du während der Übertragung zu viele von diesen "Log missing"-meldungen oder andere Fehler bekommst dann abbrechen ("x" drücken!! dann bricht er am Tagesende ab). Dann einen Parameter anfügen. Mit dem Delay-Multiplikator kannst Du die geschwindigkeit/Wratezeiten "tunen". Wenn zuviele Meldungen kommen ist z.B. 2 ein um Faktor 2 höherer Delay … das hilft vllt

Die "duplicate entry" kommen bei speziellen "ALARM"-Datenpunkten ... da werden manchmal falsche Timestamps generiert ... die kannst Du ignorieren wenn Sie so aussehen wie in deiner Meldung

Dann viel Spass und Danke für Diene geduld und Unterstützung beim Bugfixing

GerdSo

~~@apollon77:~~

Kleiner Tipp,

beobachte mal die iobroker logs.

Wenn Du während der Übertragung zu viele von diesen "Log missing"-meldungen oder andere Fehler bekommst dann abbrechen ("x" drücken!! dann bricht er am Tagesende ab). Dann einen Parameter anfügen. Mit dem Delay-Multiplikator kannst Du die geschwindigkeit/Wratezeiten "tunen". Wenn zuviele Meldungen kommen ist z.B. 2 ein um Faktor 2 höherer Delay … das hilft vllt

Die "duplicate entry" kommen bei speziellen "ALARM"-Datenpunkten ... da werden manchmal falsche Timestamps generiert ... die kannst Du ignorieren wenn Sie so aussehen wie in deiner Meldung

Dann viel Spass und Danke für Diene geduld und Unterstützung beim Bugfixing `

Habe es abgebrochen und neugestartet mit der 2 hinter dem Pfad und er hat erneut versucht Alarme einzulesen und den Rest hat er übersprungen. Während dessen kamen weiterhin die duplicate entry Einträge, stimmt also mit Deiner Vermutung überein.

Die Connection-Fehlermeldung kommt jetzt nicht mehr.

eastcoast

Hallo,

gibt es eigentlich auch eine Möglichkeit eine bestehende ioBroker "SQL History" in eine "Influx DB" History zu übertragen?

apollon77

Aktuell nicht. Ein weg wäre irgendwie aus SQL-Daten wieder JS-Files zu erzeugen, dann geht der Converter von hier … aber ob das sinnvoll ist weiss ich nicht.

Einfacher wohl eher die Daten über kluge queries als csv oder so aus sql rauszuholen (also ohne ioBroker, sondern direkt mit SQL-Tools/Kommandozeile oder so). Dann ein bissl Texteditor Magie oder ein kleines Skriptchen was das diekt in die Influxdb pumpt.

Wie fit bist Du mit sowas?

NEWS

History2DB converter

Support us

1.3k
Online

30.6k
Users

77.2k
Topics

1.2m
Posts

NEWS

History2DB converter

Support us

1.3kOnline

30.6kUsers

77.2kTopics

1.2mPosts

1.3k
Online

30.6k
Users

77.2k
Topics

1.2m
Posts