Offizielles FHEM Docker Basis Image für verschiedene Plattformen

Begonnen von Loredo, 28 Juli 2018, 21:24:57

Vorheriges Thema - Nächstes Thema

Loredo

Zitat von: adnan am 01 April 2019, 17:16:58
Hat jemand Telegram oder alexa-fhem am laufen? Falls ja, funktionieren diese zwei Geräte nach einem Image-Update noch korrekt?


Ja, läuft beides einwandfrei.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

nanocosmos

Guten Abend,

ich bin von meinem Raspi 3 auf einen Mini Server (AMD64) mit Docker umgezogen.
FHEM läuft jetzt stabil im Container, bin mittels Backup vom Raspi umgezogen.
Leider hat Telegram noch Probleme.
Ich vermute es liegt an den fehlenden Ports in Docker.
Welche Ports müsste ich frei geben?

Beste Grüße
Daniel

Loredo

Soweit ich weiß braucht Telegram keine eingehenden Ports.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

nanocosmos

Danke für Deine Antwort!

Ich glaube mittlerweile, dass meine Fhem Config an mehreren Stellen (z.B. bei Telegram) durch den Umzug ein wenig durcheinander geraten ist.
Versuche aktuell den ursprünglichen Zustand wieder herzustellen. [emoji4]

druschba

Hallo,

ich habe das Problem, dass der Docker Container jeden Tag zur selben Zeit neu startet. Das ganze läuft auf einem Synology DS716+.
Angefügt das Log von fhem.
Ich weiß nicht woher dieses shutdown kommt.

Danke.

Druschba


2019.04.05 17:01:03.181 5: Cmd: >{ DockerImageInfo_GetImageInfo(); }<
2019.04.05 17:01:20.203 4: Connection accepted from telnetPort_127.0.0.1_43583
2019.04.05 17:01:20.204 5: Cmd: >shutdown<
2019.04.05 17:01:20.205 5: Starting notify loop for global, 1 event(s), first is SHUTDOWN
2019.04.05 17:01:20.206 5: AptToDate (fhemServerApt) - Notify: $VAR1 = [
          'SHUTDOWN'
        ];

2019.04.05 17:01:20.206 5: npmjs (fhemServerNpm) - Notify: $VAR1 = [
          'SHUTDOWN'
        ];

2019.04.05 17:01:20.206 4: DbLog mysqllog -> ################################################################
2019.04.05 17:01:20.206 4: DbLog mysqllog -> ###              start of new Logcycle                       ###
2019.04.05 17:01:20.206 4: DbLog mysqllog -> ################################################################
2019.04.05 17:01:20.206 4: DbLog mysqllog -> number of events received: 1 for device: global
2019.04.05 17:01:20.207 4: DbLog mysqllog -> check Device: global , Event: SHUTDOWN
2019.04.05 17:01:20.207 5: DbLog mysqllog -> parsed Event: global , Event: SHUTDOWN
2019.04.05 17:01:20.207 5: End notify loop for global
2019.04.05 17:01:20.207 0: Server shutdown
2019.04.05 17:02:06.473 5: Initializing Type Library:
2019.04.05 17:02:06.473 1: Including fhem.cfg
Synology Docker FHEM-Server | 1-wire an RasPi | virtual CCU | 3x HM-CFG-USB-2 an RasPi und Synology| HM-ES-PMSw1-PI | HM-TC-IT-WM-W-EU | HM-CC-RT-DN | HM-LC-Bl1PBU-FM | HM-WDS10-TH-O | DbLog | div. 1-wire Sensoren | FR!TZ DECT 200 | JeeLink | ebusd an WOLF CGB2-20

nanocosmos

Zitat von: nanocosmos am 05 April 2019, 07:19:42
Danke für Deine Antwort!

Ich glaube mittlerweile, dass meine Fhem Config an mehreren Stellen (z.B. bei Telegram) durch den Umzug ein wenig durcheinander geraten ist.
Versuche aktuell den ursprünglichen Zustand wieder herzustellen. [emoji4]
Es funktioniert jetzt wieder mit Telegram und msgDialog, aber es ist sehr langsam. Dauert teilweise 10 Sekunden bis der Bot seine Antwort schickt.
Geht es euch auch so?

Loredo

Zitat von: druschba am 05 April 2019, 19:49:29
ich habe das Problem, dass der Docker Container jeden Tag zur selben Zeit neu startet.


Der Befehl "shutdown" kommt nirgends im Quellcode des Docker Containers vor, von daher muss es eine andere Ursache in deiner Konfiguration geben. Durchsuch doch mal die fhem.cfg nach dem Schlagwort "shutdown", da findest du sicherlich etwas.


Zitat von: nanocosmos am 06 April 2019, 09:09:19
Es funktioniert jetzt wieder mit Telegram und msgDialog, aber es ist sehr langsam. Dauert teilweise 10 Sekunden bis der Bot seine Antwort schickt.
Geht es euch auch so?


Nope. Die Ursache ist sicherlich nicht bei Docker an und für sich zu suchen.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

nanocosmos

Bei mir läuft Telegramm jetzt auch wieder normal.
Hatte eine Stativ IP vergeben und IPV6 wieder deaktiviert. Eines von beiden oder beide zusammen brachten den gewünschten Erfolg.

Ich wollte meine Xiaomi Bluetooth Komponenten demnächst noch integrieren, hat jemand damit schon Erfahrungen gemacht?

Gesendet von meinem MI 9 mit Tapatalk


waschbaerbauch

#263
Hallo Gemeinde :)

Ich wollte meine ESXi Umgebung nun auch mal in Docker packen. Nach anfänglichen Schwierigkeiten wie durchreichen der USB Geräte in den Container und dauerhaft korrekter Zuordnung (/dev/serial/by-path/) der Geräte ohne Serial (nanoCUL mit CH340) wollte ich meine alte Konfiguration (configDB) in den Container bringen. Die Datei selbst ist da auch nicht das Problem, allerdings fehlt mir grad der Groschen an der Mark wieso ich mein fhem nicht als "perl fhem.pl configDB" gestartet bekomme wenn ich auf meinem Zotac IONITX mit Ubuntu 18.04.2 LTS (Server) ein 'sudo docker-compose up -d) starte.

# This is an exmaple Docker Compose file to start your own Docker Stack

version: '2.3'

networks:
    fhem-network:
        driver: bridge
services:
    fhem:
        image: fhem/fhem:latest
        restart: always
        privileged: true
        ports:
            - "8083:8083"
        volumes:
            - "./fhem/:/opt/fhem/"
            - "./etc/init.d/fhem:/etc/init.d/fhem"
            - "/dev/serial/by-path/:/dev/serial/by-path/"
        networks:
            - fhem-network
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
            CONFIGTYPE: configDB
           
        depends_on:
            - "mysql"
            - "mqtt"
    habridge:
        restart: always
        build: habridge
        network_mode: host
        volumes:
            - ./habridge/data/:/opt/habridge/data/
    mysql:
        restart: always
        expose:
            - "3306"
            - "33060"
        ports:
            - "3306:3306"
            - "33060:33060"
        image: mysql/mysql-server:5.7
        volumes:
            - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
            - ./mysql/data:/var/lib/mysql
        environment:
            - MYSQL_RANDOM_ROOT_PASSWORD=yes
        networks:
            - fhem-network

    mqtt:
        restart: always
        expose:
            - "1883"
            - "9001"
        ports:
            - "1883:1883"
            - "9001:9001"
        image: toke/mosquitto
        networks:
            - fhem-network
        volumes:
            - ./mqtt/config/:/mqtt/config/
            - ./mqtt/log/:/mqtt/log/
            - ./mqtt/data/:/mqtt/data/

    nodered:
        restart: always
        expose:
            - "1880"
        ports:
            - "1880:1880"
        image: nodered/node-red-docker:0.18.4
        user: "1000:1000"
        volumes:
            - ./nodered/data/:/data/
        networks:
            - fhem-network
        depends_on:
            - "mqtt"


Mit der Variable 'CONFIGTYPE: configDB' loopt der Container fhem (restarting) und ohne startet er halt als 'perl fhem.pl fhem.cfg' - ich meine das mal in einer sehr rudimentären Version schon mal zum laufen gehabt zu haben, es kann aber auch ein anderer Container - nicht der offizielle von fhem - gewesen sein.

Muss man hier noch - wenn ja wo - in der "/entry.sh start"  etwas anpassen damit es läuft? Einen FHEM Service (Datei) zu erstellen und in den Container zu mounten ist kein Problem, aber er startet ja per default 'perl fhem.pl fhem.cfg' - wo kann man das abstellen/ändern?

Für eine Axt in meinem Wald wäre ich dankbar!

Viele Grüße
Mario

PS: Mit manuellen Änderungen in der 'entry.sh'
#!/bin/bash
#
# Credits for the initial process handling to Joscha Middendorf:
#    https://raw.githubusercontent.com/JoschaMiddendorf/fhem-docker/master/StartAndInitialize.sh

export FHEM_DIR="/opt/fhem"
export SLEEPINTERVAL=0.5
export TIMEOUT="${TIMEOUT:-10}"
export RESTART="${RESTART:-1}"
export TELNETPORT="${TELNETPORT:-7072}"
export CONFIGTYPE="${CONFIGTYPE:-"configDB"}"
export DNS=$( cat /etc/resolv.conf | grep -m1 nameserver | cut -d " " -f 2 )
export FHEM_UID="${FHEM_UID:-1000}"
export FHEM_GID="${FHEM_GID:-1000}"
export FHEM_CLEANINSTALL=1

bekomme ich nun im FHEM Log
2019.04.17 16:13:30.679 1: usb create end
2019.04.17 16:13:30.683 0: Featurelevel: 5.9
2019.04.17 16:13:30.683 0: Server started with 96 defined entities (fhem.pl:19085/2019-04-01 perl:5.024001 os:linux user:fhem pid:282)
2019.04.17 16:13:30.705 3: 00_SIGduino IdList: ### Attribute development is in this version ignored ###
2019.04.17 16:13:30.705 3: 00_SIGduino: IDlist attr whitelist disabled or not defined (all IDs are enabled, except blacklisted and instable IDs):
2019.04.17 16:13:30.707 3: 00_SIGduino: IDlist MS 0 0.1 0.2 0.3 0.4 1 3 3.1 4 6 7 13 13.2 14 15 17 23 25 33 35 41 51 55 65 90 91.1
2019.04.17 16:13:30.708 3: 00_SIGduino: IDlist MU 8 9 13.1 16 17.1 19 21 22 24 26 27 28 29 30 31 32 34 36 37 38 39 40 42 44 44.1 45 46 48 49 50 56 59 60 61 62 64 66 67 69 70 71 72 74 76 79 80 81 83 84 85 86 89 91 92
2019.04.17 16:13:30.708 3: 00_SIGduino: IDlist MC 10 11 12 18 43 47 52 57 58
2019.04.17 16:13:30.708 3: 00_SIGduino: IDlist development protocol is active (to activate dispatch to not finshed logical module, enable desired protocol via whitelistIDs) = 2 72.1 82
2019.04.17 16:13:30.709 3: 00_SIGduino/init: disable receiver (XQ)
2019.04.17 16:13:30.719 3: 00_SIGduino/init: get version, retry = 0
2019.04.17 16:13:30.748 2: 00_SIGduino: initialized. v3.3.3
2019.04.17 16:13:30.758 3: 00_SIGduino/init: enable receiver (XE)
2019.04.17 16:14:50.012 1: reload: Error:Modul 98_configdb deactivated:
configDB.pm did not return a true value at ./FHEM/98_configdb.pm line 9.
BEGIN failed--compilation aborted at ./FHEM/98_configdb.pm line 9.

2019.04.17 16:14:50.012 0: configDB.pm did not return a true value at ./FHEM/98_configdb.pm line 9.
BEGIN failed--compilation aborted at ./FHEM/98_configdb.pm line 9.



PPS: Nach starten des Containers ist mir nun aufgefallen wenn ich mit ' sudo docker exec -it dockerfhem_fhem_1 bash' in den Container gehe im '/' die folgende 'entry.sh' bekomme - woher kommt denn die?

root@8080a216d62f:/# cat entry.sh
#!/bin/bash
#
#       Credits for the initial process handling to Joscha Middendorf:
#    https://raw.githubusercontent.com/JoschaMiddendorf/fhem-docker/master/StartAndInitialize.sh

export FHEM_DIR="/opt/fhem"
export SLEEPINTERVAL=0.5
export TIMEOUT="${TIMEOUT:-10}"
export RESTART="${RESTART:-1}"
export TELNETPORT="${TELNETPORT:-7072}"
export CONFIGTYPE="${CONFIGTYPE:-"fhem.cfg"}"
export DNS=$( cat /etc/resolv.conf | grep -m1 nameserver | cut -d " " -f 2 )
export FHEM_UID="${FHEM_UID:-6061}"
export FHEM_GID="${FHEM_GID:-6061}"
export FHEM_CLEANINSTALL=1

thotti70

Hallo Allerseits,

als erstes einmal ein dickes Lob.
Habe inzwischen in kürzester Zeit meinen RaspPi gegen das Docker-Image ausgetauscht.
Läuft super, inklusive z.B. Alexa in der neuen Version.

Ein Problem habe ich allerdings, da ich Anfänger im Bereich Docker bin, ist es sicherlich dort angesiedelt.
Ich habe einen zweiten Container als Test FHEM erstellt und dachte eigentlich, dass zwischen den Containern (Produktiv / Test) keine Beeinflussung existieren sollte.
Habe aber den Effekt, wenn ich mein Testsystem stoppe, mein fhem in der Produktivumgebung neu startet.

Das ganze läuft auf einer Synology, die eingebundenen Verzeichnisse (opt/fhem) sind nicht die gleichen.
Hat jemand eine Idee, woraus diese Beeinflussung resultieren kann?
Muss man evtl. "environment variables" zwingend unterschiedlich setzen? (für den Telnet-Port habe ich das getan, auch fhem verwendet unterschiedliche Ports)

Bin für Anregungen dankbar.

Danke und Gruß
Thotti70

ulli


thotti70

Das war auch meine Vermutung.
Daher ist Telnet, 8083 usw. beim Testsystem auf andere Ports gelegt.
Ich sehe da keine Überschneidungen.  ???

Keine Ahnung ob UID oder GID, welche ich ja per environment Variable beeinflussen kann, einen Einfluss haben.
Da fehlt mir halt die Dockererfahrung.

VG


plin

Wie sehen die beiden docker Commandlines aus mit denen du die beiden Instanzen angelegt/gestartet hast?
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

thotti70

Hmm,
das ist ein Problem  :-\
Bei Synology habe ich das über die grafische Oberfläche erledigt.
Was sonst mit -v und -e per command line erledigt wird, kann man hier grafisch machen.
Da bin ich im Moment wirklich blind mit verbundenen Augen unterwegs.

link611

Guten Morgen und Frohe Ostern,

ich habe vor 2 Tagen das Docker Image mal wieder aktualisiert und seit dem kann mein FHEM das dockerimageinfo-Modul nicht mehr laden...

Ein erneutes erstellen des Containers bringt leider auch nichts...

Kann ich das Modul denn nachträglich irgendwo herbekommen?