Microcontroller dynamisch vernetzen

Guten Tag,
Ich wollte mit einem Kollegen die nanoleaf leuchten nachbauen und das ganze am Ende als open Source anbieten.
Da das Projekt noch am Anfang steht, läuft gerade die „Grundlagen Forschung“. Als Master soll ein ESP Modul dienen (vllt 32 oder 8266 mal schauen)
Das Problem welches ich gerade habe ist die Vernetzung einer Unbekannten Anzahl von Controllern über eine steckverbindung am ESP. Es gibt die Überlegung das per 1-Wire Protokoll zu lösen. Aber da weis ich nach aktuellem Kenntnisstand noch nicht vor stabil diese Art der Kommunikation ist.
Eine einfache Art mehrere unbekannte Controller anzusteuern ist über die spi Schnittstelle darüber wäre auch relativ einfach möglich die Form der Panele abzubilden.
Es gibt ja noch I2C dort dürfte aber ein ähnliches Problem auftreten wie bei der seriellen Kommunikation die Controller wissen zum Start nicht wie der andere heißt und würden alle beim Call vom Master reagieren bzw. den ersten Namen der vergeben wird annehmen.
Gibt es noch eine 5. Möglichkeit die ich bisher übersehen hab?
Oder hat jemand schon Erfahrungen mit dem 1-Wire gemacht und eine Empfehlung welche Lib sich dafür gut eignet um darauf aufbauend ein eigenes Protokoll zu schrauben?

Mit freundlichen Grüßen
Skorpio

Also mein Nachbar hat sich ja auch in die Dinger verliebt und ich begreif nicht wieviel Kohle man in solche Dinger stecken kann wenn ich sie zumindest in einer vereinfachten Form selber rbauen kann (Plexiglas Dreieck mit ein paar APA102 LEDs und dann mit CS-losem SPI einfach die Daten reinschaufeln und die Stecker zwischen den Panelen so auslegen dass man sie nicht verpolen kann)

Diese einfache Lösung hat antürlich keinen Rückkanal und auch keine Formerkennung, wäre aber zumidnest eine wesentlich billigere Lösung als die Nano Leafs :)

Du triggerst mich gerade relativ hart :D

Ich hätte da sogar eine Idee wie man das mit 5 Drähten und rekursiver Verschaltung lösen könnte, das wären dann allerdings 5 Pins pro Stecker

Der ESP32 hat Bluetooth onboard (aber das zum funktionieren zu bringen hat mich zumindest unglücklich gemacht) für den 8266 und 8285(8266 mit internem Flash) gibt es immerhin µPython, was einem unendliche Freiheit im Controller bietet (perfekt für OpenSource und außerdem super einfach zu programmieren)

Und man kann es sicher auch easy für NodeMCU oder andere bereits auf dem ESP verwirklichten "OS" porten, so kann man neben der eigentliche Lichtfunktion auch ganz easy weitere Funktionen in den Controller packen (mini webbrowser und ein AP, sodass man keine App braucht sondern nur nen Browser mit WLAN)

Genau das soll das Endziel sein. Wir versuchen in erster Linie eine Platform zu schaffen auf der sich Leute mit weit mehr Erfahrung im Bereich der Programmierung austoben können. Aber eine Lösung die soweit lauffähig ist das ein Anfänger das ganze aufbauen und in Betrieb nehmen kann.

Es werden dafür auch Platinen hergestellt und als LEDs sollen rgbw LEDs verwendet werden. Ob jetzt apa102 sk6812 oder ws2812 sei erstmal dahin gestellt.
Da es ja auch mal mehr können soll als einfach nur ne etwas intelligenterer led streifen. Wollten wir uns direkt zu Beginn mit der Frage auseinander setzen eine aktive Komunikation zwischen den Modulen aufzubauen. Dies hat den Vorteil das jederzeit neue Teile angehängt werden können ohne ständig die Basis zu ändern.

ich hatte dir schonmal ein Bild zukommen lassen, siehe inbox :)

1 wire würde ich nicht machen.
Einen Controller als Master zu verwenden ist relativ einfach.
Einen Slave zu proggen dafür umso schwieriger, da dieser eine "einmalige" Seriennummer hat.

Mir würde da RS 485 in den Sinn kommen, oder je nach Anwendung auch CAN.
Es kommt halt auf die Menge der zu übertragenden Daten und die Art der Steuerung an.
Diese nanoleaf leuchten kenn ich gerade nicht.

Zitat:

---

.. Einen Controller als Master zu verwenden ist relativ einfach ..

---

Unbestritten.

Zitat:

---

.. Einen Slave zu proggen dafür umso schwieriger, da dieser eine "einmalige" Seriennummer hat ..

---

Vielleicht versteh ich da was falsch, aber ich sehe kein Problem, keine Schwierigkeit das in I²C zu machen. Mein Master im archie (im Bild R5 Master mit Softwareversion x76) startet I²C mit ner Abfrage ".. wer ist denn alles da ..?" über einen von mir begrenzten Adressbereich. Da melden sich die Slaves, entweder alle (die von Bedeutung sind). Im Beispiel hier: ArmRechts-Controller, KopfController, MotorController, ArmLinks-Controller und Cirp-Controller :

......Bild hier  

oder es sind einige nicht verbunden, dann sieht die Meldung so aus für ArmRechts-Controller, KopfController und ArmLinks-Controller.

...... Bild hier  

Im Master werden dann Flags gesetzt, mit denen die entsprechende Kommunikation ein- oder ausgeschaltet wird.

Gaaanz normales I²C-Verfahren, abgesehen davon, dass der Kabelbaum nen ziemlich guten Meter lang ist. Das Beispiel ist mit der identischen Hardware gezeigt, nur dass beim zweiten Bild der I²C-Anschluss von Motor- und CIRP-Controller gelöst war bevor archie - der Master - wieder gestartet wurde.

@Skorpio:
i2c halte ich auch grundsätzlich für kein Problem.
Aber wie lang darf oder muss denn die Verbindung zwishen den Masters und Slaves sein können?

Zitat:

---

Zitat von HaWe

Aber wie lang darf oder muss denn die Verbindung zwishen den Masters und Slaves sein können?

---

Das wäre wichtig zu wissen.

Aus Zeitmangel beschäftige ich mich gar nicht mit den ESP-Dingern, aber hat der ESP32 nicht auch CAN ?

Das ist von seiner Herkunft ja dafür gedacht im Auto dezentral Controller zu vernetzen. Es gibt auch Anwendungen in der Automation (CANopen) oder Schifffahrt (NMEA2000) oder auch für autonome Roboter und Drohnen:
https://uavcan.org/

Nur so eine Idee ...

CAN zu programmieren per C++ ist für Anfänger zu exotisch - das kennt keiner.
Die Arduino IDE ist auch das einzige, was ich für anfängertauglich halte.

Für ESP8266 habe ich auch noch keine Arduino CAN lib gesehen, auch wenn esp8266 mit Arduino eingeschränkt anfängertauglich wäre,
andererseits für ESP32 mag es welche geben, aber den halte ich wiederum nicht für anfängertauglich, und dessen cores sind ja auch noch lange nicht ausgereift.
Allerdings kann vlt der Arduino Due auch CAN - aber trotzdem, CAN halte ich für zu exotisch.

I2C hingegen halte ich zwar für einfach und anfängertauglich (Arduino Wire lib mit allen möglichen Arduino MCUs), aber nur bei kurzen Entfernungen (vlt 2m insg. schätzungsweise) -
ansonsten ist ja WiFi das Standard-Netzprotokoll bei ESP8266:
Vorteil: der Server braucht die einzelnen Clients nicht zu kennen, die melden sich einfach bei einer festen IP Adresse an.
Die erlaubten Variablennamen müssten allerdings stattdessen zur Kommunikation vorher (z.B. per fester Liste) vordefiniert sein, um die übergebenen bzw. zurückgegebenen html-strings auf dem html-Server und den Clients auswerten zu können.

Man kann auch I2C machen und nur die Physik von CAN nutzen, das ist das Prinzip hinter diesen Treiberchips, die I2C über große Distanzen ermöglichen.

Die Verkabelung von CAN und RS485 sind bis auf Details sehr ähnlich.

RS485 wurde ja oben schon genannt. Vorteil wäre es ist nur eine Variante einer seriellen Schnittstelle, Nachteil gegenüber CAN ist, dass es nicht damit umgehen kann, wenn mehrere Teilnehmer gleichzeitig anfangen zu reden. Ein Protokoll aus dem Beleuchtungsbereich, was RS485 nutzt, wäre DMX, dafür gibt es viel für Arduino & Co.

Bei der Aussage mit der einmaligen Seriennummer beim Slave war der 1 wire Bus gemeint.
CAN wäre für mich die erste Wahl, wenn alle Controller im prinzip Master sind die Ihre gewonnenen Daten auf den Bus legen, ohne den eigentlichen Empfänger zu kennen.
Kollisionserkennung ist bei CAN automatisch mit eingebaut. Priorisiert wird hierbei über die Nachrichten ID.
Die Daten werden im Prinzip vom Knoten der die Daten verarbeitet rausgefiltert.
Beispiel GPS: Ein GPS Empfänger legt seine Positionsdaten auf den Bus, wer diese Daten auswertet interessiert diesen Knoten erstmal nicht.

Es gibt zwar auch bei CAN call Aufrufe, bei denen Daten abgefordert werden können - Ist aber eigentlich nicht der übliche Standard.

Die Verkabelung sieht bei CAN und RS 485 ähnlich aus, das Protokoll ist aber ein gänzlich anderes.

Das DMX Protokoll ist eigentlich ein schlechtes Beispiel, da es hier nur einen Master gibt, der Daten sendet, aber keine empfängt ( simplex Betrieb ).
Das geht nur, wenn man von den Slaves keine Rückantwort braucht.

Bei Elektor haben die Leutz auch mal ein Hausbus System entwickelt.
Auf welcher Basis das läuft hab ich gerade nicht auf dem Schirm, dafür gäbe es aber fertige Librarys auch für AVR Controller - Kannst ja mal gucken.

Essenz:
Wenn es um ein Protokoll mit mehreren Mastern und mehreren auswertenden Knoten geht würde ich CAN verwenden.
Wenn es um ein reines Single Master Protokoll mit weniger als 32 Teilnehmern geht würde ich RS 485 vorziehen, oder wenn die Buslänge gering ist I²C.
SPI geht nur mit einem Master bei kurzen Verbindungen und relativ wenigen Slaves, ist dafür aber schnell.
1 wire halte ich für problematisch, weil das Timing beim Slave nicht ganz ohne ist, es fixe einmalige Adressen gibt und eigentlich keine mir bekannte Library für Slaves.

Zitat:

---

Zitat von HaWe

@Skorpio:
i2c halte ich auch grundsätzlich für kein Problem.
Aber wie lang darf oder muss denn die Verbindung zwishen den Masters und Slaves sein können?

---

Also da liegt ein Problem der Überlegung. Es können theoretisch je nach zu beleuchtenden Teil mehrere Meter sein.
CAN kenne ich persönlich nur aus dem S7 Datenblatt aber keine genauen Spezifikationen.
Dem RS485 schaue ich mir mal genauer.
Da ich aktuell mehr im Urlaub als am Rechner bin beschränken sich viel Überlegungen noch im Kopf.

Eine dieser Ideen läuft darauf hinaus das der Master nur die Anzahl kennt der angeschlossenen Module und dann über eine Leitung alle Daten seriel herausschießt. Und die einzelnen Module holen sich nur die Farbe ab.

Vielen Dank für die großartige Hilfe jetzt schon ;)

Zitat:

---

Eine dieser Ideen läuft darauf hinaus das der Master nur die Anzahl kennt der angeschlossenen Module und dann über eine Leitung alle Daten seriel herausschießt. Und die einzelnen Module holen sich nur die Farbe ab.

---

Das deckt aber keine Verzweigungen ab oder man müsste eine Rückleitung mit einbauen und die Stecker so bauen, dass wenn kein Modul angeschlossen ist, der Rückpfad mit dem Sende Pfad kurzgeschlossen wird ... so hätte man quasi alle Module in Reihe, trotz das sie wie ein Baum verzweigt sind (als Algo ausgedrückt Tiefensuche mit fester Entscheindungsrichtung)

Wenn am 1ten LED Modul Port 1 keiner angeschlossen ist, geht der Sendepin auf den Empfangspin und der geht zum Sendepin von Port2 usw. (evtl. könnte man hier noch ein Logik Gate mit Schmitttriggereingängen als Signalkonditionierer dazwischenschalten ... da wir nur senden und nicht empfangen geht das auch wunderbar für I2C ... mit einem Open Drain Ausgang am Gate ... und man muss sich nicht die Bohne um Reichweite kümmern)

Also wenns möglichst einfach und billig sein soll wäre das der Weg der Wahl, mit Richtungserkennung braucht man dann schon einen Controller pro LED Modul ... dann könnte man auch einzelne Kacheln unabhängig voneinander und Lastfrei für den Master Blinken lassen

dennoch würde ich schon alleine wegen der Aktualisierungsgeschwindigkeit und flüssiger komplexer ansteuerung auf ein schnelles serielles protokoll wie SPI (wegen synchroner clock) oder uart mit clock setzen (RS485 ist nichts weiter als differentielle signalübertragung um gleichtaktstörungen zu filtern) aber CAN halte ich schon allein wegen des Overhead für übertrieben

Zitat:

---

Eine dieser Ideen läuft darauf hinaus das der Master nur die Anzahl kennt der angeschlossenen Module und dann über eine Leitung alle Daten seriel herausschießt. Und die einzelnen Module holen sich nur die Farbe ab.

---

Da man dafür keinen Rückkanal braucht und es sich um eine Beleuchtungsanwendung handelt ist das eindeutig eine Aufgabe für DMX 512, das hardwaremässig auf dem RS 485 Protokoll beruht.
Das ist der Quasi Standard für Theater Beleuchtungsanwendungen.
Das System kann ohne Repeater 32 Knoten ansprechen und 512 Kanäle verwalten.
Maximale Buslänge bis zu 1000m.
Im Standard sind 5polige XLR Stecker definiert, die aber fast niemand verwendet.
Üblicherweise werden 3polige XLR Stecker und Buchsen verwendet.
Die Adressierung der 512 Kanäle findet im Master statt, die angeschlossenen Geräte werden im einfachsten Fall per DIL Schalter auf eine Startadresse adressiert und können im Prinzip beliebig viele Kanäle haben.
Bei RGB Anwendungen sid das üblicherweise 6= Master Dim, Rot, Grün, Blau, Effekt, Speed ( Anordnung nach Hersteller unterschiedlich ) .
Es gibt für diesen Standard fast alles, was man Beleuchtungstechnisch so braucht ( Dimmerpacks, PAR Stahler, LED Bars, Profilscheinwerfer, ... ).
Das Protokoll ist einfach und im Prinzip mit jedem Microcontroller USART realisierbar.
PC Interfaces und PC Software sind auch verfügbar - Google mal nach DMX Control, das es kostenlos gibt und bei dem man auch Eigenbau Beleuchtungsgeräte definieren kann.
Interfaces gibt's sehr viele, wir verwenden das von Digital Enlightment ( Bausatz oder fertig ) sowie das von EURO Lite ( Fertiggerät ).
Früher hatten wir auch mal das von DMX4All.

Zitat:

---

Die Adressierung der 512 Kanäle findet im Master statt, die angeschlossenen Geräte werden im einfachsten Fall per DIL Schalter auf eine Startadresse adressiert und können im Prinzip beliebig viele Kanäle haben.

---

die eleganz der nano leafs ist aber dass man deren adressen nicht einstellen muss sondern ihre struktur selber erkennen, deswegen fände ich eine "einfache lösung" OHNE controller / leaf als eine große serielle kette (mit "repeatern") sinnvoll oder eine "intelligente lösung" MIT controller pro leaf aber dann als eine art "daisy chain" kommunikation und rekursives polling besser

Zitat:

---

OHNE controller / leaf als eine große serielle kette (mit "repeatern") sinnvoll oder eine "intelligente lösung" MIT controller pro leaf aber dann als eine art "daisy chain" kommunikation und rekursives polling besser

---

Dazu braucht man natürlich einen Rückkanal und DMX scheidet somit aus.
Da sich die Module über ihre Struktur ja "absprechen" müssen und diese Struktur auf den Steuerrechner rückübertragen müssen.
Ist das Protokoll bei den Nanoleafes bekannt?
Ein Problem seh ich noch bei der Lagen Erkennung.
Allein über die angeschlossenen Schnittstellen kanns im Prinzip nicht funktionieren, weil es dann ja auch Spiegelbildlich aufgebaut sein kann - Oder das Ganze wird dann in der Steuersoftware gedreht.

Zitat:

---

Zitat von wkrug

Dazu braucht man natürlich einen Rückkanal und DMX scheidet somit aus.

---

Da bin ich mir nicht sicher, laut Wikipedia sieht DMX-512-A schon Rückantworten vor. Allerdings ignorieren viele ältere Geräte das. Wenn man aber nur eigene Hardware am Bus hat, sollte das aber kein Problem sein.
https://de.wikipedia.org/wiki/DMX_(Lichttechnik)

In der Doku meiner Bastelboards sind auch Libs verlinkt, die über DMX lesen können.
https://www.pjrc.com/teensy/td_libs_DmxSimple.html

das klningt aber alles nicht sehr anfängertauglich mit CAN und DMX.
Anfänger können kein Eclipse und kein AVRStudio sondern eher nur Arduino IDE/API mit Wire() (i2c), Serial() (UART) und maximal (!) WiFi mit esp8266 und html (WiFiServer-Libs) mit vorgerfertigten Beispielcodes zum copy+pasten, aber das ist bereits das höchste der Gefühle.

Zitat:

---

Ist das Protokoll bei den Nanoleafes bekannt?
Ein Problem seh ich noch bei der Lagen Erkennung.

---

Nein und ich denke auch nicht dass es eine zu große Aufgabe ist.

SPOILER: TEXTWAND VORAUS, das ist mir gerade so durch den Kopf gelaufen und kann auch üble Denkfehler beinhalten, Verwendung und lesen auf eigene Gefahr

Wenn ich jetzt über ein beliebiges Protokoll und am wichtigstens kontrolliert zu einzelnen ports reden kann, kann ich zumindest schonmal für mich selber herausfinden an welcher seite jemand hängt.

ACHTUNG: Sollte jemand das so oder in der Art umsetzen würde ich mich um eine Nennung mit meinem Synonym "mindforger" als Idee Urheber sehr freuen :P

Was ich mir z.B. vorstelle ist eine Art SPI oder Synchrones UART mit kombiniertem Chipselect und multiplen Sense Leitungen ... alle Leafs haben einen Controller mit 2 SPI/UART Schnittstellen und intern für alle Ports eine gemeinsame Chipselect Leitung und zusätzlich pro Port einen Pin der zur Identifikation des eingehenden Signals dient.

Nur der ESP-Master darf die CS leitung initial auf GND ziehen und macht das ganze auch nur einzeln pro Port (damit umgehen wir direkt die Problematik des Zirkelbezuges)

Findest er keinen Partner wechselt er zum nächsten Port.

Das erste Leaf das sich angesprochen fühlt, reagiert und wechselt von reinem Empfang auf den Daisy Chain Betrieb. Er schaltete also alle anderen Ports auf ausgang und fragt genau wieder Master seinerseits die Ports nach Nachbarn ab, die dann ihrereseits wieder den die Nachbarn abfragen.

Ich würde die CLK Leitung durch alle Leafs durchschleifen und nur der Master darf diese Leitung bedienen um eine perfekte Synchronisatuion zu haben (da bietet sich eigentlich synchrones UART besser dafür an und wegen Vollduplex gibt es auch keinen Kurzschluss)

Wenn jetzt ein Zeikelbezug entsteht, also 2 Leafs sich berühren die über die Kette auch shcon vom Master angesprochen werden, teilen sie sich gegenseitig mit, dass sie bereites "entdeckt" worden sind

Melden jetzt alle Leafs zurück, dass sie alle Nachbarn und deren Nachfolger identifiziert haben, sendet der Master einen Befehl der zunächst von jedem leaf ignoriert wird, das mindestens 1 weitern nachbarn hat und den Befehl einfach weitergibt (einmal pro port! und nicht gleichzeitig).

Das erste Leaf das also keine weiteren Nachbarn hat Antwortet dann mit etwas wie "(RGB_LEAF_P3" (P3 für Master hängt an Port 3 und die Klammer ist wichtig)

Das Leaf davor nimmt diese Nachricht und fügt seine eigene Identifikation hinzu und darauf wird dann "((RGB_LEAF_P3,P5),RGB_LEAF_P2" es fügt also vor den String eine Klammer hinzu und an den String des Nachbars die zugehörige Portnummer an und schließt die innere offene Klammer mit ",P5)" um zu zeigen von wo diese Identifikation her kam ... sollten weitere Leafs an anderen Ports sein, verbindet er die Strings die er mit Portnummer geschlossen hat und hängt dann ganz am Ende seine eigenen Identifikation an.

Der Master bekommt dann so etwas in der Art zurück

Port 1 - (leer)
Port 2 "(((RGB_LEAF_A_P3@P5), RGB_LEAF_B_P2@P3),(RGB_LEAF_C_P4@P4),RGB_LEAF_D_P1"

Der String wird also rekursiv erstellt.
Und daraus lesen kann man von Rechts nach Links:
- an Port 2 vom Master hängt ein RGB_LEAF_D das seinerseits an seinem Port1 vom Master angesprochen wird.
- an RGB_LEAF_D hängen 2 weitere Leafs, das RGB_LEAF_C an Port 4 und RGB_LEAF_B an seinem Port 3
- an RGB_LEAF_C hängt sonst kein weiteres
- an RGB_LEAF_B hängt allerdings noch an Port 5 das RGB_LEAF_A

Damit ist die gesamte Struktur auslesbar und dank der Klammern kann man das easy mit Regulären Ausdrücken verarbeiten und in eine gelinkte Liste verwalten

Da man von jedem Leaf den Ein und Ausgangsport kennt kann man auch anhand der geometrischen Struktur alle Leafs räumlich orten und mit der Bezeichnung RGB_LEAF kann man auch den Typ erkennen ... man könnte auch sagen RGB_HEX_LEAF um ein Hexagonales Leaf zu beschreiben oder ein WHITE_TRI_LEAF für ein sinples Helligkeit gesteuertes Dreieeck und unterschiedliche geometrische Strukturen verwenden.

So kleines Update.

in ca. einer Woche kommen alle nötigen Teile an dann kann ich endlich loslegen.