Weiter zum Inhalt
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Hell
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dunkel
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Off Topic
  4. InfluxDB
  5. Frage zu Datenreduktion im Influx-Adapter

NEWS

  • Neuer ioBroker-Blog online: Monatsrückblick März/April 2026
    BluefoxB
    Bluefox
    6
    1
    215

  • Verwendung von KI bitte immer deutlich kennzeichnen
    HomoranH
    Homoran
    8
    1
    215

  • Monatsrückblick Januar/Februar 2026 ist online!
    BluefoxB
    Bluefox
    18
    1
    890

Frage zu Datenreduktion im Influx-Adapter

Geplant Angeheftet Gesperrt Verschoben InfluxDB
2 Beiträge 2 Kommentatoren 220 Aufrufe 2 Beobachtet
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • H Offline
    H Offline
    harvey637
    schrieb am zuletzt editiert von
    #1

    Hallo zusammen,
    meine Fragen zu influxdb bzw. BestPractice:
    Ich habe einige schnell sich änderende Daten, etwa von meiner Solaranlage und Speicher, teils alle 10 Sekunden. Da interessieren mich zeitnah die Daten der etwa 7 Tage, danach wird es eher uninteressant, also längere Zeitabstände wären super (auch für Speicherverbrauch in influxdb).
    Leider gibt es wohl keine (einfache, allgemeine) Lösung, die Speicherdauer unterschiedlich zu begrenzen, also schnell sich ändernde Daten z.B. 4 Wochen zu halten, danach die Daten auf z.B. 1/30 zu reduzieren. Also von 10 Sekunden auf 5 Minuten ... Eigentlich eine mögliche influxdb interne Aufgabe (timed data reduction). Oder zwei Buckets mit unterschiedlichen retentions zur Auswahl ...
    Aktuell habe ich eine vereinfachte Zwischenlösung, die aber neue Probleme hat:
    ich habe die "Blockzeit" auf 300000ms (5 Minuten) eingestellt, so werden die sich schnell ändernden Werte zwar in echarts sofort angezeigt, aber nur nach 5 Minuten "Blockierung" in die Datenbank eingetragen. Damit taucht aber ein neues Problem auf:
    Wenn etwa in der Solarleistung INNERHALB der Blockzeit der Wert z.B. auf 0.0W fällt und dann unverändert bleibt wird ja der letzte Wert VOR Beginn der Blockzeit in die Datenbank geschrieben, der allerneueste Wert, auch wenn geändert, wird ja aufgrund der Blockzeit in der Datenbank ignoriert. Das führt dazu, dass etwa bei Solarleistung der letzte Wert VOR der Blockzeit, z.B. 15W die ganze Nacht erhalten bleibt, obwohl wenige Sekunden hinter dem Wert von 15W der Wert 0.0W gemessen wurde, aber dieser Wert aufgrund der Blockzeit nicht in die Datenbank eingetragen wurde. Danach erfolgt aber keine weitere Eintragung in die Datenbank, da der Wert ja nicht mehr geändert wird (und nur geänderte Werte eingetragen werden sollen). Auch bei kurzen Bool-Werteänderungen führt das dazu, dass der allerneueste Wert nicht in die Datenbank eingetragen wird, da er blockiert wird.
    Jemand eine Idee dazu?
    Vielen lieben Dank!
    cu
    Harvey

    Ro75R 1 Antwort Letzte Antwort
    0
    • H harvey637

      Hallo zusammen,
      meine Fragen zu influxdb bzw. BestPractice:
      Ich habe einige schnell sich änderende Daten, etwa von meiner Solaranlage und Speicher, teils alle 10 Sekunden. Da interessieren mich zeitnah die Daten der etwa 7 Tage, danach wird es eher uninteressant, also längere Zeitabstände wären super (auch für Speicherverbrauch in influxdb).
      Leider gibt es wohl keine (einfache, allgemeine) Lösung, die Speicherdauer unterschiedlich zu begrenzen, also schnell sich ändernde Daten z.B. 4 Wochen zu halten, danach die Daten auf z.B. 1/30 zu reduzieren. Also von 10 Sekunden auf 5 Minuten ... Eigentlich eine mögliche influxdb interne Aufgabe (timed data reduction). Oder zwei Buckets mit unterschiedlichen retentions zur Auswahl ...
      Aktuell habe ich eine vereinfachte Zwischenlösung, die aber neue Probleme hat:
      ich habe die "Blockzeit" auf 300000ms (5 Minuten) eingestellt, so werden die sich schnell ändernden Werte zwar in echarts sofort angezeigt, aber nur nach 5 Minuten "Blockierung" in die Datenbank eingetragen. Damit taucht aber ein neues Problem auf:
      Wenn etwa in der Solarleistung INNERHALB der Blockzeit der Wert z.B. auf 0.0W fällt und dann unverändert bleibt wird ja der letzte Wert VOR Beginn der Blockzeit in die Datenbank geschrieben, der allerneueste Wert, auch wenn geändert, wird ja aufgrund der Blockzeit in der Datenbank ignoriert. Das führt dazu, dass etwa bei Solarleistung der letzte Wert VOR der Blockzeit, z.B. 15W die ganze Nacht erhalten bleibt, obwohl wenige Sekunden hinter dem Wert von 15W der Wert 0.0W gemessen wurde, aber dieser Wert aufgrund der Blockzeit nicht in die Datenbank eingetragen wurde. Danach erfolgt aber keine weitere Eintragung in die Datenbank, da der Wert ja nicht mehr geändert wird (und nur geänderte Werte eingetragen werden sollen). Auch bei kurzen Bool-Werteänderungen führt das dazu, dass der allerneueste Wert nicht in die Datenbank eingetragen wird, da er blockiert wird.
      Jemand eine Idee dazu?
      Vielen lieben Dank!
      cu
      Harvey

      Ro75R Online
      Ro75R Online
      Ro75
      schrieb am zuletzt editiert von
      #2

      @harvey637 ich arbeite mit 2 Buckets. Es macht doch keinen Sinn, die Datenspeicherung zu verringern - dann kann ich auch ganz darauf verzichten. Ich will ja mit den Daten etwas darstellen. Also, arbeite mit mehreren Buckets.

      Ro75.

      SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen

      1 Antwort Letzte Antwort
      0

      Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.

      Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.

      Mit deinem Input könnte dieser Beitrag noch besser werden 💗

      Registrieren Anmelden
      Antworten
      • In einem neuen Thema antworten
      Anmelden zum Antworten
      • Älteste zuerst
      • Neuste zuerst
      • Meiste Stimmen


      Support us

      ioBroker
      Community Adapters
      Donate

      490

      Online

      32.8k

      Benutzer

      82.8k

      Themen

      1.3m

      Beiträge
      Community
      Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
      ioBroker Community 2014-2025
      logo
      • Anmelden

      • Du hast noch kein Konto? Registrieren

      • Anmelden oder registrieren, um zu suchen
      • Erster Beitrag
        Letzter Beitrag
      0
      • Home
      • Aktuell
      • Tags
      • Ungelesen 0
      • Kategorien
      • Unreplied
      • Beliebt
      • GitHub
      • Docu
      • Hilfe