FHEM Forum

FHEM - Hardware => Server - Linux => Thema gestartet von: Loredo am 28 Juli 2018, 21:24:57

Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 28 Juli 2018, 21:24:57
Hallo,

auf Docker Hub (https://hub.docker.com/r/fhem/fhem/) stehen ab sofort 2 fertige Basis Docker Images für FHEM bereit:
Alle Images werden für unterschiedliche Plattformen angeboten. Derzeit sind dies für Linux:
Die richtige Plattform wird automatisch gewählt, wenn man das Image über das Meta-Repository läd:

docker pull fhem/fhem

Ohne die Angabe eines Tags am Ende wird das "latest" Image geladen. Wenn man hinten ":dev" anhängt, bekommt man entsprechend das andere Image.
Statt über das Meta-Repository zu gehen, kann man auch direkt aus einem der Plattform-spezifischen Repositories das Image laden. Dort stehen dann auch weitere Tags bereit, beispielsweise wenn man eine ganz bestimmte Version fest verwenden möchte statt über die "Rolling Tags" zu gehen.


Der Source Code wird auf Github unter github.com/fhem/fhem-docker (https://github.com/fhem/fhem-docker) verwaltet.


Was bedeutet Basis Image?
Die Idee ist, dass FHEM in dem Image möglichst unverändert ausgeliefert wird und nur solche Voreinstellungen gemacht werden, die für ein Docker Image generell sinnvoll sind. Auf dieser Grundlage kann jeder dann bei Bedarf seine eigenes Dockerfile schreiben und dort "FROM fhem/fhem" als Ausgangslage verwenden. Vermutlich ist das aber selten notwendig, denn Zusatzmodule sind soweit bereits im Image integriert. Sollte etwas fehlen, wird es zentral für alle ergänzt.


Wie benutze ich das Image?
Das FHEM Installationsverzeichnis /opt/fhem wird (sicherlich nicht überraschend für die, die Docker kennen) als eigenes Volume definiert. Man kann also seine bestehende FHEM Installation beim starten des Containers über "-v /pfad:/opt/fhem" mit angeben. Wenn man das nicht tut, dann wird die FHEM Installation nach Zerstörung des Containers gelöscht. Ist das beim Start angegebene FHEM Verzeichnis leer, so wird FHEM dort aus dem Docker Image heraus installiert. Mit dieser Vorgehensweise kann man also seine Grundinstallation starten.


Was bietet das Image?
Neben vorinstallierten Paketabhängigkeiten sind folgende Dinge verfügbar:
Folgende FHEM Einstellungen werden automatisch vorgenommen:
Dabei wird die dnsServer Einstellung bei jedem Neustart automatisch aktualisiert.


Wie kann ich das Image für mein eigenes FHEM Image verwenden?
Wenn du selbst ein FHEM Image baust, dann kannst du dich in die Start und Konfigurationslogik des Basis Images einklinken.
Die folgenden Scripte werden an den entsprechenden Stellen im Ablauf ausgeführt, wenn sie vorhanden sind:
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: chris1284 am 28 Juli 2018, 21:44:09
Sehr gut,  endlich was offizielles. Kann ich GID und UID definieren, im GitHub ist dies nicht dokumentiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: chris1284 am 28 Juli 2018, 21:49:07
Zitat
Das FHEM Installationsverzeichnis /opt/fhem wird (sicherlich nicht überraschend für die, die Docker kennen) als eigenes Volume definiert.
Wie verhält es wenn ich bisher in eine DB logge, ist SQLite/MySQL im Image integriert? Wie Verhält es sich bei Usern mit config-db?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 28 Juli 2018, 22:01:39
Kann ich GID und UID definieren, im GitHub ist dies nicht dokumentiert.

Wenn du einen Vorschlag hast das einzubauen, nur zu.
Habe ich im Developer Image eingebaut.

Wie verhält es wenn ich bisher in eine DB logge, ist SQLite/MySQL im Image integriert?

Es ist ein Basis Image. SQlite als Dateibasierte Lösung funktioniert natürlich direkt. Ansonsten hat ein Docker Image nur einen einzelnen Zweck. Eine MySQL/MariaDB Datenbank gehört in einen eigenen, separaten Container und ist nicht Teil des Images. Eine automatisierte Migration von A nach B ist nicht vorgesehen.

Wie Verhält es sich bei Usern mit config-db?

configDB kann über die Umgebungsvariable CONFIGTYPE beeinflusst werden:

-e CONFIGTYPE=configDB
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rudolfkoenig am 29 Juli 2018, 11:41:08
Zitat
die aktuelle Stable Version von FHEM, zusammen mit der aktuellen Stable Version des Docker Images
Ich weiss nicht genau, was diese Version enthaelt, aber wenn es 5.8 ist, dann bitte es nicht als stable bezeichnen: 5.8 ist nicht mehr oder weniger stabil, als ein durchschnittlicher "nightly". 5.8 ist als Ausgangspunkt gedacht, damit man irgendwo anfangen kann. Siehe auch https://fhem.de/#Download


P.S. Die Voreinstellung fuer updateInBackground ist 1 und fuer nofork ist 0, und es bleibt vermutlich auch dabei.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 29 Juli 2018, 12:35:19

Hi Rudi,


danke für dein Feedback!

Ich weiss nicht genau, was diese Version enthaelt, aber wenn es 5.8 ist, dann bitte es nicht als stable bezeichnen: 5.8 ist nicht mehr oder weniger stabil, als ein durchschnittlicher "nightly". 5.8 ist als Ausgangspunkt gedacht, damit man irgendwo anfangen kann. Siehe auch https://fhem.de/#Download (https://fhem.de/#Download)


5.8 entspricht halt dem letzten Release Tag, genau wie es auch unter fhem.de/#Download der Fall ist. Den Release Zyklus von FHEM generell können wir aber gerne mal in einem anderen Fred besprechen  ;)
Allgemein ist nunmal die Erwartung, dass ich bei einem "latest" Image die letzte offiziell veröffentlichte Version erhalte. Da tue ich mich schwer den SVN Build als "latest" zu bezeichnen (auch wenn die Bezeichnung ggf. aus Entwicklersicht etwas verwirrend scheint, so ist halt der Standard Tag...). Ich wollte auch nicht davon abweichen was man als ZIP/TGZ Download auf der Website bekommt.


Ich kann noch ergänzen, dass der automatische Build sich auf den Tag im FHEM SVN stützt. Wenn du also ein neues Release machst, spiegelt sich das auch entsprechend im Docker Image sofort wieder.


P.S. Die Voreinstellung fuer updateInBackground ist 1 und fuer nofork ist 0, und es bleibt vermutlich auch dabei.


Ja das stimmt. Diese Einstellungen so zu belassen sind jedoch für den stabilen Betrieb als Container in dieser Konstellation unabdingbar, weshalb die Einstellungen, die ein Benutzer evtl. hinterher geändert hat, wieder rückgängig gemacht werden, da der Container ansonsten nicht mehr richtig funktioniert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rudolfkoenig am 29 Juli 2018, 14:29:33
Zitat
Ich wollte auch nicht davon abweichen was man als ZIP/TGZ Download auf der Website bekommt.
Auf der Webseite wird das .tgz mit "starting point for the update process" beschrieben.
latest ist inzwischen 1.5 Jahre alt, und ist keineswegs stabiler, als beta, auch wenn in der Beschreibung auf Docker Hub das suggeriert wird (stable vs. bleeding edge). Nach dieser Beschreibung wird kein Anfaenger beta herunterladen, und die Maintainer duerfen sich mit laengst vergessenen Bugreports herumschlagen.

Nicht falsch verstehen: Ich habe kein Problem mit einer stable Version, wenn jemand sich die Muehe macht, es zu pflegen, und den Leuten zu garantieren, dass es stabil laeuft. Nur ich mach das nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 29 Juli 2018, 14:44:59
Ich verstehe das durchaus. Nur macht es dann überhaupt gar keinen Sinn auf der Website überhaupt irgendeine Datei, die mit einer Version gekennzeichnet ist, zum Download anzubieten.


Ich kann ja gerne die Beschreibung abändern und das Wort "stable" ersetzen, nur ändert es nichts daran, dass es eigentlich auch nach deiner Beschreibung überhaupt gar keinen Sinn mehr macht einem Beginner zu sagen, dass er die Datei fhem-5.8.zip laden soll, aber danach sofort wieder ein "update" machen muss. Ich kann ja verstehen, dass man aus Bequemlichkeit keine aktuelle ZIP Datei auf der Website anbietet, aber einleuchtend ist das nicht gerade.


Also wenn es hier quasi Konsens ist, dass man keine "Beta" Version (mehr) braucht und man stattdessen den tagesaktuellen Entwicklungsstand als "latest" haben möchte: Habe ich nichts dagegen, aber dann muss eben auch klar sein, dass hier genauso Leute um die Ecke kommen mit "da geht was nicht".


Ist damit quasi offiziell gesagt, dass es keine weiteren offiziellen Releases von FHEM mehr geben wird?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rudolfkoenig am 29 Juli 2018, 15:28:32
Zitat
Ist damit quasi offiziell gesagt, dass es keine weiteren offiziellen Releases von FHEM mehr geben wird?
Ich glaube wir haben eine unterschiedliche Auffassung, was 5.7, 5.8, etc ist.

Fuer mich sind das Startpunkte fuer den update, nichts mehr. In diesem Sinne wird auch ein 5.9 geben, hoffentlich demnaechst. Und ich werde die Entwickler bitten, moeglichst keine neuen Features in der Woche zuvor zu implementieren, damit man 5.9 nach dem Herunterladen starten kann. Ich finde sie weiterhin sinnvoll, fuer den seltenen Fall, dass jemand "gestern" im Halbschlaf das halbe Repository geloescht hat, oder ein Modul mit Syntax-Error eingecheckt hat.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: betateilchen am 29 Juli 2018, 15:59:53
wird kein Anfaenger beta herunterladen, und die Maintainer duerfen sich mit laengst vergessenen Bugreports herumschlagen.

Das ist genau der Grund, warum ich vor langer Zeit die Trennung von "stable" und "nightly" auf debian.fhem.de aufgegeben habe und nur noch das nightly ( eigentlich ein "daily", weil 07:55 Uhr morgens nicht mehr nachts ist  8) ) bereitstelle.

Auch ein neues Release 5.9 wird am ersten Tag seiner Veröffentlichung nichts anderes als ein "nightly" sein :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 30 Juli 2018, 17:34:43
Habe den Tag "beta" jetzt in "latest" umbenannt und die Doku im Wording entsprechend angepasst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rudolfkoenig am 30 Juli 2018, 19:02:57
Danke!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 30 Juli 2018, 23:07:51
Auch wenn es hier und im GitHub-Repo mehrfach beschrieben steht, verstehe ich die beiden Tags nicht.

Ich arbeite immer mit dem aktuellen Trunk. Ist das dann der DEV-Tag beim Docker-Projekt?

Ich verstehe die Tags und Branches bei FHEM nicht. Ist natürlich irgendwie offtopic hier. Aber ist nicht jede getaggte Version nach dem Update wieder auf Trunk-Niveau?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 31 Juli 2018, 08:59:51
Ich arbeite immer mit dem aktuellen Trunk. Ist das dann der DEV-Tag beim Docker-Projekt?


Nein. Der Tag bezeichnet nur den Entwicklungsstand für das Docker Image. Unabhängig davon hat jedes Image FHEM auf dem Stand des "Trunk" enthalten.


Aber ist nicht jede getaggte Version nach dem Update wieder auf Trunk-Niveau?


Richtig.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rudolfkoenig am 31 Juli 2018, 09:52:43
Eigentlich sollte:
- trunk die aktuelle Entwicklung enthalten
- in tags jede "veroeffentlichte" Version vermerkt sein, es ist sowas wie ein Stempel, da erfolgt keine Weiterentwicklung
- branches steht fuer jeden frei, der eine abweichende/experimentelle Version bestimmter Module pflegen will

Soweit ich sehe sind in tags einige alte Experimente, die eigentlich ins branches gehoeren, ich habe sie verschoben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 31 Juli 2018, 10:33:24
Ich denke FunkOdyssey hat sich jetzt auf das Git Repository für das Docker Image bezogen.
Um Verwirrung zu vermeiden: Rudi bezieht sich bei seiner Erklärung auf das Subversion Code Repository von FHEM alleine.
Es ist also wichtig zu verstehen, dass es zwei verschiedene Code Quellen sind, die in dem Docker Image zusammengeführt werden.


Das sieht man auch daran, dass ein Docker Image nicht nur die Rolling Tags "latest" und "dev" hat, sondern auch entsprechend der Version aus der Kombination FHEM+Docker (zu sehen/nutzen aber nur in den Plattform-spezifischen Repositories auf Docker Hub, also z.B. fhem/fhem-amd64_linux).
Der Versions-Tag sieht dann so aus:


   5.8-s17052_1.0.1 --> FHEM tagged version + s(=Subversion) + Code revision number; _ als Trennzeichen; Version Tag aus dem Git Docker Repository


Ein Development Image hat auf jeden Fall noch den Zusatz "-dev" hinten dran. In der Regel hat auch ein Development Image dann zusätzlich noch die Git Revision mit drin, sofern die Revision nicht gleichzeitig auch noch einen Version-Tag hat. Also beispielsweise so:


  5.8-s17052_1.0.1-dev --> entspricht tatsächlich auch der aktuellen "latest" Version, da es noch keine Änderungen seit der letzten "latest" Version gab.


Wenn die erste Änderung im Dev-Image vorhanden ist, jedoch noch nicht in "latest" veröffentlicht, sieht ein Development Tag so aus:


  5.8-s17052_1.0.1-1-gXXXXXX-dev --> die erste Nummer hinter dem Versions-Tag (hier 1.0.1) entspricht der Anzahl von Commits seit dem Tag, hier also erstmal nur eine Änderung. Danach kommt das "g" für Git, gefolgt von der Kurzschreibweise für den entsprechenden Commit. Zur besseren Kennzeichnung folgt dann noch am Schluss der Branch, hier immer "-dev".
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 31 Juli 2018, 10:45:40
Danke, euch beiden, für die umfassende Erklärung.
Mir sind die Git&SVN wie auch Tags/Branches/Forks etc. schon (seit Jahren und als Entwickler) bekannt.  😄

Ich hatte bei den Docker-"Varianten" mich gewundert, wie es von FHEM selbst eine DEV-"Variante" geben kann. Nun habe ich den Unterschied aber verstanden.

Ich finde Loredos Docker-Repositories schon recht geil. Ich bin auch echt froh, dass du den Kniff von Joscha Middendorf übernommen hast. Bis dato habe ich mir meine Images selber gebaut. Aber das könnte sich mit der neuen Flexibilität (pre/post-Scripts) jetzt ändern.

Geile Arbeit.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 06 August 2018, 15:45:47
Ich wollte gerade mein eigenes lepresenced-Build auf dein Image umstellen.

Ist das wirklich gewollte, dass deine Docker-Images den Namen der Plattformen enthalten?
homeautomationstack/fhem-lepresenced-amd64_linux
Wäre es nicht übersichtlicher, wenn man dafür eigene Docker-Tags anlegt? Oder gibt es dafür evtl. auch schon ein Meta-Repository?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Morgennebel am 06 August 2018, 17:16:28
Moin,


ist es möglich, vier FHEM-Instanzen parallel auf demselben Server via Docker zu betreiben, die miteinander mit FHEM2FHEM reden?

Ich hätte gerne:


Dabei sollten das Main und DEV/QA-FHEM auf die Daten der beiden anderen FHEMs zugreifen können...

Danke, -MN
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 August 2018, 19:47:43
Das ist absolut möglich, dafür ist Docker prima geeignet. Einfach die entsprechende Anzahl Container starten und so konfigurieren, wie sie für die jeweilige Umgebung sein sollen.
Das wiederum ist dann aber keine Docker Frage mehr.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 17 August 2018, 16:13:53
@Loredo: Dürfte ich noch einmal kurz auf folgenden Post verweisen: https://forum.fhem.de/index.php/topic,89745.msg824810.html#msg824810
Könnte sein, dass du diesen vielleicht übersehen hast. Danke.



Könnte man im DockerHub-Projekt vielleicht einen Link auf das GitHub-Repo setzen?
Dies ist bei vielen Projekten der Fall und ganz hilfreich.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: M.Schulze am 18 August 2018, 08:38:09
Hallo,

Problem wird leider sein, das im Pfad /opt/fhem die persistenten Dateien des Nutzers nicht klar von den FHEM-Dateien aus dem Image getrennt sind. Ein einfaches Update via Image-Tausch (bevorzuge ich) scheint mir hier also nicht machbar zu sein - also zumindest mit diesem "Offiziellen" Image nicht. Vielleicht könnte man FHEM hier generell optimieren damit es nicht jeder selbst machen muss.

MFG
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 18 August 2018, 08:39:58
Wie Rudi erklärt hat, ist das auch nicht die richtige Art, um FHEM zu aktualisieren. Aus dem selben Grund gibt es kein Update über das Debian Paket.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: pipp37 am 18 August 2018, 10:50:50
Docker-Compose:
Vorerst super Arbeit!
Ich wollte mir gerade mal ein neues Image für Fhem bauen und habe deines gefunden.

Du könntest auch ein docker-compose.yml im Git anbieten.

Im Beispiel wird ein eigenes Docker Volume unter /var/lib/docker/volumes für fhem verwendet.

Einen Ordner /docker/fhem anlegen und  die Datei  docker-compose.yml erstellen.

Variante 1: ohne Modifikation mit host_network
version: '2'
volumes:
  files:
    driver: local

services:
  fhem:
    container_name: fhem
    image: "fhem/fhem"
    restart: always
    network_mode: "host"
    volumes:
      - "files:/opt/fhem"

Variante 2: mit Modifikation und host_network
Dabei ein Verzeichnis /docker/fhem/build  anlegen.
Darin die Datei  Dockerfile   erstellen.
FROM fhem/fhem
RUN apt-get update
RUN apt-get install -y mc libmime-lite-perl libsnmp-perl libnet-snmp-perl libsnmp-session-perl libwww-curl-perl snmp
Die fehlenden  Snmp Libs werden hier z.B. nachinstalliert.

/docker/fhem/docker-compose.yml
version: '2'
volumes:
  files:
    driver: local

services:
  fhem:
    container_name: fhem
   
    build: ./build
    restart: always

    network_mode: "host"
    volumes:
      - "files:/opt/fhem"

Der Docker Container wird im Verzeichnis /docker/fhem wie folgt verwaltet.
docker-compose build  # erzeugt/ändert den modifizierten Container der Variante 2
docker-compose up &  # erzeugt und startet den Container
docker-compose down # löscht den Container
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: M.Schulze am 18 August 2018, 11:20:45
Wenn du Docker-Compose nutzt würde ich gleich noch einen File-Container und einen Reverse-Proxy-Container vorsehen. Dann kann man auf einem Server beliebig viele FHEM Installationen gleichzeitig laufen lassen. Macht aber auch so Sinn.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 August 2018, 15:08:31
Ich wollte gerade mein eigenes lepresenced-Build auf dein Image umstellen.

Ist das wirklich gewollte, dass deine Docker-Images den Namen der Plattformen enthalten?
homeautomationstack/fhem-lepresenced-amd64_linux
Wäre es nicht übersichtlicher, wenn man dafür eigene Docker-Tags anlegt? Oder gibt es dafür evtl. auch schon ein Meta-Repository?

Die anderen Images sind derzeit nicht für die breite Öffentlichkeit bestimmt. Sonst stände ja was darüber im ersten Post  ;)
Sie sind deshalb ja auch gar nicht im selben Docker Hub Repository unter hub.docker.com/r/fhem/.

Könnte man im DockerHub-Projekt vielleicht einen Link auf das GitHub-Repo setzen?Dies ist bei vielen Projekten der Fall und ganz hilfreich.

Jaein, den Link habe ich absichtlich nicht publiziert. Ich möchte derzeit nicht, dass unbedarfte Personen zu leicht mit der Nase darauf stoßen, weil ich dazu keine großartigen Fragen beantworten möchte und die anderen Repos - wie oben schon erwähnt - derzeit nicht für die breitere Masse bestimmt sind.
Auch geht es hier im Forum Post um ein FHEM Basis Image. Die anderen Images sind und werden nicht Teil davon sein, da gibt es eine ganz klare Trennung. Aus diesem Grund gibt es auch das Image als "Basis", ich nutze es selbst für weitere Entwicklungen und es ist dabei quasi als "Abfallprodukt" herausgepurzelt.

Im Grunde würden die Sourcen nach github.com/fhem/fhem-docker gehören, aber den Projektnamen hat schon jemand anderes (ungenutzt) belegt.

Du könntest auch ein docker-compose.yml im Git anbieten.

Ich habe eine passende Beispiel docker-compose.yml (https://github.com/docker-home-automation-stack/fhem-docker/blob/master/docker-compose.yml) hinzugefügt und die README (https://github.com/docker-home-automation-stack/fhem-docker#adding-git-for-version-control-of-your-home-automation-docker-containers) auch um eine Beispielanwendung zusammen mit Git als Versionsverwaltung erweitert.


Die fehlenden  Snmp Libs werden hier z.B. nachinstalliert.


Habe ich ins Basis Image mit aufgenommen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Shojo am 24 August 2018, 20:50:24
Ich wollte nur mal ein Danke da lassen.
Das Image ist echt super und man sehr gut darauf seine eigene Installation aufbauen.
Ich habe tatsächlich für den zwitsch von meiner "normalen" Installation auf die Docker 45 min benötigt (mit allen Spielereien und einlesen ;) )

Gruß
Dennis
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 August 2018, 22:15:54
Danke für das Feedback! Freut mich, dass es für dich so einfach lief :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: supernova1963 am 25 August 2018, 10:18:40
Ich wollte ebenfalls mal ein Danke da lassen.
Das Image ist echt super und man sehr gut darauf seine eigene Installation aufbauen.
Ich habe einfach mal unter OS X docker mit Kitematic ausprobiert. Es funktioniert nachdem ich das volume für /opt/fhem mit ~/opt/fhem definiert habe.

Gruß
Gernot

Edit: Mit Ausnahme:
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 03 September 2018, 12:36:12
Hallo,

ich starte FHEM aktuell wie folgt:

    fhem:
        container_name: fhem
        restart: unless-stopped
        cap_add:
            - SYS_ADMIN
            - NET_ADMIN
            - NET_RAW
        expose:
            - "7072"
            - "8083"
        ports:
             - 7072:7072
             - 8083:8083
        privileged: true
        image: fhem/fhem
        volumes:
             - /etc/localtime:/etc/localtime:ro
             - ./data/fhem/:/opt/fhem
        network_mode: "host"
        environment:
            TIMEOUT: 10
            TZ: Europe/Berlin

Heute habe nach in dem "docker-compose up" folgende Fehlermeldungen:

fhem          | /entry.sh: line 87: $(date +"$LOGFILE"): No such file or directory
fhem          | /entry.sh: line 87: $(date +"$LOGFILE"): No such file or directory
fhem          | /entry.sh: line 87: $(date +"$LOGFILE"): No such file or directory
fhem          | /entry.sh: line 87: $(date +"$LOGFILE"): No such file or directory
fhem          | /entry.sh: line 87: $(date +"$LOGFILE"): No such file or directory
fhem          | /entry.sh: line 87: $(date +"$LOGFILE"): No such file or directory
fhem          | /entry.sh: line 87: $(date +"$LOGFILE"): No such file or directory

Zeile 87 (https://github.com/docker-home-automation-stack/fhem-docker/blob/dev/src/entry.sh#L87) ist in der Function "PrintNewsLines".

Das Log ist in entry.sh wie folgt definiert:
LOGFILE="${FHEM_DIR}/log/fhem-%Y-%m.log"
Mein FHEM-Log ist jedoch auf täglich eingestellt: fhem-2018-09-03.log

Aber selber wenn ich ein Dummy-Log anlege, so bleibt der Fehler.

Hat jemand eine Idee?



Nachtrag:
Okay, ich musste die Rechte neu setzen und dann ging es.
Aber ich musste vorher ein "touch fhem-2018-09.log" ausführen.
Könnte man die Syntax der Log-Datei vielleicht per ENV mitgeben? Sonst habe ich spätestens im Oktober wieder ein Problem.

In FHEM will ich es gerne bei täglichen Logs lassen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Shojo am 09 September 2018, 16:33:47
Ich hatte heute mal versucht FHEM auf Synology DSM (x86-64/AMD64) zum laufen zu bekommen...

aber kommen beim Start leider nicht über folgende Fehlermeldung hinaus:
Preparing configuration ...
Starting FHEM ...
su: System error
Unable to start FHEM process - errorcode 1
Hat wer ein Tipp für mich wo ich da ansetzten kann?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Shojo am 11 September 2018, 08:46:56
Keiner ein Tipp für mich was es mit der Fehlermeldung aufsich hat? :(
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 11 September 2018, 08:55:53
Du wist das Problem haben, das keiner Docker auf Synology kennt ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Shojo am 11 September 2018, 09:07:12
Ja das befürchte ich auch, obwohl ich schon diverse (14) Container über docker-compose dort laufen habe.
Habe sonst noch keine Einschränkungen in Vergleich zu Ubuntu feststellen können.

Daher hatte ich die Hoffnung das wer mir was zum Fehler sagen kann. 

Gruß
Dennis
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 11 September 2018, 09:49:18
@Loredo:

Wo hättest du denn gerne "feature requests" oder sonstige "issues" genannt?
Im GitHub-Projekt oder hier im Forum?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 12 September 2018, 15:24:49
Danke, Loredo:
https://github.com/docker-home-automation-stack/fhem-docker/commit/64787727e43111ee4eb84144ee8a12e5f3ca112c
 :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 September 2018, 16:54:08
Requests sind geduldig und besser in Github aufgehoben :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 12 September 2018, 16:55:12
Da gibt es sogar schon welche.  :)
Die finde ich gar nicht mal so schlecht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 16 September 2018, 13:13:06
Ich hatte heute mal versucht FHEM auf Synology DSM (x86-64/AMD64) zum laufen zu bekommen...

aber kommen beim Start leider nicht über folgende Fehlermeldung hinaus:
Preparing configuration ...
Starting FHEM ...
su: System error
Unable to start FHEM process - errorcode 1
Hat wer ein Tipp für mich wo ich da ansetzten kann?

Ich vermute deine docker-compose Definition ist nicht kompatibel. Der su Befehl wird benötigt, um fhem unter nicht-Root Rechten laufen zu lassen:
http://lmgtfy.com/?q=docker+su+%22system+error%22 (http://lmgtfy.com/?q=docker+su+%22system+error%22)

Das Image ist nicht dafür bestimmt das Netzwerk als "Host Networking" zu betreiben. Eine Beispiel docker-compose Datei findet sich hier:
https://github.com/docker-home-automation-stack/fhem-docker/blob/master/docker-compose.yml (https://github.com/docker-home-automation-stack/fhem-docker/blob/master/docker-compose.yml)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 16 September 2018, 13:20:10
  • der Einbindung von USB

Für die Einbindung von USB Geräten muss der Container im Privileged Modus laufen. Das ist aber Docker spezifisch und hat nichts mit dem Image ansich zu tun.
In der docker-compose Beispieldatei (https://github.com/docker-home-automation-stack/fhem-docker/blob/master/docker-compose.yml) sind dazu bereits ein entsprechende Einträge vorhanden, die man nur einkommentieren muss:

# privileged: true
   [...]
# - /dev/ttyUSB0:/dev/ttyUSB0


Ich habe bei mir allerdings alles auf IP laufen und brauche daher kein USB mehr.




Edit:
Habe die Beispiel docker-compose Datei um einige Beispiele aus der Literatur erweitert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Shojo am 16 September 2018, 16:03:06
Ich vermute deine docker-compose Definition ist nicht kompatibel. Der su Befehl wird benötigt, um fhem unter nicht-Root Rechten laufen zu lassen:
http://lmgtfy.com/?q=docker+su+%22system+error%22 (http://lmgtfy.com/?q=docker+su+%22system+error%22)
Danke für den lmgtfy Link, das hatte ich auch ohne  in hinbekommen...
Aber egal das war ja nur ein Test, wollte das eh nicht wirklich auf der Syno laufen lassen.

Das Image ist nicht dafür bestimmt das Netzwerk als "Host Networking" zu betreiben. Eine Beispiel docker-compose Datei findet sich hier:
https://github.com/docker-home-automation-stack/fhem-docker/blob/master/docker-compose.yml (https://github.com/docker-home-automation-stack/fhem-docker/blob/master/docker-compose.yml)
Am "Host Network" komm ich leider nicht drum rum, da ich anderes nicht meine Sonos System ins Fhem eingebunden bekomme.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 16 September 2018, 16:19:17
Ich nutze die ganz aktuelle Version und habe folgende Ausgabe im FHEM-Log:
sort: cannot read: '/image_info.*': No such file or directory
sort: cannot read: '/image_info.*': No such file or directory
sort: cannot read: '/image_info.*': No such file or directory
sort: cannot read: '/image_info.*': No such file or directory
sort: cannot read: '/image_info.*': No such file or directory

Oje. Ich ahne es schon. Die neue 99_DockerImageInfo.pm wird wahrscheinlich gar nicht automatisch eingespielt. Kann das sein? Nachtrag: Ich habe die Version aus dem Repo manuell hochgeladen. Kein Unterschied. Fehler bleibt.



Und es wird scheinbar jedesmal versucht, Telnet hinzuzufügen:

Messages collected while initializing FHEM:
configfile: telnetPort already defined, delete it first
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 16 September 2018, 20:44:42
Am "Host Network" komm ich leider nicht drum rum, da ich anderes nicht meine Sonos System ins Fhem eingebunden bekomme.

Den Sonos Daemon sollte man dafür in einen eigenen Container auslagern. Der Travis Build, resp. ein fertiges Image, dafür steht noch aus.
Das Dockerfile sieht bei mir so aus:

FROM debian:stretch
ENV DEBIAN_FRONTEND noninteractive
ENV TERM xterm

# Install base environment
RUN apt-get update && apt-get upgrade -y && apt-get install -y --no-install-recommends apt-utils
RUN apt-get -y install \
apt-transport-https \
build-essential \
curl \
cpanminus \
dfu-programmer \
etherwake \
git \
netcat \
perl \
snmp \
snmpd \
sqlite3 \
sudo \
telnet \
usbutils \
vim \
wget && \
apt-get -y install \
libwww-perl \
libsoap-lite-perl \
libxml-parser-lite-perl

EXPOSE 4711

WORKDIR "/opt/fhem/FHEM"

CMD perl 00_SONOS.pm 4711 3 1


docker-compose.yml:

  fhem-sonos:
    restart: always
    build: fhem-sonos
    volumes:
      - ./fhem/:/opt/fhem/:ro
    network_mode: host

  fhem-sonos-smb:
    restart: always
    image: dperson/samba
    ports:
      - "445:445"
    environment:
      TZ: "Europe/Berlin"
    volumes:
      - ./fhem-sonos/SonosSpeak/:/mnt/SonosSpeak/
    networks:
      - net
    command: -p -s "SonosSpeak;/mnt/SonosSpeak"

Ich nutze die ganz aktuelle Version und habe folgende Ausgabe im FHEM-Log:

Danke, da fehlte beim Übertrag aus der Shell noch etwas.

Ich ahne es schon. Die neue 99_DockerImageInfo.pm wird wahrscheinlich gar nicht automatisch eingespielt.

Nope, wird aktualisiert.

Und es wird scheinbar jedesmal versucht, Telnet hinzuzufügen:

Messages collected while initializing FHEM:
configfile: telnetPort already defined, delete it first

Absolut, ja. Wird für den Health Check benötigt und daher hinzugefügt, wenn nicht vorhanden bzw. nicht auf 7072 hörend vorhanden.
Wenn du einen anderen Port verwendest, kannst du die Umgebungsvariable TELNETPORT entsprechend anders im Container setzen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 16 September 2018, 21:04:23
Das Problem ist nur, dass jedesmal versucht wird, den Telnet-Zugang hinzuzufügen.
Der Fehlerhinweis multipliziert sich mit jedem Rebuild (oder Restart?).

---

Das Projekt ist auf Docker-Hub ja bereits aktualisiert. Den "image_info"-Bug habe ich aber immer noch:

touch: cannot touch '/image_info.tmp': Permission denied
sort: cannot read: '/image_info.*': No such file or directory
rm: cannot remove '/image_info.tmp': No such file or directory
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 17 September 2018, 11:51:36
Danke für die Rückmeldung. Sollte nun mit dem neuen Build ausgeräumt sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 17 September 2018, 15:29:29
Ja, sieht gut aus. Alle Container aktualisiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Shojo am 17 September 2018, 22:19:38
Den Sonos Daemon sollte man dafür in einen eigenen Container auslagern. Der Travis Build, resp. ein fertiges Image, dafür steht noch aus.
Das Dockerfile sieht bei mir so aus:
......
Danke hat wunderbar geklappt :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: devil77 am 11 Oktober 2018, 09:11:08
Hallo,
ich bekommen bei mir immer folgende Meldung im log
sort: cannot read: '/image_info.*': No such file or directoryWas hat das zu bedeuten? Kommt auch nachdem ich das Dockerfile aktualisiert habe.

Dockerimageinfo sieht so aus
CFGFN     
   CHANGED   
   NAME       DockerImageInfo
   NR         113
   STATE      ok
   TYPE       DockerImageInfo
   READINGS:
     2018-10-11 07:30:31   image.created   2018-10-10T05:08:23+0000
     2018-09-20 11:01:37   image.description A basic Docker image for FHEM house automation system, based on Debian Stretch.
     2018-09-24 11:38:11   image.documentation https://github.com/docker-home-automation-stack/fhem-docker/blob/9e476fccc8df4aa64c7d67a05ac0bf3f763bfcc5/README.md
     2018-09-20 11:01:37   image.licenses  MIT
     2018-09-24 11:38:11   image.revision  9e476fccc8df4aa64c7d67a05ac0bf3f763bfcc5
     2018-09-20 11:01:37   image.source    https://github.com/docker-home-automation-stack/fhem-docker/
     2018-09-20 11:01:37   image.title     fhem-amd64_linux
     2018-09-20 11:01:37   image.url       https://hub.docker.com/r/fhem/fhem-amd64_linux
     2018-09-20 11:01:37   image.vendor    FHEM
     2018-10-11 07:30:31   image.version   5.9-s17498_1.3.0-beta-1-g9e476fc-dev

Docker läuft bei mir auf einem Synology NAS.

Eine weitere Frage habe ich noch zum Health-Check. Wie funktioniert der genau und muss dazu der Telnet Port in Docker nach außen weitergeleitet werden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 Oktober 2018, 12:27:47
ich bekommen bei mir immer folgende Meldung im log
sort: cannot read: '/image_info.*': No such file or directoryWas hat das zu bedeuten? Kommt auch nachdem ich das Dockerfile aktualisiert habe.

Ich habe dafür nochmals einen Fix eingecheckt, sollte damit hoffentlich dann gefixt bleiben.

Der Healthcheck funktioniert rein lokal auf dem FHEM Server innerhalb des Containers, es ist nicht notwendig den Telnet Port von außerhalb des Containers erreichbar zu haben. Das bedeutet, dass sowohl die Definition in FHEM nicht unbedingt "global" sein muss und dass auch keine Portweiterleitung für den Docker Container definiert werden muss.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: hoppel118 am 29 Oktober 2018, 22:37:52
Moinsen,

mit Begeisterung habe ich diesen Thread gefunden, da FHEM das einzige ist, was bei mir noch nicht dockerisiert ist/wurde.

FHEM läuft bei mir auf Openmediavault4 (Debian Stretch).

Folgende Fragen habe ich nun:

1. Werden die Daten in den Container übernommen, wenn ich den Ordner /opt/fhem in die Docker-Config einbinde, so dass ich /opt/fhem danach löschen kann oder ist es danach weiterhin als Config-Verzeichnis erforderlich? Oder soll ich lieber komplett von vorn anfangen und keine Altdaten übernehmen? Das wäre allerdings ziemlich heftig.
2. Soll/muss ich eine Netzwerkbridge konfigurieren oder geht auch Host-Modus? Bin der Meinung, dass ich gerade gelesen hatte, dass nur der Bridge-Modus funktioniert?
3. Ich nutze einen HM-CFG-USB. Wenn ich es richtig verstanden habe, muss ich den Container privilegiert starten. Gibt es dann noch etwas zu beachten?
4. Ich nutze momentan SSL. Funktioniert das auch mit diesem Docker Image? Was muss ich dabei beachten?
5. Ich nutze momentan zusätzlich eine Homebridge. Was sollte ich machen, um Homebridge auch weiterhin nutzen zu können? Brauche ich für die Homebridge einen extra Container oder kriegt man das irgendwie in diesen Container integriert?

Ich hoffe, die Fragen sind nicht allzu dumm. ;) Ich bin aber nicht ganz auf den Kopf gefallen. Habe einige Jahre Linux-Erfahrung. Bei Docker habe ich bisher allerdings lediglich fertige Container-Images installiert und konfiguriert. Der FHEM-Container wird meiner Einschätzung nach etwas aufwändiger.

Danke euch und Gruß Hoppel
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 30 Oktober 2018, 09:11:02
1. Werden die Daten in den Container übernommen, wenn ich den Ordner /opt/fhem in die Docker-Config einbinde, so dass ich /opt/fhem danach löschen kann oder ist es danach weiterhin als Config-Verzeichnis erforderlich? Oder soll ich lieber komplett von vorn anfangen und keine Altdaten übernehmen? Das wäre allerdings ziemlich heftig.


Daten, die innerhalb eines Containers wären, sind nicht persistent. Deshalb braucht es immer ein externes Config Verzeichnis. Du kannst einfach /opt/fhem von deinem Host auch innerhalb des Containers verlinken oder das Verzeichnis auch woanders hin verschieben und von dort in den Container als Volume laden.


2. Soll/muss ich eine Netzwerkbridge konfigurieren oder geht auch Host-Modus? Bin der Meinung, dass ich gerade gelesen hatte, dass nur der Bridge-Modus funktioniert?


Das ist dem Image eigentlich egal, aber getestet und entwickelt wird das Image als Standalone. Docker Images generell im Host Modus zu betreiben ist nicht unbedingt der Grund, warum man Docker verwendet.

3. Ich nutze einen HM-CFG-USB. Wenn ich es richtig verstanden habe, muss ich den Container privilegiert starten. Gibt es dann noch etwas zu beachten?


Das weiß ich nicht, das ist eine Docker spezifische Frage, unabhängig von FHEM. Wahrscheinlich musst du aber auch noch das USB Device durchreichen. Wenn Umgebungen virtualisiert werden, dann ist es prinzipell immer eine gute Idee davon Abstand zu nehmen, Geräte durchreichen zu müssen. Ich empfehle einen Wechsel auf IP-only (z.B. CCU3 über HMCCU Modul).

4. Ich nutze momentan SSL. Funktioniert das auch mit diesem Docker Image? Was muss ich dabei beachten?


Sicher, es gibt nichts spezielles zu beachten, außer dass du alle Dateien eben im /opt/fhem Ordner haben musst, damit sie nicht verloren gehen können.

5. Ich nutze momentan zusätzlich eine Homebridge. Was sollte ich machen, um Homebridge auch weiterhin nutzen zu können? Brauche ich für die Homebridge einen extra Container oder kriegt man das irgendwie in diesen Container integriert?


Das Docker Konzept sieht generell vor, dass für jeden Prozess idealerweise ein eigener Docker Container besteht. Das selbe gilt für Homebridge, insbesondere auch, weil Homebridge tatsächlich im Host Modus betrieben werden muss.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: hoppel118 am 04 November 2018, 00:16:57
Moinsen,

danke erstmal @Loredo für die Antworten. Habe sicher noch einiges zu lernen und zu verstehen im Thema Docker. ;)

Das letzte FHEM Update habe ich vor ca. 8 Monaten durchgeführt, so dass ich das gerade erstmal nachgeholt habe, um mit der Migration zu Docker sauber starten zu können. Nun möchte ich allerdings ein Bisschen abwarten, ob es durch das Update an sich irgendwelche Probleme gibt. Ich habe keine Lust mich nachher durch Fehler zu wühlen, ohne zu wissen, ob diese durch das FHEM Update oder die Docker-Migration entstanden sind. ;)

Ich melde mich wieder.

Viele Grüße Hoppel
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 19 November 2018, 10:44:34
Hallo,
erstmal besten Dank an Loredo.
Bin gerade dabei von meinem Raspberry auf einen HP Thin Client "umzuziehen".
Hat soweit auch gut geklappt, dank der Anleitung im github.
In portainer wird der container allerdings als "unhealty" angezeigt, woran könnte das liegen?

so sieht meine docker compose aus:
# This is an exmaple Docker Compose file to start your own Docker Stack

version: '2.3'

networks:
  net:
    driver: bridge
    # enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/24
          gateway: 172.27.0.1
        # - subnet: fd00:0:0:0:27::/80
        #   gateway: fd00:0:0:0:27::1

services:

  ####
  # HINT: use only ONE of the example "fhem:" service
  # definitions below !
  #


      # CONFIGTYPE: configDB



  # Example to connect USB to the container w/
  # privileged mode (not recommended for security reasons)
  fhem:
    image: fhem/fhem:latest
    restart: always
    privileged: true
    networks:
      - net
    ports:
      - "7072:7072"
      - "8083:8083"
    volumes:
      - "./fhem/:/opt/fhem/"
      - "/dev/ttyUSB0:/dev/ttyUSB0"
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin

Außerdem bekomme backup über bitbucket nicht hin:
holgi@debian:/docker/home$ sudo git push --force --set-upstream origin master
Permission denied (publickey).
fatal: Konnte nicht vom Remote-Repository lesen.

Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
und das Repository existiert.
holgi@debian:/docker/home$
Hatte mich dazu vorher bei bitbucket mit usernamen theholgi angemeldet, was fehlt da wohl noch?







Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 19 November 2018, 21:43:11
In portainer wird der container allerdings als "unhealty" angezeigt, woran könnte das liegen?


Es wird eine Telnet Instanz benötigt, die zumindest auf Localhost hört. Die Instanz wird automatisch angelegt, wenn du  mit einer frischen FHEM Instanz startest. Bei einer bestehenden Instanz musst du das Gerät ggf. manuell hinzufügen:



defmod telnetPort telnet 7072


Außerdem bekomme backup über bitbucket nicht hin:
[...]
Hatte mich dazu vorher bei bitbucket mit usernamen theholgi angemeldet, was fehlt da wohl noch?


Was meinst du mit angemeldet, du meinst lokal von der Linux Shell aus?
Generell gibt es da zwei Möglichkeiten und die hängen davon ab, ob du das externe Repository mit SSH oder per HTTPS eingebunden hast. Beides funktioniert grundsätzlich, wobei SSH wahrscheinlich etwas einfacher ist. Dafür muss dein Linux Benutzer einen SSH Schlüssel erstellt haben und der Public Schlüssel muss bei Bitbucket hinterlegt werden, um den Zugriff zu gestatten. Google sollte dir da helfen:


https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html
https://confluence.atlassian.com/bitbucketserver/ssh-access-keys-for-system-use-776639781.html

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 November 2018, 10:32:18
Zur Info:


Der Source Code für das Docker Image liegt jetzt unter github.com/fhem/fhem-docker (https://github.com/fhem/fhem-docker)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 20 November 2018, 11:20:44
Hallo,
telnet ist definiert. Probleme gibt es wohl mit dem Passwort. Sobald ich ein Passwort in allowed_telnetPort setze kommt der Fehler Login denied via telnetPort_127.0.0.1_34158.
Wenn ich das attr password lösche ist der Fehler weg, die "Farbe"  des state Feldes in portainer wechselt dann von orange zu grün aber healthy steht dennoch da.
Woran könnte das liegen?
Auf dem Raspberry gab es keine Probleme (hatte das komplette backup des Raspberry in das fhem Verzeichnis des "neuen Rechners" entpackt).
Schon erstaunlich das der "Rest" so problemlos funktioniert.

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 November 2018, 11:54:26
telnet ist definiert. Probleme gibt es wohl mit dem Passwort. Sobald ich ein Passwort in allowed_telnetPort setze kommt der Fehler Login denied via telnetPort_127.0.0.1_34158.
Wenn ich das attr password lösche ist der Fehler weg, die "Farbe"  des state Feldes in portainer wechselt dann von orange zu grün aber healthy steht dennoch da.
Woran könnte das liegen?

Der Zugriff von lokal muss ohne Passwort erlaubt sein. Das erreichst du, indem du "globalpassword" statt "password" im allowed Device setzt. Es darf kein Attribut "password" vorhanden sein. Also z.B.:

defmod allowed_telnetPort allowed
attr allowed_telnetPort globalpassword SHA256:AAAAAA:BBBBBBBBBBBBB
attr allowed_telnetPort validFor telnetPort
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 20 November 2018, 12:15:25
Danke für den Tip, jetzt geht es. Das in portainer healthy anstatt running steht ist normal?

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 20 November 2018, 12:16:22
Ja
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 20 November 2018, 13:11:24
Supi,
dann muß ich jetzt nur noch die dashbutten mit dhcp und und den hyperion server ans laufen bekommen.
Habe hier einen dummy erstellt mit dem ich den Raspberry auf dem hyperion läuft herunterfahre:
"ssh pi@192.168.178.62 sudo shutdown -h now" das funktioniert leider nicht aus dem docker container nicht.

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 November 2018, 17:53:20
Ein aktualisiertes Docker Image mit SSH Client Support baut gerade.
Im DockerImageInfo Device stehen dann die Public Keys (Ed25519 + RSA), mit denen sich der Container nach außen hin anmeldet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 20 November 2018, 21:00:36
Das hört sich doch gut an. Dann halte ich die Füße noch ein bißchen still.
Wenn ich es richtig verstanden habe, führe ich ein update des images aus, in dem ich meine noch vorhandene yaml Datei mittels docker-compose up -d nochmals ausführe.
Oder sind noch andere „Schritte“ nötig?

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 November 2018, 23:02:42
Das gehört zum Umgang mit Docker generell und hat nichts kit dem Fhem Image zu tun.

Images werden lokal zwischengespeichert. Man muss sie manuell aktualisieren, damit sie beim anlegen von neuen Containern verwendet werden. Ansonsten bleibt das anfänglich geladene Image im Einsatz.

Für die Verwendung zusammen mit docker-composer, siehe hier:
https://docs.docker.com/compose/reference/pull/
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 22 November 2018, 11:49:04
Da fällt mir jetzt siednheis ein:
Wollte jemand jetzt mein "docker-proxy-nginx" Script haben?

Wobei es wirklich relativ einfach gestrickt ist ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 22 November 2018, 19:16:17
Sowas in der Art ist in Arbeit, zusammen mit einigem anderen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 22 November 2018, 19:34:13
Brauchst Du Tipps?

Habe es per bash gelöst ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 22 November 2018, 21:05:06
Wahrscheinlich nicht, läuft hier schon alles in eine Reihe von Docker Containern aufgeteilt inkl. automatisierter interner PKI. Hab es nur noch nicht geschafft die Images für die Continuous Integration Umgebung (Travis) fertigzustellen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 23 November 2018, 15:09:34
Hallo,
benutzt hier jemand das hyperion modul, um auf einen Hyperion Server zuzugreifen?
Habe Probleme die remote SSH verbindung aufzubauen. Auf dem Hyperionserver läuft Raspian Stretch.
Ich habe die Keys, die in der Dockerinfo von fhem angezeigt werden nach etc/ssh des Hyperionservers kopiert.
Gibt es da sonst noch etwas zu beachten?

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 23 November 2018, 15:14:59
Ich denke mal es liegt am Host Key, der per Default zunächst manuell zu akzeptieren wäre. Dafür musst du dich einmal in dem Container als Benutzer fhem anmelden und manuell einen SSH Verbindung aufgebaut haben. Oder du umgehst due Prüfung des Host Public Key:

https://askubuntu.com/questions/123072/ssh-automatically-accept-keys#123080
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 23 November 2018, 17:31:38
Hm,
wie  melde ich mich als Benutzer fhem am Container an?
(Ich weiß hat jetzt nicht direkt was mit dem image zu tun, bastel hier aber schon seit Stunden ojne Erfolg daran herum).

Gruß Holgi
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 23 November 2018, 18:28:39
Portainer macht das ganz einfach per Klick, ansonsten bringt Google sehr schnell dieses Ergebnis:

https://stackoverflow.com/questions/17903705/is-it-possible-to-start-a-shell-session-in-a-running-container-without-ssh#26496875
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 23 November 2018, 19:41:27
Prinzipiell ja ... nur besser:
docker exec -it "id of running container" /bin/bash
Es ist immer gut, mit exakten Pfaden zu arbeiten. Falls das nicht geht, kann man auch anstatt /bin/bash ein /bin/sh probieren.....

Edit:"to many Fingers on Keybord beseitigt"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 23 November 2018, 20:35:32
docker exec -it "id of running container" /bin/bash

Wenn schon klugscheißen, dann doch aber bitte im richtigen Kontext ;-)

docker exec -ti "id of running container" /bin/su - fhem
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 23 November 2018, 20:43:08
Wenn der Container su hat ;o)

Wollte es einfach mal allgemeiner Schreiben ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 24 November 2018, 10:30:49
Hallo Jungs,
das hat auf Anhieb geklappt.
Besten Dank.
Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: flipkill am 05 Dezember 2018, 08:54:28
Hallo,

bekomme leider mit dem Docker Image Fronthem nicht zum laufen hat jemand auch die Probleme?

Gruß Jan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto am 05 Dezember 2018, 08:59:48
Hi,

was hast du für Fehlermeldungen?

Bei mir läuft alles perfekt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: christian.71 am 05 Dezember 2018, 13:36:48
Ich habe es dank dieses Threads geschafft, dass Sonos soweit wieder eingebunden werden kann. Nun habe ich noch das Problem, dass die Sprachausgabe mittels speak einfach nicht funktionieren will. Im Log steht leider auch keine Fehlermeldung. Wie kann ich noch testen, was mit der Konfig nicht passt.
Meine docker-compose.yml sieht so aus:
    fhem-sonos:
      restart: always
      build: fhem-sonos
      volumes:
        - ./fhem/core/:/opt/fhem/:ro
      network_mode: host

    fhem-sonos-smb:
      restart: always
      image: dperson/samba
      ports:
        - "445:445"
      environment:
        TZ: Europe/Berlin
      volumes:
        - ./fhem-sonos/SonosSpeak/:/mnt/SonosSpeak/
      networks:
        - fhem-network
      command: -p -s "SonosSpeak;/mnt/SonosSpeak"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 05 Dezember 2018, 20:43:04
Hast du denn das Speaker Verzeichnis auch deiner FHEM Instanz zugewiesen und schreibt die die Datei auch da hin?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: christian.71 am 05 Dezember 2018, 22:33:17
Meinst du damit das attr beim Sonos Modul targetSpeakDir und targetSpeakMP3FileDir? Da hab ich jeweils /mnt/SonosSpeak eingegeben. Muss das auch irgenwo in der yml von fhem als volume?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 Dezember 2018, 01:13:50
Selbverständlich
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: christian.71 am 06 Dezember 2018, 10:32:31
volumes:
            - ./fhem/:/opt/fhem/
            - ./fhem-sonos/SonosSpeak/:/opt/fhem/SonosSpeak/

Dies habe ich nun in meiner docker-compose.yml beim Service fhem ergänzt. Die Attribute im Sonos Modul  targetSpeakDir und targetSpeakMP3FileDir habe ich natürlich dementsprechend auf "/opt/fhem/SonosSpeak" angepasst. Allerdings immer noch ohne Erfolg. Er schreibt auch keine Dateien im SonosSpeak Verzeichnis. Die Rechte des Ordners sind auf 777. Was habe ich nur übersehen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 Dezember 2018, 10:45:21
Wenn die Datei gar nicht erst geschrieben wird, dann würde ich den Fehler erstmal in der FHEM Konfiguration bzw der des SONOS Modula suchen. Evtl funktioniert der Zugriff auf den TTS Anbieter ja auch nicht richtig
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 06 Dezember 2018, 11:55:30
Ich hatte damals die gleichen Probleme. Ich habe lange mit dem "command" experimentiert.

Meine Docker-Zeilen zu Samba sehen wir folgt aus:

    samba:
        container_name: samba
        restart: unless-stopped
        ports:
            - "139:139"
            - "445:445"
        image: dperson/samba
        volumes:
             - ./data/SonosSpeak:/mnt/SonosSpeak
        command: samba.sh -S -u "fhem;fhempass" -s "SonosSpeak;/mnt/SonosSpeak;no;no;yes"  -g "security = user" -g "ntlm auth = yes"


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 06 Dezember 2018, 16:25:59
Hallo,
bastel gerade mit dem espeasy Modul herum.
Hatte es früher auf dem Raspberry ohne docker schonmal am laufen.
Habe die espBridge mit port 8383 definiert, kann es sein das der port geblockt wird, so das der esp8266 keine Verbindung zu fhem aufbaut ?
Fhem zu Esp8266 klappt ohne Probleme nur Esp8266 zu fhem nicht.

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 06 Dezember 2018, 16:59:47
Du musst eigentlich nur den Port öffnen.
Mehr habe ich auch nicht gemacht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 06 Dezember 2018, 17:28:45
Hm,
OK in fhem direkt unter allowed_WEB oder wo?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 06 Dezember 2018, 17:37:57
Nein, soweit ich weiß nutzt das ESPEASY-Modul die allowed-Möglichkeiten nicht.

Der Post muss nur im Docker-Container weitergeleitet werden.

        ports:
            - "8383:8383"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 06 Dezember 2018, 17:59:13
OK,
das heißt ich muß den container neu erstellen,
also die docker-compose.yml editieren und dann mit docker-compose build den container neu bauen?
Oder gibt ers eine andere Möglichkeit?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 06 Dezember 2018, 18:00:41
- docker-compose.yml editieren
- docker-compose up -d

Gerne auch vorher Container und Images löschen. Sollte hier aber nicht notwendig sein.

Ich verstehe aber ehrlich gesagt die Frage nicht. So hast du doch deine anderen Ports doch auch geöffnet, oder?
Wie kommst du sonst an 8083 & Co.?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 06 Dezember 2018, 18:03:21
Ja schon, hatte nur gedacht ich könnte den container selbst editieren.
Muß mich da noch ein wenig "einlesen".

Hat so auf jedenfall geklappt.
Danke für die Hilfe
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 06 Dezember 2018, 18:06:26
Damit editiert man ja auch den Container.
Kann das sein, dass du eigentlich das Image meinst? Also eine Änderung bpsw. am Dockerfile? Das ist nicht nötig.
Änderungen an der yml-Datei werden nach einem "docker-compose up -d" direkt im Container übernommen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 Dezember 2018, 20:37:18
Fast: Gilt nicht für Umgebungsvariablen zum Beispiel. Daran muss man denken, ist oft sonst eine lange Fehlersuche :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mrixs am 09 Dezember 2018, 19:18:23
Ich bekomme es auf einer Synology NAS DS415+ nicht im host mode zum laufen. Mit briged Netzwerk läuft es ohne Probleme aber es empfängt keine Multicast Pakete. Hat jemand so eine Version am laufen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Karflyer am 12 Dezember 2018, 19:55:20
Hallo Loredo,

auf die Frage ob man mehrere Instanzen von FHEM in unterschiedlichen Kontainern starten kann, hattest du (einige Posts vorher) geantwortet:

Zitat
Das ist absolut möglich, dafür ist Docker prima geeignet. Einfach die entsprechende Anzahl Container starten und so konfigurieren, wie sie für die jeweilige Umgebung sein sollen.

Das funktioniert ja soweit auch. Aber wie verhält sich das mit der fhem.cfg bzw. fhem.save?
Ich habe beispielsweise zwei Kontainer mit jeweils einer FHEM-Instanz. Die eine lauscht auf Port 8083 die andere auf 8084. Beide greifen auf das gleich gemappte Verzeichnis zu. Ändere ich jetzt etwas in der einen Instanz, dass zu einer Änderung in der fhem.cfg führt, bekommt das die zweite Instanz erst einmal nicht mit. Gibt es eine Möglichkeit beide Kontainer zu 'synchronisieren', oder wie müsste das ganze aufgesetzt werden? Wäre schön, wenn du mir ein paar 'Schlagworte' zu dem Thema nennen könntest.

Gruß
Stefan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 Dezember 2018, 20:23:06
Das kann natürlich nicht funktionieren. FHEM selbst ist nicht dafür gemacht es mit den selben Konfigurationsdateien gleichzeitig mehrfach laufen zu lassen, da auch sehr viel im Arbeitsspeicher stattfindet und die Konfiguration nur beim Start eingelesen wird.

Mit den gleichen Konfigurationsdateien als Kopie (selbe vs. gleiche, ne ;)) geht das natürlich etwas besser. Aber du wirst es niemals schaffen, dass zwei FHEM Instanzen absolut synchron laufen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 13 Dezember 2018, 19:46:15
Hallo,
nach Eingabe docker events:
2018-12-13T19:48:27.968317274+01:00 container exec_create: /bin/sh -c /health-check.sh ec198775da7487380f6ab510cddd88c8732de768a658147bcd8ca904e8e05d1e (com.docker.compose.config-hash=b2b4e2858ad4acbe1a19fe270d5ce08b1ba2a9c859ea3c062e1b69262876e907, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=home, com.docker.compose.service=fhem, com.docker.compose.slug=8b0e18c9b56bab41429f6a7f0fcd05f71a2c48c1114f5d4b06c52de48aca34, com.docker.compose.version=1.23.1, execID=e418ab9785ecbf119657ae6c7da892676eba443ce535b9e895171c26acf074af, image=fhem/fhem:latest, name=home_fhem_1_8b0e18c9b56b, org.fhem.authors=https://fhem.de/MAINTAINER.txt, org.fhem.description=FHEM (TM) is a GPL'd perl server for house automation. It is used to automate some common tasks in the household like switching lamps / shutters / heating / etc. and to log events like temperature / humidity / power consumption., org.fhem.documentation=https://fhem.de/#Documentation, org.fhem.licenses=GPL-2.0, org.fhem.revision=17800, org.fhem.source=https://svn.fhem.de/, org.fhem.url=https://fhem.de/, org.fhem.vendor=FHEM, org.fhem.version=5.9-s17800, org.opencontainers.image.authors=Julian Pawlowski (Forum.fhem.de:@loredo, Twitter:@loredo), org.opencontainers.image.created=2018-11-20T16:51:45+0000, org.opencontainers.image.description=A basic Docker image for FHEM house automation system, based on Debian Stretch., org.opencontainers.image.documentation=https://github.com/fhem/fhem-docker/blob/cb5bd5bf3c9fa64785750be0fe6196d7d1928e46/README.md, org.opencontainers.image.licenses=MIT, org.opencontainers.image.revision=cb5bd5bf3c9fa64785750be0fe6196d7d1928e46, org.opencontainers.image.source=https://github.com/fhem/fhem-docker/, org.opencontainers.image.title=fhem-amd64_linux, org.opencontainers.image.url=https://hub.docker.com/r/fhem/fhem-amd64_linux, org.opencontainers.image.vendor=FHEM, org.opencontainers.image.version=5.9-s17800_1.4.2)
2018-12-13T19:48:27.968562827+01:00 container exec_start: /bin/sh -c /health-check.sh ec198775da7487380f6ab510cddd88c8732de768a658147bcd8ca904e8e05d1e (com.docker.compose.config-hash=b2b4e2858ad4acbe1a19fe270d5ce08b1ba2a9c859ea3c062e1b69262876e907, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=home, com.docker.compose.service=fhem, com.docker.compose.slug=8b0e18c9b56bab41429f6a7f0fcd05f71a2c48c1114f5d4b06c52de48aca34, com.docker.compose.version=1.23.1, execID=e418ab9785ecbf119657ae6c7da892676eba443ce535b9e895171c26acf074af, image=fhem/fhem:latest, name=home_fhem_1_8b0e18c9b56b, org.fhem.authors=https://fhem.de/MAINTAINER.txt, org.fhem.description=FHEM (TM) is a GPL'd perl server for house automation. It is used to automate some common tasks in the household like switching lamps / shutters / heating / etc. and to log events like temperature / humidity / power consumption., org.fhem.documentation=https://fhem.de/#Documentation, org.fhem.licenses=GPL-2.0, org.fhem.revision=17800, org.fhem.source=https://svn.fhem.de/, org.fhem.url=https://fhem.de/, org.fhem.vendor=FHEM, org.fhem.version=5.9-s17800, org.opencontainers.image.authors=Julian Pawlowski (Forum.fhem.de:@loredo, Twitter:@loredo), org.opencontainers.image.created=2018-11-20T16:51:45+0000, org.opencontainers.image.description=A basic Docker image for FHEM house automation system, based on Debian Stretch., org.opencontainers.image.documentation=https://github.com/fhem/fhem-docker/blob/cb5bd5bf3c9fa64785750be0fe6196d7d1928e46/README.md, org.opencontainers.image.licenses=MIT, org.opencontainers.image.revision=cb5bd5bf3c9fa64785750be0fe6196d7d1928e46, org.opencontainers.image.source=https://github.com/fhem/fhem-docker/, org.opencontainers.image.title=fhem-amd64_linux, org.opencontainers.image.url=https://hub.docker.com/r/fhem/fhem-amd64_linux, org.opencontainers.image.vendor=FHEM, org.opencontainers.image.version=5.9-s17800_1.4.2)
2018-12-13T19:48:29.195756539+01:00 container exec_die ec198775da7487380f6ab510cddd88c8732de768a658147bcd8ca904e8e05d1e (com.docker.compose.config-hash=b2b4e2858ad4acbe1a19fe270d5ce08b1ba2a9c859ea3c062e1b69262876e907, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=home, com.docker.compose.service=fhem, com.docker.compose.slug=8b0e18c9b56bab41429f6a7f0fcd05f71a2c48c1114f5d4b06c52de48aca34, com.docker.compose.version=1.23.1, execID=e418ab9785ecbf119657ae6c7da892676eba443ce535b9e895171c26acf074af, exitCode=0, image=fhem/fhem:latest, name=home_fhem_1_8b0e18c9b56b, org.fhem.authors=https://fhem.de/MAINTAINER.txt, org.fhem.description=FHEM (TM) is a GPL'd perl server for house automation. It is used to automate some common tasks in the household like switching lamps / shutters / heating / etc. and to log events like temperature / humidity / power consumption., org.fhem.documentation=https://fhem.de/#Documentation, org.fhem.licenses=GPL-2.0, org.fhem.revision=17800, org.fhem.source=https://svn.fhem.de/, org.fhem.url=https://fhem.de/, org.fhem.vendor=FHEM, org.fhem.version=5.9-s17800, org.opencontainers.image.authors=Julian Pawlowski (Forum.fhem.de:@loredo, Twitter:@loredo), org.opencontainers.image.created=2018-11-20T16:51:45+0000, org.opencontainers.image.description=A basic Docker image for FHEM house automation system, based on Debian Stretch., org.opencontainers.image.documentation=https://github.com/fhem/fhem-docker/blob/cb5bd5bf3c9fa64785750be0fe6196d7d1928e46/README.md, org.opencontainers.image.licenses=MIT, org.opencontainers.image.revision=cb5bd5bf3c9fa64785750be0fe6196d7d1928e46, org.opencontainers.image.source=https://github.com/fhem/fhem-docker/, org.opencontainers.image.title=fhem-amd64_linux, org.opencontainers.image.url=https://hub.docker.com/r/fhem/fhem-amd64_linux, org.opencontainers.image.vendor=FHEM, org.opencontainers.image.version=5.9-s17800_1.4.2)
Scheint wohl mit health-check zu tun zu haben ist das normal ?
In Portainer unter events sieht das so aus:
(https://www.bilder-upload.eu/thumb/ca950f-1544726697.jpg) (https://www.bilder-upload.eu/bild-ca950f-1544726697.jpg.html)

Ansonsten läuft alles wie es soll:

(https://www.bilder-upload.eu/thumb/0b720c-1544768740.jpeg) (https://www.bilder-upload.eu/bild-0b720c-1544768740.jpeg.html)

Was hat das zu bedeuten?
com.docker.compose.oneoff False
Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 18 Dezember 2018, 10:17:22
Scheint wohl mit health-check zu tun zu haben ist das normal ?


Ja.
Google erklärt es zum Beispiel hier: https://help.datadoghq.com/hc/en-us/articles/115002548983-Reduce-Docker-Health-Check-Event-Spam (https://help.datadoghq.com/hc/en-us/articles/115002548983-Reduce-Docker-Health-Check-Event-Spam)


Was hat das zu bedeuten?
com.docker.compose.oneoff    False


Wie der Name andeutet, kommt diese Einstellung von deinem docker-compose Kommando und hat nichts mit dem FHEM Image zu tun.
Google erklärt es zum Beispiel hier: https://docs.docker.com/compose/faq/#whats-the-difference-between-up-run-and-start (https://docs.docker.com/compose/faq/#whats-the-difference-between-up-run-and-start)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: hajuerue am 18 Dezember 2018, 17:18:38
Hi,
habe seit gestern FHEM nun auch im Docker laufen.

Bisher läuft es prima. (auch mit update direkt nach dem installieren)

Allerdings habe ich 2 Dinge die mir noch unklar sind:
Bei "DockerImageInfo" stehen ???
und im LogFile ist der Eintrag "login denied" zu finden.

Für das "login denied" habe ich schon die Anpassung gemacht, die hier ein paar Seiten vorher beschrieben wurden.
Bin allerdings nicht sicher, was das SHA256 für ein passwort ist, denn ich hatte eigentlich ein anderes...

Gruss
HaJueRue
PS: sorry für die Noob Beschreibung ;-)

--
edit: Das DockerImageInfo Problem hat sich nach dem 2ten Neustart gelöst... komisch
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 18 Dezember 2018, 22:50:33

Ja.
Google erklärt es zum Beispiel hier: https://help.datadoghq.com/hc/en-us/articles/115002548983-Reduce-Docker-Health-Check-Event-Spam (https://help.datadoghq.com/hc/en-us/articles/115002548983-Reduce-Docker-Health-Check-Event-Spam)


Hallo,
wenn ich es richtig verstanden habe, könnte man im docker-daemon eine whitelist für den fhem container anlegen um den „spam“ zu reduzieren.
Ist das nötig, ich meine um ressourcen zu „sparen“ ?
Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 18 Dezember 2018, 23:12:45
Keine Ahnung, das ist eine reine Docker Frage, die ich nicht beantworten kann.

Was man aber sicher sagen kann ist, dass der Health Check ein Feature vom Docker selbst jst, genauso wie die Events. Geh also mal davon aus, dass die Entwickler von Docker sich etwas dabei gedacht haben und auch die Performance nicht ganz außer Acht gelassen haben.

Mein Tipp: Lass alles so, du wirst keine merklichen Verbesserungen erreichen. Abschließend solltest du dir auch die Frage stellen, ob du tatsächlich ein Problem hast, welches du lösen möchtest, oder ob es dir nur um ein Gefühl bei der Sache geht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: hajuerue am 19 Dezember 2018, 09:46:13
Moin,
heisst dass ich soll den Fehler mit dem "Login denied via telnetPort_192." ignorieren?

Ich denke es liegt nur am falschen Passwort, das ich aber nicht kenne ;-)

Gruss
Hans-Jürgen
PS: der Rest läuft echt gut !
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 19 Dezember 2018, 11:25:23
Das mit dem Telnet Passwort würde ich nicht ignorieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: hajuerue am 19 Dezember 2018, 12:20:23
Das mit dem Telnet Passwort würde ich nicht ignorieren.

Hi Loredo,
Danke für die Rückmeldung.

Aber wie bekomme ich das dann gelöst?

Ich habe die Zeile auf "globalpassword" angepasst, wie hier vor ein paar Seiten beschrieben wurde.

Kann ich da nochwas ändern dazu?
Ich weiss ehrlich gesagt nicht genau für was für eine Funktion es genutzt wird.
Vom Docker aus.

Gruss
HaJueRue
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: hajuerue am 19 Dezember 2018, 13:10:32
Hallo an alle,
Danke nochmal fürs drauf hinweisen.

Es lag an meinem hinterlegten Passwort in der Fhem Config und im ioBroker.

Jetzt sind die Meldungen weg und es funktioniert bisher alles super.

Gruss
HaJueRue
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 04 Januar 2019, 15:44:00
Hallo,
das läuft ja ziemlich gut. Ich habe das über die Neujahrswoche parallel mitlaufen lassen.
Nun versuche ich, bisher ohne Erfolg, jabber ans laufen zu bekommen.
Ich habe einfach alle Einstellungen aus meiner laufenden Instanz übernommen, erhalte aber im Status vom jabber Modul disconnected.
In  CONNINFO "Jabber authentication error: error invalid-mechanism"
Hat jemand eine Idee?

Gruß
geohem

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 05 Januar 2019, 13:32:49
Da bin ich überfragt, da die Perl Module ja enthalten sind. Bitte zunächst auf Modul-Ebene debuggen. Evtl. hat es auch mit der veränderten Netzwerk-Topologie zu tun, die mit Docker einher kommt, aber ich weiß leider nicht, wie das Jabber Modul arbeitet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 06 Januar 2019, 19:34:14
Danke für die Antwort, da bin ich leider nicht weitergekommen und habe die Medlungen auf telegram umgestellt.
Das klappt prima, kannte ich vorher auch noch nicht.

Für TTS habe ich aber noch keinen Ersatz bzw. Lösung gefunden.
Ich habe zwei Instanzen von Fhem. Einen Server und eine RemoteInstanz. Diese Remote Instanz habe ich jetzt auf diese Docker Version umgestellt.
An dieser R-Instanz habe ich einen Lautsprecher angeschlossen, der mir als Sprachrohr dient.
Damit TTS funktioniert, müsste ich nun mplayer in Docker installieren. Das gelingt mir aber noch nicht. Kann ich auch auf einen im System installierten mplayer zugreifen?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 07 Januar 2019, 01:58:38
Ich habe weitere Pakete zum Docker Image hinzugefügt, allerdings vorerst nur im Dev Image. Wenn du kannst, probiere dieses einmal aus, bis es im produktiven Image verfügbar ist.
Generell kann man sagen, dass Audio nicht unbedingt die beste Idee ist aus einem Docker Container heraus. Für solche Einsätze ist Docker eher nicht konzipiert. Hier (https://stackoverflow.com/questions/28985714/run-apps-using-audio-in-a-docker-container) gibt es ggf. einige Anregung zur Konfiguration des Docker Containers an sich.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 07 Januar 2019, 10:40:51
Ich habe jetzt 2 Scripts geschrieben, die man auch manuell aus dem Docker Container heraus ausführen kann, um herauszufinden, welche Perl Module und Debian Pakete für FHEM benötigt werden:


https://github.com/fhem/fhem-docker/blob/dev/src/find-missing-deb-packages.sh (https://github.com/fhem/fhem-docker/blob/dev/src/find-missing-deb-packages.sh)
https://github.com/fhem/fhem-docker/blob/dev/src/find-missing-perl-modules.sh (https://github.com/fhem/fhem-docker/blob/dev/src/find-missing-perl-modules.sh)


Die Scripts liefern natürlich auch Indizien für andere Umgebungen (Debian Paketerstellung, eigene Installation, etc.).
Auf dieser Grundlage versuche ich gerade alle Abhängigkeiten mit in das Docker Image einzubauen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 07 Januar 2019, 10:52:10
Gute Idee ... nur findet er auch packete, die man eigentlich nicht braucht.

z.B. bei mir:
wiringpi (gibt es auch für meinen X86-Ubuntu-Server nicht)
und noch diverse andere ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 07 Januar 2019, 10:57:48
Nicht brauchen kommt ja immer auf den Standpunkt an. Du vielleicht nicht, andere schon, wenn sie ein Modul verwenden, welches du nicht verwendest.
Und ich schrieb ja, dass man dadurch nur Indizien bekommt, interpretieren muss man das schon noch selbst und im Zweifel auch mal noch ein manuelles grep über den Sourcecode hinterher schicken um zu bewerten, woher die Abhängigkeit stammt.


Die RaspberryPi Sachen werden natürlich nur in die ARM Images eingebaut.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 07 Januar 2019, 11:17:34
Hey .. war doch nur als Fingerzeig. Übrigens war es ein Testlauf Deinesw Scriptes auf der Maschine .. dachte, Du könntest den Feedback gebrauchen :o)

Und bei den hier vorhandenen Usern sind die ersten Fragen dann "Vorprogrammiert"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 07 Januar 2019, 11:56:57
Das ist dann wohl ein Missverständnis, hatte diesbezüglich nicht wirklich auf (User)Feedback gehofft. Es war mehr ein netter Hinweis an Entwickler und fortgeschrittene Benutzer.
Die Scripts haben wirklich nur den Anspruch bei der Analyse zu helfen, welche Abhängigkeiten FHEM global-galaktisch so hat.
Trotzdem aber natürlich Danke ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 07 Januar 2019, 12:08:43
OT:
global-galaktischDann fehlt da noch die 42 *griiiins*
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 08 Januar 2019, 05:40:15
"Wenn du kannst, probiere dieses einmal aus, bis es im produktiven Image verfügbar ist."

Ich habe mir das Dev Image schon mal geladen. Zum testen werde ich wohl erst am Wochenende kommen, aber die Links schaue ich mir schon mal an.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nightstorm99 am 09 Januar 2019, 17:10:55
Hallo,

ich wollte meine aktuelle FHEM Installation jetzt auf meinem neuen Server in Docker laufen lassen.
Jetzt habe ich wie im ersten Post mit dem Parameter -v das Verzeichnis meiner alten FHEM Config angegeben, aber er übernimmt dieses überhaupt nicht.
Habe ich einen Denkfehler oder bekomme ich dieses auch anders dort rein?

Nachtrag:
Mein Start Kommando
docker run -d --name fhem -p 8083:8083 fhem/fhem -v /opt/volumes/fhem:/opt/fhem --device=/dev/ttyACM0 --device=/dev/ttyACM1

Danke und Gruß
Denny
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 09 Januar 2019, 18:15:54
1. Deine config liegt doch bestimmt nicht unter /opt/volumes/fhem? Ich würde mal das "volumes" wegnehmen
2. Du willst 2 USB-Geräte direkt verwenden? Lese Dich bitte mal in die Verwendung von /dev/by-id (oder /dev/by-path) ein ...

Alle Angaben ungetestet!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nightstorm99 am 09 Januar 2019, 19:03:41
1. Deine config liegt doch bestimmt nicht unter /opt/volumes/fhem? Ich würde mal das "volumes" wegnehmen

Habe ich schon Tesweise unter /opt/fhem verschoben, aber das gleiche Ergebnis.


2. Du willst 2 USB-Geräte direkt verwenden? Lese Dich bitte mal in die Verwendung von /dev/by-id (oder /dev/by-path) ein ...
/dev/by-id ..... gibts unter Debian 9 leider nicht.

Gruß
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 09 Januar 2019, 19:32:04
Ich meinte den Aufruf zur Config ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 09 Januar 2019, 19:50:28
@werniemann
Ich bin zwar der Meinung, dass deine Verzeichnis Übergabe funktionieren sollte.
Ich lege allerdings ein Volume im dicker Verzeichnis an.

-v fhem_data:/opt/fhem

Dann liegt die fhem Konfiguration im Unterverzeichnis volumes von docker.
docker/volumes/fhem_data/_data
Dahin kannst du dann deine Konfiguration kopieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 09 Januar 2019, 19:52:47
ähm, sorry.
Das war für nightstorm99 gedacht.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 09 Januar 2019, 20:47:05
Kein Problem ;o)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nightstorm99 am 09 Januar 2019, 20:59:16
@werniemann
Ich bin zwar der Meinung, dass deine Verzeichnis Übergabe funktionieren sollte.
Ich lege allerdings ein Volume im dicker Verzeichnis an.

-v fhem_data:/opt/fhem

Dann liegt die fhem Konfiguration im Unterverzeichnis volumes von docker.
docker/volumes/fhem_data/_data
Dahin kannst du dann deine Konfiguration kopieren.

Danke, probiere ich aus.

Gruß
Denny
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 10 Januar 2019, 05:52:16
Ich habe weitere Pakete zum Docker Image hinzugefügt, allerdings vorerst nur im Dev Image. Wenn du kannst, probiere dieses einmal aus, bis es im produktiven Image verfügbar ist.

Ich denke das geht auch in der dev Version nicht, auch da braucht tts den mplayer.
Ich habe auch hier ein wenig angepasst und die Sprachausgabe über meinen bestehenden mpd Server realisiert. Der spielt nun zur gegebenen Zeit mp3 file mit dem gewünschten Text ab.

Insgesamt eine gelungene Idee mit dem docker-fhem, danke.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 15 Januar 2019, 12:10:18
Es baut gerade gibt eine neue Produktiv-Version 1.5.0 des FHEM Docker Image.

Dabei werden soweit erkenntliche Abhängigkeiten für alle FHEM Module mit eingebaut. Einige Perl Module gibt es jedoch nicht als fertige Debian Pakete und auf der ARM Plattform dauert das bauen des Images dann zu lange. Daher sind diese Pakete auf ARM dann leider nicht enthalten.
Für die i386 Plattform ergeben sich ebenfalls einige Einschränkungen.

Hier die Neuerungen im Überblick:

Alle Plattformen (amd64, i386, arm64v8, arm32v7, arm32v5):
- alle von FHEM Modulen benötigten Debian Pakete (soweit automatisch erkennbar)
- alle von FHEM Modulen benötigten Perl Module, die als Debian Paket verfügbar sind (soweit automatisch erkennbar)
- Unterstützung für Python3 (für das GOOGLECAST Modul)

Nur auf amd64, i386, arm64v8, arm32v7:
- FHEM Alexa Connector Support (für das alexa Modul)
- Node.js 10.x LTS (8.x LTS bei i386)

Nur auf amd64 und i386:
- Manuell gebaute Perl Module: Crypt::OpenSSL::AES, CryptX, Device::SMBus, Net::MQTT::Constants, Net::MQTT::Simple

Nur auf amd64:
- Manuell gebaute Perl Module: Crypt::Random, Math::Pari
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 15 Januar 2019, 16:54:39
Hallo,
Danke für das update.
Habe von Version 1.4.2 auf die 1.5.0 upgedatet, ist es richtig, das das image nun 1Gb groß ist, oder habe ich da irgendwie Mist gebaut?
Meine "alte" Version (1.4.2)  war 461 Mb groß.

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 15 Januar 2019, 18:18:52
Hm, also 1 GB klingt zu groß. Woran hast du die Größe abgelesen? Einige Layer des alten Images bleiben auf deiner Festplatte erhalten, solange du sie nicht aufräumst.


Die Größe der Images je nach Plattform kann man auf Docker Hub nachsehen.
Für AMD64 zum Beispiel hier:
https://hub.docker.com/r/fhem/fhem-amd64_linux/tags (https://hub.docker.com/r/fhem/fhem-amd64_linux/tags)


Dort sieht man, dass das "latest" Image genau 400 MB groß ist derzeit.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 15 Januar 2019, 18:58:34
Ich habe das dev und liege bei einer Imagegröße von 1,1 GB.
Aber liegt das nicht nahe, wenn nodejs, SSH, Homebridge und Alexa in ein Image gepackt werden? Ich bin einerseits begeistert, aber andererseits widerspricht das meine Vorgehensweise in Docker (1 Dienst - 1 Container).
Aber soweit ich das abschätzen kann läuft Alexa aktuell doch sowieso nur auf dem gleichen Host, oder? Die Angabe von Hostnamen existiert derzeit, soweit ich das überflogen habe, nicht.

Danke für die Anpassung!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 15 Januar 2019, 18:59:01
Hm,
die größe habe ich in Portainer abgelesen bzw ist mir zufällig aufgefallen wie groß das image ist.
https://www.bilder-upload.eu/bild-096309-1547574975.jpg.html
Warum ist es bei mir so groß? Habe es mit docker pull fhem/fhem geladen.

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 15 Januar 2019, 19:13:56
Hier noch ein screenshot:
https://www.bilder-upload.eu/bild-6e5a68-1547575996.jpg.html
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 15 Januar 2019, 19:44:19

Ich denke die Größe wird dann einfach auf Docker Hub falsch angezeigt (warum auch immer).

Aber liegt das nicht nahe, wenn nodejs, SSH, Homebridge und Alexa in ein Image gepackt werden?


Absolut, ja.


Nachdem das neue Image in Layer je nach Bereich aufgeteilt ist, kann man auch etwas genauer sagen was wieviel wegnimmt:
http://take.ms/Ert1C


Die Entwicklergemeinde nutzt halt alles, was es so gibt und nimmt nicht immer die selben Tools/Libraries für ähnliche Dinge. Dazu ist der Entwicklerpool zu divers :-)


Ich bin einerseits begeistert, aber andererseits widerspricht das meine Vorgehensweise in Docker (1 Dienst - 1 Container).


Wer möchte, kann das ja weiterhin tun, da spricht ja grundsätzlich überhaupt nichts dagegen. Plattenplatz sollte da jetzt nicht unbedingt das Thema sein heutzutage...
Der Punkt ist halt, dass Leute (zurecht) erwarten, dass sie das fertige Image nicht erst noch selbst erweitern müssen, damit Module lauffähig sind. Wer ein schlankes Image möchte und genau weiß was er tut, der muss das selbst bauen (geht ja auch, die Quellen gibt es ja zum abgucken). Ich denke auch für eine ganze Reihe anderer macht es das austesten leichter - auslagern geht immer, sofern das Modul das unterstützt.


Aber soweit ich das abschätzen kann läuft Alexa aktuell doch sowieso nur auf dem gleichen Host, oder? Die Angabe von Hostnamen existiert derzeit, soweit ich das überflogen habe, nicht.


Laut André soll man die Node.js basiertem Daemons explizit wie bisher auch extern betreiben können. Nach meinen ersten Tests geht das allerdings derzeit nicht mehr innerhalb von einem Docker Container, da der Prozess sich kurz nach dem Start wieder beendet. Wahrscheinlich hat es was mit dem veränderten stdin/stdout Verhalten zu tun (Docker lässt den Prozess ja eigentlich im Vordergrund laufen, aber wenn man ihn im normal üblichen detached Modus in den Hintergrund schickt, fallen natürlich stdin/stdout weg). Ich denke aber mal, dass das irgendwann wieder gehen wird.


Wenn man also die neue alexa-fhem Version benutzen will statt der alten, dann muss man derzeit wohl den Prozess von FHEM direkt managen lassen. Das geht auch im Docker Image zuverlässig, wenn FHEM der Vaterprozess ist.


Was auch gehen soll ist über SSH remote einen Prozess zu starten. Da funktioniert für eine normale VM oder ein richtiges Device, aber im Falle von Docker müsste man dann einen SSH Daemon laufen lassen, was etwas unschön ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 15 Januar 2019, 19:51:42
Danke für die Erklärung. Mich stört die Größe nicht, kam mir nur komisch vor.

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 15 Januar 2019, 19:57:10
Du musst im Docker einen Prozess im "Vordergrund" laufen lassen, da er sonst von docker gekillt wird. Deshalb wird z.B. der apache im offiziellen apache-Docker-Image so gestartet.

Hintergrund:
Wenn der Start Prozess sich verabschiedet geht docker davon aus, das der Container nicht mehr gebraucht wird. Also wenn Dein Programm sich im Hintergrund startet und damit die PID vechselt, geht dockr davon aus, das es sich beendet hat.

Was ich nicht verstehe, wieso ssh im docker-Container? Es ist docker und keine VM!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 15 Januar 2019, 20:09:01
Wie Docker mit Prozessen umgeht, ist mir geläufig.

justme1968 (der alexa-fhem Entwickler) denkt mehr in VMs und dass man etwas in einer separaten VM laufen hat. Containerisierung ist ihm nicht so bekannt, daher liegt es nun an der Community die richtigen Requirements zu finden und für ihn zu formulieren, so dass er versuchen kann sie zu berücksichtigen.

alexa-fhem bleibt auch im Vordergrund, kommt aber eben mit dem Detaching offenbar nicht richtig klar bisher. Um das zu debuggen, brauchts erstmal eine dafür geeignete Umgebung. Hilfe ist dabei gerne willkommen, denn wie man auf Github vielleicht gesehen hat, hatte ich vor ein alexa-fhem-docker Image dort bereitzustellen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 16 Januar 2019, 15:24:20
In einer aktualisierten Version hat André das Problem adressiert und einen neuen Kommandozeilen Parameter --dockerDetached eingeführt.
Auf dieser Basis steht nun auch ein vorbereitetes Docker Image als Ergänzung zum fhem-docker Image bereit:


https://hub.docker.com/r/fhem/alexa-fhem
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: WumpE am 18 Januar 2019, 12:30:48
@Loredo, danke für die neue version. Was mir noch aufgefallen ist, kannst du mal noch cpanm Net::WebSocket::Server mit aufnehmen, das ist für Hermann sein Fronthem modul verdammt wichtig.

Danke und Grüße
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Mike70 am 20 Januar 2019, 12:05:20
Hi,

Habe das docker image laufe, wollte PRESENCE verwenden mittels G-Tag, läuft aber nicht. Muss ich das erst im Docker einbinden?

LG
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 Januar 2019, 12:08:36
Was mir noch aufgefallen ist, kannst du mal noch cpanm Net::WebSocket::Server mit aufnehmen, das ist für Hermann sein Fronthem modul verdammt wichtig.

 Das ist aber kein offizielles Modul, oder?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 Januar 2019, 12:10:29
wollte PRESENCE verwenden mittels G-Tag, läuft aber nicht. Muss ich das erst im Docker einbinden?

Wahrscheinlicher ist, dass du dich damit beschäftigen musst, wie du reale USB Geräte bzw. Bluetooth für einen Docker Container verfügbar machst. Wie du das Docker image bei dir startest und betreibst, bleibt ganz dir überlassen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Mike70 am 21 Januar 2019, 04:59:45
Wahrscheinlicher ist, dass du dich damit beschäftigen musst, wie du reale USB Geräte bzw. Bluetooth für einen Docker Container verfügbar machst. Wie du das Docker image bei dir startest und betreibst, bleibt ganz dir überlassen.


Vielen Danke für die Information, hat mich auf den richtigen weg gebracht. Funktioniert soweit.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 25 Januar 2019, 10:35:27
Die aktualisierte Version 1.6.0 des Images beinhaltet jetzt folgende Veränderungen:


1. Unterstützung für Google Assistant (nur i386 und amd64)
2. Unterstützung für ECHODEVICE
3. Aktualisierung der APT Pakete (siehe auch DSA-4371-1 (https://www.debian.org/security/2019/dsa-4371))
4. Umstellung von HTTP auf HTTPS für das Debian Repository (https://cdn-aws.deb.debian.org)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 25 Januar 2019, 19:57:48
hallo,
gibt es eine Möglichkeit mit Docker, dass ich nur meine modifizierten files in einem externen volume liegen habe?
z.b.
fhem.cfg
FHEM/einesModul.pm

Ich möchte die FHEM Docker files alle im container liegen haben und dann beim start soll der container meine customized files aus einem volume dazu laden.

geht das?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 Januar 2019, 20:02:21
Eigentlich sollte man sich ändernde Daten NICHT im Container haben. z.B. auch Logfiles sind dort nicht gut aufgehoben. Bringt sehr schnell Geschwindigkeitsverluste .. also ist das Rauslinken des kompletten /opt/fhem-Ordners Sinnvoller
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 26 Januar 2019, 09:22:35
gibt es eine Möglichkeit mit Docker, dass ich nur meine modifizierten files in einem externen volume liegen habe?
z.b.
fhem.cfg
FHEM/einesModul.pm

Ich möchte die FHEM Docker files alle im container liegen haben und dann beim start soll der container meine customized files aus einem volume dazu laden.


Das geht mit dem FHEM Docker Image nicht.
Der Grund, weshalb man FHEM selbst nicht über das Docker Image aktualisieren kann ist, dass FHEM eigentlich kein richtiges Release Management in Form von Versionen hat. Das wurde anfangs auch in diesem Thread nochmals von Rudi erklärt (https://forum.fhem.de/index.php/topic,89745.msg822481.html#msg822481). Aus diesem Grund macht es keinen wirklichen Sinn, dass man FHEM über das Image aktualisiert statt über den FHEM Update Befehl. Es geht hier also rein darum eine Umgebung für FHEM zu pflegen, in der es sich möglichst wohl fühlt und in der die Funktionen, die die verschiedenen Modul-Autoren sich ausgedacht haben, direkt lauffähig sind.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nightstorm99 am 26 Januar 2019, 09:28:28
Hallo,

ich kann nur eins sagen, VIELEN DANK für das Docker Image.

Ich habe vor 2 Wochen meinen Server, von Virtuellen Maschinen auf Docker umgestellt und es läuft weit aus besser.
FHEM läuft seid dem perfekt und ich konnte noch keine Fehler fest stellen.
Zusätzlich habe ich jetzt noch alles über einen Proxy (Nginx) mit SSL geschützt und auch das war ohne Probleme möglich.

Nochmals vielen Dank für eure Arbeit.

Gruß
Denny
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: M.Schulze am 26 Januar 2019, 11:25:21

Das geht mit dem FHEM Docker Image nicht.
Der Grund, weshalb man FHEM selbst nicht über das Docker Image aktualisieren kann ist, dass FHEM eigentlich kein richtiges Release Management in Form von Versionen hat. Das wurde anfangs auch in diesem Thread nochmals von Rudi erklärt (https://forum.fhem.de/index.php/topic,89745.msg822481.html#msg822481). Aus diesem Grund macht es keinen wirklichen Sinn, dass man FHEM über das Image aktualisiert statt über den FHEM Update Befehl. Es geht hier also rein darum eine Umgebung für FHEM zu pflegen, in der es sich möglichst wohl fühlt und in der die Funktionen, die die verschiedenen Modul-Autoren sich ausgedacht haben, direkt lauffähig sind.

Dann wäre ein weiteres Docker Image wünschenswert das das kann.
Persistente Nutzer Daten in einem Pfad sammeln und nicht überall wild verteilen.
Update via docker recreate. Quelle z.B.  Github gemäß Versionsangabe im Dockerfile.

Dann braucht es nicht jeder  selbst machen.

Mfg
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 26 Januar 2019, 11:27:01
Dann wäre ein weiteres Docker Image wünschenswert das das kann.
Persistente Nutzer Daten in einem Pfad sammeln und nicht überall wild verteilen.
Update via docker recreate. Quelle z.B.  Github gemäß Versionsangabe im Dockerfile.

Dann braucht es nicht jeder  selbst machen.


Ein solches offizielles Image wird es nicht geben, Begründung siehe oben.
Wild verteilt ist im aktuellen Image überhaupt gar nichts, eine persistente Versionierung für das Image ansich existiert in den Docker Hub Repositories der einzelnen unterstützten Plattformen.


Für das, was du möchtest, müsste sich die Architektur und das Release Management von FHEM zunächst komplett neu aufstellen. Es macht keinen Sinn die von dir gewünschte Struktur zu schaffen, solange nicht alle daran beteiligten Komponenten dazu geeignet sind.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 26 Januar 2019, 18:20:13
Eine aktualisierte Version 1.7.0 baut gerade und enthält folgende Änderungen:


- Support für tradfri-fhem (https://forum.fhem.de/index.php/topic,96530.0.html)
- Support für AptToDate (https://forum.fhem.de/index.php/topic,87835.0.html) und npmjs (https://forum.fhem.de/index.php/topic,96525.0.html)
   - bei Greenfield Installationen werden automatisch 2 Geräte mit angelegt, um die Aktualität des Docker Images zu beobachten. Ein Update der Systemumgebung kann dann entweder wie gehabt durch Aktualisierung des Docker Images oder aber auch innerhalb des bestehenden Containers vorgenommen werden.
- Net::WebSocket::Server wurde hinzugefügt
- Sudo Support für nmap
- Fix für speedtest-cli
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 27 Januar 2019, 05:49:40
Jetzt habe ich wie im ersten Post mit dem Parameter -v das Verzeichnis meiner alten FHEM Config angegeben, aber er übernimmt dieses überhaupt nicht.
Habe ich einen Denkfehler oder bekomme ich dieses auch anders dort rein?

Nachtrag:
Mein Start Kommando
docker run -d --name fhem -p 8083:8083 fhem/fhem -v /opt/volumes/fhem:/opt/fhem --device=/dev/ttyACM0 --device=/dev/ttyACM1
Das Docker Image (fhem/fhem) muss HINTER die Optionen, ansonsten wird z.B. die Angabe des Volumes ignoriert. Vielleicht kann @Loredo das in seinem Readme anpassen?

In einer aktualisierten Version hat André das Problem adressiert und einen neuen Kommandozeilen Parameter --dockerDetached eingeführt.
Auf dieser Basis steht nun auch ein vorbereitetes Docker Image als Ergänzung zum fhem-docker Image bereit:

https://hub.docker.com/r/fhem/alexa-fhem
Inwiefern unterscheidet sich denn die alexa-fhem Version in dem neuen Docker Container von dem alexa-fhem node.js Modul, dass im "alten" Image schon mitgeliefert wird?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 27 Januar 2019, 09:42:18
Hallo,
ich habe nun auch meine zweite fhem Instanz auf Docker umgestellt.
Dort benutze ich die i2c Schnittstelle für ein USV Akkupack.
Um i2c zu nutzen muss ich nach jedem Start des Containers den Besitzer bzw die Gruppe von /dev/i2c* ändern auf root:dialout.

Kann ich das /pre-start.sh Script dafür nutzen?
Wo finde ich das und wie binde ich das ein? Ist dasDockerspezifisch?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 Januar 2019, 10:47:15
Das Docker Image (fhem/fhem) muss HINTER die Optionen, ansonsten wird z.B. die Angabe des Volumes ignoriert. Vielleicht kann @Loredo das in seinem Readme anpassen?


Ah, manchmal übersieht man solche Dinge einfach :-) Danke!


Inwiefern unterscheidet sich denn die alexa-fhem Version in dem neuen Docker Container von dem alexa-fhem node.js Modul, dass im "alten" Image schon mitgeliefert wird?


Die Frage kann André besser beantworten. Konkret das Startverhalten war und ist für fhem-docker unwichtig, eine Rolle spielt es beim separaten alexa-fhem-docker Image, da dort kein FHEM dazwischen ist, sondern der Daemon direkt von Docker gestartet wird. Ansonsten sind in den neueren Version gewiss viele Detailverbesserungen für einen robusteren Betrieb, das sind aber alles alexa-fhem Spezifika und relativ unwichtig für fhem-docker, da dort die Basis ja auf einem verlässlichen Stand ist, der schon funktioniert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 Januar 2019, 13:07:32
Um i2c zu nutzen muss ich nach jedem Start des Containers den Besitzer bzw die Gruppe von /dev/i2c* ändern auf root:dialout.

Kann ich das /pre-start.sh Script dafür nutzen?
Wo finde ich das und wie binde ich das ein? Ist dasDockerspezifisch?


Das Script existiert nur, wenn du selbst eines schreibst und es per "-v" Parameter als Volume mit in den Container legst. Dort muss es unter /pre-start.sh zu finden sein:


-v /path/on/host/pre-start.sh:/pre-start.sh:ro


Die Besitzrechte kann ich aber auch im Entry Script direkt anpassen. Bisher war mir diese Notwendigkeit nicht bekannt, da ich natürlich nicht sämtliche Funktionen in FHEM selbst benutze oder testen kann :-)
Ich bin aber nicht sicher, was alles notwendig ist bzw. scheinen mir nach kurzer Recherche hier auch eine Menge Halbwahrheiten zu kursieren (bspw. gibt es eigentlich dedizierte System Gruppen "gpio" und "i2c" für diese Dinge, anstatt dialout zu verwenden).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 Januar 2019, 13:55:16
Ich habe jetzt mal einen Wurf zur Korrektur der Berechtigungen im Entwickler-Image implementiert:
https://github.com/fhem/fhem-docker/blob/959b9120c9e403fdf0f1f13013356b07a1ef97ac/src/entry.sh#L131-L151


Dabei wird absichtlich nicht auf die Gruppe dialout gesetzt, sondern getrennt auf i2c und gpio. Allerdings werden diese Gruppen IDs dynamisch bei der Installation des Docker Host Systems vergeben, weshalb die GIDs in Docker dann per Default anders lauten. Da ich innerhalb des Docker Containers aber nicht nachschauen kann, welche GIDs das Hostsystem verwendet, müssen diese GIDs bei der Erstellung des Docker Containers als Umgebungsvariable übergeben werden (siehe README.md (https://github.com/fhem/fhem-docker/blob/959b9120c9e403fdf0f1f13013356b07a1ef97ac/README.md)).
Diese Vorgehensweise vermeidet, dass man per chown auch die Besitzrechte ändert, um die Abgrenzung zwischen den verschiedenen Use Cases weiterhin zu gewährleisten und die Sicherheit des Host Systems zu erhöhen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 27 Januar 2019, 17:52:55
dev Version läuft super, vielen Dank.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 Januar 2019, 19:36:37
Prima, danke für das Feedback!
Musstest du dafür die GIDs anpassen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 27 Januar 2019, 22:12:23
Nein das ist auf Standard. Glücklicherweise musste ich da nicht dran. Ehrlicherweise muss ich zugeben, dass ich da auch nicht gewusst hätte, was zu tun ist. :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 28 Januar 2019, 08:56:23
Ok :-)


Habe es somit in die Produktivversion übernommen, die nun gerade baut.
Änderungen in v1.7.1:


- Berechtigungen für Bluetooth, GPIO und I2C Zugriff
- rpi.gpio hinzugefügt (nur ARM Plattformen)
- Python Layer umgestaltet: Alle Pakete werden per pip3 installiert statt über Debian Pakete
- Node.js Layer: alexa-cookie2 hinzugefügt (für echodevice Modul)
- Perl Layer: Pakete hinzugefügt: libio-all-perl, libtypes-path-tiny-perl, libutf8-all-perl
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 29 Januar 2019, 16:26:18
habe das ganze mal im Docker auf meiner Synology laufen. Wie kann ich nun die USB Ports da "durchschleifen" ?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 29 Januar 2019, 18:30:23
habe das ganze mal im Docker auf meiner Synology laufen. Wie kann ich nun die USB Ports da "durchschleifen" ?

https://forum.fhem.de/index.php/topic,89745.msg836674/topicseen.html#msg836674
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 29 Januar 2019, 20:22:50
Okay Danke nur wie kann ich das USB Gerät per Seriennummer oder ähnliches anbinden ? So wäre es doch auf den Port beschränkt ? Habe da so einen passiven 4er USB Port dran und 2 Sticks
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 29 Januar 2019, 20:31:44
Okay Danke nur wie kann ich das USB Gerät per Seriennummer oder ähnliches anbinden ? So wäre es doch auf den Port beschränkt ? Habe da so einen passiven 4er USB Port dran und 2 Sticks

wenn das device eine eindeutige id hat dann kannst du auch das durchreichen. auf dem rpi3 ist es ...

ls -l /dev/serial/by-id

damit bekommst du alle angeschlossenen usb-devices mit der eindeutigen id

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A7031TM7-if00-port0   ist z. B. mein CUL.

in docker compose sagst du dann

- /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A7031TM7-if00-port0:/dev/ttyUSB0

im container wäre bei dem beispiel der CUL unter /dev/ttyUSB0 ansprechbar. musst mal prüfen, bin mir grad nicht sicher ob die syntax passt. beispiel von mir ist <device_host>:<device_container>   bin mir grad nicht sicher ob das docker-device vor oder nach dem doppelpunkt ist.

ach ja ... vorteil von serial/by-id ... es ist egal an welchem usb-port du ansteckst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 29 Januar 2019, 20:50:42
schade das geht auf dem synology wohl nicht. kein Serial Ordner zu finden.
Ich habe dort den Docker mit hohen Privilegien gestartet so schleift er von selbst alles durch und Fhem findet es von selbst due CULs sind nun in Fhem und laufen. Trotzdem das "feste" hinterlegen wäre schon schön da am NAS öfters mal die Ports wechseln wie ich mitbekommen habe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schlimbo am 29 Januar 2019, 21:14:55
Hallo Loredo,

ware es möglich im DockerImageInfo Modul noch ein Reading wie zum Beispiel "updatesAvailable" und/oder "image.latest" zu integrieren?
So dass man sich über FHEM einfach benachrichtigen könnte, sobald ein neues Docker Image verfügbar ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 30 Januar 2019, 09:25:33
Kurze Frage: Hast sich im Master-Branch des Docker-Images irgendetwas an den Multicast-Paketen geändert?
Ich habe gestern das Image neu gepullt und vermutlich seitdem folgenden Fehler in FHEM:

Messages collected while initializing FHEM:
configfile: install IO::Socket::Multicast to use autodiscovery
Please define HarmonyController 5c42dca7-f33f-47ae-93f7-xxxxxxxxxx first

Im Changelog zu FHEM und https://github.com/fhem/fhem-docker konnte ich jedoch nichts in dieser Richtung finden.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 30 Januar 2019, 15:22:04
Die Pakete libio-file-withpath-perl und libio-socket-*-perl wurden ersetzt durch libio-all-perl, was eigentlich das Meta Paket sein sollte, um alle IO Perl Module zu installieren.
Offenbar ist dem nicht so... das ist wohl doch ein eigenes Paket, sorry wegen des Irrtums meinerseits...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 30 Januar 2019, 16:00:53
Nicht schlimm. War sowieso nur fakeRoku betroffen und somit hatte ich endlich die Chance aufzuräumen. :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beddo am 30 Januar 2019, 16:34:20
Hallo Zusammen,

erstmal danke für die Super Arbeit.
Hab mittlerweile fast alles unter dem Container zum laufen gebracht.
Jedoch nutze ich einige TPLINK HS110 Steckdosen und diese benötigen libio-socket-timeout-perl

Könntet ihr das noch mit ins nächste Build aufnehmen.

Wäre super.
Danke
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 30 Januar 2019, 16:34:45
Ich weiß, das ist eher eine Docker spezifische Frage, allerdings habe ich zu dem Thema echt wenig bei Google gefunden:

Wie bekomme ich den innerhalb des Containers Zugriff auf die Bluetooth-Schnittstelle eines Raspberry Pi 3?
"id" listet keine Gruppe speziell für BT.

Bis jetzt hat es nur geklappt, wenn ich den Network mode auf host setze. Das ist mir aber ein bisschen zu unsicher und außerdem verliere ich dadurch die Möglichkeit mit dem FHEM-Container Dockers Funktion für virtuelle Netze zu nutzen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: GammaTwin am 30 Januar 2019, 21:14:46
Eine aktualisierte Version 1.7.0 baut gerade und enthält folgende Änderungen:

[...]
- Net::WebSocket::Server wurde hinzugefügt
[...]

Grüße,
ich musste RUN cpan Net::WebSocket::Server im Dockerfile ausführen, damit fronthem läuft.

Ansonsten: Sehr, sehr geile Arbeit ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 31 Januar 2019, 08:27:38
Bitte tut mir einen Gefallen und macht nicht den Container zu einer "Eierlegenden Wollmilchsau", er wird dann einfach "zu dick".

Der Vorteil von docker sind gerade "schlanke" Container! Und wenn man dann etwas spezielles braucht, kann man sich die docker-compose.yml besorgen, anpassen und eben um das passende Produkt erweitern!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 31 Januar 2019, 09:53:46
Bitte tut mir einen Gefallen und macht nicht den Container zu einer "Eierlegenden Wollmilchsau", er wird dann einfach "zu dick".

Der Vorteil von docker sind gerade "schlanke" Container! Und wenn man dann etwas spezielles braucht, kann man sich die docker-compose.yml besorgen, anpassen und eben um das passende Produkt erweitern!


Ich denke das Ende der Fahnenstange ist hier auch langsam erreicht, viel mehr gibt es wohl nicht mehr. Ich arbeite außerdem daran einen Paketmanager für Fhem zu schreiben, der dann auch on-demand Sachen nachinstalliert. Das fertige Dockerimage modifizieren zu müssen, weil ein Paket fehlt, widerspricht der Absicht, dass die (offiziellen) Fhem Module alle einfach laufen. Ich gebe euch aber recht, dass für inoffizielle Module sehr enge Grenzen zu setzen sind - der Wildwuchs an redundanten Perl Modulen, die verwendet werden, ist ohnehin schon enorm groß.


Wer einen schlanken Minimalcontainer will, der kann sich ja selbst einen Container bauen. Denen, den es mehr auf die Funktion statt auf Festplattenplatz ankommt, möchte ich das aber nicht zumuten. Vielleicht setze ich nochmal ein "Light" Image auf, aber derzeit möchte ich nichts doppelt und dreifach pflegen.


ich musste RUN cpan Net::WebSocket::Server im Dockerfile ausführen, damit fronthem läuft.


Das liegt daran, dass selbst zu kompilierende Pakete, die per cpanm installiert werden, aufgrund der zu langen Build Zeit nur in die Images für amd64 und i386 Plattformen kommen. Auf ARM muss man sie leider derzeit selbst nachinstallieren, da ich es auch bisher nicht geschafft habe automatisiert vorkompilierte Debian Pakete dafür zu bauen, die die Build Time nicht beeinträchtigen. Wer an dieser Stelle helfen möchte, sei herzlich eingeladen sich das Entwurf-Script (https://github.com/fhem/fhem-docker/blob/dev/scripts/compile-perl-arm.sh) (welches so aber noch nicht funktioniert) anzusehen und fertig zu stellen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beddo am 31 Januar 2019, 10:46:12
Bitte tut mir einen Gefallen und macht nicht den Container zu einer "Eierlegenden Wollmilchsau", er wird dann einfach "zu dick".

Der Vorteil von docker sind gerade "schlanke" Container! Und wenn man dann etwas spezielles braucht, kann man sich die docker-compose.yml besorgen, anpassen und eben um das passende Produkt erweitern!

Vermutlich eine sehr blöde Frage. Aber wie kann ich den über die docker-compose.yml beim starten automatisch fehlende Module nachinstallieren?
Bisher habe ich mir geholfen, mich über portainer auf den Console des Container einzuloggen und dann entsprechend von Hand zu installieren.
Das muss ich aber jedes mal machen wenn ein neuer Container gezogen wird. Macht ja nicht wirklich Sinn.
Wenn das über die docker-compose.yml direkt ausführbar ist, kann ich auch so damit leben.
Aktuell starte ich den Container über die docker-compose Datei aus dem fhem-docker Git Repository.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 31 Januar 2019, 12:09:14
@beddo:

Es muß in der docker-compose.yml geändert werden. Am besten sagt Dir das der Ersteller ...

@Loredo:
Zitat
...die Funktion statt auf Festplattenplatz ankommt...
Dein Problem wird werden, das ein aufgeblähter Container viele Möglichkeiten für Probleme bekommt. Ein Einfacher ist eben einfacher zu warten. Es ging mir also NICHT um Plattenplatz .... sondern um Stabilität.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 31 Januar 2019, 12:31:07
Bisher habe ich mir geholfen, mich über portainer auf den Console des Container einzuloggen und dann entsprechend von Hand zu installieren.
Das muss ich aber jedes mal machen wenn ein neuer Container gezogen wird. Macht ja nicht wirklich Sinn.
Wenn das über die docker-compose.yml direkt ausführbar ist, kann ich auch so damit leben.
Aktuell starte ich den Container über die docker-compose Datei aus dem fhem-docker Git Repository.


Das geht zum Beispiel, indem du Befehle in das /pre-init.sh Script packst, welches dann beim allerersten Start des Containers ausgeführt wird. Wiederkehrende Befehle können in das /pre-start.sh Script gepackt werden. Beide Scripte musst du selbst erstellen und als Volume nach / mounten. In der docker-compose.yml Datei ist das dann ein weiterer Eintrag analog zu dem Eintrag für die Daten, die du nach /opt/fhem mountest.


@Loredo:Dein Problem wird werden, das ein aufgeblähter Container viele Möglichkeiten für Probleme bekommt. Ein Einfacher ist eben einfacher zu warten. Es ging mir also NICHT um Plattenplatz .... sondern um Stabilität.


Das sehe ich anders. Es sind zunächst einmal nur Dateien, die je nach Umfang der FHEM Konfiguration genutzt werden oder nicht. Wenn überhaupt geht es um den Build Vorgang, aber den habe ich soweit im Griff. An der Betriebsstabilität des Images ändert sich da nichts.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 01 Februar 2019, 15:16:58
Habe immer wieder DockerImageInfo probleme .. Quasi jedermal wenn ich die fhem.cfg änder dann sagt er das DockerImageInfo doppelt wäre .. es ist aber nur einmal drin. Oder er sagt Dockerimageinfo wäre icht definiert .. IST ES ABER.
In fhem taucht es nicht auf.

Das Logg wird so schnell vollgemüllt jede Sekunde :
2019.02.01 15:06:43.416 1: readingsUpdate(,image.created,2019-01-28T08:24:47+0000) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.417 1: stacktrace:
2019.02.01 15:06:43.417 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.418 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.418 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.418 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.419 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.419 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.420 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.421 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.421 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.422 1: readingsUpdate(,image.description,A basic Docker image for FHEM house automation system, based on Debian Stretch.) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.422 1: stacktrace:
2019.02.01 15:06:43.423 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.424 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.424 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.424 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.425 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.425 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.425 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.426 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.426 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.426 1: readingsUpdate(,image.documentation,https://github.com/fhem/fhem-docker/blob/6d13de9d4fe7de225a2d80fd239b3da0e3d7bd87/README.md) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.427 1: stacktrace:
2019.02.01 15:06:43.427 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.427 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.428 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.428 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.428 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.429 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.429 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.429 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.430 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.430 1: readingsUpdate(,image.licenses,MIT) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.431 1: stacktrace:
2019.02.01 15:06:43.431 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.431 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.431 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.432 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.432 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.432 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.433 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.433 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.433 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.434 1: readingsUpdate(,image.revision,6d13de9d4fe7de225a2d80fd239b3da0e3d7bd87) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.434 1: stacktrace:
2019.02.01 15:06:43.435 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.450 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.451 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.451 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.451 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.451 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.455 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.455 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.455 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.465 1: readingsUpdate(,image.source,https://github.com/fhem/fhem-docker/) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.466 1: stacktrace:
2019.02.01 15:06:43.466 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.466 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.467 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.467 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.490 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.491 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.493 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.494 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.494 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.494 1: readingsUpdate(,image.title,fhem-amd64_linux) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.494 1: stacktrace:
2019.02.01 15:06:43.496 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.497 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.497 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.497 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.498 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.498 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.498 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.498 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.499 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.500 1: readingsUpdate(,image.url,https://hub.docker.com/r/fhem/fhem-amd64_linux) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.500 1: stacktrace:
2019.02.01 15:06:43.500 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.501 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.501 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.501 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.501 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.502 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.502 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.502 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.502 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.503 1: readingsUpdate(,image.vendor,FHEM) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.503 1: stacktrace:
2019.02.01 15:06:43.504 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.504 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.504 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.504 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.505 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.505 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.505 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.506 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.506 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.506 1: readingsUpdate(,image.version,5.9-s18439_v1.8.0-beta) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.507 1: stacktrace:
2019.02.01 15:06:43.507 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.508 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (57)
2019.02.01 15:06:43.508 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.509 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.510 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.510 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.510 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.511 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.511 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.526 1: readingsUpdate(,ssh-id_ed25519.pub,ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBgUiLkxSAOB3+mNxdiTzU9zWGGmq1gGfXq0S9rZZUDZ fhem@fhem-docker
) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.526 1: stacktrace:
2019.02.01 15:06:43.527 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.527 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (60)
2019.02.01 15:06:43.528 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.528 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.528 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.528 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.529 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.529 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.529 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:43.545 1: readingsUpdate(,ssh-id_rsa.pub,ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+nTH54VMOZQfSRhSt6qRgRaFujcGLP5MqZiR0U+Znnd7gxtv2PdB83vtcg/wAmZ9Eh4FMzNE45ESRPs5po4UpwQIxs03iDYJffZWASi6aOdqc1jbmTpRcQSm0dN5wLhylR1IsW/kkh8be1j96BcHgpHBlMbNrqoGbeAAoGQRkUnczvebulNe+SjkcqKlBZ6GbMtm9I3NrRufzo1eA9M+eOvDXL7wH2zIOLh5K7t7IZ97e648Aw+zWisTZDbiEEGO6s5LChJg03TFFVHKIAPu5+IjuCFMWxGQEFq3KBj8SP2vGiyV/2BSFWYge6Db/044no7TxeMFVEIzsmg3vTB+D fhem@fhem-docker
) missed to call readingsBeginUpdate first.
2019.02.01 15:06:43.545 1: stacktrace:
2019.02.01 15:06:43.546 1:     main::readingsBulkUpdate            called by fhem.pl (4689)
2019.02.01 15:06:43.546 1:     main::readingsBulkUpdateIfChanged   called by ./FHEM/99_DockerImageInfo.pm (61)
2019.02.01 15:06:43.547 1:     main::DockerImageInfo_GetImageInfo  called by (eval 33813) (1)
2019.02.01 15:06:43.547 1:     (eval)                              called by fhem.pl (1127)
2019.02.01 15:06:43.548 1:     main::AnalyzePerlCommand            called by fhem.pl (1152)
2019.02.01 15:06:43.548 1:     main::AnalyzeCommand                called by fhem.pl (1074)
2019.02.01 15:06:43.548 1:     main::AnalyzeCommandChain           called by ./FHEM/98_telnet.pm (255)
2019.02.01 15:06:43.550 1:     main::telnet_Read                   called by fhem.pl (3684)
2019.02.01 15:06:43.550 1:     main::CallFn                        called by fhem.pl (737)
2019.02.01 15:06:55.325 0: Strange call for typeless DockerImageInfo: DelayedShutdownFn
2019.02.01 15:06:55.335 0: Server shutdown
2019.02.01 15:06:55.355 0: Strange call for typeless DockerImageInfo: ShutdownFn

Auch wenn ich es aus der fhem.cfg ausbaue ..
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 01 Februar 2019, 18:01:12
DockerImageInfo ist aktuell nicht kompatibel mit rereadcfg und damit auch nicht mit dem direkten editieren der fhem.cfg. Ohnehin eine gute Idee die Datei nicht selbst zu editieren, dazu fordern dich hier sicherlich andauernd Leute auf. Wäre gut, es sein zu lassen ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 01 Februar 2019, 19:28:12
okay was kann ich machen damit ich da ssganze erstmal wegbekomme ? Spammt mein Log total zu.

Das direkte arbeiten geht aktuell nicht anders da ich neu anfange und backups aus der alten direkt reinkopiere
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 01 Februar 2019, 20:42:19
Warum postest Du nicht im "RAW" Mode? Dann brauchst Du die FHEM-Konfig nicht zu editieren .....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 01 Februar 2019, 20:45:21
Noch nie gemacht ;) Aber nu hab ich alles drin
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beddo am 02 Februar 2019, 00:25:43

Das geht zum Beispiel, indem du Befehle in das /pre-init.sh Script packst, welches dann beim allerersten Start des Containers ausgeführt wird. Wiederkehrende Befehle können in das /pre-start.sh Script gepackt werden. Beide Scripte musst du selbst erstellen und als Volume nach / mounten. In der docker-compose.yml Datei ist das dann ein weiterer Eintrag analog zu dem Eintrag für die Daten, die du nach /opt/fhem mountest.


Ok hiermit oute ich mich nun als zu doof.
Aber wie bekomme ich das gemountet.

Bsp:
            - ./fhem/data/:/opt/fhem/   # hier mounte ich die normale installation
            - ./fhem/config:/                # hier lege ich mein post-init.sh rein, dort führe ich ein apt-get aus und kopiere Beispielsweise meine eigene fhem.cfg, die controls.txt und für FTUI gleich meine html Files.

Beim Ausführen sagt mir docker-compose jedoch ich darf nach / nicht mounten
Lege ich mein post-init.sh - in meinem Beispiel unter ./fhem/data/ wird die Datei nicht ausgeführt.


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 02 Februar 2019, 11:00:32
Scheint nicht ganz offensichtlich, aber die Lösung ist ganz einfach: Du kannst auch einzelne Dateien und nicht nur Verzeichnisse in den Container mounten:


            - ./fhem/data/:/opt/fhem/
            - ./fhem/config/pre-init.sh:/pre-init.sh
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 04 Februar 2019, 09:35:02
nochmal um drauf zurück zu kommen wie kann ich das DockerInfo rausschmeißen ? Und wozu ist das gut ?
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 04 Februar 2019, 12:03:18
Das kann man nicht rausschmeißen, es ist integraler Bestandteil und informiert beispielsweise über die aktuelle Version des verwendeten Images.
Wenn du das nicht möchtest: Es zwingt dich niemand das Image zu verwenden.


Edit: Image 1.8.1 kann jetzt mit rereadcfg umgehen. Außerdem kann man das DockerImage Device löschen, das Modul bleibt jedoch im Speicher.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Julisch am 06 Februar 2019, 18:00:09
Wieso werden die Docker Images auf hub.docker.com je nach Architektur unterschiedlich getaggt?

Es sollte naheliegend sein, dass die jeweilige Version von FHEM konsistent für alle Architekturen gleich getaggt ist.

Stattdessen:

amd64 (https://hub.docker.com/r/fhem/fhem-amd64_linux/tags):
5.9-s18494_v1.8.1
5.9-s18494_v1.8.0-beta-14-gd6549d9-dev
5.9-s18494_v1.8.0-beta-13-g3e8bb8b-dev
5.9-s18491_v1.8.0

armhf (https://hub.docker.com/r/fhem/fhem-arm32v7_linux/tags):
5.9-s_v1.8.1
5.9-s_v1.8.0-beta-14-gd6549d9-dev
5.9-s_v1.8.0-beta-13-g3e8bb8b-dev
5.9-s_v1.8.0

Warum tut man so etwas?
Kann man das bitte korrigieren?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 Februar 2019, 18:42:24
Trotz deiner Ausdrucksart, danke für das Finding. Schaue ich mir gelegentlich genauer an.

Es dürfte jedoch nicht schwer sein zu erraten, dass das keineswegs Absicht ist und einfach nur die SVN Revision Nummer hinter dem s(=Subversion) fehlt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Julisch am 07 Februar 2019, 11:01:06
Danke. Das wäre ziemlich nice, wenn ihr das korrigieren könntet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 07 Februar 2019, 11:15:24
Was ist so schlimm daran, dass du dich vermutlich nur dafür registriert hast? 😄

Der Ton deiner Zeilen ist schon recht vorwurfsvoll.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 08 Februar 2019, 10:51:32
Derzeit finde ich keinen Grund dafür. Auf dem Build System sind alle Images richtig getaggt, beim "docker push" Befehl geht dann seltsamerweise eben dieser Teil des Tags verloren.
Ich tippe auf einen Fehler bei Docker Hub o.ä., immerhin gab es dort auch einige Umstellungen in der letzten Zeit.


Aus der Tag Historie der ARM Images geht auch hervor, dass alle Builds bis Version 1.4.4 korrekt getaggt waren.


Trotzdem ist die fehlende FHEM Revision kein Beinbruch, denn der mitgelieferte Versionsstand von FHEM spielt keine große Rolle. Bestandsinstallationen werden nicht über das Image aktualisiert und neue Setups auf der grünen Wiese sollten sowieso zu beginn immer noch ein "update" Kommando ausführen (siehe Diskussion hier früher bzw. Statement dazu von Rudi). Der entscheidende Teil über die Version des Systems um FHEM drum herum ist also nach wie vor gegeben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Julisch am 08 Februar 2019, 11:03:54
Vorsicht! Bei genauem Blick auf den Screenshot ist mir aufgefallen, dass Du arm32v5 gepusht hast. Im Docker Hub sind aber amd64 und arm32v5 korrekt. Da steht die Revisionsnummer korrekt im Tag mit drin.

Wo es nicht funktioniert sind arm32v7 und arm32v8. Wollt ihr euch vielleicht die beiden nochmal genauer angucken?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 08 Februar 2019, 11:22:17
Danke.


Ich denke ich konnte etwas finden und habe den Build Cache einmal geleert, anschließend sollte alles wieder einheitlich sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Julisch am 08 Februar 2019, 13:58:55
Jawohl! Hat funktioniert. Die Tags sind wieder konsistent. Vielen Dank! :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 13 Februar 2019, 19:26:24
Hallo zusammen,

ich steige gerade auf Docker um und wollte fhem nun auch umziehen.
Ich musste feststellen das das Image riesig ist und viele Funktionen vorhält welche ich garnicht nutze.
Ist es  möglich Funktionen wie z.B. Alexa über z.B. ENV Variablen raus zu nehmen, so das ich ein Image über docker-compose auf meine Anwendung zusammenbauen kann?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 13 Februar 2019, 19:46:47
Du kannst natürlich das Dockerfile nehmen und so anpassen, wie es dir beliebt. Es liegt alles auf Github (https://github.com/fhem).
Allerdings wirst du dann auch nicht am Update Prozess teilnehmen können und musst selbst für Kompatibilität sorgen.


Über das docker-compose YAML lässt sich das nicht steuern, denn das Image wird vorher gebaut. Das Image ist aktuell darauf ausgelegt heruntergeladen und direkt gestartet zu werden zu können, ohne dass die Startzeit erstmal langwierig Pakete herunterladen und nach installieren muss. Derzeit gibt es auch noch keine Möglichkeit überhaupt zu erkennen, welche fehlenden Pakete denn ein bestimmtes FHEM Modul hat, das wird noch eine ganze Weile dauern.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 13 Februar 2019, 21:09:14
Ja ich möchte hald gerne an Updates dann bleiben.
Wenn ich das dockerfile und das yaml vom git ziehe müsste es doch über eine env File konfigurierbar sein oder?
Bauen muss ich es dann damit natürlich selbst
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 Februar 2019, 00:26:53
Ich habe beim DEV Image (https://github.com/fhem/fhem-docker/blob/d19baafa669cc62b32501c88152eb58d93c12ff9/Dockerfile#L18-L25) einmal versucht die Image Layer optional über die folgenden Build Environment Variablen steuerbar zu machen:

IMAGE_LAYER_SYS_EXT="1"
IMAGE_LAYER_PERL_EXT="1"
IMAGE_LAYER_DEV="1"
IMAGE_LAYER_PERL_CPAN="1"
IMAGE_LAYER_PYTHON="1"
IMAGE_LAYER_NODEJS="1"

Setzt man eine dieser Variablen auf 0, dann sollte der entsprechende Layer nicht mit eingebaut werden.
Was jeweils im Layer enthalten ist oder nicht, kann man aus dem Dockerfile recht einfach aufgrund der Kommentare darin herauslesen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 14 Februar 2019, 20:47:27
Super, probier ich gleich aus.
Kurzerhand ist mir aufgefallen das du mehrmals ein "apt-get update " drin hast. Eins würde vermutlich reichen :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 Februar 2019, 20:51:01
Nee, is schon Absicht und muss auch so sein :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beddo am 14 Februar 2019, 20:59:49
Der integrierte node.js im aktuellen Image warnt er wäre veraltet, lässt sich aber über die fhem Oberfläche nicht aktualisieren. Generelles Problem, oder nur in meinen Setting?
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 Februar 2019, 21:16:13
Nicht node.js ist veraltet, sondern die Pakete der Node.js Inc liefern nicht die bleeding Edge Version des Paketmanagers NPM mit (siehe www.nodejs.org). Der NPM Paketmanager kann sich problemlos selbst aktualisieren und das funktioniert auch über das FHEM Modul npmjs.pm

Ansonsten: siehe hier
[42_npmjs.pm] Update von Node.js Paketen per NPM aus FHEM
 https://r.tapatalk.com/shareLink?share_fid=75100&share_tid=96525&share_pid=906144&url=https%3A%2F%2Fforum%2Efhem%2Ede%2Findex%2Ephp%3Ftopic%3D96525%2Emsg906144%23msg906144&share_type=t
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 15 Februar 2019, 11:50:20
Ich habe gerade eine neue Produktivversion v1.8.3 an das Build System geschickt:


- fix sudo Rechte
- Docker Container Capabilities werden als Readings in DockerImageInfo angezeigt
- verbessertes Startup Script


Als Hinweis: Node.js und NPM sind immer auf dem Stand, als das Image gebaut wurde. Es gibt keinen externen Trigger, der das Image neu baut, wenn es eine neue Version von Node.js oder eines NPM Paketes gibt. Dafür gibt es die Möglichkeit das über das npmjs.pm Modul über FHEM zu aktualisieren. Das ist also das gleiche wie mit FHEM auch: Wer mit einem frischen FHEM über den Container anfängt, der bekommt FHEM auf dem Stand des Tages, als das Image gebaut wurde und kann dann über den FHEM Update Befehl auf den neusten Stand aktualisieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 17 Februar 2019, 01:30:34
Mit der neuesten Version wird das Log 2018-02-17.log nicht mehr angezeigt.
Die (bei mir) Tageslogs werden seit dem Rebuild nicht mehr fortgeschrieben.
ENV gesetzt.

Nachtrag: oh, der Pfad muss nun anders angegeben werden.
-e LOGFILE=./log/fhem-%Y-%m.log
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schlimbo am 17 Februar 2019, 08:53:13
Hallo Loredo,
das FireTV (https://forum.fhem.de/index.php?topic=68748.0) Modul benötigt die ADB binary.
Wäre super wenn das noch in das Image mit aufgenommen werden könnte.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 19 Februar 2019, 07:54:30
Hallo Loredo,

Auf hub.docker.com steht "Updated 4 days ago".
Wie oft werden die Images aktualisiert?

Grüße
Stephan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 19 Februar 2019, 11:22:24
Auf hub.docker.com steht "Updated 4 days ago".
Wie oft werden die Images aktualisiert?


Im Grunde täglich, allerdings hatte ich vor einiger Zeit für die Produktiv-Images konfiguriert, dass nur Versiontags gebaut werden, weil die dann eben auf Github auch entsprechend grün werden. Dafür hatte ich abgeschaltet, dass bei generellen Änderungen am Master Branch auch ein Build ausgelöst wird, da diese sonst doppelt gemoppelt sind. Allerdings funktioniert dann offenbar die Cronjob Funktion von Travis nicht mehr...
Daher habe ich es jetzt wieder umgestellt und lebe leider mit dem fehlenden grünen Bubble auf Github  :'(


das FireTV (https://forum.fhem.de/index.php/topic,68748.0.html) Modul benötigt die ADB binary.


Habe ich gerade hinzugefügt.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 19 Februar 2019, 16:53:23
Ich bin immer noch am überlegen ob das der richtige Weg für fhem ist.
Wenn wir alle möglichen Pakete ergänzen für alle Eventualitäten die es gibt wird der Container immer schwerer handlebar.
(Auch die Grundidee ein begrenztes Minimalsystem für hoffentlich weniger Angriffsfläche zu bieten ist damit dahin.)

Wäre ein min basis fhem container eine Möglichkeit, welcher dann als From in compose files genutzt werden kann um Funktionen zu ergänzen?

(Ich versuche gerade zu vermeiden was eigenes zu machen, da ihr echt tolle Arbeit geleistet habt....)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 19 Februar 2019, 17:01:26
Es wird irgendwann ein "light" Image geben, aber dafür müssen erst andere Voraussetzungen geschaffen werden, damit das sinnvoll funktioniert. Die Fortschritte in dieser Richtung sieht man beim Thema 42_npmjs.pm (https://forum.fhem.de/index.php/topic,96525.0.html) oder Meta.pm (https://forum.fhem.de/index.php/topic,97589.0.html).
Aber auch die Github Aktivitäten (https://github.com/orgs/fhem/teams/3rd-party) spielen mit rein.

Du bist natürlich herzlich eingeladen tatkräftig zu unterstützen, meckern kann schließlich jeder  :P


Der Punkt ist: Das zu modular zu machen verkompliziert die Sache nur für alle Seiten. Wer jede Stellschraube ständig und immer selbst unter Kontrolle haben will, für den kann es nie was fertiges geben, mit dem er dann auch zufrieden sein wird. Da wird dann keine Seite mit glücklich werden. Deshalb: Bau selbst, was du maximal selbst kontrollieren willst.


Übrigens: Der Docker Container von Home Assistant ist doppelt so groß wie unserer. Nur mal um das ganze etwas einzuordnen.




Übrigens, die zweite: Was ist mit den Custom Build Options? Die sind doch genau das, was du willst? https://forum.fhem.de/index.php/topic,89745.msg905962.html#msg905962
Du kannst das Image selbst bauen und es klein halten und mit den pre-Scripts beim ersten Start selbst Kommandos ausführen, um fehlende Dinge zu ergänzen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: patlabor am 22 Februar 2019, 16:59:38
Hallo,

erstmal ein dickes Dankeschön für die tolle Arbeit. Mir ist letztes Jahr während den Weihnachtsfeiertagen meine alte Fhem installation abgeraucht, und ich habe die Gelegenheit genutzt fhem von 0 auf neu zu bauen und auf Docker umzustellen.
Jetzt habe ich gerade versucht meine Google Home Lautsprächer per googlecast zu integrieren.
Leider funktioniert das nicht so wirklich. Scheinbar ist das falsche Inline Python installiert
https://forum.fhem.de/index.php/topic,97702.0.html
Nachdem ich gestern Abend die dort angegebene Lösung versucht habe, ging es zumindes schon mal soweit das ich das device anlegen konnte, leider wurde der Lautsprecher aber nicht gefunden.
Habe dann den Hinweis gefunden das für googlecast der Container im Host mode laufen muß. Habe ich versucht, dabei wurde dann der Container neu gebaut und die Änderungen bezüglich Python wurden wieder zurück gesetzt.
Jetzt versuche ich seit heute morgen die Lösung von oben wieder umzusetzten, aber es will mir einfach nicht mehr gelingen. Ständig kommt die Meldung

Cannot load module GOOGLECAST
Und das Log spuckt folgendes aus:
Traceback (most recent call last):
  File "<string>", line 3, in <module>
ImportError: No module named pychromecast
2019.02.22 16:51:42.033 1: reload: Error:Modul 98_GOOGLECAST deactivated:
 Error -- py_eval raised an exception at /usr/lib/arm-linux-gnueabihf/perl5/5.24/Inline/Python.pm line 221.
BEGIN failed--compilation aborted at ./FHEM/98_GOOGLECAST.pm line 695.

2019.02.22 16:51:42.034 0: Error -- py_eval raised an exception at /usr/lib/arm-linux-gnueabihf/perl5/5.24/Inline/Python.pm line 221.
BEGIN failed--compilation aborted at ./FHEM/98_GOOGLECAST.pm line 695.

Auch bin ich mir nicht sicher ob das ganze dann funktionieren würde. Da ich traefik als proxy benutze habe ich ein docker netzwerk namens proxy für den container, wenn ich jetzt "network_mode: "host"" benutze, bekomme ich die meldung das etweder "network" oder "network_mode" benutzt werden kann, aber nicht beide. ich habe dann einfach
network:
   - proxy
   - internal
im docker-config file angegeben. zumindest ist der container dann gestartet, aber leider bekomme ich das googelcast modul nicht mehr zum laufen, kann daher auch nicht sagen, ob der google home jetzt gefunden wird.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 Februar 2019, 12:54:48
Mit Bezug auf diesen Beitrag von dir (https://forum.fhem.de/index.php/topic,45505.msg910365.html#msg910365) habe ich Inline::Perl jetzt aus dem CPAN statt dem mitgelieferten Debian Paket installiert.
Derzeit noch im DEV Image, demnächst dann auch im PROD Image.


Die anderen Teile deines Posts besprichst du ja bereits im anderen Thread und die sind dort auch richtig/besser aufgehoben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 28 Februar 2019, 09:33:52
Hiho,

habe eben versucht folgendes Modul im FHEM Docker Container zu nutzen:

https://forum.fhem.de/index.php/topic,79168.0.html


Dafür fehlt leider im Image das libxml-bare-perl.
Habe ich jetzt mal manuell im Container installiert, dann klappt es auch :)

Habe es jetzt erstmal über das pre-init script gelöst.

Wäre es möglich das mit in das Image einzubauen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 01 März 2019, 14:23:15
Hallo Loredo,

hatten wir schon mal, sollte das nicht täglich geupdatet werden?
Auf hub.docker.com steht "Updated 2 days ago".

Grüße
Stephan


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: vbs am 01 März 2019, 14:58:04
Habt ihr evtl. einen Tipp für mich, wie ich ein USB-Device in Docker sauber einbinden kann, dessen Bezeichnung sich potenziell ändern kann?

Ich würde gernen einen VOC-USB-Stick einbinden in einen Container den ich per compose starte. Der Stick ist momentan als "/dev/bus/usb/002/009" erreichbar. Wird aber beim nächsten Anstecken ein anderer Pfad sein.

Ich hab schon versucht, per udev eine Regel zu definieren, die das Gerät immer als Symlink auch nach "/dev/iaqstick" legt. Jedoch funktioniert der Stick nicht, wenn ich nur dieses Device dem Container bereit stelle. Aus der compose.yml:
    devices:
    - "/dev/iaqstick:/dev/iaqstick"

Das ist vermtl. eine bessere Beschreibung als ich sie zustande bringe:
https://github.com/moby/moby/issues/13840

Hat das jemand da eine schöne Lösung für? Danke!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 März 2019, 15:04:51


Habt ihr evtl. einen Tipp für mich, wie ich ein USB-Device in Docker sauber einbinden kann, dessen Bezeichnung sich potenziell ändern kann?


Hat das jemand da eine schöne Lösung für? Danke!

devices:
            #- " /dev/ttyUSB0:/dev/ttyUSB0" 
            #- " /dev/ttyUSB1:/dev/ttyUSB1"
            - "/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0:/dev/ttyUSB0" 
            - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A7031TM7-if00-port0:/dev/ttyUSB1"

Über Serial Boy ID?

Sieht bei mir so aus wie oben gepostet.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 März 2019, 15:06:28
Coole autocorrection :)   Serial by  ID natürlich
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: vbs am 01 März 2019, 15:13:42
Dieser VOC-Stick ist leider kein serielles Device und taucht deshalb nicht unter /dev/serial auf :(

T:  Bus=02 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#=  9 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
P:  Vendor=03eb ProdID=2013 Rev=10.00
S:  Manufacturer=AppliedSensor
S:  Product=iAQ Stick
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbfs

Driver ist "usbfs".
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 März 2019, 15:40:45
Ok. Sauber ist vielleicht das falsche Wort dafür aber so wird es gehen

Docker-compose mit einer .env datei nutzen

Beim Start des Servers den sym-link auswerten und eine Zeile (variable) in der .env mit der aktuellen Adresse  /dev/bus/USB... setzen. Name z.b. usbport

Im docker-compose eine Zeile
-{usbport}:/dev/usb1

Beim Start des Server ein docker-compose up ausführen. Wenn der port geändert wurde wird der Container neu erzeugt mit richtigem Link. Wenn der port gleich bleibt wird nichts neu generiert

Nachteilig ist halt die 2 Minuten Zeit die ggf. Benötigt werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: vbs am 01 März 2019, 15:59:34
Hm, hatte auch über sowas nachgedacht, aber bin mir wegen mindestens eins Punktes unsicher:
Wenn ich "restart: always" setze, dann wird der Container ja nach dem nächsten Reboot automatisch wieder gestartet (von irgendeinem Docker-Dienst offenbar). Ich vermute mal, dass dieser Docker-Dienst es ja nicht hinbekommen wird, auch erst automatisch diese Env-Variable auszuwerten und stattdessen den Container einfach gemäß des zuletzten gesetzten Wertes starten wird? Der wird dann wahrscheinlich nach dem nächsten Reboot ja nicht mehr stimmen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 März 2019, 16:08:11
Das ist richtig. Du kannst aber entweder den Dienst in systemd anpassen und ein docker-compose up einfügen oder einen eigenen Dienst schreiben.

Aber selbst wenn du docker starten lässt, würde das docker-compose up den Container neu starten. Du hättest ggf. Ein paar fehler im log.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: vbs am 01 März 2019, 20:50:05
Ok danke dir! Ist ja schonmal ein Weg. Noch schicker wäre es natürlich mit Docker-Bordmitteln.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 März 2019, 21:03:11
kennst du dich mit systemd aus? im ordner /etc/systemd/system/docker.service.d eine config eingefügt ändert den dienst ohne dass du viel machen musst. meine container downloads liegen bei mir extern ... beispiel meiner local.conf

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -g /media/SSD2/docker_lib -H unix://

an dieser Stelle könntest du " && sleep 5 && docker-compose up -d" einfügen.

läuft dein docker mit "privileged: true"? nicht empfohlen, aber manchmal nötig. Dann kannst du direkt auf den Host durchgreifen.

andere idee, /dev:/dev als volume mounten und beim systemstart mit docker exec -it <fhemcontainer> chown root:dailout ****   die Rechte ändern und über telnet in fhem ein defmod auf das DEVIO durchführen ... könnte gehen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 02 März 2019, 16:17:31
Du bist natürlich herzlich eingeladen tatkräftig zu unterstützen, meckern kann schließlich jeder  :P

Ja dann nehme ich dich beim Wort :)

Anbei ein angepasstes Dockerfile mit folgenden Anpassungen:
* Zusätzliches Argument für eine Light Konfiguration (460MB container) in kombination mit den anderen Argumenten "IMAGE_LAYER_"
   IMAGE_LAYER_FHEM_BASE_ONLY
   IMAGE_LAYER_PERL_CPAN_BASE_ONLY
* Zusätzliche Argumente indem man je nach Bedarf Pakete ergänzen kann
    IMAGE_USER_PACKAGES_DEBIAN
    IMAGE_USER_PACKAGES_PERL
    IMAGE_USER_PACKAGES_PERL_CPAN

Was denkst du?


-------------------------
Update:
- Eins ist mir noch aufgefallen. Bei einer Abschaltung von NodeJS über das Argument erscheint in FHEM immer noch das "npmjs" Device.
  Natürlich mit einem Fehler.
- Die neuen Argumente lassen sich jetzt über das Docker-Compose File setzten.
   (Die wurden vorher immer wieder über das DockerFile überschrieben)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 03 März 2019, 16:43:36
Bitte einen Pull Request auf Github fürs korrekte Source Handling und Bugtracking aufmachen.


PS: Sinn ist nicht, dass das Dockefile mit jeder möglichen Variable zugebombt wird. Ziel ist, dass es ein vorkompiliertes Image gibt und nicht, dass man sich das Image jedes Mal selbst neu bauen muss. Um die Wartbarkeit zu erhalten soll das Dockerfile nicht noch mehr wenn/dann/sonst bekommen als ohnehin schon.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 04 März 2019, 08:12:51
Dafür wurde bis jetzt das Dockerfile mit allen Möglichkeiten "zugebombt" ... also nicht gerade "leicht und einfach" aus Systemsicht ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 04 März 2019, 08:53:08
Dem stimme ich so nicht zu.


Du kannst das ganze auch nur aus Anwendersicht betrachten: Ob da jetzt ein paar Hundert Megabyte mehr oder weniger auf der Festplatte/SSD/Speicherkarte/younameit liegen, kratzt niemanden. Es geht um die Funktion - und dass bei FHEM so viele kunterbunte Komponenten verwendet werden, dafür kann niemand was (und man kann das auch als Vorteil auslegen). Was man aber versuchen kann ist dies zu ordnen (siehe z.B. auch anderer Thread über Meta.pm). Wenn das mal geordnet ist, dann kann man auch besser entscheiden welche Pakete man für welches FHEM Modul auch tatsächlich braucht - vorher geht das nicht. Zumindest ist es nicht Ziel dieses Docker Images hier, dass sich hinterher wieder jeder seine Pakete selbst zusammensuchen muss. Deshalb sind alle Pakete, die man brauchen könnte, solange mit im Image enthalten, bis ein Installer in FHEM die ganze Sache übernehmen kann. Ziel ist ein "it just works", kein Wettbewerb 100 MB weniger Speicherplatz zu verbrauchen - sowas ist in 2019 wirklich überflüssig. Ziel ist, dass man sich auf die Programmierung innerhalb von FHEM konzentrieren kann und nicht erst noch Tage und Wochen mit Systemabhängigkeiten verbringen muss. Genau dafür ist Docker gemacht und genau das machen wir hier auch damit.


Also nochmal: Wer granulare Kontrolle darüber haben möchte, welche einzelne Datei in seinem Docker Container liegt und jede kleine Stellschraube selbst kennen will (oder muss), der baue sich doch bitte seine eigene Dockerfile Datei zusammen. Ich kann diese ganze Diskussion hier überhaupt nicht nachvollziehen, denn es geht in meinen Augen wirklich nur um Gefühlssachen, nix weiter. Ein Argument "ja aber die Dateien sind doch da und wer weiß was man damit anfangen könnte als Angreifer!" lasse ich nicht gelten - ein System hat auch dann sicher zu sein, wenn Dateien da sind, Punkt. Dafür lässt sich Docker selbst prima in einer VM betreiben, mache ich auch so auf einem Proxmox Server. Docker ist nur das Vehicle für die einfache Bereitstellung der Systemumgebung.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 04 März 2019, 12:06:34
Was denkst du?


Ich habe das mal uminterpretiert und ein erweitertes Dockerfile ins DEV Image eingecheckt:
https://github.com/fhem/fhem-docker/commit/7558a19e55c405c301c52754e222811fdd51a6fe
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: vbs am 04 März 2019, 12:22:35
Schön hier mal eine ordentliche Nutzung von Git(Hub) zu sehen. Halte ich aus vielen Gründen für wesentlich besser als die Patchfile-Posterei übers Forum.  :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 04 März 2019, 14:18:10
Es ging mir nicht um den Speicherverbrauch, sondern mehr Software-Produkte = mehr Problemquellen

Eigentlich sollte es eine Light-Container geben, der bei den "Großcontainern" in der Docker-Compose reverenziert wird .... also "Verschachteltes" Bauen, wie es in der Regel gemacht wird.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 04 März 2019, 14:58:06
Ich sehe bei einem Paket, was dann nicht benutzt wird, keine größere Problemquelle. Es wird ja nichts selbst kompiliert (und selbst dann sind die Komponenten voneinander unabhängig).
Welche Probleme hast du denn konkret beobachtet?
Das einzige, was ich sehe ist, dass Leute Probleme damit haben, dass ihnen Komponenten fehlen, von denen sie nicht wissen, dass sie benötigt werden. Oder mit Tools, die die Komponenten installieren, nicht in geeigneter Weise umgehen, damit die Installation auch richtig ist. Das alles macht die Docker Umgebung so, dass alles funktioniert. Sie schafft aber IMHO keine neuen Problemquellen.

Was jedoch neue Problemquellen schafft, ist die höhere Maintenance von mehreren aufeinander aufbauenden Docker Paketen. Das kann man so machen und ich hatte ja auch schonmal angedeutet, dass es möglicherweise auch mal ein "light" Image geben könnte. Der Aufwand die Continuous Integration Umgebung daraufhin umzubauen ist aber nicht unerheblich und ich sehe für mein Vorhaben da absolut keinen Mehrwert, sondern nur Mehraufwand, den ich derzeit lieber in den FHEM Installer bzw. der Schaffung der richtigen Voraussetzungen für diesen stecke. Erst dann macht ein Light Image wirklich Sinn, bei dem man dann über den Installer selektiv einzelne Pakete nachinstallieren kann und diese dann auch automatisch wieder installiert werden, wenn man den Container neu erstellt.


Und wie gesagt: Wenn du meine Einschätzung nicht teilst oder nicht bereit bist dem vorgefertigten Image ein Stückweit Vertrauen entgegen zu bringen, dann kannst du doch auch deine eigene Dockerfile Datei schreiben und so gestalten, wie du sie brauchst? Dann weißt du auch garantiert, was drin ist. Du kannst nicht beides haben: 100% eigene Kontrolle _und_ alles vorgefertigt - du musst dich entscheiden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 04 März 2019, 18:21:56

Ich habe das mal uminterpretiert und ein erweitertes Dockerfile ins DEV Image eingecheckt:
https://github.com/fhem/fhem-docker/commit/7558a19e55c405c301c52754e222811fdd51a6fe (https://github.com/fhem/fhem-docker/commit/7558a19e55c405c301c52754e222811fdd51a6fe)


Außerdem kann man jetzt auch beim Containerstart über die selben Variablennamen die Installation ad-hoc mit einbauen:
https://github.com/fhem/fhem-docker/commit/8f9778754d6ef060957aa6f1c77665ce945e0b32
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beddo am 05 März 2019, 11:46:08

Dieser VOC-Stick ist leider kein serielles Device und taucht deshalb nicht unter /dev/serial auf :(

T:  Bus=02 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#=  9 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
P:  Vendor=03eb ProdID=2013 Rev=10.00
S:  Manufacturer=AppliedSensor
S:  Product=iAQ Stick
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbfs

Driver ist "usbfs".


Hallo vbs,

Hab das bei mir so gelöst:
Der Stick meldet sich mit lsusb bei mir so: "Bus 001 Device 004: ID 03eb:2013 Atmel Corp."
Dies ist auch nach einem Neustart des PIs so, oder wenn ich den Stick an einen frisch installierten Pi anstecke.

Auf einem neuen System folgendes in /etc/udev/rules.d/99-usb.rules einfügen (sonst läuft der Stick bei mir nicht)
[SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666" ```] 
dann reboot.


Da der Stick ja immer die gleiche Device ID hat, binde ich das in meiner docker-compose.yml so ein
 devices:
            - "/dev/bus/usb/001/004:/dev/bus/usb/001/004"

Läuft einwandfrei bei mir.
Hoffe das hilft Dir weiter.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beddo am 10 März 2019, 16:49:30
Hallo Zusammen,
hab mir heute das neue Dockerimage gezogen.
Seither spinnt mein fhem
1. ewig lange Startzeiten ~ rund 5 min
2. bei update kommt nur folgende Fehlermeldung:

https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: Bad hostname 'fhem.de:443'

Hat noch wer das gleiche Problem?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: vbs am 10 März 2019, 16:54:51
Hi beddo,
Der Stick meldet sich mit lsusb bei mir so: "Bus 001 Device 004: ID 03eb:2013 Atmel Corp."
das Problem bei mir ist, dass die Device-ID nicht stabil ist. Mindestens bei jedem Reconnect wird hochgezählt. Bin momentan bei 38 39: :o
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 039: ID 03eb:2013 Atmel Corp.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: patlabor am 10 März 2019, 19:29:47
Hallo Zusammen,
hab mir heute das neue Dockerimage gezogen.
Seither spinnt mein fhem
1. ewig lange Startzeiten ~ rund 5 min
2. bei update kommt nur folgende Fehlermeldung:

https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: Bad hostname 'fhem.de:443'

Hat noch wer das gleiche Problem?

Habe zwar nicht das gleiche Problem, habe aber seit einem Update heute morgen auch Probleme.
Mit latest geht leider gar nichts mehr, habe jetzt auf dev umgestellt, und jetzt bekomme ich das Log hiermit vollgespammt:
2019.03.10 19:20:39.128 1: ERROR evaluating { DockerImageInfo_GetImageInfo(); }: Undefined subroutine &main::DockerImageInfo_GetImageInfo called at (eval 35411) line 1.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beddo am 10 März 2019, 21:36:25
"...Bad hostname 'fhem.de..." klang für mich nach einem DNS Problem. War aber nur fhem. Handy&Desktop usw. im gleichen Netz hatten keine DNS Probleme.
Hab das Image gerade nochmal neu gezogen.
Nun läuft wieder alles.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 10 März 2019, 23:04:10
"...Bad hostname 'fhem.de..." klang für mich nach einem DNS Problem. War aber nur fhem. Handy&Desktop usw. im gleichen Netz hatten keine DNS Probleme.
Hab das Image gerade nochmal neu gezogen.
Nun läuft wieder alles.


Genau. Wenn dein DNS nicht erreichbar ist, blockiert FHEM. Das kann man mildern, indem man das globale Attribut dnsServer setzt. Das Startup Script aktualisiert das Attribut automatisch auf den Docker internen DNS Server (genauer den ersten DNS aus resolv.conf, den die Docker Engine aber in der Regel setzt), wenn es gesetzt ist.


Habe zwar nicht das gleiche Problem, habe aber seit einem Update heute morgen auch Probleme.
Mit latest geht leider gar nichts mehr, habe jetzt auf dev umgestellt, und jetzt bekomme ich das Log hiermit vollgespammt:
2019.03.10 19:20:39.128 1: ERROR evaluating { DockerImageInfo_GetImageInfo(); }: Undefined subroutine &main::DockerImageInfo_GetImageInfo called at (eval 35411) line 1.


Ich kann mit einem blank hochgefahrenen Container ohne bestehende FHEM Installation keinen Fehler feststellen.
Der Fehler liest sich als wenn du 99_DockerImageInfo.pm aus deiner FHEM Installation gelöscht hast. Das Modul wird jedoch vom Container angesprochen und daher benötigt. Du kannst zwar, wenn du willst, das DockerImageInfo Device in FHEM selbst löschen, aber die Moduldatei muss bleiben und würde auch bei einem neu erstellten Container wieder ins FHEM Verzeichnis kopiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 11 März 2019, 18:01:33
Ich habe mit dem Wakeonlan Module das Problem das es ohne Probleme ausgeführt wird aber scheinbar  aus dem docker Container nicht raus kommt.
Habt ihr eine Idee woran das liegt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 11 März 2019, 18:33:12
Ich habe mit dem Wakeonlan Module das Problem das es ohne Probleme ausgeführt wird aber scheinbar  aus dem docker Container nicht raus kommt.
Habt ihr eine Idee woran das liegt?

liegt wahrscheinlich daran, dass fhem (der User) kein rootrechte hat, wol aber etherwake nutzt. Ich rufe per SSH etherwake vom host, der user fhemusr existiert im HOst und hat sudo für etherwake ...

kurzfristig ....

Änderung in 98_WOL.pm Zeile 309 ... Voraussetzung SSH-Call vom Docker zum HOst mit Key und WOL-Modul "exclude from update"

  if (-e $sysWake) {
     $sysCmd =~ s/\$mac/$mac/;
     $sysCmd =~ s/\$sysInterface/$sysInterface/;
     Log3 $hash, 4, "[$name] executing $sysCmd";
     #qx (sudo $sysCmd);
qx (ssh fhemuser\@192.168.0.25 -p 444 -o StrictHostKeyChecking=no    "sudo $sysCmd -i wlan0")
  } else {
     Log3 $hash, 1, "[$hash->{NAME}] system command '$sysWake' not found";
  }

ggf. etherwake in sudo des containers zur langfristigen lösung.

Edit: wenn docker fhem im host-modul läuft müsste es jetzt schon gehen, wenn es bridged ist werden die magic packages nicht durchgelassen. Stichwort magic packet bridge, subnet ... sowas. Broadcasts werden nicht oder nicht immer weitergeleitet. Eine Netzwerksache, nicht unbedingt Docker.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: patlabor am 13 März 2019, 10:59:09

Ich kann mit einem blank hochgefahrenen Container ohne bestehende FHEM Installation keinen Fehler feststellen.
Der Fehler liest sich als wenn du 99_DockerImageInfo.pm aus deiner FHEM Installation gelöscht hast. Das Modul wird jedoch vom Container angesprochen und daher benötigt. Du kannst zwar, wenn du willst, das DockerImageInfo Device in FHEM selbst löschen, aber die Moduldatei muss bleiben und würde auch bei einem neu erstellten Container wieder ins FHEM Verzeichnis kopiert.

Hallo nochmal,

habe jetzt versuchsweise nochmal das Image gezogen, leider immernoch die gleiche Fehlermeldung. Genaugenommen steht das hier im Log:

2019.03.13 10:49:36.016 1: Including fhem.cfg
2019.03.13 10:49:36.061 1: reload: Error:Modul 99_DockerImageInfo deactivated:
 Can't locate FHEM/Meta.pm in @INC (you may need to install the FHEM::Meta module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM) at ./FHEM/99_DockerImageInfo.pm line 7, <$fh> line 11.
BEGIN failed--compilation aborted at ./FHEM/99_DockerImageInfo.pm line 7, <$fh> line 11.

Entfernt habe ich eigentlich gar nichts, weder in der config noch in Image. Am Sonntag morgen hat watchtower das neuste Image gezogen, seit dem habe ich dieses Problem.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 13 März 2019, 11:20:43
Aber hast du auch dein FHEM auf dem aktuellsten Stand? Dort kommt Meta.pm nämlich erst mit.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: patlabor am 13 März 2019, 15:35:15
Jetzt bin ich etwas verwirrt.
Ich habe Docker immer so verstanden, das ich eine gekapselte Umgebung unabhängig von meinem OS habe in der alles drin ist was der entsprechende Dienst braucht um zu funktionieren.
Sprich ich brauche mir keine Gedanken und die verschieden Abhängigkeiten und Versionen zu machen: Im Image ist alles drin was ich brauche.

Habe fhem im Container jetzt mal geupdated, und jetzt geht es auch wieder.

Solle aber in einem aktuellen Image auch nicht gleich die passende Version von fhem installiert sein?
Habe ich da irgendwas bezgl. Docker falsch verstanden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 13 März 2019, 16:29:14
Das ist bei FHEM anders. FHEM kann nicht über das Image aktualisiert werden, nur die Umgebung drum herum.
Das grundsätzliche Design von FHEM lässt das nicht anders zu.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: marty29ak am 17 März 2019, 00:22:10
Hallo, erst mal danke für deine Arbeit uns das Docker Image zu Verfügung zu stellen!!

Allerdings versuche ich mich schon den ganzen Tag  daran das ganze auf meinem Synology System ordentlich ans laufen zu bringen.
Grundsätzlich geht auch erst mal alles wie gewünscht, allerdings lastet das Fhem sobald ich meine fhem.cfg einspiele das NAS komplett aus.
Es funktioniert zwar alles normal weiter aber die vier Prozessoren sind durchgehen auf 100%. Wenn die fhem.cfg original vom Image bleibt habe ich die Effekt nicht. Der Fehler liegt also bei mir nur,....
finde einfach nicht den (sicher dummen) Fehler.
Vielleicht kann ja mal Jemand drüber schauen und mir einen Tip geben?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 17 März 2019, 09:01:14

Mit einem aktuellen 5.9-s18876_v1.10.2 Image habe ich den gleichen Effekt:

root@7fac1843c202:/opt/fhem# ps faxw
  PID TTY      STAT   TIME COMMAND
 2120 pts/0    Ss     0:00 bash
 2161 pts/0    R+     0:00  \_ ps faxw
    1 ?        Ss     0:00 /bin/bash /entry.sh start
  211 ?        S      0:00 perl fhem.pl fhem.cfg
  214 ?        S      0:00  \_ perl fhem.pl fhem.cfg
  216 ?        S      0:00      \_ sh -c echo n | node -e "console.log(JSON.stringify(process.versions));" 2>&1
  218 ?        Rl     1:22          \_ node -e console.log(JSON.stringify(process.versions));
 2160 ?        S      0:00 sleep 0.5
root@7fac1843c202:/opt/fhem# top

top - 08:39:48 up  6:54,  0 users,  load average: 2.62, 1.10, 0.41
Tasks:   8 total,   2 running,   6 sleeping,   0 stopped,   0 zombie
%Cpu(s): 21.3 us, 41.2 sy,  0.0 ni, 37.2 id,  0.2 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem :  2047036 total,   194320 free,   662796 used,  1189920 buff/cache
KiB Swap:  1048572 total,  1028840 free,    19732 used.  1201996 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                     
  218 fhem      20   0  157720  13304  12756 R  99.0  0.6   1:51.57 node                                                                                         
    1 root      20   0   19784   3544   3088 S   0.3  0.2   0:00.39 entry.sh                                                                                     
  211 fhem      20   0   90188  31724   4528 S   0.0  1.5   0:00.23 perl                                                                                         
  214 fhem      20   0   81352  28784   2120 S   0.0  1.4   0:00.00 perl                                                                                         
  216 fhem      20   0    4276    720    656 S   0.0  0.0   0:00.00 sh                                                                                           
 2120 root      20   0   19864   3836   3288 S   0.0  0.2   0:00.03 bash                                                                                         
 2511 root      20   0   44772   3580   3108 R   0.0  0.2   0:00.00 top                                                                                         
 2727 root      20   0    5828    684    620 S   0.0  0.0   0:00.00 sleep
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: marty29ak am 17 März 2019, 09:50:32
Wenn man die Zeilen für den Telnetport mit der Raute deaktiviert, scheint es das Problem nicht zu geben.

#define allowed_telnetPort allowed
#attr allowed_telnetPort allowedCommands on,off
#attr allowed_telnetPort globalpassword 1
#attr allowed_telnetPort room A_Global
#attr allowed_telnetPort validFor telnetPort
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 17 März 2019, 13:28:15
noch mal mit 5.9-s18929_v1.10.3 getestet. Sieht nach einem "node" Problem aus.
Warum das mit 100% CPU hängt ist mir unklar. Der gleiche Befehl via Shell kommt sofort zurück:
root@bc8aa69cf2e8:/opt/fhem# sh -c echo n | node -e "console.log(JSON.stringify(process.versions));" 2>&1
{"http_parser":"2.8.0","node":"10.15.3","v8":"6.8.275.32-node.51","uv":"1.23.2","zlib":"1.2.11","ares":"1.15.0","modules":"64","nghttp2":"1.34.0","napi":"3","openssl":"1.1.0j","icu":"62.1","unicode":"11.0","cldr":"33.1","tz":"2018e"}
root@bc8aa69cf2e8:/opt/fhem#

Grüße
Stephan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 18 März 2019, 10:34:51
noch mal mit 5.9-s18929_v1.10.3 getestet. Sieht nach einem "node" Problem aus.
Warum das mit 100% CPU hängt ist mir unklar. Der gleiche Befehl via Shell kommt sofort zurück:
root@bc8aa69cf2e8:/opt/fhem# sh -c echo n | node -e "console.log(JSON.stringify(process.versions));" 2>&1
{"http_parser":"2.8.0","node":"10.15.3","v8":"6.8.275.32-node.51","uv":"1.23.2","zlib":"1.2.11","ares":"1.15.0","modules":"64","nghttp2":"1.34.0","napi":"3","openssl":"1.1.0j","icu":"62.1","unicode":"11.0","cldr":"33.1","tz":"2018e"}
root@bc8aa69cf2e8:/opt/fhem#


Ich bekomme das bei mir leider nicht nachgestellt.  ???


Wenn man die Zeilen für den Telnetport mit der Raute deaktiviert, scheint es das Problem nicht zu geben.

#define allowed_telnetPort allowed
#attr allowed_telnetPort allowedCommands on,off
#attr allowed_telnetPort globalpassword 1
#attr allowed_telnetPort room A_Global
#attr allowed_telnetPort validFor telnetPort


Der lokale Telnet Port darf nicht beschränkt sein. Das braucht man auch nicht, solange man ihn nicht als "global" definiert.
Wer einen globalen Telnet Port braucht, legt einen separaten an, der dann geschützt werden kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 18 März 2019, 16:01:17
Hallo Loredo,

danke fürs nachschauen. Ist alles ok. War wohl bloß ein Docker Swarm Problem.

Grüße
Stephan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: adnan am 21 März 2019, 08:16:15
Hallo zusammen

Danke für das Docker Image. Ich betreibe mein Setup auf einem raspi 3 und das ganze läuft sehr stabil.

Ein problem habe ich aktuell noch:
FHEM/FhemUtils/uniqueID

D.h. jedesmal wenn ich den container neu erstelle (z.B. um auf das neueste Image zu wechseln), sind die dort abgelegten secrets im Eimer. Mein TelegramBot und der Alexa Skill speichern ihre Secrets in diesem File. Ich muss für den TelegramBot das Token dann nochmals neu setzen bzw. Alexa nochmals neu einrichten.
uniqueID ist irgendwie am host system gekoppelt, was in einem docker setup nicht so vorteilhaft ist.

Hat jemand eine Lösung für dieses Problem?
Von mir aus kann man die uniqueID auch komplett deaktivieren, falls jemand weiss wie das geht. Oder mindestens auf das neue Image migrieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 März 2019, 10:11:39
Hat jemand eine Lösung für dieses Problem?
Von mir aus kann man die uniqueID auch komplett deaktivieren, falls jemand weiss wie das geht. Oder mindestens auf das neue Image migrieren.

Wo liegen die Secrets? Sind das Dateien? Wenn ja, kannst du diese per docker cp in beide Richtungen kopieren ... https://docs.docker.com/engine/reference/commandline/cp/

Alternativ dazu, vorausgesetzt der Fhem-User im Container hat Schreibrechte, könntest das auch direkt aus Fhem machen lassen ... {qx (cp -p /<pfad>/file /opt/fhem/log/file_sik) } ... und beim Zurückspielen genau in umgekehrter Reihenfolge
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: adnan am 21 März 2019, 11:31:42
ich hab mein komplettes fhem directory als volume in den container ge-mounted.

Mein komplettes fhem und damit auch das File ist  persistent und verschwindet nicht, falls der container bzw. das image neu erstellt werden.
Daher muss ich das nicht kopieren.

Im textfile "FHEM/FhemUtils/uniqueID" werden passwörter, etc. verschlüsselt abgelegt.
Das Problem ist, das das "FHEM/FhemUtils/uniqueID" irgendwie am am host gekoppelt ist. Wenn ich einen neuen container nach einem image update starte, dann ist das wie ein neuer host und alle einträge in das "uniqueID" file sind nicht mehr valide, obwohl noch vorhanden und unverändert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 23 März 2019, 09:38:16
Dieses Problem ist mir nicht bekannt.
Wenn /opt/fhem als ganzes Volume behandelt wird, dann verschwinden Dateien nicht einfach so daraus. Dateien aus und in den Container zu kopieren ist nicht der richtige Weg dafür.
Bitte die README.md (https://github.com/fhem/fhem-docker/blob/dev/README.md) beachten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: arallon am 29 März 2019, 20:29:26
Betreibt das Image noch jemand auf Synology mit alexa-fhem?

Habe das heute versucht ans laufen zu bekommen. Wenn ich das aus dem Terminal starte mit dem user "fhem" (also alexa-fhem), dann startet der Service und ist erreichbar unter Port 3000.
Starte ich das ganze via definiertem Device bekomme ich immer das Problem mit den Berechtigungen auf dem home dir. (Ich habe ein Ordner eingebunden für /opt/fhem).
chmod Befehl als fhem/root haben bisher keine Abhilfe geschafft. Stehe wohl irgendwie auf dem Schlauch gerade.

Jemand ein Denkanstoss? Noch der letzte Step damit ich vom rasp umziehen kann.

Danke und Gruss
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 29 März 2019, 20:33:20
Die Berechtigungen für /opt/fhem werden beim Start des Containers automatisch durch das entry-Script korrigiert.
Ich verstehe nicht, was du hiermit meinst:


Starte ich das ganze via definiertem Device bekomme ich immer das Problem mit den Berechtigungen auf dem home dir.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: arallon am 29 März 2019, 20:55:26
ah ich meinte, wenn ich ein Device (alexa) im fhem anlege und dort via set Befehl starte.
Dann gibts das reading, dass etwas mit den Berechtigungen auf das home directory nicht passt und ein chmod 755 ausgeführt werden sollte.

alexaFHEM.ProxyConnection
error; user homedir writable by group/other ('chmod 755 /opt/fhem' required)


edit: das Problem scheint gelöst (alles neu und im terminal chmod hat jetzt geklappt) jetzt muss ich mir das mal anschauen, da ich noch 0.4.4 verwendet hatte vorher.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: adnan am 01 April 2019, 17:16:58
Dieses Problem ist mir nicht bekannt.
Wenn /opt/fhem als ganzes Volume behandelt wird, dann verschwinden Dateien nicht einfach so daraus. Dateien aus und in den Container zu kopieren ist nicht der richtige Weg dafür.
Bitte die README.md (https://github.com/fhem/fhem-docker/blob/dev/README.md) beachten.

Wie gesagt, ich kopiere die Dateien nicht aus dem Container. Ich mounte mein fhem root verzeichnis in den container als volume, gemäss der Anleitung. Ich nutze Docker-Compose für mein Setup.

Anders gefragt:
Hat jemand Telegram oder alexa-fhem am laufen? Falls ja, funktionieren diese zwei Geräte nach einem Image-Update noch korrekt?

Bei mir gehend diese zwei Geräte "kaputt", weil die tokens nach einem neuen image nicht mehr OK sind. Bei diesen zwei Plugins werden die tokens in der oben genannten Datei "uniqueID" gespeichert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 01 April 2019, 18:36:32
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.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nanocosmos am 04 April 2019, 19:29:00
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
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 04 April 2019, 21:26:00
Soweit ich weiß braucht Telegram keine eingehenden Ports.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag 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]
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: druschba am 05 April 2019, 19:49:29
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
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nanocosmos am 06 April 2019, 09:09:19
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?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 April 2019, 10:40:31
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.


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.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nanocosmos am 09 April 2019, 19:58:32
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

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: waschbaerbauch am 17 April 2019, 16:03:53
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
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 17 April 2019, 17:50:39
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
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 17 April 2019, 18:25:43
Gibt es evtl einen Port konflikt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 17 April 2019, 19:28:26
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

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: plin am 17 April 2019, 21:22:28
Wie sehen die beiden docker Commandlines aus mit denen du die beiden Instanzen angelegt/gestartet hast?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 17 April 2019, 22:02:31
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.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 20 April 2019, 07:12:27
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?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 April 2019, 08:43:19
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?


Geht das etwas genauer? Gibt es Meldungen im Log?
Es wäre sehr ungewöhnlich, wenn das Modul gar nicht laden würde, da es kaum mehr als ein Dummy Device ist. Die Datei wird beim Neuerstellen des Containers automatisch aktualisiert. Aber wenn du das FHEM Device einmal manuell gelöscht hast, wird es nicht wieder angelegt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 20 April 2019, 09:14:38
Naja Meldung ist can Not load Module und please definie device First.

Log sagt folgendes:

PERL WARNING: Subroutine DockerImageInfo_Initialize redefined at ./FHEM/99_DockerImageInfo.pm line 7, <$fh> line 2592.
2019.04.20 08:14:25 1: PERL WARNING: Subroutine DockerImageInfo_Define redefined at ./FHEM/99_DockerImageInfo.pm line 17, <$fh> line 2592.
2019.04.20 08:14:25 1: PERL WARNING: Subroutine DockerImageInfo_GetImageInfo redefined at ./FHEM/99_DockerImageInfo.pm line 58, <$fh> line 2592.
2019.04.20 08:14:25 0: Undefined subroutine &FHEM::Meta::InitMod called at ./FHEM/99_DockerImageInfo.pm line 13, <$fh> line 2592.
Habe das device aber nie manuell gelöscht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 20 April 2019, 09:31:09
Habe eben Mal ein Update vom fhem gemacht, jetzt klappt's wieder.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 20 April 2019, 19:58:31
Ich rätsel ja immer noch, wie ich am besten die Bluetooth-Schnittstelle meines Raspberry Pi 3 in FHEM nutzen kann.

Also ich weiß, dass es im Netmode host geht. Allerdings ist der Container dann ja nicht mehr im Docker-Netzwerk, wie die anderen Container. Das gute jetzt ist ja gerade, dass die Container von FHEM, Nodered und MQTT kommunizieren können, ohne das ich alle Ports nach außen öffnen musste.
Mit dem Netmode host fällt das ja flach, außerdem ist mir das Sicherheitsgründen nicht ganz so genehm.

Kennt ihr vielleicht eine andere Möglichkeit? Oder kann ich mit Bluetooth Dongles vielleicht auf den Netmode host verzichten? Hab tagelang gegoogelt und eben nur diesen einen Weg gefunden...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 April 2019, 20:35:26
Da ist die Frage, was Du mit ereihen willst, also "machen".

Eventuell solltest Du für diese Sache einen eigenen Container hochziehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 20 April 2019, 21:43:43
Eventuell solltest Du für diese Sache einen eigenen Container hochziehen.

Ein eigener Container nur für die Bluetooth-Verbindung? Wie soll das funktionieren? Ich will ja von FHEM über dieses Modul https://wiki.fhem.de/wiki/XiaomiBTLESens auf den Sensor per BLE zugreifen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 April 2019, 21:51:21
gatttool und hcitool laufen beide in der Shell, das geht theoretisch auch remote per SSH. Aber ob Cooltux das Modul so gebaut hat, weiß ich nicht. Das Prinzip generell gibt es bei Fhem aber an diversen Stellen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 20 April 2019, 22:58:45
tatsächlich geht das..
es gibt das Attribute sshHost, nur leider kommt bei mir jetzt die Fehlermeldung:
2019.04.20 22:47:18 4: XiaomiBTLESens (xiaomi_FlowerCare_Bonsai) - Run CreateParamGatttool with mod: read,
2019.04.20 22:47:18 5: XiaomiBTLESens (xiaomi_FlowerCare_Bonsai) - Read XiaomiBTLESens_ExecGatttool_Run xiaomi_FlowerCare_Bonsai|C4:7C:8D:6A:91:5C|read|0x38,
2019.04.20 22:47:18 4: XiaomiBTLESens (xiaomi_FlowerCare_Bonsai) - stateRequestTimer: Call Request Timer,
No user exists for uid 6061
,
2019.04.20 22:47:18 5: XiaomiBTLESens (xiaomi_FlowerCare_Bonsai) - ExecGatttool_Done: gatttool return string: xiaomi_FlowerCare_Bonsai|C4:7C:8D:6A:91:5C|error|read|0x38|{"gtResult":"no gatttool binary found. Please check if bluez-package is properly installed"},
2019.04.20 22:47:18 4: XiaomiBTLESens (xiaomi_FlowerCare_Bonsai) - ProcessingErrors,
2019.04.20 22:47:18 4: XiaomiBTLESens (xiaomi_FlowerCare_Bonsai) - WriteReadings: Readings were written

leider weiß ich nicht, wie ich den Docker-Container und Host einrichten muss, das der Docker-Container sich verbindet.

lt CoolTux im Wiki:
sshHost - FQDN oder IP-Adresse eines entfernten SSH-Systems. Das SSH-System ist auf Keyfile basierte Authentifizierung zu konfigurieren. Am elegantesten geschieht das mit einer .ssh/config Datei auf dem SSH-Client.

nur wie wird das gemacht? das übersteigt mein Verständnis. ich glaub ich muss den Public-Key (den ich aus Dockerinfo-Device bekomme) in Authorized_Keys im Host-System packen.. aber mehr weiß ich nicht...

Edit
Achso ich weiß nicht, wie ihr mittlerweile die USB-Geräte einbindet?
Aber ich kann ganz entspannt Serial/by-id nutzen.. habt ihr das mitlerweile auch drin?
--> für mein Signalduino mappe ich einfach das /dev/serial/by-id:/dev/serial/by-id als Volume... und schon kann ich es in Fhem direkt damit ansprechen.. falls das bekannt ist, könnt ihr mein Kommentar ignorieren.. hatte das bisher noch nicht gelesen...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 21 April 2019, 03:55:46
Also, vielen Dank für den Tipp mit der SSH-Verbindung! Genau das, was ich gesucht habe. Funktioniert bei mir nach 1,5 Stunden frickelei auch :)

Leider muss man ein Keyfile nutzen, um das Modul mit dem Host per SSH zu verbinden. Eigentlich ja ganz einfach:
1. Auf dem Host mit ssh-keygen -b 4096 ein solches erstellen
2. Dieses mit ssh-copy-id -i ~/.ssh/id_rsa.pub pi@raspberrypi als Login-Methode hinzufügen
3. Jetzt noch dafür sorgen, dass der Container den Private Key nutzen kann, also als Volumen einbinden:
-v /home/pi/.ssh/id_rsa:/opt/fhem/.ssh/id_docker_host

Nun wird es etwas kompliziert, ich hoffe @Loredo kann da weiter helfen.
4. Wir müssen nun die SSH Config von FHEM anpassen. Am besten auf dem Host als Root die Datei *euer persistentes FHEM-Verzeichnis*/.ssh/config öffnen und am Ende das einfügen:
Host docker-host
    HostName 172.17.0.1
    User pi
    IdentityFile ~/.ssh/id_docker_host

5. Als letztes habe ich den FHEM-Container kurz interactive gestartet (Benutzer fhem!), und per ssh docker-host die erste Verbindung hergestellt, damit der Fingerprint vom SSH Server in der Liste der bekannten Hosts steht.

Edit2: Alternative in der ssh config noch diese Zeile unter der Host-Direktive hinzufügen: StrictHostKeyChecking no
Damit hätten wir dann aber einen Unsicherheitsfaktor.

So, zwei großes Fragen:
Seht ihr hier irgendwelche eklatanten Sicherheitsprobleme?
Wie kann ich die letzten zwei Schritte möglichst automatisiert erledigen?

Edit: Im Bluetooth Modul wird als sshHost natürlich docker-host eingetragen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 21 April 2019, 03:58:39
Edit
Achso ich weiß nicht, wie ihr mittlerweile die USB-Geräte einbindet?
Aber ich kann ganz entspannt Serial/by-id nutzen.. habt ihr das mitlerweile auch drin?
--> für mein Signalduino mappe ich einfach das /dev/serial/by-id:/dev/serial/by-id als Volume... und schon kann ich es in Fhem direkt damit ansprechen.. falls das bekannt ist, könnt ihr mein Kommentar ignorieren.. hatte das bisher noch nicht gelesen...

Steht so ähnlich sogar in der Readme auf Github. Allerdings weiß ich nicht, was der unterschied zwischen -v /dev/serial/by-id:/dev/serial/by-id und  --device=/dev/serial/by-id ist. Vermutlich gar keiner.
Aber wie gesagt, bei Bluetooth funktioniert der Weg leider nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nightstorm99 am 21 April 2019, 08:13:59
Hallo Loredo,

kannst du bitte folgende Perl Pakete mit ins Image aufnehmen?
- DateTime::Event::Sunrise
- Date::Calc

Diese brauche ich für ein paar Scripte. Ansonsten super Arbeit.

Laut WIKI soll es auch damit gehen:
- CPAN_PKGS="App::DateTime::Event::Sunrise App::Date::Calc"
aber leider will es nicht.

Danke und Schöne Ostern

Denny
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 April 2019, 09:21:24

Wie kann ich die letzten zwei Schritte möglichst automatisiert erledigen?

Edit: Im Bluetooth Modul wird als sshHost natürlich docker-host eingetragen.

ich habe das vollautomatisch in meinem Docker-Updatescript. ssh-keyscan trägt den ssh-host ein damit keine Abfrage zu neuem / geänderten ssh-host erscheint.

# fhemusr ist mein SSH-User, nutze keinen Raspi, kann auch mit user PI gemacht werden. Dann fhemusr durch pi tausch
cd /home/fhemusr/.ssh
#Datei aus Docker kopieren     fhem = name des Docker Containers
docker cp fhem:/opt/fhem/.ssh/id_rsa.pub id_rsa.pub
#authorized_keys erstellen     fhem = User unter dem fhem im Container läuft, default fhem
echo  $(cat ./id_rsa.pub | cut -d" " -f1,2) "fhem@"$(docker ps | grep -i fhem | cut -d" " -f1) > authorized_keys
#Owner setzen    ggf. fhemuser durch pi tauschen, (wie oben, ssh-User)
chown fhemusr:fhemusr authorized_keys
#Berechtigung
chmod 700 authorized_keys
#Key löschen
rm -r id_rsa.pub
#SSH-Key bekannt machen - 172.17.0.1 default IP des Docker hosts, ggf. anpassen
#docker exec -it fhem  ssh-keygen -f "/opt/fhem/.ssh/known_hosts" -R [172.17.0.1]:22
docker exec -it fhem sh -c 'ssh-keyscan -H 172.17.0.1 >> /opt/fhem/.ssh/known_hosts'
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 21 April 2019, 12:17:38
Ich habe im DEV Image jetzt mal die DNS Auflösung für "host.docker.internal" nebst automatischer SSH Host Key Aktualisierung eingebaut.
Über diesen DNS Namen kann man dann automatisch eine SSH Verbindung zum Docker Host aufbauen. Bitte einmal testen.


Laut WIKI soll es auch damit gehen:
- CPAN_PKGS="App::DateTime::Event::Sunrise App::Date::Calc"
aber leider will es nicht.


Geht hier, gerade getestet. Natürlich heißen die beiden Perl Module aber "DateTime::Event::Sunrise" und "Date::Calc" - wie du auf den Präfix "App::" kommst, ist mir unverständlich.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 21 April 2019, 12:49:29
Ich habe im DEV Image jetzt mal die DNS Auflösung für "host.docker.internal" nebst automatischer SSH Host Key Aktualisierung eingebaut.
Über diesen DNS Namen kann man dann automatisch eine SSH Verbindung zum Docker Host aufbauen. Bitte einmal testen.

sorry...
fühle mich dazu echt zu doof.. weiß aj nicht mal wo das update-script hingeschrieben werden müsste.. muss ich das im Host oder im Docker-Image ausführen?
in welche datei für den Docker muss es rein.. unter /fhem/core/pre-start.sh???? oder wo...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 21 April 2019, 12:51:06
Wenn das so ist, wartest du einfach ab, bis es eine neue Produktiv-Version des Docker Images gibt und erstellst dann den Container einfach neu.
Das neue Prod Image baut gerade und ist so in 2h verfügbar.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 April 2019, 15:39:07
Ich habe im DEV Image jetzt mal die DNS Auflösung für "host.docker.internal" nebst automatischer SSH Host Key Aktualisierung eingebaut.
Über diesen DNS Namen kann man dann automatisch eine SSH Verbindung zum Docker Host aufbauen. Bitte einmal testen.

gute Idee, habe es getestet. Funktioniert. Danke
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 21 April 2019, 19:24:48
Hab jetzt mal das dev vom FHEM-Build gemacht. und unter enviroment DOCKER_HOST=172.27.0.1 eingefügt. Wobei mein Fhem die 172.27.0.6 als IP hat...
leider kommt unter FHEM Folgende Meldung:
ssh: connect to host host.docker.internal port 22: Connection refused
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 April 2019, 19:47:17
hast du ssh für den User auf dem Host konfiguriert? Gibt es den Ordner bzw. die Datei ? /home/<user>/.ssh/authorized_keys   

<user> ist bei dir ggf. PI

Wenn nicht musst du erstmal SSH konfigurieren. Hat aber nichts mit Docker zu tun.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 21 April 2019, 19:53:46
hast du ssh für den User auf dem Host konfiguriert? Gibt es den Ordner bzw. die Datei ? /home/<user>/.ssh/authorized_keys   

<user> ist bei dir ggf. PI

Wenn nicht musst du erstmal SSH konfigurieren. Hat aber nichts mit Docker zu tun.

Hallo,

also ssh ist eingerichtet... (komme per Putty ja drauf.. auch mit einem zweiten Schlüssel..)
es gibt im Host die datei authorized_keys mit 2 Schlüssen, der 2. ist für Putty, der erste ist (zumindest die letzten 7 Zeichen) gleich dem, welcher unter fhem/core/.ssh/id_rsa.pub drinn steht...

okay. weiter oben hab ich meinen Fehler entdeckt.. ich hab das enviromental host herausgenommen.. und neu gestartet.. und gateway eingesetzt...
jetzt kommt "leider" die nächste Fehlermeldung:

Host key verification failed.

....
ich probiere es mal weiter
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 April 2019, 20:00:12
Host key verification failed.

....
ich probiere es mal weiter

das bedeutet dass die Keys nicht zusammenpassen.

du kannst mal die Schritte aus meinem Post https://forum.fhem.de/index.php/topic,89745.msg932018.html#msg932018
testen, das ist die Minimalkonfiguration in einem Script das bei mir problemlos alles anlegt was ich brauch. Du muss nur aufpassen dass du die bestehende Konfiguration nicht überschreibst sonst funktioniert die aktuelle Konfig nicht mehr über Putty.

edit. die letzte Zeile ist nicht mehr nötig, das ist jetzt im Docker schon drin (ssh-keyscan)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nightstorm99 am 21 April 2019, 20:16:24
Geht hier, gerade getestet. Natürlich heißen die beiden Perl Module aber "DateTime::Event::Sunrise" und "Date::Calc" - wie du auf den Präfix "App::" kommst, ist mir unverständlich.

Ich bekomme trotzdem die Fehlermeldungen:
2019.04.21 20:11:03 1: reload: Error:Modul 99_SUNRISE deactivated:
 Can't locate DateTime/Event/Sunrise.pm in @INC (you may need to install the DateTime::Event::Sunrise module) (@INC contains: . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base ./FHEM ./FHEM/lib) at ./FHEM/99_SUNRISE.pm line 14, <DATA> line 1.
BEGIN failed--compilation aborted at ./FHEM/99_SUNRISE.pm line 14, <DATA> line 1.

2019.04.21 20:11:03 1: reload: Error:Modul 99_myUtilsBewaesserung deactivated:
 Can't locate Date/Calc.pm in @INC (you may need to install the Date::Calc module) (@INC contains: . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base ./FHEM ./FHEM/lib) at ./FHEM/99_myUtilsBewaesserung.pm line 13, <DATA> line 1.
BEGIN failed--compilation aborted at ./FHEM/99_myUtilsBewaesserung.pm line 13, <DATA> line 1.

2019.04.21 20:11:03 1: Including fhem.cfg
2019.04.21 20:11:03 1: reload: Error:Modul 99_SUNRISE deactivated:
 Can't locate DateTime/Event/Sunrise.pm in @INC (you may need to install the DateTime::Event::Sunrise module) (@INC contains: . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base ./FHEM ./FHEM/lib) at ./FHEM/99_SUNRISE.pm line 14, <$fh> line 11.
BEGIN failed--compilation aborted at ./FHEM/99_SUNRISE.pm line 14, <$fh> line 11.

2019.04.21 20:11:03 1: reload: Error:Modul 99_myUtilsBewaesserung deactivated:
 Can't locate Date/Calc.pm in @INC (you may need to install the Date::Calc module) (@INC contains: . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base ./FHEM ./FHEM/lib) at ./FHEM/99_myUtilsBewaesserung.pm line 13, <$fh> line 11.
BEGIN failed--compilation aborted at ./FHEM/99_myUtilsBewaesserung.pm line 13, <$fh> line 11.

Ich starte FHEM über docker-compose! Kann es daran liegen?

Danke und Gruß
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 21 April 2019, 20:24:13
das bedeutet dass die Keys nicht zusammenpassen.

du kannst mal die Schritte aus meinem Post https://forum.fhem.de/index.php/topic,89745.msg932018.html#msg932018
testen, das ist die Minimalkonfiguration in einem Script das bei mir problemlos alles anlegt was ich brauch. Du muss nur aufpassen dass du die bestehende Konfiguration nicht überschreibst sonst funktioniert die aktuelle Konfig nicht mehr über Putty.

edit. die letzte Zeile ist nicht mehr nötig, das ist jetzt im Docker schon drin (ssh-keyscan)

Also im Endeffekt muss ich nach der heutigen Änderung am FHEM Container nur noch den SSH Public Key von FHEM in die Datei mit den autorisierten Keys auf dem Docker Host eintragen? Muss ich nicht noch im Container festlegen, unter welchem Nutzer sich dann das FHEM Modul auf dem Host einloggen soll?

Ich hatte das ja ursprünglich in der ssh config von FHEM noch rein geschrieben.
Oder erkennt der SSH-Server zu welchen Nutzer das Zertifikat passt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 21 April 2019, 20:27:56
das bedeutet dass die Keys nicht zusammenpassen.

du kannst mal die Schritte aus meinem Post https://forum.fhem.de/index.php/topic,89745.msg932018.html#msg932018
testen, das ist die Minimalkonfiguration in einem Script das bei mir problemlos alles anlegt was ich brauch. Du muss nur aufpassen dass du die bestehende Konfiguration nicht überschreibst sonst funktioniert die aktuelle Konfig nicht mehr über Putty.

edit. die letzte Zeile ist nicht mehr nötig, das ist jetzt im Docker schon drin (ssh-keyscan)

ich habe exakt dein Skript ablaufen lassen. hab die authorized_keys datei gelöscht, hab das Skript nochmals ausgeführt, und natürlich mein eigenen ssh-Key für putty als 2. Zeile wieder eingefügt..
trotzdem kommt unter Portainer die nachricht, das ich ein Password eintippen sollen..
fhem@7ff36a02548d:~$ ssh gateway.docker.internal
The authenticity of host 'gateway.docker.internal (172.27.0.1)' can't be established.
ED25519 key fingerprint is SHA256:yfBgWbH7kLL/xWUDluoAG/jmVdJ9tu5F+iky8lSyID0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gateway.docker.internal' (ED25519) to the list of known hosts.
fhem@gateway.docker.internal's password:

edit: okay mir ist beim start von fhem folgendes aufgefallen:

13. Adding gateway.docker.internal to /etc/hosts ...
/entry.sh: line 376: [: 62.138.238.45: binary operator expected

was hat das zu bedeuten?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 April 2019, 20:55:14
Also im Endeffekt muss ich nach der heutigen Änderung am FHEM Container nur noch den SSH Public Key von FHEM in die Datei mit den autorisierten Keys auf dem Docker Host eintragen? Muss ich nicht noch im Container festlegen, unter welchem Nutzer sich dann das FHEM Modul auf dem Host einloggen soll?

SSH-Aufruf syntax     ssh [-p <port>]<user>@<host> 

Angenommen du willst auf dem Host den User pi nutzen  dann wäre der aufruf      ssh pi@host.docker.internal
Wenn alles richtig eingerichtet ist kommst du ohne Passwort drauf.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 April 2019, 20:58:53

Warning: Permanently added 'gateway.docker.internal' (ED25519) to the list of known hosts.


versuche Host       host.docker.internal     nicht gateway.docker.internal auch wenn es auf das selbe Ziel zeigt. Im Docker wird der "host.docker.internal" zu den "known_hosts" hinzugefügt. Gateway.docker.internal ist dort nicht bekannt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 21 April 2019, 21:43:14
SSH-Aufruf syntax     ssh [-p <port>]<user>@<host> 

Angenommen du willst auf dem Host den User pi nutzen  dann wäre der aufruf      ssh pi@host.docker.internal
Wenn alles richtig eingerichtet ist kommst du ohne Passwort drauf.

oh man.. da bin ich echt dämlich...
mit pi@gateway.docker.internal funzt es....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 April 2019, 22:03:08
@Loredo, ich glaub ich habe einen Fehler gefunden. Folgendes Verhalten, beim neu Erstellen des Containers funktioniert ssh. Sobald ich aber mit "docker stop fhem" und später mit "docker start fhem" den Container neu starten lasse ist ssh korrupt.

Fehlermeldung:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:IpQswZKmXC4Y+S9QMsIOOmgeNdNm+KOVMFoBAmKzdsw.
Please contact your system administrator.
Add correct host key in /opt/fhem/.ssh/known_hosts to get rid of this message.
Offending RSA key in /opt/fhem/.ssh/known_hosts:3
  remove with:
  ssh-keygen -f "/opt/fhem/.ssh/known_hosts" -R host.docker.internal
ED25519 host key for host.docker.internal has changed and you have requested strict checking.
Host key verification failed.

die known_hosts wird durch docker restart verändert
host.docker.internal ssh-ed25519 -- dieser Eintrag wird gelöscht. Wenn dieser wieder eingefügt wird funktioniert auch SSH wieder

host.docker.internal ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEKqC6ot6Kw2IviHcuodBWSbasL80S+a3WGkl/xxxx


known_hosts direkt nach docker up
host.docker.internal ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEKqC6ot6Kw2IviHcuodBWSbasL80S+a3WGkl/xxxxxx
[fhem-va.fhem.de]:58824,[288.199.311.302]:58824,[2a01:4f8:10a:806::ff]:58824 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCcTyjPHgeBFgxtOmq8aZWOXyJU1K57cGyllhV1YhIbzM8MAjdhLV54vTcDKyoDszjug24luyU+OnCHfgyeo9mFZdM93vJI0LrB8fQWSHXD2tjBhDwxGhxm0ksqlDFP3h3ZFP6HoXzrOP69ucqLSKv8/cfkvpp2kfxRMxHGjsfroNHOHmwUtBy80wh/XNcUikOBqQ7aZiCQWGkdJLHEFWgTT1VQ9P7ZkNe33bG+TICc4LF05DqDIZbD4zqhfKj/oNCgmm+vxQU2GQc/FZBjxO6+qtkcO7Ne0kksI3L2xcEyvkJOm1GUvwB0tDJQSiNfbc6lEzEZx6MOUL3SY00xxxxx
host.docker.internal ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDTd/Vr3VF0CUh21PIs8nOQtI//Gd6AVY+FvciR5drWzFdgNrDnUAht+wm+2A8PKBt2mwLrW+FbgAJWj+z/JEXss27X4iwGWDv2hH6fdThRDhuDgbK+zy/u0eEnZjzeo6MfIyYuCyf5TWxvtrKhgzaU+o9vWO+djpiVo7lie5Y+ANHGmoCo4vLg8s/nLr0+NYrlv+qIYjRqPgCd8cDK3k/CY75qkfkpVixy20Ub74M83IK7A0V5fQM4rBDsvbLbnWljWWflbXYdt2c+2d3/Q8cJTPrBt2yyn9LMGfS/T7PMCuABWNpDO/P2RiNvf4k8CMJV8vCKpv3ldzMjxxxxxx
|1|PaBSQYio/NtnXeELAFyzeeNyDzo=|rXfRtghxdRqqhfclxapOlcyvyyM= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEKqC6ot6Kw2IviHcuodBWSbasL80S+a3WGkl/xxxx


known_hosts nach docker stop / start
|1|PaBSQYio/NtnXeELAFyzeeNyDzo=|rXfRtghgdRqqhfclxapOlcyvyyM= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEKqC6ot6Kw2IviHcuodBWSbasL80S+a3WGkl/xxxxx
[fhem-va.fhem.de]:58824,[288.199.311.302]:58824,[2a01:4f8:10a:806::ff]:58824 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCcTyjPHgeBFgxtOmq8aZWOXyJU1K57cGyllhV1YhIbzM8MAjdhLV54vTcDKyoDszjug24luyU+OnCHfgyeo9mFZdM93vJI0LrB8fQWSHXD2tjBhDwxGhxm0ksqlDFP3h3ZFP6HoXzrOP69ucqLSKv8/cfkvpp2kfxRMxHGjsfroNHOHmwUtBy80wh/XNcUikOBqQ7aZiCQWGkdJLHEFWgTT1VQ9P7ZkNe33bG+TICc4LF05DqDIZbD4zqhfKj/oNCgmm+vNQU2GQc/FZBjxO6+qtkcO7Ne0kksI3L2xcEyvkJOm1GUvwB0tDJQSiNfbc6lEzEZx6MOUL3SY00xxxxx
host.docker.internal ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDTd/Vr3VF0CUh21PIs8nOQtI//Gd6AVY+FvciR5drWzFdgNrDnUAht+wm+2A8PKBt2mwLrW+FbgAJWj+z/JEXss27X4iwGWDv2hH6fdThRDhuDgbK+zy/u0eEnZjzeo6MfIyYuCyf5TWxvtrKhgzaU+o9vWO+djpiVo7lie5Y+ANHGmoCo4vLg8s/nLr0+NYrlv+qIYjRqPgCd8cDK3k/CY75qkfkpVixy20Ub74M83IK7A0V5fQM4rBDsvbLbnWljWWflbXYdt2c+2d3/Q8cJTPrBt2yyn9LMGfS/T7PMCuABWNpDO/P2RiNvf4k8CMJV8vCKpv3ldzMjcxxxxx
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 22 April 2019, 09:06:14
Ich denke das konnte ich beheben, Prod Image v1.13.2 baut gerade.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 22 April 2019, 11:40:03
Ich denke das konnte ich beheben, Prod Image v1.13.2 baut gerade.

funktioniert, danke fürs fixen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 22 April 2019, 18:39:23
Was bedeutet die Änderung eigentlich für mich...
muss ich jetzt nach dem pullen des Image noch das Skript mit dem Kopieren des SSH-Keys ausführen? muss ich die Partner bekannt machen, indem ich mich bei Docker einlogge und einmal eine SSH-Verbindung aufbaue? bin da etwas unsicher, was da funktionieren müsste
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 22 April 2019, 20:07:45
Ja genau, entweder einmal eine Shell als fhem User in Docker starten und dann:

ssh-copy-id -i ~/.ssh/id_rsa.pub xyz@host.docker.internal

Oder einfach direkt vom Host aus, wie von kadettilac89 vorgeschlagen das Zertifikat aus dem Container raus kopieren:
https://forum.fhem.de/index.php/topic,89745.msg932018.html#msg932018

Im XiaomiBLE Modul trägst du dann unter sshHost einfach nur noch xyz@host.docker.internal ein und fertig.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 22 April 2019, 20:22:58
Das ist recht umständlich, weshalb die SSH Public Keys aus DockerImageInfo als Reading direkt aus FHEM auslesbar sind. Das kopiert man auf dem Zielsystem im Benutzerverzeichnis nach ~/.ssh/authorized_keys und gut ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: waschbaerbauch am 24 April 2019, 17:43:13
Hallo zusammen,
ich habe noch einmal auf der grünen Wiese angefangen und mit der folgenden docker-compose.yml
# This is an exmaple Docker Compose file to start your own Docker Stack

version: '2.3'

networks:
  net:
    driver: bridge
    # enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/24
          gateway: 172.27.0.1
        # - subnet: fd00:0:0:0:27::/80
        #   gateway: fd00:0:0:0:27::1

services:

  # Example to connect USB to the container w/o
  # privileged mode (preferred method)
  fhem:
    image: fhem/fhem:latest
    restart: always
    networks:
      - net
    ports:
      - "8083:8083"
    volumes:
      - "./fhem/:/opt/fhem/"
    devices:
      - "/dev/ttyUSB0:/dev/ttyUSB0"
      - "/dev/ttyUSB1:/dev/ttyUSB1"
      - "/dev/ttyUSB2:/dev/ttyUSB2"
      - "/dev/ttyUSB3:/dev/ttyUSB3"
      - "/dev/ttyUSB4:/dev/ttyUSB4"
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
      # CONFIGTYPE: configDB

meinen FHEM Container gestartet. Aber immer wenn ich versuche auf 'configDB' zu wechseln fängt mein Container an zu loopen/restarten.
Hat wer ein Tipp für mich was ich machen muss bzw. was ich verkehrt mache? Ich finde einfach den Weg nicht ...

2019.04.24 17:44:05.648 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.24 17:44:05.649 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.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 25 April 2019, 07:36:22
Hallo zusammen,

eine kurze Frage: Ich arbeite mit dem aktuellen Docker Image auf meinem Synology NAS 218+ und habe nach Anweisung versucht die 98_Installer.pm https://forum.fhem.de/index.php/topic,98381.45.html (https://forum.fhem.de/index.php/topic,98381.45.html) in Betrieb zu nehmen - das Modul läuft, aber beim Versuch ein "set fheminstaller statusRequest"  bekomme ich die Fehlermeldung:

E403 Forbidden - passwordless sudo permissions required

Detail:
curl: (23) Failed writing body (843 != 16384)

You may add the following lines to /etc/sudoers.d/fhem:
  fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/perl - App\:\:cpanminus

und der state wechselt zu "error 'getCpanVersion' "

Soweit ich das überblicke, sind in der /etc/sudoers.d/fhemdocker die entscheidenden Einträge vorhanden und auch cpanminus ist lt. Konsole die aktuelle Version. Gibt es beim Docker-Image noch etwas spezielles für dieses Modul zu beachten?

Ich hatte das Thema schon im anderen Thread gepostet, aber dort konnte mir offensichtlich niemand helfen. Deshalb hab ich es dort gelöscht und versuche es hier.


Danke für einen Tipp
wolf

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 25 April 2019, 12:22:06
Gibt es beim Docker-Image noch etwas spezielles für dieses Modul zu beachten?


Nein, nichts spezielles. Mir scheint aber trotzdem, dass dein Image nicht aktuell ist. Welche Version du konkret hast, steht im DockerImageInfo Device im Reading "image.version".
Dort sollte am Ende mindestens "_v1.12.0" stehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 25 April 2019, 12:23:57
meinen FHEM Container gestartet. Aber immer wenn ich versuche auf 'configDB' zu wechseln fängt mein Container an zu loopen/restarten.
Hat wer ein Tipp für mich was ich machen muss bzw. was ich verkehrt mache? Ich finde einfach den Weg nicht ...


Das Image ist aktuell nicht auf configDB optimiert/getestet, da ich es selbst nicht verwende. Ich kenne configDB nicht gut genug um alle Eventualitäten dafür zu kennen.


EDIT: Ich habe einige Hinweise in der README ergänzt (https://github.com/fhem/fhem-docker#customize-your-container-configuration)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 25 April 2019, 13:12:39
Danke Loredo für Deine Antwort!

In der Tat steht dort: "5.9-s19223_v1.11.0" ???

Jetzt muss ich mal lesen, wie ich an die neue Version komme - bin ganz frisch auf Docker umgestiegen und muss mich da erstmal reinlesen. Ich war der Meinung, dass beim Neustart des Containers automatisch passiert, ohne dass ich diesen neu herunterladen und neu konfigurieren muss.

Ich geb bescheid, wenn ich es geschafft hab.

Danke nochmal
wolf
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 25 April 2019, 13:55:42
Erledigt, das Docker Image hat jetzt die Version 5.9-s19245_v1.13.2
Leider bleibt die Fehlermeldung erhalten:

No. Error Code Description
E403 Forbidden - passwordless sudo permissions required

Detail:
sudo: unable to resolve host FHEM1

You may add the following lines to /etc/sudoers.d/fhem:

  fhem ALL=(ALL) NOPASSWD:SETENV: /usr/local/bin/cpanm *
  fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/perl - App\:\:cpanminus

Kann ich sonst noch etwas tun?

Danke und liebe Grüße
wolf
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Toxano am 25 April 2019, 16:22:47
Hallo zusammen,

ich bin noch ein ziemlicher Anfänger was fhem angeht und das ist hier mein erster post :D Hoffe ihr könnt mir weiterhelfen.
Ich versuche aktuell den MySensors Serial Gateway mit dem Fhem-Docker Image am RPI zum Laufen zu bekommen. Für das Gateway nutze ich den RFM69HW, der über die GPIO Ports des RPI mittels SPI angebunden ist. Bei der Installation bin ich nach der Anleitung siehe: https://www.mysensors.org/build/raspberry  (https://www.mysensors.org/build/raspberry) vorgegangen und das Gateway funktioniert auch mit der Fhem Installation auf dem Host-System, jedoch nicht mit dem Docker-Image.

Ich nutze bereits einen nano cul über 433mhz und den habe ich problemlos einbinden können, allerdings habe ich dafür die Methode "serial-by-id" verwendet, was hier ja aufgrund der virtuellen Schnittstelle nicht funktioniert, oder?

Für das Docker-Image habe ich noch folgende Anpassungen vorgenommen:

#Hinzufügen des gateways im yaml
        devices:
             - "/dev/ttyMySensorsGateway:/dev/ttyMySensorsGateway"

#Anpassung der Berechtigungen
root@7871765df993:/opt/fhem# ls -la /dev/ttyM*
crw--w---- 1 root tty  136, 1 Apr 25 15:55 /dev/ttyMySensorsGateway
root@7871765df993:/opt/fhem# chmod a+rw /dev/ttyMySensorsGateway
root@7871765df993:/opt/fhem# ls -la /dev/ttyM*
crw-rw-rw- 1 root tty  136, 1 Apr 25 15:55 /dev/ttyMySensorsGateway

Über das Fhem Logfile wird mir beim Versuch eines connects folgende Fehlermeldung angezeigt:
2019.04.25 16:05:27.889 3: Opening MySensorGateway device /dev/ttyMySensorsGateway
2019.04.25 16:05:27.890 1: MySensorGateway: Can't open /dev/ttyMySensorsGateway: Input/output error

Hat jemand eine Idee woran das liegen könnte?
LG
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 25 April 2019, 16:45:45
Kann ich sonst noch etwas tun?

Ich kann das hier leider nicht nachvollziehen. Bei einer Blanko-Installation ist eine Instanz vom Installer direkt mit angelegt und funktioniert hier auch tadellos. Mehr als einen Container zu erstellen und zu starten muss man nicht tun. Wenn das bei dir nicht funktioniert, weiß ich nicht weshalb. Die Eigenheiten von Docker auf Drittsystemen wie auf einem NAS kenne ich nicht.
Startest du denn auch mit einem "leeren" FHEM Container oder übernimmst du eine bestehende FHEM Installation? Ist letzteres der Fall, dann bitte auch vorher ein Update machen.


@Toxano: Mit dem Einbinden von externen Geräten habe ich keine Erfahrung.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 25 April 2019, 17:14:49
Hallo Loredo,

Vielen Dank für deine Unterstützung, aber es ist in der Tat eine ganz frische Installation. Image heruntergeladen, ein paar mount Pfade gesetzt und gestartet. Keine Geräte - blitzte blanke Neuinstallation....


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 25 April 2019, 18:11:11
Deine Fehlermeldung von oben ist übrigens unerklärlich, denn "sudo: unable to resolve host FHEM1" bedeutet, dass etwas auf "FHEM1" als Hostnamen zugreifen würde, was der Installer aber nicht tut (ich vermute dein Container heißt so?). Noch seltsamer ist, dass die Meldung von "sudo" kommen soll - völlig unmöglich. Ich habe wirklich keinerlei Idee was da bei dir vorgeht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 26 April 2019, 12:26:56
Hallo,

also ich konnte den Fehler eingrenzen: Ich hatte vorher über die WebGUI meines NAS das Dockerimage heruntergeladen und in Betrieb genommen.
Nachdem ich mich in die commandozeilen von Docker etwas eingelesen habe, habe ich das über die Shell meines NAS' das Image noch einmal "gepullt" und gestartet und siehe da - der Fehler ist weg!

Wahrscheinlich hat es wirklich etwas mit einer "Spezialität" der GUI des NAS zu tun.....
Das wäre also erledigt - und vielen Dank für die Hilfe.

Eine Kleinigkeit treibt mich aber trotzdem um: Der Container läuft mit der Netzwerkeinstellung "host". So konnte ich auch das Sonos-Modul in Betrieb nehmen. Definiere ich aber nun auch das Calendar-Modul, bekomme ich Fehlermeldungen:

Calendar Kalender_Feiertage: retrieval failed with error message Cant create UDP socket:Invalid argument
ebenso beim Weather-Modul:
ErrorMsg: Cant create UDP socket:Invalid argument
Gibts hierfür noch etwas zu beachten?

Vielen Dank und schöne Grüße
wolf
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 26 April 2019, 14:05:55
Hi,

kontrolliere einmal bei global den dnsServer (das Attribut).
Da stand bei mir ein falscher Wert drin. Dort darf nur die IP drin stehen. Wenn ich das richtig verstanden habe, wird dieses Attribut beim Neustart des Containers immer wieder neu gesetzt.
Ein Großteil hat funktioniert, aber z.B. Abfragen ins Internet bei httpmod, Kalender usw. gingen nicht.

VG
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 26 April 2019, 14:56:12
Hallo zusammen,

ich bin noch ein ziemlicher Anfänger was fhem angeht und das ist hier mein erster post :D Hoffe ihr könnt mir weiterhelfen.
Ich versuche aktuell den MySensors Serial Gateway mit dem Fhem-Docker Image am RPI zum Laufen zu bekommen. Für das Gateway nutze ich den RFM69HW, der über die GPIO Ports des RPI mittels SPI angebunden ist. Bei der Installation bin ich nach der Anleitung siehe: https://www.mysensors.org/build/raspberry  (https://www.mysensors.org/build/raspberry) vorgegangen und das Gateway funktioniert auch mit der Fhem Installation auf dem Host-System, jedoch nicht mit dem Docker-Image.

Ich nutze bereits einen nano cul über 433mhz und den habe ich problemlos einbinden können, allerdings habe ich dafür die Methode "serial-by-id" verwendet, was hier ja aufgrund der virtuellen Schnittstelle nicht funktioniert, oder?

Für das Docker-Image habe ich noch folgende Anpassungen vorgenommen:

#Hinzufügen des gateways im yaml
        devices:
             - "/dev/ttyMySensorsGateway:/dev/ttyMySensorsGateway"

#Anpassung der Berechtigungen
root@7871765df993:/opt/fhem# ls -la /dev/ttyM*
crw--w---- 1 root tty  136, 1 Apr 25 15:55 /dev/ttyMySensorsGateway
root@7871765df993:/opt/fhem# chmod a+rw /dev/ttyMySensorsGateway
root@7871765df993:/opt/fhem# ls -la /dev/ttyM*
crw-rw-rw- 1 root tty  136, 1 Apr 25 15:55 /dev/ttyMySensorsGateway

Über das Fhem Logfile wird mir beim Versuch eines connects folgende Fehlermeldung angezeigt:
2019.04.25 16:05:27.889 3: Opening MySensorGateway device /dev/ttyMySensorsGateway
2019.04.25 16:05:27.890 1: MySensorGateway: Can't open /dev/ttyMySensorsGateway: Input/output error

Hat jemand eine Idee woran das liegen könnte?
LG

Einbinden kannst du Geräte wirklich gut über das Volume.. nicht über das device.. es klingt wirklich komisch, aber damit habe ich mein SIGNALduino eingebunden, und kann es entspannt mit Serial-by-id einbinden..

Teste mal und teile mit ob es klappt. ich würde dann @Loredo bitten, vielleicht darauf hinzuweisen...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 26 April 2019, 14:58:25
Danke @thotti70 - das war's!!!

Schönes Wochenende
wolf
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 26 April 2019, 17:26:21
Wenn man das Device-Attribut nutzt, dann doch ohnehin nur einmal den Pfad zum Device angeben und nicht zwei mal mit Doppelpunkt getrennt oder?
Das könnte auch eine Fehlerquelle sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 27 April 2019, 02:12:29
Hallo nochmals,
ich greife mein Thema noch einmal auf.
Evtl. kann loredo mich im Zweifelsfall korrigieren.

Ich hatte beschrieben, dass ich zwei fhem container auf meinem system laufen lassen wollte.
Live und Test.
Ich hatte den Effekt, dass mein Live-fhem sich beendet hat, wenn ich das Testsystem ausgeschaltet habe.
Ursache bis dato unbekannt.

Jetzt meine Vermutung und erster Test scheint das zu bestätigen:
im Livesystem habe ich den Telnetport auf Standard 7072 belassen, im Testsystem auf einen anderen (da Netzwerk im hostmodus) um natürlich Dopplungen zu vermeiden.
Soweit ich das als Laie sehen kann, ist im Skript zum beenden des Containers der Port aber fest verdrahtet
su - fhem -c "cd "${FHEM_DIR}"; perl fhem.pl 7072 shutdown"Für mich ergibt sich daraus: habe ich das Testsystem beendet, ging der shutdown Befehl aber an den Telnetport des Livesystems.

Lange Rede, kurzer Sinn, Port im Livesystem geändert und jetzt sieht es so aus, als wenn es nicht mehr gestoppt wird.
ABER: vermute jetzt erhält fhem natürlich nicht mehr den shutdown Befehl.
Oder?

Liege ich richtig und wenn ja, gibt es einen Workaround?

Hoffe es ist trotz später Stunde nachvollziehbar.

Gute Nacht

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 April 2019, 11:12:19
Teste mal und teile mit ob es klappt. ich würde dann @Loredo bitten, vielleicht darauf hinzuweisen...


Kann da mal jemand eine vollständige Liste aller Möglichkeiten aufschreiben und auch alle Schritte Ende-zu-Ende, um dann ein Device einzubinden? Ich nehme das dann gerne mit in die README auf, kann das aber unmöglich alles selbst testen, da ich wie gesagt keine externen Geräte habe, die kein IP sprechen.



Soweit ich das als Laie sehen kann, ist im Skript zum beenden des Containers der Port aber fest verdrahtet
su - fhem -c "cd "${FHEM_DIR}"; perl fhem.pl 7072 shutdown"Für mich ergibt sich daraus: habe ich das Testsystem beendet, ging der shutdown Befehl aber an den Telnetport des Livesystems.


Sehr gutes Finding! Habe ich mal im DEV Image korrigiert, wird dann die Tage auch ins PROD Image wandern.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 April 2019, 13:59:29
Ich habe begonnen das DEV Image auf Debian Buster umzustellen. Es baut gerade und ist wohl in einer guten Stunde abrufbar.


Große Änderungen am FHEM Image selbst sind dabei nicht zu erwarten, dennoch ist der Unterbau natürlich aktueller und es ist nicht ausgeschlossen, dass dabei Probleme auftreten, auf die FHEM Entwickler in Modulen reagieren müssten.


Freiwillige Tester sind gern gesehen, da ich selbst das wie immer nur beschränkt alleine testen kann.
Sofern keine Schwierigkeiten erkennbar sind, kann Buster dann auch schon vor dem offiziellen Release als produktives Image verwendet werden, da die noch offenen Punkte für den Release von Buster mehrheitlich den Debian Installer betreffen, der bei Docker ohnehin keine Rolle spielt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 27 April 2019, 14:50:36
Ich habe heute auch mal das Docker Image ausprobiert, funktioniert prinzipiell sehr gut (ein passendes, fertiges für Sonos wäre natürlich noch toll ;-).

Allerdings fällt mir folgendes auf:

Internals:
   FUUID      5cc42668-f33f-8030-8fd2-0c3143c6b507339c
   NAME       DockerImageInfo
   NR         318
   STATE      Initialized
   TYPE       DockerImageInfo
Attributes:
   room       10_System
 

   
So dürfte das eigentlich ja nicht aussehen. Also habe ich mal mein Telnetport und Allowed geprüft, die schauen so aus:
   
Internals:
   FUUID      5c446459-f33f-8030-e853-ecd6cef796ffe01d
   FVERSION   96_allowed.pm:0.190460/2019-03-27
   NAME       allowed_491726518426
   NR         100
   STATE      validFor:WEB,WEBhook,telnetPort
   TYPE       allowed
   validFor   WEB,WEBhook,telnetPort
   READINGS:
     2019-04-27 14:42:11   state           validFor:WEB,WEBhook,telnetPort
Attributes:
   basicAuth  SHA256:aaaaaaaaaaaa
   globalpassword SHA256:bbbbbbbbbbb
   validFor   WEB,WEBhook,telnetPort
 

   
   
   
Internals:
   CONNECTS   18
   DEF        7072 global
   FD         5
   FUUID      5c446454-f33f-8030-3cf3-a1ab21cde6695530
   FVERSION   98_telnet.pm:0.175290/2018-10-14
   NAME       telnetPort
   NR         3
   PORT       7072
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2019-04-27 14:41:49   state           Initialized
Attributes:

was übersehe ich? Dachte eigentlich, es würde soweit zu den Vorgaben passen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 April 2019, 15:11:32
Telnet muss nicht global sein und braucht dann auch kein allowed.
Du hast aber bei allowed ein Passwort gesetzt, das funktioniert aber mit Docker nicht. Für diese Telnet Instanz darf es kein Passwort geben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 April 2019, 15:32:35

Ich habe begonnen das DEV Image auf Debian Buster umzustellen. Es baut gerade und ist wohl in einer guten Stunde abrufbar.


.....


Freiwillige Tester sind gern gesehen, da ich selbst das wie immer nur beschränkt alleine testen kann.
...


Wie komme ich zum buster Image? Werde es testen.

edit: hat sich erledigt, du hast es ja geschrieben, DEV ... habe es mal geladen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 27 April 2019, 15:41:28
Telnet muss nicht global sein und braucht dann auch kein allowed.
Du hast aber bei allowed ein Passwort gesetzt, das funktioniert aber mit Docker nicht. Für diese Telnet Instanz darf es kein Passwort geben.

Ah, dann lege ich mal eine zweite Telnet-Instanz auf einem anderen Port an und passe diese an. Ich brauche nämlich tatsächlich auch ein Telnet, welches ich von außen füttern kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 28 April 2019, 04:00:56
Ich habe begonnen das DEV Image auf Debian Buster umzustellen. Es baut gerade und ist wohl in einer guten Stunde abrufbar.

Wie sieht denn das bzgl. des Ressourcen-Managements bzw. -sparsamkeit aus? Mein Host läuft unter Stretch und auch die anderen Container von mir basieren auf Stretch bzw. eher "latest".

Sooo viel RAM hat der Pi ja nun nicht...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 28 April 2019, 09:59:39
Wie sieht denn das bzgl. des Ressourcen-Managements bzw. -sparsamkeit aus? Mein Host läuft unter Stretch und auch die anderen Container von mir basieren auf Stretch bzw. eher "latest".

Sooo viel RAM hat der Pi ja nun nicht...


Am Arbeitsspeicher Verbrauch kannst du nur etwas ändern, wenn du weniger FHEM Module verwendest. Das hat nichts mit der Systemumgebung zu tun, es kommt auf die laufenden Anwendungsprozesse an und da gibt es nur fhem.pl und je nach verwendeter Module noch Kindprozesse wie homebridge, alexa-fhem, etc. ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LuckyLuis am 28 April 2019, 12:00:59
Hallo,

nach einem erfolgreichen Umzug meiner FHEM-Installation mit DBLog auf Docker habe ich derzeit ein kleines Problem (gehabt ;-): Leider ist im Docker-Image nicht die Localzone "de_DE.UTF-8" vorgeneriert. Dies führt in Zusammenarbeit mit MariaDB (auf UTF8 eingestellt) zu unerwünschten Effekten (Umlaute). Kann dies in das Image mit aufgenommen werden? Ich habe mir damit geholfen, dies im Container zu erstellen.

Vielen Dank für die tolle Arbeit, die meine Lebenszeit wieder etwas Freiraum für andere Dinge schafft :D!

LuckyLuis
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 28 April 2019, 13:09:22
Ich habe begonnen das DEV Image auf Debian Buster umzustellen. Es baut gerade und ist wohl in einer guten Stunde abrufbar.


Hier mal ein Zwischenstand:


Node.js:
Ich habe versucht Node.js 12 mit einzubauen, allerdings ist für gassistant-fhem eine Abhängigkeit da, für die es wohl (noch) kein vorkompiliertes NPM Modul gibt. Die Kompilierung endet mit einem etwas seltsamen Fehler, so dass die Images nun erstmal Node.js 10 enthalten, welches direkt in Buster enthalten ist. Ich schaue nochmal, ob man zumindest auf Node.js 10 von der Node.js Foundation gehen kann.


SSL Support:
Die Validierung von SSL Zertifikaten scheint in Buster an mehreren Stellen komplett kaputt zu sein. Das betrifft alle ARM 32-Bit Plattformen und sowohl curl als auch npm können deshalb keine Verbindung zu Webservern herstellen, während wget komischerweise funktioniert. Für curl gibt es bereits einen Bugreport bei Debian, aber eher unspezifisch. Bugreports sind sehr umständlich bei Debian, daher habe ich selbst noch keinen erstellt.


Aufgrund des SSL Findings wird es so schnell also erstmal kein Buster geben. Ich überlege mal, ob ich das DEV Image so belasse oder es wieder auf Debian Stretch zurückstufe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 28 April 2019, 15:33:00
Hallo zusammen,

ich muss noch einmal nachfragen: Nach jedem Neustart des Containers bekomme ich, wie @thotti70 beschrieben hat in der global von fhem den Eintrag:

DNS Server: nameserver     8.8.8.8
eingetragen, was zu Problemen mit UDP aus FHEM heraus führt. Ändere ich den Eintrag auf "8.8.8.8" (ohne das Wort "nameserver"), funkioniert alles bestens.
Ich bin also auf die Suche gegangen und scheinbar ist es so, dass der Eintrag aus der "resolve.conf" beim Start gezogen wird. Eigentlich sollte dort doch dann nur die IP-Adresse in die fhem.conf übergeben werden und nicht die ganze Zeile, was zu den genannten Problem führt.

Wie kann ich das verhindern? Das Wort "nameserver" aus der resolve.conf herausnehmen, ist glaube ich ne schlechte Idee?  8)

Hat jemand einen Tipp für mich?

Viele Grüße und einen schönen Sonntag

wolf
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 28 April 2019, 16:13:11
Hat jemand einen Tipp für mich?


Aus irgendeinem Grund ist in deiner resolv.conf statt Leerzeichen ein Tab als Trennzeichen verwendet. Ich schaue mal, dass ich das im nächsten Update berücksichtige.
Derweil kannst du aber auch per Docker Environment Variable "DNS=8.8.8.8" explizit nachhelfen. Mich wundert aber, dass du offenbar keinen lokalen DNS Server hast, sondern deinen Docker Server so eingestellt hast, die Datenkrake direkt zu fragen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 28 April 2019, 16:15:01
Leider ist im Docker-Image nicht die Localzone "de_DE.UTF-8" vorgeneriert. Dies führt in Zusammenarbeit mit MariaDB (auf UTF8 eingestellt) zu unerwünschten Effekten (Umlaute). Kann dies in das Image mit aufgenommen werden? Ich habe mir damit geholfen, dies im Container zu erstellen.


Ich verstehe nicht ganz, wo deine Datenbank läuft. Installierst du die nachträglich im Container? Dann sollte es auch kein Problem sein die Sprache zusätzlich zu installieren. Bisher wurde sie nicht benötigt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LuckyLuis am 28 April 2019, 17:25:19
Hallo Laredo,

ich habe MariaDB in einem eigenen Container laufen (separat von FHEM, welches auch in einem eigenen Container läuft). Verbindung läuft über TCP. MariaDB läuft explizit unter UTF8 und dies habe ich auch für ConfDB parametrisiert. Das von Dir bereitgestellte Image (als Basis meines FHEM-Containers) rufe ich auch mit den Parametern LANG und LC_ALL mit de_DE.UTF-8 auf. Beim Start des FHEM-Containers gibt es dann schon die Fehlermeldung, dass er die Locale nicht kennt und fällt zurück auf Default LANG_C o.ä.. Dies kann durch Generierung der Locale abgestellt werden. Wie gesagt, ich habe es bei mir manuell behoben und müsste es bei einem Image-Update jeweils wieder machen (außer ich baue mein eigenes Image, da bin ich aber nicht Firm drin ...). Und wenn ich nicht beides (MariaDB und FHEM) auf UTF-8 stelle, bekomme ich Probleme mit Umlauten.

VG
LuckyLuis
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 29 April 2019, 11:04:45
Okay verstehe, danke für die Erläuterung!
Ein aktualisiertes PROD Image mit dem Sprachen en,de,nl,fr,pl,it baut gerade, auch ein Update für die DNS Problematik ist enthalten.


Für mich bleibt nur die Frage übrig, weshalb Umlaute beim englischen UTF8 Probleme machen sollen, leuchtet mir nicht ein.



-----


Das DEV Image ist nun wieder auf Debian 9 Stretch zurückgestellt. Derweil wurde zunächst ein Bugreport (https://github.com/debuerreotype/docker-debian-artifacts/issues/68) an die Docker Image Crew für Debian gestellt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 30 April 2019, 00:20:32
Hallo Wolf,
ich habe es so gelöst, dass ich mir eine neue resolv.conf außerhalb des Containers gebaut habe und dies dann per Dateimapping eingebunden habe.
Sprich in der Docker-Admin-Oberfläche der Synology (glaube du hattest das auch darauf laufen?) die selbst erstellte Datei nach /etc/resolv.conf „gemappt“

VG
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 30 April 2019, 08:43:56
ich habe es so gelöst, dass ich mir eine neue resolv.conf außerhalb des Containers gebaut habe und dies dann per Dateimapping eingebunden habe.
Sprich in der Docker-Admin-Oberfläche der Synology (glaube du hattest das auch darauf laufen?) die selbst erstellte Datei nach /etc/resolv.conf „gemappt“


Das hilft wahrscheinlich nichts, weil das Startup Script dann eben diese gemappte Datei zwar hernimmt, aber die resolv.conf dann nicht mehr im korrekten Format ist und somit die Namensauflösung innerhalb des Containers nicht mehr funktioniert.
Es ist auch nicht mehr nötig, es gab vor einigen Tagen einen Patch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 30 April 2019, 13:52:13
Nur als Anmerkung,
es hat funktioniert, aber ein Patch ist natürlich viiiieeeel eleganter und besser.

Vielen Dank

LG Thotti70
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 30 April 2019, 19:59:54
Hattest du auch schon Zeit gefunden den Telnetport für das Beenden von fhem variable zu gestalten?

LG
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 30 April 2019, 20:12:08
Hattest du auch schon Zeit gefunden den Telnetport für das Beenden von fhem variable zu gestalten?


Die Variable gibts ja schon lange. Einen Fix, die auch für das Restart Verhalten zu verwenden, ist seit ner Woche oder so eingecheckt und im Prod Image enthalten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Helmuth am 03 Mai 2019, 19:05:59
Hallo zusammen

Ich bin etwas konfuse, Ihr tüddelt alle wie die Weltmeister an Euern Containerern herrum und ich stehe mit Stumpfen Bohrer und leerem Akkuschrauber vor der riesen Kiste und komme per SSH nicht drauf.  ;D ;D

Spaß beiseite kann mit bitte jemand nen Tipp geben was ich falsch mache. Also von Win10 Putty Verbindung zum Container.

Und bitte nicht schreiben Bohrer anschleifen und Akku aufladen. ;D

Gruß Helmuth
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thotti70 am 03 Mai 2019, 19:08:02
Was willst du denn machen?
Ich hatte bisher keinen Bedarf direkt per ssh auf die Maschine zu wollen.

VG
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Helmuth am 03 Mai 2019, 19:44:28
Hallo

naja ich habe gerne noch ein Hintertürchen offen sodass ich im Notfall eingreifen kann wenn Fhem mal nicht will.

Ich konnte mir da schon mal helfen, damit ich nicht alles neu aufsetzen musste.

Solange alles läuft wie momentan braucht man es nicht, da muss ich dir Recht geben.

Gruß Helmuth
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 03 Mai 2019, 20:47:23
docker exec -it fhem bash
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 03 Mai 2019, 21:11:49
Docker <> VM

D.h. eigentlich ist ein Docker-Container nur EIN Programm, Du kommst nicht direkt von außen per ssh rauf (jedenfalls nicht bei "richtigen" Containern")(Außnahme: SSH-Container ;o) )

Indirekt geht es aber trotzdem. Du loggst Dich per ssh auf den Host-Rechner und von dort per "docker exec -it <containername> /bin/bash"

Hinweis:
Es gibt Container, wo keine bash installiert ist, dann besser /bin/sh

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Helmuth am 04 Mai 2019, 09:34:13
Hallo Wernieman

Danke für die ausführliche Erklärung.

Mit sudo vor dem Befehl funktioniert es. Coole Sache Danke nochmal.

Gruß Helmuth
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 05 Mai 2019, 11:46:32
Dann ist Dein User nicht in der "docker-gruppe"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 07 Mai 2019, 15:01:09

Hallo,

im README https://github.com/fhem/fhem-docker/blob/dev/README.md steht man solle das Attribut nofork auf 1 setzen.

"make sure the global attribute 'nofork' is set to 1, otherwise FHEM will not be able to start properly."

macht man das und setzt das Attribut nofork auf 1 in der fhem.cfg wird durch das entry.sh beim starten des Docker Containers nofork auf 0 gesetzt?!

Ist das in der Anleitung falsch, oder im entry.sh Skript?

Grüße
Stephan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 07 Mai 2019, 15:43:59
Oh, ist in der Tat ein Dreher in der README. Richtig ist nofork=0.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 07 Mai 2019, 15:59:40
Es baut jetzt gerade ein neues PROD Image, welches insbesondere im Bezug auf configDB eine Verbesserung ist: Es wird die neue Umgebungsvariable FHEM_GLOBALATTR verwendet, um die richtigen Starteinstellungen zu forcieren. Eine spezielle Vorbereitung von configDB Installationen beim Erststart in Docker ist somit nicht mehr erforderlich.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 07 Mai 2019, 16:01:26
mal als Docker Anfänger. Ich hab es unter Synology auf dem Docker fhem:fhem. Wie mache ich nun am besten ein Update ?
Export der Container Einstellungen.
Abbild fhem löschen
Abbild neu raussuchen und "last" runterladen und dann einfach die Container Einstellungen wieder Importieren ??
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 07 Mai 2019, 16:33:22
Hallo,

Oh, ist in der Tat ein Dreher in der README. Richtig ist nofork=0.

ich dachte ich habe ein Fehler gefunden. :(
FHEM läuft im Docker Container nicht stabil, und wird auch nicht neu gestartet:

"... /entry.sh start"        2 hours ago         Up 2 hours (unhealthy) ...
root@b82cf37e39f9:/opt/fhem/log# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  1.3  0.2   4540  2232 ?        Ss   14:25   1:43 /bin/bash /entry.sh start
root      1009  0.0  0.2   4532  2524 pts/0    Ss+  16:18   0:00 /bin/bash
root     16286  0.1  0.2   4532  2560 pts/1    Ss   16:29   0:00 /bin/bash
root     19020  0.0  0.0   3016   344 ?        S    16:31   0:00 sleep 0.5
root     19021  0.0  0.0   1428   360 ?        Ss   16:31   0:00 /bin/sh -c /health-check.sh
root     19026  0.0  0.2   4400  2252 ?        S    16:31   0:00 /bin/bash /health-check.sh
root     19030  0.0  0.2   6728  2144 pts/1    R+   16:31   0:00 ps aux
root     19031  0.0  0.1   4400  1388 ?        S    16:31   0:00 /bin/bash /health-check.sh
root     19032  0.0  0.2   5392  2452 ?        R    16:31   0:00 perl fhem.pl 7072 jsonlist2 TYPE=FHEMWEB:FILTER=TEMPORARY!=1
root@b82cf37e39f9:/opt/fhem/log# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  1.3  0.2   4540  2232 ?        Ss   14:25   1:43 /bin/bash /entry.sh start
root      1009  0.0  0.2   4532  2524 pts/0    Ss+  16:18   0:00 /bin/bash
root     16286  0.1  0.2   4532  2560 pts/1    Ss   16:29   0:00 /bin/bash
root     19071  0.0  0.0   3016   344 ?        S    16:31   0:00 sleep 0.5
root     19072  0.0  0.2   6728  2136 pts/1    R+   16:31   0:00 ps aux

kann ich da noch was debuggen?

Grüße
Stephan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 07 Mai 2019, 17:38:10
Telnet beachtet?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 07 Mai 2019, 20:17:50
Telnet beachtet?

Telnet Port 7072 ist konfiguriert:

define telnetPort telnet 7072 global
Grüße
Stephan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 08 Mai 2019, 07:10:52
mal als Docker Anfänger. Ich hab es unter Synology auf dem Docker fhem:fhem. Wie mache ich nun am besten ein Update ?
Export der Container Einstellungen.
Abbild fhem löschen
Abbild neu raussuchen und "last" runterladen und dann einfach die Container Einstellungen wieder Importieren ??

Ich nutze ein docker-compose und mach ein
docker-compose pull fhem weiß aber nicht was die offizielle Variante ist
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 08 Mai 2019, 10:31:16
Hallo,

zwei Sachen sind mir noch aufgefallen die regelmässig gestartet werden:

perl fhem.pl 7072 jsonlist2 TYPE=FHEMWEB:FILTER=TEMPORARY!=1Can't connect to localhost:7072
ist ok. fhem läuft ja nicht.

grep -q Server started /dev/fd/63
grep: started: No such file or directory
grep: /dev/fd/63: No such file or directory

ist da was bei PrintNewLines nicht ok?

so langsam keine Idee was ich da noch debuggen könnte.

Grüße
Stephan


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 08 Mai 2019, 16:30:54
grep -q Server started /dev/fd/631. die "" vergessen? Bei grep ist der erste parameter das Suchmuster, beim 2. (optional) das File. Du gibst als ersten Parameter das "Server" und als 2. "startet" ..... ein Space ist Trennzeichen ...
2. Existiert überhaupt /dev/fd/63

Eigentlich wollte ich aber schreiben:
Was willst Du mit Deiner Zeile erreichen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisler am 08 Mai 2019, 16:56:37
Was willst Du mit Deiner Zeile erreichen?

1. das grep sollte passen. Im ps output werden die "" nicht mit angezeigt.
2. /dev/fd/63 existiert nicht

das kommt aus: https://github.com/fhem/fhem-docker/blob/master/src/entry.sh
...
function PrintNewLines {
  if [ -s "$( date +"${LOGFILE}" )" ]; then
  NEWLINES=$(wc -l < "$(date +"${LOGFILE}")")
  (( OLDLINES <= NEWLINES )) && LINES=$(( NEWLINES - OLDLINES )) || LINES=${NEWLINES}
  tail -n "${LINES}" "$(date +"${LOGFILE}")"
  [ -n "$1" ] && grep -q "$1" <(tail -n "$LINES" "$(date +"${LOGFILE}")") && FOUND=true || FOUND=false
  OLDLINES=${NEWLINES}
  fi
}
...

mit dem entry.sh sollte fhem gestartet werden... startet aber nicht. :(

Grüße
Stephan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 08 Mai 2019, 17:03:50
Fhem und KNXD mit Docker?
verwendet wer obiges? Ich habe da ein kurioses Problem:
knxd als docker läßt bei mir nicht alles durch oder um es anders zu sagen: knxd mit einem pi (ohne docker) zeigt alle gruppenadressen an nur wenn ich das ganze auf meinem server mit ubuntu in einem docker laufen lasse verschwinden einige gad's (immer die gleichen wie z.b. 2/6/101, 2/4/21+22) alles andere funktioniert)
fhem im docker funktioniert dafür ohne probleme.
oder gibt es die möglichkeit dieses docker basis image mit knxd in einem container laufen zu lassen ohne das ich bei jedem update diesen neu bauen muß? hätte auch den vorteil knxd nicht im net modus laufen zu lassen...
bin allerdings nicht der fitteste bei docker - bin schon froh es so hin gekriegt zu haben :-)
gruß anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 08 Mai 2019, 20:59:53
Mehere Daemons in einem Docker Container ....

Wie ich schon obe geschrieben habe: Docker <> VM

In Docker wird eigentlich ein Service (Daemon) mit "seiner" Umgebung um laufen gebracht. Sogenannte "microservices".

Zu KNXD kann ich mangels Hardware nicht sagen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schlimbo am 09 Mai 2019, 05:47:14
Hallo Loredo,
bei dem Text2Speech Modul haben sich die Abhängigkeiten etwas geändert. Bekomme mir der aktuellen Version folgende Meldung:

Can't locate Text/Iconv.pm in @INC (you may need to install the Text::Iconv module) (@INC contains: . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base ./FHEM ./FHEM/lib) at ./FHEM/98_Text2Speech.pm line 28.
BEGIN failed--compilation aborted at ./FHEM/98_Text2Speech.pm line 28.

Aus dem Text2Speech Thread:
Das Wiki ist noch nicht komplett ergänzt.
Es wird Text::Iconv sowie in der nächsten Version Encode::Guess benötigt.
Wenn du die neue Amazon Polly Engine nutzen willst, kommt noch Paws und File::Homedir dazu

Bitte nachinstallieren

Könntest du die fehlenden Abhängigkeiten bitte noch mit aufnehmen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 09 Mai 2019, 18:50:38
Ist es eventuell möglich die aktuellen Module für DoorBird noch zu integrieren? https://forum.fhem.de/index.php/topic,41758.msg937826.html#msg937826
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 11 Mai 2019, 10:14:06
2. /dev/fd/63 existiert nicht

Ich vermute du hast /dev/fd/63 irgendwo als LOGFILE gesetzt. Das ist natürlich absoluter quatsch und das musst du irgendwie beheben.

bei dem Text2Speech Modul haben sich die Abhängigkeiten etwas geändert. Bekomme mir der aktuellen Version folgende Meldung:
[.....]
Könntest du die fehlenden Abhängigkeiten bitte noch mit aufnehmen?

Done.

Ist es eventuell möglich die aktuellen Module für DoorBird noch zu integrieren? https://forum.fhem.de/index.php/topic,41758.msg937826.html#msg937826 (https://forum.fhem.de/index.php/topic,41758.msg937826.html#msg937826)

Die Abhängigkeiten sind etwas exotischer, weshalb das eigentlich eher Kandidaten für die Umgebungsvariablen APT_PKGS oder CPAN_PKGS sind (siehe README.md (https://github.com/fhem/fhem-docker/blob/master/README.md)). Hast du das mal versucht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 11 Mai 2019, 16:23:05
Die Abhängigkeiten sind etwas exotischer, weshalb das eigentlich eher Kandidaten für die Umgebungsvariablen APT_PKGS oder CPAN_PKGS sind (siehe README.md (https://github.com/fhem/fhem-docker/blob/master/README.md)). Hast du das mal versucht?

Hmm, also ich rufe den Container jetzt so auf:

sudo docker run -d --name fhem -p 8083:8083 -e CPAN_PKGS="Crypt::Argon2 Crypt::NaCl::Sodium Alien::Base::ModuleBuild Alien::Sodium" -v /opt/fhem:/opt/fhem fhem/fhem
allerdings kann dann DoorBird nicht definiert werden, weil laut Logfile diese Module fehlen. Mache ich beim Aufruf etwas falsch? Oder werden die nachgelagert installiert und stehen dadurch beim Start von FHEM noch nicht zur Verfügung?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 12 Mai 2019, 00:21:08
Hallo,

seit neusten ist mir aufgefallen, das der FHEM Container den Raspi ständig belastet Außerdem hört die SD Karte kaum auf zu lesen..
es scheint dem Log geschuldet zu sein...
denn unter htop sehe ich, das vorallem der Prozess cp -1 ca 15% CPU-Last dauerhaft fährt.. das ist auf meinen Raspi 2b jetzt nicht ganz so pralle....
gibt es eine Möglichkeit, das die last wieder verringert wird? bin auf dem DEV-Build. und habe vor 1h ein Pull gemacht...

lg
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 Mai 2019, 09:41:05
Hmm, also ich rufe den Container jetzt so auf:

sudo docker run -d --name fhem -p 8083:8083 -e CPAN_PKGS="Crypt::Argon2 Crypt::NaCl::Sodium Alien::Base::ModuleBuild Alien::Sodium" -v /opt/fhem:/opt/fhem fhem/fhem
allerdings kann dann DoorBird nicht definiert werden, weil laut Logfile diese Module fehlen. Mache ich beim Aufruf etwas falsch? Oder werden die nachgelagert installiert und stehen dadurch beim Start von FHEM noch nicht zur Verfügung?


Du startest damit nur den schon vorhandenen Container. Du musst den Container aber komplett neu anlegen, damit auch die Startphase so abläuft, dass auch Pakete nachinstalliert werden. Das passiert nur ein einziges Mal, wenn du den Container aktualisiert oder neu angelegt hast.


Ob die Pakete installiert werden und ob das erfolgreich ist, siehst du im Docker Logfile für den Container.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 Mai 2019, 09:46:20
seit neusten ist mir aufgefallen, das der FHEM Container den Raspi ständig belastet Außerdem hört die SD Karte kaum auf zu lesen..
es scheint dem Log geschuldet zu sein...
denn unter htop sehe ich, das vorallem der Prozess cp -1 ca 15% CPU-Last dauerhaft fährt.. das ist auf meinen Raspi 2b jetzt nicht ganz so pralle....


Bist du sicher, dass der Befehl so heißt, wie heißt der denn ganz genau und unter welchem Benutzer wird er ausgeführt? Einen solchen Befehl gibt es in keinem der Scripts innerhalb des Docker Containers. Das Logfile wird schon seit jeher von FHEM selbst geschrieben, das ist auch keine Besonderheit vom Docker Image. Wenn du ein entsprechend hohes Loglevel eingestellt hast, wird auch mehr produziert und damit auch (regelmäßig) abgespeichert. Es gibt bei FHEM derzeit keinen Modus, um die Logdatei zeitversetzt und resourcenschonender zu schreiben. Das macht wahrscheinlich auch wenig Sinn, denn man möchte in der Regel die Logausgaben sehr zeitnah sehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 12 Mai 2019, 10:39:36

Bist du sicher, dass der Befehl so heißt, wie heißt der denn ganz genau und unter welchem Benutzer wird er ausgeführt? Einen solchen Befehl gibt es in keinem der Scripts innerhalb des Docker Containers. Das Logfile wird schon seit jeher von FHEM selbst geschrieben, das ist auch keine Besonderheit vom Docker Image. Wenn du ein entsprechend hohes Loglevel eingestellt hast, wird auch mehr produziert und damit auch (regelmäßig) abgespeichert. Es gibt bei FHEM derzeit keinen Modus, um die Logdatei zeitversetzt und resourcenschonender zu schreiben. Das macht wahrscheinlich auch wenig Sinn, denn man möchte in der Regel die Logausgaben sehr zeitnah sehen.

Morgen,

Den Befehl gibt es in /src/Entry.sh
Und hier zu finden:
# Function to print FHEM log in incremental steps to the docker log.
[ -s "$( date +"${LOGFILE}" )" ] && OLDLINES=$( wc -l < "$( date +"${LOGFILE}" )" ) || OLDLINES=0
NEWLINES=${OLDLINES}
FOUND=false
function PrintNewLines {
  if [ -s "$( date +"${LOGFILE}" )" ]; then
  NEWLINES=$(wc -l < "$(date +"${LOGFILE}")")
  (( OLDLINES <= NEWLINES )) && LINES=$(( NEWLINES - OLDLINES )) || LINES=${NEWLINES}
  tail -n "${LINES}" "$(date +"${LOGFILE}")"
  [ -n "$1" ] && grep -q "$1" <(tail -n "$LINES" "$(date +"${LOGFILE}")") && FOUND=true || FOUND=false
  OLDLINES=${NEWLINES}
  fi
}[/codeA]

Es läuft in der treeansicht unter dem Docker wo auch fhem läuft.
Kann ich dir am Rechner ein Screenshot machen.

Edit: na gut. Mein Docker-image wird auch als Unhealthy  betitelt...

 Container health
Status    unhealthy
Failure count   196
Last output   Health check exceeded timeout (10s)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 Mai 2019, 11:04:41
Den Befehl gibt es in /src/Entry.sh
Und hier zu finden:


Ich kann da keinen "cp -1" Befehl finden, tut mir leid.
Alle Befehle, die in dem von dir gezeigten Ausschnitt ausgeführt werden, sind nur lesend aktiv und schreiben nichts.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 12 Mai 2019, 11:37:02

Ich kann da keinen "cp -1" Befehl finden, tut mir leid.
Alle Befehle, die in dem von dir gezeigten Ausschnitt ausgeführt werden, sind nur lesend aktiv und schreiben nichts.

ja du hast auch absolut recht... ich meine auch wc -1 weshalb ich den teil rausgesucht habe.. war wohl gestern abend etwas zu spät ^^
sorry...
kann ja mal spontan den ganzen Container neu bauen lassen, vielleicht ist dann das unhealthy weg...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 Mai 2019, 11:49:48
Ah! Du meinst 'wc -l' mit kleinem 'L', das ist keine 1/Eins ;-)


Der Grund fürs unhealthy steht ja im Docker Statusfeld drin. Wahrscheinlich hast du kein Telnet device, was ohne Passwort auf localhost und Port 7072 horcht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 12 Mai 2019, 16:13:49
Ah! Du meinst 'wc -l' mit kleinem 'L', das ist keine 1/Eins ;-)


Der Grund fürs unhealthy steht ja im Docker Statusfeld drin. Wahrscheinlich hast du kein Telnet device, was ohne Passwort auf localhost und Port 7072 horcht.

Hab ich dann iegendein Device gelöscht? Früher hat er Healthy gesagt... jetzt komischer weise nicht. Kann ich da was korrigieren?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 Mai 2019, 19:46:01
Ich kenne deine FHEM Installation nicht.
Bei einer frischen Installation, bei der du kein FHEM mitbringt, wird ein Telnet Device angelegt, welches auf Port 7072 auf localhost hört. Das musst du manuell anlegen, wenn du eine bestehende Installation mitbringst und den Health Status bzw. DockerImageInfo nutzen willst. Dabei darf der Zugriff zumindest für localhost nicht über ein allowed Device beschränkt sein. Steht auch in der README, es gilt das gleiche wie für configDB in diesem Fall.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: KraxelHuber am 16 Mai 2019, 21:13:16
Ich würde das Docker Image gerne in mein Version Control System einbinden, so wie auf der Github Seite beschrieben. Es gibt aber leider Probleme :-(
Wenn ich in einem ersten Schritt den Container starte, läuft alles bestens. Ich habe Zugriff auf die an meinem RPi angeschlossenen USB-Sticks (Z-Wave, CUL) und alles scheint gut zu funktionieren. Hier ist die docker-compose.yml, die ich benutze:

version: '2.3'

networks:
  net:
    driver: bridge
    # enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/24
          gateway: 172.27.0.1
        # - subnet: fd00:0:0:0:27::/80
        #   gateway: fd00:0:0:0:27::1

services:

  fhem:
    image: fhem/fhem:latest
    container_name: fhem_slave
    restart: always
    networks:
      - net
    ports:
      - "8083:8083"
    volumes:
      - "./fhem/:/opt/fhem/"
    devices:
      - "dev/ttyACM0:/dev/ttyACM0"
      - "dev/ttyACM1:/dev/ttyACM1"
      - "dev/ttyAMA0:/dev/ttyAMA0"
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin

Nun habe ich leichte Änderungen an der Konfiguration vornheme, z.B. ein 'update all' und die Änderungen committet und in mein online Repo gepusht. Im Anschluss stoppe und lösche ich den Container. Außerdem lösche ich das gesamte /docker/home/ Verzeichnis, um das Einspielen des "Backups" zu testen. Nachdem ich mein Online Repo dann wieder in dieselben Verzeichnisse gecloned habe, startet der Container beim Aufruf von docker-compose up -d nicht mehr richtig. Er hängt sich anscheinend in einer Art Endlosschleife auf. Ein Aufruf von docker ps zeigt mir im Status "Restarting" an. Ist dieses Phänomen hier irgendwie bekannt? Wo und wie sollte ich evtl. nach dem Fehler suchen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 17 Mai 2019, 18:54:42
Kann es sein das
attr global exclude_from_update 88_VantagePro2.pmin fhem.cfg ignoriert wird? Bei einem update all kommt bei mir:
2019.05.17 18:53:17.145 1 : UPD FHEM/88_VantagePro2.pm
2019.05.17 18:53:17.190 1 : open ./FHEM/88_VantagePro2.pm failed: Permission denied, trying to restore the previous version and aborting the update
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: KraxelHuber am 17 Mai 2019, 20:44:51
Zitat
2019.05.17 18:53:17.145 1 : UPD FHEM/88_VantagePro2.pm
2019.05.17 18:53:17.190 1 : open ./FHEM/88_VantagePro2.pm failed: Permission denied, trying to restore the previous version and aborting the update

Diese Meldungen tauchen bei mir nach einem "update all" überhaupt nicht auf. Der Event Monitor sieht eigentlich ganz normal ohne merkwürdige Meldungen aus.

Es ist wirklich wie verhext. Nach einem

update all

git add -A
git commit -m "Test"
git push

docker stop fhem_slave
docker remove fhem_slave

sudo rm -r /docker/home
cd /docker

sudo git clone HTTPS_ADRESSE_MEINES_REPOS.git home

sieht die Verzeichnisstruktur praktisch genauso aus, wie vor dem ganzen Löschvorgang. Aber der Container will dann einfach nicht starten sondern hängt sich in dieser Endlos-Schleife auf.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 17 Mai 2019, 21:31:10
Ist dieses Phänomen hier irgendwie bekannt? Wo und wie sollte ich evtl. nach dem Fehler suchen?


Nein, ist mir nicht bekannt. "docker ps" hilft dir nicht, du musst in die Log Ausgabe von Docker gucken:
https://docs.docker.com/config/containers/logging/ (https://docs.docker.com/config/containers/logging/)


Also "docker logs fhem_slave".
Die Meldungen dort werden dir wahrscheinlich weiterhelfen. Meine Vermutung ist, dass deine Verzeichnisstruktur nicht richtig passt.


Kann es sein das
attr global exclude_from_update 88_VantagePro2.pmin fhem.cfg ignoriert wird?


Der Container hat keinerlei Einfluss darauf. Wahrscheinlich hast du exclude_from_update aber falsch benutzt, ich glaube man schreibt dort nur "88_VantagePro2" rein - ohne ".pm".
Wenn da irgendwelche Verzeichnisberechtigungen nicht stimmen, liegt das nicht am Docker Container. Dort werden beim Start alle Rechte ordentlich gesetzt. Was während der Laufzeit so passiert, liegt an dir. Vermutlich hast du die Datei dort manuell hinkopiert und die Berechtigungen dabei nicht korrigiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 18 Mai 2019, 16:26:44
Mein Logfile wird leider mit
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)vollgespammt.

Ich vermute, dass irgendwie mal von einem Rechner mit deutschen Locales auf die Console des Containers oder so zugriffen wurde? Wie kann ich das denn fixen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 18 Mai 2019, 19:36:40
Mein Logfile wird leider mit
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)vollgespammt.

Ich vermute, dass irgendwie mal von einem Rechner mit deutschen Locales auf die Console des Containers oder so zugriffen wurde? Wie kann ich das denn fixen?

Setze diese Variablen im Docker-Compose ... oder als Parameter je nach Umgebung

        environment:
            LANG: "de_DE.UTF-8"
            LC_ALL: "de_DE.UTF-8" 

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 18 Mai 2019, 20:53:52
Die Umgebung auf Deutsch zu stellen ist wahrscheinlich nicht zielführend.


Zunächst einmal ist das ja auch "nur" eine Warnung.
Allerdings ist die englischen Locales im Image vorgeneriert und wird auch per Default verwendet, von daher habe ich keine Ahnung weshalb das bei dir so ist.
Dieser Fehler tritt bei mir nirgends auf. Was passiert denn mit einem blanken FHEM Container ohne eigene Dateien?
Ansonsten nutzt du vielleicht irgendein Modul, welches auf der Kommandozeile was tut und nicht richtig funktioniert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 18 Mai 2019, 21:09:24
Ich vermute mal, dass es daran liegt, dass eins der Module welches sich per SSH auf dem Host einloggt um dort die Bluetooth-Schnittstelle zu nutzen, diesen Fehler verursacht.
Edit: Vermutung bestätigt, wenn der SSH Login vom Modul auf dem Docker-Host deaktiviert wird, dann ist die Fehlermeldung weg.

Der Host ist auf deutsch gestellt, der Docker-Container wird dann vermutlich keine deutschen Sprachdateien haben.

An sich funktioniert ja alles, aber das Logfile wird so extrem unübersichtlich, also brauche ich zumindest eine Möglichkeit die Warnung auszuschalten, wenn ich schon die eigentlich Ursache nicht fixe...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: KraxelHuber am 18 Mai 2019, 21:21:50
Zitat
Also "docker logs fhem_slave".
Die Meldungen dort werden dir wahrscheinlich weiterhelfen. Meine Vermutung ist, dass deine Verzeichnisstruktur nicht richtig passt.

Mit deiner Vermutung scheinst du nicht schlecht zu liegen. Das Log zeigt mir immer wieder die folgenden Einträge, wobei das Problem wohl direkt am Anfang beim Namen benannt wird. Es gibt bei mir kein ./log/fhem-2019-05.

Preparing configuration ... done

Starting FHEM ...
Can't open ./log/fhem-2019-05.log: No such file or directory at fhem.pl line 2763.
Unable to start FHEM process - errorcode 2
Preparing user environment ...
1. Creating group 'fhem' with GID 6061 ...
2. Enforcing GID for group 'bluetooth' to 6001 ...
3. Creating user 'fhem' with UID 6061 ...
4. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...
5. Correcting group ownership for /dev/tty* ...
6. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
7. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
8. Updating /etc/sudoers.d/fhem-docker ...
9. Adding gateway.docker.internal to /etc/hosts ...
10. Adding host.docker.internal to /etc/hosts ...
11. Pre-authorizing SSH to Docker host for user 'fhem' ...
12. Updating SSH key pinning and SSH client permissions for user 'fhem' ...

Und woran liegt das? - Das Verzeichnis fhem/log/* wird in der Datei .gitignore ausgeschlossen, d.h. das Verzeichnis wird nicht ins Online Repo gepusht. Bei einem kompletten Neu-Clone ist es dann auch entsprechend nicht mehr da. Ich wundere mich nur, dass das Problem noch nie bei jemand anderem aufgetaucht ist. Schließlich ist diese Zeile in der .gitignore Datei auch Bestandteil des offiziellen Repo auf GitHub.

Wenn ich diese entsprechende Zeile aus der .gitignore Datei entferne, wird das Log Verzeichnis auch ins Online Repo gepusht. Bei mir startet der Container dann auch reibungslos.

Danke auf jeden Fall für den Hinweis mit den Docker Logs. Das war entscheidend!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 18 Mai 2019, 21:55:12
Die Umgebung auf Deutsch zu stellen ist wahrscheinlich nicht zielführend.


Zunächst einmal ist das ja auch "nur" eine Warnung.
Allerdings ist die englischen Locales im Image vorgeneriert und wird auch per Default verwendet, von daher habe ich keine Ahnung weshalb das bei dir so ist.
Dieser Fehler tritt bei mir nirgends auf. Was passiert denn mit einem blanken FHEM Container ohne eigene Dateien?
Ansonsten nutzt du vielleicht irgendein Modul, welches auf der Kommandozeile was tut und nicht richtig funktioniert.

definition "zielführend"...damit ist die Warnung weg. Hatte die selbe Meldung. Nutze ssh auf den Host intensiv, wollte nur die Warnungen weg haben. Für mich war das der schnellste weg.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 18 Mai 2019, 22:01:48
definition "zielführend"...damit ist die Warnung weg. Hatte die selbe Meldung. Nutze ssh auf den Host intensiv, wollte nur die Warnungen weg haben. Für mich war das der schnellste weg.

Hab jetzt einfach auf meinem Host noch en_US.UTF-8 dazu installiert, bis jetzt war nur en_EN.UTF-8 und de_DE.UTF-8 vorhanden

Das ist vermutlich im Sinne der Problemlösung die sauberste Methode...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 19 Mai 2019, 09:42:11
Ich vermute mal, dass es daran liegt, dass eins der Module welches sich per SSH auf dem Host einloggt um dort die Bluetooth-Schnittstelle zu nutzen, diesen Fehler verursacht.
Edit: Vermutung bestätigt, wenn der SSH Login vom Modul auf dem Docker-Host deaktiviert wird, dann ist die Fehlermeldung weg.

Der Host ist auf deutsch gestellt, der Docker-Container wird dann vermutlich keine deutschen Sprachdateien haben.


Anders herum: Der Docker Container ist in Englisch und nimmt seine Sprache beim Login woanders mit. Die Sprache kann nicht dynamisch anhand des Zielhosts ausgewählt werden, weil zu dem Zeitpunkt noch gar nicht klar ist, was der Zielhost macht. Deshalb ist es wichtig und richtig neben der lokalen Sprache immer auch die Standard English Locale zu generieren (en_US.UTF-8), da man ansonsten - wie du siehst - nicht kompatibel ist.


Die korrekte Vorgehensweise ist also eher, dass du auf deinem Docker Host dafür sorgst, dass neben Deutsch auch Englisch zur Verfügung steht.
Wenn du den Docker Container auf Deutsch stellst, dann musst du dir einiger Nebeneffekte bewusst sein. Es gibt FHEM Module, die ihre Spracheinstellung rein über die Systemsprache steuern. Das bedeutet, dass Readingswerte und teilweise auch die Readingsnamen dann auf die deutsche Sprache festgelegt sind und somit nicht mehr zwingend transportabel. Du weichst dann wissentlich von der Standardsprache "Englisch" ab und solltest dir aller Konsequenzen bewusst sein.


Hab jetzt einfach auf meinem Host noch en_US.UTF-8 dazu installiert, bis jetzt war nur en_EN.UTF-8 und de_DE.UTF-8 vorhanden

Das ist vermutlich im Sinne der Problemlösung die sauberste Methode...


Korrekt!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 19 Mai 2019, 12:30:51
Ich habe jetzt nochmals einige Verbesserungen was die Sprachunterstützung angeht im Container vorgenommen:
https://github.com/fhem/fhem-docker/blob/d1bb5be9d1669dd4491e63c6882763d9bc9017e4/README.md#tweak-container-settings-using-environment-variables (https://github.com/fhem/fhem-docker/blob/d1bb5be9d1669dd4491e63c6882763d9bc9017e4/README.md#tweak-container-settings-using-environment-variables)

Das aktualisierte DEV Image baut gerade. Wenn es sich bewährt, wird es in PROD übernommen.


Für Modulautoren, die per SSH auf Fremdsysteme zugreifen, lässt sich schlussfolgern, dass es hilfreich ist, wenn sie vor dem SSH Kommando noch ein "LC_ALL=C" schreiben. Das ist speziell fürs Scripting vorgesehen, so dass ein standardisiertes Verhalten erzwungen werden kann und keine Abhängigkeit zur auf dem Zielsystem installierten Sprachen besteht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 29 Mai 2019, 08:16:24
Ah! Du meinst 'wc -l' mit kleinem 'L', das ist keine 1/Eins ;-)


Der Grund fürs unhealthy steht ja im Docker Statusfeld drin. Wahrscheinlich hast du kein Telnet device, was ohne Passwort auf localhost und Port 7072 horcht.

So nun konnte ich das Problem größtenteils beheben....
jetzt ist der Lesevorgang nicht mehr ständig aktiv. Scheinbar ist mein Log-File vollgelaufen, und der wc -l Befehl hat den Raspi so ausgelastet, das es zu erheblichen verzögerungen gekommen ist...
Hab jetzt erstmal auf Tagslog (werde noch auf Wochenlog wechseln) und jetzt ist der Befehl unter htop nicht mal mehr zu finden...
nur zur Info, falls jemand auch das Problem hat...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: patlabor am 02 Juni 2019, 14:06:22
Hallo nochmal,

habe gerade versucht meinen Mi Vacuum in mein unter Docker laufendes fhem einzubinden.
Leider fehlt hierzu ein Perl Modul.
Crypt::Cipher::AES or Crypt::Rijndael_PP is required!Ich kann es natürlich von Hand nachinstallieren, dann klappt auch alles wunderbar, einmal einen neuen Container erstellt und alles ist wieder weg. Da die Installation (auf meinem Raspi) leider auch ziemlich zeitaufwendig ist, ist es auch nur eine Notlösung das ganze per Script zu lösen.
Ist es möglich das entsprechende Modul mit ins Containerimage zu übernehmen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 02 Juni 2019, 14:53:57
Die selben zeitlichen Schwierigkeiten, wie du bei deinem lokalen Rapi hast, gibt es beim Bau des Images auf dem Server ebenfalls. Laufzeiten sind dort jedoch zusätzlich beschränkt, so dass Perl Module, die sehr lange zum kompilieren brauchen, nicht mit enthalten sind. Das betrifft ganz besonders sehr viele Crypto Perl Module. Hinzu kommt, dass ganz besonders diese Perl Module dann häufig auch nicht stabil oder gar nicht kompilieren, besonders wenn es sich um die Geräteplattform ARM handelt und diese nur auf einer x86_64 CPU über QEMU emuliert wird.


Crypt::Rijndael_PP als pure Perl Implementierung (--> "_PP" am Ende) scheint mir recht neu zu sein und ist mir bisher nicht als Abhängigkeit aufgefallen. Hier ist zu hoffen, dass die Installation nicht lange dauert. Ich schaue mal, ob das Image so noch baut. Es kann aber jederzeit sein, dass das Modul nicht mehr baut und es sich nicht beheben lässt. In dem Fall wird es dann wieder aus dem Image verschwinden - entweder ganz oder zumindest für die ARM Plattformen. Daher ist der langfristige Rat, dass du dich von deiner ARM Abhängigkeit löst.




Edit: Neues PROD Image mit Crypt::Rijndael_PP (auch für ARM) baut gerade.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Feinfinger am 25 Juni 2019, 08:24:58
Hallo zusammen,

Ich nutze das Fhem-Basis Image in der aktuellen Version.

Leider geht seit einigen Tagen das echodevice von mwinkler nicht mehr, anscheinend hat sich der Amazon Login geändert.

Das workaround, npm zu installieren scheitert leider.

root@0722932d1695:/opt/fhem# sudo npm install --prefix /opt/fhem/cache/alexa-cookie alexa-cookie2
npm WARN saveError ENOENT: no such file or directory, open '/opt/fhem/cache/alexa-cookie/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/opt/fhem/cache/alexa-cookie/package.json'
npm WARN alexa-cookie No description
npm WARN alexa-cookie No repository field.
npm WARN alexa-cookie No README data
npm WARN alexa-cookie No license field.

Dieser Fehler wird ausgegeben, wenn ich es in der Shell des Fhem-Containers ausführe.

Kann mir jemand helfen?

Gruß Feinfinger
Titel: Offizielles FHEM Docker Basis Image auf Syno 918+
Beitrag von: Dirk070 am 02 Juli 2019, 14:23:06
Hallo zusammen,

ich habe das Docker-Image auf der Syno installiert. Aktuell habe ich Fhem noch direkt auf der Syno unter ActivePerl laufen.
Also die aktuelle Installation im Paket-Manager angehalten, damit nicht 2 Fhem-Instanzen laufen.

Dann den Container analog dieser Einstellungen hier eingerichtet: https://github.com/oznu/docker-homebridge/wiki/Homebridge-on-Synology (https://github.com/oznu/docker-homebridge/wiki/Homebridge-on-Synology)
Dazu das Volume "fhem" unterhalb von Docker angelegt und die Inhalte des Verzeichnis /volume1/@appstore/fhem/opt nach /volume1/docker/fhem kopiert.

Soweit so gut, Fhem läuft. Toll (bin Anfänger bzgl. Docker!)

Aber: folgender Fehler erscheint alle 20 Sekunden im Log:
ERROR evaluating { DockerImageInfo_GetImageInfo(); }: Undefined subroutine &main::DockerImageInfo_GetImageInfo called at (eval 723) line 1.
Kann mir jemand helfen herauszufinden, was da schief läuft?

Danke Euch und viele Grüße
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 02 Juli 2019, 14:31:15
Beim Start des Containers wird normalerweise das FHEM Modul 99_DockerImageInfo.pm in das ./FHEM Verzeichnis kopiert. Darin ist besagte Funktion enthalten, die für das Monitoring bzw. den Health Check von Docker verwendet wird.


Ich vermute stark, dass die Datei nicht kopiert werden konnte, weil irgendwas mit den Zugriffsrechten des Benutzers, unter dem der Docker Prozess läuft, nicht stimmt. Das ist aber in jedem Fall eine Synology spezifische Angelegenheit, bei der ich nicht helfen kann, da ich kein solches Gerät besitze.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 02 Juli 2019, 14:54:36
Hallo Loredo,

Danke für die Info. Ich habe die Modul 99_DockerImageInfo.pm manuell über "Edit Files" in Fhem angelegt, mit dem Code aus dem GitHub.
Container neu gestartet und die Meldung ist weg. Sieht also erstmal gut aus.

Dabei ist mir aber aufgefallen, dass mein angelegt Verzeichnis für Fhem nun leer ist.
Die Installation ist unter /volume1/@docker/volumes in einem kryptisch (dynamisch) benannten Verzeichnis gelandet.

Ich vermute mal, dass dieses Verzeichnis gelöscht wird, wenn ich den Container lösche.
Wie lässt sich denn das verhindern?

Danke und Gruß
Dirk
Titel: Lösung Syno-Docker
Beitrag von: Dirk070 am 02 Juli 2019, 15:39:51
Hallo,

ich denke, ich habe die Lösung.

Der letzte Punkt zeigt die Verzeichnisse, wenn vorher über das Paketzentrum der Syno das Fhem-Paket genutzt wurde.

Container starten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 02 Juli 2019, 15:45:12
Nein, ich weiß jetzt, was du falsch machst.
Du musst deine FHEM Installation nicht nach /volume1/docker/fhem kopieren, sondern nach /volume1/docker/opt/fhem (analog zum Grundsatz, dass FHEM normalerweise in /opt/fhem installiert ist).


In dem ersten Verzeichnis liegt die leere FHEM Installation, die jedes Image dann kopiert, wenn du noch keine fertige FHEM Installation mitbringst. Darin ist auch 99_DockerImageInfo.pm enthalten und wird auch von dort nach der Aktualisierung des Images rüber kopiert, um ein Update des Moduls zu gewährleisten. Du kannst nicht einfach die mitgelieferte FHEM Installation überschreiben, die löscht das Image selbstständig nach dem ersten Start eines neuen Containers.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 02 Juli 2019, 16:35:03
Danke für Deine Hilfe.
Mit dem letzten von mir beschriebenen Ablauf funktioniert es aktuell, der Inhalt des Verzeichnis wird nicht mehr gelöscht.

Das Verzeichnis beinhaltet nun die Dateien und die Logs werden dort auch aktualisiert.
Mit meinem Laien-Verständnis müsste doch das docker/fhem auf das opt/fhem aus dem Container gemapped werden.
Dann wäre es egal, ob ich physisch noch ein "opt" anlege.

Oder bin ich auf dem Holzweg.....und warum funktioniert es jetzt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 02 Juli 2019, 16:44:01
Du bist auf dem Holzweg, weil das Image nunmal anders arbeitet und nicht vorherzusagen ist, was bei einem Update (sprich der Neuerstellung des Containers) passiert. Aktuell hast du wahrscheinlich einfach Glück, weil der Container ab dem zweiten Start ein anderes Verhalten hat.
In jedem Fall bekommst du keine Updates des 99_DockerImageInfo Moduls, wenn du das Verzeichnis vorher überschreibst.

Btw, ich weiß nicht wie Synology das macht, aber du willst nichts direkt in das Image hinein kopieren, sondern ein permanentes Volume in das Image nach /opt/fhem mappen. Ansonsten sind deine FHEM Änderungen weg, wenn du den Container aktualisierst.

Beschäftige dich etwas mehr mit den Docker Grundlagen, das ist nichts FHEM spezifisches :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 02 Juli 2019, 17:28:52
Mache ich, Danke jedenfalls für die Erklärungen!!!!

Ich probiere die Tage mal, den Container neu zu starten und auch mal neu aufzusetzen. Dann sehe ich ja, was mit den Einstellungen etc. passiert.

Eine Info/Frage aber doch noch: mein Ordner "/volume1/docker/fhem" ist ein permanentes Verzeichnis (den Unterordner "docker" habe ich so benannt, das hat nichts mit der Dockerverwaltung der Syno zu tun).
Titel: GELÖST: Offizielles FHEM Docker Basis Image auf der Syno
Beitrag von: Dirk070 am 03 Juli 2019, 10:18:16
So, hier nun das zugesagte Ergebnis des Tests auf der Syno.
Vorweg, das "/volume1/docker/fhem" ist ein permanentes Verzeichnis, das ich angelegt habe und befindet sich nicht im Docker-Container.
Ich habe in diesem Verzeichnis die persistenten Daten aller Docker-Images abgelegt, mit jeweils einem Unterverzeichnis pro Container.

Zum Test: ich habe den Container gestoppt und anschließend gelöscht. Danach einen neuen Container aus dem selben Abbild mit identischen Einstellungen erzeugt.
Nach dem Start hat Fhem im Log alle Infos gezeigt, die auch vor dem Stop/Löschen vorhanden waren. So sollte es sein.

Zur Info für alle Syno-Anwender:
Man kann die Einstellungen eines Containers in eine Datei exportieren (ca. 1KB).
Löscht man den Container, kann man diesen über den Import mit 2 Klicks wieder erzeugen.
Dürfte bei Updates auf das Abbild interessant sein.

Nochmals Danke an Loredo für den Austausch und Deine Infos. Und natürlich für das Image!!!! Super Sache.

Viele Grüße
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 08 Juli 2019, 18:56:28
Zum Feierabend noch ein Schmankerl:


Ein auf Debian Buster basierendes FHEM Docker Image will getestet werden, bevor ich es als neues Produktiv-Image markiere:


docker pull fhem/fhem-amd64_linux:buster
docker pull fhem/fhem-i386_linux:buster
docker pull fhem/fhem-arm32v5_linux:buster
docker pull fhem/fhem-arm32v7_linux:buster
docker pull fhem/fhem-arm64v8_linux:buster


Wie man sieht gibt es die bekannten Geschmacksrichtungen. Da Python3 RPi.GPIO nicht baut, ist es aktuell nicht mehr im Image enthalten. Ich bin auch nach wie vor nicht sicher, ob es dort überhaupt benötigt wird oder ob man diese Pakete nicht ohnehin eher auf dem "Host" System braucht. Da ich keinen RPi mit GPIO nutze, kann ich das nicht beurteilen.


Sofern im Laufe der Woche keine Probleme von freiwilligen Testern gemeldet werden, markiere ich Buster als Standard Image. Dann wird es auch unter "fhem/fhem" abrufbar sein, ohne dass man eine Plattform explizit angeben muss.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 08 Juli 2019, 22:02:19
ich hab mal fhem/fhem-amd64_linux:buster gezogen, werde zwar nicht viel testen können, aber ich beobachte mal ob im Log oder auch so irgend was auffällt
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 09 Juli 2019, 09:30:16
Hallo ich muss gestehen ich habe mir jetzt nicht die 27 Seiten durchgelesen.

Ich hatte bis vor paar Woche (in der Wohnung) FHEM auf einem Raspberry PI 2 laufen.
Da ich nun einen Unraid Sever habe der 24/7 läuft und noch Reserven hat, würde ich FHEM gerne darauf laufen lassen (sind nun ins Haus gezogen)

Meine Frage läuft der FHEM im Docker nun schon stabil genug, und kann ich da auch alles drauf laufen lassen was ich benötige?
FHEM wird nur als NivetoHAve laufen - sprich alle Grundfunktionen laufen von haus aus schon mal.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 09 Juli 2019, 10:48:43
Aus meiner Sicht läuft das Docker Image sehr stabil.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 09 Juli 2019, 12:10:59
Meine Frage läuft der FHEM im Docker nun schon stabil genug, und kann ich da auch alles drauf laufen lassen was ich benötige?
FHEM wird nur als NivetoHAve laufen - sprich alle Grundfunktionen laufen von haus aus schon mal.

Ich habe schon eine Weile am Laufen, zuerst auf RPI und jetzt auf Linux Server .. läuft alles. Netzwerkdesign Docker ist halt anders als nativ. Netzwerk Magic Package z. B. geht niczht durch (Wake on Lan) ... Solche Dinge können auffallen. Ist aber dann Docker spezifisch und hat nichts mit Fhem zu tun.

Bis jetz tkonnte ich alles lösen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 09 Juli 2019, 19:08:54
Wie hast Du das mit dem Magic Packet gelöst? Ich habe jetzt schon einige Apps drumherum gedockert, jetzt will ich zeitnah auch an FHEM ran.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 09 Juli 2019, 19:15:45
Wie hast Du das mit dem Magic Packet gelöst? Ich habe jetzt schon einige Apps drumherum gedockert, jetzt will ich zeitnah auch an FHEM ran.


Gesendet von iPhone mit Tapatalk
Ich hab das wol Modul umgebaut um per ssh auf dem host das Paket zu senden. Du könntest auch host Networking machen. Das will ich aber nicht. Sicherheit ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 09 Juli 2019, 19:39:26
Die selben zeitlichen Schwierigkeiten, wie du bei deinem lokalen Rapi hast, gibt es beim Bau des Images auf dem Server ebenfalls. Laufzeiten sind dort jedoch zusätzlich beschränkt, so dass Perl Module, die sehr lange zum kompilieren brauchen, nicht mit enthalten sind. Das betrifft ganz besonders sehr viele Crypto Perl Module. Hinzu kommt, dass ganz besonders diese Perl Module dann häufig auch nicht stabil oder gar nicht kompilieren, besonders wenn es sich um die Geräteplattform ARM handelt und diese nur auf einer x86_64 CPU über QEMU emuliert wird.


Crypt::Rijndael_PP als pure Perl Implementierung (--> "_PP" am Ende) scheint mir recht neu zu sein und ist mir bisher nicht als Abhängigkeit aufgefallen. Hier ist zu hoffen, dass die Installation nicht lange dauert. Ich schaue mal, ob das Image so noch baut. Es kann aber jederzeit sein, dass das Modul nicht mehr baut und es sich nicht beheben lässt. In dem Fall wird es dann wieder aus dem Image verschwinden - entweder ganz oder zumindest für die ARM Plattformen. Daher ist der langfristige Rat, dass du dich von deiner ARM Abhängigkeit löst.




Edit: Neues PROD Image mit Crypt::Rijndael_PP (auch für ARM) baut gerade.
Weil das hier gerade aufgerufen wurde, hat mich im Dockerfile gewundert, dass kein Paket libcrypt-rijndael-perl installiert wird. Eigentlich war das immer die Basis, damit Homematic Devices mit AES funktionieren.
Übersehe ich da etwas?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 09 Juli 2019, 20:28:19
Ich hab das wol Modul umgebaut um per ssh auf dem host das Paket zu senden. Du könntest auch host Networking machen. Das will ich aber nicht. Sicherheit ...
Gibt es die Modifikation irgendwo abgelegt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 09 Juli 2019, 20:34:00
Gibt es die Modifikation irgendwo abgelegt?
ist quick'n'dirty ...

Request der Änderung bzw. Erweiterung damit SSH genutzt wird
https://forum.fhem.de/index.php/topic,97064.msg943070.html#msg943070

Codeänderung
https://forum.fhem.de/index.php/topic,87714.msg943068.html#msg943068

Musst halt dann WOL-Modul vom Update ausnehmen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 09 Juli 2019, 20:52:35
ich hab mal fhem/fhem-amd64_linux:buster gezogen, werde zwar nicht viel testen können, aber ich beobachte mal ob im Log oder auch so irgend was auffällt

Mir ist schon mal aufgefallen, dass speedtest-cli für das Modul nun woanders liegt. Ist ein Attribut im Modul (Path). Wer aber nicht weiß, wie man das im Docker prüft wird nachfragen.

Früher /usr/local/bin/speedtest-cli
Buster /usr/bin/speedtest-cli

Last auf dem System:
Mem: würde sagen, ist identisch. Die stündlichen Spikes sind nicht da weil speedtest-cli nicht gefunden wurde
CPU: wenn man die 1% Linie ansieht scheint es, als wäre CPU etwas höher. Die Spikes haben etwas höhere Ausschläge.

Mein Server ist für FHEM oversized, darum ist die Systemlast unter 1%. Da kann eventuell jemand mit schwächer Hardware testen. Bei mir kann FHEM aus dem Vollen schöpfen, habe einige Docker laufen auf einem virtuellen Host mit 8 GB Ram, und vollen Zugriff auf CPU (i3 5010U).

Die rote Linie zeigt den Reboot nachdem das neue Image geladen wurde.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 09 Juli 2019, 20:56:35
Eine Frage hätte ich noch zum Image. Gibt es einen Grund, warum stretch getagged wird und nicht stretch-slim?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 10 Juli 2019, 12:31:08
Weil das hier gerade aufgerufen wurde, hat mich im Dockerfile gewundert, dass kein Paket libcrypt-rijndael-perl installiert wird. Eigentlich war das immer die Basis, damit Homematic Devices mit AES funktionieren.
Übersehe ich da etwas?


Ja:
https://github.com/fhem/fhem-docker/blob/3b4b4d040053c206d1dd58dd29d0ba5cb673a736/Dockerfile#L252

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 10 Juli 2019, 12:32:37
Eine Frage hätte ich noch zum Image. Gibt es einen Grund, warum stretch getagged wird und nicht stretch-slim?


Es gab/gibt einen Grund, aber ich kriege das gerade nicht mehr unbedingt zusammen. Aber ist das nicht wirklich egal und eher eine homöopatische Frage...  ::)


EDIT: Ich glaube es lag vor allem daran, dass die Locale/Sprachdateien so stark aufgeräumt werden und somit keine umfassende Sprachunterstützung mehr möglich ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 10 Juli 2019, 18:58:17
Ich habe schon eine Weile am Laufen, zuerst auf RPI und jetzt auf Linux Server .. läuft alles. Netzwerkdesign Docker ist halt anders als nativ. Netzwerk Magic Package z. B. geht niczht durch (Wake on Lan) ... Solche Dinge können auffallen.


Inzwischen tendiere ich dazu die Empfehlung durchaus zu geben, dass der Container im Netzwerk Modus "host" betrieben wird.
Der Grund ist, dass es inzwischen mit mit (einer noch nicht im SVN veröffentlichten Version) dem Siri Modul in Kombination mit dem npmjs Modul sehr leicht möglich ist Homebridge zu installieren. Bekanntlich basiert Homekit stark auf mDNS und ohne die Komplexität eines weiteren Proxy ist es doch einfacher, wenn man den Container einfach im Hostmode laufen lässt. Diejenigen, denen es neben der Funktion auch auf das i-Tüpfelchen an Sicherheit ankommt, die haben in der Regel ohnehin die Möglichkeit einen virtuellen Server nur für Docker abzustellen. Sprich, wenn man Docker in einem virtuellen Server laufen lässt statt bare metal, dann kann man dort IMHO auch getrost den FHEM Container direkt im selben LAN betreiben. Wer es übertreiben will, muss ja nicht auf dem selben virtuellen Server auch andere Container betreiben... somit bekommt man das, was man von einem Docker Container erwartet: Eine fix und fertige Laufzeitumgebung für FHEM, die einfach zu replizieren ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 10 Juli 2019, 19:01:09
EDIT: Ich glaube es lag vor allem daran, dass die Locale/Sprachdateien so stark aufgeräumt werden und somit keine umfassende Sprachunterstützung mehr möglich ist.
Das ist definitiv so, Locales und manpages werden abgeräumt. Ist aber eigentlich nichts, was man in einem Container braucht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 10 Juli 2019, 19:21:55
Doch, wenn man mit unterschiedlichen Zeitzonen oder Sprachen gleichzeitig arbeiten möchte.
Das fängt schon an, dass viele (und ich auch) gerne das System und die Backend Konfiguration in Englisch haben, das User Interface aber für andere auch in Deutsch sein soll (nebst korrekter Formatierung von Zahlen und Zeiten). Das Astro Modul erlaubt dies beispielsweise, kann das aber nur, wenn das Betriebssystem unten drunter nicht alle Sprachen außer Englisch abgeräumt hat.


Es gibt auch Benutzer, die haben ihr Ferienhaus auf Teneriffa in ihrer lokalen FHEM Instanz zuhause mit drin (also beispielsweise eben die Astrodaten). Das liegt aber in einer anderen Zeitzone und womöglich möchte man die Zeiten nicht in der deutschen Zeit angezeigt bekommen, sondern in Ortszeit. Das Astro Modul kann auch das, aber eben wieder nur, wenn das System unten drunter nicht die Zeitzonen Unterstützung gestutzt bekommen hat.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 10 Juli 2019, 19:24:21

Inzwischen tendiere ich dazu die Empfehlung durchaus zu geben, dass der Container im Netzwerk Modus "host" betrieben wird.
Der Grund ist, dass es inzwischen mit mit (einer noch nicht im SVN veröffentlichten Version) dem Siri Modul in Kombination mit dem npmjs Modul sehr leicht möglich ist Homebridge zu installieren. Bekanntlich basiert Homekit stark auf mDNS und ohne die Komplexität eines weiteren Proxy ist es doch einfacher, wenn man den Container einfach im Hostmode laufen lässt. Diejenigen, denen es neben der Funktion auch auf das i-Tüpfelchen an Sicherheit ankommt, die haben in der Regel ohnehin die Möglichkeit einen virtuellen Server nur für Docker abzustellen. Sprich, wenn man Docker in einem virtuellen Server laufen lässt statt bare metal, dann kann man dort IMHO auch getrost den FHEM Container direkt im selben LAN betreiben. Wer es übertreiben will, muss ja nicht auf dem selben virtuellen Server auch andere Container betreiben... somit bekommt man das, was man von einem Docker Container erwartet: Eine fix und fertige Laufzeitumgebung für FHEM, die einfach zu replizieren ist.
Ich sehe das ein bisschen anders. Der Vorteil von Docker ist, dass ich unterschiedliche Applikationen auch in ihren Abhängigkeiten von Bibliotheken etc. super entkoppeln kann. Ich habe zwei Homebridges in Docker laufen und wenn ich was Neues probieren will, ziehe ich mir kurz eine dritte und vierte hoch, ohne die Stabilität meiner laufenden einzuschränken.
Das von Dir doch wieder alles in einen Container pack-Konzept wird dem aber nicht gerecht. Die Entkoppelung einzelner Komponenten und Verpackung in schlanke Images ist eines der Basiskonzepte von Docker. Mit Docker-compose gibt es auch eine exzellente Möglichkeit diese komplexeren Konfigurationen zu erstellen, zu transportieren und auch zu versionieren.
Daher werde ich vermutlich auch eher kein Kunde für das Fertig-Image werden, aber gern auf die Ideen im Dockerfile zurückgreifen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 10 Juli 2019, 19:25:52
Das bleibt ja jedem selbst überlassen, wieviel Arbeit sich jeder damit machen will. Ob das tatsächlich nötig ist bzw. wie die Kosten/Nutzen Bilanz aussieht, muss jeder für sich selbst beurteilen. Du hast ja alle Möglichkeiten und musst keinesfalls alles aus dem Image heraus nutzen. Und selbstverständlich kannst du so viele andere Container nebendran laufen lassen, wie du magst. Die Überlappungen von Ports musst du da genauso managen, das ist also weder pro noch contra.


Man muss auch einfach erkennen, dass FHEM kein Microservice Dienst ist. Ich würde den Vergleich zwischen dem FHEM Docker Image und dem Home Assistant Image durchaus ziehen wollen... Ziel ist einfachste Inbetriebnahme und Recovery, nicht das bauen komplexester Zusammenhänge. Es soll Komplexität genommen werden, nicht die Basis für mehr Komplexität geschaffen. Aber ich denke das habe ich schon oft genug ausgeführt ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 13 Juli 2019, 18:49:12
Schau Dir bitte mal den folgenden commit an:
https://github.com/fhem/fhem-docker/commit/449f647ca54576d856a33185cee8b480cd8d5ed0

Ich würde es für sinnvoll halten, wenn Du das für das Image übernimmst, da es die Zahl der intermediate Layer ein Stück reduziert. 
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 13 Juli 2019, 20:11:32
Wofür genau muss man die reduzieren?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 13 Juli 2019, 20:27:59
Der Build dürfte inperformanter sein. Du kannst ja mal
 docker history fhem/fhem
machen oder Dir den Log Output ansehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 Juli 2019, 10:55:53
Schau Dir bitte mal den folgenden commit an:
https://github.com/fhem/fhem-docker/commit/449f647ca54576d856a33185cee8b480cd8d5ed0 (https://github.com/fhem/fhem-docker/commit/449f647ca54576d856a33185cee8b480cd8d5ed0)

Ich würde es für sinnvoll halten, wenn Du das für das Image übernimmst, da es die Zahl der intermediate Layer ein Stück reduziert.


Ich frage mich noch immer, weshalb du in mein Repository direkt commited hast (und es wohl konntest?) und keinen Pull Request erstellst. Außerdem findet man die Commits komischerweise nur über den Direktlink, sehr verwirrend. Ich habe weder einen Überblick über deine Änderungen (ist wohl offenbar mehr als nur der eine Commit) noch kann ich diese überhaupt technisch übernehmen.
Bitte zukünftig an den Prozess halten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 14 Juli 2019, 11:05:39

Ich frage mich noch immer, weshalb du in mein Repository direkt commited hast und keinen Pull Request erstellst. Außerdem findet man die Commits komischerweise nur über den Direktlink, sehr verwirrend.
Ich habe nichts gegen Dein Repository commited. Das scheint die github-interne Anzeige zu sein, wenn man auf den commit in einem Fork verlinkt. Könnte ich auf garnicht, da ich sicher nicht als Collaborator eingetragen bin.  ;)
Das war nur ein Finding in meinen aktuellen Spielereien. PR habe ich bisher nicht geplant.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 Juli 2019, 11:27:50
Mir ist schon mal aufgefallen, dass speedtest-cli für das Modul nun woanders liegt. Ist ein Attribut im Modul (Path). Wer aber nicht weiß, wie man das im Docker prüft wird nachfragen.

Früher /usr/local/bin/speedtest-cli
Buster /usr/bin/speedtest-cli


Das FHEM Modul für speedtest ist ein Wackelkandidat. Zum Zeitpunkt der Erstellung des Squeeze Images hatte das Modul den Pfad /usr/local/speedtest-cli/speedtest-cli hard codiert, weshalb auch damals schon ein Symlink dorthin angelegt wurde. Wenn das Modul jetzt plötzlich /usr/local/bin/speedtest-cli will, ohne dass man was einstellen muss, scheint mir das neu. Ich habe den Symlink angepasst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 Juli 2019, 11:43:22
Ich habe nichts gegen Dein Repository commited. Das scheint die github-interne Anzeige zu sein, wenn man auf den commit in einem Fork verlinkt.


Sehr dubios das, eigentlich sind Links immer so, dass die den User enthalten, wo der Fork zu finden ist. Über die GUI kann man gar keinen anderen Link generieren ;)
Spannend aber, dass trotz des unterschiedlichen Repositories der Commit gefunden und angezeigt wird. IMHO ein Github Bug ^^
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 14 Juli 2019, 13:57:29
Du könntest bei Gelegenheit noch das Readme zu git anpassen. Es muss sich natürlich niemand einen Account bei Bitbucket holen, der schon auf Github ist, da die seit Januar 2019 auch frei unbegrenzte private Repositories anbieten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 Juli 2019, 14:41:43
Danke, ich habs angepasst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: plin am 14 Juli 2019, 19:11:09
Hi Loredo,

ich wollte mir gerade für's Debugging eines SIP-Problems einen frischen FHEM-container bauen. Ich habe den alten docker container sowie das gecachte Image gelöscht und mittels
docker pull fhem/fhem
das aktuellste runter geladen. Container gestartet und mein SIP-Device angelegt. Dann wollte einen Anruf testen. Das führte zur Fehlermeldung

sh: 1: ps: not found
2019.07.14 19:04:20.149 1: SipTest[774], can´t find my parent 199 in process list !
Died at ./FHEM/96_SIP.pm line 386.

Fehlt ps im aktuellen Image?

VG plin
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 14 Juli 2019, 22:07:32

Das FHEM Modul für speedtest ist ein Wackelkandidat. Zum Zeitpunkt der Erstellung des Squeeze Images hatte das Modul den Pfad /usr/local/speedtest-cli/speedtest-cli hard codiert, weshalb auch damals schon ein Symlink dorthin angelegt wurde. Wenn das Modul jetzt plötzlich /usr/local/bin/speedtest-cli will, ohne dass man was einstellen muss, scheint mir das neu. Ich habe den Symlink angepasst.

das Modul hat ein Attribut "path" in dem man angeben kann, wo die Libs lieben. Hier hatte ich - vor Docker - den Defaultpath /usr/local/bin eingetragen. Das hatte auch bis jetzt funktioniert. Der Pfad kommt vom Wiki-Artikel https://wiki.fhem.de/wiki/Speedtest

Nun in Buster lag das Programm in /usr/bin ... also Abweichend von der Wiki-Anleitung (die wahrscheinlich die meisten nutzen). Das meinte ich mit meinem Post, nicht den hardcoded Pfad im Modul selbst.

Im aktuellen Container sind beide Pfade möglich. Danke dir!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 15 Juli 2019, 10:15:07
sh: 1: ps: not found
2019.07.14 19:04:20.149 1: SipTest[774], can´t find my parent 199 in process list !
Died at ./FHEM/96_SIP.pm line 386.

Fehlt ps im aktuellen Image?


Offenbar hat das Debian Team entschieden, dass das Paket procps nun nicht mehr standardmäßig mitinstalliert wird. Ich füge es explizit dem Image hinzu.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: plin am 15 Juli 2019, 17:50:58
Offenbar hat das Debian Team entschieden, dass das Paket procps nun nicht mehr standardmäßig mitinstalliert wird. Ich füge es explizit dem Image hinzu.

Danke
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 17 Juli 2019, 16:04:03
Hallo,

hier im Forum ist eine Möglichkeit beschrieben worden, den Homepod für eine Sprachausgabe zu nutzen.
https://forum.fhem.de/index.php/topic,102295.0.html (https://forum.fhem.de/index.php/topic,102295.0.html)

Dazu wird Node AirTunes (mit einem Bugfix) genutzt. Wäre es möglich, Node AirTunes inkl. dem Bugfix ins Image aufzunehmen?
Den Homepod auch für die Sprachausgabe aus FHEM zu nutzen ist noch eine offene Baustelle (zumindest bei mir).

Danke vorab und schöne Grüße
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 18 Juli 2019, 05:18:43
Moin moin  :)

Ich hab nun endlich meinen Server in den produktiven Betrieb genommen und habe somit nun alles in schönen Containern.

Wie kann ich denn noch arp-scan und hping3 mir dazu installieren ohne viel Aufwand - alternativ könnte ich mir auch ein eigenes Dockerfiles bauen.... tu mich aktuell nur noch etwas schwer wie es dann sein muss :-D
Brauche die beiden für meine Anwesenheitserkennung -> https://forum.fhem.de/index.php/topic,76342.msg769242.html#msg769242

Vielen Danke für die Arbeit mit dem Docker Image soweit :-) funzt wunderbar.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 18 Juli 2019, 08:22:04
Also bei mir läufts auch perfekt, habe das Docker Image im unraid laufen, und da bekommts eine eigene IP Adresse, dadruch bruache ich nicht wirklich was machen, und es läuft alles bisher ohne irgendwelche probleme
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 18 Juli 2019, 09:20:48
Joa ich hab ihm auch einfach Hostnetzwerkzugriff gegeben - aber es fehlen für mich persönlich halt die 2 Anwendungen ;-D (arp-scan und hping3)
Die versuche ich mit "APT_PKGS="package1 package2" nun rein zu holen. -> klappt perfekt! Sehr genial gemacht


*Edit denke mal hier könnte ich mit arbeiten ->
Zitat
/pre-init.sh - Wird beim allerersten Start des Containers noch vor der FHEM Installation ausgeführt.

Leider gibt es wohl massive probleme einzelne dateien in einen docker container zu mounten. Zumindest unter Rancher mit Kubernetes - und das nutze ich :-)
Könnte man die Scripts eventuell im Image in einen unterordner packen? Dann wäre das einfach mit einem Volume mount zu machen.


*EDIT

Genau das Nachfolgende, geht so für mich leider nicht - daher meine Bitte die scripts in ein Unterverzeichnis zu legen, dass würde extrem helfen :-D

Scheint nicht ganz offensichtlich, aber die Lösung ist ganz einfach: Du kannst auch einzelne Dateien und nicht nur Verzeichnisse in den Container mounten:


            - ./fhem/data/:/opt/fhem/
            - ./fhem/config/pre-init.sh:/pre-init.sh

@Loredo wäre das denkbar :-) für die die nur docker nutzen ist es ja kein Beinbruch das in einen Unterordner zu mounten.
Ich muss z. B. die fhem-docker unter /etc/sudoers.d anpassen damit bei "sudo arp-scan" und "sudo hping3" mir nicht ein blocker entsteht und derartiges :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 19 Juli 2019, 10:44:28
Dazu wird Node AirTunes (mit einem Bugfix) genutzt. Wäre es möglich, Node AirTunes inkl. dem Bugfix ins Image aufzunehmen?


Schau dir mal die Möglichkeit an selbst Pakete in das Image beim ersten Start des Containers nachzuinstallieren:
https://github.com/fhem/fhem-docker#add-custom-packages (https://github.com/fhem/fhem-docker#add-custom-packages)


Sofern das reine installieren eines Paketes nicht genügt, kannst du auch zusätzlich noch ein pre-init Script nach "/pre-init.sh" über "-v" als Volume mounten (https://docs.docker.com/storage/volumes/), dessen Befehle dann ebenfalls beim ersten Start abgearbeitet werden. Mir ist aufgefallen, dass diese Möglichkeit noch nicht in der README.md erwähnt ist, werde ich ergänzen.


Leider gibt es wohl massive probleme einzelne dateien in einen docker container zu mounten. Zumindest unter Rancher mit Kubernetes - und das nutze ich :-)
Könnte man die Scripts eventuell im Image in einen unterordner packen? Dann wäre das einfach mit einem Volume mount zu machen.


Diese Komplikation war mir bisher nicht bekannt, danke dafür. Ich ergänze das Startscript noch dahingehend, dass man die Scripts auch als Verzeichnis nach /docker mounten kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 19 Juli 2019, 11:11:53

*Edit denke mal hier könnte ich mit arbeiten ->
Leider gibt es wohl massive probleme einzelne dateien in einen docker container zu mounten. Zumindest unter Rancher mit Kubernetes - und das nutze ich :-)
Noch ein k3s-Nutzer. Cool. Ich bin allerdings noch in der Testphase.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 19 Juli 2019, 12:28:02
@Loredo - klasse vielen Dank!

@volschin ich kenne es nur unter k8s ;-)

Also ich kann Rancher echt empfehlen - auch die weiterreichung von USB Geräten in den FHEM Container - einfach mal 0 aufwand... eingesteckt - fertig.

Ich habe nun nanoCUL und USB BT Stack mit dem Container in Nutzung.
Klappt alles großartig - vielen vielen Dank Loredo!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 19 Juli 2019, 12:28:22
Image Version 2.0.2 steht bereit, die README.md (https://github.com/fhem/fhem-docker/blob/dev/README.md) wurde aktualisiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 19 Juli 2019, 12:28:58
Gaheil!  ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 19 Juli 2019, 13:06:33
@volschin ich kenne es nur unter k8s ;-)
Ok, ein Missverständnis. [emoji3526]
Ich dachte, wenn schon Rancher, dann komplett.
https://k3s.io/
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 19 Juli 2019, 14:48:22
Ach das heißt dann mit Rancher k3s? :-D Was es nicht so gibt...

Den hier hab ich laufen -> https://rancher.com/products/rancher/
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 19 Juli 2019, 15:59:00

Schau dir mal die Möglichkeit an selbst Pakete in das Image beim ersten Start des Containers nachzuinstallieren:
https://github.com/fhem/fhem-docker#add-custom-packages (https://github.com/fhem/fhem-docker#add-custom-packages)


Sofern das reine installieren eines Paketes nicht genügt, kannst du auch zusätzlich noch ein pre-init Script nach "/pre-init.sh" über "-v" als Volume mounten (https://docs.docker.com/storage/volumes/), dessen Befehle dann ebenfalls beim ersten Start abgearbeitet werden. Mir ist aufgefallen, dass diese Möglichkeit noch nicht in der README.md erwähnt ist, werde ich ergänzen.

Erstmal Danke für Deine Hilfe.  :)

Da muss ich mich zugegebenermaßen einlesen. Das Projekt auf GitHub und auch den branch habe ich gefunden.
Um dies nun als Node.js zu kompilieren braucht es diese Befehlskette:
git clone https://github.com/afaden/node_airtunes.git
cd node_airtunes
git checkout fix_port_0_error
node-gyp configure build

Da muss ich mal testen und probieren, wie ich das eingebaut bekomme.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 20 Juli 2019, 10:41:33
Wird das eigenständige Alexa-Fhem auf Dockerhub eigentlich noch weiterentwickelt oder hat sich das mit Integration in das Basisimage erledigt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 Juli 2019, 11:19:04
Da stecke ich aktuell keine Ressourcen rein.
André hat das alexa-Modul in FHEM stark darauf ausgelegt, dass alexa-fhem von diesem Modul direkt gestartet und gestoppt wird und das ganze funktioniert am zuverlässigsten ohne ein SSH auf einen entfernten Server. Mein Eindruck ist, dass das alexa-Modul seit der Änderung nicht mehr gut mit Standalone alexa-fhem Installationen umgehen kann. Solange das so ist, macht es für mich keinen Sinn das alleinige alexa-fhem-docker Image zu erweitern, denn dort möchte ich kein Bugfixing betreiben oder um die abgeschwächten Standalone Funktionalitäten des alexa-Moduls herum programmieren.


Die Integration direkt im FHEM Docker Image läuft hervorragend und rein security-technisch sehe ich keinen großen Beweggrund mehr, das unbedingt trennen zu müssen, nur weil der Kindsprozess kein Perl, sondern ein Node Prozess ist. Da sich FHEM selbstständig um das starten und stoppen kümmern kann, widerspricht das auch in keiner Weise der hier oft so hoch gehypten Philosophie "ein Prozess pro Container" (von der ich nach wie vor nichts halte, wenn es nur auf Prinzipienreiterei beruht).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 20 Juli 2019, 12:22:27
Grundsätzlich magst Du da recht haben, wenn alles benutzt wird.
Mich reizt es, das fertige Node Image zu nehmen, das entsprechend getestet ist und nur das Alexa-fhem reinzuinjecten. Werde ich wohl mal dieses Wochenende probieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 Juli 2019, 18:56:06
Mhh ich hab da so ein kleines Problem... und mein FHEM schmockt die ganze Zeit ab:

Zitat
2019.07.20 18:55:16 0: Server started with 181 defined entities (fhem.pl:19805/2019-07-09 perl:5.028001 os:linux user:fhem pid:4235)
dbus[4594]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file ../../../dbus/dbus-connection.c line 5905.
This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 Juli 2019, 23:36:22
Da solltest du mal schauen, welches deiner genutzten Module DBus verwendet und ggf. beim Modul Autor erfragen, was da schief läuft.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 Juli 2019, 23:38:15
Ok - ja ich hatte gerade den Plan mal so die Module die ich als in Frage kommend sehe raus zu nehmen das sie nicht geladen werden.

Weißt du was der Dbus ist?  :-D
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 20 Juli 2019, 23:43:47
Ich würde anfangen, indem ich die CommandRef mal nach “dbus” durchsuchte.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 Juli 2019, 23:52:00
Zitat
sudo mv 30_HUEBridge.pm 30_HUEBridge.pm.DISABLED

Das war der Retter - wie es scheint. Kein Absturz mehr beim aufruf des Raumes.
Ist aber noch nicht die Lösung vom dbus ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 21 Juli 2019, 01:56:13
Hast du zufällig am Healt-Check was angefasst? :-)
./health-check.sh: line 10: [: missing `]
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 21 Juli 2019, 09:33:47
Nein. Das würde auch beim Build bereits auffallen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 21 Juli 2019, 09:38:45
Puh - ich raff echt net was dann bei mir gerade passiert :-D

Ich kann den health-check nicht ausführen kommt die Meldung mit line 10. :-D
Aber so ca alles andere ist auch am spacken :-D
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 22 Juli 2019, 11:50:10
Ist es möglich, dass 'health-check.sh' nur für nicht configDB User geeignet ist?

Ich las in der Datei viel über fhem.cfg aber nichts über die configDB. - Alternativ verstehe ich das Script nur nicht ;-D
Den Zeile 10 Fehler habe ich weiterhin.

*Edit nachdem ich nun meine alte nicht mehr vewendete fhem.cfg mal da raus geschoben habe ->

root@fhem-bbc947bf4-g2pwf:/opt/fhem# /health-check.sh
cat: /opt/fhem/fhem.cfg: No such file or directory
cat: /opt/fhem/fhem.cfg: No such file or directory
Telnet(undefined): FAILED;

;-D ich bin gespannt ob ich es komplett falsch nutze oder was es ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Migul47 am 22 Juli 2019, 18:56:31
Hallo,

wie ist den die Auslastung des Systems bei euch? Ich hab hier fast durchgängig vollen CPU-Takt mit einem NUC mit N2820. Sollte das nicht weniger sein oder bin ich da falsch mit dem Gedanken?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 22 Juli 2019, 19:01:35
Also Volllast habe ich nicht.

Das sollte man eigentlich auch seltenst haben oder gar nie :-D Da scheint dann eher was ein wenig im Kreis zu fahren?
htop  und mal prüfen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 22 Juli 2019, 19:28:21
Migul47 wie ist dein setup. Wie läuft docker auf dem nuc. Wo musst du hohe cpu?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Migul47 am 22 Juli 2019, 20:15:31
Hallo,

zum Setup Intel NUC mit N2820 Ubuntu 18 Server LTS aktuell, Docker und Compose. Container sind FHEM von hier, Portainer, mysql, Homebridge, MQTT und Nodered. CPU-Takt wird mit Sysmon in FHEM ausgelesen. Laut sysmon taktet er nur selten runter, meistens hat er vollen Takt. Hab mal den governor von powersave auf ondemand geändert, mal shehen ob's hilft.

Danke schon mal vorab für eure Mühe
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 22 Juli 2019, 22:45:00
Hallo,

zum Setup Intel NUC mit N2820 Ubuntu 18 Server LTS aktuell, Docker und Compose. Container sind FHEM von hier, Portainer, mysql, Homebridge, MQTT und Nodered. CPU-Takt wird mit Sysmon in FHEM ausgelesen. Laut sysmon taktet er nur selten runter, meistens hat er vollen Takt. Hab mal den governor von powersave auf ondemand geändert, mal shehen ob's hilft.

Danke schon mal vorab für eure Mühe

OK, ohne ESXi oder Proxmox sondern direkt auf der Hardware. Zeige mal mit    top   Befehl  ob es wirklich Fhem ist, wie Master_Nick schon schrieb. Wenn du Docker nutzt, laufen auch andere Container, könnte es auch ein anderer Container sein? Ggf. alle Container außer Fhem stoppen und nochmal CPU prüfen. Ich habe auch Nuc aber mit ESXi und da hab ich einstellige CPU-Last bei FHEM.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 23 Juli 2019, 09:36:26
Hallo,

zum Setup Intel NUC mit N2820 Ubuntu 18 Server LTS aktuell, Docker und Compose. Container sind FHEM von hier, Portainer, mysql, Homebridge, MQTT und Nodered. CPU-Takt wird mit Sysmon in FHEM ausgelesen. Laut sysmon taktet er nur selten runter, meistens hat er vollen Takt. Hab mal den governor von powersave auf ondemand geändert, mal shehen ob's hilft.

Danke schon mal vorab für eure Mühe

Ist denn zu erkennen (durch LED oder ähnliches) ob eine Festplattenaktivität die ganze zeit vorhanden ist?
Und welcher Prozess bei HTOP lastet das System vor allem aus?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 23 Juli 2019, 11:36:50
Also eine generelle Festplattenaktivität mach ja nicht pauschal CPU Last.
Ich habe durch Rancher auf der SSD dauerhaft Aktivitäten von bis zu 13 Mb die Sekunde (das ist damit aber normal).

Ansonsten kann man mit htop iotop und top ganz gut analysieren was es sein kann.

Ich habe mit einem Rancher -> Kubernetes -> Docker Cluster folgende Last:

top - 11:34:46 up 1 day, 26 min,  1 user,  load average: 0,70, 0,70, 0,67
Tasks: 405 total,   1 running, 287 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2,4 us,  2,5 sy,  0,0 ni, 93,7 id,  1,3 wa,  0,0 hi,  0,1 si,  0,0 st
KiB Mem : 16127352 total,  2155208 free,  4362748 used,  9609396 buff/cache
KiB Swap: 16777212 total, 16777212 free,        0 used. 11424324 avail Mem


Da laufen der MQTT Borker, FHEM, Node-Red, PXE-Server, TFTP-Server, Anwesenheitserkennung drauf.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 23 Juli 2019, 14:10:26
Also eine generelle Festplattenaktivität mach ja nicht pauschal CPU Last.
Ich habe durch Rancher auf der SSD dauerhaft Aktivitäten von bis zu 13 Mb die Sekunde (das ist damit aber normal).

Ansonsten kann man mit htop iotop und top ganz gut analysieren was es sein kann.

ich kann nur sagen, das mein System auch ausgelastet war (okay ein Raspi aber tortzdem) weil ich ein Monatslog anhatte, das relativ voll war durch viele eintrage. Dies wurde durch ein Prozess für Docker ausgelesen, und hat mein System sehr verlangsamt.
Nachdem ich dies auf ein Wochenlog umgestellt hab, war mein System deutlich entspannter wieder.  Kam auch aus dem nix...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 23 Juli 2019, 15:56:26
Ja gut, dass ein Log ab einer gewissen Größe beim darin arbeiten ein System verlangsamen kann ist bekannt :-)
Dafür hatte man in FHEM (sofern man nun z. B. Temperaturen oder ähnliches loggt) - ja die 'DBLog' gebaut.

Mit kleinem Log ist es nun besser?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 23 Juli 2019, 16:36:04
Auf jeden Fall, seit dem ist alles wieder Funktionabel.. es war ja sogar davon der Health-Check gestört gewesen, und ständig war mein FHEM als "unhealthy" markiert...
aber seit dem ist es wieder sehr viel flotter :S

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 23 Juli 2019, 16:43:46
@kotaro, wenn du den nutzt :-D verrate mir doch mal wie :-D Also die im Container liegende health-check.sh

"muss" man seinen Telnet Port ändern? Oder muss man nicht?

Geht es auch mit der config.db?

Ich bekomme da nur:

root@fhem-5f7d6dbbb6-pg2kd:/# ./health-check.sh
cat: /opt/fhem/fhem.cfg: No such file or directory
cat: /opt/fhem/fhem.cfg: No such file or directory
Telnet(undefined): FAILED;

@Loredo

Ich habe gerade (glaube ich) festgestellt, dass /etc/sudoers.d/fhem-docker noch nach der Ausführung der post-init.sh mal bearbeitet wird ggf. sogar erstellt :-)
Könntest du das noch davor schieben so das post-init.sh wirklich vor dem start von FHEM ist und alles andere erledigt?  ;-)
Genau da fummel ich halt herum, da ich noch weitere Programme freigeben muss für die Nutzung ohne pw mit sudo.

Zumindest wurde meine Änderung immer wieder getilgt obwohl es durcdh die post-init.sh gemacht wurde.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 23 Juli 2019, 17:17:01
Ah wenn du den nutzt :-D verrate mir doch mal wie :-D Also die im Container liegende health-check.sh

"muss" man seinen Telnet Port ändern? Oder muss man nicht?

Geht es auch mit der config.db?

Ich bekomme da nur:

root@fhem-5f7d6dbbb6-pg2kd:/# ./health-check.sh
cat: /opt/fhem/fhem.cfg: No such file or directory
cat: /opt/fhem/fhem.cfg: No such file or directory
Telnet(undefined): FAILED;

ein Kurzer Blick in die GitHub zeigt mir leider folgende Zeilen:
if [ -z "$(cat ${FHEM_DIR}/fhem.cfg | grep -P "^define .+ telnet ${TELNETPORT}")" ]; then
  TELNETPORT="$(cat ${FHEM_DIR}/fhem.cfg | grep -P '^define telnetPort telnet ' | cut -d ' ' -f 4)"

  if [ -z "${TELNETPORT}"]; then
    echo "Telnet(undefined): FAILED;"
    exit 1
  fi
fi

Daher denke ich akutell.. Ja...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 23 Juli 2019, 17:19:10
TELNETPORT hab ich aber definiert als Umgebungsvariable vom Container. Mhh seltsam.


root@fhem-5f7d6dbbb6-pg2kd:/opt/fhem# echo ${TELNETPORT}
7075

*Edit ah ich es ist eingerückt -> nur wenn fhem.cfg dann...... noch die if mit TELNETPORT...

if [ -z "$(cat ${FHEM_DIR}/fhem.cfg | grep -P "^define .+ telnet ${TELNETPORT}")" ]; then
  TELNETPORT="$(cat ${FHEM_DIR}/fhem.cfg | grep -P '^define telnetPort telnet ' | cut -d ' ' -f 4)"

  if [ -z "${TELNETPORT}"]; then
    echo "Telnet(undefined): FAILED;"
    exit 1
  fi
fi


Dann hatte ich dich richtig verstanden -> geht nur mit fhem.cfg :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Migul47 am 23 Juli 2019, 19:18:23
top - 11:34:46 up 1 day, 26 min,  1 user,  load average: 0,70, 0,70, 0,67
Tasks: 405 total,   1 running, 287 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2,4 us,  2,5 sy,  0,0 ni, 93,7 id,  1,3 wa,  0,0 hi,  0,1 si,  0,0 st
KiB Mem : 16127352 total,  2155208 free,  4362748 used,  9609396 buff/cache
KiB Swap: 16777212 total, 16777212 free,        0 used. 11424324 avail Mem
Also bei mir sieht's so aus:
top - 19:10:08 up  4:40,  1 user,  load average: 0,78, 0,66, 0,58
Tasks: 159 gesamt,   1 laufend, 158 schlafend,   0 gestoppt,   0 Zombie
%CPU(s): 35,9 be, 16,3 sy,  0,0 ni, 47,5 un,  0,3 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Spch :  3931468 gesamt,  1612848 frei,   984328 belegt,  1334292 Puff/Cache
KiB Swap:   999420 gesamt,   999420 frei,        0 belegt.  2662216 verfü Spch

perl hat teilweise mehr als 50% CPU. Lt sysmon ca 80% idle. Scheint ok zu sein, aber er taktet kaum runter. Es ändert auch nichts, das ich mal die anderen Container beendet hatte. Teilweise ist das System langsamer als mein Pi3. Ist aber die selbe Config. Ich mach mal testweise nur FHEM direkt auf eine frische Inst. ohne Docker und den Rest. Mal schauen, was er dann macht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 23 Juli 2019, 19:55:05
Before du alles neu machst starte doch mal fhem mit der beispielconfig fhem.cfg.demo und schau mal wie es sich verhält. Dann siehst du ob das setup mit docker Schuld ist oder deine persönliche fhem.cfg.

Wahrscheinlich ist es am einfachsten die fhem.cfg umunennen und dann fhem.cfg.demo zu fhem.cfg umzubenennen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Migul47 am 24 Juli 2019, 06:17:06
Hi,

die Demo erzeugt ca. 3% CPU und er taktet kaum runter. Die Config, die momentan auf meinem Pi3 1,5% Last hat, hat in Docker ca 10%. Der Pi taktet aber nur selten hoch und ist momentan das Produktivsystem mit allen Events.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 24 Juli 2019, 09:12:24
Nur mit diesem Docker Container oder läuft nochwas parallel?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 Juli 2019, 11:53:15
root@fhem-bbc947bf4-g2pwf:/opt/fhem# /health-check.sh
cat: /opt/fhem/fhem.cfg: No such file or directory
cat: /opt/fhem/fhem.cfg: No such file or directory
Telnet(undefined): FAILED;

;-D ich bin gespannt ob ich es komplett falsch nutze oder was es ist.


Es war bisher nicht vorgesehen, dass man fhem.cfg komplett löscht, sondern sie weiterhin da bleibt. Im DEV Image habe ich jetzt mal versucht das zu berücksichtigen.


ich kann nur sagen, das mein System auch ausgelastet war (okay ein Raspi aber tortzdem) weil ich ein Monatslog anhatte, das relativ voll war durch viele eintrage. Dies wurde durch ein Prozess für Docker ausgelesen, und hat mein System sehr verlangsamt.Nachdem ich dies auf ein Wochenlog umgestellt hab, war mein System deutlich entspannter wieder.  Kam auch aus dem nix...


Bisher hatte ich davon abgesehen die FHEM Standardeinstellung für einen Monatslog hier zu verändern. Allerdings sehe ich die Notwendigkeit, da scheinbar nur wenige das Verständnis haben, dass man dies sinnvollerweise selbst ändern sollte (und für mich diese Einstellung so selbstverständlich ist, dass ich da gar nicht mehr drüber nachdenke). Ich habe den Spieß im DEV Image deshalb jetzt umgedreht und ein Daily Logfile als Standard eingebaut, welches man aber natürlich wie gehabt über die Docker Umgebungsvariable LOGFILE ändern kann. Das hat aber natürlich den Nachteil, dass eventuelle FileLog Devices nicht nachgezogen werden - das muss man selbst tun. Das war bisher zwar auch schon so, aber evtl. fällt es nun mehr ins Gewicht. Ich habe dafür zwar jetzt auch noch was eingebaut, aber es greift womöglich nicht immer (und bei configDB ohnehin nicht).


Ich habe gerade (glaube ich) festgestellt, dass /etc/sudoers.d/fhem-docker noch nach der Ausführung der post-init.sh mal bearbeitet wird ggf. sogar erstellt :-) Könntest du das noch davor schieben so das post-init.sh wirklich vor dem start von FHEM ist und alles andere erledigt?  ;-)


Nope. Warum nimmst du nicht (gefälligst  :P ) deine eigene Datei?  ;D
Dafür sind /etc/*.d/ Verzeichnisse da - man kann einfach beliebig viele Dateien parallel anlegen und pflegen und kommt sich nicht ins Gehege.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 Juli 2019, 14:14:01
Ich habe gerade eine neue Produktivversion v2.1.0 veröffentlicht, bei der die configDB Unterstützung verbessert sein sollte und auch der health-check robuster ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 24 Juli 2019, 14:19:10
Nope. Warum nimmst du nicht (gefälligst  :P ) deine eigene Datei?  ;D
Dafür sind /etc/*.d/ Verzeichnisse da - man kann einfach beliebig viele Dateien parallel anlegen und pflegen und kommt sich nicht ins Gehege.

 ;) ;D  Ich hatte es genau so gelöst mir einer eigenen Datei ;-)


Ich habe gerade eine neue Produktivversion v2.1.0 veröffentlicht, bei der die configDB Unterstützung verbessert sein sollte und auch der health-check robuster ist.

Geil ich klick mal eben redeploy  8)  Danke dir!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 24 Juli 2019, 14:31:14
configDB: logfile is readonly, it is set in the FHEM_GLOBALATTR environment
Ist das was, von deinen Änderungen? (Info ich nutze das default {latest} Dockerimage)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 Juli 2019, 14:44:42
Lies mal den aktualisierten Abschnitt in README.md (https://github.com/fhem/fhem-docker#tweak-container-settings-using-environment-variables):


Note that some essential global configuration that is affecting FHEM during startup is being enforced using FHEM_GLOBALATTR environment variable (nofork=0 and updateInBackground=1; logfile and pidfilename accordingly, based on environment variables LOGFILE and PIDFILE). These settings cannot be changed during runtime in FHEM and any setting that might be in your configDB configuration will be overwritten the next time you save your configuration. It might happen that FHEM will show you some warnings as part of the "message of the day" (motd attribute), stating that an attribute is read-only. That's okay, just clear that message and save your FHEM configuration at least once so the configuration is back in sync.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 24 Juli 2019, 15:07:08
Habe ich getan, aber das war jetzt für micht klar als ich MUSS etwas angeben.


The FHEM log file is mirrored to the Docker console output in order to give input for any Docker related tools. However, if the log file becomes too big, this will lead to some performance implications. For that reason, the default value of the global attribute logfile is different from the FHEM default configuration and set to a daily file (attr global logfile ./log/fhem-%Y-%m-%d.log).

Change FHEM logfile format: To set a different logfile path and format (default is ./log/fhem-%Y-%m-%d.log):

  -e LOGFILE=./log/fhem-%Y-%m-%d.log

Der Path ist für mich ja völlig in Ordnung und er hat da auch Schreibrechte.

*Edit ah ich vermute ... ich muss im LogFile noch das anpassen ;-D ?
DEF
./log/fhem-%Y-%m.log fakelog

*EDIT* So auf "fhem-%Y-%m-%d.log" geändert.  Lüppt.
Lesen hat Vorteile ... du schriebst es ja sogar.... -> dass eventuelle FileLog Devices nicht nachgezogen werden - das muss man selbst tun.
Ah und nun raffte ich auch was du meintest mit dem lesen ;-D Von wegen Meldung... und save :-D

Dauerte... aber wurde ja dann. Danke dir!  ;D ;D ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Migul47 am 24 Juli 2019, 23:04:08
Nur mit diesem Docker Container oder läuft nochwas parallel?
Nein, da läuft nur dieser eine Container, alle anderen wurden gelöscht damit auch ja nichts dazwischen funkt. Nichts anderes, ist auch nicht mit nem CUL bestückt. Es kommen also auch keine Events an. Ist quasi mit sich selbst beschäftigt. Hab es jetzt mal frisch ohne Docker aufgestetzt. 0,5% CPU und er taktet sauber rauf und runter. Ist momentan allerdings Ubuntu 16 lts und noch nicht produktiv.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 25 Juli 2019, 08:46:35
Dann fahr doch erstmal alles aufs aktuelle :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 25 Juli 2019, 09:23:03
Mh bei mir läuft der Healthcheck nun zwar generell ohne Fehler durch - er zeigt aber immer nur ein Ergebnis "Failed"

root@fhem-57c7686b5c-fvr2p:/opt/fhem# sudo /health-check.sh
Telnet(7072): FAILED

Mir scheint ich mache noch etwas falsch in der Anwendung.

Telnet ist bei mir 7072 - Rancher kann auch darauf einen Healthcheck machen - erfolgreich.
Ich versteh leider noch nicht ganz, was das script versucht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 25 Juli 2019, 12:05:38
Telnet muss ohne Passwort konfiguriert sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 25 Juli 2019, 13:55:05
Guter Hinweis - teste ich mal.

Vorschlag:

In der README.md erscheinen mir einige Themensprünge (mach ich auch sehr gern) - dadurch steht die Info mit keinem Passwort für Telnet unter Config DB und nicht unter Telnet oder Healthcheck :-)
Daher hatte ich es nicht so wirklich gefunden - geb ich zu.

Hätte es in der Sektion "Change FHEM local Telnet port" eingeordnet :-)
Oder ggf einfach nochmal nen Hinweis dort fallen lassen.

Logisch der, der immer alles ließt :-) bei dem ist das egal :-D
Aber gerade bei Konfigurationsmöglichkeiten such man ja dann doch ab und an speziell etwas.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 26 Juli 2019, 11:13:16
Telnet(7072): OK; WEB(8083): OK; WEB2(8086): OK; WEBphone(8084): OK; WEBtablet(8085): OK; DockerImageInfo:undefined;
Perfekt Danke :-)

Ich schau dann nochmmal nach dem DockerImageInfo :-D

Anscheinend wird, obwohl ich es hier im Thread anders gelesen habe DockerImageInfo nicht angelegt beim start des Containers.
So habe ich es zumindest verstanden, dass es so gedacht ist.

configDB: Please define DockerImageInfo first
Please define DockerImageInfo first
Please define DockerImageInfo first
Please define DockerImageInfo first
weiter Wiederholungen des selbigen...

Habe mir nun einfach mit "define DockerImageInfo DockerImageInfo" selber geholfen.

Unter Docker Image Info sind alle verfügbaren Capabilitiesgelistet - möchte der Container die gerne haben?
Ich frage, weil man unter Kubernetes mit Rancher diese selber zuteilen muss und sie nicht einfach gewährt werden wenn das Image es ansagt.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Migul47 am 27 Juli 2019, 01:01:15
Dann fahr doch erstmal alles aufs aktuelle :-)
So, alles aktuell. FHEM direkt ohne Container. Homebridge und mySQL im Container. Nur 2,5% CPU, Sauberer Takt. So hab ich das im Container nie gehabt. Denke, ich lass es jetzt so.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 27 Juli 2019, 01:28:14
Mahlzeit!

Habe gerade meine zwei Container auf das offizielle Image portiert. Läuft soweit. Allerdings gibt es Probleme mit dem health-check:
./health-check.sh
Telnet(7000): OK; WWW(8000): OK; WWW_FTUI(8001): OK; WWW_HOMEBRIDGE(8002): FAILED; DockerImageInfo:undefined;

Dass der health-check (korrekterweise) nicht auf WWW_HOMEBRIDGE zugreifen kann, führt nun dazu, dass der Container unhealthy ist. Ich sehe leider auf den ersten Blick keine Möglichkeit, dem health-check mitzuteilen, dass er einige (oder am besten alle) FHEMWEBs ignorieren soll, außer natürlich den Check zu patchen...

Patrick

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 Juli 2019, 12:38:51
In der README.md erscheinen mir einige Themensprünge (mach ich auch sehr gern) - dadurch steht die Info mit keinem Passwort für Telnet unter Config DB und nicht unter Telnet oder Healthcheck :-)
Daher hatte ich es nicht so wirklich gefunden - geb ich zu.

Hätte es in der Sektion "Change FHEM local Telnet port" eingeordnet :-)
Oder ggf einfach nochmal nen Hinweis dort fallen lassen.


Das ist eigentlichn kein Themensprung, denn es ist vor allem für configDB Nutzer relevant, bei denen _keinerlei_ automatische Anpassungen möglich sind.
Und ich hatte bisher verstanden, dass du sehr wohl configDB nutzt. Ich selbst nutze das absichtlich überhaupt gar nicht und habe auch keine Erfahrungen damit, weshalb ich nicht vorausahnen kann, welche Schritte jemand mit configDB tatsächlich alles tun muss. Das ist die investigative Zuarbeit der Community, die ich hier erwarte - und die du ja nun fleißig erbringst ;-)
Sei herzlich eingeladen deine Erfahrungen in einem FHEM Wiki Beitrag zu verewigen, genau dafür ist es da  8)


Andere Nutzer ohne configDB sollten(!) davon profitieren, dass Anpassungen an der fhem.cfg automatisch vorgenommen werden, sofern sie für den Betrieb des Containers notwendig sind. Dazu gehört auch das erste(!) Telnet Device in der fhem.cfg auszulesen und auch zu schauen, ob es ein allowed Device dazu gibt und dieses anzupassen (theoretisch, ob das immer funktioniert, dafür fehlen die Erfahrungswerte - und deshalb sind wir ja hier).


Anscheinend wird, obwohl ich es hier im Thread anders gelesen habe DockerImageInfo nicht angelegt beim start des Containers.
So habe ich es zumindest verstanden, dass es so gedacht ist.


Ist es auch - aber für configDB User ist das eben nicht möglich (wie oben schon erwähnt). Du musst also auch hier selbst Hand anlegen, deshalb hast du dich ja für configDB entschieden  ;D
Die da selbst zu helfen läuft also unter "works as designed".
Der Hinweis im Docker Start Protokoll weißt dich auch nochmals darauf hin, dass du alles selbst machen musst. Was genau das alles ist, das kann dir vorher keiner sagen, weil deine Konfiguration eben individuell ist und ich vor dem Start nicht in die Datenbank schauen kann (und will).


Unter Docker Image Info sind alle verfügbaren Capabilitiesgelistet - möchte der Container die gerne haben?
Ich frage, weil man unter Kubernetes mit Rancher diese selber zuteilen muss und sie nicht einfach gewährt werden wenn das Image es ansagt.


Wie der Name des Moduls schon sagt, ist es eine Info - also eine Info für dich und FHEM über den aktuellen Container Zustand und dessen Rechte, Betriebsart, etc.


Dass der health-check (korrekterweise) nicht auf WWW_HOMEBRIDGE zugreifen kann, führt nun dazu, dass der Container unhealthy ist. Ich sehe leider auf den ersten Blick keine Möglichkeit, dem health-check mitzuteilen, dass er einige (oder am besten alle) FHEMWEBs ignorieren soll, außer natürlich den Check zu patchen...


Für den Health Check ist es zwingend notwendig und auch sinnvoll, Zugriffe von lokal zuzulassen. Du musst dein allowed-Device für die FHEMWEB Instanz also so einstellen, dass man über localhost kein Passwort benötigt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: der-Lolo am 27 Juli 2019, 13:38:46
Hat eigentlich einer der Docker Nutzer das can not fork / can not allocate memory problem..?

Ich würde gerne umsteigen wenn ich dieses problem hierdurch gelöst bekomme.
Hardware wäre eine Syno DS 716+i - hat diese kombination schon jemand am laufen..?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 27 Juli 2019, 14:01:38
Hi!

Für den Health Check ist es zwingend notwendig und auch sinnvoll, Zugriffe von lokal zuzulassen. Du musst dein allowed-Device für die FHEMWEB Instanz also so einstellen, dass man über localhost kein Passwort benötigt.
Die Voraussetzungen des Skripts habe ich auch so verstanden. Meine Frage ging allerdings eher in die Richtung, wie man dieses Verhalten elegant bzw. robust anpassen kann.

Um ehrlich zu sein verstehe ich allerdings den informativen Mehrwert nicht, wenn drei FHEMWEB-Instanzen statt einer geprüft werden. Streng genommen sollte der Check über Telnet mehr als ausreichend sein, der tatsächlich sinnvoll ist.

Patrick
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 Juli 2019, 17:00:01
Naja, weil es streng genommen darum geht jeden Dienst/Port zu prüfen und nicht implizit von der Funktion des einen auf die des anderen zu schließen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 28 Juli 2019, 01:50:18
Hi!

Naja, weil es streng genommen darum geht jeden Dienst/Port zu prüfen und nicht implizit von der Funktion des einen auf die des anderen zu schließen.
Das Problem ist, dass Du nur die Dienste prüfst, die üblicherweise in jeder FHEM-Instanz laufen, nicht jedoch jene, die tatsächlich wichtig sind (Telnet als genereller Indikator kann da eine Ausnahme sein). Die wirklich wichtigen Funktionalitäten sind aber individuell und vermutlich über keinen noch so durchdachte generische Logik ermittelbar.

Um mal in Richtung einer Lösung zu navigieren: Das Docker-Image glänzt ja durch eine unerschöpfliche Konfigurierbarkeit. Eine Lösung über die Skript-Hooks wie pre-start.sh wäre möglich, aber unschön. Wie wäre es, wenn Du die Zeile:

FHEMWEB=$( cd /opt/fhem; perl fhem.pl ${TELNETPORT} "jsonlist2 TYPE=FHEMWEBOFF:FILTER=TEMPORARY!=1" 2>/dev/null )
durch
FHEMWEB=$( cd /opt/fhem; perl fhem.pl ${TELNETPORT} "jsonlist2 TYPE=FHEMWEBOFF:FILTER=TEMPORARY!=1:FILTER=noHealthCheck!=1" 2>/dev/null )
ersetzen würdest?

Dann könnte man über ein userattr noHealthCheck die Instanz von der Prüfung ausnehmen.

Patrick
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 28 Juli 2019, 11:40:32
Gute Idee, ich habe das mal testweise ins DEV Image aufgenommen.
In der README.me gibt es zwei neue Abschnitte zu diesen Themengebieten:


Role of the telnet device in FHEM (https://github.com/fhem/fhem-docker/tree/775f854c3781f9b14f5e000fee9e7b3588e1686b#role-of-the-telnet-device-in-fhem)
Docker health check control (https://github.com/fhem/fhem-docker/tree/775f854c3781f9b14f5e000fee9e7b3588e1686b#docker-health-check-control)

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 28 Juli 2019, 20:05:58
Hi!

Gute Idee, ich habe das mal testweise ins DEV Image aufgenommen.

Hi! Sieht gut aus. Allerdings ist in DockerImageInfo noch der Wurm drin:

2019.07.28 20:01:06.653 0: Missing $ on loop variable at ./FHEM/99_DockerImageInfo.pm line 14.

Patrick
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 29 Juli 2019, 18:47:59
Danke, hab ich noch korrigiert und jetzt baut ein neues Prod Image.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 29 Juli 2019, 21:15:10
Hi!

Danke, hab ich noch korrigiert und jetzt baut ein neues Prod Image.

Prima, DockerImageInfo läuft nun unter latest und dev. DockerHealthCheck funktioniert ebenfalls unter dev. Wenn ich es richtig gesehen habe, kümmert sich DockerImageInfo um das "Erlauben" des Attributs. Das klappt leider bei mir nicht. Über den Workaround mit einem userattr passt es aber.

Patrick
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 30 Juli 2019, 08:47:29
Da das User Attribut beim hochfahren eines Demo Containers wie gewünscht erscheint, kann ich das leider nicht nachvollziehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 30 Juli 2019, 18:17:23
Hat eigentlich einer der Docker Nutzer das can not fork / can not allocate memory problem..?

Ich würde gerne umsteigen wenn ich dieses problem hierdurch gelöst bekomme.
Hardware wäre eine Syno DS 716+i - hat diese kombination schon jemand am laufen..?
Ist denn der Docker ansonsten auf der Syno für Dich OK?
Da die Docker-Version immer noch auf 17.05 rumdümpelt, steht ja immer mehr in Frage, wie lange das noch gut geht.  :(
Es lassen sich z.B. viele neuere compose-Features nicht nutzen, da bei Level 2.2 Schluss ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 30 Juli 2019, 19:08:08
Hat eigentlich einer der Docker Nutzer das can not fork / can not allocate memory problem..?

Ich würde gerne umsteigen wenn ich dieses problem hierdurch gelöst bekomme.
Hardware wäre eine Syno DS 716+i - hat diese kombination schon jemand am laufen..?


Das Problem hab ich nur (und auch ohne Docker) wenn der RAM und der SWP voll war auf einem Pi3.


@Loredo :-) klar kein Ding ich helf gern mit wo ich kann.
Läuft alles perfekt bisher mit deinem Image! Ganz großes Kino! Sehr sehr hilfreich und easy2do.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 30 Juli 2019, 20:11:18
Hallo noch eine Frage, wie integriere ich eine Datenbank am besten?

Kann ich die in den Container von FHEM integrieren oder soll dazu ein neuer Container erzeugt werden?

ich möchte gerne paar daten loggen, und dazu gleich in DB wenn schon denn schon
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 30 Juli 2019, 20:52:04
Hi!

Da das User Attribut beim hochfahren eines Demo Containers wie gewünscht erscheint, kann ich das leider nicht nachvollziehen.

Mehr als den Container mehrfach neu erstellen kann ich auch nicht, sorry :/. Aber wie gesagt, mit dem userattr-workaround klappt es.

Patrick
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 01 August 2019, 13:20:58
Hallo noch eine Frage, wie integriere ich eine Datenbank am besten?

Kann ich die in den Container von FHEM integrieren oder soll dazu ein neuer Container erzeugt werden?

ich möchte gerne paar daten loggen, und dazu gleich in DB wenn schon denn schon


Das Konzept von Docker ist (überwiegend) für verschiedene Use Cases einzelne Container zu erstellen. Ein einzelner Use Case ist zumeist auch ein einzelner Dienst, in deinem Fall ein Dienst "Datenbank".
Da FHEM selbst keinen Start/Stop Mechanismus für eine Datenbank hat (und es da auch ein Henne/Ei Problem gäbe), brauchst du einen eigenen Container dafür.
Einzige Ausnahme ist, wenn du eine Datei basierte Datenbank verwendest (z.B. SQLite). Die eignet sich aber nur für die FHEM Konfiguration, ist aber ineffizient wenn es darum geht, Messdaten zu loggen.


Mehr als den Container mehrfach neu erstellen kann ich auch nicht, sorry :/. Aber wie gesagt, mit dem userattr-workaround klappt es.


Vielleicht reden wir auch aneinander vorbei.
Das Attribut "userattr" wird bei allen FHEMWEB Instanzen mit dem Inhalt "DockerHealthCheck:1,0" ergänzt. Man muss das eigentliche Attribut "DockerHealthCheck" danach selbst setzen und die Standardeinstellung ist eben 1 = "ja, ich will".
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 01 August 2019, 13:54:03
Vielleicht reden wir auch aneinander vorbei.
Das Attribut "userattr" wird bei allen FHEMWEB Instanzen mit dem Inhalt "DockerHealthCheck:1,0" ergänzt. Man muss das eigentliche Attribut "DockerHealthCheck" danach selbst setzen und die Standardeinstellung ist eben 1 = "ja, ich will".

Einfach aus Neugier:

Verstehe ich richtig, dass dann in allen FHEMWEB Instanzen ein attr DockerHealthCheck verfügbar sein sollte in der UI?

Bei mir wäre das nämlich auch nicht der Fall (evlt. configDB Sache - hatten ja schon Sachen die dadurch nicht automatisch passieren?) Eventuell fehlt ja noch was - habe mich aber nochmal durch alles durch gelesen - und die Schritte die automatisch passieren sollen kontrolliert - soweit sah alles gut aus nachdem ich "Docker Image Info" selbst definiert hatte.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 01 August 2019, 14:35:54
Hi!

Vielleicht reden wir auch aneinander vorbei.
Das Attribut "userattr" wird bei allen FHEMWEB Instanzen mit dem Inhalt "DockerHealthCheck:1,0" ergänzt. Man muss das eigentliche Attribut "DockerHealthCheck" danach selbst setzen und die Standardeinstellung ist eben 1 = "ja, ich will".

Ich glaube, wir meinen das Gleiche. Um sicher zu sein: Ich musste folgende Schritte durchführen:
Ich meine mich zu erinnern, dass der erste Teil bereits durch DockerImageInfo (ich habe eine aktive Instanz) erledigt sein sollte. War er aber bei mir aus unerfindlichem Grund nicht.

Patrick

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eisenhauer1987 am 02 August 2019, 10:11:26
Hallo,

ich bin heute scheinbar Opfer eines BUGs geworden:

2019.08.02 09:48:20.738 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP3_0)
2019.08.02 09:48:20.780 1: /dev/ttyUSB0 reappeared (TCM_ESP3_0)

Dies tritt bei nahezu jedem Empfangen und senden über das Device auf und verhindert ein vernünftiges Arbeiten mit dem Device. Nach einer weile hängt sich das gerät komplett auf. Das Problem tritt sowohl mit der Latest und dev auf, ich bin jetzt auf fhem-amd64_linux:5.9-s19885_v2.0.2 zurück und das problem tritt nicht mehr auf. Fhem ist aktuell und gleich sowohl bei dev Latest und der alten Version.

List des Gerätes:
Internals:
   BaseID     xxxxxxxx
   ChipID     04100B15
   DEF        ESP3 /dev/ttyUSB0@57600
   DeviceName /dev/ttyUSB0@57600
   FD         10
   FUUID      5d43ccef-f33f-899f-47dc-9d8c048380868b62
   FVERSION   00_TCM.pm:0.196070/2019-06-13
   LastID     FFF2AD7F
   MODEL      ESP3
   NAME       TCM_ESP3_0
   NOTIFYDEV  global
   NR         285
   NTFY_ORDER 45-TCM_ESP3_0
   PARTIAL   
   RESET_CAUSE unknown
   RSSI       -71
   SECURE_MODE standard
   STATE      opened
   TYPE       TCM
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1564732946.05349
           VALUE      CONNECTED
   READINGS:
     2019-08-02 10:01:07   baseID          BaseID: xxxxxxxx RemainingWriteCycles: FF
     2019-08-02 10:01:07   maturity        01
     2019-08-02 10:01:07   repeater        RepEnable: 00 RepLevel: 00
     2019-08-02 10:02:26   state           opened
     2019-08-02 10:01:07   version         APIVersion: 01030300 APPVersion: 01020700 ChipID: 04100B15 ChipVersion: 454F0103 Desc: TCM515
   helper:
     cdmSeq     1
     init_done  1
     telegramSentTimeLast 1564733045.17014
     awaitCmdResp:
       0
       0
       0
       0
       0
       0
       0
       0
       0
       0
       0
Attributes:
   group      Gateway.EnOcean
   icon       usb_stick
   room       Funktion - Gateway,Gerät - EnOcean,Raum - HWR
   sendInterval 0
   smartAckMailboxMax 0

Was kann ich liefern um den Problem näher zu kommen?


Edit: Nein problem ist auch jetzt wieder da..... ist scheinbar ein anderer Grund

2019.08.02 10:21:22.482 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP3_0)
2019.08.02 10:21:22.521 3: Setting TCM_ESP3_0 serial parameters to 57600,8,N,1
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 03 August 2019, 12:33:41
@Loredo ich glaube ich weiß nun was es mit dem Dbus auf sich hat - mir scheint das bluetoothhctl aktuell nicht funktioniert im Container:


Beim ausführen von bluetoothctl kommt ->
dbus[10149]: arguments to dbus_connection_get_object_path_data() were incorrect, assertion "connection != NULL" failed in file ../../../dbus/dbus-connection.c line 5905.
This is normally a bug in some application using the D-Bus library.

Habe mal im Container ein wenig getestet - mittels
  apt purge bluez
  apt install bluez

Startet bluetoothctl  schon mal. Da fehlte wohl etwas an Config Files (vermutlich)

Und auch der dbus Fehler im Logging beim FHEM start ist Gescichte:
Zitat
2019.08.03 12:48:28 0: Featurelevel: 5.9
2019.08.03 12:48:28 0: Server started with 175 defined entities (fhem.pl:19805/2019-07-09 perl:5.028001 os:linux user:fhem pid:15169)

Mal zur Erklärung ich habe einen USB BT Stick am Server für 3 EQ3 Thermostate :-) bisher meckern sie hier und sagten "no BT Device found" - mal sehen ob es nun schon weiter kommt.
Konnten wohl gar nichts machen mit nicht laufendem bluez

Leider sagt mein EQ3 Modul weiterhin zu den 3 Thermostaten die von dem BT Stack gesteuert werden sollen:
no BT Device found
*EDIT*  :) das purge und install brachte übrigens keinen großen Erfolg ^^ - oh wunder oh wunder  ;D
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mgt1111 am 13 August 2019, 16:29:45
Hallo

Ich hoffe das Ihr mir weiterhelfen könnt

Ich habe Fhem jetzt in einem Docker installiert,
jetzt meine Frage
ein Backup von einer anderen Fhem Installation muss ich in welchen Ordner kopieren damit ich es einspielen kann

Irgendwie sehe ich den Wald vor lauter Bäumen nicht :(
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 13 August 2019, 16:39:36
Hallo

Ich hoffe das Ihr mir weiterhelfen könnt

Ich habe Fhem jetzt in einem Docker installiert,
jetzt meine Frage
ein Backup von einer anderen Fhem Installation muss ich in welchen Ordner kopieren damit ich es einspielen kann

Irgendwie sehe ich den Wald vor lauter Bäumen nicht :(

Schau mal im 1. Post dieses Threads:

Wie benutze ich das Image?
Das FHEM Installationsverzeichnis /opt/fhem wird (sicherlich nicht überraschend für die, die Docker kennen) als eigenes Volume definiert. Man kann also seine bestehende FHEM Installation beim starten des Containers über "-v /pfad:/opt/fhem" mit angeben. Wenn man das nicht tut, dann wird die FHEM Installation nach Zerstörung des Containers gelöscht. Ist das beim Start angegebene FHEM Verzeichnis leer, so wird FHEM dort aus dem Docker Image heraus installiert. Mit dieser Vorgehensweise kann man also seine Grundinstallation starten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mgt1111 am 14 August 2019, 09:39:01
Schau mal im 1. Post dieses Threads:

Wie benutze ich das Image?
Das FHEM Installationsverzeichnis /opt/fhem wird (sicherlich nicht überraschend für die, die Docker kennen) als eigenes Volume definiert. Man kann also seine bestehende FHEM Installation beim starten des Containers über "-v /pfad:/opt/fhem" mit angeben. Wenn man das nicht tut, dann wird die FHEM Installation nach Zerstörung des Containers gelöscht. Ist das beim Start angegebene FHEM Verzeichnis leer, so wird FHEM dort aus dem Docker Image heraus installiert. Mit dieser Vorgehensweise kann man also seine Grundinstallation starten.


Ich besitze nur ein Backup von einer anderen FHEM Installation die nicht auf dem gleichen Raspberry läuft
Kann ich dieses Backup nachträglich einspielen


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 August 2019, 09:42:41
Container neu erstellen, vor dem ersten Start richtig so konfigurieren, dass die alte FHEM Installation nach /opt/fhem in den Container gemappt wird, fertig.

So schwer ist das wirklich nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mgt1111 am 14 August 2019, 09:51:00
Container neu erstellen, vor dem ersten Start richtig so konfigurieren, dass die alte FHEM Installation nach /opt/fhem in den Container gemappt wird, fertig.

So schwer ist das wirklich nicht.

Ich habe nur die .tar.gz Datei

(Sry blutiger Anfänger)


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 August 2019, 10:37:06
Wie man ein Archiv entpackt und Docker bedient kann ich hier nicht erklären, dafür gibt es andere Quellen im Internet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 14 August 2019, 12:26:46
Auf einem Windows-System kannst Du die .tar.gz Datei z.B. mit der Freeware 7-ZIP entpacken.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 14 August 2019, 12:32:41
Davon möchte ich abraten, da gehen alle Berechtigungen eines Linux Systemes verloren und er müsste sie neu setzen.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 14 August 2019, 14:32:58
Und er müsste dann X-Dateien übertragen .. besser die tar copieren und Unix-Standardtool verwenden .. Stichwort tar ..

https://wiki.ubuntuusers.de/tar/ (https://wiki.ubuntuusers.de/tar/)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: monosurr0und am 21 August 2019, 13:17:13
Hallo zusammen, kann mir jemand einen Tipp geben wie ich Bluetooth vom raspberrry zum fhem Container durchgereicht bekomme?! Steh da gerade ein wenig auf dem schlauch...Nutze OMV auf einem Pi4

Edit:habs mit einem BT Dongle gelöst. Intern schient wohl noch nicht zu funktionieren
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: monosurr0und am 21 August 2019, 18:27:41
was mache ich denn bei:

alexaFHEM.ProxyConnection      error; user homedir writable by group/other ('chmod 755 /opt/fhem' required)   2019-08-21 17:17:36
 :o
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 26 August 2019, 18:18:49
@monosurr0und PM mich falls das Problem noch besteht.

In dem Thread hier geht es um das FHEM Docker.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 06 September 2019, 09:57:23
Wobei das in der Fehlermeldung eigentlich doch praktisch drinsteht:
Zitat
('chmod 755 /opt/fhem' required)

Und noch etwas für alle, die Beiträge ohne Beachtung per copy&paste übernehmen, es hat sich anstelle eines "t" ein "f" eingeschlichen ...
chown -R fhem: /opt/fhem
# Hinweis: zwischen fhem und /opt ist ein :
cd /opt/fhem
find . -type f  -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod +x fhem.pl
Es heißt opt und nicht opf .... ;o)
Auch reicht es, wenn fhem.pl die Ausführrechte zusätzlich gegeben wird (+x), sauber gemacht wurde es doch schon vorher?

Allgemeiner Hinweis:
Ungetestet und damit könnten auch andere Fehler drin sein, also alle angaben nach besten Wissen und Gewissen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 September 2019, 10:05:09
Eigentlich gehört das überhaupt nicht hier her, denn die vermurksten Datei- und Ordnerberechtigungen würden auch ohne Docker angezählt werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 06 September 2019, 10:38:10
Das ist das Problem, wenn ein "alter thread" erweiter wird, anstelle in neuen zu eröffnen .. ist nicht das erste mai (und wird nicht das letzte mal sein)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 06 September 2019, 10:43:50
 ;) Wollt ihn nur nicht dumm sterben lassen - aber ja hätte ich auch per PM machen können.
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 September 2019, 10:57:59
Eigentlich gehört das überhaupt nicht hier her, denn die vermurksten Datei- und Ordnerberechtigungen würden auch ohne Docker angezählt werden.


Ich habe es trotzdem zum Anlass genommen im DEV DEV+PROD Image jetzt probeweise einmal chmod mit einzubauen (chown gab es vorher schon, da essentiell notwendig).
Dabei wird auch eine umask gesetzt, die Berechtigungen für Dateien sind dann 0640 und 0750 für Verzeichnisse (also etwas restriktiver als hier zuvor angenommen).
Über die Umgebungsvariablen FHEM_PERM_DIR und FHEM_PERM_FILE kann man die Datei/Ordnerrechte abändern; umask lässt sich über UMASK steuern. Einzelne Dateien und Verzeichnisse kann jeder dann über die post-Scripts auch wieder etwas weniger restriktiv setzen.


Ob alexa-fhem hier statisch nur auf 755 Berechtigung prüft oder eine noch strengere Berechtigung ebenfalls honoriert, weiß ich leider nicht. In dem Fall sollte alexa-fhem so angepasst werden, dass restriktivere Rechte nicht zu der besagten Fehlermeldung führen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 07 September 2019, 01:48:51
Frage: Hast du das zufällig im normalen Image auch schon angewandt?

Dann wäre das eventuell der Grund warum meinen Scripten das +X zum ausführen entzogen wurde :-)

Wenn ja - das müsste man etwas weniger restriktiv tun - oder abhängig von irgend etwas. 

Habe unter /opt/fhem/container-scripts das post init, welches ich dann in den Container mounte -> +x wurde entzogen und unter /opt/fhem/scripts viele Dinge wie mein presence script auch hier bei allen das +x futsch.

Alternativ sagst du nun... pfui was liegen die da leg die eines höher außerhalb von /opt/fhem ;-)
Das wäre natürlich auch machbar. Hab sie halt aus bequemlichkeit mit der FHEM installation direkt in den Container geholt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 07 September 2019, 08:20:10
Ich habe jetzt hinzugefügt, dass einige Dateien wieder mit einem Executable Bit versorgt werden:

https://github.com/fhem/fhem-docker/commit/ab1eff2bb93b00b0571f26125bcd924c0f4c3a68 (https://github.com/fhem/fhem-docker/commit/ab1eff2bb93b00b0571f26125bcd924c0f4c3a68)

Siehe auch neuer README (https://github.com/fhem/fhem-docker#directory-and-file-permissions) Abschnitt.

Die PRE-/POST- Scripts (https://github.com/fhem/fhem-docker#make-any-other-changes-during-container-start) wurden schon immer gesondert mit Execution Permissions versorgt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 11 September 2019, 11:02:22
Danke dir :-)
Läuft sonst alles wie geschmiert - absolut klasse!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 13 September 2019, 21:26:57
Mahlzeit!

Kann man eigentlich das GetImageInfo aus dem Healthcheck auf irgendeine saubere Art ausnehmen?

2019.09.13 21:22:34.749 1:  [Freezemon] freezemon: Long running Command detected { DockerImageInfo_GetImageInfo(); }:TELNET_Local - 0.960355 seconds
2019.09.13 21:22:34.750 1:  [Freezemon] freezemon: Long function call detected ReadFn:TELNET_Local_127.0.0.1_48110 - 0.960704 seconds
2019.09.13 21:22:56.533 1:  [Freezemon] freezemon: Long running Command detected { DockerImageInfo_GetImageInfo(); }:TELNET_Local - 1.080851 seconds
2019.09.13 21:22:56.534 1:  [Freezemon] freezemon: Long function call detected ReadFn:TELNET_Local_127.0.0.1_48226 - 1.081216 seconds
2019.09.13 21:23:18.203 1:  [Freezemon] freezemon: Long running Command detected { DockerImageInfo_GetImageInfo(); }:TELNET_Local - 0.921923 seconds
2019.09.13 21:23:18.203 1:  [Freezemon] freezemon: Long function call detected ReadFn:TELNET_Local_127.0.0.1_48348 - 0.922322 seconds
2019.09.13 21:23:39.858 1:  [Freezemon] freezemon: Long running Command detected { DockerImageInfo_GetImageInfo(); }:TELNET_Local - 0.950013 seconds
2019.09.13 21:23:39.858 1:  [Freezemon] freezemon: Long function call detected ReadFn:TELNET_Local_127.0.0.1_48494 - 0.950525 seconds

Patrick
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 14 September 2019, 08:37:30
Du löscht das DockerImageInfo Device, dann muss es auch nicht aktualisiert werden.
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 14 September 2019, 12:33:52
Werde ich testen. Ich wäre jetzt davon ausgegangen, dass das Fehlen dann "repariert" wird, so wie die Permissions, die gestern meine Backups außer Funktion gesetzt haben.

Patrick


Von unterwegs gesendet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 15 September 2019, 16:54:19
Hallo eine Frage, schaffe ich es irgendwie eine python package zu installieren. dass es auch bleibt?

Im moment installiert er mirs ins "usr/local/lib/python3.7/dist-packages"

was wäre da der korrekte weg?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 16 September 2019, 07:57:43
Kann es sein das es ab und zu mal zu Problemen auf ner Synology Diskstation kommt ? Seit ich das FHEM Docker noch mit laufen habe hängt sich meine Diskstation fast weg. Komme zwar drauf aber sonst nichts mehr möglich. Ist nicht ausgelastet ..
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 16 September 2019, 08:03:25
Was hast Du denn für eine Docker-Version drauf? Synology hat leider im August ein fehlerhaftes Update ausgeliefert, dass mit Docker-Compose Probleme macht. Dafür gibt es einen Fix, aber wohl noch nicht OTA.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 16 September 2019, 08:09:59
Ach gut zu wissen das wird der Grund wohl sein meine Version ist wohl: docker18.09.0-0505
Wie kann ich den Fix einspielen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 16 September 2019, 08:12:17
0506 ist aktuell. Musst Du derzeit vom Synology-Server Downloaden und manuell über die Oberfläche installieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 16 September 2019, 08:48:53
Danke habe ich eingespielt nu steht seit 30 Minuten Starten.. kommt aber nichts mehr hoch .. werd ich mal die STation Neustarten
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ChrisW am 16 September 2019, 09:54:21
Nach dem einspielen startet mein Docker leider nicht mehr .. es wird mal kurz fhem gestartet und eine Push gesendet aber wenn ich wieder schaue in der Diskstation steht dort "Angehalten"
Glaube ich habe zu viel im Autostart ?!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 16 September 2019, 09:58:39
Du wirst den Container möglicherweise neu aus dem Image erzeugen müssen, da der Docker-Fehler zum fehlerhaften Bau der Container führen konnte.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 16 September 2019, 13:16:18
Hello,

ich habe gestern ein Update des Images gemacht. Bis jetzt wurden die SSH-Keys bei jedem Update unverändert übernommen bzw. beibehalten. Beim gestrigen Update wurden aber neue Keys erzeugt. Gibt es eine Möglichkeit, die bestehenden Keys immer zu behalten?

Ansonsten muss ich die Keys sichern und im Update-Script wieder zurückspielen lassen.

Die ssh-Keys habe ich zum Teil ausge-x-t.
Internals:
   CHANGED   
   FUUID      5c575e13-f33f-4fe4-bc87-8f277fae9f8d253c
   NAME       DockerImageInfo
   NR         15
   STATE      ok
   TYPE       DockerImageInfo
   READINGS:
     2019-03-17 10:28:40   container.cap.e audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot
     2019-03-17 10:28:40   container.cap.i audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot
     2019-03-17 10:28:40   container.cap.p audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot
     2019-09-15 21:21:43   container.hostname 230dc814782a
     2019-04-21 14:57:34   container.hostnetwork 0
     2019-09-15 21:21:43   container.id    230dc814782a456f9a67cb248354123d631f3aada55acca91635f48ea0ab22c6
     2019-03-17 10:28:40   container.privileged 0
     2019-03-17 10:28:40   id.gid          6061
     2019-03-17 10:28:40   id.gname        fhem
     2019-03-17 10:28:40   id.groups       [ "fhem": 6061, "tty": 5, "mail": 8, "dialout": 20, "audio": 29, "video": 44, "bluetooth": 6001, "gpio": 6002, "i2c": 6003 ]
     2019-03-17 10:28:40   id.uid          6061
     2019-03-17 10:28:40   id.uname        fhem
     2019-09-15 21:21:43   image.created   2019-09-13T19:23:39+00:00
     2019-07-08 21:58:40   image.description A basic Docker image for FHEM house automation system, based on Debian Buster.
     2019-09-07 22:13:03   image.documentation https://github.com/fhem/fhem-docker/blob/ae19137eaa2af2fcfe97997d16c1c761d4fa0cd6/README.md
     2019-03-17 10:28:40   image.licenses  MIT
     2019-09-07 22:13:03   image.revision  ae19137eaa2af2fcfe97997d16c1c761d4fa0cd6
     2019-03-17 10:28:40   image.source    https://github.com/fhem/fhem-docker/
     2019-03-24 11:36:11   image.title     fhem-amd64_linux
     2019-03-24 11:36:11   image.url       https://hub.docker.com/r/fhem/fhem-amd64_linux
     2019-07-27 04:02:58   image.vendor    Julian Pawlowski
     2019-09-15 21:21:43   image.version   5.9-s20156_v2.2.1-3-gae19137
     2019-09-15 21:21:43   ssh-id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILmS92VsRIHJ1Nxxxxxxxxxxxxxxxxxxxxx fhem@fhem-docker
     2019-09-15 21:21:43   ssh-id_rsa.pub  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC03vDAKHZQya96xxxxxxxxxxxxxxxxxxxxxxxx== fhem@fhem-docker
     2019-04-18 21:50:26   sudoers         [ "# Auto-generated during container start", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm install *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm uninstall *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm update *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/local/bin/cpanm *", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -q update", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -s -q -V upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y install *", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y -q -V dist-upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y -q -V upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/nmap" ]
Attributes:
   alias      Docker Image Info
   devStateIcon ok:security@green .*:message_attention@red
   group      System
   icon       it_server
   room       System
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 16 September 2019, 18:22:12
hat sich erledigt ... lesen bildet


=====


Kann es sein, dass mit dem aktuellen Dockerfile gar kein Zugriff mehr auf die FHEM-Daten von außerhalb möglich ist?

Wenn ich sonst von meinem Host aus versuche auf den FHEM-Ordner zugreifen, dann kommt

pi@dockerhost:/opt $ cd fhem/
-bash: cd: fhem/: Keine Berechtigung

Ich musste gestern das Dockerfile neu aufbauen, vorher ging das.

pi@dockerhost:/opt $ ls -al
insgesamt 24
drwxr-xr-x  6 root             root 4096 Sep 16 17:46 .
drwxr-xr-x 21 root             root 4096 Sep 16 15:41 ..
drwx--x--x  4 root             root 4096 Sep 16 15:45 containerd
drwxr-x--- 15             6061 6061 4096 Sep 16 17:57 fhem
drwxr-xr-x  3 systemd-timesync root 4096 Sep 16 17:46 SonosSpeak
drwxr-xr-x  6 root             root 4096 Jul 10 02:08 vc
pi@dockerhost:/opt $

Würde eigentlich gerne wieder auf das Verzeichnis zugreifen, z.B. um den aktuellen Stand nach git zu pushen.

Ist das Absicht oder kann ich den Besitzer des Ordners wieder auf root oder pi zurücksetzen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: PatrickR am 16 September 2019, 21:08:52
Hi!

Du löscht das DockerImageInfo Device, dann muss es auch nicht aktualisiert werden.

Habe das Device gelöscht, was aber leider nicht das gewünschte Ergebnis bringt:

Zitat
So 15.09.2019 08:00:28  freezemon s:08:00:27 e:08:00:28 f:1.947 d:cmd-{ DockerImageInfo_GetImageInfo(); }(TELNET_Local) fn-ReadFn(TELNET_Local_127.0.0.1_59196)

/Edit:
Es kommt leider noch dicker:
2019.09.16 21:10:44.565 1: readingsUpdate(,ssh-id_ed25519.pub,ssh-ed25519 [...] fhem@fhem-docker
) missed to call readingsBeginUpdate first.

Patrick
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 17 September 2019, 16:55:29
Container Neustart nicht vergessen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 17 September 2019, 17:51:46
Gibt es eine Möglichkeit, die bestehenden Keys immer zu behalten?


Das werden sie bereits:
https://github.com/fhem/fhem-docker/blob/cc196036a159e9116b025216d3c4e20949ed1a29/src/entry.sh#L382 (https://github.com/fhem/fhem-docker/blob/cc196036a159e9116b025216d3c4e20949ed1a29/src/entry.sh#L382)
https://github.com/fhem/fhem-docker/blob/cc196036a159e9116b025216d3c4e20949ed1a29/src/entry.sh#L391 (https://github.com/fhem/fhem-docker/blob/cc196036a159e9116b025216d3c4e20949ed1a29/src/entry.sh#L391)


Dort wird nur ein Schlüssel erzeugt, wenn die Datei noch nicht existiert oder keinen Inhalt hat.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 17 September 2019, 18:06:51
Dort wird nur ein Schlüssel erzeugt, wenn die Datei noch nicht existiert oder keinen Inhalt hat.

Bis jetzt war es auch so, beim letzen Update verschwanden sie ... werde es beobachten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 24 September 2019, 20:30:17
Guten Abend,

ich muss mal ne blöde Frage stellen und hoffe auf Hilfe:

Ich habe fhem als Dockerimage auf einem Synology NAS laufen und es funktioniert bestens. Jetzt habe ich es auch geschafft einen CUL-Stick (am USB des NAS) in den Container "durchzureichen" und kann senden und empfangen - tiptop!!!
Geschafft habe ich das, in dem ich - in der grafischen Oberfläche des NAS  :-X - den USB-Stick (CUL) wie in der Anlage zu sehen als Enviromentvariable hinzugefügt habe.
Jetzt habe ich einen weiteren CUL (andere Frequenz) am NAS und er hängt am "ttyUSB0".....

Wie genau füge ich (in der grafischen Oberfläche) ein zweites Device hinzu? Ich hab mich schon totgesucht, aber nix gefunden... Leerzeichen? Komma dazwischen? 2. Eintrag?

Kann mir mal jemand einen Schubs in die richtige Richtung geben?

Danke und einen schönen Abend
wolf
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 September 2019, 20:59:24
Die Umgebungsvariable DEVICE wird nicht vom FHEM Docker Image verarbeitet. Ich vermute das ist eine Spezialität von Synology. Dazu kann ich allerdings nichts sagen, weil ich kein NAS benutze.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 24 September 2019, 21:07:59
Danke für die Antwort,

aber erst als ich diese per Hand hinzugefügt habe, läuft der eine der beiden CUL's in der Dockerumgebung. Also mein Gefühl sagt, dass das irgendwas damit zu tun hat.

Diese habe ich in der graphischen Oberfläche des NAS hinzugefügt und dann lief er.... Die Frage ist, wie bringe ich 2 CUL's in diese Variable unter?

wolf


Gesendet von iPhone mit Tapatalk Pro
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 September 2019, 21:09:13
Das fragst du besser jemanden, der sich mit Synology auskennt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 24 September 2019, 21:13:34
wahrscheinlich hast Du recht. Ich dachte es ist "fhem-docker-spezifisch" - ich geh mal auf die Suche und berichte.

Danke
wolf
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wolfram am 24 September 2019, 21:33:51
Ich hab's herausgefunden:

In der graphischen Oberfläche des Nas unter den Umgebungsvariablen den Eintrag "DEVICES" ergänzen und die einzelnen (USB)Devices getrennt mit ":" eintragen und in fhem standardmäßig anlegen.

Danke für den Schubs.

wolf
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 24 September 2019, 21:37:24
Siehe mein Beitrag vom 16.9.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: stera am 24 September 2019, 23:08:25
Hallo zusammen,

auch ich benutze Docker mit einer Synology Diskstation. Funktioniert tadellos, auch mit mehreren Instanzen.
Auf einer normal Debian Installation kann man natürlich mehr Rechte vergeben und würde gerne per Script oder FhemBefehl({ system("sudo rm -R /mnt/Diskstation/test.txt &") }) auf einem gemountet Ordner (/mnt/Diskstation) etwas löschen.
Gibt es dort irgendeine Möglichkeit in der Dockerumgebung?

Es bringt auch leider nichts im Terminal den Ordner mehr Rechte zu vergeben (chmod 666 / 777, chown -R fhem:dialout /mnt/Diskstation) . Es liegt wohl daran, das der User FHEM nicht die Rechte dafür hat.
Wie kann ich das denn im Container anpassen ohne nano Editor. Denke da muss die Zeile in sudoers rein oder?


Fhem bzw. das System meldet aktuell:
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: patlabor am 03 Oktober 2019, 18:38:33
Hallo zusammen,

ich fürchte ich habe mir meine Fhem installation heute komplett zerschossen.
Ich wollte eigentlich "nur" von MQTT2_SERVER auf MQTT2_CLIENT mit Mosquitto umsteigen.
Beides läuft komplett in Docker und war grundsätzlich kein Problem.
Alle Geräte ohne nennenswerte Probleme umgezogen, bis auf einen ESP32 Milight Hub. Der lies sich zwar auch ohne weiteres anlegen, und auch steuern, sobald aber Mosquitto ins Spiel kommt, hat die Lampe nur noch wie verrückt geblinkt.
Dabei habe ich dann angefangen (mehr oder wenig planlos und auf gut Glück) MQTT Geräte anzulegen und zu löschen.
Hat aber leider nichts gebracht.
Als letzten Ausweg habe ich einmal die Komplette Docker Installation mit mosquitto, zigbee2mqtt, und fhem selbst in einem docker-compose file, mit --force-recreate neu gestartet.

Und seit dem geht leider gar nichts mehr. Das Fhem Webui ist nicht mehr erreichbar, und in den Logs taucht folgendes auf:

fhemgen       | 2019.10.03 18:22:11.691 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_IDENTIFIER_REJECTED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.692 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.692 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_EXACTLY_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.692 1: PERL WARNING: Constant subroutine MQTT::MQTT_SUBSCRIBE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.693 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_UNACCEPTABLE_PROTOCOL_VERSION redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.693 1: PERL WARNING: Constant subroutine MQTT::MQTT_PINGRESP redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.693 1: PERL WARNING: Constant subroutine MQTT::MQTT_UNSUBSCRIBE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.694 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_ACCEPTED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.694 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBCOMP redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.694 1: PERL WARNING: Constant subroutine MQTT::MQTT_SUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.695 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_BAD_USER_NAME_OR_PASSWORD redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.695 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBLISH redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.696 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.696 1: PERL WARNING: Constant subroutine MQTT::MQTT_UNSUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.696 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_AT_LEAST_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.697 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_AT_MOST_ONCE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.697 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_NOT_AUTHORIZED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.697 1: PERL WARNING: Constant subroutine MQTT::MQTT_DISCONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.698 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBREC redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.698 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.698 1: PERL WARNING: Constant subroutine MQTT::MQTT_PINGREQ redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.699 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBREL redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.699 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_SERVER_UNAVAILABLE redefined at FHEM/lib/Net/MQTT/Constants.pm line 44, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.702 1: PERL WARNING: Subroutine Define redefined at ./FHEM/00_MQTT.pm line 106, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.703 1: PERL WARNING: Subroutine Undef redefined at ./FHEM/00_MQTT.pm line 135, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.704 1: PERL WARNING: Subroutine Delete redefined at ./FHEM/00_MQTT.pm line 141, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.705 1: PERL WARNING: Subroutine Shutdown redefined at ./FHEM/00_MQTT.pm line 148, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.706 1: PERL WARNING: Subroutine onConnect redefined at ./FHEM/00_MQTT.pm line 156, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.707 1: PERL WARNING: Subroutine onDisconnect redefined at ./FHEM/00_MQTT.pm line 163, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.707 1: PERL WARNING: Subroutine onTimeout redefined at ./FHEM/00_MQTT.pm line 170, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.708 1: PERL WARNING: Subroutine isConnected redefined at ./FHEM/00_MQTT.pm line 179, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.709 1: PERL WARNING: Subroutine process_event redefined at ./FHEM/00_MQTT.pm line 186, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.712 1: PERL WARNING: Subroutine Set redefined at ./FHEM/00_MQTT.pm line 207, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.716 1: PERL WARNING: Subroutine parseParams redefined at ./FHEM/00_MQTT.pm line 254, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.718 1: PERL WARNING: Subroutine parsePublishCmdStr redefined at ./FHEM/00_MQTT.pm line 341, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.720 1: PERL WARNING: Subroutine parsePublishCmd redefined at ./FHEM/00_MQTT.pm line 350, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.723 1: PERL WARNING: Subroutine Notify redefined at ./FHEM/00_MQTT.pm line 392, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.724 1: PERL WARNING: Subroutine Attr redefined at ./FHEM/00_MQTT.pm line 400, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.726 1: PERL WARNING: Subroutine Start redefined at ./FHEM/00_MQTT.pm line 433, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.727 1: PERL WARNING: Subroutine Stop redefined at ./FHEM/00_MQTT.pm line 450, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.728 1: PERL WARNING: Subroutine Ready redefined at ./FHEM/00_MQTT.pm line 464, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.729 1: PERL WARNING: Subroutine Rename redefined at ./FHEM/00_MQTT.pm line 469, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.730 1: PERL WARNING: Subroutine Init redefined at ./FHEM/00_MQTT.pm line 479, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.731 1: PERL WARNING: Subroutine Timer redefined at ./FHEM/00_MQTT.pm line 488, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.741 1: PERL WARNING: Subroutine Read redefined at ./FHEM/00_MQTT.pm line 501, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.743 1: PERL WARNING: Subroutine send_connect redefined at ./FHEM/00_MQTT.pm line 647, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.745 1: PERL WARNING: Subroutine send_publish redefined at ./FHEM/00_MQTT.pm line 660, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.746 1: PERL WARNING: Subroutine send_subscribe redefined at ./FHEM/00_MQTT.pm line 672, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.747 1: PERL WARNING: Subroutine send_unsubscribe redefined at ./FHEM/00_MQTT.pm line 679, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.747 1: PERL WARNING: Subroutine send_ping redefined at ./FHEM/00_MQTT.pm line 686, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.748 1: PERL WARNING: Subroutine send_disconnect redefined at ./FHEM/00_MQTT.pm line 690, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.749 1: PERL WARNING: Subroutine send_message redefined at ./FHEM/00_MQTT.pm line 697, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.751 1: PERL WARNING: Subroutine topic_to_regexp redefined at ./FHEM/00_MQTT.pm line 712, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.753 1: PERL WARNING: Subroutine client_subscribe_topic redefined at ./FHEM/00_MQTT.pm line 723, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.755 1: PERL WARNING: Subroutine client_unsubscribe_topic redefined at ./FHEM/00_MQTT.pm line 742, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.756 1: PERL WARNING: Subroutine Client_Define redefined at ./FHEM/00_MQTT.pm line 759, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.757 1: PERL WARNING: Subroutine Client_Undefine redefined at ./FHEM/00_MQTT.pm line 778, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.763 1: PERL WARNING: Subroutine client_attr redefined at ./FHEM/00_MQTT.pm line 783, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.765 1: PERL WARNING: Subroutine notify_client_connected redefined at ./FHEM/00_MQTT.pm line 897, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.765 1: PERL WARNING: Subroutine notify_client_disconnected redefined at ./FHEM/00_MQTT.pm line 902, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.766 1: PERL WARNING: Subroutine notify_client_connection_timeout redefined at ./FHEM/00_MQTT.pm line 907, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.768 1: PERL WARNING: Subroutine client_start redefined at ./FHEM/00_MQTT.pm line 912, <$fh> line 1716.
fhemgen       | 2019.10.03 18:22:11.769 1: PERL WARNING: Subroutine client_stop redefined at ./FHEM/00_MQTT.pm line 944, <$fh> line 1716.
fhemgen       | Undefined subroutine &MQTT::DEVICE::client_attr called at ./FHEM/10_MQTT_DEVICE.pm line 232, <$fh> line 1718.

Habe mir per docker pull mal das neuste Image gezogen, aber das hat leider keine Änderung bewirkt.
Wenn ich das richtig verstehe, ist wohl irgendwas mit dem MQTT.pm Modul nicht in Ordnung. Das scheint aber etwas anderes als das von mir benutzte MQTT2 zu sein.
Ich hatte Versuchsweise auch mal mosquitto über mqtt(1) eingebunden, das fand ich allerdings nicht so elegant und bin dann auf MQTT2_CLIENT umgestiegen. Ich habe meine fhem.cfg auch mal durchsucht, ich habe keine verweis auf die alte MQTT instanz gefunden.

Jemand eine Idee wie ich fhem jetzt wieder ins Laufen bekomme?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 03 Oktober 2019, 19:40:24
Da kann dir in diesem Thread niemand helfen, das Docker Image fungiert nur als Laufzeitumgebung und hat mit den FHEM eigenen Dateien nichts zu tun.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 03 Oktober 2019, 23:10:51
Ich hoffe mal für Dich, Du hast einen Backup Deiner FHEM-Installation außerhalb des Docker-Images. Docker ersetzt keinen Backup der config-Dateien oder auch der Daten in den Docker-Volumes.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 07 Oktober 2019, 16:45:51
 ;) Huhu

Was macht man eigentlich, wenn das Icon der "Docker Image Info" dauerhaft orange bleibt?
Einen Reboot hab ich schon gemacht - aber es bleibt einfach so....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Karflyer am 11 Oktober 2019, 14:18:37
Ich habe enocean-Sensoren/Aktoren die verschlüsselt kommunizieren. Hierzu werden die beiden CPAN-Module Crypt::Rijndael und Crypt::Random benötigt. Diese beiden Module habe ich in der docker-compose.yml als Environment-Variable eingetragen:
  environment:
            APT_PKGS: "gcalcli python-pip python-gflags python-vobject python-parsedatetime"
            [b]CPAN_PKGS: "Crypt::Rijndael Crypt::Random"[/b]
Dennoch fehlen nach einem Update des Containers (oder Neustart) diese beiden Module im Container. Fhem meldet im Log auch richtigerweise EnOcean Cryptographic functions are not available.Nach einem manuellen nachinstallieren der beiden Module im Container funktioniert hiernach der verschlüsselte EnOcean-Funk.
@Loredo Kannst du diese beiden Module in das Standard-Image übernehmen? Oder wie müssten die Environment-Variablen lauten, damit das beim erstellen des Containers automatisch passiert?

Grüße
Stefan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 11 Oktober 2019, 15:34:22
Moin

soweit ich das jetzt verstanden hätte auf https://github.com/fhem/fhem-docker :

Zitat
Perl CPAN modules:

-e CPAN_PKGS="App::Name1 App::Name2"

Somit

-e CPAN_PKGS="Crypt::Rijndael Crypt::Random"
Dann haste die immer mit dabei und sie werden beim starten des Containers mit installiert.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 11 Oktober 2019, 15:55:19
Besser libcrypt-rijndael-perl per apt nutzen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Karflyer am 11 Oktober 2019, 18:29:00
Zitat
Moin

soweit ich das jetzt verstanden hätte auf https://github.com/fhem/fhem-docker :

Zitat

    Perl CPAN modules:

    -e CPAN_PKGS="App::Name1 App::Name2"


Somit

Code: [Auswählen]

-e CPAN_PKGS="Crypt::Rijndael Crypt::Random"


Dann haste die immer mit dabei und sie werden beim starten des Containers mit installiert.

Diese Variante funktioniert nur in Verbindung mit dem docker run-command. Ich benutze docker-compose und hier werden die Environment-Variablen so deklariert wie ich es geschrieben habe. Andere Variablen die ich ebenso deklariert habe, führen zum gewünschten Erfolg. Nur CPAN_PKGS: "Crypt::Rijndael Crypt::Random" scheint keine Wirkung zu haben.

Zitat
Besser libcrypt-rijndael-perl per apt nutzen.
Damit habe ich es zuerst probiert. Zeigt leider keinen Erfolg bei verschlüsseltem EnOcean-Funk.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 12 Oktober 2019, 23:45:28
Damit habe ich es zuerst probiert. Zeigt leider keinen Erfolg bei verschlüsseltem EnOcean-Funk.
Das ist verwunderlich. Allerdings enthält Buster die Version 1.13 und CPAN die 1.14.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 13 Oktober 2019, 00:56:07
Puh ... da kann ich auch nix zu sagen weiter sry.  :-X
Habe das alles in einem Cluster mit Rancher Kubernetes Engine da kann ich solche Eigenschaften einfach setzen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Karflyer am 14 Oktober 2019, 09:08:37
Noch einmal zu dem Thema Enocean-Verschlüsselt

Aktuell habe ich in der der docker-compose.yml folgenden Eintrag:

environment:
    CPAN_PKGS: "Crypt::Rijndael Crypt::Random"

Bei dem Start des Containers erscheinen unter anderem folgende Zeilen im Log:
Preparing initial start:
1. Adding custom APT packages to container ...
2. Adding custom Perl modules to container ...
3. Updating existing FHEM installation in /opt/fhem

Hiernach sieht es so aussehen, dass die oben genannte Variable  CPAN_PKGS nicht berücksichtigt wird (im Log ist nicht die Rede davon, dass CPAN-Packages zum Container hinzugefügt werden).

Ich habe nun die beiden CPAN-Packages in die entry.sh gepackt. So funktioniert es jetzt. Trotzdem ist es unbefriedigend nicht zu wissen warum das setzen der Environment-Variable in der docker-compose.yml nicht funktioniert.

@Loredo Noch einmal der Wunsch von mir, die beiden CPAN-Module gleich in das Image zu integrieren.

Gruß
Stefan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 14 Oktober 2019, 09:18:12
Also wenn ich ins Dockerfile schaue, sehe ich dort folgende Anweisung


libcrypt-*-perl

D.h. ich vermute, die Pakete sind über apt bereits vorinstalliert. Mit Deiner cpan-Geschichte produzierst Du damit evtl. Einen Versionskonflikt
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 14 Oktober 2019, 09:57:30
@Karflyer: Probier doch bitte mal an einem neuen Image, ob auch die cpan-Installation von Crypt::Random den gewünschten Effekt gibt. Es gibt unter Debian zwar libcrypt-random-seed-perl und libcrypt-random-source-perl, aber anscheinend kein identisches Paket.
Crypt::Rijndael ist definitiv abgedeckt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Karflyer am 15 Oktober 2019, 20:11:07
Zitat
@Karflyer: Probier doch bitte mal an einem neuen Image, ob auch die cpan-Installation von Crypt::Random den gewünschten Effekt gibt. Es gibt unter Debian zwar libcrypt-random-seed-perl und libcrypt-random-source-perl, aber anscheinend kein identisches Paket.
Crypt::Rijndael ist definitiv abgedeckt.

Du hast Recht. Es genügt in der Tat das Modul Crypt::Random. Jetzt funktioniert auch der folgende Eintrag in der docker-compose.yml um das Modul zu laden:
environment:
     CPAN_PKGS: "Crypt::Random"
Vielen Dank für die Unterstützung! Es wäre natürlich schön, wenn das Modul Crypt::Random in das Basis-Image aufgenommen würde. Der Start des Containers dauert so recht lang, weil die Installation des Moduls seine Zeit benötigt.

Grüße
Stefan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 18 Oktober 2019, 11:49:15
Crypt::Random und seine Abhängigkeiten brauchen leider zu lange, als dass sie im Build direkt installiert werden können. Die Build-Zeit ist bereits auf Kante (50 Minuten Maximum).
Die Lösung über die Umgebungsvariable CPAN_PKGS ist deshalb der richtige Weg. Die Installation findet auch nur beim ersten Start eines frischen Containers statt, nicht bei weiteren Starts. Einen Container ständig neu frisch zu erstellen macht wenig Sinn, man kann ihn problemlos mit den vorhandenen FHEM Modulen AptToDate, npmjs und dem Installer aktuell halten (das Ergebnis ist exakt das selbe).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 02 November 2019, 15:12:27

Inzwischen tendiere ich dazu die Empfehlung durchaus zu geben, dass der Container im Netzwerk Modus "host" betrieben wird.

[...]

Diejenigen, denen es neben der Funktion auch auf das i-Tüpfelchen an Sicherheit ankommt, die haben in der Regel ohnehin die Möglichkeit einen virtuellen Server nur für Docker abzustellen. Sprich, wenn man Docker in einem virtuellen Server laufen lässt statt bare metal, dann kann man dort IMHO auch getrost den FHEM Container direkt im selben LAN betreiben. Wer es übertreiben will, muss ja nicht auf dem selben virtuellen Server auch andere Container betreiben... somit bekommt man das, was man von einem Docker Container erwartet: Eine fix und fertige Laufzeitumgebung für FHEM, die einfach zu replizieren ist.

Das möchte ich auch so betreiben. Dazu will ich einen weiteren Container mit Mysql/MariaDB für configDB und LogDb betreiben. Da fhem im host-Modus läuft, muss aus meiner Sicht die Datenbank über einen host-Port (z.B. 3307) freigegeben werden, damit der DB Container nicht auch im host-Modus laufen muss, richtig?

Mein (testweise) docker-compose.yml sieht zurzeit wie folgt aus:

version: '3'

services:
  fhem:
    image: fhem/fhem
    restart: unless-stopped
    network_mode: host
    volumes:
        - fhem_log:/opt/fhem/log
        - ./configDB.conf:/opt/fhem/configDB.conf
    devices:
        # CUL 433
        - "/dev/serial/by-id/usb-busware.de_CUL433-if00:/dev/CUL433"
        # CUL 868
        - "/dev/serial/by-id/usb-busware.de_CUL868-if00:/dev/CUL868"
        # jeeLink
        - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL014KEQ-if00-port0:/dev/jeeLink"
    environment:
        - FHEM_UID=999
        - FHEM_GID=20
        - TZ=Europe/Berlin             
        - CONFIGTYPE=configDB
        - APT_PKGS="libcryptx-perl"
    depends_on:
        - database

  database:
    image: mariadb
    restart: unless-stopped
    ports:
        - 3307:3306
    volumes:
        - database_files:/var/lib/mysql
    env_file: ./database.env
    environment:
        - MYSQL_ROOT_PASSWORD=root

volumes:
  fhem_log:
  database_files:

Dazu passend die .configDB.conf

%dbconfig= (
   connection => "mysql:host=localhost;database=fhem;port=3307",
   user => "fhem",
   password => "fhem",
);

So startet allerdings der fhem container nicht, da er den "localhost" direkt über das lokale "/var/run/mysqld/mysqld.sock" ansprechen möchte, was natürlich schief geht. Workaround wäre, den hostname des host-Systems einzutragen. Ist das korrekt so oder gibt es da einen eleganteren Weg?

Leider wird der host-Modus kaum thematisiert, auch nicht auf Github (weder README noch docker-compose.yml).

EDIT: Auch mein DbLog funktioniert nicht korrekt. Obwohl ich auf die gleiche configDB.conf verweise, wird einfach irgendeine (alte) Standard-Konfiguration geladen, die auf Port 3306 verweist .. Ich kann sogar von fhem aus die conf-Datei ausgeben mit dem korrekten Port 3307, aber bei reopen wird das nicht berücksichtigt.
EDIT2: Antwort gefunden, configDB speichert natürlich Konfigurationsdateien (wie configDB.conf) für andere Module in der Datenbank, das muss man natürlich beim Umzug beachten.

ManOki
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 02 November 2019, 22:08:39
Auch ich versuche gerade von einer Installation auf einem bananaPi mit logDB und seperater configDB auf einen NUC mit komibinierter mysql Datenbank zu wechseln. Ich hab es jetzt geschafft, dass ich einen mysql und portainer fehlerfrei und fhem wenigstens mal halbwegs startet und sich nicht sofort wieder beendet. Jetzt hänge ich gerade an folgender Meldung:

Preparing initial start:


1. Updating existing FHEM installation in /opt/fhem





Preparing user environment ...


1. Creating group 'fhem' with GID 6061 ...


2. Enforcing GID for group 'bluetooth' to 6001 ...


3. Creating user 'fhem' with UID 6061 ...


4. Creating log directory /opt/fhem/./log ...


5. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...


6. Enforcing file and directory permissions for /opt/fhem ...


7. Correcting group ownership for /dev/tty* ...


8. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...


9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...


10. Updating /etc/sudoers.d/fhem-docker ...


11. Adding gateway.docker.internal to /etc/hosts ...


12. Adding host.docker.internal to /etc/hosts ...


13. Pre-authorizing SSH to Docker host for user 'fhem' ...


14. Updating SSH key pinning and SSH client permissions for user 'fhem' ...





Preparing configuration ... skipped (detected configDB)


 HINT: Make sure to have your FHEM configuration properly prepared for compatibility with this Docker Image _before_ using configDB !



Starting FHEM ...


2019.11.02 21:03:20 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log


2019.11.02 21:03:20 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid


2019.11.02 21:03:20 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1


2019.11.02 21:03:20 3: From the FHEM_GLOBALATTR environment: attr global nofork 0


Can't locate RTypes.pm in @INC (you may need to install the RTypes module) (@INC contains: . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at fhem.pl line 597.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 03 November 2019, 11:09:09
Can't locate RTypes.pm in @INC (you may need to install the RTypes module)

Irgendwie musst du dieses Perl-Modul installieren, z.B. über das Debian-Package https://packages.debian.org/de/buster/libmime-types-perl (gefunden nach Google-Suche, nicht selbst ausprobiert..)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 03 November 2019, 11:55:56
Das war leider nicht das passende Packet. Wenn man sich die Liste der beinhalteten Dateien aus deinem Link anguckt, dann ist da auch RTypes.pm nicht dabei. :(

Liegt das ganze vielleicht daran, dass ich ubuntu server 18.04 und nicht debian verwende??

EDIT: die Datei liegt auch unter /opt/fhem/FHEM, aber scheinbar wird diese Datei nicht gefunden bzw. gar nicht der komplette Ordner nicht.

Hier ist mal meine docker-compose.yml

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

version: '2.3'

networks:
  net:
    driver: bridge
    # enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/24
          gateway: 172.27.0.1
        # - subnet: fd00:0:0:0:27::/80
        #   gateway: fd00:0:0:0:27::1
volumes:
  portainer_data:

services:

  ####
  # HINT: use only ONE of the example "fhem:" service
  # definitions below !
  #

  # Example w/ custom environment variables
  fhem:
    image: fhem/fhem:latest
    restart: always
    networks:
      - net
    ports:
      - "8083:8083"
      - "7072:7072"
    volumes:
      - "./fhem/:/opt/fhem/"
      - "./fhem/contrib/configDB/configDB.conf:/opt/fhem/configDB.conf"
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
      CONFIGTYPE: configDB
    depends_on:
      - mysql

  portainer:
    image: portainer/portainer:1.20.0
    restart: always
    command: -H unix:///var/run/docker.sock --no-auth
    networks:
      - net
    ports:
      - "9000:9000"
    environment:
      - REGISTRY_HTTP_TLS_CERTIFICATE=/certs/portainer.crt
      - REGISTRY_HTTP_TLS_KEY=/certs/portainer.key
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
      - /home/pirate/certs/portainer.key:/certs/portainer.key
      - /home/pirate/certs/portainer.crt:/certs/portainer.crt

  mysql:
    image: mysql/mysql-server:5.7
    restart: always
    networks:
      - net
    expose:
      - "3306"
      - "33060"
    ports:
      - "3306:3306"
      - "33060:33060"
    volumes:
      - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init-sql
      - ./mysql/data:/var/lib/mysql
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 03 November 2019, 12:06:31
Es ist egal, was für ein Hostsystem du hast. Entscheidend ist, von welchem Parent der Container abstammt. Du könntest auch SUSE oder ARCH als Host haben und trotzdem einen Debian-Container starten.

Ich vermute mal, du baust kein frisches FHEM neu auf im Container, sondern versuchst einen Umzug von deinem Hostsystem nach Docker. Dann musst du herausfinden, woher das Perl-Modul kommt und es im Container bereit stellen, entweder über ein APT-Package, dass du im Container installierst oder ein Perl-Modul, dass du auch im Container installierst. Es nützt nichts, wenn du es im Hostsystem hast.

Und das das Paket nicht passt, habe ich (wie geschrieben), billigend in Kauf genommen 8)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 03 November 2019, 12:06:38
Der Server hat mit dem Container nichts zu tuen .... das ist doch gerade Sinn des Containers.

Ist denn das Packet im Container zu finden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 03 November 2019, 12:14:56
Jetzt habt ihr geantwortet während ich mein Post editiert habe. Ich versuche verzweifelt rauszufinden, welches Paket diese Datei beinhaltet. Ich hab nun sicherlich schon 2 Std. gegoogled und finde nix was mir weiterhilft.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 03 November 2019, 12:27:00
Ok, das scheint ein FHEM-eigenes Modul zu sein, bei mir liegt es in /opt/fhem/FHEM/RTypes.pm ... wirf am besten dein Container inkl. Volume weg und fang neu an.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 03 November 2019, 12:42:51
Ich hab jetzt von docker alles auf dem System gelöscht, Images, Volumes, komplett alles. Danach wieder docker-compose up -d und alles wurde neu heruntergeladen und erzeugt. Es ändert aber nix. Ich kann den Container auch mit der fhem.cfg statt der configDB starten. Aber das möchte ich nicht mehr. In meiner aktuellen configDB habe ich auch nur die Sachen eingefügt, die in der fhem.cfg beinhaltet sind. Also aktuell keine persönlichen Konfigurationen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 03 November 2019, 12:46:06
Ok, dann zeig mal dein docker-compose.yml her. Welche docker-Version verwendest du?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 03 November 2019, 13:30:37
dirk@homeserver:~$ docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.4
 Git commit:        e68fc7a
 Built:             Tue May  7 17:57:34 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.4
  Git commit:       e68fc7a
  Built:            Tue May  7 17:57:34 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Und noch die docker-compose.yml. Basis war hier die aus dem git repo von fhem-docker.

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

version: '2.3'

networks:
  net:
    driver: bridge
    # enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/24
          gateway: 172.27.0.1
        # - subnet: fd00:0:0:0:27::/80
        #   gateway: fd00:0:0:0:27::1
volumes:
  portainer_data:

services:

  ####
  # HINT: use only ONE of the example "fhem:" service
  # definitions below !
  #

  # Example w/ custom environment variables
  fhem:
    image: fhem/fhem:latest
    restart: always
    networks:
      - net
    ports:
      - "8083:8083"
      - "7072:7072"
    volumes:
      - "./fhem/:/opt/fhem/"
      - "./fhem/contrib/configDB/configDB.conf:/opt/fhem/configDB.conf"
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
      CONFIGTYPE: configDB
    depends_on:
      - mysql

  portainer:
    image: portainer/portainer:1.20.0
    restart: always
    command: -H unix:///var/run/docker.sock --no-auth
    networks:
      - net
    ports:
      - "9000:9000"
    environment:
      - REGISTRY_HTTP_TLS_CERTIFICATE=/certs/portainer.crt
      - REGISTRY_HTTP_TLS_KEY=/certs/portainer.key
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
      - /home/pirate/certs/portainer.key:/certs/portainer.key
      - /home/pirate/certs/portainer.crt:/certs/portainer.crt

  mysql:
    image: mysql/mysql-server:5.7
    restart: always
    networks:
      - net
    expose:
      - "3306"
      - "33060"
    ports:
      - "3306:3306"
      - "33060:33060"
    volumes:
      - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init-sql
      - ./mysql/data:/var/lib/mysql
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 03 November 2019, 14:04:42
Und das host-Verzeichnis ./fhem ist zu Beginn leer und wird erst durch den Container gefüllt, richtig?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 03 November 2019, 14:15:41
ja, ich hatte einfach ein git clone https://github.com/fhem/fhem-docker.git ausgeführt, die docker-compose.yml ergänzt und den Ordner mit den mysql Daten in das entsprechende directory kopiert. Danach dann noch die fhem/contrib/configDB/configDB.conf angepasst und versucht die Datenbank soweit zu bereinigen, damit fhem erstmal startet. Der nächste Step wäre dann nach und nach die Datenbank um meine devices aus der alten Datenbank zu erweitern (mit SQL Scripten INSERT INTO .... usw.).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 03 November 2019, 14:40:21
Das klingt alles irgendwie falsch..ich nehme an, du probierst eher herum und hast nicht wirklich Ahnung (von docker, mysql usw.), was genau du tun sollst. Wenn dem nicht so ist, ignoriere die folgenden Hinweise.

- auf der Github README steht: "docker pull fhem/fhem" und nicht clone, warum tust du das?
- mysql Daten: Was ist das? Meinst du mysqldump Dateien? An welche Stelle packst du die?
- Bitte nicht eigenständig an der fhem.cfg oder in dem Fall configDB herumschrauben .. das steht überall im Forum. Weder manuell löschen, noch anschließend mit SQL Insert Skripten im Anschluss Konfigurationen ändern!

Versuche erstmal mit einer wirklich leeren Datenbank und einem leeren Container zu starten. Ich werde das Gefühl nicht los, dass dein "./fhem" Verzeichnis nicht schon bereits von einer anderen FHEM-Instanz gefüllt wurde.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 03 November 2019, 17:42:56
Du hast recht, ich probiere, weil Docker für mich neu ist. Zwar habe ich schon viel gelesen und mir Videos angeschaut, aber so 100%ig steige ich da noch nicht durch. Aber jeder fängt mal klein an. Ja, in der Readme steht man soll docker pull fhem/fhem eingeben und nicht git clone.... Warum tue ich das? Ganz einfach: ich möchte mein persönliches fhem repo auf meinem Synology NAS mit git speichern und wollte dieses repo als Basis nehmen. Aber auch beim Thema git bin ich erstmal noch neu. Aber nun back to topic:

Ich habe jetzt das komplette Dockerzeug bereinigt, eine neuen Ordner fhem und fhem/core angelegt und dort mit docker pull fhem/fhem den Container geladen. Dann mit docker run -d --name fhem -p 8083:8083 -v /fhem/core:/opt/fhem fhem/fhem ein leeres Hostverzeichnis dem Container zugewiesen. So startet fhem auch, aber das hat es bereits mit der alten Umgebung. Nun habe ich in fhem/core/contrib/configDB/configDB.conf meine Zugangsdaten eingetragen und meine alte docker-compose.yml in den Ordner fhem geladen (also den Ordner, den ich erstellt habe in meinem home-Verzeichnis - die Daten liegen ja nach dem docker run Befehl in fhem/core) und dazu meinen Ordner "mysql" mit dem Inhalt "init.sql". Ein docker-compose up -d hat dann wieder alles gestartet.

Inhalt der init.sql:
CREATE DATABASE `fhem` DEFAULT CHARACTER SET = `utf8`;

CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'xxx';

REVOKE CREATE ROUTINE, CREATE VIEW, CREATE USER, ALTER, SHOW VIEW, CREATE, ALTER ROUTINE, EVENT, SUPER, INSERT, RELOAD, SELECT, DELETE, FILE, SHOW DATABASES, TRIGGER, SHUTDOWN, REPLICATION CLIENT, GRANT OPTION, PROCESS, REFERENCES, UPDATE, DROP, REPLICATION SLAVE, EXECUTE, LOCK TABLES, CREATE TEMPORARY TABLES, INDEX ON *.* FROM 'fhemuser'@'%';

UPDATE mysql.user SET max_questions = 0, max_updates = 0, max_connections = 0 WHERE User = 'fhemuser' AND Host = '%';

GRANT CREATE ROUTINE, CREATE VIEW, ALTER, SHOW VIEW, CREATE, ALTER ROUTINE, EVENT, INSERT, SELECT, DELETE, TRIGGER, GRANT OPTION, REFERENCES, UPDATE, DROP, EXECUTE, LOCK TABLES, CREATE TEMPORARY TABLES, INDEX ON `fhem`.* TO 'fhemuser'@'%';

USE `fhem`;

CREATE TABLE history (
    TIMESTAMP TIMESTAMP,
    DEVICE varchar(64),
    TYPE varchar(64),
    EVENT varchar(512),
    READING varchar(64),
    VALUE varchar(255),
    UNIT varchar(32),
    KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`,`VALUE`),
    KEY `Device_Idx` (`DEVICE`,`READING`),
    KEY `Report_Idx` (`TIMESTAMP`,`READING`) USING BTREE
);

CREATE TABLE current (
    TIMESTAMP TIMESTAMP,
    DEVICE varchar(64),
    TYPE varchar(64),
    EVENT varchar(512),
    READING varchar(64),
    VALUE varchar(255),
    UNIT varchar(32)
);

CREATE TABLE fhemversions (
`VERSION` INT,
`VERSIONUUID` CHAR ( 50 )
);
CREATE TABLE fhemstate (
`stateString` TEXT
);
CREATE TABLE fhemconfig (
`COMMAND` VARCHAR ( 32 ),
`DEVICE` VARCHAR ( 64 ),
`P1` VARCHAR ( 50 ),
`P2` TEXT,
`VERSION` INT,
`VERSIONUUID` CHAR ( 50 )
);
CREATE TABLE fhemb64filesave (
`filename` TEXT,
`content` BLOB
);
CREATE INDEX config_idx ON fhemconfig (
`versionuuid`,
`version`
);

FLUSH PRIVILEGES;

Nun scheint aber die Datenbank nicht angelegt zu werden. Spiele ich die alte Datenbank ein, dann hab ich wieder die selbe Fehlermeldung wie zu Beginn -> die Datenbank ist das Problem.

Aber wie kommt man zu einer noch leeren Datenbank, die sowohl die Configs, als auch das Logging beinhaltet??

Und zum Thema keine manuelle Bearbeitung der Datenbank bzw. der fhem.cfg:
Mir sind die Probleme schon bekannt, aber über welchen Weg soll ich meine bisherige FHEM Installation auf das neue System portieren? Ich denke dazu ist ein SQL Dump der jetzigen sqlite DB und ein einfügen in die mysql DB notwendig. Aber ich lasse mich auch gerne eines besseren belehren, denn ich denke ich bin nicht der Erste und sicherlich auch nicht der letzte, der vor diesem Problem steht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 04 November 2019, 09:45:25
So, ich glaub ich hab meinen Fehler gefunden:

in der docker-compose.yml war der Fehler in folgender Zeile:

- ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init-sql
richtig ist:

- ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
Wenn man mit dem Fehler schon einmal ein docker-compose up -d ausgeführt wurde, dann wurden die Datenbank versucht zu initialisieren, aber es hat nicht geklappt. Trotzdem wurde im mysql Container etwas angelegt. Nach der Korrektur wurde das init-script nicht mehr beachtet, weil es schon eine (wenn auch missglückte) Initialisierung gab.

Mit
docker-compose stop
docker-compose rm
cd mysql
rm -f data
docker-compose up -d
wurden die Daten gelöscht und beim nächsten starten korrekt initialisiert. Mein fhem-container ist nun mit Status 'healthy' in portainer gelistet. 
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 04 November 2019, 10:41:29
Du hast recht, ich probiere, weil Docker für mich neu ist. Zwar habe ich schon viel gelesen und mir Videos angeschaut, aber so 100%ig steige ich da noch nicht durch. Aber jeder fängt mal klein an. Ja, in der Readme steht man soll docker pull fhem/fhem eingeben und nicht git clone.... Warum tue ich das? Ganz einfach: ich möchte mein persönliches fhem repo auf meinem Synology NAS mit git speichern und wollte dieses repo als Basis nehmen. Aber auch beim Thema git bin ich erstmal noch neu. Aber nun back to topic:

Das sollte kein Vorwurf werden :) Ich wollte es nur wissen, damit ich nicht völlig in die falsche Richtung schreibe und du denkst "das kenne ich doch schon alles, laaangweilig"  ;)

Falls du systemd verwendest, empfehle ich dir sowas: https://philipp-weissmann.de/docker-compose_mit_systemd/ Dort wird ein generischer docker-compose@.service konfiguriert, mit dem du dann z.B. docker-compose@fhem starten kannst. Und statt dem gesamten fhem-docker repo richtest du dir dann nur noch ein repo (im Blog-Eintrag wäre das dann /opt/dockerfiles/fhem) für deine Konfigurationsdateien ein, also docker-compose.yml, configDB.conf etc. ein. Dann musst du auch nicht ständig das fhem-docker repo in deins nachziehen (ich nehme mal an, dass du eh keine Änderungen bzgl. fhem-docker machen würdest).

Und zum Thema keine manuelle Bearbeitung der Datenbank bzw. der fhem.cfg:
Mir sind die Probleme schon bekannt, aber über welchen Weg soll ich meine bisherige FHEM Installation auf das neue System portieren? Ich denke dazu ist ein SQL Dump der jetzigen sqlite DB und ein einfügen in die mysql DB notwendig. Aber ich lasse mich auch gerne eines besseren belehren, denn ich denke ich bin nicht der Erste und sicherlich auch nicht der letzte, der vor diesem Problem steht.

Ja ein dump der vollständigen Datenbank ist natürlich notwendig. Aber du hattest vorher geschrieben, dass du einzelne Zeilen gelöscht hast und anschließend diese wieder mit INSERT INTO einfügen wolltest.

Aber soweit ich das jetzt verstehe, läuft deine Instanz und die Probleme sind gelöst, oder?  8)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rieders am 04 November 2019, 16:18:45
Hallo

Ich habe mich bisher noch nicht mit docker befasst.
Jetzt möchte ich Fhem vom Raspberry auf die DS 218+ übertragen bzw. laufen lassen.
Ich hatte schon mal ein Image runter geladen , was auch lief.
Nun wollte ich meine Dateien, welche ich im Tablet UI sich befinden auf die Diskstation übertragen.
Leider finde ich den Pfad nicht.

Gibt es eine Anleitung oder sowas für Fhem Docker auf der Diskstation?

Grüße
André
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 04 November 2019, 16:31:49
Generelle Anleitung hier: https://github.com/fhem/fhem-docker/

Für die DiskStation eher selbst zu übertragen.
Aber solange die Docker kann "sollte" das ja durchaus gehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 04 November 2019, 16:49:52
Ja ein dump der vollständigen Datenbank ist natürlich notwendig. Aber du hattest vorher geschrieben, dass du einzelne Zeilen gelöscht hast und anschließend diese wieder mit INSERT INTO einfügen wolltest.

Aber soweit ich das jetzt verstehe, läuft deine Instanz und die Probleme sind gelöst, oder?  8)

Ich hatte einzelne Zeilen verwendet, indem ich die fhem.cfg aus dem docker repo "nachbilden" wollte. Der komplette Dump geht z.b. nicht, weil ich mindestens das https Zeug entfernen muss. Aber das sollte jetzt nicht das große Problem sein. Ansonsten läuft erstmal die configDB, Logging läuft noch nicht, aber da hab ich noch nicht nach dem Fehler gesucht. Erstmal denke ich, dass ich weiter komme...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 04 November 2019, 16:59:41
Eine einzelne Zeile sollte ja auch mit den korrekten Argumenten und Environmentvariablen reichen :-)
docker run oder was machste bei der Synologie?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 07 November 2019, 10:03:02
So, meine Migration von der alten Installation auf die docker Installation ist weitestgehend abgeschlossen. Meine Probleme waren bei der Presence-Erkennung über die Fritzbox. Lösung war eine Anmeldung mit Benutzername und Passwort an der Fritzbox. Werte für Nodered hatte ich per jsonlist2 abgefragt, das ging auch nicht wegen dem csrf-Token. Das habe ich gelöst, in dem ich eine WEBapi auf Port 8088 ohne csfr-Token erstellt habe und diese WEBapi nur Container-intern angesprechbar habe (docker-compose Eintrag: expose - "8088") .
Weiterhin hab ich ein Darstellungsproblem von ä/ö/ü/ß. Wenn ich die Devices korrigiere und speichere, dann funktioniert es. Irgendwie ist das wohl beim Datenbankübertrag von Alt nach Neu kaputt gegangen. Das ist aber ein lösbares Problem.

Insgesamt gefällt mir die Dockerlösung wirklich gut. Danke fürs basteln und für die Unterstützung... :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 07 November 2019, 13:07:29
Wie reaktiv ist das bei dir mit der FritzBox? Bei mir dauert ein Wechsel von Present zu Absent viel zu lange - daher hab ich was eigenes gebaut mit einem Dockercontainert das an FHEM mittels MQTT reported.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 07 November 2019, 13:11:30
Ich hab das so oder so relativ träge eingestellt. Alle 5 Minuten prüfen, dann 3x hintereinander muss auf absent geprüft werden und erst dann ist man wirklich absent. Also alles in allem 20 Minuten. Da ich hauptsächlich die Raumtemperatur damit regle und eine Heizung Ansicht träge ist reicht mir das völlig aus.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 07 November 2019, 13:47:43
Mh bei mir bleiben die Geräte deutlich länger in der FritzBox als aktiv. Also ich rede da von Stunde oder mehr :-D
Danke für die Info.

Nun aber back to topic :-) bevor ich Haue bekomme.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 07 November 2019, 13:58:14
das liegt aber eher daran, das WLAN kein "abmelden" kennt, also je nach FritzBox (und Örtlichkeit ...) die Clients so lange im WLAN zu finden sind
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 07 November 2019, 14:03:42
Und deswegen mache ich es mit ping, hping3 und nmap. :-)
Stell ich aber gesondert mal vor - passt hier net hin.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 07 November 2019, 20:59:10
Bei mir war es sogar so schnell, dass mein Android 9 Handy oft zu schnell auf absent gesetzt wurde. Darum auch die 3x testen bevor man wirklich absent ist. Ich hab eine Fritzbox 7490...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 06 Dezember 2019, 08:26:15
Neues Problem und ich weiß nicht woran es liegen könnte. Wenn ich in die fhem-Befehlszeile ein "update" eintippe, dann bekomme ich folgende Fehlermeldung:

2019.12.06 08:21:54.756 1 :
2019.12.06 08:21:54.757 1 : fhem
2019.12.06 08:21:58.765 1 : https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: connect: timeout
2019.12.06 08:21:58.768 1 :
2019.12.06 08:21:58.769 1 : fhemabfall
2019.12.06 08:22:01.027 1 : nothing to do...

Warum bekomme ich keine Verbindung zu fhem.de hin? muss ich für den Container noch den Port 443 zugänglich machen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 06 Dezember 2019, 10:58:47
Naja der Container braucht Internetzugang für Updates.
Sieht hier so aus, als wäre das eifach nicht gegeben.

Dafür muss aber nicht der Port 443 vom Container zugägnlich sein sondern https://fhem.de:443 vom Container aus erreichbar sein.

Wobei ich mich gerade etwas wundere über das doppelt gemoppelte: https = 443 warum es dann nochmal hinten dran steht O_o
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 06 Dezember 2019, 11:11:01
ich bin mir nicht sicher, ob ich es richtig mache, aber wenn ich mich per portainer in den fhem container einlogge und dort "nmap -p 443 fhem.de" eingebe, dann erhalte ich folgende ausgabe:


root@a01d486b77a1:/opt/fhem# nmap -p 443 fhem.de
Starting Nmap 7.70 ( https://nmap.org ) at 2019-12-06 11:08 CET
Nmap scan report for fhem.de (88.99.31.202)
Host is up (0.021s latency).
Other addresses for fhem.de (not scanned): 2a01:4f8:10a:806::2

PORT    STATE SERVICE
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 2.09 seconds
root@a01d486b77a1:/opt/fhem#

für mich sieht das gut aus...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 06 Dezember 2019, 11:12:38
Oh sorry - hab was überlesen  8)

2019.12.06 08:22:01.027 1 : nothing to do...
Er hatte einfach nix upzudaten - ist aktuell :-D
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 06 Dezember 2019, 11:13:30
Dann kannst Du ja auch noch ein wget oder curl auf die Datei machen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 06 Dezember 2019, 11:21:03
bezieht sich das "nothing to do" nicht auf "fhemabfall"?

allerdings geht ein "curl https://fhem.de/fhemupdate/controls_fhem.txt" auch... also ist die Datei auch erreichbar. Mich wunder das bloß, ich hab schon lange kein Update mehr gemacht...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 06 Dezember 2019, 14:44:22
Was ist denn "fhemabfall"  :o

Ein updaterun der feststellt "es ist alles up to date" bewirkt die Ausgabe "nothing to do"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 06 Dezember 2019, 15:14:43
Das kommt wohl von diesem Youtube Beitrag:

https://m.youtube.com/watch?v=HpZ2m0C3vb0 (https://m.youtube.com/watch?v=HpZ2m0C3vb0)

Ich befürchte dass das mittlerweile in das offizielle Release von fhem geschafft hat und deshalb dieser Link gar nicht mehr nötig wäre...

Nichtsdestotrotz finde ich meine Fehlermeldung wegen der ich geschrieben habe mindestens verwirrend. Auf das "nothing to Do" hab ich gar nicht so richtig geachtet...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: OdfFhem am 06 Dezember 2019, 15:49:10
Bei update all würde die Meldung nothing to do... jeweils pro Repository ausgegeben.

update list liefert die Liste aller Repositories.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: desmoloch am 08 Dezember 2019, 13:21:07
Also irgendwie klappt das mit Pyhton3 und dem Inline::Python nicht so richtig
Ich bekomme bei GOOGLECAST immer folgenden Fehler:
2019.12.08 13:15:03 1: reload: Error:Modul 98_GOOGLECAST deactivated:
 Error -- py_eval raised an exception at /usr/lib/x86_64-linux-gnu/perl5/5.28/Inline/Python.pm line 177.
BEGIN failed--compilation aborted at ./FHEM/98_GOOGLECAST.pm line 699.

2019.12.08 13:15:03 0: Error -- py_eval raised an exception at /usr/lib/x86_64-linux-gnu/perl5/5.28/Inline/Python.pm line 177.
BEGIN failed--compilation aborted at ./FHEM/98_GOOGLECAST.pm line 699.

Traceback (most recent call last):
  File "<string>", line 3, in <module>
ImportError: No module named pychromecast

mein Inline Pyhthon ist eigentlich gesetzt:
INLINE_PYTHON_EXECUTABLE=/usr/bin/python3 cpanm Inlin
e::Python

Was mache ich noch falsch?!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 08 Dezember 2019, 15:23:53
Bei update all würde die Meldung nothing to do... jeweils pro Repository ausgegeben.

update list liefert die Liste aller Repositories.

Ob ich update oder update all eintippe macht in der Ausgabe keinen Unterschied.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: OdfFhem am 08 Dezember 2019, 18:08:10
@persching

update list
https://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt


update check
fhem
nothing to do...

fhemtabletui
nothing to do...


update all
2019.12.08 17:57:08.784 1 : fhem
2019.12.08 17:57:11.002 1 : nothing to do...
2019.12.08 17:57:11.012 1 :
2019.12.08 17:57:11.013 1 : fhemtabletui
2019.12.08 17:57:11.530 1 : nothing to do...


So sieht derzeit meine Ausgabe aus, wenn ich alle Repositories auf dem aktuellen Stand habe.

Statt https://fhem.de/fhemupdate/controls_fhem.txt kann man auch http://fhem.de/fhemupdate/controls_fhem.txt nutzen; ist wohl derzeit auch der Standard im Docker-Image. Beide Varianten führen bei mir aber zum selben Ergebnis.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 08 Dezember 2019, 19:50:54
Wo kann ich denn angeben ob die Daten per http oder https geholt werden? Ich habe (zumindest bewusst) nichts umgestellt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: OdfFhem am 08 Dezember 2019, 20:10:15
@persching

more /opt/fhem/FHEM/controls.txt
https://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt

Diese Datei wird normal über das update-Kommando verwaltet, kann aber im Zweifel auch vom Prompt aus editiert werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Jackson am 08 Dezember 2019, 21:45:20
Nabend,

irgendwie schaffe ich es nicht den node.js package im fhem container zu aktualiseren.

Error code E500
Summary:
Parsing error - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 277 (before "sh: 2: npm: Permissi...") at ./FHEM/42_npmjs.pm line 1160.
Detail:
{
"versions":
{"http_parser":"2.8.0","node":"10.17.0","v8":"6.8.275.32-node.54","uv":"1.28.0","zlib":"1.2.11","brotli":"1.0.7","ares":"1.15.0","modules":"64","nghttp2":"1.39.2","napi":"5","openssl":"1.1.1d","icu":"64.2","unicode":"12.1","cldr":"35.1","tz":"2019a"}
, "outdated": sh: 2: npm: Permission denied
}

Was mach ich falsch? Wenn ich ein "set fhemServerNpm statusRequest" ausführe, ist der Status plötzlich wieder grün.

List Docker

Internals:
   .FhemMetaInternals 1
   CHANGED   
   FUUID      5dba9b1c-f33f-ebd1-6eb9-52ce42b0745edb9c
   NAME       DockerImageInfo
   NR         14
   STATE      ok
   TYPE       DockerImageInfo
   READINGS:
     2019-10-31 09:30:17   container.cap.e audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot

     2019-10-31 09:30:17   container.cap.i audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot

     2019-10-31 09:30:17   container.cap.p audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot

     2019-12-04 20:19:50   container.hostname e707bbf79ed6

     2019-10-31 09:30:17   container.hostnetwork 0

     2019-12-04 20:19:50   container.id    e707bbf79ed6809c6052dc9716ef22a414ac5c2570ba75ece3d2e15e2ab345e7

     2019-10-31 09:30:17   container.privileged 0

     2019-10-31 09:30:17   id.gid          1000
     2019-10-31 09:30:17   id.gname        fhem
     2019-10-31 09:30:17   id.groups       [ "fhem": 1000, "tty": 5, "mail": 8, "dialout": 20, "audio": 29, "video": 44, "bluetooth": 6001, "gpio": 6002, "i2c": 6003 ]
     2019-10-31 09:30:17   id.uid          1000
     2019-10-31 09:30:17   id.uname        fhem
     2019-11-11 21:39:19   image.created   2019-11-10T19:16:37+00:00
     2019-10-31 09:30:17   image.description A basic Docker image for FHEM house automation system, based on Debian Buster.
     2019-10-31 09:30:17   image.documentation https://github.com/fhem/fhem-docker/blob/ae19137eaa2af2fcfe97997d16c1c761d4fa0cd6/README.md
     2019-10-31 09:30:17   image.licenses  MIT
     2019-10-31 09:30:17   image.revision  ae19137eaa2af2fcfe97997d16c1c761d4fa0cd6
     2019-10-31 09:30:17   image.source    https://github.com/fhem/fhem-docker/
     2019-10-31 09:30:17   image.title     fhem-amd64_linux
     2019-10-31 09:30:17   image.url       https://hub.docker.com/r/fhem/fhem-amd64_linux
     2019-10-31 09:30:17   image.vendor    Julian Pawlowski
     2019-11-11 21:39:19   image.version   5.9-s20490_v2.2.1-3-gae19137
     2019-10-31 09:30:17   ssh-id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcVEvrQUjUCijaKDeKOuiycXrOHlAQy+mxzwl6jk3T/ fhem@fhem-docker

     2019-10-31 09:30:17   ssh-id_rsa.pub  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCz7gLpR+A3PguntwsJOmaxMAY46Yh0CXuut677JROk+WYq3pirJRC8KWmeG8moHYGmRrx5R36apTUZEFGRqM4Q1CJpv1d/3rTMv/6ou+AGb2uaQKfjUKiZswLc8E/YYQTCfxLZpuTdfdN3VIxeG0rSFtaaYNSJeeCd+6qBCyDv/np2vzXj28w00rOn45KhD/up/i8yKmhjD3slvpj0aPtlJjib4KmX44dA1n41EUPwiMyD+oh5eQId3+AE7kCQel3NHx86b/QPLCS2Ew36sZxrKAOPut6XXh9u9Edq26aR6eatLI36ex7/ukY676oSmgcbs2qASzrcKkibX5sfhG6lUbPuwIDSZ1EP3xUfrf0LkKfhJ2FzNfqkU2bzUKOBY1jIjb5Y8IIAk1MImO5EJqWqbGbvehVXYWQPojJTeDqJAOi0dgfU5pSpYKwvhjJ5o7EOQtt/rkTK7ZAzIGQArACrMTJKuWMhUOgM6ZG+LhTdYzc47Fnzm0Yad/eCAWCNevGpFlnQRiPhrW1tua6dB0RaGwCf4o9CyzoZuoDeBwn9iSmucPXG3HvbWIugrDXZPFiJdTlcfP/CxutTsXTaLC9qii5VGPvLbTrHYFLZBHQfC9y91djAc5BtA2Cf3nE++f7Pk7m2gEgHo9y4XvcRL+0BVVp7zBYQ37Ih4qCKYIN51Q== fhem@fhem-docker

     2019-10-31 09:30:17   sudoers         [ "# Auto-generated during container start", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm install *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm uninstall *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm update *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/local/bin/cpanm *", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -q update", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -s -q -V upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y install *", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y -q -V dist-upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y -q -V upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/nmap" ]
Attributes:
   alias      Docker Image Info
   devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red
   group      System
   icon       docker
   room       00_System



Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 09 Dezember 2019, 19:54:35
Ich befürchte fast dass ich ganz andere Probleme habe. Ich hab jetzt mein pihole wieder auf cloudflare als DNS resolver eingestellt und jetzt bekomme ich wenigstens mal irgendwas hin so dass bei Update mal kein 'nothing to do' angezeigt bekomme. Aber so richtig flutscht es nicht. Ich bleibe schon bei 10_CUL_HM.pm hängen...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Morgennebel am 10 Dezember 2019, 12:14:26
, "outdated": sh: 2: npm: Permission denied

npm kann wegen fehlender Rechte nicht von /bin/sh aufgerufen werden. Wer das aufruft, keine Ahnung.

Dein Setup verstößt aber gegen das KISS-Prinzip und Du selbst kannst es nicht debuggen. Was soll passieren, wenn es mal richtig kritisch wird...?

Ciao, -MN
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 10 Dezember 2019, 15:01:05
@persching

more /opt/fhem/FHEM/controls.txt
https://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt

Diese Datei wird normal über das update-Kommando verwaltet, kann aber im Zweifel auch vom Prompt aus editiert werden.

Es wird immer komischer. In meiner controls.txt steht definitiv "http://fhem.de/fhemupdate/controls_fhem.txt":

https://ibb.co/VjFzpfY (https://ibb.co/VjFzpfY)

 trotzdem kommt dann im Log der Eintrag

2019.12.10 14:48:40.106 1: https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: connect: timeout
erste Idee: vielleicht wird auf eine andere Datei zugegriffen und darum habe ich einfach .aaa an den Pfad gehängt. Das führt zu

2019.12.10 14:51:26.849 1: https://fhem.de/fhemupdate/controls_fhem.txt.aaa: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: connect: timeout
Woher kommt das https?  :o

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: OdfFhem am 10 Dezember 2019, 16:54:00
@persching

Ist denn Dein Problemfall auf den FHEM-Server beschränkt oder generell in Deinem Netzwerk vorhanden?

Mach doch mal folgenden Test: Starte einen Browser im private/incognito-Modus - http/https-Aufrufreihenfolge einhalten:

Erster und evtl weitere http-Aufrufe liefern immer das not secure-Schloss
http://fhem.de/fhemupdate/controls_fhem.txt

Mindestens ein https-Aufruf ausführen; liefert logischerweise das secure-Schloss
https://fhem.de/fhemupdate/controls_fhem.txt

Ab jetzt (!) liefert aber auch jeder weitere http-Aufruf das secure-Schloss; d.h. werden statt mit http mit https ausgeführt
http://fhem.de/fhemupdate/controls_fhem.txt
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 10 Dezember 2019, 17:20:02
Hallo OdfFhem,
es ist wie von dir beschrieben: http Aufruf erst ohne Schloss, dann https mit Schloss und ab dann beide Varianten mit Schloss.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: OdfFhem am 10 Dezember 2019, 18:33:51
@persching

Von welchem Rechner hast Du den Test jetzt gemacht?

Mach doch mal zusätzlich folgende Aufrufe vom Prompt am FHEM-Server:
curl http://fhem.de/fhemupdate/controls_fhem.txt -o http.out -v > http.verbose 2>&1
curl https://fhem.de/fhemupdate/controls_fhem.txt -o https.out -v > https.verbose 2>&1

Darauf achten, dass die Ausgabedateien in einem temporären Verzeichnis (z.B. /tmp) landen bzw. wieder entfernt werden.

Die out-Dateien sollten ja im Normalfall gleichgroß sein. In den verbose-Dateien finden sich im Fehlerfall vermutlich ein paar zusätzliche Informationen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Morgennebel am 10 Dezember 2019, 19:54:48
es ist wie von dir beschrieben: http Aufruf erst ohne Schloss, dann https mit Schloss und ab dann beide Varianten mit Schloss.

Im dritten Test macht der Server automatisch eine Umlenkung von http auf https. Schau Dir die URL im Browser mal genau an.

Warum er es beim ersten Mal nicht macht, keine Ahnung. Evtl. eine RegExp im Redirect, die nicht funktioniert?

Ciao, -MN
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 11 Dezember 2019, 15:53:46
@persching

Von welchem Rechner hast Du den Test jetzt gemacht?

Mach doch mal zusätzlich folgende Aufrufe vom Prompt am FHEM-Server:
curl http://fhem.de/fhemupdate/controls_fhem.txt -o http.out -v > http.verbose 2>&1
curl https://fhem.de/fhemupdate/controls_fhem.txt -o https.out -v > https.verbose 2>&1

Darauf achten, dass die Ausgabedateien in einem temporären Verzeichnis (z.B. /tmp) landen bzw. wieder entfernt werden.

Die out-Dateien sollten ja im Normalfall gleichgroß sein. In den verbose-Dateien finden sich im Fehlerfall vermutlich ein paar zusätzliche Informationen ...

Ich habe den Test mit Firefox auf meinem Android 9 Handy gemacht.

Die beiden curl Befehle bringen folgendes zutage:

http.verbose:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2a01:4f8:10a:806::2...
* TCP_NODELAY set
* Connected to fhem.de (2a01:4f8:10a:806::2) port 80 (#0)
> GET /fhemupdate/controls_fhem.txt HTTP/1.1
> Host: fhem.de
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 11 Dec 2019 06:20:45 GMT
< Server: Apache
< X-Xss-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Last-Modified: Tue, 10 Dec 2019 06:45:12 GMT
< Accept-Ranges: bytes
< Content-Length: 143698
< Vary: Accept-Encoding
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Pragma: no-cache
< Content-Type: text/plain
<
{ [1031 bytes data]

100  140k  100  140k    0     0  1287k      0 --:--:-- --:--:-- --:--:-- 1287k
* Connection #0 to host fhem.de left intact

https.verbose

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2a01:4f8:10a:806::2...
* TCP_NODELAY set
* Connected to fhem.de (2a01:4f8:10a:806::2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2677 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=fhem.de
*  start date: Dec  1 14:09:13 2019 GMT
*  expire date: Feb 29 14:09:13 2020 GMT
*  subjectAltName: host "fhem.de" matched cert's "fhem.de"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
} [5 bytes data]
> GET /fhemupdate/controls_fhem.txt HTTP/1.1
> Host: fhem.de
> User-Agent: curl/7.58.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Date: Wed, 11 Dec 2019 06:21:55 GMT
< Server: Apache
< Strict-Transport-Security: max-age=31536000;
< X-Xss-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Last-Modified: Tue, 10 Dec 2019 06:45:12 GMT
< Accept-Ranges: bytes
< Content-Length: 143698
< Vary: Accept-Encoding
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Pragma: no-cache
< Content-Type: text/plain
<
{ [5 bytes data]

100  140k  100  140k    0     0  1031k      0 --:--:-- --:--:-- --:--:-- 1031k
* Connection #0 to host fhem.de left intact

diff http.out https.out liefert keine unterschiede...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 12 Dezember 2019, 16:51:38
Ich hab jetzt noch einen weiteren Test gemacht und mich in Portainer in meinen fhem-Container eingeloggt und dort im Terminalfenster die curl Befehle ausgeführt. Beide liefern die gleich große Dateien zurück. Und das wichtigste: es werden die Daten runtergeladen, kein Timeout oder sonst etwas. Wartet der Updateprozess von fhem einfach nicht lange genug und bringt darum diese Fehlermeldung??
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 Dezember 2019, 18:19:46
Neues Problem und ich weiß nicht woran es liegen könnte. Wenn ich in die fhem-Befehlszeile ein "update" eintippe, dann bekomme ich folgende Fehlermeldung:

2019.12.06 08:21:54.756 1 :
2019.12.06 08:21:54.757 1 : fhem
2019.12.06 08:21:58.765 1 : https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: connect: timeout
2019.12.06 08:21:58.768 1 :
2019.12.06 08:21:58.769 1 : fhemabfall
2019.12.06 08:22:01.027 1 : nothing to do...

Warum bekomme ich keine Verbindung zu fhem.de hin? muss ich für den Container noch den Port 443 zugänglich machen?


Meine Vermutung: Du benutzt Docker mit IPv6 und das ist nicht ganz trivial. So wie es aussieht scheitert der Verbindungsaufbau über IPv6 und Perl nimmt glaube ich kein Fallback auf IPv4 vor.


Wobei ich mich gerade etwas wundere über das doppelt gemoppelte: https = 443 warum es dann nochmal hinten dran steht O_o


Doppelt gemoppelt ist da nichts, es überschreibt einfach nur die implizite Assoziation, dass https per Default über Port 443 läuft. Zufällig wird das eben auch mit 443 überschrieben und somit "statisch" festgelegt. Das eine legt den Port fest, das andere sorgt für einen verschlüsselten Verbindungsaufbau - zwei verschiedene paar Schuhe, rein technisch ;-)
Das ist in den HttpUtils von FHEM fest so implementiert.


Statt https://fhem.de/fhemupdate/controls_fhem.txt (https://fhem.de/fhemupdate/controls_fhem.txt) kann man auch http://fhem.de/fhemupdate/controls_fhem.txt (http://fhem.de/fhemupdate/controls_fhem.txt) nutzen; ist wohl derzeit auch der Standard im Docker-Image. Beide Varianten führen bei mir aber zum selben Ergebnis.


Aus dem Gedächtnis:
Das ist keine Eigenart des Docker Image, das ist allgemeiner FHEM Default, weil ganz früher(TM) gab es eben kein Update über HTTPS. 98_update.pm handhabt das abhängig von der Verfügbarkeit von den Crypto Libraries auf der lokalen Maschine speziell für die fhem.de Domain. Wenn man also http://fhem.de (http://fhem.de) statt https://fhem.de (https://fhem.de) drin stehen hat, dann wird trotzdem https verwendet, wenn die lokalen Libraries dafür verfügbar sind, ansonsten wird auf unverschlüsseltes http zurückgeschaltet, um trotzdem ein Update zu ermöglichen.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 12 Dezember 2019, 20:11:09
Und was kann ich nun tun?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 Dezember 2019, 09:06:17
Du könntest versuchen, IPv6 abzuschaltet .. jedenfalls für Docker ..
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 13 Dezember 2019, 09:36:16
Wie bekomme ich alexa-fhem installiert? Bei mir scheitert das immer mit folgenden ergebnis im event monitor:
2019-12-13 09:32:28.808 npmjs fhemServerNpm command 'npm getNodeVersion' in progress
2019-12-13 09:32:29.981 npmjs fhemServerNpm npm is up to date
2019-12-13 09:32:38.057 npmjs fhemServerNpm command 'npm install alexa-fhem' in progress
2019-12-13 09:32:38.096 Global global npmjs:BEGININSTALL fhemServerNpm alexa-fhem
2019-12-13 09:32:46.170 alexa alexa alexaFHEM: stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
2019-12-13 09:32:46.178 Global global npmjs:FINISHINSTALL fhemServerNpm alexa-fhem
2019-12-13 09:32:46.193 npmjs fhemServerNpm installed: successful
2019-12-13 09:32:46.193 npmjs fhemServerNpm npm is up to date
2019-12-13 09:32:46.193 npmjs fhemServerNpm command 'npm outdated' in progress
2019-12-13 09:32:47.355 npmjs fhemServerNpm outdated: check failed
2019-12-13 09:32:47.355 npmjs fhemServerNpm error 'outdated'
und wenn ich das mache:
sudo npm install -g alexa-fhem
ergibt es:
udated 1 package in 0.437

aber alexa-fhem geht weiterhin nicht und im log steht
Error: Cannot find module 'commander'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object. (/usr/lib/node_modules/alexa-fhem/lib/cli.js:2:15)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)[\code]
Wenn ich dann einen statusrequest mach meint er dann wieder up-to-date und das spiel kann von vorne beginnen.
anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 15 Dezember 2019, 12:28:41
Du könntest versuchen, IPv6 abzuschaltet .. jedenfalls für Docker ..

ich hatte die ganzen IPv6 Sachen in der docker-compose.yml auskommentiert gehabt. Da war es auch nicht besser. Ich dachte dann, ich füge mal IPv6 hinzu, vielleicht funktioniert es ja dann, weil mein Anschluss wohl auf IPv6 ist (zumindest bekomme ich überall eine IPv6 Adresse angezeigt). Scheinbar macht das aber alles kein unterschied. :( Hab denn nur ich die Probleme??? Soll ich vielleicht mal ein docker system prune machen, damit mal alles neu gebildet wird? Sollte ja relativ problemlos funktionieren und es sollte auch nix dadurch verloren gehen...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Ranseyer am 16 Dezember 2019, 17:59:30
Hi,

ich könnte mal einen Tipp gebrauchen...

Es laufen zwei fhem-container:

    fhem:
        restart: always
        ports:
            - "8084:8084"
            - "7070-7074:7070-7074"
        image: fhem/fhem:latest
        volumes:
            - ./fhem/core/:/opt/fhem/
        networks:
            - fhem-network
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7070
            TZ: Europe/Berlin
            CPAN_PKGS: "XML::Bare XML::Bare"
            APT_PKGS: "bash mc net-tools"
        depends_on:
            - "mysql"
            - "mqtt"


    fhem-realtime:
        restart: always
        ports:
            - "8083:8083"
            - "7075-7080:7075-7080"
        image: fhem/fhem:latest
        volumes:
            - ./fhem-realtime/core/:/opt/fhem/
        networks:
            - fhem-network
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7075
            TZ: Europe/Berlin
            CPAN_PKGS: "XML::Bare XML::Bare"
            APT_PKGS: "bash mc net-tools"
        depends_on:
            - "mysql"

Telnet läuft bei "fhem" auf Port 7070. Bei "fhem-realtime" auf Port 7075.
Vom Dockerhost kann ich auf keinen der Telnet Ports zugreifen. Auf FHEM-Web klappt der Zugriff mit den Ports von oben aber problemlos.


Ein List auf den allowed_telnetPort:
Internals:
   CFGFN     
   FUUID      5df7b3a8-f33f-fc98-dad5-1f0d344908b8e215
   NAME       allowed_telnetPort
   NR         822
   STATE      validFor:telnetPort
   TYPE       allowed
   validFor   telnetPort
   READINGS:
     2019-12-16 17:41:12   state           validFor:telnetPort
Attributes:
   DbLogExclude .*
   globalpassword HxxxxxxxxxxxH
   validFor   telnetPort

Wenn ich vom Docker-Host eingebe:
Zitat
root@SRV:/opt/docker/fhem# telnet 192.168.1.2 7075
Trying 192.168.1.2...
telnet: Unable to connect to remote host: Connection refused

Hat sich mit der Dockergeschichte noch etwas geändert was ich übersehen habe?
(Das habe ich gelesen: https://github.com/fhem/fhem-docker/tree/775f854c3781f9b14f5e000fee9e7b3588e1686b#role-of-the-telnet-device-in-fhem)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 16 Dezember 2019, 18:49:32
        ports:
            - "8083:8083"
            - "7075-7080:7075-7080"

Hast Du fhem denn auch gesagt, das Telnet auf dem Port laufen soll?

Allerdings .. wenn Du vom Host selber auf die COntainer willst, brauchst Du die Ports nicht direkt zu exposen. Du kannst auch über docker-ip und Port "reinhüpfen"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Ranseyer am 16 Dezember 2019, 19:11:43
Hast Du fhem denn auch gesagt, das Telnet auf dem Port laufen soll?

Der Meinung bin ich schon !
(ed: das allowfrom habe ich erst später eingebaut, da kein Erfolg)
 
Internals:
   CONNECTS   422
   DEF        7075
   FD         8
   FUUID      5c645895-f33f-0eb4-037e-84e485e4fd6a2192
   NAME       telnetPort
   NR         35
   PORT       7075
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2019-12-16 17:09:16   state           Initialized
Attributes:
   allowfrom  127/8, 192.168/16
   group      System
   icon       it_telephone
   room       8.00_Zentral



Zitat
Allerdings .. wenn Du vom Host selber auf die COntainer willst, brauchst Du die Ports nicht direkt zu exposen. Du kannst auch über docker-ip und Port "reinhüpfen"
Da hast Du Recht ! Das Exponieren möchte ich später auch wieder rausnehmen wenn das alles sauber läuft...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Jackson am 17 Dezember 2019, 12:21:55
Wie bekomme ich alexa-fhem installiert? Bei mir scheitert das immer mit folgenden ergebnis im event monitor:
2019-12-13 09:32:28.808 npmjs fhemServerNpm command 'npm getNodeVersion' in progress
2019-12-13 09:32:29.981 npmjs fhemServerNpm npm is up to date
2019-12-13 09:32:38.057 npmjs fhemServerNpm command 'npm install alexa-fhem' in progress
2019-12-13 09:32:38.096 Global global npmjs:BEGININSTALL fhemServerNpm alexa-fhem
2019-12-13 09:32:46.170 alexa alexa alexaFHEM: stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
2019-12-13 09:32:46.178 Global global npmjs:FINISHINSTALL fhemServerNpm alexa-fhem
2019-12-13 09:32:46.193 npmjs fhemServerNpm installed: successful
2019-12-13 09:32:46.193 npmjs fhemServerNpm npm is up to date
2019-12-13 09:32:46.193 npmjs fhemServerNpm command 'npm outdated' in progress
2019-12-13 09:32:47.355 npmjs fhemServerNpm outdated: check failed
2019-12-13 09:32:47.355 npmjs fhemServerNpm error 'outdated'
und wenn ich das mache:
sudo npm install -g alexa-fhem
ergibt es:
udated 1 package in 0.437

aber alexa-fhem geht weiterhin nicht und im log steht
Error: Cannot find module 'commander'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object. (/usr/lib/node_modules/alexa-fhem/lib/cli.js:2:15)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)[\code]
Wenn ich dann einen statusrequest mach meint er dann wieder up-to-date und das spiel kann von vorne beginnen.
anton

Da ich ja nicht der einzigen bin zum Thema permission und npm, muss ich das Thema nochmal highlighten....

https://forum.fhem.de/index.php/topic,89745.msg1000286.html#msg1000286 (https://forum.fhem.de/index.php/topic,89745.msg1000286.html#msg1000286)

Wie kann man das Thema zu den Rechten im Container lösen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 17 Dezember 2019, 18:40:13

Internals:
   CONNECTS   422
   DEF        7075      <<<<---- global ??????
   FD         8
   FUUID      5c645895-f33f-0eb4-037e-84e485e4fd6a2192
   NAME       telnetPort
   NR         35
   PORT       7075
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2019-12-16 17:09:16   state           Initialized
Attributes:
   allowfrom  127/8, 192.168/16
   group      System
   icon       it_telephone
   room       8.00_Zentral


Da hast Du Recht ! Das Exponieren möchte ich später auch wieder rausnehmen wenn das alles sauber läuft...

Define
define <name> telnet <portNumber> [global|hostname]
oder
define <name> telnet <servername>:<portNummer>

Erste Form, Server-mode:
Überwacht den TCP/IP-Port <portNummer> auf ankommende Verbindungen.


Wenn der zweite Parameter nicht angegeben wird, wird der Server nur auf Verbindungen von localhost achten.

>>>> Falls der zweite Parameter global ist, dann wird telnet auf allen lokalen Netzwerk-Interfaces zuhören,
ansonsten wird der Parameter als Hostname oder Adresse interpretiert, und nur diese lokale Adresse bedient. <<<<

Teste mal global ... ansonsten, netstat ob schon ein anderer Dienst auf diese Ports lauscht ... funktioniert es, wenn du nur einen Container startest?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mrfloppy am 18 Dezember 2019, 08:26:55
Zitat
Da ich ja nicht der einzigen bin zum Thema permission und npm, muss ich das Thema nochmal highlighten....

https://forum.fhem.de/index.php/topic,89745.msg1000286.html#msg1000286

Wie kann man das Thema zu den Rechten im Container lösen?
Ebenso das selbe Problem.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wiego am 18 Dezember 2019, 20:42:01
Hallo,

ich nutze das FHEM Docker Image mit Begeisterung auf einem RaspberryPi mit hypriot.
In Fhem nutze ich die  51_RPI_GPIO.pm und dessen Interrupt-Funktion um ein paar Signale direkt an den GPIOs am RaspberryPi zu empfangen.

Leider funktioniert genau dieser Interrupt nur, wenn ich wiringPi nachträglich manuell im laufenden Docker Image einbaue:
git clone git://git.drogon.net/wiringPi
cd wiringPi
./build


Ich hab dafür leider bisher für wiringPi kein APK gefunden, dass ich über Environments einbinden könnte.

Meine Frage ist jetzt, welche Möglichkeit gibt es, wiringPi in das Docker Image zu bekommen, so dass es bei jedem docker-compose up auch wieder eingebaut ist?

Danke und Grüße
wiego


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Ranseyer am 18 Dezember 2019, 22:38:16
Zitat
Teste mal global ... ansonsten

Danke das wars !
(Hatte ich auch schon mal probiert, damals aber noch ein weiteres Problem :-)

Morgen geht es weiter!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 18 Dezember 2019, 23:59:51
Hallo,

ich nutze das FHEM Docker Image mit Begeisterung auf einem RaspberryPi mit hypriot.
In Fhem nutze ich die  51_RPI_GPIO.pm und dessen Interrupt-Funktion um ein paar Signale direkt an den GPIOs am RaspberryPi zu empfangen.

Leider funktioniert genau dieser Interrupt nur, wenn ich wiringPi nachträglich manuell im laufenden Docker Image einbaue:
git clone git://git.drogon.net/wiringPi
cd wiringPi
./build


Ich hab dafür leider bisher für wiringPi kein APK gefunden, dass ich über Environments einbinden könnte.

Meine Frage ist jetzt, welche Möglichkeit gibt es, wiringPi in das Docker Image zu bekommen, so dass es bei jedem docker-compose up auch wieder eingebaut ist?

Danke und Grüße
wiego
Und warum nimmst Du bei einem Debian Image kein Debian Paket?
wget https://project-downloads.drogon.net/wiringpi-latest.deb
sudo dpkg -i wiringpi-latest.deb
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wiego am 19 Dezember 2019, 15:06:55
Und warum nimmst Du bei einem Debian Image kein Debian Paket?
Code: [Auswählen]

wget https://project-downloads.drogon.net/wiringpi-latest.deb
sudo dpkg -i wiringpi-latest.deb

Stimmt, das ist schöner, Danke.

Was mir noch gefehlt hat, wo ich das einbaue? Hab es jetzt nach einigem Herumexperimentieren in das pre.init.sh script eingebaut und das im Docker-Compose.yml explicit gemountet:

        - ./data/fhem/pre-init.sh:/docker/pre-init.sh

Damit scheint es zu funktionieren.
Vielleicht hilft das nochmal jemanden.

Danke und Grüße
wiego
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 20 Dezember 2019, 12:34:17
Zur Info:
ich konnte mein Problem lösen in dem ich die Daten manuell ausgecheckt habe und die Dateien in den entsprechenden Ordner kopiert habe. Dort war auch eine neue Version von "98_update.pm" dabei. Danach ein "shutdown restart" und nach dem Start ein "update" und alles funktionierte wieder wie gewohnt. :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 21 Dezember 2019, 14:07:41
Hallo,
ich bin noch in der Orientierungsphase zu fhem mit docker.
Die docker Kenntniss sind sehr bescheiden.

Nun habe ich folgendes gefunden:
  klein0r / fhem-docker
Dies habe ich mit docker-compose sehr einfach installieren koennen, jedoch kaempf ich noch mit dem Status einiger Pakete, die anscheinend nicht installiert sind.
Die Container setzen dann wohl auch auf alpine und nicht auf buster auf, was mich etwas verwirrt hat.
fhem_reverseproxy_1 running fhem nginx:latest
fhem_adminer_1 running fhem adminer
fhem_portainer_1 running fhem portainer/portainer:latest
fhem_mariadb_1 running fhem fhem_mariadb
fhem_fhem_1 running fhem fhem_fhem

Und dann noch aus diesem Thread:
   fhem / fhem-docker
Das hat mir ebenfalls ein fhem aufgesetzt, jedoch ohne db und reverseproxy. Hier scheint mir jedoch die Basis Installation kompletter und runder zu sein.
Ein fhem update all und node Update hat von anfangan geklappt, was in obiger Installation wegen fehlendem cpanm nicht klappte.
Portainer hatte ich bereits selber vom ersten testen bereits aufgesetzt.
fhem stopped - fhem/fhem

Jetzt ist fuer mich die Frage, mit welcher Implementierung soll ich weiter machen, um mir nicht zu viele Probleme ein zu handeln?

Mein Ziel ist es fhem vom rpi2 auf den bereits laufenden rpi4 mit docker zu migrieren/sauber zu uebernehmen.
Wegen meiner PV-Anlage moechte ich das logging in eine DB ueberfuehren und mit Grafana darstellen.
Brauche ich den reverseproxy ueberhaupt, wenn ich von extern eh nur mit VPN auf fhem zugreife?
Ist docker-composer sinnvoll zu diesem Zeitpunkt?

Ueber Meinungen waere ich sehr erfreut.

Viele Gruesse
    Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 21 Dezember 2019, 17:37:12
Hallo ch.eick,
ich habe auch erst seit kurzem docker und kann dir einfach mal meine docker-compose.yml hier rein stellen, vielleicht hilft dir die weiter:

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

version: '2.3'

networks:
  net:
    driver: bridge
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/24
          gateway: 172.27.0.1
        - subnet: fd00:0:0:0:27::/80
          gateway: fd00:0:0:0:27::1
volumes:
  portainer_data:

services:

  ####
  # HINT: use only ONE of the example "fhem:" service
  # definitions below !
  #

  # Example w/ custom environment variables
  fhem:
    image: fhem/fhem:latest
    restart: always
    networks:
      - net
    expose:
      - "8088"
    ports:
      - "8083:8083"
      - "7072:7072"
    privileged: true
    devices:
      - "/dev/ttyACM0:/dev/ttyACM0"
    volumes:
      - "./core/:/opt/fhem/"
      - "./core/contrib/configDB/configDB.conf:/opt/fhem/configDB.conf"
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
      CONFIGTYPE: configDB
    depends_on:
      - "mysql"
#     - "mariadb"
      - "mqtt"

  portainer:
    image: portainer/portainer:latest
    restart: always
    command: -H unix:///var/run/docker.sock --no-auth
    networks:
      - net
    ports:
      - "9000:9000"
    environment:
      - REGISTRY_HTTP_TLS_CERTIFICATE=/certs/portainer.crt
      - REGISTRY_HTTP_TLS_KEY=/certs/portainer.key
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
      - /home/dirk/certs/portainer.key:/certs/portainer.key
      - /home/dirk/certs/portainer.crt:/certs/portainer.crt

  mysql:
    image: mysql/mysql-server:5.7
    restart: always
    networks:
      - net
    expose:
      - "3306"
      - "33060"
    ports:
      - "3306:3306"
      - "33060:33060"
    command: --sql_mode=""
    volumes:
      - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
      - ./mysql/log:/var/log
      - ./mysql/data:/var/lib/mysql
      - ./mysql/mycustom.cnf:/etc/mysql/conf.d/custom.cnf
    environment:
      - MYSQL_RANDOM_ROOT_PASSWORD=yes

#  mariadb:
#    image: mariadb/server:10.4
#    restart: always
#    networks:
#      - net
#    expose:
#      - "3306"
#      - "33060"
#    ports:
#      - "3306:3306"
#      - "33060:33060"
#    command: --sql_mode=""
#      - ./mariadb/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
#      - ./mariadb/log:/var/log
#      - ./mariadb/data:/var/lib/mysql
#      - ./mariadb/mycustom.cnf:/etc/mysql/conf.d/custom.cnf
#    environment:
#      - MYSQL_RANDOM_ROOT_PASSWORD=yes

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

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

  grafana:
    image: grafana/grafana:latest
    restart: always
    networks:
      - net
    expose:
      - "3000"
    ports:
      - "4000:3000"
    volumes:
      - ./grafana/data:/var/lib/grafana
      - ./grafana/log:/var/log/grafana
      - ./grafana/conf/mygrafana.ini:/etc/grafana/grafana.ini
    environment:
      - GF_SECURITY_ADMIN_PASSWORT={your password}
      - GF_LOG_MODE=console file
      - GF_LOG_LEVEL=debug
      - GF_RENDERING_SERVER_URL=http://{HOST IP}:8081/render
      - GF_RENDERING_CALLBACK_URL=http://{HOST IP}:4000/
      - GF_LOG_FILTERS=rendering:debug
    depends_on:
      - "mysql"
     # - "mariadb"

  renderer:
    image: grafana/grafana-image-renderer:latest
    restart: always
    networks:
      - net
    expose:
      - "8081"
    ports:
      - "8081:8081"
    depends_on:
      - "grafana"

mariaDB ist da auskommentiert, weil ich damit mal rumgespielt hatte aber es nicht so funktionierte wie erhofft. Ich hab dann aber auch nicht groß nach Fehlern gesucht und einfach weiterhin mysql genommen. Die Dinge in geschweifter Klammer musst du noch durch deine Daten ersetzen. MQTT und nodered kannst du bei Bedarf ja auch einfach weglassen. Port 8088 bei fhem ist für Daten per jsonlist an nodered zu bekommen.

Den Reverseproxy brauchst du in der Tat nicht, wenn du nur per VPN auf den raspi zugreifst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 21 Dezember 2019, 19:46:18
Hallo persching,

vielen Dank, jetzt habe ich erst mal Futter und Urlaub :-) , da komme ich dann sicher weiter.
Noch eine Frage, mit https hatte ich auf dem bisherigen System oft Fehlermeldungen. ich denke da gilt das Gleiche wie bei
dem reverseproxy, also nicht unbedingt notwendig, da ich nur per vpn von aussen ins Netz gehe.

Gruesse
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: SB am 27 Dezember 2019, 16:39:26
Hallo zusammen!

Erstmal großes Danke an Loredo für die Zeit, Mühe und Know-How, welches in diesem Image steckt. Da mir Docker etc. nicht gänzlich fremd ist, kann ich nachvollziehen wie viel Arbeit so ein schickes Image macht.

Ich habe bis vor Kurzem ein selbst gestaltetes Image für Fhem und Alexa-Fhem verwendet und bin jetzt letztendlich doch im Zuge einer Systemumstellung Zuhause auf KVMs+Docker (Proxmox VE für meine VMs) auf dein Image umgestiegen. (Vor allem, weil Alexa-Fhem nicht wollte wie ich...)

Ich habe aber dennoch eine Frage zum Status dieses kleinen Projektes...

Mir ist aufgefallen, dass die letzten Commits in beiden Branches auf Github schon eine Zeit her sind und das Repo auf Travis als inactive markeirt wurde. Die letzten Builds des dev Branches waren ja nicht successful (offensichtlich hat sich ein Problem nach Commit https://github.com/fhem/fhem-docker/commit/029bb604cf93510a193d16035304ed51936ca124 im dev Branch eingeschlichen). Der main Branch ist leider noch ein paar Commits hinterher...

Ich wollte deshalb mal vorsichtig nachfragen, ob du weiterhin Pflege an dem Image betreiben wirst oder du das Vorhaben (zB aufgrund des Aufwandes/Zeitmangels - völlig verständlich) vorerst auf Eis gelegt hast?

Danke nochmal für deine Arbeit!

LG Sascha
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 28 Dezember 2019, 17:55:40
Hallo zusammen,

ich bearbeite gerade die Netzwerkintegration mit docker-compose, um meine ersten docker container ins Hausnetz zu integrieren. Durch Eure Hilfe bin ich bereits einige Schritte weiter,
doch es fehlt noch etwas. Gibt es eine Liste der docker-compose optionen? Ich habe bereits auf der Dokuseite von docker gesucht, komme jedoch immer nur zu Beispielen.
Durch Volker und Beispiele habe ich zB bereits einiges bekommen, was hier eingekuerzt fuer das Netzwerk ist:
version: '3.3'

networks:
  net:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.178.0/24

services:
  fhem:
    networks:
      net:
        ipv4_address: 192.168.178.42
    expose:
      - "8088"
    ports:
      - "9522:9522/udp"
      - "8083:8083"
      - "7072:7072"

Bisher kann ich die Service ipv4_adressen im Router bereits sehen.
Aus fhem heraus scheint das Netzwerk bereits zu arbeiten, denn IP_devices werden bereits erreicht.
Wegen den notwendigen udp Verbindung, die ich zum SMAEM benoetige habe ich "9522:9522/udp" eingetragen. Diese Verbindung kommt auch bereits zustande.

Was noch nicht funktioniert ist die http Verbindung zu den Webinterfaces in den Containern.
http://192.168.178.41:9000 fuer Portainer
http://192.168.178.42:8083/fhem fuer fhem

Momentan wuerde mir ein flaches Netwerk genuegen, da ich nur per vpn von ausserhalb zugreife.

Die vorherige docker-compose Konfiguration funktionierte bereits, jedoch mit dem Manko, dass die udp Verbindung ins Hausnetz nicht klappte.
@Volker, vielen dank fuer die bisherige Hilfe, faellt Dir ansonsten noch auf wo mein Fehler liegt?

Fuer weitere Tipps waere ich sehr dankbar. Wie bereits geschrieben finde ich ums Verrecken nicht den Link zur docker-compose Netzwerk Optionen Seite :-(

Viele Gruesse
     Christian


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 30 Dezember 2019, 13:02:24
Hallo zusammen,
hier kommt noch ein Update meiner Experimente.

Ich habe es nun mit zwei Netzwerkdefinitionen versucht. Im Container finde ich auch beide.
Nun klappt wieder der Zugriff ueber das docker Netzwerk mit den Ports auf Portainer und Fhem.

Nur klappt es jetzt wieder nicht mit dem upd auf meinen SMAEM :-(

Wie koennte ich denn zB. mit netcat die Verbindung testen, ich glaube da ist in den letzten Jahrzehnten einiges an Wissen verschuettet worden :-)

version: '3.3'

networks:
  net:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/24

 net-udp:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.178.0/24

####################################################

services:
  fhem:
   networks:
      net:

      net-udp:
        ipv4_address: 192.168.178.42

    expose:
      - "8088"

    ports:
      - "9522:9522/udp"
      - "8083:8083"
      - "7072:7072"


root@30a6971e25ab:/opt/fhem# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.27.0.4  netmask 255.255.255.0  broadcast 172.27.0.255
        ether 02:42:ac:1b:00:04  txqueuelen 0  (Ethernet)
        RX packets 761  bytes 744085 (726.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 632  bytes 103985 (101.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.42  netmask 255.255.255.0  broadcast 192.168.178.255
        ether 02:42:c0:a8:b2:2a  txqueuelen 0  (Ethernet)
        RX packets 2157  bytes 395236 (385.9 KiB)
        RX errors 0  dropped 942  overruns 0  frame 0
        TX packets 1492  bytes 138777 (135.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@30a6971e25ab:/opt/fhem# ping 192.168.178.16
PING 192.168.178.16 (192.168.178.16): 56 data bytes
64 bytes from 192.168.178.16: icmp_seq=0 ttl=64 time=3,238 ms

root@30a6971e25ab:/opt/fhem# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway.docker. 0.0.0.0         UG    0      0        0 eth0
172.27.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1

Gruss
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 30 Dezember 2019, 13:22:00
Hallo zusammen,
hier kommt noch ein Update meiner Experimente.

Ich habe es nun mit zwei Netzwerkdefinitionen versucht. Im Container finde ich auch beide.
Nun klappt wieder der Zugriff ueber das docker Netzwerk mit den Ports auf Portainer und Fhem.

Nur klappt es jetzt wieder nicht mit dem upd auf meinen SMAEM :-(


Bevor du hier weitermachst ... was genau willst du erreichen? Warum die ganzen Netzwerkdefinitionen? Funktioniert es im Standard, also Default bridge-mode? Ich würde erstmal alles mit Standardnetz aufbauen. Wenn das funktioniert kannst dich an das Splitten der Netzwerke machen. Aktuell weißt du nicht wo der Fehler zu suchen ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 30 Dezember 2019, 14:51:35
Bevor du hier weitermachst ... was genau willst du erreichen? Warum die ganzen Netzwerkdefinitionen? Funktioniert es im Standard, also Default bridge-mode? Ich würde erstmal alles mit Standardnetz aufbauen. Wenn das funktioniert kannst dich an das Splitten der Netzwerke machen. Aktuell weißt du nicht wo der Fehler zu suchen ist.

Hallo kadettilac.

Meine Ziele im groben:
- Die bestehende fhem Installation auf den rpi4 uebertragen
- Mich in Docker einarbeiten :-)
- Die Flexibilitaet von Docker nutzen
- fhem mit mysql und dblog erweitern
- Das Strom Logging ins dblog ueberfuehren
- Diagramme mit graffana erstellen weil svg den Beduerfnissen nicht mehr standhaelt


Im Standardnetz laeuft alles mit der Ausnahme der udp Verbindung zum SMAEM. Durch Volker habe ich gelernt, dass die udp Verbindung nur laeuft, wenn der Fhem Container direkt im Hausnetz mit dem macvlan device betrieben wird https://forum.fhem.de/index.php/topic,51569.msg1006062.html#msg1006062 (https://forum.fhem.de/index.php/topic,51569.msg1006062.html#msg1006062)

1. Ich hatte Portainer, mysql und fhem mit docker am laufen. Portainer wurde ueber Port 9000 , fhem mit Port 8083 und der Ip Adresse der rpi4 erreicht. Das lief dann ueber die docker Netzwerkebene mit der Port Freigabe.

2. Ich hatte dann als ersten Test nur den fhem Container mit dem macvlan und einer festen IP Adresse definiert und bekam dann die udp Verbindung zum SMAEM. Leider konnte ich dann fhem nicht mehr  ueber http auf Port 8083 erreichen.

3. Der aktuelle Test ist nun mit den zwei Netwerkdefinitionen. Nun kann ich wieder ueber die Docker Netzwerkverbindung Fhem und Portainer erreichen. Im Fhem Container ist das Hausnetz ebenfalls direkt aktiv. Am Router kann ich einmal die IP der rpi4 sehen und auch die zweite IP aus dem fhem Container.
Meine Vermutung ist nun, dass der Port 9522 und die mcast Adresse 239.12.255.254 fuer die Kommunikation mit dem SMAEM nicht ueber die zweite Netzwerk Konfiguration aus dem fhem Container laeuft.

Ich bin fuer jeden Vorschlag oder auch jede Aenderung im docker-compose offen. Was kann ich testen oder aendern?

Viele Gruesse
     Christian

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 30 Dezember 2019, 15:28:38
irgendwie schaffe ich es nicht den node.js package im fhem container zu aktualiseren.

Error code E500   
Summary:
Parsing error - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 277 (before "sh: 2: npm: Permissi...") at ./FHEM/42_npmjs.pm line 1160.
Detail:
{
"versions":
{"http_parser":"2.8.0","node":"10.17.0","v8":"6.8.275.32-node.54","uv":"1.28.0","zlib":"1.2.11","brotli":"1.0.7","ares":"1.15.0","modules":"64","nghttp2":"1.39.2","napi":"5","openssl":"1.1.1d","icu":"64.2","unicode":"12.1","cldr":"35.1","tz":"2019a"}
, "outdated": sh: 2: npm: Permission denied
}


Offenbar hat sich in neueren Versionen des npm Kommandos der Aufruf von "npm outdated" geändert bzw. kann dieser wohl nur noch als root ausgeführt werden.
Ich checke ein Update für 42_npmjs ein, welches dies behebt und stelle ein aktualisiertes Docker Image bereit.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 30 Dezember 2019, 15:44:18
Mir ist aufgefallen, dass die letzten Commits in beiden Branches auf Github schon eine Zeit her sind und das Repo auf Travis als inactive markeirt wurde.


Das ist nicht beabsichtigt und etwas unerklärlich. Die einzige Erklärung, die mir dazu einfällt ist, dass viele andere Entwickler inzwischen ebenfalls mit Travis CI und dem FHEM Team auf Github (also alles unter https://github.com/fhem) experimentieren. Sie haben damit auch Zugriff auf die Travis Instanzen für fhem-docker und dabei hat sich wahrscheinlich jemand vertan. Anders kann ich mir das nicht erklären.


Ich schaue gerade den Build zu fixen.


Übrigens, die Motivation dazu ist gestern auch wieder etwas gestiegen, weil ich tatsächlich die ersten 10€ meines Lebens dafür gespendet bekommen habe  8)  (neben der Zeit, die ich seit Monaten erst jetzt zwischen den Feiertagen einmal finde).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 30 Dezember 2019, 16:01:03
Ich bin fuer jeden Vorschlag oder auch jede Aenderung im docker-compose offen. Was kann ich testen oder aendern?

Wenn ich dich richtig verstehe geht es hier um Multicast ... du schreibst auch dass dein Netz nicht nach außen geroutet ist. Teste mal die Container im Host-modus zu betreiben wenn du mit dem host-modus leben kannst,. Wenn das funktioniert brauchst du keine zusätzlichen Netzwerke im Docker. Ansonsten warten ob hier jemand was beitragen kann, ansonsten google ... es ist eine spezielle Anforderung.

    network_mode: host
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 30 Dezember 2019, 16:38:40
Hallo kadettilac.

Als workaround ist das erst mal okay. Das verhaelt sich dann jetzt so als ob alles native installiert waere, zumindest was das Netzwerk an geht.
Ich habe nun alle drei Docker Container mit  "network_mode: host" definiert und auch die Port Eintraege entfernt.

Das SMAEM Modul findet nun den SMAEM wieder und ich kann mit der IP Adresse des rpi4 und der entsprechenden Port Nummer die einzelnen Anwendungen in den Containern erreichen.

An einer etwas eleganteren Loesung waere ich jedoch weiterhin interessiert, da ich ja auch noch was dazu lernen moechte :-)
Jetzt kann ich zumindest schon mal an den anderen Baustellen weiter machen.

Viele Gruesse
     Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: synci am 30 Dezember 2019, 18:20:20
Kann mir jemand verraten wie ich es schaffe das unter /etc/sudoers.d/ ein File erhalten bleibt nach zB. einem Docker Image Update ?
Hab es ehrlich gesagt nicht verstanden mit den Entry Points etc. :-(

Vielen Dank !
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 30 Dezember 2019, 19:33:59
Kann mir jemand verraten wie ich es schaffe das unter /etc/sudoers.d/ ein File erhalten bleibt nach zB. einem Docker Image Update ?
Hab es ehrlich gesagt nicht verstanden mit den Entry Points etc. :-(

Vielen Dank !
Versuche es mit Volumes. Die Datei /sudoers/own_sudo liegt auf dem Host und wird dann nicht überschrieben. Das Verzeichnis und die Datei muss existieren bevor du den Container neu erzeugen lässt sonst wird ein Verzeichnis "own_sudo" erstellt.

Ob das bei sudo-Files funktioniert musst du testen ... wegen Berechtigungen könnte es sein, dass es dann nicht greift.

        volumes:
            - ./fhem:/opt/fhem
            - ./sudoers/own_sudo:/etc/sudoers.d/own_sudo
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: synci am 31 Dezember 2019, 00:41:53
Geniale Idee :-)

Funktioniert bestens, hatte zuerst "own_sudo" immer im FHEM Verzeichnis abgelegt, dort werden jedoch die Berechtigungen immer überschrieben. :-X
Dann funktioniert das ganze nicht wie Du schon vermutet hast.
Nun liegt das File auf meinem Host eine Ebene weiter vorne und behält die Berechtigungen "root/root".

Vielen lieben Dank !!!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 31 Dezember 2019, 08:47:25
Moin,

ich habe da auch noch eine Anfaenger Frage in die gleiche Richtung.
Wie kann ich nachinstallierte python Pakete erhalten, oder diese jeweils neu nachinstallieren?

Gruss
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 31 Dezember 2019, 11:47:21
Moin,

ich habe da auch noch eine Anfaenger Frage in die gleiche Richtung.
Wie kann ich nachinstallierte python Pakete erhalten, oder diese jeweils neu nachinstallieren?

Gruss
   Christian

https://github.com/fhem/fhem-docker#add-custom-packages
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 31 Dezember 2019, 11:54:08
Scharm und Schande ueber mich.
Entschuldigt bitte das Ueberlesen, es ist glaube ich zuviel Aenderung auf einmal....

gilt das auch fuer pip3 packages?

-e PIP_PKGS="package1 package2"

Gruss
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 31 Dezember 2019, 12:13:52
Scharm und Schande ueber mich.
Entschuldigt bitte das Ueberlesen, es ist glaube ich zuviel Aenderung auf einmal....

gilt das auch fuer pip3 packages?

-e PIP_PKGS="package1 package2"

Gruss
   Christian

Im Dockerfile wird mit python3 gearbeitet, ich gehe davon habe es aber nicht im Einsatz ... einfach mal testen?

# Add Python app layer
RUN if [ "${PIP_PKGS}" != "" ] || [ "${IMAGE_LAYER_PYTHON}" != "0" ] || [ "${IMAGE_LAYER_PYTHON_EXT}" != "0" ]; then \
      LC_ALL=C DEBIAN_FRONTEND=noninteractive apt-get update \
      && LC_ALL=C DEBIAN_FRONTEND=noninteractive apt-get install -qqy --no-install-recommends \
          libinline-python-perl \
          python3 \
          python3-dev \
          python3-pip \
          python3-setuptools \
          python3-wheel \
      && if [ "${PIP_PKGS}" != "" ]; then \
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 31 Dezember 2019, 12:52:07
gilt das auch fuer pip3 packages?


Es gilt sogar nur für Python3 Pakete; Python2 ist deprecated, siehe den 2020 Countdown hier :D
https://pythonclock.org/ (https://pythonclock.org/)


Der Korrektheit halber, dies ist der entsprechende Sprungpunkt im Quellcode, nicht der oben zitierte ;-)
https://github.com/fhem/fhem-docker/blob/d43317cc1647baa585f52cec9e9451ed4fc5490d/src/entry.sh#L111-L127
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 31 Dezember 2019, 16:07:21
Super, danke es klappt.

Und nochmals vielen Dank fuer Eure unermuedliche Hilfe.

Viele Gruesse und einen guten Rutsch ins neue Jahr
       Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 02 Januar 2020, 11:58:16
Weil es gerade in einem Kommentar an anderer Stelle auftauchte:


Eine Homebridge Integration im FHEM Docker Image gibt es bereits. Sie ist auf die bisher von André noch nicht offiziell veröffentlichte Version 2 des Siri Moduls ausgelegt:
https://forum.fhem.de/index.php/topic,97447.0.html (https://forum.fhem.de/index.php/topic,97447.0.html)


Derzeit muss man das Modul selbst aus dem Forum laden und installieren. Ich weiß leider nicht, wann/ob André plant das Modul einzuchecken. Vermutlich ist das auch aufgrund der ganzen Entwicklungen im letzten Jahr eher zu einem Moving Target geworden. Am besten einmal darüber im anderen Thread (siehe Link oben) philosophieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: justme1968 am 02 Januar 2020, 12:44:39
das problem ist: ich hatte noch keine gute idee wie ich so einfach wie möglich und rückwärtskompatibel den autostart mit mehreren config files bzw. homebridge instanzen verbinden kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Lanhydrock am 02 Januar 2020, 13:51:48
Hallo Julian,

vielen Dank für das tolle Angebot! Installation klappt auf Anhieb und ohne Probleme...

@auch an weitere Mitleser:
Hat zufällig jemand den Docker mit Homebridge auf einem macOS Gerät laufen?

Wir haben Homebridge mit den Docker Tools (https://docs.docker.com/docker-for-mac/docker-toolbox/) zum Laufen gebracht, nicht jedoch - wegen bekannter (https://forums.docker.com/t/should-docker-run-net-host-work/14215/8) Einschränkung (https://docs.docker.com/docker-for-mac/networking/) - mit der aktuellen Docker Desktop für Mac Version.
Unter VirtualBox konnte man mit Sebastians genialem Script (https://raw.githubusercontent.com/blueimp/shell-scripts/df2eaf79ad7935bfb4b6d5834895d4912d6df4ea/bin/docker-machine-bridge.sh) einen neuen Bridged Adapter erstellen, der dann die Container im lokalen Netz verfügbar gemacht und somit den Discovery von Homebridge ermöglicht hat. Leider hatten wir aber bei dieser Variante dann Probleme mit den Rechten bei der Erstellung des Shared Folders für /opt/fhem.

Danke im voraus für Rückmeldungen.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: hoppel118 am 02 Januar 2020, 20:17:32
das problem ist: ich hatte noch keine gute idee wie ich so einfach wie möglich und rückwärtskompatibel den autostart mit mehreren config files bzw. homebridge instanzen verbinden kann.

Hi, ich bin ja einer derjenigen, der mehrere Homebridge Instanzen in Verwendung hat. Seit der Diskussion in dem Siri v2 Thread habe ich hier im Forum in verschiedenen Threads mal etwas genauer darauf geachtet. Es gibt hier einige User, die mehrere Homebridge Instanzen betreiben. Immer mal wieder liest man das. Ich bin damit kein Exot.

Mir stellt sich gerade die Frage, ob man dir das Leben irgendwie einfacher machen könnte, um eine Rückwärtskompatibilität zumindest unter gewissen Voraussetzungen gewährleisten zu können?

Bin momentan noch knapp 2 Wochen im Urlaub. Kann/will an meiner Umgebung während dieser Zeit aber nichts testen. Danach bin ich aber für alles offen. ;)

Können das gern in dem Siri Thread weiter diskutieren.

Gruß Hoppel

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Init am 03 Januar 2020, 10:24:30
Hallo zusammen,

ich habe letzte Tage angefangen mich mit Docker zu beschäftigen und würde gerne mein FHEM auf mein QNAP-NAS als Docker Container umziehen.

Hierzu habe ich folgende docker-compose.yml erzeugt:

version: '2'

services:
    fhem:
        restart: always
        ports:
            - "8083:8083"
            - "7072:7072"
        image: fhem/fhem:latest
        volumes:
            - /share/CE_CACHEDEV1_DATA/Docker/Fhem/volumes/core/:/opt/fhem/
        networks:
            - fhem-network7
        mac_address: AA:F8:5F:95:84:11
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
            IMAGE_LAYER_DEV: 1
            CPAN_PKGS: "Frontier::Client MIME::Lite Net::SMTP::SSL MIME::Base64"
networks:
    fhem-network7:
        driver: qnet
        ipam:
          driver: qnet
          options:
            iface: "bond0"

Wenn jetzt der Container fertig erzeugt ist, erhalte ich in FHEM beim Ausführen eines einen subs folgende Meldung:
Can't locate Frontier/Client.pm in @INC (you may need to install the Frontier::Client module) (@INC contains: /opt/fhem ./FHEM/lib ./lib . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base ./FHEM) at ./FHEM/99_myUtils.pm line 12.
BEGIN failed--compilation aborted at ./FHEM/99_myUtils.pm line 12.

Im Environment hatte ich aber die benötigten CPAN_PKGS hinzugefügt.

Kann mir jemand auf die Sprünge helfen, was ich ggf. falsch mache?

VG
Marc
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 03 Januar 2020, 11:26:18
Wa steht denn im Docker Log für diesen Container?
Gibt es innerhalb des Containers die Datei /pkgs.cpan ? Was steht drin?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Init am 03 Januar 2020, 11:31:44
Hier der Inhalt von / aber leider kein /pkgs.cpan

drwxr-xr-x   2 root root 4096 Nov  9  2018 bin
drwxr-xr-x   2 root root 4096 Jun 26  2018 boot
drwxr-xr-x   5 root root  340 Jan  3 10:37 dev
-rwxr-xr-x   2 root root 7100 Nov  9  2018 entry.sh
drwxr-xr-x   1 root root 4096 Jan  3 10:37 etc
-rwxr-xr-x   2 root root 1897 Nov  9  2018 health-check.sh
drwxr-xr-x   2 root root 4096 Jun 26  2018 home
-rw-r--r--   9 root root 1376 Nov  9  2018 image_info
-rw-r--r--   1 root root    0 Jan  3 10:37 image_info.EMPTY
drwxr-xr-x   9 root root 4096 Nov  9  2018 lib
drwxr-xr-x   2 root root 4096 Nov  9  2018 lib64
drwxr-xr-x   2 root root 4096 Oct 11  2018 media
drwxr-xr-x   2 root root 4096 Oct 11  2018 mnt
drwxr-xr-x   3 root root 4096 Nov  9  2018 opt
dr-xr-xr-x 525 root root    0 Jan  3 10:37 proc
drwx------   2 root root 4096 Nov  9  2018 root
drwxr-xr-x   3 root root 4096 Nov  9  2018 run
drwxr-xr-x   2 root root 4096 Nov  9  2018 sbin
drwxr-xr-x   2 root root 4096 Oct 11  2018 srv
dr-xr-xr-x  12 root root    0 Jan  2 17:27 sys
drwxrwxrwt   2 root root 4096 Nov  9  2018 tmp
drwxr-xr-x  10 root root 4096 Nov  9  2018 usr
drwxr-xr-x   1 root root 4096 Nov  9  2018 var

Wie komme ich an das Docker log? Sorry für dieses Basics  :-(
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 03 Januar 2020, 11:49:32
Am einfachsten geht das über Portainer (https://www.portainer.io/), alternativ so (https://docs.docker.com/config/containers/logging/).


Meine Vermutung: Du hast den Container schonmal gestartet gehabt und erst danach CPAN_PKGS gesetzt. Das funktioniert nicht, die Pakete werden nur einmalig beim allerersten Start eines frischen Containers installiert. Du musst also den Container neu erstellen. Das passiert eigentlich automatisch, wenn du was an deinem docker-compose File änderst, aber natürlich musst du dafür trotzdem docker-compose erneut aufrufen. Der Container ändert sich nicht von alleine ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 03 Januar 2020, 11:55:14
Übrigens: Die Variable IMAGE_LAYER_DEV für einen Container zu setzen macht überhaupt keinen Sinn. Diese Variablen sind ausschließlich für die Nerds, die unbedingt ihr eigenes Image bauen und auf bestimmte Layer verzichten wollen. Sie werden nur während eines "docker build" im Dockerfile ausgewertet, niemals mehr zur Laufzeit.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Init am 03 Januar 2020, 12:03:20
Also den Container hatte ich komplett frisch über die Oberfläche von QNAP angelegt und hatte das File von ober genutzt.

Im Log steht folgendes:
Zitat
[~] # docker logs 8237a06fb000
Preparing initial start:
1. Updating existing FHEM installation in /opt/fhem
2. Updating fhem.cfg for Docker container compatibility
Preparing user environment ...



Preparing configuration ...
Starting FHEM ...

Den alten Container habe ich mal jetzt gelöscht und einen neuen angelegt:
Zitat
[/share/CE_CACHEDEV1_DATA/Docker/fhemtest] # docker-compose up
Creating network "fhemtest_fhem-network9" with driver "qnet"
Creating fhemtest_fhem9_1 ... done
Attaching to fhemtest_fhem9_1
fhem9_1  | Preparing initial start:
fhem9_1  | 1. Updating existing FHEM installation in /opt/fhem
fhem9_1  | 2. Updating fhem.cfg for Docker container compatibility
fhem9_1  | Preparing user environment ...
fhem9_1  |
fhem9_1  |
fhem9_1  |
fhem9_1  | Preparing configuration ...
fhem9_1  | Starting FHEM ...

Aber auch hier finde ich die Datei nicht
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 03 Januar 2020, 13:33:11
Sieht so aus als wenn die Umgebungsvariable nicht richtig gesetzt worden wäre. Ich kenne mich mit der QNAP Umgebung nicht aus und kann daher keine weitere Hilfe geben, warum das so ist. Wenn die Umgebungsvariable ordentlich gesetzt ist, dann funktioniert es auch - gerade nochmal getestet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 03 Januar 2020, 17:40:09
Hallo zusammen, frohes neues Jahr! .. und danke für die tolle Arbeit.

Läuft bei mir auf einer Synology wunderbar ..
Vermisse allerdings /usr/bin/mail (oder einen anderen Mail-client), um es mit msg zu nutzen. Oder nehmt ihr da etwas anderes?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 03 Januar 2020, 18:16:41
Ohne einen lokal im Container laufenden Mailserver nutzt dir /usr/bin/mail nichts.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 Januar 2020, 18:26:02
Hallo zusammen, frohes neues Jahr! .. und danke für die tolle Arbeit.

Läuft bei mir auf einer Synology wunderbar ..
Vermisse allerdings /usr/bin/mail (oder einen anderen Mail-client), um es mit msg zu nutzen. Oder nehmt ihr da etwas anderes?

ich kenne msg nicht. Willst du mails versenden? ... das hier funktioniert, hab ich im Einsatz. https://wiki.fhem.de/wiki/E-Mail_senden#Raspberry_Pi

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 03 Januar 2020, 19:21:11
Ohne einen lokal im Container laufenden Mailserver nutzt dir /usr/bin/mail nichts.

Ich kenne Mail als Client nicht so gut, nail kann mit beliebigen externen Mailservern arbeiten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Init am 03 Januar 2020, 20:31:51
Sieht so aus als wenn die Umgebungsvariable nicht richtig gesetzt worden wäre. Ich kenne mich mit der QNAP Umgebung nicht aus und kann daher keine weitere Hilfe geben, warum das so ist. Wenn die Umgebungsvariable ordentlich gesetzt ist, dann funktioniert es auch - gerade nochmal getestet.

Ich habe das Problem gefunden. 2018 hatte ich schonmal getestet und danach den Container wieder gelöscht.
Beim jetzigen Test hat Docker das alte Image wieder verwendet und daher funktionierten die schönen neuen Funktionen nicht.

Nach dem Löschen funktioniert nun alles  :)

BTW: Gibt es für mich ein Möglichkeit in FHEM zu sehen, ob es ein neues Image gibt? Und könnte ich das dann einfach austauschen oder so?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 04 Januar 2020, 15:34:10
Crypt::Rijndael_PP als pure Perl Implementierung (--> "_PP" am Ende) scheint mir recht neu zu sein und ist mir bisher nicht als Abhängigkeit aufgefallen. Hier ist zu hoffen, dass die Installation nicht lange dauert. Ich schaue mal, ob das Image so noch baut. Es kann aber jederzeit sein, dass das Modul nicht mehr baut und es sich nicht beheben lässt. In dem Fall wird es dann wieder aus dem Image verschwinden - entweder ganz oder zumindest für die ARM Plattformen. Daher ist der langfristige Rat, dass du dich von deiner ARM Abhängigkeit löst.

Edit: Neues PROD Image mit Crypt::Rijndael_PP (auch für ARM) baut gerade.

Ich habe ebenfalls ein XiaomiDevice und möchte Crypt::Rijndael_PP installieren. Mir ist leider nicht klar, was das EDIT oben bedeutet. Ich habe bereits CPAN_PKGS="Crypt::Rijndael_PP" und CPAN_PKGS="Crypt::Cipher::AES" mit APT_PKGS="libcryptx-perl libcrypt-cbc-perl" probiert, jedoch scheint mir CPAN_PKGS irgendwie nicht korrekt ausgewertet zu werden. Per 'docker exec bash' kann ich im Container das Package per 'cpan Crypt::Rijndael_PP' manuell nachinstallieren, CPAN_PKGS macht irgendwie keinen Unterschied.

Was mache ich falsch bzw. wie bekomme ich das fhem-Modul XiaomiDevice in docker zum laufen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 05 Januar 2020, 11:24:43
Wie man das debugt habe ich wenige Posts vorher gerade erst erklärt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 05 Januar 2020, 13:38:42
.. mal eine Frage, wie ihr das Logging handhabt beim Docker-Image. Ich möchte auf einen USb-Stick loggen.

symbolische Links sind ja so eine Dache in Docker. Ich habe ein Verzeichnis auf dem USb-Stick erstellt und das unter dem gleichen Namen gemountet in Docker. Dann in FHEM das "logdir" auf dieses Verzeichnis eingestellt. Das klappt soweit ganz gut, nur wenn ich innerhalb von FHEM das Logfile ausgeben will, dann kommt in der Weboberfläche ein 404-Fehler. das scheint aber ein fhem-Problem zu sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 05 Januar 2020, 15:51:28
Warum nicht einfach den USB Stick vom Docker Host als Volume nach /opt/fhem/log mounten?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 06 Januar 2020, 09:00:13
oder so ... danke.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ManOki am 06 Januar 2020, 10:47:18
Wie man das debugt habe ich wenige Posts vorher gerade erst erklärt.

Bezieht sich das auf meine Frage bzgl. CPAN_PKGS="Crypt::Rijndael_PP"?

Ich habe die Container mittels docker-compose up erstellt. Beim beenden werden die Container gelöscht und anschließend neu erstellt, daher gehe ich davon aus, dass auch jedes Mal die Container-Option CPAN_PKGS neu ausgewertet wird, richtig?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eddso am 06 Januar 2020, 18:38:59
Frage: benutze seit längerem FHEM im Docker, zuletzt das aktuelle Image geladen. Hatte aber immer das Problem dass nach ca. paar Stunden der Container sich irgendwie festfrisst das man ihn nicht mehr stoppen oder in ihn reinwechseln kann. Fhem funktioniert aber weiterhin monatelang normal ohne sichtbare Probleme. Das einzige was funktioniert Neustart der Hardware. Kann man irgendwie rausfinden wo fhem/container hängt?
Gruß Eduard
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 06 Januar 2020, 18:58:52
Hast du was im log stehen wenn du neu startest? Siehst du was wenn du mit "docker logs fhem" die Container logs ausgibst? Hast du andere Container die parallel problemlos laufen? Weles Setup für docker?

Gesendet von meinem SM-G960F mit Tapatalk

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eddso am 06 Januar 2020, 19:37:10
Hi, ja.
Es läuft portainer und docker-compose mit fhem, mosquitto, mysql, zigbee2mqtt, nginx.
CONTAINER ID        IMAGE                                                  COMMAND                  CREATED             STATUS                      PORTS                                                                                            NAMES
59e2c5398603        fhem/fhem-arm32v7_linux:5.9-s20490_v2.2.1-3-gae19137   "/entry.sh start"        2 days ago          Up 44 hours (unhealthy)     0.0.0.0:3002->3002/tcp, 0.0.0.0:4196->4196/tcp, 0.0.0.0:7072->7072/tcp, 0.0.0.0:8083->8083/tcp   sda1_fhem_1
81c4944beac1        koenkk/zigbee2mqtt:1.8.0                               "./run.sh"               2 days ago          Up 21 hours                                                                                                                  sda1_zigbee2mqtt_1
cac0c16b2191        arm32v6/nginx:alpine                                   "nginx -g 'daemon of…"   2 days ago          Up 2 days                   0.0.0.0:80->80/tcp                                                                               sda1_proxy_1
29556f5f23c0        arm32v6/eclipse-mosquitto                              "/docker-entrypoint.…"   2 days ago          Up 2 days                   0.0.0.0:1883->1883/tcp                                                                           sda1_mqtt_1
103de4de61e6        hypriot/rpi-mysql                                      "/entrypoint.sh mysq…"   2 days ago          Up 2 days                   0.0.0.0:3306->3306/tcp                                                                           sda1_mysql_1
871a12f340b2        portainer/portainer:arm                                "/portainer"             11 months ago       Up 2 days                   0.0.0.0:9000->9000/tcp     
Alle container lassen sich einzeln starten, stoppen, restarten, hineinchangen mit bash (alles über portainer). Der fhem container lässt sich aber nicht stoppen,restarten,hineinchangen, alles läuft auf ein timeout ob über docker, portainer oder docker-compose. fhem funktioniert dabei wie er soll, logs sind unauffälig.
Hab grade in Syslog geschaut, Docker macht tatsächlich alle halbe stunde error log:
Jan 05 11:39:31 bananapi dockerd[1226]: time="2020-01-05T11:39:31.931471941+01:00" level=warning msg="Health check for container 59e2c539860339716b9746cb8b087b516a997d67ae0a82b97c2abb165dd7142a error: context deadline exceeded: unknown"Gruß Eduard
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 Januar 2020, 19:56:59
Fehlendes Telnet Device. Readme lesen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eddso am 06 Januar 2020, 21:15:27
Hi,
telnet device war schon immer da, also ist es was anderes:
Internals:
   CONNECTS   5407
   DEF        7072
   FD         7
   FUUID      5c604f40-f33f-c059-dbb7-e892a5f5697b861a
   NAME       telnetPort
   NR         17
   PORT       7072
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2020-01-05 17:13:08   state           Initialized
Attributes:
   DbLogExclude .*
   room       System
Gruß Eduard
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 Januar 2020, 21:16:56
Da es anders wo keine Probleme gibt, handelt es sich wohl um ein lokales Problem.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 06 Januar 2020, 21:31:42
Hi,
telnet device war schon immer da, also ist es was anderes:


was bedeutet "immer". Vor Docker?

Ist Telnet passwortgeschützt? Hast du es mit einem "allowed" abgesichert ... wenn ja, Verweis wie von Loredo, Doku auf Github.

Ansonsten, ist das Problem auch wenn du die Demo-Config startest ... wie das geht auch in der Doku auf Github.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eddso am 07 Januar 2020, 09:14:48
Hi,
-Telnet ist nicht abgesichert.
-For Docker? Docker beinhaltet Fhem und ich meine auch default das telnet device, kann mich nicht erinnern es angelegt zu haben, ist aber auch jahre her.
-Das System ist ein sauberes Armbian. Nichts extra installiert da Armbian Docker hat. System auf dem neuestem stand update/upgrade.
-Das Problem bestand seit Anfang an auch mit älteren docker-ce Versionen und älteren fhem images. Mich hats nicht gestört da ich den Container so gut wie nie restarte.
-Ich vermute ja das beim beenden von fhem.pl was klemmt, irgend ein Modul. Obwohl Dan müsste ich trotzdem in den Container reingehen können mit bash.
- Probiere bei Gelegenheit ein sauberen fhem Container zu starten parallel.
Gruß Eduard
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 07 Januar 2020, 12:58:39
Nimm doch einfach das "offizielle" Docker Image und gut ist (ich schließe aus deinem Beitrag, dass du das nicht hast).

Dann kann man dir aich bei Problemen hier sicher besser helfen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 07 Januar 2020, 14:28:43
Nimm doch einfach das "offizielle" Docker Image und gut ist (ich schließe aus deinem Beitrag, dass du das nicht hast).

Dann kann man dir aich bei Problemen hier sicher besser helfen.

er hat doch fhem/fhem-arm32v7_linux ... das ist das offizielle, Banaan PI hat ein armv7
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 09 Januar 2020, 16:58:20
sorry, dachte, weil er schreibt "seit Jahren", dass er etwas anderes nutzt.

PS: falls jemand an einem Mailversand aus dem Docker interessiert ist über nail.
Habe das Paket s-nail über APT mit installieren lassen. Die zugehörige Konfigurationsdatei /etc/s-nail.rc habe ich dann als Volume definiert, so dass sie persistent und editierbar wird von außen.
Dann kann man den Befehl msg (siehe hier: https://forum.fhem.de/index.php/topic,39983.msg322257.html#msg322257)
nutzen, in dem man in msgConfig das Mailprogramm auf /usr/bin/s-nail ändert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 11 Januar 2020, 18:25:47
Hi,

mir ist aufgefallen dass ich im Container kein Alias für gateway.docker.internal + host.docker.internal in /etc/hosts habe.

Wenn ich /entry.sh ausführe erhalte ich diese Ausgabe

1. Creating group 'fhem' with GID 6061 ...
2. Enforcing GID for group 'bluetooth' to 6001 ...
3. Creating user 'fhem' with UID 6061 ...
4. Creating log directory /opt/fhem/./log ...
5. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...
6. Enforcing file and directory permissions for /opt/fhem ...
7. Correcting group ownership for /dev/tty* ...
8. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
10. Updating /etc/sudoers.d/fhem-docker ...
/entry.sh: line 414: [: too many arguments
/entry.sh: line 421: [: too many arguments
11. Pre-authorizing SSH to Docker host for user 'fhem' ...
12. Updating SSH key pinning and SSH client permissions for user 'fhem' ...

ab Zeile 414 wird gateway.docker.intern
ab Zeile 421 wird host.docker.intern   angelegt.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 11 Januar 2020, 21:02:31
Ich hab seit ein paar Tagen wieder das Problem, dass ich mein FHEM nicht updaten kann:

2020.01.11 20:48:39.929 1 : Downloading https://fhem.de/fhemupdate/controls_fhem.txt
2020.01.11 20:48:43.938 1 : https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: connect: timeout

Hab es schon versucht mit und ohne IPv6 Einstellung in der docker-compose... Hatte das Problem vor Weihnachten ja schon einmal und da ging es dann irgendwann 1x wieder. Ich hatte damals die Module manuell geupdated und danach ging es. Dachte das hätte was mit dem manuellen Update zu tun, aber dieser "Trick" funktioniert nun auch nicht mehr. War damals wohl nur Zufall...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 12 Januar 2020, 00:17:35
Ggf hat auch der FHEM Server IPv6 Connectivity Probleme. Gab is IIRC schon.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 13 Januar 2020, 20:51:05
Gestern gings mal wieder und heute wieder nicht. Langsam vermute ich, dass ich irgendwelche andere Probleme habe. Z.B. ist ein anderes Problem, dass Pushpullet messages mal raus gehen und mal nicht. Ich hab mal in portainer unter "Events" nach möglichen Ursachen gesucht. Dort steht nur folgendes drin:

2020-01-13 20:39:30 container Exec instance started
2020-01-13 20:39:30 container Exec instance created
2020-01-13 20:39:20 container Unsupported event
2020-01-13 20:39:19 container Exec instance started
2020-01-13 20:39:19 container Exec instance created
2020-01-13 20:39:10 container Unsupported event
2020-01-13 20:39:09 container Exec instance started
2020-01-13 20:39:09 container Exec instance created
2020-01-13 20:38:49 container Unsupported event
2020-01-13 20:38:49 container Unsupported event
2020-01-13 20:38:49 container Exec instance started
2020-01-13 20:38:49 container Exec instance created
2020-01-13 20:38:48 container Exec instance started
2020-01-13 20:38:48 container Exec instance created
2020-01-13 20:38:29 container Unsupported event
2020-01-13 20:38:28 container Exec instance started
2020-01-13 20:38:28 container Exec instance created
2020-01-13 20:38:18 container Unsupported event
2020-01-13 20:38:18 container Exec instance started
2020-01-13 20:38:18 container Exec instance created
2020-01-13 20:38:08 container Unsupported event
2020-01-13 20:38:07 container Exec instance started
2020-01-13 20:38:07 container Exec instance created
2020-01-13 20:37:48 container Unsupported event
2020-01-13 20:37:47 container Exec instance started
2020-01-13 20:37:47 container Exec instance created
2020-01-13 20:37:47 container Unsupported event
2020-01-13 20:37:46 container Exec instance started
2020-01-13 20:37:46 container Exec instance created
2020-01-13 20:37:26 container Unsupported event
2020-01-13 20:37:25 container Exec instance started
2020-01-13 20:37:25 container Exec instance created
2020-01-13 20:37:17 container Unsupported event

Ist das normal??? Oder habe ich irgendein Problem?? Und wenn ich ein Problem habe: wie kommt man dahinter was den "unsupported event" auslöst??

Sorry, ich bin in Sachen docker absoluter Anfänger! :(
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 13 Januar 2020, 21:04:35
Normal ist das denke ich nicht. Liegt wahrscheinlich an deiner Host Installation/Konstellation. Helfen kann ich da nichts.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 Januar 2020, 21:56:26
War das jetzt "normales docker" oder Synology?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 13 Januar 2020, 22:07:17
War das jetzt "normales docker" oder Synology?

Ist die Frage an mich? Bei mir ist es normales Docker (denke ich). Ich hab einen Intel NUC mit Ubuntu 18.04 Server. Da hab ich docker während der Installation von Ubuntu mit installiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 Januar 2020, 22:11:02
Du hast merere Probleme ... könntest Du einen eigenen Thread aufmachen?

habe Probleme bei solchen "Sammelthread"

Deine Probleme sofern erkannt:
1. Update (eventuell IPv6 Problem)
2. Pushpullet messages
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 14 Januar 2020, 05:33:52
Ja ich verstehe schon dass das vielleicht verwirrend oder sogar störend ist wenn es um Einzelfälle in einem Sammelthread geht... Und scheinbar bin ich wohl der einzige mit solchen Problemen.
Für mich hatte es immer hier her gepasst, weil ich die Probleme von der konventionellen fhem Installation nicht kenne und ich deshalb auf ein Problem mit dem ganzen Thema docker geschlossen hatte. Ich versuche weiter zu analysieren und ggf meinen eigenen Thread zu eröffnen...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 14 Januar 2020, 09:29:28
Ich habe auf meinem Raspi jetzt das v8-Kernel aktiviert. In der Konsequenz zieht er sich nicht mehr das arm/v7, sondern das arm/v5 Image. Hat irgendjemand noch diesen Effekt und eine Idee das zu fixen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 14 Januar 2020, 10:39:18
Ich habe auf meinem Raspi jetzt das v8-Kernel aktiviert. In der Konsequenz zieht er sich nicht mehr das arm/v7, sondern das arm/v5 Image. Hat irgendjemand noch diesen Effekt und eine Idee das zu fixen?
nutzt du docker "docker pull fhem/fhem" oder explizit v7 "docker pull fhem/fhem-arm32v7_linux". Vielleicht funktioniert der zweite pull ... aber wahrscheinlich kommt die Meldung dass du die falsche Architektur hast.

ansonsten schau mal ob du mit "dpkg-architecture" was setzen kannst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 16 Januar 2020, 07:57:44
nutzt du docker "docker pull fhem/fhem" oder explizit v7 "docker pull fhem/fhem-arm32v7_linux". Vielleicht funktioniert der zweite pull ... aber wahrscheinlich kommt die Meldung dass du die falsche Architektur hast.

ansonsten schau mal ob du mit "dpkg-architecture" was setzen kannst.
Ich werde mal am Wochenende den direkten Aufruf testen. Anscheinend gibt es ein generelles Docker-Problem durch das 32bit Userland.

https://github.com/docker/distribution/issues/3008
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 16 Januar 2020, 18:02:53
Danke, auf die von Dir beschriebene direkte Zugriffsweise bekomme ich sowohl das v7 als auch das v8 Image gepulled.
Dann werde ich mal ein bisschen v8 im 32bit Userland testen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 18 Januar 2020, 06:58:15
Das Problem mit Multiarch ist, dass Docker sich jetzt als Architektur mit linux/arm/v8 meldet. Da Docker selbst für Raspbian nicht als 64Bit existiert, reicht er anscheinend auch kein arm64 durch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: persching am 18 Januar 2020, 11:08:05
Gestern gings mal wieder und heute wieder nicht. Langsam vermute ich, dass ich irgendwelche andere Probleme habe. Z.B. ist ein anderes Problem, dass Pushpullet messages mal raus gehen und mal nicht. Ich hab mal in portainer unter "Events" nach möglichen Ursachen gesucht. Dort steht nur folgendes drin:

2020-01-13 20:39:30 container Exec instance started
2020-01-13 20:39:30 container Exec instance created
2020-01-13 20:39:20 container Unsupported event
2020-01-13 20:39:19 container Exec instance started
2020-01-13 20:39:19 container Exec instance created
2020-01-13 20:39:10 container Unsupported event
2020-01-13 20:39:09 container Exec instance started
2020-01-13 20:39:09 container Exec instance created
2020-01-13 20:38:49 container Unsupported event
2020-01-13 20:38:49 container Unsupported event
2020-01-13 20:38:49 container Exec instance started
2020-01-13 20:38:49 container Exec instance created
2020-01-13 20:38:48 container Exec instance started
2020-01-13 20:38:48 container Exec instance created
2020-01-13 20:38:29 container Unsupported event
2020-01-13 20:38:28 container Exec instance started
2020-01-13 20:38:28 container Exec instance created
2020-01-13 20:38:18 container Unsupported event
2020-01-13 20:38:18 container Exec instance started
2020-01-13 20:38:18 container Exec instance created
2020-01-13 20:38:08 container Unsupported event
2020-01-13 20:38:07 container Exec instance started
2020-01-13 20:38:07 container Exec instance created
2020-01-13 20:37:48 container Unsupported event
2020-01-13 20:37:47 container Exec instance started
2020-01-13 20:37:47 container Exec instance created
2020-01-13 20:37:47 container Unsupported event
2020-01-13 20:37:46 container Exec instance started
2020-01-13 20:37:46 container Exec instance created
2020-01-13 20:37:26 container Unsupported event
2020-01-13 20:37:25 container Exec instance started
2020-01-13 20:37:25 container Exec instance created
2020-01-13 20:37:17 container Unsupported event

Ist das normal??? Oder habe ich irgendein Problem?? Und wenn ich ein Problem habe: wie kommt man dahinter was den "unsupported event" auslöst??

Sorry, ich bin in Sachen docker absoluter Anfänger! :(

Kurzes Feedback, vielleicht hat jemand ja irgendwann ähnliche Probleme:

Das oben genannte Problem ist wohl vom HealthCheck und wird in der neuesten Version von Portainer so angezeigt:
https://github.com/portainer/portainer/issues/2717 (https://github.com/portainer/portainer/issues/2717)

und meine restlichen Probleme haben sich erledigt nachdem ich ein docker-compose stop
docker system prune -a
docker-compose up -d
ausgeführt habe. Sprich, einmal alles neu installieren. Seit dem kein Probleme mit dem update oder pushbullet...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MCh76 am 23 Januar 2020, 20:19:23
hallo zusammen,

mit großem interesse habe ich mich die tage in die docker thematik eingelesen und bin fest entschlossen mein aktuelles FHEM system, welches aktuell auf einem raspberry 3b+ läuft umzuziehen.
um die mühsam aufgebaute und aktuell zum glück stabil laufende produktive smarthome umgebung nicht negativ zu beeinflussen habe ich mir nen neuen raspi 3b+ zugelegt und hab die grundlegenden dinge vorgenommen wie raspbian buster image drauf, docker und docker-compose installiert. das passt alles soweit.

auf dem produktiven system laufen FHEM, pivccu für HmIP über aufgestecktem HM-MOD-RPI-PCB, Homematic über im netz (WEMOS) befindlichen HM-MOD-UART/HMUARTLGW, homebridge, mysql, VCCU über zudem ist noch ein SignalDuino am raspi.
meine idee war, das produktive FHEM mal per volume in die neue docker welt zu bringen und dann stück für stück schauen was noch zu tun ist um alles zum laufen zu bringen.

gestern dann der erste versuch mit dem ersten container gemäß der anleitung https://github.com/fhem/fhem-docker. Ergebnis: fhem im auslieferungszustand des docker images war auf der IP des neuen raspberry erreichbar (port 8030). alles okay. nun habe ich heute mein produktiv backup vom sonntag (FHEM-20200119_234500.tar.gz file) ins home/pi des neuen raspi kopiert und von dort ins verzeichnis /opt/fhem entpackt, auch problemlos.

nun zu meinen fragen:

1) der Befehl docker run -d --name fhem -p 8083:8083 -v /opt/fhem:/opt/fhem fhem/fhem hat zwar keinen fehler geliefert, aber fhem ließ sich über die IP die gestern mit dem nackten fhem noch funktioniert hatte nicht aufrufen. ist das ein thema der berechtigungen? ich sehe dass das verzeichnis /opt/fhem nun dem user "6061" gehört, was lt. dem thread verlauf hier aber standard sein soll. oder muss ich hier mit den environment variablen "-e FHEM_UID=fhem" und "-e FHEM_GID=dialout" arbeiten damit sich die produktiv-kopie von /opt/fhem mit der docker variante versteht?
oder falls nicht, was könnte ich noch tun bzw. wo ansetzen um den fehler zu finden?

oder macht der gesamte umzug ggf. mehr sinn indem ich gerät für gerät einzeln in die docker welt umziehe ohne das volume der produktiven FHEM installation?

2.) was wäre die empfehlung für die piVCCU? sollte ich die auf dem alten raspberry belassen oder gibt es eine möglichkeit diese auch auf dem neuen raspi zu installieren und von dort aus der docker version von fhem anzusprechen. habe hierzu im netz keine erfahrungswerte finden können.

vielen lieben dank für etwas input.
vg,
chris
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 24 Januar 2020, 12:52:21
Die user/Gruppe 6061 ist richtig, das ist der User/gruppe, die vom Docker-Image vorgesehen ist. Schau mal, ob der User alle Dateien im Verzeichnis hat, eventuel ein chown durchführen.

Ich habe auch umgestellt, allerdings nur die fhem.cfg und die *.cfg-dateien übernommen, nicht den ganzen opt-Bereich. Warum nicht ganz neu starten, damit man ein sauberes System hat? Mein System läuft -nachdem ich so umgezogen bin- deutlich stabiler.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 Januar 2020, 15:50:18
Ich würde sagen sowohl das Docker Log (https://docs.docker.com/engine/reference/commandline/logs/) und auch die FHEM Logdatei sind die ersten Anlaufpunkte das weiter zu analysieren.
Ersteres geht prima über portainer.io (https://www.portainer.io/).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 24 Januar 2020, 20:27:20
Erstmal Vielen Dank für den Container und die Pflege des Image.

Ich habe immer mal wieder das Phänomen, dass der Container bei einem shutdown restart in FHEM
Nicht wieder richtig hoch kommt. Ich sehe dann in portainer die Fehlermeldung, dass der Port bereits in Benutzung ist.
Sobald ich den Container über portainer Neustart läuft es sofort wieder. Dennoch: lässt sich das umgehen?


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 24 Januar 2020, 20:36:50
Bei “shutdown restart” ist das wohl kein Docker spezifisches Problem, sondern ein Problem mit einem FHEM Modul, dessen Subprozess nicht richtig beendet wird.

Versuch mal das normale “shutdown”, der Container startet per Default auch dann FHEM neu.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 24 Januar 2020, 20:41:50
Okay, das würde dazu passen, dass es ab und an auch mal funktioniert.

Ich teste mal mit einfachen shutdown - danke.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 24 Januar 2020, 20:49:18
Mal probieren, ob es hilft, wenn der Container im run ein —init bekommt bzw. in compose einen Eintrag init: true. Das aktiviert tini und verbessert den Umgang mit Zombie-Prozessen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: bgewehr am 25 Januar 2020, 13:39:20
Ich verzweifle an fronthem in meinem docker container.



Irgendein Tipp, was ich machen kann? Bin seit Tagen dran und mir fällt nix mehr ein...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 25 Januar 2020, 13:43:16
Erstmal mit net host zum laufen bringen, dann schauen, ob es im Subnetz läuft.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: bgewehr am 25 Januar 2020, 14:06:18
net host geht sofort. Einfach so lassen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 25 Januar 2020, 14:10:25
Vorteile des Subnetzes ergeben sich eigentlich nur, wenn Du mehrere Container mit Kommunikation untereinander laufen lässt und die Ports nach außen nicht freigibst. Solange du keine Portkollisionen mit dem Host hast, spricht nichts dagegen es so zu lassen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: bgewehr am 25 Januar 2020, 14:11:33
OK, dann scheint das am einfachsten zu sein, danke!!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ulli am 25 Januar 2020, 21:52:32
Servus,
Ich hab seit längeren mal wieder ein  update gemacht und jetzt startet fhem bzw das Image sehr langsam.
Im log finde ich folgende Fehler
/entry.sh: line 414: [: too many arguments,
/entry.sh: line 421: [: too many arguments,

Kann das daher kommen?

Vielen Dank im Voraus!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 Januar 2020, 13:56:28
Servus,
Ich hab seit längeren mal wieder ein  update gemacht und jetzt startet fhem bzw das Image sehr langsam.
Im log finde ich folgende Fehler
/entry.sh: line 414: [: too many arguments,
/entry.sh: line 421: [: too many arguments,

Kann das daher kommen?

Vielen Dank im Voraus!

Kann sein wenn er den Host anpingen will aber nicht findet ...

Hi,

mir ist aufgefallen dass ich im Container kein Alias für gateway.docker.internal + host.docker.internal in /etc/hosts habe.

Wenn ich /entry.sh ausführe erhalte ich diese Ausgabe

1. Creating group 'fhem' with GID 6061 ...
2. Enforcing GID for group 'bluetooth' to 6001 ...
3. Creating user 'fhem' with UID 6061 ...
4. Creating log directory /opt/fhem/./log ...
5. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...
6. Enforcing file and directory permissions for /opt/fhem ...
7. Correcting group ownership for /dev/tty* ...
8. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
10. Updating /etc/sudoers.d/fhem-docker ...
/entry.sh: line 414: [: too many arguments
/entry.sh: line 421: [: too many arguments
11. Pre-authorizing SSH to Docker host for user 'fhem' ...
12. Updating SSH key pinning and SSH client permissions for user 'fhem' ...

ab Zeile 414 wird gateway.docker.intern
ab Zeile 421 wird host.docker.intern   angelegt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wowogiengen am 27 Januar 2020, 08:54:16
Hallo,
ich habe vor, das Docker-Image für die synology Diskstation zu verwenden. Prinzipiell läuft die Installation bereits. Wie sieht es denn mit dem Einbinden des USB-Dongles für Homematic aus? Geht das auch so einfach wie beim raspy, oder muss ich da dann doch am Docker-Image rumfummeln?

Zum einen wüsste ich noch nicht, wie man das Docker-Image anpasst, und zum anderen geht das wohl bei der diskstation auch nicht so einfach...

Rein theoretisch könnte ich aber auch mit FHEM2FHEM die Hardware am raspy lassen und nur die Daten ins Docker-Image übertragen.


Viele Grüße
Wolfgang
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 Januar 2020, 12:44:32
Hallo,
ich habe vor, das Docker-Image für die synology Diskstation zu verwenden. Prinzipiell läuft die Installation bereits. Wie sieht es denn mit dem Einbinden des USB-Dongles für Homematic aus? Geht das auch so einfach wie beim raspy, oder muss ich da dann doch am Docker-Image rumfummeln?

Zum einen wüsste ich noch nicht, wie man das Docker-Image anpasst, und zum anderen geht das wohl bei der diskstation auch nicht so einfach...

Rein theoretisch könnte ich aber auch mit FHEM2FHEM die Hardware am raspy lassen und nur die Daten ins Docker-Image übertragen.


Viele Grüße
Wolfgang

Durchreichen von USB Geräten geht mit attribut "devices", s. u. ... wie das in der diskstation aussieht musst du nachsehen. Docker Image musst warhscheinlich nicht anpassen
        devices:
            - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A4010LPL-if00-port0:/dev/ttyUSB0"
            - "/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A7031TM7-if00-port0:/dev/ttyUSB1"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 27 Januar 2020, 12:46:23
Hallo,

die eingebauten System-Funktionen sind  ja klasse, funktionieren bei mir aber nicht (siehe Bild). Per Click geht da gar nichts. Gibt es dazu eine Beschreibung? habe nichts gefunde.
Danke!

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 Januar 2020, 14:24:59
die eingebauten System-Funktionen sind  ja klasse, funktionieren bei mir aber nicht (siehe Bild). Per Click geht da gar nichts. Gibt es dazu eine Beschreibung? habe nichts gefunde.
Danke!

dann bleiben dir folgende möglichkeiten
- container im privileged mode laufen lassen, dann hast alle devices ohne was durchschleifen zu müssen
- docker-compose auf dem host starten und nicht über gui
- container "portainer" anlegen und die weiteren container darüber einbinden / anlegen. ungeprüft, könnte aber funktioneren

das ganze fhem unabhängig. ggf. in synology foren nachschauen wie andere das machen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 27 Januar 2020, 14:46:48
dann bleiben dir folgende möglichkeiten
- container im privileged mode laufen lassen, dann hast alle devices ohne was durchschleifen zu müssen
- docker-compose auf dem host starten und nicht über gui
- container "portainer" anlegen und die weiteren container darüber einbinden / anlegen. ungeprüft, könnte aber funktioneren

das ganze fhem unabhängig. ggf. in synology foren nachschauen wie andere das machen

Hallo Kadettilac, der Container läuft im privileged-modus, da ich ein CUL seriell dran habe. Portainer läuft bei mir auch. Aber das ist nicht der Punkt: fhem läuft ja gut, aber eben nicht diese System-Devices zum Updaten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 Januar 2020, 16:21:09
Hallo Kadettilac, der Container läuft im privileged-modus, da ich ein CUL seriell dran habe. Portainer läuft bei mir auch. Aber das ist nicht der Punkt: fhem läuft ja gut, aber eben nicht diese System-Devices zum Updaten.
vergiss das, ich dachte das ist ein reply zu dem durchreichen der devices. hast du mal im device selber geschaut? da gibt es upgrade o. ä. in der set-auswahl oben. mache das per at regelmäßig, ist beim mir immer grün. vielleicht funktioniert nur der link im webcmd nicht

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 27 Januar 2020, 17:15:06
vergiss das, ich dachte das ist ein reply zu dem durchreichen der devices. hast du mal im device selber geschaut? da gibt es upgrade o. ä. in der set-auswahl oben. mache das per at regelmäßig, ist beim mir immer grün. vielleicht funktioniert nur der link im webcmd nicht
Danke, die entsprechenden Set-Befehle haben einwandfrei geklappt. Bei Webcmd war was offenbar nicht in Ordnung.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 Januar 2020, 17:52:28
Es kommt auf die Reihenfolge an. Ich denke das ist schwer mit Buttons abzubilden
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 27 Januar 2020, 18:44:58
die eingebauten System-Funktionen sind  ja klasse, funktionieren bei mir aber nicht (siehe Bild). Per Click geht da gar nichts. Gibt es dazu eine Beschreibung? habe nichts gefunde.


Keines dieser Module gehört zum Docker Image, auch wenn sie per Voreinstellung bei einem jungfräulichen System als Standard vordefiniert sind.
Für das npmjs Modul gab es jüngst ein Update in diese Richtung, ist dein System aktuell?


Das aptodate Modul scheint aktuell fehlerhaft in der Erkennung noch offener Updates zu sein. Dies könntest du an Cooltux als Autor melden.


Beim FHEM Installer sehe ich keinen Fehler in der Anzeige.


Dass dir bei 2 von 3 Devices das Web Icon fehlt liegt wohl daran, dass du die devStateIcon Attribute dafür einmal gelöscht hast oder du die Devices einmal manuell zu deiner FHEM Installation hinzugefügt hast (keine von ihnen wird bei bestehenden Installation durch die reine Nutzung von FHEM Docker dazugefügt; einzige Ausnahme ist eben DockerImageInfo).


Alle Update Module können übrigens nur richtig funktionieren, wenn von außerhalb des Containers seit dessen Erstellung keine Änderungen an Dateirechten o.ä. vorgenommen wurden. Der FHEM Container korrigiert nur die Dateirechte für /opt/fhem, nicht jedoch für Systemkomponenten oder Node.js Module.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 28 Januar 2020, 12:53:10
?? diese "System"-Module hatte ich automatisch, als ich das Docker-Image eingerichtet habe. Ich habe die nicht angelegt.

Ich habe an den Dateirechten nichts geändert. Nachdem die anzeigten, dass bei mir alles "outdatet" ist, ahbe ich die Webcmds betätigt. Danach war das dann so zerschossen wie es das Bild zeigt. Die Webcmds gingen dann auch nicht mehr. Nach einem manuellen Aufruf der Set-Befehle lief alles ordnungsgemäß durch.
Siehe hier:

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 28 Januar 2020, 17:16:59
@Loredo: Besteht eigentlich die Möglichkeit das sleep Intervall von

SLEEPINTERVAL=0.5 im Skript entry.sh in der loop zu erhöhen? Ich meine das überprüfen ob FHEM noch läuft. Ich habe mir den Container ein paar Tage angeschaut und stelle eine Grundlast fest, die u.a. auch vom entry.sh Skript erzeugt wird. Reichen nicht z.B. 5 Sekunden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 28 Januar 2020, 18:02:36
Das schöne an Containern ist ja, dass Du jede Datei von extern injecten kannst. Also modifiziere sie Dir doch und mounte sie als Volume an der richtigen Stelle.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 28 Januar 2020, 18:12:41
Das schöne an Containern ist ja, dass Du jede Datei von extern injecten kannst. Also modifiziere sie Dir doch und mounte sie als Volume an der richtigen Stelle.

Danke für den Tipp. Ich würde aber auch gerne verstehen, warum das Intervall zu kurz definiert ist. Vielleicht gibt es einen Grund, den ich gerade nicht sehe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MCh76 am 28 Januar 2020, 21:11:29
ich hab mal noch eine verständnisfrage.
in der docker-compose.yml, welche in meinem hostverzeichnis ~/dockerfiles lieg habe ich folgenden inhalt drin:
            - "./fhem_core/FHEM/99_myUtils.pm:/opt/fhem/FHEM/99_myUtils.pm"
            - "./fhem_core/:/opt/fhem/"
            - "./fhem_core/contrib/configDB/configDB.conf:/opt/fhem/configDB.conf"
            - "./fhem_core/db.conf:/opt/fhem/db.conf"

Ziel des Ganzen ist dass direkt beim ersten Erstellen des Containers die 99_myUtils.pm aus meinem hostverzeichnis /dockerfiles/fhem_core/FHEM in den container lädt.
was aber passiert ist, dass bei erzeugen des container das verzeichnis /opt/fhem/FHEM aus nichts anderem mehr besteht als aus meiner  99_myUtils.pm datei.
ich hatte erwartet dass sich der container die daten aus dem image: fhem/fhem:latest holt und bei einem volume zu einer einzelnen datei nur diese ergänzt.
scheinbar ein denkfehler.
wie macht man das denn am sinnvollsten? erst den container aus dem image einmal aufbauen lassen, dann stoppen und erst dann die persönlichen konfigurationen aus dem fhem backup in die mount verzeichnisse des hosts kopieren? dann erneut starten? oder gibt es einen eleganteren weg das direkt beim erstaufbau des containers aus der yml datei zu erreichen?
danke für eine kurze erklärung.
VG,
Chris
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 28 Januar 2020, 21:32:47
Was Du da tust, ist auch völlig unlogisch. Du kannst entweder /opt/fhem mounten oder einzelne Dateien darin, aber doch schlecht beides. [emoji2962]
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MCh76 am 28 Januar 2020, 21:51:51
Was Du da tust, ist auch völlig unlogisch. Du kannst entweder /opt/fhem mounten oder einzelne Dateien darin, aber doch schlecht beides. [emoji2962]

meine dann wohl etwas falsche idee war direkt beim erstmaligen erstellen des containers einzelne dateien aus der „alten“ fhem installation mitzugeben und den rest in opt/fhem aus dem docker hub image zu verwenden. ist wohl ein denkfehler. was wäre denn dann best practice? erst nachträglich die individuellen dateien in das mount verzeichnis reinzukopieren? sorry für die dumme frage aber es sind die ersten gehversuche im docker umfeld...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 29 Januar 2020, 00:35:48
Du kannst und sollst deine komplette FHEM Installation nach /opt/fhem mounten.
FHEM ist nicht dafür gemacht, um über den klassischen Container aktualisiert zu werden. Er dient stattdessen nur als standardisierte Laufzeitumgebung.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 29 Januar 2020, 00:59:45
Danke für den Tipp. Ich würde aber auch gerne verstehen, warum das Intervall zu kurz definiert ist. Vielleicht gibt es einen Grund, den ich gerade nicht sehe.

Der Grund ist die möglichst zeitnahe Logfile Ausgabe. Die ist derzeit nicht sehr effizient gelöst, weshalb auch tägliche statt wöchentliche oder monatliche Logfiles empfohlen werden.
Mir ist da bisher auch keine bessere Methode eingefallen, die zusammen mit den Anforderungen für das Start und Prozessmanagement von Docker funktionieren.

Das Interval zu vergrößern dürfte insofern nicht allzu viel ändern, weil die Last nicht von der Prüfung des laufenden Prozesses kommt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 29 Januar 2020, 05:50:19
Danke für die Info.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MCh76 am 29 Januar 2020, 07:12:28
Du kannst und sollst deine komplette FHEM Installation nach /opt/fhem mounten.
FHEM ist nicht dafür gemacht, um über den klassischen Container aktualisiert zu werden. Er dient stattdessen nur als standardisierte Laufzeitumgebung.

vielen dank! dann hatte ich guhu's vorschlag wohl missverstanden als er in antwort  #701 meinte:
Zitat
Ich habe auch umgestellt, allerdings nur die fhem.cfg und die *.cfg-dateien übernommen, nicht den ganzen opt-Bereich. Warum nicht ganz neu starten, damit man ein sauberes System hat? Mein System läuft -nachdem ich so umgezogen bin- deutlich stabiler.
vermutlich hat er den vorschlag so gemeinst erstmal mit dem blanken image zu beginnen und dann nach und nach die benötigten individuellen dateien nachträglich in das dann ja schon vorhandene /opf/fhem mountverzeichnis bzw. deren jeweiligen unterordner zu kopieren.
 
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 29 Januar 2020, 09:24:51
Ja das hast du, ist aber auch missverständlich :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 29 Januar 2020, 09:49:43
vielen dank! dann hatte ich guhu's vorschlag wohl missverstanden als er in antwort  #701 meinte:vermutlich hat er den vorschlag so gemeinst erstmal mit dem blanken image zu beginnen und dann nach und nach die benötigten individuellen dateien nachträglich in das dann ja schon vorhandene /opf/fhem mountverzeichnis bzw. deren jeweiligen unterordner zu kopieren.

Ja. Die Frage ist natürlich auch, wieviel externe Dateien Du da überhaupt noch brauchst. Bei mir sind es nur einige *.cfg-Dateien gewesen (Vitodens, Weekdaytimer, ..) das war's dann auch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MCh76 am 29 Januar 2020, 10:02:11
@loredo, guhu
vielen dank für eure erklärungen, dann ist mir jetzt der weg klar wie es weitergehen soll ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 30 Januar 2020, 18:26:07
Ich nutze bereits seit langer Zeit FHEM, Samba und eine FHEM-Sonos-Container in Docker.
Dies habe ich ähnlich wie hier beschrieben umgesetzt: https://forum.fhem.de/index.php?topic=89745.msg836848#msg836848

Neben dem normalem FHEM-Container (bridged) sind die anderen Container folgendermaßen konfiguriert:

    fhem_sonos:
        build: fhem_sonos
        cap_add:
            - SYS_ADMIN
            - NET_ADMIN
            - NET_RAW
        volumes:
             - ./opt/data/SonosSpeak:/opt/SonosSpeak
        network_mode: "host"


    samba:
        ports:
            - "139:139"
            - "445:445"
        image: dperson/samba
        volumes:
             - ./opt/data/SonosSpeak:/mnt/SonosSpeak
        command: samba.sh -S -u "fhem;pass" -s "SonosSpeak;/mnt/SonosSpeak;no;no;yes"  -g "security = user" -g "ntlm auth = yes"
        networks:
             bridge:
                ipv4_address: x.y.z.d


Das Sonos-Device hat folgende Pfad-Attribute:

   targetSpeakDir /opt/SonosSpeak
   targetSpeakFileHashCache 1
   targetSpeakFileTimestamp 0
   targetSpeakMP3FileDir /opt/SonosSpeak
   targetSpeakURL \\hostname\SonosSpeak


Eigentlich funktioniert alles. Aber leider nur gelegentlich.
Die Wiedergabe der Sprache über "set sonosplayer speak 10 de Test" hat eine enorme Verzögerung; wenn es denn überhaupt klappt.
Über die Google soll die MP3-Datei generiert werden. Die URL ist korrekt und wenn ich diese aus dem Docker-Log manuell aufrufe, so wird mir die Sprache auch abgespielt.
Aber es dauert teilweise viele Minuten bis die MP3-Datei im Samba-Share abgelegt wird. Der Player scheint aber nur eine begrenzte Zeit auf die Datei zu warten.

Im Docker-Log des Sonos-Container sehe ich folgende Zeilen:
21:27:16.847 Load Google generated MP§ (1. Element) from "http://translate.google.com...." to "/opt/SonosSpeak/RINCON_xxxx.mp31"
21:29:26.793 Combine loaded chunks into "/opt/SonosSpeak/RINCON_xxx.mp3"
21:29:26.851 Start temporary playing of "\\hostname\SonosSpeak/RINCON_xxx.mp3"

Wie man sieht, dauert es etwas über 2 Minuten bis die MP3 generiert/geholt/gespeichert wird.

Hat jemand dieses Problem auch?
Kennt jemand die Lösung oder einen Ansatz wo ich suchen muss?




Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Januar 2020, 18:30:27
Dauert das Manuelle holen auch so lange?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 30 Januar 2020, 18:31:12
Danke, dass du dich damit beschäftigst. Nein, der Aufruf über die URL spielt die Datei direkt ab.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Januar 2020, 18:42:21
Wenn Du manuell eine Datei ablegst ....

Irgendwo müssen die 2 Minuten herkommen. Also einfach mal manuell einen Schritt nach dem anderen und gucken, wo es hängt ..
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: steru85 am 30 Januar 2020, 20:27:24
Hallo zusammen,

ich steige gerade von einem Rasperry auf einen NUC mit Docker um. Das meiste läuft schon.
Habe aber das Problem das ich keine Verbindung zur Fritzbox über das Fritzboxmodul und den FB_Callmonitor hinbekomme.
Bekomme immer den Fehler "Didn't get a session ID".  Boxuser und Passwort habe ich gesetzt. Habe mal versuchshalber im Fritzboxmodul den Repeater im Mesh eingetragen, dieser funktioniert. Fritzbox ist eine 7490.
Auf dem Rasperry funktiontiert es tadelos.
Die IP der Fritzbox kann ich vom Docker aus erfolgreich anpingen.

Hatte jemand dasselbe Problem?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: FunkOdyssey am 31 Januar 2020, 16:25:32
Wenn Du manuell eine Datei ablegst ....

Irgendwo müssen die 2 Minuten herkommen. Also einfach mal manuell einen Schritt nach dem anderen und gucken, wo es hängt ..

Deine Hinweise haben mir geholfen. Danke.
Es hat nichts mit Docker zu tun. Egal in welchem Container oder sogar auf dem Host-System habe ich folgenden Ablauf:

wget --verbose -U Mozilla "http://translate.google.com/translate_tts?tl=de&client=tw-ob&q=%20Hallo" -O test2.mp3
--2020-01-30 22:07:02--  http://translate.google.com/translate_tts?tl=de&client=tw-ob&q=%20Hallo
Auflösen des Hostnamens translate.google.com (translate.google.com) … 2a00:1450:4005:803::200e, 172.217.19.78
Verbindungsaufbau zu translate.google.com (translate.google.com)|2a00:1450:4005:803::200e|:80 … fehlgeschlagen: Die Wartezeit für die Verbindung ist abgelaufen.
Verbindungsaufbau zu translate.google.com (translate.google.com)|172.217.19.78|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 2976 (2,9K) [audio/mpeg]
Wird in »test2.mp3« gespeichert.

test2.mp3                 100%[====================================>]   2,91K  --.-KB/s    in 0s     

2020-01-30 22:09:11 (28,3 MB/s) - »test2.mp3« gespeichert [2976/2976]

Mein Debian benötigt zwei Minuten zum Auflösen des IPv6-Hostnamens. Ich war mir nicht sicher, ob ich in Debian die IPv6-Unterstützung ausschalten soll oder im Router. Ich habe mich für den Router entschieden. Damit habe ich das Problem aber nur verschoben. Über IPv4 (oder vorher mit wget -4 getestet) funktioniert alles reibungslos.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mumpitzstuff am 31 Januar 2020, 16:40:32
Ich habe mich auch mal ein wenig mit Docker auseinandersetzen wollen und kämpfe mit dem Problem, das bereits die Tatsache das dockerd und containerd laufen, die SD Karte massiv belastet wird. Nicht ein einziger Container läuft wie gesagt. Trotzdem schreiben die beiden Prozesse mehrere Gigabyte pro Tag auf die SD Karte.
iostat macht das direkt sichtbar. Mit iotop sehe ich leider nur das dockerd und containerd irgendwas schreiben, hier wird als Menge aber immer nur 0 ausgegeben. Hat jemand eine Ahnung weshalb das so sein könnte bzw. wie ich rausbekommen kann, was dort genau geschrieben wird?

Aber 3-4 Gigabyte pro Tag, ohne das irgendwas an Containern gestartet ist, ist doch nicht wirklich normal bzw. gesund. Wenn ich beide Prozesse stoppe, ist übrigens sofort Ruhe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 31 Januar 2020, 19:41:37
Dürfte auch am Mageren Speicher vom PI liegen .. müsste mal meinen "PI-Docker-Cluster" rausholen. habe nur dieses WE keine zeit

@FunkOdyssey

Wenn Du kein IPv6 brauchst, ist es relativ einfach an einem unix-System abgeschaltet. Du hast jetzt "global" abgeschaltet, was ich für die Zukunft nicht tuen würde. Irgendwo bei Docker kann man IPv6-Support abschalten .. oder eben am System
https://www.thomas-krenn.com/de/wiki/IPv6_deaktivieren (https://www.thomas-krenn.com/de/wiki/IPv6_deaktivieren)


Zitat
Verbindungsaufbau zu translate.google.com (translate.google.com)|2a00:1450:4005:803::200e|:80 … fehlgeschlagen: Die Wartezeit für die Verbindung ist abgelaufen.
Nicht Du, google hat ein IPv6 Problem
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mumpitzstuff am 01 Februar 2020, 20:46:36
Ich habe gestern Docker mit allem was dazu gehört komplett deinstalliert und danach neu aufgesetzt. Container oder irgend was anderes habe ich nicht laufen lassen. Nach rund 8h wurden auf meine SD Karte 400-500MB geschrieben. Auf den Tag hochgerechnet wären das 1,2GB. Das wäre jetzt selbst für eine SSD nicht so toll. Hat dieses Verhalten noch jemand beobachten können (sieht man mit iostat)?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 10 Februar 2020, 12:21:43
Hat jemand einen Tipp für mich, wie man am besten eine Email aus dem Container verschickt?
Leider bietet das Image mein bisher genutztes SSMTP nicht an. Wie macht ihr das?
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 10 Februar 2020, 12:31:00
Hat jemand einen Tipp für mich, wie man am besten eine Email aus dem Container verschickt?
Leider bietet das Image mein bisher genutztes SSMTP nicht an. Wie macht ihr das?
Was heißt "bietet das Image nicht an"? Von Haus aus ist Mail Versand doch garnicht implementiert.

Ich mache das über sendEmail in einer Funktion in den 99_myutils. Ein Beispiel ist im Mail-Wikieintrag unter "Raspberry Pi" zu finden.
Das hat den Umzug nach docker ohne weiteres überlebt.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 10 Februar 2020, 13:41:59
Und ansonsten musst Du Dir eben das Paket über die Funktion des Images installieren lassen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 10 Februar 2020, 15:02:05
Danke euch das habe ich gesucht.

https://wiki.fhem.de/wiki/E-Mail_senden (https://wiki.fhem.de/wiki/E-Mail_senden)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fallenguru am 11 Februar 2020, 16:14:45
War mir nicht sicher, ob ich hier fragen soll, oder einen neuen Thread aufmachen. Hab's sicher versemmelt, sorry.

1. Die letzten Jahre hab ich Fhem nackt auf Debian (inzwischen) buster auf einem kleinen ARM-Board laufen, jetzt soll es gemeinsam mit ein paar anderen 24/7 "Infrastruktur"-Services auf einen Intel Mini-PC (auch buster) umziehen. Auf dem werd ich mich wohl oder übel sowieso mit Docker/VMs auseinandersetzen müssen -- isses dann gescheiter, Fhem auch gleich in der Docker-Variante zu betreiben? Sprich, ist das auf die Dauer tatsächlich pflegeleichter, auch wenn man noch keine Docker-Erfahrung hat, oder nur die neueste Sau, die durch's Dorf getrieben wird?

2. Ich hab nicht den ganzen Thread gelesen, aber gegen Ende tauchen ein paar Kommentare auf, die nahelegen, dass die Verwendung von Docker ein ziemliches Schreibaufkommen erzeugt ...?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 11 Februar 2020, 18:52:00
Zitat
Intel Mini-PC

Also betrifft Dich das nicht. Das Problem tritt beim Pi auf, da dort viel schreiben die SD-Card ruinieren kann. habe es hier bei meinem Test-Cluster aber nicht nachvollziehen können ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 11 Februar 2020, 20:47:54
Das mit der SD Karte und dem Schreibaufkommen ist sicherlich auch von der FHEM Config abhängig. Wenn du gnadenlos alles loggst und eine DB betreibst kann das schon sein.
Zu deiner Frage: nimm Docker - ich bin vor ein paar Tagen umgestiegen und finde es herrlich. Ich habe mal versucht ein paar Dinge im github festzuhalten. Vielleicht hilft es dir. Ist aber noch nicht fertig. Über Kommentare oder fragen würde ich mich freuen.

https://github.com/stormmurdoc/fhemdocker
 (https://github.com/stormmurdoc/fhemdocker)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fallenguru am 11 Februar 2020, 22:44:00
Ich [...]  kämpfe mit dem Problem, das bereits die Tatsache das dockerd und containerd laufen, [...] Nicht ein einziger Container läuft wie gesagt. Trotzdem schreiben die beiden Prozesse mehrere Gigabyte pro Tag auf die SD Karte.

Klingt nicht, als ob FHEM selbst der Übeltäter wär. Meine aktuelle Installation läuft seit vielen Jahren auf derselben SD. Loggt aus allen Rohren. Max ein paar MB/Tag.

Mehrere *GB*/Tag killen die günstige SSD in meinem neuen Mini aber auch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mumpitzstuff am 12 Februar 2020, 00:32:50
Probier es mal aus. Vielleicht bin ich ja ein Einzelfall und das Docker Zeug wird bei mir nicht richtig installiert. Du kannst es relativ schnell prüfen, indem du iostat aufrufst, den Wert notierst und ein paar Stunden später noch mal rein schaust. Sind’s nur ein paar MB, ist alles ok.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 Februar 2020, 08:05:45
Wir fahren (hier in der Firma) mittlerweile fast nur noch Docker-Server. Sogar "single Projekt Server" werden immer weiter auf docker migriert. Die ersten "nativ-Server Freunde" kamen letzten Woche und Fragten nach migration ...

also beruflich würde ich heute fast nur noch auf Docker gehen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: M.Schulze am 12 Februar 2020, 11:35:32
Wir fahren (hier in der Firma) mittlerweile fast nur noch Docker-Server. Sogar "single Projekt Server" werden immer weiter auf docker migriert. Die ersten "nativ-Server Freunde" kamen letzten Woche und Fragten nach migration ...

also beruflich würde ich heute fast nur noch auf Docker gehen ...


Das hört sich ja total altmodisch an. Schon mal was von Kubernetes gehört ?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 Februar 2020, 13:29:21
Preis/Leistung von Kubernetes ist hier nicht gegeben ... da dann doch mehr als "nur" Kubernetes ....

Und Dienstleister kosten auch ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 12 Februar 2020, 14:22:54
Was heißt "bietet das Image nicht an"? Von Haus aus ist Mail Versand doch garnicht implementiert.

Ich mache das über sendEmail in einer Funktion in den 99_myutils. Ein Beispiel ist im Mail-Wikieintrag unter "Raspberry Pi" zu finden.
Das hat den Umzug nach docker ohne weiteres überlebt.


Gesendet von iPhone mit Tapatalk

Ich hab's so gemacht: https://forum.fhem.de/index.php/topic,89745.msg1010980/topicseen.html#msg1010980
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: knueppler am 16 Februar 2020, 14:23:34
Hallo,
ich verwende das image schon sehr lange und bin sehr zufrieden damit.
Allerdings habe ich nun mal wieder alles geupdated und noch einen MQTT2_Client definiert um meinen Roborock einzubinden nun wird mein log wie folgt geflutet:
2020.02.16 14:06:01 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 172.17.0.1)Hat irgendjemand einen sachdienlichen Hinweis für mich, das wäre sehr lieb.

Danke, Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fallenguru am 16 Februar 2020, 15:51:09
Danke für Eure Antworten. Auf den ersten Blick kann ich kein exzessives Schreibvolumen feststellen, insofern wunderbar.

Leider schaut's so aus, als ob FHEM wieder auf bare metal, oder zumindest in einen Eigenbau-Container müsste, zumindest kann ich die Philosophie des Entwicklers nicht nachvollziehen. Um genauer zu sein, die Reaktion auf meinen bug report (https://github.com/fhem/fhem-docker/issues/24) haut mich ehrlich gesagt aus den Socken.
Ein bug report ist kein Ort für eine Diskussion, hier vielleicht schon. Mich würde schon interessieren, ob Ihr diesen Zugang (dem Admin dazwischenzupfuschen) in Ordnung findet. Keine Sorge, wenn kein Interesse besteht, geh ich einfach wieder und such mir eine andere Lösung, lieber wär mir, diese zu verbessern ;-)

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 16 Februar 2020, 16:42:35
Dann baue Dir Dein eigenes Docker Image ...

Mir ist z.B. für ein produktives System dieses Image auch zu groß. Liebe eher kleine Image ... und wenn man mehr braucht, kann man ein 2. Größeres machen, welches aber auf dem minimalem aufbaut. Auch dieses wurde abgelehnt ... trotzdem würde ich hier nicht auf den Entwickler "zeigen" ... jeder arbeitet anders ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 16 Februar 2020, 17:20:31
Danke für Eure Antworten. Auf den ersten Blick kann ich kein exzessives Schreibvolumen feststellen, insofern wunderbar.

Leider schaut's so aus, als ob FHEM wieder auf bare metal, oder zumindest in einen Eigenbau-Container müsste, zumindest kann ich die Philosophie des Entwicklers nicht nachvollziehen. Um genauer zu sein, die Reaktion auf meinen bug report (https://github.com/fhem/fhem-docker/issues/24) haut mich ehrlich gesagt aus den Socken.
Ein bug report ist kein Ort für eine Diskussion, hier vielleicht schon. Mich würde schon interessieren, ob Ihr diesen Zugang (dem Admin dazwischenzupfuschen) in Ordnung findet. Keine Sorge, wenn kein Interesse besteht, geh ich einfach wieder und such mir eine andere Lösung, lieber wär mir, diese zu verbessern ;-)
Ich bin kein Entwickler aber stelle mir beim lesen deines big report folgende Fragen:
- wie sollten Änderungen in FHEM (Geräte anlegen) möglich sein, wenn die fhem.cfg readonly wäre? Ich meine das wird ja in die config GESCHRIEBEN und dann gespeichert... dauerhafte Änderungen wären da ja nicht mehr möglich oder übersehe ich was?
- allgemein sind volumes doch dazu gedacht gewisse Daten persistent zu machen. Auch hier wäre meine Frage wie das gehen sollte, wenn ein Container nicht in ein Volume schreiben dürfte?

Dann baue Dir Dein eigenes Docker Image ...

Mir ist z.B. für ein produktives System dieses Image auch zu groß. Liebe eher kleine Image ... und wenn man mehr braucht, kann man ein 2. Größeres machen, welches aber auf dem minimalem aufbaut. Auch dieses wurde abgelehnt ... trotzdem würde ich hier nicht auf den Entwickler "zeigen" ... jeder arbeitet anders ...
Was bedeutet denn für dich "kleineres Image"? (Frage aus purem Interesse)
Generell schleppt FHEM ja auf Grund des fehlenden Managements für die Module ziemlich viel unnützes Zeug mit sich rum... ich kann mir jedenfalls nur schwer vorstellen, dass ein User auch nur die Hälfte aller Module wirklich im Einsatz hat.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 16 Februar 2020, 18:22:44
Genau das meinte ich mit "Klein", wenig Balast. Hat aber den Nachteil, das eben nicht alles gleich "outofthebox" funktionieren kann.

Bei anderen Projekten geht man deshalb mittlerweile anders vor:
Basis Image mit Basis-Funktionalität
- Erweitertes Image für Alexa
- Erweitertes Image für ....

Natürlich bauen die Erweiterten auf das Basis-Image auf.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 16 Februar 2020, 18:37:43
Aber an der Herangehensweise von FHEM einfach bei der Installation ALLE verfügbaren Module herunterladen und abzulegen, unabhängig davon ob diese jemals genutzt werden, änderst du doch mit einem Image nichts.
Das Image kleiner zu bekommen würde dann bedeuten in der FHEM installation herum zu fuhrwerken, oder?
Grundsätzlich fände ich ja gut nur die Module zu laden, die auch genutzt werden aber das müsste dann direkt in FHEM implementiert werden - unabhängig von Docker ja oder nein.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 17 Februar 2020, 00:02:21
Um genauer zu sein, die Reaktion auf meinen bug report haut mich ehrlich gesagt aus den Socken.
Ein bug report ist kein Ort für eine Diskussion, hier vielleicht schon. Mich würde schon interessieren, ob Ihr diesen Zugang (dem Admin dazwischenzupfuschen) in Ordnung findet.


Mir ist z.B. für ein produktives System dieses Image auch zu groß. Liebe eher kleine Image ... und wenn man mehr braucht, kann man ein 2. Größeres machen, welches aber auf dem minimalem aufbaut. Auch dieses wurde abgelehnt ...


Ich denke ich habe das schon mehrfach erklärt.


1. FHEM ist von seiner Systemarchitektur selbst kein guter Kandidat für ein klassisch-modernes Container Setup.
2. FHEM Module sind extrem divers in ihren Systemanforderungen und kaum durchschaubar. Die Systemabhängigkeiten herauszufinden ist oft sehr zeitaufwändig und für Anfänger oft eine unüberwindbare Hürde.
3. Der FHEM Installer (https://forum.fhem.de/index.php/topic,98381.0.html) zusammen mit dem Meta.pm Package (https://forum.fhem.de/index.php/topic,97589.0.html) sind beides Entwicklungen von mir, die (auch) darauf abziehlen, eine schlankere Systemumgebung zu ermöglichen bzw. eine Installation "On-Demand". Wem dies wichtig ist, der ist herzlich eingeladen dort aktiv mitzuwirken. Dies ermöglichte dann eine Verkleinerung des Images ohne Verlust des Komforts zur einfachen Nutzung der meisten FHEM Module.

Ergo: Wie schon richtig erkannt geht es hier nicht darum, dass Power Systemintegratoren ihre Wolllust befriedigt bekommen. Der Ansatz ist eher pragmatisch für die Mehrzahl der "normalen" Benutzer gewählt. Zu denen zählt ihr beide euch eben nicht. Das ist vollkommen okay, aber einsehen solltet ihr das eben auch ;-)

Als "Hintertür" gibt es für euch aber auch die Möglichkeit das Image selbst zu bauen. Das Dockerfile (https://github.com/fhem/fhem-docker/blob/8ecba2817b073bd0dcd24756e0776b7149327782/Dockerfile) ist in Layern aufgeteilt und sehr viele lassen sich zur Buildzeit übergehen, wenn man die Umgebungsvariablen (https://github.com/fhem/fhem-docker/blob/8ecba2817b073bd0dcd24756e0776b7149327782/Dockerfile#L18-L28) entsprechend setzt. Ich nehme an das ist für Kenner kein Problem dies zu tun.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 17 Februar 2020, 00:06:47
Bei anderen Projekten geht man deshalb mittlerweile anders vor:
Basis Image mit Basis-Funktionalität
- Erweitertes Image für Alexa
- Erweitertes Image für ....

Natürlich bauen die Erweiterten auf das Basis-Image auf.


Kann man alles machen, technisch kein Problem. Geht sogar fast schon mit dem aktuellen Dockerfile. Problem: Das CI/CD Setup dafür zu initialisieren und zu pflegen ist zeitlich sehr aufwändig und die kostenfreien Kapazitäten der Anbieter sind begrenzt. Wenn hier jemand Zeit investieren will - go for it, ich begleite das dann gerne. Ich kann da aber selbst derzeit keine zusätzlichen Ressourcen reinstecken.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 17 Februar 2020, 08:21:22
Ich habe versucht Dir zu sagen, das ich Deinen Ansatz verstehe und Dich deshalb NICHT kritisiere .. auch wenn ich es anders machen würde ;o)

Übrigens .. gerade wegen der zeitlichen Begrenzung wäre ein aufsplitten sinnvoll. Kann aber bezüglich docker-hub selber diesbezüglich nicht mitreden, da wir hier eine eigene Pipeline haben .. die ich nur leider "privat" nicht nutzen darf (schon nachgefragt).

Mit "Klein" meinte ich übrigens nicht fhem sondern "nur" die mitgelieferten Libarys ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sille am 17 Februar 2020, 13:07:47
Hat jemand  dash_dhcp mit dem offiziellen Docker Image zum Laufen gebracht?

Bei mir läuft fhem seit 2 Jahren im selbstgebauten Docker Image und ich wollte nun auf das offizielle umstellen.
Bei dash_dhcp habe ich das Problem, dass ich das Mapping nicht hin bekomme (im eigenen Container läuft es bestens)

Beim offizielle Image habe ich über den Parameter APT_PKGS die Pakete nachinstalliert: iptables iptables-persistent
Über das post-init.sh Script soll dann das Mapping erfolgen durch
iptables -I PREROUTING -t nat -i eth0 -p udp --src 0.0.0.0 --dport 67 -j DNAT --to 0.0.0.0:6767
Docker meckert auch nicht, arbeitet den Befehl ab. ifconfig spuckt eth0 aus.

Auch wenn ich es manuell direkt im Docker Container ausführe kommt kein Fehler.
In die /etc/iptables/rules.v4 habe ich den Eintrag
Zitat
-I PREROUTING -t nat -i eth0 -p udp --src 0.0.0.0 --dport 67 -j DNAT --to 0.0.0.0:6767
aufgenommen.

Trotzdem kommt als Fehler

Zitat
2020.02.17 12:46:32.709 2: dashButton: failed to open port 67 IO::Socket::INET: Permission denied
2020.02.17 12:47:02.711 2: dashButton: failed to open port 67 IO::Socket::INET: Permission denied
2020.02.17 12:47:32.713 2: dashButton: failed to open port 67 IO::Socket::INET: Permission denied

NET_ADMIN ist aktiviert, als Netzwerk nutze ich jeweils macvlan. Ich habe den Verdacht, dass das Routing auf udp fehlschlägt...

Ich bin für jeden Hinweis dankbar!
LG Sille
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 18 Februar 2020, 03:42:20
Deine Fehlermeldung ist doch wohl ziemlich klar. Dein Dash Button Modul versucht Port 67 zu öffnen und nicht Port 6767.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sille am 18 Februar 2020, 06:40:11
Das verstehe ich schon, dass versucht wird Port 67 zu öffnen. Das will ich ja auch, der Dashbutton ist ja so definiert. Ich benötige aber dazu ein udp Mapping von 67 auf 6767 und verstehe nicht, warum es in diesem Docker Container mit obigen Befehlen nicht klappt, in meinem selbstgebauten - auch Debian Buster - schon.
LG Sille

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 18 Februar 2020, 07:03:04
Wenn Dein fhem nicht unter Root läuft, steht dort sicher als Attribut auch Port 6767. dein iptables Eintrag macht ja überhaupt keinen Sinn, wenn Du doch versuchst auf Port 67 zu horchen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sille am 18 Februar 2020, 07:11:09
Richtig, root ist der Unterschied! Ich versuche heute Abend, den Container auch unter root laufen zu lassen und gucke, ob das Mapping dann klappt.
LG Sille
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schlimbo am 18 Februar 2020, 07:56:55
Nutze die Dash Buttons auch in Docker, habe einfach das Port Mapping in die docker-compose File aufgenommen:
 ports:
      - 67:6767/udp
Und schon geht's.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sille am 18 Februar 2020, 08:52:52
OK, das kann ich auch noch versuchen. So läuft auch mein eigener fhem Container, da ich über docker-compose noch weitere abhängige Container mitstarte. Momentan habe ich das offizielle Docker Image über Portainer eingerichtet und dort auch das Mapping eingetragen. Ich vermute aber eher, dass es an der root Rechten liegt. Werde es heute Abend ausprobieren und berichten.

Schlimbo, nutzt du das offizielle Docker Image für fhem oder hast du auch ein eigenes?

LG Sille
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 18 Februar 2020, 09:02:00
An den root-Rechten sollte es nicht liegen, da Docker Selber immer mit diesen Rechten läuft .. würde Dir das Mapping auch empfehlen! Egal ob mit docker-compose oder direkt bei Docker ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schlimbo am 18 Februar 2020, 12:36:29
Schlimbo, nutzt du das offizielle Docker Image für fhem oder hast du auch ein eigenes?

Nutze das offizielle FHEM Docker aus diesem Thread.
An den Rechten habe ich auch nichts geändert, läuft so Out of the box.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sille am 18 Februar 2020, 21:05:49
Irgendwie will es nicht so wie ich es will... Ich bin auch kein Netzwerkauskenner...

Der Container ist gestartet mit
ports:
      - 67:6767/udp

und mit dem Netzwerk macvlan
networks:
          macvlan0:
            ipv4_address: 192.168.1.104


Auf dem Host erkenne ich auf Port 67 den Dashbutton
sille@nuc:~/docker/fhem-official/install$ sudo tcpdump -nli eno1 udp port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
19:07:44.827942 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fc:a6:67:xx:ac:ba, length 261

Im Docker Container auch nur auf Port 67
root@fhem-official:/opt/fhem# tcpdump -nli eth0 udp port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:08:12.080633 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from fc:a6:67:xx:ac:ba, length 261

Dann wird 67 nicht auf 6767 gemappt...

Ich weiss nun, warum es im selbgebauten Dockercontainer läuft.... Dort ist das Netzwerk "host" und fhem läuft als "root". Der Dashbutton lauscht auf 67, was natürlich so klappt...

@Schlimbo, welches Netzwerk nutzt du?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 19 Februar 2020, 08:33:44
Was mir an Deinem Beitrag so auffällt ...
Zitat
Dort ist das Netzwerk "host"
Zitat
ports:
      - 67:6767/udp

- Lege mal den Port um, egal welches protokol (also udp weg)
- Warum vergiiebst Du eigentlich die Netzwerkadresse des Containers fest? und .. wie ist das Netzwerk überhaupt konfiguriert?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sille am 19 Februar 2020, 14:25:32
So es läuft nun. Ich habe auf dem Docker Host alles zurückgesetzt, auf dem Docker Container ebenfalls. Da muss von den vielen Versuchen irgendetwas schief gewesen sein...

Über APT_PKGS ist iptables zusätzlich installiert und in das pre-start.sh Script (vorher habe ich das post-init.sh benutzt) habe ich folgenden Befehl eingetragen:

iptables -I PREROUTING -t nat -i eth0 -p udp --src 0.0.0.0 --dport 67 -j DNAT --to 0.0.0.0:6767
Mein Netzwerk ist mit dem macvlan-driver erzeugt

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.254 \  (<=Fritzbox)
   -o parent=eno1 pub_net

und zusätzlich in den Netzwerkeinstellungen des Docker Hosts (/etc/network/interfaces):
auto eno1
iface eno1 inet manual

auto macvlan0

iface macvlan0 inet static
    address 192.168.1.99 (<=Dockerhost)
    network 192.168.1.0
    netmask 255.255.255.0
    broadcast 192.168.1.255
    gateway 192.168.1.254 (<=Fritzbox)
    dns-nameservers 192.168.1.254 (<=Fritzbox)
    pre-up ip link add link eno1 name macvlan0 type macvlan mode bridge

Das hat den Vorteil, dass jeder Docker Container eine eigene IP-Adresse bekommt und man über z.b. 8080 und die jeweilige IP-Adresse des Docker Containers zugreifen kann und nicht nur einmal pro Dockerhost.

Ich habe zur Zeit 12 Container, da waren einige Ports doppelt und ich war es leid, immer die Ports umzuleiten und mir diese zu merken....

LG Sille
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 19 Februar 2020, 14:51:00
Hi,
ich habe fhem mit host network laufen, um an einige devices zu kommen, die mit udp laufen. Da hatte ich mir hier bereits helfen lassen. Soweit ist alles prima.

Nun möchte ich für's logging eine DB in einem weitern Container betreiben mairidb oder mysql wäre mir sympatisch, da ich mit mysql schon mal etwas umgesetzt habe.

Welches docker image würde da am besten passen?

Ich habe einen RPI4 mit 4G Ram und nes 250 GB SSD mit Debian Buster.

Muss ich mit dem Netzwerk etwas beachten?
    Host Network? Wäre dann ja vom ganzen Netz erreichbar.
    Zusätzliches Network? Geht das im Docker zwischen fhem- und mysql Container wenn fhem bereits ein Host Netzwerk hat?

Eine kleine Starthilfe wäre mir lieb.

Viele Grüße
     Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 19 Februar 2020, 15:04:31
Ich habe es wie Matthias schon in seinem Github hochgeladen mit MySQL-Server gemacht. Braucht insgesammt nur 2 Layer, die MySQL-Docker-Hub braucht glaube ich ca 5 oder 6 Layer...

Oh, sorry, gerade  nochmal gelesen, das du ein RPI4 nutzt..

Hier kannst du das nachlesen, was er für Einstellungen in der Docker-Compose gesetzt hat , damit dies mit Docker super klappt ^^ (hab dir auf das Raspbian-Build verlinkt, Master ist für x64)
https://github.com/klein0r/fhem-docker/tree/raspbian (https://github.com/klein0r/fhem-docker/tree/raspbian)
Edit: er nutzt dafür das Build von hypriot/rpi-mysql
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 19 Februar 2020, 15:33:11
Ich habe es wie Matthias schon in seinem Github hochgeladen mit MySQL-Server gemacht. Braucht insgesammt nur 2 Layer, die MySQL-Docker-Hub braucht glaube ich ca 5 oder 6 Layer...

Oh, sorry, gerade  nochmal gelesen, das du ein RPI4 nutzt..

Hier kannst du das nachlesen, was er für Einstellungen in der Docker-Compose gesetzt hat , damit dies mit Docker super klappt ^^ (hab dir auf das Raspbian-Build verlinkt, Master ist für x64)
https://github.com/klein0r/fhem-docker/tree/raspbian (https://github.com/klein0r/fhem-docker/tree/raspbian)
Edit: er nutzt dafür das Build von hypriot/rpi-mysql
Ich schau es mir an, jedoch ist der letzte update auf hypriot/rpi-mysql 2 Jahre her.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MCh76 am 19 Februar 2020, 17:47:18
habe gerade meine FHEM umgebung auf docker umgestellt und für das db logging folgendes basis image verwendet:
https://hub.docker.com/r/webhippie/mariadb
Klappt einwandfrei
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 19 Februar 2020, 18:00:54
Hm, soweit so gut

DBI connect('database=fhem;host=<ip-adresse>;port=3306','fhemuser',...) failed: Access denied for user 'fhemuser'@'%' to database 'fhem' at ./FHEM/93_DbLog.pm line 2975.

mysql> select User,Host from mysql.user;
+----------+-------------+
| User     | Host        |
+----------+-------------+
| fhemuser | %           |
| root     | 127.0.0.1   |
| root     | ::1         |
| root     | localhost   |
| root     | raspberrypi |
+----------+-------------+
5 rows in set (0.00 sec)

mysql> set password for 'fhemuser'@'%' = password('geheim');
Query OK, 0 rows affected (0.01 sec)


root@raspberrypi:/# mysql -u fhemuser -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6541
Server version: 5.5.60-0+deb7u1 (Debian)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

mysql> connect fhem
ERROR 1044 (42000): Access denied for user 'fhemuser'@'%' to database 'fhem'
mysql>

ohne Passwort gehts
root@raspberrypi:/# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6853
Server version: 5.5.60-0+deb7u1 (Debian)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> connect fhem
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Connection id:    6855
Current database: fhem

mysql> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current        |
| history        |
+----------------+
2 rows in set (0.00 sec)

mysql>

Wo habe ich denn nun schon wieder einen Fehler gemacht? Dies hier war Teil des init.sql
mysql> CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'geheim';

mysql> select User,Host from mysql.user;
+----------+-------------+
| User     | Host        |
+----------+-------------+
| fhemuser | %           |
| root     | 127.0.0.1   |
| root     | ::1         |
| root     | localhost   |
| root     | raspberrypi |
+----------+-------------+
5 rows in set (0.00 sec)

mysql>


Im Hausnetz ist der Port 3306 auch schon aktiv
pi@raspberrypi:~/docker-compose/fhem_2020 $ nc -zv <ip-adresse> 3306
Connection to <ip-adresse> 3306 port [tcp/mysql] succeeded!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 19 Februar 2020, 18:10:11
Hast du fhemuser auch per Grant die Berechtigung zum Zugriff auf die Datenbank fhem ermöglicht?

sonst nutze die enviroment-Variablen ;-) meistens wird das gleich so fertig eingerichtet ^^
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 19 Februar 2020, 18:17:55
Hast du fhemuser auch per Grant die Berechtigung zum Zugriff auf die Datenbank fhem ermöglicht?

sonst nutze die enviroment-Variablen ;-) meistens wird das gleich so fertig eingerichtet ^^

Ich habe die init.sql verwendet und nur das passwort verändert. Einmal beim DB initialisieren und dann natürlich auch in der db.conf vom FHEM.
Die fhem Meldung sagt ja auch Access denied :-(
Ein grand ist auch in der init.sql

Ich habe den Grand nochmals ausgeführt und nun sieht's so aus als ob es okay ist.
mysql> GRANT CREATE ROUTINE, CREATE VIEW, ALTER, SHOW VIEW, CREATE, ALTER ROUTINE, EVENT, INSERT, SELECT, DELETE, TRIGGER, GRANT OPTION, REFERENCES, UPDATE, DROP, EXECUTE, LOCK TABLES, CREATE TEMPORARY TABLES, INDEX ON `fhem`.* TO 'fhemuser'@'%';
Query OK, 0 rows affected (0.00 sec)

Vielen Dank für den Schubser.
    Christian


EDIT:
Nun rauschen auch schon die ersten Eintrag in die db...

Im "userattr global" musste noch "DbLogExclude DbLogInclude DbLogValueFn:textField-long" rein und schon konnte man mit

attr .* DbLogExclude .*

für Ruhe sorgen. Danach kann man dann einzelne Einträge wieder frei geben, ohne das die DB sofort dicke Backen bekommt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 19 Februar 2020, 18:51:53
Sehr gut  :)

ich habe noch folgendes Notify am laufen:
define nDbLogExclude notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*
das Verhindert einfach, das immer, wenn ein Gerät definiert wird, erstmal automatisch DbLogExclude gesetzt wird. Dann kann man gezielt immer noch aktivieren, was man benötigt. Aber man muss sich keine Gedanken machen.
Alternativ kannst du natürlich DbLog nur auf include stellen ^^ aber, das hab ich halt einmal so eingerichtet..
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 19 Februar 2020, 18:55:50
Sehr gut  :)

ich habe noch folgendes Notify am laufen:
define nDbLogExclude notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*
das Verhindert einfach, das immer, wenn ein Gerät definiert wird, erstmal automatisch DbLogExclude gesetzt wird. Dann kann man gezielt immer noch aktivieren, was man benötigt. Aber man muss sich keine Gedanken machen.
Alternativ kannst du natürlich DbLog nur auf include stellen ^^ aber, das hab ich halt einmal so eingerichtet..
Okay, danke das notify habe ich auch bereits eingetragen. Nun schau ich mal wie ich die alten Daten gefiltert importieren kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 19 Februar 2020, 22:47:49
habe gerade meine FHEM umgebung auf docker umgestellt und für das db logging folgendes basis image verwendet:
https://hub.docker.com/r/webhippie/mariadb
Klappt einwandfrei
Warum nutzt Du nicht das official Image?

https://hub.docker.com/_/mariadb

Da ist Aktualität gewährleistet und auch ein Security Scan.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 19 Februar 2020, 23:06:09
Meine Aussage könnte jetzt falsch sein.
Ich meine gelesen zu haben, dass der Rpi4 noch mit 32 Bit Buster läuft. 64 Bit soll noch kommen.
Das Mariadb Image ist für arm64 und kann somit noch nicht laufen.
Wenn das falsch ist lösche ich den Eintrag gerne wieder.

Gesendet von meinem SM-G930F mit Tapatalk

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 19 Februar 2020, 23:12:40
Ja, du bist zumindest teilweise richtig. Du kannst auch den 64Bit-Kernel aktivieren, den Raspbian standardmäßig ausliefert.
Docker gibt es für Raspbian nur 32bit. Leider sind damit ein paar Hacks notwendig, um arm64 Images laufen zu lassen. Ich habe das bei mir am Laufen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 19 Februar 2020, 23:22:28
Ich denke das ist dann noch nichts für Anfänger. Mit etwas Geduld kommt sicher bald ein von Disk bootendes 64Bit mit Docker und dann geht's ab ;-)

Gesendet von meinem SM-G930F mit Tapatalk

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MCh76 am 20 Februar 2020, 07:42:18
Warum nutzt Du nicht das official Image?

https://hub.docker.com/_/mariadb

Da ist Aktualität gewährleistet und auch ein Security Scan.

weil ich auf einem Raspberry 3b+ bin und ich gelesen hatte dass das offizielle image hierfür nicht ausgelegt ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fallenguru am 26 Februar 2020, 15:32:39
- wie sollten Änderungen in FHEM (Geräte anlegen) möglich sein, wenn die fhem.cfg readonly wäre?

Gar nicht. Ich schreibe meine cfg mit der Hand, mit Unterstützung von ein paar scripts. Um an der laufenden Instanz etwas umzukonfigurieren, braucht's keine Schreibrechte, wenn sich was bewährt, kann man's ja übernehmen. Einfach cfg unter anderem Namen rausschreiben lassen, diffen, relevante Änderungen händisch in die schreibgeschützte einarbeiten. Das mach ich auch so, wenn neue Gerätetypen dazukommen, nach größeren Fhem-Updates ...
Die Änderung der (persistenten) Konfiguration in der Weboberfläche hat sich bei mir einfach nicht bewährt, zu oft haben mir gutgemeinte Automatismen und unachtsame Bedienung die komplette Konfiguration zerschossen.

- allgemein sind volumes doch dazu gedacht gewisse Daten persistent zu machen. Auch hier wäre meine Frage wie das gehen sollte, wenn ein Container nicht in ein Volume schreiben dürfte?

Das sind jetzt zwei verschiedene Dinge:
1. Schreibgeschützt habe ich nur die fhem.cfg, s. o., der Rest (updates, logs, ...) ist schreibbar.
2. Ein Container darf natürlich in seine volumes schreiben, aber eben nur in diese. Er darf keine Änderungen am Host-System vornehmen Zudem ist ein Unterschied zwischen "in eine volume schreiben" und "dort vorhandene Konfiguration in Bausch und Bogen überschreiben".

1. FHEM ist von seiner Systemarchitektur selbst kein guter Kandidat für ein klassisch-modernes Container Setup.
2. FHEM Module sind extrem divers in ihren Systemanforderungen und kaum durchschaubar. Die Systemabhängigkeiten herauszufinden ist oft sehr zeitaufwändig und für Anfänger oft eine unüberwindbare Hürde.
3. [...] Dies ermöglichte dann eine Verkleinerung des Images ohne Verlust des Komforts [...]

1. kann ich nicht nachvollziehen. Die Tatsache, dass sowieso schon alles in /opt/fhem sitzt und gut dokumentiert ist, sollte doch eher helfen.
2. kann ich nicht beurteilen. Selbst wenn dem so wäre, "eine saubere Lösung ist den dummen Usern nicht zumutbar" ist IMHO nie ein gutes Argument.
3. ist mir nicht so wichtig.

Ergo: Wie schon richtig erkannt geht es hier nicht darum, dass Power Systemintegratoren ihre Wolllust befriedigt bekommen. Der Ansatz ist eher pragmatisch für die Mehrzahl der "normalen" Benutzer gewählt. Zu denen zählt ihr beide euch eben nicht. Das ist vollkommen okay, aber einsehen solltet ihr das eben auch ;-)

Mein Problem liegt darin, dass ich mit (Docker-)Containern bestimmte Eigenschaften und Zielsetzungen verbinde, die Dein Projekt nicht aufweist, ja noch nicht einmal anstrebt. Erwartet habe ich eine Containerisierung, die es erlaubt, Fhem sauber neben einer Anzahl anderer Services auf einem Server laufen zu lassen, was vorliegt, ist quasi eine Art anfängerfreundlicher Installer, der zufällig unter der Haube Docker verwendet. Wenn das wem was bringt, wunderbar -- aber es ohne weiteres als Docker-Image, noch dazu als offizielles, zu präsentieren, finde ich irreführend.

Keine Frage, ich hätte den Source auf Github lesen können/sollen, aber ich dachte mir, was soll sein, es ist ja ein "offizielles" Docker-Image.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 26 Februar 2020, 15:38:03
Zitat
er darf keine Änderungen am Host-System vornehme
Sorry aber für Docker ist es irrelevant, ob Du ein Direktory einmountest oder ein Volumen ... Docker darf (und soll) dort schreiben.

So wie Du es übrigens beschreibst, solltest Du die config nicht reinmounten, sondern copy ....

Eigentlich ist Dein Vorgehen mit schreibgeschützter Config nicht nach FHEM-Doing aber funktioniert (komischerweise). Ist aber eher ein undokumentiertes "Feature". Es kann Dir also immer passieren, das auch ein normales FHEM das in Zukunft nicht mag .... ohne Ankündigung.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 26 Februar 2020, 16:00:57
Gar nicht. Ich schreibe meine cfg mit der Hand, mit Unterstützung von ein paar scripts.
Wenn das für dich funktioniert und du damit glücklich bist - wunderbar. Erwarte doch aber bitte nicht, dass hier etwas umgesetzt oder berücksichtigt wird, von dem an so ziemlich _jeder_ Stelle im FHEM-Forum abgeraten wird.
Das händische bearbeiten der cfg führt teilweise zur Verweigerung des Supports durch die Entwickler und Maintainer, weil es zu viele Pubkte gibt die dabei schiefgehen.

Zitat
Erwartet habe ich eine Containerisierung, die es erlaubt, Fhem sauber neben einer Anzahl anderer Services auf einem Server laufen zu lassen
Hier verstehe ich dein Problem nicht wirklich. Bei mir laufen aktuell 13 Container neben FHEM und ich hatte hier noch keinerlei Effekte auf die andere Container oder auf die Funktionen meines QNAP-Host.

Zitat
es ohne weiteres als Docker-Image, noch dazu als offizielles, zu präsentieren, finde ich irreführend.
Dieses Image wird von einem FHEM-Entwickler bereitgestellt und arbeitete nach den vorgesehenen Regeln für die Nutzung von FHEM. Ich weis nicht was du genau am wording auszusetzen hast aber für mich geht es nicht "offizieller".


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Reinschki am 01 März 2020, 16:22:13
Hallo, der Umzug auf das FHEM Docker Basis Image ist (fast) vollzogen.
Ich frage mich derzeit, wie ich die das hier https://haus-automatisierung.com/projekt/2019/02/26/projekt-amazon-polly-tts.html (https://haus-automatisierung.com/projekt/2019/02/26/projekt-amazon-polly-tts.html) im Container realisieren kann.

Bei der Installation werden einige Daten abgefragt.
Ich bin mit der Übergabe des AWS Polly Zugriffsschlüssel-ID sowie der weiteren Übergabe von Zugangsdaten bei der Ausführung von sudo aws configure im pre-init.sh script überfragt.
Kann man diese Installation im pre-init.sh durchführen?
Wie übergibt man die abgefragten Zugangsdaten.

Im Moment habe das auf dem Host installiert und mounte das Verzeichnis /usr/local/bin/aws in den Container. Das funktioniert, ist aber meiner Ansicht nach nicht gut im Sinne der Containerisierung!?

Kann mir jemand einen Tipp geben?

Schönen Sonntag noch!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: der-Lolo am 05 März 2020, 20:03:19
Mir geht es zur Zeit auch um die Scripts - ich würde gerne im post-start.sh die rote LED des Raspi4 ausschalten.
Das bedeutet ich muss ja vom Container aus den Schaltvorgang auslösen - hier gibt es die LED natürlich nicht...
Wie muss ich vorgehen um auf dem Host einen "root" Befehl auszuführen..?
Oder muss ich die LED in den Container mounten und dann mit einem notify auf INTIALIZED einen System aufruf starten..?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 05 März 2020, 21:00:00
Wie wenn es auf einem anderen Rechner ist .. also ssh ..
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: der-Lolo am 05 März 2020, 21:43:22
Hm, ich habe jetzt ein post-start.sh angelegt und das mit -v in Docker eingebunden

docker run -d --name PIV-FHEM -p 8083:8083 -v /opt/fhem:/opt/fhem -v /opt/config/post-start.sh:/post-start.sh fhem/fhem
Habe ich vielleicht hier schon einen Syntax-fehler..?

In /opt/config habe ich nun eine Datei post-start.sh angelegt - brauche ich hier noch ein ausführ Flag oder Berechtigungen für den Container..?

  GNU nano 3.2                                                         post-start.sh                                                                   

#!/bin/bash
ssh pi@host.docker.internal sudo echo 0 > /sys/class/leds/led1/brightness


sudo echo 0 > /sys/class/leds/led1/brightness funktioniert jedenfalls auf dem Raspi4 als user pi

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 06 März 2020, 00:17:35
Du kannst nicht in ein Filesystem schreiben, das du nicht als Volume im Container gemountet hast.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 März 2020, 08:37:40
zu oft haben mir gutgemeinte Automatismen und unachtsame Bedienung die komplette Konfiguration zerschossen.


Adding Git for version control of your Home Automation Docker containers (https://github.com/fhem/fhem-docker#adding-git-for-version-control-of-your-home-automation-docker-containers)



Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wollet42 am 07 März 2020, 10:37:57
Hallo,

ich habe gerade von einem anderen Docker Image auf dieses hier umgestellt und beobachte ein komisches Verhalten.

Bei mir wird die fhem.cfg immer 2x geladen beim Imagestart.

Aufgefallen ist mir das, da ich dadurch eine Fehlermeldung im Log habe wegen Telent (port in use)

Hat das sonst noch jemand bzw weiss jemand, wie ich das abschalte?

Logauszug:
2020.03.07 10:17:53 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2020.03.07 10:17:53 3: From the FHEM_GLOBALATTR environment: attr global pidfilename /opt/fhem/log/fhem.pid
2020.03.07 10:17:53 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2020.03.07 10:17:53 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2020.03.07 10:17:53 1: Including fhem.cfg
2020.03.07 10:17:53 3: telnet: port 7072 opened
2020.03.07 10:17:54 3: WEB: port 8083 opened
2020.03.07 10:17:54 2: eventTypes: loaded 492 events from /opt/fhem/log/eventTypes.txt
...
2020.03.07 10:17:56 1: Including /opt/fhem/log/fhem.save
2020.03.07 10:17:56 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2020.03.07 10:17:56 3: From the FHEM_GLOBALATTR environment: attr global pidfilename /opt/fhem/log/fhem.pid
2020.03.07 10:17:56 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2020.03.07 10:17:56 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
...
2020.03.07 10:18:02 0: Featurelevel: 6
2020.03.07 10:18:02 0: Server started with 122 defined entities (fhem.pl:21333/2020-03-01 perl:5.028001 os:linux user:fhem pid:5477)
...
2020.03.07 10:18:04 2: AttrTemplates: got 140 entries
2020.03.07 10:18:13 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2020.03.07 10:18:13 3: From the FHEM_GLOBALATTR environment: attr global pidfilename /opt/fhem/log/fhem.pid
2020.03.07 10:18:13 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2020.03.07 10:18:13 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2020.03.07 10:18:13 1: Including fhem.cfg  <-------------------- hier taucht das 2. include auf!!!!
2020.03.07 10:18:13 1: telnet: Can't open server port at 7072: Address already in use. Exiting.

update
FHEM läuft jedoch einwandfrei, mich stört nur die Fehlermeldung.
/update


Danke

Gruss,
Wolle
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: gklank am 15 März 2020, 15:16:35
Hallo,

ich möchte mich mit Telnet an dem Docker-FHEM (Docker-IP = 192.168.1.248) anmelden können.

Leider schaffe ich es nicht den telnetd so zu installieren, dass er dauerhaft und eben auch nach einem reboot nutzbar ist:
- apt-get install telnetd
- in /etc/securetty mehrere pts/0, pts/1 etc. gemacht
- docker neu gestartet
- mit telnet von einem Linuxsystem im gleichen Netz auf den Docker:
      nach einigen Sekunden - telnet: Unable to connect to remote host: Connection refused
- den vorhandenen inetd mit "S01openbsd-inetd start" gestartet
- mit ps -ef sehe ich, dass der inetd läuft
- in /etc/inetd.conf ist der Telnet eingetragen:
      telnet          stream  tcp     nowait  telnetd /usr/sbin/tcpd  /usr/sbin/in.telnetd
- mit telnet von einem Linuxsystem auf den Docker:
      im Vergleich vor dem gestarteten inetd kommt jetzt ohne jegliche Verzögerung: Connection closed by foreign host.

Ich wäre um helfende Tipps dankbar.


Grüße,

Gerhard
Docker auf QNAP 431+ mit fhem-arm32v7
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 15 März 2020, 17:22:07
Anstatt telnet mal ssh (putty) probiert?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 15 März 2020, 17:26:51
Mein Tipp: Lass es!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: gklank am 15 März 2020, 18:47:12
Hallo,

sshd war ein guter Tipp.

Nach dem Reboot läuft zwar der sshd nicht mehr, auch der sshd User ist gelöscht, aber es ist so reproduzierbar.
Falls da jemand noch etwas dazu weiß, dann gerne...

Und ein Reboot kommt bei mir nur selten vor.

D.h. es geht, wenn auch nach dem Reboot von Hand der sshd User wieder angelegt und der sshd gestartet werden muss..


Danke und Grüße,


Gerhard
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 15 März 2020, 18:56:18
Hallo,

sshd war ein guter Tipp.

Nach dem Reboot läuft zwar der sshd nicht mehr, auch der sshd User ist gelöscht, aber es ist so reproduzierbar.
Falls da jemand noch etwas dazu weiß, dann gerne...

Und ein Reboot kommt bei mir nur selten vor.

D.h. es geht, wenn auch nach dem Reboot von Hand der sshd User wieder angelegt und der sshd gestartet werden muss..


Danke und Grüße,


Gerhard

Du kannst den SSH Dämonen über das pre-init.sh Skript starten.
Hier mal als Beispiel: https://github.com/stormmurdoc/fhemdocker/blob/master/pre-init.sh (https://github.com/stormmurdoc/fhemdocker/blob/master/pre-init.sh)
Du musst aber den SSH Server noch als zusätzliches Paket beim Container Start starten.

Eintrag in die docker-compose.yml

APT_PKGS: "openssh-server"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 15 März 2020, 19:17:18
Ich befürchte, dass hier jemand versucht etwas mit Docker zu machen, was eigentlich ganz einfach ist.

Vielleicht einfach nochmal ein paar Grundlagen lesen.
https://phoenixnap.com/kb/how-to-ssh-into-docker-container
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 15 März 2020, 19:59:23
Ich befürchte, dass hier jemand versucht etwas mit Docker zu machen, was eigentlich ganz einfach ist.

Vielleicht einfach nochmal ein paar Grundlagen lesen.
https://phoenixnap.com/kb/how-to-ssh-into-docker-container

Nun ich sehe in der Anleitung keinen Unterschied zu der Lösung. Ich möchte via SSH auf den fhemuser einloggen. Da helfen mir die anderen Methoden nicht weiter.
Übersehe ich etwas?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 16 März 2020, 11:02:04
Andere Möglichkeit -je nach Anwendungsfall- wäre es auch, einfach über Portainer eine Shell zu öffnen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 16 März 2020, 11:55:47
Ich glaube, hier ist ein grundsätzliches Missverständnis:

Docker <> VM

Was Du willst, ist eigentlich eher eine VM .... eigentlich sollte in Docker nur "ein" Dienst laufen. Was Du willst, sind mehrere Dienste ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: plin am 16 März 2020, 15:07:20
Andere Möglichkeit -je nach Anwendungsfall- wäre es auch, einfach über Portainer eine Shell zu öffnen.
docker exec <container> <command>
führt zum gwünschten Ergebnis
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 16 März 2020, 15:26:49
Also mal zu meinem Anwendungsfall: Ich steuere über ein Shell Script (via SSH) FHEM. Ja geht auch über HTTPS.
Wozu? Um auf der Shell Dinge zu steuern! Da die Ports von FHEM nicht aus dem Container geführt sind, finde ich
SSH in den Container ok. Ja ich weiß, das entspricht nicht der Docker Philosophie, dass tut das Image ja schließlich auch nicht.
Und wenn ich jetzt noch sage, dass ich sogar einen Cron Dämonen laufen habe, werde ich wahrscheinlich gesteinigt :-) *duckundrennweg*
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: plin am 16 März 2020, 15:31:57
... Da die Ports von FHEM nicht aus dem Container geführt sind, finde ich SSH in den Container ok. ...
Mal 'ne Frage: Den Container willst Du nicht für die FHEM-Ports öffnen wohl aber für den SSH-Port? Wo ist da der Unterschied?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 16 März 2020, 15:39:58
Mal 'ne Frage: Den Container willst Du nicht für die FHEM-Ports öffnen wohl aber für den SSH-Port? Wo ist da der Unterschied?

ganz einfach: SSH vertraue ich mehr :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: plin am 16 März 2020, 15:47:03
ganz einfach: SSH vertraue ich mehr :-)
Was willst Du denn "steuern"? Start/Stop? Auf welchem Trägersystem läuft Dein conatainer?
Geht
?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 16 März 2020, 15:56:20
cat myfile | docker exec telnet localhost 7072
^^ das schaue ich mir an! Danke für die Tipps.


*EDIT*

cat myfile | docker exec -u1000 fhem_fhem telnet localhost 7072^^ das klappt leider nicht. Any idea?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 16 März 2020, 16:11:14
Innerhalb des Containers ist telnet offen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 16 März 2020, 17:45:02
Innerhalb des Containers ist telnet offen?

Yes sir!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 16 März 2020, 18:13:26
Dann probiere bitte erst mal:
docker exec telnet localhost 7072
Was kommt raus?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: plin am 16 März 2020, 18:56:34
telnet versucht Input aus dem Container zu lesen und nicht vom host-System. So geht's
cat myfile  | docker exec --interactive fhem_fhem telnet localhost 7072
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 16 März 2020, 19:35:42
telnet versucht Input aus dem Container zu lesen und nicht vom host-System. So geht's
cat myfile  | docker exec --interactive fhem_fhem telnet localhost 7072

Cool - überzeugt ich schmeiße den SSH Dämon raus.
In einem Skript sieht das dann wie folgt aus:

#!/usr/bin/env sh
#
# Description: send FHEM command via ssh to the local telnet daemon
#
# Configuration file: none
#
# Parameters: none
#

ssh 2>/dev/null pi@raspberrypi4 -n "echo "$@" | docker exec --interactive fhem_fhem socat -t50 - TCP:localhost:7072"

Als fcmd.sh speichern und mit chmod +x ausführbar machen.
Vielleicht kann das ja noch jemand gebrauchen. Danke dir plin!

Aufruf mit

fcmd.sh <FHEM CMD>
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 16 März 2020, 19:38:00
Cool - überzeugt ich schmeiße den SSH Dämon raus.
In einem Skript (ok mit socat muss nicht unbedingt sein) sieht das dann wie folgt aus:

#!/usr/bin/env sh
#
# Description: send FHEM command via ssh to the local telnet daemon
#
# Configuration file: none
#
# Parameters: none
#

ssh 2>/dev/null pi@raspberrypi4 -n "echo "$@" | docker exec --interactive fhem_fhem socat -t50 - TCP:localhost:7072"

Als fcmd.sh speichern und mit chmod +x ausführbar machen.
Vielleicht kann das ja noch jemand gebrauchen. Danke dir plin!

Aufruf mit

fcmd.sh <FHEM CMD>
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nanocosmos am 20 März 2020, 14:50:13
Hallo zusammen,

ich nutze fhem docker aktuell auf meinem Selbstbau NAS mit Openmediavault.
Alle docker Container besitzen in einem Hauptordner jeweils eigene Unterordner.
Ich kann auf alle Ordner zugreifen, außer auf fhem. Sobald ich den core Ordner öffnen möchte, kommt die Meldung, dass ich keine Berechtigung habe.
Ich habe den Hauptordner bereits mehrfach in OMV für Windows Netzwerkfreigabe verfügbar gemacht. Das Problem bleibt...
Da ich ja auf alle anderen Unterordner zugreifen kann, bin ich mir nicht sicher, dass es ein Berechtigungsproblem ist, zumal ich in OMV nur den Hauptordner verfügbar mache und somit eigentlich alle Unterordner die gleichen Berechtigungen besitzen müssten.

Mir ist jedoch aufgefallen, dass der core Ordner von fhem schreibgeschützt ist.

Vielleicht hat jemand ne Idee.. [emoji1]

Besten Dank und viele Grüße!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 20 März 2020, 16:15:40
Ist ein Berechtigungsproblem. Leider agiert der FHEM-Container mit automatischen Rechteänderungen auf dem Hostsystem. Kannst Du nur durch ein eigenes Image unterbinden oder indem Du eine spezifische seccomp-Datei zuweist, die chown verbietet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nanocosmos am 20 März 2020, 16:37:52
Danke!
Das ist aber neu, oder?
Ich hatte mein Fhem Docker vor ca. 3 Monaten auf den damals aktuellen Stand gebracht. Davor gab es die Probleme nicht... [emoji1]
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Papaloewe am 21 März 2020, 10:26:18
Hallo Lerodo,

ich bin seit ein paar Tagen auf "fhem im Container" produktiv umgestiegen und dabei sehr dankbar für dieses Image.

Jetzt fällt mir auf, dass mein täglicher Sicherungsjob mittels rsync nicht mehr läuft.
Frage: Ist rsync im Image enthalten? Falls nein, könnte man es bitte noch integrieren?

Vielen Dank & bleibt alle gesund.

Thomas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Papaloewe am 21 März 2020, 10:29:57
Hat sich erledigt.

Die Möglichkeit, eigene Pakete zu integrieren ist ja bereits vorhanden.
Super!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maci am 23 März 2020, 12:18:59
...
Ich kann auf alle Ordner zugreifen, außer auf fhem. Sobald ich den core Ordner öffnen möchte, kommt die Meldung, dass ich keine Berechtigung habe.
.....

Ich habe in meiner docker.compose.yaml die FHEM.UID und die FHEM.GID gesetzt mit dem Rechten meines Users, der auch Docker bedienen darf.
Somit kann ich auf alle fhem Dateien zugreifen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nanocosmos am 23 März 2020, 12:25:28
Hej zusammen,

ich nutze die aktuelle Zeit im Home Office um meine Docker Umstellung voran zu treiben.
Aktuell sitze ich an MySQL als Docker Container.

Ich habe es schon hinbekommen, dass fhem sich mit mysql verbindet.
Leider schaffe ich es nicht die notwendigen Tabellen (current, history) in mysql anzulegen.
Von außen komme ich gar nicht auf die mysql Instanz.

Daher dachte ich, dass ich die init.SQL in das mysql Verzeichnis packe:
CREATE TABLE history (
    TIMESTAMP TIMESTAMP,
    DEVICE varchar(64),
    TYPE varchar(64),
    EVENT varchar(512),
    READING varchar(64),
    VALUE varchar(255),
    UNIT varchar(32),
    KEY `Search_Idx` (`DEVICE`,`READING`,`TIMESTAMP`,`VALUE`),
    KEY `Device_Idx` (`DEVICE`,`READING`),
    KEY `Report_Idx` (`TIMESTAMP`,`READING`) USING BTREE
);

CREATE TABLE current (
    TIMESTAMP TIMESTAMP,
    DEVICE varchar(64),
    TYPE varchar(64),
    EVENT varchar(512),
    READING varchar(64),
    VALUE varchar(255),
    UNIT varchar(32)
);

Mache ich nun ein docker-compose up -d möchte mysql nicht starten. In einem kompletten leerer Ordner ist das kein Problem.
Anbei Auszüge meiner yml Datei:
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_DATABASE=fhem
            - MYSQL_USER=fhemuser
            - MYSQL_PASSWORD=XXXXXXXX
            - MYSQL_RANDOM_ROOT_PASSWORD=true
            - MYSQL_ONETIME_PASSWORD=false
        networks:
            - fhem-network


Leider kenne ich mich mit Docker noch nicht gut genug aus.
Ich habe wohl sehr sicher einen Fehler in meiner yml Datei...

Vielleicht sieht jemand diesen Fehler. Besten Dank für die Untersützung!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 23 März 2020, 12:45:10
Also ..
- "33060" was ist das für ein Port??
- Du solltest "von Außen", d.h. vom docker-Server auf mysql kommen, in dem Du den Port angibst. Du kannst auch auf mysql Zugreifen, in dem Du über <IP-des Containers> Port zugreifst.
- Warum machst Du expose UND port?


Leider verstehe ich Deine Meldung nicht:
Zitat
In einem kompletten leerer Ordner ist das kein Problem.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: spectdan am 23 März 2020, 12:52:18
Du kannst dich doch einfach in deinen Container einloggen und die Befehle eingeben. So habe ich es gemacht.

docker exec -it <ContainerName> bash

Dann noch in die Datenbank einloggen wie sonst auch.

mysql -p -u <fhemuser>

Der Rest sollte ja bekannt sein.

Gesendet von meinem SM-G960F mit Tapatalk

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 23 März 2020, 14:15:26
Portainer ist hier auch sehr hilfreich, da man ja nur einmal daran muss und danach"eigentlich" nicht mehr direkt an den MySQL-Container muss.

Geht natürlich auch alles über "docker exec" aber damit kommt ja nicht jeder gleich gut klar.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nanocosmos am 23 März 2020, 14:46:46
Du kannst dich doch einfach in deinen Container einloggen und die Befehle eingeben. So habe ich es gemacht.

docker exec -it <ContainerName> bash

Dann noch in die Datenbank einloggen wie sonst auch.

mysql -p -u <fhemuser>

Der Rest sollte ja bekannt sein.

Gesendet von meinem SM-G960F mit Tapatalk
Besten Dank, die Möglichkeit war mir noch gar nicht bewusst. Vielen Dank!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Andy89 am 23 März 2020, 16:50:08
Ich habe in meiner docker.compose.yaml die FHEM.UID und die FHEM.GID gesetzt mit dem Rechten meines Users, der auch Docker bedienen darf.
Somit kann ich auf alle fhem Dateien zugreifen.
danke für diesen hilfreichen Tipp. Funktioniert super und ich muss nicht mehr das root Password eintippen, um Kleinigkeiten zu ändern.
Danke!

Bleibt Gesund,
Andy
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: nanocosmos am 23 März 2020, 18:16:05
Ich habe in meiner docker.compose.yaml die FHEM.UID und die FHEM.GID gesetzt mit dem Rechten meines Users, der auch Docker bedienen darf.
Somit kann ich auf alle fhem Dateien zugreifen.

Könntest Du mir das bitte an einem Beispiel zeigen?  :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Andy89 am 23 März 2020, 19:13:27
Könntest Du mir das bitte an einem Beispiel zeigen?  :)

in der docker-compose.yml habe ich diese Variablen hinzugefügt:
environment:
      FHEM_UID: 6061
      FHEM_GID: 6061

Die beiden Zahlen müssen auf den gewünschten User angepasst werden.

Die UID von deinem User bekommst du so raus (pi ist der Username):
id -u piund so die GID:
id -g pi
Danach natürlich den Container neustarten und du solltest wieder Zugriff auf dem fhem Ordner haben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eddy242 am 25 März 2020, 16:25:05
Hallo zusammen,

fhem läuft seit Monaten im Docker stabil. Ins Image wird ein Host-Folder gemounted, der von Sonos Speak verwendet wird (straightforward nach Anleitung). Diese Host Folder wird in einem anderen Container ebenfalls gemounted auf dem Samba läuft und die Sprachausgabe MP3 liegt.

Die Berechtigungen sind seit Monaten gleich und alles lief stabil. Seit ein paar Tagen funktionieren die Sprachausgaben nicht mehr und ich habe mich ans debuggen gemacht. Was mit auffällt ist dass seit neuestem die Files nicht mehr im Container mit rw-rw-r-- angelegt werden sondern mit rw-rw----, d.h. für everyone gibts keine Berechtigungen. Das ist im File des Hostfolders genau gleich, d.h. auf dem Sonosshare kann man das File als guest nicht mehr abholen.

Ich habe bereits im Container die umask überprüft (022), sollte ok sein. Habe auch mit umask 002 rumgespielt, ohne Erfolg.

Gab es bei der umask für File-Creations innerhalb des Containers in letzter Zeit Änderungen? Hat jemand eine Idee zu einem Workaround?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 26 März 2020, 00:19:23
Was heißt denn „in letzter Zeit“? Letzte Änderung in Github war am 7.1.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: eddy242 am 26 März 2020, 08:14:41
ok dann scheidet das wohl aus. Tatsache ist dass Dateien früher mit der Berechtigung rw-rw-r-- angelegt wurden, jetzt mit rw-rw----. Ich habe keinen Anhaltspunkt für Zeitpunkt und Ursache der Änderungen, sehe nur, dass es eine Änderung im Verhalten gab. Vielleicht hat jemand einen Anhaltspunkt? Ich frage sonst im Sonos-Forum.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 27 März 2020, 23:12:50
Lies dir aber mal auf der github-Seite durch, wie Du die Datei- und Vereichnisrechte mit -e steuern kannst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Holzlenkrad am 03 April 2020, 00:38:09
Ich möchte am Wochenende mein komplettes Setup das seit über einem Jahr recht stabil läuft auf potentere Hardware umziehen. Vielleicht bin ich damit sogar bis nach Ostern durch  :o

Reicht es, wenn ich die backup.tar.gz von fhem auf dem neuen System entpacke und dann einfach beim ersten Containerstart dieses Verzeichnis auf /opt/fhem linke?
Oder muss ich sonst noch etwas beachten? Dateirechte o.ä.?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 03 April 2020, 01:25:27
Schön wärs. Hängt von Deiner Installation ab. Grade Sensor-Hardware macht Bauchschmerzen.
Und ich habe bis heute noch nicht rausgefunden, warum das Pushover-Modul auf einer nackten Konfiguration läuft, mit meiner migrieren aber nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 03 April 2020, 01:49:20
Macht es in Docker Probleme die UID und GID nicht auf 6061 zu setzen?, sonder auf den Benutzer von Synology NAS (1020 und 100)?

Wo stellt man Docker ein, das andere Container zuerst starten müssen oder geht das im Anschluss nicht mehr?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thm12345 am 03 April 2020, 09:14:34
Hallo,

ich versuche gerade eine FHEM Umgebung mit Container Station (Docker 17.09) auf einer QNAP (ARM) aufzubauen. Ich möchte unter einer IP 2 Instanzen von FHEM laufen lassen (FHEM_prod/FHEM_test). Die Instanzen sollen über die Ports unterschieden werden. Da ich beides über eine IP laufen lassen will, habe ich beim 2. Container den Netzwerkmode "service" konfiguriert. Hier kann ich aber nicht mit "-p" die Ports umlenken. Also habe ich eine vorkonfigurierte fhem.cfg in Verzeichnis für fhem_test abgelegt. Leider ignoriert fhem_test diese Einstellungen und meckert, dass Port 8083 schon in Nutzung ist. Ich vermute es "muss" mit 8083 hochkommen und ändert dann intern erst den in der fhem.cfg eingestellten Port?! Kann man das eventuell irgendwie forcieren, das es initial mit einem anderen Port hochkommt?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 03 April 2020, 09:16:24
Meine Empfehlung: Setze das gleich mit docker-compose auf.
Du kannst dort depends-on benutzen, hilft aber nur bedingt und hat den unschönen Nebeneffekt, das auch ein recreate für den Container dadurch ausgelöst wird.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 April 2020, 09:19:27
Wo stellt man Docker ein, das andere Container zuerst starten müssen oder geht das im Anschluss nicht mehr?

in docker-compose gibts den parameter "depends_on". Erst wenn die Container laufen wird der Container mit dem Attribut gestartet. Musst mal prüfen ob das in deiner Umgebung / Framework vorhandne ist wenn du nicht docker-compose nutzt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 03 April 2020, 09:19:36
Hallo,

ich versuche gerade eine FHEM Umgebung mit Container Station (Docker 17.09) auf einer QNAP (ARM) aufzubauen. Ich möchte unter einer IP 2 Instanzen von FHEM laufen lassen (FHEM_prod/FHEM_test). Die Instanzen sollen über die Ports unterschieden werden. Da ich beides über eine IP laufen lassen will, habe ich beim 2. Container den Netzwerkmode "service" konfiguriert. Hier kann ich aber nicht mit "-p" die Ports umlenken. Also habe ich eine vorkonfigurierte fhem.cfg in Verzeichnis für fhem_test abgelegt. Leider ignoriert fhem_test diese Einstellungen und meckert, dass Port 8083 schon in Nutzung ist. Ich vermute es "muss" mit 8083 hochkommen und ändert dann intern erst den in der fhem.cfg eingestellten Port?! Kann man das eventuell irgendwie forcieren, das es initial mit einem anderen Port hochkommt?
Poste bitte mal deine Kommandos für die beiden Instanzen hier.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 03 April 2020, 12:18:07
Da ich ein Problem mit dem AutoShutterControl habe, würde ich das zum testen mal in einen neuen Container überführen, gibt es ein Problem wenn man den Z-Wave USB-Stick in 2 Containern eingebunden hat?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 03 April 2020, 12:20:35
Da ich ein Problem mit dem AutoShutterControl habe, würde ich das zum testen mal in einen neuen Container überführen, gibt es ein Problem wenn man den Z-Wave USB-Stick in 2 Containern eingebunden hat?
Typischerweise können die meisten Devices nur exklusiv durch einen Container genutzt werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thm12345 am 03 April 2020, 14:40:52
Poste bitte mal deine Kommandos für die beiden Instanzen hier.
Das ist ein Auszug aus meiner docker-compose.yml:
############################################
# Heimdall
# Port: 80 / 443
# FHEM
# Ports: 8083 / 8084 / 8085 / 7072
# FHEM Test
# Ports: 18083 / 18084 / 18085 / 17072
# mosquitto
# Ports: 1883 / 9001
# NodeRed
# Ports: 1880
# HA Bridge
# Port: 8080 / 50000
############################################
version: "2"
# Services
services:
# FHEM
# Ports: 8083 / 8084 / 8085 / 7072
  fhem:
    image: fhem/fhem
    container_name: fhem
    hostname: fhem
    environment:
      FHEM_UID: 1000
      FHEM_GID: 1000
      TELNETPORT: 7072
      TZ: Europe/Berlin
      LANG: de_DE.UTF8
      LANGUAGE: de_DE.de
    volumes:
      - $PWD/fhem/fhem/data:/opt/fhem
    networks:
      qnet_static:
      # static:
        ipv4_address: 192.168.178.227
    restart: unless-stopped

# FHEM Test
# Ports: 18083 / 18084 / 18085 / 17072
# Die Ports werden durch eine vorkonfigurierte fhem.cfg ungebogen
  fhem_test:
    image: fhem/fhem
    container_name: fhem_test
    environment:
      FHEM_UID: 1000
      FHEM_GID: 1000
#      TELNETPORT: 17072
      TZ: Europe/Berlin
      LANG: de_DE.UTF8
      LANGUAGE: de_DE.de
    volumes:
      - $PWD/fhem/fhem/data:/opt/fhem
    network_mode: "service:fhem"
    depends_on:
      - nodered_fhem
    restart: unless-stopped

...

#Networks
networks:
  qnet_static:
    external: true

Den FHEM-Ordner habe ich von der Prod-Version, nach einem erfolgreichen Start, komplett nach Test kopiert und dann die fhem.cfg angepasst:
attr global logfile ./log/fhem-%Y-%m-%d.log
attr global modpath .
attr global verbose 3
attr global statefile ./log/fhem.save

define WEB FHEMWEB 18083 global
define WEBphone FHEMWEB 18084 global
define WEBtablet FHEMWEB 18085 global
define telnetPort telnet 17072

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m-%d.log fakelog

define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log

define eventTypes eventTypes ./log/eventTypes.txt

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
attr global dnsServer 127.0.0.11
attr global commandref modular
attr global mseclog 1
define DockerImageInfo DockerImageInfo
attr DockerImageInfo alias Docker Image Info
attr DockerImageInfo devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red
attr DockerImageInfo group System
attr DockerImageInfo icon docker
attr DockerImageInfo room System
define fhemServerApt AptToDate localhost
attr fhemServerApt alias System Update Status
attr fhemServerApt devStateIcon system.updates.available:security@red system.is.up.to.date:security@green:repoSync .*in.progress:system_fhem_reboot@orange errors:message_attention@red
attr fhemServerApt group Update
attr fhemServerApt icon debian
attr fhemServerApt room System
define fhemInstaller Installer
attr fhemInstaller alias FHEM Installer Status
attr fhemInstaller devStateIcon .*updates.available:security@red:outdated up.to.date:security@green:outdated .*outdated.*in.progress:system_fhem_reboot@orange .*in.progress:system_fhem_update@orange warning.*:message_attention@orange error.*:message_attention@red
attr fhemInstaller group Update
attr fhemInstaller icon system_fhem
attr fhemInstaller room System


Wenn ich docker-compose starte, startet die fhem-Version ohne Probleme. Die fhem_test gibt die folgenden Meldungen aus:
Preparing initial start:,
1. Updating existing FHEM installation in /opt/fhem,
,
Preparing user environment ...,
1. Creating group 'fhem' with GID 1000 ...,
2. Enforcing GID for group 'bluetooth' to 6001 ...,
3. Creating user 'fhem' with UID 1000 ...,
4. Creating log directory /opt/fhem/./log ...,
5. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...,
6. Enforcing file and directory permissions for /opt/fhem ...,
7. Correcting group ownership for /dev/tty* ...,
8. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...,
9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...,
10. Updating /etc/sudoers.d/fhem-docker ...,
11. Adding gateway.docker.internal to /etc/hosts ...,
12. Adding host.docker.internal to /etc/hosts ...,
13. Pre-authorizing SSH to Docker host for user 'fhem' ...,
14. Updating SSH key pinning and SSH client permissions for user 'fhem' ...,
,

Preparing configuration ... done,
,
Starting FHEM ...,
2020.04.03 14:29:12.319 3: telnetPort: port 7072 opened,
2020.04.03 14:29:12.319 1: Including ./log/fhem.save,
2020.04.03 14:29:12.328 3: From the FHEM_GLOBALATTR environment: attr global nofork 0,
2020.04.03 14:29:12.328 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid,
2020.04.03 14:29:12.329 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1,
2020.04.03 14:29:12.329 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log,
2020.04.03 14:29:13.495 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid,
2020.04.03 14:29:13.495 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log,
2020.04.03 14:29:13.496 3: From the FHEM_GLOBALATTR environment: attr global nofork 0,
2020.04.03 14:29:13.496 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1,
2020.04.03 14:29:13.501 1: Including fhem.cfg,
2020.04.03 14:29:13.784 1: WEB: Can't open server port at 8083: Address already in use. Exiting.,
2020.04.03 14:29:14.358 1: usb create starting,
2020.04.03 14:29:14.399 1: usb create end,
2020.04.03 14:29:14.400 0: Featurelevel: 6,
2020.04.03 14:29:14.400 0: Server started with 10 defined entities (fhem.pl:21337/2020-03-02 perl:5.028001 os:linux user:fhem pid:3765),
/entry.sh: Zeile 621: kill: (3765) - Kein passender Prozess gefunden,
,

Abrupt daemon termination, starting 10s countdown .../entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 10/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 9/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 8/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 7/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 6/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 5/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 4/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 3/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 2/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
 1/entry.sh: Zeile 625: kill: (3765) - Kein passender Prozess gefunden,
/entry.sh: Zeile 632: kill: (3765) - Kein passender Prozess gefunden,
 0,
Automatic restart ...,
,
/entry.sh: Zeile 645: kill: (3765) - Kein passender Prozess gefunden,
,
Preparing configuration ... done,
,
Starting FHEM ...,
2020.04.03 14:29:25.913 3: From the FHEM_GLOBALATTR environment: attr global nofork 0,
2020.04.03 14:29:25.913 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log,
2020.04.03 14:29:25.914 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1,
2020.04.03 14:29:25.914 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid,
2020.04.03 14:29:25.919 1: Including fhem.cfg,
2020.04.03 14:29:26.217 1: WEB: Can't open server port at 8083: Address already in use. Exiting.,
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 April 2020, 16:39:21
Hier kann ich aber nicht mit "-p" die Ports umlenken. Also habe ich eine vorkonfigurierte fhem.cfg in Verzeichnis für fhem_test abgelegt.

Das ist ein Auszug aus meiner docker-compose.yml:
############################################
# Heimdall
# Port: 80 / 443
# FHEM
# Ports: 8083 / 8084 / 8085 / 7072
# FHEM Test
# Ports: 18083 / 18084 / 18085 / 17072
# mosquitto
# Ports: 1883 / 9001
# NodeRed
# Ports: 1880
# HA Bridge
# Port: 8080 / 50000
############################################
version: "2"
# Services
services:
# FHEM
# Ports: 8083 / 8084 / 8085 / 7072
.....
    volumes:
      - $PWD/fhem/fhem/data:/opt/fhem    <<<<<<<<<<<<<<<<<<<<<<<<<
 
# FHEM Test
# Ports: 18083 / 18084 / 18085 / 17072
# Die Ports werden durch eine vorkonfigurierte fhem.cfg ungebogen
  fhem_test:
    image: fhem/fhem
    container_name: fhem_test
    environment:
      FHEM_UID: 1000
.....
    volumes:
      - $PWD/fhem/fhem/data:/opt/fhem    <<<<<<<<<<<<<<<<<<<<<<<<<<<<
    network_mode: "service:fhem"
    depends_on:
      - nodered_fhem
    restart: unless-stopped

...


Den FHEM-Ordner habe ich von der Prod-Version, nach einem erfolgreichen Start, komplett nach Test kopiert und dann die fhem.cfg

Wenn du zwei verschiedene Container hast, solltest du dann nicht auch unterschiedliche Volumes nutzen? Wenn du den 2. Container startest dann liest er immer die selbe fhem.cfg. Selbes Verzeichnis mit der selben fhem.cfg hat dann natürlich die selben Ports die dann schon belegt sind. Oder wie soll das getrennt werden? Wo befindet sich das oben genannte "Verzeichnis für fhem_test abgelegt".
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 03 April 2020, 17:13:50
Also ich verstehe nicht, was Du dort mit dem Network_mode erreichen willst? Ist ein sehr unübliches Konstrukt, wenn auch laut Doku möglich. Du läufst möglicherweise in einen Port-Konflikt, da der FHEM-Container mehrere Ports öffnet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thm12345 am 03 April 2020, 21:23:30
Wenn du zwei verschiedene Container hast, solltest du dann nicht auch unterschiedliche Volumes nutzen? Wenn du den 2. Container startest dann liest er immer die selbe fhem.cfg. Selbes Verzeichnis mit der selben fhem.cfg hat dann natürlich die selben Ports die dann schon belegt sind. Oder wie soll das getrennt werden? Wo befindet sich das oben genannte "Verzeichnis für fhem_test abgelegt".

Das war der Fehler, Danke. Ich habe den Abschnitt mit Copy/Paste erzeugt und übersehen den Pfad anzupassen ???.
Danach hat es funktioniert. Als ich dann probiert habe, alles zu löschen und neu zu erzeugen, funktionierte es wieder nicht. Die Lösung habe ich dann noch selbst gefunden. Es bei der Neueinrichtung wird eine schon vorhandene fhem.cfg mit der aus dem Paket überschrieben. Meine Lösung eine extra fhem_test.cfg vorher in den data-Pfad ablegen und fhem dann mit dem Parameter "CONFIGTYPE: fhem_test.cfg" starten. Jetzt geht es  :).

Also ich verstehe nicht, was Du dort mit dem Network_mode erreichen willst? Ist ein sehr unübliches Konstrukt, wenn auch laut Doku möglich. Du läufst möglicherweise in einen Port-Konflikt, da der FHEM-Container mehrere Ports öffnet.

Öffnet der Container mehr Ports wie 8083/8084/8085/7072? Die biege ich ja alle mit der fhem_test.cfg um.

Ich möchte eine "reale" IP Adresse in meinem Netzwerk verwenden, keine über NAT. Daher nutze ich den qnet-Treiber von QNAP. Mit dem Network_mode möchte ich einfach nur verhindern, das ich zu viele IP's vergeben muss. Das potentielle Problem mit überlagernden Ports versuche ich auf dem Schirm zu behalten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 04 April 2020, 00:05:14
Zitat von: thm12345 link=topic=89745.msg1038283#msg1038283 date=
Öffnet der Container mehr Ports wie 8083/8084/8085/7072? Die biege ich ja alle mit der fhem_test.cfg um.
Es ist schon möglich, dass das ein oder andere Modul zusätzliche Ports benötigt.
Titel: Offizielles FHEM Docker Basis Image, Problem nach fhem update
Beitrag von: Dirk070 am 04 April 2020, 18:54:57
Hallo zusammen,

vielleicht kann mir jemand bei einem Phänomen helfen. Basis ist eine Syno 918.
Seit Anfang Juli 2019 hatte ich einen Docker-Container mit fhem laufen. Anfang März 2020 habe ich einen neuen, aktuellen, Docker-Container erstellt und gegen das vorhandene Fhem-Verzeichnis gehängt. Alles lief gut, keine Probleme.

Heute habe ich in fhem ein "update" gemacht, gefolgt von "shutdown restart". Danach war die Weboberfläche nicht mehr erreichbar. Container gestoppt und über Midnight Commander ein Backup eingespielt. Container gestartet, keine Besserung.

Also den alten Container aus Juli 2019 gestartet, mit dem selben fhem-Verzeichnis. Weboberfläche erreichbar. Nun wieder das aktuelle Verzeichnis von fhem aktiviert (voher Container gestoppt und anschließend wieder gestartet). Läuft.

Nun meine Frage: wie kann das fhem-Update Einfluss auf den Container nehmen? Warum läuft das Ganze mit dem alten Container und nicht mit dem Neuen (der bis dahin über einen Monat problemlos lief)?

Danke Euch vorab und viele Grüße
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: pas am 05 April 2020, 23:00:44
Hallo zusammen

Zuerst mal Dank an euch alle für diese tolle Arbeit hier! Fhem ist schon ein paar Jahre im Einsatz bei mir zuhause, und funktioniert unglaublich stabil - und das auch noch mit äusserst bescheidenen Hardware-Anforderungen - fantastisch!

Zu meiner Frage:
Im offiziellen Docker-Image vermisse ich das Fhem-Modul FUIP. Ich glaube hier irgendwo gelesen zu haben dass noch fehlende Fhem-Module besser direkt im offiziellen Docker-Image eingepflegt werden sollen? Falls das so stimmt, an wenn müsste ich mich da wenden? Evtl. hat es einen guten Grund dass dieses Modul fehlt. Vielleicht könnte ich auch irgenwie mithelfen - allerdings sind meine Kenntnissen doch eher beschieden.

LG Pascal
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 06 April 2020, 00:39:45
Nun meine Frage: wie kann das fhem-Update Einfluss auf den Container nehmen? Warum läuft das Ganze mit dem alten Container und nicht mit dem Neuen (der bis dahin über einen Monat problemlos lief)?
Moin Dirk,
Ich habe meine Glaskugel gerade verlegt. Du solltest Dir zumindest mal die Mühe machen in die Logs vom FHEM zu schauen. In 90% der Fälle ist dort ersichtlich, wo es klemmt.

Gruß
Veit
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 06 April 2020, 00:45:57
Zu meiner Frage:
Im offiziellen Docker-Image vermisse ich das Fhem-Modul FUIP. Ich glaube hier irgendwo gelesen zu haben dass noch fehlende Fhem-Module besser direkt im offiziellen Docker-Image eingepflegt werden sollen? Falls das so stimmt, an wenn müsste ich mich da wenden? Evtl. hat es einen guten Grund dass dieses Modul fehlt. Vielleicht könnte ich auch irgenwie mithelfen - allerdings sind meine Kenntnissen doch eher beschieden.

Das offizielle Image enthält das, was Bestandteil von FHEM auch mit dem offiziellen Paket ist. Module, die keine Maintanance haben, sind daher nicht enthalten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 06 April 2020, 08:13:46
Zu meiner Frage:
Im offiziellen Docker-Image vermisse ich das Fhem-Modul FUIP. Ich glaube hier irgendwo gelesen zu haben dass noch fehlende Fhem-Module besser direkt im offiziellen Docker-Image eingepflegt werden sollen? Falls das so stimmt, an wenn müsste ich mich da wenden? Evtl. hat es einen guten Grund dass dieses Modul fehlt. Vielleicht könnte ich auch irgenwie mithelfen - allerdings sind meine Kenntnissen doch eher beschieden.

".... Ich glaube hier irgendwo gelesen zu haben ..."

von welchen Modulen sprichst du? FUIP setzt FTUI voraus. Beides kann per "update add" / "update all" installiert werden. Im Anschluss sind die DAteinen im /opt/fhem Ordner persistent und werden auch beim Update eines Containers nicht verändert. Oder sehe ich das falsch?

Wenn du von Dateien sprichst die außerhalb des Fhem-Ordners angelegt werden --> zusätzliches Volume und die DAteien bleiben
Wenn du von Abhängigkeiten sprichst, s. Doku ..
- -e APT_PKGS="package1 package2"
- -e CPAN_PKGS="App::Name1 App::Name2"
- -e PIP_PKGS="package1 package2"
- -e NPM_PKGS="package1 package2"

auch da schon alles da, bzw. ohne Änderung am Container möglich.

Ansonsten bitte etwas konkreteren Input, was genau vermisst du. Vielleicht liegt es auch nur an deiner Config.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kotaro am 06 April 2020, 21:58:54
Also irgendwie klappt das mit Pyhton3 und dem Inline::Python nicht so richtig
Ich bekomme bei GOOGLECAST immer folgenden Fehler:
2019.12.08 13:15:03 1: reload: Error:Modul 98_GOOGLECAST deactivated:
 Error -- py_eval raised an exception at /usr/lib/x86_64-linux-gnu/perl5/5.28/Inline/Python.pm line 177.
BEGIN failed--compilation aborted at ./FHEM/98_GOOGLECAST.pm line 699.

2019.12.08 13:15:03 0: Error -- py_eval raised an exception at /usr/lib/x86_64-linux-gnu/perl5/5.28/Inline/Python.pm line 177.
BEGIN failed--compilation aborted at ./FHEM/98_GOOGLECAST.pm line 699.

Traceback (most recent call last):
  File "<string>", line 3, in <module>
ImportError: No module named pychromecast

mein Inline Pyhthon ist eigentlich gesetzt:
INLINE_PYTHON_EXECUTABLE=/usr/bin/python3 cpanm Inlin
e::Python

Was mache ich noch falsch?!

Leider stehe ich auch an der selben stelle, und komme irgendwie einfach nicht weiter....

Weiß jemand, wie man GoogleCast einbinden kann?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 10 April 2020, 14:29:00
Ich habe ein Problem mit dem Docker Image, und zwar wenn ich meinen Zwave Rollladen über einen Pi ohne Docker steuere mit dem AutoShutterControl werden alle Zeiten ordentlich berechnet, wenn ich diese mit dem Zwave Stick im Docker auf meinem NAS betreibe funktioniert das AutoShutterControl in Verbindung mit den Zwave Geräten nicht mehr, hier springt die Zeit auf 1970 zurück und es gibt noch ein paar Readings die nicht mehr funktionieren oder ausgegeben werden. Kann mir hier jemand sagen woran das liegt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 10 April 2020, 15:49:18
Wie ist die Zeiteinstellung Deines NAS?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 10 April 2020, 15:55:01
An der Synology ist eingestellt:

Serveradresse: pool.ntp.org
Zeitzone: GMT +1:00 (Berlin)


im Docker Container übergebe ich mit:
-e TZ=Europe/Berlin

ohne dem wäre die Zeit -2 Stunden im log vom Docker Container
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 10 April 2020, 17:04:42
Gib mal das in dem befehlsfeld ein um zu sehen was auf dem docker für ne zeit herrscht. Passt das Datum und Zeit?

{qx(date)}
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 10 April 2020, 17:07:25
Die Zeit wird passen. Die 1970 Zeit wird von ASC kommen.
Grund wenn ASC keine Sau Eren Daten bekommt setzt er Unixtime 0
Frage ist halt nur wieso er im Docker die Daten nicht sauber bekommt. Fehlt eine Bibliothek?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 10 April 2020, 17:21:14
Gib mal das in dem befehlsfeld ein um zu sehen was auf dem docker für ne zeit herrscht. Passt das Datum und Zeit?

{qx(date)}
Fr 10. Apr 17:20:49 CEST 2020

das passt
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 10 April 2020, 23:46:56
Ich stelle für einen Test mal meine Daten zur Verfügung. angelegt sind ein ZwaveDongle und 2 Rollladen. Der Fehler tritt auf einem Pi nicht auf (mit dem selben RAW Import). Nach einem get ASC_Device showNotifyDevInformations bleibt die Liste Leer, am Pi stehen die 2 Rollladen in der Liste. Je mehr man die Rollladen konfiguriert im ASC umso mehr Fehler kommen.

Mit diesem Befehl habe ich den Container angelegt:
docker run -d --name FHEM  -p 8083:8083 -v /volume1/docker/fhem/:/opt/fhem --device=/dev/serial/by-id/usb-0658_USBDevice_ffffffd1ffffffb2ffffffdbffffffad-if00:/dev/ttyACM0  -e CPAN_PKGS="JSON::XS" -e FHEM_UID=1026 -e FHEM_GID=100 -e TZ=Europe/Berlin fhem/fhem:latest
Hier die 3 Geräte als RawDefinition zum Import und Test:
defmod ASC_Device AutoShuttersControl
attr ASC_Device ASC_debug 1
attr ASC_Device ASC_expert 1
attr ASC_Device devStateIcon { AutoShuttersControl_DevStateIcon($name) }
attr ASC_Device icon fts_shutter_automatic
attr ASC_Device room ASC

setstate ASC_Device created new drive timer
setstate ASC_Device 2020-04-10 23:29:48 Rollladen_01_Ki_nextAstroTimeEvent 11.04.2020 - 06:46
setstate ASC_Device 2020-04-10 23:29:48 Rollladen_02_Flur_nextAstroTimeEvent 11.04.2020 - 06:46
setstate ASC_Device 2020-04-10 23:05:39 ascEnable on
setstate ASC_Device 2020-04-10 23:05:39 controlShading off
setstate ASC_Device 2020-04-10 23:05:39 hardLockOut off
setstate ASC_Device 2020-04-10 23:29:45 room_unsorted Rollladen_01_Ki,Rollladen_02_Flur
setstate ASC_Device 2020-04-10 23:05:39 selfDefense off
setstate ASC_Device 2020-04-10 23:29:48 state created new drive timer
setstate ASC_Device 2020-04-10 23:05:39 sunriseTimeWeHoliday off
setstate ASC_Device 2020-04-10 23:29:45 userAttrList rolled out

defmod Rollladen_01_Ki ZWave dacfd218 4
attr Rollladen_01_Ki userattr ASC_Adv:on,off ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforDayOpen ASC_BlockingTime_beforNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Down:time,astro,brightness,roommate ASC_DriveUpMaxDuration ASC_Drive_Delay ASC_Drive_DelayStart ASC_ExternalTrigger ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownValue_beforeNightClose ASC_PrivacyDown_Pos ASC_PrivacyUpValue_beforeDayOpen ASC_PrivacyUp_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Mode:absent,gone,off ASC_Shading_InOutAzimuth ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_SunnyCloudy ASC_Shading_WaitingPeriod ASC_Shutter_IdleDetection ASC_ShuttersPlace:window,terrace ASC_Sleep_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness,roommate ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate
attr Rollladen_01_Ki ASC 2
attr Rollladen_01_Ki ASC_Pos_Reading position
attr Rollladen_01_Ki IODev ZWDongle_0
attr Rollladen_01_Ki classes MULTI_CHANNEL_ASSOCIATION MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION POWERLEVEL METER SWITCH_MULTILEVEL SENSOR_MULTILEVEL SWITCH_BINARY MANUFACTURER_PROPRIETARY PROTECTION MARK METER SENSOR_MULTILEVEL MANUFACTURER_PROPRIETARY SCENE_ACTIVATION SWITCH_MULTILEVEL SWITCH_BINARY
attr Rollladen_01_Ki vclasses ASSOCIATION:2 CONFIGURATION:1 MANUFACTURER_PROPRIETARY:1 MANUFACTURER_SPECIFIC:1 METER:2 MULTI_CHANNEL_ASSOCIATION:2 POWERLEVEL:1 PROTECTION:2 SCENE_ACTIVATION:1 SENSOR_MULTILEVEL:2 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:1

setstate Rollladen_01_Ki associationAdd 3 1
setstate Rollladen_01_Ki 2020-04-10 23:29:29 .ASC_AttrUpdateChanges_v0.8.26 1
setstate Rollladen_01_Ki 2020-04-10 23:06:49 ASC_Enable on
setstate Rollladen_01_Ki 2020-04-10 23:29:48 ASC_Time_DriveDown 11.04.2020 - 20:07
setstate Rollladen_01_Ki 2020-04-10 23:29:48 ASC_Time_DriveUp 11.04.2020 - 06:46
setstate Rollladen_01_Ki 2020-04-10 23:00:09 assocGroup_1 Max 16 Nodes ZWDongle_0
setstate Rollladen_01_Ki 2020-04-10 23:00:09 assocGroup_2 Max 16 Nodes
setstate Rollladen_01_Ki 2020-04-10 23:00:10 assocGroup_3 Max 1 Nodes ZWDongle_0
setstate Rollladen_01_Ki 2020-04-10 23:00:09 assocGroups 3
setstate Rollladen_01_Ki 2020-04-10 23:29:45 associatedWith ASC_Device
setstate Rollladen_01_Ki 2020-04-10 23:00:13 configEnergyReports 10
setstate Rollladen_01_Ki 2020-04-10 23:00:13 configInRollerBlindModeOrVenetianBlind17 10
setstate Rollladen_01_Ki 2020-04-10 23:00:13 configInVenetianBlindModeTheParameter12 150
setstate Rollladen_01_Ki 2020-04-10 23:00:18 configManagingLamellasInResponseTo35 SetLamellasToTheirExtreme1
setstate Rollladen_01_Ki 2020-04-10 23:00:18 configMotorOperationDetection 10
setstate Rollladen_01_Ki 2020-04-10 23:00:18 configMotorOperationTime 240
setstate Rollladen_01_Ki 2020-04-10 23:00:18 configPeriodicPowerOrEnergyReports 3600
setstate Rollladen_01_Ki 2020-04-10 23:00:18 configPowerReports 10
setstate Rollladen_01_Ki 2020-04-10 23:00:23 configReportsType BlindPositionReportsSentToThe1
setstate Rollladen_01_Ki 2020-04-10 23:00:23 configResponseToFloodingAlarm NoReaction
setstate Rollladen_01_Ki 2020-04-10 23:00:23 configResponseToGeneralAlarm CloseBlind
setstate Rollladen_01_Ki 2020-04-10 23:00:24 configResponseToSmokeCOOrCO2Alarm OpenBlind
setstate Rollladen_01_Ki 2020-04-10 23:00:24 configResponseToTemperatu