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.20Auf 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 addressDadurch 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 SystemZigbee2mqtt:
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 offHab 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
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
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.
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 foreverZitat 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:52709Das zeigt mir, dass es eigentlich erreichbar sein sollte ;)
VG
Andreas
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
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
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
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
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 1 | System 2 | System 3 |
Livesystem Grundlage Raspberry | Testsystem Grundlage Docker | Testsystem Grundlage Docker |
Fhem | Fhem (eigener Docker) | Fhem (eigener Docker) |
Zigbee2MQTT Separater USB Stick | Zigbee2MQTT 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
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
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
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?
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
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
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 SystemDas 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.20Kommt folgende Fehlermeldung
docker_MQTT2: Can't open server port at 52709: Cannot assign requested addressUnd 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
Zitatdefmod docker_MQTT2 MQTT2_SERVER 52709 192.168.0.20
Gibt es einen triftigen Grund, statt global die genaue Adresse anzugeben?
Zitat von: rudolfkoenig am 19 Mai 2021, 12:27:56
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 ?
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.
ZitatWenn 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?
defmod docker_MQTT2 MQTT2_SERVER 52709 192.168.0.20Auf dem Host FHEM?
Hast Du Dir auf dem Host schon mal die Ports angeschaut?
ss -lntu und hast Du einfach mal diesen Befehl mit einem anderen Port (und ohne IP ) versucht? Nur mal so?
Zitatdass 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 ;D ;D ;D
ZitatDu bist höchstens der Einzige der alles auf einem Port reiten will ;D ;D ;D
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.
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 ;D
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).
@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. :-X
Zitatwerden _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.
Wie dem auch sei, Sätze wie
Zitatdass 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?
Zitat[...] - 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?)
Zitat von: rudolfkoenig am 19 Mai 2021, 15:12:24
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...)
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:
ZitatHier 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:
Zitat von: rudolfkoenig am 19 Mai 2021, 14:12:11
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: Zitat von: Beta-User am 19 Mai 2021, 15:15:29
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)
ZitatFrage: 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
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.
mMn bist Du völlig verpolt:
ZitatDamit 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. ;D
Zitat von: Beta-User am 19 Mai 2021, 15:15:29
(Mist, eigentlich wollte ich mich nicht intensiver mit docker rumschlagen, aber insgesamt scheint es interessant zu sein, wenn man mal durchgestiegen ist...)
Ja ;D ;D ;D
Zitat von: Beta-User am 19 Mai 2021, 18:13:33
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 :)
Zitat von: Otto123 am 19 Mai 2021, 18:29:06
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. ;D
Von verpolt würde ich jetzt nicht sprechen, aber bei verpeilt kommen wir der Sache näher ;D ;D
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 :)
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 :)
Zitat von: flummy1978 am 19 Mai 2021, 20:34:59
Vielen Dank für die [...]
War auch von mir nicht böse gemeint :) .
Zitat von: Otto123 am 19 Mai 2021, 20:44:44
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 :)
Na ja, wenn man die Daten von zigbee2mqtt irgendwo anders her abholen will, braucht man eben einen Zugang zu dem MQTT-Server, an den die Daten geschickt werden - und das kann halt immer nur jeweils einer sein... Von daher ist es mit M2C zwar komplexer, aber wie sonst sollen die Daten vom M2S abgeholt werden (vom jeweils anderen FHEM)? (klar, 00_MQTT + eines der "alten" MQTT-Module ginge auch, aber das lassen wir jetzt besser mal außen vor...)
Naja ich dachte erstmal dran das es überhaupt 1 zu 1 geht - rein protokollmäßig.
Ich hatte noch nicht verstanden, das es einen dauerhaften gemeinsamen Betrieb der gesamten Umgebung geben sollte. 2 x zigbee2mqtt und 2 x FHEM.
Wenn es prinzipiell funktioniert kann man ja die Kiste migrieren und gut. So einen 2 zu 2 Betrieb würde ich mir nicht unbedingt zumuten. Da verliert man schnell das eigentliche Ziel aus den Augen ;D
Moinsen,
oh man da muss ich ja einiges wieder gerade rücken ... ich sollte doch wieder mehr mit Smilies schreiben, da kommt Ironie und Spaß besser durch ;)
Zitat von: Otto123 am 19 Mai 2021, 20:44:44
nein -> verpeilt oder verpolt - beides kann man als Beleidigung verstehen. Wollte ich definitiv nicht. Manchmal wähle ich eben übertrieben Worte ;)
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 :)
Schön locker bleiben: WEDER hab ich das als Beleidigung aufgefasst, noch fühle ich mich durch sowas angegriffen. Ich bin Handwerker, arbeite in der Industerie UND komme aus dem Ruhrpott, wenn einer mit nem locker doofen Spruch aus der Hüfte klarkommt, dann sollte ich das sein ;) Alles gut, hab da nichts böse aufgefasst. Du hilfst hier so vielen Menschen, da muss ein lustiger und netter Spruch eh mal drin sein.
Ehrlicherweise bin ich jetzt wirklich etwas verpeilt ;D ;D Was meinst Du mit "Ich meine einfach ein define für den Server" ? Der Define für den Server den ich probiert habe, funktioniert(e) ja so nicht durch den externen Zugriff auf den Docker (wie rudolf ja gesagt hat, KANN es auch an der Abschottung und der Docker IP liegen). Deswegen werde ich wohl
@Beta-Users Ansatz nehmen, weil es am einfachsten scheint, beide z2mqtt in Betrieb zu nehmen und dann nach und nach mit den Geräten einzeln umzuziehen.
@Beta-UserZitat von: Beta-User am 19 Mai 2021, 21:38:16
War auch von mir nicht böse gemeint :)
Siehe obere Erklärung habe ich überhaupt nicht so aufgefasst ;) Ganz im Gegenteil. Ich bin bin MEGA -froh, dass ich hier so eine angeregte Unterhaltung habe und mir jemand bei meinem Problem helfen möchte. Ich war froh, dass Du dort eben kurz und präzise erwähnt hast was ich wo wie einbinden soll und welchen Vorteil das dann hat. Das wiederum ist eine perfekte Anweiseung (man könnte auch Anleitung / Hilfe etc) sagen... Deshalb danke dafür :D
So nachdem alle Klarheiten beseitig sind, kann ich Euch auch sagen, dass ich erst heute Nacht dazu kommen werde, wieder n bisschen daran zu basteln und zu testen
Zitat von: Otto123 am 19 Mai 2021, 23:15:16
Ich hatte noch nicht verstanden, das es einen dauerhaften gemeinsamen Betrieb der gesamten Umgebung geben sollte. 2 x zigbee2mqtt und 2 x FHEM.
Wenn es prinzipiell funktioniert kann man ja die Kiste migrieren und gut. So einen 2 zu 2 Betrieb würde ich mir nicht unbedingt zumuten. Da verliert man schnell das eigentliche Ziel aus den Augen ;D
Deswegen ja weiter oben die Auflistung. Vielleicht hattest Du da ja was übersehen ;)
Zitat von: flummy1978 am 19 Mai 2021, 17:44:30
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.
Vielen Dank für Eure Hilfe bis hierher schon
VG
Andreas
Danke für die Rückmeldung.
Vielleicht noch eine Anmerkung zu dem hier:
Zitat von: Otto123 am 19 Mai 2021, 23:15:16
Wenn es prinzipiell funktioniert kann man ja die Kiste migrieren und gut. So einen 2 zu 2 Betrieb würde ich mir nicht unbedingt zumuten. Da verliert man schnell das eigentliche Ziel aus den Augen ;D
Otto hat völlig recht, auch ich würde versuchen, direkt möglichst mit allem (!) umzuziehen und finde die "nach und nach"-Lösung eher schwierig. Vielleicht machst du dir erst mal ein "Abhängigkeitsbild" (https://forum.fhem.de/index.php/topic,114960.msg1125012.html#msg1125012), damit du einen Überblick bekommst, wie eigentlich die wechselseitigen Abhängigkeiten vieler Definitionen voneinander sind...
Falls es "nur" darum geht, erst mal zigbee2mqtt "verdockert" ans Laufen zu bekommen (und das Haupt-FHEM "komplett" zu belassen), würde ich das nach dem ersten Testen direkt so machen, dass ich den "Hauptstick" samt backup von zigbee2mqtt auf die docker-Umgebung umziehen würde und dann direkt ALLE zigbee2mqtt-Geräte auf dem "alten" System nur noch via M2C holen würde. Erfordert kein langwieriges Umlernen und Verteilen der bisherigen Logiken und müßte stressfrei innerhalb überschaubarer Frist laufen...
Ergänzend zu Beta-Users Zusammenfassung meine Fragen - bitte einfach mit ja oder nein (ich versuche immer noch das Problem aus #1 zu verstehen) antworten:
Wenn Du von Zigbee2mqtt redest, meinst Du Dein MQTT2_Device in FHEM?
Sowohl das Live System und das Docker System, bestehend jeweils aus: FHEM (MQTT2_SERVER, MQTT2_DEVICE "Zigbee2mqtt") und dem zigbee Stick mit dem zigbee2mqtt Dienst, funktioniert jeweils in sich?
Mhmm da habt ihr wohl beide nicht unrecht. Mit einem Schlag umziehen hätte den Vorteil, dass ein "nicht funktionieren" auf dem Docker, wohl einfacher rückgängig zu machen wäre, als ein Teilumzug *grübel* .... das muss ich mir (nach den Tests) noch mal in Ruhe durch den Kopf gehen lassen.
Zitat von: Otto123 am 20 Mai 2021, 10:54:38
Wenn Du von Zigbee2mqtt redest, meinst Du Dein MQTT2_Device in FHEM?
Sowohl das Live System und das Docker System, bestehend jeweils aus: FHEM (MQTT2_SERVER, MQTT2_DEVICE "Zigbee2mqtt") und dem zigbee Stick mit dem zigbee2mqtt Dienst, funktioniert jeweils in sich?
Wenn ich von Zigbee2mqtt rede, dann meine ich damit auch die Umgebung die hier beschrieben ist und entsprechend aufgebaut ist: https://www.zigbee2mqtt.io/
D.h. ja, wie ich schon mehrmals gesagt habe:
Zitat
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)
Also funktioniert jedes System für sich bereits.
Nochmal eine Frage bezüglich
MQTT2_ClientHab das jetzt mal auf die Schnelle auf beiden System eingebunden und getestet und es scheint einfacher zu sein, als gedacht bzw ich hab irgendwo vorher n Denkfehler gemacht. Die Testrichtung Docker ==> Raspi funktioniert, die Signale werden durch gegeben, aber erst nach manuellem Anlegen der readingList. Autocreate funktioniert auf beiden Systemen nicht. Es wird in beiden FHEMs jeweils kein Gerät angelegt auch wenn die Daten aus dem jeweiligen M2C kommen. (Wenn ich neue Geräte Manuell über das Zigbee2Mqtt anlege, wird normal ein Gerät angelegt) sprich:
Der Kontakt ist am Docker angelernt, schickt die Infos an RaspberryPi am Raspberry kommt aber nichts an, solange ich das attr readingList nicht um den entsprechenden Zigbeeeintrag aus dem Docker erweitere. (Ich hab zum Testen erstmal Dinge genommen, die am Hauptfhem angelernt waren, ich aber dort aktuell nicht dringend benötige) .... hat jemand nen Tipp wo ich da genauer nachschauen muss?
Raspilist:
readingList zigbee2mqtt/TK_OG_GZ_fenster:.* { json2nameValue($EVENT) } <<<<<<<<<======= Originaleintrag
zigbee2mqtt/0x00158d0002d72f41:.* { json2nameValue($EVENT) } <<<<<<<<<<<<<<< Hinzugefügter Eintrag aus dem Docker (damit funktioniert dann auch das Schalten vom Docker -> M2C -> Raspi Fhem)
(Auf dem Docker wird auch kein Gerät angelegt (was bei der Menge der Geräte wohl auch erst mal besser so ist ;D ;D ))
List:
Internals:
.attreocr-thresholdlinkquality 36
CID zigbee_TK_OG_GZ_fenster
DEF zigbee_TK_OG_GZ_fenster
DEVICETOPIC TK_OG_GZ_fenster
FUUID 5fabbb8d-f33f-6adc-2f4b-7e000c8afd75a9c3
IODev brok_MQTT2
LASTInputDev MQTT2Client_docker
MQTT2Client_docker_MSGCNT 9
MQTT2Client_docker_TIME 2021-05-20 11:41:19
MSGCNT 10
NAME TK_OG_GZ_fenster
NR 288
STATE <pre>
open
</pre>
TYPE MQTT2_DEVICE
brok_MQTT2_MSGCNT 1
brok_MQTT2_TIME 2021-05-16 12:17:02
.attraggr:
.attreocr:
state
contact
linkquality:10
.attreour:
state
.attrminint:
.userReadings:
HASH(0x4a4a400)
READINGS:
2021-05-03 13:19:44 IODev brok_MQTT2
2020-11-11 11:23:09 associatedWith dev_SYS_zigbee_bridge
2021-05-20 11:41:19 battery 100
2021-05-20 11:41:19 contact false
2020-11-11 11:28:19 delay 5
2021-05-20 11:41:19 linkquality 39
2021-05-20 11:41:24 state open
2021-05-20 11:41:24 timestamp 1621503684.54455
2021-05-20 11:41:19 voltage 3025
Attributes:
DbLogExclude .*
IODev brok_MQTT2
TIMER_announce 7200
TIMER_announcemsg Gästezimmerfenster ist seit 2 Std offen (Sollte geschlossen werden)
TIMER_announcetarget home
alias GZ Fenster
autocreate 1
devStateIcon delay:own-window-delayed@blue closed:fts_window_2w@green open:fts_window_2w_open@red
event-on-change-reading state,contact,linkquality:10
event-on-update-reading state
group Fenster
imageLink /fhem/deviceimages/mqtt2/MCCGQ01LM.jpg
readingList zigbee2mqtt/TK_OG_GZ_fenster:.* { json2nameValue($EVENT) }
zigbee2mqtt/0x00158d0002d72f41:.* { json2nameValue($EVENT) }
room Büro / Gäste
sortby 90
stateFormat <pre>
state
</pre>
userReadings timestamp:.* { time() }p.s. Kann den Rest aber erst heute Nacht testen ... Arbeit wartet da leider auf mich ;(
Zum einen sollte "irgendwo" was ankommen, wenn "autocreate" am M2C aktiv ist (und ein TYPE=autocreate). Vermutlich aber nicht da, wo du vermutest, denn
- das IODev-Attribut müßte geändert werden (sieht nach dem "alten" (internen) Server aus, nicht nach M2C; bitte auch am "bridge-Gerät" checken)
- und M2D-autocreate müßte wissen, dass die "umbenannte" und die "tech"-Id Identisch sind (das ist u.A. der Grund, warum ich "friendly names" für zigbee2mqtt _nicht empfehle_... Arbeitet man nur mit den tech-Names ("0xirgendwas") als "Pseudo-CID", sind die auch über verschiedene Installationen weg einheitlich und können für bridgeRegexp besser genutzt werden).
Ergänzend: Bitte den Wiki-Artikel zu M2C lesen, da steht noch drin, was man (mAn.) ergänzend tun sollte. (Feedback ist wie immer zu den Wiki-Themen ausdrücklich erbeten!)
Ein wesentlicher Unterscheid in der default Einstellung
Attribute | MQTT2_SERVER | MQTT2_CLIENT |
autocreate | simpel | no |
Hey,
sorry dass ich mich jetzt erst melde, hatten privat viel um die Ohren und bin heute erst zum testen gekommen.
Zitat von: Beta-User am 20 Mai 2021, 12:51:34
Zum einen sollte "irgendwo" was ankommen, wenn "autocreate" am M2C aktiv ist (und ein TYPE=autocreate). Vermutlich aber nicht da, wo du vermutest, denn
- das IODev-Attribut müßte geändert werden (sieht nach dem "alten" (internen) Server aus, nicht nach M2C; bitte auch am "bridge-Gerät" checken)
- und M2D-autocreate müßte wissen, dass die "umbenannte" und die "tech"-Id Identisch sind (das ist u.A. der Grund, warum ich "friendly names" für zigbee2mqtt _nicht empfehle_... Arbeitet man nur mit den tech-Names ("0xirgendwas") als "Pseudo-CID", sind die auch über verschiedene Installationen weg einheitlich und können für bridgeRegexp besser genutzt werden).
Das habe ich nun auch öfter gemerkt. Habe zum Glück die Pseudo CID nur bei einigen wenigen Teilen genommen und das ist auch gut so. So kann ich die Sachen auch direkt in der Installation zuordnen und auch in der Datenbank findet sich das Device schneller, wenn man die tech-ID behält. Das werde ich in Zukunft auch befolgen.
Zitat von: Otto123 am 20 Mai 2021, 12:52:00
Ein wesentlicher Unterscheid in der default Einstellung
Kaum macht man es richtig, funktkioniert es auch. Hatte das schon getestet bevor ich hier alles gelesen hatte und genau das war es auch..... Hab im M2C Device auf Raspi autocreate simple eingeschaltet und schon werden die Geräte vom Docker auch auf dem Raspi angelegt. Andersrum hab ich mich nicht getraut, weil ich glaube dass ich den Radikalumstieg machen werde.
Ergänzend noch das List von einem angelegte Gerät, das auf dem Docker-Zigbee2MQTT angelernt ist und per M2C auf das Raspi -Fhem geschickt wird:
Internals:
CFGFN
CID zigbee_0x00158d00033a22bd
DEF zigbee_0x00158d00033a22bd
DEVICETOPIC MQTT2_zigbee_0x00158d00033a22bd
FUUID 60a6db8e-f33f-6adc-4e27-2ce5d22b66473acd
IODev MQTT2Client_docker
LASTInputDev MQTT2Client_docker
MQTT2Client_docker_MSGCNT 565
MQTT2Client_docker_TIME 2021-05-24 14:44:31
MSGCNT 565
NAME MQTT2_zigbee_0x00158d00033a22bd
NR 498059
STATE ???
TYPE MQTT2_DEVICE
.attraggr:
.attreocr:
.*
.attrminint:
READINGS:
2021-05-20 23:58:38 IODev MQTT2Client_docker
2021-05-20 23:58:38 associatedWith dev_SYS_zigbee_bridge
2021-05-24 14:44:31 battery 97
2021-05-24 14:44:31 illuminance 25
2021-05-24 14:44:31 illuminance_lux 25
2021-05-24 14:44:31 linkquality 65
2021-05-24 14:44:31 occupancy false
2021-05-24 14:44:31 voltage 2995
Attributes:
DbLogExclude .*
event-on-change-reading .*
readingList zigbee2mqtt/0x00158d00033a22bd:.* { json2nameValue($EVENT) }
room Verbindungen->Zigbee->DockerEs ist zwar keine MQTT Frage, aber vielleicht hat jemand von euch trotzdem eine IdeeWie würdet Ihr vorgehen (bzw habt Ihr eine Idee) ob es möglich ist, die die Config vom Raspi (inkl entsprechendem Stick) auf den Docker zu übertragen ohne alles neu anzulernen? D.h. ich müsste dem Zigbee2MQTT auf dem Docker alle Einstellungen vom Raspi geben (ID, Geräte username passwort usw) ? Also eigentlich sollte es doch reichen die config.yaml und database.db rüber zu kopieren den Stick umzustecken und es sollte 1:1 übernommen werden oder ? *grübel*
VG
Andreas
Hallo Andreas,
ich habe das noch nicht gemacht, aber hier ist doch ein backup und restore beschrieben? Punkt 6
https://www.zigbee2mqtt.io/getting_started/running_zigbee2mqtt.html
Gruß Otto