Zugriff auf externe zigbee2MQTT2 bzw MQTT2_device

[rudolfkoenig]

defmod docker_MQTT2 MQTT2_SERVER 52709 192.168.0.20

Gibt es einen triftigen Grund, statt global die genaue Adresse anzugeben?

[flummy1978]

Gibt es einen triftigen Grund, statt global die genaue Adresse anzugeben?

Wahrscheinlich weil ich hier alles durcheinander geworfen habe was ich nur kann:

Der Aufruf erfolgt auf dem Raspi der die IP x.x.x.24 hat und er soll eben auf das Zigbee auf x.x.x.20 zugreifen. Somit muss ich ihm natürlich sagen wo er das Ganze findet ?

[rudolfkoenig]

MQTT2_SERVER ist ein Server, d.h. er lauscht auf einem oder mehreren Netzwerk-Interfaces, und wartet auf Anfragen.
Ohne zweiten Parameter lauscht MQTT_SERVER auf localhost, mit global auf alles, was auf dem Rechner vorhanden ist, und mit der IP-Adresse versucht er ein Interface mit dieser IP zu verwenden. Letzteres koennte im Docker ein Problem sein.

[Otto123]

Wenn ich nun das DockerFhem ausschalte (somit wird dieser Port ja auch nicht genutzt)
und versuche wie oben geschrieben den mqtt2_server einzubinden:

Hier bin ich verloren 
Du schaltest docker-fehm - also Du beendest den container in dem FHEM läuft? Du beendest FHEM? Du bräuchtest auch nur den MQTT2_SERVER beenden...
Vielleicht tust Du ja hier etwas, was in Wirklichkeit gar nicht beendet?

Auf welchem FHEM führst Du dann diesen Befehl aus?

Code Auswählen Erweitern

defmod docker_MQTT2 MQTT2_SERVER 52709 192.168.0.20

Auf dem Host FHEM?
Hast Du Dir auf dem Host schon mal die Ports angeschaut?

Code Auswählen Erweitern

ss -lntu

und hast Du einfach mal diesen Befehl mit einem anderen Port (und ohne IP ) versucht? Nur mal so?

dass ich der Einzige bin, der auf einen entfernten Zigbee Stick zugreifen will

Du bist höchstens der Einzige der alles auf einem Port reiten will 

[rudolfkoenig]

Du bist höchstens der Einzige der alles auf einem Port reiten will 

Die Fehlermeldung weist nicht auf ein Port Konflkt hin, das waere "Port already in use".
"Cannot assign requested address" hat mAn eher was mit der Adresse (192.168.0.20) zu tun.
Aber ich gebe dir Recht, die IP-Adresse spezifiziert kaum jemand, und noch weniger in einem container mit host-netzwerk.

[Otto123]

Da hast Du Recht.  Da habe ich offenbar falsch gedacht ...
Er muss eben einfach mal links und rechts probieren und nicht die eine Definition reiten 

[Beta-User]

Habe zwar von docker eigentlich auch keine Ahnung, aber so wie ich das bei Andreas Spiess in https://www.youtube.com/watch?v=KJRMjUzlHI8 (ca. 14:27) verstanden habe, werden _innerhalb_ einer docker-Umgebung keine IP-Adressen verwendet, sondern (ausschließlich) Container-Namen. Von daher müßte zigbee2mqtt an den "fhem"-Container senden (wenn MQTT2_SERVER auf dem üblichen Port verwendet wird), und FHEM sollte wie gewohnt auf den "üblichen Ports" erreichbar sein, also z.B. auch für externe MQTT-Clients (wie z.B. einer 2. Installation auf einem anderen Rechner).

(Das mit den abweichenden Ports würde ich (wenn überhaupt) erst angehen, wenn mal die Basis steht).

[Otto123]

@Jörg schön das es Dir ähnlich wie mir geht. Aber ich glaube mittlerweile verstanden zu haben, dass es um die DEF geht, die auf dem FHEM auf dem Host ist - und nicht eine im docker

Und er arbeitet im Host Modus, da hängen alle direkt am Netzwerk. 

[rudolfkoenig]

werden _innerhalb_ einer docker-Umgebung keine IP-Adressen verwendet, sondern (ausschließlich) Container-Namen.

Das gilt dann, wenn man alle betroffenen Container mit --network XXX an dem gleichen docker Netzwerk angeschlossen hat, und den Zielcontainer mit einem (sinnvollen) Namen gestartet hat. IP-Adressen kann man natuerlich weiterhin verwenden, das ist aber nicht so sexy, insb. wenn man die Container als Service auf einem Swarm/Kubernetes/etc Verbund von mehreren Rechnern startet.

[Beta-User]

Wie dem auch sei, Sätze wie

dass ich der Einzige bin, der auf einen entfernten Zigbee Stick zugreifen will

irritieren mich ziemlich. Es geht ja nicht um ser2net (& ähnliches), sondern um die Kommunikation zwischen zwei Diensten (MQTT-Server und zigbee2mqtt).

Die Kommunikation zwischen beidem _auf der Docker-Maschine_ schein ja zu funktionieren.

Frage: Was soll in dem Zusammenhang MQTT GENERIC BRIDGE?

[...] - und wenn ich es mal richtig verstanden hab kann ich über die MQTT GENERIC BRIDGE [...] auch die Sachen korrekt an das entfernte FHEM weiterleiten (bisher funktionierte es bedingt, mit falschen Topics / Readings etc.) - Aber es ging generell und somit war die Funktion zigbee->fhem (auf der gleichen Hardware - aber jeweils im Docker) schon mal vorhanden

Klar kann man mit MQTT GENERIC BRIDGE auch hinfrickeln, dass man die Geräte irgendwo anders nochmal abbildet. Aber da wir es von vonherein mit MQTT-Daten zu tun haben, ist es doch einfacher, aus dem "Zweit-FHEM" (also außerhalb docker) via MQTT2_CLIENT den MQTT-Server (MQTT2_SERVER) auf der docker-Installation anzuzapfen? Dann sollte es reichen, einfach IODev an den bestehenden Geräten in dem "Zweit-FHEM" zu ändern und gut ist?

(Oder übersehe ich auch an der Stelle wieder was wichtiges?)

Das gilt dann, wenn man alle betroffenen Container mit --network XXX an dem gleichen docker Netzwerk angeschlossen hat, und den Zielcontainer mit einem (sinnvollen) Namen gestartet hat. IP-Adressen kann man natuerlich weiterhin verwenden, das ist aber nicht so sexy, insb. wenn man die Container als Service auf einem Swarm/Kubernetes/etc Verbund von mehreren Rechnern startet.

(Mist, eigentlich wollte ich mich nicht intensiver mit docker rumschlagen, aber insgesamt scheint es interessant zu sein, wenn man mal durchgestiegen ist...)

[flummy1978]

Ihr seid ja echt die geilsten, unterhaltet Euch mal schön weiter über mein Problem, ich versuche dann mal durchzusteigen und melde mich in 3 Wochen wenn ich alles verstanden hab wieder *lach*

Ne mal im Ernst: Vielen lieben Dank für die rege Beteiligung an meinem "Problem". Langsam werden einige Dinge klarer, ABER ich befürchte mit dem Erwähnen des Ports habe ich für mehr Verwirrung gesorgt als ich wollte. Bin arbeiten, daher kann ich grad nichts ausführen oder testen, aber ich versuche es trotzdem der Reihe nach nochmal.

Für die Übersicht:
System 1 (alles auf einem Raspberry installiert) beinhaltet Raspi-Fhem und Raspi-Zigbee
System 2 (alles auf einer Synology Diskstaition installiert) beinhaltet Docker-Fhem (ein Docker den ich einzeln ein und ausschalten kann) und Docker-Zigbee (ein Docker den ich einzeln ein und ausschalten kann)
System 3 ingorieren wir jetzt mal vollständig

Im Großen und Ganzen muss es doch egal sein ob ich Port 1883 oder 1234 oder 99999 für etwas benutze? Solange der Port VORHER frei war, nicht von anderen Sachen genutzt wird und der Zugriff ermöglicht wird, (sprich es wird in der Config so eingerichtet), ist es ja wurscht.

DASS es funktioniert hat @Beta-User ja korrekt erkannt, weil die Kommunikation von Docker-FHEM zu Docker-Zigbee genauso funktioniert wie von Raspi-Fhem zu Raspi-Zigbee. Raspi-Fhem mit Zugriff auf Docker-Zigbee ist genauso das Problem wie Docker-Fhem auf Raspi-Zigbee (was ich gern hätte)

@Otto:

Hier bin ich verloren 
Du schaltest docker-fehm - also Du beendest den container in dem FHEM läuft? Du beendest FHEM? Du bräuchtest auch nur den MQTT2_SERVER beenden...

Warum ? Na klar, würden vielleicht auch andere Sachen funktionieren, aber in dem fall: DOCKER Fhem: shutdown -> Docker aus. Damit greift auf KEINEN FALL etwas auf den Zigbee2MQTT im anderen Docker. Es ist ein Testsystem also kein Problem das komplett es aus zu machen. Dann kommt der entsprechende Versuch es einzubinden und somit zu der entspr. Fehlermeldung.
Restlichen Dinge / Einwände kann ich wie gesagt erst zu Hause testen.

@rudolfkoenig:

Ohne zweiten Parameter lauscht MQTT_SERVER auf localhost, mit global auf alles, was auf dem Rechner vorhanden ist, und mit der IP-Adresse versucht er ein Interface mit dieser IP zu verwenden. Letzteres koennte im Docker ein Problem sein
.....
Die Fehlermeldung weist nicht auf ein Port Konflkt hin, das waere "Port already in use".
"Cannot assign requested address" hat mAn eher was mit der Adresse (192.168.0.20) zu tun.
Aber ich gebe dir Recht, die IP-Adresse spezifiziert kaum jemand, und noch weniger in einem container mit host-netzwerk.

Das eine bestätigt ja meine Vermutung, das Andere wären in der Tat Einwände, die durchaus zutreffen könnten. Ich werde versuchen ausschließlich von Docker-Fhem auf das Raspi-Zigbee zuzugreifen, dann sollte mich die IP vom Docker nicht tangieren. WENN das irgendwann läuft, kann ich aus Lerngründen mal Zigbee im Docker OHNE Host (eigene IP) laufen lassen und das dann nochmal testen.

Damit komme ich auch  zum Einwand von @Beta-User:

Wie dem auch sei, Sätze wieirritieren mich ziemlich. Es geht ja nicht um ser2net (& ähnliches), sondern um die Kommunikation zwischen zwei Diensten (MQTT-Server und zigbee2mqtt).

Die Kommunikation zwischen beidem _auf der Docker-Maschine_ schein ja zu funktionieren.

Wie oben geschrieben FUNKTIONIERT die Kommunikation jeweils Systemintern vollständig. Ser2net hab ich auch irgendwo mal gelesen und wäre vielleicht ja auch eine Möglichkeit - Aber in diesem einen Fall geht es ja speziell wie Du korrekt erkannt hast um die Kommunikation zwischen MQTT Server (auf der einen Hardware) und Zigbee2MQTT (auf der anderen Hardware)

Frage: Was soll in dem Zusammenhang MQTT GENERIC BRIDGE?

In dem Zusammenhang SOLL es gar nichts. Ich habe einfach versucht wie ich sonst zwischen den beiden Teilen kommunizieren könnte. Das hier zu erwähnen, war doof, weil es überhaupt nichts damit zum tun hat.... Sorry.

Um das Ganze  in der Übersicht besser stehen zu lassen noch mal die aktuelle Situation :
Oben gelistete Systeme -> Auf dem Raspi laufen auch ein paar Homematik und Tasmota Geräte. Altes System mit vielen Altlasten
und mein Wunsch:
Ich würde gern (langsam der Reihe nach) vom Raspi auf den Docker umziehen. Im Raspi-Zigbee sind aber viele Geräte die durchgehend und auch nach dem Umzug weiterhin erreichbar bleiben sollten. Ein erneutes Anlernen an (neuem) Zigbe2MQTT würde ich gern vermeiden (weil es eben doch ein "paar" sind)
Das Haus ist relativ verstreut und auch repeater kommen an ihre Grenzen. Abgesehen davon komme ich auch Gerätetechnisch langsam an die Grenzen komme, weil es wie gesagt viele sind.
Das neue System etwas aufteilen (damit nicht bei Ausfall eines Teils alles weg ist)
Zugriff auf externe Geräte lernen (Ser2Net oder MQTT GENERIC BRIDGE hab ich genauso schon mal gelesen wie Fhem2Fhem ... aber was macht wo am meisten Sinn?

Beim Umziehen möchte ich natürlich eben noch mehr (korrektes) Wissen aneignen, weil ich glaube dass das System vom Ursprung her zwar läuft, aber sicher nicht 1000%ig korrekt angelegt wurde.

Vielleicht wird es damit wieder verständlicher.

Ich freue mich sehr über und auf eine weiterhin angeregte Unterhaltung  und Tipps von Euch 

Viele Grüße
Andreas

[Beta-User]

Also: ser2net vergißt du bitte gleich wieder, du hast je einen eigenen Stick pro zigbee2mqtt-Dienst, und das ist auch (vorübergehend) ok so.

Du schaust dir bitte MQTT2_CLIENT an und bindest darüber bitte das jeweils andere FHEM (genauer: den jeweiligen MQTT2_SERVER) ein - so solltest du (eigentlich direkten!) Zugriff auf die zigbee2mqtt-Daten bekommen. Wenn das klappt, kannst du jeweils "umlernen" (also am einen Stick ab- und am anderen an-lernen) und einfach das IODev von M2S auf M2C umhängen, wenn das geklappt hat.

[Otto123]

mMn bist Du völlig verpolt:

Damit greift auf KEINEN FALL etwas auf den Zigbee2MQTT im anderen Docker.

Ich meine: man kann das sehen wie man will - aber Du brauchst einen MQTT Server und auf den greift Zigbee2MQTT als MQTT Client zu. Oder lieg ich falsch?
Mach doch die zweite DEF MQTT2_SERVER genau wie die Erste, die Du herunterfährst?!

Im Übrigen: Ich bezweifle, dass ein FHEM shutdown den docker container herunterfährt. Das Ding ist schneller wieder oben als Du denken kannst, der macht per default einen restart.
ein docker stop würde den container beenden.
Aber das kann bei deinem docker auf diskstation wieder anders sein - allein mir fehlt die Überzeugung. 

(Mist, eigentlich wollte ich mich nicht intensiver mit docker rumschlagen, aber insgesamt scheint es interessant zu sein, wenn man mal durchgestiegen ist...)

Ja 

[flummy1978]

Du schaust dir bitte MQTT2_CLIENT an und bindest darüber bitte das jeweils andere FHEM (genauer: den jeweiligen MQTT2_SERVER) ein - so solltest du (eigentlich direkten!) Zugriff auf die zigbee2mqtt-Daten bekommen. Wenn das klappt, kannst du jeweils "umlernen" (also am einen Stick ab- und am anderen an-lernen) und einfach das IODev von M2S auf M2C umhängen, wenn das geklappt hat.

Vielen Dank für die Anweisung... Jetzt wird aus den M2S M2C M2D oder MGB Bereichen auch wieder ein wenig mehr ein Schuh draus. Schau ich mir auf jeden Fall genauso an und versuche das mal umzusetzen

mMn bist Du völlig verpolt:

Im Übrigen: Ich bezweifle, dass ein FHEM shutdown den docker container herunterfährt. Das Ding ist schneller wieder oben als Du denken kannst, der macht per default einen restart.
ein docker stop würde den container beenden.
Aber das kann bei deinem docker auf diskstation wieder anders sein - allein mir fehlt die Überzeugung. 

Von verpolt würde ich jetzt nicht sprechen, aber bei verpeilt kommen wir der Sache näher 

Aber mal im Ernst..... Ich glaube in einigen Sachen unterschätzt Du mich. Sicherrlich bin  ich nicht die hellste Kerze auf der Linux Torte und tue mir auch hier und da sehr schwer, aber ich gebe kaum Befehle einfach so ein (auch im docker nicht) , ohne zu wissen was sie tun.
So war es auch beim restart Befehl, der bei einem Testsystem keinen Sinn macht. DH wenn ich meinen docker nicht autostarten will, nachdem ich ihn herunter gefahren habe, dann startet dieser auch nicht neu. Genau das passiert hier auch
Soll heißen: ich fahre fhem runter,mache den Docker aus (korrekt über stop) und damit läuft kein fhem mehr im docker sondern lediglich zig2mqtt läuft noch auf einem anderen docker.

Viele Grüße
Andreas 

[Otto123]

nein -> verpeilt oder verpolt - beides kann man als Beleidigung verstehen. Wollte ich definitiv nicht. Manchmal wähle ich eben übertrieben Worte

Nochmal zu fhem stop: docker stop reicht dafür völlig, das beendet FHEM ordentlich und die "Maschine" ist aus. 

Aber wie isses denn jetzt? Du machst es spannend. Ich meine einfach ein define für den Server. Das mit MQTT2_CLIENT macht es ja jetzt noch komplexer und dauert nochmal länger