by ·10 Kommentare

Eine der nächsten Dinge die im neuen Haus erledigt werden mussten ist die Temperetaturmesseung der einzelnen Räume für die automatisierte Heizungssteuerung.

Ich plane immer noch 1-Wire einzusetzen und habe auch dafür schon ein Gateway auf Basis des ESP8266 mit ESPEasy gebaut. Allerdings gibt es ein Störsignal auf den Leitungen imHaus (JY-ST-Y) was 1-Wire etwas aus dem Tritt bringt. Da muss ich mal schauen wie ich das gefiltert bekomme – das Gateway selbst funktioniert 🙂
Der 1-Wire-Plan ist also nicht begraben, ich brauchte aber eine Übergangslösung…

Auf der Suche nach einer Alternative bin ich über Xiaomi Aquara Temperatur-, Druck- und Luftfeuchte-Fühler gestolpert und fand mich plötzlich mitten im ZigBee-Universum wieder.
Die Sensoren sind wirklich klein und verhältnismäßig günstig, außerdem laufen sie mit einer CR2032-Batterie ziemlich lange. Aktuell habe ich sie etwa sechs Monate im Einsatz und die Batterieanzeige verspricht mir immer noch über 80%.

Software

Aktuell kommt für die Anbindung der Sensoren zigbee2mqtt zum Einsatz, dessen Dokumentation und Hardwaresupport vorbildlich ist. Mittelfristig will ich aber die ZigBee-Geräte komplett zu Homegear umziehen.

Das Einrichten von zigbee2mqtt am Pi geht mit dem passenden ZigBee-CC2531-USB-Stick schnell von der Hand und nach kurzem Studium der Anleitung hat man die Sensoren benannt und die Daten im MQTT-Broker:

{
"battery": 86,
"voltage": 2975,
"temperature": 22.07,
"humidity": 45.39,
"pressure": 985,
"linkquality": 102
}

Homegear holt mit großen Schritten bei der Zigbee-Implementation auf und io.broker funktioniert ebenso wie zigbee2mqtt da es auf zigbee-herdsman, eine freie ZigBee Implementierung in nodeJS, setzt.

Um den üblichen CC2531-USB-Stick zum laufen zu bekommen, muss man ihm eine entsprechende Z-Stack-Firmware verpassen. Da ich direkt einen CC-Debugger mitbestellt habe war das kein Problem. Es gibt auch Möglichkeiten den Stick mit einem Pi oder Arduino zu flashen.

Plötzlich hat man aber die ganzen Probleme am Bein: Angefangen von der teilweise unterirdischen chinesischen Hardware, über die verschiedenen Firmwares für selbige – vor allem aber die Reichweite von 2,4GHz mit schlechten Antennen.

Die China-Sticks gibt es zum Glück auch mit externer statt PCB-Antenne was die Reichweite etwas verbessert. So lange man aber keine aktiven – also mit Strom versorgten – Komponenten in seinem ZigBee-Mesh hat, hat man keine Repeater. Also Geräte, die grundliegend erst mal ein Mesh aufbauen können. Alle batteriebetriebenen Geräte haben eine solche Funktion aus Stromspargründen logischerweise nicht.
Meine Hue-Lampen sind aktuell nicht im Betrieb und hängen außerdem noch an der Hue-Bridge – somit können diese nicht als Repeater fungieren.

Alternativen zum CC2531-USB-Stick sind übrigens das RaspBee-Modul oder der ConbeeII-Stick, die wohl auch recht gut funktionieren und in jedem Fall ein Fortschritt gegenüber den China-Sticks sind.
Mein Problem dabei: Keine externe Antenne und demnach weniger Reichweite. Eine Installation des Raspberry Pi’s im Serverschrank fällt dabei auch aus, da die Funksignale nur schwer durch die Metallwände des Schrankes kommen…

Hardwaregrundlagen

Warum gibt es also kein ZigBee-Modul für den RaspberryPi mit externem Antennenanschluss? Dem aufmerksamen Leser meines Blogs wird aufgefallen sein wo das hin führt… 😉

Der CC2531 ist ein von Texas Instruments entwickelter ZigBee-Microcontroller und quasi der Standard für ZigBee-Kommunikation. Er hat einen Bruder, den CC2530.
Der einzige wirkliche Unterschied zwischen den Beiden ist der beim CC2530 fehlende integriete USB-Stack, wodurch er eben nicht ohne zusätzliche Hardware am USB-Anschluss betrieben werden kann. Der CC2530 stellt nur ein UART-Interface zur Verfügung.
Beide Chips können zur Reichweitenverbesserungen mit einem CC2592 kombiniert werden.

Das Schöne ist jetzt, dass es bereits fertige SMD-Module mit CC2530 und CC2530+CC2592 von EByte gibt, deren Bauteile ich ja bereits beim CC1101-868MHz-Modul einsetze und die wir in der Firma offiziell, inkl. Zoll und Einfuhrumsatzssteuer, importieren. EByte baut beide Module in Varianten mit PCB-Antenne und u.FL-Antennenanschluss.

ZigBee Raspberry Pi Modul

Die theoretische Funkreichweite für das CC2530-SMD-Modul wird vom Hersteller mit 240m angegeben, für den CC2530+CC2592 sogar 1000m. Dass diese Entfernungen in der Realität maximal auf dem freien Feld bei Sichtverbindung und idealen Antennen erreichbar sind, sollte klar sein.

Ich hab mich also dran gesetzt und eine Adapterplatine mit dem Modul E18-MS1-IPX für die GPIO-Leiste des Raspberry Pi gebaut. Da das Modul eine u.FL-Buchse habt, kann man einfach eine externe Antenne anschließen. Das ermöglicht den Betrieb mit besserer Reichweite oder zum Beispiel den Betrieb in einem Schaltschrank/Serverschrank.

„Long-Range“ Variante

Zusätzlich gibt es noch eine „Long Range“-Variante wo dem CC2530 ein CC2592 „Range Extender“ vorgeschaltet ist. EByte bietet das im Modul E18-MS1PA1-IPX, das ich genauso wie das E18-MS1-IPX implementiert habe.

The CC2592 device is a range extender for all CC25XX2.4-GHz low-power RF transceivers, transmitters, and system-on-chip products from Texas Instruments.
To increase the link budget,the CC2592 device provides a poweramplifier for increased output power and an LNA with a low-noise figure for improved receiver sensitivity.

https://www.ti.com/lit/ds/symlink/cc2592.pdf?ts=1592397878858

Fertige Module

CC2530 ZigBee Raspberry Pi Modul V0.3
CC2530 ZigBee Raspberry Pi Modul V0.3
CC2530 ZigBee Long-Range Raspberry Pi Funkmodul V0.3
CC2530 ZigBee Long-Range Raspberry Pi Funkmodul V0.3 mit integriertem CC2592

Die fertigen Module können im cod.m-Shop bestellt werden. Zusätzlich bieten wir Bundles mit verschiedenen Antennen an sowie eine Auswahl an passenden 2.4GHz-Antennen.

2,4GHz Antennen im cod.m Shop
2dBi, 2.5dBi, 5dBi und 3.5dBi 2,4GHz Antennen

Firmware

Wie bekomme ich aber nun die Firmware auf das Modul? Man benötigt dafür einen CC-Debugger oder muss etwas – wie oben erwähnt – mit einem Arduino oder Raspberry Pi basteln.
In vielen Facebook-Gruppen sieht man Anfragen nach fertig geflashten USB-Sticks oder die Frage nach jemandem, der bereit wäre die Firmware auf den in China erstandenen Stick zu flashen.
Um diesem Problem aus dem Weg zu gehen, kann man bei der Bestellung im cod.m-Shop die Firmware wählen und bekommt ein direkt einsatzbereites Modul.

Homegear mag aufgrund der Art der Implementation lieber die Z-Stack Firmware 3.0.x. zigbee2mqtt kommt bei Version 1.2.x genauso wie mit 3.0.x klar – sollte demnach genauso für io.broker gelten.
Version 3.x – nicht verwechseln mit 3.0.x – befindet sich noch in der Entwicklung und ist sowieso nicht mehr für den CC2530 konzipiert.
Bei der Auswahl von Z-Stack 3.0 spielen wir die Version mit Serial-Boot-Loader (SBL) auf. Damit sollte man dann auch ohne CC-Debugger eine Firmware updaten können. Habe ich aber bisher nicht getestet.
Siehe Ende des Artikels…

Informiert euch in jedem Fall über die Unterschiede der Firmware für euren entsprechenden Anwendungsfall.

Inbetriebnahme

In der Standardkonfiguration eines Raspberry Pi’s ist der UART der GPIO-Leiste durch eine serielle Konsole belegt. Um ihn also als serielle Schnittstelle nutzen zu können, muss man diesen zuerst freiräumen und sicherstellen, dass Bluetooth den mini UART benutzt.

Öffnet mit einem Editor die Datei /boot/cmdline.txt und entfernet alle Einträge die console=serial0,115200 oder console=ttyAMA0,115200 lauten. Dann noch in der Datei /boot/config.txt zwei Zeilen hinzufügen

enable_uart=1
dtoverlay=miniuart-bt

Abschließend noch den „Modem System Service“ mit sudo systemctl disable hciuart deaktiveren.
Nach einem Neustart kann der UART über /dev/ttyAMA0 genutzt werden.

Zigbee2MQTT und auch Homegear erklären das auch nochmal sehr genau auf Ihren entprechenden Konfigurationsseiten:

Homegear ZigBee Manual
zigbee2mqtt: Connecting the CC2530

Den beiden verlinkten Anleitungen könnt ihr zur weiteren Einrichtung folgen. Im groben muss jetzt nur noch das Modul konfiguriert werden.

Homegear

Nach Installation des Moduls homegear-zigbee die Datei /etc/homegear/families/zigbee.conf bearbeiten und entsprechend anpassen: 

[Serial]
id = CC2530
deviceType = serial
#use your own 16 bytes hexadecimal key!
password = AABBCCDDEEFF11223344556677889900
device = /dev/ttyAMA0

zigbee2mqtt

Bei zigbee2mqtt muss nach erfolgreicher Installation in der Datei /opt/zigbee2mqtt/data/configuration.yaml folgendes ergänzt werden: 

serial:
  port: /dev/ttyAMA0
advanced:
  baudrate: 115200
  rtscts: false

io.broker

Ich habe selbst keine io.broker-Installation und habe daher auch keine Tests gemacht. Die Module sollten, da es sich ja „nur“ um CC2530 handelt, aber dort genauso funktionieren. Wie weiter oben beschrieben, wird dort auch der zigbee-herdsman genutzt, der auch zigbee2mqtt zu Grunde liegt.
Die io.broker ZigBee-Anleitung führt sie in jedem Fall als kompatibel auf.

Pairing

Nach der Konfiguration die jeweilige Software neu starten und es kann mit dem Pairing losgehen. Dieser Prozess ist in den jeweiligen Anleitungen sehr detaliert erklärt und ist im Normalfall ohne größere Hürden zu nehmen.

Homegear: Adding Zigbee Devives
zigbee2mqtt: Pairing Devices

Ich glaube jetzt das einzeln nochmal hier hin zu schreiben macht keinen Sinn, oder?

Fazit

Für „mal Schnell“ ne Platine machen, war es doch ein wenig mehr Aufwand 😉
SMD-Module und Antennen sourcen, Platine designen mit mehreren Prototypen und natürlich noch Anleitung schreiben und dergleichen.
Dann die passende Software finden für den CC2530 und den CC2530+CC2592 – da auch noch mal dickes Danke an Koen Kanters der durch die Entwicklung von zigbee2mqtt und der Bereitstellung von fertiger Z-Stack-Firmware Vieles erst möglich gemacht hat.

Wenn es zukünftig brauchbare CC2538-SMD-Module gibt, werden ich denke damit in jedem Fall ein Aufsteckmodul bauen. Der CC2530 ist teilweise einfach ein bisschen schwach auf der Brust und ist, was die Anzahl der Geräte angeht, doch sehr begrenzt.

Update: Mittlerweile gebaut und verfügbar: https://shop.codm.de/automation/zigbee/29/zigbee-cc2538-raspberry-pi-modul
Der CC2538 wird nur von Z-Stack Firmware 3.0.x unterstützt und ermöglicht bis zu 100 Children direkt am Coordinator. Näheres dazu auf der Produktdetailseite.
Außerdem ist damit, durch die hinzugekommenen Reset- und Flash-Buttons, auch ein Update der Firmware direkt über die GPIO-Leiste des Raspberry Pi möglich.

Wie immer gilt, bei Fragen und Anregungen jederzeit melden.

by ·Keine Kommentare
Homegear mit Beckhoff BK9000 Titelbild

Wie bereits an anderer Stelle erwähnt, haben wir Ende 2018 ein Haus gekauft und fast das komplette Jahr 2019 damit verbracht es zu renovieren. Endlich konnte ich Grundlagen für eine Automation schaffen und war nicht mehr an die Grenzen einer Mietwohnung gebunden 😁
Die Frage war also, was verbaue ich für die Aktorik (Schalten) und Sensorik (Taster, Fühler, etc.)?

Findungsphase

Geplant ist die komplette Beleuchtung, alle Taster, die Rollos/Raffstores und die Heizung zu automatisieren. Zusätzlich noch die Anbindung des Logitech Media Servers und eine ordentliche Anzeige und Steuerung per Handy/Tablet.

Die erste Idee war der Einbau eines Loxone Miniservers um die wirklich gute Visualisierung zu nutzen und von den vielen fertigen Funktionen zu profitieren. Durch den von mir entwickelten node-red-Node (node-red-contrib-loxone) hätte ich ja die Möglichkeit beliebige Komponenten mit Loxone zu verbinden…
Allerdings wurde keine neue Hauptverteilung eingebaut, wodurch wir platztechnisch ein wenig begrenzt waren. Noch dazu hätte ich für die benötigte Anzahl an Ein- und Ausgängen mindestens acht bis zehn Loxone-Extensions benötigt. Das entspricht dann genau so vielen Plätzen auf der Hutschiene mit jeweils neun TE und kostentechnisch wäre es nur schwer abbildbar.

Es musste also eine andere Lösung her: Durch meine Erfahrung und Begeisterung für Homegear war schnell klar, dass damit das Herz der Automation realisert wird. Node-Blue als Grundlage für Logik und Abläufe bildet dafür eine exzellente Basis. Dazu kommt noch, dass es mit der Zeit immer mehr fertige und nutzbare Module in node-blue gibt – so zum Beispiel ein PID-Regler zur Heizungssteuerung.

Hardware

Mit dieser Entscheidung hieß es dann herauszufinden, welche Mittel für Taster und Schaltaufgaben zur Verfügung stehen. Eine Möglichkeit wäre natürlich gewesen auf Homematic oder EnOcean zu setzen… ich wollte aber keine Funkprotokolle nutzen, wenn ich die Möglichkeit habe Kabel zu verlegen.
Nach ein paar Gesprächen zum Thema, wurde ich auf homegear-beckhoff und die damit mögliche Anbindung eines Beckhoff BK9000 Felsbuskopplers aufmerksam gemacht. Danke Sathya 😉

Die Steuerung von Beckhoff ist eine ausgewachsene Industriesteuerung die über verschiedenste Module erweitert werden kann. Basis bildet ein Buskoppler um den sog. Feldbus anbinden zu können. Diese „Feldbuskoppler“ gibt es mit zig verschiedenen Schnittstellen wie zum Beispiel CAN, RS485, ModBus und Ethernet.
Ähnliche Systeme mit vergleichbaren Leistungsmerkmalen gibt es auch von Wago und Phoenix Contact – allerdings sind die Jungs von Homegear noch nicht dazu gekommen eine Anbindung dafür zu schreiben 😉

Homegear nutzt zur Kommunikation mit einem Beckhoff BK9000 Ethernet-Feldbuskopplers ModBusTCP. Darüber können bereits verschiedenste Module – die in diesem Kontext Feldbusklemmen heißen – angesprochen werden. Neben reinen digitalen I/O-Modulen werden bereits analoge Ein- und Ausgänge sowie ein Modul für PT100-Temperaturfühler unterstützt. Diese Module können am Feldbus beliebig kombiniert werden und es gibt noch viele weitere Module von Beckhoff.

Der Feldbuskoppler selbst enthält keine Logik und dient nur zur physischen Anbindung der bis zu 64 Module pro Feldbus. Mit Homegear kann man nun die Logik abbilden und zum Beispiel auch eine Brücke zu mqtt schlagen, um die I/O’s in beliebigen (anderen) System nutzen zu können.

Aufbau

Installation Beckhoff BK9000 im Schaltschrank

In meinem Fall nutze ich die Feldbusklemmentypen KL1408 für acht digitale Eingänge und KL2408 für acht digitale Ausgänge. Diese werden in verschiedener Häufigkeit am Feldbus angesteckt und dann der Feldbus mit einer Busabschlussklemme BK9010 terminiert. Bei mir also

  • 5 x KL2408 = 40 x 24V/500mA Ausgänge
  • 8 x KL1408 = 64 x 24V Eingänge
  • 1 x KL9010 Busabschluss

Beim Aufbau des Feldbusses bitte in jedem Fall die Vorgaben von Beckhoff beachten und für die Versorgung der Klemmen, inkl. der eventuell angeschlossenen Verbraucher, in jedem Fall den Bus passend aufteilen und mit Buseinspeiseklemmen arbeiten.

An den Eingangsklemmen (lila Kabel) sind normale Taster oder Bewegungsmelder mit 24V angeschlossen, die per J-Y(ST)Y aus dem ganzen Haus kommen. Für das Schalten von 230V nutze ich Koppelrelais in verschiedenen Größen (rote Kabel). Dazu kommen dann zukünftig noch die Heizungsstellmotoren.

Obwohl wir keine Fußbodenheizung haben, hatten wir das Glück, dass die meisten Heizkörper über einen Heizkreisverteiler versorgt sind. Dort kommen 24V-Stellantriebe zum Einsatz, die ohne Probleme direkt von den Digitalausgängen der KL2408 geschaltet werden können.

Für die Beleuchtung setze ich den von uns (cod.m) entwickelten 10-Kanal LED-Dimmer ein. Dafür werde ich natürlich noch mal einen gesonderten Artikel schreiben – genauso wie für die Lösung zur Messung der Temperaturen in den einzelnen Räumen. Da bin ich noch nicht ganz wo ich sein will 😉

Programmierung

Liste von Kanalnamen im Admin-UI
Benamung einer KL2408-Klemme im Admin-UI

Der Feldbuskoppler wie auch die angesteckten Klemmen müssen Homegear bekannt gemacht werden. Das ist mittlerweile recht einfach über das Admininterface möglich. Es empfiehlt sich die Datenpunkte bei diesem Schritt direkt passend zu benennen. Sie tauchen dann mit diesen Namen in node-blue auf und können über den variable-in-node einfach genutzt werden.

Für simple Schaltaufgaben ist es fast schon zu einfach: Durch den Toggle-Node wird der Zustand eines Ausgangs beim Triggern einfach nur umgeschaltet. Wichtig ist dabei, dass jeder Tastendruck der durch die KL1408-Klemme an Homegear weitergereicht wird, eine steigende und fallende Flanke hat. Also true wenn der Taster gedrückt wird – der Eingang auf „high“ geht und false wenn der Taster losgelassen wird – der Eingang also wieder „low“ wird. Der Toogle-Node verarbeitet das direkt entsprechend.

Einfache Ein-Aus-Schaltung mit Tastereingang in node-blue

Eine Sache auf die man bei der Programmierung in node-blue achten muss, ist, dass jeder neue Zustand ein Event erzeugt. Im Beispiel von eben also das true und auch das false. Wenn man nun anfängt boolsche-Verknüpfungen zu bauen, bekommt man auch im Falle von false im Ergebnis einen Event generiert. Wenn man nur an true interessiert ist, kann das leicht mit einen risingedge-node filtern.

Anfangs ist der gedankliche Spagat von klassisch logischer Programmierung (AND, OR, etc.) und eventbasiertem Ansatz etwas schwierig. Nach einer kurzen Eingewöhnungszeit stolpert man dann nur noch selten über diese Hürde.

Da wir ja ein Haus umgebaut haben, konnte ich natürlich nicht an jede Stelle neue Kabel aus der Verteilung ziehen. Für diese Fälle setze ich auf mehrere Shelly’s, die hinter die vorhandenen Schalter – die gegen Taster ausgetauscht wurden – eingebaut wurden.

Der Taster am Shelly toggled das Relais direkt und von anderer Stelle im Raum wird mit einem Taster, der über die Beckhoff kommt, per MQTT das entsprechende Topic des Shelly gefüttert. Der change-node setzt die Message „toggle“…

Flow node-blue Beckhoff Shelly
Schalten eines Shelly’s per MQTT mittels Taster am Beckhoff KL1408

Fazit

Preislich ist die Masse an I/O die ich mit der Beckhoff-Steuerung über Homegear realisieren kann ungeschlagen. Die meisten Teile habe ich über eBay bezogen, als Beispiel für die 8-fach Ausgangsklemme (24V/500mA) zwischen 25,- und 35,- Euro. Pro Ausgangskanal muss dann natürlich noch das eventuelle Koppelrelais gerechnet werden. Im Schnitt bleibe ich dann aber pro Kanal unter 10,- Euro. Der Feldbuskoppler schlägt zwar mit deutlich mehr zu Buche, kann aber auch über eBay bezogen werden.
Für den professionellen Einbau bezieht man die Teile über den Elektrogroßhändler, der im Normalfall entsprechende Rabatte einkalkulieren kann.

Die Reaktionszeiten – also Pollingzeiten für ModBusTCP – können in der Homegearkonfiguration noch mal „getuned“ werden, abhängig von der verwendeten Hardware. Auf meinem Pi 3B+ könnte ich das Pollingintervall also viel niedriger setzen als die aktuellen 50ms. Ich kann aber jetzt schon keine Verzögerungen wahrnehmen – selbst bei Schaltaufgaben für MQTT (Shelly).
Der Beckhoff Feldbuskoppler kann durchaus im 2ms-Takt gepollt werden. Dafür ist er ja gemacht 😉

Ein großer Vorteil ist außerdem der Platzbedarf. Schlussendlich hatte ich in der Verteilung nur vier Hutschienen für die Automation zur Verfügung. Davon werden schon zwei durch die Dimmer belegt – so blieben also nur noch zwei mal 12 TE übrig.
Zugegebenermaßen hätte ich noch einen weiteren Aufputzverteiler setzen können. Dagegen spricht dann aber der preisliche Vorteil der jetzigen Lösung.

Wie immer bei Fragen oder Anregungen melden 👍

Update 26.6.2020

Sathya hat am Beispiel von ein paar EnOcean-Geräten mal ein wenig node-blue im Video erklärt.

by ·Keine Kommentare
Node-Blue Title

Erst mal möchte ich mich für die lange Funkstille entschuldigen. Berufliches und der eigene Hausumbau fordern leider ihren zeitlichen Tribut. Dafür sind dadurch aber viele neue Themen auf den Tisch gekommen die ich verbloggen will und die euch hoffentlich interessieren.

Wie ihr ja wisst, bin ich großer Fan von Homegear. Einerseits weil ich denke, dass Sathya ein wirklich geniales und performantes Stück Software geschaffen hat und andererseits weil ich mit Homegear Geräte transparent in ein anderes Protokoll schieben kann. Dies habe ich mit MQTT in Verbindung mit node-red ja schon mehrfach genutzt.

Also, was ist node-blue?

node-blue ist wie node-red nur anders!

Node-blue ist die Logikengine von Homegear. Von „vorne“ sieht sie aus wie node-red (Editor), im Hintergrund läuft aber eine komplett neu entwickelte C++-Runtime.
Der Vorteil? Man ist nicht an die Begrenzungen gebunden die node.js mitbringt. Unter anderem ist die Verarbeitungsgeschwindigkeit massiv höher und es können mehrere Threads, also auch mehrere CPU-Kerne, verwendet werden.
Die aus node-red bekannten function-nodes werden bei node-blue mit PHP (nativ) oder Python (externer Prozess) programmiert anstatt mit JavaScript. Durch das Multithreading können hängende Nodes node-blue nicht lahmlegen.

Node-red erlaubt immer nur einen „Eingang“ pro Node und sieht auf direktem Weg keine boolschen Verknüpfungen (AND, OR, etc.) vor. Node-blue bringt eigene Nodes für diese Funktion mit – man kann damit also aus der SPS-Programmierung bekannte Logiken aufbauen ohne auf den eventbasierten Ansatz verzichten zu müssen.
Zusätzlich wurden die Debuginformationen an den Nodes im Editor gegenüber node-red erweitert.

Alle in Homegear bekannten Geräte und deren Variablen lassen sich einfach über einen node (variable-in) in den Flow übernehmen und werden bei Auftreten verarbeitet – also genauso wie bei node-red, nur dass hier nicht der Umweg über eine Schnittstelle (MQTT, WebSocket, etc.) oder einen zusätzlichen Node (Hue, API-x, etc.) genutzt werden muss.
Gleiches gilt für die Ausgabe von Werten über den variable-out-node.

But wait, there’s more!

Homegear Admin-UI

Seit Version 0.7.30 bringt Homegear ein eigenes Admininterface mit (http://<ip-host-homegear>:2001/admin/). Darüber lassen sich Geräte nun endlich logisch ordnen – also in Räume, Gruppen und Stockwerke einteilen, neue Geräte anlernen und verschiedene Wartungs- und Einstellungsaufgaben ausführen.
Über den Menüpunkt „Programmierung“ landet man dann auch schon direkt im node-blue Editor (http://<ip-host-homegear>:2001/node-blue/).

Homegear UI
Homegear UI

Außerdem ist ein Userinterface zur Bedienung in der Entwicklung, das man schon unter https://test.homegear.eu ausprobieren kann.
Eine erste Version kann über das Paket homegear-ui bereits installiert werden.

Die Oberfäche wurde zusammen mit der Hochschule Furtwangen entwickelt und macht einen sehr guten Eindruck. Ich bin gespannt wie die vielen Gerätetypen abgebildet und bedient werden.

Ein Programmierbeispiel

Um mal ein bisschen in node-blue einzusteigen, habe ich eine simple Musiksteuerung für meinen Logitechmediaserver programmiert. Unser WLan-Radio im Bad hatte sowieso gerade den Geist aufgegeben und so kam mein portabler Squeezebox-Player zum Einsatz.
Als Grundlage habe ich mir ein Beispiel von Job aus dem Homegear-Forum genommen und ein wenig erweitert. Der Flow sendet nach entsprechender Verarbeitung einfach die gewollten Kommandos per HTTP an den Server.

4-fach EnOcean Taster mit provisorischer Beschriftung

Zur Steuerung wird ein 4-fach EnOcean-Taster genutzt, der über einen USB300-USB-Stick an meine RaspberryPi hängt auf dem Homegear läuft. Die Taster benötigen keine Batterien und passen sich recht gut ins vorhandene Schalterprogramm ein.
Das Anlernen erfolgt als Rocker-Switch und ist mit der richtigen EEP kein Problem. Danach stehen unter der entsprechenden Geräte-ID die Kanäle des Schalters in Homegear/node-blue zur Verfügung.

Ein Taster liefert true solange er gedrückt ist, sowie man ihn loslässt wird ein false gesendet. Mit den entsprechenden node-blue nodes kann man so eine einfache Steuerung realisieren und auch das Halten der Taste auswerten.
Die Programmierung in den function-nodes ist eher simpel. Es werden nur ein paar Variablen gesetzt, die dann im unteren Teil des Flows in eine URL umgewandelt und gesendet werden.

Mit dem Playlist-Button (oben rechts) kann man durch die im cycle-playlist-node hinterlegte Liste von Streaming-URL’s schalten.
Eine Verbesserung die ich noch plane ist, dass man bei Doppelklick auf diesen Taster zum ersten Eintrag in der Playlist springt. Node-blue bringt für solch eine Funktion schon einen eigenen Node mit.
Es ist nicht immer leicht den Sender zu „erraten“ den man gerade hört und eine visuelle Ausgabe fehlt mir gerade 😉

Komplette Programmierung einer Squeezeboxsteuerung in node-blue

Der komplette Flow ist im oben verlinkten Homegear-Forum-Thread zu bekommen.

Wichtig: Leßt bitte in jedem Fall die Info der einzelnen nodes. Die Doku ist zugegebenermaßen noch etwas dünn, das Wichtigste was man zum Verständnis braucht, steht aber dort.

Fazit

Node-blue ist unheimlich schnell und die Programmierung geht – nach etwas Eingewöhnung – fast schneller von der Hand als bei node-red. Das ist vor allem der vorhandenen boolschen Logik-Engine zu verdanken. Man muss, wie bei allem was man neu anfängt, erst mal seinen Kopf dazu bekommen in den neuen Strukturen zu denken.

Nachteil an node-blue ist die aktuell dünne Dokumentation und die nicht wie von node-red gewohnte node-Vielfalt. Mit homegear-nodes-optional gibt es schon ein paar Erweiterungen, diese kommen an Vielfalt aber natürlich nicht an die schiere Masse bei node-red ran.
Hier gilt auch wieder der Open-Source-Gedanke: Wer mitmacht und vielleicht sogar eigene Nodes oder Dokumentation erzeugt, hilft allen die node-blue benutzen.

Homegear wird aktuell an allen Stellen weiterentwickelt und wird immer mehr zu dem, was man auch als nicht so technisch versierter Anwender gebrauchen kann. Die Einstiegshürde – auch zur Programmierung – wird immer niedriger.

Update

Die Weiterentwicklung des Flows zur Logitech-Mediaserver-Steuerung könnt ihr im Homegear-Forum verfolgen: https://forum.homegear.eu/t/flow-squeezebox/2664/7

by ·85 Kommentare

Mit einer Version ohne externe Antenne war es natürlich nicht getan 😉

CC1101 SPI Adaptor mit u.FL Antennenbuchse

Im üblichen chinesischen Warenhaus habe ich noch ein weiteres CC1101-Modul (E07-868MS10) mit passender 868MHz-Antennenkonfiguration gefunden. Da die ersten Funktionstests erfolgreich waren, bot es sich an damit zu lernen, wie man SMD Komponenten mit Lötpaste (Sn42/Bi57.6/Ag0.4) lötet. Eine Heißluftlötstation hatte ich mir vor längerer Zeit angeschafft, um besser entlöten zu können.

Das Adapterboard in einer ersten Version mit u.FL-Antennenbuchse habe ich jetzt endlich testen können (siehe Bild). Die Entwicklung dazu lässt sich im homegear Forum verfolgen.
Natürlich ist hier antennentechnisch und auch löttechnisch noch nicht alles hundertprozentig rund, aber ich bin mit den ersten Ergebnissen recht zufrieden.

u.FL Buchse mit etwas zu viel Lot

Pads mit ungleichmäßig verteiltem Lot

Man sieht klar, dass ich noch an der Verteilung der Lötpaste arbeiten muss. Wenn es mehr als ein paar Platinen werden sollten, werde ich in jedem Fall das passende Stencil mitbestellen, um die Lötpaste ordentlich aufzutragen. Das Zweite Board war zum Glück schon besser 🙂

Ich entwickle gerade mit etwas Hilfe aus dem Forum V0.2 des Boards. Es fehlt zum Beispiel noch an Groundplane für die Leiterbahnen des Antennenanschlusses. Eventuell schaffen wir es sogar eine Platine mit Leiterbahnantenne zu bauen.

Außerdem führe ich auf der neuen Version nicht nur GDO2 sondern auch GDO0 aus. Dadurch ändert sich zwar die Zuordnung zu den GPIO’s, aber man kann das Modul dann zum Beispiel für einen CUL nutzen. Bei meinen Tests hat allerdings der Selbstbau-CUL auch mit nur einem GDO für 868Mhz funktioniert.

Wie immer gilt: bei Fragen und Anregungen gerne melden. Auch wenn jemand ein Modul kaufen möchte.

Nachtrag

Mittlerweile hab ich mit der Hilfe von @malli aus dem Homegear-Forum die Antennenleiterbahnen inkl. Groundplane passend für 868MHz überarbeitet. Die Adapterplatine kann nun entweder mit U.FL-Buchse oder Drahtantenne bestückt werden.

Nachtrag II

Die Platinen von OSHPark sind endlich da und ich muss sagen, ich bin mit dem Ergebnis sehr zufrieden. Die Platinen können bei OSHPark oder bei mir komplett bestückt, mit U.FL-Buchse oder Drahtantenne, bestellt werden.

Das CC1101 SPI Raspberry Pi Modul kann im cod.m Online-Shop bestellt werden!

Hier die Config für V0.3 des Moduls mit Homematic (homematicbidcos.conf):

[TI CC1101 Module]
id = My-C1101-Module
default = true

deviceType = cc1100
device = /dev/spidev0.0
responseDelay = 100

interruptPin = 0
gpio1 = 25

Und so sieht das Ganze mittlerweile bei mir zu Hause aus:

by ·7 Kommentare

Da ich vermehrt Homegear für Kunden einsetze und nicht ständig das CC1101-Modul aufs neue an Kabel anlöten wollte, habe ich mir mal eine kleine Adapterplatine gebaut.

Das (chinesische) CC1101-Modul ist die günstigste Möglichkeit mit einem Raspberry Pi und homegear auf Homematic oder Max! Komponenten bei 868MHz zuzugreifen. Von Timing ist diese Variante auf jedem Fall einem CUL – also USB Stick – vorzuziehen.

Wie im vorigen Beitrag „Homematic mit node-red über homegear“ zu sehen ist, ist die Kabellösung doch auch immer recht unordentlich und vor allem fehleranfällig.

Wer mag kann die Platine bei OSHPark für $2.85 je 3 Stück (keine Versandkosten) bestellen und das CC1101-Modul auflöten. Dazu benötigt man ansonsten nur noch eine 2X05-Buchsenleiste um die Platine dann auf den Pi aufstecken zu können. Das Modul wir, wie im Bild zu sehen, ab Pin 17 der GPIO-Leiste des Pi gesteckt, GDO2 ist dann auf GPIO25 ausgeführt.

Hier mal beispielhaft der Auszug aus der homematicbidcos.conf:

[TI CC1101 Module]

id = My-CC1101
default = true

deviceType = cc1100
device = /dev/spidev0.0

responseDelay = 100

interruptPin = 2
gpio1 = 25

Wenn die Nachfrage groß genug ist, überlege ich das Modul komplett fertig verlötet zum Verkauf anzubieten. Also gerne melden 😊

Update: Ich habe mittlerweile neue Version des Adapters gebaut: https://allgeek.de/2017/09/23/cc1101-spi-adapter-mit-u-fl-antennenbuchse/

Update 2: Das CC1101 SPI Raspberry Pi Modul kann im cod.m Online-Shop bestellt werden!

by ·18 Kommentare

Inspiriert von Oliver Lorenz schreibe ich hier mal eine Alternative zum Anbinden von Homematic-Komponenten an node-red auf. Ich nutze für die Hardwareanbindung der Homematic-Komponenten homegear, da es mir die bidirektionale Kommunikation per mqtt erlaubt.

In Oliver’s Post musste ein Programm auf der CCU geschrieben werden, um die Zustände bei Auftreten (event) „zurück“ an node-red zu melden, oder sie müssten zyklisch abgefragt werden. Durch die Nutzung von homegear entfällt dieser Schritt, weil jedes event direkt per mqtt kommuniziert wird.

Hardware

Aus einem Vortrag beim @make_ldk von letztem Jahr habe ich noch folgende Folie, die die Struktur recht anschaulich zeigt:

Es bietet sich an, homegear auf einem Raspberry Pi zu betreiben, da man dort den direkten Zugang zu den eventuell benötigten Hardwareschnittstellen hat. Homegear kann mit einer Vielzahl von Geräten mit homematic (BidCOS) kommunizieren. Ich nutze hier ein CC1101-Funkmodul, das per SPI angebunden wird. Natürlich kann man auch das HM-MOD-RPI-PCB, das HM-LGW oder eine CUL benutzen. Weiteres dazu in der homegear-Dokumentation zu Homematic-BidCOS.

Auch wenn das CC1101-Modul der basteltechnisch größere Aufwand ist, so ist es doch die günstigste und auch technisch beste Lösung (Timing). Die Module lassen sich für unter 5,- € bei den üblichen chinesischen Versandhäusern bestellen. Pollin bietet zum Beispiel auch ein CC1101 Modul an, was sich ohne Probleme einsetzen lässt.

Der CC1101 kann mit 868MHz oder 433MHz funken, allerdings muss er für die entsprechende Frequenz die passenden Antennenkonfiguration vorweisen – 433er-Module funktionieren nicht mit Homematic, das in 868MHz funkt. Auf den Marktplätzen werden viele Module mit 433MHz als 868MHz verkauft. Am besten haltet ihr euch an die Vorschläge im Wiki von FHEM für den Selsbstbau-CUL, den ihr natürlich auch mit homegear nutzen könntet.

Homegear kann mehrere Protokolle/Hardware anbinden. Es kann also nicht nur mit Homematic, sondern auch mit MAX!, Sonos, Philips Hue, Intertechno uvm. auf dem hier gezeigten Weg kommuniziert werden.

Software

Ich nutze für dieses Beispiel hier nicht das fertige homegear-Raspbian, da es sich um ein für den Dauerbetrieb optimiertes read-only Image handelt. Stattdessen habe ich ein Raspbian mit node-red installiert und dort zusätzlich mosquitto (ein mqtt-broker) und homegear mit dem homematic-bidcos Paket installiert. Mosquitto lässt sich sehr einfach über das zur Verfügung gestellte Debian-Repository installieren. Danach nur noch den Dienst mit systemctl enable mosquitto.service aktivieren.
Für die Installation könnt ihr gerne openHABian nutzen oder euch an mein Anfängertutorial zur Installation eines RaspberryPi mit node-red halten. OpenHABian kann node-red wie auch homegear mit installieren.

Für die Grundlagen mag ich euch ein paar Links empfehlen:

Als Client, um die mqtt-Kommunikation zu überwachen, eignet sich mqtt-spy.

Aufbau/Konfiguration

Das CC1101 Modul wird direkt am SPI des Raspberry Pi betrieben, der Anschluss und die Konfiguration sind in der Dokumentation von homegear erklärt: Configure Texas Instruments CC1101 (SPI aktivieren mit raspi-config).

Nach Einrichtung des Betriebssystems sowie Verkabelung muss homegear und das Modul nur noch konfiguriert werden. Schaut dazu bitte in das Grundlagen-Tutorial unter dem Punkt „Konfiguration“ – wichtig auch der Absatz über AES (!) – oder in die Dokumentation von homegear.

Raspberry Pi 3 mit CC1101 SPI Modul

Update: Mittlerweile habe ich einen Adapter für das CC1101 Modul gebaut, damit man nicht immer so einen Kabelsalat veranstalten muss und eine externe Antenne anschließen kann. CC1101 SPI Adapter mit u.FL Antennenbuchse.
Das Modul ist auch bei uns im Online-Shop bestellbar.

Zum Test verwende ich einen HM-LC-Sw1-Pl-2. Nach dem Anlernen, wie unter First Steps beschrieben, meldet sich der Aktor mit seinen Datenpunkten per mqtt unter dem Topic homegear/<homegear-id>/plain/<device-id>/<channel>/<var-name>.
Die homegear-id und der Typ der Meldung wird in der mqtt.conf konfiguriert. Neben plain können auch noch json und jsonobj zurück gegeben werden. Achso, natürlich noch enabled = true setzen, um mqtt zu aktivieren.

Die in den Geräten vorhandenen Datenpunkte können in der offizielen Homematic Dokumentation nachgeschlagen werden.

In unserem Beispiel ist der Status des Aktors also unter homegear/1234-5678-9abc/plain/1/1/STATE zu finden (true/false). Um nun den Status zu „beschreiben“, tauschen wir plain im Topic einfach durch set aus: homegear/1234-5678-9abc/set/1/1/STATE. Dort können wir nun entweder true oder false hinterlegen (publish) – 1/0 würde genauso funktionieren, homegear verarbeitet die gelieferten Daten logisch.

In mqtt-spy kann man nun sehr gut die Zustandsänderungen unseres Status beobachten:

An „Last Received“ der Nachricht sieht man, dass Schaltbefehl senden (set) und Änderungen des Status (STATE) nur ca. 150ms auseinander liegen.

Die Zeit zwischen Betätigung des Tasters am Aktor bis zur Meldung per mqtt ist leider etwas länger (ca. 2s). Das liegt allerdings am Aktor selbst und im weiteren Zusammenhang an der 1%-Regel bei 868MHz.

node-red

Beispielhaft verwende ich node-red-dashboard zum Schalten des Aktors.

Man abonniert (subscribe) also das Topic des Status des Aktors und gibt diese msg.payload in einen Dashboard-Switch-Node. Der Switch muss so konfiguriert werden, dass er true und false als String in der on- bzw. off-payload versteht.

Beim Schalten sendet der Switch die konfigurierte Payload an seinen Ausgang und wir senden diese an unser set-Topic (publish).

Wichtig ist, dass ankommende Nachrichten nicht direkt an den Ausgang durchgereicht werden,  da es durch die 150ms Verzögerung beim Schalten zu einer Race-Condition kommen würde. Zum Glück bietet uns der Switch-Node dafür schon eine passende Option:

Der Switch-Node ändert seinen Status durch das eingehende Topic und sendet bei Betätigung die Änderung an das ausgehende Topic.

Conclusion


(die USB-Kamera hat ein wenig Verzögerung)

Damit haben wir erfolgreich Homematic bzw. jedes von homegear zur Verfügung gestellte Gerät an node-red per mqtt angebunden. Wichtig hierbei ist, dass wir dadurch einen eventbasierten Rückweg haben, also auch Schaltaktionen am Aktor selbst oder durch andere gepairte Homematic-Geräte direkt wieder in node-red gemeldet bekommen.

Ein weiterer Weg wäre über das neu in homegear eingeführte node-blue nur bestimmte Variablen der Geräte in mqtt zu publishen. Dazu dann vielleicht mal mehr in einem anderen Artikel.