HomeMatic-Forum / FHZ-Forum forum

Hallo zusammen, ich brauch (mal wieder) eure Hilfe Für unsere Aussenrollos im Treppenhaus habe ich 2 FROLL mit einem HMIP-WRC6 per DV verknüpft. Den WRC6 habe ich um 90° gedreht verbaut damit - links unten/oben den linken FROLL - rechts unten/oben den rechten FROLL - mitte unten/oben beide FROLL bedient. Das ganze klappt auch soweit wunderbar und meine Frau (und auch ich) sind happy - für den kurzen Tastendruck. Der lange Tastendruck macht ja - fahr solange gedrückt wird - auch das funktioniert, wird aber nicht wirklich genutzt - weder von meiner Frau noch von mir. Jetzt wollte ich mal bei euch Experten-Einstellungs-Versteher nachfragen ob ich den langen Tastendruck "missbrauchen" könnte um die beiden FROLL auf eine bestimmte Position zu fahren? Also - langer Tastendruck ausgeführt und losgelassen und FROLL fährt bis x% Position erreicht. Hintergrund: Die beiden Aussenrollos sind, wie schon geschrieben, aussen am Treppenhaus verbaut mit Ausrichtung SO. Das Treppenhaus, und somit auch die Rollos, gehen vom EG (eher halber Keller) bis ins OG (eher halbes OG). Der Treppenaufgang vom EG ins OG ist eine offene Holztreppe, also nur die Stufen zum draufsteigen wo man durschauen kann. Vom EG in den Keller haben wir dann eine normale Betontreppe mit Fliesen (der Keller ist Vollbeton und vom EG bis ins Dach ist Holzriegelbauweise mit Kaltdach). Zwischen EG und OG haben wir ein Podest und da wäre es genial wenn mit einem langen Tastendruck die Rollos bei dem Podest stehen bleiben würden

Vielen Dank Roland für die schnelle Hilfe. Ich habe zwei Zentralen mit gleicher Hardwareausstatung (Rasperry PI 4, SSD über USB und abgesetzten Funkmodulen). Die Homematic Installation umfasst mehr als 100 Geräte (Homematic und HomematicIP) und einer großen Anzahl von Direktverbindungen und Programmen. Zusätzlich 2 HMIP-HAPs. Die eine Zentrale ist immer das Produktionssystem, die andere nicht aktive Zentrale kann im Notfall mit dem täglichen Backup das Produktionssystem ersetzen. Die Firmware der Systeme sind immer gleich. Ich wollte nun die nicht aktive Zentrale nutzen und es mit der neusten OpenCCU Version flashen, das aktuelle Backup einspielen und es als Produktionssystem nutzen. Ist diese Vorgehensweise sinnvoll und habe ich eine Chance, falls das neue System nicht funktioniert, die bisherige Zentrale wieder zu nutzen. Bei der großen Installation wäre es ein Rettungsanker. Statistik: Verfasst von ehohz — 22.09.2026, 20:10

Zumindest /tmp ist ein tmp Filesystem, das solle sich automatisch leeren bei jedem Boot. /usr/local/tmp ist ein anderer Schnack, das sollte erstmal alles Alte explizit rausgeputzt bekommen bevor der Download von neuem Zeug gestartet wird. checkFirmwareUpdate.sh macht das so. Statistik: Verfasst von joerg_rw — 22.09.2026, 19:26

noch mal starten und schauen, ob ich "Bewegung" im /usr/local/tmp habe Vorher mal prüfen ob in /usr/local und in /tmp genug Platz vorhanden ist. Das .tgz ist ~ 370MB groß, diese Größe muss in beiden Locations verfügbar sein. CODE: # df -hFilesystem Size Used Available Use% Mounted on/dev/root 975.9M 520.0M 388.7M 57% /devtmpfs 480.9M 0 480.9M 0% /devtmpfs 485.4M 0 485.4M 0% /dev/shmtmpfs 485.4M 100.0K 485.3M 0% /tmptmpfs 485.4M 84.0K 485.3M 0% /runtmpfs 485.4M 636.0K 484.8M 0% /vartmpfs 485.4M 0 485.4M 0% /media/dev/mmcblk0p3 2.0G 46.3M 1.9G 2% /usr/local/dev/mmcblk0p1 255.7M 38.6M 217.2M 15% /mnt/boot_par Hier kommt des Rätsels Lösung: warum auch immer gab es in /tmp CGI*.2 Reste von Installationen, so dass der Speicherplatz dort zu gering war. Ich habe über ssh die Fragmente in /tmp sowie /usr/local/tmp beseitigt und den Upload über die WebUI neu gestartet. Im usr/local/tmp wurden dann die Päckchen abgelegt, nach /tmp zusammengepackt (in usr/local/tmp gelöscht). Anschließend wurde alles automatisch nach usr/local/tmp wieder entpackt und das Upgrade gestartet. Upload (inkl. Backup) , entpacken ca. 10-15 Minuten und Neustart mit roter Lichtorgel CCU3 ... ... warten ... bei mir ca. ... Statistik: Verfasst von ccu-user-42 — 22.09.2026, 18:46

Hallo! betreibe ich auch 2 HMIP-HAPs zur Reichweitensteigerung. ]...} Muss ich etwas anpassen, damit sie unter OpenCCU erkannt und in gleicher Weise laufen? Nope. Völlig unauffällig. Auch die klassischen HM-LAN-Gateways. Roland Statistik: Verfasst von Roland M. — 22.09.2026, 18:09

Hi, er ist schmaler und flacher und in der Kombination ist der Unterschied in der Praxis schon erheblich. Gruß Gerti Statistik: Verfasst von Gerti — 22.09.2026, 18:00

Der DLP ist laut technischen Daten genau 13 Millimeter schmaler als der DLD. Das macht 6,5 Millimeter mehr Luft von der Zylindermitte aus gemessen. Ich würde sagen, die Anzahl an Türen, an denen der DLP im Vergleich zum DLD wegen 6,5 Millimetern noch an der Zarge vorbei passt, dürfte sich in Grenzen halten. Statistik: Verfasst von Artie — 22.09.2026, 17:58

Wie alt ist denn die Firmware der Zentrale? Aktuell? Wie hoch ist CS? Statistik: Verfasst von Matsch — 22.09.2026, 17:56

Ich habe noch eine Nachfrage. In meiner jetzigen Raspberrymatic Version betreibe ich auch 2 HMIP-HAPs zur Reichweitensteigerung. Sie laufen dort ohne Probleme. Muss ich etwas anpassen, damit sie unter OpenCCU erkannt und in gleicher Weise laufen? Vielen Dank. Statistik: Verfasst von ehohz — 22.09.2026, 17:53

Hallo Markus! Hi, die Umfrage müsste man mal wieder neu aufsetzen, oder? Ja, ist mir bewusst! Leider lassen sich in der Forensoftware Umfragen nachträglich nicht mehr ändern, ohne dass alle Eingaben verloren gehen. Somit möchte ich noch etwas warten, bis das endgültige Vorgehen mit der originalen CCU bekannt ist (angefangen von der dann richtigen Namensgebung), Alex' Entscheidung zur Zukunft von piVCCU/debmatic feststeht, aber sich auch möglicherweise Sebastians aktuell entwickelndes Projekt OpenCCU-lite schon etabliert hat. Ähnliches gilt natürlich auch für Umfrage zur Middleware, wo Home Assistent massiv fehlt. Also bitte noch etwas gedulden! Roland Statistik: Verfasst von Roland M. — 22.09.2026, 17:42

Der LGW ist noch eine Homematic Version Vermutlich RaspberryMatic. Könnte man mal updaten, muss man aber nicht. Am LGW-Code wurde ewig nichts gemacht, meins läuft mit der letzten OpenCCU für Pi2 (3.85.7.20260131) und verbindet sich problemlos mit der 3.89.11.20260919. Es gibt auch keine Änderungen zwischen 0914 und 0920 die ein LGW betreffen. Zumindest sehe ich da erstmal nix. Ich werde morgen mal ein Update des Gateways auf Vers 919 machen und mal schauen, was passiert. Statistik: Verfasst von ereus — 22.09.2026, 17:38

IP des LGW angegeben in der OpenCCU, oder nicht? Ich _vermute_ das macht gegebenenfalls nen Unterschied, falls nur broadcast(?) oder nur IP-Adresse behandeln einen Treffer hat. In dem Zusammenhang wuerde ich wohl auch mal nen Blick auf die Netzwerk- und Firewall-config werfen Statistik: Verfasst von joerg_rw — 22.09.2026, 17:36