Homeassistant (Container) und externe Datenbank, bzw die Umstellung mit Import?

[mgutt]

Es macht einfach keinen Sinn: Die Datenbank ist nun 289 MB groß statt 220 MB, aber ich sehe überall im HA, dass wie von mir verlangt die Verlaufsdaten nicht mehr ermittelt werden:

 

 

Und ich denke hier ist das Problem zu suchen. Der räumt gar nicht auf, sondern ermittelt nur einfach nichts mehr:

 

 

Sollte der Recorder nicht auch die historischen Daten nun löschen?!

 

EDIT1:

Also laut Anleitung kann man einen "Purge" über die Entwicklertools manuell anstoßen, was ich auch wie folgt gemacht habe:

 

 

Nur das ändert nichts am Ergebnis. Ich vermute mal, weil es die "apply filter" gar nicht gibt. Denn wenn ich auf den YAML-Modus umschalte, sieht man nur das:

 

Ich mein welche Filter soll er denn anwenden!? Den "exclude"-Teil aus meiner recorder-Regel nimmt er jedenfalls nicht.

 

Und die anderen Optionen wie "Days to keep" usw werde ich bestimmt nicht nehmen, weil er dann ja bestimmt alles global löscht, was älter ist. Ich will ja nur bestimmte Sachen weg haben und nicht alles.

 

EDIT2:

Ok. Jetzt habe ich die Lösung. Man muss nicht wie in dem Thread im HA Forum beschrieben "Purge" nutzen, sondern "Purge Entities". Leider übernimmt HA nicht die vorhandenen Regel vom Recorder. Stattdessen muss man sie hier wieder manuell eintragen, was ich dann auch wie folgt gemacht habe:

 

 

Jetzt ist zB das Temperatur-Chart wie erwartet komplett leer:

 

 

Da die Datenbank aber immer noch 289 MB groß ist, habe ich zum Abschluss doch noch mal "Purge" benutzt und da das Repack ausgewählt:

 

 

Nun ist die Datenbank auf 236 MB geschrumpft. Da ich deutlich mehr erwartet habe, werde ich die Tage noch mal die DB analysieren und schauen welche Werte diesmal in großer Anzahl vorkommen.

[JoMe]

Glaub da ist was so richtig im argen gewesen, durch die Umstellung und Tests, aber du scheinst es ja in den Griff zu bekommen. 

 

Anhand der Screenshots und der Beschreibung kann ich nur nicht ganz nachvollziehen, der Recorder logt da doch gar nicht, die Kurve der letzten Temperaturen steht ja still.

 

Zur Größe:

Vielleicht Mal eine zweite Datenbank zum Test anlegen, jetzt wo du deine excludes ja zusammen hast wäre die dann frisch. Und dann ggf. nur die Langzeitdaten zurückspielen?!

[mgutt]

15 minutes ago, JoMe said:

die Kurve der letzten Temperaturen steht ja still.

Ja, das war schon korrekt, aber ich ging davon aus, dass dadurch auch die bisher ermittelten Daten gelöscht würden. Weil in dem Thread spricht der Ersteller ja von der Verkleinerung der DB.

 

Ich sehe aber gerade den Absatz. Er wusste es scheinbar auch nicht so genau:

Quote

Note: I guess the database file size will never go down, unless you purge it with the repack parameter. I have not confirmed this, and I don’t have enough experience with SQLite to be sure about it.

 

Also ja, das hat das weitere Logging von der Temperatur verhindert, aber wenn man auch die bisher ermittelten Werte loswerden will, muss man parallel die selben Filter bei Purge Entities ausführen.

 

Ansonsten wären die Temperaturwerte nämlich für 1100 Tage drin geblieben.

[fir3drag0n]

On 1/21/2023 at 2:23 PM, JoMe said:

 

Ja, genau. Die Antwort hast du dir ja mit deinem EDIT schon selbst gegeben. Ob du nun HomeAssistant zur Auswertung benutzt liegt natürlich bei dir. Eine andere Denkweise könnte natürlich sein, das HomeAssistant die DB befüllt und jährliche Abfragen direkt aus der Datenbank abgefragt werden. Wie überall gibt es da wieder 100te Möglichkeiten.

Falls du bei HomeAssitant bleiben magst, schau dir mal die apexcharts an. Dort hast du doch einiges mehr an Formatierungsoptionen und kannst u.a. auch mal "schnell" eine Reihe von Daten per csv direkt im Diagramm herunterladen.

 

Der Inhalt ist damit vorbei, noch kurz mein Senf dazu:
Bin selbst seit vergangenem Jahr von einer ioBroker-Installation zu HomeAssistant am wechseln. Bin sicherlich kein Datenbankspezialist, hab gelegentlich beruflich was mit diesem Thema zu tun. Finde so wie es in HA gelöst ist entgegen mancher Kommentare hier und im restlichen Internet doch sehr schick. Wenn man sich die Datenbankstruktur anschaut, wie diese aufgebaut ist, auch teilweise mit den JSON-Blöcken um weitere Spalten und Tabellen zu sparen - kann da nur meinen Hut ziehen. Man vergisst bei solchen Sachen immer schnell, dass es da ein großes Spektrum an Anforderungen verschiedener Nutzer gibt, demnach kann da immer nur ein Kompromiss rauskommen.

 

Auch wenn sqlite da sicherlich nicht an seine Limits kommt bietet eine MariaDB da doch noch andere Möglichkeiten. Auch von der Performance wenn da mal ein paar mehr Anfragen zusammen kommen. Klar, die Frage ist auch hier ob es sich da lohnt und besonders ob es sich lohnt sich da einzuarbeiten oder ob OUT-of-the-box dann doch wieder gut genug ist. 

 

 

Wieso wechselt du von iobroker zu Home Assistant und wie sind so bisher so deine Erfahrungen? Ich nutze iobroker auch schön und mich würde das interessieren.

[JoMe]

2 hours ago, fir3drag0n said:

Wieso wechselt du von iobroker zu Home Assistant und wie sind so bisher so deine Erfahrungen? Ich nutze iobroker auch schön und mich würde das interessieren.

 

Guten Morgen,

 

das lässt sich kaum beantworten, ohne einen lange Vortrag zu schreiben. In Kürze:

ioBroker ist doch schon sehr "frickelig". Jenachdem was man da vorhat, eigene Strukturen und Datenpunkte verwalten, etc...., dieser Alias Adapter, ... ioBroker besteht da aus sehr vielen, kleinsten Bausteinen die ineinander greifen. Mir fehlt da persönlich ein wenig das durchgängige Konzept. Jeder Adapter bedient sich anders, baut anders seine Daten auf.... Alles ist mit 1000 klicks verbunden... Die Abläufe widerholen sich sehr oft... Klar geht da auch viel mit Scripten, aber auch diese müssen gepflegt werden und oft braucht man sowas ja dann nach Jahren nochmal wenn eine weitere Erweiterung dazu kommt.

 

Das Thema Visu ist auch Stiefkind. Die VIS darf ja gerne mächtig sein, aber da mal "eben schnell" was machen ist kaum möglich. War dann nachher JARVIS Premium Kunde. Der Ansatz war OK aber auch noch recht Zeitintensiv.

 

Bei HomeAssistant ist das Konzept viel Durchgängiger. Es ist hervorragend Dokumentiert. Man muss sich aber auf deren Denkweise einlassen. Die Unterschiede sind schon enorm.

Zudem ist die Community viel Größer, die monatlichen Updates... Wie einfach manche Sachen OUT-of-the-Box funktionieren können (z.B. RFID mit der Android-App).

Diese Datenbankthemen (mach das in diesem Umfang mal in ioBroker)... ESPHome... Klar, muss man nicht mögen aber wozu denn immer das Rad neu erfinden. Und ich könnte sicherlich noch 100 andere Sachen aufzählen.

 

Das Ding ist einfach komplett. Mir ist klar, dass alle Funktionsumfänge jeweils auch beim anderen umzusetzen sind. Bei HomeAssistant brauch ich dazu aber 95% weniger Zeit und das ist das wirklich wesentliche für mich.

 

 

[sonic6]

On 1/25/2023 at 4:06 PM, mgutt said:

Weil in dem Thread spricht der Ersteller ja von der Verkleinerung der DB.

Ich konnte mich nun mal aufraffen und meine 5GB große DB, mit dem von @mgutt geposteten Thread, analysieren und bereinigen.

Bin nun bei ca 3GB bei 100Tage recording Time angekommen.

 

Habe mir nun auch die mühe gemacht und angefangen Entitäten zu exkludieren.

 

Dabei stellt sich mir eine Frage:

 

Kann man auch komplette Device, mit all deren Sensoren, exkludieren?
Ich möchte nicht tendenziell alle "switche" exkludieren, aber besonders die Fritzbox Integration generiert schon recht viele Entitäten die ich nicht brauche.

 

Habe mir jetzt erstmal mit entity_globs weiter geholfen:

recorder:
  purge_keep_days: 100
  commit_interval: 10
  exclude:
    domains:
      - device_tracker
      - media_player
      - uptime
      - time_date
      - worldclock
    entity_globs:
      - sensor.fritzbux*
      - sensor.h_l*
      - sensor.tautulli*
      - switch.*_internet_access
      - switch.*_internet_access_2
      - switch.*_internet_access_3
      - switch.fritzbux_port_forward*

Damit sollte ich schonmal nen Großteil erschlagen haben.

[mgutt]

Da ich mittlerweile bei 8GB angekommen bin 😅, wollte ich mal schauen, wo man vielleicht noch was Platz sparen kann.

 

Ein wie ich finde interessanter Punkt ist folgender:

Bei einem benutzerdefinierten Sensor (configuration.yaml), der sich auf mehrere Entitäten bezieht, wird dieser jedes mal berechnet, wenn nur eine der beteiligen Entitäten einen neuen Wert meldet. 

 

Addiert man also zB wie ich drei Sensoren eines Shelly 3EM, um den Gesamtverbrauch aller drei Phasen als Summe zu erhalten, so würde das Ergebnis alle paar Sekunden berechnet und in die Datenbank geschrieben. Das kann man verhindern, in dem man einen time_pattern trigger dem sensor-Block voranstellt. Hier aktualisiere ich zB die Summe nur alle 5 Minuten:

    - name: Wärmepumpe Summe
      unique_id: shelly3wp_energy
      unit_of_measurement: 'kWh'
      state: >-
        {#- on reboot some sensors do not return a number (instead they return "unknown" or "unavailable") -#}
        {%- if is_number(states("sensor.shelly3wp_channel_a_energy")) and is_number(states("sensor.shelly3wp_channel_b_energy")) and is_number(states("sensor.shelly3wp_channel_c_energy")) -%}
          {{ (states("sensor.shelly3wp_channel_a_energy") | float + states("sensor.shelly3wp_channel_b_energy") | float + states("sensor.shelly3wp_channel_c_energy") | float) | round(2) }}
        {%- else -%}
          unavailable
        {%- endif -%}
      device_class: energy
      state_class: total_increasing

 

Oder hier nur alle 30 Sekunden:

  - trigger:
      - platform: time_pattern
        seconds: "/30"
    sensor:
    - name: Wärmepumpe Verbrauch
      unique_id: shelly3wp_power
      unit_of_measurement: 'W'
      state: >-
        {#- on reboot some sensors do not return a number (instead they return "unknown" or "unavailable") -#}
        {%- if is_number(states("sensor.shelly3wp_channel_a_power")) and is_number(states("sensor.shelly3wp_channel_b_power")) and is_number(states("sensor.shelly3wp_channel_c_power")) -%}
          {{ (states("sensor.shelly3wp_channel_a_power") | float + states("sensor.shelly3wp_channel_b_power") | float + states("sensor.shelly3wp_channel_c_power") | float) | round(2) }}
        {%- else -%}
          unavailable
        {%- endif -%}
      device_class: power
      state_class: measurement

 

 

 

P.S. das Prüfen auf "is_number" und Setzen auf "unavailable" hat geholfen, dass der Sensor nach einem Neustart des Containers nicht mehr auf 0 zurückspringt. Seitdem habe ich ausschließlich saubere Werte in der Datenbank.

 

Was eventuell auch noch interessant ist, dass neben der Datenbank-Tabelle "states" auch "statistics_short_term" einiges an Speicherplatz belegt:

 

Dazu recherchiere ich aber später noch mal.

 

Bis dahin habe ich die Abfrage aus dem verlinkten Thread noch mal ausgeführt:

SELECT
  COUNT(*) AS cnt,
  COUNT(*) * 100 / (SELECT COUNT(*) FROM states) AS cnt_pct,
  SUM(LENGTH(attributes)) AS bytes,
  SUM(LENGTH(attributes)) * 100 / (SELECT SUM(LENGTH(attributes))  FROM states) AS bytes_pct,
  entity_id
FROM states
GROUP BY entity_id
ORDER BY cnt DESC

 

Das Ergebnis von damals:

 

Und von heute:

 

Was mir dabei auffällt:

 

1.) Umso häufiger ein Gerät beim Verbrauch schwankt, umso häufiger kommt es zu DB-Einträgen. Vom Prinzip logisch, ich hätte nur nicht gedacht, dass alleine der Shelly 3EM, der den Allgemeinstrom des Stromzählers ermittelt, 39% (14+13+12) aller DB-Einträge ausmacht. Wie soll ich das reduzieren?!

 

2.) Benutzerdefinierte Sensoren / Entitäten werden nicht aus der DB entfernt, obwohl sie nicht mehr existieren. zB alles was mit "stromzahler" anfängt, gibt es gar nicht mehr. Ich habe schon über Entwicklerwerkzeuge > Dienste > Recorder: Purge Entities > Entity Globs to remove > "- sensor.stromzahler*" versucht diese Entitäten zu löschen, aber sie bleiben hartnäckig in der Datenbank enthalten 🤔

 

3.) Man sollte grundsätzlich jeden Sensor / Entität beim Hinzufügen zu Home Assistant umbenennen. zB "lumi_lumi_blablabla" ist wenig aussagekräftig. Da darf man dann erst mal die Entitäten-Liste durchsuchen:

 

Wobei ich aber auch hier überfragt bin, wie ich die Menge der DB-Einträge beeinflussen könnte. 🤔

 

 

[Anym001]

On 9/24/2023 at 10:27 PM, mgutt said:

1.) Umso häufiger ein Gerät beim Verbrauch schwankt, umso häufiger kommt es zu DB-Einträgen. Vom Prinzip logisch, ich hätte nur nicht gedacht, dass alleine der Shelly 3EM, der den Allgemeinstrom des Stromzählers ermittelt, 39% (14+13+12) aller DB-Einträge ausmacht. Wie soll ich das reduzieren?!

 

Ich habe dazu, gleich wie du die 3 Phasen vom Shelly 3EM zusammengerechnet, aber zusätzlich diese 3 Phasen beim Recorder deaktivier, damit diese nicht mehr in die Datenbank geschrieben werden.  (Siehe -> sensor.shellypro3em_*_active_power)

 

- trigger:
    - platform: time_pattern
      seconds: "/10"
  sensor:
  - name: ShellyPro3EM aktuelle Leistung Gesamt
    unique_id: shellypro3em_aktuelle_leistung_gesamt
    unit_of_measurement: 'W'
    state: '{{ (states("sensor.shellypro3em_0cb815fcbbd4_phase_a_active_power") | float(0)
           + states("sensor.shellypro3em_0cb815fcbbd4_phase_b_active_power") | float(0)
           + states("sensor.shellypro3em_0cb815fcbbd4_phase_c_active_power") | float(0)) | round(2) }}'
    device_class: power
    state_class: measurement

 

Recorder Einstellungen: 

db_url: !secret mariadb_url
purge_keep_days: 30
commit_interval: 60
exclude:
  domains:
    - device_tracker
    - sun
  entity_globs:
    - sensor.count*
    - sensor.date*
    - sensor.time*
    - sensor.internet_time*
    - sensor.abfalltermine_*
    # sonos
    - switch.*_surround_music_full_volume*
    - switch.*_surround_enabled*
    - switch.*_subwoofer_enabled*
    - switch.*_speech_enhancement*
    - switch.*_night_sound*
    - switch.*_loudness*
    - switch.*_crossfade*
    - number.*_treble*
    - number.*_bass*
    - number.*_gain*
    - number.*_surround_level*
    - number.*_sub_gain*
    - number.*_audio_delay*
    - binary_sensor.*_microphone*
    # shelly
    - sensor.shellypro3em_*_active_power
    - sensor.*_power_factor
    - sensor.*_voltage
    - sensor.*_current
    - sensor.*_device_temperature*
    - binary_sensor.*_overheating
    - binary_sensor.*_overpowering
    - binary_sensor.*_overvoltage
    # aqara weather and window sensor
    - button.lumi*_identify*
    # aqara smart plug
    - sensor.lumi*_rms_voltage*
    - sensor.lumi*_power_factor*
    - sensor.lumi*_device_temperature*
    - button.lumi*_identify*
  entities:
    # shelly
    - sensor.steckdose_server_power

 

 

 

On 9/24/2023 at 10:27 PM, mgutt said:

2.) Benutzerdefinierte Sensoren / Entitäten werden nicht aus der DB entfernt, obwohl sie nicht mehr existieren. zB alles was mit "stromzahler" anfängt, gibt es gar nicht mehr. Ich habe schon über Entwicklerwerkzeuge > Dienste > Recorder: Purge Entities > Entity Globs to remove > "- sensor.stromzahler*" versucht diese Entitäten zu löschen, aber sie bleiben hartnäckig in der Datenbank enthalten 🤔

 

Bei mir funktionier es unter Entwicklerwerkzeuge > Dienste > Recorder: Purge Entities > Entität auswählen.

Ich wähle einfach alle gewünschten Enitäten manuell aus und gehe dann auf Dienst ausführen. 

Danach 5-10 warten und Neustart. Das hilft normalerweise. 

[mgutt]

1 hour ago, Anym001 said:

Ich habe dazu, gleich wie du die 3 Phasen vom Shelly 3EM zusammengerechnet, aber zusätzlich diese 3 Phasen beim Recorder deaktivier

Ja, da hätte ich auch mal drauf kommen können 😅 Danke!

[ShadowJumper]

@mgutt

 

Sorry wenn ich das Thema hochhole, aber da du ja auch die Batterie Daten entfernt hast eine Frage: Alle anderen Daten wurden bei mir entfernt, aber Sensoren mit "battery" im Namen scheinen da etwas Hartnäckiger zu sein.

 

Du hast ja bei dir z.b. ebenfalls eine GLOB mit "- sensor.*_battery*". Versuche ich das gleiche bei mir z.b. für die Thermomether mit "sensor.fritz_dect_440_*" dann werden auch "fast" alle Daten entfernt.

 

Für die Temperatur ist der Verlauf weg, Luftfeuchtigkeit ist weg, aber Batterie bleibt hartnäckig da.

 

Ich bin da mit meinem Latein langsam am ende, da er die anderen Werte ja auch entfernt.

 

Jemand noch eine Idee?

 

Interessanterweise gilt bei Handy und Tablet das gleiche Problem: Alle Werte außer die von der Batterie lassen sich entfernen.