Zu viele Schreibzugriffe auf SD-Karte in HomeAssistant/pyhomematic Umgebung

Describe the bug Raspberrymatic schreibt /etc/config/homematic.regadom viel zu häufig auf die SD-Karte. Die Datei ist bei mir 2.6 MB groß und wird bei meiner Docker-basierten Installation alle 30 Sekunden auf die SD-Karte geschrieben. Das sind 7.5 GB/Tag und im 24/7 Betrieb zu viele Schreibzugriffe für jede SD-Karte. Bei mir ist bereits eine SD-Karte vermutlich dadurch defekt geworden. Issue 1183 könnte auch damit zusammenhängen.

Steps to reproduce the behavior

1. iotop -a -o ein paar Minuten auf dem Host laufen lassen
2. 4077 be/4 root 0.00 B 15.45 M 0.00 % 0.00 % ReGaHss -f /etc/rega.conf -l 2
3. ReGaHss erzeugt ein hohes Schreibvolumen (15.45 MB nach 3 Minuten)

Expected behavior Nur, wenn sich die Datei auch verändert, sollte sie geschrieben werden. Außerdem sollten volatile Daten, insbesondere der DutyCycle, nicht mit persistiert werden.

Langfristig sollte das Abspeichern einer 2.6 MB Datei komplett vermieden werden, nur weil sich eine einzige Variable ändert. Datenbank?

Screenshots …

System information:

• RaspberryMatic Version: 3.57.4.20210320
• Used Hardware: Raspberry Pi 3
• Used HomeMatic RF-Module: RPI-RF-MOD

Additional context Ich habe bereits einen Workaround gefunden über einen eigenen Entrypoint, aber ich denke das Problem muss in Raspberrymatic/OCCU/? gefixt werden, da es nicht nur für die Docker-basierte Installation gilt, sondern für alle. Durch den Workaround konnte ich die Schreibzugriffe auf 10% reduzieren. Noch nicht ideal, aber wesentlich besser, also zuvor.

Ich vermute, dass in 80% der Fälle die DutyCycle-Variable den Schreibvorgang erfordert. Meistens sieht ein diff folgendermaßen aus:

/ # diff -Nur /tmp/homematic.regadom /etc/config/homematic.regadom
--- /tmp/homematic.regadom
+++ /etc/config/homematic.regadom
@@ -12320,7 +12320,7 @@
 <type>0</type>
 </valdef>
 </dp>
-<var>24.000000</var>
+<var>25.000000</var>
 <varType>4</varType>
 </var-dp>
 </vardpmap>

24->25 war genau die Änderung des DutyCycles.

Hier ist der entrypoint.sh von meinem Workaround:

#!/bin/sh
set -e

TEMP_FOLDER="/tmp"
TEMP_DOM="$TEMP_FOLDER/homematic.regadom"
PERSISTENT_DOM="/etc/config/homematic.regadom"

sed 's|DomFileName=/etc/config|DomFileName=/tmp|' -i /etc/rega.conf

function persist_dom()
{
  while ! mount | grep "$TEMP_FOLDER" || ! test -e "$PERSISTENT_DOM"
  do
    echo "Waiting for temp folder and persistent file"
    sleep 1
  done

  echo "Putting homematic.regadom to RAM disk"
  cp "$PERSISTENT_DOM" "$TEMP_DOM"

  while true
  do
    if test -e "$TEMP_DOM" && test -e "$PERSISTENT_DOM"
    then
      while true
      do
        FILE_AGE=$(echo "$(date +'%s') - $(stat -c '%Y' $TEMP_DOM)" | bc)
        if test "$FILE_AGE" -gt 10
        then
          break
        fi
        sleep 1
      done
      while ! cmp -s "$TEMP_DOM" "$PERSISTENT_DOM"
      do
        echo "$(date) Persisting modified homematic.regadom"
        cp "$TEMP_DOM" "$PERSISTENT_DOM"
        sleep 1
      done
    fi
    sleep 120
  done
}

persist_dom &

exec /sbin/init

Verwendbar über

docker run -v $PWD/entrypoint.sh:/entrypoint.sh --entrypoint /entrypoint.sh ... ghcr.io/jens-maus/raspberrymatic

[jens-maus]

Ok, ich denke ich hab es. Du nutzt ja die session.Logout() JSON RPC Methode für den Logout und diese nutzt intern unter RaspberryMatic die system.ClearSession() ReGa Methode. Allerdings unter der Standard WebUI wird hier die system.ClearSessionID() Method verwendet und diese macht im Grunde das selbe, nur speichert sie eben die homematic.regadom vorher nicht ab (siehe https://github.com/eq-3/occu/blob/master/WebUI/www/api/methods/session/logout.tcl#L12) und das wohl (wie man hier sieht) aus gutem Grund.

Reingekommen ist diese Änderung in RaspberryMatic im Zuge eines vermeintlichen Bugfixes in der WebUI (siehe https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/patches/occu/0060-WebUI-Fix-SessionLogoutSave.patch). Nun muss ich mir das mal genauer anschauen wieso ich das damals von ClearSessionID() zu ClearSession() geändert habe. Aber auslösender Punkt wird genau das hier sein. Insofern ist das dann doch wohl meine Aufgabe hier etwas zu verbessern - und natürlich könnte in der Tat pyhomematic trotzdem nicht so offensiv mit den Sessions umgehen 😉

[rusitschka]

I’m running ghcr.io/jens-maus/raspberrymatic:3.57.4.20210326-e66b34e now and it solves the issue. My work-around is no longer required. Thank you very much, @jens-maus and @danielperna84 😃