Zugriff auf externe zigbee2MQTT2 bzw MQTT2_device

Begonnen von flummy1978, 16 Mai 2021, 13:26:43

Vorheriges Thema - Nächstes Thema

flummy1978

Hallo zusammen,

nachdem ich mit meiner neuen Diskstation unzählige Sachen durch habe und dort auch mittlerweile vieles läuft wollte ich gern auf die nächste Baustelle zugehen:

Zugriff von FHEM aus auf FHEM bzw zigbee2mqtt, das auf der Diskstation läuft (Später auch umgekehrt, damit die Diskstation zum HauptFHEM wird). Mir ist durchaus bewusst, dass ich auch mit Fhem2Fhem oder ähnlichem drauf zugreifen könnte, aber ich denke direkt auf die MQTT daten zugreifen, macht viel mehr Sinn. Vor allem wenn diese tests erfolgreich sind, würde ich ggf gern langsam aber sicher den Umstieg vom Raspi auf die Diskstation vornehmen wollen. Dazu möchte ich gern von beiden Seiten auf den jeweiligen MQTT Teil (hier erstmal Zigbee, später dann alles andere)  Teil zugreifen. Konstellation:

Auf beiden Geräten (Raspi und Diskstation) ist jeweils ein Zigbee Stick, FHEM und Zigbeee2MQTT installiert. Beide Instanzen funktionieren separat. Hier ist also in allen Bereichen alles richtig eingebunden. Nun habe ich die folgende Info gelesen und gedacht dass es richtig so wäre:

Zitatdefine <name> MQTT2_SERVER <tcp-portnr> [global|IP]

Enable the server on port <tcp-portnr>. If global is specified, then requests from all interfaces (not only localhost / 127.0.0.1) are serviced. If IP is specified, then MQTT2_SERVER will only listen on this IP.
To enable listening on IPV6 see the comments here.
defmod docker_MQTT2 MQTT2_SERVER 52709 192.168.0.20

Auf dem Docker mit der IP läuft der  MQTT2_SERVER der unter dem Port. Dummerweise ist die Defition ja schon nicht richtig, weil er die Adresse nicht zuordnen kann:
docker_MQTT2: Can't open server port at 52709: Cannot assign requested address

Dadurch dass das auch mein Live System ist an dem ich etwas rumspiele, möchte ich ungern zuviel auf einmal verstellen. Daher meine Frage: Wie gehe ich am besten vor?

Lists vom Docker (auf dem Live System ist es ähnlich aufgebaut)
brok_MQTT2
Internals:
   CONNECTS   2
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        52709 global
   FD         9
   FUUID      5fb06b88-f33f-2acb-0283-34428bf182a80c89
   FVERSION   00_MQTT2_SERVER.pm:0.239870/2021-03-17
   NAME       brok_MQTT2
   NR         21
   PORT       52709
   STATE      Initialized
   TYPE       MQTT2_SERVER
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2021-05-16 12:45:12   RETAIN          {"zigbee2mqtt/bridge/config":"{\u0022commit\u0022:\u00226b32f30\u0022,\u0022coordinator\u0022:{\u0022meta\u0022:{\u0022maintrel\u0022:3,\u0022majorrel\u0022:2,\u0022minorrel\u0022:6,\u0022product\u0022:0,\u0022revision\u0022:20190619,\u0022transportrev\u0022:2},\u0022type\u0022:\u0022zStack12\u0022},\u0022log_level\u0022:\u0022info\u0022,\u0022network\u0022:{\u0022channel\u0022:20,\u0022extendedPanID\u0022:\u00220xdddddddddddddddd\u0022,\u0022panID\u0022:6754},\u0022permit_join\u0022:false,\u0022version\u0022:\u00221.16.1\u0022}","zigbee2mqtt/bridge/state":"online"}
     2021-05-16 12:45:12   nrclients       1
     2021-05-16 12:23:21   state           Initialized
   clients:
     brok_MQTT2_192.168.0.20_45014 1
   retain:
     zigbee2mqtt/bridge/config:
       ts         1621161912.89965
       val        {"commit":"6b32f30","coordinator":{"meta":{"maintrel":3,"majorrel":2,"minorrel":6,"product":0,"revision":20190619,"transportrev":2},"type":"zStack12"},"log_level":"info","network":{"channel":20,"extendedPanID":"0xdddddddddddddddd","panID":6754},"permit_join":false,"version":"1.16.1"}
     zigbee2mqtt/bridge/state:
       ts         1621161912.88376
       val        online
Attributes:
   alias      MQTT Broker
   autocreate simple
   disable    0
   event-on-change-reading RETAIN,state
   group      MQTT
   icon       mqtt
   room       System


Zigbee2mqtt:
Internals:
   CID        mqttjs_e0b1f225
   DEF        mqttjs_e0b1f225
   DEVICETOPIC zigbee2mqtt
   FUUID      5fb06b89-f33f-2acb-504f-95063f4c44356d53
   FVERSION   10_MQTT2_DEVICE.pm:0.244470/2021-05-15
   IODev      brok_MQTT2
   LASTInputDev brok_MQTT2
   MSGCNT     12
   NAME       MQTT2_mqttjs_e0b1f225
   NR         22
   STATE      online
   TYPE       MQTT2_DEVICE
   brok_MQTT2_MSGCNT 12
   brok_MQTT2_TIME 2021-05-16 12:45:12
   READINGS:
     2021-05-16 12:23:21   IODev           brok_MQTT2
     2021-05-16 12:45:12   commit          6b48f30
     2021-05-16 12:45:12   coordinator_meta_maintrel 3
     2021-05-16 12:45:12   coordinator_meta_majorrel 2
     2021-05-16 12:45:12   coordinator_meta_minorrel 6
     2021-05-16 12:45:12   coordinator_meta_product 0
     2021-05-16 12:45:12   coordinator_meta_revision 20190619
     2021-05-16 12:45:12   coordinator_meta_transportrev 2
     2021-05-16 12:45:12   coordinator_type zStack12
     2021-05-16 12:28:29   log             {"message":"interview_successful","meta":{"description":"MiJia door & window contact sensor","friendly_name":"0x00158d0002d72f41","model":"MCCGQ01LM","supported":true,"vendor":"Xiaomi"},"type":"pairing"}
     2021-05-16 12:45:12   log_level       info
     2021-05-16 12:45:12   network_channel 20
     2021-05-16 12:45:12   network_extendedPanID 0xdddddddddddddddd
     2021-05-16 12:45:12   network_panID   4571
     2021-05-16 12:45:12   permit_join     false
     2021-05-16 12:45:12   state           online
     2021-05-16 12:45:12   version         1.16.1
Attributes:
   IODev      brok_MQTT2
   alias      ZigbeeBridge
   bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]+)[/]?.*:.* "zigbee_$1"
   comment    To check for new updates of the deamon software, you might want to use a separate HTTPMOD device. See HTTPMOD template zigbee2mqtt_daemon_updates for further details.
   devicetopic zigbee2mqtt
   event-on-change-reading .*
   getList    devicelist:noArg log $DEVICETOPIC/bridge/config/devices
  networkmap_raw:noArg raw $DEVICETOPIC/bridge/networkmap raw
  networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/networkmap graphviz
   icon       mqtt
   model      zigbee2mqtt_bridge
   readingList $DEVICETOPIC/bridge/state:.* state
  $DEVICETOPIC/bridge/config/devices:.* {}
  $DEVICETOPIC/bridge/config/log_level:.* log_level
  $DEVICETOPIC/bridge/config/permit_join:.* permit_join
  $DEVICETOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }
  $DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices
  $DEVICETOPIC/bridge/log:.* log
  $DEVICETOPIC/bridge/networkmap:.* {}
  $DEVICETOPIC/bridge/networkmap/graphviz:.* graphviz
  $DEVICETOPIC/bridge/networkmap/raw:.* raw
  $DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT) }
   room       System
   setList    log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1
  permit_join:true,false $DEVICETOPIC/bridge/config/permit_join $EVTPART1
  remove:textField $DEVICETOPIC/bridge/config/remove $EVTPART1
  ota_update:textField $DEVICETOPIC/bridge/ota_update/update $EVTPART1
  ota_update_check:textField $DEVICETOPIC/bridge/ota_update/check $EVTPART1
  y_device_setting:textField $DEVICETOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}
  x_bind:textField $DEVICETOPIC/bridge/bind/$EVTPART1 $EVTPART2
  x_bind_unbind:textField $DEVICETOPIC/bridge/unbind/$EVTPART1 $EVTPART2
  x_device_options:textField $DEVICETOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}
  x_group_add_to:textField $DEVICETOPIC/bridge/group/$EVTPART1/add $EVTPART2
  x_group_rm_from:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove $EVTPART2
  x_group_rm_from_all:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2
  x_group_add_group:textField $DEVICETOPIC/bridge/config/add_group $EVTPART1
  x_group_rm_group:textField $DEVICETOPIC/bridge/config/remove_group $EVTPART1
  z_elapsed:textField $DEVICETOPIC/bridge/config/elapsed $EVTPART1
  z_last_seen:disable,ISO_8601,epoch,ISO_8601_local $DEVICETOPIC/bridge/config/last_seen $EVTPART1
  z_ban:textField $DEVICETOPIC/bridge/config/ban $EVTPART1
  z_rename:textField $DEVICETOPIC/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}
  z_reset_CC:noArg $DEVICETOPIC/bridge/config/reset
   setStateList on off


Hab auf dem Docker mal zwei Geräte angelernt um das hin und her lesen zu können, weiß aber außer dem oberen Beispiel ehrlicherweise nicht wonach ich jetzt Ausschau halten könnte.... Bin für jeden Tipp dankbar.

Vielen Dank im Voraus
Viele Grüße
Andreas

Otto123

#1
Hallo Andreas,

docker ist eben etwas speziell: daher die primäre Frage: Wie läuft denn Dein docker Container? Wie ist das Netzwerk eingestellt? Offenbar nicht im hostmodus?
Offenbar hat der die IP Adresse 192.168.0.20 nicht. Vielleicht hat der docker host diese Adresse?

Dann mach die Definition mit global - ist aus meiner Sicht gleichbedeuten mit der IP Des Containers :)

Um die Netzwerkfrage zu  klären: was gibt dir:
{qx(ip addr show)}
In der FHEM Kommandozeile des FHEM im docker container zurück?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

Zitatdocker_MQTT2: Can't open server port at 52709: Cannot assign requested address
Im Docker Container ist die IP 192.168.0.20 nicht verfuegbar (der Container ist vom Aussenwelt abgekapselt), die Verbindung muss man  mit dem Container start Parameter -p:52709:52709 explizit herstellen. Ob der MQTT2_SERVER global Parameter im Container noetig ist, weiss ich nicht, es schadet aber sicher nicht.

flummy1978

Holla,

vielen lieben Dank für Eure TURBO Antworten... der Reihe nach:

Zitat von: Otto123 am 16 Mai 2021, 13:37:10
docker ist eben etwas speziell: daher die primäre Frage: Wie läuft denn Dein docker Container? Wie ist das Netzwerk eingestellt? Offenbar nicht im hostmodus?
...
{qx(ip addr show)}
In der FHEM Kommandozeile des FHEM im docker container zurück?
Doch der Docker läuft im Hostmodus die 20 ist die Adresse der Diskstation und mit http://192.168.0.20:port kann ich entsprechendes FHEM aufrufen.
addr show:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:11:32:be:8f:45 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.20/16 brd 192.168.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::211:32ff:febe:8f45/64 scope link
       valid_lft forever preferred_lft forever
4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:11:32:be:8f:46 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.205/16 brd 192.168.255.255 scope global eth1
       valid_lft forever preferred_lft forever
6: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:3e:05:ad:d7 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:3eff:fe05:add7/64 scope link
       valid_lft forever preferred_lft forever
8: docker9d1c521@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 8e:3b:a2:46:80:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::8c3b:a2ff:fe46:8099/64 scope link
       valid_lft forever preferred_lft forever


Zitat von: rudolfkoenig am 16 Mai 2021, 13:37:58
Im Docker Container ist die IP 192.168.0.20 nicht verfuegbar (der Container ist vom Aussenwelt abgekapselt), die Verbindung muss man  mit dem Container start Parameter -p:52709:52709 explizit herstellen. Ob der MQTT2_SERVER global Parameter im Container noetig ist, weiss ich nicht, es schadet aber sicher nicht.
Mhmm das wäre in der Tat eine Möglichkeit. Allerdings kann ich die Ports im Host Modus nicht verändern. Diese werden 1:1 weiter gegeben. Für mich ist das Zeichen dafür, dass ich auf FHEM zugreifen kann ohne diesen Port explizit eingerichtet zu haben (außer in der FHEM Installation)
Hatte temporär mal die Firewall auf der Diskstation abgestellt, aber ohne Erfolg (wobei ich mir auch sicher bin, dass ich immer alle Ports die mit Fhem Zigbee etc zu tun hatten auch frei gegeben habe)

Wenn ich im Docker "Log" schaue (es ist nicht wirklich n Log, aber zumindest stehen da ein paar Infos:

Zigbee2MQTT:info  2021-05-16 13:46:35: Zigbee: disabling joining new devices.
Zigbee2MQTT:info  2021-05-16 13:46:35: Connecting to MQTT server at mqtt://192.168.0.20:52709


Das zeigt mir, dass es eigentlich erreichbar sein sollte ;)

VG
Andreas

flummy1978

Hallo zusammen,

auch wenn das sonst bisher kein Idee dazu kam kleine Info von mir:

Zitat von: flummy1978 am 16 Mai 2021, 13:26:43
defmod docker_MQTT2 MQTT2_SERVER 52709 192.168.0.20

Auf dem Docker mit der IP läuft der  MQTT2_SERVER der unter dem Port. Dummerweise ist die Defition ja schon nicht richtig, weil er die Adresse nicht zuordnen kann:
docker_MQTT2: Can't open server port at 52709: Cannot assign requested address
Mit dem Befehl bin ich (scheinbar) so oder so nicht richtig, ich hab nämlich noch einiges getestet:
Der Port 52709 ist auf der Diskstation erreichbar (Portscan)
Wenn ich den Befehl auf der Diskstation ausführe und versuche damit auf mein Live-System-Raspi zuzugreifen, kommt die gleiche Fehlermeldung  :'(

Hat sonst jemand eine gute Idee, wie ich versuchen könnte auf die entsprechenden Daten zuzugreifen ?

VG
Andreas

Otto123

ZitatDer Port 52709 ist auf der Diskstation erreichbar (Portscan)
Das bedeutet doch der Port ist belegt. Damit kann FHEM MQTT den Port nicht noch einmal verwenden.
Wie kommst Du eigentlich auf diesen exotischen Port? Warum nimmst Du nicht Standard?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

flummy1978

Hallo Otto,

Zitat von: Otto123 am 17 Mai 2021, 18:41:23
Das bedeutet doch der Port ist belegt. Damit kann FHEM MQTT den Port nicht noch einmal verwenden.
Wie kommst Du eigentlich auf diesen exotischen Port? Warum nimmst Du nicht Standard?

Der erste Hinweis hat mich auf einen eventuellen Denkfehler von mir gebracht: Ich habe ja eimal FHEM und Zigbee2MQTT im Docker laufen und einmal eben auf dem Raspi. Wenn jetzt im Docker von FHEM auf Zigbee zugegriffen wird, kann ich ja nicht nochmal vom Raspi auf den Docker Zigbee zugreifen ... eigentlich logisch. Habe ich aber vorher nicht bedacht. Nun den Fhem im Docker aus, Zigbee2MQTT auf dem Docker neu gestartet ...... leider ohne Erfolg ;( Ergebnis ist das Gleiche wie oben....

Zum Port: Ich hab mir irgendwann mal angewöhnt keine Stadardports zu nutzen und dadurch eine (nicht) vorhandene zusätzliche Sicherheit vorzutäauschen. Mir ist bewusst, dass das gar nichts bringt, aber aus Gewohnheit hab ichs beibehalten - Beim docker hat es den Vorteil dass ich im host Modus mehrere Versionen installiert haben kann und dadurch ja eh unterschiedliche Ports nutzen muss.

Ich kann mir fast nicht vorstellen, dass ich der Erste / Einzige bin, der auf die Idee kommt auf MQTT und/oder Zigbee Informationen zugreifen möchte, die auf einer anderen Quelle ihren Ursprung haben, als das laufende FHEM *grübel*  ???

VG
Andreas

Otto123

Hallo Andreas,

es ist mir und MQTT wahrscheinlich wurscht welches Port du verwendest. Nur Du darfst eben nicht für alle Deine Applikationen das Port 52709 verwenden.

BTW: Der eigentliche Sinn von Docker ist es nicht, dass alle Container im Host Modus laufen. Kann man als Ausnahme mal machen weil mache Applikationen schwierig in der Abschottung des Dockernetzwerkes zu händeln sind. Aber Hostmodus im Docker ist wie alles sudo im System -> ein dünnes Brett bohren. ;)

Du kannst selbstverständlich 27 mal einen MQTT Server auf einer Station betreiben, nur eben jeder auf einem anderen Port. Und wenn Du alle Docker Container im Hostmodus betreibst, darfst Du auf dem Host nur jedes Port einmal verwenden.

Ich habe jetzt nicht verstanden, was Du probierts - aber offenbar versuchst Du immer noch ein Port mehrfach für einen Serverdienst zu verwenden.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

flummy1978

Hai Otto,
und alle anderen,

ich fürchte ich hab mein Problemchen irgendwie falsch beschrieben. Zunächst einmal bzgl Docker:
Ich finde es so sogar teilweise noch besser, wenn das Ding im Host  läuft und so eben die Sachen alle unter der IP erreichbar bleiben (viele Docker Dokus beschreiben explizit den Host Modus - Ich denke dieser ist Anfängerfreundlicher zu diesen zähle ich mich defintiv).

Selbstverständlich ist es aber so, dass die Sachen die dort laufen, eben nicht alle auf den gleichen Port hören, sondern jede Applikation eben ihren eigenen Port(s) hat. Fhem (mehrere Testinstanzen), Zigbee2MQTT,  Portainer,  Unifi und Pihole laufen dort alle und erfolgreich.
ZitatAber Hostmodus im Docker ist wie alles sudo im System -> ein dünnes Brett bohren.
Dazu kannst Du mir bestimmt noch etwas lesestoff empfehlen, warum das so ist ? - Ich meine ich habe kein Problem damit, das auf mehrere / andere IPs zu verteilen (hilft ja nur was zu lernen), aber den Grund warum das besser ist, wüsste ich gern :)

ZitatIch habe jetzt nicht verstanden, was Du probierts - aber offenbar versuchst Du immer noch ein Port mehrfach für einen Serverdienst zu verwenden.
Genau deswegen lieber nochmal eine genaue Beschreibung:









System 1System 2System 3
Livesystem Grundlage RaspberryTestsystem Grundlage DockerTestsystem Grundlage Docker
FhemFhem (eigener Docker) Fhem (eigener Docker)
Zigbee2MQTT Separater USB StickZigbee2MQTT Separater USB Stick(eigener Docker) nN
Andere MQTT sachen wie Shelly / Tasmota
Homematic Anbindung
usw

Nun würde ich gern (um zu testen, dass es wirklich geht)  Mit System 1 auf das Zigbee2MQTT vom System 2 zugreifen wollen (z.B. um mehrere Netzwerke zu testen) - Gleichzeitig aber auch um den Umzug vom Raspi auf das Docker vorzubereiten und vorher wirklich ALLES testen zu können.
Ich würde mich am Anfang vielleicht auch zufrieden stellen, wenn ich alle MQTT Nachrichten vom System1 an das System2 weiter zu leiten und dort mit zu verarbeiten (oder andersrum).  Da dort Shelly und Tasmota laufen, wären das zwei Fliegen mit einer Klappe. Oder auch von System 3 die Sachen von 1 und 2 abfragen usw.....

Ich würde eben gern direkt auf die MQTT oder Zibee2MQTT Daten zugreifen wollen, ohne den Umweg über ein zweites FHEM bzw dort einen eigenen Prozess der mit FHEM2FHEM die Daten dann weiter schaufelt. Ich hoffe damit ist es etwas verständlicher.

Wenn noch was unklar ist, immer her damit. Ich bin ja derjenige der Hilfe sucht ;)

Viele Grüße
Andreas

Otto123

Hi,

die entscheidenen Frage: System 1 2 3 bedeutet:

  • 3 mal Hardware oder
  • 1 mal Hardware und zwei docker container?

Ich vermute letzteres ...
Wenn auf deinem Livesystem (also dem Host) der MQTT2_SERVER mit Port1 läuft ?! Kannst du in dem docker im Hostmodus keinen MQTT2_SERVER mit Port1 definieren sondern musst dort Port2 nehmen.

Sind wir soweit einig?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

flummy1978

Aloha,
Zitat von: Otto123 am 18 Mai 2021, 20:33:21
Ich vermute letzteres ...
Wenn auf deinem Livesystem (also dem Host) der MQTT2_SERVER mit Port1 läuft ?! Kannst du in dem docker im Hostmodus keinen MQTT2_SERVER mit Port1 definieren sondern musst dort Port2 nehmen.

Sind wir soweit einig?

Fast  Live System ist das System 1 das auf einem Raspberry Pi installiert ist und damit vollkommen getrennt von System 2 und 3 die jeweils auf einer Diskstation im Docker laufen. Der USB Stick für Zigbee2MQTT für System 2 ist separat im Docker auf der gleichen Diskstation

VG
Andras

Otto123

zur Sicherheit:
ZitatSystem 2 und 3 die jeweils auf einer Diskstation im Docker laufen
zwei getrennte Diskstation ?
Also System 1 2 3 ist getrennte Hardware?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

flummy1978

Zitat von: Otto123 am 18 Mai 2021, 21:04:51
zur Sicherheit:zwei getrennte Diskstation ?
Also System 1 2 3 ist getrennte Hardware?
2 Geräte=
1 RaspberryPi
und
1 Diskstation  auf der mehrere Docker laufen.

War mit System 2 und 3 die JE auf einer diskstation laufen sehr missverständlich ausgedrückt. Sorry.
Aber ignoriere System 3 einfach und betrachte oben einfach nur die ersten beiden Systeme die auf von einander getrennten Hardware laufen ;)

Andreas

Otto123

Also auf der Diskstation mit docker, darfst Du nur jeden Port einmal verwenden - wenn Du die docker container alle im Hostmodus betreibst ;)

zigbee2mqtt ist ein mqtt Client
Auf deinen FHEM Servern willst Du MQTT2_SERVER betreiben. Mit zigbee2mqtt willst Du auf diesen MQTT2_SERVER zugreifen? Also definiere den MQTT2_SERVER mit einem freien Port.
Im FHEM auf System 2 und im FHEM auf System 3 kannst Du nicht den MQTT2_SERVER mit gleichen Port definieren!!!

Ob der Port den Du verwenden willst findest Du auf der Diskstation im Terminal mit z.B.
ss -lntu
Wobei ich keine Diskstation habe und nicht weiß, welche Tools dort verfügbar sind.

Beim zigbee2mqtt trägst Du den Server:port ein, den Du verwenden willst. entweder den auf system 1 oder den auf system 2

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

flummy1978

Zitat von: Otto123 am 18 Mai 2021, 22:27:55
Also auf der Diskstation mit docker, darfst Du nur jeden Port einmal verwenden - wenn Du die docker container alle im Hostmodus betreibst ;)

zigbee2mqtt ist ein mqtt Client
Auf deinen FHEM Servern willst Du MQTT2_SERVER betreiben. Mit zigbee2mqtt willst Du auf diesen MQTT2_SERVER zugreifen? Also definiere den MQTT2_SERVER mit einem freien Port.
Im FHEM auf System 2 und im FHEM auf System 3 kannst Du nicht den MQTT2_SERVER mit gleichen Port definieren!!!

Ich glaube so langsam komme ich ein wenig mit ... ich fürchte zwar dass wir immernoch ein wenig an einander vorbeireden aber ich versuche es nochmal zu beschreiben womit ich ein Problem hab:

Das ist das List vom MQTT2_Server auf dem Docker-Fhem das das Zigbee2MQTT auf dem Docker nutzt:
Internals:
   CONNECTS   1
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        52709 global
   FD         9
   FUUID      5fb06b88-f33f-2acb-0283-34428bf182a80c89
   NAME       brok_MQTT2
   NR         21
   PORT       52709
   STATE      Initialized
   TYPE       MQTT2_SERVER
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2021-05-17 21:16:53   RETAIN          {"zigbee2mqtt/bridge/config":"{\u0022commit\u0022:\u00226b32f30\u0022,\u0022coordinator\u0022:{\u0022meta\u0022:{\u0022maintrel\u0022:3,\u0022majorrel\u0022:2,\u0022minorrel\u0022:6,\u0022product\u0022:0,\u0022revision\u0022:20190619,\u0022transportrev\u0022:2},\u0022type\u0022:\u0022zStack12\u0022},\u0022log_level\u0022:\u0022info\u0022,\u0022network\u0022:{\u0022channel\u0022:20,\u0022extendedPanID\u0022:\u00220xdddddddddddddddd\u0022,\u0022panID\u0022:6754},\u0022permit_join\u0022:false,\u0022version\u0022:\u00221.16.1\u0022}","zigbee2mqtt/bridge/state":"online"}
     2021-05-18 22:20:34   nrclients       1
     2021-05-18 22:20:34   state           Initialized
   clients:
     brok_MQTT2_192.168.0.20_55274 1
   retain:
     zigbee2mqtt/bridge/config:
       ts         1621369234.06299
       val        {"commit":"6b32f30","coordinator":{"meta":{"maintrel":3,"majorrel":2,"minorrel":6,"product":0,"revision":20190619,"transportrev":2},"type":"zStack12"},"log_level":"info","network":{"channel":20,"extendedPanID":"0xdddddddddddddddd","panID":6754},"permit_join":false,"version":"1.16.1"}
     zigbee2mqtt/bridge/state:
       ts         1621369234.06299
       val        online
Attributes:
   alias      MQTT Broker
   autocreate simple
   disable    0
   event-on-change-reading RETAIN,state
   group      MQTT
   icon       mqtt
   room       System


Das funktioniert einwandfrei. Ich kann die beiden Zigbee Testgeräte dort bedienen - und wenn ich es mal richtig verstanden hab kann ich über die MQTT GENERIC BRIDGE mal richtig verstehe, damit 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

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

defmod docker_MQTT2 MQTT2_SERVER 52709 192.168.0.20
Kommt folgende Fehlermeldung

docker_MQTT2: Can't open server port at 52709: Cannot assign requested address

Und das verwirrt mich hier total  ???

Bei der Beliebtheit der Zigbee Produkte etc kann ich mir kaum vorstellen, dass ich der Einzige bin, der auf einen entfernten Zigbee Stick zugreifen will, das nicht auf der gleichen Hardware läuft. Ich fürchte nur, dass ich Dir mit dem Missverständnis bei dem Problem die Zeit raube, weil für mich hier nicht der Docker / Port oder was auch immer das Problem darstellt, sondern wie ich es schaffe auf System A Hardware von System B einzubinden ......

Vielen lieben Dank für Deine Zeit und Mühe mir helfen zu wollen (und hoffe natürlich auch, dass sich da noch der ein oder anderer mit dran hängt :D )

VG
Andreas