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 ·31 Kommentare

Wie ja viele von euch mit Sicherheit mitbekommen habe, habe ich eine neue Version meines alten WLAN Pixel Controllers gebaut…

LoxPixel!

LoxPixel! Prototyp
LoxPixel! Prototype, © Dennis Henning

Auf Basis von Dennis‘ Loxpixel-Projekt habe ich mit ihm zusammen die Idee weiterentwickelt und zuerst seine Prototypenplatinen überarbeitet. In Zusammenarbeit mit m0fa, zu dieser Zeit Entwickler bei cod.m, haben wir die von Dennis entwickelte Software umgeschrieben und erweitert.

Allerdings kamen wir hier immer wieder an Grenzen, was Zusammenspiel einzelner Bibliotheken, Featurewünsche und Implementation anging. Nach langer Diskussion haben wir uns dann zusammen dazu entschieden, die Codebasis von LoxPixel aufzugeben.

Software

Bei meinen ersten Controller hatte ich auf McLighting als Firmware gesetzt, hatte aber damals schon ein Auge auf das WLED-Projekt geworfen. McLighting wird offensichtlich nicht mehr weiterentwickelt, WLED hat dagegen in den letzten Jahren massive Schritte nach vorne gemacht – ich war buchstäblich erschlagen was die Software mittlerweile kann.

WLED hat ein vorzügliches User-Interface, beherscht über 150 Effekte, bietete zahlreiche API’s (HTTP, MQTT, UDP, DMX, etc.), ermöglicht den Stripe in Segmente aufzuteilen, läuft auf ESP8266 sowie ESP32, es existieren Apps für iOS und Android und es gibt eine sehr aktive Entwicklergemeinde. Viel mehr Infos dazu findet ihr auf der Projektseite: https://github.com/Aircoookie/WLED.
Außerdem werden so ziemlich alle Pixeltypen unterstützt, die man finden kann. Ob WS2801 (Data/Clock), APA201/SK9822 (Data/Clock) oder die weitverbreiteten WS2812/WS2813/SK6812 mit nur einer Datenleitung. Wichtig ist nur, dass die Firmware für diese drei Kategorien unterschiedlich kompiliert werden muss – Standard ist WS281x/SK6812. Mit der kommenden Version 0.12 entfällt auch das.

Jeder, der die Software nutzt, ist aufgerufen bei WLED etwas zu spenden um die Entwicklung weiter zu unterstützen. Link dazu findet ihr auf Github.

Weiterentwicklung

Die Entscheidung für WLED stand also fest. Allerdings konnte WLED nichts mit dem Loxone-Universum anfangen. Klar konnte man per virtuellem HTTP-Ausgang einzelne Effekte schalten aber es gab zum Beispiel für die von Loxone intern verwendeten Farbwerte aus dem Lichsteuermodul keinen direkten Weg.
Genauso macht es zum Beispiel keinen Sinn, einen Slider/Schieberegler per HTTP anzubinden, weil der Overhead des Protokolls zu hoch ist um eine flüssiges Einstellen der (z.B.) Helligkeit am WLED-Controller möglich zu machen.

Wir haben uns also hingesetzt um die direkte Verwendung von WLED mit Loxone zu integrieren. Damit können die Farbinformationen (RGB, Lumitech) aus den Lichtsteuerbausteinen von Loxone direkt an einen virtuellen UDP/HTTP-Ausgang gegeben werden, der die Daten an WLED sendet. Die komplette HTTP-API ist jetzt auch über den bereits vorhandenen UDP-Port (21324) ansprechbar.
Alles weitere dazu kann man im Pull-Request bei WLED nachlesen: https://github.com/Aircoookie/WLED/pull/1185

Seit Version 0.11.0 sind diese Erweiterungen Bestandteil von WLED und können von jedem genutzt werden. Boarddefinitionen für den cod.m Pixel Controller V0.4 und V0.5 sind vorhanden, wobei Version 0.5 die gleichen Pins nutzt wie das Standard-Binary – V0.5 gilt genauso für V0.6.

Hardware

Ich habe mich schon vor Längerem von den ESP-12F-Modulen verabschiedet. Einerseits weil ich schlechte Erfahrungen bezüglich Stabilität mit ihnen gemacht habe und andererseits, weil es teilweise wirklich schwer war verlässliche Module und ordentliche Dokumentation zu bekommen.
Mittlerweile setze ich komplett auf die Espressif-eigenen ESP-WROOM-02-Module, wenn es um den ESP8266 geht. Die bekommt man beim üblichen Distributor und die Dokumentation („Typical Application“, etc.) ist einfach was anderes als bei Aliexpress-Ware.

Gegenüber dem alten Pixel Controller sollte dieses mal auch ein schickes Gehäuse her und zusammen mit Dennis fiel die Entscheidung, den empfohlenen 1000µF-Kondensator nicht mit auf die Platine zu nehmen. Dieser sollte sowieso bei jeder Spannungseinspeisung in den Stripe benutzt werden – siehe Adafruit Uberguide – weswegen wir ihn als eigenständige Platine in Form unseres Power Capacitor Boards gebaut haben.
Wie alles verkabelt wird, findet man im ausführlichen Anschlussplan auf der Shopseite.
Um die Hardware bei Falschverkabelung nicht direkt zu zerstören ist außerdem ein Verpolungsschutz mit an Board.

Pixel Controller in Gehäuse

Bei dem Gehäuse hatten wir uns ziemlich schnell auf „USB-Stick-Größe“ geeinigt und ich fand das Hammond USB1551CLR recht ansprechend. Die gegebene Platinengröße ist ausreichend und durch das transparente Gehäuse konnte man die Status-LED direkt sehen. Einzig die Öffnung muss für die Schraub-Steckklemme etwas bearbeitet werden. Leider unterstützt WLED noch keine Status-LED weswegen die LED aktuell einfach leuchtet, wenn der Stripe eingeschaltet ist.

Ausgangssignal cod.m Pixel Controller V0.6

Wie schon auf der alten Platine ist ein SN74AHCT125D als Level-Shifter von 3.3V auf 5V mit an Board. Damit sind Datenkabellängen von gut zwei Metern möglich und man muss nicht tricksen, wobei man evtl. das erste Pixel verliert (etc.). Im Ozilloskop-Bild sieht man wie „gut“ dadurch das 5V-Signal ist.

Wer längere Strecken (bis 500m) zwischen Controller und Stripe überbrücken muss, kann zu unserem Pixel Range Extender greifen. Schaffe es hoffentlich dazu auch noch mal einen Blogpost zu schreiben.

Natürlich kann man auf dem Controller auch beliebige andere Firmware aufspielen. Der Programmierheader ist ausgeführt und es gibt Buttons für Flash/Reset. Die benutzten Pins sind auf der Platine dokumentiert und ansonsten findet man alles andere auf Github https://github.com/codm/wifi-pixel-controller (Open-Source Hardware, CC-BY-NC-SA).

Grundaustattung

Was braucht man also um eine Beleuchtung mit WLED zu realisieren?

Macht euch in jedem Fall mit den verschiedenen Pixeltypen vertraut. WLED kann auf einem ESP8266 bis zu 850 Pixel adressieren. WS281x/SK6812 ist der gängigste Typ mit nur einer Datenleitung, wobei SK6812 fast immer RGBW Pixel sind und auch unter der von Adafruit geprägten Bezeichnung „Neopixel“ zu finden sind.

Stripes/LEDs

Stripes gibt es außerdem in 5V und in 12V. Bei 12V sind meist drei Pixel zu einem logischen Pixel zusammengefast und die Datenleitung läuft mit 5V (!).
Ich habe gute Erfahrung mit dem Stripes von BTF-Lighting gemacht, die ihr beim Amazon oder den üblichen chinesischen Warenhäußern findet.

Ansonsten ist es wirklich persönliche Präferenz. Ob 30 Pixel/m Stripe, 60 Pixel/m Stripe, 144 Pixel/m Stripe, einzelne LED’s mit Kabel dazwischen (Lichterkette) oder was auch immer. WLED kann mit jedem mir bekannten Pixeltyp umgehen.

Tobt und probiert euch aus 👍🏻

Strom

Weswegen also 5V und 12V Stripes? Das ergibt sich, wenn man anfängt die benötigte Leistung und damit den benötigten Strom eines Stripes zu berechnen. Am Strom hängen zum Beispiel die benötigten Kabelquerschnitte und daran auch wieder die möglichen Leitungslängen.

Als Beispiel: Ihr habt einen 5m Stripe mit 60 Pixeln pro Meter, also ingesamt 300 Pixel. Jede Farbe (RGB/RGBW) pro Pixel schlägt bei maximaler Helligkeit mit 20mA zu Buche (Siehe oben verlinkten Adafruit Uberguide). Bei RGB sind wir dann also bei 5 x 60 x 3 x 20mA und bei RGBW bei 5 x 60 x 4 x 20mA. Ergibt für RGB 18 Ampere und bei RGBW 24 Ampere, respektive 90 bzw. 120 Watt.

Bei 12V sind es dann „nur“ noch 7,5 Ampere (RGB) bzw. 10 Ampere (RGBW) bei gleicher Pixelanzahl.
Aber nochmal: 12V Stripes haben typischerweise drei echte LED’s zu einem logischen Pixel zusammengeschlossen, können also nur zusammen angesprochen werden.
Update: WS2815 12V Stripes haben keine gruppierten Pixel. D.h. jede LED ist einzeln ansteuern bei einer Versorgungsspannung von 12V aber immer noch mit 5V Datenleitung. Das oben genannte gilt also für WS2811@12V aber nicht für WS2815.

Dazu kommt noch, dass die Leiterquerschnitte im Stripe zu gering sind. Wenn ihr jetzt den beispielhaften 5m-Stripe einseitig mit 5V einspeißt, wird nach etwa 2 bis 2,5m bei maximaler Helligkeit (weiß) ein Ausbleichen stattfinden. Deswegen sollte bei 5V der Stripe dort wieder neu eingespeißt werden. Im Beispiel (5m) reicht es, wenn man an beiden enden 5V anschließt. Bei 12V-Stripes sollte ein einspeißen alle 5m ausreichen.
Ist auch nochmal im Anschlussplan auf der cod.m-Shopseite vermerkt.

Bei der Netzteildimensionierung ist also Aufmerksamkeit geboten!
Grundliegend sollte ein Netzteil immer auf den maximal möglichen Stromverbrauch ausgelegt sein plus etwas Toleranz nach oben. In der Realität werdet ihr aber, außer bei 100% Weiß, nie die volle Leistung nutzen. Effekte laufen oft mit nur einer Farbe und selten bei voller Helligkeit – ergo Stromverbrauch.

WLED hat diesbezüglich noch ein Ass im Ärmel. In der LED-Konfiguration kann man den maximalen Strom seines Netzteils hinterlegen. Damit begrenzt WLED abhängig dieser Einstellung die Helligkeit des Stripes, man hat aber bei Effekten durch weniger Stromverbrauch meist trotzdem die volle Helligkeit.

Verkabelung

Anschlusplan WS281x/SK6812 5V

Im Anschlussplan im cod.m Shop hab ich versucht für jeden Pixeltyp wie auch für 5V bzw. 12V alles aufzuzeigen. Wichtig: Der cod.m Pixel Controller muss mit 5V versorgt werden, auch bei 12V Stripes.
Bei Verwendung von getrennten Netzteil für Stripe und Controller ist auf einen „common ground“ – also gemeinsame Masse – zu achten.
(Seit WLED Controller V0.8 nicht mehr nötig)

Das Netzteil sollte so nah wie möglich am Stripe positioniert sein. Der Spannungsabfall bei hohen Leitungslängen ist bei 5V nicht zu verachten, weswegen bei größeren Entfernungen in jedem Fall der Querschnitt entsprechend der Leistung/Länge berechnet werden sollte.

Die Strecke der Datenleitung, also vom Controller zum ersten Pixel, sollte 2m nicht überschreiten (cod.m Pixel Controller). Länger kann klappen, liegt aber an der Umgebung bzw. an eurem verwendeten Controller. Das Signal verschlechtert sich sehr schnell (800kHz).
Wer größere Entfernungen der Datenleitung zwischen Controller und Stripe überbrücken muss, kann – wie schon erwähnt – auf unseren Pixel Range Extender zurückgreifen.

Anbindung

„Womit“ ihr WLED steuert bleibt völlig euch überlassen. Als Standalone-Lösung taugt WLED durch das auf dem Controller laufende Webinterface genauso wie integriert über die zahllosen Schnittstellen.
Falls man mehrere WLED-Controller am laufen hat, kann man diese sehr gut über die WLED-App bedienen und WLED selbst erlaubt sogar die Synchronisation von mehreren Controllern im gleichen WLAN.

Integrationen in node-red, io.broker, openhab, Loxone (etc.) sind entweder über MQTT, HTTP oder UDP möglich. Oft gibt es auch schon fertige Integrationen die genutzt werden können.

Produktion/Aktueller Stand

Üblicherweise entstehen die Platinen bei uns in Kleinserien und Handbestückung. Wer an der Produktion interessiert ist, ich hatte da in einem Twitter-Thread mal ein paar Bilder geposted: https://twitter.com/pregopm/status/1319939302437097473

Aktuell haben wir allerdings einen Auftrag beim Bestücker platziert, weil wir letze Woche völlig überrollt worden sind. Warum fragt ihr euch? Deswegen:

Manuel Dietrich hatte Ende letzten Jahres in der Loxone Users-Facebook-Gruppe seine Garage, die unserem WLED Controller einsetzt, mit großer Resonanz gezeigt. Die Steuerung erfolgt bei ihm über Loxone und das entsprechende Kommunikationsmodul seines Garagentorantriebs.
Einfach nur der Knaller. In seinem Youtube-Video findet ihr alle Befehle und die von Ihm verwendeten Animationen. Im LoxForum hat er außerdem ein kleines Tutorial geschrieben wo er alles wichtige zusammengetragen hat, inkl. einer .loxone-Beispieldatei: https://www.loxforum.com/forum/faqs-tutorials-howto-s/300117-tutorial-garagensturzbeleuchtung-mit-wled

Anfang des Monats sprachen wir kurz und er hat angeboten das Video noch mal in guter Qualität neu aufzunehmen und uns zur Verfügung zu stellen. Nach Postings auf seinem und dem Youtube-Kanal von cod.m war unser Lagerbestand fast weg. Als dann aber auch noch Spiel und Zeug Manuel’s Video gefeatured hat, waren wir am Tag darauf komplett leergekauft.

Mit solch einer Resonanz haben wir nichr gerechnet – WOW! Danke!
Wir wollen baldmöglichst wieder lieferfähig sein, weswegen uns ein befreundeter Bestücker ausgeholfen hat. Bei ein paar Bauteilen gibt es aber aus aktuellen Gründen ein paar Lieferprobleme und wir hoffen ab dem 30.3.2021 wieder das Lager gefüllt zu haben.

Update 10.4.2021: Wir sind schon wieder leergekauft 😳 Aber, Platinen sind schon bestellt und der Slot beim Bestücker ist bereits gebucht. Wir rechnen aktuell damit ab 22.4. wieder liefern zu können.
Danke!!

Update 1.5.2021: Alle Vorbestellungen abgearbeitet und der aktuelle Bestand schwindet schon wieder. Wir haben bereits die nächste Charge bestellt.

Update 20.5.2021: Seit heute versenden wir alle bestehenden Vorbestellungen und haben bereits die erneute Nachproduktion angestoßen, so dass wir zukünftig auch etwas Bestand vorhalten können.
Vielen Dank für die ganzen Bestellungen.

Fazit

Puh, ich bin froh, dass ich das alles endlich mal zusammengeschrieben habe. Die Entwicklung war ja bereits im letzten Jahr und wir verkaufen den Pixel-Controller ja auch schon ein paar Tage.

Ich bin sehr stolz, dass der Entwickler von WLED unsere Ideen so super fand und wir sogar als kompatible Hardware im WLED-Wiki gelistet sind. AirCookie war unheimlich hilfreich und hatte immer ein offenes Ohr. Danke!
Natürlich auch ein dickes Danke an Dennis für die Lox!Pixel-Idee und Manuel für das sagenhafte Video.

Es ist auch bereits die nächste Hardware in Arbeit, will aber noch nicht zu viel verraten. Es geht in jedem Fall um WLED 😉

Ich freue mich wie immer über euer Feedback.

Update: Wir haben ein WLAN Pixel Controller Starterset (WLED) zusammengestellt, vorkonfiguriert und steckerfertig. Bestehend aus 2m SK6812 IP30 Pixelstripe, 6A/5V Netzteil und WLAN Pixel Controller.

Da mir eine Spule/Rolle für 2m Stripe fehlte, habe ich kurzerhand eine desgined und 3D-gedruckt. Files dazu findet ihr auf Thingiverse: https://www.thingiverse.com/thing:4883381

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 ·7 Kommentare

Ich habe zusammen mit dem Loxone-Forum eine Alternative zur DMX-Steuerung auf Netzwerkbasis entwickelt. Hier im Blog habe ich ja schon recht viel über die Hardwareentwicklung geschrieben, wollte aber jetzt auch mal zusammentragen, was sonst noch dazu gehört.

Einstellbare Dimmkurven

Robert Lechner hat im Loxone-Forum vor längerem seine Entwicklung einer Alternative zur Loxone DMX Extension gezeigt und vor allem die Software dafür programmiert. Die Software lässt sich einfach auf einen Arduino (Atmega 328p) mit Ethernet-Shield (W5100) und RS485-Adapter flashen und hat ein paar Vorteile gegenüber der bei Loxone etablierten DMX-Steuerung. Die größten sind wohl, dass beliebige UDP-Kommunikation zur Steuerung genutzt werden kann und, dass sich Dimmkurven sowie Geschwindigkeiten beim schalten übergeben lassen. Man kann also DMX nicht nur am Loxone-Miniserver nutzen, sondern auch an z.B. node-red oder eben einfach an allem, was UDP spricht.
Die Anbindung an Loxone erfolgt über einen einfachen Virtuellen-UDP-Ausgang. Im Loxone-Forum wurde die Anbindung auch schon recht ausführlich erklärt.

Das Protokoll zur Ansteuerung ist von Robert natürlich auch dokumentiert.

Ich bin begeistert, wieviele Leute diese Lösung nachgebaut haben und auch in ein 2TE-Hutschienengehäuse montiert haben, um eine günstigere Alternative zur Steuerung von DMX-Geräten zu haben. Das Feedback im Originalthread liest sich durchweg positiv.

Hier als Beispiel ein paar Bilder von hismastersvoice aus dem Forum:

Im Oktober 2017 habe ich dann eine „große Klappe“ gehabt und angeboten, eine Platine für die Schaltung zu entwickeln.

Ziel war es, eine bestückte Open-Source-Platine zu bauen, die den „besseren“ WizNet-Ethernet-Chip (zuerst W5200 dann W5500) enthält, eine „echte“ MAC-Adresse hat (EUID48), einen Verpolungsschutz sowie einen großen Spannungsversorgungsbereich hat und eine Schutzbeschaltung auf RS485/DMX-Seite enthält. Das Ganze dann bitte noch in einem ansprechenden Gehäuse 😉

Für mich war das eine gute Gelegenheit zu lernen, wie man Ethernet selbst auf eine Platine bringt und was man alles für eine Kleinserie bewerkstelligen muss. In meiner Firma wurde die Nachfrage nach Eigentwicklungen für Kunden auch immer größer und so war es sinnvoll die ersten Versuche zu starten.

Die eigentliche Hardwareentwicklung kann hier im Blog und im Ursprungsthread verfolgt werden.
Natürlich war es damit nicht getan, denn wenn man in DE offiziell Elektronik verkaufen möchten, muss die Entsorgung des Geräts wie auch die Versorgung der Verpackung schon geregelt sein, wenn etwas das Haus verlässt. Meine Firma ist also mittlerweile WEEE-registriert, ist Mitglied im VERE e.V. und lizensiert Versandverpackung. Dazu gehört auch eine monatliche Mengenmeldung an die verschiedenen Stellen und die Zahlung entsprechender Gebühren.
Natürlich wollten wir auch die CE-Konformität für die Bridge erklären, weswegen ich einen mehrtägigen Kurs besuchte, um mich dann – mit externer Hilfe – durch einen Dschungel von CE-Richtlinien und Europanormen zu kämpfen.

Dann war noch die Frage, wo man denn bitte eine Kleinserie der Platinen bestücken lassen kann. Bei ~60 Bauteilen pro Platine wäre der Preis bei Handbestückung einfach nicht mehr marktfähig gewesen. Zum Glück fand ich ein paar Orte weiter einen kleinen Elektronikbestücker, der einen Europlacer und entsprechende Lötautomaten betreibt… es konnte also in die Fertigung gehen.

Vom letzten Prototyp bis zur ersten fertigen Platine vergingen aber noch ein paar Tage. Die Bauteile mussten mit dem Bestücker abgesprochen werden, leichte Änderungen an der Platine gemacht werden und vor allem ein Nutzen gefertigt werden – also die Platte, auf der 2×5 Platinen in einer großen Platine gefertigt sind, damit der Placer diese bestücken kann.

Hier ein Video wie sowas dann aussieht:

Das Endergebnis sieht dann so aus:

Nachdem das alles erledigt war, fehlte nur noch die Anleitung. Diese wird eng an de CE-Konformitätserklärung geknüpft, da dort ja auch Risiken eingeschätzt werden und die bestimmungsgemäße Verwendung definiert ist.
Die Platine ist komplett als Open-Source entwickelt, wer möchte kann sich also anhand des Schaltplans selbst eine Bridge zusammenbauen.

Für alle, die ein fertiges CE-konformes Produkt mit Garantie und Bedienungsanleitung im ansprechenden Gehäuse inklusive Schutzbeschaltung möchten, haben wir die Ethernet DMX Bridge seit letzter Woche offiziell im Verkauf.
Es wurden ursprünglich 30 produziert und es können zeitnah 20 nachproduziert werden.

Ethernet DMX Bridge

Ethernet DMX Bridge im geschlossene 2TE-Gehäuse

Ich freue mich wie immer auf euer Feedback und hoffe, dass ein paar Leute mit den ganzen Infos was anfangen können 🙂

Update

Stephan Löwemann hat ein Tool entwickelt womit man auf einfache Art und Weise die virtuellen Ausgänge für die Steuerung der DMX Bridge in der Loxone-Config erzeugen kann:

https://smarthome-loewemann.de/p/dmx-bridge-to-loxone

Super Arbeit, Danke!

Update II

Wir haben wieder Ethernet DMX Bridges auf Lager und konnten den Preis sogar um 10,- Euro senken: https://shop.codm.de/module/8/ethernet-dmx-bridge-v0.4

Upate III

Endlich ist es soweit, der Nachfolger der DMX Bridge V0.4 ist im Shop bestellbar: DMX Bridge V0.5 im cod.m GmbH Shop.

Volle 512 Kanäle durch die Nutzung eines ATMega 644p anstatt eines 328p und damit mehr zur Verfügung stehender Speicher.
Natürlich ist es immer noch ein 16MHz Microcontroller und beim gleichzeitigen Dimmen von vielen Kanälen wird es zur Performanceproblemen kommen.

Des weiteren sind wir endlich von den günstigen Schraubklemmen weg 😉

by ·38 Kommentare

Bluetooth BLE Sensor Node

Zusammen mit Techdata haben wir bei cod.m auf Basis des Giess-o-Mats einen Bluetooth Low Energy-Bodenfeuchtesensor (soil moisture sensor) gebaut und an die IBM BlueMix Cloud angebunden: https://ibm.techdata.de/weitere-informationen/smart-garden

Technisch misst ein kaskadierter Schmitt-Trigger die Frequenz an den beiden Kontaktflächen, die im Erdreich sitzen. Anhand dieser Frequenz kann eine Aussage über die Bodenfeuchte getroffen werden.
Die Sensoren laufen mit CR2032 Knopfzellen und bilden ein Bluetooth-Mesh. Auf einem RaspberryPi befindet sich ein weiterer Node, der das Mesh zugänglich macht und die Daten an die BlueMix Cloud sendet.

Das zur Präsentation und Proof-of-Concept geplante Projekt hat doch ein wenig Aufmerksamkeit erzeugt 😀

Um nicht auf Batterien angewiesen zu sein, haben wir uns Gedanken gemacht, wie man einen solchen Sensor kabelgebunden realisieren könnte. Die Entscheidung fiel hier recht schnell auf 1-Wire, da man damit ohne großen Implementations- und Verkabelungsaufwand einen Bus mit bis zu 100 Metern aufbauen kann. Außerdem haben wir damit durch andere Projekte genug Erfahrung und können bei dieser Idee darauf bauen. Zusätzlich hatte ich zwischenzeitlich die vorzügliche OneWireHub-Bibliothek gefunden, mit der man ohne große Probleme 1-Wire-Devices emulieren kann.

Da wir ja auch mit der Loxone-Welt recht verbunden sind, haben wir uns für die Emulation eines DS2438 entschieden. Der DS2438 ist eigentlich ein Batteriewächter, der neben Temperatur auch Spannungen von 0.00-10.00V messen und übertragen kann – damit hätten wir 0-100% als Wert. Dieser Baustein wird bereits bei vielen Fühlerprojekten im Loxone-/1-Wire-Universum genutzt und kann ohne Probleme über die 1-Wire-Extension an den Miniserver angebunden werden. Natürlich auch an jeden anderen Master, der mit dem DS2438 klar kommt (owfs, etc.).

Smart Garden 1-Wire Sensor Node V0.2

Die Platine wurde so klein wie möglich gehalten und im Prototyp mit passiven Bauteilen der Größe 1206 gefertigt. Auf der 1-Wire Seite des Sensors haben wir außerdem einen MAX9940 zum Schutz des Microcontrollers verbaut. Der Sensor benötigt eine eigene 5V-Stromversorgung da eine parasitäre Speisung aufgrund des Stromverbrauchs des Microcontrollers nicht in Frage kam.

Ein weiteres Problem war, dass jedes 1-Wire-Gerät eine (weltweit) eindeutige Seriennummer hat und diese Seriennummer auch nicht doppelt auf dem Bus vorkommen darf, weil die einzelnen Geräte darüber adressiert werden. Da der DS2438 auch einen Temperaturfühler integriert hat, haben wir kurzerhand einen DS18B20 mit auf die Platine gepackt, um erstens die Temperatur zu messen und um uns zweitens die MAC (Seriennummer) zu „borgen“. Nach Anpassung des Family-Codes haben wir damit wieder eine eindeutige Seriennummer, die uns erlaubt mehrere Sensoren pro Bus zu nutzen. Natürlich könnte man auch einfach eine beliebige Seriennummer vergeben, hätte aber eben dann das Problem, dass man jeden Sensor einzeln mit einer eigenen MAC programmieren müsste.

Nun möchte man ja, wenn möglich dass die Sensoren lange halten, sowie Wind und Wetter trotzen. Wir arbeiten gerade daran, die Platine komplett nach IP67 zu vergießen, sodass man sie sogar vergraben könnte. Das Problem, welches damit einhergeht ist, dass man dann keine Software mehr auf den Microcontroller spielen kann oder anderweitig eine Konfiguration vornehmen kann – außer eben über die nach Außen geführte 1-Wire-Schnittstelle…
Auch dazu haben wir eine Lösung erarbeit: Der DS2438 hat neben seiner Funktion als Batteriewächter und Temperaturfühler auch einen über 1-Wire beschreibbaren Speicherbereich – „40-byte nonvolatile user memory“. Das 1-Wire Protokoll erlaubt es, diesen Speicher zu bedienen und so können wir darin Konfigurationsparameter ablegen und der Microcontroller kann diese verwerten. Dadurch haben wir die Möglichkeit, gemessene Frequenzen als „trocken“ oder „feucht“ zu definieren. Je nach vorhandenem „Erdreich“ kann die Messung des Sensors nämlich variieren. In Pflanzenerde beispielsweise ist ein anderer Zustand „feucht“ als in einem Glas Wasser.

Wir dachten uns, dass diese Konfiguration am besten über ein Mobilgerät erfolgen sollte. Es gibt also nun ein ESP8266 basiertes Gerät, mit dem man sich per WLAN verbindet. Dieses Interface wird statt dem 1-Wire-Master am Bus angeschlossen und man kann damit jeden Sensor kontrollieren und konfigurieren. Zum Beispiel kann man den Sensor, der ja nur durch seine Seriennummer identifiziert wird, blinken lassen, um ihn zu lokalisieren. Zusätzlich kann man festlegen, ob er bei der Messung generell blinken soll und natürlich die oberen und unteren Frequenz-Grenzwerte für feucht/trocken speichern.

Smart Garden Konfigurationsinterface

Für die Zukunft ist durchaus geplant, dass das Konfigurationsgerät ein eigenständiges Gateway mit MQTT- oder HTTP-Anbindung sowie eigenem Status-Webinterface wird. Der Anbindung an Systeme ohne eigene 1-Wire-Schnittstelle steht damit nichts mehr im Wege.

Schlussendlich ist der Sensor also nichts anderes als ein ATMega328p, ein kapazitiver Bodenfeuchtesensor und ein DS18B20 zur Temepraturmessung. Die Software wie auch die Hardware werden als Open-Source veröffentlicht werden und so könnte sich jeder auch den Sensor selbst bauen 👍

Der Sensor wird, sowie er fertig ist, bei uns im Shop verkauft. Bis dahin halte ich euch natürlich weiter auf dem Laufenden und freue mich über eure Anregungen und euer Feedback.

Update

Die Produktionsprototypen der Sensoren sind fertig. Das erste Mal im VQFN-Package gelötet und es sieht gut aus!

Im Bild ist auch der oben erwähnte Hub zu sehen. Damit können – wenn benötigt – die Grenzwerte, Intervalle, etc. der Sensoren konfiguriert werden.

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 🙂

by ·8 Kommentare

Im Loxone-Forum haben findige Leute, unter anderem Robert L., an einer günstigen Möglichkeit gearbeitet aus einem Arduino mit Ethernet-Shield und RS485-Wandler einen DMX-Controller mit Netzwerkanschluss zu bauen.

Die erste Idee bestand in der Anbindung an den Loxone Miniserver als Ersatz für die offizielle DMX-Extension mit der Nutzung eines „Virtuellen Ausgangs“ per UDP. Natürlich funktioniert das auch mit jedem anderem System – zum Beispiel node-red oder alles was UDP spricht.
Durch UDP gibt es ja bekanntermaßen keinen TCP-ACK, wodurch Overhead vermieden wird aber auch nicht sicher gestellt werden kann, dass ein Datenpaket auch wirklich ankommt. Bei einer Dimmersteuerung ist es allerdings unerheblich, ob von 100 Paketen die eine Dimmkurve beschreiben, nur 97 ankommen.

Der Original-Code ist übrigens genauso auf einem ESP8266 lauffähig und Robert L. hat sogar extra eine angepasste Version für den günstigen H801 (ESP8266) WLAN-Dimmer geschrieben, der direkt LED’s anteuern kann und keinen separaten DMX-Dimmer mehr benötigt.

Die Nutzer im Forum haben viele Unzulänglichkeiten der original DMX-Extension zu Tage gefördert und sich vielfach für die Lösung von Robert L. ausgesprochen.
In der Elektroverteilung ist WLAN eher weniger zuträglich und ich suchte schon lange nach einer Möglichkeit endlich mal selbst Ethernet auf einer Platine zu implementieren und hatte damit das passende Projekt gefunden.

Der Prototyp

Offensichtlich hatte ich mir viel vorgenommen als im Forum kund tat, dass ich eine Open-Source Platine (CC-BY-SA) Version der Platine designen, produzieren sowie bestücken und zum Verkauf anbieten könnte.

Allein der Aufbau des Prototyps war recht anspruchsvoll, was man im oberen Bild recht anschaulich sieht. Zum Testen habe ich mir auf ebay einen günstigen 3-Kanal-DMX-Dimmer bestellt, da ich keine eigene DMX-Installation besitze.

Den originalen Code habe ich nur ein wenig aufgeräumt und um die später erwähnte EEPROM-Funktion erweitert. Die Ethernet-Verbindung habe ich um DHCP erweitert, was dann auch die default Einstellung sein wird.

Schaltung

Über die letzten Wochen und vor allem am letzten Wochenende durfte ich dann am eigenen Leib (Zeit) feststellen wie viel Arbeit in sowas steckt. Dies ist (bis jetzt) meine bei Weitem komplexeste Schaltung!

Explizit möchte ich aber hier noch mal die Hilfe aus dem Loxone-Forum erwähnen, ohne deren Input die Umsetzung so nicht möglich gewesen wäre. Beim Ethernet Teil mit WizNet’s W5500 konnte ich mich zum Glück beim Layout des W5500 Ethernet Shields bedienen, das als Open-Source frei verfügbar ist.

Ethernet DMX Bridge Schaltung

Der W5500 ist die zweite Weiterentwicklung des im üblichen Arduino Ethernet Shield verbauten W5100. Zusammen mit Paul Stoffregen’s exzellenter Arduino Ethernet Bilbiothek, die ursprünglich für den Teensy entwickelt wurde, merkt man die erhöhte Verarbeitungsgeschwindigkeit deutlich. Direkte vergleiche mit der „alten“ Hardware müssen den subjektiven Eindruck natürlich noch bestätigen.

Paul’s Ethernet Bibliothek hat mehrere Vorteile. Darunter unter anderem die komplette Auto-Erkennung des verwendeten W5x00, vor allem aber die bessere Verarbeitung in der Bibliothek selbst:

Wiznet socket registers are cached, which greatly reduces SPI communication overhead, at the cost of a small increase in RAM usage. TCP connections and UDP packets accessed in small chunks typically see a substantial performance boost.

Zusätzlich habe ich noch ein 24AA025E48 EEPROM von Microchip in die Schaltung integriert. Der Speicher des EEPROMs wird zwar nicht genutzt, aber es bringt eine EUI-48 ID mit die als weltweit eindeutige MAC-Adresse für das Ethernet-Interface genutzt werden kann. Anregung dafür fand ich bei Freetronics, einem australischen Arduino-Produzenten.
Die WizNet Chips haben von Hause aus keine MAC-Adresse. Sie bringen mittlerweile zwar eine mit, diese ist aber ein Aufkleber auf der Platine und damit nicht wirklich nützlich für den Code auf dem Microcontroller.
Im Normalfall initialisiert man die Ethernet-Bibliothek einfach mit einer beliebigen MAC-Adresse, was für das lokale LAN absolut ausreichend ist. Wenn man aber im selben LAN mehrere gleiche Geräte verwenden möchte, muss man für jedes die Addresse anpassen und somit eine eigenen Software kompilieren. Dieser Aufwand entfällt durch die Nutzung der EUI-48 ID des EEPROMs, was auch die „out of the box“-Nutzung genau genommen erst möglich macht.

Die Spannungsversorgung wird zwischen 24V und 5V wählbar sein. In der 5V Version wird der OKI-78 Spannungswandler entfallen, wodurch man bei dieser Version noch ein paar euro sparen kann.

Platine, Gehäuse und BOM

Nach der Schaltung ging es dann an das Layout der Platine. Ich würde behaupten, dass dies der dickste Batzen arbeit war.

Da die Platine im Labor eines befreundeten Prototypenherstellers entstehen und „gebacken“ wird, habe ich mich für handbestückungsfreundliche SMD-1206 Bauteile entschieden.

Phönix Contact BC 35,6

Der Anspruch war, keine Gehäusebearbeitung nötig zu machen um auch Nicht-Bastlern die Möglichkeit zu geben die Ethernet-DMX-Bridge zu nutzen und zusammen bauen zu können. Der Gewinner ist das hervorragende Phönix Contact BC 35,6 2TE Hutschienengehäuse. Hier auch ein Dank für die unkomplizierte Zusendung von Mustern um die verschiedenen Gehäusetypen auszuprobieren und die vorzügliche Beratung des Vertrieblers.

Ich habe den UART sowie den ISP des ATMega328p nach außen geführt. Der UART wird benötigt um eine Programmierung per Arduino-IDE zu ermöglichen. Als Pin-Belegung habe ich mich für die Anordnung des FOCA FTDI Adapters entschieden, die mir über DTR auch den Auto-Reset des ATMega zur Programmierung erlaubt.

Ein integrierter FTDI-Chip entfällt aus Kostengründen. Außerdem ist die Programmierung ja nur einmalig – wenn überhaupt – nötig. Mit Jumperkabeln kann man natürlich auch jeden anderen USB-FTDI-Adapter nutzen. Wenn der eigene Adapter kein DTR-Signal zur Verfügung stellt, reicht ein manueller Reset der Schaltung während des Programmierens um im Arduino-Bootloader zu landen und damit den Sktech zu übertragen.
Mit dem ISP spiele ich den Arduino-Bootloader auf und er bietet natürlich auch die Möglichkeit der direkten Programmierung der MCU.

Ethernet DMX Board Layout

Die Platinen sind mittlerweile bei OSHPark bestellt und bereits auf dem Weg in die Produktion.

Als nächstes war also das „sourcen“ der knapp 60 Bauteile dran – das alleine war eine abendfüllende Angelegenheit.
Ich habe DigiKey, RS-Components und Reichelt nebeneinander gestellt. Die meisten Bauteile werde ich bei DigiKey bestellen, weil es dort die besseren Rabatte bei SMD-1206 gibt und auch Markenhersteller wie Murata und Panasonic vorrätig sind. Reichelt liegt bei manchen Bauteilen vorne und bekommt auch einen Teil der Bestellung ab. RS-Components war entweder nur vergleichbar oder teuerer – einzig bei der Netzwerkbuchse hätte ich etwas sparen können. Allerdings wäre der Vorteil durch die Versandkosten wieder aufgefressen worden.

Ausblick

Die ersten Boards werde ich im Loxone-Forum anbieten und bin gespannt, wie die Erfahrungen und Rückmeldungen aussehen. Das Board wird mit Gehäuse (optional) zukünftig im geplanten cod.m-Webshop bestellbar sein.

Achso, hier natürlich noch das Ganze in Aktion 😀

Ich bin wirklich begeistert wie „responsive“ alles ist. Zu sehen übrigens das Loxone-Webinterface, Anbindung dann über virtuellen Ausgang per UDP.

Wie immer gilt, bei Fragen, Feedback und Kritik, immer gerne melden.

Update

Mittlerweile sind die gefertigten Platinen eingetroffen und es sieht wirklich gut aus. Werde die Tage dann mal die Teile bestellen um das Ganze zu bestücken.

Update II

Die Platinen sind mittlerweile bestückt. Leider hat sich, wie bei einem ersten Prototyp ja fast üblich, ein Fehler eingeschlichen. Mit einem Quick-Fix funktioniert aber alles und ich bin wirklich ein wenig stolz 😉

Mittlerweile habe ich V0.3 des Layouts fertig. Ich werd noch ne Nacht drüber schlafen und diese dann in Produktion geben. Wenn diese dann funktionieren, steht einer kleinen Serie nichts mehr im Wege.

Update III

Mittlerweile ist ja etwas Zeit vergangen und wir haben sie genutzt: Unsere WEEE-Registrierung, damit man in Deutschland offiziell Elektronik verkaufen darf, ist auf dem Weg und sollte in den nächsten Wochen bewilligt sein. Die CE Konformitätserklärung für die Ethernet DMX Bridge ist so gut wie fertig.

Das Wichtigste allerdings ist, dass wir nächste Woche einen Termin beim Bestücker haben um die Bauteile maschinell bestücken zu lassen. Dazu mussten wir einen Nutzen produzieren lassen und können nun eine Kleinserie herstellen:

Update IV

Es ist soweit! Die Hardware ist fertig und steht zum Verkauf. Alles Weitere findet ihr im Shop: https://shop.codm.de/module/8/ethernet-dmx-bridge-v0.4

by ·Ein Kommentar

Im Oktober habe ich eine Crowdfunding Kampagne gestartet, um meinen eigenen Miniserver für die Weiterentwickling von node-red-contrib-loxone zu ermöglichen. Das war nötig, da der bis dahin geliehene Miniserver von seinem Besitzer, einem befreundeten Elektriker und Loxone-Partner, zurück benötigt wurde, um eine Testumgebung für ein Kundensystem aufzubauen.

Durch das viele Feedback auf die Entwicklung von node-red-contrib-loxone im LoxForum habe ich mich bestärkt gefühlt, es ein mal mit einem Crowdfunding über GoFundMe zu versuchen. Ich war überwältigt! Innerhalb von 2 Tagen wurden 343,- € gespendet und unzählige Hilfs- und Unterstützungsangebote wurden gemacht. Ich habe viele Leute, deren Namen ich nur kannte, kennengelernt und viele Telefonate geführt. Die nötige Differenz zum eigentlichen Preis habe ich dann noch selbst beglichen und den Fundraiser entsprechend beendet.

Vielen VIELEN Dank an alle Unterstützer – egal auf welchem Weg!

Natürlich gab es auch Kritik, die sich aber, so zumindest meine Wahrnehmung, schnell aus der Welt schaffen ließ. Der Node-Red-Node ist Open-Source und jeder kann ihn durch die MIT-Lizenz kostenlos, auch in kommerziellen Projekten, einsetzen. Die Entwicklung findet für jedermann einsehbar auf GitHub statt und wer möchte, kann (und sollte?) sich an der Verbesserung des Codes und der Dokumentation beteiligen. Ich freue mich über jedwede Kritik 🙂

Auch nach dem „einfrieren“ der GoFundMe-Seite haben sich viele Leute beschwert, dass sie nichts mehr spenden konnten. Ich habe mich also entschlossen, die Kampagne wieder zu eröffnen und jedem die Möglichkeit zu geben mich, auch nach erfolgreicher Finanzierung des Miniservers,  weiterhin ein wenig bei der Arbeit an node-red-contrib-loxone zu unterstützen: https://www.gofundme.com/miniserver-fur-nodered-entwicklung

Nochmal, vielen Dank an ALLE – ihr seid der Knaller!