Blog

Nun haben wir alles vorbereitet um endlich die ersten Schaltvorgänge auszuführen. Das Ziel ist, dass der Präsenzmelder automatisch das Licht einschaltet, wenn es zu dunkel im Raum wird. Natürlich nur, wenn sich jemand gerade in diesem Raum aufhält. Wie schon zuvor angesprochen, müssen wir dazu eine Gruppenadresse anlegen. Die Gruppenadressen werden dann auf den Bus gesendet und die Teilnehmer reagieren auf diese. Klingt erstmal einfach (und ist es auch). Der große Knackpunkt dabei ist meistens: Wie bekommt man seine Gruppenadressen so aufgebaut, dass man später noch den Überblick behält. Dafür gibt es viele Herangehensweisen und Konzepte. Aber darauf kommen wir später noch zu sprechen. Jetzt erstmal die Basics.

In den letzten Videos wurde alles für diesen Inhalt vorbereitet. Das Demo-Board ist fertig, die ETS eingerichtet und nun können wir das erste Mal mit den Komponenten kommunizieren. Damit die Teilnehmer auch wissen, wer sie eigentlich sind, bekommt jede Komponente eine physikalische Adresse zugeordnet. Dabei sollte man sich natürlich vor dem Projekt überlegen, wie man die Linien und Adressen eigentlich aufteilen und vergeben möchte. Seitens KNX gibt es dafür natürlich auch Guidelines, welche man als Empfehlung oder Basis für die eigene Umsetzung nutzen kann.

Jetzt haben wir die Hardware erstmal soweit vorbereitet. Wie geht es weiter? Logisch, mit dem Software-Teil. Da KNX herstellerunabhängig ist, muss irgendjemand eine Software entwickeln, welche mit den Komponenten kommuniziert. Daher ist (anders als z.B. bei Loxone) die Software lizenzpflichtig. Und leider auch gar nicht so günstig. Diese Software nennt sich ETS (Engineering Tool Software). Welche Lizenz Du genau benötigst, und wie Du viel Geld sparen kannst, erfährst Du in diesem Beitrag. Kurz vor weg: Ich mache die Preise nicht und finde sie für Privatkunden auch zu hoch. Das Konzept sieht eben auch eigentlich eher vor, dass Elektriker diese Lizenzen kaufen, und die Kosten dafür über Projekte wieder reinholen. Gerade der Sprung von der Lite zur Professional ist für mich viel zu weit. Aber sieht selbst.

In einem vorigen Video habe ich die Integration von SONOS in die verschiedenen Systeme gezeigt. Dabei habe ich bewusst nur Google TTS (Text to Speech) genutzt, da dies die einzige Variante ist, welche von FHEM im Standard unterstützt wird. Das klingt leider oft etwas abgehackt und künstlich, also suchen wir eine bessere Lösung. Wenn man nach weiteren Diensten sucht, stolpert man immer wieder über Amazon Polly. Und die Ergebisse können sich sehen lassen (bzw. hören). Daher stelle ich Dir jetzt vor, wie Du in den Genuss von Amazon Polly in deiner FHEM, ioBroker oder auch NodeRed-Umgebung kommst.

Schon vor längerer Zeit wollte ich bei SONOS zuschlagen. Irgendwie habe ich immer wieder überlegt, ob mir die Lautsprecher wirklich das geben, was ich brauche. Die weite Verbreitung ist natürlich ein riesen Pluspunkt. Es gibt kein System, in welches SONOS nicht integriert wurde. Und das schon vor sehr langer Zeit - also müssten die Schnittstellen auch sehr stabil sein. Warum habe ich also so lange überlegt? Wegen dem Registrierungszwang und der halben Cloud-Anbindung. Die Lautsprecher telefonieren relativ viel nach Hause (soweit ich weiß). Aber im Gesamtpaket haben sie mich dann doch überzeugen können.

Nachdem wir nun etwas Theorie hinter uns gebracht haben, geht es mit Praxis weiter. Um in der Tutorial-Reihe etwas praktisch zeigen zu können, habe ich ein kleines Demo-Board vorbereitet. Dieses besteht aus den unten genannten Komponenten. Außerdem habe ich noch einen Raspberry Pi mit aufgenommen, sodass wir später auch direkt mit weiteren Integrationen weitermachen können. Für den Start zeige ich aber erstmal wie man die Komponenten mit der Busleitung miteinander verbindet und worauf man dabei achten sollte. So komplex ist das ganze wirklich nicht. Mit ein paar einfachen Werkzeugen kommt man sehr schnell ans Ziel!

Endlich wird es Zeit für KNX! Ich glaube, zu keinem anderen Thema wurden sich so oft Videos gewünscht. Verständlich - immerhin ist KNX das Urgestein und Vater aller Smart Home Systeme (wenn man das so sehen möchte). Viele von Euch haben bereits seit Jahren KNX im Einsatz und möchten das Thema natürlich auch selbst in die Hand nehmen. Im ersten Video starten wir ganz locker mit ein paar Grundlagen, damit wir alle den gleichen Wissensstand haben. Wie immer setze ich dabei so früh wie möglich an.

In einem früheren Video habe ich ja bereits gezeigt, wie man über einen generischen Weg per MQTT die Daten in NodeRed aktualisieren kann. Was wäre aber, wenn man kein MQTT hat oder extra nutzen möchte, und trotzdem Informationen aus FHEM holen will? Dann bietet sich der Weg über ein FHEM-Modul namens JsonList2 an. Dieses liefert die aktuellen Readings und deren Wert im Json-Format aus. In NdeRed lieben wir JSON, da man damit extrem einfach weiter arbeiten kann. Wie genau das geht, zeige ich DIr in diesem Video.

Vor einiger Zeit wurden hier schon mehrere Projekte zum Thema ZigBee und Xiaomi vorgestellt. Der CC2531 ist eine tolle Lösung, um ohne Cloud oder Bridge die ganzen ZigBee-Komponenten nutzen zu können. Leider ist der Weg zum fertigen Stick relativ weit. Für viele etwas zu weit. Wenn man wenige Euro mehr ausgibt, bekommt man schon einen ConBee-Stick von Dresden Elektronik. Dieser stellt ebenfalls ein universelles Interface zu allen möglichen ZigBee-Komponenten bereit. So kann Philips Hue, IKEA Tradfri, Osram Lightify usw. genauso integriert werden wie die ganzen Xiaomi-Sensoren natürlich auch. Also das gleiche Ergebnis, nur sehr viel einfacher umzusetzen.

Wenn Du auf deinem Smartphone mehrere WiFi-Netze konfiguriert hast (Zuhause, Arbeit, Freunde, Cafes, …) und das Haus verlässt, fragt das Gerät ständig ob diese Netzwerke in der Umgebung erreichbar sind. Ist dies der Fall, verbindet es sich. Meistens ist man aber unterwegs und weit weg von Zuhause - dann fragt es trotzdem munter weiter. Und das für alle Einträge. Warst Du also im letzten Urlaub im Hotel-WLAN, dann fragt es auch in der Fußgängerzone in Deutschland weiter nach diesem Netz. Diese Anfragen nennt man Probe Requests. Das gleiche passiert, wenn der DHL-Zusteller mit seinem Handheld vor Deiner Haustür steht. Diese Geräte haben auch WLAN und fragen ständig nach diesem. So können wir diese erkennen. Cool, oder?