NEWS
History überarbeitet
-
Hi,
es bleibt alles schwierig :-(
-
Unterschiede rpc und rega bei Rollos (und Dimmer?) (0-100 <-> 0.00 - 1.00) sind nervig, da damit kein informativer Graph gezeichnet werden kann
-
Memory steigt steil an und bringt iobroker nach wenigen Stunden zum Abbruch (bananapi 1GB, ~40 Messpunkte - nur Änderung, mysql)
-
rega-Werte werden nur manchmal in die mysql-db geschrieben,
-
wenn sql.0 neu gestartet.
-
wenn kein Haken bei "nur Änderung" dann alle 30 Sekunden identische Werte (will ich nicht, da nur selten Änderungen, aber eigentlich ok)
-
garnicht, wenn Haken gesetzt. Werte werden aber von rega geholt, ich sehe neue, geänderte Werte bei der "Zustände" Anzeige.
Ich habe alles neu (sql-history neu) aufgesetzt, nur mysql-db aktiv, aber keine Verbesserung.
So sieht das Log aus, es geht um diese Werte:
hm-rega.0 2016-01-12 21:19:11 debug hm-rega.0 stateChange hm-rega.0.8023 {"val":-41.5,"ack":true,"ts":1452629952,"q":0,"from":"system.adapter.hm-rega.0","lc":1452629700}
hm-rega.0 2016-01-12 21:19:11 debug inMem message hm-rega.0.* hm-rega.0.8023
Aber ich sehe keinerlei Inserts into mysql-db:
sql.0 2016-01-12 21:23:12 debug inMem message * hm-rega.0.8023
aber andere Inserts gehen:
sql.0 2016-01-12 21:25:09 debug sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(17, 1452630300000, 45.12, 1, 4, 0);
(id=17 ist übrigens system.adapter.sql.0.memRss)
2016-01-12 21:21:58.821 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(24, 1452630109000, 20.1, 1, 1, 0);
2016-01-12 21:31:50.528 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(24, 1452630701000, 20.2, 1, 1, 0);
(die id=24 ist die actual_temperature eines Raumthermostaten, dessen Temperatur sich geändert hat. Hier ist also der nicht gesetzte Haken "nur Änderungen"
korrekt berücksichtigt worden)
Und insert geht auch mit ID=10, das ist der rega.8023 Wert von oben - dies geht aber NUR ohne Haken "nur bei Änderung", und dann alle 30 Sekunden:
2016-01-12 21:29:22.091 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(10, 1452630552000, -41.5, 1, 3, 0);
Also fast so, als wäre die Bedeutung von "Aktiviert" und "nur Änderungen aufzeichnen" von der Bedeutung beides "Aktivieren AN/AUS", aber nur bei rega ?????
-
-
hi @ bluefox,
ich glaub, ich habe was in sql/main.js gefunden, und zwar in der Zeile
if (sqlDPs[id].state && settings.changesOnly && (state.ts !== state.lc)) return;Kurz der Hintergrund:
ein HM-Programm berechnet alle 15 Minuten den Sonnenstand - bekanntes Script.
Nur Änderungen sollen übernommen werden.
Allerdings ist es so, dass die letzte Änderung (state.lc) der Zeitpunkt des Programmablaufes ist, der Timestamp /state.ts) aber der Zeitpunkt des Abholens der Daten.
Diese sind aber nicht exakt gleich, also "returned" die Codezeile immer.
308.2 true hm-rega.0 2016-01-12 22:28:13 2016-01-12 22:15:00 ... 308.2 true hm-rega.0 2016-01-12 22:29:43 2016-01-12 22:15:00Das ist die Wiederholung des "alten" Wertes, also keine Eintragungen in die Datenbank - ok.
313.1 true hm-rega.0 2016-01-12 22:30:13 2016-01-12 22:30:00Denn dies ist der erste Eintrag mit dem neuen Wert, also hätte eigentlich dieser Wert in die Datenbank geschrieben werden müssen!
Besser ist wohl als Erkennung, dass die Zeit "annähernd" gleich ist. Da standardmäßig rega alle 30 Sekunden geholt wird sollte
ein Abstand <= 30 Sekunden (genau der Wert des zeitlichen Abstands ders rega-Pollings) wohl als "identisch" gelten, also der neue Wert in die Datenbank eingetragen werden.
Ohne Entwicklungslandschaft kenne ich den state.ts/state.lc Wert nicht. Ist es die unixtime können beide /30 geteilt werden, dann gilt wieder !==.
Oder Differenz bilden und bei "time_diff(state.ts - state.lc)" < "rega_polling_time_sec" den sql-insert auslösen.
cu
-
Noch was Doku zu dem rpc <-> rega Werten.
2016-01-12 22:57:24.599 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(29, 1452635835000, 10, 1, 1, 0);
2016-01-12 22:59:19.428 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(29, 1452635946000, 0.1, 1, 3, 0);
2016-01-12 23:00:16.704 - debug: sql.0 INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(29, 1452636007000, 7.000000000000001, 1, 1, 0);
die erste Zeile entsteht, wenn ich das Rollo manuell bewege.
Die zweite Zeile ist nach der Restart des rega-Adapters, die dritte Zeile wieder eine manuelle Bewegung.
Daher die "10" aus rpc (3. Spalte=1=rpc), die "0.1" aus rega (3. Spalte=3=rega), die "7.00000000000001" wieder aus rpc (3.Spalte=1=rpc).
Der "doppelte" Eintrag (erste und zweite Zeile) sind durchaus ein "feature", kommen ja von unterschiedlichen Quellen.
Aber der unterschiedliche Wertebereich der beiden Quellen muss zwingend normalisiert werden, damit die Werte dargestellt werden können.
cu
-
Fehlerbeseitigung bei sql-history!!!
ich konnte mit etwas basteln den Fehler beseitigen, dass Wertänderungen ignoriert (nicht in die sql-db geschrieben) wurden, deren
Änderungszeitstempel vom Zeitstempel des Auslesens abweicht.
Zu theoretisch? Hier mein konkretes Beispiel:
Das bekannte Skript zur Berechnung des Sonnenstandes von funkturm läuft auf der CCU2 und erzeugt - wichtig - alle 15 Minuten
geänderte Werte in den Variablen "sonne_elevation" und "sonne_azimut". Diese Werte möchte ich in einer Grafik anzeigen und erwarte
zwei Sinuskurven.
Ich wurde enttäuscht, da nur selten mal ein Punkt überhaupt in der History (mit SQL-Adapter!) landet :-(
Ich fand heraus, das die Werte korrekt von der CCU ausgelesen werden, im iobroker.Zustand tauchen sie auf. Und dort fand ich auch meinen
Ansatzpunkt: die Zeiten "Zeit" und "Geändert" waren nie identisch. Unter "Geändert" steht der Zeitpunkt, wann das Script gelaufen war,
unter "Zeit" der Zeitpunkt, wann die Daten vom rega-Adapter von der CCU gelesen wurden.
In /opt/iobroker/node_modules/iobroker.sql/main.js hatte ich in der Funktion pushHistory(id, state) gesehen, dass
in der Zeile 904 bei geseztem Flag "nur bei Änderung" KEIN Eintrag in die sql-db stattfindet, wenn diese beiden Zeitstempel ungleich sind.
Bei mir waren die Zeiten aber nie gleich, die Zeitdifferenz lief von 18 Sekunden bis 888 Sekunden hoch um alle 15 Minuten wieder mit
18 Sekunden zu beginnen. Die 18 Sekunden sind reiner Zufall von Starten des iobrokers.
Lösung:
In der Funktion pushHistory(id, state) rund Zeile 904 diese
eine Zeile ändern (das Original steht noch als Kommentar drin):
// if (sqlDPs[id].state && settings.changesOnly && (state.ts !== state.lc)) return; if (sqlDPs[id].state && settings.changesOnly && ((state.ts - state.lc) >= 30)) return;Und schon werden meine Variableninhalte übernommen, wenn die Zeiten sich um weniger als 30 Sekunden unterscheiden, also genau alle 15 Minuten einmal,
da sich die Werte nur und genau alle 15 Minuten durch die Ablauf des Scriptes dann geändert haben.
Jetzt klappts auch mit dem Sinus des Sonnenstandes!
Damit ist ein Punkt meiner Probleme gelöst.
Bleibt der Punkt mit den unterschiedlichen Werten der Rollos aus hm-rpc (0-100) und hm-rega (0.00 - 1.00) - vielleicht kann da jemand helfen?
-
Moin,
ich hab gestern mal testweise das SQL Logging aktiviert. MySQL liegt nicht mit auf dem Cubietruck, sondern auf einem BananaPI in meinem Netzwerk.
Die Verbindung klappt erstmal problemlos. Ich hatte in einer alten Installation einige Werte über den history Adapter geloggt. Den musste ich wegen Speicherknappheit auf dem vorherigen Raspi2 deaktivierten. Ich hatte bloß den Adapter deaktiviert und anscheinend nicht das Logging aus den Datenpunkten entfernt. Nachdem mein ioBroker auf den Cubie (gleicher Hostname, gleiche IP) umgezogen ist (welcher mit 2GB mehr Speicher hat, aber anscheinend mangels CPU Kernen langsamer ist), habe ich den sql Adapter aktiviert.
Neue Datenpunkte werden auf den ersten Blick korrekt geloggt. Aber die Datenpunkte, welche schonmal vorher für history aktiviert waren, werden nicht geloggt. Entweder schliesst sich das Fenster beim Klick auf Speichern nicht, oder es schliesst sich und das logging erfolgt nicht.
Ich habe die Vermutung, das vorher in der DB nachgeschaut wird, ob Daten da sind. Da sie es nicht sind wird das ganze anscheinend ignoriert.
Hier mal ein Auszug aus dem Log (ich wollte den Datenpunkt POWER loggen, welcher vorher schonmal für history aktiviert war):
sql-0 2016-01-15 09:03:18 info sendTo "getHistory" to system.adapter.admin.0 from system.adapter.sql.0: {"step":null,"error":null} sql-0 2016-01-15 09:03:18 info No Data inMem 2016-01-15 09:03:18 debug message messagebox.system.adapter.sql.0 messagebox.system.adapter.sql.0 command=getHistory, id=hm-rpc.1.MEQ00XXXX.1.POWER, end=1452845008, count=50, instance=sql.0, from=true, ack=true, q=true, use admin-0 2016-01-15 09:03:18 info sendTo "getHistory" to system.adapter.sql.0 from system.adapter.admin.0: {"id":"hm-rpc.1.MEQ00XXXX.1.POWER","options":{"end":1452845008,"count":50,"instance":"sql.0","from":true,"ack":true,"q":true,Gruss Marco
-
Moin,
ich versuche gerade mein History auf PostgreSQL umzustellen.
Ich erhalte jedoch folgenden Fehler beim Schreiben von Ereignissen in die Tabelle "datapoints".
"Cannot insert INSERT INTO datapoints (name, type) VALUES('hm-rpc.0.KEQ1111111.1.TEMPERATURE', 0);: error: null value in column "id" violates not-null constraint"
Bisher bin ich davon ausgegangen, dass meine Einstellungen korrekt sind, allerdings kennt meine PostgreSQL Version v.9.3.4 noch keine Einstellung für "IDENTITY(1,1)". Hat das ggf. Einfluss auf die Adressierung der Tabelle(n)? Mein PostgreSQL läuft übrigens auf einem "Thecus NAS N4800eco"
Freue mich über Tipps und Unterstützung 8-)
Sofern weitere Infos?Details(Screenshots benötigt werden, liefere ich gern nach.
1917_sql_log.jpg
1917_postgresdatapointstabelle.jpg -
Hi,
hast DU die Logs noch vom ersten Start der SQL Instanz?
Da sollten die Tabellen angelegt worden sein. Postgres an sich mit:
CREATE TABLE datapoints (id SERIAL NOT NULL PRIMARY KEY, name TEXT, type INTEGER);
Das "SERIAL" ist ein Auto-Increment … dann sollte das an sich nicht passieren.
Kannst Du ggf die Tabelle mal bitte löschen und mit oben genannter Query neu anlegen. Klappt es dann?
Schau mal in sources, sollte ähnlich angelegt sein:
CREATE TABLE sources (id SERIAL NOT NULL PRIMARY KEY, name TEXT);
-
Warum denn das?
Der Adapter macht das beim ersten Start selbst :-)
Dann prüfe bitte alle Tabellen. Die "originalen" Queries zum Anlegen findest du unter:
https://github.com/ioBroker/ioBroker.sq … esql.js#L3 . die 5 CREATE TABLE Statements
-
Hallo appolon77,
zunächst die Frage ob ich etwas falsch mache?
Ich wollte den Befehl gemäß Screenshot ausführen und erhalte den ebenfalls angefühten Fehler.
(bitte ignoriere, dass die Tabelle "datapoints" noch da ist, der Fehler kommt auch wenn die Tabelle zuvor gelsöcht wurde).
1917_sql-befehlausf_hren.jpg
1917_sql-codefehler.jpg -
Warum denn das?
Der Adapter macht das beim ersten Start selbst :-) `
Das wußte ich da ja noch nicht :-)Ich hatte erst mit dem Verbindungsaufbau zu kämpfen, bis ich einen Hinweis fand, dass ich den externen Zugriff auf PostgreSQL erst in den Config -Dateien erlauben muss 8-)
Ich glaube du birngst mich aber auf den richtigen Weg.
Gemäß Beschreibung sind die ID`s der Tabellen "sources" und "datapoints" "Integer", ud so habe ich diese angelegt.
Laut Script legst Du diese allerdings als "Serial" an, und dadurch bekommt die Tabelle wohl erst den "Zähle"r?!
Nachtrag:
Vielleicht kann man in der Beschreibung "SERIAL" statt "Integer" schreiben?
1917_sql_beschreibung.jpg -
Zu oben: versuch mal das "Ergebnisse Seitenweise" nicht anzuhaken. Ich denke das die Erwarteung von myPgAdmin ist das dort ergebnisse zurückkommen und daher will er rausfinden wieviele. Macht natürlich hier keinen Sinn ;-)
Ansonsten brauchst Du einen Weg für solche Queries. Da kenn ich mich nicht aus.
DIe "Doku" der Tabellenstrukturen ist DB-Übergreifend in der README dargestellt. Jede DB will das anders haben. Aber ja "SERIAL" bei PostgreSQL mach einen Autoincrement counter und dann kann "id" bei der echten Insert-Query weggelassen werden
-
Ich habe in der Zwischenzeit die Tabellen neu manuell angelegt und konnte aufgrund deines Verweises zu den Queries ebenfalls erkennen, das in den "ts_" Tabellen jeweils die Kombination aus "id" und "ts" den PrimaryKay ausmachen.
und was soll ich sagen - nun laufen die Werte auch die Tabelle … jipppiiihhh 8-)
Vielen Dank für deine Hilfe!
Anmerkung
Sollte sonst noch jemand die Anbindung mit PostgreSQL umsetzen, folgende Konfigurations-Anpassungen habe ich für den Zugriff vorgenommen:
Datei: postgresql.conf
alt:````
#listen_addresses = 'localhost'neu:```` listen_addresses = '*'Datei: ph_hba_conf
folgende Zeilen habe ich am Ende angefügt:
host all all 0.0.0.0/0 md5 host all all ::/0 md5
606
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge