Blog Obsolet

HomeMatic – CCU Abstürze durch zu viele Skriptvariablen verhindern

WebUI

Letzte Aktualisierung am 1. Juli 2023

Dieser Beitrag ist zwischenzeitlich obsolet, da das CCU-Firmware-Problem seit längerer Zeit behoben ist. Er wird nicht mehr aktualisiert. Die Kommentare wurden geschlossen.

Mittlerweile wurde bekannt und auch vom Hersteller eingeräumt, dass auf einer HomeMatic-Zentrale maximal 200 Variablen deklariert werden können. Hierbei sind die in den Skripten intern genutzten Variablen gemeint, nicht die Systemvariablen. Die Zahl 200 markiert dabei die Gesamtanzahl von Skriptvariablen in allen verwendeten Skripten. Bei Überschreiten dieser Zahl kommt es nach einiger Zeit dazu, dass Programme nicht mehr laufen oder die CCU abstürzt.


Update Juli 2017

Mit der CCU2 Firmware 2.29.18 wurde dieser Fehler (in den Logikschicht Versionen „Standard“ und „Community“) offensichtlich behoben. Ab dieser Version kann man auf die temporären Skript-Variablen verzichten.

Das „historische Phänomen“ ist daher für Nutzer aktueller CCU-Firmwareversionen der CCU2, CCU3, RaspberryMatic etc. obsolet.

Die 200 Skriptvariablen erreicht man bei intensiver Nutzung des Systems recht schnell, so führten auch bei mir zuletzt 234 Skriptvariablen regelmäßig zu den genannten Phänomenen.

Falls sich die eigene Installation dieser Größe nähert oder sie gar bereits überschritten hat, ist es an der Zeit zu handeln. Die herstellerseitige Lösung des Problems im Rahmen eines Firmwareupdates wurde nicht wirklich in Aussicht gestellt. So sollte man sich anderweitig behelfen.

Im HomeMatic Forum gibt es hierzu mehrere Ansätze. Ich habe mich für die Variante entschieden, die internen Skriptvariablen in allen genutzten Skripten durch „temporäre Variablen“ zu ersetzen und zwar nach dem Schema…


tmpA bis tmpZ

…und falls das noch nicht reicht, zusätzlich noch…


tmpA1 bis tmpZ1

…, sodass bei konsequenter Nutzung maximal 52 Skriptvariablen benötigt werden. Dort sind auch einige gängige Skripte nach der Methode angepasst hinterlegt.

Man kann die Skripte zwar nahezu nicht mehr verstehen aber wenn es der Sache dient 😉 . Ich empfehle, eventuelle Anpassungen und Versuche mit den Original-Skripten anzustellen und diese dann anzupassen, wenn alles klappt.


Übrigens hat es offensichtlich keine negativen Auswirkungen, wenn man ein Skript in der „Skript testen“-Funktion des WebUI oder im erweiterten Skript Parser ausführt. Erst bei Erstellen eines neuen Skriptes bzw. Benutzen der „Fehlerprüfung“ werden die Variablen in den Cache geschrieben und bis zum nächsten Reboot der CCU nicht mehr gelöscht.

Bitte beachten…

SMART WOHNEN in Stern’s Haus ist ein rein privates, nicht kommerzielles Projekt. Meine Hinweise, Anleitungen, Schaltungen und Software werden so angeboten, „wie sie sind“, Support kann ich nur im Rahmen meiner begrenzten Freizeit leisten, hierfür bitte ich um Verständnis.
Die Verwendung meiner Hinweise, Anleitungen, Schaltungen und Software erfolgt auf eigenes Risiko. Ich übernehme hierfür keinerlei Gewährleistung bzw. Haftung! Für die Einhaltung der einschlägigen technischen Vorschriften ist jeder Anwender selbst verantwortlich!
Creative Commons Lizenzvertrag
Copyright © Jens-Peter Stern | SMART WOHNEN in Stern’s Haus | sternshaus.de
  1. rUmtifUsel

    Dank des Prüfscripts aus dem HomeMatic Forum weiß ich nun, dass ich mit 150 Scriptvariablen unterwegs bin. Es ist also noch etwas Platz.
    In diesem Zusammenhang bin ich schon seit einiger Zeit am Überlegen, eine zweite CCU anzuschaffen um die Last etwas zu verteilen.
    Hast Du hierbei schon Erfahrungen?

    Gruß

    rUmti

  2. Hallo rUmti,
    ich selbst nutze nur eine CCU, mehrere Zentralen parallel zu betreiben ist aber offensichtlich problemlos möglich, solange man die Komponeneten jeweils nur an eine der Zentralen anlernt. Hierzu gibt es im HomeMatic-Forum einiges an Erfahrungswerten.
    Aber der zusätzliche Aufwand mit Updates und dergleichen sollte man bei der Entscheidung auch berücksichtigen. Fehler muss man dann möglicheweise über zwei (oder mehr) CCUs suchen. Mehr ist nicht immer besser.
    Liebe Grüße Jens

  3. rUmtifUsel

    Wohl war.

    Um den Performaceproblemen zu entgehen ist es sicherlich ratsam für manche AddOns und Scripte nicht die CCU zu bemühen, sondern einen RasPi.
    Kannst Du da ggf. eine Empfehlung aussprechen?

    • Hallo rUmti,
      ich nutze z.B. überhaupt keine CCU-internen Diagramme und auch keine von CUxD-Highcharts sondern dafür den CCU-Historian auf einem RasPi. Außerdem deaktiviere ich meist den Java HM-Server (geht mit CUxD-Maintenance), weil der nur für die CCU-Diagramme, Gruppen (bei Heizungsthermostaten), die Erstinitialisierung der SD-Karte und den Gerätefirmwareupdate über das WebUI benötigt wird.
      Liebe Grüße Jens

  4. Hallo Herr Stern,

    ich benutze seit fast 2 Jahren das Skript und bedanke mich dafür!
    Bin vor ja 4 Monaten auf diese Variante mit den reduzierten Systemvariablen umgestiegen.
    Lief alles bis vor 2 Tagen gut, bis ich auf die aktuelle Firmware von der CCU aktualisiert hatte.
    Seit dem wird wird die Brennerlaufzeit (Tag Woche Monat Jahr) auf 0 gerechnet somit auch der Verbrauch. Haben Sie schon auf die neuste FW gewechselt und ähnliche Erfahrungen gesammelt? Hoffe ich finde den Fehler bald, da sonst die Highchart unschön aussehen.

    Hoffe auf Feedback.
    Viele Grüße aus Franken
    Fruehwi

  5. Bevor ich mir eine 2. CCU2 zulegen würde, würde ich mir einen Raspberry zulegen, um darauf IObroker zu installieren..
    Danach erst mal alle unwichtigen Programme auf IObroker zu portieren.
    Nein, die Programme werden auf der CCU2 nicht gelöscht, sondern nur deaktiviert. Sollte es zu Problemen kommen, kann man die Programme einfach wieder aktivieren und gut is.

Kommentare sind geschlossen.

WordPress Cookie Plugin von Real Cookie Banner