Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • 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

  • Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
    BluefoxB
    Bluefox
    16
    1
    1.7k

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    13
    1
    865

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    25
    1
    2.1k

Frage zu Datenreduktion im Influx-Adapter

Geplant Angeheftet Gesperrt Verschoben InfluxDB
2 Beiträge 2 Kommentatoren 187 Aufrufe 2 Watching
  • Ä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 Offline
      Ro75R Offline
      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
      Antworten
      • In einem neuen Thema antworten
      Anmelden zum Antworten
      • Älteste zuerst
      • Neuste zuerst
      • Meiste Stimmen


      Support us

      ioBroker
      Community Adapters
      Donate

      533

      Online

      32.6k

      Benutzer

      82.1k

      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