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.