NEWS
History2DB converter
-
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```` {}
-
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>
-
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>
-
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?
-
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 setid
=(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 setid
=(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 -
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
-
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? -
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.
-
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
-
Da fehlen Parameter! Da muss noch Das Datum und vor allem der Pfad dran!
node history2db.js sql.0 debug 20170218<pfad></pfad>
-
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!
-
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'
-
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
-
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.
-
Hallo,
gibt es eigentlich auch eine Möglichkeit eine bestehende ioBroker "SQL History" in eine "Influx DB" History zu übertragen?
-
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?
-
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? `
So etwas in der Art hatte ich mir vorgestellt, leider habe ich im moment kein Zeit mich darin einzuarbeiten.Hätte gehofft ist gibt schon etwas fertiges… trozdem Danke für die Antwort.
-
Hallo zusammen,
ich versuche gerade meine history in influxdb zu konvertieren ..klappt aber leider nicht gleicher Fehler bei analyze script und history2db script
nodejs history2db.js influxdb.0 debug 0 /home/history --processAllDPs --simulate module.js:550 throw err; ^ Error: Cannot find module '/opt/history2db/ioBroker.history/converter/../lib/utils' at Function.Module._resolveFilename (module.js:548:15) at Function.Module._load (module.js:475:25) at Module.require (module.js:597:17) at require (internal/module.js:11:18) at Object.<anonymous> (/opt/history2db/ioBroker.history/converter/history2db.js:9:14) at Module._compile (module.js:653:30) at Object.Module._extensions..js (module.js:664:10) at Module.load (module.js:566:32) at tryModuleLoad (module.js:506:12) at Function.Module._load (module.js:498:3)
Ich befürchte mir fehlt da was aber was?
Hängt es an dem .../lib/utils am Ende der Error Zeile?
Hab einfach das ioBroker.history git geclont da müsste ja alles mitgekommen sein was ich brauche oder?Irgendjemand eine Idee?
Für jede Hilfe dankbar
Stefan -
@stefan sagte in History2DB converter:
/opt/history2db/ioBroker.history/converter/../lib/utils
da ist doch verkehrt.. von wo rufst du das Script auf
-
Hmm aus dem Verzeichnis wo ich das git hingeklont hab ...
Muss es aus dem iobroker installationsverzeichnis aufgerufen werden?