by ·Keine Kommentare

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…

Prototyp RP2040/W5500 ZigBee Coordinator

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)

by ·16 Kommentare

Update 2020:

Mittlerweile haben wir eine professionelle Variante des Pixel Controllers mit WLED als Software gebaut.

cod.m WLAN Pixel Controller in Gehäuse
cod.m WLAN Pixel Controller V0.4

Nähere Informationen bei uns im Webshop und demnächst im Blog.
https://shop.codm.de/automation/pixel/30/wlan-pixel-controller

In unserem Bürogebäude in Haiger befindet sich seit ein paar Jahren im untersten Stockwerk eine Event-Gastronomie: http://arnos-event.de/
Arno, Wirt und Namensgeber der Bar, wollte für seinen Loungebereich eine besonderere Beleuchtung als in den restlichen Räumen.

Die Wahl fiel auf die bekannten Neopixel (WS2812) in RGBW, von denen wir ~1600 Stück in der Lichtkante der Decke montierten. Die Steuerung für den Stripe lag einige Zeit brach, aber nun hatte ich endlich Zeit, etwas passenden zusammenzubauen. Eines der Hauptprobleme ist bis heute, dass es sehr wenige Neopixel-Projekte gibt, die den Warmweiß-Kanal (RGBW) mitbenutzen oder überhaupt mit so vielen Pixel klarkommen. Die Adafruit-Neopixel-Library unterstützt die Anordnung (GRBW) zum Glück… benutzt wird sie aber offenbar von keinem Projekt, was auch die Steuerung von Außen zulassen würde.

Leßt bitte in jedem Fall den wirklich sehr nützlichen und wichtigen Adafruit-Neopixel-Überguide. Hier ist alles erklärt, was ihr über das Arbeiten mit Neopixeln wissen müsst.

Hard- & Software

Meine ersten Versuche begannen auf einem Arduino Mega (ATMega 2560, 8kb SRAM) und ein wenig selbst programmierten Code. Der Mega deswegen, weil er einerseits die richtige Spannung (5V) hat und andererseits genügend Speicher für die ~1600 Pixel bietet.

Für jedes Pixel mit RGBW werden 4 Byte im RAM des Mikrocontrollers benötigt. Das heißt also: 4 x 1600 = 6,4kb. Ein Arduino Uno (ATMega 328p) mit seinem 2kb SRAM wäre damit schlicht überfordert. Ich hatte nur nicht bedacht, dass ich für Transistionen zum Beispiel von einer Farbe zur anderen ja minimum das doppelte an Speicher haben muss.
Die Pixel leuchteten also erst mal einfarbig. Durch ein Ethernet-Shield hatte ich zumindest schon ein krudes HTTP-Interface implementiert, um den Mega von „Außen“ zu steuern, das hat mich aber natürlich wieder Speicher gekostet.

Im Laufe des letzten Jahres habe ich dann immer wieder mal nach Software oder Controllern gesucht, die den Anforderungen genügen würden. Selbst im allseits bekannten chinesischen Warenhaus waren – wenn schon für ~2000 Pixel – nur RGB-Controller zu haben.
Irgendwann bin ich dann auf Tobias Blum’s MCLightning V2 für den ESP8266 gestoßen und war begeistert. Tobias setzt die Adafruit-Neopixel-Library ein, die ja mit RGBW Pixeln klarkommt. Er implementiert zwar auch keine Nutzung des Warmweißkanals, was ich aber für eine vernünftige Steuerung über Websockets oder MQTT fürs erste völlig in Kauf nehmen kann. Zusätzlich dazu hat Tobias die WS2812FX Library eingebunden, die einen netten Haufen an vorgefertigten Effekten mitbringt.

Da ich nicht wusste, wie viele Neopixel ein ESP8266 wirklich verkraften kann, plante ich die ~1600 Pixel auf 5-6 Controller aufzuteilen.

Die Spannungsversorung wird von sechs 10A/5V-Meanwell Netzteilen bereitgestellt. Alle 2,5-3m gibt es eine erneute Einspeisung der Versorgungsspannug um den Spannungsabfall im Stripe zu kompensieren, inklusive dem im Überguide empfohlenem 1000µF Kondensators,.

Controller

Die Idee, einen eigene Controller-Platine zu bauen war schon vor Längerem geboren, jetzt war dann auch die passende Software da. Bei der Hardware gab es folgende Punkte zu beachten:

  • Anpassung Logikpegel 3,3V zu 5V
  • 1000µF Kondensator zum Schutz der NeoPixel
  • Durchleitung von mehreren Ampere (5V) auf der Platine
  • leichte Programmierbarkeit (FOCA-Header, Flashtaster, etc.)

Neopixel werden mit 800kHz gepulst angesteuert, was einen einfachen Levelshifter für die Anbindung an 3,3V ausschließt. Der Adafruit Guide bot dafür zum Glück eine Lösung: 74HCT125 Logic-Level Line Driver. Damit ist es möglich, ohne jeglichen „Hack“, wie zum Beispiel die Nutzung einer Diode, die 5V-Neopixel direkt anzusteuern.

Basierend auf meinem esp2866-proto-board habe ich dann eine einfache Schaltung als Neopixel-Controller entworfen.

Schaltung ESP8266 Neopixel Controller V0.3
ESP8266 Neopixel PCB V0.2

Leider gibt es den 74HCT125 nur in einer Vierkanalvariante. Für die Produktion dieser Platine probierte ich zum ersten Mal Multi-Cicruit-Boards aus, die eine DRC-Datei für Eagle zur Verfügung stellen und somit das Layouten vereinfachen. Die Qualität der Boards ist überragend (HAL Bleifrei), der Silkscreen könnte allerdings etwas besser sein.
Als Controller kommt der bekannte ESP-12F zum Einsatz, der auf die „Mutterplatine“ aufgelötet wird. Die Bauteilegröße ist 1206, um Bestückung von Hand so einfach wie möglich zu machen. Die Kondensatoren und Widerstände sind entweder von Panasonic oder Murata. Den kleinen Preisunterschied zu China-Bauteilen macht die Qualität wieder wett.

Die Platine habe ich zum ersten Mal komplett alleine per Reflow mit Heißluft gelötet. Vielen Dank auch noch mal an Andreas Draxler von Draxler-Elektronik für die geduldige Beantwortung all meiner Fragen und die Hilfe.

Ich habe wie immer viel gelernt, vor allem was man beachten muss und wie schnell sich zum Beispiel zu viel Lötpaste unter dem ESP-12F rächen kann. Für solche Arbeiten ist in jedem Fall ein Solder-Stencil zu empfehlen, den ich aus Kostengründen hierfür gespart habe.

Auftragen von Lötpaste und Bauteilen für das händische Reflow-Löten
ESP8266 Neopixel Controller Platine fertig gelötet

Installation

Da im Gebäude der Installation eine Loxone zur Hausautomatisierung zum Einsatz kommt, stellt sich die Frage der Anbindung. McLightning erlaubt die Steuerung per Websocket, HTTP und MQTT. Da ich ja mehrere Controller gleichzeitig steuern wollte, war der Plan einen RaspberryPi 3 mit eigenem WLAN für die Controller und node-red einzusetzen. Die Verbindung zu den Controllern wird über Websockets hergestellt, weil ich durch das deaktivieren von MQTT und OTA noch mal Speicher spare.

Das bringt uns dann zu der Frage, wie viele Pixel denn nun mit dem Board angesteuert werden können?

EIN Controller (ESP-12F) kann ALLE ~1600 RGBW Pixel mit McLightning ansteuern! Allerdings funktioniert dann das Webinterface auf dem Mikrocontroller nicht mehr komplett, da anscheinend nicht mehr genug Speicher für die Bereitstellung des JSON zur Steuerung der Animationsmodi bereitsteht.
Außerdem ist mir aufgefallen, dass die Effekte dann – trotz maximaler Geschwindigkeitseinstellung – sehr langsam ablaufen.

Ich habe also die Pixel auf drei Controller aufgeteilt und diese dann per node-red vorerst provisorisch verbunden und ein node-red-dashboard zur Steuerung eingerichtet. Die gewünschten Befehle werden einfach nur an alle verbundenen Controller übertragen. Später ist dann die Anbindung an den Loxone-Miniserver per node-red-contrib-loxone geplant.

Conclusion

Auch wenn die Controller unterschiedlich schnell und nicht synchron laufen, kann sich das Ergebnis denke ich sehen lassen. Die unterschiedlichen Geschwindigkeiten kommen durch die unterschiedliche Anzahl an Neopixeln pro Controller zu Stande, ergeben aber bei „Breath“ und „Chasing Rainbow“ auch ganz nette Effekte 😉

Der Regenbogen ist im Beitragsbild oben zu sehen. Hier mal der „Fireworks“-Effekt in Aktion:

Wenn die Nachfrage hoch genug ist, produziere ich gerne ein Paar Platinen und packe sie in den kommenden cod.m-Webshop. Wer eine haben möchte, meldet sich einfach.

Fragen, Feedback? Meldet euch 🙂