DbLog "verschluckt" Daten

[GaiusMarius]

Was kann ich dagegen tun?
"Verschluckt" werden die Daten letztendlich spezifikationsgemäß, denn wenn ein PRIMARY KEY über `TIMESTAMP`,`DEVICE` und `READING` existiert, kommt innerhalb ein und derselben Sekunde nur der zeitlich erste aller Werte in die Datenbank. `TIMESTAMP` unterscheidet ja nur ganze Sekunden.


Ja und? Warum stellst du dich sich so an?
Als Beispiel seien Homematic-Schalter genannt. Nach einen "on"-Befehl gehen sie über den State "set_on" in den State "on". In der DB steht nun aber als endgültiger State "set_on". Das "on" wird verschluckt, da es in der selben Sekunde eintrifft. Dieses Verhalten stört bei der Weiterverarbeitung der Daten...


Lass doch den PRIMARY KEY weg.
Das funktioniert sogar. Wobei ich mich frage, ob es ein "zufälliges" Funktionieren ist. Im Moment nimmt DbLog für z. B. SVGs den zeitlich letzten Wert innerhalb einer Sekunde^*). Ist sichergestellt, dass dieses Verhalten so bleibt?


Nimm doch `TIMESTAMP`,`DEVICE`, `READING` und `VALUE` als PRIMARY KEY.
Meine DB kann das nicht... (Mangels weitergehender MySQL-Kenntnissen weiß ich auch gar nicht, ob so etwas erlaubt wäre...)


??
"FileLog" und "Global" haben ein Attribut "mseclog" (https://fhem.de/commandref_DE.html#mseclog). Mir würde die Aufnahme der Millisekunden in den `TIMESTAMP` helfen. Allerdings scheinen sich diese Attribute nicht auf das Verhalten von DbLog durchzuschlagen.


??
Helfen würde mir auch, wenn der zeitlich letzte Wert in die DB geschrieben werden würde. Ich könnte mir sogar vorstellen, dass dies das sinnvollste Verhalten für alle Nutzer wäre.


Hier endlich der Schluss: Liege ich mit meinen Annahmen richtig? Hilf mir bitte, wenn ich wieder einen Knoten im Gehirn habe und den Wald vor lauter Bäumen nicht sehe. Aktuell behelfe ich mich damit, dass ich den PRIMARY KEY entfernt habe.



^*) = Vermutung; Verhalten nicht ausgiebig getestet...

[ch.eick]

Lass doch den PRIMARY KEY weg.
Das funktioniert sogar. Wobei ich mich frage, ob es ein "zufälliges" Funktionieren ist. Im Moment nimmt DbLog für z. B. SVGs den zeitlich letzten Wert innerhalb einer Sekunde^*). Ist sichergestellt, dass dieses Verhalten so bleibt?

Du solltest dann in der DB bei diesem Device eine Vielzahl von Einträgen mit dem selben TIMESTAMP bekommen. Die Spalte TIMESTAMP ist jedoch nur ein Text Feld in der Tabelle und es gibt darüber hinaus noch den Timestamp der Datenbank, der das ganze eindeutig macht.
Eine Sortierung nach TIMESTAMP wird Dir die Einträge nicht zwangsläufig in die richtige Reihenfolge bringen.
Das Datenmodel von FHEM ist da für das TIMESTAMP Feld nicht granular genug

Nimm doch `TIMESTAMP`,`DEVICE`, `READING` und `VALUE` als PRIMARY KEY.
Meine DB kann das nicht... (Mangels weitergehender MySQL-Kenntnissen weiß ich auch gar nicht, ob so etwas erlaubt wäre...)

Das könntest Du tun, jedoch verschiebt sich das Problem nur um ein weites Feld.
Wenn in der selben Sekunde zwei mal der selbe VALUE kommt ist auch einer weg.

??
"FileLog" und "Global" haben ein Attribut "mseclog" (https://fhem.de/commandref_DE.html#mseclog). Mir würde die Aufnahme der Millisekunden in den `TIMESTAMP` helfen. Allerdings scheinen sich diese Attribute nicht auf das Verhalten von DbLog durchzuschlagen.

FileLog ist nicht gleich DbLog

??
Helfen würde mir auch, wenn der zeitlich letzte Wert in die DB geschrieben werden würde. Ich könnte mir sogar vorstellen, dass dies das sinnvollste Verhalten für alle Nutzer wäre.

Ich denke nicht, das Heiko eine Änderung des Datenmodels durchführen möchte. Ich glaube er hat das Modul auch nur geerbt.

Könntest Du bei dem Homematic auf den Zwischenstatus verzichten?
Über ein userreading könnte man einen Zwischenfilter implementieren, der erst Triggert, wenn der endgültige Status gesetzt ist. Den könntest Du dann loggen und Darstellen.
Ich frage mich, ob es eh Sinn macht einen Taster Status im Raster kleiner 1 Sekunde zu loggen, womit mein Vorschlag dann denkbar  würde.

VG
Christian

[Otto123]

Ich habe wenig Ahnung von dbLog und verwende sie nicht.
Aber warum sollte man eigentlich (gerade bei Homematic) jeden Krümel loggen? Da blubbert derart viel durch den state ....
Definiere doch einfach ein ordentliches regExp? So in der Art?

Code Auswählen Erweitern

Kontakte.:o[nf]+
Damit wird nur der state on und off von KontakteX geloggt  (zumindest fast:) )

Gruß Otto

[ch.eick]

Aber warum sollte man eigentlich (gerade bei Homematic) jeden Krümel loggen? Da blubbert derart viel durch den state ....
Definiere doch einfach ein ordentliches regExp? So in der Art?

Code Auswählen Erweitern

Kontakte.:o[nf]+
Damit wird nur der state on und off von KontakteX geloggt  (zumindest fast:) )

Sowas hatte ich gemeint, aber ich habe ja kein HM, danke Otto.

VG
  Christian

[GaiusMarius]

Eine Sortierung nach TIMESTAMP wird Dir die Einträge nicht zwangsläufig in die richtige Reihenfolge bringen.
Das Datenmodel von FHEM ist da für das TIMESTAMP Feld nicht granular genug

Ja leider, deshalb auch meine Formulierung "zufällig richtig".

Das könntest Du tun, jedoch verschiebt sich das Problem nur um ein weites Feld.
Wenn in der selben Sekunde zwei mal der selbe VALUE kommt ist auch einer weg.

Wobei man hier argumentieren könnte, dass dann immerhin das Ergebnis korrekt wäre.

FileLog ist nicht gleich DbLog

Echt? Ich kenne weder die Historie noch die Gründe für die Implementierung, aber es kann die Millisekunden. Einen Grund dafür muss es ja gegeben haben. Ich will mir auch nicht anmaßen, zu behaupten, dass es irgendwie einfach wäre, so etwas in DbLog einzubauen.

Ich denke nicht, das Heiko eine Änderung des Datenmodels durchführen möchte. Ich glaube er hat das Modul auch nur geerbt.

Heiko? Heiko!

Könntest Du bei dem Homematic auf den Zwischenstatus verzichten?
[...]
Ich frage mich, ob es eh Sinn macht einen Taster Status im Raster kleiner 1 Sekunde zu loggen, womit mein Vorschlag dann denkbar  würde.

Aber warum sollte man eigentlich (gerade bei Homematic) jeden Krümel loggen?

Ich benötige die Zwischenstati nicht. Ihr habt da völlig Recht.


Es wäre halt einfach eleganter, wenn das Phänomen im Architekur-Umfeld von DbLog gelöst werden könnte.

• Aufnahme der Millisekunden in `TIMESTAMP`

oder

• Internes Speichern aller `TIMESTAMP`,`DEVICE` und `READING` einer Sekunde und Übergabe des zeitlich jüngsten Wertes an die DB

Ich schreibe mal einen Wunschzettel. Wichtig ist, dass ich nichts falsch verstanden habe.

Danke!