NEWS
History überarbeitet
-
Hi,
das mit der X-Achse ist leider nicht so einfach.
Wenn ich also auf der X-Achse die Zeiten für drei Messpunkte anzeige sehe ich
drei Linien, die Zeitlich NICHT übereinander stehen, die unterschiedlichen Zeiten werden
angezeigt, aber eben nicht zeitlich synchron, sondern verschoben. Die verschobenen Zeiten
werden für jede Linie angezeigt.
Wähle ich nun nur für eine Linie eine einzige Zeitanzeige (X-Achse) und für alle anderen "nichts",
dann wird auch nur genau eine Zeit angezeigt. Die Linien sind aber EXAKT so wie vorher,
also zeitlich NICHT synchron.
Das ganze fällt nicht so auf, wenn der angezeigte Zeitraum recht groß ist und die Messpunkte
häufig kommen. Also eine Anzeige diverser Temperaturen über ein paar Tage ist nahezu
richtig, aber eben nur zufällig.
Bei Anzeigen - bei Rollos oder Ist-Temperaturen gemeinsam mit Soll-Temperaturen, die sich nur selten
ändern - passt das überhaupt nicht zusammen.
Im Bild zeigen die drei schwarzen Pfeile auf Ist-Temperaturen, also alle rund 3 Minuten ein Datenpunkt und
damit recht synchron.
Der rote Pfeil zeigt auf die Soll-Temperatur und hat völlig andere Zeitskala. Damit ist es komplett unmöglich,
etwa die Ändernung der Vorlauf-Ist-Temperatur mit dem Über-/Unterschreiten des Soll-Temperatur und
damit dem Ende/Beginn des Einschalten der Heizung zeitlich zu vergleichen.
Ähnlich sieht das Bild bei Rollos aus, für jede einzelne Linie ist der letzte Datenpunkt an der rechten Grafikseite,
egal ob ein einzelnes Rollo etwa drei Stunden später geschaltet wurde, trotzdem alles senkrecht übereinander,
aber halt zeitlich komplett asynchron.
Gerne würde ich das so sehen, das der rechte Rand der Grafik etwa "jetzt" entspricht oder einer einstellbaren Zeit,
aber bitte dann für ALLE Linien Anfangszeitpunkt und Endzeitpunkt identisch. Ganz besonders gerne noch, wenn
Typ "Linie" dann mit dem letzten echten Messpunkt aufhört, der Typ "Schritte" aber den letzten Punkt bis an jede
beliebige Endezeit waagerecht heranzieht. Denn eine Temperatur ist ja quasi in ständiger Änderung, ein Rollo, was
auf eine Position bewegt wurde, verbleibt ja dort und der Punkt ist ja auch gültig bis zur nächsten Änderung.
nur so ein Wunschgedanke ….
cu
Harvey
964_bild_2.png -
Das problem ist dabei, wenn der letzte Wert ist nie bei allen gleichen Datenpunkten gleich.
Dafür wird vom History-Adapter ein Null-Wert geliefert.
Bei ignoreNull wird dieser aber ignoriert und flot passt die Skala an.
Für den letzten Wert muss man also ignorenull deaktivieren.
Anbei ein Quickfix:
`function readOneChart(id, instance, index, callback) { var option = getStartStop(index); option.instance = instance; socket.emit('getHistory', id, option, function (err, res, step) { if (!err && res) { //for (var i = 0, len = res.length; i < len; i++) { if (config.longestStep < step) { config.longestStep = step; } for (var i = 0; i < res.length; i++) { //quickfix if (res[i].val != null || !config.ignoreNull) { if (res[i].val != null || !config.ignoreNull || i == res.length-1 || i == 0) { // Convert boolean values to numbers if (res[i].val === 'true' || res[i].val === true) { res[i].val = 1; } else if (res[i].val === 'false' || res[i].val === false) { res[i].val = 0; } if (typeof res[i].val == 'string') res[i].val = parseFloat(res[i].val); seriesData[index].push([res[i].ts * 1000, res[i].val]); } } }` anzupassen in /opt/iobroker/node_modules/iobroker.flot/www/index.html Anschließend iobroker upload flot[/i][/i][/i][/i][/i][/i][/i][/i][/i][/i][/i][/i] -
`function readOneChart(id, instance, index, callback) { var option = getStartStop(index); option.instance = instance; socket.emit('getHistory', id, option, function (err, res, step) { if (!err && res) { //for (var i = 0, len = res.length; i < len; i++) { if (config.longestStep < step) { config.longestStep = step; } var lval = null; //qf for (var i = 0; i < res.length; i++) { //qf if (res[i].val != null || !config.ignoreNull) { // Convert boolean values to numbers if (res[i].val === 'true' || res[i].val === true) { res[i].val = 1; } else if (res[i].val === 'false' || res[i].val === false) { res[i].val = 0; } if (typeof res[i].val == 'string') res[i].val = parseFloat(res[i].val); //qf -- start if (res[i].val == null) { if (config.ignoreNull || i == res.length-1) { res[i].val=lval; } } else { lval=res[i].val; } if (res[i].val != null || i == 0 || i == res.length-1) { //qf -- ende seriesData[index].push([res[i].ts * 1000, res[i].val]); } } } // Add first tick with required range // todo muss das sein ?? // seriesData[index] = fillRange(seriesData[index]); if (callback) callback(id, index); }); }` Bei dieser Variante werden nie Null-Werte geschrieben. Wenn man ignore-Null aktiviert werden null-Werte durch den letzten bekannten Wert ersetz. Sieht ab und an besser aus.[/i][/i][/i][/i][/i][/i][/i][/i][/i][/i][/i][/i][/i][/i][/i] -
Schön, warten wir mal ab, wenn bluefox wieder da ist.
Bin mir nicht ganz sicher, ob es die richtige und einzige Stelle ist.
Sinnvoller wäre es am Anfang ein paar Stunden zu weit zu lesen und dann den den an der y-Achse am nächsten Punkt als Start zu nehmen. Am Ende genauso, wenn man nicht grade relative Werte anzeigt.
Wären halt immer pro Linie 2 DB Zugriffe mehr.
-
Bei "statik" scheint die Zeitachse zwar für alle Rollo-Level gleich zu sein, aber mir ist keine Start/Stop Zeit ausgewertet worden. Hier macht eine
absolute Zeitangabe (etwa yy.mm.dd HH:MM:SS) keinen Sinn, da die URL ja als bookmark verwendet werden kann.
Kann jemand was zu den "statik" Start/Stop Zeiten sagen? Oder zu der Aggregation "Anzahl/Sekunden"? zu ""null ignorieren"?
Harvey `
diese Frage stellte ich anderswo auch schon, aber offenbar weis niemand Bescheid.
Was muss bei statik Start/Stop angegeben werden?
Ich hab alles Mögliche ausprobiert. In der URL wird timeArt von relative auf static verändert, allerdings bleiben die Parameter &relativeEnd=now&range=120 bestehen, anschliessend folgen start= und end= , die Grafik aber ändert sich nicht.
-
Hallo Starfish,
vlt. verstehe ich das Problem ja nicht:
http://192.168.1.12:8082/flot/index.htm … D=lineplot&timeArt=static&relativeEnd=now&range=360&live=true&start=2015-11-01&end=2015-12-31&aggregateType=count&aggregateSpan=300&legend=nw&hoverDetail=true&timeFormat=%25H%3A%25M+%25d.%25m&smoothing=0&afterComma=1&useComma=true
Bei mir wird das sauber übernommen. Es werden die Parameter start und end hinzugefügt.
Diese kannst du z.B. in VIS über eine Funktion, Kalender etc. füllen lassen.
In der URL ersetzt du das Datum durch die entsprechenden Variablen in {}.
Siehe dazu z.B. meinen Beitrag um beliebig viele Diagramme anzeigen zu können.
Aggregation = Wieviele Werte sollen benutz werden um das Diagramm zu zeichnen.
Sekunden = 300 -> alle 300 Sekunden ein Stützpunkt
Anzahl = 300 -> 300 Stützpunkte für das Gesamte Diagramm.
Ich würde hier Anzahl empfehlen und ca. Pixelbreite des Diagramms / 2 für Stützpunkte.
Her die gleiche Grafik von oben mit nur 30 Stützstellen:
Zum Tragen kommt das, wenn du z.B. ein Jahr anzeigen läßt und dadurch deutlich mehr Datenpunkte hast als zur Anzeige notwendig/möglich.
"null" ignorieren:
Wenn du z.B. ein Diagramm von 10:00 - 20:00 anzeigen läßt und flot dafür eine bestimmte Anzahl Datenpunkte
abfragt, wird mit "null" geantwortet, wenn es zum Zeitpunkt keinen Messwert gibt.
Deine Heizung stellt sich z.B. um 11:00 auf 22° um 17:00 auf 23° und um 18:00 auf 22.5°
Dann erhälst du ohne "null" ignorieren die Datenpunkte:
10:00 null
11:00 22°
12:00 null
13:00 null
14:00 null
15:00 null
16:00 null
17:00 23°
18:00 22.5°
19:00 null
20:00 null
Deine Linie wird dann bei jeden "null"-Datenpunkt unterbrochen.
Bei "null" ignorieren Werte er nur noch die Punkte ohne null aus und du erhälst eine durchgehende Linie.
-
hallo sissiwup,
Dein screenshot zeigt mir die Darstellung, wie ich sie eigentlich erwarte. Bei statik, start 03.01.2016 ende 04.01.2016 sollten eigentlich genau die 2 Tage gezeichnet werden. Bei mir kommt irgendetwas undefinierbares: start 04.01.2016 und ende jetzt und zwar unabhängig, was ich bei start und ende eintrage.
die url wird im relevanten Abschnitt so generiert: &timeArt=static&relativeEnd=now&range=10080&start=03.01.2016&end=04.01.2016&….
Das sieht doch etwas anders aus, als bei Deinem Beispiel.
edit:
jetzt habe ich das Format Deines roten Abschnitts in meine URL eingesetzt - und siehe da: die Anzeige stimmt.
Weshalb stellt der Flot-adapter hier die URL falsch bzw. anders zusammen?
edit 2:
habs selbst rausgefunden: Browser-Problem. Mit Chrome ist der Spuk vorbei. Kaum zu glauben, dass 2 aktuelle Browser in der jeweils neusten Version solche Unterschiede bewirken. FF ist in diesem Kontext nicht zu gebrauchen. In Chrome sieht das Eingabefeld so aus:
in FF fehlen die up/dwn-Pfeile/dropdown Kalenderauswahl und X - eine Translation ins ISO-Format findet nicht statt. -
Hi,
vielen Dank.
Ich kann die Funktion mit dem Quickfix als etwa ok nennem, das klappt schon ganz gut.
Da "Statik" wohl nicht mit Firefox geht - schade, aber aktuell halt nicht zuändern. Merkwürdig schon!
Die Grafiken mit vielen Datenpunkten sehen schon sehr gut aus.
Etwas problematisher sind die mit wenigen Daten, und dann noch fehlerhaft: die Rolos :-(
gehen Morgens hoch und abends runter, eigentlich einfach, ich erwarte eine Linie mit
senkrechten und waagerechten Linien. Das klappt nur inder Einstellung "Chart Type=Schritte", also
eine Fläche kann ich nicht anzeigen.
Und noch schlimmer: Während das Rollo in Wirklichkeit zwischen 100% und 17% hin- und herwandert
grätscht da rega mit 0.17% rein, da bei rpc der Rollanden zwischen 0-100%, bei rega aber zwischen
0-1 läuft. So die Tabelle:
…
17 true hm-rpc.0 2016-01-05 17:16:21
100 true hm-rpc.0 2016-01-05 07:00:24
17 true hm-rpc.0 2016-01-05 07:00:02
0.17 true hm-rega.0 2016-01-04 22:26:10
17 true hm-rpc.0 2016-01-04 17:15:22
100 true hm-rpc.0 2016-01-04 07:00:24
17 true hm-rpc.0 2016-01-04 07:00:02
Richtig ist (von unten gelesen), dass um 07:00:02 Das Rollo von 17% auf 100% hochgeht, und um 17:15 wieder auf 17% runter.
Die fehlerhaften rega Einträge zerstören die Grafik komplett, da von 17% anstatt auf 100% sogar nach unten auf rega-wert "0.17"
die Linie gezeichnet wird.
Und das kann nichts mit firefox zu tun haben :-)
Also irgendwie müssten bei rega-basierter History nur rega-Werte, bei rpc-History nur rpc-Werte berücksichtigt werden?!?
-
zu static/start/stop sehe ich folgendes:
Es stehen immer alle werte in der URL drin,
z.B. timeArt=relative&relativeEnd=now&range=4320&start=01.01.2016&end=03.01.2016
dabei gehören zur "timeArt=static"
die Werte "start=01.01.2016" und "end=03.01.2016"
und zu "timeArt=relative"
die Werte "relativeEnd=now" und "range=4320". Die range ist dabei in Minuten, also im Beispiel
3 Tage = 2 *24 * 60 = 4320 Minuten.
Die Flot/index.html wertet nur die richtigen Werte abhängig von "timeArt=static/relativ" aus und ignioriert die anderen.
if (config.timeArt == 'static') { start = Math.round(new Date(config.start).setHours(0) / 1000) - (config.lines[index].offset || 0); end = Math.round(new Date(config.end).setHours(24) / 1000) - (config.lines[index].offset || 0) } else { if (config.relativeEnd == 'now') { end = Math.round(new Date() / 1000) - (config.lines[index].offset || 0); start = end - (config.range * 60); ... } }Problematisch wird es nun wohl, da einige Systeme in Sekunden rechnen, andere in Millisekunden.
Dadurch ist der Aufruf````
Date(config.start).setHours(0) / 1000dem einen oder anderen einfach Unsinn. Wenn mir jemand hilft, wie man in dieser index.html den Wert z.B. der Variable "end= …" am einfachsten etwa in iobroker-2016...log schreiben kann gebe ich gerne mehr Unterstützung. Eventuell kann man ja den CPU-Typ? oder die Zeit "now()" abfragen und erkennem, ob man auf einem 1Sekunden oder 1000Millisekunden System arbeitet. edit: Unfug, das Zeitformat ist bei mir "2016-01-01" und nicht "01.01.2016" :-((( Ok, zu den Zeiten habe ich was rausgefunden: wenn ich "static" eingebe und start="2016-01-01" end="2016-01-06" bekomme ich richtig die Grafik von start-end. Ist also abhängig vom Datumsformat? Dabei ist bei "start" der Tagesanfang = 00:00:00 Uhr gemeint, bei "end" das Tagesende des angegebenen Tages, also ****00:00:00: des folgendes Tages**** Klappt auch mit Firefox :-)))) Hinweis zum debuggen: flot mit einem Wert, dann in der Logdatei "socketio.0 sendTo "getHistory"" suchen, da sind die ausgerechneten "start/end" Zeiten in unixtime enthalten. Kleinere Anzeige als 24 Stunden geht nicht, da in der Funktion (siehe code Schnippsel) bei "start" die 0\. Stunde, bei "end" die 24\. Stunde verwendet wird. gerade so beim Testen: Der Datumswechsel, also die Linie in flot mit dem Datum scheint die 01:00 Stunde zu sein. Bei "2 Tage" ist die Spalte von "21:00:00" bis "05.01.2016" genausobreit wie von "05.01.2016" bis "05:00:00" -
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
321
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge