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.