Nerd-Blog

Ich war's leid: X Systeme, Sensoren, Protokolle, Lampen, Stecker, .... und eine Homematic Anlage, für deren Bedienung man ein Programmierer mit Bastelleidenschaft sein muss.
Aber jetzt soll Schluss damit sein! Ok, vieles kann ich über die Bridge von Philips Hue steuern, aber eben nicht Fenstersensoren, Heizkörperthermostate, Rauchmelder, usw. . Und so schlich ich gedanklich schon seit einiger Zeit um das homee-System herum, das scheinbar der Heilsbringer sein soll; zumindest der Beschreibung des Herstellers nach, aber auch, wenn man Blogposts und Videos Glauben schenken darf.

Ich bestellte also den Braincube und einen ZigBee Würfel, die es beide zusammen auch noch mit 25,- € Rabatt gab. Geliefert werden soll das ganze dann morgen und ich bin schon gespannt. Mit sogenannten "homeegrammen" kann man dann "Wenn...Dann..."-Abfragen und Aktionen recht einfach erstellen. Das System erkennt hersteller- und protokollübergreifend die einzelnen Sensoren und Geräte und kann sie mit einander verbinden.
So werde ich dann hoffentlich(!) endlich auf einfachstem Wege einstellen können: "Wenn Rauchmelder 'Garage' Rauch entdeckt, dann sende eine Push-Nachricht an:" . So einfach scheint es zu gehen, schaut man sich Bilder von diversen homeegrammen an. Im Homematic Universum würde diese einfache Funktion....äh.....ja......, aber vergessen wir das ganz schnell.

Ich besorgte mir von Osram die Steckdosen (Osram Lightify Plug), um die Weihnachtsbaumbeleuchtung, IKEA LED Strips usw. ebenfalls über meine HUE-App steuern zu können wie die Philips Lampen auch. Das Problem war aber, dass sie von meiner Bridge partout nicht erkannt wurden. Der Grund: die Bridge der 1. Generation kann die Osram Plugs offenbar nicht erkennen. Diese funken zwar auch über ZigBee, doch die Bridge kann mit ihnen - trotz letztem verfügbaren Philips Update - nichts anfangen. Also musste eine Bridge einer neuen Generation her und so kaufte ich die der 3. .

Doch danach ging erstmal nichts mehr. Ich wollte die Einstellungen von der alten Bridge auf die neue übertragen, was per Philips Hue App im Grunde ganz komfortabel geht. Was mich schon von Anfang an wunderte: der blaue Ring der Bridge wollte partout nicht leuchten. Und auch die App konnte die Bridge die meiste Zeit nicht finden. Wurde sie mal gefunden, brach die Verbindung nach kurzer Zeit auch schon wieder ab und die blauen LEDs für Netzwerk und Internet erloschen, blinkten kurz darauf wieder und leuchteten, bis sie wieder erloschen. Lediglich einmal gelang mir auf die Schnelle das Übertragen der Einstellungen und nur beim Punkt: "Setzen Sie Ihre alte Bridge jetzt auf den Werkszustand zurück", zögerte ich. Bevor auf der neuen nicht alles reibungslos läuft, lösche ich erst einmal gar nichts. Und so trennte ich sie zunächst lediglich vom Strom.

Doch welches Problem hat die neue Bridge? Immer und immer wieder brach die Verbindung ab und der blaue Ring leuchtete nicht. Und so versuchte ich es zunächst mit einem anderen LAN-Kabel: erfolglos.
Danach schloss ich sie direkt an der Fritz!Box an (zuvor an einem kleinen Gigabit-Switch), doch auch hier: dasselbe. Dann sah ich mir "in" der Fritz!Box mal die Geräte im Netzwerk an und sah, dass die Bridge verbunden ist und auch eine IP erhielt. Die IP stellte ich bei dieser Gelegenheit gleich auf eine feste um, damit ich zukünftig nicht das Problem habe, dass ich per App nach einer Neuzuweisung über DHCP nicht mehr drauf kommen.
Zwischendurch sah ich, dass die Bridge immer wieder offline ging und war ratlos. War sie vielleicht defekt? Eine Suche im Internet ergab, dass viele Benutzer das Problem haben (nach dem letzten Update, das auch bei mir beim ersten Start eingesielt wurde). Immerhin war der Philips Support auf deren Facebookseite stets bemüht, eine Lösung zu bieten.

--- Die Lösung ---

Ich war also schon hoffnungslos, dass sich hier schnell eine Lösung finden wird, bis mir eine Kleinigkeit auffiel, die aber alles änderte.
Mir fiel auf, dass ich für die alte Bridge Portforwarding aktiviert hatte, um sie auch von außen via DynDNS zu erreichen. Also richtete ich auch diese für die neue Bridge ein, weil ich ja auch sie wieder von außen erreichen will, wenn sie denn dann mal funktioniert. Und siehe da: Nach dem Speichern der Einstellung begann der blaue Ring zu leuchten und die Bridge blieb verbunden! Die Verbindung per Hue App im LAN sowie über DynDNS klappte und blieb stabil, alle Einstellungen der alten Bridge waren vorhanden und das Steuern der Lampen und Geräte klappte ebenfalls!

Aber da frage ich mich, weshalb die Bridge nicht auch ohne Port Forwarding online kommt und vor allem die Kommunikation im internen Netz verweigert! Da muss man erstmal drauf kommen!

Nachdem also endlich alles lief, versuchte ich die Plugs erkennen zu lassen. Doch: Fehlanzeige. Wieder wurden sie nicht erkannt. Ich versuchte wieder alles möglich und als ich mit meinem Smartphone dann mal direkt neben einem stand wurde er plötzlich gefunden; und so auch der zweite. Ääähhhh, ja. Dass man einige Geräte in kurzen Abstand zur Bridge(!) bringen muss, um sie anzulernen, ist ja ok, aber dass der Plug in der Nähe des Smartphones sein muss, erscheint mir unwahrscheinlich.

So oder so: jetzt waren sie erkannt (als Lampe mit "EIN/AUS") und konnten eingerichtet werden. In der "Hue Pro" App erstellte ich mir zwei neue Gruppen, passende Szenen und Timer und alles funktioniert wunderbar.
Wenn's geht, ist's super, aber der Weg bis dahin war wieder unnötig schwer und stellenweise unlogisch. Und dann frage ich mich dabei immer wie "Otto Normaluser" das hinbekommen soll; alleine schon die Inbetriebnahme der Bridge!

Das Upgrade des Seafile Servers von 6.1.x auf 6.2.2 auf meinem Raspberry Pi schlug erwartungsgemäß fehl. Wie in den Anmerkungen zum Paket angegeben, nahm ich die Anpassungen in Nginx (sudo nano /etc/nginx/sites-available/seahub) vor, scheiterte dann aber beim Upgrade Befehl: upgrade_6.1_6.2.sh . Ich erhielt dabei immer nur folgende Fehlermeldung:



Na, toll.
Also frickelte ich mir einen zurecht und passte erst die "seahub.sql" im Upgrade Verzeichnis des Pakets unter sql/6.2.0/sqlite3/ an, indem ich folgende Zeilen hinzufügte:



Ich speicherte die Änderungen und startete das Upgrade per sudo ./upgrade_6.1_6.2.sh erneut. Doch wieder erhielt ich die Fehlermeldung. Also machte ich mich daran, die drei Zeilen direkt in die Datenbank zu schreiben und dabei unterlief mir ein Denkfehler, denn ich bearbeitete die seahub.db im sqlite3 Verzeichnis des Upgrade Ordners. Ich erhielt erneut dieselbe Fehlermeldung, bis ich drauf kam! Die relevante und zu bearbeitende Datenbank liegt natürlich im Seafile Verzeichnis und muss, da schreibgeschützt, mit erweiterten Rechten bearbeitet werden.

Also zurück nach /home/seafile, zu root gewechselt und per nano seahub.db die Datenbank um obige drei Zeilen ergänzt. Das ganze dann gespeichert, von root wieder zum Pi User zurükgewechselt und das Upgrade ausgeführt, das nun endlich erfolgreich durchlief.

Abschließend startete ich seafile.sh und seahub.sh wieder, wobei der Start von seahub.sh nach den Änderungen in Nginx jetzt nicht mehr per ./seahub.sh start-fastcgi erfolgte, sondern nur noch per ./seahub.sh start.

Mein Client war danach auch direkt wieder verbunden, aber das Web Interface bringt mir noch eine "Bad URL in request" Meldung. Diesen Fehler muss ich jetzt im zweiten Schritt beheben. Doch soweit so gut schonmal.

Ein wenig Hausautomation ist ja heutzutage in und HUE Lampen oder zeutgesteuerte Thermostate fast schon Steinzeit. Also wollte ich auch auf den fahrenden Zug der Hausautomation aufspringen und ein bisschen ausprobieren. Da ich in einer/unserer Wohnung wenig Sinn in viel Automation sah (mit Ausnahme der Lampensteuerung), beschfäftigte ich mich in der Praxis nicht weiter mit dem Thema, wollte es aber nicht ganz außen vor lassen. Naja, und so stöberte ich dann doch mal hier und da ein wenig und ließ mich schließlich von einem Bekannten überzeugen, der mir seine Homematic präsentierte.

Das sah alles ganz toll aus und funktionierte gut. Fenstersensoren? Heizungsthermostate? Rauchmelder? Alles Standardgeräte, die man kennt. Also verglich ich ein paar Preise und sah mir Alternativen an, bis ich letzten Endes zur Homematic CCU2 griff. Die Homematic IP Version kam für mich nicht in Frage, weil ich meine "Haussteuerung" nicht über eine Cloud betreiben will. An- und Abwesenheiten, "Internas" usw. will ich nicht bei irgendeinem Anbieter liegen haben; selbst wenn's der Hersteller ist.

Also bestellte ich mir die ganzen Brocken und fing an das ganze einzurichten. Schnell stellte sich Ernüchterung ein, weil von Komfort hier keine Spur zu erkennen ist. Vieles wirkt unübersichtlicht, technisch und ist tatsächlich - aus meiner Sicht - umständlich bis kompliziert einzurichten. Die Oberfläche ist hässlich und oft muss man anders denken, wenn man Regeln erstellen will. Und will man ein wenig mehr machen wie E-Mail-Versand oder Lampensteuerung, kommt man ohne (rudimentäre) Programmierkenntnisse nicht aus, weil man sich für gefühlt alles, was über die Basics hinausgeht, ein Script programmieren muss. Schnelle Alarmmeldungen unterwegs erhalten? Einfache Statusabfragen oder eine Überischt via Handy? Auch fast Fehlanzeige, denn der Hersteller bietet für die CCU2 keine App an und die Alternativen sind.....: naja.

Ihr lest schon: zufrieden bin ich nicht. Und vermutlich werden jetzt die Homematic Bastler auf mich eindreschen wollen, aber so ist es nun einmal.

Was machte und probierte ich jetzt in der Zwischenzeit?

Nun, zunächst einmal wollte ich, dass Fenstersensoren erkennen, wenn ein Fenster oder die Balkontür geöffnet wird. In Verbindung damit sollen alle Lampen auf volle Helligkeit und in weiß eingeschaltet werden. Und das ganze natürlich nur, wenn keiner da ist. Am besten soll auch gleich eine Meldung verschickt werden. Ach, und der Brandmelder in der Garage soll natürlich auch melden, wenn dicke Luft herrscht und mir am besten eine Meldung schicken.
Soweit so gut, aber dann begann das Gefrickel, das aktuell immerhin in den meisten Fällen wenigstens funktioniert.


- Zuerst lernte ich Fenstersensoren an der CCU2 an, was problemlos klappte
- Im nächsten Schritt lernte ich den Homematic IP Rauchmelder an, was anfangs nicht funktionierte, dann aber möglich war, nachdem ich einen Reset des Melders durchführte und ihn über "Homematic IP Gerät mit Internetzugang anlernen" anlernte

HUE-Lampen ansteuern

Danach frickelte ich mir ein Script zusammen, das die Hue Lampen einschaltet.
Dazu musste ich:

- Cux-Daemon runterladen und auf der CCU2 installieren
- Einen Benutzer auf der Hue Bridge generieren
- Lampen IDs auslesen
- Ein Script basteln

Hierbei halfen mir u.a. folgende Anleitungen:

https://www.technikkram.net/2017/04/philips-hue-per-homematic-steuern
http://homematic.simdorn.net/philips-hue-mit-homematic-steuern/
http://www.appproject.de/Hausautomatisierung/Hue/PhilipsHueHomematic.html
https://www.sgiersch.de/hue-leuchte-mit-einer-ccu-2-steuern/
http://www.schimpfen.de/wordpress/philips-hue-led-lampen-mit-homematic-steuern/

Also mit mal eben schnell und einfach war hier schonmal nix. Die Lightify Kopplung scheint da schon unkomplizierter zu sein, aber das sah ich mir nicht weiter an, weil ich keine Osram Leuchtmittel habe.
Also lud ich mir CuxD runter, installierte es und machte dann auf der Hue Bridge mit der Benutzeranlage weiter. Danach las ich die Lampen IDs aus und machte mich an das Script, in dem ich testweise erstmal nur eine handvoll Lampen einbaute:

!Mehrere Hue Lampen Einschalten
!------------------------------
!__IP Adresse der Hue Bridge
string ip_address = "192.168.x.x";

!__User ID in der Bridge
string api_key="EsT5lLmRPjp...";


!----Wohnzimmerregal---
string lamp ="4";
string reqdata="{\"on\":true, \"sat\":255, \"bri\":255,\"hue\":35000}";
string request="/usr/local/addons/cuxd/curl -X PUT -H \"Content-Type: application/json\" -d '" # reqdata # "' http://" # ip_address # "/api/" # api_key # "/lights/" # lamp # "/state/";
dom.GetObject("CUxD.CUX...:1.CMD_EXEC").State(request);

!----Couch---
string lamp ="2";
string reqdata="{\"on\":true, \"sat\":255, \"bri\":255,\"hue\":35000}";
string request="/usr/local/addons/cuxd/curl -X PUT -H \"Content-Type: application/json\" -d '" # reqdata # "' http://" # ip_address # "/api/" # api_key # "/lights/" # lamp # "/state/";
dom.GetObject("CUxD.CUX...:1.CMD_EXEC").State(request);

!----Stehlampe---
string lamp ="3";
string reqdata="{\"on\":true, \"sat\":255, \"bri\":255,\"hue\":35000}";
string request="/usr/local/addons/cuxd/curl -X PUT -H \"Content-Type: application/json\" -d '" # reqdata # "' http://" # ip_address # "/api/" # api_key # "/lights/" # lamp # "/state/";
dom.GetObject("CUxD.CUX...:1.CMD_EXEC").State(request);

!----Flurecke---
string lamp ="7";
string reqdata="{\"on\":true, \"sat\":255, \"bri\":255,\"hue\":35000}";
string request="/usr/local/addons/cuxd/curl -X PUT -H \"Content-Type: application/json\" -d '" # reqdata # "' http://" # ip_address # "/api/" # api_key # "/lights/" # lamp # "/state/";
dom.GetObject("CUxD.CUX...:1.CMD_EXEC").State(request);

Natürlich fragte ich mich erstmal, wo so ein Script hinterlegt wird und ob das auch mehrfach wiederverwendet werden kann. Nun, so wie es aussieht ist das nur in der jeweiligen Regel möglich und bedeuet immer Copy & Paste oder man macht aus der Regel/dem Programm ein neues, das quasi als Vorlage dient.

Abwesenheitsprüfung

Um die Lampen beim Öffnen eines Fensters in Abwesenheit einzuschalten, brauchte es aber noch eine Anwesenheitsprüfung. Also grübelte und rätselte ich, wie das umgesetzt werden kann und auch das war wieder nicht einfach zu machen, sondern an mehreren Stellen.

1. Zunächst musste ich also in die Systemvariablen und nahm dort die Variable "Anwesenheit". Für "wahr" und "falsch" gab ich als Wertebezeichnung "anwesend" und "nicht anwesend" an. Doch wie weiter? Wie sollte ich der CCU2 beibringen, dass sie merkt, dass keiner da ist? Jaaaa, wäre ja auch zu einfach, aber nein.

2. Man muss jetzt in die Geräteübersicht und sich einen Schaltaktor anlegen; in meinem Fall ein "Funk Wandtaster 2-fach", weil ich zwei Smartphones überwachen wollte. Was? "Funk Wandtaster"? "Schaltaktor"? Smartphones überwachen? Äh ja. Genau. Die An- oder Abwesenheit kann am einfachsten geprüft werden, wenn man ein ein Smartphone im WLAN anpingt und antwortet es, ist man eben anwesend und wenn nicht, dann nicht. ^^ Aber diesen Status bzw. die Abfrage muss man an ein Gerät koppeln. *seufz*

3. Damit die Smartphones auch über die jeweilige Funktion auf immer und ewig angepingt werden können, brauchen sie im Idealfall - besser: zwingend - eine feste IP. Und die muss man auf dem Heimrouter den Geräten erstmal verpassen.

4. Danach wählte ich auf der CCSU2 besagten "Funk Wandtaster 2-fach" und dessen Einstellungen. Darin legte ich fest:

- SWITCH|ACTIVE (Haken gesetzt)
- SWITCH|IP_DNS_ADS: 192.168.x.x (die feste IP Adresse des 1. Smartphones)
- SWITCH|Port: 0
- SWITCH|INTERVAL_ALIVE: 60
- SWITCH|INTERVAL_FAIL: 60
- SWITCH|MAX_RETRY: 0
- SWITCH|THRESHOLD: 1
- die letzten beiden Einträge ließ ich leer

Dieselben Einstellungen nahm ich auch für das zweite Smartphone vor, natürlich mit der entsprechenden festen IP des Geräts.

5. So, nun haben wir 'nen Schalter. Und jetzt? Großes Rätselraten. Weiter geht's mit den Programmen. Doch bevor wir zur eigentlichen Regel - oder hier "Programm"- kommen, müssen wir ein davor ein anderes Programm erstellen, damit die CCU2 auch in der Lage ist, den An- und Abwesenheitsstatus zu speichern ^^ Und das nannte ich: "Smartphones Anwesenheitssteuerung":

Bedingung: Wenn...
Geräteauswahl - Smartphone 1 bei Schaltzustand: ein bei Änderung auslösen
ODER
Geräteauswahl - Smartphone 2 bei Schaltzustand: ein bei Änderung auslösen

Aktivität: Dann... Vor dem Ausführen alle laufenden Verzögerungen für die Aktivitäten beenden (z.B. Retriggern) => Haken rein
Systemzustand Anwesenheit sofort anwesend

Bedingung: Sonst, wenn...
Geräteauswahl - Smartphone 1 bei Schaltzustand: aus bei Änderung auslösen
UND
Geräteauswahl - Smartphone 2 bei Schaltzustand: aus bei Änderung auslösen

Aktivität: Dann... Vor dem Ausführen alle laufenden Verzögerungen für die Aktivitäten beenden (z.B. Retriggern) => Haken rein
Systemzustand Anwesenheit sofort nicht anwesend

Soweit so gut. Soll also heißen: wenn eins der Smartphones auf anpingen nicht reagiert, weiß die CCU2, dass es nicht anwesend zu sein scheint
und setzt den Status für das Gerät, also die Variable oder was auch immer, auf: "nicht anwesend". Ist das Gerät (wieder) verfügbar, wird dessen
Status auf: "anwesend", gesetzt. Es reicht, wenn ein Gerät online ist, denn dann ist ja jemand daheim, aber sobal beide offline sind, ist eben keiner daheim.
Daher auch die Auswahl von ODER und UND.


Sensorstatus auslesen

6. Nach zig Vorbereitungen kam ich dann endlich zum eigentlichen Programm, das ich "Alle Sensoren und Hue Aktivierung" nannte:

Bedingung: Wenn...
Geräteauswahl Fenstersensor 1 bei offen bei Änderung auslösen
UND
Systemzustand Anwesenheit bei nicht anwesend nur prüen

ODER
Geräteauswahl Fenstersensor 2 bei offen bei Änderung auslösen
UND
Systemzustand Anwesenheit bei nicht anwesend nur prüen

ODER
Geräteauswahl Fenstersensor 3 bei offen bei Änderung auslösen
UND
Systemzustand Anwesenheit bei nicht anwesend nur prüen

Aktivität: Dann... Vor dem Ausführen alle laufenden Verzögerungen für die Aktivitäten beenden (z.B. Retriggern) => Haken rein
Skript: (Hier das oben genannte Script reinhauen) ... sofort
Systemzustand Alarmzone 1 sofort ausgelöst

Was macht das "Programm" jetzt? Nun, es überprüft den Status der Fenstersensoren auf Änderungen und hier fiel ich direkt auf die Nase, denn für mich wäre logisch gewesen: "Wenn geschlossen und der Status ändert sich, dann". In Homematic Sprache: "bei geschlossen bei Änderung auslösen". Aber das war falsch! Es muss genau umgekehrt lauten! Eben: "bei offen bei Änderung" auslösen. ^^ Nun gut.
Das Script, das ich eingangs erwähnte muss jetzt hier eingebaut werden. Und der Punkt mit der "Alarmzone 1"? Zu dem komme ich gleich.

Ok. Öffnet man jetzt ein Fenster und befindet sich keins der Smartphones mehr im Netzwerk, werden die jeweiligen Lampen eingeschaltet (weiß, 100% Heligkeit).

Alarmmeldung und (Android-)App

Klasse. Wie aber verhält es sich mit einer Alarmmeldung und wie kann ich prüfen, was sich daheim tut? Nun, auch das kann man ermöglichen, mit ein wenig Bastelarbeit.
Es gibt in den CCU2 Variablen eine sogenannte "Alarmzone 1", die man heranziehen kann und die die Werte "ausgelöst" und "nicht ausgelöst" bietet. Diese kann man dann in enem Programm wie in obigem verwenden.
Die Benachrichtigung unterwegs bzw. die schnelle Statusabfrage ist wieder mit Hürden verbunden.

Ich verwende die Android App "Home24" (es gibt auch noch die inzwischen umbenannte TinyMatic (vorher HomeDroid)) und deren Widgets sowie Alarmfunktion. Auf dem Handydesktop legte ich mir Widgets für die Anwesenheits Statusanzeige sowie für die Stati der Sensoren an, aaaaber es wäre nicht Homematic, wenn das mal eben schnell getan wäre. Nein, man muss zunächst Systemvariablen definieren, auf die man zurückgreift. Also vorher wieder zurück auf die CCU2 und unter "Systemvariablen" Variablen für die Sensoren anlegen.
Ich nannte meine Variablen: "Status Sensor 1" und "Status Sensor 2 und 3".

Beispiel für Sensor 1:

Name = Status Sensor 1
Beschreibung = Fenster X
Variablentyp = Logikwert
Werte = wahr = geschlossen; falsch = offen
Maßeinheit = leer
Kanalzuordnung = ohne

Weshalb die Werte bei mir für "wahr" "geschlossen" und für "falsch" "offen" lauten hat den Grund, dass ein geschlossenes Fenster für mich der korrekte, als "wahre" Zustand ist und ein offenes eben nicht.

Jetzt konnte ich jeweils ein Widget hinzufügen und darüber die jeweilige neu erstellte Variable auswählen. Ist ein Fenster geschlossen oder ein Smartphone anwesend wird dies über einen grünen Haken angezeigt. Ansonsten ist der grüne Haken raus.
AAAABER: Dies ist natürlich erst möglich, nachdem die die App konfiguriert wurde, sodass der Zugriff auf die CCU2 aus der Ferne möglich ist, was wiederum einen DynDNS Account erfordert. Zudem muss die XML API abgefragt werden, was bedeutuet, dass man auch hier im Vorfeld wieder vorbereitend tätig werden muss, indem man auf der CCU ein XML File hochläd, das man hier beziehen kann: https://www.homematic-inside.de/software/addons/item/xmlapi

Die Aktualisierungszeit sollte danach in den Einstellungen der App dann auf den niedrigst möglichen Wert, hier 2 Minuten, gesetzt werden und der Eintrag "Alarm aktivieren" unter "Anzeige und Alarmeinstellungen" aktiviert werden. Idealerweise legt man sich noch ein Widget für die manuelle Aktualisierung auf dem Desktop an, da die automatische Aktualisierung nach meiner Erfahrung oftmals fehlschlägt. ^^

So funktioniert das ganze schonmal ganz gut. Lästigerweise rappelt das Telefon allerdings zwischendurch wie oft und alarmiert mich über eine Änderung der Sensoren, obwohl keine stattfand. Das muss ich noch irgendwie ändern, denn ansonsten ist die Funktion unbrauchbar.

E-Mail-Benachrichtigung

Will man sich per E-Mail benachrichtigen lassen, hat man nochmal richtig Spaß, denn eine Standardfunktion bietet Homematic hierfür auch nicht an.
Man muss sich wieder ein kleines Paket installieren, das man hier beziehen kann: https://www.homematic-inside.de/software/email
Eine Anleitung zur Konfiguration findet sich hier: http://www.christian-luetgens.de/homematic/e-mail/einrichtung/Einrichtung.htm#chapter_3
Eine Anleitung zum Versand generell findet sich hier: http://www.christian-luetgens.de/homematic/e-mail/servicemeldungen/Servicemeldungen.htm

Leider ist auch hier wieder ein wenig Programmierwissen vonnöten, weshalb so manch einer direkt scheitern dürfte und wie der Ochs' vorm Berg steht. Mir war es eindeutig zuviel Gefrickel, weshalb ich von dieser Lösung erstmal absah und die Alarmmeldung der Home24 App verwende, sofern sie denn sauber funktioniert, wobei der Auslöser der Fehlalarme ein Sensor, ein Programm, die CCU2 oder weiß der Kuckuck was sein kann.
Zudem kann man beim Versand der Testmail in der Mailanwendung auf der CCU2 schnell verzweifeln, da der Test in den meisten Fällen fehlschlägt, was aber mit der Konfiguration zusammen hängen dürfte.
Die funktionierenden Einstellungen für den Versand über GMX seien zum Beispiel:

SMTP Server: mail.gmx.net
Absender: meine.mailadresse@gmx.de
Authentifikation: LOGIN
Port: 465
Verschlüsselte Verbindung (TLS): Haken rein
STARTTLS deaktivieren (bei Port 465): Haken rein
Benutzername: meine.mailadresse@gmx.de
Passwort

Im Zweifelsfall hilt einem die Hilfefunktion bei der Einrichtung weiter, wenn man einen anderen Anbieter verwendet und der Testversand partout nicht klappen will. Ansosten findet man hierzu auch unzählige Seiten im Internet.


So, und vielleicht verteht der eine oder andere jetzt, weshalb ich die Anlage für umständlich und für sicherlich einige Benutzer zu kompliziert im Umgang halte. Andere Anbieter lösten das sicherlich komfortabler.
Ich werde mal sehen wie ich weiter mit der Homematic agiere. Mir mühsam immer alles zusammensuchen zu müssen ist mir einfach zu lästig und an x Stellen etwas zu basteln zuviel. Jetzt läuft ja aber erstmal alles. Also schauen wir mal.

Gestern schloss ich mal wieder meinen alten ATARI 2600 (Atari VCS - CX2600A) an unseren Samsung LCD an und wusste nicht mehr wie ich das Bild übertragen bekomme, bis ich mich wieder entsonn. Für alle, die sich das auch fragen, hier die schnelle Anleitung:

1. ATARI, Intertone, SEGA oder was auch immer per Antennenkabel an den Antennenanschluss des Fernsehers anschließen (besser: HF Modulator verwenden)
2. Einen beliebigen Programmplatz auswählen
3. In die Einstellungen des TV wechseln und in die manuelle Sendersuche gehen
4. Kanal C2, 3 oder 4 wählen* und schon sollte das Bild angezeigt werden**

*Die Wahl des jeweiligen Kanals hängt von der Konsole und deren Einstellung ab. Der ATARI 2600 hat z.B. einen Umschalter für Kanal 2 und 3, andere wiederum senden von vornherein auf Kanal 4 oder sogar 32. Die richtige Frequenz sollte bei Wahl des jeweiligen TV Kanals automatisch eingestellt werden. Will man das auch manuell tun, sollte man im Internet nach seiner Konsole und deren verwendeten Einstellungen suchen, da sich diese je nach Modell und Land (für das die Konsole hergestellt wurde) unterscheiden kann.
Als Bildformat kann man "Automatisch" wählen oder stellt auf "PAL" um, sofern es sich um ein Gerät für den Europäischen Markt handelt (Ausnahme: Frankreich mit SECAM).
Ein paar Infos dazu fand ich mal hier: https://circuit-board.de/forum/index.php/Thread/15278-Sind-die-Kanalfrequenzen-bei-alten-RF-Konsolen-immer-gleich/

**Das Tonformat kann mit "DK" oder "BG" voreingestellt bleiben oder man wählt in Verbindung mit PAL "I".

Ein besseres Bild bekommt man, wenn man sich einen HF Modulator bestellt und die Konsole über diesen mit dem Fernseher verbindet, um eine stabile Ausgangsfrequenz zu bekommen.