2022 haben wir, auf Basis einer Idee von Matthias Kleine von haus-automatisierung.com, einen ZigBee Coordinator gebaut. Der war nicht viel mehr als ein ZigBee-Funkmodul (CC2652P2) und ein USR-Ethernetmodul auf einer kleinen Platine mit Spannungswandler, USB-Buchse und einem 3D-gedruckten Gehäuse drum herum. Power over Ethernet (PoE) war mit dieser Version nur mit externem Adapter möglich.
Offensichtlich haben wir damit aber einen Nerv getroffen, da sich der Coordinator doch recht gut im cod.m Shop verkaufte.

Anfang 2023 wollten wir dann das Modul überarbeiten und zum Beispiel die PoE-Funktionalität mit auf die Platine bringen. Genauso gab es Wünsche an die Firmware. So habe ich Kontakt zu USR aufgenommen um zu gucken ob weitere Features in die Software integriert werden können. Leider gab es da kein positives Feedback und wir fingen mit Überlegungen zu einer kompletten Eigenentwicklung an…

Zu diesem Zeitpunkt war der von uns präferierte ESP32 zwar lieferbar, der nötige LAN8720 für die Ethernetanbindung aber nicht – oder wenn nur sehr schwer.
Die Idee war also auf Basis des RP2040 und dem uns aus anderen Projekten bekannten W5500 eine komplett neue Platine zu entwickeln. Dazu gehörte dann auch die Eigenentwicklung von Firmware für den RP2040 die wir in einem Protoyp mit Grundfunktionalität (ohne PoE) auch schon am laufen hatten.

Durch das normale Tagesgeschäft und (z.B.) die Umstellung der Platinenproduktion sowie die daraus folgende Preissenkung für den cod.m WLED Controller, war unsere Zeit für dieses Projekt leider recht begrenzt.
Die erste Version unseres ZigBee Coordinators mit USR-Modul war etwa ab April/Mai 2023 nicht mehr lieferbar. Und da die neue Version ja schon als Prototyp auf der Werkbank lag, planten wir keine Neuauflage der alten Platinen.

Aber was sagt denn die Community zu dieser Entscheidung? Neue Version bauen oder die alte nochmal auflegen. Bei einer Umfrage im Juli in der IoBroker-Gruppe auf Facebook, ließ sich diese Frage recht schnell klären 😉 91% stimmten für die neue Version und der damit verbundenen Wartezeit.

Neuausrichtung Hardware und Firmware-Entscheidung

Im Sommer/Herbst 2023 verbesserte sich dann die Liefersituation für den LAN8720 was uns die Möglichkeit geben würde auf den ESP32 als Basis umzuschwenken. Natürlich würde das heißen, die Hardware komplett über den Haufen zu werfen und die bereits geleistete Arbeit bei der Firmwareentwicklung wäre auch für die Füße.
Leider lief es bei der Firmware-Entwicklung mit Arduino Core auf dem RP2040 im Zusammenhang mit dem Netzwerk-Stack nicht wirklich rund. Benötigte Bibliotheken waren noch nicht auf den RP2040 portiert, Standardfunktionen mussten teilweise reimplementiert werden, Nebenläufigkeit von Prozessen war fragwürdig, etc.

Die Entscheidung fiel also recht schnell: Wir wechseln auf die usprünglich geplante Hardware.

Anstatt dort aber mit der Firmwareentwicklung komplett von vorn anzufangen, schauten wir uns nach bereits vorhandener Software um… und natürlich gibt es dort einige: Angefangen bei der ZigStar-FW, die auf ZiGate-Ethernet aufbaut, hin zu der UZG Firmware, die ein Fork der ZigStar-FW ist.
Alle diese Firmwares für verschiedene ZigBee Gateways stehen unter der GPL. Eine Weiterentwicklung (fork) und Nutzung ist damit kein Problem. Die Entscheidung für unseren Fork fiel auf die UZG Firmware.

cod.m Fork der UZG Firmware

Meine Hoffnung auf Lange Sicht ist, dass sich eine allgemeine Gateway-Firmware entwickelt, die auf verschiedener Hardware läuft. Das ist doch der Grundgedanke von Open-Source 😉
Wir lassen natürlich unsere Änderungen in die UZG Firmware zurückfließen. Zum Beispiel haben wir einen USB-Passthrough implementiert, wodurch der USB-Modus auch ohne die extra Hardware auf der UZG-Platine funktioniert.

Hardwareentwicklung ESP32 mit Auto-Reset Circuit und PoE

Als nächstes Stand dann also die Hardwareentwicklung an. ESP32 hatten wir schon oft genug mit LAN8720 implementiert – soweit kein Problem. Neu für uns war aber PoE und die Integration eines USB-Serial Chips zusammen mit einem Auto-Reset Circuit. Man sollte endlich den ESP32 flashen können ohne irgendwelche Taster auf der Platine drücken zu müssen.

Bisher hatten wir uns das immer gespart, weil keine dauerhafte USB-Verbindung zur Platine gebraucht wurde. Gelegentliches Programmieren des ESP rechtfertigte nicht den Preis für einen FTDI-Chip.

Der ZigBee Coordinator kann aber außer über LAN/WLAN auch über USB betrieben werden – was sicher in den wenigstens Fällen passieren wird. Man kauft sich ja schließlich keinen PoE-fähigen LAN/WLAN ZigBee Coordinator um ihn dann per USB zu betreiben… aber: Die Firmware gibt es her.
Und natürlich macht es das Aufspielen der Firmware massiv einfacher.

Eagle-PCB-Design des cod.m ZigBee Coordinators (ESP32)

Die Wahl fiel klar auf eine USB-C Buchse. In der ersten Version hatten wir mit der verbauten Micro-USB Buchse zu viele Probleme mit Wackelkontakten und mechanischer Stabilität. Beim USB-Serial Chip setzen wir auf den FT231X da der sonst verwendete CH340 nur über chinesische Zulieferer beschafft werden kann.

Beim PoE-Teil wurde es etwas schwieriger. Zuerst mussten wir einen Interface Controller suchen – also einen Chip, der sich mit dem Netzwerk-Switch „unterhält“ und entsprechend die Stromversorgung aushandelt. Hier fiel die Wahl auf OnSemi’s NCP1092.

Dieser erlaubt es uns zwischen PoE- und USB-Versorgung hin und her zu schalten (AUX). USB hat dabei immer Priorität und deaktivert entsprechend PoE. Das funktioniert sogar unterbrechungfrei!
Nur beim Wechsel von USB- auf PoE-Versorgung startet der Coordinator neu, da der NC1092 erneute die Bedingungen mit dem Netzwerk-Switch aushandeln muss.

Die drei LED’s am Gehäuse zeigen entsprechend den Betriebszustand an. Grün für Power, Rot für den Modus und Gelb für das ZigBee-Pairing. Alle LED’s werden per Firmware gesteuert und können auch ausgeschaltet werden.
Der am Gehäuse befindliche Taster hat mehrere Funktionen und kann zum Beispiel den USB-Modus einschalten. Wir haben uns absichtlich für die Betätigung mittels Büroklammer (o.ä.) entschieden.

Fertige Hardware und Dokumentation

cod.m ZigBee Coordinator Gehäuse mit Wandhalterung

Natürlich darf auch ein Gehäuse nicht fehlen. Da wir nicht die Mengen absetzen werden, die eine Spritzgußform für den ZigBee Coordinator rechtfertigen, haben wir wieder ein 3D-Druck Gehäuse designt.

Die Druckdateien bieten wir natürlich kostenlos zum Download an. Diesmal habe ich zusätzlich eine Variaten mit Wandhalterung erstellt, die man sich bei Bedarf selbst ausdrucken kann.
Auch wenn man das Gehäuse in einer anderen Farbe haben möchte, ist das dann kein Problem ☺️
Printables: Druckdateien Gehäuse cod.m ZigBee Coordinator.

Die Schnellstart-Anleitung sollte euch den direkten und unkomlizierten Betrieb ermöglichen. Wie man zum Beispiel die Firmware des ESP32 oder des CC2652 aktualisiert, werden wir euch in detalierten Tutorials erklären.

Alle Infos, Anleitungen und Dateien findet ihr in unserer cod.m Knowledge Base: ZigBee Coordinator.

Fazit

Wenn man sich unsere ersten Platinen anguckt, sind wir doch ein gutes Stück weitergekommen 😉
Wir lernen bei jedem Projekt dazu und ich freue mich wie immer über jeglichen Input eurerseits. Kritik ist gerne gesehen und vielleicht hat der eine oder andere von euch ja auch noch eine Idee, was wir besser machen können.

Danke für eure Geduld und euren Support! ❤️

cod.m ZigBee Coordinator V1.0 (CZC)

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.