Es handelt sich nicht um ein fertiges Produkt, welches man kaufen kann, sondern um eine Nachbauanleitung für den Raspberry Pi mit funktionierender Software. Durch das Open Source Prinzip kann die Software erweitert werden, sodass eine komplette Steuerung der Anlage nach eigenen Wünschen möglich ist. Die ausgelesenen Daten werden in einer Influx Datenbank gesammelt und können dann mit dem Open Source Programm Grafana dargestellt werden. Dabei ist es wichtig, dass der Nutzer selbst die Anzeige ändern oder auch ganz neu gestalten kann. Dazu sind keine Programmierkenntnisse nötig. Es reicht, wenn man sich etwas damit beschäftigt. Dadurch kann die Anzeige genau die Daten enthalten, die für einen wichtig sind. Ein Beispiel ist hier zu sehen:

SmartSolar Regler 150/85 von Victron

In der Influx Datenbank sind mehr Daten enthalten, wie in der Ansicht dargestellt werden. Auch können die Daten noch mathematisch bearbeitet werden. So kann z.B. die Summe pro Monat oder pro Jahr dargestellt werden. Auch die Summen mehrerer Monate oder Jahre sind möglich. Durchschnittswerte können gebildet werden, und vieles mehr. Die Influx Datenbank ist besonders für das Speichern zeitlicher Abläufe geeignet.

Weiterhin können die Daten an eine Smart Home Zentrale übermittelt werden, damit diese die Daten verarbeiten kann. Die geänderten Schaltzustände können dann wieder zurück zum Raspberry gesendet werden. In der oberen Anzeige ist z.B. unten links zu sehen, dass die HomeMatic aufgrund der gelieferten Daten den 80 Liter Wasserboiler eingeschaltet hat. Die Sonnenenergie reicht dafür in diesem Fall aus.

Die ausgelesenen Daten können weiterhin an eine Influx Datenbank im lokalen Netz oder im Internet gesendet werden. Zusätzlich können dann noch, aufgrund der Daten, Nachrichten an Desktop Browser oder an Handys gesendet werden. Als Warnung oder Erinnerung.

Funktionsweise lokal und im lokalen Netzwerk

Die gesamte Software befindet sich auf einem Raspberry Pi 2B oder 3B oder 3B+ oder 4B Als Betriebssystem wird das Raspbian benutzt. (Linux) Die komplette Software befindet sich in einem Image, dass sich auf dem Support Forum solaranzeige.de im Bereich „Download“ befindet und von dort herunter geladen werden kann. Den Bereich kann man jedoch nur nach einer Registrierung erreichen. Die Registrierung ist kostenlos und verpflichtet zu nichts.

Das Image kann dann mit dem Windows Programm „Win32DiskImager“ auf eine SD-Karte oder einen USB-Stick übertragen werden. Ein einfaches kopieren geht nicht!
Mit einer SD-Karte bootet der Raspberry schneller, jedoch gibt es nach 2-3 Monaten meist lese Probleme, wenn der Raspberry Pi im Keller installiert oder der Außenluft ausgesetzt ist. In diesen Fällen sollte man das Image auf einem USB Stick übertragen und diesen als Speicher nutzen. Das Raspberry Pi Modell 3B+ kann direkt von einem USB Stick booten. Eine SD-Karte ist nur zu empfehlen, wenn der Raspberry sich in einem trockenen und warmen Raum befindet. Das Modell 4B kann im Moment noch nicht von einem USB Stick booten, das soll aber mit einem der nächsten Updates kommen. (Stand September 2019)

Das Image beinhaltet die gesamte Software für das Auslesen aller hier aufgeführten Geräte:

• IVT Regler SCplus und SCDplus benötigt Image Software Version 4.0.x
• Steca TAROM 6000 und TAROM 4545 benötigt Image Software Version 4.2.3
• Steca Solarix PLI 5000-48 benötigt Image Software 4.0.x
• Regler der Tracer Serie z.B. von Solar XXL benötigt Image Software Version 4.0.x
• Victron BlueSolar und SmartSolar Regler benötigen Image Software 4.0.x
• Victron BMV 700 benötigt Image Software ab Version 4.2.1
• Victron Phoenix Wechselrichter mit VE.Direct Anschluß benötigt Image Software ab Version 4.2.3
• AEconversion INV Wechselrichter benötigt Image Software 4.0.x
• Effekta AX Serie benötigt Image Software 4.0.x
• Voltronic Axpert Serie benötigt Image Software 4.0.x
• InfiniSolar PIP Serie benötigt Image Software 4.0.x
• InfiniSolar V Serie benötigt Image Software ab 4.0.x
• MPPSolar PIP HSE/MSE Serie benötigt Image Software 4.0.x
• MPPSolar PIP-MS/MSX SERIES benötigt Image Software ab 4.0.x
• MPPSolar MPI Hybrid 3-Phasen 10kW benötigt Image Software ab 4.1.5
• SolarMax S-Serie und MT-Serie benötigt Image Software ab 4.5.2
• Fronius Symo Serie, ECO Serie oder IG Plus mit MODBUS TCP Schnittstelle benötigt Image Software ab 4.2.3
• AutarcTech Joulie-16 BMS Batteriemanagementsystem benötigt Image Software ab 4.2.4
• Rover-Serie Laderegler von Renogy benötigt Image Software ab 4.2.5
• US2000 B Batterie-Management-System benötigt Image ab Version 4.2.8
• SolarEdge Wechselrichter benötigt Image ab Version 4.2.8
• KOSTAL Pico und Plenticore Serie Wechselrichter mit MODBUS TCP Anschluss benötigt Image ab Version 4.2.8
• KOSTAL Pico Wechselrichter mit RS485 Anschluss benötigt Image ab Version 4.5.2
• FSP Solar PowerManager Hybrid Serie benötigt Image ab Version 4.2.8
• S10E und S10 mini von E3/DC benötigt Image ab Version 4.3.1
• eSmart3 Laderegler benötigt Image ab Version 4.3.5
• Toyo MPPT Laderegler von SRNE benötigt Version 4.5.0
• Smart Energy Meter von KOSTAL und anderen Anbietern benötigt Version 4.5.3 (Fronius?)
• Sonoff POW R2 / TH10 / TH16 benötigt Version 4.5.6
• Infini x KW Hybrid Wechselrichter und Baugleiche (Protokoll 16) benötigt Version 4.5.4
• Sonnen Batterien benötigt Version 4.5.5
• MPPSolar 5048 MK und GK Serie benötigt Version 4.5.6 + Update

Während der Installation gibt man dann an, welches Gerät ausgelesen werden soll. Dafür wird auch noch ein Verbindungskabel zum Gerät benötigt. Es kann ein spezielles Kabel vom Hersteller oder aber auch ein einfaches USB oder Netzwerkkabel sein. Das hängt vom Hersteller und vom Gerätetyp ab. Die Software läuft Hersteller übergreifend, d.h. es können Geräte unterschiedlicher Hersteller ausgelesen und diese Daten dann zusammengeführt werden.

Die ausgelesenen Daten werden von der Software in eine Influx Datenbank geschrieben, die sich auf dem Raspberry Pi befindet. Auch ist das Programm Grafana dort installiert. Mit dem Aufruf:

http://solaranzeige.local:3000

kann im lokalen Netzwerk dann die Solaranzeige aufgerufen werden. Falls der DNS Server im Router das nicht unterstützt, bitte folgendes aufrufen:

http://xxx.xxx.xxx.xxx:3000

Sollte kein lokales Netzwerk existieren, kann auch ein HDMI-Monitor an den Raspberry Pi angeschlossen werden, um direkt vor Ort die Solaranzeigen zu sehen.

Steuerung der Wechselrichter / Laderegler usw.

Einige Geräte können auch direkt per HTTP Aufruf gesteuert werden. Da dies jedoch je nach Hersteller sehr unterschiedlich ist, nachfolgend nur ein Überblick. Sofern eine solche Kommunikation gegegen ist, können darüber auch Einstellungen geändert werden. Dies geschieht - wie gesagt - über einen HTTP Aufruf oder über MQTT. Theoretisch auch parallel in unterschiedlichen Geräten unterschiedlicher Hersteller!

Solltest Du soetwas vorhaben, dann melde Dich bitte beim:

Zur Zeit sind nur einzelne Befehle von einzelnen Geräten implementiert. Der Vorteil der HTTP / MQTT Aufrufe ist, dass solche Änderungen im Gerät auch ganz automatisch (z.B. über eine SmartHome-Zentrale) ablaufen können.

Steuerung der Solaranlage über HomeMatic

Mit den Informationen des Ladereglers können gezielt Verbraucher nur dann eingeschaltet werden, wenn z.B. im Moment wenig Energie verbraucht wird oder sehr viel PV-Leistung erzeugt wird. Der Raspberry Pi überträgt die Werte mit einem HTTP GET Aufruf auf Port 8181 zur HomeMatic.

Da die Anleitung zur Konfiguration bzw. Inbetriebnahme den Rahmen an dieser Stelle sprengen würde, sind die wichtigsten Informationen dazu unter folgenden Links zu erreichen:

Mittlerweile wurde das Projekt "Solaranzeige" vom Entwickler um einige neue Features ergänzt und erlaubt nun u.a. die grafische Darstellung der gesendeten Messwerten von (fast) allen angeschlossenen HomeMatic-Geräten wie z.B. Heizkörperventilen, Gaszählern, Lichtsensoren oder Wandthermometern.

Der folgende Screenshots zeigt z.B. ein mit einem Fensterkontakt gekoppeltes Heizkörperventil im Badezimmer:

Mit der Solaranzeige können ~ 20-30 HomeMatic-Geräte ausgelesen und dargestellt werden. Damit das funktioniert, ist die Zusatzsoftware "XMP-API" auf der HomeMatic Zentrale zu installieren.

Im Zuge der Erweiterungen wurde auch das Dokument HomeMatic Anbindung aktualisiert.

Anbei noch ein paar weitere Screenshots:

Die Integration erfolgt dabei auf einem Raspberry Pi mit RaspberryMatic sowie dem AddOn „RedMatic“, das es so aber auch für die CCU3 (und anderen Systemen, wie z.B. der Smartha Zentrale von Easy SmartHome) gibt.

Wie bereits in der Einleitung beschrieben, sollen folgende Funktionen abgedeckt werden:

• Anzeige des aktuellen Covers
• Anzeige des aktuellen Titels sowie des Albums & Interpreten
• Anzeige der aktuellen Wiedergabeposition
• Bedienung der Funktionen „Pause“, „Wiedergabe“, „Voheriger Titel“ und „Nächster Titel“

Da die wichtigsten Dinge direkt über RedMatic bzw. die CCU umgesetzt werden, können die hier gewonnenen Informationen aber auch für andere Visualisierungslösungen herangezogen werden.

RedMatic / NodeRed

Für RaspberryMatic bzw. die CCU3 (und andere Zentralen) gibt es mit NodeRed eine sehr leistungsfähige, grafische Entwicklungsumgebung, mit der man unterschiedliche Systeme miteinander verbinden kann. Über so genannte „Nodes“ wird dabei die Funktionalität abgebildet und innerhalb eines „Flows“ visualisiert. Neben einfachen String- und Logikoperatoren sind aber auch komplexere Aufgaben möglich, wie z.B. das Abfragen und „Parsen“ von Statusinformationen über HTTP-Requests (Müllkalendern, Feiertage & Ferien, ...) oder der Einbindung von HomeConnect Geräten (Geschirrspülmaschinen oder Kaffeevollautomaten, ...), FritzBox, usw.

Die Einbindung von NodeRed in die HomeMatic Landschaft erfolgt über die Zusatzsoftware „RedMatic“, die wie jedes andere AddOn zu installieren ist. Auf YouTube & Co. gibt es dazu unzählige Anleitungen und Tutorials. Wer mit RedMatic zuvor noch nicht gearbeitet hat, dem sei auch das Wiki (siehe Links am Ende der Anleitung) ans Herz gelegt, die sämtliche, von Haus aus zur Verfügung stehenden Nodes (teilweise an Beispielen) ausführlich erklärt.

Das Prinzip

Ziel ist ja u.a. die Darstellung des aktuellen Covers sowie der Titelinformationen auf einer Fernbedienungsseite des AIO Creator NEO. Diese Statusinformationen werden üblicherweise über ein Textfeld abgebildet, das mit einer Variable (aus einem Gateway) zu verbinden ist. Das Gateway ist an dieser Stelle die CCU, auf der also entsprechende Systemvariablen anzulegen sind. Ferner soll es möglich sein, über die Fernbedienung den aktuell gespielten Spotify-Titel anzuhalten, die Wiedergabe fortzusetzen bzw. zum nächsten/vorherigen Lied zu springen. Dafür benötigt man in NEO eine Taste, die mit einem Gerätekanal zu verbinden ist. Da wir in der CCU aber kein „Spotify“-Gerät haben, müssen wir uns eines „basteln“. Dazu legt man z.B. eine virtuelle Fernbedienung über den „CUx-Daemon“ an oder einfacher: man benutzt die virtuellen Kanäle der CCU.

Systemvariablen anlegen

Für die Übermittlung der Titelinformationen müssen entsprechend viele Systemvariablen angelegt werden. Die folgende Tabelle zeigt eine möglich Auswahl sowie die jeweils dazugehörigen Datentypen:

Das aktuelle Coverbild wird ebenfalls über eine Variable vom Typ „Zeichenkette“ abgebildet und enthält später eine URL. Findet aktuell keine Wiedergabe über Spotify statt, soll die URL zu einem Standardbild führen, das stattdessen dargestellt wird (z.B. das Spotify-Logo).

Virtuelle Kanäle benennen

Die virtuellen Kanäle lassen sich über die Geräteliste der WebUI definieren. Dazu sucht man in dieser nach dem Namen „HM-RCV-50“ (Virtuelle Fernbedienung / Drahtlos) und klappt den Eintrag mit einem Klick auf „+“ auf. Nun sucht man sich drei unbenutzte Kanäle aus und benennt diese z.B. wie folgt:

NodeRed vorbereiten

Nachdem nun die Grundvoraussetzungen geschaffen wurden, geht es an‘s Eingemachte. An dieser Stelle sei nochmals erwähnt, sich die verfügbaren Einführungsvideos zu RedMatic bzw. NodeRed anzusehen, sofern noch nicht geschehen, um ein Grundverständnis für die nachfolgenden Schritte zu haben.

Von Haus aus gibt es keinen „Node“, um mit Spotify direkt zu kommunizieren. Diese Funktionalität muss daher zuvor nachinstalliert werden. Dazu öffnet man in der NodeRed-Oberfläche das Hamburger-Menü (rechts oben) und wählt „Palette verwalten“. Nun klickt man auf den Reiter "Installieren" und sucht nach "Spotify". Aus der Liste wählt man nun den Eintrag "node-red-contrib-spotify" und klickt auf "Installieren":

Ggf. muss nun RedMatic neu gestartet werden, damit der neue Node (spotify) in der linken Liste erscheint.

Neben dem sichtbaren Node wurde bei der Installation auch noch ein so genannter "Konfigurations-Node" eingerichtet, über den die Verbindung zur Spotify-Authorisierung (OAuth2) erfolgt. Dafür ist mit dem eigenen Spotify-Konto auf dem Dashboard der Developer-Console eine neue "App" zu erstellen:

Der „Spotify“-Flow

Nachdem nun der neue Spotify-Node verwendet werden kann (Tipp: über den Eintrag "Credentials" kann in diesem ebenfalls der Konfigurations-Node eingerichtet werden), geht es um die Erstellung der eigentlichen Logik in einen neuen Flow innerhalb der RedMatic /NodeRed Oberfläche. Dazu klickt man in der Tableiste oben auf das "+" und erhält damit einen "frischen" Flow. Als erstes zieht man nun einen "inject"-Node von der Palette auf die Oberfläche, um in einem hinterlegten Intervall (z.B. 5 Sekunden) den aktuellen Spotify-Status abfragen zu können (Polling):

Als nächstes platziert man nun einen "spotify"-Node und verbindet diesen mit dem zuvor erstellten "inject"-Node. Mit einem Doppelklick auf den Node öffnet man nun dessen Eigenschaften, wählt unter Credentials den Konfigurations-Knoten aus und wählt unter "API" den gewünschten Eintrag aus:

Es gibt dutzende Eigenschaften & Funktionen, die man über die API Dropdown-Box auswählen kann. Wir interessieren uns aber erstmal nur für die Daten des aktuell gespielten Tracks und wählen daher den Eintrag "getMyCurrentPlayingTrack". Der "Payload" aus diesem Knoten enthält danach sämtliche von uns benötigte Daten, die nur noch daraus extrahiert werden müssen. Was genau alles an Daten enthalten ist, kann man sich z.B. mit einem "debug"-Node im rechten Bereich der NodeRed Oberfläche ausgeben lassen (Auszug):

"item": {
    "album": {
      "album_type": "single",
      "artists": [
        {
          "name": "Sunlounger",
          "type": "artist",
        },
        {
          "id": "2IuTspiSwgQQs4LmvNSBIZ",
          "name": "Susie Ledge",
          "type": "artist",
        },
        {
          "id": "3dAnWbqTzCOK1jdiK2v3gI",
          "name": "Roger Shah",
          "type": "artist",
        }
      ]
   }
}    

Da Spotify diese Informationen nur bei einer aktiven Wiedergabe zurückgibt, sollte man als nächstes prüfen, ob es überhaupt etwas zu verarbeiten gibt. Sollte dies nicht der Fall sein, gibt man einfach vordefinierte Standardwerte zurück, also z.B. "Keine aktuelle Wiedergabe" für den Titel oder das Spotify-Logo als Cover. Dazu verwendet man in NodeRed einen "switch"-Node und definiert zwei Ausgänge:

Liegen Daten vor, werden diese (= Payload) über den ersten Ausgang weitergereicht und können im Nachgang weiter verarbeitet werden. Dazu kommen dieses Mal die "change"-Nodes zum Einsatz, die je eine einzelne Information aus dem Payload extrahieren, diesen damit ersetzen und an eine HomeMatic Systemvariable weiterreichen. Da der Payload eine wohl definierte JSON-Struktur enthält, lässt sich diese mit Boardmitteln von NodeRed recht komfortabel "parsen". Am einfachsten geht dies mit Hilfe von JSONata und einem entsprechend definiertem Ausdruck:

Anschließend steht der extrahierte Titel als neue Payload zur Verfügung und kann nun an HomeMatic weitergereicht werden. Dazu steht der "sysvar"-Node im Bereich "ccu" zur Verfügung. Diesen füttert man mit einem Wert (Payload) und wählt den entsprechenden Namen der Systemvariable aus, in die dieser geschrieben werden soll:

Nach diesem Schemata werden nun auch alle anderen Daten extrahiert und in die zuständigen Systemvariablen geschrieben. Die folgende Tabelle führt alle dazu benötigten JSONata Ausdrücke auf:

Für das Cover wurde eine Auflösung mit einer Höhe von 640 Pixels gewählt, die für meine AIO CREATOR NEO Fernbedienungsseite genau passt. Alternativ stehen auch noch andere Auflösungen parat. Die aktuelle Position innerhalb des gespielten Titels wird mit Hilfe einer kleinen Formel in einen Prozenzwert (0-100%) überführt. Der Status gibt lediglich an, ob die Wiedergabe gerade pausiert wird oder nicht. Spotify wartet eine Zeit lang, bevor die pausierte Wiedergabe komplett gestoppt wird (und die Abfrage der Daten leer ist, siehe oben).

Liegen aktuell keine Daten vor, wird der 2te Ausgang des "switch"-Nodes getriggert. Auch hier kommen wir die "change"-Nodes zum Einsatz, um die Systemvariablen mit sinnvollen Standard-Daten zu füttern:

Da nun alle Daten an HomeMatic Systemvariablen weiter gereicht wurden, geht es um die Fernsteuerung von Spotify, also dem Pausieren und Weiterspielen des aktuellen sowie der Anwahl des nächsten bzw. vorherigen Titels. Dazu wurden ja bereits weiter oben die benötigten virtuellen Geräte konfiguriert, die nun zum Einsatz kommen.

Mit Hilfe des "rpc event"-Nodes aus dem Bereich "ccu" haben wir einen passenden Trigger, der die entsprechende Aktion auslöst. In diesem wählen wir nun unsere CCU und unter "Interface" den Eintrag "BidCos-RF" aus. Unter "channelName" ist letztendlich der Name des virtuellen Gerätes zu wählen, also z.B. "CCU#Spotify.Next", um einen Titel weiter zu springen:

Dieser Node wird nun einfach mit der entsprechende Funktion aus dem Spotify-API verbunden, in unserem Fall also mit "skipToNext":

Das Gleiche wird anschließend mit "skipToPrevious" gemacht, um zum Beginn bzw. vorherigen Titel zu springen. Etwas tricky ist die Toggle-Funktion zum Pausieren bzw. Weiterspielen des aktuellen Tracks. Dazu muss zunächst ermittelt werden, wie der Status der Wiedergabe aktuell ist - was wir allerdings weiter oben bereits erledigt haben...doch wie kommen wir da nun ran?

Hier machen wir uns den so genannten "Flow"-Container zu Nutze, in dem alle möglichen Objekte innerhalb eines Flows geschrieben und auch wieder gelesen werden können. Bei der Ermittlung der aktuellen Titeldaten schreiben wir den Status der Wiedergabe einfach in diesen Container:

Auf diesen Wert können wir nun innerhalb des Flows jederzeit zugreifen, um in unserem Fall dann zu entscheiden, ob die aktuelle Wiedergabe pausiert oder fortgesetzt werden soll. Dazu schalten wir hinter den "rpc event"-Node den bereits bekannten "switch"-Node, definieren zwei Ausgänge, und lösen danach die entsprechende Aktion in Spotify aus:

Die Ausgänge der Steuer-Nodes sind dabei mit dem Eingang des ersten Spotify-Nodes verbunden, um die Titeldaten nach der jeweiligen Aktion (Pause/Play/Prev/Next) sofort zu aktualisieren.

Geräte & Systemvariablen in NEO importieren

Wenn der Flow dann wie gewünscht funktioniert, kann man die eigentliche Visualierung bzw. Ansteuerung von Spotify im AIO CREATOR NEO angehen. Dazu importiert man als Erstes die zuvor im WebUI der CCU angelegten Systemvariablen und virtuellen Aktor-Kanäle. Um die virtuellen Kanäle überhaupt sehen zu können, ist zuvor die Option "Geräte ohne Raum ausblenden" im Import-Dialog zu deakivieren, falls in der WebUI diesen zuvor kein Raum (Default) zugewiesen wurde.

Anschließend markiert man die gewünschten Einträge in den jeweiligen Kategorien und klickt auf „Importieren“. Die Variablen und Tastenaktionen stehen dann für die Integration in die Fernbedienungsseiten zur Verfügung.

Die Visualisierung

Da jeder seine Fernbedienung nach eigenem Geschmack gestaltet, möchte ich an dieser Stelle auf das Design nicht weiter eingehen. Vom Prinzip her lassen sich die Angaben zum Titel einfach über "Textfelder" in NEO abbilden. Dazu verknüpft man den Status des Feldes mit der zuvor importierten Systemvariable (die ja nun durch NodeRed automatisch gefüllt wird) und formatiert diese wie gewünscht:

Die Wiedergabeposition habe ich in meinem Beispiel über einen "Slider" visualiert und auch hier einfach der entsprechenden Systemvariable (Spotify.Fortschritt) zugewiesen. Das Interval geht hierbei von 0-100 in 1-er Schritten. Die Bedienung wurde über die entsprechende Option deakviert, da es sich hierbei nur um einen Lese-Wert handelt. Über einen ensprechenden API-Aufruf wäre aber auch ein Verändern der Wiedergabeposition möglich.

Die Anzeige des Covers übernimmt ein Webseiten-Element, dem allerdings keinerlei Webseite (Eintrag: "X ---") zugewiesen wird. Vielmehr wird auch hier wieder die entsprechende Systemvariable (Spotify.Bild) im Status ausgewählt, um die URL (Adresse des Bildes) dem Element zur Verfügung zu stellen. Den Aufbau der darzustellenden Seite definiert man über die Funktion "HTML-Gerüst festlegen":

Im Bereich "Dokumenten-Beginn" wählt man nun den Eintrag "Benutzerdefiniert" und fügt folgenden Quellcode hinzu:

<!DOCTYPE html><html>
<head>
    <meta charset="utf-8" />
    <style>
    body { 
        background-color: transparent;
    }
    </style>
<head>
<body>

Der Inhalt kann natürlich den eigenen Vorstellungen entsprechend angepasst werden. Erwähnenswert ist hierbei nur der Sytle-Abschnitt für den HTML-Body, dessen Hintergrundfarbe auf transparent gesetzt wurde.

Im Hauptbereich definiert man nun dass darzustellende Bild (Cover), das über den Status an dieses Element weitergegeben wurde:

Die URL steht dabei in der Variable "%neo_state%" zur Verfügung und wird als Quelle (src) an das HTML-Image übergeben. Die beiden Attribute "width" und "height" sorgen lediglich für eine 100%-tige Darstellung innerhalb des Webseiten-Elements.

Im Bereich "Dokumenten-Ende" wird die Webseiten-Struktur mit folgendem Code wieder sauber "geschlossen":

</body></html>

Die zuvor möglichen Bedienaktionen lassen sich über "Button"-Elemente realisieren, deren Aktionen die virtuellen Tastendrücke auslösen (die wiederum im NodeRed Flow die Spotify-API ansprechen):

Wie geht's weiter?

Die Spotify-API wurde hier nur am Rande angekratzt und bietet jede Menge weiterer Möglichkeiten. So liese sich das aktuell gespielte Lied z.B. in die eigene Bibiliothek übernehmen oder man könnte veranlassen, dem aktuellen Künstler zu folgen oder die Wiedergabelautstärke zu ändern. Das würde aber den Umfang dieses Artikel sprengen...

]]>

Alternativ kann man an der Stelle, an der das Einscannen des QR-Codes verlangt wird, auch einfach die letzten 4 Ziffern der SGTIN eingeben - diese ist direkt auf dem Gerät aufgeklebt und besteht aus Zahlenblöcken, die durch einen Bindestrich voneinander getrennt sind.

Sollte aber auch dieser Aufkleber abhanden gekommen sein, ist ein Anlernen der Geräts leider nicht mehr möglich. In diesem Fall muss die Komponente eingeschickt und durch den Hersteller neu "geflasht" werden.

In der Regel kommt bei den Homematic IP Geräten das Background Update zum Einsatz. Dabei wird die Firmware des Geräts im Hintergrund per Funkverbindung aktualisiert. Einige andere Geräte werden über ein Live Update, welches direkt in der Homematic IP App durchgeführt werden muss, auf den aktuellen Stand gebracht.

• Homematic IP Schaltsteckdose (HmIP-PS)
• Homematic IP Schalt-Mess-Steckdose (HmIP-PSM)
• Homematic IP Schaltplatine (HmIP-PCBS)

Das Homematic IP System basiert auf der gleichen, besonders leistungsfähigen und robusten Funktechnik, die sich bereits in Millionen von Geräten bei Homematic, MAX! und auch RWE Smart Home (innogy) bewährt hat. Dadurch wird eine Reichweitenerhöhung i. d. R. nicht benötigt.

Je nach anliegender Last erkennt der Aktor, ob z.B. der Rollladen fährt oder eine Endposition erreicht hat. Die Messfunktion erwartet zu Beginn der Fahrt eine Mindestlast von 5 Watt am Ausgang des Aktors. Unter gewissen Bedingungen, wie bei der Verwendung eines Trennrelais zur Ansteuerung mehrerer Motoren über einen Aktor oder bei motorspezifischen Eigenschaften wie einer Anlauframpe, wird diese Last nicht erreicht und der Aktor stoppt die Fahrt sofort. Bei der Verwendung eines Trennrelais empfehlen wir die Deaktivierung der Option "Automatische Erkennung der Endposition". Führen Sie eine manuelle Kalibrierfahrt durch. Gehen Sie dazu in die "Geräteübersicht" und wählen Sie das Gerät aus der Liste.

Wurde bei der Einrichtung bereits eine manuelle Kalibrierung durchgeführt, ist die Messfunktion von Beginn an deaktiviert.

Kann der Access Point bei der Inbetriebnahme jedoch keine Verbindung zur Homematic IP Cloud aufbauen (signalisiert durch blaues Blinken der Systemtaste), kann dies an den individuellen Einstellungen Ihres Routers liegen. Deaktivieren SIe bitte auch den Energiespar-Modus (in vielen Fällen auch Greenmode genannt) für den Port des Routers, an dem Sie der Homematic IP Access nicht an einem Port des Routers angeschlossen ist.

Für einen reibungslosen Betrieb des Homematic IP Systems muss die Kommunikation über folgende TCP-Ports dauerhaft möglich sein:

Kommunikation zwischen HAP und Cloud: 9292 und 43439
Kommunikation zwischen Smartphone-App und Cloud: 6969, 8888 und 48335

Kann dennoch keine Verbindung zur Cloud aufgebaut werden, prüfen Sie, ob Sie BitTorrent in den Zugangsprofilen Ihres Routers (Ihrer Fritzbox) gesperrt haben.

Bei individuellen Fragen zu den Routereinstellungen kontaktieren Sie bitte Ihren Internetprovider oder den Routerhersteller.

Dies gilt in besonderem Maße für Gegenstände, die selbst Funkwellen aussenden:

• WLAN Router
• DECT-Stationen
• Fernseher
• Computer
• Funklautsprecher und Funkheadsets
• Audio- und Videoanlagen
• Alarmanlagen
• Mobiltelefone und schnurlose Telefone
• Mikrowellengeräte
• Vorschaltgeräte für Leuchtstofflampen
• Babyphone
• uvm.

Diese Störungen lassen sich weitgehend reduzieren, indem man einen möglichst großen Abstand zwischen Funk-Komponenten und solchen potenziellen Störquellen einhält.

Wir empfehlen einen freien Aufstellort für die Zentrale oder den Access Point ohne die o.g. Störquellen in direkter Nähe (im Idealfall mind. 1 m Abstand), um eine optimale Funkabdeckung zu erreichen.

Im Vergleich mit anderen Systemen bieten Homematic IP Aktoren den deutlichen Vorteil, dass cloudunabhängige Funktionen, wie beispielweise Heiz- und Zeitprofile und die Kommunikation einzelner Geräte untereinander, dank eines integrierten Speichers auch ohne aktive Internet- und Cloudverbindung autark bestehen bleiben. Cloudabhängige Funktionen sind alle unter Automatisierungen erstellten Regeln, Beschattungskonfigurationen wie Aussperrschutz, Sturmschutz, Wärmeschutz oder Fluchtfunktion sowie die Einbindung von Sprachsteuerungsdiensten. Diese werden in der Cloud geprüft und benötigen immer auch eine aktive Internet- und Cloudverbindung. Es empfiehlt sich, die Homematic IP Geräte über Gruppenfunktionen, wie z. B. Licht- und Beschattungsgruppen, zu verbinden. Dies reduziert zum einen den Funkverkehr, zum anderen bleiben alle über diese Gruppen erstellten Verbindungen auch ohne Internetverbindung weiterhin funktional.

Beim Einsatz von Sprachsteuerungsdiensten wie Amazon Alexa oder Google wird zudem empfohlen, zusätzlich Homematic IP Fernbedienungen oder Taster zum Steuern Ihrer Geräte zu verwenden, um zu jeder Zeit Ihre Komponenten auch ohne aktive Sprachsteuerung ein- und ausschalten zu können.

Die nachfolgende Übersicht zeigt mögliche Funktionen mit und ohne aktive Internetverbindung:

Möchte man RaspberryMatic auf einem kompatiblen Board installieren oder ein Firmware-Update machen, sind ein paar Dinge zu beachten, die in diesem Artikel beschrieben werden.

RaspberryMatic Image installieren

Vor der eigentlichen Installation ist zunächst darauf zu achten, dass man ein kompatibles Board am Start hat. Als nächstes muss man auf der Downloadseite das richtige Image für die Hardware-Platform wählen. Aktuelle Images stehen auf folgender Seite zum Download bereit:

Nach dem Herunterladen muss das ZIP-Archiv entpackt werden. Diese enthält eine Image-Datei mit der Endung ".img", die mit Hilfe eines kleinen Tools auf die microSD-Karte (vom RaspberryPi) kopiert werden muss.

Das Tool ist selbsterklärend und besteht im Prinzip nur aus der Auswahl des Images - der Rest wird von selber erledigt. Die vorbereitete microSD-Karte steckt man nun (wieder) in das Board ein und schaltet dieses ein. Während des Hochfahrens sollte die rote LED regemäßig blinken. Wurde das System ordnungsgemäß gestartet, sollte die rote LED wieder ausgehen und dafür die grüne LED im so genannten "heatbeat" Modus blinken. Nach kurzer Zeit erscheint dann das HomeMatic/Homematic IP Logo und das WebUI ist gestartet.

Firmware Update einspielen

RaspberryMatic wird ständig weiter entwickelt und so kommt man zwangsläufig an den Punkt, ein Firmware-Update durchführen zu wollen. Seit Version 2.31.25.20180428 funktioniert ein Update von RaspberryMatic genauso wie bei einer "normalen" CCU:

• Firmware-Datei über WebUI herunterladen...
• ...und über diese auf die CCU hochladen & anwenden

Bevor jedoch ein Update durchgeführt wird, sollte vorher unbedingt ein aktuelles Backup erstellt werden. Dazu meldet man sich am WebUI an und navigiert zu "Einstellungen -> Systemsteuerung -> Sicherheit -> Backup erstellen". Die dadurch erstellte Datei mit der Endung ".sbk" sollte man an einem sicheren Ort aufbewahren.

Im nächsten Schitt läd man das aktuelle Firmware-Update über "Einstellungen -> Systemsteuerung -> Zentralen-Wartung -> Herunterladen" herunter. Dabei wird man direkt auf die Projektseite von RaspberryMatic weitergeleitet:

Dort angekommen lädt man dann die aktuellste .zip-Datei für die eingesetzte Hardware-Platform (rpi3=RaspberryPi2/3, tinkerboard=ASUS Tinkerboard, rpi0=RaspberryPi0/1) herunter.

Das eigentliche Update wird letztendlich über "Einstellungen -> Systemsteuerung -> Zentralen-Wartung -> Heruntergeladene Software auswählen" hochgeladen & eingespielt.

Während des Updates blinkt die rote LED des RaspberryPi/Tinkerboard in regelmäßigen Abständen und das System wird auch automatisch insgesamt 2x neu gestartet. Wurde das Update korrekt angewendet und RaspberryMatic ist wieder betriebsbereit hochgefahren blinkt die grüne LED im sogenannten "heartbeat" Modus.

Nun kann man sich wie gewohnt auf dem frisch geupdateten RaspberryMatic mittels Webbrowser/WebUI einloggen und das Update sollte korrekt vollzogen worden sein.

Wenn's mal schief läuft

Sollte dieses Prozedere schief gehen und ein Update direkt über die WebUI nicht durchgeführt worden sein, kann man auch in das Recovery System wechseln ("Einstellungen -> Systemsteuerung -> Zentralen-Wartung -> In Recovery Modus neustarten") und das Firmware-Update darüber versuchen anzuwenden.

Lässt sich das Update auch darüber nicht anwenden, sollte man wie ersten Abschnitt beschrieben die microSD-Karte von Hand auf die neueste Version "flashen". Danach spielt man dann das zuvor angelegte Backup über das WebUI zurück.

Neuere Dimmer sollten das folgende Problem nicht mehr aufweisen, bei älteren Chargen kann dies aber durchaus nach 1-2 Jahren im Einsatz auftreten (so wie bei mir jüngst an mehreren Aktoren).

Phänomen

Der Dimmer (HM-LC-Dim1TPBU-FM) wird durch einen Tastendruck eingeschaltet, schaltet sich nach wenigen Sekunden aber wieder automatisch aus.

Beobachtung

Nimmt man den Taster ab, sodass man die Status-LED des Aktors im Blick hat, so sieht man nach dem Ein- und (nicht gewollten) Ausschalten, dass diese anfängt, mehr oder weniger periodisch zu blinken. In dieser Zeit ist eine Bedienung nicht möglich und deutet auf einen erneuten Start des integrierten Mikrocontrollers (Bootloader) hin.

Problem

Der verwendete Elektrolytkondensator (C7) hat den "Geist" aufgegeben. Dieser ist Teil des integrierten Spannungswandlers und führt bei Defekt zu einer instabilen Schaltung, die zu dem beschriebenen Problem führt.

Lösung

Sofern man im Umgang mit dem Lötkolben geübt ist, ist der Austausch des Elkos ein Leichtes. Nach dem Öffnen des Gehäuses lokalisiert man dazu den Elko C7. Neuere Bestückungen weisen bereits eine besser geeignete Variante auf, die an dem grünen Gehäuse zu erkennen ist. Besitzt der Elko noch ein schwarzes Gehäuse, handelt es sich hierbei um das "alte Modell" und sollte auf alle Fälle getauscht werden. Ein geeigneter Ersatzkondensator sollte folgende Eigenschaften aufweisen:

10µF/25V(oder 35V) mit LowESR und 110°C

Die Lage des Kondensators auf der Hauptplatine

Der Kondensator liegt nahe einem SMD-Widerstand, daher ist der Einsatz einer dünnen Lötspitze zu empfehlen. Zudem ist auf die Polarität zu achten (der Minuspol zeigt in Richtung der Platine weg!). Nach dem Austausch kann das Gehäuse wieder zusammengeklickt werden. War der Tausch erfolgreich, sollte der Aktor wieder einwandfrei funktionieren (und das Licht gemäß der Programmierung) eingeschaltet bleiben.

Zunächst einmal sollte überprüft werden, ob das Firmware-Update überhaupt für einen selber sinnvoll ist. Gemäß dem Motto "never change a running system" sollte man sich daher vorher die Frage stellen, ob das Update neue Funktionen bereitstellt, die man unbedingt benötigt. Anders sieht es aus, wenn das Update sicherheitsrelevante Fehlerbehebungen enthält. In diesem Fall macht das Update auf jeden Fall Sinn. Jetzt kann es aber vorkommen, dass das Update nicht eingespielt werden kann. Je nach verwendetem Betriebssystem und Browser äußert sich dies durchaus unterschiedlich. Im einen Fall scheint der Upload ewig zu dauern, im anderen Fall wird er erst gar nicht angestoßen (es erscheint z.B. kein Fortschrittsdialog) oder die Datei wird schlicht nicht als valides Update akzeptiert.

Was also kann ich tun?

Vor jedem Firmware-Update sollte man auf alle Fälle vorher ein System-Backup machen. Die entsprechende Funktion findest Du unter:

Je nach Umfang Deiner Konfiguration und verwendeten Zusatzsoftware (sowie verwendeten Zentrale) kann die Erstellung der Backupdatei einige Minuten in Anspruch nehmen - habe also ein wenig Geduld. Im Anschluss kannst Du einige der nachfolgenden Tipps ausprobieren, um das Firmware-Update doch noch auf die Zentrale zu bekommen:

Immer gepackte Datei verwenden

Ein Firmware-Update (sowie andere Zusatzsoftware) wird gepackt ausgeliefert. Dies erkennt man an der Dateiendung, die entweder auf ".tar", ".tar.gz" oder ".tgz" endet. Jetzt hat z.B. der Safari auf einem Mac die Angewohnheit, dieses Archiv nach dem Herunterladen automatisch zu entpacken und die Original-Datei in den Papierkorb zu legen. Da das entpackte Archiv in der Regel ein weiteres enthält (normalerweise eines, welches auf ".tar" endet), fällt einem das nicht auf. Nimmt man anstatt der Original-Datei nun diese, funktioniert das Einspielen des Updates nicht. Daher stellt man das automatische Entpacken für den Safari entweder aus, oder man nimmt die Original-Datei (aus dem Papierkorb).

Anderen Browser ausprobieren

So banal es sich anhört - der eingesetzte Browser kann u.U. dafür verantwortlich sein, dass sich ein Update nicht einspielen lässt. Das kann an alten Cache-Datein liegen oder an der Größe des Images. Auch die Browser-Version kann hier Unterschiede machen. Sollte also das Update auch nach dem Leeren des Browser-Caches nicht eingespielt werden können, sollte man es mal mit einem anderen Browser probieren. Als ziemlich zuverlässig in dieser Hinsicht hat sich bei mir z.B. der Chrome-Browser gezeigt.

Zentrale im abgesicherten Modus starten

Manchmal kann auch ein laufendes AddOn das Einspielen eines Updates verhindern. Um dies auszuschließen kann man die Zentrale daher zunächst mal im abgesicherten Modus neu starten. Bei diesem einmaligen Neustart wird die auf dem System installierte Zusatzsoftware nicht mit gestartet:

Was sonst?

Wenn alle zuvor aufgezeigten Schritte nicht zum Erfolg führen, wird es schwierig. In diesem Fall kannst Du Dein Problem mal im HomeMatic-Forum schildern. Dort wird Dir sicher jemand helfen können...

Der Einbau ist dabei relativ einfach und gemäß folgender, schematischen Zeichnung zu entnehmen:

Quelle: technikkram.net

Der ESB1 wird dabei seriell in die Phase (L) führende Leitung "eingeschleust" und kann so seinen Dienst verrichten. Dabei ist zu beachten, dass dieser für Lasten bis max. 200 VA ausgelegt und nicht für periodischen Schalten geeignet ist. Die Pausenzeit zwischen einem Schaltvorgang sollte mindestens über 30 Sekunden betragen. Bei kleineren Zeiten besteht laut ELV die Gefahr, dass der Einschaltstrombegrenzer nicht greift.

Muss ich die Firmware aktualisieren?

Bei dieser Frage kommt mir immer zuerst der bekannte Spruch in den Sinn:

Never change a running system!

Bevor Du die Firmware eines Gerätes aktualisieren möchtest stelle Dir daher zunächst die Frage, warum Du dies tun möchtest. Solange das Gerät einwandfrei funktioniert und Du auch keine Funktion(en) vermisst - die ein Firmware-Update evtl. mit sich bringt - musst Du dieses auch nicht unbedingt auf dem neuesten Stand halten.

Anders sieht es aus, wenn im Nachhinein z.B. wichtige Funktionen nachgeliefert werden oder bereits bestehende aufgrund eines Fehlers korrigiert wurden. Hier kann es dann duchaus Sinn machen, ein Firmware-Update in Erwägung zu ziehen.

Wie mache ich ein Firmware-Update?

Um diese Frage zu beantworten, muss ich zunächst ein wenig ausholen. Als das HomeMatic System (als Nachfolger zu FS20) auf dem Markt kam, war ein Firmware-Update durch den Endverbraucher überhaupt nicht vorgesehen. Wollte man dann ein Gerät auf den neuesten Stand bringen, musste man dieses an ELV einschicken wo es durch einen Techniker aktualisiert (geflasht) wurde. Dabei muss man wissen, das die HomeMatic (und Homematic IP)-Komponenten auf einem Mikroprozessor basieren. Dieser kann über eine Programmierschnittstelle mit neuer Software geladen werden. Dazu benötigt man neben einem Programmieradapter aber auch entsprechende Software sowie technisches Geschick, weshalb eine Aktualisierung durch den Verbraucher nicht so einfach möglich ist.

ELV / eQ-3

Auch heute noch muss dieser Aktualisierungsvorgang bei älteren Komponenten durch einen Techniker von ELV (eQ-3) erfolgen. Neben dem Zeitaufwand kostet ein Firmware-Update auf diesem Wege aber auch jedes Mal Geld, weshalb es in der Regel - vor allem bei vielen Geräten - nicht allzu viel Sinn macht. Hinzukommt, das viele Geräte im Haus oder der Wohnung verbaut sind (z.B. Unterputz) - und die baut man ja nicht unbedingt mal eben wieder so aus.

Over-the-air (OTA)

Neuere Komponenten verfügen über eine so gegannte OTA-Updatefunktion. Dabei erfolgt die Aktualisierung quasi "über die Luft" - nutzt also das vorhandene Funkprotokoll (oder die Busleitung bei Wired-Komponenten) für die Übertragung. Dabei ist zu beachten, dass das Update einige Zeit in Anspruch nehmen kann. Das liegt darin begründet, dass immer nur kleine Pakete auf diesem Wege verschickt werden können, um die zur Verfügung stehende Sendezeit nicht zu überschreiten (Stichwort: Duty-Cycle). Das eigentliche Update wird über die jeweilige Eigenschaftsseite in den Geräteeinstellungen angestoßen. Evtl. zur Verfügung stehende Updates werden dabei auf der Startseite der WebUI auf der rechten Seite gemeldet.

Flash-Party (Usertreffen)

Seit einigen Jahren besteht auf dem offiziellen HomeMatic Usertreffen die Möglichkeit, ausgewählte Komponenten vor Ort kostenlos auf den neuesten Stand bringen zu lassen. Bei der so genannten "Flash-Party" werden die mitgebrachten Geräte durch den oben angesprochenen Programmieradapter auf den neuesten Stand gebracht (geflasht) und können direkt danach wieder in Empfang genommen werden. In der Regel veröffentliche ich vor einem anstehenden Usertreffen eine Liste mit den entsprechenden Geräten, die auf der Party aktualisiert werden können.

Auch im Zeitalter von OCCU und RaspberryMatic mit all seinen Verbesserungen und Ergänzungen war genau dieser Befehl bei mir Ausschlaggebend für unerklärbare und scheinbar zufällige Abstürze. Zwar kommt es auch darauf an, wie der Befehl in einem Skript ausgeführt wird (z.B. durch das Anhängen eines kaufmännischen Und's für eine parallele Ausführung), aber es gibt auch eine "sicherere" Variante.

Das AddOn CUx-Daemon bringt neben der Anbindung HomeMatic fremder Komponenten auch die ein oder andere (erweiterte) Systemfunktion mit. Eine solche Funktion ist der absturzsichere System-Exec Befehl, der nachfolgend in einem Beispiel näher erläutert werden soll.

Nachdem Du das AddOn installiert hast, muss zunächst ein neues Gerät vom Typ "(28) System" angelegt werden. Dieses bekommt im Regelfall den Namen "CUX2801001". Sollte das Gerät bei Dir anders heißen, ist das nachfolgende Skript entsprechend anzupassen. Weitere Informationen zu den Möglichkeiten von CUx-D kannst Du dem ausführlichen Handbuch entnehmen.

Nehmen wir als nächstes ein Beispiel aus einem etwas älteren Skript von "pocket control" (mit dem oben angesprochenen, kaufmännischen 'Und' am Ende) zum Versenden einer Push-Notification:

system.Exec("wget -q -O /dev/null '--post-data=" # msg  # "' " # url # " &");

Um diese nun durch die CUx-D Variante zu ersetzen, ist die letzte Zeile wie folgt abzuändern:

dom.GetObject("CUxD.CUX2801001:1.CMD_EXEC").State("wget -q -O /dev/null '--post-data=" # msg  # "' " # url # " &");

Entscheidend ist hier die eingesetzte Geräteadresse (CUX2801001), die ggf. abzuändern ist. Der eigentliche Befehl (also alles hinter "wget"...) bleibt dabei absolut gleich.

Nach diesem Prinzip können "problematische" Aufrufe entsprechend ersetzt werden.

Schaltungsmodifikationen

Die Schaltung mit T11 und T12 dient zur Optimierung der Stromaufnahme bei Batteriebetrieb an den Eingang "2-3,3V". Wenn also nur der oben genannte Eingang (z.B. 9V Batteriebetrieb) genutzt werden soll, kann dieser Schaltungsteil entfallen.

Zunächst stellt der HAP über den Port 43439 eine Anfrage, um den zu verwendenden Cloud-Server zu ermitteln. Die Verbindung zu diesem Server wird dann über den Port 9292 aufgebaut. Für den Zugriff mit der Smartphone App werden zusätzlich die TCP Ports 8888 und 6969 verwendet. Bei einem Firmware-Update wird zusätzlich der Port 80 (HTTP) benötigt, der aber standardmäßig auf einem Router freigegeben sein sollte.

Sollte die Kommunikation zwischen den beteiligten Parteien also nicht wie gewünscht funktionieren, sind die oben genannten Portfreigaben zu überprüfen.

In diesen Netzen werden die Daten in Paketen versendet, in welchen nach einem Schichtenmodell Steuerinformationen verschiedener Netzwerkprotokolle ineinander verschachtelt um die eigentlichen Nutzdaten herum übertragen werden. IPv6 stellt als Protokoll der Vermittlungsschicht (Schicht 3 des OSI-Modells) im Rahmen der Internetprotokollfamilie eine über Teilnetze hinweg gültige 128-Bit-Adressierung der beteiligten Netzwerkelemente (Rechner oder Router) her. Ferner regelt es unter Verwendung dieser Adressen den Vorgang der Paketweiterleitung zwischen Teilnetzen (Routing).

Die Teilnetze können so mit verschiedenen Protokollen unterer Schichten betrieben werden, die deren unterschiedlichen physikalischen und administrativen Gegebenheiten Rechnung tragen.

BidCoS® ermöglicht den Aufbau einer kompletten Haussteuerung:

• Schalten/Dimmen von Licht und anderen elektrischen Verbrauchern
• Klimatisierung (Heizen, Kühlen, Lüften)
• Wettermesstechnik
• Energiemanagement
• Zugangskontrolle
• Einbruchschutz
• Gefahrenabsicherung (Rauch, Gas, Wasser) usw.

Dabei werden sowohl netz- als auch batteriebetriebene Komponenten innerhalb und außerhalb des Hauses berücksichtigt. Die schnelle bidirektionale Kommunikation (gesendete Funksignale werden vom Empfänger bestätigt) erhöht die Funktionssicherheit und bildet die Grundlage für die umfangreichen Möglichkeiten der Fernsteuerung/-überwachung solcher Systeme.

Moderne Rollladenmotoren verfügen über automatische End(lagen)schalter (bzw. über eine Endlagenerkennung) und bieten meist auch eine Hinternisserkennung (Überlastschutz). Fährt der Rollladen in eine seiner Endpositionen (komplett hoch bzw. komplett runter), schaltet der eingebaute Schutz den Motor automatisch ab. Dies passiert auch, wenn der Rollladen im Winter z.B. eingefroren ist, und sich nicht mehr automatisch bewegen lässt.

Beim Einrichten des HomeMatic Rollladen-Aktors stellt man überlicherweise im WebUI die benötigten Maximal-Laufzeiten für jede Richtung ein, also wie lange der Rollladen von einer Position (hoch/runter) in die andere benötigt. Mit ein wenig Pufferzeit fährt man damit in der Praxis eigentlich super. So lange man damit auch immer nur die jeweiligen Endpositionen anfährt ist das kein Problem. Schwierig wird es, wenn man hin und wieder auch mal Zwischenpositionen anfahren möchte, also z.B. 75% (oder einen kleinen Spalt offen lässt, um zu lüften).

Bei diesen Zwischenpositionen wird es zeitlich tricky, da 50% Anfahrposition nicht genau die Hälfte des Weges entspricht wenn man davon ausgeht, dass der Rollladen dann genau in der Mitte des Fensters halten soll. Das liegt in der Gegebenheit des Rollladens beim Hochfahren, da hier überlicherweise zunächst die einzelnen Luftschlitze zwischen den Lamellen "ausgefahren" werden, bevor sich der gesamte Rollladen in Bewegung setzt. Das Gleiche passiert auch beim Herunterfahren, sobald die erste Lamelle auf der Fensterbank aufsitzt.

Um den Rollladen also in genau der Mitte des Fensters anhalten zu können, muss zunächst ein wenig mit den Prozenzwerten experimentiert werden. Trägt man diese dann z.B. in ein entsprechendes Programm ein, wird man mit der Zeit aber feststellen, dass die gewünschte Position nicht mehr genau angefahren wird. Da bei jedem Anfahren Laufzeitunterschiede auftreten können (z.B. durch Witterungseinflüsse), verschiebt sich diese Position zusehend.

Und genau hier kommen die so genannten Kalibrierungsfahrten ins Spiel. Damit sagt man dem Rollladenaktor, nach wie vielen Fahrten dieser einmal komplett einfach runter und wieder hoch fahren soll, um sich quasi neu zu justieren. Nach dieser Fahrt sollten nachfolgend angefahrene Zwischenpositionen wieder zeitlich stimmen.

So stellst Du die Kalibrierungsfahrten ein

• Melde Dich auf der WebUI an
• Gehe auf "Einstellungen > Geräte"
• Suche den entsprechenden Aktor aus der Liste aus
• Klicke auf "Einstellen"
• Stelle die gewünschte Anzahl der Fahrten ein
• Klicke auf "OK", um die Einstellungen zu übernehmen