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.

[roemi]

Hallo und nein, du trittst mir nicht zu nahe und ja, ich taste mich langsam ran an das Thema.
Nochmal mein Problem:
Beide Container, Fhem und z2m, liegen im gleichen Docker Netz.
Ich muss aber leider in die configuration.yaml vom z2m Container immer die exakte Container IP vom Fhem Container angeben damit dieser startet.

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
Wenn aber Docker kompl. neu gestartet wird, vergibt das Management von Synology Docker den Containern neue IPs.
In folge dessen startet der z2m Container erst wenn ich die IP angepasst habe.
Gemeint sind damit die IPs im Docker Netz
Es funktioniert nicht den Namen des Fhem Container oder die Gateway IP zu nehmen.
Portainer werde ich installieren und mir anschauen.

Danke Euch und ich bin für jede Hilfe/Idee dankbar

Römi

[juemuc]

Hallo Römi,

hier ein Beispiel, wie du in Portainer die IP-Adresse des Containers festlegen kannst. Zu dem Thema gibt es viele gute youtube-Anleitungen.
Du darfst diesen Dateianhang nicht ansehen.

Viele Grüße
Jürgen

[Otto123]

Hi,

also ich nehme z.B. in der docker-compose.yml

Code Auswählen Erweitern

- SONOS2MQTT_MQTT=mqtt://fhem:1883Ich vergebe immer containernamen:

Code Auswählen Erweitern

  fhem:
    container_name: fhem
    image: fhem/fhem:latestIch bin mir jetzt nicht ganz sicher und finde die Stelle in der Doku nicht. Aber ich meine im (default) container network geht die Namensauflösung mit container- (und ev. sogar mit service- ) namen. Allerdings nur innerhalb eines docker netzwerkes / Stacks
Beispiel, ping auf den deconz Container:

Code Auswählen Erweitern

docker exec -i fhem bash -c "ping deconz"
Gruß Otto

[roemi]

@juemuc: Ich drücke mich evtl. falsch aus. Leider weiß ich aber auch nicht wie ich es besser erklären kann. Meine Container sind von außen erreichbar. Mir geht es einzig um die Kommunikation unter den Container selbst. Und hier auch nur um zwei Container. Nämlich fhem und z2m.

"Hallo" @Otto  : An sich haben die Container Namen und z.B. die Datenbank spreche ich auch über diesen an. Läuft problemlos. Die Docker interne IP kann dabei lauten wie auch immer sie will. Synology empfiehlt auch für die Kommunikation der Container untereinander den Namen zu verwenden.
Koenkk empfiehlt "If you run the MQTT-Server on the same host (localhost) you could use the IP of the docker0 bridge to establish the connection: server: mqtt://172.17.0.1"
Aber beides will nicht funktionieren.

Da mein Fhem Container den irren Namen fhem-fhem-minimal-1 hat, habe ich schon überlegt ob z2m damit nicht zurechtkommt. Das wäre dann aber auch wieder ein seltsame Sache denn der xampp Container trägt den Namen tomsik68-xampp-1 und ist, wie gesagt, darüberansprechbar.


Ich habe Portainer installiert und werde damit ein wenig spielen/testen.

Römi

[Otto123]

Du betreibst den MQTT auf dem Host und nicht im docker?

[roemi]

Doch, im Docker. 
Opps ... ich meinte natürlich das die Container nur innerhalb einer Docker bridge per Name ansprechbar sind.

RÖmi

[roemi]

Vielleicht wird das ganze so etwas verständlicher
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen. 

[kadettilac89]

@juemuc: Ich drücke mich evtl. falsch aus. Leider weiß ich aber auch nicht wie ich es besser erklären kann. Meine Container sind von außen erreichbar. Mir geht es einzig um die Kommunikation unter den Container selbst. Und hier auch nur um zwei Container. Nämlich fhem und z2m.

"Hallo" @Otto  : An sich haben die Container Namen und z.B. die Datenbank spreche ich auch über diesen an. Läuft problemlos. Die Docker interne IP kann dabei lauten wie auch immer sie will. Synology empfiehlt auch für die Kommunikation der Container untereinander den Namen zu verwenden.
Koenkk empfiehlt "If you run the MQTT-Server on the same host (localhost) you could use the IP of the docker0 bridge to establish the connection: server: mqtt://172.17.0.1"
Aber beides will nicht funktionieren.

Da mein Fhem Container den irren Namen fhem-fhem-minimal-1 hat, habe ich schon überlegt ob z2m damit nicht zurechtkommt. Das wäre dann aber auch wieder ein seltsame Sache denn der xampp Container trägt den Namen tomsik68-xampp-1 und ist, wie gesagt, darüberansprechbar.


Ich habe Portainer installiert und werde damit ein wenig spielen/testen.

Du musst das Attribut "container_name" setzen, dann hast du keine "komischen" Namen mehr. Wenn Synology selbst keine komischen Dinge macht kennen sich die Contanier am Namen ohne dass du irgenwelche IP setzen musst wie schon geschrieben. Wenn du aktuell den MQTT auf dem Host laufen hast (was bis jetzt nicht klar kommuniziert wurde) würde ich den in einen Container verfrachten. EMQX ist z. B. ganz nett, da eine Oberfläche dabei ist mit der du alles konfigurieren kannst. Im Anschluss überall nur noch Hostnamen und keine IP mehr.

Ich würde Zigbee2Mqtt und Fhem im selben Netz lassen, dann kennen sich die hosts und du brauchst keine IP.

[roemi]

Hallo,

z2m läuft nicht auf dem Host sonder auch im Container und in der gleichen bridge wie fhem.

Aber wichtiger, wie darf ich das verstehen mit dem Attribut "container_name" verstehen. Ist das was anderes als der Containername (s. Anhang)
Du darfst diesen Dateianhang nicht ansehen.
Und setzte ich das als Umgebungsvariable?

Römi

[Otto123]

wie darf ich das verstehen mit dem Attribut "container_name" verstehen.

oben ist ein Auszug meiner docker-compose.yml - aber die hast Du wohl nicht auf der syno?

[kadettilac89]

Hallo,

z2m läuft nicht auf dem Host sonder auch im Container und in der gleichen bridge wie fhem.

Aber wichtiger, wie darf ich das verstehen mit dem Attribut "container_name" verstehen. Ist das was anderes als der Containername (s. Anhang)

Und setzte ich das als Umgebungsvariable?

Römi

Das ist die Sicht von Synology. Ob das an Docker durchgereicht wird sieht man da nicht. Wie sieht die yml-Datei aus? Du hattest vonhin mal MQTT gepostet. Zeige das mal von Fhem. Wo das in Synology gesetzt wird weiß ich nicht. In der yml-DAtei wäre es der Parameter Container_name wie geschrieben. Sieht bei mir so aus ... zumindest ein Auszug davon.

Code Auswählen Erweitern

    fhem:
        image: ghcr.io/fhem/fhem-minimal-docker:4.0.0-beta7-bullseye
        container_name: fhem
        restart: always


Das hier vom Fhem-Container. Bei mqtt ist das Attribut nicht zu sehen.

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


[Otto123]

Da mein Fhem Container den irren Namen fhem-fhem-minimal-1 hat,

Das kommt daher, dass Du ihn nicht vergeben hast. Er wird dann aus dem Pfad für die docker-compose.yml Datei und dem Servicenamen und einer laufenden Nummer gebildet.

[roemi]

Ich komme gerade vom Spanier und habt lecker Tapas und Wein hinter mir.
Davor habe ich kurz, veranlasst durch die drei letzten Posts, nach den yml Datei gesucht bzw. recherchiert. Augenscheinlich suche nicht nur ich, sondern auch andere Synology Nutzer danach.
Aber ... ich bin auf den von mir stets ignorierten Punkt "Projekte" gestoßen.
Hier kann ich Container manuell anlegt und damit ergibt "passibe" erster Post für mich Sinn.
Ich werde im laufe der nächsten Tage einen Docker Container manuell anlegen und dabei alles berücksichtigen was genannt wurde.
Kann ja nur gut gehen und schlechter kann es nicht werden.

Danke Euch und ich melde mich frohlockend oder verzweifelt.

GN8

Römi

[roemi]

Frohe Ostern!!!

Ich habe nun einen Container mit folgender manuell angelegter cpmpose.yaml gestartet (und er läuft auch)

Code Auswählen Erweitern

version: '2'
services:
    fhem:
        container_name: fhemtest3
        image: fhem/fhem-minimal:latest
        hostname: fhemtest3
        ports:
            - "8084:8083"
        volumes:
            - /volume1/docker/fhem-test3:/opt/fhem
        environment:
            - LOGFILE=./log/fhem-%Y-%m.log
            - FHEM_PERM_DIR:0754
            - FHEM_PERM_FILE:0644
            - UMASK=0033
            - TZ=Europe/Berlin
            - TELNETPORT=7072
        network_mode: bridge
        restart: 'always'
Folgende Ergebnisse haben die Abfragen gebracht:

Code Auswählen Erweitern

michael@NAS101:~$ sudo docker container inspect fhemtest3 | grep --after 3 DNSNames

michael@NAS101:~$ sudo docker container inspect fhemtest3 | grep --after 3 IPAddress
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "a27ebc91bafcc4614eb8ca5c33dcf0955c299ccadd8b6be1f511f039a2777269",
            "Gateway": "172.17.0.1",
--
            "IPAddress": "172.17.0.5",
            "IPPrefixLen": 16,
            "IPv6Gateway": "",
            "MacAddress": "02:42:ac:11:00:05",
--
                    "IPAddress": "172.17.0.5",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                   
michael@NAS101:~$ sudo docker container inspect fhemtest3 | grep --after 3 hostname
        "HostnamePath": "/volume1/@docker/containers/babb3260b5b6b50325a3276f270c755d9bb8832274d158b2ed16882c761c26ec/hostname",
        "HostsPath": "/volume1/@docker/containers/babb3260b5b6b50325a3276f270c755d9bb8832274d158b2ed16882c761c26ec/hosts",
        "LogPath": "/volume1/@docker/containers/babb3260b5b6b50325a3276f270c755d9bb8832274d158b2ed16882c761c26ec/log.db",
        "Name": "/fhemtest3",

michael@NAS101:~$ sudo docker exec koenkk-zigbee2mqtt-1 nslookup fhemtest3.
Server:        192.168.178.1
Address:    192.168.178.1:53

** server can't find fhemtest3.: NXDOMAIN

** server can't find fhemtest3.: NXDOMAIN
Das heißt aber doch, das z2m den Namen noch immer nicht auflösen kann und ich folgerichtig kein Schritt weiter bin.
Oder bin ich jetzt zu pessimistisch?
Das alles live auszuprobieren geht erst am Dienstag wenn die Chefin nicht im Haus ist.

Römi

[Otto123]

fhemtest3.

Das mit dem Punkt wird nicht gehen

Probier mal ein:

Code Auswählen Erweitern

docker exec -i koenkk-zigbee2mqtt-1 bash -c "ping fhemtest3"

[roemi]

Hallo Otto,

bash is nicht, habe es daher mit sh gemacht

Code Auswählen Erweitern

michael@NAS101:~$ sudo docker exec -i koenkk-zigbee2mqtt-1 sh -c "ping fhemtest3"
ping: bad address 'fhemtest3'
Mit der compose.yaml ist aber alles i.O.?

Römi

[Otto123]

Bin jetzt nicht sicher, aber sind die im gleichen Netzwerk?

Code Auswählen Erweitern

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' koenkk-zigbee2mqtt-1

Code Auswählen Erweitern

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' fhemtest3Die Namensauflösung mit Container Namen geht nur innerhalb eines docker netzwerkes.

[roemi]

Isch schwör   
Du darfst diesen Dateianhang nicht ansehen.

Code Auswählen Erweitern

michael@NAS101:~$ sudo docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' koenkk-zigbee2mqtt-1
172.17.0.3
michael@NAS101:~$ sudo docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' fhemtest3
172.17.0.5
michael@NAS101:~$


[Otto123]

offenbar macht Synology etwas anders als ein Stino Linux Host - wo es mehr Wissen erfordert 

Ich vermute Synology verwendet einen eigenen DNS Server der speziell konfiguriert werden muss.

[roemi]

Ich habe nun einen zweite fhemtest Container angelegt und einen ping abgesetzt

Code Auswählen Erweitern

michael@NAS101:~$ sudo docker exec -i fhemtest3 sh -c "ping fhemtest4"
PING fhemtest4 (172.20.0.3): 56 data bytes
64 bytes from 172.20.0.3: icmp_seq=0 ttl=64 time=0,201 ms
64 bytes from 172.20.0.3: icmp_seq=1 ttl=64 time=0,165 ms
64 bytes from 172.20.0.3: icmp_seq=2 ttl=64 time=0,185 ms
64 bytes from 172.20.0.3: icmp_seq=3 ttl=64 time=0,172 ms
^C
michael@NAS101:~$ sudo docker exec -i fhemtest4 sh -c "ping fhemtest3"
PING fhemtest3 (172.20.0.2): 56 data bytes
64 bytes from 172.20.0.2: icmp_seq=0 ttl=64 time=0,135 ms
64 bytes from 172.20.0.2: icmp_seq=1 ttl=64 time=0,119 ms
64 bytes from 172.20.0.2: icmp_seq=2 ttl=64 time=0,180 ms
^C
und

Code Auswählen Erweitern

michael@NAS101:~$ sudo docker exec fhemtest4 nslookup fhemtest3
Server:        127.0.0.11
Address:    127.0.0.11#53

Non-authoritative answer:
Name:    fhemtest3
Address: 172.20.0.2

Sollte es notwendig sein die Container manuell zu erstellen?

[Otto123]

meinst Du mit manuell -> docker-compose.yml ? Ich mache es immer so.

[roemi]

meinst Du mit manuell -> docker-compose.yml ? Ich mache es immer so.

Ja, natürlich hast Du Recht.
Zugegebenermaßen habe ich mich mit dem Thema nie beschäftigt und habe bisher Container immer nur mit dem Assistenten erstellt und nicht geglaubt das sich das so unterscheidet.
Das heißt ich werde nun auch den z2m Container so erstellen und checken ob sich das alles so bestätigt.
Interessant ist auch, das ich bei dieser Art der Container-Erstellung den Pfad zu compose.yml bestimmen kann.

Ich danke erstmal allen und werde die nächsten Tage basteln und das Ergebnis berichten.

Römi

[Otto123]

Moin,

ich glaube man könnte festhalten: So speziell ist Synology vielleicht auch nicht, aber wir reden gerade über ein Feature von docker compose!
https://docs.docker.com/compose/networking/

Und es ist wohl weniger der Container Name sondern der Service Name (der bei mir meistens gleich gewählt ist )

Ich habe nicht getestet ob Portainer mit "add Stacks" die gleiche Funktionalität erzeugt.

Gruß Otto

[roemi]

Hallo (von einem etwas am zweifelnden Römi),

die erste zwei Anfragen zeigen, das beide Container in einer bridge wohnen.
Die dritte läßt fhem nach xampp schauen und finden.
Umgekehrt findet xampp in der vierte Anfrage fhem NICHT.
In der fünften Anfrage ein erfolgreicher Ping und in der sechsten wieder nicht.

Code Auswählen Erweitern

michael@NAS101:~$ sudo docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' xamppprod
172.21.0.3

michael@NAS101:~$ sudo docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' fhemprod
172.21.0.2

michael@NAS101:~$ sudo docker exec fhemprod nslookup xamppprod
Server:        127.0.0.11
Address:    127.0.0.11#53
Non-authoritative answer:
Name:    xamppprod
Address: 172.21.0.3

michael@NAS101:~$ sudo docker exec xamppprod nslookup fhemprod
OCI runtime exec failed: exec failed: unable to start container process: exec: "nslookup": executable file not found in $PATH: unknown

michael@NAS101:~$ sudo docker exec -i fhemprod sh -c "ping xamppprod"
PING xamppprod (172.21.0.3): 56 data bytes
64 bytes from 172.21.0.3: icmp_seq=0 ttl=64 time=0,102 ms
64 bytes from 172.21.0.3: icmp_seq=1 ttl=64 time=0,182 ms
^C64 bytes from 172.21.0.3: icmp_seq=4 ttl=64 time=0,116 ms

michael@NAS101:~$ sudo docker exec -i xamppprod sh -c "ping fhemprod"
sh: 1: ping: not found

Hier die Compose-files in denen ich keinen offensichtlichen Fehler finde.

Code Auswählen Erweitern

version: '2'
services:
    xampp:
        container_name: xamppprod
        image: tomsik68/xampp:latest
        hostname: xamppprod
        ports:
            - "3308:3306"
        volumes:
            - /volume1/docker/prod/xampp/htdocs:/opt/lampp/htdocs
        network_mode: bridge
        restart: 'always'

Code Auswählen Erweitern

version: '2'
services:
    fhem:
        container_name: fhemprod
        image: fhem/fhem-minimal:latest
        hostname: fhemprod
        ports:
            - "8084:8083"
        volumes:
            - /volume1/docker/prod/fhem:/opt/fhem
        environment:
            - LOGFILE=./log/fhem-%Y-%m.log
            - FHEM_PERM_DIR:0754
            - FHEM_PERM_FILE:0644
            - UMASK=0033
            - TZ=Europe/Berlin
            - TELNETPORT=7072
        network_mode: bridge
        restart: 'always'
Sieht einer von Euch was da falsch läuft?

@Otto: Wie meinst Du das mit dem Service-Namen der bei Dir immer gleich ist?

Ein dankbarer Römi (der nun zum Grill geht und hofft das wenigstens da alles funzt) 
 
PS.: Es ist aber alles kein Drama! Ich will schließlich nur ein funktionierendes System besser machen.

[Otto123]

Hier die Compose-files in denen ich keinen offensichtlichen Fehler finde.

Der Fehler ist eventuell  die files, es muss das file heißen
Der von mir beschriebene Mechanismus: die container finden sich anhand der service namen - bezieht sich auf: innerhalb einer docker compose Umgebung, also in einem docker-compose.yml file.
Und ich benenne den service und den container bisher immer gleich, deswegen weiß ich nicht genau welcher von beiden zieht. Laut doku aber der servicename.

Das mit hostnamen ist ev. ein zweiter Mechanismus (den ich bisher nicht verwendet habe) - aber Dein Problem jetzt ist simpel

sh: 1: ping: not found

heisst: ping existiert nicht im container

"nslookup": executable file not

dito

[roemi]

aber Dein Problem jetzt ist simpel

Aber das mit dem grillen hat heute super geklappt 

Römi (der beschlossen hat heute nichts mehr zu machen)

Danke!!

[roemi]

Hallo.

der neue mit compose.yml erstellt fhem Container läuft und hat ohne zu murren den Job übernommen!
Der mit compose erzeugte z2m Container ziggt wegen dem Adapter den er angeblich nicht findet und das, obwohl er die gleiche Konfi hat wie der ursprünglich über den Assistenten erzeugte z2m Container.
Nun, es ist also weitgehend der gleiche Stand und der neue fhem-Container wird ebenfalls nicht gefunden und muss mit der IP direkt angesprochen werden.
Ich werde wohl nun einen RPI mit ConBee aufsetzten, dort Docker installieren und damit ein wenig spielen.

Danke für Eure Hilfe und Geduld

Römi

[Otto123]

Hallo Römi,
ich bin nicht sicher deswegen frag ich nach: jetzt beide Container in einer docker-compose.yml oder in zweien?

Gruß Otto

[roemi]

jetzt beide Container in einer docker-compose.yml oder in zweien?

Ahhhhh ... gerade ist bei mir ein Groschen gefallen. Nein, in zweien. Das checke ich dann auch noch mal.
Aber dann muss ich auch erstmal das Thema mit dem Adapter lösen.

Danke

Römi

[kadettilac89]

ich weiß nicht was du alles machst.

in der Demolandschaft von Synology diese Datei hochgeladen, keinerlei Netzwerk konfiguriert, keine weiteren Settings und es läuft. Hosts kennen sich gegenseitig

Code Auswählen Erweitern

version: '3'
services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /volume1/docker/dockerfiles/portainer:/data
    ports:
      - 9000:9000
  - 8000:8000
      - 9443:9443
  debian1:
    image: debian:buster-slim
    container_name: debian1
    restart: unless-stopped
    entrypoint: ["tail", "-f", "/dev/null"]
  debian2:
    image: debian:buster-slim
    container_name: debian2
    restart: unless-stopped
    entrypoint: ["tail", "-f", "/dev/null"]


Code Auswählen Erweitern

ping -c 3 debian2                                                             
PING debian2 (172.20.0.3) 56(84) bytes of data.                                 
64 bytes from debian2.stack_default (172.20.0.3): icmp_seq=1 ttl=64 time=0.109 ms
64 bytes from debian2.stack_default (172.20.0.3): icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from debian2.stack_default (172.20.0.3): icmp_seq=3 ttl=64 time=0.093 ms                                                                             
--- debian2 ping statistics ---                                                 
3 packets transmitted, 3 received, 0% packet loss, time 5ms                     
rtt min/avg/max/mdev = 0.082/0.094/0.109/0.015 ms                               

# ping -c 3 portainer                                                           
PING portainer (172.20.0.4) 56(84) bytes of data.                               
64 bytes from portainer.stack_default (172.20.0.4): icmp_seq=1 ttl=64 time=0.173 ms                                                                               
64 bytes from portainer.stack_default (172.20.0.4): icmp_seq=2 ttl=64 time=0.098 ms                                                                               
64 bytes from portainer.stack_default (172.20.0.4): icmp_seq=3 ttl=64 time=0.071 ms                                                                               
--- portainer ping statistics ---                                               
3 packets transmitted, 3 received, 0% packet loss, time 2ms                     
rtt min/avg/max/mdev = 0.071/0.114/0.173/0.043 ms                               
                                         
# ping -c 3 debian1                                                             
PING debian1 (172.20.0.2) 56(84) bytes of data.                                 
64 bytes from d75349ffc5ce (172.20.0.2): icmp_seq=1 ttl=64 time=0.018 ms         
64 bytes from d75349ffc5ce (172.20.0.2): icmp_seq=2 ttl=64 time=0.045 ms         
64 bytes from d75349ffc5ce (172.20.0.2): icmp_seq=3 ttl=64 time=0.083 ms                                                                                       
--- debian1 ping statistics ---                                                 
3 packets transmitted, 3 received, 0% packet loss, time 1000ms                   
rtt min/avg/max/mdev = 0.018/0.048/0.083/0.027 ms   


[roemi]

Hallo, ich wollte mich nur kurz melden und mitteilen, das ich z.Z. nicht weitermachen kann.
Sobald wieder Luft ist ...

Danke

[roemi]

Guten Morgen,

nachdem ich mit dem Projekt pausieren musste und nun (nach dem die Terrasse wieder fit für den Sommer, das Gäste WC neu saniert und mein Büro umgezogen sind) habe ich mich gestern Abend frisch und motiviert ans Werk gemacht.
Ich habe die funktionierende Container gestoppt und die über ein compose.yml erstellte fhem und z2m Container gestartet.
Aber egal was ich als MQTT-Server eintrage, der z2m Container schmiert sofort ab. Im Protokoll finden man: Not connected to MQTT Server.
Jede andere Konsultation (Wordpress, Nextcloud mit DB, fhem mit db) funktioniert.
fhem mit z2m funktioniert nur dann, wenn ich die IP von fhem (der MQTT-Server) hart in der configuration.yaml hinterlege.
Ich habe nun beschlossen das dies am z2m Container selbst liegt und checke nach jedem Image Update ob sich was getan hat.

Ich danke Euch für Eure Geduld und werde hier von meinen Erkenntnisse berichten bzw. gegebenenfalls fragen.

Römi

[roemi]

Hallo,

ca. drei Monate später kann ich Euch mitteilen ... es klappt!
Ich habe nun einen eigenen kleinen PC auf dem Docker läuft. Ich kann stoppen, starten und rebooten ... alles läuft wie es soll.
Docker auf der Synology läuft auch noch, aber nur noch für eher unwichtige Container.

Zwischenzeitlich war ich temporäre mit z2m und fhem auf den vorhergehenden RPI umgezogen. Hier allerdings nicht in Docker.

Ich habe mir eigens einen weiteren Dongle geholt um ungestört mit Docker basteln und testen zu können.

Vielen Dank nochmals, ich komme bestimmt mit weiteren fragen um die Ecke.

Römi