SQL.0 loggt Daten viel zu oft

[apollon77]

Korrekt. Egal ob wert geändert oder gleich.

Gesendet vom Handy …

[Hiltex]

Danke für die Aufklärung.

[Habedere]

Servus zusammen,

da mich das Thema SQL-Logging auch gerade beschäftigt - kurz eine Frage.

Fragt der SQL-Adapter einen Temperatur/Humidity Sensor dann auch viel öfter ab

als bei keiner Aufzeichnung?

Da müsste ja die Batterie extrem darunter leiden…

mfg

[Sneak-L8]

Der SQL-Adapter fragt gar nichts ab. Er hat nur den state abonniert und bekommt mit, wenn dort Werte (auch gleiche) geschrieben werden.

Die Werte werden nur vom Temperatur-Adapter gesetzt.

[Habedere]

@Sneak-L8:

Der SQL-Adapter fragt gar nichts ab. Er hat nur den state abonniert und bekommt mit, wenn dort Werte (auch gleiche) geschrieben werden.

Die Werte werden nur vom Temperatur-Adapter gesetzt. `
Somit bleibt die Lauftzeit der Sensoren also gleich - egal ob geloggt oder nicht.

Danke für die Aufklärung

[Sneak-L8]

@apollon77 @paul53 Ich muss dieses alte Thema wieder öffnen. Habe gerade festgestellt, dass sql.0 mal wieder jede Sekunde loggt anstelle nur alle Minute oder seltener.
Die Daten komemn von einem EnergyMeter, das seine Daten im Sekundentakt sendet.
Eingestellt habe ich:

aktiviert: ja
Änderungen aufzeichnen: ja
trotzdem gleiche Werte aufzeichnen: 0
Speichern als: automatisch
Entprellzeit: 60000 (alle Minute)
minimale Differenz zum letzten Wert: 150
keine automatische Löschung

Neu habe ich aktiviert, keine Null- und 0-Werte zu loggen.

In den Verlaufsdaten sehe ich aber wie gesagt ca. jede Sekunde einen Eintrag mit Werten:

• 16:05:36 => 3482
• 16:05:35 => 3491,4
• 16:05:34 => 3484,60000000004
• 16:05:33 => 3483,4
• 16:05:32 => 3489,8
• 16:05:31 => 3487,10000000004
• 16:05:30 => 3473,4

Das sind ja deutlich geringere Abweichungen als 150 (W). Mache ich etwas falsch?

Der Datenpunkt ist definiert als

• Zustandstyp: Zahl
• Rolle: value

Im JSON ist es noch mal schön zusammengrfasst:

{
  "type": "state",
  "role": "value",
  "common": {
    "name": "psurplus",
    "type": "number",
    "role": "value",
    "custom": {
      "sql.0": {
        "enabled": true,
        "changesOnly": true,
        "debounce": "60000",
        "maxLength": 10,
        "retention": 0,
        "changesRelogInterval": 0,
        "changesMinDelta": 150,
        "storageType": "",
        "aliasId": "",
        "counter": false,
        "ignoreZero": true,
        "ignoreBelowZero": false
      }
    }
  },
  "native": {},
  "_id": "sma-em.0.1901706890.psurplus",
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1647874776659
}

Vielleicht hab ich auch einfach nur einen Denkfehler?

[apollon77]

@sneak-l8 entprellzeit ist (und war es nicht nie!!!!) der logging Abstand!!!!!

Ja der „Bug“ ist immer noch da der hier Zuviel loggt. Ansonsten würdest du mit deiner Einstellung wohl nie auch nur einen Wert geloggt bekommen.
Entprellzeit bedeutet: logge nur wenn wert für diese Zeitspanne stabil - also gleich- ist!!

[Sneak-L8]

@apollon77 Danke für die Info. Dann setze ich die Entprellzeit wieder nach unten (die Option, frühesten nach x Sekunden wieder zuloggen fände ich aber auch hilfreich ).
Und dass das zuviel-Loggen noch ein Bug ist, beruhigt mich dahingehend, dass ich doch nichts falsch eingestellt hab (von der Entprellzeit abgesehen
Bug ist aber in Anführungszeichen. Hab ich vielleicht dochwas falsch verstanden?
Denn durch minDelta = 150 sollte ja eigentlich nur bei großen Änderungen was geloggt werden.

[Homoran]

@sneak-l8 sagte in SQL.0 loggt Daten viel zu oft:

Denn durch minDelta = 150 sollte ja eigentlich nur bei großen Änderungen was geloggt werden.

ja!

[Sneak-L8]

@homoran aber warum werden die Daten dann alle paar Sekunden geschrieben, wenn sich die werte nur um ein paar Watt verändert haben?

[Homoran]

@apollon77 sagte in SQL.0 loggt Daten viel zu oft:

der „Bug“ ist immer noch da der hier Zuviel loggt.

[Sneak-L8]

@homoran @apollon77 Wie lange gibt es den Bug schon? Quasi immer oder erst in letzter Zeit? Gibt es Bestrebungen diesen Bug zu fixen? Kann ich unterstützen?

[apollon77]

@sneak-l8 Schon länger, fix ist aber tricky weil nicht ganz so easy. Bestrebungen natürlich, bisher jemand Zeit gefunden leider nicht

[apollon77]

Für History habe ich das in der neuen "History 2.0.0" mal gefixt weil dort das gleiche Problem besteht. Wäre es möglich im vergleich sql/history mal anzusehen und zu sagen ob es in History 2.0.0 gefixt ist bevor ich "das gleiche" auf sql ausrolle?

Details: https://forum.iobroker.net/topic/54197/test-adapter-history-2-0-0

[Sneak-L8]

@apollon77 Vielen Dank für die neue Version. Ich habe sie jetzt mal für den EnergyMeter parallel zu SQL.0 mitlaufen lassen. Insgesamt sieht es sehr gut aus. Ab und an werden noch Werte 2x hintereinander geloggt, aber deutlich seltener als mit dem bisherigen Bug.

Einstellunen:

• aktiviert
• Entprellzeit: 0
• Blockzet: 30000 (das ist ne super neue Option!)
• nur Änderugnen aufzeichnen
• trotzdem gleiche Werte: 0
• minimale Differenz: 150
• Vorhaltezeit: 1 Jahr
• Sätze im RAM: 960
  Der Rest ist leer.

So würde mir das auch für den SQL-Adapter gefallen.

Einzige Verbesserungsmöglichkeit: beim energyMeter kommen durchaus zurecht 0-Werte vor (surplus und regard in getrennten Feldern), daber wäre es schlnm, man könnte die Option "Zero- oder Nullwerte ignorieren (==0)" in zwei Optionen aufteilen, so dass nur die null unterdrückt werden.

Viele Grüße und danke für Deine Arbeit!
Sneak-8

[apollon77]

@sneak-l8 Hi,

Wenn nochwas zuviel geloggt wird dann schalte ür den Datenpunkt mal das erweiterte Debug log ein und stelle Lofglevel auf Debug und dann zeig Logauschnitt (1-2 Werte jeweils vor und nach dem "zuviel" und sag was genau zuviel ist. Dann schaue ich gern.

Für SQL und InfluxDB ist das gleiche auch in Arbeit ... ist nur etwas größer und testen frisst da die Zeit.

Einzige Verbesserungsmöglichkeit: beim energyMeter kommen durchaus zurecht 0-Werte vor (surplus und regard in getrennten Feldern), daber wäre es schlnm, man könnte die Option "Zero- oder Nullwerte ignorieren (==0)" in zwei Optionen aufteilen, so dass nur die null unterdrückt werden.

Verstehe ich nicht. Du hast jetzt DREI Optionen:

• Zero- oder Nullwerte ignorieren (==0) ignoriert genau nur die 0 (oder null)
• werte kleiner X ignorieren
• Werte größer X ignorieren

Also die erste ist doch genau das was Du brauchst oder was verstehe ich falsch?

[Sneak-L8]

@apollon77 Danke für Deine Antwort. Ich habe mal mitgeloggt:

2022-04-28 09:02:09.129 - debug: history.0 (32205) Min-Delta not reached sma-em.0.1901706890.psurplus, last-value=3008.9, new-value=3131.2000000000003, ts=1651129329116
2022-04-28 09:02:10.119 - debug: history.0 (32205) Min-Delta not reached sma-em.0.1901706890.psurplus, last-value=3008.9, new-value=3111.6000000000004, ts=1651129330110
2022-04-28 09:02:11.127 - debug: history.0 (32205) Min-Delta not reached sma-em.0.1901706890.psurplus, last-value=3008.9, new-value=3114.3, ts=1651129331117
2022-04-28 09:02:12.118 - debug: history.0 (32205) Min-Delta not reached sma-em.0.1901706890.psurplus, last-value=3008.9, new-value=3128.3, ts=1651129332107
2022-04-28 09:02:13.137 - debug: history.0 (32205) Min-Delta not reached sma-em.0.1901706890.psurplus, last-value=3008.9, new-value=3147.9, ts=1651129333117
2022-04-28 09:02:14.119 - debug: history.0 (32205) Min-Delta reached sma-em.0.1901706890.psurplus, last-value=3008.9, new-value=3172.2000000000003, ts=1651129334110
2022-04-28 09:02:14.120 - debug: history.0 (32205) Skipped value logged sma-em.0.1901706890.psurplus, value=3147.9, ts=1651129333117
2022-04-28 09:02:14.122 - debug: history.0 (32205) Value logged sma-em.0.1901706890.psurplus, value=3172.2000000000003, ts=1651129334110
2022-04-28 09:02:15.125 - debug: history.0 (32205) value ignored blockTime sma-em.0.1901706890.psurplus, value=3147.8, ts=1651129335115, lastState.ts=1651129334110, blockTime=30000

Die Werte dazu sind:

2022-04-28T06:59:37.155Z	3008.9	true
2022-04-28T07:02:13.117Z	3147.9	true
2022-04-28T07:02:14.110Z	31.722.000.000.000.000	true
2022-04-28T07:05:17.067Z	3316.3	true

Wegen den Drei Optionen: ich will nur die "null" unterdrücken. Alle "echten" Zahlen, ach 0, sollen geloggt werden. Das geht - so wie ich die drei Werte verstehe - nicht. Oder hab ich vielleicht was missverstanden?

[apollon77]

@sneak-l8 Also in deinem Log sieht man das ein "skipped Wert" geloggt wird. Wenn das der wert ist den Du nicht willst dann kannst du das jetzt doch ausschalten ... liess doch mal oben ... ist dieses "zusätzliche Werte zur grafischen Darstellungsoptimierung" ... kannste jetzt ausschalten.

Zu Null vs 0 ... aahhhhhjjaaaaa ... also nur die Null solls nicht sein? ... puuhhhh Am Ende kann man bei getHistory, wo man Daten abfragt, sagen das null ignoriert werden sollen ... Hilft Dir das?

[Sneak-L8]

@apollon77 Ah, ok, wenn der zusätzliche Wert bewusst gelogtgt wird, um die Darstellung zu optimieren (das war mir nicht klar), dann hat alles seine Ordnung.

Meinst Du mit "am Ende" die Option: "Schreibe NULL-Werte an Start-/Stop-Grenzen"? Kommen die NULL-Werte daher? Dann kann ich die Option natürlich auch deaktivieren.

[apollon77]

@sneak-l8 sagte in SQL.0 loggt Daten viel zu oft:

@apollon77 Ah, ok, wenn der zusätzliche Wert bewusst gelogtgt wird, um die Darstellung zu optimieren (das war mir nicht klar), dann hat alles seine Ordnung.

naja wenn Du History 2.0 gerade testet lies dochmal meinen monolog am Anfang des Threads ... da ist das alles beschrieben