Synology Container zusammenspiel fhem und zigbee2mqtt

[roemi]

Hallo,

Ich hatte vor kurzem einen Stromausfall, ganz ganz kurz, aber die Synology war aus und fhem damit auch ... und ich war nicht zu hause.
Meine bessere Hälfte konnte die NAS zwar wieder starten, aber fhem, genauer zigbee2mqtt verweigerten den Dienst.
Daher habe ich mit nun auch eine USV bestellt.
Aber auch hier kann es passieren, das der NAS in den Ruhemodus fährt und die Container beim starten eine neue IP erhalten.
Damit sind wir auch bei meinem Problem.
Sobald Docker dem fhem-Container eine neue IP vergibt, findet der z2m-Container diesen nicht mehr und wird gestoppt.

Auf zigbee2mqtt.io wird der Tipp gegeben, folgendes in die configuration.yaml zu schreiben wenn beide Container in eine bridge laufen "server: mqtt://172.17.0.1".
Das funktioniert leider nicht. Auch nicht wenn ich einen Port angebe.
Auch den Container namentlich zu nennen hat nichts gebracht.

Hier der Part aus meine funktionierenden configuration.yaml

Code Auswählen Erweitern

mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://172.17.0.2:1884
  client_id: zigbee_pi
  keepalive: 60
  reject_unauthorized: true
  version: 4
Hier ein MQTT2_FHEM_Server der Online ist von dem ich aber glaube das er unnötig ist. Ich habe mich aber bisher nicht getraut zu deaktivieren.

Code Auswählen Erweitern

Internals:
   CID        zigbee_901
   DEF        zigbee_901
   FUUID      657b1a3c-f33f-8c96-8176-dd95a3f22f1f1e25
   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_CONN MQTT2_FHEM_Server_172.17.0.3_48554
   MQTT2_FHEM_Server_MSGCNT 5
   MQTT2_FHEM_Server_TIME 2024-03-26 08:27:19
   MSGCNT     5
   NAME       MQTT2_zigbee_901
   NR         47
   STATE      online
   TYPE       MQTT2_DEVICE
   eventCount 5
   READINGS:
     2024-03-23 22:19:58   IODev           MQTT2_FHEM_Server
     2023-12-14 16:07:40   associatedWith  MQTT2_zigbee_pi
     2024-03-26 08:27:19   state           online
Attributes:
   readingList zigbee2mqtt/901/availability:.* { json2nameValue($EVENT) }
   room       Allerlei->System

Dann gibt es noch eine deaktiviere "MQTT2_zigbee_bridge". Deaktiviert weil der Status schon lange auf Error steht.

Und zu guter Letzt ein zweiter Server von dem ich glaube das er der einzig richtig ist.

Code Auswählen Erweitern

Internals:
   CID        zigbee_pi
   DEF        zigbee_pi
   FUUID      657b18f2-f33f-8c96-f9e8-6d57ad09a70aff36
   FVERSION   10_MQTT2_DEVICE.pm:0.279350/2023-09-05
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_CONN MQTT2_FHEM_Server_172.17.0.3_48554
   MQTT2_FHEM_Server_MSGCNT 154
   MQTT2_FHEM_Server_TIME 2024-03-26 19:33:48
   MSGCNT     154
   NAME       MQTT2_zigbee_pi
   NR         46
   STATE      {"state":"online"}
   TYPE       MQTT2_DEVICE
   eventCount 154

   READINGS:
     2024-03-23 22:19:58   IODev           MQTT2_FHEM_Server
    ...
     2024-03-26 08:27:19   state           {"state":"online"}
     2024-03-18 08:07:49   subscriptions   zigbee2mqtt/#
     2024-03-26 19:33:48   type            device_announce

Attributes:
   IODev      MQTT2_FHEM_Server
   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
   getList    networkmap_raw:noArg raw $DEVICETOPIC/bridge/request/networkmap raw
  networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/request/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/config:.* { json2nameValue($EVENT) }
  $DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices
  $DEVICETOPIC/bridge/log:.* log
  $DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'log_') }
  $DEVICETOPIC/bridge/response/networkmap:.* { my $type = $EVENT =~ m/.*,"type":"(raw|graphviz)",.*/ ? $1 : 'networkmap'; $EVENT =~ m/{"data":\{.*"value":"?(.*[^"])"?\},"status":"ok"\}/ ? { $type=>$1 } : {} }
  $DEVICETOPIC/bridge/devices:.* devices
  $DEVICETOPIC/bridge/info:.* info
  $DEVICETOPIC/bridge/groups:.* groups
  $DEVICETOPIC/bridge/event:.* { json2nameValue($EVENT) }
  $DEVICETOPIC/bridge/extensions:.* extensions
   room       Allerlei->System
   setList    log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1
  permit_join:true,false $DEVICETOPIC/bridge/request/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
In diesem Konstrukt steckt irgendwo der Wurm drin.
Wenn jemand weiß, das der MQTT2_FHEM_Server "zigbee_901" tatsächlich unnötig ist, dann würde ich den deaktivieren oder auch löschen.
Evtl. wäre das schon die Lösung. Aber so richtig glauben tue ich das nicht.

Danke für Eure Hilfe

Römi

[roemi]

Ich habe nun einen Server und die Bridge gelöscht und Fhem tut nach wie vor was es soll.
Nur lässt sich die IP noch immer nicht umstellen.

Römi

[passibe]

Du hast zwei Optionen:
1. Den Hostnamen des FHEM-Containers in der configuration.yaml angeben (sauber, keine Ahnung wieso das bei dir vorher nicht funktioniert hat, vermutlich hattest du den falschen Hostnamen)
2. Dem FHEM-Container z.B. im docker-compose file immer dieselbe IP-Adresse zuweisen (mE Pfusch, solange Option 1 möglich ist)

Für Option 1 kannst du entweder den Hostnamen des Containers über das compose-file setzen (googeln) oder du findest ihn über docker inspect:

Code Auswählen Erweitern

sudo docker inspect ha_fhem | grep --after 3 DNSNamesWichtig: Hier nicht die ID des Containers (z.B. 3fd67b2c658b) nehmen, sondern einen der "menschenlesbaren" Namen.

Wenn du den Namen hast, kannst du noch

Code Auswählen Erweitern

sudo docker exec <ID/NAME zigbee2mqtt-Container> nslookup <HOSTNAME FHEM-Container>.ausführen und schauen, ob zigbee2mqtt den Namen auflösen kann.
Wichtig ist hier der Punkt am Ende, also direkt hinter dem Hostnamen – kann sein, dass nslookup sonst z.B. search domains anhängt und dann den Namen nicht auflösen kann.

Hoffe das hilft!

[roemi]

Erst einmal Danke!

Wenn ich abfrage:

Code Auswählen Erweitern

sudo docker inspect fhem-fhem-minimal-2 | grep --after 3 DNSNamesIst das Ergebnis gleich null
Frage ich:

Code Auswählen Erweitern

sudo docker container inspect fhem-fhem-minimal-2 | grep --after 3 DNSNamesDann ebenfalls
Frage ich aber:

Code Auswählen Erweitern

sudo docker container inspect fhem-fhem-minimal-2 | grep --after 3 IPAddress
"SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "d1ac872178fcfe6ccce6c7c8e6712c177c70008cd85815a7fd7c2708594b4c9a",
            "Gateway": "172.17.0.1",
--
            "IPAddress": "172.17.0.2",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "MacAddress": "02:42:ac:11:00:02",
--
                    "IPAddress": "172.17.0.2",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",Nur leider ist da nichts dabei was hilft.

Heißt also, ich muss den DNSNames erst setzen!?
Ich melde mich.

Danke

Römi

[roemi]

Hallo,

ich habe meinem Testcontainer einen Umgebungsvariable DNSNames gegeben und konnte diese dann auch abfragen.

Code Auswählen Erweitern

sudo docker inspect fhemfhemminimaltest | grep --after 3 DNSNames
                "DNSNames=fhemtest"
            ],
            "ConsoleSize": [
                0,
--
                "DNSNames=fhemtest"
            ],
            "Cmd": [
                "start"
Anschließend konnte ich den Test erfolgreich(?) durchführen:

Code Auswählen Erweitern

sudo docker exec koenkk-zigbee2mqtt-1 nslookup fhemtest
Server:        192.168.178.1
Address:    192.168.178.1:53
Mir ist aber aufgefallen, das dieser DNSNames weder in die configuration.yaml, noch nach state.json oder in die database.db geschrieben wird.
Das heißt dann aber auch, das er bei einem Neustart oder oder Update weg wäre.
Richtig?

Römi

[passibe]

Wie startest du den Container? Einfach mit docker run? Oder mit docker-compose?
Je nach dem dann bitte den Hostnamen manuell setzen, das geht nicht über eine Umgebungsvariable.
Siehe hier bzw. für docker-compose hier.

Bei nslookup fehlt hinten der Punkt. Das was du als Ausgabe siehst ist nur, welcher DNS-Server abgefragt wird. Wieso aber dein normaler DNS-Server (Fritzbox) abgefragt wird und nicht der Docker-interne (127.0.0.11) ist mir (noch) unklar.
Eigentlich sollten ja beide Container Teil des gleichen Docker-Netzwerks sein, oder? Bitte das noch überprüfen.

[roemi]

Hallo,

ich starte den Container über den Docker-Manager von Synology.
Und ja, du hast richtig vermutet ... beide fhem-Container sind in unterschiedlichen Netzwerken (bridge).
Das habe ich übersehen.
Ich muss das testen aber auf später verschieden.

Danke Dir

Römi

[roemi]

Hallo,

da ist wieder eins meines Probleme ... kein ausreichendes Englisch für so was.
Und die Besonderheit, das mein Docker auf einer Synology NAS läuft und dort die Verwaltung (scheinbar) etwas anders ist.
Nach meinem Verständnis (welches (sicher) nicht richtig ist) habe ich bei einem Container nur die configuration.yaml zur Verfügung um die Konfigurationen zu sichern. Alles andere wird überschrieben.

Puh ... da muss ich mich tiefer einlesen. 

Römi

[roemi]

So. Nun wieder evtl. ein Stück weiter.
Exportiere ich die Einstellung vom Container, sehe ich darin alles was ich eingestellt habe und was sämtliche Neustarts und Stromausfälle überlebt hat.
Unter anderem auch den DNSNames Eintrag (leider falscher Container in falscher Bridge).

Morgen schließe ich meine USV an. Bei der Gelegenheit werde ich ein wenig mit den Container und den Einstellungen experimentieren.
Es kann ja eigentlich nichts kaputt gehen ... 

Römi

[roemi]

Hallo,
ich habe heute ein wenig erfolglos experimentiert 
Nun haben sich kurzfristig meine Prioritäten verschoben ... meine Frau hat mich erinnert das nun Ostern ist ... 
Und ich habe meine USV in Betrieb genommen und will diese schnellstmöglich in Fhem einbinden.
Dank der USV hoffe ich, das mein IP Problem nicht mehr ganz oben auf der Liste steht.

Ich melde mich aber zeitnahe mit neuen Fragen zum Thema

Danke Dir

Römi

[roemi]

Hallo passibe,

ich habe in einem Terminal eines laufenden Container den Hostname abgefragt und habe die Namen zurückbekommen den ich für den Container bei der Erstellung genutzt habe.
Dann wollte ich mit Nano die notwendige Dateien bearbeiten bzw. mit "-h, --hostname= Container host name" einen neuen Namen vergeben.
Das geht (natürlich) auch nicht. Nano könnte ich nach installieren, bringt aber nichts ... denn wenn ich versuche "etc" mit einem Volumen nach außen zu verknüpfen wird der Container gestoppt. Also würden die Änderung beim nächsten Update überschrieben.

Ich habe gelesen, das man auch eine bridge erstellen kann und dort die IP manuell vergeben kann. Habe ich probiert und festgestellt, das ich zwar bei der Erstellung der bridge alles vergeben kann, aber die Container bekommen trotzdem bei jedem Start eine neue IP zugewiesen. Bringt mich also auch nicht weiter.

Ich bin also nicht wirklich weiter.

Frohe Ostern

Römi

[roemi]

Hallo passibe,

ich habe zwar (bisher) keine Lösung gefunden, aber evtl. einen gangbaren Weg.
Ich habe mich gefragt warum ich immer wieder unterschiedliche IPs bekomme und hoffe korrekt festgestellt zu haben, das liegt daran das ich immer wieder Container zum testen erstelle und bestehende auch mal deaktiviere. Somit muss bei einem Neustart logischerweise die IP Vergabe immer unterschiedlich sein.
Ich habe nun alle Container außer fhem, z2m und die Datenbank in eine andere bridge verschoben und alle neu gestartet.
Die drei genannten haben nun IPs der Reihe nach.
Wenn ich nächste Woche meinen USV Test mache, wird der NAS kompl. neu gestartet und dann sollten diese drei Container wieder die gleichen IP bekommen.

Die Hoffnung stirbt zuletzt

Römi

[juemuc]

Hallo roemi,

warum vergibst du keine feste IP-Adresse, dort wo du sie benötigst? Das geht entweder am DHCP-Server oder am Container im Bereich Netzwerk.

Viele Grüße
Jürgen

[roemi]

Hallo Jürgen,

an welcher Stelle des Synology Docker Manager kann ich einem Container eine feste IP zuweisen?
Und die Container tauchen im DHCP-Server, in meiner Fall eine Fritz!Box, nicht auf. Also kann ich auch dort keine IP vergeben.
Zudem suche ich ja nach einer Möglichkeit zur Sicherstellung der Kommunikation innerhalb eines Docker Netzwerks.

Aber vielleicht liege ich auch falsch.

Römi

[kadettilac89]

Römi, mal ne dumme Frage. Warum überhaupt separate Netzwerke, fixe IP ... ohne dir zu nahe treten zu wollen. Es schein als hättest du nicht so viel Erfahrung mit dem Docker Themen. Du kannst dir die Verwaltung in Synology sparen und stattdessen Portainer nutzen. Da kannst du dann alles schön konfigurieren. Du musst nur Portainer in der Synology Container Verwaltung anlegen, sobald Portainer läuft alle Container dann über Portainer anlegen und konfigurieren. Ich habe keine Synology, du musst nur schaun wo die permanenten DAten dann liegen, vermutlich irgend wie in /volume1/<selbst erstellter Ordner z. B. docker_files>/<Unterordner je Container>

Ich würde Zigbee2Mqtt und Fhem im selben Netz lassen, dann kennen sich die hosts und du brauchst keine IP. Wenn du Zigbee2Mqtt vor Fhem starten willst geht das per "depends on". D. h. Fhem startet erst wenn "depends" läuft.