Zigbee-Stick cc2652P direkt über LAN anbinden

[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 ?

[1N4148]

@klassisch Bin gespannt auf die Langzeiterfahrung.

[klassisch]

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

@klassisch Bin gespannt auf die Langzeiterfahrung.

Ich auch.

• Heute stabil, keine Aussetzer
• Frittenupdate hat die Sache auch überstanden. Anschließend wieder connected

Allerdings habe ich mir durch die Experimente 2 Floalt in einen seltsamen Zustand gebracht. Habe testweise eine andere Pan Id genommen. Jetzt lassen die sich nicht mehr an die ursprüngliche Pan Id anlernen.
6 mal Aus und Ein funktioniert leider nicht.

Gibt es da noch einen anderen Trick die Panels in den Werkszustand zu versetzen?