Zigbee-Stick cc2652P direkt über LAN anbinden

[klassisch]

Motivation
Der Anschluß von Funk-HW an eine USB Buchse bindet den Funkort an den Aufstellungsort des ioBroker-Rechners. Je nach dessen Aufstellungsort kann das ungünstig sein.
Außerdem erhöht ein USB-Anschluß die Komplexität und mindert damit auch die Robustheit bzw. Verfügbarkeit des Systems

Mögliche Lösungen

• ser2net Verbindung
• serial <-> LAN konverter
• ioBroker Multihost mit Zigbee-Slave

Die ser2net Lösung umgeht den USB Port und dessen Komplexität nicht.
Sie erfordert in der Nähe der Funk-HW (z.B. eines Zigbee Sticks) einen Rechner mit USB. Habe eine solche Verbindung testweise in Betrieb: Bei mir dient ein Orange Pi Plus 2e, auf dem auch piVCCU läuft als Verbindungsrechner. Leider war in meinem speziellen Fall die Verbindung nach einigen Tagen gestört und mußte neu angeschubst werden. Ursache leider unklar.
Und wenn man im Dunkeln steht, weil das Licht nicht mehr schaltet wird man etwas intoleranter und ungeduldiger. Ser2net habe ich also nicht weiter verfolgt, meine Erfhahrungen beim Einrichten auf einem SBC habe ich dort dokumentiert
Eine Lösung mit ioBroker Multihost habe ich nicht gewählt, weil ich die zusätzliche Komplexität und den Wartungsaufwand sparen wollte. Wer das aber ohnehin schon betreibt, ist sicher auch gut bedient, weil man dann ja auch den Zigbee Adapter und die zugehörigen JScripts quasiautark auf dem Slave laufen lassen kann, wie es @1N4148 beschreibt.

Für mich habe ich eine Lösung, die sich bei mir für RFLink und Smartmeter bewährt hat, auf Zigbee übertragen.

Habe als proof of concept (Edit: mittlerweile als stabile Produktivlösung) eine direkte LAN-Verbindung zum cc2652P Stick aus dem Marktplatz dieses Forums hergestellt - ohne Umweg über USB.
Als Interface dient derzeit ein USRIOT USR-K7 Modul.
Plane noch einen Umbau auf ein USR-E2, weil ich ein solches bereits in einer Anwendung zur Anbindung von RFLink und smartmeter habe und die Sache sehr robust funktioniert (Edit: Mittelerweile als Produktivlösung realisiert Edit im Edit: Läuft in dieser Form noch immer stabil 2024-09).
Die Anbindung hier ist ähnlich wie die vom RFLink realisiert: die Verbindung zum Pin2 (dessen serial data out) des CH340C wird aufgetrennt und der data input des Zigbee Moduls stattdessen mit dem serial out des USR verbunden. Die data out Leitung des Zigbee Moduls bedient beide Eingänge parallel - die des ungenutzten CH340 und die des USR serial <-> LAN Moduls.
Im Prinzip könnte man die Anbindung hier auch über ein RS485 Zwischenmodul machen, ähnlich wie ich es beim Smartmeter "moderne Messeinrichtung" gemacht habe.

Ein paar Bilder dazu weiter unten in diesem Thread

Edit: Für alle, die sich das Gebastel ersparen wollen: Habe gesehen, daß der user @dimaiv fertigen LAN fähigen CC2652P anbietet. Kenne das Produkt nicht, bin aber vom Prinzip der LAN-Kopplung nach wie vor überzeugt. Wer also nicht selbst bauen möchte, kann ja den referenzierten Thread verfolgen.

Edit 2: Mittlerweile gibt es auf dem youtube Kanal des users @haus-automatisierung eine Videoanleitung für solch eine Anwendung. In jenem Fall unter Verwendung der TI Evalboards, wodurch man das Löten vermeiden kann. Die Konfigurationen sind dort ebenfalls anschaulich erklärt.
Dazu hat er noch eine Adapterplatine entwickelt und zur Verfügung gestellt. Damit kann das USR Modul mit dem TI Eval-board direkt verbunden werden.

[1N4148]

@klassisch said in Zigbee-Stick cc2652P direkt über LAN anbinden:

USR-E2

Mich würde mal interessieren, wie robust diese Lösung bzgl. Reconnect bei zwischenzeitlichem Ausfall der Netzwerkverbindung ist. Hatte den Stick einige Zeit per ser2net an IoBroker angebunden, aber jedesmal wenn die Netzwerkverbindung mal unterbrochen wurde (z.B. weil ich das Netzwerk umkonfiguriert hatte) lief der der IoBroker Adapter auf Fehler.

Habe daher als Abhilfe einen alten Pi2 als IoBroker-Slave aufgesetzt, auf dem läuft nun der Zigbee-Adapter sowie eine Javascript-Instanz die alle Zigbee-Aktionen abwickelt.

Ich sehe allerdings nicht, wieso USB die Komplexität erhöhen bzw. die Verfügbarkeit verringern sollte.

[klassisch]

@1n4148 sagte in Zigbee-Stick cc2652P direkt über LAN anbinden:

Mich würde mal interessieren, wie robust diese Lösung bzgl. Reconnect bei zwischenzeitlichem Ausfall der Netzwerkverbindung ist.

Meine Smartmeter- und RFLink-Applikationen laufen sehr robust und haben bisher immer wieder reconnected.
Das mag aber auch von den Adaptern abhängen. Ich habe beim Zigbee Adapter ein USB-Thema per log eingefangen. Der Adapter hat innerhalb von 10 Sekunden seine 5 attempts to reconnect durchgeführt und sich dann verabschiedet

Bei einer tcp-Anbindung scheint er hier ausdauernder zu sein.
Habe gestern Abend mal mit der Baudrate gespielt. und danach hat der Adapter wieder reconnected. Wie lang er das versucht, habe ich noch nicht ermittelt. Aber das könnte man dann erforderlichenfalls per Javascript-induzierten Adapter-Restart beeinflussen.

Hatte den Stick einige Zeit per ser2net an IoBroker angebunden, aber jedesmal wenn die Netzwerkverbindung mal unterbrochen wurde (z.B. weil ich das Netzwerk umkonfiguriert hatte) lief der der IoBroker Adapter auf Fehler.

Die Erfahrung hatte ich mit ser2net auf meinem OPi auch gemacht. Wenn die USB-Verbindung zur Platine aussetzt, kann man das Glück eines reconnects haben oder auch nicht. Ähnlich nach einem reboot.

Habe daher als Abhilfe einen alten Pi2 als IoBroker-Slave aufgesetzt, auf dem läuft nun der Zigbee-Adapter sowie eine Javascript-Instanz die alle Zigbee-Aktionen abwickelt.

Das klingt nach einer sehr guten Lösung. Solange man sich um Updates und Restarts drücken kann, hat man ein "autark" laufendes System, welches auch bei Updates des Hauptrechners noch das Licht bedient. Man bezahlt es halt mit der Komplexitätserhöhung durch ein multi host system. Wollte (und konnte) ich bisher vermeiden. Hatte das auch überlegt, denn mein OPI langweilt sich mit piVCCU und steht am guten Funkstandort.

Ich sehe allerdings nicht, wieso USB die Komplexität erhöhen bzw. die Verfügbarkeit verringern sollte.

Das sind halt ein paar Instanzen mehr "in Reihe" geschaltet. Fängt beim Kabel und den Steckern an, geht über den ser2net, das Linux USB-tty Zeugs und dessen Bootfestigkeit, der USB Architektur (root-Hub, generischer Hub) und Beinflussung durch andere USB Geräte.

Hatte eine Zigbee Platine direkt am USB meines ioBroker-Notebooks. Da laufen aber auch noch andere Programme drauf mit Zugriff auf USB Platten und Drucker. Da kam es etwa alle 2 Tage zu einem USB-"Schluckauf" (Ursache nicht erforscht), welche dann den zigbee-Adapter zum Abwurf veranlasst haben. Die anderen USB-Teilnehmen haben das aber klaglos weggesteckt.

Habe jetzt die Lösung mit dem USR TCP-Server-Modul im Probebetrieb und schaue, wie sie sich mit dem Adapter verträgt und wie stabil und robust das Ganze ist.
Die USRIOT-Module sind halt

• wie ein Stück Hardware
• Einschalten und läuft
• Kein Update, keine Pflege
• In der Fritte ist das Internet für diese Teile gesperrt
• Physikalisch sind die klein (besonders das K7), so daß man sie auch gut in ein Gehäuse integrieren kann und
• Mit 300mW sind sie auch nicht ganz so leistungshungrig.
• Und man kann mit solch einer Lösung auch parallel weitere ioBroker oder auch ganz andere Systeme darauf zugreifen lassen.

[arteck]

ich habe ser2net laufen und davor usbip.. beide Lösungen funktionieren SUPER..

aber

Vorrausetzung ist 100% LAN Verbindung ohne Aussetzter... wenn dich knallt der Zigbee Adapter und der Zwave2 bleibt stehen ohne Daten zu verarbeiten...

meine 2 Sticks (zigbee und zwave) laufen Monate lang mit einem Rock64 im Netz.. jetzt ohne Probleme.. es gab ein Treiber Problem mit meiner Proxmix Umgebung .. wo ich 2 Wochen gesucht habe ..
seid dem 24/7 rennt die Kiste

[klassisch]

@arteck Danke für den Erfahrungsbericht und die Warnung.
USBIP kannte ich bisher noch nicht, danke für den Hinweis.

Ser2net war tricky zu installieren, weil es sich auf meinem armbian OPi nicht nach manpage verhalten hat. Hat aber dannletztlich funktionier - also fast immer.
Und dann soradische Aussetzer, dann wieder ein paar Tage gut.
Ähnlich am USB an meinem Win ioBroker Rechner. Da konnte man aber mit einem JScript was erreichen. Die USB-Hickups waren immer nur kurz und wenn man dann den Adapter 30 Sekunden nach disconnect wieder gestartet hat, dann war es wieder gut. Unelegant aber pragmatisch.
Aber USB direkt am ioBroker Rechner bedeutet bei mir auch einen schlechten Funkstandort. Und gute Funkbedingungen sind durch nichts zu ersetzen.
Wahrscheinlich hätte man das Thema näher einkreisen können, aber wenn nachts das Licht nicht mehr geht, werde ich ungeduldig. Die letzten 10 Jahre hat meine Hausautomatisierung eigentlich nur Komfortsteigerung, Datalogging etc realisiert. Mit Zigbee und Licht habe ich diesen Pfad der Tugend verlassen und jetzt bleibt das Licht aus, wenn die Zigbee-Kette unterbrochen ist oder der ioBroker Rechner nicht mehr läuft (gut in der Schublade gibt es noch Fernbedienungen, aber halt in der Schublade...). Diese Art der Abhängigkeit ist ein Novum für mich.

Deshalb habe ich diesen Weg versucht, der sich bei mir an anderer Stelle bereits bewährt hat. Nach dem Motto "Schnelle Lösung mit dem Holzhammer". Mal sehen, ob sich das hier auch bewährt.

Weißt Du wie lange der Adapter ein reconnect versucht, wenn das LAN weg ist? Beim USB waren es 5 Versuche; beim TCP scheint es etwas anders zu sein.

[1N4148]

@klassisch said in Zigbee-Stick cc2652P direkt über LAN anbinden:

Habe daher als Abhilfe einen alten Pi2 als IoBroker-Slave aufgesetzt, auf dem läuft nun der Zigbee-Adapter sowie eine Javascript-Instanz die alle Zigbee-Aktionen abwickelt.

Das klingt nach einer sehr guten Lösung. Solange man sich um Updates und Restarts drücken kann, hat man ein "autark" laufendes System, welches auch bei Updates des Hauptrechners noch das Licht bedient. Man bezahlt es halt mit der Komplexitätserhöhung durch ein multi host system. Wollte (und konnte) ich bisher vermeiden. Hatte das auch überlegt, denn mein OPI langweilt sich mit piVCCU und steht am guten Funkstandort.

Ein einzelnes System, das alles abdeckt, erhöht die Komplexität genauso. Irgendwo wird immer ein neuralgischer Punkt sein. Mittlerweile habe ich noch FHEM samt IoBroker Adapter auf den Pi2 umgezogen, da hängen die HM-MOD-RPI-PCB Funkmodule allerdings verteilt über mehrere OpenWrt-Router & ser2net. FHEM ist da robuster was einen Reconnect per LAN/WLAN betrifft.

Ich sehe allerdings nicht, wieso USB die Komplexität erhöhen bzw. die Verfügbarkeit verringern sollte.

Das sind halt ein paar Instanzen mehr "in Reihe" geschaltet. Fängt beim Kabel und den Steckern an, geht über den ser2net, das Linux USB-tty Zeugs und dessen Bootfestigkeit, der USB Architektur (root-Hub, generischer Hub) und Beinflussung durch andere USB Geräte.

Deshalb ist es immer besser wenn man die Geräte über /dev/serial/by-id/xxx anspricht.

Habe jetzt die Lösung mit dem USR TCP-Server-Modul im Probebetrieb und schaue, wie sie sich mit dem Adapter verträgt und wie stabil und robust das Ganze ist.
Die USRIOT-Module sind halt

• wie ein Stück Hardware
• Einschalten und läuft
• Kein Update, keine Pflege
• In der Fritte ist das Internet für diese Teile gesperrt
• Physikalisch sind die klein (besonders das K7), so daß man sie auch gut in ein Gehäuse integrieren kann und
• Mit 300mW sind sie auch nicht ganz so leistungshungrig.
• Und man kann mit solch einer Lösung auch parallel weitere ioBroker oder auch ganz andere Systeme darauf zugreifen lassen.

Sind durchaus interessant. Ich würde mir dann noch POE wünschen, dann könnte man sie tatsächlich ohne zusätzliches Netzteil irgendwo unterbringen.

[1N4148]

@klassisch said in Zigbee-Stick cc2652P direkt über LAN anbinden:

Mit Zigbee und Licht habe ich diesen Pfad der Tugend verlassen und jetzt bleibt das Licht aus, wenn die Zigbee-Kette unterbrochen ist oder der ioBroker Rechner nicht mehr läuft (gut in der Schublade gibt es noch Fernbedienungen, aber halt in der Schublade...). Diese Art der Abhängigkeit ist ein Novum für mich.

Noch mehr Gründe, Zigbee & Hauptlogik in ein eigenes, kleines System zu verfrachten. Wenn man dieses System dann noch irgendwie spiegeln könnte, so daß ein zweiter Host automatisch übernimmt wenn der erste ausfällt...

[klassisch]

Weißt Du wie lange der Adapter ein reconnect versucht, wenn das LAN weg ist? Beim USB waren es 5 Versuche; beim TCP scheint es etwas anders zu sein.

Habe das jetzt mal getestet:
ethernetstecker von USR Modul abgezogen.
Alle 30 Sekunden wird ein reconnect versucht.
Nach einer Stunde habe ich den Ethernetstecker wieder eingesteckt und beim nächsten retry hat der reconnect funktioniert.
Also recht robust und sollte ein Update der Fritte überstehen.

@1n4148 sagte in Zigbee-Stick cc2652P direkt über LAN anbinden:

Deshalb ist es immer besser wenn man die Geräte über /dev/serial/by-id/xxx anspricht.

Bei den Linux-Geräten mache ich das und beim Windows-Rechner ist das eh robuster

Ein einzelnes System, das alles abdeckt, erhöht die Komplexität genauso. Irgendwo wird immer ein neuralgischer Punkt sein

Mit diesen USRIOT Geräten geht das nicht schlecht. Natürlich, der ioBroker Rechner ist wichtig und muß deshalb gut wartbar sein. Deshalb bin ich dort von den SBCs weg. Ebenso muß das Netzwerk spielen. Aber wenn das (verkabelte) Netzwerk nicht mehr funktioniert, hat man ein generelles Problem.

Sind durchaus interessant. Ich würde mir dann noch POE wünschen, dann könnte man sie tatsächlich ohne zusätzliches Netzteil irgendwo unterbringen.

Sollte machbar sein. für 100MBit gibt es ja POE-Nachrüstlösungen, Injektorboxen etc. Sogar sowas billiges von Pollin. Habe aber keine Erfahrung damit. Bei Funkkomponenten habe ich eher einen (wahrscheinlich übertriebenen) Hang zu sauberen Versorgungen, siehe Homematic-Beispiel.

Noch mehr Gründe, Zigbee & Hauptlogik in ein eigenes, kleines System zu verfrachten.

Ja, keine Frage; möchte Dich auch nicht davon abbringen. Wenn man den Schritt zum Multi-Host mal gemacht hat und mit der Wartung zurecht kommt.
Selbst wenn das Netwerk ausfällt (Frittenupdate), sollte das zigbee Netz noch voll funktionieren. Oder?

[1N4148]

@klassisch said in Zigbee-Stick cc2652P direkt über LAN anbinden:

Habe das jetzt mal getestet:
ethernetstecker von USR Modul abgezogen.
Alle 30 Sekunden wird ein reconnect versucht.
Nach einer Stunde habe ich den Ethernetstecker wieder eingesteckt und beim nächsten retry hat der reconnect funktioniert.
Also recht robust und sollte ein Update der Fritte überstehen.

Interessant. Hier lief der Zigbee-Adapter irgendwann auf Fehler und benötigte einen Restart des Adapters.

Mit diesen USRIOT Geräten geht das nicht schlecht. Natürlich, der ioBroker Rechner ist wichtig und muß deshalb gut wartbar sein. Deshalb bin ich dort von den SBCs weg. Ebenso muß das Netzwerk spielen. Aber wenn das (verkabelte) Netzwerk nicht mehr funktioniert, hat man ein generelles Problem.

Mit den SBC habe ich halt die Möglichkeit Funktionen in sich zu autark kapseln. Die Heizungssteuerung (Brenner, Mischer, Speicher) lief jahrelang störungsfrei auf einem Pi 1B ohne Updates. Hardware & Logic waren eine Einheit. Das Netzwerk spielt damit eine untergeordnete Rolle.

Ja, keine Frage; möchte Dich auch nicht davon abbringen. Wenn man den Schritt zum Multi-Host mal gemacht hat und mit der Wartung zurecht kommt.
Selbst wenn das Netwerk ausfällt (Frittenupdate), sollte das zigbee Netz noch voll funktionieren. Oder?

Das ist Sinn und Zweck der Übung. Wobei hier ja auch noch einige Homematic-Komponenten im Einsatz sind, die Teil der Kette sind. Die Fritz ist zum einem von zwei Internet-Gateways degradiert, das Core-Netz besteht aus einem Ethernet-Backbone und parallelem OpenWrt-Mesh so daß zumindest die Backbone-Verbindung redundant ist.

[klassisch]

@1n4148 sagte in Zigbee-Stick cc2652P direkt über LAN anbinden:

Interessant. Hier lief der Zigbee-Adapter irgendwann auf Fehler und benötigte einen Restart des Adapters.

Das war bei meiner ser2net-Lösung auch so. In der Nacht stieg da irgendwas aus und hat sich nicht mehr gefangen. Vielleicht lag das am ser2net, am USB, oder an der Adapterversion? Keine Ahnung. Jetzt habe ich die Adapterversion 1.4.5 und da verhält sich das zusammen mit den USR Modulen so wie beschrieben. Finde ich sehr gut.

Mit den SBC habe ich halt die Möglichkeit Funktionen in sich zu autark kapseln. Die Heizungssteuerung (Brenner, Mischer, Speicher) lief jahrelang störungsfrei auf einem Pi 1B ohne Updates. Hardware & Logic waren eine Einheit. Das Netzwerk spielt damit eine untergeordnete Rolle.

Ja, solange man ohne Updates auskommt, ist das eine gute Lösung. Bei mir dümpelt ein NUT-Server ebenfalls ohne Updates. Und auch beim OPi für HM habe ich zumindest die Kernel-Updates unterdrückt.
In einem Multihost System gibt es aber wieder Abhängigkeiten zum Master, die zu Updtaes zwingen könnten - so zumindest meine Befürchtung.
Die Entwicklung bei ioBroker ist derzeit recht dynamisch und das hat Pros und Cons.

Das ist Sinn und Zweck der Übung. Wobei hier ja auch noch einige Homematic-Komponenten im Einsatz sind, die Teil der Kette sind. Die Fritz ist zum einem von zwei Internet-Gateways degradiert, das Core-Netz besteht aus einem Ethernet-Backbone und parallelem OpenWrt-Mesh so daß zumindest die Backbone-Verbindung redundant ist.

Respekt! So weit bin ich hier noch nicht. Wobei ich mich über die Zuverlässigkeit der 7590 nicht beschweren kann und zur Not gibt es noch die alte 7490 in der Reserve.

[1N4148]

@klassisch said in Zigbee-Stick cc2652P direkt über LAN anbinden:

In einem Multihost System gibt es aber wieder Abhängigkeiten zum Master, die zu Updtaes zwingen könnten - so zumindest meine Befürchtung.
Die Entwicklung bei ioBroker ist derzeit recht dynamisch und das hat Pros und Cons.

Ich muß gestehen, ich hab zwar Multihost aber die Abhängigkeiten noch nicht alle verstanden. Gut möglich, dass es kein verteiltes System ist, wie ich mir das vorstelle. Wunsch wäre ein virtueller redundanter Cluster.

Respekt! So weit bin ich hier noch nicht. Wobei ich mich über die Zuverlässigkeit der 7590 nicht beschweren kann und zur Not gibt es noch die alte 7490 in der Reserve.

Die 7360 läuft seit 2013 ununterbrochen ohne Ausfall. Allerdings ist das Netz hier in mehrere isolierte VLANs aufgetrennt, das kann die Fritz nicht. Daher habe ich sie zum Edge-Router degradiert.

[Slowman]

@klassisch

Verstehe ich es richtig, du hast mithilfe eines USB to Lan Adapter deinen ZigBee USB Stick über Netzwerk eingebunden und es funktioniert erst mal gut? Wenn das gut funktioniert, wäre das für mich auch die perfekte Lösung. An das Master/Slave und dem Ser2Net (zu viel englisch ) habe ich mich nicht ran getraut. Due Hardware, die du in deinen Beiträgen genannt hast find eich auch nicht, nur Seriell RS232 zu Ethernet.

Kannst du dann bitte für Unwissende einen kleinen FAQ, mit der benötigten Hardware erstellen?

[1N4148]

@slowman Nein, er hat den CC2652 vom Stick unter Umgehung des CH340 USB2SER-Konverters direkt an einen SER2LAN-Konverter (USRIOT) angeschlossen.

[Slowman]

@1n4148

Danke für deine Antwort. Also nichts Fertiges, was man kaufen kann. Sondern man muss selber Hand anlegen

Man findet ja nicht mal richtig die Teile

[1N4148]

@slowman Google findet mit USR E2 sofort einige richtige Treffer. Was ist dir an ser2net zu kompliziert?

[Slowman]

@1n4148 sagte in Zigbee-Stick cc2652P direkt über LAN anbinden:

ser2net

Habe keine deutsche aktuelle Anleitungen gefunden.

[klassisch]

@slowman sagte in Zigbee-Stick cc2652P direkt über LAN anbinden:
Also nichts Fertiges, was man kaufen kann. Sondern man muss selber Hand anlegen

Teilweise. Die serial <-> LAN Wandler gibt es schon fertig. Habe oben zu meinen Lösungen für RFLink und smartmeter verlinkt. Da gibt es mehr Info zu den Teilen, z.T. auch mit Bildern.
Aber bei den vorhandenen Zigbee Platinen muß man leider Hand anlegen, Leiterbahnen trennen Löten mit dünnen Drähtchen.

Man findet ja nicht mal richtig die Teile

s.o., mal in die Links schauen.

Wenn man nichts löten will bleibt nur eine Lösung mit einem SBC wie einem (kleinen) Raspi o.ä. und dem SW-Paket ser2net.

[klassisch]

@slowman sagte in Zigbee-Stick cc2652P direkt über LAN anbinden:

@1n4148 sagte in Zigbee-Stick cc2652P direkt über LAN anbinden:

Habe keine deutsche aktuelle Anleitungen gefunden.

Wie wäre es damit In diesem Forum und noch Zigbee

Bitte die hilfreichen Hinweise von @arteck befolgen und auf ipv4 achten. Damit hatte ich Probleme, wie man im weiteren verlauf des Threads lesen kann.

[1N4148]

@klassisch said in Zigbee-Stick cc2652P direkt über LAN anbinden:

Aber bei den vorhandenen Zigbee Platinen muß man Leiter Hand anlegen, Leiterbahnen trennen Löten mit dünnen Drähtchen.

Da würde ich dann gleich zum Ebyte E72 greifen. Schade dass bei Zigbee leider keine Redundanz mit mehreren Koordinatoren möglich ist, sonst hätte ich schnell ein Platinchen für beides entworfen.

[klassisch]

@1n4148 sagte in Zigbee-Stick cc2652P direkt über LAN anbinden:

@klassisch said in Zigbee-Stick cc2652P direkt über LAN anbinden:

Da würde ich dann gleich zum Ebyte E72 greifen.

ja, wäre möglich. Aber ein CH340 (FTDI, oder so) an Bord hat auch seine Vorteile. Denn den kann ich durch Umschalten (oder hier habe ich es durch Umstecken realisiert) wieder in Betrieb nehmen und dann kann man erforderlichenfalls auch Flashen. Beim RFLink hat das Flashen über Ethernet nicht funktioniert.

Schade dass bei Zigbee leider keine Redundanz mit mehreren Koordinatoren möglich ist, sonst hätte ich schnell ein Platinchen für beides entworfen.

Ja, das ist aus meiner Sicht ein großer Mangel. Denn so richtig bulletproof wie man es sich für eine Lichtsteuerung wünscht, scheint das Zigbee System out of the box nicht zu sein. Aber security und Redundanz würde die Komplexität nochmals steigern. Vielleicht bei Zigbee 5.0 ?