Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[harvey637]

Hi,

habe auch gleich einen Workaround, siehe am Ende. Erstmal das Problem:

Eine Variable wird von einem Script auf der CCU2 gesetzt.

Sie soll mit dem sql-Adapter geloggt werden, und zwar "nur bei Änderung".

wird sie aber nicht :-(

Hier der Grund:

Die Auswertung des Flags "nur bei Änderung" wertet nicht die inhaltliche Änderung des Wertes (.val) aus, sondern

prüft, ob der Zeitpunkt des Timestamps (.ts) identisch mit dem Zeitpunkt der letzten Änderung (.lc) ist.

Timestamp (.ts) ist dabei Zeitpunkt der Datenabholung, also rund alle 30 Sekunden.

Wenn also die Variable auf der CCU2 irgendwann innerhalb der letzten 30 Sekunden geändert wurde

wird die Änderung nicht in die sql-Datenbank übernommen.

So sieht dies in etwa Zeile 1009 in node_modules/iobroker.sql/main.js im Original aus:

if (sqlDPs[id].state && settings.changesOnly && (state.ts !== state.lc)) return;

Also return (und nicht in sql speichern) wenn state.ts ungleich state.lc ist.

Wenn die Variable also nicht exakt zum Abholezeitpunkt geändert wurde wird sie auch bei "nur bei Änderung" gar

nicht geschrieben.

Workaround (zur Info: ich arbeite mit Versionen, wo der Zeitstempel in Millisekunden ist):

Prüfen, ob die letzte Änderung innerhalb der letzten 30000 Millisekunden war. Damit wird die oben erwähnte Zeile zu:

if (sqlDPs[id].state && settings.changesOnly && ((state.ts - state.lc) > 30000)) return;

Achtung, damit dies korrekt ist muss auch hm-rega auf ms geändert werden in Zeile 1136 node_modules/iobroker.hm-rega/hm-rega.js:

var ts = Math.floor((new Date(data[id][1])).getTime());

(Math.Floor ist jetzt eigentlich nicht mehr notwendig)

Problem dieses Workarounds ist und bleibt, dass die Beschreibung "nur bei Änderung" etwas irreführend ist. Es geht nicht um

Änderung des Wertes, sondern nur um den Zeitpunkt, den die CCU2 beim schreiben des Wertes setzt, unabhängig davon, ob es eine

Werteänderung ist oder der alte Wert nur erneut geschrieben wird. So werden leider identische Werte, die zeitgesteuert

immer wieder geschrieben werden obwohl sie sich nicht geändert haben, trotzdem in die Datenbank geschrieben.

Die optimale Lösung wäre wohl, der Erwartung, dass nur Werte-Änderungen in die Datenbank geschrieben werden, durch lesen

des bisherigen Wertes und Vergleich mit dem jetzt geliefertem Wert aus Entscheidung für das Schreiben/Nicht_Schreiben zu entsprechen.

Ist natürlich eine Datenbankabfrage und damit teuerer als ein einfacher numerischer Vergleich von state.ts und state.lc, sehe ich ein.

cu

Harvey

[Homoran]

@harvey637:

Eine Variable wird von einem Script auf der CCU2 gesetzt.

Sie soll mit dem sql-Adapter geloggt werden, und zwar "nur bei Änderung".

wird sie aber nicht :-( `

DANKE!

Sitze seit Stunden gerade auch daran :(

Funktioniert aber auch nicht mit History.

Solange ich das Fenster des History Datenpunktes aufhabe, wird dort auch hineingeschrieben.

mit flot oder rickshaw sehe ich aber immer nur den ersten Wert.

Nach schließen des Fensters sind ebenfalls wieder alle Werte - bis auf den ersten weg.

Ich habe noch keine Lösung gefunden.

Gruß

Rainer

[harvey637]

Hi,

ich verstehe die Anzeige beim Setzen des Loggings (für sql/history/…) auch nicht.

Also konkret, wo die Werte in dem Tab "Tabelle" herkommen.

Es sind definitiv nicht die Werte aus der Datenbank!.

Das habe ich konkret geprüft. Wenn ich mit sql-Befehlen aus der Datenbank direkt auslese bekomme ich nur

(ein weisser Schimmel:-)) die Werte aus der Datenbank. In der Tabelle stehen aber mehr Werte drin,

auch geänderte Werte, die aber nie in die Datenbank übernommen werden.

Aber zu Deinem Problem, wahrscheinlich gibt es auch im history-Adapter den Vergleich von state.ts und state.lc.

Um dem Fehler auf die Spur zu kommen habe ich folgende Zeile direkt vor den Vergleich geschrieben:

adapter.log.info('sql-1 ' + id + ' ts: ' + state.ts + ' lc: ' + state.lc + ' diff: ' + diff);

Dann im Log schauen, durch grep filtern:

tail -f log/iobroker.2016-05-13.log  | grep "sql-1 hm-rega"

Dort sehe ich etwa Variable, die alle 15 Minuten geschrieben werden mit diff:-Zeiten

von z.B. 15116 Millisekunden, alle 30 Sekunden, bis kurz unterhalb von 900000 (also dem Umlauf über die 15 Minuten) wieder eine

kleine Zahl unterhalb 30 Sekunden auftaucht. Es ist übrigens der Sonnenstand alle 15 Minuten reicht mir:-)

2016-05-13 15:28:45.155  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146125110 lc: 1463145300000 diff: 825110
2016-05-13 15:29:15.187  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146155110 lc: 1463145300000 diff: 855110
2016-05-13 15:29:45.179  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146185126 lc: 1463145300000 diff: 885126
2016-05-13 15:30:15.159  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146215116 lc: 1463146200000 diff: 15116
2016-05-13 15:30:15.161  - info: sql.0 sql-2 hm-rega.0.8023 chg val: 45.9
2016-05-13 15:30:45.191  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146245153 lc: 1463146200000 diff: 45153
2016-05-13 15:31:15.235  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146275172 lc: 1463146200000 diff: 75172
2016-05-13 15:31:45.244  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146305156 lc: 1463146200000 diff: 105156
2016-05-13 15:32:15.236  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146335156 lc: 1463146200000 diff: 135156
2016-05-13 15:32:45.228  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146365142 lc: 1463146200000 diff: 165142
2016-05-13 15:33:15.227  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146395152 lc: 1463146200000 diff: 195152
2016-05-13 15:33:45.219  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146425174 lc: 1463146200000 diff: 225174
2016-05-13 15:34:15.278  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146455197 lc: 1463146200000 diff: 255197
2016-05-13 15:34:45.231  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146485190 lc: 1463146200000 diff: 285190
...
2016-05-13 15:43:09.488  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463146989404 lc: 1463146200000 diff: 789404
2016-05-13 15:43:39.500  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463147019403 lc: 1463146200000 diff: 819403
2016-05-13 15:44:09.507  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463147049435 lc: 1463146200000 diff: 849435
2016-05-13 15:44:39.519  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463147079435 lc: 1463146200000 diff: 879435
2016-05-13 15:45:09.529  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463147109444 lc: 1463147100000 diff: 9444
2016-05-13 15:45:09.537  - info: sql.0 sql-2 hm-rega.0.8023 chg val: 44.3
2016-05-13 15:45:39.510  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463147139434 lc: 1463147100000 diff: 39434
2016-05-13 15:46:09.530  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463147169430 lc: 1463147100000 diff: 69430
2016-05-13 15:46:39.537  - info: sql.0 sql-1 hm-rega.0.8023 ts: 1463147199440 lc: 1463147100000 diff: 99440

Nur zur Verwirrung, die sql-2 Ausgabe steht unterhalb der return-Zeile um das tatsächliche Schreiben zu debuggen.

Zwei Infos noch auf den Weg:

Es gibt noch eine Zeile in hm-rega, die als Timestamp Sekunden und nicht Millisekunden verwendet - bin noch auf der Suche.

Dadurch ist der state.lc um den Faktor 1000 falsch :-(

Mit hm-rpc taucht das Problem überhaupt nicht auf, da ja die Änderungen von der CCU gepusht werden. Dadurch ist

der Transfertimestamp immer exakt identisch mit dem Änderungszeitpunkt. Anders bei hm-rega, wo alle 30 Sekunden gepullt

wird und damit eine frische Änderung ja bereits 29,999 Sekunden alt sein kann.

[harvey637]

@hormoran

in history.js steht die problematische Zeile in Zeile 645 !!!!

cu

Harvey

[Bluefox]

Es gibt neue Version von hm-rega