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
ZitatDas 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
Zitat von: chris1284 am 28 Juli 2018, 21:44:09
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.

Zitat von: chris1284 am 28 Juli 2018, 21:49:07
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.

Zitat von: chris1284 am 28 Juli 2018, 21:49:07
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
Zitatdie 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!

Zitat von: rudolfkoenig am 29 Juli 2018, 11:41:08
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.


Zitat von: rudolfkoenig am 29 Juli 2018, 11:41:08
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
ZitatIch 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
ZitatIst 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
Zitat von: rudolfkoenig am 29 Juli 2018, 14:29:33
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
Zitat von: FunkOdyssey am 30 Juli 2018, 23:07: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.


Zitat von: FunkOdyssey am 30 Juli 2018, 23:07:51
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
Zitat 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?

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/.

Zitat von: FunkOdyssey am 17 August 2018, 16:13:53
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.

Zitat von: pipp37 am 18 August 2018, 10:50:50
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.


Zitat von: pipp37 am 18 August 2018, 10:50:50
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
Zitat 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?

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
Zitat von: supernova1963 am 25 August 2018, 10:18:40

       
  • 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
Zitat von: Loredo am 16 September 2018, 13:13: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.

Zitat von: Loredo am 16 September 2018, 13:13:06
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
Zitat von: Shojo am 16 September 2018, 16:03:06
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"


Zitat von: FunkOdyssey am 16 September 2018, 16:19:17
Ich nutze die ganz aktuelle Version und habe folgende Ausgabe im FHEM-Log:

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

Zitat von: FunkOdyssey am 16 September 2018, 16:19:17
Ich ahne es schon. Die neue 99_DockerImageInfo.pm wird wahrscheinlich gar nicht automatisch eingespielt.

Nope, wird aktualisiert.

Zitat von: FunkOdyssey am 16 September 2018, 16:19:17
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
Zitat von: Loredo am 16 September 2018, 20:44:42
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 directory
Was 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
Zitat von: devil77 am 11 Oktober 2018, 09:11:08
ich bekommen bei mir immer folgende Meldung im log
sort: cannot read: '/image_info.*': No such file or directory
Was 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
Zitat von: hoppel118 am 29 Oktober 2018, 22:37:52
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.


Zitat von: hoppel118 am 29 Oktober 2018, 22:37:522. 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.

Zitat von: hoppel118 am 29 Oktober 2018, 22:37:523. 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).

Zitat von: hoppel118 am 29 Oktober 2018, 22:37:524. 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.

Zitat von: hoppel118 am 29 Oktober 2018, 22:37:525. 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
Zitat von: The-Holgi am 19 November 2018, 10:44:34
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



Zitat von: The-Holgi am 19 November 2018, 10:44:34
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
Zitat von: The-Holgi am 20 November 2018, 11:20:44
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
Zitat von: Wernieman am 23 November 2018, 19:41:27
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:

ZitatDas 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
Zitat von: The-Holgi am 13 Dezember 2018, 19:46:15
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)


Zitat von: The-Holgi am 13 Dezember 2018, 19:46:15
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
Zitat von: Loredo am 18 Dezember 2018, 10:17:22

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
Zitat von: Loredo am 19 Dezember 2018, 11:25: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-galaktisch
Dann 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
Zitat 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

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


Zitat von: Wernieman am 09 Januar 2019, 18:15:54
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
Zitat 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.

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
Zitat 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.

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).

Zitat von: FunkOdyssey am 15 Januar 2019, 18:58:34
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 :-)


Zitat von: FunkOdyssey am 15 Januar 2019, 18:58:34
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.


Zitat von: FunkOdyssey am 15 Januar 2019, 18:58:34
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
Zitat von: WumpE am 18 Januar 2019, 12:30:48
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
Zitat von: Mike70 am 20 Januar 2019, 12:05:20
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
Zitat von: Loredo am 20 Januar 2019, 12:10:29
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
Zitat von: ulli am 25 Januar 2019, 19:57:48
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
Zitat von: Loredo am 26 Januar 2019, 09:22:35

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
Zitat von: M.Schulze am 26 Januar 2019, 11:25:21
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
Zitat von: nightstorm99 am 09 Januar 2019, 17:10:55Jetzt 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?

Zitat 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
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
Zitat von: Holzlenkrad am 27 Januar 2019, 05:49:40
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!


Zitat von: Holzlenkrad am 27 Januar 2019, 05:49:40Inwiefern 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
Zitat von: geohem am 27 Januar 2019, 09:42:18
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
Zitat 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" ?

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
Zitat 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

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
Zitat von: Loredo am 26 Januar 2019, 18:20:13
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
Zitat 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!


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.


Zitat von: GammaTwin am 30 Januar 2019, 21:14:46
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
Zitat 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!

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
Zitat von: beddo am 31 Januar 2019, 10:46:12
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.


Zitat von: Wernieman am 31 Januar 2019, 12:09:14
@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
Zitat von: Loredo am 31 Januar 2019, 12:31:07

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
Zitat von: eisler am 19 Februar 2019, 07:54:30
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  :'(


Zitat von: Schlimbo am 17 Februar 2019, 08:53:13
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


Zitat 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?


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
Zitat von: Loredo am 19 Februar 2019, 17:01:26
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
Zitat von: ulli am 02 März 2019, 16:17:31
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
Zitat von: Loredo am 04 März 2019, 12:06:34

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

Zitat 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".


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,
Zitat von: beddo am 05 März 2019, 11:46:08
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
Zitat 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?

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
Zitat 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.


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.


Zitat von: patlabor am 10 März 2019, 19:29:47
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
Zitat 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?

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
Zitat von: Loredo am 10 März 2019, 23:04:10

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
Zitat 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#



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


Zitat 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



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
Zitat von: adnan am 21 März 2019, 08:16:15
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:


Zitat von: arallon am 29 März 2019, 20:29:26
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
Zitat 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.

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


Ja, läuft beides einwandfrei.
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
Zitat von: nanocosmos am 05 April 2019, 07:19:42
Danke für Deine Antwort!

Ich glaube mittlerweile, dass meine Fhem Config an mehreren Stellen (z.B. bei Telegram) durch den Umzug ein wenig durcheinander geraten ist.
Versuche aktuell den ursprünglichen Zustand wieder herzustellen. [emoji4]
Es funktioniert jetzt wieder mit Telegram und msgDialog, aber es ist sehr langsam. Dauert teilweise 10 Sekunden bis der Bot seine Antwort schickt.
Geht es euch auch so?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Loredo am 06 April 2019, 10:40:31
Zitat von: druschba am 05 April 2019, 19:49:29
ich habe das Problem, dass der Docker Container jeden Tag zur selben Zeit neu startet.


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


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


Nope. Die Ursache ist sicherlich nicht bei Docker an und für sich zu suchen.
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
Zitat 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?


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
Zitat von: Wernieman am 20 April 2019, 20:35:26Eventuell 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
Zitat von: kotaro am 20 April 2019, 22:58:45
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
Zitat von: Holzlenkrad am 21 April 2019, 03:55:46

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.


Zitat von: nightstorm99 am 21 April 2019, 08:13:59
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
Zitat 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.

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
Zitat 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.

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
Zitat 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.

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
Zitat von: kotaro am 21 April 2019, 19:53:46
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
Zitat von: Loredo am 21 April 2019, 12:17:38
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
Zitat von: kadettilac89 am 21 April 2019, 20:00:12
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
Zitat von: kadettilac89 am 21 April 2019, 20:00:12
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
Zitat von: Holzlenkrad am 21 April 2019, 20:24:13
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
Zitat von: kotaro am 21 April 2019, 20:27:56

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
Zitat von: kadettilac89 am 21 April 2019, 20:55: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
Zitat von: Loredo am 22 April 2019, 09:06:14
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
Zitat von: wolfram am 25 April 2019, 07:36:22
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
Zitat von: waschbaerbauch am 24 April 2019, 17:43:13
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
Zitat von: wolfram am 25 April 2019, 13:55:42
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
Zitat 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

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
Zitat von: kotaro am 26 April 2019, 14:56:12
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.


Zitat von: thotti70 am 27 April 2019, 02:12:29
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

Zitat 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.


.....


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
Zitat 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.

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
Zitat 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.

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
Zitat von: Holzlenkrad am 28 April 2019, 04:00:56
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
Zitat 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.


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
Zitat von: wolfram am 28 April 2019, 15:33:00
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
Zitat von: LuckyLuis am 28 April 2019, 12:00:59
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
Zitat von: thotti70 am 30 April 2019, 00:20:32
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
Zitat 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?


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,

Zitat von: Loredo am 07 Mai 2019, 15:43:59
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
Zitat von: Loredo am 07 Mai 2019, 17:38:10
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
Zitat 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 ??

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!=1
Can'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/63
1. 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
Zitat von: Wernieman am 08 Mai 2019, 16:30:54
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:
Zitat von: Tobias am 03 Mai 2019, 09:30:42
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
Zitat von: eisler am 08 Mai 2019, 16:56:37
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.

Zitat von: Schlimbo am 09 Mai 2019, 05:47:14
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.

Zitat 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 (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
Zitat von: Loredo am 11 Mai 2019, 10:14:06
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
Zitat von: kjmEjfu am 11 Mai 2019, 16:23: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
Zitat von: kotaro am 12 Mai 2019, 00:21:08
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
Zitat von: Loredo am 12 Mai 2019, 09:46:20

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
Zitat von: kotaro am 12 Mai 2019, 10:39:36
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
Zitat von: Loredo am 12 Mai 2019, 11:04:41

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
Zitat 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.

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.pm
in 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
Zitat2019.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
Zitat von: KraxelHuber am 16 Mai 2019, 21:13:16
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.


Zitat von: antonwinden am 17 Mai 2019, 18:54:42
Kann es sein das
attr global exclude_from_update 88_VantagePro2.pm
in 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
Zitat 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?

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
ZitatAlso "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
Zitat 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.

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
Zitat von: kadettilac89 am 18 Mai 2019, 21:55:12
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
Zitat 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.


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.


Zitat von: Holzlenkrad am 18 Mai 2019, 22:01:48
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
Zitat 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.

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
Zitat von: sn0000py am 09 Juli 2019, 09:30:16
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
Zitat 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
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
Zitat 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.
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
Zitat von: kadettilac89 am 09 Juli 2019, 19:15:45
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
Zitat von: volschin am 09 Juli 2019, 20:28:19
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
Zitat 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

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
Zitat von: volschin am 09 Juli 2019, 19:39:26
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
Zitat 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?


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
Zitat von: kadettilac89 am 09 Juli 2019, 12:10:59
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
Zitat von: Loredo am 10 Juli 2019, 12:32:37
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
Zitat von: Loredo am 10 Juli 2019, 18:58:17

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
Zitat 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 (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
Zitat von: Loredo am 14 Juli 2019, 10:55:53

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
Zitat von: kadettilac89 am 09 Juli 2019, 20:52:35
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
Zitat von: volschin am 14 Juli 2019, 11:05:39
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
Zitat von: Loredo am 14 Juli 2019, 11:27:50

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
Zitat von: plin am 14 Juli 2019, 19:11:09
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
Zitat von: Loredo am 15 Juli 2019, 10:15:07
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

Zitat 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


@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
Zitat von: Dirk070 am 17 Juli 2019, 16:04:03
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.


Zitat von: Master_Nick am 18 Juli 2019, 09:20:48
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
Zitat von: Master_Nick am 18 Juli 2019, 09:20:48

*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
Zitat von: Master_Nick am 19 Juli 2019, 12:28:02
@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
Zitat von: Loredo am 19 Juli 2019, 10:44:28

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:

Zitat2019.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
Zitatsudo 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
Zitat 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

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
Zitat 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

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
Zitat 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 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
Zitat von: Master_Nick am 23 Juli 2019, 16:43:46
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
Zitat von: Master_Nick am 23 Juli 2019, 11:36:50
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
Zitat von: Master_Nick am 22 Juli 2019, 11:50:10

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.


Zitat von: kotaro am 23 Juli 2019, 14:10:26ich 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).


Zitat von: Master_Nick am 23 Juli 2019, 16:43:46Ich 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
Zitat von: Loredo am 24 Juli 2019, 11:53:15
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 ;-)


Zitat 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.

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
Zitat von: Master_Nick am 24 Juli 2019, 09:12:24
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
Zitat von: Master_Nick am 25 Juli 2019, 08:46:35
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
Zitat von: Master_Nick am 25 Juli 2019, 13:55:05
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).


Zitat von: Master_Nick am 26 Juli 2019, 11:13:16
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).


Zitat von: Master_Nick am 26 Juli 2019, 11:13:16
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.


Zitat von: PatrickR am 27 Juli 2019, 01:28:14
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!

Zitat von: Loredo am 27 Juli 2019, 12:38:51
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!

Zitat 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.
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!

Zitat von: Loredo am 28 Juli 2019, 11:40:32
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!

Zitat von: Loredo am 29 Juli 2019, 18:47:59
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
Zitat 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..?
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
Zitat 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..?


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!

Zitat 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.

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
Zitat 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


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.


Zitat von: PatrickR am 30 Juli 2019, 20:52:04
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
Zitat von: Loredo am 01 August 2019, 13:20:58
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!

Zitat von: Loredo am 01 August 2019, 13:20:58
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:
Zitat2019.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
Zitat 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 :(

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
Zitat von: Dirk070 am 13 August 2019, 16:39:36
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
Zitat 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.

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
Zitat 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.


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!

Zitat von: Loredo am 14 September 2019, 08:37:30
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
Zitat von: kadettilac89 am 16 September 2019, 13:16:18
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
Zitat von: Loredo am 17 September 2019, 17:51:46
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 :

ZitatPerl 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
ZitatMoin

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.

ZitatBesser 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
Zitat von: Karflyer am 11 Oktober 2019, 18:29:00
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
Zitat von: Loredo am 10 Juli 2019, 18:58:17

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
Zitat von: persching am 02 November 2019, 22:08:39

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
Zitat 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:

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).

Zitat von: persching am 03 November 2019, 17:42:56
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
Zitat von: ManOki am 04 November 2019, 10:41:29
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
Zitat 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.

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
Zitat von: Jackson am 08 Dezember 2019, 21:45:20
, "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
Zitat 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.

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
Zitat von: persching am 10 Dezember 2019, 17:20:02
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
Zitat 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 ...

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
Zitat 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?


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.


Zitat von: Master_Nick am 06 Dezember 2019, 10:58:47Wobei 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.


Zitat von: OdfFhem am 08 Dezember 2019, 18:08:10Statt 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
Zitat von: Wernieman am 13 Dezember 2019, 09:06:17
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:
Zitatroot@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
Zitat von: Wernieman am 16 Dezember 2019, 18:49:32
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




ZitatAllerdings .. 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
Zitat 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


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
Zitat von: Ranseyer am 16 Dezember 2019, 19:11:43

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
ZitatDa 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
ZitatTeste 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
Zitat 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
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: AlpenFlizzer 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
Zitat 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 :-(


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
Zitat von: kadettilac89 am 30 Dezember 2019, 13:22:00
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
Zitat von: Jackson am 08 Dezember 2019, 21:45:20
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
Zitat von: SB am 27 Dezember 2019, 16:39:26
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
Zitat von: ch.eick am 30 Dezember 2019, 14:51:35
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
Zitat 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 !
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
Zitat 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

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
Zitat 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

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
Zitat von: ch.eick am 31 Dezember 2019, 11:54:08
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
Zitat 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.

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
Zitat 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?

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
Zitat von: Loredo am 03 Januar 2020, 18:16:41
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
Zitat 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.

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
Zitat von: Loredo am 02 Juni 2019, 14:53:57
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
Zitat von: Loredo am 05 Januar 2020, 11:24:43
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
Zitat von: eddso am 06 Januar 2020, 21:15:27
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
Zitat 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.

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
Zitat von: Wernieman am 13 Januar 2020, 21:56:26
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
Zitat 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?
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
Zitat von: kadettilac89 am 14 Januar 2020, 10:39:18
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
Zitat 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! :(

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
Zitat 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!

Kann sein wenn er den Host anpingen will aber nicht findet ...

Zitat 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: 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
Zitat 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

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
Zitat von: guhu am 27 Januar 2020, 12:46:23
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
Zitat von: kadettilac89 am 27 Januar 2020, 14:24:59
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
Zitat von: guhu am 27 Januar 2020, 14:46:48
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
Zitat von: kadettilac89 am 27 Januar 2020, 16:21:09
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
Zitat von: guhu am 27 Januar 2020, 12:46:23
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
Zitat 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.

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
Zitat 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]

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
Zitat von: P.A.Trick am 28 Januar 2020, 18:12:41
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
Zitat 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.

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
Zitat von: MCh76 am 29 Januar 2020, 07:12:28
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
Zitat 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 ..

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)


ZitatVerbindungsaufbau 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
Zitat 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?
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
ZitatIntel 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
Zitat von: mumpitzstuff am 31 Januar 2020, 16:40:32
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
Zitat 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 ...


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
Zitat von: balli1187 am 10 Februar 2020, 12:31:00
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
Zitat 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 ;-)
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?

Zitat 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 ...
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
Zitat von: fallenguru am 16 Februar 2020, 15:51:09
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.


Zitat von: Wernieman am 16 Februar 2020, 16:42:35
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
Zitat von: Wernieman am 16 Februar 2020, 18:22:44
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

Zitat2020.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
Zitat von: Sille am 18 Februar 2020, 08:52:52
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 ...
ZitatDort ist das Netzwerk "host"
Zitatports:
      - 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
Zitat 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
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
Zitat 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 ^^

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
Zitat 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..
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
Zitat 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
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
Zitat von: volschin am 19 Februar 2020, 22:47:49
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
Zitat von: balli1187 am 16 Februar 2020, 17:20:31
- 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.

Zitat von: balli1187 am 16 Februar 2020, 17:20:31
- 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".

Zitat von: Loredo am 17 Februar 2020, 00:02:21
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.

Zitat von: Loredo am 17 Februar 2020, 00:02:21
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
Zitater 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
Zitat von: fallenguru am 26 Februar 2020, 15:32:39
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.

ZitatErwartet 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.

Zitates 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
Zitat von: fallenguru am 26 Februar 2020, 15:32:39
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
Zitat 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

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
Zitat 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

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
Zitat 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.
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
Zitat von: P.A.Trick am 16 März 2020, 15:26:49
... 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
Zitat von: plin am 16 März 2020, 15:31:57
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
Zitat von: P.A.Trick am 16 März 2020, 15:39:58
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
Zitat von: Wernieman am 16 März 2020, 16:11:14
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
Zitat 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

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
Zitat von: P.A.Trick am 16 März 2020, 19:35:42
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
Zitat von: nanocosmos am 20 März 2020, 14:50:13
...
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:
ZitatIn 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
Zitat 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
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
Zitat von: maci am 23 März 2020, 12:18:59
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
Zitat von: maci am 23 März 2020, 12:18:59
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
Zitat von: nanocosmos am 23 März 2020, 18:16:05
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 pi
und 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
Zitat von: Typ1er am 03 April 2020, 01:49:20
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
Zitat 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?
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
Zitat 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?
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
Zitat von: volschin am 03 April 2020, 09:19:36
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
Zitat von: thm12345 am 03 April 2020, 09:14:34
Hier kann ich aber nicht mit "-p" die Ports umlenken. Also habe ich eine vorkonfigurierte fhem.cfg in Verzeichnis für fhem_test abgelegt.

Zitat von: thm12345 am 03 April 2020, 14:40:52
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
Zitat von: kadettilac89 am 03 April 2020, 16:39:21
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  :).

Zitat 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.

Ö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
Zitat von: Dirk070 am 04 April 2020, 18:54:57
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
Zitat von: pas am 05 April 2020, 23:00:44
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
Zitat von: pas am 05 April 2020, 23:00:44
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
Zitat 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?!

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
Zitat 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)}
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 configResponseToTemperatureAlarm OpenBlind
setstate Rollladen_01_Ki 2020-04-10 23:00:24 configRollerShutterOperatingModes 1RollerBlindModeWithPositioning
setstate Rollladen_01_Ki 2020-04-10 23:00:24 configScenesAssociationsActivation AssociationsActivation
setstate Rollladen_01_Ki 2020-04-10 23:00:24 configSelfMeasurement SelfMeasurementInactive
setstate Rollladen_01_Ki 2020-04-10 23:00:24 configSetLamellasBackToPrevious13 1LamellasReturnToPreviouslySet1
setstate Rollladen_01_Ki 2020-04-10 23:00:24 configSwitchType ToggleSwitches
setstate Rollladen_01_Ki 2020-04-10 23:00:24 energy 1.13 kWh
setstate Rollladen_01_Ki 2020-04-10 23:00:24 mcaGroups 2
setstate Rollladen_01_Ki 2020-04-10 23:00:24 mca_1 Max 7 Nodes ZWDongle_0
setstate Rollladen_01_Ki 2020-04-10 23:00:24 mca_2 Max 7
setstate Rollladen_01_Ki 2020-04-10 23:00:02 model FIBARO System FGRM222 Roller Shutter Controller 2
setstate Rollladen_01_Ki 2020-04-10 23:00:02 modelConfig fibaro/fgrm222.xml
setstate Rollladen_01_Ki 2020-04-10 23:00:02 modelId 010f-0302-1000
setstate Rollladen_01_Ki 2020-04-10 23:00:29 neighborList ZWDongle_0 UNKNOWN_2 UNKNOWN_3 UNKNOWN_5 UNKNOWN_6 UNKNOWN_7 UNKNOWN_8 UNKNOWN_9 UNKNOWN_11
setstate Rollladen_01_Ki 2020-04-10 23:11:18 pct 99
setstate Rollladen_01_Ki 2020-04-10 23:05:22 position 99
setstate Rollladen_01_Ki 2020-04-10 23:00:38 powerlvl current 0 remain 0
setstate Rollladen_01_Ki 2020-04-10 23:00:02 state associationAdd 3 1
setstate Rollladen_01_Ki 2020-04-10 23:05:22 timeToAck 0.031
setstate Rollladen_01_Ki 2020-04-10 23:05:22 transmit OK

defmod Rollladen_02_Flur ZWave dacfd218 8
attr Rollladen_02_Flur 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_02_Flur ASC 2
attr Rollladen_02_Flur ASC_Pos_Reading position
attr Rollladen_02_Flur IODev ZWDongle_0
attr Rollladen_02_Flur 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_02_Flur 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_02_Flur associationAdd 3 1
setstate Rollladen_02_Flur 2020-04-10 23:29:29 .ASC_AttrUpdateChanges_v0.8.26 1
setstate Rollladen_02_Flur 2020-04-10 23:06:49 ASC_Enable on
setstate Rollladen_02_Flur 2020-04-10 23:29:48 ASC_Time_DriveDown 11.04.2020 - 20:07
setstate Rollladen_02_Flur 2020-04-10 23:29:48 ASC_Time_DriveUp 11.04.2020 - 06:46
setstate Rollladen_02_Flur 2020-04-10 23:03:48 assocGroup_1 Max 16 Nodes ZWDongle_0
setstate Rollladen_02_Flur 2020-04-10 23:03:48 assocGroup_2 Max 16 Nodes
setstate Rollladen_02_Flur 2020-04-10 23:03:48 assocGroup_3 Max 1 Nodes ZWDongle_0
setstate Rollladen_02_Flur 2020-04-10 23:03:48 assocGroups 3
setstate Rollladen_02_Flur 2020-04-10 23:29:45 associatedWith ASC_Device
setstate Rollladen_02_Flur 2020-04-10 23:03:52 configEnergyReports 10
setstate Rollladen_02_Flur 2020-04-10 23:03:52 configInRollerBlindModeOrVenetianBlind17 10
setstate Rollladen_02_Flur 2020-04-10 23:03:52 configInVenetianBlindModeTheParameter12 150
setstate Rollladen_02_Flur 2020-04-10 23:03:57 configManagingLamellasInResponseTo35 SetLamellasToTheirExtreme1
setstate Rollladen_02_Flur 2020-04-10 23:03:57 configMotorOperationDetection 10
setstate Rollladen_02_Flur 2020-04-10 23:03:57 configMotorOperationTime 240
setstate Rollladen_02_Flur 2020-04-10 23:03:57 configPeriodicPowerOrEnergyReports 3600
setstate Rollladen_02_Flur 2020-04-10 23:03:57 configPowerReports 10
setstate Rollladen_02_Flur 2020-04-10 23:04:02 configReportsType BlindPositionReportsSentToThe1
setstate Rollladen_02_Flur 2020-04-10 23:04:02 configResponseToFloodingAlarm NoReaction
setstate Rollladen_02_Flur 2020-04-10 23:04:02 configResponseToGeneralAlarm CloseBlind
setstate Rollladen_02_Flur 2020-04-10 23:04:02 configResponseToSmokeCOOrCO2Alarm OpenBlind
setstate Rollladen_02_Flur 2020-04-10 23:04:02 configResponseToTemperatureAlarm OpenBlind
setstate Rollladen_02_Flur 2020-04-10 23:04:02 configRollerShutterOperatingModes 1RollerBlindModeWithPositioning
setstate Rollladen_02_Flur 2020-04-10 23:04:03 configScenesAssociationsActivation AssociationsActivation
setstate Rollladen_02_Flur 2020-04-10 23:04:03 configSelfMeasurement SelfMeasurementInactive
setstate Rollladen_02_Flur 2020-04-10 23:04:03 configSetLamellasBackToPrevious13 1LamellasReturnToPreviouslySet1
setstate Rollladen_02_Flur 2020-04-10 23:04:03 configSwitchType ToggleSwitches
setstate Rollladen_02_Flur 2020-04-10 23:04:03 mcaGroups 2
setstate Rollladen_02_Flur 2020-04-10 23:04:03 mca_1 Max 7 Nodes ZWDongle_0
setstate Rollladen_02_Flur 2020-04-10 23:04:03 mca_2 Max 7
setstate Rollladen_02_Flur 2020-04-10 23:03:43 model FIBARO System FGRM222 Roller Shutter Controller 2
setstate Rollladen_02_Flur 2020-04-10 23:03:43 modelConfig fibaro/fgrm222.xml
setstate Rollladen_02_Flur 2020-04-10 23:03:43 modelId 010f-0302-1000
setstate Rollladen_02_Flur 2020-04-10 23:04:08 neighborList ZWDongle_0 UNKNOWN_2 UNKNOWN_3 Rollladen_01_Ki UNKNOWN_5 UNKNOWN_6 UNKNOWN_7 UNKNOWN_9 UNKNOWN_10 UNKNOWN_11
setstate Rollladen_02_Flur 2020-04-10 23:11:18 pct 99
setstate Rollladen_02_Flur 2020-04-10 23:04:11 position 99
setstate Rollladen_02_Flur 2020-04-10 23:04:22 powerlvl current 0 remain 0
setstate Rollladen_02_Flur 2020-04-10 23:03:43 state associationAdd 3 1
setstate Rollladen_02_Flur 2020-04-10 23:04:22 timeToAck 0.030
setstate Rollladen_02_Flur 2020-04-10 23:04:22 transmit OK


Hier die fhem.cfg vom Docker:
attr global userattr ASC:0,1,2 cmdIcon devStateIcon:textField-long devStateStyle genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock homebridgeMapping:textField-long icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global commandref modular
attr global dnsServer 192.168.178.5
attr global logfile ./log/fhem-%Y-%m-%d.log
attr global modpath .
attr global motd SecurityCheck:\
  telnetPort is not password protected\
  WEB is not password protected\
\
Protect this FHEM installation by defining an allowed device with define allowed allowed\
You can disable this message with attr global motd none
attr global mseclog 1
attr global nofork 0
attr global pidfilename ./log/fhem.pid
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define WEB FHEMWEB 8083 global
setuuid WEB 5e90b39c-f33f-58cd-655b-e23a1d2946c89aab

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m-%d.log fakelog
setuuid Logfile 5e90b39c-f33f-58cd-e195-37fd87c3cdb858b9

define autocreate autocreate
setuuid autocreate 5e90b39c-f33f-58cd-7726-546791e91b545765
attr autocreate filelog ./log/%NAME-%Y.log

define eventTypes eventTypes ./log/eventTypes.txt
setuuid eventTypes 5e90b39c-f33f-58cd-fbe9-e922d46ef55619b6

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 5e90b39c-f33f-58cd-b637-b8efad7fea64e5aa
define DockerImageInfo DockerImageInfo
setuuid DockerImageInfo 5e90b39c-f33f-58cd-ab64-f25ff4d3f2598fee
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
setuuid fhemServerApt 5e90b39c-f33f-58cd-b088-743e264173118a96
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 fhemServerNpm npmjs localhost
setuuid fhemServerNpm 5e90b39c-f33f-58cd-03fc-16c9f048e670438a
attr fhemServerNpm alias Node.js Package Update Status
attr fhemServerNpm devStateIcon npm.updates.available:security@red:outdated npm.is.up.to.date:security@green:outdated .*npm.outdated.*in.progress:system_fhem_reboot@orange .*in.progress:system_fhem_update@orange warning.*:message_attention@orange error.*:message_attention@red
attr fhemServerNpm group Update
attr fhemServerNpm icon npm-old
attr fhemServerNpm room System
define fhemInstaller Installer
setuuid fhemInstaller 5e90b39d-f33f-58cd-2e60-48b0a4ea81448d65
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
define telnetPort telnet 7072
setuuid telnetPort 5e90b39d-f33f-58cd-0e2d-d31c1dcd9cf4dbd5
define ZWDongle_0 ZWDongle /dev/ttyACM0@115200
setuuid ZWDongle_0 5e90b39f-f33f-58cd-0fc9-f9f8cf40929dd0c8
attr ZWDongle_0 homeId dacfd218
define Rollladen_01_Ki ZWave dacfd218 4
setuuid Rollladen_01_Ki 5e90ddf4-f33f-58cd-95c4-07719d78d8d7b053
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
define Rollladen_02_Flur ZWave dacfd218 8
setuuid Rollladen_02_Flur 5e90dee0-f33f-58cd-27d6-caef63182538f5e5
attr Rollladen_02_Flur 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_02_Flur ASC 2
attr Rollladen_02_Flur ASC_Pos_Reading position
attr Rollladen_02_Flur IODev ZWDongle_0
attr Rollladen_02_Flur 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_02_Flur 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
define ASC_Device AutoShuttersControl
setuuid ASC_Device 5e90dfa3-f33f-58cd-cd40-cc842c4e02de70d1
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


Angehängt noch das Logfile, vor dem Update sind noch ein paar Perl Fehler:
2020.04.10 19:57:47.967 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2020.04.10 19:57:47.968 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2020.04.10 19:57:47.968 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2020.04.10 19:57:47.968 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2020.04.10 19:57:47.971 1: Including fhem.cfg
2020.04.10 19:57:48.234 3: WEB: port 8083 opened
2020.04.10 19:57:48.265 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2020.04.10 19:57:48.638 3: AptToDate (fhemServerApt) - defined
2020.04.10 19:57:49.300 3: telnetPort: port 7072 opened
2020.04.10 19:57:49.300 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2020.04.10 19:57:49.300 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2020.04.10 19:57:49.301 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2020.04.10 19:57:49.301 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2020.04.10 19:57:50.640 1: usb create starting
2020.04.10 19:57:51.054 3: Probing CUL device /dev/ttyACM0
2020.04.10 19:57:51.391 3: Probing TCM_ESP3 device /dev/ttyACM0
2020.04.10 19:57:51.529 3: Probing ZWDongle device /dev/ttyACM0
2020.04.10 19:57:51.667 1: define ZWDongle_0 ZWDongle /dev/ttyACM0@115200
2020.04.10 19:57:51.683 3: Opening ZWDongle_0 device /dev/ttyACM0
2020.04.10 19:57:51.684 3: Setting ZWDongle_0 serial parameters to 115200,8,N,1
2020.04.10 19:57:52.763 3: ZWDongle_0 device opened
2020.04.10 19:57:52.764 1: MKDIR restoreDir/save/2020-04-10
2020.04.10 19:57:52.765 1: copy ./log/fhem.save ./restoreDir/save/2020-04-10/./log/fhem.save failed:No such file or directory
2020.04.10 19:57:52.767 1: usb create end
2020.04.10 19:57:52.768 0: Featurelevel: 6
2020.04.10 19:57:52.768 0: Server started with 12 defined entities (fhem.pl:21573/2020-04-01 perl:5.028001 os:linux user:fhem pid:4095)
2020.04.10 22:58:28.864 2: AttrTemplates: got 154 entries
2020.04.10 23:00:01.203 3: ZWave get Rollladen_01_Ki model
2020.04.10 23:00:02.175 3: ZWave got config for fibaro/fgrm222.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
2020.04.10 23:00:02.176 3: ZWave set Rollladen_01_Ki associationAdd 3 1
2020.04.10 23:00:05.955 3: ZWave: downloading http://fhem.de/deviceimages/zwave//271.770.4096_fgr222.roller.shutter.controller.jpg for 010f-0302-1000
2020.04.10 23:00:09.841 3: ZWave get Rollladen_01_Ki associationGroups
2020.04.10 23:00:09.885 3: ZWave get Rollladen_01_Ki association 1
2020.04.10 23:00:09.929 3: ZWave get Rollladen_01_Ki association 2
2020.04.10 23:00:09.974 3: ZWave get Rollladen_01_Ki association 3
2020.04.10 23:00:13.509 3: ZWave get Rollladen_01_Ki configEnergyReports
2020.04.10 23:00:13.511 3: ZWave get Rollladen_01_Ki configInRollerBlindModeOrVenetianBlind17
2020.04.10 23:00:13.512 3: ZWave get Rollladen_01_Ki configInVenetianBlindModeTheParameter12
2020.04.10 23:00:13.513 3: ZWave get Rollladen_01_Ki configLocalProtection
2020.04.10 23:00:13.513 3: ZWave get Rollladen_01_Ki configManagingLamellasInResponseTo35
2020.04.10 23:00:13.514 3: ZWave get Rollladen_01_Ki configMotorOperationDetection
2020.04.10 23:00:13.514 3: ZWave get Rollladen_01_Ki configMotorOperationTime
2020.04.10 23:00:13.515 3: ZWave get Rollladen_01_Ki configPeriodicPowerOrEnergyReports
2020.04.10 23:00:13.515 3: ZWave get Rollladen_01_Ki configPowerReports
2020.04.10 23:00:13.516 3: ZWave get Rollladen_01_Ki configRFProtectionRadioProtection
2020.04.10 23:00:13.516 3: ZWave get Rollladen_01_Ki configReportsType
2020.04.10 23:00:13.517 3: ZWave get Rollladen_01_Ki configResponseToFloodingAlarm
2020.04.10 23:00:13.518 3: ZWave get Rollladen_01_Ki configResponseToGeneralAlarm
2020.04.10 23:00:13.518 3: ZWave get Rollladen_01_Ki configResponseToSmokeCOOrCO2Alarm
2020.04.10 23:00:13.519 3: ZWave get Rollladen_01_Ki configResponseToTemperatureAlarm
2020.04.10 23:00:13.519 3: ZWave get Rollladen_01_Ki configRollerShutterOperatingModes
2020.04.10 23:00:13.520 3: ZWave get Rollladen_01_Ki configScenesAssociationsActivation
2020.04.10 23:00:13.520 3: ZWave get Rollladen_01_Ki configSelfMeasurement
2020.04.10 23:00:13.521 3: ZWave get Rollladen_01_Ki configSetLamellasBackToPrevious13
2020.04.10 23:00:13.522 3: ZWave get Rollladen_01_Ki configSwitchType
2020.04.10 23:00:18.642 2: ZWave: No ACK from Rollladen_01_Ki after 5s for sentackget:130403700501250a
2020.04.10 23:00:18.785 3: ZWave get Rollladen_01_Ki mcaGroupings
2020.04.10 23:00:22.430 3: ZWave get Rollladen_01_Ki meter
2020.04.10 23:00:23.863 2: ZWave: No ACK from Rollladen_01_Ki after 5s for sentackget:1304037005022510
2020.04.10 23:00:24.340 3: ZWave get Rollladen_01_Ki mca 1
2020.04.10 23:00:24.431 3: ZWave get Rollladen_01_Ki mca 2
2020.04.10 23:00:34.333 3: ZWave get Rollladen_01_Ki position
2020.04.10 23:00:38.383 3: ZWave get Rollladen_01_Ki powerlevel
2020.04.10 23:00:43.176 3: ZWave get Rollladen_01_Ki versionClass ASSOCIATION
2020.04.10 23:00:43.178 3: ZWave get Rollladen_01_Ki versionClass CONFIGURATION
2020.04.10 23:00:43.179 3: ZWave get Rollladen_01_Ki versionClass MANUFACTURER_PROPRIETARY
2020.04.10 23:00:43.180 3: ZWave get Rollladen_01_Ki versionClass MANUFACTURER_SPECIFIC
2020.04.10 23:00:43.181 3: ZWave get Rollladen_01_Ki versionClass METER
2020.04.10 23:00:43.181 3: ZWave get Rollladen_01_Ki versionClass MULTI_CHANNEL_ASSOCIATION
2020.04.10 23:00:43.182 3: ZWave get Rollladen_01_Ki versionClass POWERLEVEL
2020.04.10 23:00:43.183 3: ZWave get Rollladen_01_Ki versionClass PROTECTION
2020.04.10 23:00:43.184 3: ZWave get Rollladen_01_Ki versionClass SCENE_ACTIVATION
2020.04.10 23:00:43.184 3: ZWave get Rollladen_01_Ki versionClass SENSOR_MULTILEVEL
2020.04.10 23:00:43.185 3: ZWave get Rollladen_01_Ki versionClass SWITCH_BINARY
2020.04.10 23:00:43.186 3: ZWave get Rollladen_01_Ki versionClass SWITCH_MULTILEVEL
2020.04.10 23:00:43.187 3: ZWave get Rollladen_01_Ki versionClass VERSION
2020.04.10 23:03:43.280 3: ZWave get Rollladen_02_Flur model
2020.04.10 23:03:43.372 3: ZWave set Rollladen_02_Flur associationAdd 3 1
2020.04.10 23:03:48.005 3: ZWave get Rollladen_02_Flur associationGroups
2020.04.10 23:03:48.050 3: ZWave get Rollladen_02_Flur association 1
2020.04.10 23:03:48.095 3: ZWave get Rollladen_02_Flur association 2
2020.04.10 23:03:48.139 3: ZWave get Rollladen_02_Flur association 3
2020.04.10 23:03:52.348 3: ZWave get Rollladen_02_Flur configEnergyReports
2020.04.10 23:03:52.350 3: ZWave get Rollladen_02_Flur configInRollerBlindModeOrVenetianBlind17
2020.04.10 23:03:52.351 3: ZWave get Rollladen_02_Flur configInVenetianBlindModeTheParameter12
2020.04.10 23:03:52.352 3: ZWave get Rollladen_02_Flur configLocalProtection
2020.04.10 23:03:52.352 3: ZWave get Rollladen_02_Flur configManagingLamellasInResponseTo35
2020.04.10 23:03:52.353 3: ZWave get Rollladen_02_Flur configMotorOperationDetection
2020.04.10 23:03:52.353 3: ZWave get Rollladen_02_Flur configMotorOperationTime
2020.04.10 23:03:52.354 3: ZWave get Rollladen_02_Flur configPeriodicPowerOrEnergyReports
2020.04.10 23:03:52.354 3: ZWave get Rollladen_02_Flur configPowerReports
2020.04.10 23:03:52.355 3: ZWave get Rollladen_02_Flur configRFProtectionRadioProtection
2020.04.10 23:03:52.356 3: ZWave get Rollladen_02_Flur configReportsType
2020.04.10 23:03:52.356 3: ZWave get Rollladen_02_Flur configResponseToFloodingAlarm
2020.04.10 23:03:52.357 3: ZWave get Rollladen_02_Flur configResponseToGeneralAlarm
2020.04.10 23:03:52.357 3: ZWave get Rollladen_02_Flur configResponseToSmokeCOOrCO2Alarm
2020.04.10 23:03:52.358 3: ZWave get Rollladen_02_Flur configResponseToTemperatureAlarm
2020.04.10 23:03:52.359 3: ZWave get Rollladen_02_Flur configRollerShutterOperatingModes
2020.04.10 23:03:52.359 3: ZWave get Rollladen_02_Flur configScenesAssociationsActivation
2020.04.10 23:03:52.360 3: ZWave get Rollladen_02_Flur configSelfMeasurement
2020.04.10 23:03:52.360 3: ZWave get Rollladen_02_Flur configSetLamellasBackToPrevious13
2020.04.10 23:03:52.361 3: ZWave get Rollladen_02_Flur configSwitchType
2020.04.10 23:03:57.481 2: ZWave: No ACK from Rollladen_02_Flur after 5s for sentackget:1308037005012537
2020.04.10 23:04:01.675 3: ZWave get Rollladen_02_Flur mcaGroupings
2020.04.10 23:04:02.702 2: ZWave: No ACK from Rollladen_02_Flur after 5s for sentackget:130803700502253d
2020.04.10 23:04:03.183 3: ZWave get Rollladen_02_Flur mca 1
2020.04.10 23:04:03.229 3: ZWave get Rollladen_02_Flur mca 2
2020.04.10 23:04:11.732 3: ZWave get Rollladen_02_Flur position
2020.04.10 23:04:17.942 3: ZWave get Rollladen_02_Flur versionClass ASSOCIATION
2020.04.10 23:04:17.945 3: ZWave get Rollladen_02_Flur versionClass CONFIGURATION
2020.04.10 23:04:17.945 3: ZWave get Rollladen_02_Flur versionClass MANUFACTURER_PROPRIETARY
2020.04.10 23:04:17.946 3: ZWave get Rollladen_02_Flur versionClass MANUFACTURER_SPECIFIC
2020.04.10 23:04:17.947 3: ZWave get Rollladen_02_Flur versionClass METER
2020.04.10 23:04:17.948 3: ZWave get Rollladen_02_Flur versionClass MULTI_CHANNEL_ASSOCIATION
2020.04.10 23:04:17.948 3: ZWave get Rollladen_02_Flur versionClass POWERLEVEL
2020.04.10 23:04:17.949 3: ZWave get Rollladen_02_Flur versionClass PROTECTION
2020.04.10 23:04:17.950 3: ZWave get Rollladen_02_Flur versionClass SCENE_ACTIVATION
2020.04.10 23:04:17.951 3: ZWave get Rollladen_02_Flur versionClass SENSOR_MULTILEVEL
2020.04.10 23:04:17.952 3: ZWave get Rollladen_02_Flur versionClass SWITCH_BINARY
2020.04.10 23:04:17.952 3: ZWave get Rollladen_02_Flur versionClass SWITCH_MULTILEVEL
2020.04.10 23:04:17.953 3: ZWave get Rollladen_02_Flur versionClass VERSION
2020.04.10 23:04:22.318 3: ZWave get Rollladen_02_Flur powerlevel
2020.04.10 23:05:22.744 3: ZWave get Rollladen_01_Ki position
2020.04.10 23:05:39.482 3: AutoShuttersControl (ASC_Device) - defined

ASC_DEBUG!!! 2020.04.10 23:06:49 - FnIsDay: Rollladen_01_Ki Allgemein: 0

ASC_DEBUG!!! 2020.04.10 23:06:49 - FnIsDay: Rollladen_02_Flur Allgemein: 0

ASC_DEBUG!!! 2020.04.10 23:11:15 - FnIsDay: Rollladen_01_Ki Allgemein: 0

ASC_DEBUG!!! 2020.04.10 23:11:15 - FnIsDay: Rollladen_02_Flur Allgemein: 0
2020.04.10 23:12:17.107 3: AutoShuttersControl (ASC_Device) - delete device ASC_Device
2020.04.10 23:12:17.142 3: Sub AptToDate (fhemServerApt) - delete device fhemServerApt
2020.04.10 23:12:17.143 1: DockerImageInfo is against deletion (HASH(0x5642c7bcdd08)), continuing with rereadcfg anyway
Use of uninitialized value $nfile in string ne at fhem.pl line 981.
Use of uninitialized value $currlogfile in string eq at fhem.pl line 1413.
Use of uninitialized value $currlogfile in concatenation (.) or string at fhem.pl line 1422.
Use of uninitialized value $currlogfile in concatenation (.) or string at fhem.pl line 1422.
2020.04.10 23:12:17 1: PERL WARNING: Use of uninitialized value $nfile in string ne at fhem.pl line 981.
Use of uninitialized value $currlogfile in string eq at fhem.pl line 1413.
Use of uninitialized value $currlogfile in concatenation (.) or string at fhem.pl line 1422.
Use of uninitialized value $currlogfile in concatenation (.) or string at fhem.pl line 1422.
2020.04.10 23:12:17 1: PERL WARNING: Use of uninitialized value $currlogfile in string eq at fhem.pl line 1413.
Use of uninitialized value $currlogfile in string eq at fhem.pl line 1413.
Use of uninitialized value $currlogfile in concatenation (.) or string at fhem.pl line 1422.
Use of uninitialized value $currlogfile in concatenation (.) or string at fhem.pl line 1422.
2020.04.10 23:12:17 1: PERL WARNING: Use of uninitialized value $currlogfile in concatenation (.) or string at fhem.pl line 1422.
2020.04.10 23:12:17 3: logfile is readonly, it is set in the FHEM_GLOBALATTR environment
2020.04.10 23:12:17.149 1: Including fhem.cfg
2020.04.10 23:12:17.154 3: WEB: port 8083 opened
2020.04.10 23:12:17.156 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2020.04.10 23:12:17.322 3: AptToDate (fhemServerApt) - defined
2020.04.10 23:12:17.326 3: telnetPort: port 7072 opened
2020.04.10 23:12:17.327 3: Opening ZWDongle_0 device /dev/ttyACM0
2020.04.10 23:12:17.328 3: Setting ZWDongle_0 serial parameters to 115200,8,N,1
2020.04.10 23:12:18.408 3: ZWDongle_0 device opened
2020.04.10 23:12:18.414 3: AutoShuttersControl (ASC_Device) - defined
2020.04.10 23:12:18.415 1: Including ./log/fhem.save
2020.04.10 23:12:18.428 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2020.04.10 23:12:18.429 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2020.04.10 23:12:18.429 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2020.04.10 23:12:18.429 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1

ASC_DEBUG!!! 2020.04.10 23:12:19 - FnIsDay: Rollladen_01_Ki Allgemein: 0

ASC_DEBUG!!! 2020.04.10 23:12:19 - FnIsDay: Rollladen_02_Flur Allgemein: 0
2020.04.10 23:12:19.672 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9

ASC_DEBUG!!! 2020.04.10 23:14:39 - FnIsDay: Rollladen_01_Ki Allgemein: 0

ASC_DEBUG!!! 2020.04.10 23:14:39 - FnIsDay: Rollladen_02_Flur Allgemein: 0
2020.04.10 23:29:04.306 1: Downloading https://fhem.de/fhemupdate/controls_fhem.txt
2020.04.10 23:29:04.679 1: UPD ./CHANGED
2020.04.10 23:29:04.783 1: UPD FHEM/00_MQTT2_CLIENT.pm
2020.04.10 23:29:04.830 1: UPD FHEM/00_MQTT2_SERVER.pm
2020.04.10 23:29:04.878 1: UPD FHEM/00_SIGNALduino.pm
2020.04.10 23:29:04.928 1: UPD FHEM/14_SD_UT.pm
2020.04.10 23:29:04.981 1: UPD FHEM/14_SD_WS.pm
2020.04.10 23:29:05.021 1: UPD FHEM/14_SD_WS09.pm
2020.04.10 23:29:05.066 1: UPD FHEM/37_echodevice.pm
2020.04.10 23:29:05.136 1: UPD FHEM/70_DENON_AVR.pm
2020.04.10 23:29:05.199 1: UPD FHEM/70_HYDRAWISE.pm
2020.04.10 23:29:05.238 1: UPD FHEM/73_AutoShuttersControl.pm
2020.04.10 23:29:05.297 1: UPD FHEM/90_SIGNALduino_un.pm
2020.04.10 23:29:05.338 1: UPD FHEM/93_Log2Syslog.pm
2020.04.10 23:29:05.397 1: UPD FHEM/98_readingsWatcher.pm
2020.04.10 23:29:05.442 1: UPD FHEM/lib/SD_ProtocolData.pm
2020.04.10 23:29:05.529 1: UPD www/pgm2/fhemweb.js
2020.04.10 23:29:05.569 1: saving fhem.cfg
2020.04.10 23:29:05.569 1: saving ./log/fhem.save
2020.04.10 23:29:05.577 1:
2020.04.10 23:29:05.578 1: New entries in the CHANGED file:
2020.04.10 23:29:05.578 1:  - bugfix: 70_DENON_AVR: fixed HTTP 403 (thx justme1968)
2020.04.10 23:29:05.579 1:  - bugfix : 73_AutoShuttersControl: fix shading drive if current position under
2020.04.10 23:29:05.581 1:                                     shading position
2020.04.10 23:29:05.581 1:  - feature: 37_echodevice.pm
2020.04.10 23:29:05.582 1:      CHANGE:  Keepalive aktiviert
2020.04.10 23:29:05.583 1:      BUG:     set "NPM_login new"
2020.04.10 23:29:05.583 1:      FEATURE: Unterstützung A3RBAYBE7VM004 ECHO Studio
2020.04.10 23:29:05.583 1:               Unterstützung A3SSG6GR8UU7SN ECHO SUB
2020.04.10 23:29:05.584 1:               Unterstützung A1HNT9YTOBE735 Telekom Smart Speaker
2020.04.10 23:29:05.584 1:               set sounds: (Sounds gemäß Routine-Übersicht)
2020.04.10 23:29:05.584 1:  - feature: 14_SD_UT.pm
2020.04.10 23:29:05.584 1:      new model Momento
2020.04.10 23:29:05.585 1:  - bugfix: 14_SD_WS_09.pm: WindDirAverage
2020.04.10 23:29:05.585 1:  - feature: 14_SD_WS_09.pm: support for WH2315
2020.04.10 23:29:05.585 1:  - feature: 14_SD_UT.pm
2020.04.10 23:29:05.586 1:      new model Novy_840039
2020.04.10 23:29:05.586 1:      new remote control xavax 00111939
2020.04.10 23:29:05.586 1:      new remote control with 4 buttons for diesel heating
2020.04.10 23:29:05.587 1:  - change: 14_SD_UT.pm
2020.04.10 23:29:05.587 1:      model Novy_840039, rename button text power_button to power_on_off
2020.04.10 23:29:05.587 1:      remove sort option
2020.04.10 23:29:05.587 1:  - bugfix: 14_SD_UT.pm
2020.04.10 23:29:05.587 1:      fix UTClock for all models
2020.04.10 23:29:05.588 1:      TR-502MSV bugfix, ident was only 8 bit, must be 12 bit long
2020.04.10 23:29:05.588 1:      RC_10 button set all work after renaming the device
2020.04.10 23:29:05.588 1:  - featire: SD_ProtocolData.pm v1.1.7
2020.04.10 23:29:05.588 1: ... rest of lines skipped.
2020.04.10 23:29:05.589 1: Calling /usr/bin/perl ./contrib/commandref_modular.pl, this may take a while
2020.04.10 23:29:05.785 1:
2020.04.10 23:29:05.786 1: update finished, "shutdown restart" is needed to activate the changes.
2020.04.10 23:29:05.786 1:
2020.04.10 23:29:05.787 1: Please consider using the global attribute sendStatistics
2020.04.10 23:29:17.967 0: Server shutdown
2020.04.10 23:29:21.013 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2020.04.10 23:29:21.013 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2020.04.10 23:29:21.013 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2020.04.10 23:29:21.013 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2020.04.10 23:29:21.017 1: Including fhem.cfg
2020.04.10 23:29:21.269 3: WEB: port 8083 opened
2020.04.10 23:29:21.395 2: eventTypes: loaded 6 events from ./log/eventTypes.txt
2020.04.10 23:29:21.811 3: AptToDate (fhemServerApt) - defined
2020.04.10 23:29:22.541 3: telnetPort: port 7072 opened
2020.04.10 23:29:22.584 3: Opening ZWDongle_0 device /dev/ttyACM0
2020.04.10 23:29:22.612 3: Setting ZWDongle_0 serial parameters to 115200,8,N,1
2020.04.10 23:29:23.691 3: ZWDongle_0 device opened
2020.04.10 23:29:24.125 3: AutoShuttersControl (ASC_Device) - defined
2020.04.10 23:29:24.126 1: Including ./log/fhem.save
2020.04.10 23:29:24.138 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2020.04.10 23:29:24.139 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2020.04.10 23:29:24.139 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2020.04.10 23:29:24.139 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2020.04.10 23:29:26.440 1: usb create starting
2020.04.10 23:29:26.640 1: usb create end

ASC_DEBUG!!! 2020.04.10 23:29:26 - FnIsDay: Rollladen_01_Ki Allgemein: 0

ASC_DEBUG!!! 2020.04.10 23:29:26 - FnIsDay: Rollladen_02_Flur Allgemein: 0
2020.04.10 23:29:26.728 0: Featurelevel: 6
2020.04.10 23:29:26.728 0: Server started with 15 defined entities (fhem.pl:21573/2020-04-01 perl:5.028001 os:linux user:fhem pid:26144)
2020.04.10 23:29:26.729 2: ZWDongle_ProcessSendStack: no ACK, resending message 0107000301020100f9
2020.04.10 23:29:29.215 3: ZWave got config for fibaro/fgrm222.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
2020.04.10 23:29:29.306 2: AttrTemplates: got 154 entries

ASC_DEBUG!!! 2020.04.10 23:29:45 - FnIsDay: Rollladen_01_Ki Allgemein: 0

ASC_DEBUG!!! 2020.04.10 23:29:45 - FnIsDay: Rollladen_02_Flur Allgemein: 0


Ich hoffe mir kann einer damit helfen,
Danke Typ1er
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 11 April 2020, 00:27:32
Also ich sehe nur überall die no ack vom zwave. Mit ASC hat das wohl nichts zu tun.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 11 April 2020, 00:57:49
die NoAck Meldung kommen vom Zwave Dongle, spielen fürs ASC keine Rolle, die kommen vom Auslesen der config, Habe die get Befehle zu schnell hintereinander ausgeführt, Trotzdem läuft das ASC nicht. Mit oder Ohne ZwaveDongle.


Edit:
Mann kann auch einfach 2 Dummys anlegen, gibt den per setreading eine Wert für pct und dann ist der Fehler derselbe. Am Pi geht es. Eine Fehlermeldung erscheint nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 11 April 2020, 08:39:32
Synology war ja mal eine Zeit lang gruselig mit seiner Docker-Unterstützung hinterher. Welche Version hast Du denn laufen? Denn am Image liegt es wohl weniger.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 11 April 2020, 09:19:44
Docker version 18.09.8, build 2c0a67b auf der DS918+


Ergänzung auf einem Pi im Docker geht das ASC auch nicht, es scheint irgend was zu fehlen.

dort ist die Version aktuell:
pi@raspberrypi:~ $ docker -v
Docker version 19.03.8, build afacb8b
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 11 April 2020, 09:56:27
Mach mal ein list vom ASC und zeige mal ob er die Rollos gefunden hat.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 11 April 2020, 10:40:39
Internals:
   CFGFN     
   FUUID      5e917608-f33f-a315-dbf6-0532e16119d36052
   FVERSION   73_AutoShuttersControl.pm:v0.8.26-s21634/2020-04-10 TESTING
   MID        da39a3ee5e6b4b0d3255bfef95601890afd80709
   NAME       ASC_Device
   NOTIFYDEV  global,ASC_Device,Rollladen_01_Dummy,Rollladen_02_Dummy
   NR         47
   NTFY_ORDER 51-ASC_Device
   STATE      created new drive timer
   TYPE       AutoShuttersControl
   VERSION    v0.8.26
   READINGS:
     2020-04-11 09:47:55   Rollladen_01_Dummy_nextAstroTimeEvent 11.04.2020 - 20:09
     2020-04-11 09:47:55   Rollladen_02_Dummy_nextAstroTimeEvent 11.04.2020 - 20:09
     2020-04-11 09:47:20   ascEnable       on
     2020-04-11 09:47:20   controlShading  off
     2020-04-11 09:47:20   hardLockOut     off
     2020-04-11 09:47:52   room_unsorted   Rollladen_01_Dummy,Rollladen_02_Dummy
     2020-04-11 09:47:20   selfDefense     off
     2020-04-11 09:47:55   state           created new drive timer
     2020-04-11 09:47:20   sunriseTimeWeHoliday off
     2020-04-11 09:47:52   userAttrList    rolled out
   helper:
     shuttersList:
       Rollladen_01_Dummy
       Rollladen_02_Dummy
Attributes:
   ASC_expert 1
   devStateIcon { AutoShuttersControl_DevStateIcon($name) }
   icon       fts_shutter_automatic
   room       ASC
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 11 April 2020, 10:45:17
Stehen beide sauber drin

helper:
     shuttersList:
       Rollladen_01_Dummy
       Rollladen_02_Dummy

Scheint also eher ein Problem im auslesen zu sein. Eventuell wegen schleifen oder so.

Zeiten scheinen auch im

     2020-04-11 09:47:55   Rollladen_01_Dummy_nextAstroTimeEvent 11.04.2020 - 20:09
     2020-04-11 09:47:55   Rollladen_02_Dummy_nextAstroTimeEvent 11.04.2020 - 20:09
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 12 April 2020, 02:17:06
Da der Fehler nicht weg ist und ich das ASC eines meiner Hauptfunktionen sind in FHEM, habe ich weiter rum probiert.
Einen neuen Container angelegt mit einem alternativen Image.

ein Wunder, das erste mal ohne Fehler auf dem NAS  ;D ;D

ich habe vom Joscha Middendorf https://github.com/JoschaMiddendorf/fhem-docker das Image für Docker installiert:
docker run -d --name FHEM-Testsystem -p 8084:8083 -v /volume1/docker/fhem2/:/opt/fhem -e FHEM_UID=1026 -e FHEM_GID=100 -e TZ=Europe/Berlin diggewuff/fhem-docker


Hier ist der Fehler verschwunden. Es scheint so als ob ein Paket fehlt und ich möchte gern bei der Fehlersuche helfen, da ich ja scheinbar der einzige bin mit dem Fehler.
Reicht es in den  2 Dockerfiles, alle Paket zu vergleichen?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 12 April 2020, 05:58:17
Es ist ziemlich sicher, das kein Paket fehlt. Bei mir läuft ASC und bei vermutlich einigen weiteren ebenfalls. Ich habe zwar ein paar Zusatzpakete am Start. Die haben jedoch nichts mit ASC zu tun.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: majestro84 am 12 April 2020, 10:12:13
Bei mir läuft der fhem docker auch mit ASC und fibaro Roller shutter ohne Probleme. Pakete habe ich zusätzlich bis auf gcali keine einzigen.
Schöne Ostern
VG Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Typ1er am 12 April 2020, 11:29:00
habe jetzt aus dem einen Dockerfiledie  apt-get listen drüber gebügelt, seitdem ist der Fehler weg, werde die Tage mal testen welches Paket das ist, heute hab erstmal keine Zeit zum testen.

apt-get install apt-transport-https bluez build-essential curl dfu-programmer etherwake git perl python snmp sox sqlite3 sudo usbutils wget

und diese:

apt-get install libalgorithm-merge-perl libauthen-oath-perl libavahi-compat-libdnssd-dev libcgi-pm-perl libclass-dbi-mysql-perl libclass-isa-perl libcommon-sense-perl libconvert-base32-perl libcrypt-cbc-perl libcrypt-ecb-perl libcrypt-urandom-perl libdata-dump-perl libdatetime-format-strptime-perl libdbd-sqlite3-perl libdbi-perl libdevice-serialport-perl libdpkg-perl liberror-perl libfile-copy-recursive-perl libfile-fcntllock-perl libgd-graph-perl libgd-text-perl libhtml-tableextract-perl libimage-info-perl libimage-librsvg-perl libio-socket-inet6-perl libio-socket-ip-perl libio-socket-multicast-perl libio-socket-ssl-perl libio-socket-timeout-perl libjson-perl libjson-xs-perl liblist-moreutils-perl libmail-imapclient-perl libmail-sendmail-perl libmime-base64-perl libmodule-pluggable-perl libnet-sip-perl libnet-telnet-perl librpc-xml-perl libsoap-lite-perl libsocket-perl libsocket6-perl libsox-fmt-mp3 libswitch-perl libsys-hostname-long-perl libsys-statistics-linux-perl libterm-readkey-perl libterm-readline-perl-perl libtext-csv-perl libtext-diff-perl libtimedate-perl libwww-perl libxml-simple-perl

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 12 April 2020, 11:52:59
Sollte der Fehler in der Tat von ASC kommen
wären Kandidaten:
libdatetime-format-strptime-perl
und die ganzen json packete.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schlimbo am 20 April 2020, 20:44:05
Hallo Loredo,

Könntest du bitte noch die Abhängigkeiten für das MusicCast Modul "71_YAMAHA_MC.pm" aufnehmen:
https://forum.fhem.de/index.php/topic,98383.msg917227.html#msg917227

https://fhem.de/commandref.html#YAMAHA_MC

Bekomme aktuell folgenden Fehler:
2020.04.20 20:11:14.008 0: Can't locate Net/UPnP/AV/MediaRenderer.pm in @INC (you may need to install the Net::UPnP::AV::MediaRenderer module)

Gruß Schlimbo
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 21 April 2020, 14:55:30
Wenn der Autor bzw. Maintainer sich mal zur Pflege der Requirements in der Commandref hätte hinreißen lassen. Ich sehe dort nur json oder guck ich schief?

Du brauchst es ja nur im entsprechenden Parameter als zusätzliches Modul zu definieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schlimbo am 29 April 2020, 23:31:33
Hallo zusammen,

habe gerade versucht die Abhängigkeiten für MusicCast über den Parameter APT_PKGS anzufügen:
- APT_PKGS="libnet-upnp-perl
Jedoch wird dies scheinbar nicht installiert, gibt es hier eine Möglichkeit zu prüfen weshalb es nicht installiert wird?
Im Docker log könnte ich hierzu nichts finden.
Preparing initial start:
1. Adding custom APT packages to container ...
2. Updating existing FHEM installation in /opt/fhem
Preparing user environment ...

Ist es möglich dass Loglevel zu verändern damit ich hier mehr Information bekomme?

Geh ich direkt über die Konsole des Containers und installiere es im über:

docker exec -i -t fhem_fhem_1 /bin/bash
sudo apt-get install -y libnet-upnp-perl

Klappt es. Liegt es evtl. an den Parameter "-y"?
Kann man bei APT_PKGS auch irgendwie diesen Parameter mit übergeben?

Gruß Schlimbo
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schlimbo am 29 April 2020, 23:40:24
Zitat von: volschin am 21 April 2020, 14:55:30
Wenn der Autor bzw. Maintainer sich mal zur Pflege der Requirements in der Commandref hätte hinreißen lassen. Ich sehe dort nur json oder guck ich schief?
Nein, da guckst du nicht schief,
habe den Modulentwickler geben dies zu aktualisieren.
Zitat von: Leugi am 25 April 2020, 19:52:20
Hallo Schlimbo,

gute Idee werde ich mit in der Commandref aufnehmen.

Gruß,
Leugi
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: derstinker am 10 Mai 2020, 19:51:24
Hallo in die Runde,

bis dato ein stiller und dankbarer Mitleser aber jetzt muss ich euch doch mal bemühen. Folgendes Phänomen nach einem Speicherupgrade fährt mein Container mit folgendem Fehlerlog hoch:


Preparing user environment ...,
1. Creating group 'fhem' with GID 6061 ...,
groupadd: existing lock file /etc/gshadow.lock without a PID,
groupadd: cannot lock /etc/gshadow; try again later.,
2. Enforcing GID for group 'bluetooth' to 6001 ...,
3. Creating user 'fhem' with UID 6061 ...,
useradd: existing lock file /etc/gshadow.lock without a PID,
useradd: cannot lock /etc/gshadow; try again later.,
usermod: group '6061' does not exist,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
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 ...,
groupadd: existing lock file /etc/gshadow.lock without a PID,
groupadd: cannot lock /etc/gshadow; try again later.,
adduser: The user `fhem' does not exist.,
chown: invalid user: '.gpio',
9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...,
adduser: The user `fhem' does not exist.,
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' ...,
chown: invalid user: 'fhem.fhem',
,
,
,
Preparing configuration ... done,
,
Starting FHEM ...,
su: user fhem does not exist,
Unable to start FHEM process - errorcode 1,


Zur Umgebung: Docker läuft in einem Debian Container auf einer Virtualisierung (Proxmox).

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 10 Mai 2020, 20:07:13
Zitat von: derstinker am 10 Mai 2020, 19:51:24
Hallo in die Runde,

bis dato ein stiller und dankbarer Mitleser aber jetzt muss ich euch doch mal bemühen. Folgendes Phänomen nach einem Speicherupgrade fährt mein Container mit folgendem Fehlerlog hoch:


Preparing user environment ...,
1. Creating group 'fhem' with GID 6061 ...,
groupadd: existing lock file /etc/gshadow.lock without a PID,
groupadd: cannot lock /etc/gshadow; try again later.,
2. Enforcing GID for group 'bluetooth' to 6001 ...,
3. Creating user 'fhem' with UID 6061 ...,
useradd: existing lock file /etc/gshadow.lock without a PID,
useradd: cannot lock /etc/gshadow; try again later.,
usermod: group '6061' does not exist,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
adduser: The user `fhem' does not exist.,
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 ...,
groupadd: existing lock file /etc/gshadow.lock without a PID,
groupadd: cannot lock /etc/gshadow; try again later.,
adduser: The user `fhem' does not exist.,
chown: invalid user: '.gpio',
9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...,
adduser: The user `fhem' does not exist.,
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' ...,
chown: invalid user: 'fhem.fhem',
,
,
,
Preparing configuration ... done,
,
Starting FHEM ...,
su: user fhem does not exist,
Unable to start FHEM process - errorcode 1,


Zur Umgebung: Docker läuft in einem Debian Container auf einer Virtualisierung (Proxmox).


Stoppe den Container, lösche ihn und lass ihn neu anlegen. Dann sollte das weg sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: derstinker am 10 Mai 2020, 20:13:34
Zitat von: P.A.Trick am 10 Mai 2020, 20:07:13

Stoppe den Container, lösche ihn und lass ihn neu anlegen. Dann sollte das weg sein.

manchmal kann es so einfach sein... :-) Danke!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 11 Mai 2020, 20:41:29
Hi zusammen,
ich habe meinen HM-CFG-USB2 jetzt für die Plattform amd64 dockerized. Falls jemand Interesse hat, habe ich das Image auch bei Docker-Hub (https://hub.docker.com/r/volschin/hmcfgusb) abgelegt.

Grüße
Veit
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 18 Mai 2020, 11:50:22
hallo mal ein blöde Frage

Im Moment nutze ich einen Unraid Server (also Linux) wo ich im Docker das FHEM laufen lassen - schleuse da nur 2 USB Geräte durch.

Da ich nun bald einen schnelleren Windows 10 Pro Rechner bekomme - ist die Frage.

Würde dort FHEM auch ohne Probleme laufen (da es ja LINUX ist) also laufen wirds vermutlich aber auch gut?
Kann ich die einstellungen und die Settings sogar 1:1 vom aktuellen Unraid server verwenden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 18 Mai 2020, 11:59:39
Da unter Docker ist eigentlich die darunter liegende Plattform egal ... eigentlich ...

Was ich nicht weiß: Wie gut das USB-durchreichen bei Docker und Windows läuft .... deshalb das obige "eigentlich"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 18 Mai 2020, 13:07:14
Zitat von: sn0000py am 18 Mai 2020, 11:50:22
Da ich nun bald einen schnelleren Windows 10 Pro Rechner bekomme - ist die Frage.

Würde dort FHEM auch ohne Probleme laufen (da es ja LINUX ist) also laufen wirds vermutlich aber auch gut?
Kann ich die einstellungen und die Settings sogar 1:1 vom aktuellen Unraid server verwenden?

Fhem-Docker unter Windows nicht. Fhem läuft unter Perl, das geht auch in Windows. Dennoch rate ich davon ab. Sobald du Probleme hast wird es schwer Hilfe zu erhalten. Nahezu 100% der Installationen sind auf Linux.

Beispiele ... unternschiedliche Art Verzeichnisse anzusprechen, USB-Ports ... Da wird auch eine 1:1 Kopie der Config nicht gehen. Du könntest hier zumindest per RAW-Import Device für Device einspielen.

Empfehlung ist aber ganz klar, lasse Fhem auf Linux. Ggf. auch in einer Virutal Machine die auf dem neuen Server läuft. Die kann ja klein sein und braucht wenig Resourcen. Wenn du dennoch an Windows festhalten willst, kannst du ja eine VM mit Windows 10 aufsetzen und da versuchen Fhem einzurichten. Wenn du das hinkriegst, kannst du die Config später von Windows zu Windows übernehmen.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 18 Mai 2020, 14:35:07
Okay also sehe ich das korrekt das ich wenn ich Docker am Win 10 installiere ich da die Linux Container nicht laufen lassen kann bzw schon laufen lassen kann, aber viele container nicht richtig funktionieren werden?
Kann ich dann in einer VM eine Linux Maschine mit Docker laufen lassen? Wo ich dann mehrere Container laufen lasse?

HAbe ja noch das mariaDB, deconz, Grafana (und einige andere Docker Container)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 18 Mai 2020, 14:52:03
Zitat von: sn0000py am 18 Mai 2020, 14:35:07
Okay also sehe ich das korrekt das ich wenn ich Docker am Win 10 installiere ich da die Linux Container nicht laufen lassen kann bzw schon laufen lassen kann, aber viele container nicht richtig funktionieren werden?
Kann ich dann in einer VM eine Linux Maschine mit Docker laufen lassen? Wo ich dann mehrere Container laufen lasse?

HAbe ja noch das mariaDB, deconz, Grafana (und einige andere Docker Container)

Technisch reicht die Docker-Infrastructure die Prozesse an den Host durch, darum hat Docker kaum Overhead. Bedingung dafür ist, dass HOst und Docker die selbe Architektur haben. Linux Container auf Linux Host wobei es auf den Kernel ankommt, Windows Docker auf Windows Host ... Linux Docker auf Windows Host geht nicht.

VM geht. Einfach in der VM Debian installieren und dann Docker darin installieren. Ich habe auch VW-Workstation auf meinem Notebook und da läuft permanent eine oder mehrere kleine Linux-VM. Vorteil du kannst ganz einfach Backup der VM machen (zumindest in VM Workstation).

Edit, es gibt noch eine Einschränkung. CPU-Typ muss auch identisch sein, Docker von ARM funktioniert nicht auf HOst mit AMD64.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 18 Mai 2020, 14:56:42
Aber prinzipiell gehen schon Linux Container am Docker ... irgendwo habe ich in Erinnerung das mit Win10 un dem neuen Docker dort das gehen sollte - wie gut ist eine andere Frage - aber prinzipiell gehen sollte es oder?

Oder verwechsel ich da etwas?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 18 Mai 2020, 14:57:05
Das stimmt so nicht. Mit Docker Desktop funktioniert das auch mit Linux via Subsystem. Allerdings fängt es dann bei Docker compose Dateien schon an, schwieriger zu werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 18 Mai 2020, 15:00:09
Auch die Aussage, dass die Hostarchitektur identisch sein muss, ist falsch. Ich lasse auch ARM-Images auf einem Intel NUC laufen. Kein Problem mehr.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 18 Mai 2020, 15:04:54
Zitat von: volschin am 18 Mai 2020, 14:57:05
Das stimmt so nicht. Mit Docker Desktop funktioniert das auch mit Linux via Subsystem. Allerdings fängt es dann bei Docker compose Dateien schon an, schwieriger zu werden.
Was meinst du mit Docker Compose Dateuen?

Würde man so direkt im Windows Docker dann diesen FHEM Container lauffähig bringen?
Oder sollte man den umweg über eine Linux VM gehen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 18 Mai 2020, 15:08:24
Lies einfach mal etwas Doku.

https://docs.docker.com/docker-for-windows/install/
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 18 Mai 2020, 15:41:50
das linux subsystem ist über hyper-v eine virtualisierung. natürlich geht das auch irgendwie da ja dann docker wieder auf linux läuft. arm geht auch über qemu-emulatoren, jedoch ist es dennoch empfehlenswert die entsrechenden container zu nutzen wenn verfügbar.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 08:17:57
Moin,

Ich habe hier  https://www.edureka.co/community/10588/how-can-i-run-a-docker-exec-command-inside-a-docker-container (https://www.edureka.co/community/10588/how-can-i-run-a-docker-exec-command-inside-a-docker-container) gelesen, dass es eigentlich funktionieren sollte eine Docker-Kommando (Docker exec, Docker ps) in einem Container auszuführen.

Wenn ich das im FHEM-Container (via Shell in portainer) probiere, erhalte ich jedoch die Fehlermeldung, dass der Befehl nicht bekannt ist.
Liegt das am Container oder gibt es außer dem docker.sock noch was zu beachten?


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 20 Mai 2020, 08:24:29
Zitat von: balli1187 am 20 Mai 2020, 08:17:57
Moin,

Ich habe hier  https://www.edureka.co/community/10588/how-can-i-run-a-docker-exec-command-inside-a-docker-container (https://www.edureka.co/community/10588/how-can-i-run-a-docker-exec-command-inside-a-docker-container) gelesen, dass es eigentlich funktionieren sollte eine Docker-Kommando (Docker exec, Docker ps) in einem Container auszuführen.

Wenn ich das im FHEM-Container (via Shell in portainer) probiere, erhalte ich jedoch die Fehlermeldung, dass der Befehl nicht bekannt ist.
Liegt das am Container oder gibt es außer dem docker.sock noch was zu beachten?


Gesendet von iPhone mit Tapatalk

Hast du deinen User der Gruppe docker hinzugefügt?

sudo usermod -a -G docker $USER

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 09:26:09
Zitat von: P.A.Trick am 20 Mai 2020, 08:24:29
Hast du deinen User der Gruppe docker hinzugefügt?

sudo usermod -a -G docker $USER

Du meinst auf dem Host?
Es liegt ggf. an meinem QNAP aber dort habe ich keine gruppe "docker", wenn ich diese mit cat /etc/group anzeigen lasse


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 09:51:43
Hast Du dem Docker-Container überhaupt die Docker-Tools installiert?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 10:01:24
Zitat von: Wernieman am 20 Mai 2020, 09:51:43
Hast Du dem Docker-Container überhaupt die Docker-Tools installiert?
Wie meinst du das "dem Container [...] installiert"?
Ich habe dem FHEM-Container nur das zusätzliche volume verpasst.... mehr nicht.
Wenn ich nach Docker-Tools google werd ich auch nicht so recht fündig.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 10:48:29
Zitatdass der Befehl nicht bekannt ist.
Wenn innerhalb des Containers der Befehl "docker" nicht installiert ist, kann es nicht "funktionieren". Es fehlt dir also "docker-ce-cli".

Bevor Du es aber jetzt auf die schnelle installierst, solltest Du dir überlegen, was Du genau damit erreichen willst .... warum brauchst Du in FHEM eine docker-Steuerung?

Edit:
Da es jetzt den Thread sehr aufbläht .. kannst Du einen neuen Thread dafür aufmachen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 10:54:31
Zitat von: Wernieman am 20 Mai 2020, 10:48:29
Wenn innerhalb des Containers der Befehl "docker" nicht installiert ist, kann es nicht "funktionieren". Es fehlt dir also "docker-ce-cli".

Bevor Du es aber jetzt auf die schnelle installierst, solltest Du dir überlegen, was Du genau damit erreichen willst .... warum brauchst Du in FHEM eine docker-Steuerung?

Edit:
Da es jetzt den Thread sehr aufbläht .. kannst Du einen neuen Thread dafür aufmachen?
Okay, danke.

Ich möchte eine Aktion in einem anderen Container anstoßen und dies schien mir der einfachste weg...


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 10:57:27
Kommt drauf an, wie der andere Container erreichbar ist, was er für "Dienste" anbietet. Du könntet auch direkt übers Docker-Netzwerk etwas aktivieren ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 11:03:36
In dem anderen Container läuft meine Nextcloud - der ist also von außen erreichbar.
Ich will mal testen ob ich über das darin enthalten Notification-System FHEM-Benachrichtigungen pushen kann.
Per commandozeile funktioniert es schon mal....

Mein FHEM soll eigentlich so weit wie möglich intern bleiben, daher wollte ich dir beiden Container nicht ins gleiche Netzwerk packen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 11:07:09
Zitatdaher wollte ich dir beiden Container nicht ins gleiche Netzwerk packen.
Bist Du Dir sicher, das sie in unterschiedlichen Netzwerken sind?

Ich will Deinen Vorschlag nicht schlecht machen, sondern finde Ihn sogar gut. Nur den meisten ist nicht klar, das docker ein eigenes Netzwerk aufspannt. Guck mal nach der IP-Adresse der Container ....

Weiß jetzt gar nicht, wie nextcloud-Notifikation funktioniert ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 11:18:13
Zitat von: Wernieman am 20 Mai 2020, 11:07:09
Bist Du Dir sicher, das sie in unterschiedlichen Netzwerken sind?

Ich will Deinen Vorschlag nicht schlecht machen, sondern finde Ihn sogar gut. Nur den meisten ist nicht klar, das docker ein eigenes Netzwerk aufspannt. Guck mal nach der IP-Adresse der Container ....

Weiß jetzt gar nicht, wie nextcloud-Notifikation funktioniert ....
Ja, die sind getrennt.
Ich habe beides über eigene Compose-Files hochgezogen und vorher eigene Docker-Netzwerke erstellt, in denen dann die weiteren Dienste (für FHEM: MariaDB, Mosquitto) laufen und erreichbar sind.
FHEM läuft in Docker im IP-Bereich 172.29.8.x und Nextcloud im Bereich 172.29.4.x


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 11:27:59
Dann gucke doch einfach mal, ob von Container A der Container B anpingbar ist ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 11:36:04
Zitat von: Wernieman am 20 Mai 2020, 11:27:59
Dann gucke doch einfach mal, ob von Container A der Container B anpingbar ist ...
Ist er nicht.
(Und sollte er ja sich nicht, oder?)


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 11:37:59
Naja .. kommt drauf an wie Docker configuriert ist.

Aber unabhängig davon ... Du willst per "docker exec" praktisch einen Befehl auf einem anderen Container anstoßen? Der Anderweitig nicht erreichbar ist?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 11:48:25
Zitat von: Wernieman am 20 Mai 2020, 11:37:59
Naja .. kommt drauf an wie Docker configuriert ist.

Aber unabhängig davon ... Du willst per "docker exec" praktisch einen Befehl auf einem anderen Container anstoßen? Der Anderweitig nicht erreichbar ist?
An Docker selbst kann ich nur bendingt was Konfigurieren, da das (sehr wahrscheinlich) durch das QNAP OS geblockt oder beim nächsten Update wieder zurückgesetzt wird.

Der NC-Container ist schon von außen erreichbar (sonst würde es ja mit dem Sync auf die Clients, etc. nicht funktionieren) aber auf dem Weg kann man keine Kommandos an das backend schicken. Das ist ja auch gut so, sonst könnte ja jeder von draußen in meiner Config rumbasteln und Sicherheitsmechanismen aushebeln etc.
Per 'Docker exec' (oder über die Shell in portainer) kann man diese Befehle aber absetzen. Ich könnte mir vorstellen, dass es auch mit einer ssh-Verbindung in den Container gehen könnte aber dafür müssten beide Container wieder ins selbe Netz.

Wahrscheinlich übersteigt es auch ein wenig mein Docker-/Netzwerkwissen aber ich suche nach eine möglichkeit ohne ein großes Sicherheitsloch reinzureißen....


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 12:24:39
Sicherheitstechnisch ist es nicht schön, wenn ein Container aus seinem Container raus docker steuern kann. Mit docker geht mehr als nur "exec". Genau so unschön ist es, wenn in einem Container (=Dienst) mehr als ein Dienst enthalten ist. Besser ist: Ein Dienst - Ein Container. Du hast z.B. auch einen eigenen mysql-Container und baust nicht alles in einen ein.

(Btw: Deshalb baut man in der Containerwelt für jedes Projekt sogar eigene Container, obwohl z.B. mysql auch mehrere Datenbanken könnte)

Da ich nicht weiß, wie genau der Notifikation-Versand bei nextcloud funktioniert, steuerbar ist, kann ich Dir da wenig Hilfestellung geben. Muß das Script wirklich auf der gleichen Instanz laufen?

Auch wenn es jetzt OT wird:
Rein von der Basis her ist Docker kein Sicherheitsgewinn. Der Vorteil von Docker sind übersichtliche Dienste -> dadurch einfach zu Konfigurieren und nur notwendige Libarys/Erweiterungen -> dadurch sicherer. Das ist anders als z.B. VMs, die auch einen Sicherheitsgewinn darstellen. Es ist einfacher aus Docker auszubrechen als aus einer VM
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 12:42:30
Zitat von: Wernieman am 20 Mai 2020, 12:24:39
Sicherheitstechnisch ist es nicht schön, wenn ein Container aus seinem Container raus docker steuern kann. Mit docker geht mehr als nur "exec". Genau so unschön ist es, wenn in einem Container (=Dienst) mehr als ein Dienst enthalten ist. Besser ist: Ein Dienst - Ein Container. Du hast z.B. auch einen eigenen mysql-Container und baust nicht alles in einen ein.

(Btw: Deshalb baut man in der Containerwelt für jedes Projekt sogar eigene Container, obwohl z.B. mysql auch mehrere Datenbanken könnte)
Soweit klar. Habe ich auch so angefangen/aufgebaut. Meine NC und FHEM haben jeweils eigene Maria-DB-Container, um es nicht zu mischen.

ZitatDa ich nicht weiß, wie genau der Notifikation-Versand bei nextcloud funktioniert, steuerbar ist, kann ich Dir da wenig Hilfestellung geben. Muß das Script wirklich auf der gleichen Instanz laufen?
Nextcloud nutzt die OCC (OenCloud Console) als command-line Interface.
Laut Doku ist das ein php-Skript. Was dieses dann wiederum genau macht und ob es auf einem anderen Server laufen könnte, müsste man wohl die NC-Entwickler fragen. Ich würde das aber von der Sache her eher nicht 'zerreißen' wollen.

ZitatAuch wenn es jetzt OT wird:
Rein von der Basis her ist Docker kein Sicherheitsgewinn. Der Vorteil von Docker sind übersichtliche Dienste -> dadurch einfach zu Konfigurieren und nur notwendige Libarys/Erweiterungen -> dadurch sicherer. Das ist anders als z.B. VMs, die auch einen Sicherheitsgewinn darstellen. Es ist einfacher aus Docker auszubrechen als aus einer VM
Hm.... wie gesagt... übersteigt vielleicht mein Wissen/Verständniss (daher bitte das folgende als Frage verstehen) aber wie man an dem Beispiel hier sieht, sind ja durch Docker hier doch ein paar weitere Hürden eingebaut. Hätte ich alles direkt auf dem Host, wäre es in FHEM mit einem einfachen {system ()} getan, richtig?!

Würdest du das nicht als sicherheitsgewinn sehen?


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 13:02:42
Der Vorteil von docker auf einer NAS ist, das Du unabhängig vom Betriebsystem der NAS bist. Wenn durch ein Update der NAS-Software etwas geändert wird, funktioniert Dein installiertes FHEM nicht, bei docker dagegen schon. Auch mußt Du dazu auch nichts mehr auf dem NAS installieren ....

Das FHEM-Docker ist quasi ein "fertiges-Produkt".

Habe jetzt mich mal wegen OCC informiert, da es mich privat interessiert, aber nichts rausgefunden ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 Mai 2020, 13:36:04
Zitat von: Wernieman am 20 Mai 2020, 13:02:42
Der Vorteil von docker auf einer NAS ist, das Du unabhängig vom Betriebsystem der NAS bist. Wenn durch ein Update der NAS-Software etwas geändert wird, funktioniert Dein installiertes FHEM nicht, bei docker dagegen schon. Auch mußt Du dazu auch nichts mehr auf dem NAS installieren ....

Das FHEM-Docker ist quasi ein "fertiges-Produkt".

Habe jetzt mich mal wegen OCC informiert, da es mich privat interessiert, aber nichts rausgefunden ...
Wie gesagt... Vorteile sind soweit verstanden. Ich habe es bisher auch als kleines Plus an Sicherheit verstanden. Sollte dem nicht so sein, würde ich gern verstehen warum.

Spricht denn etwas dagegen die docker-cli im Container zu installieren? Wenn es denn anders nicht geht?

Push notifications sind schon nett aber dafür eine extra App usw. würde ich nicht installieren (krieg ich auch der Frau nicht vermittelt).


Gesendet von iPhone mit Tapatalk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 Mai 2020, 13:41:26
Ja geht ... irgendwie kann man im fhem-docker so etwas auch festlegen. Wenn Du es manuell machst, mußt Du es beim nächsten Containerupdate manuell nachziehen.

Weiß jetzt aktuell nur nicht, ob das ubuntu-docker ausreicht, oder Du eine externe apt-Quelle dazunehmen müsstest (siehe ubuntu-install auf der docker-Webside).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 21 Mai 2020, 11:29:32
Zitat von: Wernieman am 20 Mai 2020, 12:24:39Rein von der Basis her ist Docker kein Sicherheitsgewinn. Der Vorteil von Docker sind übersichtliche Dienste -> dadurch einfach zu Konfigurieren und nur notwendige Libarys/Erweiterungen -> dadurch sicherer. Das ist anders als z.B. VMs, die auch einen Sicherheitsgewinn darstellen. Es ist einfacher aus Docker auszubrechen als aus einer VM
Die Aussage halte ich so nicht für korrekt. Docker bringt eine Reihe an Sicherheitsfeatures mit und wenn man die nicht mit privileged=true, cap-add=all und seccomp=unconfined gleich unbedarft abschaltet, weil das in irgendeiner Anleitung gepostet wurde, dann funktioniert das ziemlich gut.
In einem guten Image läuft wie Du geschrieben hast im wesentlichen der eine Prozess. Sonstige Betriebsystem-Dateien, oftmals ausgenutzt stehen kaum zur Verfügung.
Das FHEM Basisimage ist aber nun leider eher das Gegenteil. Keine Spur von Dienstetrennung, leider auch weil die FHEM-Software so entwickelt ist, dass sie es an vielen Stellen nicht zulässt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: BAfH am 28 Mai 2020, 19:45:54
Guten Abend,
ich hatte FHEM im Docker auf einen PI3 nach Matthias Kleine https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html (https://haus-automatisierung.com/hardware/fhem/2017/11/24/docker-auf-raspberry-pi.html) vermutlich waren 1 GB RAM zu wenig, also Umzug auf einen PI4 mit 4GB RAM.
Alle neu, nur diesmal habe ich mir das offizielle FHEM Docker Image gezogen. Meine docker-compose.yml
version: '3'

services:
    fhem:
        image: fhem/fhem:latest
        restart: always
        ports:
            - "8083:8083"
            - "8084:8084"
            - "7072:7072"
            - "8090:8090"
        volumes:
         - /etc/localtime:/etc/localtime:ro
         - /etc/timezone:/etc/timezone:ro
         - ./fhem/core/:/opt/fhem/
        network_mode: host
#
#        networks:
#            - fhem-network
        devices:
            - "/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0:/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0"
            - "/dev/ttyUSB0:/dev/ttyUSB0"
            - "/dev/ttyUSB1:/dev/ttyUSB1"
        environment:
            #FHEM_UID: 1000
            #FHEM_GID: 1000
            # User root           
            #FHEM_UID: 0
            #FHEM_GID: 0
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
        depends_on:
            - "mysql"
            - "mqtt"
    mysql:
        restart: always
        expose:
            - "3306"
            - "33060"
        ports:
            - "3306:3306"
            - "33060:33060"
        image: hypriot/rpi-mysql
        volumes:
            - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
            - ./mysql/data:/var/lib/mysql
        environment:
            - MYSQL_ROOT_PASSWORD=KQW8JgZEDb4CpSMaz
            - MYSQL_DATABASE=fhem
        networks:
            - fhem-network
    mqtt:
        restart: always
        expose:
            - "1883"
            - "9001"
        ports:
            - "1883:1883"
            - "9001:9001"
        image: pascaldevink/rpi-mosquitto
        networks:
            - fhem-network
        volumes:
            - ./mqtt/config/:/mqtt/config/
            - ./mqtt/log/:/mqtt/log/
            - ./mqtt/data/:/mqtt/data/

    xiaomibridge:
        restart: always
        image: koenkk/zigbee2mqtt
        devices:
          - "/dev/ttyACM0:/dev/ttyACM0"
        volumes:
            - /dev/serial/by-id:/dev/serial/by-id
            - ./xiaomibridge/data/:/app/data
        ports:
            - "4000:4000"
        networks:
            - fhem-network
        depends_on:
            - "mqtt"
    unifi:
        image: ryansch/unifi-rpi:latest
        container_name: unifi
        restart: always
        network_mode: host
        ports:
            - "8443:8443"
        # Uncomment the following to set java options
        # environment:
        #   JAVA_OPTS: -Xmx512M
        volumes:
           # Unifi v5.0.7 creates all of these directories (some remain empty)
           - config:/var/lib/unifi
           - log:/usr/lib/unifi/logs
           - log2:/var/log/unifi
           - run:/usr/lib/unifi/run
           - run2:/run/unifi
           - work:/usr/lib/unifi/work
volumes:
  config:
    driver: local
  log:
    driver: local
  log2:
    driver: local
  run:
    driver: local
  run2:
    driver: local
  work:
    driver: local


networks:
    fhem-network:
        driver: bridge


irgendwie sind die Rechte verwirrt....
aufgefallen war mir es, als ich ssh remote eingerichtet habe. Im Altsystem nach Ottos Anleitung läuft es im Neusystem nicht. Hier merkt eich auch, das der User fhem nicht existiert.
Startlog im Altsystem
ZitatPreparing 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 ...
9. Updating SSH key pinning and SSH client permissions for user 'fhem' ...
Preparing configuration ...
Starting FHEM ...
Rechte im Altsystem
Zitatpi@FHEM-OLD:~ $ ls -lha fhem-docker/fhem/core/
insgesamt 996K
drwxr-xr-x 14 6061 6061 4,0K Mai 27 19:42 .
drwxrwxr-x  3 pi   pi   4,0K Feb 27  2019 ..
drwxr-xr-x  2 6061 6061 4,0K Mai 24 23:59 backup
-rw-r--r--  1 6061 6061 321K Mär  6 10:22 CHANGED
-rw-r--r--  1 6061 6061  145 Mär  6  2019 configDB.conf
-rw-r--r--  1 6061 6061  40K Mär  6 10:22 configDB.pm
drwxr-xr-x 44 6061 6061 4,0K Feb 27  2019 contrib
-rw-r--r--  1 6061 6061  18K Feb 27  2019 COPYING
drwxr-xr-x  3 6061 6061 4,0K Feb 27  2019 demolog
drwxr-xr-x  4 6061 6061 4,0K Feb 27  2019 docs
drwxr-xr-x  6 6061 6061  24K Mär 12 07:53 FHEM
-rwxrwxrwx  1 6061 6061 113K Mai 27 19:42 fhem.cfg
-rw-r--r--  1 6061 6061 113K Apr 15 10:52 fhem.cfg.bak
-rw-r--r--  1 6061 6061  516 Feb 27  2019 fhem.cfg.default
-rw-r--r--  1 6061 6061  25K Feb 25 13:34 fhem.cfg.demo
-rwxr-xr-x  1 6061 6061 157K Mär  6 10:22 fhem.pl
-rw-r--r--  1 6061 6061  28K Feb 27  2019 HISTORY
drwxr-xr-x  2 6061 6061 4,0K Mai 27 19:42 log
-rw-r--r--  1 6061 6061  42K Feb 25 13:34 MAINTAINER.txt
-rw-r--r--  1 6061 6061 5,0K Feb 27  2019 Makefile
drwxr-xr-x  3 6061 6061 4,0K Mär  6  2019 mnt
-rw-r--r--  1 6061 6061  13K Dez 23 11:31 muellkalender.ics
-rw-r--r--  1 6061 6061  935 Feb 27  2019 README_DEMO.txt
-rw-r--r--  1 6061 6061  374 Feb 27  2019 README.SVN
drwxr-xr-x  4 6061 6061 4,0K Feb 27  2019 restoreDir
drwx------  2 6061 6061 4,0K Mai 27 19:42 .ssh
drwxr-xr-x  2 6061 6061 4,0K Apr 10  2019 unused
-rw-r--r--  1 6061 6061 1,8K Feb 27  2019 UPGRADE
drwxr-xr-x  6 6061 6061 4,0K Feb 27  2019 webfrontend
drwxrwxrwx 11 6061 6061 4,0K Jul  4  2019 www

Startlog im Neusystem
ZitatPreparing initial start:
1. Installing FHEM to /opt/fhem
2. Patching fhem.cfg default configuration
3. Adding pre-defined devices to fhem.cfg

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. Correcting group ownership for /dev/serial/* ...
9. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
10. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
11. Updating /etc/sudoers.d/fhem-docker ...
12. Generating SSH Ed25519 client certificate for user 'fhem' ...
13. Generating SSH RSA client certificate for user 'fhem' ...
14. Generating SSH client configuration for user 'fhem' ...
15. Adding gateway.docker.internal to /etc/hosts ...
16. Adding host.docker.internal to /etc/hosts ...
17. Pre-authorizing SSH to Docker host for user 'fhem' ...
18. Updating SSH key pinning and SSH client permissions for user 'fhem' ...
Preparing configuration ... done

Rechte im Neusystem
Zitatpi@FHEM:~ $ sudo ls -lha fhem-docker/fhem/core/
insgesamt 868K
drwxr-x--- 15 6061 6061 4,0K Mai 25 15:04 .
drwxr-xr-x  3 root root 4,0K Mai 25 13:48 ..
-rw-r-----  1 6061 6061 335K Mai 25 15:01 CHANGED
drwxr-x---  3 6061 6061 4,0K Mai 25 13:49 .config
-rw-r--r--  1 root root  146 Mai 25 14:22 configDB.conf
-rw-r-----  1 6061 6061  39K Mai 11 13:17 configDB.pm
drwxr-x--- 48 6061 6061 4,0K Mai  4 13:29 contrib
-rw-r-----  1 6061 6061  18K Dez 30 15:02 COPYING
drwxr-x---  3 6061 6061 4,0K Dez 30 15:02 demolog
drwxr-x---  4 6061 6061 4,0K Mai 25 13:48 docs
drwxr-x---  6 6061 6061  20K Mai 25 15:01 FHEM
-rw-r-----  1 6061 6061  82K Mai 27 11:10 fhem.cfg
-rw-r-----  1 6061 6061 2,2K Mai 25 13:55 fhem.cfg.bak
-rw-r-----  1 6061 6061  516 Mai 25 13:48 fhem.cfg.default
-rw-r-----  1 6061 6061  25K Dez 30 15:02 fhem.cfg.demo
-rwxr-----  1 6061 6061 160K Mai 25 15:01 fhem.pl
-rw-r-----  1 6061 6061  28K Dez 30 15:02 HISTORY
drwxr-x---  2 6061 6061 4,0K Mai 27 00:00 log
-rw-r-----  1 6061 6061  42K Mai 25 15:01 MAINTAINER.txt
-rw-r-----  1 6061 6061 5,0K Jan 27 12:22 Makefile
-rwxr-xr--  1 root root  13K Mai 25 14:24 muellkalender.ics
drwxr-x---  3 6061 6061 4,0K Mai 25 13:49 .npm
-rw-r-----  1 6061 6061   25 Mai 18 13:17 .proverc
-rw-r-----  1 6061 6061  935 Dez 30 15:02 README_DEMO.txt
-rw-r-----  1 6061 6061  374 Dez 30 15:02 README.SVN
drwxr-----  4 6061 6061 4,0K Mai 25 14:05 restoreDir
drwx------  2 6061 6061 4,0K Mai 25 13:56 .ssh
drwxr-----  2 6061 6061 4,0K Mai 25 14:04 unused
-rw-r-----  1 6061 6061 2,2K Mär  9 12:13 UPGRADE
drwxr-x---  6 6061 6061 4,0K Dez 30 15:02 webfrontend
drwxr-x---  9 6061 6061 4,0K Mai 25 14:04 www

Den user fhem habe ich neuangelegt
Zitatsudo useradd --system --home /home/pi/fhem-docker/fhem/core --gid dialout --shell /bin/false fhem

Komme irgendwie nicht weiter, gesucht jede Menge und nichts gefunden...
bin über jeden tipp dankbar
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 28 Mai 2020, 23:28:53
Der User fhem existiert schon, aber im Docker Container. Mir scheint du suchst ihn im Host System? Wie soll er da hin kommen? Was bezweckst Du damit?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: BAfH am 29 Mai 2020, 09:28:25
Ich möchte z.B. remote SSH im FHEM für sysmon... Ging im Altsystem.  Auch nutze in WINSCP um z.B. ale HTML File zu kopieren. Nur hat PI keine Rechte, im Altsystem ja. Daher bin ich verwirrt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 30 Mai 2020, 10:59:54
du hast scheinbar den user fhem schon auf dem Host angelegt, jedoch mit /bin/false ... welcher Test schlägt fehl? Damit kannst du keine Console öffnen. War das der Fehler den du siehst? Fehlermeldungen?

Setzte mal /bin/bash als shell und teste nur mal    ssh <ip host> und dann solltest du einen Login-Screen erhalten. Wenn das geht prüfst du nochmal ob ssh-keys eingetragen sind und postest die Fehler die du erhälst.

führe mal

whoami
ssh fhem@host.docker.internal


du schreibst dass du die Anleitung von Otto ausgeführt hast, für welchen Host? Wenn du gateway.docker.internal verwendet hast, dann den obigen Befehl auch damit testen.

Ich denke es liegt am EDSA-Fingerprint-Meldung oder an einem Key-Problem, falscher Host, User ... was auch immer



Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: BAfH am 02 Juni 2020, 11:23:38
Sorry, Pfingsten.
Ich haben jetzt die Schritte aus Otto's Blog
in der Console des Docker pi ausgeführt.
Fehlermeldung
Host key verification failed.
Jetzt die o.g. Befehle mittels Portainer Console im FHEM Container ausgeführt. Siehe da Remote ssh klappt.
defmod RPIPOOL SYSMON ssh:pi@192.168.10.60
Liefert mir Ergebnisse. Danke für den Hinweis...
Was mich nur wundert... Am Altsystem habe ich definitiv das nur auf der Console des Host durchgeführt.
Vermutlich habe ich soviel gefummelt und geändert, das ist der erste Versuch fhem und Docker, das ich wohl unbewusst quasi alles irgendwie geschafft habe.  ::)
Eigentlich ist das alles logisch, nur diesen Hinweis benötigte ich.

Jetzt geht es mir noch um die Rechte. Ziel ist hier, alle (viele) Daten ändere ich auf meinem Rechner ist halt eleganter (für mich) übertrage diese nur mittels WinSCP.
Gerade die HTML Files für TabletUI.
Nach dem Start von FHEM im Docker hat der User pi keine Rechte mehr auf das Filesystem.
Hier mal die Rechte lt fhem Console
root@FHEM:/opt/fhem# ls -lha
total 948K
drwxr-x--- 15 root root 4,0K Jun  2 08:59 .
drwxr-xr-x  1 root root 4,0K Mai 25 13:43 ..
-rw-r-----  1 root root 335K Mai 25 15:01 CHANGED
drwxr-x---  3 root root 4,0K Mai 25 13:49 .config
-rw-r-----  1 root root  146 Mai 25 14:22 configDB.conf
-rw-r-----  1 root root  39K Mai 11 13:17 configDB.pm
drwxr-x--- 48 root root 4,0K Mai  4 13:29 contrib
-rw-r-----  1 root root  18K Dez 30 15:02 COPYING
drwxr-x---  3 root root 4,0K Dez 30 15:02 demolog
drwxr-x---  4 root root 4,0K Mai 25 13:48 docs
drwxr-x---  6 root root  20K Jun  2 08:59 FHEM
-rw-r-----  1 root root  84K Jun  2 08:59 fhem.cfg
-rw-r-----  1 root root  82K Mai 28 19:39 fhem.cfg.bak
-rw-r-----  1 root root  516 Mai 25 13:48 fhem.cfg.default
-rw-r-----  1 root root  25K Dez 30 15:02 fhem.cfg.demo
-rwxr-----  1 root root 160K Mai 25 15:01 fhem.pl
-rw-r-----  1 root root  28K Dez 30 15:02 HISTORY
drwxr-x---  2 root root 4,0K Jun  2 09:01 log
-rw-r-----  1 root root  42K Mai 25 15:01 MAINTAINER.txt
-rw-r-----  1 root root 5,0K Jan 27 12:22 Makefile
-rw-r-----  1 root root  13K Mai 25 14:24 muellkalender.ics
drwxr-x---  3 root root 4,0K Mai 25 13:49 .npm
-rw-r-----  1 root root   25 Mai 18 13:17 .proverc
-rw-r-----  1 root root  935 Dez 30 15:02 README_DEMO.txt
-rw-r-----  1 root root  374 Dez 30 15:02 README.SVN
drwxr-x---  4 root root 4,0K Mai 25 14:05 restoreDir
drwx------  2 root root 4,0K Mai 29 10:38 .ssh
drwxr-x---  3 root root 4,0K Mai 18 13:17 t
drwxr-x---  2 root root 4,0K Mai 25 14:04 unused
-rw-r-----  1 root root 2,2K Mär  9 12:13 UPGRADE
drwxr-x---  6 root root 4,0K Dez 30 15:02 webfrontend
drwxr-x---  9 root root 4,0K Mai 25 14:04 www

Kann ich hier was dauerhaft ändern??
Danke
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 02 Juni 2020, 13:20:52
Zitat von: BAfH am 02 Juni 2020, 11:23:38

Liefert mir Ergebnisse. Danke für den Hinweis...

Kann ich hier was dauerhaft ändern??
Danke

wenn du pi als User auf dem Host nutzt dann kannst du den angelegten User fhem wieder löschen wenn du diesen nicht brauchst - auf dem Host, nicht im Container.

Dauerhaft ändern? Erstmal die Rechte wieder korrekt setzen auf 6061:6061 (oder dem User den du nutzt). Im Folgenden gehe ich davon aus, dass du default 6061:6061 nutzt.



Du könntest dir einen User auf dem Host anlegen der die UID:GID 6061:6061 hat. Diesen dann für WinSCP nutzen. Dann sind die Rechte immer korrekt.

Erstmal Ownership übernehmen ... dazu musst du im Docker-Verzeichnis sitzen - am Host nicth im Docker Container -, sonst überschreibst du dir alles andere auch ...

sudo chown 6061:6061 ./*


Dann User mit UID 6061 anlegen

sudo useradd fhemusr --uid 6061
sudo passwd fhemusr geheimespasswort


mit den beiden Befehlen erstellst du dir auf dem Host einen User der die UID vom Fhem-Container hat. Diesen User fhemusr mit Password geheimespasswort nutzt du in WinScp und hast automatisch die richtigen Rechte.

... und vorher ein Backup machen sollte etwas schief laufen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: BAfH am 02 Juni 2020, 16:35:18
Hat nicht das gebrach was ich hoffte,  alles nochmal gründlich geprüft und siehe da, Fehler gefunden.
In der docker-compose.yml waren die Zeilen auskommentiert
   
FHEM_UID: 1000
FHEM_GID: 1000

Geändert, neu gestartet. Jetzt läuft wieder alles so wie ich es erwarte, ich hatte den user pi des Host schon vorher zur Gruppe 6061 hinzugefügt habe.
Machmal sieht man den wald vor lauter Bäume nicht. Danke für Ratschläge.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 02 Juni 2020, 18:59:55
Zitat von: BAfH am 02 Juni 2020, 16:35:18
Geändert, neu gestartet. Jetzt läuft wieder alles so wie ich es erwarte, ich hatte den user pi des Host schon vorher zur Gruppe 6061 hinzugefügt habe.
Damit werden neue DAteien mit Owner pi angelegt wenn du über WinScp hochlädst. Rechte sind per Default rw-r--r-- ... dann fhem diese nicht lesen. Lade mal etwas hoch und schau dir in WinScp an wie die Rechte aussehen. Oder Lade mal das Log runter, lösche es und lade es wieder hoch und schau ob Fhem das Log anzeigen kann.

Ich dachte die Rechteänderungen willst du verhindern.


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: BAfH am 04 Juni 2020, 09:02:23
Ich habe einfach eine Datei mit dem Namen fhem-2020-06-00.log mittels WinSCP als User pi hochgeladen.
Folgende Rechte hat die Datei
-rw-r--r-- 1 pi pi 3,1K Aug 15  2019 fhem-docker/fhem/core/log/fhem-2020-06-00.log
Fhem kann diese lesen zeiht mir die Datei unter System Logfile Filelog an.

ZitatIch dachte die Rechteänderungen willst du verhindern.
Ja, nur die Veränderung das ich als pi komplett ausgesperrt wurde. Das ist jetzt nicht mehr der Fall.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 04 Juni 2020, 09:04:21
Fehm sollte die Datei mit den Rechten aber nicht schreiben dürfen .....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: BAfH am 04 Juni 2020, 10:06:31
das mag sein, muss fhem auch nicht.  :-\denke ich.
Eine Log Datei hat folgende Rechte
-rw-r----- 1 pi pi 21K Jun  4 09:35 fhem-docker/fhem/core/log/Velux_2-2020.log
hier schreibt aber fhem fleißig rein. ???
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 04 Juni 2020, 11:53:28
komisch, läuft dein Fhem unter User pi? Welche Rechte haben jetzt Dateien die Fhem selber angelegt hat, z. B. Plotfiles? Ist die UID im Docker identisch zu der von pi?

Solange alles funktioneirt was du dir vorstellst ist es gut. Um die Dateirechte zu verstehen fehlen ein paar Informationen.

Du hast das im docker-compose stehen? Dann läuft fehm unter der UID von pi.

FHEM_UID: 1000
FHEM_GID: 1000
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: BAfH am 04 Juni 2020, 16:29:33
Im Docker als User fhem
fhem@FHEM:~$ id
uid=1000(fhem) gid=1000(fhem) groups=1000(fhem),5(tty),8(mail),20(dialout),29(audio),44(video),6001(bluetooth),6002(gpio),6003(i2c)

auf dem Host als User pi
uid=1000(pi) gid=1000(pi) Gruppen=1000(pi),4(adm),5(tty),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),105(input),109(netdev),995(docker),997(gpio),998(i2c),999(spi)
In der Docker-compose

FHEM_UID: 1000
FHEM_GID: 1000

Ich sag mal so, mir gefällt es so ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: zimb0 am 03 Juli 2020, 08:56:55
Hallo zusammen,
habe in dem anderen Docker-Thread bereits eine Frage gestellt, poste sie jetzt nochmal hier, da der Thread doch etwas länger ist:

Ich bin gerade dabei die ersten Schritte mit Docker zu gehen und möchte mir ein docker-compose für fhem bauen.

Eine Sache verstehe ich hierbei noch nicht ganz: Ich möchte erreichen, dass eigentlich nur die fhem.cfg, 99_myUtils.pm, /log, /www/gplot und /www/tablet auf den host umgeleitet wird.
(Wenn ich die Docker-Logik richtig verstanden habe sollte der Rest ja "dynamisch" aktualisiert werden könne, ohne dass meine Config verändert wird, deshalb diese Trennung ?).

Nun habe ich in meinem docker-compose folgende Einträge erfasst:

volumes:
      - /opt/docker/fhem/log:/opt/fhem/log
      - /opt/docker/fhem/www/gplot:/opt/fhem/www/gplot
      - /opt/docker/fhem/www/tablet:/opt/fhem/www/tablet
      - type: bind
        source: /opt/docker/fhem/fhem.cfg
        target: /opt/fhem/fhem.cfg
      - type: bind
        source: /opt/docker/fhem/99_myUtils.pm
        target: /opt/fhem/FHEM/99_myUtils.pm

Die Dateien / Ordner werden auch entsprechend umgeleitet, allerdings ist es so, dass der Container nach der Umleitung der myUtils wohl den kompletten fhem/FHEM - Ordner nicht mehr lesen kann.
Ich tippe hier auf falsch konfigurierte Rechte.

Fehlermeldung beim initialisieren dann z.B:
Zitat
Can't locate RTypes.pm in @INC (you may need to install the RTypes module)
Ebenso tritt auf: Wenn der /opt/fhem/www/tablet umgeleitet ist wird keinerlei CSS im Webinterface dargestellt, was denke ich das gleiche Problem ist.

Könnt ihr mir hier etwas weiterhelfen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 04 Juli 2020, 09:20:49
Dir ist klar:
1. Das Doppelbosten einer Frage in Unterschiedliche Threads wird in den meisten Forum als Negativ angesehene
2. Die Länge einen Threads ist nicht bedeutend mit der Aufmerksamkeit
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: TWART016 am 23 Juli 2020, 02:01:10
Ich möchte nun FHEM mit configDB nutzen.

  fhem:
    container_name: fhem
    image: fhem/fhem:latest
    restart: always
    ports:
      - "8083:8083"
    volumes:
      - "./fhem/:/opt/fhem/"
      - "./fhem/contrib/configDB/configDB.conf:/opt/fhem/configDB.conf"
    environment:
      FHEM_UID: 1000
      FHEM_GID: 1000
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
      CONFIGTYPE: configDB
      LOGFILE: ./log/fhem-%Y-%m-%d.log
    depends_on:
      - "mysql"
      - "mqtt"


Mit configDB info erhalte ich folgendes:
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
d:$Id: configDB.pm 21571 2020-04-01 11:09:00Z betateilchen $
c:$Id: 98_configdb.pm 21558 2020-03-31 12:24:00Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbtype: SQLITE
dbsize: 24.00 KB
-----------------------------------------------------------------
lastReorg:   
config:       27 entries

Ver 0 saved: Thu Jul 23 01:49:10 2020 def: 3 attr: 10
Ver 1 saved: by cfgDB_Init  def: 3 attr: 6
-----------------------------------------------------------------
state: 5 entries saved: Thu Jul 23 01:49:14 2020
-----------------------------------------------------------------
filesave: 1 file stored in database
-----------------------------------------------------------------


Eigentlich sollte da mysql stehen. Die Datei /var/lib/docker/volumes/fhem/contrib/configDB/configDB.conf habe ich nach meinen Wünschen angepasst.
Muss bei configDB nicht die configDB.conf direkt in /opt/fhem liegen?
Edit: Auch wenn die configDB.conf in /var/lib/docker/volumes/fhem liegt, bekomme ich die gleiche Meldung.

Gibt es die Möglichkeit zu prüfen, ob die DB bereits existiert? Wenn nicht, soll eine automatisch angelegt werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 Juli 2020, 14:14:29
Zitat von: TWART016 am 23 Juli 2020, 02:01:10
Eigentlich sollte da mysql stehen. Die Datei /var/lib/docker/volumes/fhem/contrib/configDB/configDB.conf habe ich nach meinen Wünschen angepasst.
Muss bei configDB nicht die configDB.conf direkt in /opt/fhem liegen?
Edit: Auch wenn die configDB.conf in /var/lib/docker/volumes/fhem liegt, bekomme ich die gleiche Meldung.

Gibt es die Möglichkeit zu prüfen, ob die DB bereits existiert? Wenn nicht, soll eine automatisch angelegt werden.
ConfigDB kann ich dir nicht helfen. Mounten von einzelnen Files gibt in docker-compose manchmal Probleme. Ist die configDB.conf im Container sichtbar und lesbar?

Wenn du IM CONTAINER die Befehle unten ausführst, siehst du  dann die Konfiguration die du angelegt hast? Mit MySQL als Datenbank mit User / Passwort?


su fhem
cat /opt/fhem/configDB.conf


Wenn dass funktioniert teste mal die Config ... auch IM Container


mysql -u <mysql_fhem_username> -h <mysql_host> -p


welche Datenbanken schon bestehen kannst du dann so prüfen wenn du per Konsole auf der Datenbank bist:        show databases;


MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| fhem               |
| information_schema |
+--------------------+


Wenn das alles funktioniert scheint es eine configDB-spezifische Frage / Problem zu sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: TWART016 am 25 Juli 2020, 16:12:31
Ich hatte das falsche Volumen. Jetzt kommt jedoch der Fehler:
Starting FHEM ...


DBI connect('database=fhem;host=192.168.178.15;port=3306','fhemuser',...) failed: Plugin caching_sha2_password could not be loaded: /usr/lib/x86_64-linux-gnu/mariadb19/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory at configDB.pm line 704.


Unable to start FHEM process - errorcode 11



Bei Zeile 704 steht:
# connect do database
sub _cfgDB_Connect {
my $fhem_dbh = DBI->connect(
"dbi:$cfgDB_dbconn",
$cfgDB_dbuser,
$cfgDB_dbpass,
{ AutoCommit => 0, RaiseError => 1 },
) or die $DBI::errstr;
return $fhem_dbh;
}
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 Juli 2020, 16:25:47
Zitat von: TWART016 am 25 Juli 2020, 16:12:31
Ich hatte das falsche Volumen. Jetzt kommt jedoch der Fehler:


google sagt das hier ... ich selber nutze MariaDB, und kann mich nicht erinnern, das schon mal gesehen zu haben. Wenn du hier mit User rummachst am besten den Docker-MySQL-Ordner sichern wenn was schief geht. Wenn du sowieso neu beginnst, kannst auch mal MariaDB als Container laden, wahrscheinlich mussst nur in der MySQL-Definition statt MySQL das MariaDB Image angeben.

https://stackoverflow.com/questions/49963383/authentication-plugin-caching-sha2-password
https://github.com/docker-library/mysql/issues/454

Möglichkeit 1, Link1, ... User löschen und mit

CREATE USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';


Möglichkei 2, Link2, .. Docker MySQL ändern, docer-compose folgende Zeile hinzufügen

    command: --default-authentication-plugin=mysql_native_password
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: TWART016 am 26 Juli 2020, 01:49:40
Zitat von: kadettilac89 am 25 Juli 2020, 16:25:47
google sagt das hier ... ich selber nutze MariaDB, und kann mich nicht erinnern, das schon mal gesehen zu haben. Wenn du hier mit User rummachst am besten den Docker-MySQL-Ordner sichern wenn was schief geht. Wenn du sowieso neu beginnst, kannst auch mal MariaDB als Container laden, wahrscheinlich mussst nur in der MySQL-Definition statt MySQL das MariaDB Image angeben.

https://stackoverflow.com/questions/49963383/authentication-plugin-caching-sha2-password
https://github.com/docker-library/mysql/issues/454

Möglichkeit 1, Link1, ... User löschen und mit

CREATE USER 'username'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';


Möglichkei 2, Link2, .. Docker MySQL ändern, docer-compose folgende Zeile hinzufügen

    command: --default-authentication-plugin=mysql_native_password


Es lag tatsächlich am Image. mysql:latest hat nicht funktioniert, mysql hingegen schon.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: TWART016 am 26 Juli 2020, 02:07:29
Zitat von: ManOki am 06 Januar 2020, 10:47:18
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?

Zitat 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).

Ich wäre aktuell bei dem gleichen Punkt. Diese Pakete brauche ich, um einen Xiaomi Luftreiniger betreiben zu können:
CPAN_PKGS: "Crypt::Rijndael Crypt::Random Crypt::Cipher::AES"
APT_PKGS: "libjson-perl libdigest-md5-perl libcrypt-cbc-perl libcrypt-ecb-perl"


Allerdings werden bei jedem docker-compose up (und Änderung am FHEM Container) die Pakete installiert, was mehrere Minuten braucht. Richte ich ein neues Modul ein, welches andere Pakete benötigt, füge ich diese zur compose hinzu.
Bei jedem zusätzlichen Paket muss ich den Containers neu erstellen. Selbst bei den wenigen Paketen derzeit benötigt das mehrere Minuten. Und ich werde noch mehrere Paketen verwenden und dann braucht jede Containererstellung vermutlich über 15 Minuten. Wie ist das gedacht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 Juli 2020, 08:53:38
Zitat von: TWART016 am 26 Juli 2020, 01:49:40
Es lag tatsächlich am Image. mysql:latest hat nicht funktioniert, mysql hingegen schon.
erstmal gelöst, vermutlich kommt das Problem wieder wenn latest in das normale Image einfließt


Zitat von: TWART016 am 26 Juli 2020, 02:07:29
Allerdings werden bei jedem docker-compose up (und Änderung am FHEM Container) die Pakete installiert, was mehrere Minuten braucht. Richte ich ein neues Modul ein, welches andere Pakete benötigt, füge ich diese zur compose hinzu.
Bei jedem zusätzlichen Paket muss ich den Containers neu erstellen. Selbst bei den wenigen Paketen derzeit benötigt das mehrere Minuten. Und ich werde noch mehrere Paketen verwenden und dann braucht jede Containererstellung vermutlich über 15 Minuten. Wie ist das gedacht?
Warum musst du so oft docker-compose up ausführen? Wenn es zum Testen ist dann leg dir doch einen Testcontainer ohne die Abhängigkeit an und das Modul mit der hohen Laufzeit nur im produktiven Container.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: TWART016 am 26 Juli 2020, 11:49:03
Zitat von: kadettilac89 am 26 Juli 2020, 08:53:38
erstmal gelöst, vermutlich kommt das Problem wieder wenn latest in das normale Image einfließt
Dann schaue ich nochmal das latest an.

Zitat von: kadettilac89 am 26 Juli 2020, 08:53:38
Warum musst du so oft docker-compose up ausführen? Wenn es zum Testen ist dann leg dir doch einen Testcontainer ohne die Abhängigkeit an und das Modul mit der hohen Laufzeit nur im produktiven Container.
Das mit dem Testcontainer ist finde ich was anderes. Würde ich ein Xiaomi Gerät einrichten wollen, teste ich es im Test Container. Ist dies erfolgreich möchte ich dies aber im Produktiven einsetzen. Dann muss ich die Pakete in die compose hinzufügen und starten. Dann möchte ich später SNMP einrichten und muss das gleiche machen. Nach ein paar mal summiert sich das ganze und mit jedem weiteren Modul verlängert sich die Zeit bis der Container erstellt ist.
Nur weil ich ein neues Modul produktiv nehmen möchte, habe ich eine fhem Downtime von 15-30 min.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 26 Juli 2020, 13:52:19
Zitat von: TWART016 am 26 Juli 2020, 11:49:03
Das mit dem Testcontainer ist finde ich was anderes. Würde ich ein Xiaomi Gerät einrichten wollen, teste ich es im Test Container. Ist dies erfolgreich möchte ich dies aber im Produktiven einsetzen. Dann muss ich die Pakete in die compose hinzufügen und starten. Dann möchte ich später SNMP einrichten und muss das gleiche machen. Nach ein paar mal summiert sich das ganze und mit jedem weiteren Modul verlängert sich die Zeit bis der Container erstellt ist.
Nur weil ich ein neues Modul produktiv nehmen möchte, habe ich eine fhem Downtime von 15-30 min.
Es gibt ja mehrere Wege. Wenn Du größere Änderungen hast, solltest Du Dir einfach Dein eigenes Image bauen. Das kann ja als Base-Image auf dem FHEM-Image basieren.
Damit hast Du den Ausfall nicht während der Runtime, sondern eine separate Buildtime.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 27 Juli 2020, 08:12:21
Wie mein Vorredner schrieb und nur im Nebensatz erwähnt:

Du kannst bei Docker Container undabhängig vom laufenden Container bauen. Also Build-Time <> Downtime (bei der richtigen Configuration)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 02 August 2020, 23:10:26
Nein, das habe ich definitiv nicht erwähnt. Man kann neue Images bauen.
Ich halte es nicht für praktikabel parallel einen neuen Container zu bauen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 24 August 2020, 15:52:25
Maaahlzeit :-)

Länger was her - mit Docker läuft es halt einfach!  8)
Aber nun dann doch mal eine Frage. Mein ........

Hat sich gerade erledigt und ist wieder alles top! :-D (Perl war anscheined out of date meinte der FHEM Installer Status)

Danke für dieses wundervolle Dockerimage :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 25 August 2020, 12:01:27
Ok....nun also doch! :-D

Rotes Ausrufezeichen in rotem Dreieck beim Installer. Und folgende Fehlermeldung bei "get errors"

Hatte durchaus versucht hier infos zu finden - soweit ich das sehe habe ich CPAN installiert (wobei installiert auch falsch ist ich nutze ja das Docker Image - das ist da halt mit drin)
Wüsste gern was das nun gerade los ist :-D

Ist es auch das mit dem "\n" Zeilenumbruch?

*EDIT: Interessanterweise ist es anscheind für eine etwas längere Zeit nach einem FHEM neustart alles grün....

Danke
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 25 August 2020, 12:54:36
Bei mir auch.
Wenn ich get CheckPrereqs mache dann fehlt Data::Peek das anscheinend für DBLog benötigt wird.
nachdem das installiert wird dann ist es wieder grün...
gruß anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 25 August 2020, 14:48:32
Hallo allesamt,

ich habe das Image auf meinem QNAP (armh32) installiert, doch leider zeigen sich einige Netzwerkprobleme.
Besonders bei dem Versuch mit HTTPMOD einen Webseiten-Quelltext abzurufen kommt es zu Problemen.
Siehe dazu folgenden Threat, speziell ab Antwort #30: https://forum.fhem.de/index.php/topic,113769.30.html (https://forum.fhem.de/index.php/topic,113769.30.html)

Ich habe wirklich nicht sonderlich viel Ahnung und muss noch vieles lernen.
Bitte sagt mir deshalb einfach was ihr braucht oder wie ich euch behilflich sein kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 August 2020, 16:17:45
Zitat von: antonwinden am 25 August 2020, 12:54:36
Bei mir auch.
Wenn ich get CheckPrereqs mache dann fehlt Data::Peek das anscheinend für DBLog benötigt wird.
nachdem das installiert wird dann ist es wieder grün...
gruß anton

Ich nutze Docker schon länger, habe mehrere DBLog-Definitionen und habe keine zusätzlichen Pakete, trotzdem ist bei mir alles "grün".

Wo genau machst du den check? Welche Docker Version bzw. Build date des Images? .... 

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 August 2020, 16:22:23
Zitat von: MarkoP am 25 August 2020, 14:48:32
Hallo allesamt,

ich habe das Image auf meinem QNAP (armh32) installiert, doch leider zeigen sich einige Netzwerkprobleme.
Besonders bei dem Versuch mit HTTPMOD einen Webseiten-Quelltext abzurufen kommt es zu Problemen.
Siehe dazu folgenden Threat, speziell ab Antwort #30: https://forum.fhem.de/index.php/topic,113769.30.html (https://forum.fhem.de/index.php/topic,113769.30.html)

Ich habe wirklich nicht sonderlich viel Ahnung und muss noch vieles lernen.
Bitte sagt mir deshalb einfach was ihr braucht oder wie ich euch behilflich sein kann.

Du tanzt auf 2 Hochzeiten. Ohne jetzt den parallelen Post zu lesen ... was genau erwartest du in diesem Post zu Docker? Deutet die bisherige Analyse auf ein Docker-Problem hin? Mache mal eine Kurzzusammenfassung mit deinen Einstellungen und was du schon weißt, bzw. wo genau du Hilfe brauchst .... Du schreibst "Netzwerkproblem" ... welche Hosts sind nicht erreichbar, was bezweckst du ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 August 2020, 19:11:07
Und am besten, mach einen eigenen Thread dazu auf. Mit 64 Seiten ist dieser schon gut gefüllt ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 August 2020, 20:29:01
Zitat von: MarkoP am 25 August 2020, 14:48:32
Ich habe wirklich nicht sonderlich viel Ahnung und muss noch vieles lernen.
Bitte sagt mir deshalb einfach was ihr braucht oder wie ich euch behilflich sein kann.

Ich habe den anderen POst mal "angelesen". Die Config von betateilchen funktioniert bei mir im Docker einwandfrei. Da schließe ich mal ein Problem mit dem Fhem-Docker aus.

SCheinbar ist QNAP-Nas nicht die beste Wahl für Docker ... bist nicht der einzige der "komisches" Verhalten hat. Ein anderer User (balli1187) hat auch ein Netzwerkproblem ... auch wenn er ein komplexeres Setup hat .... Ich denke du bist im QNAP Forum besser aufgehoben. Oder du suchst jemanden hier der QNAP verwendet, ggf. balli1187, vielleicht hast du bei den Netzwerksettings eine Option übersehen, Docker HOst only, Gateway nicht gesetzt, ... was auch immer.

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

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 25 August 2020, 21:30:35
@kadettilac89
Nun, ich habe ja auch nicht behauptet, dass es ein Problem mit dem Fhem-Docker gibt.
Gehe davon aus, dass es an der Konfiguration liegt, doch leider kenne ich mich damit eben noch zu wenig aus, deshalb habe ich hier auf Hilfe gehofft.
Keine Ahnung ob es was bringt wenn ich Screens von den erweiterten Einstellungen mache und hier zeige.
Eventull fällt jemand ja eine falsche Einstellung auf.

Im QNAP-Forum braucht man eigentlich keine Hilfe zu erwarten, da ist die Benutzerfrequenz so gering, dass man ewig auf eine Reaktion wartet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 25 August 2020, 22:37:43
Also ich kann vom PC aus die IP des Fhem-servers anpingen.
Ich kann auch die Clever-Tanken Webseite anpingen

Aus dem Terminal des Fhem-Servers heraus kann ich den PC und die Fritzbox anpingen
Nur die externe Webseite (Clever-Tanken) kann ich nicht anpingen, dann gibt er mir "Unknown Host" zurück

Irgendwo muss also die Weitergabe zwischen der Fritzbox und dem Externen Netzwerk vom Fhem-server heraus gestört sein. Zumindest verstehe ich es so.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 August 2020, 22:47:50
Zitat von: MarkoP am 25 August 2020, 21:30:35

Keine Ahnung ob es was bringt wenn ich Screens von den erweiterten Einstellungen mache und hier zeige.
Eventull fällt jemand ja eine falsche Einstellung auf.

Im QNAP-Forum braucht man eigentlich keine Hilfe zu erwarten, da ist die Benutzerfrequenz so gering, dass man ewig auf eine Reaktion wartet.
Glaskugel ... hast du eine FRitzbox? Die Einstellungen des Virtuellen Switches sind idetisch zu Fritzbox-Default settings ... das könnte schon mal IP Konflikte ergeben. Oder ist es gewollt, dass der Docker-Container als Gateway direkt die evtl. vorhandene Fritzbox hat?

Ansonsten ... Einstellungen des virtuellen Switch 3 ... wie gehts da weiter ...

Zu QNAP-Forum ... das ist der Nachteil von exotischer Hardware bzw. Anwendungen ...

Hast du keine Anleitung oder Handbuch in dem eine Beispielkonfiguration enthalten ist? Würde mir eine Anleitung suchen, reset machen und bei Null beginnen, wenns dann immer noch nicht geht diese Anleitugn mit posten ...

Mache bitte einen eigenen Post dazu auf wie schon von Wernieman vorgeschlagen, dein Problem hat nichts mit Fhem-Docker zu tun. POste dort die Konfiguration der ganzen Netzwerkeinstellungen in deinem NAS ... Fhem, Virtual Switch 3, ... was sonst noch drin hängt ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 25 August 2020, 23:18:44
Ja, der Router ist eine Fritzbox.
Nein, habe keine Anleitung, ist bei QNAP grundsätzlich Mangelware und wenn dann ausschließlich in Englisch. Trotzdem würde ich QNAP jetzt nicht als exotisch bezeichnen. Ist neben Synology der Führende Anbieter von NAS-Systemen.

Was die Einstellungen angeht, wenn mir mal jemand den ganzen Kram und vorallem seine Auswirkungen erklären würde, könnte ich auch die Fragen beantworten.
Kann nur dazu sagen, dass ich zwischendurch rumprobiert habe und dem virtuellen Switsch mal die IP des Fhem-Servers und ein anderes Mal auch eine unbenutzte IP zu geben. In beiden Fällen war die Fhem Oberfläche nicht mehr erreichbar. Im ersten Fall sogar so extrem, dass auch die NAS-Benutzeroberfläche nicht mehr erreichbar war und nur ein Kaltstart des NAS geholfen hat.

Was den eigenen Post angeht, hatte ich ja schon und bin hierhin verwiesen worden. Wo in welchem Unterforum soll ich denn posten?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 August 2020, 06:41:29
mit exotisch meine ich auch Docker auf Nas ... bezogen auf die Aussage dass es kaum Dokumente gibt und auch die Reaktionen auf Fragen in entsprechenden Foren ...

Wenn hierher verwiesen wurde hatte vielleicht jemand Verdacht, dass es am Container liegen könnte oder eine simple, und bekannte, Einstellung im Docker ist ... dem ist scheinbar nciht so. Das Beispiel von betateilchen läuft ja bei mir im Docker.

Ob nun eigener Post oder der bereits offene ... du kannst auch den offenen weiter nutzen ... es bezog sich darauf, dass dein Problem nicht am Fhem-Container liegt wofür dieser Thread da ist.

Du wirst auch keinen finden der dir den "ganzen Kram" erklärt, dein Problem liegt an irgend welchen Netzwerkeinstellungen. Möglicherweise nicht mal QNAP-spezifisch. Für den Kram studieren Leute mehrere Semester.

Mit dem Hinweis einen reset des Docker Setup würdest du halt ausschließen, dass du durch Tests schon irgend etwas eingestellt hast, woran ein Experte erstmal nicht denkt weil es keinen Sinn macht. Was nun aber Sinn macht kann jemand der ein Problem hat wie du nicht beurteilen. Deine Anforderung mit dem Container ins Internet zu kommen ist ein Basic ... dafür sollte es keine, oder zumindest keine große Konfiguration benötigen.

Du hast einen virtual Switch, ist der im private Mode .. nur ein Beispiel ... du kannst ja mal die ganzen Einstellungen mit Screenshots in ein Dokument machen, aller Komponenten, FHEM hast du schon irgendwo, es gibt noch virtual Switch, Vlan settings, DNS, DHCP, ggf. Portforwarding, gibts in QNAP eine Firewall?  ... vielleicht nimmt sich jemand die Zeit und geht das mal durch ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 August 2020, 06:49:00
Noch ein Nachtrag ... im Screenshot des QNAP-Forums ist ein Adapter mit einem blauen Globus dargestellt, scheinbar ein Indikator dass Internet verfügbar ist. Dieses Symbol fehlt bei dir im virtual Switch. Viellecht musst du / kannst du das beim gewählten Adapter einstellen, oder es fehlt ein Adapter mit der Freigabe ....

https://forum.qnap.com/viewtopic.php?t=147457#p709471

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 26 August 2020, 07:58:02
Bitte mach einen neuen Thread auf. Ich würde hier anfangen auf Netzwerkebene zu debuggen. Meine Glaskugel sagt: DNS Auflösungs Problem
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 26 August 2020, 07:59:24
Sorry, aber dann sag auch an welcher Stelle ich den dritten Threat aufmachen soll?
Ich blicke duch die Struktur der Unterforen nur bedingt durch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 26 August 2020, 08:03:52
"Anfängerfragen" oder "Sonstiges" würde ich Tippen ... im Zweifel bei Sonstiges. Du kannst dann auch gerne in diesem Thread daraufhin verlinken ...

Bei den Meisten Foren steige ich bei der Struktur nicht durch. Was ich aber (persönlich) hasse: Monstersthreads, wo verschiedene Problemes behandelt werden. Dann kann ein anderer mit dem gleichen  Problem niemals die Lösung finden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 August 2020, 08:49:15
Zitat von: MarkoP am 26 August 2020, 07:59:24
Sorry, aber dann sag auch an welcher Stelle ich den dritten Threat aufmachen soll?
Ich blicke duch die Struktur der Unterforen nur bedingt durch.
Wenn du dazu schon 2 Threads geöffnet hast dann kannst auch einen der beiden weiter verwenden, du musst nur die INformationen zusammentragen, vor allem dass die Definition bei anderen im Docker funktioniert und es sehr wahrscheinlich an deinem QNAP setup liegt, nicht an FHEM-Dockerimage ... einen dritten Thread zum selben Thema musst du nicht öffnen. Betonung "selbes Thema". Bei Bedarf kannst den Thread auch in ein anderen Forumteil verschieben ... aber der eine, hier verlinkte, ist schon im Anfängerforum.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 26 August 2020, 09:10:13
Dann würde ich sagen, dass wir das Thema im anderen Threat unter "Anfängerfragen" weiterführen.
Dort wurde das Problem ja immer weiter eingeschränkt und bereits viele Informationen zusammengetragen.

In meinem letzten Post dort habe ich auch bewusst darauf hingewiesen, wohin sich die vermutliche Fehlerursache (Kommunikation zwischen Container und Extern) verschoben hat.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 28 August 2020, 09:53:56
EDIT: Ich habe gerade bereits Grafana mit in das .yml File aufgenommen.

Hallo zusammen,
ich habe das Gefühl, dass ich nach 8 Monaten meine Docker container aktualisieren müsste.
Im Fhem Container ist ja eine aktualisierung drin, die ich auch fleißig genutzt habe, aber was ist mit dem Debian?
Aus Unwissenheit habe ich dort natürlich auch ein Login gemacht und es von Hand aktualisiert. Ist das richtig so?

Wäre das hier auch ein Weg, um die neuesten Konfigurationen zu bekommen, oder schieße ich mir da ins Knie?

docker stop ...
docker rm ...
docker pull ...
docker run ...


Ich möchte natürlich auch rausbekommen, wo ich unsauber gearbeitet habe und z.B. cpam innerhalb des Containers verwendet habe, ohne es im .yml file zu laden.

Hier ist meine .yml Datei

version: '3.3'

networks:
  net:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/24
volumes:
  portainer_data:

services:

  fhem:
    image: fhem/fhem:latest
    restart: always
    network_mode: host
    privileged: true
    volumes:
      - "./core/:/opt/fhem/"
#      - "./core/contrib/configDB/configDB.conf:/opt/fhem/configDB.conf"
    environment:
      PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"
      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare"
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
#      CONFIGTYPE: configDB
    depends_on:
      - "mysql"

  portainer:
    image: portainer/portainer:latest
    restart: always
    command: -H unix:///var/run/docker.sock --no-auth
    network_mode: host
    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
      - ./certs/portainer.key:/certs/portainer.key
      - ./certs/portainer.crt:/certs/portainer.crt

  mysql:
    image: hypriot/rpi-mysql
    restart: always
    network_mode: host
    expose:
        - "3306"
        - "33060"
    ports:
        - "3306:3306"
        - "33060:33060"
    volumes:
        - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
        - ./mysql/data:/var/lib/mysql
        - ./mysql/log:/var/log
        - ./mysql/mycustom.cnf:/etc/mysql/conf.d/custom.cnf
    environment:
        - MYSQL_ROOT_PASSWORD=xxxxxxx
        - MYSQL_DATABASE=fhem
        - MYSQL_USER=fhemuser
        - MYSQL_PASSWORD=xxxxxxx

  zigbee2mqtt:
    image: koenkk/zigbee2mqtt
    volumes:
      - ./zigbee2mqtt/data:/app/data
      - /run/udev:/run/udev:ro
    devices:
      - /dev/ttyACM0:/dev/ttyACM0
    restart: always
    network_mode: host
    privileged: true
    environment:
      - TZ=Europe/Berlin

  grafana:
    image: grafana/grafana:latest
    restart: always
    network_mode: host
    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=xxxxxxxx
      - 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"

  renderer:
    image: grafana/grafana-image-renderer:latest
    restart: always
    network_mode: host
    expose:
      - "8081"
    ports:
      - "8081:8081"
    depends_on:
      - "grafana"

Grafana ist bereits mit aktiviert, es wurde jedoch noch nicht damit gemacht.

Könnte mir bitte jemand die einzelnen Schritte als Anleitung kurz auflisten?

Gruß
    Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 10 September 2020, 09:31:00
Hallo, hab mal eine Frage die einige wahrscheinlich ziemlich blöd finden werden, aber ich finde keine Lösung.

Es gibt genug Anleitungen für Fhem wo per sudo Bibliotheken oder Berechtigungen geladen/gesetzt werden müssen. Leider sind diese Anleitungen in der Regel für Raspi's geschrieben, so dass es heißt sich per ssh einzuwählen. Das funktioniert ja leider bei einer Fhem-Installation auf dem Docker nicht so einfach.

Wenn ich es im Docker über das Terminalfenster mache wird die Verarbeitung immer mit Code 1 beendet und ich bekomme beispielsweise folgendes angezeigt:
sudo: error in /etc/sudo.conf, line 0 while loading plugin "sudoers_policy"                                                                                                                                                                                                                                                       
sudo: /usr/lib/sudo/sudoers.so must be only be writable by owner                                                                                                                                                                                                                                                                   
sudo: fatal error, unable to load plugins


Daher meine - vielleicht blöde - Frage, wie und wo muss ich die Sudo-Befehle absetzen.
Gibt es eine andere Möglichkeit?

Mein Fhem läuft im Standard-Docker auf einem QNAP NAS mit ARM-Prozessor in der aktuellsten Container-Station.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 10 September 2020, 09:45:29
Ich kenne den FHEM Container nicht, aber ...

Im Allgemeinen bist Du schon root, wenn Du per "docker exec -it <Containername> /bin/bash" reingehst.

Bei (fast) allen Container gibt es auch nach dem "einloggen" im Terminal ein "Prompt". Also z.B. root@<Containername>:
In diesem Falle steht der User (hier eben root:) auch gleich drin. Wenn Es nicht so ist, mußt Du schauen wie Du root werden kannst. Sehr häufig ist bei Dockr-Containern die "sudo"-Umgebung nicht installiert.

Du solltest aber eher beim Containerbauen oder starten die Zusätzlichen Erweitrungen durchführen, als im  Container selber "zu pfuschen". Für Debug/Entwickler-Zwecke habe ich es selber schon gemacht, aber man sollte sich merken, das bei einem "neumachen" des Containers diese Änderungen verlorengehen.

Der Wichtigste Sinn von Containern ist, das man auf einem anderen System den Container bauen und Testen kann und dann weiß, das er im Zielsystem auch funktionieren muß (sollte). Dazu darf er aber eben nicht manuell angepasst werden.
Hinweis: Änderungen an der docker-compose.yml sind keine manuellen Änderungen in diesem Sinne ;o)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 10 September 2020, 09:54:10
Hallo zusammen,

leider bin ich mit meinem Refresh für den Docker Container noch nicht weiter gekommen.
Könnte eventuell mal jemand etwas hierzu https://forum.fhem.de/index.php/topic,89745.msg1081471.html#msg1081471 (https://forum.fhem.de/index.php/topic,89745.msg1081471.html#msg1081471) schreiben?

Genau das möchte ich jetzt bereinigt wissen :-)
Zitat von: Wernieman am 10 September 2020, 09:45:29
Du solltest aber eher beim Containerbauen oder starten die Zusätzlichen Erweiterungen durchführen, als im  Container selber "zu pfuschen". Für Debug/Entwickler-Zwecke habe ich es selber schon gemacht, aber man sollte sich merken, das bei einem "neumachen" des Containers diese Änderungen verloren gehen.
Hinweis: Änderungen an der docker-compose.yml sind keine manuellen Änderungen in diesem Sinne ;o)

Viele Grüße
     Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 10 September 2020, 10:25:08
ZitatIm Allgemeinen bist Du schon root, wenn Du per "docker exec -it <Containername> /bin/bash" reingehst.
Du meinst im Terminal des Dockers oder wo? Dort ergibt die Ausführung jedenfalls folgende Rückmeldung mit einem Code 126: oci runtime error: exec failed: container_linux.go:265: starting container process caused "exec: \"docker\": executable file not found in $PATH" Was genau versteht du unter Containername? die IP des Containers, den Namen der in der Containerstation angezeigt wird?

ZitatBei (fast) allen Container gibt es auch nach dem "einloggen" im Terminal ein "Prompt". Also z.B. root@<Containername>
Ich bekomme ein Promt in einem kleinen Dialogfenster in dem als Beispieltext lediglich "/bin/bash" angezeigt wird. Es ist jedoch nicht ersichtlich ob man root ist oder nicht. Es erfolgt auch keine Anmeldung etc.

ZitatDu solltest aber eher beim Containerbauen oder starten die Zusätzlichen Erweiterungen durchführen, als im  Container selber "zu pfuschen"
Wie will ich denn nach zu installieren Bibliotheken beim Containerbauen vorhersehen? Die Aussage erschließt sich mir nicht. Oder bezog sich das auf @ch.eick?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 10 September 2020, 10:29:07
s.o. ich kenne direkt den FHEM Container nicht, nur allgemein Container.

Zu der Doku zum FHEM COntainer gibt es einen Hinweis, wie man Fremderweiterungen einbaut. Bitte siehe dort nach.

Ansonsten .. probiere doch mal einen root-Befehl ohne sudo.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 10 September 2020, 10:49:02
ZitatZu der Doku zum FHEM COntainer gibt es einen Hinweis, wie man Fremderweiterungen einbaut. Bitte siehe dort nach.
Hast du vielleicht eine Quelle? Die Suchanfragen "FHEM COntainer", "FHEM COntainer Fremderweiterungen" und "COntainer Fremderweiterungen" geben keine passenden Ergebnisse zurück.

ZitatAnsonsten .. probiere doch mal einen root-Befehl ohne sudo.
Wenn ich einen kennen würde ...
Spontan fällt mir nur ls ein, wobei ich nicht weiß, ob das ein root-Befehl ist oder nicht. Der jedenfalls funktioniert und liefert ein Ergebnis zurück

Kann ich mich per ssh auf das NAS einklinken und dann weiter in den Container?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 10 September 2020, 11:09:10
Wenn Deine NAS es kann ... kenne mich aber nur mit "reinem" Docker aus. Welches Docker oder Derivat Deine NAS hat, kannst Du nur selber rausfinden.

Doku steht im ersten Beitrag im Thread von Loredo ... oder hier:
https://github.com/fhem/fhem-docker/ (https://github.com/fhem/fhem-docker/)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 10 September 2020, 11:58:15
Zitat von: MarkoP am 10 September 2020, 10:25:08
Du meinst im Terminal des Dockers oder wo? Dort ergibt die Ausführung jedenfalls folgende Rückmeldung mit einem Code 126: oci runtime error: exec failed: container_linux.go:265: starting container process caused "exec: \"docker\": executable file not found in $PATH" Was genau versteht du unter Containername? die IP des Containers, den Namen der in der Containerstation angezeigt wird?
Ich bekomme ein Promt in einem kleinen Dialogfenster in dem als Beispieltext lediglich "/bin/bash" angezeigt wird. Es ist jedoch nicht ersichtlich ob man root ist oder nicht. Es erfolgt auch keine Anmeldung etc.
Wie will ich denn nach zu installieren Bibliotheken beim Containerbauen vorhersehen? Die Aussage erschließt sich mir nicht. Oder bezog sich das auf @ch.eick?
Docker exec ... wird im Terminal des Docker Host eingegeben.
Bei QNAP musst du dafür das admin-Konto und das SSH-Protokoll aktivieren. Danach kannst du dich von einem anderen PC auf die Konsole des NAS einloggen und die Befehle ausführen.

Alternativ kannst du dir portainer installieren und dort in der Web-Oberfläche eine Shell zum FHEM-Container öffnen.
Angesichts deiner (Nach)Fragen würde ich dir eher portainer empfehlen. Per ssh kann man auf dem NAS (so wie auf jedem anderen Host) zu viel kaputt machen, wenn man es noch nicht ganz durchdrungen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 10 September 2020, 12:40:32
Danke werde ich mir anschauen und mich dann ggf. melden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 10 September 2020, 12:58:44
Portainer gibt es auch als fertigen Container .... (Hatte es jetzt ganz vergessen)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 10 September 2020, 13:23:27
Hab ich installiert und wieder gelöscht - komme ich nicht mit klar
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 11 September 2020, 09:53:01
Zitat von: MarkoP am 10 September 2020, 13:23:27
Hab ich installiert und wieder gelöscht - komme ich nicht mit klar
Der Container lief bei mir auf anhieb und dann ist es nur Bunt Klickiklicki :-)

Auszug aus der .yml , achtung, ich habe network_mode: host , das wäre eventuell zu ändern.

  portainer:
    image: portainer/portainer:latest
    restart: always
    command: -H unix:///var/run/docker.sock --no-auth
    network_mode: host
    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
      - ./certs/portainer.key:/certs/portainer.key
      - ./certs/portainer.crt:/certs/portainer.crt


Aufruf im Browser mit dieser URL und schon sieht man alle Container im Überblick. Man muss ja nicht die Docker Configuration damit machen ;-)

http://localhost:9000/#/containers


Gruß
     Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 11 September 2020, 10:21:29
Man muß nicht, kann aber ;o)

Ich kenne nicht die letzte version von Portainer, aber kann man Ihn nicht sogar per copy&paste mit docker-compose.yml "füttern"?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 11 September 2020, 10:55:26
Zitat von: Wernieman am 11 September 2020, 10:21:29
Man muß nicht, kann aber ;o)

Ich kenne nicht die letzte version von Portainer, aber kann man Ihn nicht sogar per copy&paste mit docker-compose.yml "füttern"?
Ich habe da gar nichts gemacht. der Portainer liest die aktuelle Konfiguration anscheinend selber.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 11 September 2020, 11:53:41
Zitat von: Wernieman am 11 September 2020, 10:21:29
Man muß nicht, kann aber ;o)

Ich kenne nicht die letzte version von Portainer, aber kann man Ihn nicht sogar per copy&paste mit docker-compose.yml "füttern"?
Ja das geht - nennt sich dort "Stack". Im Prinzip schreibt man dort seine compose rein. Portainer erkennt aber auch manuell hochgezogene stacks und gruppiert sie entsprechend.

Ich kann leider auch nicht nachvollziehen, weshalb der User damit nicht klarkommt aber gut... wir waren nicht dabei.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 11 September 2020, 13:30:51
Wobei ich persönlich davon ausgehe, das portainer einfach als Konsole ist .....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 14 September 2020, 09:58:35
Natürlich habe ich meine Container in Portainer sehen können.
Doch es gelang mir nicht mich über Portainer (per ssh) auf dem Container einzuwählen und genau darum geht es ja.

Insofern habe ich das Ding nach 1 Woche Probierzeit wieder runtergeschmissen, da es lediglich Recourchen in der Container-Station verbraucht hat.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 14 September 2020, 10:07:24
Zitat von: MarkoP am 14 September 2020, 09:58:35
Natürlich habe ich meine Container in Portainer sehen können.
Doch es gelang mir nicht mich über Portainer (per ssh) auf dem Container einzuwählen und genau darum geht es ja.

Insofern habe ich das Ding nach 1 Woche Probierzeit wieder runtergeschmissen, da es lediglich Recourchen in der Container-Station verbraucht hat.
Portainer geht auf die Console des Containers. Hierzu einfach auf ">_" (siehe Bild) klicken.
Danach auf connect und schon bist Du als root angemeldet.
Nun noch mit "su - fhem"  ohne Passwort zum user fhem wechseln.
Zum Abmelden aus Disconnect klicken.

EDIT: Du kannst auch den User vor dem connect auf "fhem" ändern, dann brauchst Du nicht über root zu gehen. (und 2000 € beziehen, ach das war was anderes :-) )
Gruß
     Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 14 September 2020, 10:36:43
Zitat von: MarkoP am 14 September 2020, 09:58:35
Natürlich habe ich meine Container in Portainer sehen können.
Doch es gelang mir nicht mich über Portainer (per ssh) auf dem Container einzuwählen und genau darum geht es ja.

Insofern habe ich das Ding nach 1 Woche Probierzeit wieder runtergeschmissen, da es lediglich Recourchen in der Container-Station verbraucht hat.
Bei mir funktioniert die Console, so wie von ch.eick beschrieben, reibungslos....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 14 September 2020, 10:47:45
Kann halt nur sagen wie es bei mir war.
Ich schau es mir aber gerne noch mal an.
Das erste Bild ist mir jedenfalls überhaupt nicht geläufig, bzw. nirgendwo aufgefallen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 14 September 2020, 10:56:03
Zitat von: MarkoP am 14 September 2020, 10:47:45
Das erste Bild ist mir jedenfalls überhaupt nicht geläufig, bzw. nirgendwo aufgefallen.
Gruß
    Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 14 September 2020, 12:30:06
Also mein Startbild sah anders aus.
Werde mal schauen ob ich heute Zeit habe es noch mal aufzuspielen und einen Screenshot zu machen. Geht aber nur wenn der Handwerker nicht kommt, was ich nicht hoffe.

Ich meine mich aber auf jeden Fall entsinnen zu können das in meiner Ansicht keine bunten Icons/Buttons waren und an der Stelle stattdessen ein Rahmen mit abgerundeten Ecken genau wie um die einzelnen Container unten. Auch die Linke Leiste ist mir fremd, die sieht ja praktisch aus wie in meiner Dockeroberfläche.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 14 September 2020, 12:53:03
Zitat von: MarkoP am 14 September 2020, 12:30:06
Also mein Startbild sah anders aus.
Werde mal schauen ob ich heute Zeit habe es noch mal aufzuspielen und einen Screenshot zu machen. Geht aber nur wenn der Handwerker nicht kommt, was ich nicht hoffe.

Ich meine mich aber auf jeden Fall entsinnen zu können das in meiner Ansicht keine bunten Icons/Buttons waren und an der Stelle stattdessen ein Rahmen mit abgerundeten Ecken genau wie um die einzelnen Container unten. Auch die Linke Leiste ist mir fremd, die sieht ja praktisch aus wie in meiner Dockeroberfläche.
Mit dem Link geht es direkt zu den Containern, den habe ich natürlich als Bookmark gespeichert

localhost:9000/#/containers

Du hast wahrscheinlich erst mal das aufgerufen und musst Dich dann weiter klicken...siehe Bilder, immer auf "Containers" klicken

localhost:9000


Gruß
     Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 14 September 2020, 13:35:31
Wenn Du sagst: "fast wie meine jetziege Docker-Oberfläche" .... kannst mal schauen, ob die auch ein "Shell-Zugang" anbietet.

Kenne aber Synology-Docker nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MarkoP am 14 September 2020, 14:23:28
@Wernieman
Die Oberfläche in der Container-Station bietet gar keine Zugänge an, nur wenn man in dem Container drin ist, hat man die Möglichkeit ein Terminal-Fenster zu öffnen mit einer Einzeiligen Eingabemaske. doch von da ausgeführte Befehle funktionieren eben nicht. Habe ich alles hier schon mit Auszügen aufgeführt. Und es ist ein QNAP-NAS, keine Synology.

@ch.eick
Ich muss es mir ansehen. Kann halt nur sagen, dass ich in der Container-Station das Image vom Portainer gezogen und installiert habe. Alles andere muss ich erst noch mal nachschauen, da will ich nichts falsches sagen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 15 September 2020, 17:19:16
Hallo zusammen,
es wurde schon ein/zwei mal gefragt, aber entweder nicht beantwortet oder mir hat sich die Antwort nicht erschlossen.
Ich würde gerne die Bluetooth SS vom Host im fhem Container nutzen.
Zum einen zur Anwesenheitserkennung und für das Modul XiaomiBTLESens mit Temperatursensoren.
Mit --device=/dev/bus/usb/001/005:/dev/bus/usb/001/005 scheine ich die Bluetooth Schnittstelle in den Container weiterzureichen. Das wars dann aber. Wenn ich auf der Konsole im Container versuche die bluetooth Schnittstelle anzusprechen klappt das nicht, so als ob die nötigen Dienste nicht installiert sind.
Weiss jemand wie das funktioniert?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: burgi400 am 20 September 2020, 14:16:34
Schliesse mich an, ich finde auch keine hilfreichen Hinweise, wie ich Bluetooth vom pi4 im Image nutzen kann. Ich komme immer mehr zu dem Schluss, dass FHEM, wenn man es mit heterogenen Moduken nutzt, nichts für Docker ist. Suche jetzt schon 4 Tage, wenn ich das bei jedem genutzten Fremdmodul machen muss, ist der Raspi längst Staub, bis ich alles am laufen habe....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 20 September 2020, 18:32:07
@ burgi400
Ich habe die Bluetooth Schnittstelle jetzt online, indem ich --net=host eingstellt habe. Ist keine tolle Lösung, aber zumindest läuft es damit.
Ob Docker dann sinnvoll ist, weiss ich nicht aber zumindest funktioniert es. Alle anderen USB Schnittstellen konnte ich vorher erfolgreich ohne diese Änderung an den Container weiterreichen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 20 September 2020, 18:44:32
Zitat von: geohem am 15 September 2020, 17:19:16
Hallo zusammen,
es wurde schon ein/zwei mal gefragt, aber entweder nicht beantwortet oder mir hat sich die Antwort nicht erschlossen.
Ich würde gerne die Bluetooth SS vom Host im fhem Container nutzen.
Zum einen zur Anwesenheitserkennung und für das Modul XiaomiBTLESens mit Temperatursensoren.
Mit --device=/dev/bus/usb/001/005:/dev/bus/usb/001/005 scheine ich die Bluetooth Schnittstelle in den Container weiterzureichen. Das wars dann aber. Wenn ich auf der Konsole im Container versuche die bluetooth Schnittstelle anzusprechen klappt das nicht, so als ob die nötigen Dienste nicht installiert sind.
Weiss jemand wie das funktioniert?

Teste mal
1) Container --privileged
2) Container --net host

Bluetooth im Container ist nicht so einfach .. ich habs selber mal versucht aber dann anders gelöst. Ich glaub aber mit privileged und/oder host-mode ging es irgendwie.

Edit: hast es selber auch grad gepostet ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: geohem am 20 September 2020, 20:30:32
:) @kadettilac89 trotzdem Danke. Mit privileged hat es übrigens nicht funktioniert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 22 September 2020, 18:23:54
Zitat von: burgi400 am 20 September 2020, 14:16:34
Schliesse mich an, ich finde auch keine hilfreichen Hinweise, wie ich Bluetooth vom pi4 im Image nutzen kann. Ich komme immer mehr zu dem Schluss, dass FHEM, wenn man es mit heterogenen Moduken nutzt, nichts für Docker ist. Suche jetzt schon 4 Tage, wenn ich das bei jedem genutzten Fremdmodul machen muss, ist der Raspi längst Staub, bis ich alles am laufen habe....
kannst / willst du das auch etwas erörtern? Du vermutest, dass hetrogene Systeme - Fhem Basis System??? - nicht sauber mit Docker läuft. Dann sprichst du im nächsten Satz von Fremdmodulen, was aber eben dann kein hetrogenes System mehr ist.

Bluetooth-Thema ist in Docker nicht so einfach zu lösen, aber 4 Tage suchen um das Bluetooth Thema zu lösen? Docker Topics kann man aber auch nicht FHEM ankreiden.

Gibt es konkrete Probleme die mit dem Fhem-Docker zu tun haben wo man dir helfen kann? Oder scheiterst du an Docker Basics? Ich selber hatte kaum Probleme beim Umstieg, hängt aber wie du schon sagst von den verwendeten Modulen bzw. den Resourcen die man durchreichen will ab.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 22 September 2020, 18:46:54
Sorry für die vielleicht dumme Frage aber warum gibt es da ausgerechnet bei Bluetooth solche Probleme oder gilt das generell für USB-Sticks?
Ich lese immer nur von Bluetooth und frage mich woran das liegt?

Warum werden diese Sticks (werden ja nicht zufällig alle den gleich haben) nicht richtig durchgereicht?

Vielleicht eine etwas unorthodoxe alternative / Workaround:
Ich habe einen Selbstbau-CUL an eine Enigma-Box (=Linux) gesteckt und dort mit dem Paket ser2net den CUL im Netzwerk verfügbar gemacht. Anstatt des Pfades zur seriellen Schnittstelle habe den CUL dann per IP und Port in FHEM eingebunden - funktionierte auf Anhieb perfekt.

Wer also seinen Bluetooth-Stick auch an einen anderen Host stecken könnte, kann es auf dem Weg probieren.

Edit: gerade kommt mir die verrückte Idee, dass dies ja vielleicht auf auf dem selben Host funktioniert ???
Dann halt über localhost bzw. Host-IP
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 22 September 2020, 19:07:18
Zitat von: balli1187 am 22 September 2020, 18:46:54
Sorry für die vielleicht dumme Frage aber warum gibt es da ausgerechnet bei Bluetooth solche Probleme oder gilt das generell für USB-Sticks?
Ich lese immer nur von Bluetooth und frage mich woran das liegt?

Warum werden diese Sticks (werden ja nicht zufällig alle den gleich haben) nicht richtig durchgereicht?

Vielleicht eine etwas unorthodoxe alternative / Workaround:
Ich habe einen Selbstbau-CUL an eine Enigma-Box (=Linux) gesteckt und dort mit dem Paket ser2net den CUL im Netzwerk verfügbar gemacht. Anstatt des Pfades zur seriellen Schnittstelle habe den CUL dann per IP und Port in FHEM eingebunden - funktionierte auf Anhieb perfekt.

Wer also seinen Bluetooth-Stick auch an einen anderen Host stecken könnte, kann es auf dem Weg probieren.

Edit: gerade kommt mir die verrückte Idee, dass dies ja vielleicht auf auf dem selben Host funktioniert ???
Dann halt über localhost bzw. Host-IP

Wenn du einen nano-Cul hast dann reichst du einfach Serial-by ID in Docker-Compose als Device durch. Das funktioniert einwandfrei. Bluetooth ist jedoch kein normales Device sondern wird als Network Device behandelt. Dann musst du "--net host" angeben damit der Container uneingeschränkt auf Network zugreifen kann. Das ist etwas verwirrend, da man ja eingentlich ein USB-Device (Dongle) durchreichen will.

Ich denke, selbst mit ser2net must du --net host angeben da es auch wieder Network device ist ...

Für normale Anwesenheitserkennung per Bluetooth (wahrscheinlich der häufigste Anwendungsfall) kann man auf dem HOst presenced installieren und dann per ssh von Docker auf den presenced-Dienst der dann auf dem Host läuft zugreifen. Das hab ich so laufen und man braucht keinen --net host Zusatz.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 22 September 2020, 19:47:56
Zitat von: kadettilac89 am 22 September 2020, 19:07:18
Wenn du einen nano-Cul hast dann reichst du einfach Serial-by ID in Docker-Compose als Device durch. Das funktioniert einwandfrei. Bluetooth ist jedoch kein normales Device sondern wird als Network Device behandelt. Dann musst du "--net host" angeben damit der Container uneingeschränkt auf Network zugreifen kann. Das ist etwas verwirrend, da man ja eingentlich ein USB-Device (Dongle) durchreichen will.

Ich denke, selbst mit ser2net must du --net host angeben da es auch wieder Network device ist ...

Für normale Anwesenheitserkennung per Bluetooth (wahrscheinlich der häufigste Anwendungsfall) kann man auf dem HOst presenced installieren und dann per ssh von Docker auf den presenced-Dienst der dann auf dem Host läuft zugreifen. Das hab ich so laufen und man braucht keinen --net host Zusatz.
Okay, danke für die Erklärung.
Kann ich trotzdem nur bedingt nachvollziehen, da ich ja aus dem Container auch andere Geräte im Netzwerk erreiche aber da kenn ich mich im Detail zu wenig aus.

Was ich sagen kann:
Mein FHEM-Docker läuft nicht mit — net host und ich habe trotzdem kein Problem den nanoCUL zu erreichen.
Allerdings ist es fraglich ob ser2net hier überhaupt hilfreich ist, wenn der Bluetooth-Stick da anders erkannt/behandelt wird. Käme wohl auf den Versuch drauf an.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 22 September 2020, 20:19:38
Zitat von: balli1187 am 22 September 2020, 19:47:56
Mein FHEM-Docker läuft nicht mit — net host und ich habe trotzdem kein Problem den nanoCUL zu erreichen.
Das hab ich auch geschrieben ".... Wenn du einen nano-Cul hast dann reichst du einfach Serial-by ID in Docker-Compose als Device durch. Das funktioniert einwandfrei. Bluetooth ist jedoch ...."

normale USB-Devices brauchen das --net host NICHT. Serial-by ID meinte ich die Adresse mit der das USB-Gerät in /dev/** angezeigt wird. Es wird empfohlen die Geräte mit der Hardware-ID anzulegen da die immer identisch ist ... z. B. /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_S4014LPL-if00-port0:/dev/ttyUSB0 ... das mit serial/by-id ist im nanoCul oder Thread auch erklärt.

https://docs.docker.com/network/host/
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 23 September 2020, 07:16:55
Zitat von: kadettilac89 am 22 September 2020, 20:19:38
Das hab ich auch geschrieben ".... Wenn du einen nano-Cul hast dann reichst du einfach Serial-by ID in Docker-Compose als Device durch. Das funktioniert einwandfrei. Bluetooth ist jedoch ...."

normale USB-Devices brauchen das --net host NICHT. Serial-by ID meinte ich die Adresse mit der das USB-Gerät in /dev/** angezeigt wird. Es wird empfohlen die Geräte mit der Hardware-ID anzulegen da die immer identisch ist ... z. B. /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_S4014LPL-if00-port0:/dev/ttyUSB0 ... das mit serial/by-id ist im nanoCul oder Thread auch erklärt.

https://docs.docker.com/network/host/
Ich wollte darauf hinaus, dass kein --net host notwendig ist, um mit ser2net zu arbeiten.

Aber wenn der Bluetooth dongle nicht per serieller Schnittstelle angesprochen wird, ist das vermutlich dann auch egal.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 23 September 2020, 08:00:15
ok, ich glaube nicht dass es geht. Habe es aber auch nicht getestet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 28 September 2020, 12:20:52
Der Zugriff per —net host ist anscheinend notwendig, um den Bluetooth Stack anzusprechen.
Ich verwende es für das PRESENCE Modul und mache es über LAN-Bluetooth in einen eigenen Container ausgelagert. Damit kann FHEM weiter im Bridge-Modus laufen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sturi2011 am 28 September 2020, 15:02:31
Hallo,

In dem Docker Image wird die Version von OpenSSL aus Dezember 19 verwendet.
Diese führte die Option CipherString = DEFAULT@SECLEVEL=2 in der
/etc/ssl/openssl.conf ein. Damit werden Zertifikate unter 2k Schlüssellänge nicht
mehr unterstützt. Da viele MQTT Geräte nur schwache Algorithmen verwenden ist
hier ein Auskommentieren oder das Setzen von CipherString = DEFAULT@SECLEVEL=1
erforderlich. Bitte in die Beschreibung aufnehmen oder direkt über das Dockerfile
anpassen.

Vgl.:
https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1

Gruß Andreas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 29 September 2020, 08:57:52
Zitat von: Sturi2011 am 28 September 2020, 15:02:31Da viele MQTT Geräte nur schwache Algorithmen verwenden ist
hier ein Auskommentieren oder das Setzen von CipherString = DEFAULT@SECLEVEL=1
erforderlich. Bitte in die Beschreibung aufnehmen oder direkt über das Dockerfile
anpassen.
Das wäre aus meiner Sicht wieder mal das Kurieren an Symptomen mit Einfluss auf das ganze System. Wie ersichtlich handelt es sich hier um einen System-DEFAULT, den eine Applikation auf das benötigte Niveau umsetzen kann.
Das wäre der richtige Weg. Andere Distributionen werden hier sicherlich nachziehen und das Problem sollte im MQTT-Modul gelöst werden.

PS: Ich habe mir das mal kurz angesehen. Der eigentliche Code für die OpenSSL-Ansteuerung ist in der TcpServerUtils.pm. Der müsste erweitert werden, um den CipherString setzen zu können. MQTT bräuchte dann eine Steuerung. Ist die Frage, wieviel man da freigibt. Ich würde das ganze wahrscheinlich als Attribut SSL_SECLEVEL nennen und nur 0, 1 und 2 auswählbar machen.

Code für das Protokoll ist sowieso schon drin:
  if($hash->{SSL}) {
    # Forum #27565: SSLv23:!SSLv3:!SSLv2', #35004: TLSv12:!SSLv3
    my $sslVersion = AttrVal($hash->{NAME}, "sslVersion",
                     AttrVal("global", "sslVersion", undef));

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sturi2011 am 30 September 2020, 12:28:52
Hallo,

das wäre mit Sicherheit die sicherere Methode.
Die Änderung in der openssl.con betriff sonst den gesamten Host.
Es muss halt dann für alle Module, die TCPServerutils.pm benutzen angepasst werden.

Das andere ist eher ein quick & dirty Workaround.

Gruß Andreas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: moonsorrox am 30 September 2020, 16:10:08
ich habe mir das heute mal auf meinem Unraid Server installiert, war mir nicht so ganz klar wie ich das eigentlich machen soll und habe es aber hinbekommen...

Was mich interessiert ist die latest Version, meine ist Latest Revision: 22889.
Das ist ja momentan die aktuelle.

Auf der Startseite hatte ich gesehen das dort unter image.version aber die 5.8_1.1.0 steht
Bei mir steht image.version 6.0-s22528_v2.2.4 aktuell haben wir ja schon 5.9..... ist unter Docker die 6.0 schon die aktuelle..?

Ein Update hatte ich gemacht und es ist wie geschrieben die latest. Ein weitere Check sagt nothing to do...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 30 September 2020, 20:32:34
Zitat von: Sturi2011 am 30 September 2020, 12:28:52
das wäre mit Sicherheit die sicherere Methode.
Die Änderung in der openssl.con betriff sonst den gesamten Host.
Es muss halt dann für alle Module, die TCPServerutils.pm benutzen angepasst werden.

Das andere ist eher ein quick & dirty Workaround.
Nein, es muss nicht für alle Module angepasst werden. Typischerweise arbeitet man mit einem Default, der es dann auch beim Standard belässt. Nur wenn das Modul aktiv eingreift, wird auch im Zentralmodul eingegriffen. Und das initiiert meines Wissens für jeden Port eine eigene Instanz.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sturi2011 am 30 September 2020, 20:39:37
Hallo,

das überschreibt aber im Docker Image die gesetzte default scheinbar nicht - siehe ab diesem Post:
https://forum.fhem.de/index.php/topic,114166.msg1088260.html#msg1088260 (https://forum.fhem.de/index.php/topic,114166.msg1088260.html#msg1088260)

Gruß Andreas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: moonsorrox am 06 Oktober 2020, 18:54:20
ich habe bei mir Fhem nach dem vorgehen auf der 1. Seite installiert, allerdings auf einem Unraid Server.
Der hat ja einige Apps/Docker Image schon dabei, aber eben fhem nicht.

Wenn ich das fhem Docker jetzt mal absichern möchte, finde ich es gar nicht...
Die Docker Container die Unraid selbst installiert befinden sich alle an einer STelle, sodas ich diese alle mit dem BackUp Program sichern kann, aber eben nicht fhem.

Ich hänge mal ein Screenshot ran wo die ganzen Container sich befinden da sieht man das besser
Ich habe da eben die Container
binhex-plex
DiskSpeed
LogitechmediaServer usw.

Aber fhem finde ich nicht, wie im zweiten Screenshot zu sehen ist im /opt Verzeichnis nichts drin.
Wo ist fhem jetzt gelandet.ß
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 07 Oktober 2020, 11:08:50
Ist Dir das Prinzip hinter Docker vertraut? Entscheidend ist das Mapping der Volumes für die Persistenz. Da, wo Du das Mapping hingelegt hast, da sind die Daten für die Sicherung.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: moonsorrox am 07 Oktober 2020, 13:59:56
Zitat von: guhu am 07 Oktober 2020, 11:08:50
Ist Dir das Prinzip hinter Docker vertraut? Entscheidend ist das Mapping der Volumes für die Persistenz. Da, wo Du das Mapping hingelegt hast, da sind die Daten für die Sicherung.
also ich bin absoluter Docker Neuling und versuche mich da rein zu arbeiten, fällt mir aber momentan etwas schwer.... zu Docker bin ich gekommen weil ich mir einen Unraid Server gebaut habe mit dem ich gut zurecht komme und der einfach zu erstellen ist und prima läuft.
Gekommen bin ich von Proxmox, welcher mir aber zusehends Schwierigkeiten machte.

Auf dem Unraid Server befindet sich ein Apps Store sage ich mal so, der von der Community betreut und wohl auch erstellt wurde und in diesen sind eben die ganzen Docker Container.

Soll heißen ich erstelle mir mit dem App Store einen Docker Container mit ganz geringen Configurationen und die Dinger laufen ohne große Kenntnisse.
z.B. habe ich dort einen Plex , LogitechMediaServer usw.am laufen und dieses ohne große Docker Kenntnisse.
Einen fhem Server gibt es so im App Store nicht, aber der wurde ja hier vorgestellt und den habe ich mir mit diesen Forumsthread und Github erstellt.
Nur dieser Fhem Container ist nich zu finden und mit einem FTP komme ich nicht auf den Fhem Server um  zu suchen und dann eben Dateien rein zu schieben, weil ich nicht alles neu erstellen möchte da mein Fhem doch schon erheblich gewachsen ist.
Das mit dem Mapping sagt mir gar nichts  :-\
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 07 Oktober 2020, 14:31:33
.. dann schau mal nach Docker Grundlagen (unabhängig von FHEM). Und im ersten Beitrag unter "Wie benutze ich das Image?"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: moonsorrox am 07 Oktober 2020, 19:46:03
Zitat von: guhu am 07 Oktober 2020, 14:31:33
.. dann schau mal nach Docker Grundlagen (unabhängig von FHEM). Und im ersten Beitrag unter "Wie benutze ich das Image?"
vielen Dank das hat mir sehr gut geholfen  ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: wk2000 am 09 Oktober 2020, 13:51:56
Moin,

wäre es möglich, folgende Abhängigkeiten direkt ins Docker Image aufzunehmen:

sudo cpan Protocol::WebSocket
sudo pip3 install asyncio websockets importlib_metadata


Sie werden aktuell für die BETA des FHEM Python Binding benötigt, welches wiederum nötig ist, um GOOGLECAST Devices mit FHEM abzufragen. (Siehe: https://github.com/dominikkarall/fhem_pythonbinding)

Kann man ja auch händisch nachinstallieren, dauert aber immer und benötigt zusätzlichen Konfigurationsaufwand.

Hieran anschließend:
Werden eigentlich benötigte Abhängigkeiten von eingecheckten Modulen immer in das  Basisimage mit aufgenommen, oder wie wird das gehandhabt?

Lg,
wk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 09 Oktober 2020, 14:04:15
Zitat von: wk2000 am 09 Oktober 2020, 13:51:56
Werden eigentlich benötigte Abhängigkeiten von eingecheckten Modulen immer in das  Basisimage mit aufgenommen, oder wie wird das gehandhabt?

nur die häufig benötigten. Sonst würde das Image zu groß werden.

Wie gehandhabt:
du hast per Parameter eigene pip-Module einbinden lassen

-e PIP_PKGS="package1 package2"

Wenn es komplexer wird kannst dir auch ein eigenes Image baun. From-Statement im Dockerfile ... hierzu gab es hier schon ein paar Posts ein bischen zurück.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: moonsorrox am 10 Oktober 2020, 13:47:40
ich habe da mal eine generelle Frage.. weil ich etwas nicht verstehe und habe dazu einen eigenen Pos (https://forum.fhem.de/index.php/topic,114909.msg1091316.html#msg1091316)t aufgemacht
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sandmann42 am 12 Oktober 2020, 00:34:50
Hallo zusammen,

ich bekomme den gassistent einfach nicht zum laufen.

mein docker-compose file sieht so aus:


version: '2'

services:
    fhem:
        restart: always
        ports:
            - "8083:8083"
            - "7072:7072"
        image: fhem/fhem:latest
        volumes:
            - ./fhem/core/:/opt/fhem/
        networks:
            - fhem-network
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
            NPM_PKGS: "gassistent_fhem"
        depends_on:
            - "mysql"
            - "mqtt"

... usw.



Das Gassistent Objekt sagt mir aber:


stopped; gassistant-fhem not installed. install with 'sudo npm install -g gassistant-fhem --unsafe-perm'.


wenn ich das packet installiere:


root@linux01:/etc/docker/compose/fhem# sudo npm install -g gassistant-fhem --unsafe-perm
npm WARN deprecated request-promise@4.2.6: request-promise has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142
npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated har-validator@5.1.5: this library is no longer supported
/usr/local/bin/gassistant-fhem -> /usr/local/lib/node_modules/gassistant-fhem/bin/gassistant-fhem
+ gassistant-fhem@3.0.3


ein npm list gassistent-fhem:

root@linux01:/etc/docker/compose/fhem# npm list gassistent-fhem
/etc/docker/compose/fhem
└── (empty)



Meine Fragen:

1) Habe ich den Parameter für die zusätzlichen npm-Modulerichtig in meiner docker.compose Datei gesetzt?
2) Kann Fhem im Docker Container auf meine global installierten npm Module zugreifen? Wenn ja - wieso dann der Parameter?
3) Was passiert wenn ich ein Modul als Parameter übergebe? Wird es dann innerhalb des Containers installiert? Brauche ich das Modul dann überhaupt auf meiner Host-Machine?


Vielen Dank und Freundliche Grüße
Sandmann


Edit: Das Hostsystem ist ein Ubuntu 20.04.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 13 Oktober 2020, 15:35:49
Mahlzeit :-)

Spricht etwas dagegen, dass man im Image schon Python 3.7 nutzt? :-) Das würde diversen neuen Modulen das extra installieren sparen :-)


*EDIT* Oh entschuldigung - es scheint schon 3er Python zu sein... seltsam sehe in meinem bei "python --version" 2.7 :-D - ich schau mal was da los ist. Ein python3 --version bewirkt wahre Wunder! :-D *facepalm*
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 13 Oktober 2020, 19:49:12
Hallo ich bereite mich gerade für Alexa vor.
Installieren musste ich da ja nichts das ging alles.

aber ich habe nun im FHEM Drinnen
alexaFHEM.ProxyConnection
error; user homedir writable by group/other ('chmod 755 /opt/fhem' required)
2020-10-13 19:36:54


wenn ich das ausführe (vermute muss ich aber nach jedem neustart erneut mache) kommt dann ein
alexaFHEM.ProxyConnection
error; users ssh key not protected by group/other ('chmod 600 /opt/fhem/.ssh/id_rsa' required)
2020-10-13 19:39:20


danach kommt dann aber ein
alexaFHEM.ProxyConnection
error; Reverse Proxy replied with neither registered nor unregistered status: out:  err:Bad owner or permissions on /opt/fhem/.ssh/config
2020-10-13 19:40:30

da weiss ich nicht mehr weiter?

die ssh config files haben alle
root@cb4ce06e4267:/opt/fhem/.ssh# ls -l
total 24
-rwxrwxrwx 1 fhem dialout  509 Jul  9  2019 config
-rwxrwxrwx 1 fhem dialout  411 Jul  9  2019 id_ed25519
-rwxrwxrwx 1 fhem dialout   98 Jul  9  2019 id_ed25519.pub
-rw------- 1 fhem dialout 3381 Jul  9  2019 id_rsa
-rwxrwxrwx 1 fhem dialout  742 Jul  9  2019 id_rsa.pub
-rwxrwxrwx 1 fhem dialout  959 Okt 13 19:36 known_hosts


hat noch wer einen tipp wie ich da weiter komme?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: stifft79 am 16 Oktober 2020, 11:40:07
Zitat von: volschin am 11 Mai 2020, 20:41:29
Hi zusammen,
ich habe meinen HM-CFG-USB2 jetzt für die Plattform amd64 dockerized. Falls jemand Interesse hat, habe ich das Image auch bei Docker-Hub (https://hub.docker.com/r/volschin/hmcfgusb) abgelegt.

Grüße
Veit
Hi volschin :)
kannst du mir kurz erklären, wie ich den HM-CFG-USB-2 in FHEM/Docker ans laufen bekommen hast? Sitze nun 4 Tage (mein Urlaub...) davor und bekomme es nicht hin. >:(
Die Anleitung von http://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb (http://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb) habe ich befolgt. Der Stick funktioniert einwandfrei auf dem RasPi ohne Docker.
Das Problem, wo ich jetzt hänge ist, das wenn ich "hmusb" in FHEM öffne, kommt das in Sekundentakt "disconnected:266 init:251".
Den Port "1234 "und den Ordner "/opt/hmcfgusb" ist in der docker-compose.yml eingetragen damit die durchgereicht werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 17 Oktober 2020, 22:23:44
Zitat von: stifft79 am 16 Oktober 2020, 11:40:07
Hi volschin :)
kannst du mir kurz erklären, wie ich den HM-CFG-USB-2 in FHEM/Docker ans laufen bekommen hast? Sitze nun 4 Tage (mein Urlaub...) davor und bekomme es nicht hin. >:(
Die Anleitung von http://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb (http://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb) habe ich befolgt. Der Stick funktioniert einwandfrei auf dem RasPi ohne Docker.
Das Problem, wo ich jetzt hänge ist, das wenn ich "hmusb" in FHEM öffne, kommt das in Sekundentakt "disconnected:266 init:251".
Den Port "1234 "und den Ordner "/opt/hmcfgusb" ist in der docker-compose.yml eingetragen damit die durchgereicht werden.

Ich nutze den Stick mit hmlan. Dazu gibt es ein separates Docker-Image, was läuft. Dieses habe ich ihm privileged-Modus laufen, damit ich Zugriff auf die seriellen Ports habe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: moonsorrox am 22 Oktober 2020, 17:36:13
Eine Frage zum logfile von Fhem im Docker Container, er schreibt mir ja täglich ein neues logfile, ist das so gewollt..?
Ich würde das gerne monatlich haben, aber das logfile ist schreibgeschützt und ich kann es dadurch nicht ändern. Ich habe das Fhem in Docker recht neu und möchte es so langsam komplett machen.

Ich habe es in meinem Produktiv Fhem gesehen das dort in global das logfile so aussieht:./log/fhem-%Y-%m.log und ich es ändern kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 22 Oktober 2020, 18:04:28
Hey @moonsorrox

du kannst mit einer ENV (Environmentvariable) das ganze übersteuern im Dockerfile ist es:
LOGFILE=./log/fhem-%Y-%m-%d.log \

Also einfach eine Env  "LOGFILE" anlegen mit Inhalt
./log/fhem-%Y.log

Ob das nun direkt negative folgen hat habe ich nicht geprüft. :-D Try and Error.

*EDIT ah du wolltest monatlich:
./log/fhem-%Y-%m.log
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Grist am 23 Oktober 2020, 14:10:06
Hallo zusammen,

ich bin gerade dabei meinen aktuellen FHEM (RPi3) auf einem RPi4 mit Docker umzuziehen.

Ich habe einen SIGNALduino:

lrwxrwxrwx 1 root root 13 Oct 22 14:47 usb-SHA_CUL433-if00-port0 -> ../../ttyUSB0


und versuche z.B. dies in Docker-FHEM wie folgt einzubinden:
    devices:
      - "/dev/serial/by-id/usb-SHA_CUL433-if00-port0:/dev/serial/by-id/usb-SHA_CUL433-if00-port0"
      - "/dev/ttyUSB0:/dev/ttyUSB0"



Es funktioniert aber nicht...hier die Docker-Logs:
fhem    | 2020.10.23 14:00:32.899 1: /dev/serial/by-id/usb-SHA_CUL433-if00-port0 reappeared (SIGNALduinoCUL433)
fhem    | 2020.10.23 14:00:34.401 3: SIGNALduinoCUL433: SimpleWrite_XQ, disable receiver (XQ)
fhem    | 2020.10.23 14:00:34.900 3: SIGNALduinoCUL433: StartInit, get version, retry = 0
fhem    | 2020.10.23 14:00:44.915 1: SIGNALduinoCUL433: CheckVersionResp, Not an SIGNALduino device, got for V: undef
fhem    | 2020.10.23 14:00:44.918 3: SIGNALduinoCUL433: StartInit, get version, retry = 1
fhem    | 2020.10.23 14:00:44.957 1: /dev/serial/by-id/usb-SHA_CUL433-if00-port0 disconnected, waiting to reappear (SIGNALduinoCUL433)
fhem    | 2020.10.23 14:00:44.967 3: Setting SIGNALduinoCUL433 serial parameters to 57600,8,N,1
fhem    | 2020.10.23 14:00:44.979 1: SIGNALduinoCUL433: DoInit, /dev/serial/by-id/usb-SHA_CUL433-if00-port0@57600
fhem    | 2020.10.23 14:00:44.979 1: /dev/serial/by-id/usb-SHA_CUL433-if00-port0 reappeared (SIGNALduinoCUL433)
fhem    | 2020.10.23 14:00:46.481 3: SIGNALduinoCUL433: SimpleWrite_XQ, disable receiver (XQ)
fhem    | 2020.10.23 14:00:46.980 3: SIGNALduinoCUL433: StartInit, get version, retry = 0
fhem    | 2020.10.23 14:00:47.020 1: /dev/serial/by-id/usb-SHA_CUL433-if00-port0 disconnected, waiting to reappear (SIGNALduinoCUL433)
fhem    | 2020.10.23 14:00:47.030 3: Setting SIGNALduinoCUL433 serial parameters to 57600,8,N,1
fhem    | 2020.10.23 14:00:47.044 1: SIGNALduinoCUL433: DoInit, /dev/serial/by-id/usb-SHA_CUL433-if00-port0@57600
fhem    | 2020.10.23 14:00:47.045 1: /dev/serial/by-id/usb-SHA_CUL433-if00-port0 reappeared (SIGNALduinoCUL433)
fhem    | 2020.10.23 14:00:49.045 3: SIGNALduinoCUL433: StartInit, get version, retry = 0
fhem    | 2020.10.23 14:00:49.045 3: SIGNALduinoCUL433: StartInit, get version, retry = 0
fhem    | 2020.10.23 14:00:59.063 1: SIGNALduinoCUL433: CheckVersionResp, Not an SIGNALduino device, got for V: undef
fhem    | 2020.10.23 14:00:59.065 3: SIGNALduinoCUL433: StartInit, get version, retry = 1
fhem    | 2020.10.23 14:01:09.083 1: SIGNALduinoCUL433: CheckVersionResp, Not an SIGNALduino device, got for V: undef
fhem    | 2020.10.23 14:01:09.086 3: SIGNALduinoCUL433: StartInit, get version, retry = 2
fhem    | 2020.10.23 14:01:19.107 1: SIGNALduinoCUL433: CheckVersionResp, Not an SIGNALduino device, got for V: undef
fhem    | 2020.10.23 14:01:19.110 3: SIGNALduinoCUL433: StartInit, get version, retry = 3
fhem    | 2020.10.23 14:01:19.110 2: SIGNALduinoCUL433: StartInit, init retry count reached. Closed
fhem    | 2020.10.23 14:01:19.110 2: SIGNALduinoCUL433: CloseDevice, closed


Wie sollte dieses USB-Device in Docker-FHEM eingebunden werden?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 23 Oktober 2020, 15:05:48
Also das hat wenig mit dem spezifischen Docker FHEM Container zu tun - ggf brauchen wir mal einen Docker Hilfe Bereich hier im Forum? :-D
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Grist am 23 Oktober 2020, 20:41:18
Zitat von: Master_Nick am 23 Oktober 2020, 15:05:48
Also das hat wenig mit dem spezifischen Docker FHEM Container zu tun - ggf brauchen wir mal einen Docker Hilfe Bereich hier im Forum? :-D

Das war ein Tip, danke  ;). Also...ich habe einen 2ten Container in Privileged-Mode laufen und der hat "auf das System privilegiert zugegriffen". Vorerst ist das Problem wie folgt "gelöst" (fast):

- FHEM-Container
docker-compose beinhaltet folgende Zeilen für die USB Devices:


....
    volumes:
      - ./fhem/core/:/opt/fhem/
      - /dev/serial/by-id/:/dev/serial/by-id
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
      - /dev/ttyUSB1:/dev/ttyUSB1
...


- 2ter Container läuft nicht im privilegierten Modus

Nächstes Problem: der 2ter Container braucht Zugriff auf GPIO. Der FHEM-Container "findet den GPIO" auch:


....
fhem    | 9. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
fhem    | 10. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
...


Wie kann der FHEM-Container ohne Zugriff auf GPIO gestartet werden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: my-engel am 25 Oktober 2020, 11:01:12
Hallo,

ich komme mit der Einbindung der GPIO auf Docker und dem Modul RPI_GPIO nicht weiter

Vorgeschichte:
Bin auf einen RPI4 mit RaspberryPiOSLite und Docker umgezogen.
Fhem/Docker wird gestartet mit folgenden weiteren Optionen:
(wird u.a. benötigt damit später wiringpi funktioniert.)

--device=/dev/gpiomem:/dev/gpiomem
-v /sys/class/gpio:/sys/class/gpio
-v /sys/devices/platform/soc/fe200000.gpio:/sys/devices/platform/soc/fe200000.gpio


Da das originale wiringpi Paket auf RPI4 nicht funktioniert muss noch V2.52 im Docker installiert werden:

cd /tmp
wget  https://project-downloads.drogon.net/wiringpi-latest.deb
sudo dpkg -i wiringpi-latest.deb


folgende Befehle usw. funktionieren nun in Docker, auch die Impulse auf dem GPIO sind in Docker sichtbar

gpio readall
gpio export 24 in
gpio -g read 24
cat /sys/class/gpio/gpio24/value


Ich kann das Modul RPI_GPIO in fhem anlegen und Attribute setzen und
diese erledigen im Hintergrund auch das Anlegen der gpio-Ordner unter /sys/class/gpio
siehe Bild 1.png

Problem:
- das Modul bekommt nichts von der GPIO und seinen Zuständen mit.
  siehe Bild 2.png
- Beim starten des Container kommt im Container log:
 
  7. Correcting group ownership for /dev/tty* ...
  /entry.sh: line 328: [[: /dev/gpiomem: syntax error: operand expected (error token is "/dev/gpiomem")


das List vom 51_RPI_GPIO:

Internals:
   DEF        24
   FUUID      5c43081f-f33f-0edb-c7f7-29f19b9e3cef8bc6
   FVERSION   51_RPI_GPIO.pm:0.197850/2019-07-05
   GPIO_Basedir /sys/class/gpio
   GPIO_Nr    24
   NAME       GPIOGaszaehler
   NR         303
   STATE      on
   TYPE       RPI_GPIO
   WiringPi_gpio /usr/bin/gpio
   filehandle
   OLDREADINGS:
   READINGS:
     Pinlevel:
       TIME       2020-10-16 21:09:39
       VAL       
   fhem:
     interfaces switch
Attributes:
   active_low yes
   devStateIcon off:10px-kreis-gelb .*:10px-kreis-rot
   direction  input
   group      Gaszaehler
   interrupt  both
   room       Keller->Heizung->Übersicht,Kontrollraum
   toggletostate yes


könnt Ihr mir helfen?

MfG Uwe

----------

EDIT: ich glaube es liegt an den Berechtigungen...

fhem ist in der Gruppe gpio:
root@fhem:/opt/fhem# adduser fhem gpio
The user `fhem' is already a member of `gpio'.


die Dateiberechtigungen stehen auf:
root@fhem:/opt/fhem# ls -la /sys/class/gpio/gpio24/value
-rwxrwxr-- 1 fhem fhem 4096 Okt 17 21:19 /sys/class/gpio/gpio24/value


aber wenn ich in FHEM teste kommt folgendes:
{`cat /sys/class/gpio/gpio24/value`}
cat: /sys/class/gpio/gpio24/value: Permission denied


dann im Container:
sudo chmod 7777 -c -R /sys/class/gpio/gpio24/value
mode of '/sys/class/gpio/gpio24/value' changed from 0777 (rwxrwxrwx) to 7777 (rwsrwsrwt)


und wieder in fhem:
{`cat /sys/class/gpio/gpio24/value`}
cat: /sys/class/gpio/gpio24/value: Permission denied


Ich kapiere es nicht....

MfG Uwe


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Grist am 25 Oktober 2020, 12:30:26
Wenn ich mit "docker-compose up -d" den FHEM starte, dann sehe ich mit "docker-compose logs --follow" wie die Zugriffsrechte auf GPIO "angepasst" werden:

....
fhem    | 9. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
fhem    | 10. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
...


Was ich vorschlagen könnte...starte den Container in Privileged Modus, dann hat der Container Zugriff auf das ganze Subsystem des RPi 4. Das ist halt keine Lösung vorerst, aber es könnte helfen...das Probel zu identifizieren...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Grist am 26 Oktober 2020, 18:43:40
Hallo Uwe,

ich fange auch gerade mit Docker-FHEM an....daher kann ich nicht so behilflich bzgl. der Nutzung mit GPIO sein.

Um das Problem ein bisschen einzugrenzen...wenn kein anderer Container auf dem RPi läuft (wg. Privileged Modus) + keine andere Anwendung dem GPIO "verwendet", dann könntest du folgenden Composer testen:


version: '2'

services:
  fhem:
    restart: always
    container_name: fhem
    privileged: true
    ports:
      - "8083:8083"
      - "7072:7072"
    image: fhem/fhem:latest
    networks:
      - smarthome-network
    environment:
      FHEM_UID: 1000
      FHEM_GID: 1000
      TIMEOUT: 10
      RESTART: 10
      TELNETPORT: 7072
      TZ: Europe/Berlin
      LOGFILE: ./log/fhem-%Y-%m.log
    volumes:
      - ./fhem/core/:/opt/fhem/

networks:
  smarthome-network:
      driver: bridge
      name: smarthome-network


Somit müsste es keine Fehler mehr (mit Rechte anpassen usw.) geben....

Wenn du den Privileged Modus wegnimmst, dann müsst du die Devices angeben/definieren. Ich will jetzt nicht in HW-Details gehen...aber probiere /sys als Volume zu mounten z.B.


    volumes:
      - ./fhem/core/:/opt/fhem/
      - /sys:/sys
    devices:
      - /dev/gpiomem:/dev/gpiomem


usw.

Ich will bloß einen Weg vorschlagen, wie du den Composer Schritt für Schritt anpasst, bis es mit den Devices funktioniert....

MfG
Grist
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: my-engel am 26 Oktober 2020, 21:05:34
Hallo Grist,

Danke für deine Mühe, ich habe folgendes Ergebnis:
mit der von dir vorgeschlagenen docker-compose.yml
im Privileged Modus und ebenfalls ohne Privileged Modus aber mit den volumes und devices
sind die Ergebnisse gleich:

Container Log: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* ...
/entry.sh: line 328: [[: /dev/gpiomem: syntax error: operand expected (error token is "/dev/gpiomem")
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. Generating SSH Ed25519 client certificate for user 'fhem' ...
12. Generating SSH RSA client certificate for user 'fhem' ...
13. Generating SSH client configuration for user 'fhem' ...
14. Adding gateway.docker.internal to /etc/hosts ...
15. Adding host.docker.internal to /etc/hosts ...
16. Pre-authorizing SSH to Docker host for user 'fhem' ...
17. Updating SSH key pinning and SSH client permissions for user 'fhem' ...


ohne installiertem wiringpi:2020.10.26 20:33:30.910 1: PERL WARNING: Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 647.
2020.10.26 20:33:30.918 1: PERL WARNING: Use of uninitialized value $exp_result in pattern match (m//) at ./FHEM/51_RPI_GPIO.pm line 649.
2020.10.26 20:33:30.918 1: PERL WARNING: Use of uninitialized value $exp_result in concatenation (.) or string at ./FHEM/51_RPI_GPIO.pm line 659.
2020.10.26 20:33:35.944 1: PERL WARNING: Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 647.
2020.10.26 20:33:35.989 1: PERL WARNING: Can't exec "export": No such file or directory at ./FHEM/51_RPI_GPIO.pm line 647.
2020.10.26 20:33:36.001 1: Can't open file: GPIOGaszaehler, value
2020.10.26 20:33:36.002 1: GPIOGaszaehler GetFn: readout of Pinvalue fail
2020.10.26 20:33:36.002 1: PERL WARNING: Use of uninitialized value $zustand in concatenation (.) or string at ./FHEM/51_RPI_GPIO.pm line 198.


mit installiertem wirinpi:2020.10.26 20:37:31.773 0: Server started with 11 defined entities (fhem.pl:22990/2020-10-19 perl:5.028001 os:linux user:fhem pid:4039)
2020.10.26 20:38:44.076 1: Can't open file: GPIOGaszaehler, value
2020.10.26 20:38:44.076 1: GPIOGaszaehler GetFn: readout of Pinvalue fail
2020.10.26 20:38:44.077 1: PERL WARNING: Use of uninitialized value $zustand in concatenation (.) or string at ./FHEM/51_RPI_GPIO.pm line 198.


leider kein Erfolg
Gruß Uwe

Edit:  im Container in FHEM funktioniert aber
{`gpio -g read 24`}
sonst aber kein Erfolg
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HankMoody am 26 Oktober 2020, 21:31:05
Hallo zusammen,

ich habe leider folgenden Fehler bei der Verwendung des Docker-Images:
WEB: Can't open server port at 8083: Address already in use. Exiting.

Ich habe das mal in einem eigenen Post genauer beschrieben, weil ich nicht weiß ob das ein Anfängerfehler ist oder speziell am Docker-Image liegt:
https://forum.fhem.de/index.php/topic,115310.0.html (https://forum.fhem.de/index.php/topic,115310.0.html)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: archinaut220379 am 27 Oktober 2020, 22:26:14
Hallo Zusammen,

zum gpio Problem folgende Lösung bzgl. der fehlenden Berechtigung im Verzeichnis /sys/gpio für das Modul rpi_gpio..  für den fhem Nutzer

Container starten mit:

GPIO_GD=997 .

Damit funktioniert das GPIO Modul im Container. Habe aktuell einen RPI4 mit 64bit-ARM am laufen.

Grüsse
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: my-engel am 28 Oktober 2020, 18:23:40
Hallo an alle,

es funktioniert jetzt, der Tip von archinaut220379 hat es gebracht...
wie bist du denn auf die ID 997 gekommen???

MfG Uwe

es kommt zwar noch:
/entry.sh: line 328: [[: /dev/gpiomem: syntax error: operand expected (error token is "/dev/gpiomem")
aber es funktioniert...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 01 November 2020, 09:32:19
Hey leute, ich will von raspi auf intel nuc mit docker umsteigen, alles aufgesetzt den ordner opt/fhem auf den nuc übertragen, aber er will nicht starten bzw bleibt der fhem container im unhealthy Modus hängen. Der log spuckt das aus


  D-Bus not built with -rdynamic so unable to print a backtrace

Aborted (core dumped)

2020.10.30 05:56:31 1: BlockingInformParent (BlockingStart): Can't connect to localhost:32773: IO::Socket::INET: connect: Connection refused

Aborted (core dumped)

2020.10.30 05:56:31 1: BlockingInformParent (BlockingStart): Can't connect to localhost:32773: IO::Socket::INET: connect: Connection refused

dbus[5907]: 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.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 01 November 2020, 09:36:20
Zitat von: Kawaci am 01 November 2020, 09:32:19
Hey leute, ich will von raspi auf intel nuc mit docker umsteigen, alles aufgesetzt den ordner opt/fhem auf den nuc übertragen, aber er will nicht starten bzw bleibt der fhem container im unhealthy Modus hängen. Der log spuckt das aus


  D-Bus not built with -rdynamic so unable to print a backtrace

Aborted (core dumped)

2020.10.30 05:56:31 1: BlockingInformParent (BlockingStart): Can't connect to localhost:32773: IO::Socket::INET: connect: Connection refused

Aborted (core dumped)

2020.10.30 05:56:31 1: BlockingInformParent (BlockingStart): Can't connect to localhost:32773: IO::Socket::INET: connect: Connection refused

dbus[5907]: 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.

Was lauscht denn auf deinem Port 32773? Vielleicht das entsprechende Device mal auskommentieren und schauen ob es dann läuft.
Falls ja dann am besten in der Hilfe zu dem Modul suchen.
Hast du ggf. fehlende Paket nachinstalliert? Da gibt es Umgebungsvariablen für.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 01 November 2020, 10:22:32
Sonst hab ich nichts instaliert! Wie finde ich heraus wer oder was auf diesen port lauscht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 01 November 2020, 13:03:43
als root oder mit sudo
netstat -lntp
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 01 November 2020, 15:57:46
Dort sethen nichts von diesem port
[martin@ubuntu-server:~$ sudo netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name   
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      613/systemd-resolve
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      706/sshd: /usr/sbin
tcp6       0      0 :::9000                 :::*                    LISTEN      1065/docker-proxy   
tcp6       0      0 :::8083                 :::*                    LISTEN      352738/docker-proxy
tcp6       0      0 :::22                   :::*                    LISTEN      706/sshd: /usr/sbin
tcp6       0      0 :::8000                 :::*                    LISTEN      1078/docker-proxy   
martin@ubuntu-server:~$
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 01 November 2020, 16:52:42
Läuft denn der FHEM-Container? Der Port 8083 ist zwar belegt aber das muss nichts heißen.

Sonst Probier es mal auf deinem alten Raspi. Da lief ja alles.

Du könntest auch Google bemühen und nach Problemen mit der angegebenen Lib und Docker suchen (falls du das nicht schon getan hast).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 01 November 2020, 17:08:22
Das alte fhem läuft noch auf dem raspi! Hab den ganzen error gegoogelt aber werde daraus nicht schlau
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 01 November 2020, 21:20:12
so hab den ganzen container noch mal gelöscht und alle Daten von fhem entfernt! Neu vom raspi runter geladen (den Ordner opt) und auf den NUC in das Verzeichnis /home/martin/docker/ übertragen. Beim Download hab  ich alle Dienste die ich bewusst am laufen hatte gestoppt! Dann mit docker run -d --name fhem -p 8083:8083 -v /home/martin/docker/opt/fhem:/opt/fhem fhem/fhem wieder eingespielt! Der container ist gestartet und dann gleich in den unhealthy modus gegangen!

Und das sagt das log! Was soll ich hier reparieren das Ers startet?

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. Generating SSH Ed25519 client certificate for user 'fhem' ...

12. Generating SSH RSA client certificate for user 'fhem' ...

13. Generating SSH client configuration for user 'fhem' ...

14. Adding gateway.docker.internal to /etc/hosts ...

15. Adding host.docker.internal to /etc/hosts ...

16. Pre-authorizing SSH to Docker host for user 'fhem' ...

17. Updating SSH key pinning and SSH client permissions for user 'fhem' ...




Preparing configuration ... done


Starting FHEM ...

2020.11.01 21:08:37 1: reload: Error:Modul 99_cieToRgb deactivated:



2020.11.01 21:08:37 1: reload: Error:Modul 99_myUtilscieToRgb deactivated:



2020.11.01 21:08:37 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid

2020.11.01 21:08:37 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1

2020.11.01 21:08:37 3: From the FHEM_GLOBALATTR environment: attr global nofork 0

2020.11.01 21:08:37 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log

2020.11.01 21:08:37 1: Including fhem.cfg

2020.11.01 21:08:37 3: WEB: port 8083 opened

2020.11.01 21:08:37 3: WEBphone: port 8084 opened

2020.11.01 21:08:37 3: WEBtablet: port 8085 opened

2020.11.01 21:08:38 2: eventTypes: loaded 25667 events from ./log/eventTypes.txt

2020.11.01 21:08:38 3: Opening myJeeLink device 192.168.178.39:81

2020.11.01 21:08:39 3: myJeeLink device opened

2020.11.01 21:08:39 3: VZ_temp: I/O device is myJeeLink

2020.11.01 21:08:39 3: DHT29: I/O device is myJeeLink

2020.11.01 21:08:39 3: EQ3BT: EQ-3 Bluetooth Thermostat 2.0.5

2020.11.01 21:08:39 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_EQ3BT.pm line 226, <$fh> line 147.

2020.11.01 21:08:39 3: telnetForBlockingFn_1604261319: port 46707 opened

2020.11.01 21:08:39 3: EQ3BT: EQ-3 Bluetooth Thermostat 2.0.5

2020.11.01 21:08:39 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_EQ3BT.pm line 226, <$fh> line 154.

2020.11.01 21:08:39 3: Opening MyCUL433 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A505MPOK-if00-port0

2020.11.01 21:08:39 1: MyCUL433: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A505MPOK-if00-port0: No such file or directory

2020.11.01 21:08:39 3: Opening sduino device 192.168.178.33:23

2020.11.01 21:08:39 3: sduino: Attr, setting Verbose to: 3

2020.11.01 21:08:39 3: Opening modul868 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CUZW-if00-port0

2020.11.01 21:08:39 1: modul868: Can't open /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A700CUZW-if00-port0: No such file or directory

2020.11.01 21:08:40 2: Switched modul868 rfmode to HomeMatic

2020.11.01 21:08:40 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:

2020.11.01 21:08:40 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...

2020.11.01 21:08:40 3: EQ3BT: EQ-3 Bluetooth Thermostat 2.0.5

2020.11.01 21:08:40 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_EQ3BT.pm line 226, <$fh> line 478.

2020.11.01 21:08:41 3: TelegramBot_Define Telegram: called

2020.11.01 21:08:41 3: Terassen_temp: I/O device is myJeeLink

2020.11.01 21:08:41 3: GHoma_Server: port 4196 opened

2020.11.01 21:08:41 3: DashButton: listening

2020.11.01 21:08:41 3: telnetPort: port 7072 opened

2020.11.01 21:08:41 3: XiaomiBTLESens (Blume1) - defined with BTMAC C4:7C:8D:6A:8C:5D

2020.11.01 21:08:41 3: XiaomiBTLESens (Blume2) - defined with BTMAC C4:7C:8D:6A:BD:6F

2020.11.01 21:08:42 1: MQTT21: Can't open server port at 1884: Cannot assign requested address. Exiting.

dbus[5936]: dbus[5938]: 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.

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

  D-Bus not built with -rdynamic so unable to print a backtrace

Aborted (core dumped)

2020.11.01 21:08:49 1: BlockingInformParent (BlockingStart): Can't connect to localhost:46707: IO::Socket::INET: connect: Connection refused

Aborted (core dumped)

2020.11.01 21:08:49 1: BlockingInformParent (BlockingStart): Can't connect to localhost:46707: IO::Socket::INET: connect: Connection refused

dbus[5951]: 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)

2020.11.01 21:08:50 1: BlockingInformParent (BlockingStart): Can't connect to localhost:46707: IO::Socket::INET: connect: Connection refused
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 09 November 2020, 18:18:36
Hast du mal die Expose-Blöcke komplett weggelassen?!
Wenn ich das richtig im Kopf habe, hat man "früher" die genutzten Ports per Expose an den Host übergeben. "Port" ist die Weiterentwicklung, da man hier eine genaue Definition zwischen internen und externen Ports vornehmen kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 09 November 2020, 18:51:22
Mal gecheckt was auf den Ports hängt?
Wurde glaub ich ein paar Posts zuvor schon diskutiert.

Andere Frage: was hast du mit den mysql-Instanzen vor? Wenn du nur von FHEM aus darauf zugreifen willst, reicht es aus, wenn die Container im gleichen Netzwerk sind. Ein weiterreichen an den Host ist nur notwendig wenn du von außen darauf zugreifen willst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 09 November 2020, 18:54:00
Ich glaube, Du solltest Dich in die Doku bezüglich der "port" Angabe einlesen ...

Aber ... was hällst Du davon, einen eigenen Thread aufzumachen? Hat nun wirklich nichts mehr mit FHEM Docker zu tuen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 09 November 2020, 19:03:05
Soory, ich dachte da gehört alles dazu, was für fhem gebraucht wird.

Okay, ich bin umgezogen und mache hier weiter https://forum.fhem.de/index.php/topic,115714.0.html (https://forum.fhem.de/index.php/topic,115714.0.html)

@balli1187, Deine Posts habe ich schon rüber kopiert. Wenn Du magst, kannst Du sie hier löschen.

Vielen Dank, auch diese Nachricht verschwindet noch
    Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 15 November 2020, 20:41:47
so, danke für di antworten! Werde noch Mals alles löschen und herausfinden warum der telnet nen fehler raushaut! Und wenn ich es nicht hinbekomme mach ich ein neuen threat auf!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 23 November 2020, 16:04:34
Hallo,
versuche gerade das TABLETUI ans laufen zu bekommen.
Scheinbar bekomme ich keine Verbindung zu fhem.
Hat vielleicht jemand einen Tipp für mich?

Gruß Holger
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 23 November 2020, 18:50:27
Zitat von: The-Holgi am 23 November 2020, 16:04:34
Hallo,
versuche gerade das TABLETUI ans laufen zu bekommen.
Scheinbar bekomme ich keine Verbindung zu fhem.
Hat vielleicht jemand einen Tipp für mich?

Du gibst kaum Informationen raus. Ich nutze zwar TUI aktuell nicht, aber ich hatte es im Docker schon mal laufen. Es gab kein Docker-spezifischen Dinge zu beachten. Bist du neu im Thema, oder hattest du es schon mal laufen? Ich zweifle dass es am Docker liegt.

Wie kommst du drauf dass "scheinbar keine Verbindung" besteht?

Siehst du in der Netzwerk-Console im Browser irgend welche "?cmd=set%20xxx%" wenn du was schaltest? Netzwerk Console im Chrome z. B. ... <F12> und da unter Network.

Hast du fhem TabletUi nach der Installation im Wiki durchgeführt, oder manuell was konfiguriert? Hast du einen deiner Schalter als Test konfiguriert?

Wenn du keine Docker-Fehlermeldungen oder Hinweise hast schlage ich vor, erstmal im TUI-Thread zu fragen. Kannst ja mit angeben, dass du es im Docker laufen hast.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: The-Holgi am 23 November 2020, 20:28:01
Hallo,
habe mich bei der Installation ans Wiki gehalten.
Dann die Beispieldatei umbenannt und einige Geräte mit den Namen aus meiner fhem Installation ,,ersetzt" bzw umbenannt.
Das UI läßt sich auch öffnen und ich kann ,,schalten". In fhem kommt aber nichts an und andersherum kommen auch keine Sensorwerte in der TabletUi an.
Ob es tatsächlich an Docker liegt weiß ich natürlich nicht, hatte es aber vor Jahren mal in meiner ,,normalen"
fhem Umgebung getestet, da funktionierte es.
Ansonsten bin ich im Thema TabletUI neu. Dachte ich kann mur da was nettes für mein Echo Show basteln.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 24 November 2020, 08:05:49
wie gesagt, frage erstmal im TabletUI Thread nach ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: WW am 25 November 2020, 14:02:15
Ich versuche seit 2 Tagen im FHEM-Docker-Image die Skripte post-init.sh, pre-init.sh, post-start.sh und pre-start.sh zu implementieren, scheitere jedoch an irgenwelchen Rechten.

Eingebunden habe ich das Verzeichnis ./fhem/config nach /docker:

    fhem:
        restart: always
        ports:
            - "8083:8083"
            - "8084:8084"
            - "8085:8085"
            - "7072:7072"
            - "7073:7073"
            - "8383:8383"   # ESP-Bridge
            - "5060:5060"   # SIP
            - "5070:5070"   # SIP
            - "8090:8090"   # AMAD
        image: fhem/fhem:latest
        volumes:
            - ./fhem/core/:/opt/fhem/
            - "./fhem/config:/docker"
        network_mode: host
#        networks:
#           - fhem-network
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
        depends_on:
            - "mysql"
            - "mqtt"
        command:
            - "-e CPAN_PKGS=\"Text::Iconv File::HomeDir\"" 


Auf dem OMV-Host sehen die Zugriffsrechte folgendermassen aus:

root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config# ls -l
insgesamt 2212
-rwxrwxrwx+ 1 willi users     699 Nov 25 12:18 post-init.sh
-rwxrwxrwx+ 1 willi users     330 Nov 24 21:39 post-start.sh
-rwxrwxrwx+ 1 willi users     443 Nov 24 21:39 pre-init.sh
-rwxrwxrwx+ 1 willi users     398 Nov 24 21:39 pre-start.sh
-rwxrwxrwx+ 1 willi users 2244696 Okt 29  2019 speedtest
root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config#


Und aus der Shell des Docker-Containers (über Portainer):

root@NAS-2:/docker# ls -l
total 2212
-rwxrwxrwx+ 1 fhem users     699 Nov 25 12:18 post-init.sh
-rwxrwxrwx+ 1 fhem users     330 Nov 24 21:39 post-start.sh
-rwxrwxrwx+ 1 fhem users     443 Nov 24 21:39 pre-init.sh
-rwxrwxrwx+ 1 fhem users     398 Nov 24 21:39 pre-start.sh
-rwxrwxrwx+ 1 fhem users 2244696 Okt 29  2019 speedtest
root@NAS-2:/docker# ./post-init.sh
bash: ./post-init.sh: Permission denied
root@NAS-2:/docker# /usr/bin/env bash ./post-init.sh
+++ post-init.sh (USER/ID: root/0) started +++
root@NAS-2:/docker#


Die Datei post-init.sh:

#!/usr/bin/env bash
#
# This script will be run at the very end of the initialization
# of the new container, also after your local FHEM configuration
# was checked and adjusted for compatibility with the container.
# Custom packages you defined using the environment variables
# mentioned above will be installed already at this point in time.
# This is likely the best place for you to do any final changes
# to the environment that need to be done only once for the
# lifetime of that container.
#
# Author: murdoc@storm-clan.de
#
# Configuration file: none
#
# Parameters: none
#
SCRIPTNAME=$(basename $0)
USERNAME=$(whoami)

echo "+++ $SCRIPTNAME (USER/ID: $USERNAME/$UID) started +++"

exit 0


Meine gesamte Konfiguration liegt auf einer Samba-Freigabe, damit ich auch unter Windows 10 daran arbeiten kann. Kann es sein, dass über die ACLs das Ausführen der Skripte unterbunden wird?


root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config# getfacl *.sh
# file: post-init.sh
# owner: willi
# group: users
user::rwx
user:willi:rwx
group::rwx
mask::rwx
other::rwx

# file: post-start.sh
# owner: willi
# group: users
user::rwx
user:willi:rwx
group::rwx
mask::rwx
other::rwx

# file: pre-init.sh
# owner: willi
# group: users
user::rwx
user:willi:rwx
group::rwx
mask::rwx
other::rwx

# file: pre-start.sh
# owner: willi
# group: users
user::rwx
user:willi:rwx
group::rwx
mask::rwx
other::rwx

root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config#
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 November 2020, 18:11:04
@ww, rechte zeigen rwx und + für acl, wobei da acl auch rwx ist.

kannst du das script am host ausführen? da sind die selben rechte ...

wenn du den mountpoint mal aushängst du die datei lokal setzt, selbes problem?

auch wenn es sich blöd anhört, mal neu gestartet? nas + docker host ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 November 2020, 18:53:33
Was steht z.B. in den ersten Zeilen von post_init.sh

Eigentlich sieht die Fehlermeldung, wenn nicht Ausführbar, anders aus ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 November 2020, 19:05:35
Zitat von: Wernieman am 25 November 2020, 18:53:33
Was steht z.B. in den ersten Zeilen von post_init.sh

Eigentlich sieht die Fehlermeldung, wenn nicht Ausführbar, anders aus ....

Test mit chmod 666 (nicht ausführbar)


root@fhemlxc:/docker/docker_files/fhemscripts# ls -l
insgesamt 4
-rw-rw-rw- 1 root root 461 25. Nov 17:59 pre-start.sh
root@fhemlxc:/docker/docker_files/fhemscripts# ./pre-start.sh
bash: ./pre-start.sh: Keine Berechtigung


Das ist, zwar auf Deutsch, die Meldung. Oder welche Meldung meinst du?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 November 2020, 19:12:52
bitte den INHALT des Scriptes ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 November 2020, 19:15:20
hat er oben gepostet
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: WW am 25 November 2020, 20:15:03
Erst einmal Danke für die Reaktionen.

Wenn ich über die Shell des Containers(Portainer) den Skript nach /usr/local/bin kopiere, dann funktioniert der Skript:

root@NAS-2:/opt/fhem# cd /docker
root@NAS-2:/docker# ./post-start.sh
bash: ./post-start.sh: Permission denied
root@NAS-2:/docker# cp post-start.sh /usr/local/bin
root@NAS-2:/docker# /usr/local/bin/post-start.sh
+++ post-start.sh (USER/ID: root/0) started +++
root@NAS-2:/docker#

root@NAS-2:/docker# ls -l /usr/local/bin/post-start.sh
-rwxr-xr-x 1 root root 330 Nov 25 19:45 /usr/local/bin/post-start.sh


Auch nach Umsetzen des Users funktioniert es noch:

root@NAS-2:/docker# ls -l /usr/local/bin/post-start.sh
-rwxr-xr-x 1 root root 330 Nov 25 19:45 /usr/local/bin/post-start.sh
root@NAS-2:/docker# chown fhem:users /usr/local/bin/post-start.sh
root@NAS-2:/docker# ls -l /usr/local/bin/post-start.sh
-rwxr-xr-x 1 fhem users 330 Nov 25 19:45 /usr/local/bin/post-start.sh
root@NAS-2:/docker# /usr/local/bin/post-start.sh
+++ post-start.sh (USER/ID: root/0) started +++
root@NAS-2:/docker#


Auf dem Host direkt sieht es so aus:

root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config# ./post-init.sh
bash: ./post-init.sh: Keine Berechtigung
root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config# cp post-init.sh /usr/local/bin/post-init.sh
root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config# ls -l /usr/local/bin/post-init.sh
-rwxrwxrwx+ 1 willi users 699 Nov 25 12:18 /usr/local/bin/post-init.sh
root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config#  /usr/local/bin/post-init.sh
+++ post-init.sh (USER/ID: root/0) started +++
root@NAS-2:/sharedfolders/DatenA3/Ahornstr/fhem/config#

Das Verhalten entspricht dem aus dem Container: Liegt die Datei post-init.sh auf der SMB-Freigabe, dann funktioniert es nicht, obwohl die Rechte eigentlich stimmen.

@kadettilac89: NAS wurde neu gestartet

Eine Zusatzinfo: Auf dem Server läuft Docker unter Openmediavault.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 November 2020, 20:34:36
ww, ich habe selber mal dein script auf einen sambashare bei mir angelegt. bei mir geht es auch mit samba

Ist der Host auf dem Docker läuft gleichzeitig dein NAS? Ich lese es zumindest so. Wenn dem so ist, warum schreibst du nicht direkt in das lokale Daten-Verzeichnis? Samba selbst gibt ja auch ein lokales Verzeichnis frei. Der Sambashare zeigt dann auf den selben Server, oder sind es 2 verschiedene NAS?

Du könntest auf dem NAS auch für Linux per NFS freigeben und mounten. Und auf das selbe Verzeichnis eine Samba-Freigabe für Windows. Zumindest als Test. Sauber sieht anders aus, aber zumindest als Workaround.

Da der Fehler auch außerhalb vom Container existiert ist dieser Thread hier der falsche. Es ist zumindest eingeschränkt auf den Samba-Share. Du bist wahrscheinlich in einem reinen Linux-Forum besser aufgehoben bzw. zu Openmediavault.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: WW am 25 November 2020, 20:52:54
Ich glaube, ich bin etwas weiter: Es scheint daran zu liegen, wie OMV externe Festplatten einbindet:

root@NAS-2:/etc# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=498802ee-a400-4912-8060-dbe200dfa748 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=e3f86d6f-6204-4eb8-bfc1-992c0ab58e30 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
tmpfs           /tmp            tmpfs   defaults        0       0
# >>> [openmediavault]
/dev/disk/by-id/ata-TS128GSSD340K_0203223EE19183140046-part3 /srv/dev-disk-by-id-ata-TS128GSSD340K_0203223EE19183140046-part3 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,discard,acl 0 2
/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N1ZFN0EK-part1 /srv/dev-disk-by-id-ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N1ZFN0EK-part1 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N5JRZXHU-part1 /srv/dev-disk-by-id-ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N5JRZXHU-part1 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
# <<< [openmediavault]
root@NAS-2:/etc#


Unter OMV werden alle Festplatten mit der Option "noexec" eingebunden. Ist also kein Samba-Problem, sondern ein OMV-Problem.
Ich werde morgen nach einer Lösung/Workaround schauen und dann berichten. Danke für Eure Anmerkungen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 26 November 2020, 08:40:03
Ahhhh .... das ist ein Sicherheitsfeature .. kannst DU doch einfach aus der fstab rausnehmen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 November 2020, 10:02:52
Zitat von: Wernieman am 26 November 2020, 08:40:03
.. kannst DU doch einfach aus der fstab rausnehmen ...

nicht empfohlen, wird bei upgrades, ggf. schon bei reboot überschrieben.

es gibt dafür eigene config files
https://openmediavault.readthedocs.io/en/5.x/various/fs_env_vars.html
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 26 November 2020, 13:17:51
O.K. .. das ist dann eine OMV Spezialität ;o)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 26 November 2020, 14:28:08
Zitat von: kadettilac89 am 25 November 2020, 19:05:35
Test mit chmod 666 (nicht ausführbar)


root@fhemlxc:/docker/docker_files/fhemscripts# ls -l
insgesamt 4
-rw-rw-rw- 1 root root 461 25. Nov 17:59 pre-start.sh
root@fhemlxc:/docker/docker_files/fhemscripts# ./pre-start.sh
bash: ./pre-start.sh: Keine Berechtigung


Das ist, zwar auf Deutsch, die Meldung. Oder welche Meldung meinst du?

Unter Unix sind die Rechte zur Ausführung mit "x" gekennzeichnet. Die fehlen beim Skript. Also keine Berechtigung, das Skript auszuführen. auf Shell Ebene würde ein chmod +x pre-start.sh helfen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 November 2020, 14:44:00
Zitat von: WW am 25 November 2020, 14:02:15

Und aus der Shell des Docker-Containers (über Portainer):

.....
-rwxrwxrwx+ 1 fhem users     443 Nov 24 21:39 pre-init.sh
.....
root@NAS-2:/docker# ./post-init.sh
bash: ./post-init.sh: Permission denied                       <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
.....


[/code]


Zitat von: Wernieman am 25 November 2020, 18:53:33
Was steht z.B. in den ersten Zeilen von post_init.sh

Eigentlich sieht die Fehlermeldung, wenn nicht Ausführbar, anders aus ....

Zitat von: kadettilac89 am 25 November 2020, 19:05:35
Test mit chmod 666 (nicht ausführbar)


root@fhemlxc:/docker/docker_files/fhemscripts# ls -l
insgesamt 4
-rw-rw-rw- 1 root root 461 25. Nov 17:59 pre-start.sh
root@fhemlxc:/docker/docker_files/fhemscripts# ./pre-start.sh
bash: ./pre-start.sh: Keine Berechtigung                          <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Das ist, zwar auf Deutsch, die Meldung. Oder welche Meldung meinst du?

Zitat von: guhu am 26 November 2020, 14:28:08
Unter Unix sind die Rechte zur Ausführung mit "x" gekennzeichnet. Die fehlen beim Skript. Also keine Berechtigung, das Skript auszuführen. auf Shell Ebene würde ein chmod +x pre-start.sh helfen.

es war ja auch Sinn und Zweck des Tests die Fehlermeldung zu erzeugen. Es sollte zeigen, dass die Meldung "bash: ./pre-start.sh: Keine Berechtigung" auf fehlende Berechtigung hinweist.

Ursache des Problems ... von ww ... wurde in der Zwischenzeit schon gefunden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: WW am 27 November 2020, 10:41:33
Zitat von: kadettilac89 am 26 November 2020, 10:02:52
nicht empfohlen, wird bei upgrades, ggf. schon bei reboot überschrieben.

es gibt dafür eigene config files
https://openmediavault.readthedocs.io/en/5.x/various/fs_env_vars.html

Damit habe ich mein Problem lösen können. Das manuelle Ändern der fstab wurde (wie von kadettilac89 angedeutet) beim Neustart von OMV überschrieben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 November 2020, 11:14:40
aber jetzt wieder back to topic, aktuell etwas OT ... Offizielles FHEM Docker Basis Image für verschiedene Plattformen

Hallo IT-Helpdesk, ich habe immer Kopfschmerzen wenn ich hackevoll mit dem Kopf auf die Tastatur aufschlage
- OK, und wieso rufen sie den IT-Helpdesk? -
Na hören sie, sie kümmern sich um PCs und die Tastatur ist ja schließlich an den PC angeschlossen!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 01 Dezember 2020, 12:48:28
Hallo zusammen,

ich verwende das FHEM Docker Image und habe dies am 11.11 aktualisiert, das war wohl ein schlechtes datum :-) Hellau.

Ich weiß natürlich nicht seit wann, aber beim sauber machen habe ich im log folgendes gefunden

2020.12.01 12:43:06.107 1: PERL WARNING: Subroutine websocket_Initialize redefined at ./FHEM/00_websocket.pm line 43.
2020.12.01 12:43:06.109 1: reload: Error:Modul 00_websocket deactivated:
Can't locate Protocol/WebSocket/Handshake/Server.pm in @INC (you may need to install the Protocol::WebSocket::Handshake::Server module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/00_websocket.pm line 63.
BEGIN failed--compilation aborted at ./FHEM/00_websocket.pm line 63.
2020.12.01 12:43:06.109 0: Can't locate Protocol/WebSocket/Handshake/Server.pm in @INC (you may need to install the Protocol::WebSocket::Handshake::Server module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at ./FHEM/00_websocket.pm line 63.
BEGIN failed--compilation aborted at ./FHEM/00_websocket.pm line 63.


Ist das "Protocol::WebSocket::Handshake::Server module" nicht im Image?
Und an welcher stelle soll ich das ins .yml File eintragen?


  fhem:
    image: fhem/fhem:latest
    restart: always
    network_mode: host
    privileged: true
#    devices:
#      - "/dev/ttyACM0:/dev/ttyACM0"                                   <<< da hängt ein Device dran, dass in einem anderen Container verwendet wird
    volumes:
      - "./core/:/opt/fhem/"
#      - "./core/contrib/configDB/configDB.conf:/opt/fhem/configDB.conf"
    environment:
      PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"
      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare"
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
#      CONFIGTYPE: configDB
    depends_on:
      - "mysql"


Gruß
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 Dezember 2020, 14:43:39
Zitat von: ch.eick am 01 Dezember 2020, 12:48:28

Ist das "Protocol::WebSocket::Handshake::Server module" nicht im Image?
Und an welcher stelle soll ich das ins .yml File eintragen?


  fhem:
    image: fhem/fhem:latest
    restart: always
    network_mode: host
    privileged: true
#    devices:
#      - "/dev/ttyACM0:/dev/ttyACM0"                                   <<< da hängt ein Device dran, dass in einem anderen Container verwendet wird
    volumes:
      - "./core/:/opt/fhem/"
#      - "./core/contrib/configDB/configDB.conf:/opt/fhem/configDB.conf"
    environment:
      PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"
      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare"
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
#      CONFIGTYPE: configDB
    depends_on:
      - "mysql"




Hi, im Dockerfile sehe ich das Handshake-Modul nicht, nur "Net::WebSocket::Server" ... hört sich ähnlich an, aber ist halt nicht was du benötigst.

In deinem compose-file hast du schon den parameter .. hänge es da mit an (mit Leerzeichen getrennt) und erzeuge dann den Container neu. (Docker-Compose up .... )

      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare Protocol::WebSocket::Handshake::Server module"

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 01 Dezember 2020, 14:58:23
Zitat von: kadettilac89 am 01 Dezember 2020, 14:43:39
Hi, im Dockerfile sehe ich das Handshake-Modul nicht, nur "Net::WebSocket::Server" ... hört sich ähnlich an, aber ist halt nicht was du benötigst.

In deinem compose-file hast du schon den parameter .. hänge es da mit an (mit Leerzeichen getrennt) und erzeuge dann den Container neu. (Docker-Compose up .... )

      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare Protocol::WebSocket::Handshake::Server module"
Okay, das mach ich dann mal.
EDIT: Und schon sind die Fehler weg :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 Dezember 2020, 15:07:24
hab grad gesehen, du hattest in den Anführungszeichen noch das Wort modul drin, das gehört natürlich nicht in den Parameter. Das unten sollte aber passen

CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare Protocol::WebSocket::Handshake::Server"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 01 Dezember 2020, 15:08:30
Nächste Meldung:

8. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
/entry.sh: line 328: [[: /dev/gpiomem
/dev/gpiochip1
/dev/gpiochip0: syntax error: operand expected (error token is "/dev/gpiomem
/dev/gpiochip1
/dev/gpiochip0")

Da kann ich aber nichts dafür ;-) Es ist ein RPI4 , aber am GPIO ist bisher nichts angeschlossen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 01 Dezember 2020, 15:15:51
Und das hier scheint so auch okay zu sein???

2020.12.01 15:14:07.694 1: Including fhem.cfg
2020.12.01 15:14:07.724 1: PERL WARNING: Subroutine MyUtils_Initialize redefined at ./FHEM/99_myUtils.pm line 10, <$fh> line 12.
2020.12.01 15:14:07.726 1: PERL WARNING: Subroutine KalenderDatum redefined at ./FHEM/99_myUtils.pm line 27, <$fh> line 12.
2020.12.01 15:14:07.727 1: PERL WARNING: Subroutine datumHeuteMorgen redefined at ./FHEM/99_myUtils.pm line 47, <$fh> line 12.
2020.12.01 15:14:07.728 1: PERL WARNING: Subroutine getCalendar redefined at ./FHEM/99_myUtils.pm line 65, <$fh> line 12.
...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 02 Dezember 2020, 11:02:16
die gpio meldung kenn ich nicht, kannst vermutlich ignorieren wenn sowieso nichts angeschlossen ist. die deiner myUtils hat nichts mit Docker zu tun. Das sind deine eigenen Routinen. Sind aber nur Warnungen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: dancatt am 21 Dezember 2020, 13:26:12
Hallo zusammen,

aktuell versuche ich auch auf Docker umzustellen. Soweit klappt auch vieles schon. Danke an dieser Stelle für die tolle Arbeit am Docker-Image.

Folgende Fehlermeldung habe ich im Log:
2020.12.21 13:05:30.974 2: DbLog dbLog -> Error table history - DBD::SQLite::st execute_array failed: database disk image is malformed [err was 11 now 2000000000]
executing 1460 generated 1460 errors at ./FHEM/93_DbLog.pm line 2652.


Hatte das schon jemand?

Vielen Dank.

MfG
Daniel
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 21 Dezember 2020, 13:32:31
Zitat von: dancatt am 21 Dezember 2020, 13:26:12
Folgende Fehlermeldung habe ich im Log:
2020.12.21 13:05:30.974 2: DbLog dbLog -> Error table history - DBD::SQLite::st execute_array failed: database disk image is malformed [err was 11 now 2000000000]
executing 1460 generated 1460 errors at ./FHEM/93_DbLog.pm line 2652.

Da scheint Deine Datenbank ein fehlerhaftes Image zu haben.

Edit: Sorry, das war missverständlich, ich meinte das Datenbank File.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 Dezember 2020, 13:39:06
Ich würde erstmal auf defekte Tabelle Tippen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: dancatt am 21 Dezember 2020, 13:46:10
Zitat von: ch.eick am 21 Dezember 2020, 13:32:31
Da scheint Deine Datenbank ein fehlerhaftes Image zu haben.
Damit kann ich leider nichts anfangen  :(

Die docker-compose.yml sieht aktuell folgendermaßen aus:

version: '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
    restart: always
    networks:
      - net
    ports:
      - "8083:8083"
    volumes:
      - "./fhem/:/opt/fhem/"
    environment:
      CPAN_PKGS: "Date::Manip Protocol::WebSocket::Handshake::Server"
      FHEM_UID: 999
      FHEM_GID: 20
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
      CONFIGTYPE: configDB

Unter dem volume "./fhem/" ist mein fhem mit configDB.db und fhem.db. Der Komplette Ordner fhem kommt ursprünglich aus einem Backup meines Produktivsystems.


Zitat von: Wernieman am 21 Dezember 2020, 13:39:06
Ich würde erstmal auf defekte Tabelle Tippen
die Tabelle ist aus meinem Prodsystem 1 zu 1 kopiert worden und läuft dort ohne Probleme.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 Dezember 2020, 13:49:27
Dann teste sie bitte jetzt. Hast Du ein Dump/Restore gefahren oder einfach nur die Dateien kopiert?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 Dezember 2020, 14:05:44
Zitat von: dancatt am 21 Dezember 2020, 13:26:12
Folgende Fehlermeldung habe ich im Log:
Was sagt der Config Check in dem zugehörigen DBLog-Device?

Mögliche Ursachen ...
- DB-File nicht vorhanden bzw. Pfad nicht auffindbar
- DB-File Rechte reichen nicht aus, um DAtei zu lesen / ändern
- DB-File an sich korrupt

Fehlermeldung hat mehr mit DBLog zu tun als mit Docker. DS_Starter (Maintainer) reagiert sehr schnell auf Posts im richtigen Forum. Würde einen Thread im DBLog-Fourm starten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: dancatt am 21 Dezember 2020, 14:06:54
Zitat von: Wernieman am 21 Dezember 2020, 13:49:27
Dann teste sie bitte jetzt. Hast Du ein Dump/Restore gefahren oder einfach nur die Dateien kopiert?

Nur die Dateien kopiert. Sollte ja bei einer SQLite DB möglich sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: dancatt am 21 Dezember 2020, 14:07:49
Zitat von: kadettilac89 am 21 Dezember 2020, 14:05:44
Was sagt der Config Check in dem zugehörigen DBLog-Device?

Mögliche Ursachen ...
- DB-File nicht vorhanden bzw. Pfad nicht auffindbar
- DB-File Rechte reichen nicht aus, um DAtei zu lesen / ändern
- DB-File an sich korrupt

Fehlermeldung hat mehr mit DBLog zu tun als mit Docker. DS_Starter (Maintainer) reagiert sehr schnell auf Posts im richtigen Forum. Würde einen Thread im DBLog-Fourm starten.

Vielen Dank. Werde ich nochmal prüfen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 26 Dezember 2020, 21:21:18
Hallo!
Ich versuche schon seit einiger zeit ehem vom raspi auf einen intelnuc mit docker umzustellen, aber der container bleibt einfach in unhealty hängen und ich habe keine Ahnung warum! Kann es sein das es was damit zutunhat das die usb devices nicht angeschlossen sind?

Ich bin nach Anleitung von git mit eigenem fhem.cfg vorgegangen! es kommt im log von docker immer ein error telnet 7072. Hatte eigentlich nur portainer am laufen am nuc.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 Dezember 2020, 21:53:27
Zitat von: Kawaci am 26 Dezember 2020, 21:21:18
Hallo!
Ich versuche schon seit einiger zeit ehem vom raspi auf einen intelnuc mit docker umzustellen, aber der container bleibt einfach in unhealty hängen und ich habe keine Ahnung warum! Kann es sein das es was damit zutunhat das die usb devices nicht angeschlossen sind?

Ich bin nach Anleitung von git mit eigenem fhem.cfg vorgegangen! es kommt im log von docker immer ein error telnet 7072. Hatte eigentlich nur portainer am laufen am nuc.
ich habe fhem mit docker-compose am laufen. Wenn die Devices nicht vorhanden sind dann läuft der Container auf Fehler ... vermutlich hast du selbes Problem, entweder Devices anschließen, oder erstmal aus der Docker-Config raus.

Telnet ... wie sieht deine Config in Fhem und in Portainer aus? Hast du 7072 durchgereicht? Läuft noch was anderes auf 7072?

Hast du so oder ähnlichen Eintrag in Fhem.cfg?

defmod telnetPort telnet 7072 global
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 26 Dezember 2020, 22:04:19
Ok danke!
ich habe den container mit
docker run -d --name fhem -p 8083:8083 -v /home/martin/docker/:/opt/fhem fhem/fhem
erstellt und das "opt/fhem" Verzeichnis vom raspi in "/home/martin/docker/" kopiert

Mein telnet in fhem sieht so aus
defmod telnetPort telnet 7072 global
attr telnetPort DbLogExclude .*
attr telnetPort alias telnetPort
attr telnetPort room System
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 Dezember 2020, 11:14:11
In Github steht viel zu telnet ... durchlesen.

Teste mal ...
- Port von Container nach Host durchreichen (7072:7072)
- Hast du irgend welche allow-Config für telnet die die Benutzung einschränken ... löschen oder anpassen
- Telnet config rausnehmen und Container neu erstellen lassen. ... "Unless you are using configDB, the container will try to automatically detect and adjust your telnet configuration for it to work"

wenn das nichts hilft, poste mal die genaue Fehlermeldung
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 27 Dezember 2020, 21:28:31
so danke für die Hilfe! Habe alle vorschlage versucht und im git hab ich sowieso schon über telnet gelesen aber es hat nichts funktioniert!

hier der Fehler!

2020.12.27 21:20:40 1: MQTT21: Can't open server port at 1884: Cannot assign requested address. Exiting.

dbus[5994]: dbus[5996]: 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.

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

  D-Bus not built with -rdynamic so unable to print a backtrace

Aborted (core dumped)

2020.12.27 21:20:48 1: BlockingInformParent (BlockingStart): Can't connect to localhost:42899: IO::Socket::INET: connect: Connection refused

Aborted (core dumped)

2020.12.27 21:20:48 1: BlockingInformParent (BlockingStart): Can't connect to localhost:42899: IO::Socket::INET: connect: Connection refused

dbus[6009]: 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)

2020.12.27 21:20:48 1: BlockingInformParent (BlockingStart): Can't connect to localhost:42899: IO::Socket::INET: connect: Connection refused

     


bis zur Zeile wo der mqtt2 server abgerufen wird läuft alles durch, was kann ich da machen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 Dezember 2020, 23:17:41
Zitat von: Kawaci am 26 Dezember 2020, 21:21:18
Ich bin nach Anleitung von git mit eigenem fhem.cfg vorgegangen! es kommt im log von docker immer ein error telnet 7072. Hatte eigentlich nur portainer am laufen am nuc.

Zitat von: Kawaci am 27 Dezember 2020, 21:28:31
so danke für die Hilfe! Habe alle vorschlage versucht und im git hab ich sowieso schon über telnet gelesen aber es hat nichts funktioniert!

hier der Fehler!

2020.12.27 21:20:40 1: MQTT21: Can't open server port at 1884: Cannot assign requested address. Exiting.

dbus[5994]: dbus[5996]: 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.

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

  D-Bus not built with -rdynamic so unable to print a backtrace

Aborted (core dumped)

2020.12.27 21:20:48 1: BlockingInformParent (BlockingStart): Can't connect to localhost:42899: IO::Socket::INET: connect: Connection refused

Aborted (core dumped)

2020.12.27 21:20:48 1: BlockingInformParent (BlockingStart): Can't connect to localhost:42899: IO::Socket::INET: connect: Connection refused

dbus[6009]: 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)

2020.12.27 21:20:48 1: BlockingInformParent (BlockingStart): Can't connect to localhost:42899: IO::Socket::INET: connect: Connection refused

     


bis zur Zeile wo der mqtt2 server abgerufen wird läuft alles durch, was kann ich da machen?

Jetzt mal ne dumme Frage, du schreibst, dass du Probleme mit Telnet hast, in dem Log taucht das Wort "telnet" kein einziges mal auf. Was läuft auf Port 1884, wohin soll die Verbindung gehen, musst du evtl. Port 1884 öffnen, im Container, oder woanders?

dbus taucht im Log auf. Starte mal ohne die ganze dbus-Config. Wenn das funktioniert hast du das Problem schon mal eingegrenzt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Kawaci am 27 Dezember 2020, 23:26:03
Es läuft jetzt mal! Hab in der mqtt2_server die ip des servers auf 127.0.0.1 gestellt und die dbconfig rausgenommen in der fhem.cfg dann musste ich noch das attr ssl von global raus nehmen und jetzt funktioniert es! ich versuche als nächstes die matt gerate auf die neue ip ändern! was noch kommt weis ich noch nicht! mal sehen! Danke für eure Hilfe!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: buliwyf am 08 Januar 2021, 19:59:39
Auch wenn das Risiko besteht, dass die Frage schon beantwortet wurde: 73 Seiten sind nicht wenig:

Was ist aktuell mit den Docker images los? sowohl :latest als auch :dev sind beide bereits 5 Monate alt.

Aktuell wird mir im FHEM die Version 21240 angezeigt.
Die aktuell Version im SVN ist die 23489.

Hat das einen Grund?

Danke für eure Antworten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 08 Januar 2021, 20:13:15
Zitat von: buliwyf am 08 Januar 2021, 19:59:39
Aktuell wird mir im FHEM die Version 21240 angezeigt.
Die aktuell Version im SVN ist die 23489.
Am Image muss sich ja nichts geändert haben, wenn es im FHEM eine aktuellere Version gibt.
Das Docker Image soll doch nur die Basis sein.

Ein Update von FHEM und aus vom Debian sollte man dann doch noch häufiger mache.
Im Menü unter System/Update wird es schön angezeigt und kann auch dort aktualisiert werden.

VG
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: buliwyf am 08 Januar 2021, 20:28:00
Zitat von: ch.eick am 08 Januar 2021, 20:13:15
Am Image muss sich ja nichts geändert haben, wenn es im FHEM eine aktuellere Version gibt.
Das Docker Image soll doch nur die Basis sein.

Ein Update von FHEM und aus vom Debian sollte man dann doch noch häufiger mache.
Im Menü unter System/Update wird es schön angezeigt und kann auch dort aktualisiert werden.

VG
   Christian

Danke für den Hinweis. Irgendwie saß ich auf der Leitung.   ::)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 08 Januar 2021, 22:30:38
Zitat von: buliwyf am 08 Januar 2021, 20:28:00
Danke für den Hinweis. Irgendwie saß ich auf der Leitung.   ::)
Der Schöpfer des Images kann sich natürlich auch noch was anderes gedacht haben. Ich bin nur Endanwender ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 09 Januar 2021, 14:24:11
Die Systematik von FHEM lässt ja nicht zu, daa man das FHEM-Update über Docker macht. Das Image läuft top, also warum ändern?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 11 Januar 2021, 07:18:43
Wieso?
Natürlich kann man ein update von fhem machen und das bleibt auch erhalten nachdem ich ja annehme das ein Ordner mit fhem eingebunden ist. Was anderes ergibt wenig Sinn...
gruß Anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 11 Januar 2021, 11:41:31
Das meine ich nicht. Ich meine ein Update von fhem durch Aktualisierung des Docker-Containers. Sollte klar sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 11 Januar 2021, 11:58:09
Nur wurde der Docker-Container anders gebaut. Es ist ein "Big-Container", d.h. stellt alles dar, as FHEM zu laufen braucht. Entsprechend erfolgt das Update von FHEM durch FHEM und nicht dem Container. Sonst müsste es täglich einen neuen Container geben.

Kann man darüber diskutieren, wurde aber vom Ersteller des Containers so gemacht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Init am 19 Januar 2021, 15:43:49
Hallo zusammen,

ich möchte gerne beim Bau des Containers zusätzliche Debian APT packages installieren.

Hierzu habe ich in der docker-compose.yml folgendes hinzugefügt:

APT_PKGS: "libunixsocket-java dbus libnet-dbus-perl shared-mime-info haveged default-jre"

Leider bekomme ich in der /pkgs.apt folgende Fehler angezeigt:
Err:1 https://deb.nodesource.com/node_10.x buster InRelease
  Temporary failure resolving 'deb.nodesource.com'
Err:2 https://cdn-aws.deb.debian.org/debian buster InRelease
  Temporary failure resolving 'cdn-aws.deb.debian.org'
Get:3 https://cdn-aws.deb.debian.org/debian-security buster/updates InRelease [65,4 kB]
Get:4 https://cdn-aws.deb.debian.org/debian buster-updates InRelease [51,9 kB]
Get:5 https://cdn-aws.deb.debian.org/debian-security buster/updates/non-free amd64 Packages [556 B]
Get:6 https://cdn-aws.deb.debian.org/debian-security buster/updates/main amd64 Packages [268 kB]
Get:7 https://cdn-aws.deb.debian.org/debian buster-updates/main amd64 Packages [7.860 B]
Get:8 https://cdn-aws.deb.debian.org/debian buster-updates/non-free amd64 Packages [604 B]
Fetched 394 kB in 29s (13,5 kB/s)
Reading package lists...
W: Failed to fetch https://cdn-aws.deb.debian.org/debian/dists/buster/InRelease  Temporary failure resolving 'cdn-aws.deb.debian.org'
W: Failed to fetch https://deb.nodesource.com/node_10.x/dists/buster/InRelease  Temporary failure resolving 'deb.nodesource.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
Package default-jre is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

Package haveged is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Unable to locate package libunixsocket-java
E: Unable to locate package libnet-dbus-perl
E: Package 'haveged' has no installation candidate
E: Package 'default-jre' has no installation candidate


Kann mir jemand einen Tipp geben, was ich falsch mache?

Vorab vielen Dank
Grüße
Marc
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 19 Januar 2021, 17:33:58
Zitat von: Init am 19 Januar 2021, 15:43:49

Kann mir jemand einen Tipp geben, was ich falsch mache?

Vorab vielen Dank
Grüße
Marc

Sieht nach DNS-Problem aus. Kannst du auf dem Host auf dem du Docker laufen lässt die angemeckerten Hosts anpingen. Z. B.

ping cdn-aws.deb.debian.org
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Init am 19 Januar 2021, 17:46:53
Zitat von: kadettilac89 am 19 Januar 2021, 17:33:58
Sieht nach DNS-Problem aus. Kannst du auf dem Host auf dem du Docker laufen lässt die angemeckerten Hosts anpingen. Z. B.

ping cdn-aws.deb.debian.org

Funktioniert:
ping cdn-aws.deb.debian.org
PING dpvctowv9b08b.cloudfront.net (13.226.159.65): 56 data bytes
64 bytes from 13.226.159.65: icmp_seq=0 ttl=241 time=18,591 ms
64 bytes from 13.226.159.65: icmp_seq=1 ttl=241 time=44,461 ms
64 bytes from 13.226.159.65: icmp_seq=2 ttl=241 time=18,375 ms
64 bytes from 13.226.159.65: icmp_seq=3 ttl=241 time=17,841 ms
64 bytes from 13.226.159.65: icmp_seq=4 ttl=241 time=17,794 ms
^C--- dpvctowv9b08b.cloudfront.net ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 17,794/23,412/44,461/10,529 ms


Nachdem der Container erstellt ist, funktioniert auch das "apt-get update" ohne Fehler.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: joshi am 24 Januar 2021, 00:16:22
Bei mir lässt sich tzdata nicht aktualisieren. Hat jemand eine Idee?

dpkg: error processing archive /var/cache/apt/archives/tzdata_2020e-0+deb10u1_all.deb (--unpack):
unable to make backup link of './usr/share/zoneinfo/Europe/Berlin' before installing new version: Invalid cross-device link
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 24 Januar 2021, 12:38:41
Zitat von: joshi am 24 Januar 2021, 00:16:22
Bei mir lässt sich tzdata nicht aktualisieren. Hat jemand eine Idee?

dpkg: error processing archive /var/cache/apt/archives/tzdata_2020e-0+deb10u1_all.deb (--unpack):
unable to make backup link of './usr/share/zoneinfo/Europe/Berlin' before installing new version: Invalid cross-device link

was genau machst du, wo kommt die meldung? Erstellst du dir einen eigenen container abgeleitet vom offiziellen? warum installierst du tzdata separat?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: joshi am 24 Januar 2021, 13:30:36
Zitat von: kadettilac89 am 24 Januar 2021, 12:38:41
was genau machst du, wo kommt die meldung? Erstellst du dir einen eigenen container abgeleitet vom offiziellen? warum installierst du tzdata separat?

Ich nehme den offiziellen und versuche diesen per AptToDate (bzw. per apt-get aus dem Container heraus) zu upgraden. Tzdata ist schon im original Container enthalten und es gibt nur Update.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 24 Januar 2021, 13:48:24
funktioniert ohne Probleme.

Du hast einen externen link gemacht?  './usr/share/zoneinfo/Europe/Berlin'
Der blockiert - so verstehe ich die Meldung?

Ich habe es einfach nur mit environment gemacht:
    environment:
      - TZ=Europe/Berlin
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: joshi am 24 Januar 2021, 20:55:48
Wenn ich NICHT das OMV (edit: typo korrigiert) docker-gui benutze funktioniert es ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 24 Januar 2021, 22:40:30
Zitat von: joshi am 24 Januar 2021, 13:30:36
Ich nehme den offiziellen und versuche diesen per AptToDate (bzw. per apt-get aus dem Container heraus) zu upgraden. Tzdata ist schon im original Container enthalten und es gibt nur Update.

Du kannst doch alles aus FHEM upgraden? Siehe Raum System. Klappt bei mir auch einwandfrei.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 24 Januar 2021, 23:17:55
ZitatOVM docker-gui
Vielleicht blöde Frage: aber was ist das? Ich kenne OpenMediaVault - ist das gemeint?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: joshi am 24 Januar 2021, 23:21:00
Zitat von: Otto123 am 24 Januar 2021, 23:17:55
Vielleicht blöde Frage: aber was ist das? Ich kenne OpenMediaVault - ist das gemeint?
ja, das war ein Tippfehler
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 03 März 2021, 08:18:54
Keine Ahnung ob mir hier direkt im Forum geholfen werden kann, denke es ist eigentlich eher ein Problem des NAS.
Seit gestern Abend habe ich Probleme mit meinem Fhem-Server, der als Image auf einem Container innerhalb einer QNAP-NAS läuft.

Als ich heute Morgen nach den Problemen schauen wollte, habe ich festgestellt, dass die Container-Station auf dem NAS, überhaupt nichts mehr beinhaltet.
Weder die runtergeladenen Images noch die erstellten Container werden angezeigt. Allerdings wird wohl eine genutzte CPU- und Speicherleistung angezeigt.

Hat vielleicht jemand eine Idee was ich tun kann oder schon mal ähnliches erlebt.

Backups meines Fhem sind erstellt worden, doch ohne Container bringt das ja nicht sehr viel.
Habe vorgestern auf dem NAS auch ein Update der Firmware eingespielt, doch nach dem Update lief noch alles, weshalb ich dies als Fehlerquelle eigentlich ausschließe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 03 März 2021, 08:35:36
Weißst Du, was als Basis für den Containerdienst der QNAP läuft? Docker oder ein anderer Container-Dienst?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 März 2021, 08:43:36
Zitat von: Superposchi am 03 März 2021, 08:18:54
Hat vielleicht jemand eine Idee was ich tun kann oder schon mal ähnliches erlebt.


Container neu anlegen mit Konfiguration von vorher und auch den Pfad der persistenten Daten beibehalten. Dann werden die vorhandenen Daten wieder verwendet. Zumindest wenn die Docker-Implementierung sauber ist. Mit Docker-Compose kann ich Container löschen und neu anlegen wie ich will. Solange die persistenten Verzeichnisse bleiben sind auch Daten weiterhin da.

Wenn das, aus welchen Gründen auch immer, nicht geht den Container neu anlegen. Fhem stoppen. Die alten, persistenten Daten in den neuen Pfad der neuen persistenten Daten kopieren, ggf. Rechte anpassen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 03 März 2021, 09:14:29
Zitat von: Wernieman am 03 März 2021, 08:35:36
Weißst Du, was als Basis für den Containerdienst der QNAP läuft? Docker oder ein anderer Container-Dienst?
Da läuft Docker u ter der Haube.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 03 März 2021, 10:25:10
Es müsste Docker sein, doch wirklich erkennen kann man das nicht, da immer nur von Container-Station gesprochen wird.

Hab aber inzwischen rausbekommen was wohl passiert ist:
Habe wohl aus Versehen Daten aus dem Container-Station-Verzeichnis auf dem NAS gelöscht (Falsches Windowsfenster mit falscher Markierung beim Löschen angeklickt gehabt - Scheiß Windowslogik)
Habe schon versucht die Daten aus einer Sicherung zurück zu speichern. Bisher leider ohne Erfolg, zweiter Versuch läuft aber noch

ZitatContainer neu anlegen mit Konfiguration von vorher und auch den Pfad der persistenten Daten beibehalten.
Ohne Image und Kennnisse der Konfiguration ist das ziemlich schwer. Was meinst du mit persistenten Daten? Den Verzeichnislink auf das Verzeichnis des Fhem-Servers?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 03 März 2021, 10:44:21
"persistenten Daten" sind alle Daten, die nicht direkt im Container liegen. Also in einem extra Docker-Volumen oder (besser) direkt auf der "Platte"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 März 2021, 12:02:37
Zitat von: Superposchi am 03 März 2021, 10:25:10
Ohne Image und Kennnisse der Konfiguration ist das ziemlich schwer. Was meinst du mit persistenten Daten? Den Verzeichnislink auf das Verzeichnis des Fhem-Servers?

Du hast das Verzeichnis "/opt/fhem" irgendwo "hingemountet". Genau diese Daten brauch dein neuer Container da hier alle Logs und deine fhem.cfg liegt (und weitere Daten).

In docker-compose sieht das so aus. Wo das QNAP hat musst du dir aus der Doku rauslesen.

# Example w/ custom environment variables
  fhem:
    image: fhem/fhem:latest
    restart: always
    networks:
      - net
    ports:
      - "8083:8083"
    volumes:                                         <<<<<<<<<<<<<<<<<<<<<<<<
      - "./fhem/:/opt/fhem/"                   <<<<<<<<<<<<<<<<<<<<<<<<
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 03 März 2021, 13:02:41
Werde ich probieren sobald der Kopiervorgang abgeschlossen ist.

Ich fürchte nur, dass dies nicht das Problem löst, denn es sind ja Daten aus dem Verzeichnis der Docker-Installation (also dem Verzeichnis das die Container-Station bei der Installation selbsttätig erstellt).
Die müssen ja irgendwo wieder her kommen, oder nicht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 März 2021, 13:24:53
Zitat von: Superposchi am 03 März 2021, 13:02:41
Werde ich probieren sobald der Kopiervorgang abgeschlossen ist.

Ich fürchte nur, dass dies nicht das Problem löst, denn es sind ja Daten aus dem Verzeichnis der Docker-Installation (also dem Verzeichnis das die Container-Station bei der Installation selbsttätig erstellt).
Die müssen ja irgendwo wieder her kommen, oder nicht?

Docker Basics ... wenn du Docker richtig einsetzt hast du 2 Arten von Daten.

1) Flüchtige Daten, sprich das Image selbst und temporäre Daten. Diese können immer wieder erstellt werden indem du den Container neu anlegst und das Image lädst
2) persistente Daten, sprich die Daten die du für dich selber brauchst bzw. erstellt hast. Diese sind in dem Volume von dem ich rede. Die müssen irgendwo herkommen, richtig.

Herkommen tun die entweder indem diese immer noch da liegen wo dein System diese nach deiner Anweisung abgelegt hast. Oder eben aus deinem Backup. Wenn du kein Volume angelegt hast obwohl das so empfohlen und vorgesehen ist, dann hast du ein Problem. Dann musst du hoffen, dass du die Daten irgendwie aus deinem Backup bekommst.

Aber selbst dann, du schreibst ja dass du ein Backup hast. Wie ist der Recovery Vorgang bei QNAP, sollte in der Doku auch beschrieben sein. Dafür hat man ja das Backup.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 03 März 2021, 14:36:56
Ich habe den Eindruck wir reden aneinander vorbei.
Ich habe nicht die Daten des Containers gelöscht, sondern die Daten der Container-Software.
Also nicht die Word-Datei, sondern die Programmdateien von Word wenn man so will.

Meine Daten vom Fhem-Server sind sicher noch da, doch wenn die darüber geschaltete Container-Station selbst nicht mehr funktioniert, was dann?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 März 2021, 15:38:59
Zitat von: Superposchi am 03 März 2021, 14:36:56
Ich habe den Eindruck wir reden aneinander vorbei.
Ich habe nicht die Daten des Containers gelöscht, sondern die Daten der Container-Software.
Also nicht die Word-Datei, sondern die Programmdateien von Word wenn man so will.

Meine Daten vom Fhem-Server sind sicher noch da, doch wenn die darüber geschaltete Container-Station selbst nicht mehr funktioniert, was dann?

Dann ist das was ich vorhin sagte weiterhin gültig

Zitat von: kadettilac89 am 03 März 2021, 08:43:36
Container neu anlegen mit Konfiguration von vorher und auch den Pfad der persistenten Daten beibehalten. Dann werden die vorhandenen Daten wieder verwendet. Zumindest wenn die Docker-Implementierung sauber ist. Mit Docker-Compose kann ich Container löschen und neu anlegen wie ich will. Solange die persistenten Verzeichnisse bleiben sind auch Daten weiterhin da.

Wenn das, aus welchen Gründen auch immer, nicht geht den Container neu anlegen. Fhem stoppen. Die alten, persistenten Daten in den neuen Pfad der neuen persistenten Daten kopieren, ggf. Rechte anpassen.

Wenn der Container mit selber Konfiguration und selbem Pfad neu angelegt wird hast du ein neues, in deinem Jargon, Word mit dem alten Pfad zu den Word Dokumenten.

Wenn der Container aus welchen Gründen auch immer halb zerstört rumhängt erstmal den Container löschen und neu anlegen. Ob das Image vorhanden ist oder nicht - egal. Wird bei Bedarf vom Hub neu gezogen.

Versuche mal Docker Basics zu suchen. Damit wir vom Selben reden. Vor allem, was ist ein Image, was ist ein Container und was ist ein Volume. Wenn du den Zusammenhang verstehts kannst du leichter nachvollziehen warum du den Container neu anlegen sollst und warum die Daten im Volume bleiben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 04 März 2021, 16:51:20
Gemacht wie gesagt, die beiden Container werden wieder angezeigt, lassen sich aber nicht starten.
Offenbar wird ein Unterverzeichnis aus dem Programmverzeichnis der Container-Station selbst vermisst (Siehe Screenshot).

Eine Wiederherstellung aus einer Datensicherung lässt sich auch nicht zu 100% durchführen. Es wird mit einem Fehler abgebrochen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 04 März 2021, 18:53:54
ZitatEine Wiederherstellung aus einer Datensicherung lässt sich auch nicht zu 100% durchführen. Es wird mit einem Fehler abgebrochen.
Was hat die Fehlermeldung vom Start des Containers mit dem Fehler bei der Wiederherstellung der Datensicherung zu tun?  ???

Im Übrigen ist eine Datensicherung solange KEINE - bis der diensthabende Operator nicht mal erfolgreich eine Wiederherstellung durchgeführt hat!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 04 März 2021, 19:06:37
ZitatWas hat die Fehlermeldung vom Start des Containers mit dem Fehler bei der Wiederherstellung der Datensicherung zu tun?
Ganz einfach, es zeigt, dass der Fehler nicht im container, sondern in der Container-Station liegt. Es also nichts nutzen würde / genutzt hat den Container einfach neu aufzusetzen wie mehrfach gewünscht wurde.

Aus irgendeinem Grund läst sich ein Unterverzeichnis der Programmdateien der Container-Station nicht aus der Sicherung zurückspielen.
Genau dieses fehlende Unterverzeichnis verhindert aber ebenso den Start der nun wieder angezeigten Container.

Die Frage ist also wie ich das Verzeichnis wiederherstellen kann?
Denke dann lassen sich auch die Container wieder ordnungsgemäß starten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 04 März 2021, 19:15:49
Wobei Du den Thread für das offizielle FHEM Docker Basis Image gekapert hast - als Plattform ist sowas wie armhf oder x64 gemeint - und nicht qnap, nicht container-station und nicht allgemeiner docker support.

Tipp: installiere Deine Container-station neu, bring den "Hello World" (oder irgendwas) Container zum laufen, hol Deine Datensicherung für die Container zurück, starte die Container neu.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 04 März 2021, 20:33:36
Ganz ehrlich, dein Tonfall ist unter aller Sau.
Ich habe nichts gekapert, ich habe eine einfache Frage gestellt. Jedem steht es frei darauf zu antworten oder nicht.

Und da ursprünglich einfach der Container des Fhem-Servers verschwunden war, ist die Frage hier völlig richtig angesiedelt gewesen.
Alles weitere hat sich - wie es sehr oft der Fall ist - einfach erst entwickelt.
Dein Tipp ist leicht daher gesagt, aber als Anfänger ein extremer Schritt. Und sowas macht man eben nicht einfach so, besonders wenn die Gefahr besteht, danach den Container komplett neu aufsetzen zu müssen. Da probiert man zuerst alles andere drei Mal aus.
Übrigens als Tipp: In der QNAS Container-Station gibt es keinen "Hello World"-Container.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 04 März 2021, 20:42:41
Sorry aber jetzt bist Du auf dem "Falschen Dampfer"

"Einen Thread kapern" bedeutet, wenn Du in einem Thread etwas anderes behandelst. Und genau das hast Du getan.

Um den Thread nicht weiter aufzublähen, kannst Du bitte einen neuen aufmachen?

Übrigens als Tipp: In der QNAS Container-Station gibt es keinen "Hello World"-Container.
Gibt es .. da es der Standard Docker Testcontainer .... (Oder QNAB ist doch kein Docker)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 04 März 2021, 23:09:53
Also mal in aller Freundschaft, vielleicht solltet ihr die Definition von Kapern mal im Duden nachschlagen ehe ihr hier rumdichtet.
Kapern heißt mit Gewalt übernehmen und sich aneignen. Weder habe ich irgendeine Form von Gewalt ausgeübt - wie auch in einem Forum -, noch habe ich den Threat übernommen oder mir angeeignet.
Ich habe lediglich eine zum Threat passende Frage gestellt, die sich im nachhinein als andere Ursache herausgestellt hat. Nur weil ihr euch was anderes als Definition zurecht bastelt wird das dadurch nicht wahr. Aber egal, ich werde einen eigenen Threat eröffnen, das Forum dadurch unnötig aufblähen und Leute mit ähnlichen oder vergleichbaren Problemen im Dunkeln lassen, weil sie diesen Threat dann nicht finden.

In der QNAP Container-Station gibt es keinen Testcontainer, jedenfalls wird keiner automatisch mit installiert.
Nach der Installation der Container-Station ist diese komplett leer. Sie muss erst durch das importieren gewünschter Images befüllt werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 04 März 2021, 23:15:00
Du widersprichst dir selbst:
Threat ist Gewalt/Bedrohung Thread ist der Faden. Das hier ist ein Thread - Ende und Aus.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 05 März 2021, 08:48:09
Wenn ich etwas suche und einen Therad mit 76! Seiten finde, weiß ich schon, das dort keine Lösung zu finden ist.

Und sorry, aber Duden und "Netzspeach" ist etwas anderes. Es ist also nicht "ehe ihr hier rumdichtet." sondern in jedem Forum so zu finden.

Aufblähen tut das Forum solche Monsterhreads ...... und zum finden, kannst Du gerne hier noch den Link zum neuen Thread hinterlegen!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 05 März 2021, 08:52:51
Ah ok, jetzt wird ein Schreibfehler dazu genutzt sich eine selbst erfundene Definition eines Wortes zu rechtfertigen, ganz ehrlich - Lachhaft!
Mag sein, dass ich als Redakteur in diesem Punkt etwas penibel bin, doch man kann nicht einfach die Bedeutung eines Wortes ändern weil es einem gerade so in den Kram passt.
Es gibt die Deutsche Sprache und die ist sowohl vom Sinn, als auch von der Schreibweise für jeden bindend, der sie benutzt.

Kapern würde also zutreffen, wenn mit Gewalt oder zumindest feindlicher Absicht der Ursprungsersteller von mir verdrängt oder ausgetauscht worden wäre. Nicht aber wenn einfach eine Frage gestellt wird, die ursprünglich sogar noch zum Thema passte.

Also denkt was ihr wollt, aber sucht euch ein neues Wort. Kapern hat nichts mit dem zutun worum es in dieser Diskussion geht, die leider wieder mal völlig vom Thema abweicht und so den THREAD erst Recht aufbläht!

ZitatUnd sorry, aber Duden und "Netzspeach" ist etwas anderes.
Es gibt kein NETZSPEAK. Das ist etwas völlig selbstgebasteltes und nicht mal Anerkannt. Da hat selbst ein Dialekt wie er ein Bayer spricht einen höheren Stellenwert. Von daher halte ich mich - wenn ich Deutsch schreibe - an die Definition die der Duden vorgibt und nichts anderes hat irgendeine Bedeutung oder Rechtfertigung. Wenn es dir nicht passt, erfinde deine eigene Sprache und reiche Sie beim internationalen Sprachenkommitee zur Anerkennung ein. Bis dahin bedeutet Kapern das was ich oben geschrieben habe und nicht weiter!

Ach übrigens, ist deine Netzspeak kein Phänomen im Internet, sondern einzig in diesem Board!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 05 März 2021, 09:28:36
jetzt mal das ganze OT beseite

1) Superposchi, das Problem von dir hat nicht mit dem FHEM-Image zu tun. Es ist QNAP spezifisch. Öffne am besten mit dem Post mit dem Screenshot einen eigenen Thread im Forumteil "Linux". Wenn es dann nur noch um QNAP geht dann musst du in deren Forum weitersuchen.

2) Das "Hallo Welt Image" ... hast du irgend einen anderen Container laufen oder nur Fehm? Lege mal irgend einen Container an und starte den, egal welchen. Nginx, Mysql, ... was auch immer. Nur um zu sehen ob, bzw. dass die Docker Umgebung des QNAP funktioneirt. Der Pfad "overlay2" sind die temporären Dateien der Docker-Umgebung. Images usw. Wenn es auch mit einem anderen Container Probleme gibt bleibt dir vermutlich nur noch ein kompletter Reset der gesamten Docker-Installation

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 05 März 2021, 10:02:27
Sorry Superposchi, ab jetzt bist Du in meiner Blockliste ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 05 März 2021, 13:05:16
Zitat von: Superposchi am 05 März 2021, 08:52:51
Ach übrigens, ist deine Netzspeak kein Phänomen im Internet, sondern einzig in diesem Board!

https://www.google.com/search?q=thread+kapern
https://www.google.com/search?q=thread+hijack

Jo  ;D
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 11 März 2021, 22:32:11
Hallo,
Frage: Unterstützt das Docker Image auch GPIOs eines RPi oder ist das so einfach gar nicht inegrierbar?

VG

Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 12 März 2021, 09:18:19
Zitat von: Homalix99 am 11 März 2021, 22:32:11
Hallo,
Frage: Unterstützt das Docker Image auch GPIOs eines RPi oder ist das so einfach gar nicht inegrierbar?

VG

Alex

hat weniger mit dem Image als mit Docker Basics zu tun. Oder siehst du die GPIO devices schon im Container aber der Zugriff geht nicht?

GPOI im Container müsste mit einem der beiden WEge gehen
1) Docker Container im privileged-Mode laufen lassen (Docker Parameter --privileged)
2) Das Device welches für die GPIO verwendet wird als Device mounten. Die sind im Pfad /dev/ vermutlich irgend was mit GPIO /dev/*gpio* ... Parameter im Docker run --device /dev/gpio:/dev/gpio. .... Natürlich den Namen anpassen. Habe keinen Raspi zum nachsehen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 12 März 2021, 09:42:50
Vielen Dank,
bin erst jetzt auf das Thema Docker gestoßen und habe schon ein bisschen experimentiert.
Um also die GPIOs mit einzubinden wird das Dockerfile angepasst. Werde ich demnächst mal
testen. Wollte nur generell wissen, ob es überhaupt möglich ist, sonst wäre das ein KO-Kriterium
für Docker bei meinem System. Habe nämlich alle GPIOs in Benutzung.

VG
Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 12 März 2021, 10:05:28
es gibt sicher ein paar Hürden, aber du kannst mit einer separaten SD-Karte ja testen.

Suche im Thread nach GPIO, da sind ein paar Posts ... z. B. https://forum.fhem.de/index.php/topic,89745.msg1096018.html#msg1096018

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 12 März 2021, 10:24:14
Hallo Alex,
Zitatsonst wäre das ein KO-Kriterium für Docker bei meinem System.
Meine Meinung auch wenn es für diesen Thread etwas off-topic ist:
Als nicht Docker Spezi hat man genug damit zu tun, docker etwas zu verstehen und docker Images so zu nehmen wie sie sind!
Es ist sehr "einfach", ein System komplett nur mit docker Containern zu betreiben, das macht einen Umzug und Neuanfang sehr einfach.
Man kann auch docker Images/Container einfach so verwenden wie sie sind und zu einem individuellen System dazu verwenden.

Zusätzliche Hürden um jeden Preis würde ich vermeiden!

Deine Frage GPIO ist auch nicht so pauschal zu beantworten. ;)
Beispiele:
Alles im Docker: dieses FHEM Image mit /dev/ttyAMA0 (ja das ist GPIO) und einem HMUART Modul läuft super, dazu sonos2mqtt, conbee/deconz, homebridge alles einfach "standard".
FHEM "normal" auf dem Host dazu sonos2mqtt, conbee/deconz, homebridge alles einfach "standard" - läuft auch super und viel einfacher als die individuelle Installation dieser Zusatzdienste.

Was ich sagen will: Es besteht kein Zwang für KO :)

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 März 2021, 11:03:45
Ich muß gestehen, das ich Docker-Images rein Netzwerkbasiert benutzen würde. D.h. keinen direkten Hardwareanschluß. USB-Geräte können teilweise auch über Netzwerk (ser2net o.Ä.) angesteuert werden, was ich bevorzugen würde. Nur läuft hier auch fhem auf einem Zotac und nicht ein Raspi. Sehe beim Pi direkt keinen Vorteil von Docker (und ich habe beruflich mit Docker zu tuen). Docker hat den Vorteil, wenn verschiedene Sachen parallel auf einen Rechner laufen müssen und man verschiedene Softwarestände braucht (oder einfacheres Update, einfacheres Testing). Beim Pi würde man aber relativ schnell für 2. (oder 3. 4. 5.) Software einen 2. (3. 4. 5.) Pi nehmen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 12 März 2021, 16:19:18
naja, das ist dann mehr was für Dogmatiker. Wenn man serielle Ports nutzen will, dann geht eben auch der priviliged mode und fertig. Ohne irgendwelche ser2net-Geschichten. So hab ich das bei mir laufen. Aber natürlich jeder so wie er mag.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 12 März 2021, 17:49:07
ZitatWenn man serielle Ports nutzen will, dann geht eben auch der priviliged mode und fertig.
Was hat das miteinander zu tun? Serielle Ports kann man ganz normal durchreichen - da braucht man mW keinen priviliged mode

Aber die Intentionen warum man docker verwenden will können ganz unterschiedlich sein.  ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 März 2021, 10:38:29
Das durchreichen von Hardware zu Docker macht es komplexer. Und frei nach dem Moto "Keep it Simpel" mache ich es einfach .. Kompliziert wird es von alleine ...

Also nix mit Dogmatik oder so!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 15 März 2021, 11:38:03
Also Leute,

ich habe es hinbekommen mit den GPIOs auch ohne priveleged mode.
Habe auch ein externes Nas Laufwerk (auf Fritzbox) dem fhem Container zur Verfügung gestellt.
Vielen Dank für die Unterstützung.

Meine nächste Hürde ist Mariadb.
Die fertigen images beziehen sich meist auf Ubuntu und Alpine, habe aber debian buster installiert. Bei einem image mit eigenem Dockerfile erstellt, startet die Db nicht.
Es hat doch vermutlich jemand hier mariadb in einem Dockercontainer unter buster laufen. Dazu bräuchte ich ein paar Tipps

VG

Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 15 März 2021, 12:04:52
Hallo Alex,

das hier ? https://hub.docker.com/_/mariadb/ dein debian buster hat doch nix mit dem container image zu tun? Oder was versteh ich falsch?

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 15 März 2021, 12:21:27
Hallo Otto,

scheint aber schon so. Hab ich ja gleich zu Anfang ausgeführt, weil ich dachte es ist ja ein offizielles image zu mariadb.
Das docker pull mariadb führt bei docker folgender Ausgabe:
no matching manifest for linux/arm/v7 in the manifest list entries

Nach Fehlermeldung gegoogelt in entsprechenden Foren sagt aus, dass die offiziellen mariadb mysql images scheinbar nur auf Basis von 64 bit  OS erstellt wurden.
Und Buster läuft als 32 bit OS.

Gruß

Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 15 März 2021, 12:27:30
Zitat von: Homalix99 am 15 März 2021, 12:21:27
Das docker pull mariadb führt bei docker folgender Ausgabe:
no matching manifest for linux/arm/v7 in the manifest list entries

Nach Fehlermeldung gegoogelt in entsprechenden Foren sagt aus, dass die offiziellen mariadb mysql images scheinbar nur auf Basis von 64 bit  OS erstellt wurden.
Und Buster läuft als 32 bit OS.
Hallo Alex,
ich habe auch einen RPI 4 noch mit 32 Bit, versuche mal diese Definition. phpMyAdmin läuft dann auch.


  mysql:
    image: hypriot/rpi-mysql    <<< Das ist 32 Bit für ARM
    restart: always
    ports:
        - '3306:3306'
        - '33060:33060'
    volumes:
        - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
        - ./mysql/data:/var/lib/mysql
        - ./mysql/log:/var/log
        - ./mysql/mycustom.cnf:/etc/mysql/conf.d/custom.cnf
    environment:
        MYSQL_ROOT_PASSWORD: <Passwort>
        MYSQL_DATABASE: fhem
        MYSQL_USER: <Dein Fhem user inder DB>
        MYSQL_PASSWORD: <Passwort>

  phpMyAdmin:
    image: jackgruber/phpmyadmin
    restart: always
    ports:
        - '8082:80'
    links:
        - mysql
    environment:
        PMA_HOST: mysql
        PMA_PORT: 3306
    depends_on:
      - "mysql"


Auch ein Boot von SSD ohne SD-Card ist möglich und zu empfehlen. An der 64 Bit Installation bin ich noch dran.

Momentan boote ich mit Buster 32 Bit von SSD und habe die SSD dann gemounted. Eine DB auf der SD-Card wäre wegen der Lebensdauer nicht ratsam.
Der Boot ohne SD-Card direkt von der SSD läuft auch schon, sogar mit 64 Bit.
Dann müssen aber noch alle Docker Container auch auf 64 Bit umgestellt werden.
Und niemals das Backup vergessen!!!

VG
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 15 März 2021, 12:59:59
@Homalix99
Dein Problem liegt nicht an buster (oder Debian /Ubuntu), sondern an 32 zu 64 Problem.

Du kannst, wie von ch.eick angegeben den rpi-mysql verwenden (wobei mich dort das "Updated 3 years ago" stört), oder selberbauen. Dockerfiles werden von den meisten Projekten mit angegeben, hier z.B. https://github.com/hypriot/rpi-mysql/blob/master/Dockerfile (https://github.com/hypriot/rpi-mysql/blob/master/Dockerfile)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 15 März 2021, 13:07:54
Zitat von: Wernieman am 15 März 2021, 12:59:59
@Homalix99
Dein Problem liegt nicht an buster (oder Debian /Ubuntu), sondern an 32 zu 64 Problem.
und am "no matching manifest for linux/arm/v7 in the manifest list entries" Problem.
@Homalix99 hattest Du nicht erwähnt ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 15 März 2021, 13:36:30
Zitat von: Wernieman am 15 März 2021, 12:59:59
@Homalix99
Dein Problem liegt nicht an buster (oder Debian /Ubuntu), sondern an 32 zu 64 Problem.

Du kannst, wie von ch.eick angegeben den rpi-mysql verwenden (wobei mich dort das "Updated 3 years ago" stört), oder selberbauen. Dockerfiles werden von den meisten Projekten mit angegeben, hier z.B. https://github.com/hypriot/rpi-mysql/blob/master/Dockerfile (https://github.com/hypriot/rpi-mysql/blob/master/Dockerfile)
Das stört mich auch, aber soviel Docker kann ich noch nicht ;-)
Und ich wollte halt direkt auf das 64 Bit Buster wechseln, wo dann eventuell auch ein aktuelles MySQL verfügbar ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 15 März 2021, 16:09:27
Vielen Dank,

der mariadb container läuft.
Hat zwar das fhem-init.sql nicht ausgeführt, habe aber erstmal ein Backup des bestehenden Prod. Systems eingespielt.
@ch.eick:
Das mit der boot from SSD werde ich auf alle Fälle realisieren. Dazu brauche ich vermutlich einen USB Hub, da die SSD 1 Ampere zieht und der RPi das nicht lieferen kann.

Gruß

Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 15 März 2021, 16:21:36
Zitat von: Homalix99 am 15 März 2021, 16:09:27
Hat zwar das fhem-init.sql nicht ausgeführt, habe aber erstmal ein Backup des bestehenden Prod. Systems eingespielt.
no duplicate key nicht vergessen :-)

Zitat
Das mit der boot from SSD werde ich auf alle Fälle realisieren. Dazu brauche ich vermutlich einen USB Hub, da die SSD 1 Ampere zieht und der RPi das nicht lieferen kann.
Am RPI 4 ist ein USB3, der bei mir genügend Leistung liefert. Eventuel mal nach einer anderen SSD schauen.
eventuel ist in der cmdline.txt die option "usb-storage.quirks" notwendig, wenn die SSD mit dem USB3 nicht 100% kompatiebel ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 15 März 2021, 21:03:43
@ch.eick:
Hallo Christian.
Noch ein Verständnisproblem zu mariaDB: Das läuft ja jetzt stabil in einem eigenen Container, am bestehenden Lifesystem ja noch nicht separiert. Das Bindeglied zwischen fhem und der mysql DB ist ja die db.conf
Wie muss diese angepasst werden, damit der Zugriff auf die DB funktioniert?
Jedenfalls kann fhem die DB nicht erreichen.

zu SSD:
Zitat
Am RPI 4 ist ein USB3, der bei mir genügend Leistung liefert. Eventuel mal nach einer anderen SSD schauen.
eventuel ist in der cmdline.txt die option "usb-storage.quirks" notwendig, wenn die SSD mit dem USB3 nicht 100% kompatiebel ist.
Da ich 6 USB Ports belegt habe (HUB ist am Prod.System) wird die max. Gesamtleistung des RPi überschritten. Also eben USB-HUB, aber den kann ich erst beim filalen Umzug auf den neuen RPi-4 einsetzen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 25 März 2021, 12:03:36
Hallo zusammen,

vorab, ich bin in dem Thema Docker noch relativ neu und habe versucht, die Infos zu meinem Problem zu finden.
Ich brauche nun aber doch ein wenig Unterstützung, bitte.

Situation:
FHEM läuft im hier besprochenen Docker-Image auf der Syno (Dafür vielen Dank, das läuft schon seit langem super!!)
Nun möchte ich mit dem DoorBird Fotos und Videos auf dem Volume anlegen.
Dazu habe ich die entsprechenden Ordner im Volume-Tab (Syno) zugeordnet und im DoorBird-Modul eingetragen.
Soweit, so gut. Die Files bekommen als Besitzer und Gruppe "6061". Der User und die Gruppe existieren auf der Syno nicht.
Damit werden die Files teils nicht in der Video-/Photo-Station indiziert und mit meinem "normalen" User habe ich keinen Zugriff.

Erste Idee: Gruppe "6061" angelegt und einen meiner User zugeordnet.
Problem: die Files haben für die Gruppe die Berechtigung "lesen", um die Videos abzuspielen braucht es "ausführen".

Zweite Idee: Ändern FHEM_UID und FHEM_GID von "6061" auf einen existierenden User und Gruppe.
Keine gute Idee, der Container startet nicht mehr. Also Kommando zurück.
Liegt wohl daran, dass die Files im FHEM-Verzeichnis auch alle mit dem User "6061" angelegt wurden und nach dem Wechsel dann nicht mehr korrekt im Zurgfif sind?!?!?

Frage: wie kann ich die erzeugten Files mit den korrekten Berechtigungen/User/Gruppe erzeugen?

Danke Euch vorab und schöne Grüße
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 März 2021, 12:34:16
Zitat von: Dirk070 am 25 März 2021, 12:03:36
Zweite Idee: Ändern FHEM_UID und FHEM_GID von "6061" auf einen existierenden User und Gruppe.
Keine gute Idee, der Container startet nicht mehr. Also Kommando zurück.

Am besten erstmal den Ordner sichern / kopieren damit du dir nichts löscht oder komplett zerstörst.

Die Idee ist nciht so schlecht. FHEM_UID und FHEM_GID meinst du sicher die Parameter im Docker-Container (env-parameter). Du kannst dich per ssh auf dein Nas einloggen. Ggf. musst du dir SSH noch freischalten. Lt. Google .... Synology NAS: DSM Control Panel > Terminal & SNMP > Terminal ... wenn das veraltet ist mussst du mal suchen und Google fragen.

Per ssh einloggen und dann per  ....  sudo chown -R <user>:<group> <folder>  .... den neuen User und Gruppe setzen. Ich vermute dein Docker statet nicht weil der neue Benutzer nicht alle nötigen Rechte hat.

Da du auf der Kopie arbeitest ... :)  .... machst du nichts kaputt. Wenn der Test erfolgreich ist kannst den Ordner umbennenen und als Orginal weiter nutzen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 25 März 2021, 13:42:17
Vielen Dank, genau die Idee hatte ich auch und war schon in der Umsetzung  :D
Im Protokoll des Containers kommt es aber zu diesem Fehler:

Preparing configuration ... done

Starting FHEM ...

su: user fhem does not exist

Unable to start FHEM process - errorcode 1


Existiert der User fhem (den ich auf der Syno angelegt habe) nicht im Container?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 März 2021, 13:51:13
vielleicht sind im start (creation-script) routinen drin die jetzt bei der änderung des GUID / GID nicht mehr durchlaufen werdne. Erstelle mal einen komplett neuen container mit dem den neuen GUID / GID. Keine vorhandenen Dateien verwenden. Vermutlich wird beim komplett neu erzeugen des Containers ein user fhem mit entsprechenden GUID / GID angelegt. Da bei dir der fhem-User schon besteht geht das hier scheinbar nicht mehr.

Wenn das funktioneirt siehst du auch welche Rechte die neu angelegten Verzeichnisse / Dateien haben. Damit kannst du schon mal testen, ob die Zugriffe überhaupt funktionieren würden. Dein ursprüngliches Proble bzw. deine Anforderung.

Dann im Anschluss den vorhandenen Ordner mit den neuen Rechten präparieren und entsprechend umbennen oder in der Docker-Config den Pfad anpassen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 25 März 2021, 14:06:48
Danke für die Unterstützung.

Ich hatte den Container kopiert, ebenso wie das Verzeichnis.
UPDATE/ERGÄNZUNG: selbes Ergebnis, wenn ein komplett neuer Container aus dem Abbild erzeugt wird und ein leeres Verzeichnis gemountet wird. Die FHEM-Files werden im Verzeichnis erzeugt, haben als Besitzer aber ROOT.

Hier mal das komplette Protokoll, zu Anfang (ganz unten) wird versucht, den User und die Gruppe anzulegen:

2021-03-25 12:34:16,stdout,Unable to start FHEM process - errorcode 1

2021-03-25 12:34:16,stdout,su: user fhem does not exist

2021-03-25 12:34:16,stdout,Starting FHEM ...

2021-03-25 12:34:16,stdout,

2021-03-25 12:34:16,stdout,Preparing configuration ... done

2021-03-25 12:34:16,stdout,

2021-03-25 12:34:16,stdout,

2021-03-25 12:34:16,stdout,

2021-03-25 12:34:16,stdout,chown: invalid user: 'fhem.fhem'

2021-03-25 12:34:16,stdout,14. Updating SSH key pinning and SSH client permissions for user 'fhem' ...

2021-03-25 12:34:16,stdout,13. Pre-authorizing SSH to Docker host for user 'fhem' ...

2021-03-25 12:34:16,stdout,12. Adding host.docker.internal to /etc/hosts ...

2021-03-25 12:34:15,stdout,11. Adding gateway.docker.internal to /etc/hosts ...

2021-03-25 12:34:15,stdout,10. Updating /etc/sudoers.d/fhem-docker ...

2021-03-25 12:34:15,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:15,stdout,9. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...

2021-03-25 12:34:15,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:15,stdout,8. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...

2021-03-25 12:34:15,stdout,7. Correcting group ownership for /dev/tty* ...

2021-03-25 12:34:09,stdout,6. Enforcing file and directory permissions for /opt/fhem ...

2021-03-25 12:34:09,stdout,chown: invalid user: 'fhem:users'

2021-03-25 12:34:09,stdout,chown: invalid user: 'fhem:users'

2021-03-25 12:34:09,stdout,5. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...

2021-03-25 12:34:09,stdout,4. Creating log directory /opt/fhem//opt/fhem/log ...

2021-03-25 12:34:09,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,usermod: user 'fhem' does not exist

2021-03-25 12:34:08,stdout,useradd: invalid user ID 'fhem'

2021-03-25 12:34:07,stdout,3. Creating user 'fhem' with UID fhem ...

2021-03-25 12:34:07,stdout,2. Enforcing GID for group 'bluetooth' to 6001 ...

2021-03-25 12:34:07,stdout,groupadd: invalid group ID 'users'

2021-03-25 12:34:07,stdout,1. Creating group 'fhem' with GID users ...

2021-03-25 12:34:07,stdout,Preparing user environment ...

2021-03-25 12:34:07,stdout,

2021-03-25 12:34:07,stdout,

2021-03-25 12:34:07,stdout,

2021-03-25 12:34:07,stdout,1. Updating existing FHEM installation in /opt/fhem
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 März 2021, 14:57:04
welche uid / gid gibst du an? versuche mal das leere verzeichins mit dem uid / gid anzulegen bzw. den owner entsprechend zu setzen. dann erst den container neu erstellen lassen. wenn das leere verzeichnis root "gehört" dann kann der normale user den du verwenden willst vermutlich die reche nicht ändern.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 25 März 2021, 15:24:02
Angegeben war User (UID) "fhem" und Group (GID) "users". Der User und die Gruppe existieren auf der Syno.

Im Log sieht das für mich so aus, als wenn die Anlage des Users (adduser) schon im Image scheitert.

2021-03-25 12:34:09,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,adduser: The user `fhem' does not exist.

2021-03-25 12:34:08,stdout,usermod: user 'fhem' does not exist

2021-03-25 12:34:08,stdout,useradd: invalid user ID 'fhem'

2021-03-25 12:34:07,stdout,3. Creating user 'fhem' with UID fhem ...

2021-03-25 12:34:07,stdout,2. Enforcing GID for group 'bluetooth' to 6001 ...

2021-03-25 12:34:07,stdout,groupadd: invalid group ID 'users'

2021-03-25 12:34:07,stdout,1. Creating group 'fhem' with GID users ...

2021-03-25 12:34:07,stdout,Preparing user environment ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 März 2021, 20:40:00
ich habe eine Vermutung ...

Zitat von: kadettilac89 am 25 März 2021, 14:57:04
welche uid / gid gibst du an?

Ich habe getestet:
1) bestehender Container user/group geändert. Funktionert, neue Reche auf Verzeichnis
2) komplett neuer Container

Meine Config:


    fhemtest:
        image: fhem/fhem
        container_name: fhemtest
        restart: always   
        volumes:
            - ./fhemtest:/opt/fhem
        environment:
            FHEM_UID: 1001
            FHEM_GID: 1001
            LANG: "de_DE.UTF-8"



Poste mal deine Parameter. Hast du die UID + GID (Zahl zwischen 1000 und 9999) oder den Namen des User und Gruppe? Ich vermute da liegt das Missverständis.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 26 März 2021, 08:34:46
Wobei übrigens bei Standard-Docker die UserID extern nicht gleich der UserID intern sein muß ... (kann, aber nicht muß)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 März 2021, 09:24:05
Zitat von: Wernieman am 26 März 2021, 08:34:46
Wobei übrigens bei Standard-Docker die UserID extern nicht gleich der UserID intern sein muß ... (kann, aber nicht muß)

Um hier nicht mehr Verwirrung zu stiften ... Wording

UID = numerische Kennung des Users. Default Docker 6061
GID = numerische Kennung der Gruppe. Default Docker 6061

Real User ID / Name = der Name des uers, z. B. fhem, root, testuser
Real Group ID / Name = der Name der Gruppe, z. B. Dialout, ...

Beispiel / vermutete Fehler von Dirk zumindest lt. Log, er gibt die Real User Namen + Real Gruppen Namen statt deren UID/GID an .... fhem:users mit statt deren UID/GID.

Beispiel
Real UID im Container fhem mit ID 1001
Real UID auf Synology fhemsyn mit ID 1001

Der User fhem im Docker hat UID 1001 (da so konfiguriert). Der User auf der syn heißt fhemsyn und hat definitiv auch UID 1001. Die UID im Container und der Synology ist identisch, der Real User Name jedoch unterschiedlich je nachdem wo du schaust, fhem vs. fhemsyn.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 26 März 2021, 13:53:52
Vielen Dank an Euch.
Ja, ich habe tatsächlich mit den realnames gearbeitet.
Da die 6061 auch in der Syno als Besitzer angezeigt wurde, hatte ich das garnicht hinterfragt.  ::)

Ich teste jetzt nochmal mit uid und gid, die Infos habe ich aus der Konsole per "id fhem" gezogen.
Ich melde mich wieder, Euch nochmals vielen Dank.

UPDATE:
VIELEN DANK!!!!

Mit den ermittelten UID und GID klappt jetzt alles.
Ich habe das produktive Verzeichnis kopiert und als Besitzer den Syno-User gesetzt.
Danach im Docker die uid und gid dazu passend gesetzt. Alles top, die Bilder/Videos aus dem DoorBird-Modul werden mit dem gewünschten User angelegt.
TOP!

Nochmals Danke für Eure Zeit und Hilfe.

Viele Grüße und ein schönes Wochenende
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 28 März 2021, 09:05:11
Nachdem es jetzt seit Monaten ohne ein problem gelaufen ist will mein Docker Image nicht mehr.
Mit der Meldung:
2021.03.28 08:52:36.705 2: Calendar NCKalender: error (data not in ICal format; even not gzip data),
Error parsing time at /usr/lib/x86_64-linux-gnu/perl/5.28/Time/Piece.pm line 583.,
/entry.sh: line 621: kill: (13661) - No such process,
,
,
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (13661) - No such process,
10/entry.sh: line 625: kill: (13661) - No such process,
9/entry.sh: line 625: kill: (13661) - No such process,
8/entry.sh: line 625: kill: (13661) - No such process,
7/entry.sh: line 625: kill: (13661) - No such process,
6/entry.sh: line 625: kill: (13661) - No such process,
5/entry.sh: line 625: kill: (13661) - No such process,
4/entry.sh: line 625: kill: (13661) - No such process,

geht es in eine Endlosschleife ohne das ich was geändert hätte. Was kann ich machen? Bzw woran liegt es und wie kannich das ändern?
Es laufen 2 Container auf der Maschine wobei der 1 ohne Probleme will der andere ist jetzt in einer Endlosschleife...
Hab den Ordner .config im Fhem Ordner gelöscht und jetzt startet der Container wieder und ist auch "healthy" - warum auch immer.
gruß Anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 28 März 2021, 10:01:16
Zitat von: antonwinden am 28 März 2021, 09:05:11
Es laufen 2 Container auf der Maschine wobei der 1 ohne Probleme will der andere ist jetzt in einer Endlosschleife...
Hab den Ordner .config im Fhem Ordner gelöscht und jetzt startet der Container wieder und ist auch "healthy" - warum auch immer.
gruß Anton

Verstehe den Post nicht. Container läuft, es gab Logeinträge. Was ist nun die Frage?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 28 März 2021, 10:20:45
einer der beiden Container restarted mit Fehlermeldung ständig:
/entry.sh: line 621: kill: (12799) - No such process
Error parsing time at /usr/lib/x86_64-linux-gnu/perl/5.28/Time/Piece.pm line 583.
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (12799) - No such process
10/entry.sh: line 625: kill: (12799) - No such process
9/entry.sh: line 625: kill: (12799) - No such process
8/entry.sh: line 625: kill: (12799) - No such process


7/entry.sh: line 625: kill: (12799) - No such process

der andere Container läuft in einem anderen Ordner auf der gleichen Maschine ohne Probleme...
1 Container geht der andere auf einmal ohne Änderung nicht mehr... kurz hat es mit dem löschen von .config geholfen war allerdings nur von kurzer Dauer und seither restart bis er in "unhealthy" geht
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 28 März 2021, 10:28:30
fhem mit demo-config starten ... immer noch?
container löschen, neu anlegen, demo config starten ... immer noch?
nach re-creation backup einspielen ... immer noch?

dann kann man weiter schaun ... SD-Karte? Welche "ohne Änderungen"-Änderungen wurden gemacht, updates, Karte/HDD voll ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 28 März 2021, 11:45:26
1: geht
2: geht
3: nein geht nicht - geht wieder in endlosschleife.

ist mir schon klar das da was schief läuft nur war die letzte Änderung die ich gemacht habe 12h her (DOIF geändert) und ich kann mir schwer vorstellen das es daran liegt.
4: alle Änderungen die ich gestern gemacht habe rausgeworfen - kein Änderung geht wieder in die Endlosschleife

5: die demo-config geändert und die aktuelle config eingespielt -> läuft

6: alles was fehlt (diverse Module wie fronius, denon und ein paar andere) installieren -> nachdem ich das Modul für Renault ZOE installiert habe gab es wieder eine Endlosschleife - und das ist schon über 1 Woche ohne Änderung gelaufen...

Also ich denke ich hab den Fehler gefunden...

aber was tut man sonst an einem Sonntag Vormittag im Lockdown...
gruß Anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 28 März 2021, 12:08:36
hat dann vermutlich nichts mit dem Docker Image zu tun. Oft schwierig das Problem zu finden.

Im Modul selbst ist der Maintainer und das Forum bzw. der Unterbereich. Da solltest du mal suchen ob schon was ähnliches gemeldet wurde, oder einen Thread öffnen. In deinem Log steht was von Error pasing ... vielleicht ist auf der Gegenseite, dem Service zu Renault geändert, anderes Format, zustäzliche Authentifizierung ...

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 28 März 2021, 12:56:19
Nachdem ich selber mit "try and error" drauf gekommen bin hat sich ein anderer Leidensgenosse im Modulthread gemeldet - also bin ich nicht der einzig glückliche...
danke anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 09 April 2021, 07:52:41
Hallo zusammen,

vor zwei Tagen bin ich mit meinem FHEM erfolgreich auf die Docker Variante umgestiegen was auch soweit reibungslos funktioniert hat - Danke für den gut preparierten Container.

Ein Problem habe ich allerdings und bekomme es alleine nicht gelöst.
Ich nutze Jabber / XMPP um gewisse Statusmeldungen zu versenden. Das Fhem Modul benötigt hier gewisse Ständer der Perl Module damit es funktioniert:
https://wiki.fhem.de/wiki/Jabber (https://wiki.fhem.de/wiki/Jabber)

Ich habe versucht die Module auf den notwendigen Stand zu bringen, aber leider bleiben die Versionsstände auf dem aktuellen Stand. Das Verfahren an sich habe ich bei Raspberry Installationen schon mehrfach durchgeführt und hat funktioniert.

Kann man die Module im Container evtl. auf den notwendigen Stand downgraden und per "apt-mark hold" festsetzen?

Vielen Dank für Eure Hilfe.

Gruß, Thomas

P.S.: Das Ganze wurde hier https://forum.fhem.de/index.php/topic,89745.msg881283.html#msg881283 (https://forum.fhem.de/index.php/topic,89745.msg881283.html#msg881283) schonmal festgestellt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 09 April 2021, 10:34:01
Zitat von: ThomasMagnum am 09 April 2021, 07:52:41
Ein Problem habe ich allerdings und bekomme es alleine nicht gelöst.
Ich nutze Jabber / XMPP um gewisse Statusmeldungen zu versenden. Das Fhem Modul benötigt hier gewisse Ständer der Perl Module damit es funktioniert:
https://wiki.fhem.de/wiki/Jabber (https://wiki.fhem.de/wiki/Jabber)

Ich habe versucht die Module auf den notwendigen Stand zu bringen, aber leider bleiben die Versionsstände auf dem aktuellen Stand. Das Verfahren an sich habe ich bei Raspberry Installationen schon mehrfach durchgeführt und hat funktioniert.

Kann man die Module im Container evtl. auf den notwendigen Stand downgraden und per "apt-mark hold" festsetzen?
Hast Du das auch im Container gemacht, oder auf dem Trägersystem?
Wenn Du dich im Container anmeldest, kannst Du es zum Testen temporär machen.

Hier mal ein Beispiel für die .yml Datei um etwas nach zu installieren.

  fhem:
    image: fhem/fhem:latest
    restart: always
    network_mode: host
    privileged: true
    volumes:
      - "./core/:/opt/fhem/"
    environment:
########################################
# hier geht's los mit der Installation von speziellen Paketen
      PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"
      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare XML::Bare Protocol::WebSocket::Handshake::Server Crypt::Rijndael Crypt::Random --verbose"
########################################
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
    depends_on:
      - "mysql"

VG Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 09 April 2021, 13:06:56
Hallo Christian,

das habe ich per "docker exec -it FHEM /bin/bash" auf dem Containersystem gemacht.
Da hier erst aktuelle Module entfern und dann ältere Versionen installiert werden, komm ich mit Deinem YML File nicht klar bzw. kann das nicht umsetzen.
Zumal ich das auf einer Synology am Laufen habe und dort eine "schöne" GUI zur Verfügung steht.

Folgendes muss umgesetzt werden um das Jabber Modul wieder zum Laufen zu bekommen:
sudo apt-get remove libnet-xmpp-perl
sudo apt-get remove libxml-stream-perl

sudo apt-get install build-essential
wget http://ftp.de.debian.org/debian-archive/debian/pool/main/libn/libnet-xmpp-perl/libnet-xmpp-perl_1.02-3_all.deb
wget http://ftp.de.debian.org/debian/pool/main/libx/libxml-stream-perl/libxml-stream-perl_1.23-2_all.deb
sudo dpkg -i libxml-stream-perl_1.23-2_all.deb
sudo dpkg -i libnet-xmpp-perl_1.02-3_all.deb
sudo apt-get install libnet-jabber-perl


Thomas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 09 April 2021, 13:28:09
In aller grösster Not, baue Dir doch den Container auf Basis des FHEM Containers neu?

ich kan Dir aber nicht sagen, wie es bei der "schönen GUI" der Synology funktioniert. Aber ein Docker build sollte "drin sein" (Oder es ist eine blöde GUI)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 09 April 2021, 13:35:40
Zitat von: ThomasMagnum am 09 April 2021, 13:06:56
Hallo Christian,

das habe ich per "docker exec -it FHEM /bin/bash" auf dem Containersystem gemacht.
Da hier erst aktuelle Module entfern und dann ältere Versionen installiert werden, komm ich mit Deinem YML File nicht klar bzw. kann das nicht umsetzen.
Zumal ich das auf einer Synology am Laufen habe und dort eine "schöne" GUI zur Verfügung steht.

Folgendes muss umgesetzt werden um das Jabber Modul wieder zum Laufen zu bekommen:
sudo apt-get remove libnet-xmpp-perl
sudo apt-get remove libxml-stream-perl

sudo apt-get install build-essential
wget http://ftp.de.debian.org/debian-archive/debian/pool/main/libn/libnet-xmpp-perl/libnet-xmpp-perl_1.02-3_all.deb
wget http://ftp.de.debian.org/debian/pool/main/libx/libxml-stream-perl/libxml-stream-perl_1.23-2_all.deb
sudo dpkg -i libxml-stream-perl_1.23-2_all.deb
sudo dpkg -i libnet-xmpp-perl_1.02-3_all.deb
sudo apt-get install libnet-jabber-perl


Thomas
Wenn der Container einmal läuft kannst Du das ja im Container mit einem Skript machen. Nach einem Upgrade des Basis Containers musst Du es nur leider jedes mal neu nachziehen.
Sauberer wäre es natürlich die Jabber Implementierung auf einen aktuelle Stand weiter zu entwickeln.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 09 April 2021, 13:58:26
Danke erst mal für eure Hinweise.

Ich glaube so langsam das es an der verwendeten Perl Version (5.28.1) liegt, Jabber, und auch mein alter Raspberry, liefen noch mit 5.24.
Ich schau mir das in einer ruhigen Minute mal an.

Gruß, Thomas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Inputsammler am 17 April 2021, 19:56:59
Hey Danke mal zusammen,

Habe nun erfolgreich FHEM mit 2 Instanzen laufen. Fhem0 und Fhem1.
docker run -d --name fhem0 -p 8083:8083 -v /Container/FHEM0/opt/fhem:/opt/fhem fhem/fhem
docker run -d --name fhem1 -p 8183:8083 -v /Container/FHEM1/opt/fhem:/opt/fhem fhem/fhem

Wollte  Homebridge wie bei meiner "normalen FHEM" zum laufen zu bringen bzw in meine Homekit integrieren.
Oder das Webinterface von Homebridge instalieren.

Aber leider komme ich nicht drauf wie ich es konfigurieren muss.
Anscheinend sehe ich den Wald vor lauter Bäume nicht.

Kann mich da einer bitte unterstützen ..

Danke

Gruß Gerd
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 17 April 2021, 20:01:51
Hallo Gerd,

einfach den Homebridge Container dazu.

Tipp: Nimm docker-compose ;) hier meine Notiz  (https://heinz-otto.blogspot.com/2021/01/container-schiff.html)dazu.


Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 27 April 2021, 08:46:04
Zitat von: ThomasMagnum am 09 April 2021, 13:06:56
Hallo Christian,

das habe ich per "docker exec -it FHEM /bin/bash" auf dem Containersystem gemacht.
Da hier erst aktuelle Module entfern und dann ältere Versionen installiert werden, komm ich mit Deinem YML File nicht klar bzw. kann das nicht umsetzen.
Zumal ich das auf einer Synology am Laufen habe und dort eine "schöne" GUI zur Verfügung steht.

Folgendes muss umgesetzt werden um das Jabber Modul wieder zum Laufen zu bekommen:
sudo apt-get remove libnet-xmpp-perl
sudo apt-get remove libxml-stream-perl

sudo apt-get install build-essential
wget http://ftp.de.debian.org/debian-archive/debian/pool/main/libn/libnet-xmpp-perl/libnet-xmpp-perl_1.02-3_all.deb
wget http://ftp.de.debian.org/debian/pool/main/libx/libxml-stream-perl/libxml-stream-perl_1.23-2_all.deb
sudo dpkg -i libxml-stream-perl_1.23-2_all.deb
sudo dpkg -i libnet-xmpp-perl_1.02-3_all.deb
sudo apt-get install libnet-jabber-perl


Thomas

Hallo,

leider bekomme ich es nicht hin die notwendigen Perl Module in der notwendigen Version zu installieren (s.o.).
Weitere Aktionen, wie zum Beispiel einen Container erstellen übersteigt leider meine Fähigkeiten.

@Loredo
Ist es möglich die entsprechenden Module in der funktionierenden Version bereits im Docker Container mit auszuliefern und gegen eine Aktualisierung zu sichern?
Ich würde mich sehr darüber freuen.
Da die Module ja nur für XMPP notwendig sind, spricht ja eigentlich nichts dagegen - oder?

Vielen Dank schon mal für die Hilfe.

Gruß, Thomas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 27 April 2021, 09:04:33
Zitat von: ThomasMagnum am 27 April 2021, 08:46:04
Hallo,

leider bekomme ich es nicht hin die notwendigen Perl Module in der notwendigen Version zu installieren (s.o.).
Weitere Aktionen, wie zum Beispiel einen Container erstellen übersteigt leider meine Fähigkeiten.


Du hast mehrere Befehle angegeben. Woran scheitert es. Fehlermeldungen, Logs, sonstige Ausgaben ... bei Fehler "geht nicht" ist es schwierig zu helfen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 27 April 2021, 09:11:18
Soweit ich weiß, werden in dem Container auch Module per CPAN installiert ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 28 April 2021, 07:30:16
Vielen Dank für eure Antworten.

1. Es kommen über die angegebenen Befehle keinerlei Fehlermeldungen, einzig es funktioniert nicht. Die Module habe auch noch die aktuellste Version und sind damit nicht geeignet zum Jabber Betrieb bzw. wurden nicht getauscht.

2. Wenn die Module im Container per cpan installiert werden, wie kann ich dann eine bstimmte Version finden bzw. diese installieren?
Ich habe hier schon auf https://metacpan.org (https://metacpan.org) geschaut, kann aber keine älteren Versionen finden.
Ich denke das ist auch der Grund warum im WiKi die Installation per dpkg beschrieben wird.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 28 April 2021, 07:41:13
Zitat von: ThomasMagnum am 28 April 2021, 07:30:16
Vielen Dank für eure Antworten.

1. Es kommen über die angegebenen Befehle keinerlei Fehlermeldungen, einzig es funktioniert nicht. Die Module habe auch noch die aktuellste Version und sind damit nicht geeignet zum Jabber Betrieb bzw. wurden nicht getauscht.

2. Wenn die Module im Container per cpan installiert werden, wie kann ich dann eine bstimmte Version finden bzw. diese installieren?
Ich habe hier schon auf https://metacpan.org (https://metacpan.org) geschaut, kann aber keine älteren Versionen finden.
Ich denke das ist auch der Grund warum im WiKi die Installation per dpkg beschrieben wird.

https://stackoverflow.com/questions/260593/how-can-i-install-a-specific-version-of-a-set-of-perl-modules
versuch doch einfach das entsprechend als Parameter für den Container anzugeben https://github.com/fhem/fhem-docker/#add-custom-packages
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 28 April 2021, 10:20:36
So, ich habe es nun hinbekommen die entsprechenden Module per cpan zu installieren.

install HACKER/Net-XMPP-1.02.tar.gz
install DAPATRICK/XML-Stream-1.23.tar.gz


hat direkt die notwendige Version installiert. Danke für die Hilfe.
Jabber läuft allerdings immer noch nicht, da frag ich aber mal im Modul Thread nach.

Gruß, Thomas
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thomasgloor am 19 Mai 2021, 17:08:28
Hallo Spezis!

Ich habe eine Standalone-FHEM-Installation (Raspi2, Buster, alles aktuell), welche ich auf einen neuen Raspi4 neu mit Docker umziehen möchte. Schwupediwup und fast alles läuft! GUI ist da, erreichbar via Traefik...

Riesendankeschön für die Erstellung des Images an den Ersteller!!!

Ein Problem bleibt... Funktioniert in der Stanalone-Version, wirft aber beim Docker Fehler...

Ich habe ein paar Datumsformatierungen so realisiert:

attr WZ_LampeMorgen userReadings myTimeOn {{use Time::Piece;;;;my $time = localtime->strptime(ReadingsVal($NAME,"timer_01_c01","01.01.1900 00:00"), "%d.%m.%Y %H:%M");;;; $time->strftime("%d.%m.%Y %H:%M");;;;}\
},\
myTimeOff {{use Time::Piece;;;;my $time = localtime->strptime(ReadingsVal($NAME,"timer_02_c01","01.01.1900 00:00"), "%d.%m.%Y %H:%M");;;; $time->strftime("%d.%m.%Y %H:%M");;;;}\
}


Das läuft auf dem alten Raspi, schmeisst aber auf dem neuen folgenden Fehler:
2021.05.19 16:32:38 1: Error evaluating WZ_LampeMorgen userReading myTimeOn: Error parsing time at /usr/lib/arm-linux-gnueabihf/perl/5.28/Time/Piece.pm line 583.
https://forum.fhem.de/Themes/fhem-curve-green/images/bbc/code.gif
Part aus dem compose.yml:
  fhem:
    container_name: fhem
    image: fhem/fhem
    restart: unless-stopped
    security_opt:
        - no-new-privileges
    networks:
      - t2_proxy       
    ports:
       - 8083:8083
    volumes:
      - $DOCKERDIR/fhem:/opt/fhem   
    environment:
      - LANG=en_US.UTF-8
      - LANGUAGE=en_US:en
      - LC_ALL=en_US.UTF-8
      - LC_ADDRESS=en_US.UTF-8
      - LC_MEASUREMENT=en_US.UTF-8
      - LC_MESSAGES=en_US.UTF-8
      - LC_MONETARY=en_US.UTF-8
      - LC_NAME=en_US.UTF-8
      - LC_NUMERIC=en_US.UTF-8
      - LC_PAPER=en_US.UTF-8
      - LC_TELEPHONE=en_US.UTF-8
      - LC_TIME=en_US.UTF-8
      - TZ=Europe/Zurich
      - DOCKER_HOST=172.17.0.1
      - DOCKER_GW=172.17.0.1
     
    labels: 
      - "traefik.enable=true"
#     - "traefik.http.routers.fhem-rtr.service=fhem-docker"
      - "traefik.http.routers.fhem-rtr.entrypoints=https"
      - "traefik.http.services.fhem.loadbalancer.server.port=8083"     
      - "traefik.http.routers.fhem-rtr.rule=Host(`fhem.$DOMAINNAME`)"
      - "traefik.http.routers.fhem-rtr.tls=true"
      - "traefik.http.routers.fhem-rtr.tls.certresolver=dns-cloudflare" # Comment out this line after first run of traefik to force the use of wildcard certs
      - "traefik.http.routers.fhem-rtr.tls.domains[0].main=$DOMAINNAME"
      - "traefik.http.routers.fhem-rtr.tls.domains[0].sans=*.$DOMAINNAME"


Perl-Version ist die Gleiche, das Piece.pm ist identisch...sprptime mag mich nicht mehr...

Woran könnte das liegen?


Gruss
Thomas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 19 Mai 2021, 17:59:02
Hi Thomas,

mal das probiert in der Kommandozeile in einem FHEM in dem gleichen Dockerimage
{use Time::Piece;;my $time = localtime->strptime("01.01.1900 00:00", "%d.%m.%Y %H:%M");; $time->strftime("%d.%m.%Y %H:%M")}

Funktioniert :)

In Deiner Codezeile ist viel unnützes, aber wenn das Raw Def Code ist, sollte der funktionieren. Probiere mal meine Zeile bei Dir, wenn die geht musst Du einfach ein paar {} und ; löschen - aber eigentlich sollte es daran nicht liegen.
Die Meldung kommt mir komisch vor
ZitatError parsing time at
wieso sucht er time kleingeschrieben?

Edit:
Was mich beunruhigt ist das Ergebnis:
13.12.1901 21:45
Bei älteren Systemen ist das mMn korrekt:
01.01.1900 00:00

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: thomasgloor am 20 Mai 2021, 22:04:26
Danke Otto!

Wo es letztendlich lag: vor Jahren vergessene von Hand generierte Readings, welche schlichtweg fehlten.... Die sind irgendwo bei der Migration liegengeblieben...

Dass localtime->strptime("01.01.1900 00:00", "%d.%m.%Y %H:%M") Müll liefert, ist sehr seltsam. Mit 1901 funktioniert es wie erwartet...

Gruss
Thomas


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 20 Mai 2021, 23:19:45
Hallo Thomas,

das erklärt zumindest Deine Fehlermeldung.  8) Die kann man so provozieren:
{use Time::Piece;;my $time = localtime->strptime("01.01.1890 00:00", "%d.%m.%Y %H:%M");; $time->strftime("%d.%m.%Y %H:%M")}

Gruß Otto
Titel: Offizielles FHEM Docker Basis Image für verschiedene Plattformen (neue Frage)
Beitrag von: blackfire am 26 Mai 2021, 13:10:11
Hallo,
habe als Hostsystem ein Server Ubuntu 20.04 und Docker installiert.
Von Docker habe ich das Image fhem/fhem:latest deploynt.

Fhem läuft!
wie kann ich jetzt Node.js Packages Updaten? von Fhem aus?
ein "update all" habe ich ausgeführt

hat einer eine Idee?




Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen (neue Frage)
Beitrag von: P.A.Trick am 26 Mai 2021, 13:18:45
Zitat von: blackfire am 26 Mai 2021, 13:10:11
Hallo,
habe als Hostsystem ein Server Ubuntu 20.04 und Docker installiert.
Von Docker habe ich das Image fhem/fhem:latest deploynt.

Fhem läuft!
wie kann ich jetzt Node.js Packages Updaten? von Fhem aus?
ein "update all" habe ich ausgeführt

hat einer eine Idee?

Nimm mal das "upgrade all"!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen (neue Frage)
Beitrag von: ch.eick am 26 Mai 2021, 13:22:18
Zitat von: blackfire am 26 Mai 2021, 13:10:11
Hallo,
habe als Hostsystem ein Server Ubuntu 20.04 und Docker installiert.
Von Docker habe ich das Image fhem/fhem:latest deploynt.

Fhem läuft!
wie kann ich jetzt Node.js Packages Updaten? von Fhem aus?
ein "update all" habe ich ausgeführt
Moin,
ich habe gerade auch den Fhem Container aktualisiert und anschließend Node.js, weil es rot war. Das hat zwar etwas gedauert, war dann jedoch okay. Kannst Du das Problem genauer beschreiben?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 Mai 2021, 13:28:05
Hallo zusammen,
ich bräuchte nochmal eine kleine Schulung zur Aktualisierung einzelner Docker Containern wenn man docker-compose verwendet.

Bisher habe ich das neue Image mit einem docker pull geholt, danach den Container gestoppt und dann bin ich mir unsicher.

Wie kann ich aus einer gemeinsamen docker-compose dann einen einzelnen Container aktualisieren lassen?
Wenn ich ein "docker image rm xxxxx" ist das alte Image weg, jedoch fehlt doch dann die neue Container definition.

Ich bitte um Erhellung
    Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 26 Mai 2021, 13:47:10
Zitat von: ch.eick am 26 Mai 2021, 13:28:05
Hallo zusammen,
ich bräuchte nochmal eine kleine Schulung zur Aktualisierung einzelner Docker Containern wenn man docker-compose verwendet.

Bisher habe ich das neue Image mit einem docker pull geholt, danach den Container gestoppt und dann bin ich mir unsicher.

Wie kann ich aus einer gemeinsamen docker-compose dann einen einzelnen Container aktualisieren lassen?
Wenn ich ein "docker image rm xxxxx" ist das alte Image weg, jedoch fehlt doch dann die neue Container definition.

Ich bitte um Erhellung
    Christian

Ich nutze dafür einen eigenen Container. Vielleicht ist das auch etwas für dich?

https://github.com/containrrr/watchtower (https://github.com/containrrr/watchtower)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 Mai 2021, 13:56:28
Zitat von: P.A.Trick am 26 Mai 2021, 13:47:10
Ich nutze dafür einen eigenen Container. Vielleicht ist das auch etwas für dich?

https://github.com/containrrr/watchtower (https://github.com/containrrr/watchtower)
Vielen Dank,
ich habe mal eben die Doku überflogen, verwendet das Tool die .yml Datei, die ich bereits definiert habe?
Das geht dann ja noch einige Schritte weiter, sieht aber sehr interessant aus.

VG
    Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 26 Mai 2021, 15:41:48
Zitat von: ch.eick am 26 Mai 2021, 13:28:05
Ich bitte um Erhellung
    Christian
Hi,

ich nutze zur Verwaltung Portainer :) und hab mir vor Wochen etwas aufgeschrieben: https://heinz-otto.blogspot.com/2021/01/container-schiff.html

Aber das Prinzip ist simpler als gedacht:
* das aktuelles Image laden (docker image pull <name> )
* dann docker-compose up -d -> macht den einzelnen neu ohne die anderen zu "berühren"!

Müllabfuhr:
docker image ls
docker image rm name # oder
docker image prune


Alle Befehle abgeschlossen mit --help geben Auskunft :)

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 Mai 2021, 15:58:44
Zitat von: ch.eick am 26 Mai 2021, 13:28:05
Hallo zusammen,
ich bräuchte nochmal eine kleine Schulung zur Aktualisierung einzelner Docker Containern wenn man docker-compose verwendet.

Bisher habe ich das neue Image mit einem docker pull geholt, danach den Container gestoppt und dann bin ich mir unsicher.

Wie kann ich aus einer gemeinsamen docker-compose dann einen einzelnen Container aktualisieren lassen?
Wenn ich ein "docker image rm xxxxx" ist das alte Image weg, jedoch fehlt doch dann die neue Container definition.

Ich bitte um Erhellung
    Christian

Alle im docker-compose file

docker-compose pull  && docker-compose up -d      ..... optional noch ein "--remove-orphans" damit werden container gelöscht die nicht mehr in docker-compose enthalten sind


Ansonsten für einzelne

docker pull <image> && docker-compose up -d


Was meionst du mit der Container defintion, die Config ist im Docker-Compose-File, das Image pullst du

Edit, Otto hat parallel geantwortet ... lies dir mal alles durch und frage wenn noch was fehlt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 26 Mai 2021, 16:57:10
Ich muß gestehen, das ich immer Pro "Projekt" eine docker-compose.yml verwende. Wenn ich mal in einem "projekt" ein Container updaten muß, restarte ich immer das komplette Projekt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen (neue Frage)
Beitrag von: blackfire am 26 Mai 2021, 17:19:24
Zitat von: P.A.Trick am 26 Mai 2021, 13:18:45
Nimm mal das "upgrade all"!

Hallo,

wie hast Du Dein "upgrade" durchgeführt? Hast du eine kurze Anleitung für mich?

hast Du das über Fhem bzw. Terminal oder doch über Portainer gemacht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 26 Mai 2021, 17:27:36
Zitat von: ch.eick am 26 Mai 2021, 13:56:28
Vielen Dank,
ich habe mal eben die Doku überflogen, verwendet das Tool die .yml Datei, die ich bereits definiert habe?
Das geht dann ja noch einige Schritte weiter, sieht aber sehr interessant aus.

VG
    Christian

Kannst du einfach in deine docker-compose.yml hinzufügen. Beispiel findest du hier: https://github.com/stormmurdoc/fhemdocker/blob/master/docker-compose.yml (https://github.com/stormmurdoc/fhemdocker/blob/master/docker-compose.yml)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen (neue Frage)
Beitrag von: P.A.Trick am 26 Mai 2021, 18:04:50
Zitat von: blackfire am 26 Mai 2021, 17:19:24
Hallo,

wie hast Du Dein "upgrade" durchgeführt? Hast du eine kurze Anleitung für mich?

hast Du das über Fhem bzw. Terminal oder doch über Portainer gemacht?

In FHEM über den folgenden Befehl:

set fhemServerNpm upgrade all
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: blackfire am 26 Mai 2021, 18:47:50
Danke,

diesen Befehl habe ich gesucht!

bin halt noch Anfänger  ::)

Das System Update mit dem Debian Logo brauche ich nicht? "unter Docker Container bzw. Ubuntu"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 26 Mai 2021, 18:50:11
Zitat von: blackfire am 26 Mai 2021, 18:47:50
Danke,

diesen Befehl habe ich gesucht!

bin halt noch Anfänger  ::)

Das System Update mit dem Debian Logo brauche ich nicht? "unter Docker Container bzw. Ubuntu"
Doch wenn der Container lange läuft und es ein OS Update gibt. Dieser Container ist halt ein Kompromiss!
Also wenn rot, einfach updaten. Ich habe mir ein DOIF darauf gesetzt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: blackfire am 26 Mai 2021, 18:55:37
Ok, dann werde ich das mal versuchen! Danke für Deine Hilfe!

Gibt es hierfür auch einen bestimmten Befehl? (System Update)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 26 Mai 2021, 19:06:11
Zitat von: blackfire am 26 Mai 2021, 18:55:37
Ok, dann werde ich das mal versuchen! Danke für Deine Hilfe!

Gibt es hierfür auch einen bestimmten Befehl? (System Update)

Ja entweder auf das Icon klicken oder analog zum npm

set fhemServerApt repoSync
und dann wenn Updates vorhanden sind
set fhemServerApt toUpgrade

Schaue doch einfach mal ein die Doku. Dort ist alles beschrieben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: blackfire am 26 Mai 2021, 19:19:12
Doku ist das Stichwort  ;)
https://fhem.de/commandref_DE.html

Trotzdem Danke  :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 26 Mai 2021, 19:59:47
Zitat von: P.A.Trick am 26 Mai 2021, 18:50:11
Dieser Container ist halt ein Kompromiss!
Aber einer der sehr guten!!!  ;D ;D ;D
👏👏👏
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: JF Mennedy am 28 Mai 2021, 12:07:58
Hallo,

ich habe mich mal auf die Docker-Installation eingelassen. Der Container läuft zur Zeit auf einem UnRaid-Server. Die Migration war recht einfach und anfänglich läuft das System auch sehr gut und wesentlich performanter als zuvor auf einer VM.

Jetzt kommt das dicke Problem. Sobald ich meine Konfiguration lade, ist das Sytem ist unhealty. Telnet 7072 ist definiert und auch aus einer Konsole ansprechbar (kann auch Geräte über die Konsole schalten). Hinzukommt, dass die RAM auslastung permanent steigt, bis dann irgendwann der ganze PC streikt. Dann hilft nur noch in UnRaid das Array zu stoppen und neu zu starten. Wenn ich im Docker mit ps -eaf die Prozesse abfrage, habe ich eine elend lange Auflistung von Prozessen mit /bin/bash /health-check.sh (siehe im Screenshot Anhang)...

Wie bekomme ich bloss mein System healthy? Mit der Original fhem.cfg Ist alles ok. Erst, wenn ich meine Konfiguration lade, streikt der Health-check...

Solange ich das noch nicht sauber laufen habe, bringt es nichts, mich damit auseinanderzusetzen, wie das mit dem Backup bewerkstellige, so dass ich nicht immer wieder von vorne anfangen muss, npm und perl-Pakete nachzuladen bzw. upzudaten...

Wenn mir jemand weiterhelfen kann, wäre ich sehr dankbar...

Gruss Jan

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 28 Mai 2021, 13:12:50
Zitat von: JF Mennedy am 28 Mai 2021, 12:07:58
Solange ich das noch nicht sauber laufen habe, bringt es nichts, mich damit auseinanderzusetzen, wie das mit dem Backup bewerkstellige, so dass ich nicht immer wieder von vorne anfangen muss, npm und perl-Pakete nachzuladen bzw. upzudaten...
Die werden im .yml File direkt bei der Container Konfiguration angegeben.
Dadurch dauert natülich der erste Start des Containers länger, weil die Spezial Pakete nachinstalliert werden, anschließend sollte der Start aber dann schneller gehen.

Ein Beispiel:

  fhem:
    image: fhem/fhem:latest
    restart: always
    network_mode: host
    privileged: true
#    devices:
#      - "/dev/ttyACM0:/dev/ttyACM0"               <<<<< den brauche ich in einem anderen Container
    volumes:
      - "./core/:/opt/fhem/"
    environment:
      PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"            <<<<<< hier sind die Nachinstallationen einmal für pip und einmal für cpan
      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare XML::Bare Protocol::WebSocket::Handshake::Server Crypt::Rijndael Crypt::Random --verbose"
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
#      CONFIGTYPE: configDB     <<<< das verwende ich nicht
    depends_on:
      - "mysql"

Wärend der Nachinstallation war mein Container auch länger unhealty.

Gruß
     Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: JF Mennedy am 28 Mai 2021, 13:39:39
Zitat von: JF Mennedy am 28 Mai 2021, 12:07:58
Hallo,

ich habe mich mal auf die Docker-Installation eingelassen. Der Container läuft zur Zeit auf einem UnRaid-Server. Die Migration war recht einfach und anfänglich läuft das System auch sehr gut und wesentlich performanter als zuvor auf einer VM.

Jetzt kommt das dicke Problem. Sobald ich meine Konfiguration lade, ist das Sytem ist unhealty. Telnet 7072 ist definiert und auch aus einer Konsole ansprechbar (kann auch Geräte über die Konsole schalten). Hinzukommt, dass die RAM auslastung permanent steigt, bis dann irgendwann der ganze PC streikt. Dann hilft nur noch in UnRaid das Array zu stoppen und neu zu starten. Wenn ich im Docker mit ps -eaf die Prozesse abfrage, habe ich eine elend lange Auflistung von Prozessen mit /bin/bash /health-check.sh (siehe im Screenshot Anhang)...

Wie bekomme ich bloss mein System healthy? Mit der Original fhem.cfg Ist alles ok. Erst, wenn ich meine Konfiguration lade, streikt der Health-check...

Solange ich das noch nicht sauber laufen habe, bringt es nichts, mich damit auseinanderzusetzen, wie das mit dem Backup bewerkstellige, so dass ich nicht immer wieder von vorne anfangen muss, npm und perl-Pakete nachzuladen bzw. upzudaten...

Wenn mir jemand weiterhelfen kann, wäre ich sehr dankbar...

Gruss Jan


Ok Ok Ok.. Schande über mein Haupt... Die Nächte waren zu lange und meine Augen doof... Wer lesen kann ist klar im Vorteil...  :o

ZitatIf for whatever reason you want to disable checking a specific FHEMWEB instance, you may set the user attribute DockerHealthCheck to 0 on that particular FHEMWEB device.

Alles grün jetzt und auch der RAM bleibt ok.. Keine Ahnung was ich da vorher verbockt habe.. Habe noch mal alles neu aufgesetzt...

Gibt es für Newbies im Bereich Docker irgendwo eine gute Doku/Anleitung, wie ich mein Image z.B. in Github ablege?

Gruss Jan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 28 Mai 2021, 13:52:26
Zitat von: JF Mennedy am 28 Mai 2021, 13:39:39
Gibt es für Newbies im Bereich Docker irgendwo eine gute Doku/Anleitung, wie ich mein Image z.B. in Github ablege?
Was willst Du denn an dem Image verändern, da ist doch nahezu alles drin.
pip und cpan hatte ich ja schon geschrieben.

Deine FHEM Konfig ist ja lokal und wird bei einem Image update ja nicht überschrieben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: JF Mennedy am 28 Mai 2021, 14:17:09
Ja das ist schon richtig, dass es ziemlich komplett ist, für g-assistant z.b. muss ich aber jedes mal ein Update machen..

Ist halt komplett neu für mich. Vielleicht mach ich mir auch zu viel Stress ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 28 Mai 2021, 14:50:07
Zitat von: JF Mennedy am 28 Mai 2021, 14:17:09
Ja das ist schon richtig, dass es ziemlich komplett ist, für g-assistant z.b. muss ich aber jedes mal ein Update machen..

Was ist das für ein update?
pip oder cpan wird beim Start des Containers gemacht.

Danach mache ich die updates im Fhem, die nach dem erstellen des Containers gekommen sind

System
Docker Image Info
Update
FHEM Installer Status
Node.js Package Update Status
System Update Status

Auch das kann wohl automatisiert werden, was ich jedoch noch nicht gemacht habe, weil ich lieber am System bin wenn es aktualisiert wird ;-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: JF Mennedy am 28 Mai 2021, 15:19:42
Das ist das npm update, welches durchgeführt werden muss. Ich habe gerade auch für Velux KLF noch ein paar perl module nachinstalliert, da das Modul disconnected geblieben ist (IO::Socket::SSL, Net::SSL, Net::SSLeay, Net::SSLeay::Handle, Crypt::SSLeay, Net::Server::Proto::SSL), Danach war das Velux auch wieder online...

Ich werde mich da mal weiter einlesen und rufe noch mal nach Hilfe, wenn ich nicht weiterkommen sollte ;-)

Gruss Jan
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 28 Mai 2021, 15:25:36
Zitat von: JF Mennedy am 28 Mai 2021, 15:19:42
Das ist das npm update, welches durchgeführt werden muss. Ich habe gerade auch für Velux KLF noch ein paar perl module nachinstalliert, da das Modul disconnected geblieben ist (IO::Socket::SSL, Net::SSL, Net::SSLeay, Net::SSLeay::Handle, Crypt::SSLeay, Net::Server::Proto::SSL), Danach war das Velux auch wieder online...
Wie hier https://forum.fhem.de/index.php/topic,89745.msg1159595.html#msg1159595 geschrieben kann man das bei der Erstellung des Containers angeben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: JF Mennedy am 28 Mai 2021, 15:36:31
Danke für den Hinweis :-) Werde ich mir später anschauen... Muss jetzt die Kinder abholen und danach wird wohl erstmal nix mit weiterbauen, bis sie im Bett sind ;-)

EDIT: Vielen lieben Dank, der Container läuft seit ein Tagen sauber.. Heute habe ich noch das Installieren von Modulen mit eingepflegt, und alles funktioniert, wie es soll :-)

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 07 Juni 2021, 14:08:15
Hallo zusammen,
mich beschäftigt immer wieder ein Phyton Problem im FHEM Docker Container, das vor dem update des Containers schon stabiel gelaufen ist.
Im Buster auf dem RPI funktioniert es auch immer noch!

Nativ im Buster

fhem@raspberrypi:~/python/bin$ pip3 install vallox-websocket-api
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Requirement already satisfied: vallox-websocket-api in /mnt/ssd/home/pi/docker-compose/fhem_2021/core/.local/lib/python3.7/site-packages (2.6.0)
Requirement already satisfied: construct<3.0.0,>=2.9.0 in /usr/local/lib/python3.7/dist-packages (from vallox-websocket-api) (2.9.45)
Requirement already satisfied: websockets<9.0,>=7.0 in /usr/local/lib/python3.7/dist-packages (from vallox-websocket-api) (7.0)
fhem@raspberrypi:~/python/bin$ /usr/bin/python3 -V
Python 3.7.3

fhem@raspberrypi:~/python/bin$ /usr/bin/python3 ./kwl_status.py 192.168.178.11 192.168.178.40
>>>>> Das Skript fragt die KWL ab und sendet einen JSON String an FHEM


Nun im Docker mit dem aktuellen FHEM Container

root@raspberrypi:/opt/fhem# pip3 install vallox-websocket-api
Requirement already satisfied: vallox-websocket-api in /usr/local/lib/python3.7/dist-packages (2.6.0)
Requirement already satisfied: construct<3.0.0,>=2.9.0 in /usr/local/lib/python3.7/dist-packages (from vallox-websocket-api) (2.10.67)
Requirement already satisfied: websockets<9.0,>=7.0 in /usr/local/lib/python3.7/dist-packages (from vallox-websocket-api) (8.1)
root@raspberrypi:/opt/fhem# /usr/bin/python3 -V
Python 3.7.3

root@raspberrypi:/opt/fhem# /usr/bin/python3 /opt/fhem/python/bin/kwl_status.py 192.168.178.11 192.168.178.40
Traceback (most recent call last):
  File "/opt/fhem/python/bin/kwl_status.py", line 7, in <module>
    from vallox_websocket_api import Client
  File "/usr/local/lib/python3.7/dist-packages/vallox_websocket_api/__init__.py", line 1, in <module>
    from .client import Client
  File "/usr/local/lib/python3.7/dist-packages/vallox_websocket_api/client.py", line 7, in <module>
    from .messages import (LogReadRequest, LogReadResponse1, LogReadResponse2,
  File "/usr/local/lib/python3.7/dist-packages/vallox_websocket_api/messages.py", line 92, in <module>
    Struct("id" / LogItemId, "date" / DateAdapter(Bytes(5)), "value" / Int16ul)
  File "/usr/local/lib/python3.7/dist-packages/construct/core.py", line 444, in compile
    module = importlib.util.module_from_spec(module_spec)
AttributeError: module 'importlib' has no attribute 'util'

Leider kann ich mit meinen Kenntnissen das Problem nicht beseitigen, obwohl ich auch schon im Netz gesucht habe, es jedoch nicht verstehe.
Die aktuelleren Versionen von "construct" und "websockets" wären für mich denkbar.

Wie geschrieben, hat es bis vor dem Container update gelaufen.

.yml

  fhem:
    image: fhem/fhem:latest
    restart: always
    network_mode: host
    privileged: true
    volumes:
      - "./core/:/opt/fhem/"
    environment:
      PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"   <<< Das habe ich nicht verändert und ist so noch von vor dem update des Containers

      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare XML::Bare Protocol::WebSocket::Handshake::Server Crypt::Rijndael Crypt::Random --verbose"
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
    depends_on:
      - "mysql"


VG
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 07 Juni 2021, 17:21:07
das ist ein reiner python fehler. Was genau installierst du überhaupt, und was meinst du mit "das vor dem update des Containers schon stabil gelaufen ist"

Baust du den Container grad neu, oder was bezweckst du? Kannst du den Container verwerfen und die Schritte wiederholen? Ich gehe davon aus, dass es eine Vorraussetzung eines Fhem-Moduls ist und du nach einer Anleitung irgendwo in der Commandraf oder Wiki vorgehst. Du könntest mal im Forumteil "kwl_status.py" wenn es dazu ein Fhem-Modul gibt nachfragen.

Im Fhem-Modul auf Device-Specific-Help klicken, dann siehst du wo am besten zu posten ist.

Edit: du hast ein system das geht, eines das nichgt geht. Mit Befehl unten kannst du mal die Python Module vergleichen, vielleicht siehst du da was, ein fehlendes Modul oder eine andere Version. Könnte bei der Suche helfen


pip3 list
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 07 Juni 2021, 18:33:16
Zitat von: kadettilac89 am 07 Juni 2021, 17:21:07
das ist ein reiner python fehler. Was genau installierst du überhaupt, und was meinst du mit "das vor dem update des Containers schon stabil gelaufen ist"

Baust du den Container grad neu, oder was bezweckst du? Kannst du den Container verwerfen und die Schritte wiederholen? Ich gehe davon aus, dass es eine Vorraussetzung eines Fhem-Moduls ist und du nach einer Anleitung irgendwo in der Commandraf oder Wiki vorgehst. Du könntest mal im Forumteil "kwl_status.py" wenn es dazu ein Fhem-Modul gibt nachfragen.

Im Fhem-Modul auf Device-Specific-Help klicken, dann siehst du wo am besten zu posten ist.

Edit: du hast ein system das geht, eines das nicht geht. Mit Befehl unten kannst du mal die Python Module vergleichen, vielleicht siehst du da was, ein fehlendes Modul oder eine andere Version. Könnte bei der Suche helfen
Es handelt sich um ein Phyton Skript, das mit dem Modul vallox-websocket-api mit einer KWL kommuniziert. Mit dem Phyton Modul "fhem" wird das JSON Ergebnis ins FHEM übergeben. Also alles Phyton!
Ich hatte einen Docker FHEM Container, der das alles bis zum letzten Container Update fehlerfrei betrieben hat.
Die Phyton Module habe ich wie im .yml File zu finden nachinstalliert. Hier wurde auch nichts geändert und die Module sind auch nicht aktueller geworden.
Somit ist mein Rückschluss, dass im Docker FHEM Container irgend etwas anders geworden ist.

Auf dem RPI läuft Buster und dort funktioniert es auch noch.

Zitat
Edit: du hast ein system das geht, eines das nicht geht. Mit Befehl unten kannst du mal die Python Module vergleichen, vielleicht siehst du da was, ein fehlendes Modul oder eine andere Version. Könnte bei der Suche helfen
Okay, was ich sehen kann ist, dass es im Container aktuellere Phyton Module gibt.

Dies habe ich im .yml konfiguriert

PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"

Die Kommunikation geht über websockets

Und das wird importiert

import fhem
import json
import asyncio
from vallox_websocket_api import Client

import sys
...


Phyton im FHEM Container, hier läuft es nicht

pip3 list
Package              Version 
-------------------- ---------
beautifulsoup4       4.9.3 
vallox-websocket-api 2.6.0   
fhem                 0.6.5   

websockets           8.1   
 
certifi              2018.8.24
chardet              3.0.4   
construct            2.10.67 
idna                 2.6     
ifaddr               0.1.6   
pip                  18.1     
protobuf             3.6.1   
PyChromecast         2.4.0   
requests             2.21.0   
setuptools           40.8.0   
six                  1.12.0   
soupsieve            2.2.1   
speedtest-cli        2.0.2   
urllib3              1.24.1   
wheel                0.32.3   
youtube-dl           2019.1.17
zeroconf             0.21.3


Phyton im Buster, hier läuft es noch

$ pip3 list
Package              Version   
-------------------- -----------
beautifulsoup4       4.9.3     
vallox-websocket-api 2.6.0   
fhem                 0.6.5     
websockets           7.0   

websocket-client     0.53.0     

appdirs              1.4.3     
asn1crypto           0.24.0     
astroid              2.1.0     
asttokens            1.1.13     
automationhat        0.2.0     
blinker              1.4       
blinkt               0.1.2     
buttonshim           0.0.2     
cached-property      1.5.1     
Cap1xxx              0.1.3     
certifi              2018.8.24 
chardet              3.0.4     
Click                7.0       
colorama             0.3.7     
colorzero            1.1       
construct            2.9.45     
cookies              2.2.1     
cryptography         2.6.1     
cupshelpers          1.0       
cycler               0.10.0     
decorator            4.3.0     
distro               1.3.0     
docker               3.4.1     
docker-compose       1.21.0     
docker-pycreds       0.3.0     
dockerpty            0.4.1     
docopt               0.6.2     
docutils             0.14       
drumhat              0.1.0     
entrypoints          0.3       
envirophat           1.0.0     
ExplorerHAT          0.4.2     
Flask                1.0.2     
fourletterphat       0.1.0     
gpiozero             1.5.1     
guizero              0.6.0     
html5lib             1.0.1     
idna                 2.6       
ipykernel            4.9.0     
ipython              5.8.0     
ipython-genutils     0.2.0     
isort                4.3.4     
itsdangerous         0.24       
jedi                 0.13.2     
Jinja2               2.10       
jsonschema           2.6.0     
jupyter-client       5.2.3     
jupyter-core         4.4.0     
keyring              17.1.1     
keyrings.alt         3.1.1     
kiwisolver           1.0.1     
lazy-object-proxy    1.3.1     
logilab-common       1.4.2     
lxml                 4.3.2     
MarkupSafe           1.1.0     
matplotlib           3.0.2     
mccabe               0.6.1     
microdotphat         0.2.1     
mote                 0.0.4     
motephat             0.0.3     
mypy                 0.670     
mypy-extensions      0.4.1     
nudatus              0.0.4     
numpy                1.16.2     
oauthlib             2.1.0     
olefile              0.46       
pantilthat           0.0.7     
parso                0.3.1     
pexpect              4.6.0     
pgzero               1.2       
phatbeat             0.1.1     
pianohat             0.1.0     
picamera             1.13       
pickleshare          0.7.5     
picraft              1.0       
piglow               1.2.5     
pigpio               1.78       
Pillow               5.4.1     
pip                  18.1       
prompt-toolkit       1.0.15     
psutil               5.5.1     
pycairo              1.16.2     
pycodestyle          2.4.0     
pycrypto             2.6.1     
pycryptodome         3.9.7     
pycups               1.9.73     
pyflakes             2.0.0     
pygame               1.9.4.post1
Pygments             2.3.1     
PyGObject            3.30.4     
pyinotify            0.9.6     
PyJWT                1.7.0     
pylint               2.2.2     
pyOpenSSL            19.0.0     
pyparsing            2.2.0     
pyserial             3.4       
pysmbc               1.0.15.6   
python-apt           1.8.4.3   
python-dateutil      2.7.3     
pyxdg                0.25       
PyYAML               3.13       
pyzmq                17.1.2     
qtconsole            4.3.1     
rainbowhat           0.1.0     
reportlab            3.5.13     
requests             2.21.0     
requests-oauthlib    1.0.0     
responses            0.9.0     
roman                2.0.0     
RPi.GPIO             0.7.0     
RTIMULib             7.2.1     
scrollphat           0.0.7     
scrollphathd         1.2.1     
SecretStorage        2.3.1     
semver               2.0.1     
Send2Trash           1.5.0     
sense-emu            1.1       
sense-hat            2.2.0     
setuptools           40.8.0     
simplegeneric        0.8.1     
simplejson           3.16.0     
six                  1.12.0     
skywriter            0.0.7     
sn3218               1.2.7     
soupsieve            1.8       
spidev               3.4       
ssh-import-id        5.7       
texttable            1.6.0     
thonny               3.3.6     
tornado              5.1.1     
touchphat            0.0.1     
traitlets            4.3.2     
twython              3.7.0     
typed-ast            1.3.1     
uflash               1.2.4     
unicornhathd         0.0.4     
urllib3              1.24.1     
wcwidth              0.1.7     
webencodings         0.5.1     
Werkzeug             0.14.1     
wheel                0.32.3     
wrapt                1.10.11
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 07 Juni 2021, 18:53:11
Zitat von: ch.eick am 07 Juni 2021, 18:33:16
Ich hatte einen Docker FHEM Container, der das alles bis zum letzten Container Update fehlerfrei betrieben hat.
Welches Update meinst du? docker pull fhem/fhem:latest wurde seit 7 Monaten nicht mehr geändert.

Ich würde zum Test mal die ganzen Modulversionen installieren die auch auf dem funktionierenden System sind, als erstes das websockets. Vorher natürlich ein Backup damit du zurück kannst solltest du dir was zerschießen.

Damit müsste es gehen. Ggf. mit pip3 statt pip.

pip install 'websockets==7.0' --force-reinstall
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 07 Juni 2021, 19:07:26
Zitat von: kadettilac89 am 07 Juni 2021, 18:53:11
Welches Update meinst du? docker pull fhem/fhem:latest wurde seit 7 Monaten nicht mehr geändert.
Das war der aktuelle für mich :-) , der ältere war von 2019 und da dachte ich mir ein Update wäre mal fällig. Alles andere hat auch auf anhieb funktioniert.

Zitat
Ich würde zum Test mal die ganzen Modulversionen installieren die auch auf dem funktionierenden System sind, als erstes das websockets. Vorher natürlich ein Backup damit du zurück kannst solltest du dir was zerschießen.
Bei Docker wäre das ja einfach ein neuer FHEM Container, in dem ich dann das Pyhton testen kann wie ich will. Wenn es kaput getestet ist kann ich den doch einfach wieder löschen.

Zitat
Damit müsste es gehen. Ggf. mit pip3 statt pip.

pip install 'websockets==7.0' --force-reinstall

Na das ist ein Plan, aber dann kann ich den FHEM Container ja so nicht mehr verwenden :-(

Die reine Statusabfrage ginge ja auch mit einem cron Eintrag direkt im Buster, jedoch müsste ich mir dann für das Setzen von Werten in der KWL wieder einen neuen Mechanismus bauen.
Dafür habe ich ja auch noch Skripte, die ich jetzt aus dem FHEM mit system() aufrufe.

Hach ist das immer alles schwierig :-) :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 07 Juni 2021, 19:18:46
Zitat von: ch.eick am 07 Juni 2021, 19:07:26
Na das ist ein Plan, aber dann kann ich den FHEM Container ja so nicht mehr verwenden :-(
Warum, verstehe ich nicht. Benötigt Fhem eine aktuellere Version als 7?

1) gib mal die Anleitung oder Schritte was zu tun ist um den Fehler zu bekommen. Beginnend von einem nackten, neuen Container

2) es gibt einen DEV-Container. Teste den mal vielleicht ist da zufällig was geändert was dir hilft, fhem/fhem:dev
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 07 Juni 2021, 21:26:14
Zitat von: kadettilac89 am 07 Juni 2021, 19:18:46
Warum, verstehe ich nicht. Benötigt Fhem eine aktuellere Version als 7?

1) gib mal die Anleitung oder Schritte was zu tun ist um den Fehler zu bekommen. Beginnend von einem nackten, neuen Container

2) es gibt einen DEV-Container. Teste den mal vielleicht ist da zufällig was geändert was dir hilft, fhem/fhem:dev
Ich melde mich wieder...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: cc13 am 02 Juli 2021, 11:10:02
Hi,

meine Docker-fhem Umgebung rennt aktuell in einen E500 outdated Fehler im npm paket. Ich bin jetzt die 82 Seiten durch, habe auch schon die fhem-docker in /etc/sudoers.d/ nach Hinweisen aus diesem Thread erweitert, bekomme die Fehlermeldung leider nicht weg.

Folgendes bringt ein Raw-Definition:


defmod fhemServerNpm npmjs localhost
attr fhemServerNpm alias Node.js Package Update Status
attr fhemServerNpm devStateIcon npm.updates.available:security@red:outdated npm.is.up.to.date:security@green:outdated .*npm.outdated.*in.progress:system_fhem_reboot@orange .*in.progress:system_fhem_update@orange warning.*:message_attention@orange error.*:message_attention@red
attr fhemServerNpm group Update
attr fhemServerNpm icon npm-old
attr fhemServerNpm room System

setstate fhemServerNpm error 'outdated'
setstate fhemServerNpm 2021-07-02 10:28:46 .installedList {"versions":{"unicode":"12.1","openssl":"1.1.1k","node":"10.24.1","cldr":"35.1","nghttp2":"1.41.0","uv":"1.34.2","v8":"6.8.275.32-node.59","http_parser":"2.9.4","ares":"1.15.0","modules":"64","brotli":"1.0.7","tz":"2019c","napi":"7","icu":"64.2","zlib":"1.2.11"}}
setstate fhemServerNpm 2021-07-02 10:50:18 .packageList {"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: not foun...\") at ./FHEM/42_npmjs.pm line 1168.\n","detail":"<pre>{\n\"versions\": \n{\"http_parser\":\"2.9.4\",\"node\":\"10.24.1\",\"v8\":\"6.8.275.32-node.59\",\"uv\":\"1.34.2\",\"zlib\":\"1.2.11\",\"brotli\":\"1.0.7\",\"ares\":\"1.15.0\",\"modules\":\"64\",\"nghttp2\":\"1.41.0\",\"napi\":\"7\",\"openssl\":\"1.1.1k\",\"icu\":\"64.2\",\"unicode\":\"12.1\",\"cldr\":\"35.1\",\"tz\":\"2019c\"}\n, \"outdated\": sh: 2: npm: not found\n}\n</pre>"}}
setstate fhemServerNpm 2021-05-02 11:51:28 .updatedList {}
setstate fhemServerNpm 2021-07-02 10:28:46 installed successful
setstate fhemServerNpm 2021-04-28 14:46:31 nodejsVersion 10.24.1
setstate fhemServerNpm 2021-07-02 10:50:18 outdated check failed
setstate fhemServerNpm 2021-07-02 10:50:18 state error 'outdated'
setstate fhemServerNpm 2021-05-02 11:51:28 updated successful
setstate fhemServerNpm 2021-05-02 11:51:29 updatesAvailable 0


Ein "get fhemServer Npm showErrorList" zeigt:


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: not foun...") at ./FHEM/42_npmjs.pm line 1168.
Detail:

{
"versions":
{"http_parser":"2.9.4","node":"10.24.1","v8":"6.8.275.32-node.59","uv":"1.34.2","zlib":"1.2.11","brotli":"1.0.7","ares":"1.15.0","modules":"64","nghttp2":"1.41.0","napi":"7","openssl":"1.1.1k","icu":"64.2","unicode":"12.1","cldr":"35.1","tz":"2019c"}
, "outdated": sh: 2: npm: not found
}


Alles läuft auf einem RPi4, DietPi und eben Docker. Habt ihr eine Idee, was ich noch machen kann?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 02 Juli 2021, 11:59:03
Hi cc13,

bei mir stand in der Fehlermeldung ich soll `npm install -g npm@7.19.1` ausführen - getan, dann upgrade gemacht :( 
Hab jetzt repariert - dank Container geht das ja fix
docker-compose rm -s fhem
docker-compose up -d

Dann noch den alten Fehler weg
set fhemServerNpm outdated
Und jetzt erstmal die Finger von npm lassen :)

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 02 Juli 2021, 18:50:56
Zitat von: cc13 am 02 Juli 2021, 11:10:02

Alles läuft auf einem RPi4, DietPi und eben Docker. Habt ihr eine Idee, was ich noch machen kann?

Sieht nach dem selben Fehler aus. https://forum.fhem.de/index.php/topic,89745.msg1000286.html#msg1000286

Du könntest mal den dev-Zweig testen. Und ggf. die npm-Pakete im Docker-Compose mit angeben. Dann wird beim ersten Einrichten schon mal aktuallisiert.

Ich meine so in etwa, s.u. (nur die relevanten Parameter kopiert). Müsste eigentlich auch anders gehen, aber ich habe mir das so eingerichtet und die npm-Updates funktionieren damit auch. Hatte da auch mal ein Problem und habe es für mich so gelöst. Vielleicht nicht die eleganteste Lösung aber es läuft.

Ich  habe aber auch keinen RPi sondern ein NUC (normale Intel CPU).


    fhem:
        image: fhem/fhem:dev
        container_name: fhem 
        environment:
            NPM_PKGS: "npm@7.18.1 gassistant-fhem"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: cc13 am 05 Juli 2021, 15:01:40
Zitat von: Otto123 am 02 Juli 2021, 11:59:03
Hi cc13,

bei mir stand in der Fehlermeldung ich soll `npm install -g npm@7.19.1` ausführen - getan, dann upgrade gemacht :( 
Hab jetzt repariert - dank Container geht das ja fix
docker-compose rm -s fhem
docker-compose up -d

Dann noch den alten Fehler weg
set fhemServerNpm outdated
Und jetzt erstmal die Finger von npm lassen :)

Gruß Otto

Ich habe den Container neu angelegt, gestartet und nach

set fhemServerNpm outdated

und ein paar mal

set update/upgrade

ist jetzt alles grün. So richtig schlüssig war es für mich nicht, aber solange es das gewünschte Ergebnis bringt. ;-)

Danke Otto!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: cc13 am 05 Juli 2021, 15:02:30
Zitat von: kadettilac89 am 02 Juli 2021, 18:50:56
Sieht nach dem selben Fehler aus. https://forum.fhem.de/index.php/topic,89745.msg1000286.html#msg1000286

Du könntest mal den dev-Zweig testen. Und ggf. die npm-Pakete im Docker-Compose mit angeben. Dann wird beim ersten Einrichten schon mal aktuallisiert.

Ich meine so in etwa, s.u. (nur die relevanten Parameter kopiert). Müsste eigentlich auch anders gehen, aber ich habe mir das so eingerichtet und die npm-Updates funktionieren damit auch. Hatte da auch mal ein Problem und habe es für mich so gelöst. Vielleicht nicht die eleganteste Lösung aber es läuft.

Ich  habe aber auch keinen RPi sondern ein NUC (normale Intel CPU).


    fhem:
        image: fhem/fhem:dev
        container_name: fhem 
        environment:
            NPM_PKGS: "npm@7.18.1 gassistant-fhem"


Das werde ich die Tage mal in einem anderen Container probieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 05 Juli 2021, 16:22:04
Zitat 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

Dieser Weg hatte bei mir leider nicht funktioniert, daher hier meine Vorgehensweise, falls auch jemand ein USB-Device an der Syno an einen Docker-Container weiterreichen möchte:
https://forum.fhem.de/index.php/topic,51948.msg1165411.html#msg1165411

Schöne Grüße
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 08 August 2021, 12:41:28
Ich habe mal die Versuche von sidey79 bei Github geforkt alles von Travis CI auf Github Actions umzustellen und neue Images gebaut. Wen es interessiert hier (https://github.com/volschin/fhem-docker/pkgs/container/fhem-experimental)

Oder:docker pull ghcr.io/volschin/fhem-experimental:dev-actions

Das Version-Pinning habe ich rausgeworfen. Erschien mir eine schlechte Idee.

Viele Grüße
Veit
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beSmart am 19 August 2021, 21:05:48
Guten Abend,

ich ziehe mit Fhem gerade auf ein Intel Nuc um und habe mir auch gleich Docker und Portainer mit installiert.
Das erstellen eines Volumes für /opt/fhem und das starten des fhem-Containers war auf den ersten Blick kein Problem. Allerdings startet der Container nicht. Da es anscheinend ein Problem mit den Schreib- Leserechten gibt.

Hier das log:


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 ... done


Starting FHEM ...

Can't open ./log/fhem-2021-08-19.log: Permission denied at fhem.pl line 2799.

Unable to start FHEM process - errorcode 13



Ich habe eingestellt, dass ,,jeder" lesen,schreiben und ausführen kann. Der Zugriff per PC und Tablett funktioniert auch.
Fast vergessen: es ist ein SMB/CIFS volume  mit BN und PW.


Liegt das Problem bei den Zugriffsrechten der Freigabe, oder habe ich einen Fehler beim erstellen des Volumes in Portainer gemacht?

Vielen Dank und Gruß

Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 19 August 2021, 21:31:00
/opt/fhem ist ein SMB/CIFS Volume?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beSmart am 19 August 2021, 22:35:49
Hallo,

ja es ist ein SMB/CIFS Volume.

Gruß

Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 19 August 2021, 23:14:57
Zitat von: beSmart am 19 August 2021, 21:05:48

Ich habe eingestellt, dass ,,jeder" lesen,schreiben und ausführen kann. Der Zugriff per PC und Tablett funktioniert auch.
Fast vergessen: es ist ein SMB/CIFS volume  mit BN und PW.
:o :o  :'(
Hi Dirk,

Wozu sollte das gut sein?

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beSmart am 19 August 2021, 23:32:38
Hallo Otto,

das war Verzweiflung. Ich habe aus ,,Permission denied" geschlossen, dass die Rechte nicht passen, deshalb jeder alles, hat aber auch nichts geholfen!



Gruß


Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 19 August 2021, 23:51:20
Ich meinte: welchen Sinn macht es das docker Volume auf einem smb Share liegen zu haben?
Also: vielleicht bekommt man das hin - aber ich würde doch erstmal den geraden Weg wählen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beSmart am 20 August 2021, 12:45:45
Hallo Otto,

ich dachte bis gerade eben, dass der von mir gewählte Weg der Standart ist. Dies ist mein erster Versuch mit Docker und ich habe bevor ich angefangen habe einiges hier im Forum und im www darüber gelesen.
Der SMB Share ist zum auslagern der cfg-Dateien die sind sonst nach einem Neustart des Containers ja weg.
Dies ist hier https://github.com/fhem/fhem-docker  (https://github.com/fhem/fhem-docker) ja auch so beschrieben. Zwar nicht explizit als SMB-Share aber außerhalb des Containers.
Welchen Weg würdest du mir empfehlen? Bzw. wie kann ich es besser machen?

Vielen Dank für deine Hilfe

Edit: ich habe gerade etwas auf deinen Blog entdeckt. https://heinz-otto.blogspot.com/2021/06/docker-ein-kleiner-schnellstart-workshop.html (https://heinz-otto.blogspot.com/2021/06/docker-ein-kleiner-schnellstart-workshop.html) Das lese ich mir mal durch.


Gruß

Dirk

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 20 August 2021, 12:48:36
Zitat von: beSmart am 20 August 2021, 12:45:45
Hallo Otto,

ich dachte bis gerade eben, dass der von mir gewählte Weg der Standart ist. Dies ist mein erster Versuch mit Docker und ich habe bevor ich angefangen habe einiges hier im Forum und im www darüber gelesen.
Der SMB Share ist zum auslagern der cfg-Dateien die sind sonst nach einem Neustart des Containers ja weg.
Dies ist hier https://github.com/fhem/fhem-docker  (https://github.com/fhem/fhem-docker) ja auch so beschrieben. Zwar nicht explizit als SMB-Share aber außerhalb des Containers.
Welchen Weg würdest du mir empfehlen? Bzw. wie kann ich es besser machen?

Vielen Dank für deine Hilfe

Gruß

Dirk

Nein, der FHEM Ordner ist doch persistent. Du brauchst da gar nichts machen. Nur wichtig die docker-compose.yml richtig anzupassen.
Wichtig: dennoch ein Backup vom Ordner erstellen. Ich mache das mit git und das klappt super.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beSmart am 20 August 2021, 13:01:47
@P.A.Trick

Auch dir vielen Dank für deine Hilfe. Ich habe das gerade eben mal ausprobiert, du hast recht .
Docker-Composite kenne ich noch nicht, werde es mir aber gleich mal anschauen. Ist es so etwas ähnliches  wie Portainer?

Gruß

Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 August 2021, 13:21:18
Nicht gans ....

Wenn Du Conatiner startest, also au der Console mit docker, giebt Du per Parameter die Config an. Dieses kann man auch in der Docker-Compose eintragen, aber dann nicht nur für einen Container, sondern für ein Bündel. Mit docker-compose wird denn dieses Büdel (was auch aus einem Container bestehen kann) gestartet ...

Sofern ich weiß, kann Portainer auch mit docker-compose.yml, also der Config-Datei, umgehen .... aber meine letzte Verwendung von Portainer liegt schon etwas zurück ...

Die Config-Datei rauszulinken ist gut ... aber nur diese. Und wenn, dann nicht gleich überkomplex, d.h. aufs gleiche System des NUCs hätte gereicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 20 August 2021, 16:52:51
Zitat von: beSmart am 20 August 2021, 13:01:47
@P.A.Trick

Auch dir vielen Dank für deine Hilfe. Ich habe das gerade eben mal ausprobiert, du hast recht .
Docker-Composite kenne ich noch nicht, werde es mir aber gleich mal anschauen. Ist es so etwas ähnliches  wie Portainer?

Gruß

Dirk

Schaue mal hier: https://github.com/stormmurdoc/fhemdocker/blob/master/docker-compose.yml (https://github.com/stormmurdoc/fhemdocker/blob/master/docker-compose.yml)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 20 August 2021, 23:14:14
Oder schau mal hier: https://heinz-otto.blogspot.com/2021/01/container-schiff.html
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beSmart am 21 August 2021, 01:18:17
Guten Morgen,

Docker und Docker-Compose machen mir richtig Spaß! Im Netz gibt es jede Menge docker-compose-Dateien und wenn man einigermaßen verstanden hat wie es funktioniert, kann man sich als Anfänger schon einiges zusammenbauen. Nebenbei habe ich viele für mich interessante Container entdeckt. Nur das Wochenende ist wahrscheinlich wieder zu kurz.....


Vielen, vielen Dank an alle die hier geantwortet haben. Eure Tipps waren super.

Viele Grüße

Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 August 2021, 10:40:28
Sei vorsichtig mit "erstellten Containern", Du weißt nicht, wie die gepflegt werden.

Habe ich beruflich schon schmerzvoll erfahren müssen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: beSmart am 24 August 2021, 12:44:21
Hallo Wernieman,

meinst Du gepflegt im Sinne von aktuell oder weil man nicht weiß was da tatsächlich alles drin ist? (sog. Schadsoftware)


Gruß


Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 August 2021, 17:47:53
Eigentlich meinte ich, wie sie weiterentwickelt werden. Deine Argumente stimmen aber auch
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 10 September 2021, 12:39:03
Moin - sagt mal hab ich gerade einen Gedankenfehler - oder warum waren in meinem Dockercontainer 113 Pakete nicht aktuell?

Ich hab gerade mal das Dockerfile angesehen - es wird an einer Stelle ein upgrade gemacht.
Aber dort auch aktiv mit
  && LC_ALL=C DEBIAN_FRONTEND=noninteractive apt-get -qqy --no-install-recommends upgrade \

Ich kam gerade dahin, weil ich Perl updaten wollte -> da der Installer in FHEM sagt -> outdated.
Daraufhin habe ich geschaut was mir set "outdated" ausgibt - es war eine recht umfangreiche Liste von Paketen:

@Outdated:
Alien::Base::ModuleBuild       1.14    1.15    P/PL/PLICEASE/Alien-Base-ModuleBuild-1.15.tar.gz
Alien::Build                   2.26    2.41    P/PL/PLICEASE/Alien-Build-2.41.tar.gz
Alien::Sodium                  1.0.8.0 2.000   C/CA/CAPOEIRAB/Alien-Sodium-2.000.tar.gz
App::Cpan                      1.67    1.676   A/AN/ANDK/CPAN-2.28.tar.gz
Archive::Tar                   2.30    2.40    B/BI/BINGOS/Archive-Tar-2.40.tar.gz
autodie                        2.29    2.34    T/TO/TODDR/autodie-2.34.tar.gz
bigint                         0.49    0.53    P/PJ/PJACKLAM/bignum-0.53.tar.gz
Compress::Raw::Bzip2           2.074   2.101   P/PM/PMQS/Compress-Raw-Bzip2-2.101.tar.gz
Compress::Raw::Zlib            2.076   2.101   P/PM/PMQS/Compress-Raw-Zlib-2.101.tar.gz
Compress::Zlib                 2.074   2.102   P/PM/PMQS/IO-Compress-2.102.tar.gz
Config::Perl::V                0.29    0.33    H/HM/HMBRAND/Config-Perl-V-0.33.tgz
CPAN::Plugin::Sysdeps          0.65    0.69    S/SR/SREZIC/CPAN-Plugin-Sysdeps-0.69.tar.gz
Crypt::Argon2                  0.007   0.011   L/LE/LEONT/Crypt-Argon2-0.011.tar.gz
Cwd                            3.74    3.75    X/XS/XSAWYERX/PathTools-3.75.tar.gz
Data::Dumper                   2.170   2.183   N/NW/NWCLARK/Data-Dumper-2.183.tar.gz
DB_File                        1.840   1.856   P/PM/PMQS/DB_File-1.856.tar.gz
Devel::PPPort                  3.40    3.63    A/AT/ATOOMIC/Devel-PPPort-3.63.tar.gz
Digest                         1.17_01 1.20    T/TO/TODDR/Digest-1.20.tar.gz
Digest::MD5                    2.55    2.58    T/TO/TODDR/Digest-MD5-2.58.tar.gz
Encode                         3.00    3.12    D/DA/DANKOGAI/Encode-3.12.tar.gz
experimental                   0.019   0.025   L/LE/LEONT/experimental-0.025.tar.gz
Exporter                       5.73    5.74    T/TO/TODDR/Exporter-5.74.tar.gz
ExtUtils::CBuilder             0.280230 0.280236 A/AM/AMBS/ExtUtils-CBuilder-0.280236.tar.gz
ExtUtils::Command              7.34    7.62    B/BI/BINGOS/ExtUtils-MakeMaker-7.62.tar.gz
ExtUtils::Install              2.14    2.20    B/BI/BINGOS/ExtUtils-Install-2.20.tar.gz
ExtUtils::Manifest             1.70    1.73    E/ET/ETHER/ExtUtils-Manifest-1.73.tar.gz
FFI::CheckLib                  0.27    0.28    P/PL/PLICEASE/FFI-CheckLib-0.28.tar.gz
File::Fetch                    0.56    1.00    B/BI/BINGOS/File-Fetch-1.00.tar.gz
File::Path                     2.15    2.18    J/JK/JKEENAN/File-Path-2.18.tar.gz
File::Temp                     0.2304  0.2311  E/ET/ETHER/File-Temp-0.2311.tar.gz
Filter::Util::Call             1.58    1.60    R/RU/RURBAN/Filter-1.60.tar.gz
FindBin                        1.51    1.52    T/TO/TODDR/FindBin-1.52.tar.gz
Getopt::Long                   2.5     2.52    J/JV/JV/Getopt-Long-2.52.tar.gz
HTTP::Tiny                     0.070   0.078   D/DA/DAGOLDEN/HTTP-Tiny-0.078.tar.gz
IO                             1.39    1.48    T/TO/TODDR/IO-1.48.tar.gz
IO::Socket::IP                 0.39    0.41    P/PE/PEVANS/IO-Socket-IP-0.41.tar.gz
IO::Zlib                       1.10    1.11    T/TO/TOMHUGHES/IO-Zlib-1.11.tar.gz
IPC::Cmd                       1.00    1.04    B/BI/BINGOS/IPC-Cmd-1.04.tar.gz
IPC::Msg                       2.07    2.09    M/MH/MHX/IPC-SysV-2.09.tar.gz
JSON::PP                       4.02    4.06    I/IS/ISHIGAKI/JSON-PP-4.06.tar.gz
List::Util                     1.50    1.56    P/PE/PEVANS/Scalar-List-Utils-1.56.tar.gz
Locale::Codes                  3.56    3.68    S/SB/SBECK/Locale-Codes-3.68.tar.gz
Math::BigFloat                 1.999816 1.999823 P/PJ/PJACKLAM/Math-BigInt-1.999823.tar.gz
Math::BigInt::FastCalc         0.5006  0.5010  P/PJ/PJACKLAM/Math-BigInt-FastCalc-0.5010.tar.gz
Math::BigRat                   0.2613  0.2617  P/PJ/PJACKLAM/Math-BigRat-0.2617.tar.gz
MIME::Base64                   3.15    3.16    C/CA/CAPOEIRAB/MIME-Base64-3.16.tar.gz
Module::CoreList               5.20181129_28 5.20210820 B/BI/BINGOS/Module-CoreList-5.20210820.tar.gz
Module::Load                   0.32    0.36    B/BI/BINGOS/Module-Load-0.36.tar.gz
Module::Load::Conditional      0.68    0.74    B/BI/BINGOS/Module-Load-Conditional-0.74.tar.gz
Module::Metadata               1.000033 1.000037 E/ET/ETHER/Module-Metadata-1.000037.tar.gz
Net::Cmd                       3.11    3.13    S/SH/SHAY/libnet-3.13.tar.gz
Net::MQTT::Simple              1.24    1.26    J/JU/JUERD/Net-MQTT-Simple-1.26.tar.gz
Net::Ping                      2.62    2.74    R/RU/RURBAN/Net-Ping-2.74.tar.gz
Net::WebSocket::Server         0.003004 0.004000 T/TO/TOPAZ/Net-WebSocket-Server-0.004000.tar.gz
NEXT                           0.67_01 0.68    N/NE/NEILB/NEXT-0.68.tar.gz
ok                             1.302133 1.302186 E/EX/EXODIST/Test-Simple-1.302186.tar.gz
parent                         0.236   0.238   C/CO/CORION/parent-0.238.tar.gz
Perl::PrereqScanner::NotQuiteLite 0.9911  0.9913  I/IS/ISHIGAKI/Perl-PrereqScanner-NotQuiteLite-0.9913.tar.gz
perlfaq                        5.021011 5.20210520 E/ET/ETHER/perlfaq-5.20210520.tar.gz
PerlIO::via::QuotedPrint       0.08    0.09    S/SH/SHAY/PerlIO-via-QuotedPrint-0.09.tar.gz
Pod::Checker                   1.73    1.74    M/MA/MAREKR/Pod-Checker-1.74.tar.gz
Pod::Man                       4.10    4.14    R/RR/RRA/podlators-4.14.tar.gz
Pod::Simple                    3.35    3.43    K/KH/KHW/Pod-Simple-3.43.tar.gz
Pod::Usage                     1.69    2.01    A/AT/ATOOMIC/Pod-Usage-2.01.tar.gz
Socket                         2.029   2.032   P/PE/PEVANS/Socket-2.032.tar.gz
Storable                       3.08    3.25    N/NW/NWCLARK/Storable-3.25.tar.gz
Sys::Syslog                    0.35    0.36    S/SA/SAPER/Sys-Syslog-0.36.tar.gz
Term::ANSIColor                4.06    5.01    R/RR/RRA/Term-ANSIColor-5.01.tar.gz
Text::Balanced                 2.03    2.04    S/SH/SHAY/Text-Balanced-2.04.tar.gz
Text::Tabs                     2013.0523 2021.0814 A/AR/ARISTOTLE/Text-Tabs+Wrap-2021.0814.tar.gz
Thread::Queue                  3.12    3.13    J/JD/JDHEDDEN/Thread-Queue-3.13.tar.gz
threads::shared                1.58    1.59    J/JD/JDHEDDEN/threads-shared-1.59.tar.gz
Tie::File                      1.02    1.05    T/TO/TODDR/Tie-File-1.05.tar.gz
Tie::RefHash                   1.39    1.40    E/ET/ETHER/Tie-RefHash-1.40.tar.gz
Time::HiRes                    1.9759  1.9764  A/AT/ATOOMIC/Time-HiRes-1.9764.tar.gz
Time::Local                    1.25    1.30    D/DR/DROLSKY/Time-Local-1.30.tar.gz
Time::Piece                    1.3204  1.3401  E/ES/ESAYM/Time-Piece-1.3401.tar.gz
Unicode::Collate               1.25    1.31    S/SA/SADAHIRO/Unicode-Collate-1.31.tar.gz
version                        0.9923  0.9929  L/LE/LEONT/version-0.9929.tar.gz


Sollte nicht all dies im Container aktuell gehalten werden? Oder ist es aus Kompatibilität so gehalten?

Habe jetzt erstmal - völlig untypisch für die Art wie ich Docker nutze - innerhalb des containers ein manuelles apt update und upgrade los geschickt.

Und dann noch mit "cpan-outdated -p | cpanm" mal alles geupdated.

Mir scheint der update mechanismus wirft da nen Fehler: ""error 'outdatedPerl'

LG :-)

*EDIT nachdem ich beide oben genannten Dinge mal durch habe, ist nun auch der set outdated Befehl den man in der UI wählen kann erfolgreich durchgelaufen "check completed" 111 Sachen gab es bei cpan zu updaten. Nach dem wie ich Docker nutze, ist dieser Zustand aber genau nun haltbar bis zu einem redeploy :-D (Rancher Kubernetes Cluster) Daher eben die Frage - wie kann es kommen, das der container nachdem er sich initialisiert hat - nicht aktuell unterwegs ist innendrin: Absicht? oder Ups :-D
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 18 September 2021, 16:31:09
Der Container ist schon ewig nicht mehr aktualisiert worden. Wenn Du den durch ein Container Security Tool laufen lässt, stehen alle Ampeln auf hochrot.
ich kann nur davon abraten, diesen Containerstand noch zu verwenden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 18 September 2021, 17:24:01
Stimmt so nichts ganz. Dieser Container aktuallisiert sich nach dem Start selber, bzw. es gibt ein Aktuallisierungs Butten in seinem FHEM.

Also Generell deshalb abzuraten, ist zu kurz gesagt.

Das ich selber Ihn nicht nutze, liegt eher an der nicht vorhandenen Versionierung. Aber DAS ist ein anderes Thema.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 September 2021, 11:42:48
Moin @Werniemann,

also ich nutze den Container und komme eigentlich sehr gut damit klar.

Was ich erlebe ist halt, dass er sich irgendwie nicht sauber aktualisiert - ich werde das aber auch nochmal genauer untersuchen, damit ich nix falsches "behaupte" :-)
Ich meine nicht die FHEM Installation an sich -  ich spreche ja von der Umgebung in der FHEM da läuft. Da sind CPAN Pakete bei mir nicht aktuell etc.
Oder meinst du eine andere Update Funktion als die von FHEM selbst (update befehl)?


Was meinst du mit Versionierung?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 September 2021, 11:47:07
Im Container gibt s eine Möglichkeit, genau dieses zu aktuallisieren ...

Ich liebe Container, die versioniert sind. Also Du installierst nicht Container XXX:latest, sondern XXX:V2.1
Wenn Du Probleme bei einem Update hast, gehst Du dann "einfach" eine Version zurück. Bei FHEM selber ist es durch die automatischen Backupfunktionen mögoch, aber beim Container ... das mag ich nicht. Allerdings habe ich auch beruflich mit Container zu tuen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 September 2021, 11:51:50
Mh du kannst doch Container taggen - dann hast du deine Versionierung.
*Edit: Dockerhub bietet das nativ an. Das hat nur nix mit dem FHEM inhalt zu tun. Sondern mit der puren Umgebung in der FHEM läuft.
Da FHEM sich selber updated.

latest / 1.0 / etc etc etc :-)

"Wie" gibt es im Container die Möglichkeit? Und eigentlich sollte (so meine Denke) ein Container den man deployt direkt bevor er "ready" oder "live" Status erreicht ja für diesen Moment den aktuellsten Stand haben.
Wenn er dann Tage läuft - redeploy fertig. Manuelle Befehle in einem Container sollten nicht das Vorgehen sein - so habe ich es privat und beruflich gelernt - dennoch dürfen da andere Ansichten existieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 September 2021, 12:07:16
Sollte .. aber so ist der FHEM-Container eben nicht aufgebaut. Ist auch kein FHEM-Container-Problem, weil andere Container aus dockerhub genau so arbeiten (z.B. Calibre). Die Großen (z.B. nginx, apache, php) meistens nicht.

Und Taggen bei einem sich selbst updatenden Container ... aber das führt zu Containerdiskussionen, die hier nicht zu suchen haben ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 September 2021, 12:35:37
Also allein wenn man halt Änderungen am Container macht - im dockerfile oder Sachen weg lässt oder hinzufügt - könnte das ja schon ein Grund sein für ein Tag um es von dem vorherigen zu separieren und das vorherige dennoch vorhanden zu haben.

Quasi egal was man ändert - könnte es eine Version Höher gehen.

Ansonsten gibt es ja auch schon 2 Flavours:

This image provides 2 different variants:

latest (default)
dev


Da die Diskussion ja um den FHEM Container geht - wüsste ich nicht, warum die nicht hier stattfinden sollte oder wo sonst ;-)

Sich selbst updatend erscheint er mir persönlich nicht.
Ggf. (das muss ich noch prüfen) beim ersten Start wenn er sich einrichtet. Genau das muss ich mal prüfen. Wenn er das tut wäre ja alles fein.
Pflege eines Containers wenn er lebt ist für mich nicht sinnvoll. Ersetzen mit neuer Instanz und gut.

Pflegst du das Dockerimage?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 20 September 2021, 12:37:31
Wenn Dich das stört, ich baue derzeit monatlich ein neues Image als Weiterentwicklung des offiziellen.
https://github.com/volschin/fhem-docker/pkgs/container/fhem-experimental
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 September 2021, 12:38:10
Zitat von: volschin am 20 September 2021, 12:37:31
Wenn Dich das stört, ich baue derzeit monatlich ein neues Image als Weiterentwicklung des offiziellen.
https://github.com/volschin/fhem-docker/pkgs/container/fhem-experimental

Klingt interessant, schaue ich mir an - Danke.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 20 September 2021, 13:22:10
Zitat von: volschin am 20 September 2021, 12:37:31
Wenn Dich das stört, ich baue derzeit monatlich ein neues Image als Weiterentwicklung des offiziellen.
https://github.com/volschin/fhem-docker/pkgs/container/fhem-experimental
Hi,
warum gibt es das dann nicht als reglemäßiges produktives Update?
VG
  Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 September 2021, 13:31:27
Zitat von: ch.eick am 20 September 2021, 13:22:10
Hi,
warum gibt es das dann nicht als reglemäßiges produktives Update?
VG
  Christian

Hey Christian,

was genau hättest du gerne geupdatet?

Rein technisch muss man an einem Dockerimage nichts updaten wenn es keine großen Changes in FHEM gäbe (so meine Ansicht).
Eigentlich richtet sich das beim Start zum Zeitpunkt mit dem aktuellstens, das die Anwendung die ausgeführt werden soll zulässt, ein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 20 September 2021, 13:37:18
Zitat von: Master_Nick am 20 September 2021, 13:31:27
Hey Christian,

was genau hättest du gerne geupdatet?

Rein technisch muss man an einem Dockerimage nichts updaten wenn es keine großen Changes in FHEM gäbe (so meine Ansicht).
Eigentlich richtet sich das beim Start zum Zeitpunkt mit dem aktuellstens, das die Anwendung die ausgeführt werden soll zulässt, ein.

Das habe ich auch so verstanden, jedoch warum machst Du dann monatlich ein "fhem-experimental" ?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 September 2021, 13:54:16
 :) Nicht ich mache irgendwas - ich mache das Image ja nicht. Sondern volschin pflegt das - soweit ich das verstanden habe.

Nun wenn er Dinge umbaut, dann macht er das da ggf. fertig.

Genaue Hintergründe müsste man ihn fragen.

Aber man nimmt ja auch nicht für ein laufendes (produktives) System den "experimentellen" Zweig. Sondern die Stable :-)

Aber habe mir das Ganz auch noch nicht angeschaut.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 September 2021, 14:55:08
Wie hier schon mal geschrieben: Da mir persönlich die FHEM Container einfach zu "fett" sind (wie gesagt, persönliche Meinung), habe ich mir selber einen gebaut. Ist prinzipiell nicht schwierig .. nur das Beenden ist nicht so gut wie beim automatischen, weshalb ich es nicht veröffentlicht habe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 20 September 2021, 15:44:06
Zitat von: Master_Nick am 20 September 2021, 13:54:16
Aber man nimmt ja auch nicht für ein laufendes (produktives) System den "experimentellen" Zweig. Sondern die Stable :-)
und somit sind wir wieder an dem Punkt, dass das schon etwas älter ist, was mich jedoch nicht stört, da ich regelmäßige Updates mache.

Zitat
Wie hier schon mal geschrieben: Da mir persönlich die FHEM Container einfach zu "fett" sind (wie gesagt, persönliche Meinung), habe ich mir selber einen gebaut. Ist prinzipiell nicht schwierig .. nur das Beenden ist nicht so gut wie beim automatischen, weshalb ich es nicht veröffentlicht habe.
Einen Tod muss man sterben...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 20 September 2021, 16:21:37
Also da ich einen Rancher Kubernetes Cluster betreibe aus Spaß an der Freude ist halt für mich ein zu fett - nicht so richtig der Punkt.

Aber und das sei bitte klar gesagt - jeder hat auch ganz eigene Ansprüche.

Ich denke wir können aber auch gemeinsame finden.

Meine wären:

- Container sollte nach dem deployen / docker up tagesaktuelle Software enthalten um FHEM zu betreiben (Aktualität von FHEM komplett raus die macht FHEM selber) (muss ich noch testen, ob es "bei mir" so ist)
- Container sollte sich nicht zur Laufzeit aktualisieren (unklar wie das ist)
- Container sollte keine Konfiguration der Software enthalten, die er ausführt (ist bereits jetzt so)

Ich habe das Gefühl, wie gesagt, dass der Container nicht ganz das nutzt was machbar wäre sondern etwas ältere Stände.
Kann ja auch gut sein, dass es Gründe dafür gibt.

Mir ist wichtig, ich möchte die Arbeit kein Stück kritisieren - ich würde gern schauen, ob a) die Pflege noch vorhandenist oder b) ob man eine neues "offizielles" Image mal angehen sollte.
Ggf. bleibt von all dem am Ende nach Klärung ja genau nichts mehr über.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 21 September 2021, 15:04:02
Zitat von: ch.eick am 20 September 2021, 13:37:18
Das habe ich auch so verstanden, jedoch warum machst Du dann monatlich ein "fhem-experimental" ?
Es kommen rund monatlich normalerweise neue Versionen zum Debian Basis-Image. Regelmäßige Paket-Updates kommen sowieso. Image-Layer sind unveränderbar. Daher ist es eine Unsitte darauf wesentliche Updates zu fahren.
Das Ganze ist momentan nicht intensiv getestet (für mich funktionierts) und hat daher nicht den Status produktiv.   
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 21 September 2021, 15:07:48
Oh ja stimmt - die Grundimages hab ich mal gar nicht im Kopf gehabt bei all dem.

Mhh joa alles mit latest fahren wäre in der Theorie machbar - aber wahrscheinlich auch nicht immer geil in Produktion.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 21 September 2021, 15:40:13
Zitat von: volschin am 21 September 2021, 15:04:02
Es kommen rund monatlich normalerweise neue Versionen zum Debian Basis-Image. Regelmäßige Paket-Updates kommen sowieso. Image-Layer sind unveränderbar. Daher ist es eine Unsitte darauf wesentliche Updates zu fahren.
Das Ganze ist momentan nicht intensiv getestet (für mich funktionierts) und hat daher nicht den Status produktiv.
Jetzt kann ich Euch nicht richtig folgen.

Geht es jetzt darum, das der Fhem Container nicht jeden Monat die Debian Updates bekommen soll?
Ich versuche es wegen der Security Updates nach Möglichkeit aktuell zu halten.

Könnt Ihr mich da etwas tiefer aufklären?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 21 September 2021, 15:58:59
Ich kann nur meine Ansicht und meinen Wissenstand nutzen:

Aus meiner Sicht updatet man keine laufenden Container.
Man killt sie und ersetzt mit neuem.
Der ist dann aktuell weil er beim Start seiner selbst alles neu einrichtet und das aktuellste (sinnvolle) nutzt.

Updates in laufenden Containern zu machen von dem, was den Container ausmacht (Debian,CPAN pakete etc) ist aus meiner Sicht falsch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: M.Schulze am 21 September 2021, 17:33:03
Zitat von: Master_Nick am 21 September 2021, 15:58:59
Aus meiner Sicht updatet man keine laufenden Container.
Man killt sie und ersetzt mit neuem.
Der ist dann aktuell weil er beim Start seiner selbst alles neu einrichtet und das aktuellste (sinnvolle) nutzt.

Das ist aber keine neue Erkenntnis

https://forum.fhem.de/index.php/topic,89745.msg828154.html#msg828154

Du musst dir deinen eigenen Container bauen.
Und um FHEM mit Kubernetes zu nutzen sind mehrere kleinere Änderungen notwendig um das Potential voll auszuschöpfen. z.B. das Thema mit der Nutzung von Persistent Volumes.
Ein eigenes Repository ist nötig, aus dem automatisch Images gebaut werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Master_Nick am 21 September 2021, 17:42:29
Also ich betreibe das nun seit 4 jahren so wie es ist in einem Rancher Kubernetes Cluster. Funzt wunderbar. Es kommt darauf wie man es betreibt. Ja nicht jede Art würde damit so gehen. Bei mir gibt es ein Pod und wenn das schmiert oder so wird es gekillt und dann ein neues erschaffen. Es kommt sehr darauf an, wie man betreiben will.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 17 Oktober 2021, 00:41:34
Also jetzt verstehe ich garnichts mehr! Wird das Docker-Image: fhem/fhem:latest nicht mehr gepflegt? Oder soll er nicht mehr verwendet werden? Die letzte Aktualisierung von https://github.com/fhem/fhem-docker/ (https://github.com/fhem/fhem-docker/) war vor 10 Monaten? "NodeJS" soll jetzt auf Version 14 LTS aktualisiert werden. Wenn ich das Image pulle, ist meine NodeJS Version 10.*.*.* npm beschwert sich, dass was nicht geupdatet werden kann, weil npm? NodeJS? zu alt ist.
Portainer-Konsole von fhem:

curl -fsSL https://deb.nodesource.com/setup_16.x | bash -
apt-get install -y nodejs
apt-get install -y libjson-pp-perl
npm install pm2 -g
cpan-outdated -p | cpanm


... läuft! 8) Bei "libjson-pp-perl" und "pm2" bin ich mir nicht sicher wozu das ist.  ::)

Könnte mir bitte Jemand (verstädlich) erklären, ob fhem in Docker noch benutzt werden soll. Wenn dem so ist, wie werden in Docker fhem + System Updates gemacht, oder wie wird der fhem- Container gebaut, damit der fhem-Container Sicherheitsupdates bekommt?

Ich suche jetzt schon über 2 Monate, aber außer Verweise auf nicht relevante Diskussionen (oder die ich nicht verstehe) finde ich keine Lösung / die richtigen Stichwörter.

Mein System: J5040 mit openmediavault, darin Docker aktiviert, in Docker: Portainer, fhem, mariadb, watchtower, jellyfin, nextcloudpi

Vielen Dank schon Mal!

Lutz
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 17 Oktober 2021, 10:41:53
Leider hat das Projekt aktuell keinen Maintainer. Gerne kann sich jemand freiwillig melden dann richte ich Ihm entsprechende Rechte ein das er auf Github mit dem Projekt arbeiten kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 17 Oktober 2021, 10:52:18
Zitat von: LutzG am 17 Oktober 2021, 00:41:34

Könnte mir bitte Jemand (verstädlich) erklären, ob fhem in Docker noch benutzt werden soll. Wenn dem so ist, wie werden in Docker fhem + System Updates gemacht, oder wie wird der fhem- Container gebaut, damit der fhem-Container Sicherheitsupdates bekommt?

volschin hat einen dev-tree in github.
https://forum.fhem.de/index.php/topic,89745.msg1175625.html#msg1175625


docker pull ghcr.io/volschin/fhem-experimental:6.0-s25041_v2.2.5-22-g68f5b1c-dev-actions


Du kannst den Parameter NPM_PKGS setzen. Damit habe ich beim erstellen folgende npm, Container hat folgende node .. musst prüfen ob das reicht ..


            NPM_PKGS: "npm@8.1.0"



npm -v
8.1.0

node -v
v14.17.5


Ansonsten Container (Dockerfile) den eigenen Anforderungen anpassen und selber erzeugen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 17 Oktober 2021, 17:28:10
Vielen Dank für die schnelle Antworten!
Zitat von: kadettilac89 am 17 Oktober 2021, 10:52:18
volschin hat einen dev-tree in github.
"experimental" + nicht öffentlich, ich weiß nicht. Trotzdem, Danke für den Tip!

Zitat
Du kannst den Parameter NPM_PKGS setzen.
Oh, den habe ich überlesen. Danke vor allem für die Syntax! Auf "npm@8.1.0" wäre ich nicht gekommen.

Zitat
Ansonsten Container (Dockerfile) den eigenen Anforderungen anpassen und selber erzeugen.
Dazu bin ich nicht fit genug.  :-[

Hab ich das richtig verstanden: fhem für Docker ist Tod, es lebe der Raspberry!  :o

SD-Karte und produktives System, finde ich, gehören nicht zusammen. Die Bastelei mit USB-SSD finde ich zu anfällig, da finde ich einen sparsamen Rechner "schöner", vor allem weil darauf noch genug Ressourcen für andere Dienste sind.

Ich kann es immer noch nicht fassen, in den Signaturen lese ich viele Server, NAS, ... die sehr wahrscheinlich mit Docker laufen.

Wie betreibt ihr fhem, in virtuellen Maschinen? NAS haben meist schwache CPUs / wenig Speicher, VMs kann ich mir da nicht vorstellen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 17 Oktober 2021, 17:48:40
Ich bin aktuell dabei mich in das Thema ein zu arbeiten und werde schauen ob ich aktuelle Images in nächster Zeit bereit stellen kann. Ich hoffe auf Unterstützung durch die Community.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 17 Oktober 2021, 17:49:26
Zitat von: LutzG am 17 Oktober 2021, 17:28:10
Vielen Dank für die schnelle Antworten!"experimental" + nicht öffentlich, ich weiß nicht. Trotzdem, Danke für den Tip!
das "dev" und "experimental" nicht überbewerten. Läuft bei mir seit volschin das begonnen hat. Und hatte keinerlei Probleme. Teste es einfach mal. Kostet ja nichts.

Zitat von: LutzG am 17 Oktober 2021, 17:28:10
Hab ich das richtig verstanden: fhem für Docker ist Tod, es lebe der Raspberry!  :o
Deine Interpretation. Habe ich nicht gesagt. Muss jeder für sich entscheiden.

Für mich ist der Raspberry keine Alternative. Docker läuft stabil und ist einfach zu warten.


Zitat von: LutzG am 17 Oktober 2021, 17:28:10
Wie betreibt ihr fhem, in virtuellen Maschinen? NAS haben meist schwache CPUs / wenig Speicher, VMs kann ich mir da nicht vorstellen?

Intel Nuc, da drauf Proxmox mit einer VM. In der VM läuft Docker mit all meinen Containern. Wobei fhem an sich nicht viele Resourcen braucht. Das Basissystem, Last erzeugen die Logs, Plots, Datenbank ... wenn das mit Köpfchen aufgesetzt wird sollte ein NAS auch reichen.

Es gibt einige NAS die eine einfache Docker Engine mitbringen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 17 Oktober 2021, 18:01:27
Bei mir ist es ein ZOTAC CI320, auf dem nativ Docker läuft. Da nur ein Rechner, wäre Kubernetis u.Ä. Oversize und für eine echte VM wollte ich keine Ressourcen verbraten. Allerdings fahre ich nicht diesen Container, da er mir einfach "zu groß" ist. Zusätlich liebe ich Versionen, zu denen man "springen" kann, hier von mir schon mal angesprochen. Aber DAS ist ein anderes Thema.

@CoolTux
Was führ Hilfe brauchst Du?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 17 Oktober 2021, 18:26:12
Zitat von: Wernieman am 17 Oktober 2021, 18:01:27
Bei mir ist es ein ZOTAC CI320, auf dem nativ Docker läuft. Da nur ein Rechner, wäre Kubernetis u.Ä. Oversize und für eine echte VM wollte ich keine Ressourcen verbraten. Allerdings fahre ich nicht diesen Container, da er mir einfach "zu groß" ist. Zusätlich liebe ich Versionen, zu denen man "springen" kann, hier von mir schon mal angesprochen. Aber DAS ist ein anderes Thema.

@CoolTux
Was führ Hilfe brauchst Du?

Puh das weiß ich aktuell selber noch nicht. Ich habe es zu mindest geschafft das ganze von buster auf bullseye um zu stellen und ein lauffähiges Image inklusive aktuellem FHEM hin zu bekommen. Nun schaue ich wie das ganze mit der Veröffentlichung geht. Entweder automatisch über github oder ich muss mich da noch mal an Julian wenden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 17 Oktober 2021, 18:40:07
Hatte nicht Julian schon etwas implementiert zur automatischen Veröffentlichung?

Hast Du Zugriff zu seinem Akkount? Oder nur zum Repro?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 17 Oktober 2021, 19:54:55
Zitat von: Wernieman am 17 Oktober 2021, 18:40:07
Hatte nicht Julian schon etwas implementiert zur automatischen Veröffentlichung?

Hast Du Zugriff zu seinem Akkount? Oder nur zum Repro?

Aktuell nur zum Repo. Sidey hat einige pull requests zum check und automatischen veröffentlichen bereitgestellt. Die habe ich auch erstmal in meinen Patch eingebaut und teste aktuell.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 17 Oktober 2021, 20:58:40
Gib mir einfach einen "ping", wenn Du mich brauchst, auch gerne per PM

Kenne mich jetzt nicht direkt mit gitlab als Dienstleister, habe aber bei der letzten Anstellung einen gitlab-Server betreut ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 18 Oktober 2021, 14:04:07
Aktueller Status.

Julian hat mir Zugang zur Docker Hub FHEM Organisation gegeben. Ich teste das ganze die Tage mal und gebe dann Bescheid.


Grüße
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 18 Oktober 2021, 21:50:48
Zitat von: CoolTux am 18 Oktober 2021, 14:04:07
Aktueller Status.

Julian hat mir Zugang zur Docker Hub FHEM Organisation gegeben. Ich teste das ganze die Tage mal und gebe dann Bescheid.


Grüße

Sag' Bescheid wenn du Testhilfe benötigst. Helfe gerne mit!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 20 Oktober 2021, 12:39:21
Es gibt nun einen fertigen Container zum testen

https://github.com/fhem/fhem-docker/pkgs/container/fhem-experimental


Bitte schaut einmal ob alles soweit läuft.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 20 Oktober 2021, 13:16:05
Zitat von: CoolTux am 20 Oktober 2021, 12:39:21
Es gibt nun einen fertigen Container zum testen

https://github.com/fhem/fhem-docker/pkgs/container/fhem-experimental


Bitte schaut einmal ob alles soweit läuft.

Es geht um diesen Container, richtig? ... docker pull ghcr.io/fhem/fhem-experimental:dev

gassistant funktioniert nicht mehr. Der Fehler ist auch im entsprechenden Forum, bei manchen die node v14.18.1 hatten. https://forum.fhem.de/index.php/topic,96696.msg1180904.html#msg1180904

Edit, ich kann erst später die Meldungen genauer vergleichen. Sieht aber nach dem Problem im gassistant-thread aus.

[20.10.2021, 13:09:21] [LOCAL] FHEM Connect Google local home server running on port 37000
ReferenceError [Error]: exports is not defined
    at eval (eval at apply (/usr/lib/node_modules/gassistant-fhem/node_modules/vm2/lib/fixasync.js:21:10), <anonymous>:1:1)
    at eval (<anonymous>)
    at Object.apply (/usr/lib/node_modules/gassistant-fhem/node_modules/vm2/lib/fixasync.js:21:10)
    at Object.FHEM_getClientFunctions (/usr/lib/node_modules/gassistant-fhem/lib/remote-localhandleEXECUTE.js:18:5)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 20 Oktober 2021, 13:25:58
ok, danke fürs testen auf jeden Fall.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 20 Oktober 2021, 21:48:48
Zitat von: CoolTux am 20 Oktober 2021, 12:39:21
Es gibt nun einen fertigen Container zum testen

https://github.com/fhem/fhem-docker/pkgs/container/fhem-experimental


Bitte schaut einmal ob alles soweit läuft.

Hm ein schneller Test scheint ein Rechte-Problem bei mir hervorzubringen:

fhem_fhem             | Starting FHEM ...
fhem_fhem             | Can't open ./log/fhem-2021-10.log: Permission denied at fhem.pl line 2770.


Das Rechte-setzen scheint verändert worden zu sein. Kann das sein?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 Oktober 2021, 07:58:35
Zitat von: P.A.Trick am 20 Oktober 2021, 21:48:48
Hm ein schneller Test scheint ein Rechte-Problem bei mir hervorzubringen:

fhem_fhem             | Starting FHEM ...
fhem_fhem             | Can't open ./log/fhem-2021-10.log: Permission denied at fhem.pl line 2770.


Das Rechte-setzen scheint verändert worden zu sein. Kann das sein?

Kannst Du mal bitte schauen elche uid das File bekommen hat? Bewusst habe ich da nichts geändert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 Oktober 2021, 08:17:30
Zitat von: P.A.Trick am 20 Oktober 2021, 21:48:48
Hm ein schneller Test scheint ein Rechte-Problem bei mir hervorzubringen:

fhem_fhem             | Starting FHEM ...
fhem_fhem             | Can't open ./log/fhem-2021-10.log: Permission denied at fhem.pl line 2770.


Das Rechte-setzen scheint verändert worden zu sein. Kann das sein?

Habe das gerade mal mit dem alten Container und dann den neuen Container probiert. Bei mir geht das. Frage, hast Du vorher ein eigenes Image verwendet?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 Oktober 2021, 08:39:43
Zitat von: kadettilac89 am 20 Oktober 2021, 13:16:05
Es geht um diesen Container, richtig? ... docker pull ghcr.io/fhem/fhem-experimental:dev

gassistant funktioniert nicht mehr. Der Fehler ist auch im entsprechenden Forum, bei manchen die node v14.18.1 hatten. https://forum.fhem.de/index.php/topic,96696.msg1180904.html#msg1180904

Edit, ich kann erst später die Meldungen genauer vergleichen. Sieht aber nach dem Problem im gassistant-thread aus.

[20.10.2021, 13:09:21] [LOCAL] FHEM Connect Google local home server running on port 37000
ReferenceError [Error]: exports is not defined
    at eval (eval at apply (/usr/lib/node_modules/gassistant-fhem/node_modules/vm2/lib/fixasync.js:21:10), <anonymous>:1:1)
    at eval (<anonymous>)
    at Object.apply (/usr/lib/node_modules/gassistant-fhem/node_modules/vm2/lib/fixasync.js:21:10)
    at Object.FHEM_getClientFunctions (/usr/lib/node_modules/gassistant-fhem/lib/remote-localhandleEXECUTE.js:18:5)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)


Ich habe heute mal den gAssistant eingerichtet und der lief im Docker.
Versionen bei Auslieferung
node -v: v14.18.1
npm -v: 8.1.0

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 Oktober 2021, 18:52:36
Zitat von: CoolTux am 21 Oktober 2021, 08:39:43
Ich habe heute mal den gAssistant eingerichtet und der lief im Docker.
Versionen bei Auslieferung
node -v: v14.18.1
npm -v: 8.1.0
Ich habe einen komplett neuen Container angelegt. Ohne irgend einer Config. Def siehe unten als List. Definition selber bringt noch keinen Fehler, erst wenn man den Auth-Code einträgt. Man kann dann auch nichts schalten.

Reden wir vom selben Docker Image? docker pull ghcr.io/fhem/fhem-experimental:dev ... oder hast du ein anderes Tag?


Internals:
   CFGFN     
   FD         9
   FUUID      6171982d-f33f-7fa4-9c60-d3343d548af4ffac
   LAST_START 2021-10-21 18:42:44
   LAST_STOP  2021-10-21 18:42:44
   NAME       gassistant
   NOTIFYDEV  global,global:npmjs.*gassistant-fhem.*
   NR         35
   NTFY_ORDER 50-gassistant
   PID        7306
   STARTS     3
   STATE      login failed, please retry
   TYPE       gassistant
   currentlogfile ./log/gassistant-2021-10-21.log
   logfile    ./log/gassistant-%Y-%m-%d.log
   CoProcess:
     cmdFn      gassistant_getCMD
     name       gassistant-fhem
     state      running /usr/bin/gassistant-fhem
   READINGS:
     2021-10-21 18:42:44   gassistant-fhem running /usr/bin/gassistant-fhem
     2021-10-21 18:42:49   gassistant-fhem-connection login failed, please retry
     2021-10-21 18:42:46   gassistant-fhem-lastServerError none
     2021-10-21 18:42:49   gassistant-fhem-lasterror ReferenceError: exports is not defined
     2021-10-21 18:42:48   gassistant-fhem-localHome inactive
     2021-10-21 18:42:13   gassistant-fhem-uid google-oauth2|100018623537520537581
     2021-10-21 18:42:46   gassistant-fhem-version 3.0.4
     2021-10-21 18:42:46   gassistant-fhem-versionAvailable 3.0.4
     2021-10-21 18:42:46   gassistantFHEM.loginURL rect_uri=https://europe-west1-fhem-ga-connector.cloudfunctions.net/codelanding/start_xxxxxxxxxxxxx___rest_aus_ge_xx_t" target="_blank">Click here to login (new window/tab)</a><br></html>
     2021-10-21 18:42:12   gassistantFHEM.refreshToken crypt:xxxxxxxxxxxxxxxx_aus_ge_xx_t
Attributes:
   devStateIcon { my $error = ReadingsVal($name,"gassistant-fhem-lastServerError","none") eq "none"?"10px-kreis-gruen":"10px-kreis-rot";; my $onoff = substr(ReadingsVal($name, "gassistant-fhem", "running"),0,7) eq "running"?"control_on_off\@green":"control_on_off\@red";; my $reload = ReadingsVal($name, "gassistant-fhem-connection", "connected") eq "connected"?"audio_repeat\@green":"audio_repeat\@orange";;"<div><a>".FW_makeImage($error)."</a> <a href=\"/fhem?cmd.dummy=set $name reload&XHR=1\">".FW_makeImage($reload, "reload")."</a><a href=\"/fhem?cmd.dummy=set $name restart&XHR=1\">&nbsp;&nbsp;".FW_makeImage($onoff, "restart")."</a></div>"}
   gassistantFHEM-config ./gassistant-fhem.cfg
   gassistantFHEM-log ./log/gassistant-%Y-%m-%d.log
   icon       gassistant
   nrarchive  10
   room       GoogleAssistant
   stateFormat gassistant-fhem-connection


Selber Fehler im gassistant log

ReferenceError [Error]: exports is not defined
    at eval (eval at apply (/usr/lib/node_modules/gassistant-fhem/node_modules/vm2/lib/fixasync.js:21:10), <anonymous>:1:1)
    at eval (<anonymous>)
    at Object.apply (/usr/lib/node_modules/gassistant-fhem/node_modules/vm2/lib/fixasync.js:21:10)
    at Object.FHEM_getClientFunctions (/usr/lib/node_modules/gassistant-fhem/lib/remote-localhandleEXECUTE.js:18:5)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 Oktober 2021, 19:07:00
Ah verstehe. So weit war ich leider nicht. Dann muss ich mir das genauer anschauen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 Oktober 2021, 19:35:14
Zitat von: CoolTux am 21 Oktober 2021, 19:07:00
Ah verstehe. So weit war ich leider nicht. Dann muss ich mir das genauer anschauen.

Das Problem ist im gassistant Thread auf Raspi, Linux Host ohne Docker (glaub ich), in "deinem" Container aufgetreten ... liegt nicht speziell an Docker.

Was komisch ist, wenn ich den Container von volschin nutze und dann am os node, und aus fhem npm auf 8.1 upgrade dann läuft gassistant weiterhin.

Ich vermute, dass es Probleme nur gibt wenn initial gleich mit npm 8.1 und der aktuellsten node-Version gestartet wird. Da muss dominik mal drauf schauen. Vielleicht wird bei älteren Installer was mit installiert was beim aktuellsten nicht mehr dabei ist.

Sollte auch nur ein Hinweis sein, keine Aufforderung dass du es lösen sollst.

Versionen von volschin nach der Erstellung des Containers

npm -v
7.20.6
node -v
v14.17.5


nach Upgrade und gassistant funktioniert weiterhin

node -v
v14.18.1
npm -v
8.1.0

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fermoll am 21 Oktober 2021, 23:18:37
Seit einigen Tagen habe ich meine FHEM Installation von einem RPI 3B auf meine Synology DS 1621+ mit 32 GB Ram in Docker verlagert. Verwendet wird Diskmanger 7 (DSM 7).
Das ist insofern interessant, dass keine USB -Sticks mehr verwendet werden können. außerdem ist der Systemzugriff fast unmöglich, so dass die FHEMConfig nicht kopiert werden konnte. Der Zugriff auf die MAX!Cubes, CUNO (Lan) war eigentlich problemlos, nachdem ich die MAX! Konfiguration mit der MAX! Local Application reorganisiert hatte. Auch den Cuno (LAN Cul) konnte ich in Betrieb nehmen. Allerdings habe ich vor, die S300TH Thermometer durch Wemos DHT 22 zu ersetzen. Das war auch reletiv problemlos möglich, bis auf die Möglichkeit, mehrere Sensoren an einem Wemos zu verwenden.
Wenn man den Devices einen Namen gibt, werden bei autocreate die entsprechenden Devices eingerichtet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 22 Oktober 2021, 13:22:30
Verstehe jetzt nur nicht: Hast Du ein Problem oder Nicht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fermoll am 22 Oktober 2021, 15:07:54
Die Probleme habe ich erst einmal gelöst. Es läuft auf dem Docker bisher sehr gut. Ein großer Unterschied zum RPI 3.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 23 Oktober 2021, 12:27:07
Ich baue mal ein Dockerimage wo explizit Version 3.0.3 installiert wird. Melde mich wenn ich soweit bin.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 23 Oktober 2021, 13:11:40
Hat nichts gebracht, damit startet gassistant-fhem erst gar nicht. Bringt nur Fehlermeldungen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 23 Oktober 2021, 14:49:31
Dürfte aber nicht am Docker, sondern an den Packeten liegen .. oder?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 23 Oktober 2021, 14:50:05
Zitat von: Wernieman am 23 Oktober 2021, 14:49:31
Dürfte aber nicht am Docker, sondern an den Packeten liegen .. oder?

Ich gehe auch davon aus daß es an den Paketen liegt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 23 Oktober 2021, 14:58:50
Zitat von: CoolTux am 23 Oktober 2021, 14:50:05
Ich gehe auch davon aus daß es an den Paketen liegt.

Wie weiter oben geschrieben, in gassistant Thread ist der Fehler nativ auf Raspi, Linux Host sowie dem test-Docker von dir. Es war nur ein Hinweis da ältere Docker das Problem nicht hatten. Ggf. neueste node Version wenn initial damit begonnen wurde und nicht per Update von älterer Version.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 Oktober 2021, 13:45:49
Hallo zusammen,
ich möchte nun das erste mal im FHEM container npm und node verwenden. Dazu habe ich mich im container angemeldet und npm ist weder unter root noch unter fhem zu finden.


root@raspberrypi:/opt/fhem# node --version
v10.24.1
root@raspberrypi:/opt/fhem# npm --version
bash: npm: command not found
root@raspberrypi:/opt/fhem#

root@raspberrypi:/opt/fhem# sudo su - fhem
fhem@raspberrypi:~$ node --version
v10.24.1
fhem@raspberrypi:~$ npm --version
-bash: npm: command not found
fhem@raspberrypi:~$


verbose 5 log

2021.10.26 13:43:50.695 5: npmjs (fhemServerNpm) - Notify: [
  'ATTR fhemServerNpm verbose 5'
]

echo n | LC_ALL=C node -e "console.log(JSON.stringify(process.versions));" 2>&1
2021.10.26 13:44:08.451 5: npmjs (fhemServerNpm) - Notify: [
  'state: command \'npm getNodeVersion\' in progress'
]

2021.10.26 13:44:08.456 4: npmjs (fhemServerNpm) - execute command asynchronously (PID= 16779)
2021.10.26 13:44:08.458 4: npmjs (fhemServerNpm) - control passed back to main loop.
2021.10.26 13:44:09.458 4: npmjs (fhemServerNpm) - got result from asynchronous parsing.
2021.10.26 13:44:09.458 4: npmjs (fhemServerNpm) - asynchronous finished.
2021.10.26 13:44:09.459 4: npmjs (fhemServerNpm) - clean Subprocess
2021.10.26 13:44:09.459 4: npmjs (fhemServerNpm) - JSON: {"versions":{"openssl":"1.1.1k","v8":"6.8.275.32-node.59","zlib":"1.2.11","brotli":"1.0.7","napi":"7","modules":"64","icu":"64.2","nghttp2":"1.41.0","unicode":"12.1","cldr":"35.1","ares":"1.15.0","uv":"1.34.2","tz":"2019c","http_parser":"2.9.4","node":"10.24.1"}}
2021.10.26 13:44:09.459 4: npmjs (fhemServerNpm) - Write Readings
2021.10.26 13:44:09.460 5: npmjs (fhemServerNpm) - {
  'versions' => {
                  'ares' => '1.15.0',
                  'brotli' => '1.0.7',
                  'cldr' => '35.1',
                  'http_parser' => '2.9.4',
                  'icu' => '64.2',
                  'modules' => '64',
                  'napi' => '7',
                  'nghttp2' => '1.41.0',
                  'node' => '10.24.1',
                  'openssl' => '1.1.1k',
                  'tz' => '2019c',
                  'unicode' => '12.1',
                  'uv' => '1.34.2',
                  'v8' => '6.8.275.32-node.59',
                  'zlib' => '1.2.11'
                }
}

2021.10.26 13:44:09.536 5: npmjs (fhemServerNpm) - Notify: [
  'state: npm is up to date'
]

2021.10.26 13:44:09.540 4: npmjs (fhemServerNpm) - stateRequestTimer: Call Request Timer


VG
    Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 26 Oktober 2021, 14:11:49
Welches Image verwendest Du denn?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 Oktober 2021, 14:24:03
Zitat von: CoolTux am 26 Oktober 2021, 14:11:49
Welches Image verwendest Du denn?


  fhem:
    image: fhem/fhem:latest
    restart: always
    network_mode: host
    privileged: true
#    devices:
#      - "/dev/ttyACM0:/dev/ttyACM0"
    volumes:
      - "./core/:/opt/fhem/"

    environment:
      PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"
      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare XML::Bare Protocol::WebSocket::Handshake::Server Crypt::Rijndael Crypt::Random --verbose"
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin

    depends_on:
      - "mysql"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 26 Oktober 2021, 14:31:23
Hallo Christian,

wenn Du mich fragst, bist Du nicht im Container sondern in deinem raspberry  ::)
Zitatroot@raspberrypi ...

Und dafür, dass Du "das erste mal ..." bist Du aber gleich auf das ganz dünne Brett gestiegen:  :o
Zitatnetwork_mode: host
    privileged: true

Vielleicht zum Einstieg: https://heinz-otto.blogspot.com/2021/01/container-schiff.html
https://heinz-otto.blogspot.com/2021/06/docker-ein-kleiner-schnellstart-workshop.html

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 Oktober 2021, 14:36:31
Zitat von: Otto123 am 26 Oktober 2021, 14:31:23
Hallo Christian,

wenn Du mich fragst, bist Du nicht im Container sondern in deinem raspberry  ::)
Und dafür, dass Du "das erste mal ..." bist Du aber gleich auf das ganz dünne Brett gestiegen:  :o
Gruß Otto

Docker verwende ich bereits 2 Jahre ;-)
Das network brauche ich wegen des SMA EM broadcast.

Und der Prompt ist aus dem docker portainer connect, also wirklich im Container.

EDIT:
Für Tipps bin ich natürlich immer offen...

Gruß
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 26 Oktober 2021, 14:40:17
Sorry - wollte Dir nicht zu nahe treten :) ich hatte es halt anders verstanden

Also bei mir sieht es im Portainer Prompt so aus:
root@f607fa6b2809:/opt/fhem# npm -v
7.21.0
root@f607fa6b2809:/opt/fhem# node -v
v10.24.1
root@f607fa6b2809:/opt/fhem#

Das Image ist das gleiche :)

Ich erinnere mich aber gerade, da war mal etwas nach einem Update kaputt - einfach container zerstören und neu laden. Dann war alles wieder da. Das update von npm und node war danach etwas tricky.
Aber deshalb bastelt ja Marco gerade was neues?

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 Oktober 2021, 14:46:24
Zitat von: Otto123 am 26 Oktober 2021, 14:40:17
Sorry - wollte Dir nicht zu nahe treten :) ich hatte es halt anders verstanden
Alles gut, ich lerne immer gerne dazu.

Zitat
Also bei mir sieht es im Portainer Prompt so aus:
root@f607fa6b2809:/opt/fhem# npm -v
7.21.0
root@f607fa6b2809:/opt/fhem# node -v
v10.24.1
root@f607fa6b2809:/opt/fhem#

Das Image ist das gleiche :)

Ich erinnere mich aber gerade, da war mal etwas nach einem Update kaputt - einfach container zerstören und neu laden. Dann war alles wieder da. Das update von npm und node war danach etwas tricky. Aber deshalb bastelt ja Marco gerade was neues?
Ich meine heute auch beim ersten mal eine Version für npm angezeigt bekommen zu haben. Da lief aber wohl noch der update des containers.
Jetzt wird ja noch nicht mal mehr das npm command gefunden.

Selbst ein "find / -name npm" im container findet nichts mehr.

EDIT: Noch ein List

Internals:
   DEF        localhost
   FUUID      5dff997f-f33f-61a8-4367-b3d6be3a0868cc30
   FVERSION   42_npmjs.pm:v1.1.6-s20933/2020-01-10
   HOST       localhost
   NAME       fhemServerNpm
   NOTIFYDEV  global,fhemServerNpm
   NR         20
   NTFY_ORDER 50-fhemServerNpm
   STATE      npm is up to date
   TYPE       npmjs
   READINGS:
     2021-10-26 13:41:59   installed       error
     2021-07-09 09:22:33   nodejsVersion   10.24.1
     2021-10-26 13:42:19   outdated        check failed
     2021-10-26 13:44:09   state           npm is up to date
     2021-06-04 13:52:59   updated         successful
     2021-10-26 13:05:17   updatesAvailable 0
   helper:
     lastSync   2021-10-26
Attributes:
   DbLogExclude .*
   alias      Node.js Package Update Status
   devStateIcon npm.updates.available:security@red:outdated npm.is.up.to.date:security@green:outdated .*npm.outdated.*in.progress:system_fhem_reboot@orange .*in.progress:system_fhem_update@orange warning.*:message_attention@orange error.*:message_attention@red
   group      Update
   icon       npm-old
   room       System
   verbose    5
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 26 Oktober 2021, 14:53:21
Sag ich doch :)
https://forum.fhem.de/index.php/topic,89745.msg1164963.html#msg1164963
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 Oktober 2021, 14:56:51
Zitat von: Otto123 am 26 Oktober 2021, 14:53:21
Sag ich doch :)
https://forum.fhem.de/index.php/topic,89745.msg1164963.html#msg1164963
Hmm, dann habe ich ja wieder den alten Container und muss den wieder updaten.
Soll ich da nicht besser warten, bis es einen aktuelleren container gibt? Ihr seid doch da dran :-)

Gibt es für RPI einen separaten node red container? Das wäre doch eine alternative, oder sehe ich das falsch?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 26 Oktober 2021, 15:00:30
Wie meinst Du das? Dein FHEM bleibt so wie es ist, systemupdate kannst Du fahren - da passiert node und npm nichts.
Brauchst Du denn dringend die neueste node und npm Version?
Ich meine, Du kannst node und npm auf Kommandozeile aktualisieren und alles ist gut - ganz sicher bin ich nicht mehr. Ist eine Weile her als ich das versucht habe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 Oktober 2021, 15:04:59
Zitat von: Otto123 am 26 Oktober 2021, 15:00:30
Wie meinst Du das? Dein FHEM bleibt so wie es ist, systemupdate kannst Du fahren - da passiert node und npm nichts.
Brauchst Du denn dringend die neueste node und npm Version?
Ich glaube die Version ist eh schon neuer, ich fang ja gerade erst an mit npm.
Den Update von npm hatte ich nur angestoßen, weil der Container das als rot gezeigt hatte und bevor ich mit eztwas neuem anfange aktualisiere ich eigentlich immer erst.

EDIT: mal als Rückmeldung...
Ich habe jetzt einfach den node-red Docker Container verwendet. Damit lief dann alles in sehr kurzer Zeit und ist noch zusätzlich vom FHEM isoliert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 November 2021, 10:13:08
Zitat von: kadettilac89 am 23 Oktober 2021, 14:58:50
Wie weiter oben geschrieben, in gassistant Thread ist der Fehler nativ auf Raspi, Linux Host sowie dem test-Docker von dir. Es war nur ein Hinweis da ältere Docker das Problem nicht hatten. Ggf. neueste node Version wenn initial damit begonnen wurde und nicht per Update von älterer Version.

@CoolTux, mit einer neuen Version von gassistant-fhem (3.0.5) ist das Problem behoben. Habe den Container im Einsatz und sonst keine Probleme oder Auffälligkeiten gesehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 03 November 2021, 15:41:15
Dann werde ich mal ein neues Image erstellen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 12 November 2021, 09:23:11
Weiß jemand ob man die Default Bridge von Docker attachable machen kann?

Ich würde gerne feste Bridge IP Adressen vergeben.
Hab jetzt schon das Problem, dass sich immer mal wieder die IP mysql Datenbank ändert, wenn ein Update installiert worden ist.
Dann kann man immer in allen Containern die IP anpassen.

Danke und Grüße Robert
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 November 2021, 11:15:25
Du müsstest auch den Containernamen als DNS Namen verwenden können ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 12 November 2021, 11:16:02
Du meinst feste IP vergeben?
https://docs.docker.com/compose/networking/
ZitatNetworks can be configured with static IP addresses by setting the ipv4_address and/or ipv6_address for each attached network.
Oder: besser mit Namen arbeiten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 12 November 2021, 11:17:42
Zitat von: Wernieman am 12 November 2021, 11:15:25
Du müsstest auch den Containernamen als DNS Namen verwenden können ....
Zitat von: Wernieman am 12 November 2021, 11:15:25
Du müsstest auch den Containernamen als DNS Namen verwenden können ....

Daran hab ich noch garnicht gedacht.
Einfach den DNS Namen nehmen anstatt einer festen IP.
Dass muss ich dann gleich mal ausprobieren.

Danke für den Tip.

Grüße Robert
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 12 November 2021, 11:27:48
Zitat von: Otto123 am 12 November 2021, 11:16:02
Du meinst feste IP vergeben?
https://docs.docker.com/compose/networking/Oder: besser mit Namen arbeiten.

Das mit den festen IP Adressen geht nicht bei der default bridge, die hat diese Funktion nicht aktiviert.
jetzt hab ich es einfach mal mit dem Hostnamen des Datenbank Server genommen, aber Nextcloud als Beispiel hat da keine Lust zu.
Hat die default bridge einen DNS Server standardmäßig aktiviert?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 November 2021, 11:44:33
Docker hat Defaultmäßig einen DNS-Server

Sind die Container einzeln hochgezogen oder per docker-compose.yml?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 12 November 2021, 11:46:47
Zitat von: Wernieman am 12 November 2021, 11:44:33
Docker hat Defaultmäßig einen DNS-Server

Sind die Container einzeln hochgezogen oder per docker-compose.yml?

Ich arbeite mit portainer.
Ob es daran liegt, ich schau mal ob sich etwas finden lässt.

Grüße Robert
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 November 2021, 11:56:56
Auch mit Portainer ist die Frage: Wie ziehst Du die Container hoch?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 12 November 2021, 12:02:02
Zitat von: Wernieman am 12 November 2021, 11:56:56
Auch mit Portainer ist die Frage: Wie ziehst Du die Container hoch?
Mit Portainer über deren die Gui.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 November 2021, 12:56:50
Portainer kann auch mit docker-compose.yml umgehen. Aber so wie ich Dich verstanden habe, hast Du die Container einzeln "eingezogen".

D.h. dann auch EINEN MySQL für ALLE Container?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 12 November 2021, 13:17:36
Zitat von: Wernieman am 12 November 2021, 12:56:50
Portainer kann auch mit docker-compose.yml umgehen. Aber so wie ich Dich verstanden habe, hast Du die Container einzeln "eingezogen".

D.h. dann auch EINEN MySQL für ALLE Container?

ich hab über die portainer gui aktuell nur einen mysql container angelegt und der ist für nextcloud gerade zuständig.
Wenn ich jetzt bei Portainer nur den hostname beim erstellen einen containers eintrage, dann nimmt das system wohl den DNS des Docker host.
Sobald ich einen DNS Ip für den Docker host nehme, wird dieser übernommen.
Aber ich kann mit den Hostnamen der Container immer noch nicht arbeiten.
Selbst ein Ping sagt bad address ping: bad address 'mysql'
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 November 2021, 13:51:23
Wie hast Du denn den Container genannt?

Und vom Host ist der Container auch nicht per DNS erreichbar ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 12 November 2021, 14:55:33
Zitat von: Wernieman am 12 November 2021, 13:51:23
Wie hast Du denn den Container genannt?

Und vom Host ist der Container auch nicht per DNS erreichbar ...

das ist es je gerade, egal wie ich ihn nenne, da wird kein name aufgelöst.
Hat Docker da einen eigenen DNS?

Also ich hab nun einen container extra für den nextcloud-mysql, hostname in der netzwerkconfig bei portainer angegeben lautet: nextcloud-docker

Hier auch der Auszug was docker container ls ausgibt.
Aber auch die Container ID ist nicht auflösbar.
CONTAINER ID   IMAGE                                 COMMAND                  CREATED             STATUS                 PORTS                                                                                                                                                             NAMES
49543b827073   mysql:latest                          "docker-entrypoint.s..."   About an hour ago   Up About an hour       3306/tcp, 33060/tcp                                                                                                                                               fhem-mysql
514867ed430b   mysql:latest                          "docker-entrypoint.s..."   2 hours ago         Up About an hour       3306/tcp, 33060/tcp                                                                                                                                               nextcloud-mysql
2d8bd61b34f4   linuxserver/nextcloud:latest          "/init"                  3 hours ago         Up About an hour       80/tcp, 0.0.0.0:7500->443/tcp, :::7500->443/tcp                                                                                                                   nextcloud
d7ba0ff246ed   oznu/homebridge:ubuntu                "/init"                  30 hours ago        Up 30 hours                                                                                                                                                                              homebridge
e1dfd63848b3   linuxserver/unifi-controller:latest   "/init"                  2 days ago          Up 2 days                                                                                                                                                                                unifi
e00c6ec64a20   linuxserver/plex:latest               "/init"                  2 days ago          Up 2 days                                                                                                                                                                                plex
34a524951e0a   rednoah/filebot:node                  "/opt/bin/run-as-use..."   3 days ago          Up 3 days              0.0.0.0:5452->5452/tcp, :::5452->5452/tcp                                                                                                                         filebot-node
3930eeaeed65   checkmk/check-mk-raw:2.0.0-latest     "/docker-entrypoint...."   7 days ago          Up 7 days (healthy)    0.0.0.0:6556->6556/tcp, :::6556->6556/tcp, 6557/tcp, 0.0.0.0:7200->5000/tcp, :::7200->5000/tcp                                                                    checkmk
02a2531b7a0c   portainer/portainer-ce:latest         "/portainer"             2 weeks ago         Up 2 weeks             0.0.0.0:8000->8000/tcp, :::8000->8000/tcp, 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp, 9443/tcp                                                                    portainer
9c8662295647   pihole/pihole:latest                  "/s6-init"               2 weeks ago         Up 2 weeks (healthy)                                                                                                                                                                     pihole
bd8b74257b1e   whyet/awtrix2:latest                  "/entrypoint.sh"         3 weeks ago         Up 5 days              0.0.0.0:7010->7000/tcp, :::7010->7000/tcp, 0.0.0.0:7011->7001/tcp, :::7011->7001/tcp                                                                              awtrix-1-keller
146665a74929   whyet/awtrix2:latest                  "/entrypoint.sh"         3 weeks ago         Up 7 hours             0.0.0.0:7000-7001->7000-7001/tcp, :::7000-7001->7000-7001/tcp                                                                                                     awtrix-0-bad
6d3be63d25ac   containrrr/watchtower:latest          "/watchtower"            8 weeks ago         Up 2 weeks             8080/tcp                                                                                                                                                          watchtower
1376a1311e36   ecodms/ecodms:latest                  "/opt/ecodms/ecodmss..."   2 months ago        Up 2 weeks             0.0.0.0:17001-17002->17001-17002/tcp, :::17001-17002->17001-17002/tcp, 0.0.0.0:17004->8080/tcp, :::17004->8080/tcp, 0.0.0.0:17005->8180/tcp, :::17005->8180/tcp   ecodms
426127cd224c   linuxserver/tvheadend:release-4.2     "/init"                  3 months ago        Up 2 weeks                                                                                                                                                                               tvheadend
85af6ea95aaa   jlesage/jdownloader-2:latest          "/init"                  3 months ago        Up 2 weeks             0.0.0.0:3129->3129/tcp, :::3129->3129/tcp, 5900/tcp, 0.0.0.0:7300->5800/tcp, :::7300->5800/tcp                                                                    jdownloader2

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 12 November 2021, 14:59:47
Da ich immer mit docker-compose, also ohne Portainer, unterwegs bin, kann ich Dir aktuell auch nicht sagen, was das Problem ist .... hier funktioniert es. Allerdings sind auch alle Container von einem Projekt in einer docker-compose.yml ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 12 November 2021, 15:03:25
Zitat von: Wernieman am 12 November 2021, 14:59:47
Da ich immer mit docker-compose, also ohne Portainer, unterwegs bin, kann ich Dir aktuell auch nicht sagen, was das Problem ist .... hier funktioniert es. Allerdings sind auch alle Container von einem Projekt in einer docker-compose.yml ....

Hast du ein einges Netzwerk erstellt wo alle drauf laufen oder hast du die docker default bridge genommen?
Kannst du vielleicht mal folgende ausgäbe von dir posten: docker network inspect bridge
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 13 November 2021, 09:18:10
Also mit docker-compose.yml kannst auch jeden einzelnen container auch ein eigenes docker-compose.yml geben und z.B. mariadb mit dem namen den du dem container gegeben hast problemlos ansprechen vorausgesetzt du hast ein network das jedem container der es benutzen soll auch bekannt gegeben.
Bei mir funktioniert das ohne Probleme.
gruß anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 13 November 2021, 09:45:29
Zitat von: antonwinden am 13 November 2021, 09:18:10
Also mit docker-compose.yml kannst auch jeden einzelnen container auch ein eigenes docker-compose.yml geben und z.B. mariadb mit dem namen den du dem container gegeben hast problemlos ansprechen vorausgesetzt du hast ein network das jedem container der es benutzen soll auch bekannt gegeben.
Bei mir funktioniert das ohne Probleme.
gruß anton

Danke für deine Antwort.

So noch mal für dumme, hat docker auf seiner internen default bridge eine eigene DNS am laufen?
Docker kopiert ja standard mäßig die DNS Einstellungen vom Host zu den Container.
Das würde dann bedeuten dass docker Container meinen LAN internen DNS benutzt.

Was meinst du genau mit "bekannt gegeben"

Danke und Grüß Robert
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 13 November 2021, 10:13:34
sql und der container der in sql was abspeichern soll müssen sich im gleichen "network" bewegen. bei mir schaut das so aus:
version: '3'

services:

###fhem

   fhem:
     container_name: fhem
     restart: always
     privileged: true
     image: fhem/fhem:dev
     ports:
       - "8083:8083"
       - "8084:8084"
       - "8087:8087"
       - "1882:1882"
     networks:
       - datenbank
       - traefik_proxy
     volumes:
       - /mnt/DiskA/fhem:/opt/fhem
     devices:
       - /dev/bus/usb/001/002
     environment:
     # test 17-10-21
#        - NPM_PKGS: "npm@8.1.0"
        - FHEM_PERM_DIR=0777
#       - APT_PKGS="libjson-perl libmp3-info-perl libnet-upnp-perl"
#       - CPAN_PKGS="MP3::Info"
     labels:
       - "autoheal=true"
       - "traefik.enable=true"
       - "traefik.backend=fhem"
       - "traefik.frontend.rule=Host:fhem.xxxx.eu"
       - "traefik.port=8083"
       - "traefik.docker.network=traefik_proxy"
       - "traefik.frontend.headers.SSLRedirect=true"
       - "traefik.frontend.headers.STSSeconds=315360000"
       - "traefik.frontend.headers.browserXSSFilter=true"
       - "traefik.frontend.headers.contentTypeNosniff=true"
       - "traefik.frontend.headers.forceSTSHeader=true"
       - "traefik.frontend.headers.SSLHost=xxx.eu"
       - "traefik.frontend.headers.STSIncludeSubdomains=true"
       - "traefik.frontend.headers.STSPreload=true"
       - "traefik.frontend.headers.frameDeny=true"

networks:
  datenbank:
    external: true
  traefik_proxy:
    external: true

fhem speichert dann in mariadb:
version: "3.7"

services:

  mariadb:
    image: mariadb:10.5
#    image: mariadb:latest
    container_name: mariadb
    restart: always
    expose:
      - 3306
    ports:
      - 3306:3306
    networks:
       - datenbank
    volumes:
      - /mnt/DiskA/mariadb/daten:/var/lib/mysql
    environment:
      - MARIADB_ROOT_PASSWORD=29Anton06
      - TZ=Europe/Vienna
#keine Ahnung ob folgendes geht:
#    healthcheck:
#      test: ["CMD", "mysqladmin", "ping", "--silent"]

  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    container_name: phpmyadmin
    restart: unless-stopped
    ports:
      - 8081:80
    networks:
       - datenbank
       - traefik_proxy
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=mariadb
    depends_on:
      - mariadb
    labels:
      - "traefik.enable=true"
      - "traefik.backend=dbadmin"
      - "traefik.frontend.rule=Host:dbadmin.xxxx.eu"
      - "traefik.port=80"
      - "traefik.docker.network=traefik_proxy"
      - "traefik.frontend.headers.SSLRedirect=true"
      - "traefik.frontend.headers.STSSeconds=315360000"
      - "traefik.frontend.headers.browserXSSFilter=true"
      - "traefik.frontend.headers.contentTypeNosniff=true"
      - "traefik.frontend.headers.forceSTSHeader=true"
      - "traefik.frontend.headers.SSLHost=xxx.eu"
      - "traefik.frontend.headers.STSIncludeSubdomains=true"
      - "traefik.frontend.headers.STSPreload=true"
      - "traefik.frontend.headers.frameDeny=true"

networks:
  datenbank:
    external: true
  traefik_proxy:
    external: true

datenbank ist dann das network für fhem und mariadb damit fhem auf mariadb zugreifen kann mit der definition:
%dbconfig= (
connection => "mysql:database=fhem;host=mysql;port=3306",
user => "fhemxxx",
password => "xxxxxx"
);

und für jeden weiteren container der auf mariadb zugreift...
gruß anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 13 November 2021, 10:20:31
Zitat von: antonwinden am 13 November 2021, 10:13:34
sql und der container der in sql was abspeichern soll müssen sich im gleichen "network" bewegen. bei mir schaut das so aus:
version: '3'

services:

###fhem

   fhem:
     container_name: fhem
     restart: always
     privileged: true
     image: fhem/fhem:dev
     ports:
       - "8083:8083"
       - "8084:8084"
       - "8087:8087"
       - "1882:1882"
     networks:
       - datenbank
       - traefik_proxy
     volumes:
       - /mnt/DiskA/fhem:/opt/fhem
     devices:
       - /dev/bus/usb/001/002
     environment:
     # test 17-10-21
#        - NPM_PKGS: "npm@8.1.0"
        - FHEM_PERM_DIR=0777
#       - APT_PKGS="libjson-perl libmp3-info-perl libnet-upnp-perl"
#       - CPAN_PKGS="MP3::Info"
     labels:
       - "autoheal=true"
       - "traefik.enable=true"
       - "traefik.backend=fhem"
       - "traefik.frontend.rule=Host:fhem.xxxx.eu"
       - "traefik.port=8083"
       - "traefik.docker.network=traefik_proxy"
       - "traefik.frontend.headers.SSLRedirect=true"
       - "traefik.frontend.headers.STSSeconds=315360000"
       - "traefik.frontend.headers.browserXSSFilter=true"
       - "traefik.frontend.headers.contentTypeNosniff=true"
       - "traefik.frontend.headers.forceSTSHeader=true"
       - "traefik.frontend.headers.SSLHost=xxx.eu"
       - "traefik.frontend.headers.STSIncludeSubdomains=true"
       - "traefik.frontend.headers.STSPreload=true"
       - "traefik.frontend.headers.frameDeny=true"

networks:
  datenbank:
    external: true
  traefik_proxy:
    external: true

fhem speichert dann in mariadb:
version: "3.7"

services:

  mariadb:
    image: mariadb:10.5
#    image: mariadb:latest
    container_name: mariadb
    restart: always
    expose:
      - 3306
    ports:
      - 3306:3306
    networks:
       - datenbank
    volumes:
      - /mnt/DiskA/mariadb/daten:/var/lib/mysql
    environment:
      - MARIADB_ROOT_PASSWORD=29Anton06
      - TZ=Europe/Vienna
#keine Ahnung ob folgendes geht:
#    healthcheck:
#      test: ["CMD", "mysqladmin", "ping", "--silent"]

  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    container_name: phpmyadmin
    restart: unless-stopped
    ports:
      - 8081:80
    networks:
       - datenbank
       - traefik_proxy
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=mariadb
    depends_on:
      - mariadb
    labels:
      - "traefik.enable=true"
      - "traefik.backend=dbadmin"
      - "traefik.frontend.rule=Host:dbadmin.xxxx.eu"
      - "traefik.port=80"
      - "traefik.docker.network=traefik_proxy"
      - "traefik.frontend.headers.SSLRedirect=true"
      - "traefik.frontend.headers.STSSeconds=315360000"
      - "traefik.frontend.headers.browserXSSFilter=true"
      - "traefik.frontend.headers.contentTypeNosniff=true"
      - "traefik.frontend.headers.forceSTSHeader=true"
      - "traefik.frontend.headers.SSLHost=xxx.eu"
      - "traefik.frontend.headers.STSIncludeSubdomains=true"
      - "traefik.frontend.headers.STSPreload=true"
      - "traefik.frontend.headers.frameDeny=true"

networks:
  datenbank:
    external: true
  traefik_proxy:
    external: true

datenbank ist dann das network für fhem und mariadb damit fhem auf mariadb zugreifen kann mit der definition:
%dbconfig= (
connection => "mysql:database=fhem;host=mysql;port=3306",
user => "fhemxxx",
password => "xxxxxx"
);

und für jeden weiteren container der auf mariadb zugreift...
gruß anton

Das heist aber du hast ein eigens Netzwerk erstell welches "Datenbank" heist?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 13 November 2021, 11:03:02
genau denn irgendwie müssen die container ja miteinander kommunizieren :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 November 2021, 12:08:09
Und es ist gut, wenn z.B. die DB nur von den Containern erreicht werden kann, welche sie erreichen können müssen. Erhöht die Sicherheit ;o)

@no_Legend
.. warum vergibst Du der DB externe Ports? Die brauchst Du nicht, wenn Du von intern kommst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 13 November 2021, 12:11:36
Zitat von: Wernieman am 13 November 2021, 12:08:09
Und es ist gut, wenn z.B. die DB nur von den Containern erreicht werden kann, welche sie erreichen können müssen. Erhöht die Sicherheit ;o)

@no_Legend
.. warum vergibst Du der DB externe Ports? Die brauchst Du nicht, wenn Du von intern kommst.

Okay verstanden. Das bedeutet aber auch das. An eigentlich kein Gateway für eine reines "Datenbank" Netz?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 November 2021, 12:15:53
ZitatDas bedeutet aber auch das. An eigentlich kein Gateway für eine reines "Datenbank" Netz?

Sorry, aber das habe ich nicht verstanden.

Um es mal kurzzufassen:

Du hast ein DB Netz, welches bekanntlich nur von den Docker-Containern im gleichen Netz erreichbar sein muß. Deshalb brauchst Du eben keine Port-Angabe, weil damit ein Externer Port dem Internen Port "gleichgeschaltet" *) wird. Hat dann auch den Vorteil, das aus Deinem Externen Netz (Hier Extern = Hausnetzt) die DB nicht erreichbar ist. Erreichbar = Nicht manipulierbar.

Auch wenn Container KEINE VM sind, betrachte es mal aus einer VM Sicht.

*) Sorry für dieses Wort (Aus historischen gründen), weiß aber gerade kein besseres.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 13 November 2021, 12:18:05
Zitat von: no_Legend am 13 November 2021, 09:45:29
So noch mal für dumme, hat docker auf seiner internen default bridge eine eigene DNS am laufen?
Hallo Robert,
ich denke nein, steht eigentlich hier: https://docs.docker.com/config/containers/container-networking/

Definierst Du ein Netzwerk, dann läuft dort ein eigener DNS :)

Gruß Otto

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 13 November 2021, 12:24:20
Zitat von: Otto123 am 13 November 2021, 12:18:05
Hallo Robert,
ich denke nein, steht eigentlich hier: https://docs.docker.com/config/containers/container-networking/

Definierst Du ein Netzwerk, dann läuft dort ein eigener DNS :)

Gruß Otto

Ah Otto danke. Genau das war das Problem.
Auf der default bridge läuft keine DNS Dienst als default.
Mit einer eigens erstellter Bridge funktioniert es nun.

Danke und Grüße Robert
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 November 2021, 12:40:23
O.K. . da ich immer für jedes Projekt ein eigenes Netzwerk verwende, bin ich nicht mehr darauf gekommen ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 13 November 2021, 12:52:36
Zitat von: Wernieman am 13 November 2021, 12:40:23
O.K. . da ich immer für jedes Projekt ein eigenes Netzwerk verwende, bin ich nicht mehr darauf gekommen ....
Ich muss jetzt nur ein wenig rum probieren, ich bin gerade nicht sicher bin ob man das Gateway nicht doch braucht.
Der eine Container muss ja von außen erreichbar sein.
Oder nehmt ihr dann für den ,,extern" erreichbaren Container zwei Netzwerke?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 13 November 2021, 12:54:29
Das macht man doch typischerweise über Portmapping
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 13 November 2021, 13:18:24
Zitat von: Otto123 am 13 November 2021, 12:54:29
Das macht man doch typischerweise über Portmapping

Da hast du recht.
Nur die Frage ist halt wie du das netzwerk anlegst?
Ich hab nun zu, Beispiel da Netzwerk mit Isolation angelegt. Das hat dann nicht funktioniert.
Ohne bridge geht es aber wirklich.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 13 November 2021, 14:13:36
Ich befürchte wir schweifen vom eigentlichen Thema dieses Threads ab.
Du müsstest das mal mit Konfigurationen hinterlegen. Ich arbeite bisher mit mehreren "bridged network" und bei einigen containern mit "host network".
Und ich lese, da gibt es noch mehr: https://docs.docker.com/network/ 8)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 November 2021, 16:18:51
Warum brauchst Du denn Isolation? Und externe Verfügbarkeit geht niemals *) übers Interne Netzwerk. Das erledigt man über PortMaping *)
Macht doch, wie ein paar Einträge vorher beschrieben, ein Normales Netzwerk.

Hinweis:
*) Es sei denn über einen dedizierten Proxy über den Host.

Kleiner Hinweis: Auch wenn ich es oben anders schrieb: Docker ist KEINE VM. Also nicht wirklich wie ein Betriebsystem denken!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: no_Legend am 13 November 2021, 16:33:25
Zitat von: Wernieman am 13 November 2021, 16:18:51
Warum brauchst Du denn Isolation? Und externe Verfügbarkeit geht niemals *) übers Interne Netzwerk. Das erledigt man über PortMaping *)
Macht doch, wie ein paar Einträge vorher beschrieben, ein Normales Netzwerk.

Hinweis:
*) Es sei denn über einen dedizierten Proxy über den Host.

Kleiner Hinweis: Auch wenn ich es oben anders schrieb: Docker ist KEINE VM. Also nicht wirklich wie ein Betriebsystem denken!
Ich hab jetzt einfach wirklich ein nextcloud Netzwerk erzeugt und hab dort die Datenbank und den nextcloud Container rein rein gehängt.
Das mit der Isolation hab ich auch gemerkt.
Das mit dem Gateway hab ich auch ausprobiert, das wird nicht benötigt.
Ich muss jetzt nur noch schauen ob es so einfach geht wie gedacht, mit meinen hmlans.
Wenn ich das gelöst hab, kann ich mein fhem wirklich auf docker umziehen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: derstinker am 25 November 2021, 10:30:31
Guten Morgen Zusammen,

beim Installiern/Updaten von node.js bekomme ich folgenden Fehler.


npmjs (fhemServerNpm) - JSON: {"error":{"detail":"","summary":"Unexpected token =","code":null}}


Weiter findet sich im Log.

PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/42_npmjs.pm line 1437


Docker Fhem läuft auf einem LXC Debian buster Container unter Proxmox v7.1 (bullseye). Kann einer mit dem Log was anfangen?

Ich hatte zuerst die Vermutung es liegt an dem Umzug von Proxmox 6.x zu 7.1 aber auch auf einer komplett frischen Installation (LXC Container, Docker, FHEM) habe ich eben so den Fehler. Hierdurch kann kein Update durchgeführt werden.

Grüße.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 November 2021, 11:58:34
Zitat von: derstinker am 25 November 2021, 10:30:31
Docker Fhem läuft auf einem LXC Debian buster Container unter Proxmox v7.1 (bullseye). Kann einer mit dem Log was anfangen?

1) welchen Docker Container? Original, dev von Cooltux ...?
2) Hast du mal komplett neu erstellt?
3) Was genau machst du um die besagten Einträge zu bekommen, wann kommen die?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Init am 25 November 2021, 12:33:44
Hallo zusammen,

ich nutze das Image "fhem/fhem:dev" mit folgender "docker-compose.yml"

    fhem:
        restart: always
        ports:
            - "8083:8083"
            - "7072:7072"
        image: fhem/fhem:dev
        volumes:
            - /share/CE_CACHEDEV1_DATA/Docker/fhem/volumes/core/:/opt/fhem/
        networks:
            - hausautomation-network
        devices:
            - "/dev/ttyACM0:/dev/ttyACM0"
        hostname: fhem
        mac_address: AA:F8:5F:95:84:21
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            FHEM_PERM_DIR: 0770
            FHEM_PERM_FILE: 0660
            UMASK: 0037
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
            IMAGE_LAYER_DEV: 1
            CPAN_PKGS: "Frontier::Client MIME::Lite"
            PIP_PKGS: "pye3dc"
        depends_on:
            - "mariadb"
            - "mqtt"


Beim Starten habe ich aber das Problem, dass die Berechtigungen nicht gemäß Environment-Definition gesetzt werden.

Die Verzeichnisse werden auf 0504 statt auf 0770 gesetzt und die Dateien auf 0432 statt 0640.

Lasse ich die Angaben FHEM_PERM_DIR und FHEM_PERM_FILE weg, dann werden die Default 750/640 gemäß Beschreibung von GitHub gesetzt.

Was mache ich falsch?

Viele Grüße
Marc
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 November 2021, 12:49:43
Warum setzt Du die MAC-Adressse?

Wegen des anderen kann ich Dir (aktuell) kein Grund nennen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: derstinker am 25 November 2021, 12:50:19
Zitat von: kadettilac89 am 25 November 2021, 11:58:34
1) welchen Docker Container? Original, dev von Cooltux ...?

Aus dem Hub, https://hub.docker.com/r/fhem/fhem (https://hub.docker.com/r/fhem/fhem) die Latest.

Zitat von: kadettilac89 am 25 November 2021, 11:58:34
2) Hast du mal komplett neu erstellt?

Ja, in einer komplett neuen VM bei 0 Angefangen. Sprich erst den LXC Container (Debian-Bullseye) erstellt, dann Docker installiert und dann gemäß https://github.com/fhem/fhem-docker#installation (https://github.com/fhem/fhem-docker#installation)

Zitat von: kadettilac89 am 25 November 2021, 11:58:34
3) Was genau machst du um die besagten Einträge zu bekommen, wann kommen die?

set fhemServerNpm install fhem-all

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 25 November 2021, 14:31:46
ich kann dir nicht sagen woher die Meldung kommt.

versuche mal nicht fhem-all sondern jedes einzeln. Beginnend mit dem npm-Paket. Du kannst verbose höher setzen dann siehst du die abgesetzten Befehle im Log. Die npm-install Befehle kannst auch direkt auf OS absetzten und schaun ob da irgend welche andere Fehler oder Probleme kommen.

1) set fhemServerNpm outdated
2) get fhemServerNpm showOutdatedList
3) set fhemServerNpm upgrade <jedes einzelne Outdated Paket>

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 25 November 2021, 15:20:52
Zitat von: kadettilac89 am 25 November 2021, 14:31:46
ich kann dir nicht sagen woher die Meldung kommt.

versuche mal nicht fhem-all sondern jedes einzeln. Beginnend mit dem npm-Paket. Du kannst verbose höher setzen dann siehst du die abgesetzten Befehle im Log. Die npm-install Befehle kannst auch direkt auf OS absetzten und schaun ob da irgend welche andere Fehler oder Probleme kommen.

1) set fhemServerNpm outdated
2) get fhemServerNpm showOutdatedList
3) set fhemServerNpm upgrade <jedes einzelne Outdated Paket>
So hat es bei mir funktioniert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: derstinker am 25 November 2021, 19:02:28
Zitat von: kadettilac89 am 25 November 2021, 14:31:46
ich kann dir nicht sagen woher die Meldung kommt.

versuche mal nicht fhem-all sondern jedes einzeln. Beginnend mit dem npm-Paket. Du kannst verbose höher setzen dann siehst du die abgesetzten Befehle im Log. Die npm-install Befehle kannst auch direkt auf OS absetzten und schaun ob da irgend welche andere Fehler oder Probleme kommen.

1) set fhemServerNpm outdated
2) get fhemServerNpm showOutdatedList
3) set fhemServerNpm upgrade <jedes einzelne Outdated Paket>

Im Docker Container bekomme ich folgenden Error:


npm install -g alexa-fhem
npm WARN npm npm does not support Node.js v10.24.1
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm You can find the latest version at https://nodejs.org/
npm ERR! Unexpected token =


So war mein Ansatz, läuft aber direkt in einen error:

get fhemServerNpm showOutdatedList

Endet mit Error unexpected token
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 November 2021, 06:11:59
Zitat von: derstinker am 25 November 2021, 19:02:28
Im Docker Container bekomme ich folgenden Error:


npm install -g alexa-fhem
npm WARN npm npm does not support Node.js v10.24.1
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm You can find the latest version at https://nodejs.org/
npm ERR! Unexpected token =


So war mein Ansatz, läuft aber direkt in einen error:

get fhemServerNpm showOutdatedList

Endet mit Error unexpected token
Das hatte ich auch bei mir.
Ich habe dann leider den Docker Container nochmal neu laden müssen. Danach das node.js nicht auf die aktuellste Version bringen, weil die wohl noch nicht zu den anderen Modulen passt.

Da ich aber momentan nichts aus der Modul Liste verwende habe ich letztendlich einen anderen node-red Docker Container verwendet und dort das von mir benötigte Kia connect integriert.

VG
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 November 2021, 08:29:42
Ihr könnt die dev-Version von Cooltux testen wenn ihr wollt. Alternativ die etwas ältere Version von volschin. Alternativ das npm Script zum Update verwenden (offizielle Version) ... curl https://www.npmjs.com/install.sh | sudo sh


volschin:
docker pulll ghcr.io/volschin/fhem-experimental:dev-bullseye

Cooltux dev-Version
docker pulll ghcr.io/fhem/fhem-experimental:dev
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 26 November 2021, 08:36:12
Zitat von: kadettilac89 am 26 November 2021, 08:29:42
Ihr könnt die dev-Version von Cooltux testen wenn ihr wollt. Alternativ die etwas ältere Version von volschin. Alternativ das npm Script zum Update verwenden (offizielle Version) ... curl https://www.npmjs.com/install.sh | sudo sh


volschin:
docker pulll ghcr.io/volschin/fhem-experimental:dev-bullseye

Cooltux dev-Version
docker pulll ghcr.io/fhem/fhem-experimental:dev
Hallo kadettilac89

ich sehe da gerade bullseye, ist da generell ein Upgrade zu empfehlen?
Ich habe gerade auf einem RPI4 auf arm64 Buster migriert. Das läuft echt klasse seit einer Woche.
Rein subjektiv läuft es auch performanter als die 32 Bit Version.
Auch die arm64 Docker Container konnte ich alle recht problemlos starten.
Insbesondere für MySQL hat das diverse Releases übersprungen. Von Maria DB 5.7 auf MySQL 8 direkt von Oracle :-)

Gruß
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 26 November 2021, 08:51:18
Zitat von: ch.eick am 26 November 2021, 08:36:12
ich sehe da gerade bullseye, ist da generell ein Upgrade zu empfehlen?

Ich selber nutze keinen Raspberry sondern "normale" Intel CPU. Deshalb kann ich das ARM / Raspberry Thema nicht so beurteilen.

Zum Thema Upgrade allgemein, es macht Sinn das System aktuell zu halten da fehlende Sicherheitsupdates und auch Abhängigkeiten zu älteren Modulen Probleme machen können (wie z. b. das npm-Thema). Um das sicher zu stellen reichen normale Updates ohne Release Upgrade.

Auf der anderen Seite "never touch a running system".

Für eine Fhem Installation auf Docker ist das aber relativ einfach ...
Frage zu Upgrade des Host Betriebssystem - Erstmal sichern kopiere die Karte (oder dein Speichermedium) und teste.  Wenn alles läuft OK, wenn nicht zurück.
Frage zu Upgrade es Containers - du kannst einen zweiten Container anlegen mti dem neuen Image und dort testen. Wenn es dir gefällt, Image austauschen und gut.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: derstinker am 26 November 2021, 12:23:13
Zitat von: ch.eick am 26 November 2021, 06:11:59
Danach das node.js nicht auf die aktuellste Version bringen...

Vielen Dank Christian, genau das ist die Ursache. Es liegt defintiv an der npm/node.js version die den Fehler verursacht. Konnte ich nachstellen.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: bmwfan am 07 Dezember 2021, 20:03:04
Ich habe jetzt auch FHEM nach Docker auf einer DS720 umgezogen. Dank der Anleitung und den vielen Tips in diesem Thread hat es nach einigem Kampf mit zigbee2mqtt geklappt. Ich denke zwar, dass ich zuviele Ports freigeschalten habe, aber hauptsache es läuft.

Einzig mit der Logdatei habe ich Probleme. Ich habe das Verzeichnis, wie in Post 1 geschrieben, in den Container gemappt und es wird auch in die Logdatei geschrieben. Ich sehe die Einträge aber nur, wenn ich die Logdatei mit einem Editor (ich verwende notepad) öffne. Öffne ich sie über die Web-Oberfläche von FHEM, sind keine Einträge bzw. nur die zum Zeitpunkt des Backups auf dem Raspi vorhandenen, sichtbar.

Hat jemand einen Tip, wie ich das Problem beheben kann?

Anbei das list von global:
Internals:
   DEF        no definition
   FD         3
   NAME       global
   NR         1
   STATE      no definition
   TYPE       Global
   currentlogfile ./log/fhem-2021-12-07.log
   init_errors Messages collected while initializing FHEM:SecurityCheck:
  WEB is not password protected
  telnetPort is not password protected
  MQTT2_FHEM_Server is not password protected

Protect this FHEM installation by configuring the allowed device allowed_WEBS
You can disable this message with attr global motd none

   logfile    ./log/fhem-%Y-%m-%d.log
   hmccu:
Attributes:
   autoload_undefined_devices 1
   autosave   0
   blockingCallMax 10
   configfile fhem.cfg
   dnsServer  192.168.178.1
   exclude_from_update 98_freezemon.pm 73_PRESENCE.pm
   holiday2we BWFeiertageUrlaub
   language   DE
   logfile    ./log/fhem-%Y-%m-%d.log
   modpath    .
   motd       none
   mseclog    1
   nofork     0
   nrarchive  14
   pidfilename ./log/fhem.pid
   room       9.6.0_System
   sendStatistics onUpdate
   stacktrace 0
   statefile  ./log/fhem.save
   updateInBackground 1
   userattr   cmdIcon devStateIcon devStateIcon:textField-long devStateStyle icon mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType:text,push,mail,screen,light,audio,queue power-off power-on presentCycle presentReading sortby webCmd webCmdLabel:textField-long widgetOverride
   verbose    3
   version    fhem.pl:25197/2021-11-07


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 08 Dezember 2021, 10:47:47
Zitat von: bmwfan am 07 Dezember 2021, 20:03:04
Hat jemand einen Tip, wie ich das Problem beheben kann?

Öffnest du das selbe Logfile welches in Fhem konfiguriert wurde? Vermutungen ohne näheren Input von dir ...

- ist die Location in global und im Docker-compose (oder wo auch immer konfiguriert)? ... Tippfehler
- Berechtigungsproblem ...

gib mal
- ein "ls -la" vom Logverzeichnis um zu sehen wie die Berechtigungen gesetzt sind
- Konfiguration in docker, hast du eine eigene Konfiguration für das Logfile? ... Parameter "-e LOGFILE=./log/fhem-%Y-%m-%d.log"
- Zeigt das Log im Docker selber die Meldungen an, diese sollten mit dem Logfile überein stimmen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: bmwfan am 08 Dezember 2021, 12:50:17
Location: Ist im Global und im Docker konfiguriert. Ein List von global war im vorhergehenden Post, ein Screenshot von der Konfiguration in Docker ist im Anhang.
Berechtigung: Im Terminalfenster von Docker habe ich beim Start gesehen, dass die Berechtigungen für fhem vom Programm gesetzt werden. Siehe Anhang

Zitatein "ls -la" vom Logverzeichnis um zu sehen wie die Berechtigungen gesetzt sind
Wie komme ich zu dem Verzeichnis? Ich kann zwar mit Putty auf das NAS, finde aber weder das fhem-Verzeichnis noch das Logverzeichnis. Unter /opt/ liegt nur ein Verzeichnis "containerd" und auch darunter kein fhem. Über den Explorer unter Win10 habe ich das NAS als Netzlaufwerk eingerichtet und kann problemlos auf das Docker- und das darunterliegende fhem-Verzeichnis zugreifen. Berechtigungen unter Win angezeigt: siehe Anhang.

Das Log im Terminalfenster von Docker zeigt dieselben Meldungen an, wie das Log das ich in Notepad öffne und das unter NAS-DS720/docker/fhem/log liegt.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 08 Dezember 2021, 13:19:20
Die Zeile 4 "Creationg log directory /opt/fhem/./log ... " sieht komisch aus.

Teste mal als Paremter /opt/fhem/log/fhem-%Y-%m-%d.log und erstell den Container neu. Erstmal interessehalber da es eigentlich auch so funktionieren sollte, das oben im Log kann auch ein Darstellungsfheler sein.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: bmwfan am 08 Dezember 2021, 14:56:19
Habs getestet. Logfile in FHEM immer noch nicht aktualisiert, aber jetzt erfolgte auch keine Ausgabe mehr im Terminalfenster der Dockeranwendung

Nachtrag: Fehler gefunden.
Nach dem restore des auf dem Raspi gesicherten FHEM war die Angabe im Logfile falsch. Die DEF des Logfiles war ./log/fhem-%Y-%m.log Logfile

Hier fehlt die Erweiterung auf die tägliche Erstellung eines Logfiles und statt dem üblichen fakelog war Logfile eingestellt.

Besten Dank für die Tips.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: debu am 11 Dezember 2021, 10:40:54
Hallo zusammen,

ich versuche seit Tagen mein fhem auf docker zu portieren. Portiert habe ich per fhem backup. Leider scheiter ich nach wie vor an den USB devices.
Fhem bzw docker wird auf einem raspi 4 Model B mit Raspberry Pi OS with desktop (Release date: October 30th 2021; Kernel version: 5.10).

Leider bekomme ich unter anderem den HMLAN (HM-CFG-USB/HM-CFG-USB-2) unter docker nicht ans laufen. Auf meiner alten fhem installation (ohne docker) läuft der ohne Probleme.


lsusb:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 1b1f:c00f eQ-3 Entwicklung GmbH HM-CFG-USB/HM-CFG-USB-2 [HomeMatic Configuration adapter]
Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 003: ID 0451:16a8 Texas Instruments, Inc. CC2531 ZigBee
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


ttyUSB0 existiert bei mir nicht :-(

ls -l /dev/ttyUSB0
ls: cannot access '/dev/ttyUSB0': No such file or directory


Auszug aus meiner docker-compose.yml

services:
  fhem:
    image: fhem/fhem:latest
    container_name: fhem
    restart: unless-stopped
    networks:
      - net
    privileged: true
    ports:
      - "8083:8083"
      - "1883:1883"
    volumes:
      - "~/fhem/:/opt/fhem/"
    devices:
      - "/dev/bus/usb/001/005:/dev/bus/usb/001/005"
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin


Beim starten von fhem bekomme ich folgendes:

2021.12.11 10:01:58 1: CUL_HM finished initial cleanup
2021.12.11 10:01:58 1: usb create starting
2021.12.11 10:01:58 3: Probing CUL device /dev/ttyACM0
2021.12.11 10:01:58 3: Probing TCM_ESP3 device /dev/ttyACM0
2021.12.11 10:01:59 3: Probing ZWDongle device /dev/ttyACM0
2021.12.11 10:01:59 3: Probing SIGNALDuino device /dev/ttyACM0
2021.12.11 10:01:59 3: Probing MYSENSORS device /dev/ttyACM0
2021.12.11 10:01:59 3: Probing ArduCounter device /dev/ttyACM0
2021.12.11 10:01:59 3: Probing ElsnerWS device /dev/ttyACM0
2021.12.11 10:02:00 3: Probing FRM device /dev/ttyACM0
2021.12.11 10:02:05 3: Probing CUL device /dev/ttyAMA0
2021.12.11 10:02:05 1: CUL: Can't open /dev/ttyAMA0: Permission denied
2021.12.11 10:02:05 3: Probing CUL device /dev/ttyS0
2021.12.11 10:02:05 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 598.
2021.12.11 10:02:05 1: CUL: Can't open /dev/ttyS0: Input/output error
2021.12.11 10:02:05 1: usb create end


Mir scheint ich habe ein generelles Problem die USB devices nach docker zu mappen/bekannt zu machen? Muss ich dazu den fhem container unbedingt im privilege mode laufen lassen? Aber selbst dann geht es bei mir mit obiger config nicht.
Jemand eine idee?

Danke und beste Gruesse,
DeBu
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 11 Dezember 2021, 10:52:21
bei mir lauter das:
    devices:
       - /dev/bus/usb/001/002

ganz ohne :....
gruß sirdus
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: debu am 11 Dezember 2021, 10:57:08
versuche ich gleich mal. Danke!

Ganz vergessen zu erwähnen wie der HMLAN definiert ist: 127.0.0.1:1000
Muss ich die ip evtl. anpassen sobald fhem aus docker heraus betrieben wird? host.docker.internal:1000?

Beste Gruesse,
DeBu
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 11 Dezember 2021, 12:00:14
Hallo Debu,

konsequenterweise würde ich dafür einen eigenen docker container nehmen. Gegoogelt und gefunden:
https://github.com/djusHa/hmland-docker

Oder alternativ das Ding nicht im fhem Container betreiben sondern "normal" auf dem Host.
https://wiki.fhem.de/wiki/HM-CFG-USB_USB_Konfigurations-Adapter

Und natürlich ist dann die IP Adresse für FHEM dann nicht mehr 127.0.0.1 - das passt nur wenn alles auf dem gleichen Host läuft.

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 11 Dezember 2021, 17:55:09
Sehe bitte docker nicht wie eine VM ... das ist es erstes technisch nicht und zweitens widerspricht es der Idee von Microsservice und drittens, machst Du dir das leben nur schwer.

Wie Otto schrieb, packe HMLAN (wirklich HMLAN??) in einen eigenen Container. Jeder Serverdienst sollte (muß) seinen eigenen Container bekommen. Nur so hast Du den Vorteil, das Du einzelne Dienste einzeln updaten kannst. Und ja, nach dem Update ist vor dem nächsten Update
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: debu am 11 Dezember 2021, 20:50:33
Hi zusammen,

vielen Dank! Habe es über einen seperaten docker gelöst wie von Otto vorgeschlagen. Mir war nicht mehr bewusst dass hmland als eigener service eingerichtet werden muss. Das kommt davon wenn das zeug immer problemlos funktioniert und man es nur alle 3-4 Jahre anfasst ;-)

Meine docker-compose schaut jetzt so aus:

version: '3.8'

networks:
  fhem-net:
    driver: bridge
    name: fhem-net
services:
  hmland:
    container_name: hmland
    restart: unless-stopped
    image: hmland
    network_mode: "host"
    expose:
      - "1000"
    privileged: true
    build: /hmland

  fhem:
    image: fhem/fhem:latest
    container_name: fhem
    restart: unless-stopped
    networks:
      - fhem-net
    ports:
      - "8083:8083"
      - "1883:1883"
      - "7072:7072"
    volumes:
      - "/fhem/:/opt/fhem/"
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
    depends_on:
      - "hmland"

  zigbee2mqtt:
    container_name: zigbee2mqtt
    restart: unless-stopped
    image: koenkk/zigbee2mqtt
    networks:
      - fhem-net
    volumes:
      - "/zigbee2mqtt/data:/app/data"
      - "/run/udev:/run/udev:ro"
    ports:
      - "8080:8080"
    environment:
      - TZ=Europe/Berlin
    devices:
      - /dev/ttyACM0:/dev/ttyACM0
    depends_on:
      - "fhem"

  npresenced:
    container_name: npresenced
    image: npresenced
    restart: unless-stopped
    expose:
      - "5333"
    volumes:
      - "/npresenced:/npresenced"
    build: /npresenced
    privileged: true
    network_mode: "host"


Danke und beste Gruesse,
DeBu
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 27 Dezember 2021, 20:49:10
Hi,

ich wollte heute meine FHEM Installation um Alexa erweitern, scheitere aber an einem
Zitatstopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
als state...

Hat jemand eine Idee, was ich falsch mache? Bei mir läft Fhem auf dem RPI, hier meine Docker-compose.yml:
version: '2'

services:
    ## GENERAL
    portainer:
        restart: always
        image: portainer/portainer:latest
        command: -H unix:///var/run/docker.sock --no-auth
        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
        networks:
            - fhem-network
    ##FHEM
    fhem:
        image: fhem/fhem:latest
        restart: always
        ports:
            - "8083:8083"
            - "7072:7072"
        volumes:
            - ./fhem/core/:/opt/fhem/
        networks:
            - fhem-network
        #devices:
        #    - "/dev/ttyUSB0:/dev/ttyUSB0"
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
        depends_on:
            - "mysql"
            - "mqtt"

    #habridge:
    #    restart: always
    #    image: habridge/ha-bridge-raspberrypi3
    #    volumes:
    #        - ./habridge/data/:/ha-bridge/data
    #        - /etc/localtime:/etc/localtime:ro
    #       - /etc/timezone:/etc/timezone:ro
    #    network_mode: host

    homebridge:
        restart: always
        image: oznu/homebridge:raspberry-pi
        volumes:
            - ./homebridge:/homebridge
        environment:
            - TZ=Europe/Berlin
            - PGID=1000
            - PUID=1000
            - HOMEBRIDGE_CONFIG_UI=1
            - HOMEBRIDGE_CONFIG_UI_PORT=8081
        network_mode: host
        depends_on:
            - "fhem"

    mysql:
        restart: always
        expose:
            - "3306"
            - "33060"
        ports:
            - "3306:3306"
            - "33060:33060"
        image: hypriot/rpi-mysql
        volumes:
            - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
            - ./mysql/data:/var/lib/mysql
        environment:
            - MYSQL_ROOT_PASSWORD=XXX
            - MYSQL_DATABASE=fhem
            - MYSQL_USER=fhemuser
            - MYSQL_PASSWORD=XXX
        networks:
            - fhem-network

    mqtt:
        restart: always
        expose:
            - "1883"
            - "9001"
        ports:
            - "1883:1883"
            - "9001:9001"
        image: pascaldevink/rpi-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: elzekool/rpi-nodered
        volumes:
            - ./nodered/data/:/root/.node-red/
        networks:
            - fhem-network
        depends_on:
            - "mqtt"

    alexa-fhem:
        #image: fhem/alexa-fhem:latest
        image: ghcr.io/fhem/fhem/alexa-fhem:latest
        restart: always
        networks:
            - fhem-network
        ports:
            - "3000:3000"
        volumes:
            - ./alexa-fhem/:/alexa-fhem/
        environment:
           ALEXAFHEM_UID: 1000 #6062
           ALEXAFHEM_GID: 1000 #6062
           TZ: Europe/Berlin


volumes:
    portainer_data:

networks:
    fhem-network:
        driver: bridge


Lieben Dank im Voraus!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 28 Dezember 2021, 13:50:19
Siehe Doku im ersten Post:
z.B.
Zitat/pre-init.sh - Wird beim allerersten Start des Containers noch vor der FHEM Installation ausgeführt.

Allerdings gibt es auch eine Möglichkeit, npm Module automatisch installieren zu lassen, nur kenne ich mich mit diesem Container nicht gut aus ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 28 Dezember 2021, 13:53:08
Zitat von: maddhin am 27 Dezember 2021, 20:49:10
hier meine Docker-compose.yml:

Dort beim fhem-container folgende environment-variable einfügen:


[...]
        environment:
            NPM_PKGS: "alexa-fhem"
[...]


Quelle: https://github.com/fhem/fhem-docker#add-custom-packages (https://github.com/fhem/fhem-docker#add-custom-packages)


Edit: Achso, ups, sorry. Habe erst jetzt gesehen, dass du alexa-fhem als eigenen container hast. Den brauchst du, wenn du es über "NPM_PGKS" machst, nicht mehr. Wenn du alexa-fhem unbedingt in einem eigenen Container haben willst bräuchten wir vermutlich (mindestens) ein list deines alexa-devices.

Ist aber mE nicht notwendig, dass das in einem eigenen Container läuft, einfach als package installieren und gut ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 28 Dezember 2021, 16:03:14
Zitat von: passibe am 28 Dezember 2021, 13:53:08
Ist aber mE nicht notwendig, dass das in einem eigenen Container läuft, einfach als package installieren und gut ist.

Ok, eigentlich sollte das mit dem npm-package einfacher sein. Dann muss ich so auch Node installieren, oder? Oder ist das als Voraussetzung bei alexa-fhem schon hinterlegt?

Ich kenne mich mit Docker nicht gut aus - kennt jemand einen Vorteil, Alexa in einem eigenen Container laufen zu lassen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 28 Dezember 2021, 16:07:23
Node ist auf dem Image schon installiert!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 28 Dezember 2021, 16:48:10
komisch - die Fehlermeldung ist die gleich... Nachdem ich den Alexa-Container installiert habe und via environment npm etc Alexa installiert haben, ist der State ist immer noch "stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'."

Oh, Mann, jemand noch eine gute Idee?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 29 Dezember 2021, 15:25:55
Hi,

ich wollte mal prüfen, ob das Alexa-Fhem npm package installiert ist und habe mich in den Fhem-Container eingeloggt. Es scheint, dass weder npm noch node bei mir installiert sind!! Ein node -v oder npm -v geben nur "bash: npm: command not found" zurück.

Als ich das Alexa package in der docker-compose.yml angegeben habe, wurde der Container neu erstellt bzw. geändert (keine Fehlermeldung!)

Versteht hier jemand, was passiert? Hier nochmal meine docker-compose.yml.

version: '2'

services:
    ## GENERAL
    portainer:
        restart: always
        image: portainer/portainer:latest
        command: -H unix:///var/run/docker.sock --no-auth
        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
        networks:
            - fhem-network
   
##FHEM
    fhem:
        image: fhem/fhem:latest
        restart: always
        ports:
            - "8083:8083"
            - "7072:7072"
        volumes:
            - ./fhem/core/:/opt/fhem/
        networks:
            - fhem-network
        #devices:
        #    - "/dev/ttyUSB0:/dev/ttyUSB0"
        environment:
            FHEM_UID: 1000
            FHEM_GID: 1000
            TIMEOUT: 10
            RESTART: 1
            TELNETPORT: 7072
            TZ: Europe/Berlin
            NPM_PKGS: "alexa-fhem"
        depends_on:
            - "mysql"
            - "mqtt"

    #habridge:
    #    restart: always
    #    image: habridge/ha-bridge-raspberrypi3
    #    volumes:
    #        - ./habridge/data/:/ha-bridge/data
    #        - /etc/localtime:/etc/localtime:ro
    #       - /etc/timezone:/etc/timezone:ro
    #    network_mode: host

    homebridge:
        restart: always
        image: oznu/homebridge:raspberry-pi
        volumes:
            - ./homebridge:/homebridge
        environment:
            - TZ=Europe/Berlin
            - PGID=1000
            - PUID=1000
            - HOMEBRIDGE_CONFIG_UI=1
            - HOMEBRIDGE_CONFIG_UI_PORT=8081
        network_mode: host
        depends_on:
            - "fhem"

    mysql:
        restart: always
        expose:
            - "3306"
            - "33060"
        ports:
            - "3306:3306"
            - "33060:33060"
        image: hypriot/rpi-mysql
        volumes:
            - ./mysql/init.sql:/docker-entrypoint-initdb.d/fhem-init.sql
            - ./mysql/data:/var/lib/mysql
        environment:
            - MYSQL_ROOT_PASSWORD=xxx
            - MYSQL_DATABASE=fhem
            - MYSQL_USER=fhemuser
            - MYSQL_PASSWORD=xxx
        networks:
            - fhem-network

    mqtt:
        restart: always
        expose:
            - "1883"
            - "9001"
        ports:
            - "1883:1883"
            - "9001:9001"
        image: pascaldevink/rpi-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: elzekool/rpi-nodered
        volumes:
            - ./nodered/data/:/root/.node-red/
        networks:
            - fhem-network
        depends_on:
            - "mqtt"

    #alexa-fhem:
    #    #image: fhem/alexa-fhem:latest
    #    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    #    restart: always
    #    networks:
    #        - fhem-network
    #    ports:
    #        - "3000:3000"
    #    volumes:
    #        - ./alexa-fhem/:/alexa-fhem/
    #    environment:
    #       ALEXAFHEM_UID: 1000 #6062
    #       ALEXAFHEM_GID: 1000 #6062
    #       TZ: Europe/Berlin

    duplicati:
         image: duplicati/duplicati:latest
         #container_name: duplicati
         hostname: duplicati
         restart: always
         # Recommendation: Duplicati needs root user to get access to all files
         #user: "ROOTPUID:1000:ROOTPGID:1000"
         network_mode: bridge
         ports:
             - "8200:8200"
         volumes:
             - ./duplicati_data:/data:rw
             - /docker/backups:/backups:rw
             - ./:/source:ro
         environment:
             - TZ=Europe/Berlin


volumes:
    portainer_data:

networks:
    fhem-network:
        driver: bridge


Mache ich was falsch? 
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 29 Dezember 2021, 17:35:03
Zitat von: maddhin am 29 Dezember 2021, 15:25:55

Mache ich was falsch?

keine Ahnung. Alexa-fhem wird im docker container schon eingebaut. Ist im Dockerfile enthalten. Nimm die Zeile NPM erstmal wieder raus.

Teste mal das Image von Cooltux .. s. u. Wenn das auch nicht geht, mache ein docker-compose file nur mit fhem und lass alles andere erstmal raus, keine eigene Netzwerke, keinerlei Abhängigkeit zu was anderem.


image: ghcr.io/fhem/fhem-experimental:dev


Ansonsten mehr Input. Auf welcher Hardware läuft Docker? Ist die Weboberfläche erreichbar?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 29 Dezember 2021, 23:13:46
Zitat von: maddhin am 29 Dezember 2021, 15:25:55
ich wollte mal prüfen, ob das Alexa-Fhem npm package installiert ist und habe mich in den Fhem-Container eingeloggt. Es scheint, dass weder npm noch node bei mir installiert sind!! Ein node -v oder npm -v geben nur "bash: npm: command not found" zurück.
Das Original Docker Basis Image ist "kaputt", steht auf den vielen Seiten zuvor auch mehrfach beschrieben. Wenn man da npm aktualisiert ist es irgendwann weg. Entweder zerstörst Du den Container, und machst ihn neu und dann KEIN npm Update, oder Du nimmst wie kadettilac89 schrieb gleich das Image von cooltux ;)

Viel Erfolg
Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 30 Dezember 2021, 10:32:29
Hat eigentlich irgendwer FHEM in einem Docker Swarm laufen (inkl. Multicast)? Wenn ja, dann wäre ich da sehr dran interessiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 30 Dezember 2021, 12:41:10
Zitat von: Otto123 am 29 Dezember 2021, 23:13:46
Das Original Docker Basis Image ist "kaputt", steht auf den vielen Seiten zuvor auch mehrfach beschrieben. Wenn man da npm aktualisiert ist es irgendwann weg. Entweder zerstörst Du den Container, und machst ihn neu und dann KEIN npm Update, oder Du nimmst wie kadettilac89 schrieb gleich das Image von cooltux ;)

Zitat von: kadettilac89 am 29 Dezember 2021, 17:35:03
Ansonsten mehr Input. Auf welcher Hardware läuft Docker? Ist die Weboberfläche erreichbar?

Ahh, das ist schade. Bisher hatte das Image problemlos funktioniert und läuft seit 1+ Jahren auf einem RPI. D.h. bis auf das mit Alexa jetzt, gab es keine Probleme und es läuft alles.

Ehrlich gesagt, weiß ich gar nicht, wie man npm / das Image aktualisiert. Das muss man wohl über apt-get update / upgrade im Container selbst anstoßen? Ich habe Docker bewußt gewählt, weil es so viel einfacher ist, ein docker-compose zu basteln als alles selbst zu installieren. Meine Linux Kenntnisse sind beschränkt und es ist für mich immer sehr zeitaufwendig was zu installieren bzw. irgendwelche Installations- und Konfigurationsprobleme zu lösen.

Exkurs
Ich persönlich finde Docker eine geniale, moderne Möglichkeit FHEM auch Leuten mit beschränkten Linux Kenntnissen zugänglich zu machen. Gerade auch um MySQL, MQTT, Homebridge, Alexa(!), etc einfach zu integrieren, was nicht trivial ist. Auch um eine einfache bzw. einfach zu bedienende (Cloud-)Backup-Lösung wie z.B. Duplicati anzubieten. Dass da das original FHEM-Image "bockt" ist natürlich "suboptimal". Eigentlich sollte das Docker-Image gepusht werden.
Exkurs Ende

Kann ich jetzt die Docker-compose einfach vom Fhem- auf das cooltux-Image ändern und die Konfiguration und Daten bleiben bestehen?

Alternativ: Wie würde ich das Alexa-Fhem Docker Image integrieren? Der Alexa-Fhem Container sollte ja eigentlich funktionieren, aber irgendwie findet FHEM Alexa-Fhem wohl nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: slupus am 30 Dezember 2021, 12:58:37
Zitat von: Init am 25 November 2021, 12:33:44
Beim Starten habe ich aber das Problem, dass die Berechtigungen nicht gemäß Environment-Definition gesetzt werden.

Ich habe das gleiche Problem. Bei mir betrifft es die Berechtigung aber auch die Ports. Ich habe jetzt verschiedene Konfigurationen durchprobiert, um die Environment-Definition mitzugeben (mit ', ", :, = oder vorangestelltem -).
In meiner Prod Umgebung funktioniert aber bspw. die Übergabe des USB Devices und die Änderung des Logfiles.
Anbei der yml Auszug  für die Testumgebung:

version: '3.3'
services:
    fhem-test:
        container_name: fhem-test
        restart: 'always'
        ports:
            - "8084:8084"
        volumes:
            - '/opt/docker/fhem-test:/opt/fhem'
        environment:
            # - 'APT_PKGS=package1 package2'
            - LOGFILE=./log/fhem-%Y-%m.log
            - FHEM_PERM_DIR:0754
            - FHEM_PERM_FILE:0644
            - UMASK=0033
            - TZ=Europe/Berlin
            - TELNETPORT=7073
        network_mode: host
        image: ghcr.io/fhem/fhem-experimental:dev


Hier noch der Auszug des Container Logs (frisch aufgesetzt):

Preparing initial start:
1. Installing FHEM to /opt/fhem
2. Patching fhem.cfg default configuration
3. Adding pre-defined devices to fhem.cfg
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 ... done
Starting FHEM ...
2021.12.30 12:44:35.036 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m.log
2021.12.30 12:44:35.037 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.12.30 12:44:35.037 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.12.30 12:44:35.037 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.12.30 12:44:35.044 1: Including fhem.cfg
2021.12.30 12:44:35.264 1: WEB: Can't open server port at 8083: Address already in use. Exiting.


Hat jemand eine Idee, was wir falsch machen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Dezember 2021, 13:05:52
Wie schon Otto sagte, mach nicht EIN docker-compose.yml, sondern für jedes "Projekt" eines. z.B. muß Portainer nicht im gleichen Projekt wie fhem sein. Schließlich steuer fhem nicht Portainer und Portainer auch nicht fhem (sondern "nur" den Container"). Macht es übersichtlicher und sogar "sicherer" ...

Ich mag an diesem Container nicht, das er eine "Eierlegende Wollmichsau" ist. Er kann vieles, ist dadurch aber auch sehr groß und schwierig zu Warten.
Auch erfolgt eine Aktuallisierung innerhalb des Containers ... und eben nicht dadurch, das man den Container tauscht ... aber DAS ist ein anderes Thema.

Da der Container von Cooltux ein "fork" des "Originalen" von Loredo, sollte es so funktionieren. Ansonsten mach es wie bei Docker-Upgrade üblich:
1. Container stoppen
2. Verzeichnis sichern (bzw. Verzeichnisse)
3. docker-compose editieren (Hinweis s.o.)
4. Container starten
Bei Problemen
5. Container stoppen, 4. Rückgängigmachen, 2. zurückspielen, Container starten

Edit:
War eine Antwort auf maddhin Beitrag ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Dezember 2021, 13:10:09
Gekürtzter Beitrag
Zitat von: slupus am 30 Dezember 2021, 12:58:37

        ports:
            - "8084:8084"

Hier noch der Auszug des Container Logs (frisch aufgesetzt):

Preparing initial start:
2021.12.30 12:44:35.264 1: WEB: Can't open server port at 8083: Address already in use. Exiting.

Hat jemand eine Idee, was wir falsch machen?

Mit der Portangabe sagst Du nur Docker, NICHT fhem, das der Port 8084 von extern erreichbar sein soll, also von außerhalb der Docker-Welt. Die Fehlermeldung sagt dagegen aus, das fhem den Port 8083 nicht öffnen kann. Hast Du noch etwas auf dem Port 8083 laufen? Was sagt die fhem.cfg dazu?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 30 Dezember 2021, 13:38:07
Zitat von: maddhin am 30 Dezember 2021, 12:41:10
Ehrlich gesagt, weiß ich gar nicht, wie man npm / das Image aktualisiert. Das muss man wohl über apt-get update / upgrade im Container selbst anstoßen? Ich habe Docker bewußt gewählt, weil es so viel einfacher ist, ein docker-compose zu basteln als alles selbst zu installieren. Meine Linux Kenntnisse sind beschränkt und es ist für mich immer sehr zeitaufwendig was zu installieren bzw. irgendwelche Installations- und Konfigurationsprobleme zu lösen.
...
Kann ich jetzt die Docker-compose einfach vom Fhem- auf das cooltux-Image ändern und die Konfiguration und Daten bleiben bestehen?
Ja.
Du änderst in deiner docker-compose.yml die Zeile mit dem fhem image auf:
   image: ghcr.io/fhem/fhem-experimental:dev

und machst ein docker-compose pull
docker-compose up -d
damit macht er den fhem container neu, deine FHEM bleibt.
Der separate pull Befehl sorgt für geringe down time deines containers, er zieht damit erstmal nur das Image.

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 30 Dezember 2021, 13:54:05
Zitat von: Wernieman am 30 Dezember 2021, 13:05:52
Wie schon Otto sagte, mach nicht EIN docker-compose.yml, sondern für jedes "Projekt" eines. z.B. muß Portainer nicht im gleichen Projekt wie fhem sein. Schließlich steuer fhem nicht Portainer und Portainer auch nicht fhem (sondern "nur" den Container"). Macht es übersichtlicher und sogar "sicherer" ...

Ich mag an diesem Container nicht, das er eine "Eierlegende Wollmichsau" ist. Er kann vieles, ist dadurch aber auch sehr groß und schwierig zu Warten.

Das ist richtig, wenigstens Portainer und auch Duplicati gehören in eigene Container. Aber bei Duplicati bin ich daran gescheitert root-access zu bekommen, weil ich das "System" d.h. Zusammenspiel zwischen Docker, FHEM-Container, etc. nicht richtig verstehe (was natürlich durch mehr googeln gelöst werden kann). Duplicati in den FHEM-Container zu packen war die billige Variante - wobei ich ohnehin nur FHEM sichern möchte.

Ganz sicher ist meine docker-compose hier nicht als Paradebeispiel zu nehmen. Ich hatte aber keine bessere "Basis"-docker-compose gefunden und kenne mich mit Docker auch nicht gut aus, um das alles richtig zu machen. Ich bin schon froh, dass diese docker-compose mit dem RPI sauber läuft. Nur an Alexa ist es wohl gescheitert.

Wobei ich jetzt nicht weiß, ob die Wartung einfacher ist. Im Grunde macht die docker-compose doch einen stack aus mehreren einzelnen Containern, oder? D.h. man muss so oder so jeden Container warten. Wenn man natürlich MQTT, Homebridge, etc. gleich über "environment" in den FHEM container packen kann, wäre das viel besser. Gibt es dazu irgendwo Anleitungen?
Andererseits sind einzelne Container ggf auch gut, weil man dann bei Problemen schnell und leicht MQTT, etc. neu aufsetzen kann und man nicht in der FHEM Installation rumfummeln muss.


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Dezember 2021, 14:06:25
Mit docker-compose.yml baust Du eine Gruppe von Containern. Mit mehreren docker-compose.yml, am besten in jeweils neuem Verzeichnis, hast Du dann mehrere "Gruppen". Der Vorteil ist, das Du z.B. eine Gruppe runterfahren/warten kannst, ohne die anderen "zu belästigen".

Nur mal als Hinweis:
Bei mir läuft u.A. fhem, nextcloud, calibre, mailu-Mailserver, phihole, apt-cache, wheb-Server, lirc-Deamon, graylog, zabbix jeweils in eigenen docker-compose.yml. Damit bestehen einige Projekte aus mehr als einen Containern (z.B. Mail-Server aus 9). Wenn alles in EINER docker-compoise.yml, währe es nicht mehr zu warten. Und außerdem, "sehen" die Container sich nicht gegenseitig, was sogar die Sicherheit erhöht ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 30 Dezember 2021, 14:29:17
OT: vor allem an die "Main" Supporter wie Wernieman, Otto123, Cooltux, ...

würde es nicht Sinn machen, für Docker einen eigenen Forum-Knoten zu machen und die Probleme in eigene Posts zu trennen? Wenn ich mir die letzten Posts ansehe haben wir eigenständige Probleme, einmal Berechtigung von sluplus, das npm-Thema von maddhin ... die Themen haben nur wenig mit dem hier verwendeten Image zu tun sondern mehr wie man Docker bedient. Im 100-seitigen Thread sind sicher viele Informationen aber diese findet keiner mehr.

Außerdem wird es unübersichtlich wenn mehrere Probleme parallel supportet werden. Man muss immer aufpassen, dass man auf das richtige antwortet

... just my2cents ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Dezember 2021, 14:34:48
Du hast Recht. Nur ... eigentlich müssten dafür immer ein Neuer Thread aufgemacht werden. Solche Monsterthreads führen zu keiner Lösung mehr.

Nur die Maintainer können nichts dran ändern, das User lieber an Thread anhängen, als neue Aufmachen. Ist jetzt kein reines Docker-Thread-Problem ... sondern eines, von den Benutzern des Forum ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: slupus am 30 Dezember 2021, 14:44:13
Zitat von: Wernieman am 30 Dezember 2021, 13:10:09
Mit der Portangabe sagst Du nur Docker, NICHT fhem, das der Port 8084 von extern erreichbar sein soll, also von außerhalb der Docker-Welt. Die Fehlermeldung sagt dagegen aus, das fhem den Port 8083 nicht öffnen kann. Hast Du noch etwas auf dem Port 8083 laufen? Was sagt die fhem.cfg dazu?
Das war mir nicht bewusst. In der cfg stand natürlich 8083 (darauf läuft meine Prod Umgebung). Das abgeändert und die Testumgebung ist erreichbar.

Bleibt dennoch die Frage, was mit den Berechtigungen ist und wie diese greifen. Oder habe ich auch hier etwas nicht verstanden? Ich würde erwarten, dass das Verzeichnis auf dem Host entsprechend der Environment-Werte gesetzt wird. Leider sieht es aber wie folgt aus, hätte aber gerne 0754 für Verzeichnisse und 0644 für Files:

drwxr-x--- 15 6061 6061   4096 Dec 30 14:36 .
drwxr-xr-x  9 pi   root   4096 Dec 30 11:41 ..
-rw-r-----  1 6061 6061 369405 Nov 24 21:44 CHANGED
drwxr-x---  3 6061 6061   4096 Dec 30 11:53 .config
-rw-r-----  1 6061 6061  42987 Nov 24 21:44 configDB.pm
drwxr-x--- 52 6061 6061   4096 Nov 24 21:54 contrib
-rw-r-----  1 6061 6061  18092 Nov 24 21:44 COPYING
drwxr-x---  3 6061 6061   4096 Nov 24 21:54 demolog
drwxr-x---  4 6061 6061   4096 Dec 30 12:44 docs
drwxr-x---  6 6061 6061  20480 Dec 30 12:44 FHEM
-rw-r-----  1 6061 6061   2205 Dec 30 14:36 fhem.cfg
-rw-r-----  1 6061 6061   2205 Dec 30 14:36 fhem.cfg.bak
-rw-r-----  1 6061 6061    516 Dec 30 12:44 fhem.cfg.default
-rw-r-----  1 6061 6061  25544 Nov 24 21:44 fhem.cfg.demo
-rwxr-----  1 6061 6061 169103 Nov 24 21:44 fhem.pl
-rw-r-----  1 6061 6061  18092 Nov 24 21:44 GPL_V2.txt
-rw-r-----  1 6061 6061  28513 Nov 24 21:44 HISTORY
drwxr-x---  3 6061 6061   4096 Nov 24 21:54 lib
drwxr-x---  2 6061 6061   4096 Dec 30 14:36 log
-rw-r-----  1 6061 6061  44779 Nov 24 21:44 MAINTAINER.txt
-rw-r-----  1 6061 6061   5073 Nov 24 21:44 Makefile
drwxr-x---  3 6061 6061   4096 Dec 30 11:53 .npm
-rw-r-----  1 6061 6061     25 Nov 24 21:44 .proverc
-rw-r-----  1 6061 6061    935 Nov 24 21:44 README_DEMO.txt
-rw-r-----  1 6061 6061    374 Nov 24 21:44 README.SVN
drwx------  2 6061 6061   4096 Dec 30 14:36 .ssh
drwxr-x---  3 6061 6061   4096 Nov 24 21:54 t
drwxr-x---  3 6061 6061   4096 Nov 24 21:54 thirdparty
-rw-r-----  1 6061 6061   2693 Nov 24 21:44 UPGRADE
drwxr-x---  6 6061 6061   4096 Nov 24 21:54 webfrontend
drwxr-x---  8 6061 6061   4096 Nov 24 21:54 www
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 30 Dezember 2021, 14:55:27
Zitat von: slupus am 30 Dezember 2021, 14:44:13
Bleibt dennoch die Frage, was mit den Berechtigungen ist und wie diese greifen. Oder habe ich auch hier etwas nicht verstanden? Ich würde erwarten, dass das Verzeichnis auf dem Host entsprechend der Environment-Werte gesetzt wird. Leider sieht es aber wie folgt aus, hätte aber gerne 0754 für Verzeichnisse und 0644 für Files:


Wenn der Container neu erstellt wird, gibt das Script eine Meldung aus die auf das Ändern von Berechtigung hinweist? Siehst du die, welche Meldung wird da ausgegeben?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Dezember 2021, 14:58:22
User innerhalb Docker <> User Außerhalb Docker.
In der Docker-Compose steht kein User-Mapping.

Man sollte sich auch klar sein, wie Unix User überhaupt darstellt. In der Passwd steht zu jedem User eine ID-Zahl. Diese wird in der Datei gespeichert. Wenn Du also Wissen willst, welchem User eine Datei gehört, mußt das System die passwd nach der User-ID durchsuchen und dann den namen anzeigen. Da der Docker-FHEM-user scheinbar bei Dir die ID 6061 bekommt und natürlich in der System passwd diese User-ID nicht vergeben ist, zeigt er eben die ID an.

Edit:
Mal wieder zu langsam ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 30 Dezember 2021, 15:05:29
@sluplus network_mode: host
Damit wird nach meinen bescheidenen Kenntnissen das portmapping witzlos :)
Der Fehler kommt daher das auf deinem Host Port 8083 schon in Betrieb ist?

ich meine das muss so?
          - FHEM_PERM_DIR=0754
          - FHEM_PERM_FILE=0644

und ich rücke immer nur 2 Zeichen ein ;) ob das entscheidend ist weiß ich nicht. Ich habe die Regeln auch nicht zu 100% verstanden
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: slupus am 30 Dezember 2021, 15:08:21
Zitat von: kadettilac89 am 30 Dezember 2021, 14:55:27
Wenn der Container neu erstellt wird, gibt das Script eine Meldung aus die auf das Ändern von Berechtigung hinweist? Siehst du die, welche Meldung wird da ausgegeben?
Leider keine Meldung, die mir weiterhilft:

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' ...



/entry.sh: line 518: [: missing `]'
Preparing configuration ... done

Starting FHEM ...
2021.12.30 14:56:42.042 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.12.30 14:56:42.042 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.12.30 14:56:42.042 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.12.30 14:56:42.042 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m.log
2021.12.30 14:56:42.049 1: Including fhem.cfg
2021.12.30 14:56:42.246 3: WEB: port 8084 opened
2021.12.30 14:56:42.286 2: eventTypes: loaded 34 lines from ./log/eventTypes.txt
2021.12.30 14:56:42.603 3: AptToDate (fhemServerApt) - defined
2021.12.30 14:56:43.197 3: telnetPort: port 7073 opened
2021.12.30 14:56:43.197 1: Including ./log/fhem.save
2021.12.30 14:56:43.217 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.12.30 14:56:43.217 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.12.30 14:56:43.218 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.12.30 14:56:43.218 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m.log
2021.12.30 14:56:43.219 1: Messages collected while initializing FHEM:SecurityCheck:
  telnetPort is not password protected
  WEB is not password protected

Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none

2021.12.30 14:56:44.607 1: usb create starting
2021.12.30 14:56:44.646 1: usb create end
2021.12.30 14:56:44.648 0: Featurelevel: 6.1
2021.12.30 14:56:44.648 0: Server started with 11 defined entities (fhem.pl:25197/2021-11-07 perl:5.028001 os:linux user:fhem pid:4073)


Zitat von: Wernieman am 30 Dezember 2021, 14:58:22
Man sollte sich auch klar sein, wie Unix User überhaupt darstellt. In der Passwd steht zu jedem User eine ID-Zahl. Diese wird in der Datei gespeichert. Wenn Du also Wissen willst, welchem User eine Datei gehört, mußt das System die passwd nach der User-ID durchsuchen und dann den namen anzeigen. Da der Docker-FHEM-user scheinbar bei Dir die ID 6061 bekommt und natürlich in der System passwd diese User-ID nicht vergeben ist, zeigt er eben die ID an.
Der User 6061 is ja der default User des Docker Containers. Den will ich gar nicht ändern, sondern es sollen lediglich andere Rechte vergeben werden, damit die Dateien auch von anderen Usersn gelesen werden können.
Das versuche ich mit folgendem zu erreichen:

        environment:
            - FHEM_PERM_DIR=0754
            - FHEM_PERM_FILE=0644
            - UMASK=0033

Der Container setzt aber leider immer 0640, was dem default entspricht.

Zitat von: Otto123 am 30 Dezember 2021, 15:05:29
@sluplus network_mode: host
Damit wird nach meinen bescheidenen Kenntnissen das portmapping witzlos :)
Der Fehler kommt daher das auf deinem Host Port 8083 schon in Betrieb ist?
Danke Otto, habe ich vorhin in deinem Blogbeitrag gelesen, aber noch nicht abgeändert. Wie geschrieben läuft meine Prod Umgebung von FHEM auf Port 8083
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Dezember 2021, 15:16:04
Ahhh .... Du meinst also "Bug im FHEM-Container" ... denn von Docker werden diese Variablen nicht verwaltet
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 30 Dezember 2021, 15:16:30
@slupus Noch ein Tipp: betrachte den Container nicht als "Deinen" Host, verbiege ihn nicht unnötig und lass ihn so weit wie möglich so wie er ist. Das ist entspannter  ;D ;D ;D

Warum müssen andere user die Dateien lesen/schreiben? mM nach einer der Fehlerquellen schlechthin. Sozusagen schlechter Umgang :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 30 Dezember 2021, 15:23:05
Zitat von: slupus am 30 Dezember 2021, 14:44:13
Bleibt dennoch die Frage, was mit den Berechtigungen ist und wie diese greifen. Oder habe ich auch hier etwas nicht verstanden? Ich würde erwarten, dass das Verzeichnis auf dem Host entsprechend der Environment-Werte gesetzt wird. Leider sieht es aber wie folgt aus, hätte aber gerne 0754 für Verzeichnisse und 0644 für Files:


Nutze als Trenner ein Gleichheitszeichen und keinen Doppelpunkt wie in der Doku beschrieben

FHEM_PERM_DIR=0754 statt :0754

        environment:
            # - 'APT_PKGS=package1 package2'
            - LOGFILE=./log/fhem-%Y-%m.log
            - FHEM_PERM_DIR:0754     <<<<<<<<< FHEM_PERM_DIR=0754
            - FHEM_PERM_FILE:0644     <<<<<<<<<<
            - UMASK=0033
            - TZ=Europe/Berlin
            - TELNETPORT=7073
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 30 Dezember 2021, 15:30:26
OT:
Ich Troddel .. das ich das nicht gesehen habe ..... hast Gute Augen kadettilac89 ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 30 Dezember 2021, 15:32:17
ich hatte das oben auch noch ergänzt mit den Gleichheitszeichen - ihr schreibt zu schnell :)
Und es funktioniert mit den Variablen, gerade probiert:
Meine yml (TZ steht in der .env)
services:
  fhem:
    image: ghcr.io/fhem/fhem-experimental:dev
    container_name: fhem
    hostname: fhem
    restart: always
    ports:
      - "8083:8083"
      - "1883:1883"
    environment:
      - TZ
      - FHEM_PERM_DIR=0754
      - FHEM_PERM_FILE=0644
    volumes:
      - "./fhem/:/opt/fhem/"

total 820K
drwxr-xr-- 14 fhem fhem 4,0K Dez 30 15:25 .
drwxr-xr-x  1 root root 4,0K Nov 24 22:42 ..
-rw-r--r--  1 fhem fhem 361K Nov 24 21:44 CHANGED
-rw-r--r--  1 fhem fhem  42K Nov 24 21:44 configDB.pm
drwxr-xr-- 52 fhem fhem 4,0K Nov 24 21:54 contrib
-rw-r--r--  1 fhem fhem  18K Nov 24 21:44 COPYING
drwxr-xr--  3 fhem fhem 4,0K Nov 24 21:54 demolog
drwxr-xr--  4 fhem fhem 4,0K Dez 30 15:25 docs
drwxr-xr--  6 fhem fhem  20K Dez 30 15:24 FHEM
-rw-r--r--  1 fhem fhem 2,2K Dez 30 15:25 fhem.cfg
-rw-r--r--  1 fhem fhem  516 Dez 30 15:25 fhem.cfg.default
-rw-r--r--  1 fhem fhem  25K Nov 24 21:44 fhem.cfg.demo
-rwxr--r--  1 fhem fhem 166K Nov 24 21:44 fhem.pl
-rw-r--r--  1 fhem fhem  18K Nov 24 21:44 GPL_V2.txt
-rw-r--r--  1 fhem fhem  28K Nov 24 21:44 HISTORY
drwxr-xr--  3 fhem fhem 4,0K Nov 24 21:54 lib
drwxr-xr--  2 fhem fhem 4,0K Dez 30 15:25 log
-rw-r--r--  1 fhem fhem  44K Nov 24 21:44 MAINTAINER.txt
-rw-r--r--  1 fhem fhem 5,0K Nov 24 21:44 Makefile
drwxr-----  3 fhem fhem 4,0K Dez 30 15:25 .npm
-rw-r--r--  1 fhem fhem   25 Nov 24 21:44 .proverc
-rw-r--r--  1 fhem fhem  935 Nov 24 21:44 README_DEMO.txt
-rw-r--r--  1 fhem fhem  374 Nov 24 21:44 README.SVN
drwx------  2 fhem fhem 4,0K Dez 30 15:25 .ssh
drwxr-xr--  3 fhem fhem 4,0K Nov 24 21:54 t
drwxr-xr--  3 fhem fhem 4,0K Nov 24 21:54 thirdparty
-rw-r--r--  1 fhem fhem 2,7K Nov 24 21:44 UPGRADE
drwxr-xr--  6 fhem fhem 4,0K Nov 24 21:54 webfrontend
drwxr-xr--  8 fhem fhem 4,0K Nov 24 21:54 www

Versus Original ohne die Variablen
total 928K
drwxr-x--- 17 fhem fhem 4,0K Dez 22 13:31 .
drwxr-xr-x  1 root root 4,0K Nov 23  2020 ..
drwxr-x---  2 fhem fhem 4,0K Apr 24  2021 backup
-rw-r-----  1 fhem fhem  231 Feb  4  2021 .bash_history
drwxr-x---  2 fhem fhem 4,0K Dez 28 22:11 cache
-rw-r-----  1 fhem fhem 356K Jun 29  2021 CHANGED
drwxr-x---  3 fhem fhem 4,0K Jan 11  2021 .config
-rw-r-----  1 fhem fhem  41K Apr 24  2021 configDB.pm
drwxr-x--- 48 fhem fhem 4,0K Nov 16  2020 contrib
-rw-r-----  1 fhem fhem  18K Sep 18  2020 COPYING
drwxr-x---  3 fhem fhem 4,0K Sep 18  2020 demolog
drwxr-x---  4 fhem fhem 4,0K Jan 11  2021 docs
-rwxr-----  1 fhem fhem   78 Jan 14  2021 ext_Script.sh
drwxr-x---  6 fhem fhem  20K Jun 29  2021 FHEM
-rw-r-----  1 fhem fhem  42K Dez 22 13:31 fhem.cfg
-rw-r-----  1 fhem fhem  42K Dez 21 22:52 fhem.cfg.bak
-rw-r-----  1 fhem fhem  516 Jan 11  2021 fhem.cfg.default
-rw-r-----  1 fhem fhem  25K Sep 18  2020 fhem.cfg.demo
-rwxr-----  1 fhem fhem 165K Jun 29  2021 fhem.pl
-rw-r-----  1 fhem fhem  18K Nov  2  2020 GPL_V2.txt
-rw-r-----  1 fhem fhem  28K Sep 18  2020 HISTORY
drwxr-x---  3 fhem fhem 4,0K Sep 18  2020 lib
drwxr-x---  2 fhem fhem 4,0K Dez 30 09:19 log
-rw-r-----  1 fhem fhem  43K Jun 29  2021 MAINTAINER.txt
-rw-r-----  1 fhem fhem 5,0K Sep 18  2020 Makefile
drwxr-x---  3 fhem fhem 4,0K Feb  3  2021 .npm
-rw-r-----  1 fhem fhem   25 Sep 18  2020 .proverc
-rw-r-----  1 fhem fhem  935 Sep 18  2020 README_DEMO.txt
-rw-r-----  1 fhem fhem  374 Sep 18  2020 README.SVN
drwxr-x---  4 fhem fhem 4,0K Jan 12  2021 restoreDir
-rw-r-----  1 fhem fhem   28 Feb  4  2021 run.txt
-rwxr-----  1 fhem fhem 2,3K Jan 13  2021 setupBackupFhem2Cifs.sh
drwx------  2 fhem fhem 4,0K Dez 22 13:31 .ssh
drwxr-x---  3 fhem fhem 4,0K Sep 18  2020 t
-rw-r-----  1 fhem fhem 2,2K Sep 18  2020 UPGRADE
drwxr-x---  6 fhem fhem 4,0K Sep 18  2020 webfrontend
-rw-r-----  1 fhem fhem  180 Apr 29  2021 .wget-hsts
drwxr-x---  9 fhem fhem 4,0K Jan 12  2021 www
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: P.A.Trick am 30 Dezember 2021, 21:03:25
Zitat von: maddhin am 30 Dezember 2021, 13:54:05
.....

Wobei ich jetzt nicht weiß, ob die Wartung einfacher ist. Im Grunde macht die docker-compose doch einen stack aus mehreren einzelnen Containern, oder? D.h. man muss so oder so jeden Container warten. Wenn man natürlich MQTT, Homebridge, etc. gleich über "environment" in den FHEM container packen kann, wäre das viel besser. Gibt es dazu irgendwo Anleitungen?
.....

Schau mal ob dir das hier hilft! https://github.com/stormmurdoc/fhemdocker (https://github.com/stormmurdoc/fhemdocker)

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: slupus am 30 Dezember 2021, 21:54:47
Vielen Dank euch allen!
Es lag am Image fhem/fhem, bei dem die Environments Werte offensichtlich nicht greifen. Ich war der Meinung, ich hätte bei den Tests auf das Image von Cooltux (ghcr.io/fhem/fhem-experimental:dev) gewechselt, leider habe ich das übersehen. Sorry für die Verwirrung!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 31 Dezember 2021, 11:47:58
Un dnoch etwas, weil Du schriebst "alles in einen Container" ... Docker ist KEINE VM. Die idee ist gerade, jeden "Service" in einen eigenen Container zu packen, um es einfacher zu machen.

Bei mir ist z.B. deshalb lirc in einen eigenen Container. Gibt zwar ein FHEM Modul dafür, das pollt aber (nicht event passiert). Mein Container pushed aber die Daten zu fhem und ist damit "schneller" und einfach zu warten .... weil unabhängig von FHEM
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 07 Januar 2022, 00:32:49
es scheint, als könnte man das Image nicht mehr updaten. Oder mache ich etwas falsch?

root@13382b35a20d:/opt/fhem# sudo apt-get update
sudo: error in event loop: Operation not permitted
sudo: unexpected child termination condition: 0
Get:1 http://security.debian.org/debian-security bullseye-security InRelease [44,1 kB]
Get:2 http://deb.debian.org/debian bullseye InRelease [116 kB]           
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [39,4 kB]   
Hit:4 https://deb.nodesource.com/node_14.x bullseye InRelease                         
Err:1 http://security.debian.org/debian-security bullseye-security InRelease
  At least one invalid signature was encountered.
Err:2 http://deb.debian.org/debian bullseye InRelease
  At least one invalid signature was encountered.
Err:3 http://deb.debian.org/debian bullseye-updates InRelease
  At least one invalid signature was encountered.
Reading package lists... Done
W: GPG error: http://security.debian.org/debian-security bullseye-security InRelease: At least one invalid signature was encountered.
E: The repository 'http://security.debian.org/debian-security bullseye-security InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: GPG error: http://deb.debian.org/debian bullseye InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian bullseye InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: GPG error: http://deb.debian.org/debian bullseye-updates InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian bullseye-updates InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.


Ich hänge im Moment, weil ich keine packages installieren kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 07 Januar 2022, 10:18:02
sieht nach dem ghcr.io/fhem/fhem-experimental:dev aus? Update funktioniert bei mir. Deine Meldungen klingen als hast Du da was kaputt gemacht.
Zerstöre den Container und mach in einfach neu.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 07 Januar 2022, 12:21:33
Zitat von: Otto123 am 07 Januar 2022, 10:18:02
sieht nach dem ghcr.io/fhem/fhem-experimental:dev aus? Update funktioniert bei mir. Deine Meldungen klingen als hast Du da was kaputt gemacht.
Zerstöre den Container und mach in einfach neu.

ja, ich nutze dieses Image. Habe jetzt den Container mehrmals mit docker-compose up -d --build --force-recreate neu aufgesetzt. Aber es hat sich nichts geändert.

Das einzige, was ich ausserhalb des Containers gemacht habe, ist mal FHEM in die Sudoers eingetragen. Das habe ich aber rückgängig gemacht. Kann es sein, dass da etwas kaputt gegangen ist? Wie kann ich wissen, ob in dieser Hinsicht alles korrekt ist?

Lieben Dank für Eure Hilfe! 
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 07 Januar 2022, 12:54:17
Ich bin nicht so fit in allen docker Dingen, aber ich mache es so:
Wenn Du nur einen container rennen hast, sonst hinter -s den SERVICENAMEN angeben
docker-compose rm -s
docker-compose up -d


Das mit dem user fhem außerhalb des containers kann ich gedanklich nicht nachvollziehen - weiß nicht was da passieren kann.

BTW: wenn ich die Bedeutung von --build --force-recreate anschaue bin ich der Meinung beide Optionen sind hier nicht richtig verwendet.  Aber mag sein ich verstehe das falsch ???
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 07 Januar 2022, 13:40:44
Bei Problemen:
docker-compose down
docker-compose build
docker-compose up -d


Beim Down sollte docker-compose eigentlich aufreumen. Bei größeren Problemen, wie hier, kann und sollte) man docker cleanen, also "docker system prune -af"

Hinweis: -af wirklich nur bei Problemen! Normaler also nur "docker system prune"

fhem in die sudo auf dem Host zu nehmen ist .... sorry aber "totaler Schwachsin". Die externe sudo wird innerhalb des Containers nicht verwendet. Bitte sudo immer sehr vorsichtig einsetzen. In Zweifelsfalle immer eher zuwenig als zufiel, oder gleich "gar nicht".
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 07 Januar 2022, 14:31:28
Zitat von: Wernieman am 07 Januar 2022, 13:40:44
fhem in die sudo auf dem Host zu nehmen ist .... sorry aber "totaler Schwachsin".

Eine Verzweiflungstat, weil ich nicht nachvollziehen konnte, wo das Problem liegt. Ich hatte versucht die Amazon Echos mit dem Modul 37_echodevice zum Laufen zu bringen. Da wird ein npm Modul alexa-cookie2 installiert und irgendwie npm/nodejs benutzt und zum Teil automatisch was installiert. Irgendwie muss es da was zerschossen haben.

Wenn ich "down" etc mache, bleiben dann meine Daten bestehen? Oder geht das alles kaputt? Ich habe Backups, aber bisher noch kein "recovery" durchgespielt...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 07 Januar 2022, 14:36:47
Wenn DU Verzeichnisse "extern" hast, dann bleiben sie. Alle Daten innerhalb des Containers, welche eben externe nicht gespcieht wurden, sind mit dem Container "weg".

Laut Deiner docker-compose.yml ein paar Beiträger vorher, hast Du /opf/fhem zu extern ./fhem gemontet (Stichwort volumes). Die bleiben. Da nichts anderes Verbunden hast, ist alles andere "weg".
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 07 Januar 2022, 15:30:53
Zitat von: Wernieman am 07 Januar 2022, 14:36:47
Wenn DU Verzeichnisse "extern" hast, dann bleiben sie. Alle Daten innerhalb des Containers, welche eben externe nicht gespcieht wurden, sind mit dem Container "weg".

Laut Deiner docker-compose.yml ein paar Beiträger vorher, hast Du /opf/fhem zu extern ./fhem gemontet (Stichwort volumes). Die bleiben. Da nichts anderes Verbunden hast, ist alles andere "weg".

ja, habe ich!

Lieben Dank!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 07 Januar 2022, 15:55:32
ZitatIch hatte versucht die Amazon Echos mit dem Modul 37_echodevice zum Laufen zu bringen.
Guter Rat: entweder das ist im Image schon drin (da ist ne ganze Menge drin, ich kann es aber nicht sagen) oder Du hast eine 100% Anleitung wie das im Docker Image nachgerüstet werden kann. Am Besten ein Script was beim Start von docker eingebunden wird und alles automatisch macht. Oder noch besser dieses npm Zeugs kommt "extern" in einen extra "echodevice" container und im FHEM nur das define.
Wenn das alles nicht so ist (und nirgends was von Docker steht) lass es besser. Docker ist kein normaler host, im Image rumfummeln macht alle Vorteile von Docker für Dich kaputt und ist wahrscheinlich aufwendiger und komplizierter.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 07 Januar 2022, 18:17:28
Zitat von: Wernieman am 07 Januar 2022, 14:36:47
Da nichts anderes Verbunden hast, ist alles andere "weg".

Deshalb ergibt es eigentlich auch keinen Sinn innerhalb des Containers irgendwas mit apt zu machen. Bei der nächsten Änderung am compose file und einem d-compose down und up ist das alles weg...

Wenn man "Systemkomponenten" des Containers aktualisieren will, sollte man mittels Dockerfile ein neues Image bauen und dann daraus den Container erstellen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 07 Januar 2022, 18:51:21
Zitat von: passibe am 07 Januar 2022, 18:17:28
Deshalb ergibt es eigentlich auch keinen Sinn innerhalb des Containers irgendwas mit apt zu machen. Bei der nächsten Änderung am compose file und einem d-compose down und up ist das alles weg...

Man muss keine apt im Container installieren. Dafür bietet der Container die entsprechenden Parameter an. DAMit kann apt, NPM oder Perl mit installiert werden ohne eigene Dockerfile zu erstellen.

https://github.com/fhem/fhem-docker#add-custom-packages

Apt wäre z. B. -e APT_PKGS="package1 package2"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 07 Januar 2022, 20:13:19
Ja, klar. Das ist ja auch gut und nützlich, dass man zusätzliche Packages per Environment Variable installieren kann.

Ich wollte nur darauf hinweisen, dass ein aktualisieren irgendwelcher Pakete per apt-get update im laufenden Container keinen Sinn ergibt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 07 Januar 2022, 20:32:28
Zitat von: passibe am 07 Januar 2022, 18:17:28
Deshalb ergibt es eigentlich auch keinen Sinn innerhalb des Containers irgendwas mit apt zu machen.

ich dachte eigentlich, dass die "Maintenance" ist, die gemacht werden sollte. Aber ich nutze Docker primär, weil ich mich eben nicht gut mit Linux auskenne. In diesem Sinne, freut es mich, so also nichts machen zu müssen / sollen. In der Hinsicht finde ich die Docker Container genial. Insbesondere auch, um innerhalb von 5 min das System komplett neu aufsetzen zu können.

Ich werde jetzt mal das AlexaCookie2 als package reinschreiben und gucken, ob das dann funktioniert...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 07 Januar 2022, 20:59:14
Zitat von: maddhin am 07 Januar 2022, 20:32:28
ich dachte eigentlich, dass die "Maintenance" ist, die gemacht werden sollte.
Der Fhem-Container hat unter dem Knoten "system" das Device "fhemServerApt". Das zeigt dir an wenn etwas aktuallisiert werden soll. Das geht dann direkt in diesem Device über update (set toUpgrade).

Ansonsten neuen Container ziehen wenn ein UPdate verfügbar ist. Ist beim Fhem-Image nichdt so oft der Fall.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: DoubleD am 18 Januar 2022, 15:41:35
Hallo Leute

mich hat es jetzt auch erwischt und ich habe docker installiert und das FHEM image läuft.

Jetzt die Frage aller Fragen.
Wie bringe ich meine bestehendes FHEM in Docker?
Muss ich wirklich nur /opt/fhem als volume angeben.

Dann würde ja die vordefinierten module aus den demo verloren gehen. bzw auch die Änderungen am logdevice.

Gruß DD
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 18 Januar 2022, 16:32:01
Zitat von: DoubleD am 18 Januar 2022, 15:41:35
Hallo Leute

mich hat es jetzt auch erwischt und ich habe docker installiert und das FHEM image läuft.

Jetzt die Frage aller Fragen.
Wie bringe ich meine bestehendes FHEM in Docker?
Muss ich wirklich nur /opt/fhem als volume angeben.

Dann würde ja die vordefinierten module aus den demo verloren gehen. bzw auch die Änderungen am logdevice.

Wenn du das opt-Verzeichnis als Volume einbindest wird das verwendet. Welche "vordefinierten Module" meinst du? Wenn das Verzeichnis leer ist zieht Fhem die ganzen Dateien aus dem svn.

Wenn das Verzeichnis schon Dateien enthält wird nichts gelöscht.

Ich würde das Verzeichnis erstmal leer lassen bzw. durch Docker selbst erzeugen lassen. Wenn der Container läuft den Container stoppen und nur die selbst erstellten Dateien reinkopieren (fhem.cfg, fhem.save, dblog-Config, .... ggf. selbst erstelle Plots). Berechtigung korrigieren falls nötig und dann den Container wieder starten und testen und Log prüfen ob noch irgend was fehlt.

Wenn du das originale Verzeichins vorher sicherst kannst du immer wieder zurücksetzen und testen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 18 Januar 2022, 17:08:45
ZitatBerechtigung korrigieren falls nötig
Macht das nicht der Container sowieso beim Start?

@DoubleD Du machst das auf ein und derselben Maschine? Dann einfach docker FHEM auf ein anderes Port mappen und die bestehende FHEM Installation offline (also beide FHEM aus) vom /opt/fhem Pfad nach deinem docker Pfad kopieren. So kannst Du mit beiden testen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 18 Januar 2022, 18:03:54
Zitat von: Otto123 am 18 Januar 2022, 17:08:45
Macht das nicht der Container sowieso beim Start?
Ich hab nicht jedes Detail des  entry-Script im Kopf. Ob die Berechtiugngen nur im init-Event oder immer gesetzt werden müsste man prüfen.

Berechtigungen von irgend welchen Files ist ein wiederkehrendes Thema im Thread. Vermutlich gibt es Konstellationen wo das nicht wie gewünsccht funktioniert. Darum der Hinweis. Wenn nur ein paar DAteien kopiert werden ist es kein großer Akt und vermeidet vielleicht Probleme. Man kann acuh mal ohne den Schritt testen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: DoubleD am 18 Januar 2022, 19:51:18
@kadettilac89 und @Otto123

Danke für Eure Antworten!!!
Ich werds testen ;-)

Diese Erweiterungen meine ich... siehe Anhang
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 18 Januar 2022, 20:24:14
Zitat von: DoubleD am 18 Januar 2022, 19:51:18
Diese Erweiterungen meine ich... siehe Anhang
Die kommen mit dem Docker mit und werden wieder angelegt. Auch wenn du einen bestehednen Ordner einbindest.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 20 Februar 2022, 18:50:36
Zitat von: kadettilac89 am 07 Januar 2022, 20:59:14
Ansonsten neuen Container ziehen wenn ein UPdate verfügbar ist. Ist beim Fhem-Image nichdt so oft der Fall.

Ich arbeite daran. Allerdings nur noch in Github Packages (https://github.com/orgs/fhem/packages?repo_name=fhem-docker).

Die Zusätzlichen Laufzeitumgebungen (NodeJs, Python) bereiten mir allerdings Schwierigkeiten hinsichtlich Plattformunterstützung.
Am liebsten würde ich das alles in einer zukünftigen Version weg lassen und das ganze als reines FHEM Image ohne die Zusatzsoftware anbieten.
Die Zusatzdienste müsste man dann in eigenen containern unterbringen.


Der andere Punkt dem dem ich hadere ist das tag Schema. Aktuell lasse ich die Images auf Basis buster und bullseye bauen.
Ich fände etwas auf Basis vom semver geeigneter um hier Versionssprünge darstellen zu können.


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 Februar 2022, 11:28:42
Zitat von: Sidey am 20 Februar 2022, 18:50:36
Ich arbeite daran. Allerdings nur noch in Github Packages (https://github.com/orgs/fhem/packages?repo_name=fhem-docker).

Hast du damit Maintenance übernommen? CoolTux hatte ja den dev-Container vor einer Weile gebaut.

Aktuell funktioniert ja alles, apt-Updates können direkt aus Fhem gemacht werden, also keine Eile :)

fhem/fhem-minimal-docker finde ich gut, beschränkt auf Fhem mit weniger "Ballast". Werde ich mal testen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 21 Februar 2022, 11:49:10
Hey,
ich habe da auch mal eine Frage zum Phyton.
Nach wie vor scheint es einen Unterschied eine nativ installierten Buster oder Bulseye zum Docker Container zu geben.
Ich hatte mal versucht einen Vergleich zu machen, bekomme es aber leider nicht hin, dass alle Pakete gleich sind.

Gruß
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 Februar 2022, 12:31:38
fhem/fhem-minimal-docker würde ich auch seeehr interessieren
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 Februar 2022, 20:48:42
@Sidey
Zitat von: kadettilac89 am 21 Februar 2022, 11:28:42
fhem/fhem-minimal-docker finde ich gut, beschränkt auf Fhem mit weniger "Ballast". Werde ich mal testen.

kann es sein, dass dein "minimal" nur halb so groß ist? Portainer zeigt mir beim experimental von CoolTux 1.6 GB an, beim Minimal nur 790 MB. Scheint trotzdem zu funktionieren :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 Februar 2022, 21:33:21
Zitat von: kadettilac89 am 21 Februar 2022, 20:48:42
@Sidey
kann es sein, dass dein "minimal" nur halb so groß ist? Portainer zeigt mir beim experimental von CoolTux 1.6 GB an, beim Minimal nur 790 MB. Scheint trotzdem zu funktionieren :)

Ich habe beim minimal Image Compiler und Bibliotheken, sowie NodeJS und Python draußen gelassen. Für FHEM ist das völlig ausreichend.
Selbst die 790 MB erscheinen mir für Perl und die CPAN Module zu viel, aber durch das Weglassen von Paketen wird es halt kein Image für alle erdenklichen Fälle mehr.

Was genau ist aber das experimental von CoolTux?


Zitat von: kadettilac89 am 21 Februar 2022, 11:28:42
Hast du damit Maintenance übernommen? CoolTux hatte ja den dev-Container vor einer Weile gebaut.

Ich wiess nicht ob das "übernehmen" der richtige Begriff ist, allerdings möchte ich, dass die docker Container regelmäßig auf einen aktuellen Stand gebracht werden ohne dass ich im container ein apt- update etc. laufen lassen muss.

Beim alexa-fhem-docker läuft das schon eine Weile ganz gut und ich habe die Tags auch im Griff.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 Februar 2022, 21:41:26
Zitat von: Sidey am 21 Februar 2022, 21:33:21
Was genau ist aber das experimental von CoolTux?

ghcr.io/fhem/fhem-experimental:dev <-- das hier.

achso, ich hab npm und gassistant per parameter installieren lassen. Das erklärt vermutlich die Größe, dennoch ist halb so groß eine Hausnummer.

Jeder der will kann ja per Parameter apt, npm ... was auch immer nötig ist nachinstallieren. Das beschränkt trotzdem die Größe

Ich nutze mal das minimal, wenn es regelmäßig aktuallisiert wird um so besser. Danke dafür.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 Februar 2022, 21:44:10
Zitat von: kadettilac89 am 21 Februar 2022, 21:41:26
ghcr.io/fhem/fhem-experimental:dev <-- das hier.

Ah, das ist auch von mir :) Wird aber nicht mehr aktualisiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 Februar 2022, 22:16:31
Zitat von: Sidey am 21 Februar 2022, 21:44:10
Ah, das ist auch von mir :) Wird aber nicht mehr aktualisiert.

OK, vielleicht Fehlinterpretation meinerseits, oder Leon hat das Posten im Forum übernommen. Hauptsache wir haben kleinere Container :)

Meinte wegen dem hier
Zitat von: CoolTux am 20 Oktober 2021, 12:39:21
Es gibt nun einen fertigen Container zum testen

https://github.com/fhem/fhem-docker/pkgs/container/fhem-experimental


Bitte schaut einmal ob alles soweit läuft.

Zitat von: CoolTux am 03 November 2021, 15:41:15
Dann werde ich mal ein neues Image erstellen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 01 März 2022, 19:58:19
Hallo zusammen,
ich würde nun nach einer erneut kaputten SD-Karte am Pi auf meine Synology NAS DS220+ umsteigen. Habe gelesen das FHEM am besten über einen Docker-Container laufen soll.
Mit Docker habe ich bis dahin noch gar nichts am Hut gehabt. Habe mir ein paar Videos angeschaut und nun Docker und Docker-compose auf der NAS am laufen.
Nun die Frage welches Image ich am besten benutzen sollte. Es muss auf jeden Fall auch ein ConbeeII Stick mit integriert werden, falls das irgendwie relevant sein sollte.
Hat mir jemand da ein paar Einsteiger-Tipps oder sogar ein How-to-do?

Viele Grüße
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 März 2022, 20:08:30
Für den Conbee Stick nimmst Du bitte das Docker Image von deconz!
https://wiki.fhem.de/wiki/ConBee
https://github.com/deconz-community/deconz-docker.
Wenn Du magst findest Du in meinem Blog einen kleinen kurzen Workshop (Weltkugel unter meinem Bild)

Beim aktuellen FHEM Image bin ich unschlüssig ... Ich habe noch das alte laufen und mache mich gerade schlau um "das Dockerfile" zu verstehen.  ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 01 März 2022, 22:00:13
Zitat von: Otto123 am 01 März 2022, 20:08:30
Für den Conbee Stick nimmst Du bitte das Docker Image von deconz!
https://wiki.fhem.de/wiki/ConBee
https://github.com/deconz-community/deconz-docker.
Wenn Du magst findest Du in meinem Blog einen kleinen kurzen Workshop (Weltkugel unter meinem Bild)

Beim aktuellen FHEM Image bin ich unschlüssig ... Ich habe noch das alte laufen und mache mich gerade schlau um "das Dockerfile" zu verstehen.  ;)
Okay vielen Dank dir schon einmal. FHEM habe ich über Docker bereits am laufen. Conbee lasse ich mal am PI vorerst drauf, hab ich auch schon in FHEM wieder eingebunden.
Wie verhält es sich mit einem LaCrosse-Gateway? Das kann ich ja nicht als Gateway am Raspi lassen und in FHEM einbinden?
Wie verhält es sich mit dem MQTT2-Server? Habe mal versucht diesen einzurichten was auch geklappt hat aber kommen keine Geräte per autocreate an? Port und IP-Adressen stimmen aber?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 März 2022, 22:21:42
MQTT2_SERVER läuft völlig ohne Probleme. Hast Du denn den Port nach außen gereicht? -> Portmapping

Ich habe von LaCrosse keine Ahnung - aber das Wiki sagt da gibt es einen "Zoo" - da musst Du konkreter werden wenn Dir jemand helfen soll.
Generell sind serielle Schnittstellen normal kein Problem, alle andere Hardware durchreichen wird speziell. An einer NAS ist es nochmal speziell - aber hab ich nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 02 März 2022, 08:30:24
Zitat von: Otto123 am 01 März 2022, 22:21:42
MQTT2_SERVER läuft völlig ohne Probleme. Hast Du denn den Port nach außen gereicht? -> Portmapping

Ich habe von LaCrosse keine Ahnung - aber das Wiki sagt da gibt es einen "Zoo" - da musst Du konkreter werden wenn Dir jemand helfen soll.
Generell sind serielle Schnittstellen normal kein Problem, alle andere Hardware durchreichen wird speziell. An einer NAS ist es nochmal speziell - aber hab ich nicht.
Okay das mit dem LaCrosseGateway werde ich heute abend mal einfach versuchen einzubinden.

Den Port nach aussen gereicht habe ich nicht (zumindest nicht bewusst). Habe mein FHEM Docker mit folgendem Befehl eingerichtet:
sudo docker run -d --name fhem -p 8083:8083 -v fhem:/opt/fhem fhem/fhem

Kann ich das irgendwo im Portainer Webinterace sehen? Bzw. dann auch gleich freigeben?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 02 März 2022, 09:15:59
Zitat von: michisa86888 am 02 März 2022, 08:30:24
Kann ich das irgendwo im Portainer Webinterace sehen? Bzw. dann auch gleich freigeben?
Im Portainer Überblick der Container ist rechts in der Spalte eine Darstellung der Port Mappings.
VG   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 02 März 2022, 09:34:02
sudo  :o es gibt da normalerweise die Gruppe docker (kenne aber die Synology nicht)
-p 8083:8083 - mappt nur das Port 8083 vom Container zum Host. Also ist keines weiter erreichbar

Du kannst in portainer mW komplett die Verwaltung machen, allerdings mW nicht von "extern" gestarteten Containern.
Menüpunkt links Stacks dann add Stack - das entspricht docker compose - mMn viel einfacher als deine Kommandozeile :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 02 März 2022, 10:15:57
Okay das heisst für mich ich sollte meinen FHEM-Container nochmals neu aufsetzen mit Docker-compose über den Portainer Befehl. Habe bei dir im Blog eine docker-compose gesehen. Die könnte ich doch nutzen und auf meine Bedürfnisse anpassen. Homebridge z.B. entfernen und Zigbee2Mqtt/NodeRed/Grafana hinzufügen. Den Portainer kann ich dann in der compose auch entfernen den habe ich ja schon am laufen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 02 März 2022, 10:19:04
Zitat von: michisa86888 am 02 März 2022, 10:15:57
Okay das heisst für mich ich sollte meinen FHEM-Container nochmals neu aufsetzen mit Docker-compose über den Portainer Befehl. Habe bei dir im Blog eine docker-compose gesehen. Die könnte ich doch nutzen und auf meine Bedürfnisse anpassen. Homebridge z.B. entfernen und Zigbee2Mqtt hinzufügen. Den Portainer kann ich dann in der compose auch entfernen den habe ich ja schon am laufen?
Auch docker-compose wäre für Portainer extern, die Struktur ist jedoch trotzdem zu bedienen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 02 März 2022, 12:05:38
Ich kann wirklich nicht sagen wie man das an der Syno "gut" macht. Ich weiß, dass hier immer mal jemand "gejammert" hat weil er die Kommandozeile nicht findet :)
Ich mach halt immer portainer in der Kommandozeile, den Rest mit nano in ein docker-compose.yml und dann mit portainer "nur gucken". Da sagt portainer dann immer: "eingeschränkt weil extern"
Nun hab ich vorhin gesehen: man kann den Stack auch mit portainer erstellen. Ist sicher einfacher für jemanden, der die Kommandozeile und Linux Editoren scheut ;)
Ich habe hier ein paar einzel yml Dateien - die kannst Du als Vorlage nehmen https://github.com/heinz-otto/raspberry/tree/master/Docker
Die kompletten Vorlagen gibt es immer auf GitHub bei den jeweiligen Container Images.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 02 März 2022, 13:52:37
Zitat von: Otto123 am 02 März 2022, 12:05:38
Ich kann wirklich nicht sagen wie man das an der Syno "gut" macht. Ich weiß, dass hier immer mal jemand "gejammert" hat weil er die Kommandozeile nicht findet :)
Ich mach halt immer portainer in der Kommandozeile, den Rest mit nano in ein docker-compose.yml und dann mit portainer "nur gucken". Da sagt portainer dann immer: "eingeschränkt weil extern"
Nun hab ich vorhin gesehen: man kann den Stack auch mit portainer erstellen. Ist sicher einfacher für jemanden, der die Kommandozeile und Linux Editoren scheut ;)
Ich habe hier ein paar einzel yml Dateien - die kannst Du als Vorlage nehmen https://github.com/heinz-otto/raspberry/tree/master/Docker
Die kompletten Vorlagen gibt es immer auf GitHub bei den jeweiligen Container Images.

Okay top. Dann versuche ich das mal. Die Kommandozeile und Linux Editioren scheue ich nicht, werde es darüber versuchen. Eine Frage noch bevor ich heute abend loslege. Wie gehe ich mit dem bereits vorhandenen FHEM Container um? Einfach löschen und die Fhem-Instanz ebenfalls? Ist zwar noch nicht viel aber eigentlich schade um die Arbeit, die ich gestern reingesteckt habe.... Oder gibts nen anderen Weg diese zu übernehmen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 02 März 2022, 14:05:19
Zitat von: michisa86888 am 02 März 2022, 13:52:37
Wie gehe ich mit dem bereits vorhandenen FHEM Container um? Einfach löschen und die Fhem-Instanz ebenfalls? Ist zwar noch nicht viel aber eigentlich schade um die Arbeit, die ich gestern reingesteckt habe.... Oder gibts nen anderen Weg diese zu übernehmen?
Ich starte immer erst den FHEM Container, dann sollten sich dieVerzeichnisse vom neuen FHEM selber anlegen.
Danach einen Stop vom Container und das alte FHEM anschließend in das Container FHEM Kopieren.
Nach dem Container Start sollte dann soweit alles da sein.
Natürlich noch die USB Devices im Container frei geben.
Zum Schluss noch ein FHEM Update über die Container Installation des FHEM.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 02 März 2022, 14:58:58
Zitat von: michisa86888 am 02 März 2022, 13:52:37
... Wie gehe ich mit dem bereits vorhandenen FHEM Container um? Einfach löschen und die Fhem-Instanz ebenfalls? Ist zwar noch nicht viel aber eigentlich schade um die Arbeit, die ich gestern reingesteckt habe.... Oder gibts nen anderen Weg diese zu übernehmen?
Einfach den Container stoppen und entfernen. Die Daten bleiben ja erhalten.
Den Ausgangspunkt  - -v fhem:/opt/fhem - genauso wieder im docker-compose.yml eintragen. Achtung: der Quellpfad war relativ zum "aktuellen Standort" eingetragen! Entweder wieder so machen oder abslouten Pfad verwenden.
Dann geht es genau bei dem Stand weiter :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 02 März 2022, 18:18:09
Prinzipiell:
Immer achten, das persistente (Wichtige) Daten "extern" liegen, also nicht im Container.
Siehe auch https://docs.docker.com/storage/volumes/ (https://docs.docker.com/storage/volumes/) (Bitte aber nicht "memory"!)

Wenn Du das so machst, kannst Du einfach:
Neuen Container mit gleichen Verzeichnissen/Volumen und es muß laufen (Eventuell vorher Sicherheitskopie!)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 02 März 2022, 19:55:25
So habe mal jetzt zum testen folgende docker-compose zusammengestellt

version: '3'

services:
  fhem:
    image: fhem/fhem:latest
    container_name: fhem
    hostname: fhem
    restart: always
    ports:
      - "8083:8083"
      - "1883:1883"
    volumes:
      - "./fhem/:/opt/fhem/"
  grafana:
    image: grafana/grafana-enterprise:8.2.0
    ports:
      - 3000:3000
    user: '104'
volumes:
      - "./grafana/:/opt/grafana/"
  node-red:
    image: nodered/node-red:latest
    environment:
      - TZ=Europe/Amsterdam
    ports:
      - "1880:1880"
    networks:
      - node-red-net
    volumes:
      - node-red-data:/data

Jetzt wohin soll ich diese docker-compose über Konsole erstellen? Ins Docker-Verzeichnis wo z.B. das "alte" Fhem Verzeichnis liegt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 02 März 2022, 20:23:08
Das Dockercompose file kannst Du irgendwo ablegen, das ist egal.

Da Du auf einen ./fhem Ordner verweist, muss es dazu passend abgelegt werden.

Das verwendete Image fhem/fhem:latest ist allerdings nicht aktuell.
Hast Du das aus einer Anleitung?

Hier findest Du aktuelle Images:
https://github.com/fhem/fhem-docker

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 03 März 2022, 08:35:27
Zitat von: Sidey am 02 März 2022, 20:23:08
Das Dockercompose file kannst Du irgendwo ablegen, das ist egal.

Da Du auf einen ./fhem Ordner verweist, muss es dazu passend abgelegt werden.

Das verwendete Image fhem/fhem:latest ist allerdings nicht aktuell.
Hast Du das aus einer Anleitung?

Hier findest Du aktuelle Images:
https://github.com/fhem/fhem-docker

Grüße Sidey
Hallo Sidey,
sind das dann jetzt die offiziellen Images? Ich verwende auch schon immer das fhem/fhem:latest .
VG  Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 03 März 2022, 21:30:17
Zitat von: Otto123 am 01 März 2022, 22:21:42
Ich habe von LaCrosse keine Ahnung - aber das Wiki sagt da gibt es einen "Zoo" - da musst Du konkreter werden wenn Dir jemand helfen soll.
Generell sind serielle Schnittstellen normal kein Problem, alle andere Hardware durchreichen wird speziell. An einer NAS ist es nochmal speziell - aber hab ich nicht.
Also habe diesen Jeelink-Lacrosse
https://www.amazon.de/dp/B07T61BXLX?ref_=pe_27091401_487187591_302_E_DDE_dt_1 (https://www.amazon.de/dp/B07T61BXLX?ref_=pe_27091401_487187591_302_E_DDE_dt_1)
Habe ihn nun versucht über folgendes define einzubinden (wird so in der Artikelbeschreibung angegeben und hat damals am PI auch ohne Probleme funktioniert)
define JeeLinkLaCrosse JeeLink /dev/serial/by-id/usb-SHK_JeeLink_LaCrosse-if00-port0@57600
Das Device steht aber immer auf disconnected auch ein Versuch am zweiten USB-Port der NAS hat nicht geholfen

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 03 März 2022, 22:06:19
wie sieht Dein device Mapping für den Container aus?
Beispiel deconz:
    devices:
      - /dev/serial/by-id/${CONBEE}:/dev/ttyACM0
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 03 März 2022, 22:22:14
Zitat von: Wernieman am 21 Februar 2022, 12:31:38
fhem/fhem-minimal-docker würde ich auch seeehr interessieren
@Werner Du möchtest sowas  (https://heinz-otto.blogspot.com/2022/03/dockerfile-image-fur-den-container.html)?  ;D
Es ist nicht FHEM all inclusive sondern eher FHEM pur
Sehr viel kleiner als ein debian basiertes Image und auch kleiner als ein leeres FHEM selbst  ???
Zitatdocker image ls
REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
minifhem     latest    d0b2a4c00eb3   6 hours ago    47.9MB
du -sh docker/fhem
219M    docker/fhem
Aber es ist bisher nur eine "persönliche Machbarkeitsstudie" 8) und für diesen Thread leicht OT.
Wenn Interesse besteht, können wir gern - in einem neuen Thread - experimentieren ;) ich wollte es nur mal versuchen und lernen

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 03 März 2022, 22:36:17
Zitat von: Otto123 am 03 März 2022, 22:06:19
wie sieht Dein device Mapping für den Container aus?
Beispiel deconz:
    devices:
      - /dev/serial/by-id/${CONBEE}:/dev/ttyACM0

Finde ich das in Portainer auch irgendwo (finde da nichts)
Habe den weiteren Mqtt-Port auch über Portainer hinzugefügt da es mit der docker-compose nicht so richtig klappen wollt...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 03 März 2022, 22:50:50
Naja, ob Du da irgendwas "findest" spielt keine Rolle - Du musst es einrichten! Von allein passiert da nichts!
Finden tust Du es (sehr tief) in Inspect / Hostconfig / Devices / 0|1 ...
Wie sieht denn Dein docker-compose aus?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 04 März 2022, 07:33:06
Zitat von: michisa86888 am 03 März 2022, 22:36:17
Finde ich das in Portainer auch irgendwo (finde da nichts)

https://forums.portainer.io/t/how-to-connect-attach-pass-an-usb-device-to-a-container/310
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 04 März 2022, 08:19:12
@Otto
Gerne in einem neuen Thread, dann kann ich Dir auch mein Dockerfile geben .... auch wen ich es schon irgendwo hier gepostet hatte ....

Edit:
Meines ist übrigens 297MB groß ... ist aber auch schon etwas "mehr" einkompiliert ...

Edit2:
Es ist aber auch ein Debian (Ubuntu) Image und kein Alpine .... sehr interessant Dein Ansatz ..
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 04 März 2022, 10:45:16
Alpine ist sehr viel besser für Container geeignet, weil es so reduziert ist.

@Otto: wenn du in deinem Dockerfile ein "RUN" nutzt, dann kannst du auch dort files per wget runterladen. Man muss nur daran denken, dass jedes RUN das aktuelle Verzeichnis verliert. Heißt man muss das immer erst wieder setzen.

also z.B.


RUN cd /opt/fhem && wget http://.... && chmod ....


Ein, für mich, sehr lehrreiches Beispiel ist auch https://github.com/instantlinux/docker-tools/blob/main/images/duplicati/Dockerfile

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 05 März 2022, 13:36:00
Ich würde RUN auch versuchen zusammenzuschmeißen. Bei jedem RUN wird eine eigene "Dockerschicht" erzeugt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: klugec am 09 März 2022, 09:23:55
Hallo,

im Moment nutze das offizielle FHEM aus dem Dockerhub. Wie ich mitbekommen habe ist die Version auf Github aktueller (ghcr.io/fhem/fhem/fhem-docker:buster).
In der Beschreibung steht drin das alexa-fhem und tradfri-fhem nicht vorinstalliert ist.
Wie müsste ich das nachträglich installieren? Ich nutze für all meine Anwendungen Docker-Compose (yaml).

Ich danke euch für eure Antworten.


LG
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 09 März 2022, 09:44:01
Ich denke, für alexa-fhem einen separaten container nehmen: https://github.com/fhem/alexa-fhem-docker
Zumindest meine Hoffnung, stehe nämlich auch kurz vor der Umstellung eines solchen Systems.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 09 März 2022, 10:14:01
Zitat von: klugec am 09 März 2022, 09:23:55
Hallo,

im Moment nutze das offizielle FHEM aus dem Dockerhub. Wie ich mitbekommen habe ist die Version auf Github aktueller (ghcr.io/fhem/fhem/fhem-docker:buster).
In der Beschreibung steht drin das alexa-fhem und tradfri-fhem nicht vorinstalliert ist.
Wie müsste ich das nachträglich installieren? Ich nutze für all meine Anwendungen Docker-Compose (yaml).

Wenn du die Dienste in Fhem-Container willst hast du den Parameter s. u. da kannst du  beim Erstellen des Containers die Pakete installieren lassen. Beispiel für google-home von mir. npm müsste bei dir schon installiert sein, kannst dann auch weglassen.


            NPM_PKGS: "npm gassistant-fhem"


Alternativ, wenn npm bei dir enthalten ist, kannst du unter Menüpunkt System->node.js alexa-fhem / tradi-fhem nachinstallieren. Das musst jedesmal machen wenn das Image aktuallisiert wird.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: klugec am 10 März 2022, 09:16:34
Zitat von: kadettilac89 am 09 März 2022, 10:14:01
Wenn du die Dienste in Fhem-Container willst hast du den Parameter s. u. da kannst du  beim Erstellen des Containers die Pakete installieren lassen. Beispiel für google-home von mir. npm müsste bei dir schon installiert sein, kannst dann auch weglassen.


            NPM_PKGS: "npm gassistant-fhem"


Alternativ, wenn npm bei dir enthalten ist, kannst du unter Menüpunkt System->node.js alexa-fhem / tradi-fhem nachinstallieren. Das musst jedesmal machen wenn das Image aktuallisiert wird.

Vielen Dank für die schnelle Antowrt. Ich werde mich damit mal befassen und bei Fragen oder Problemen melde ich mich wieder.  :)

EDIT:

Ich bekomme über docker-compose eine Fehlermeldung wenn ich die yaml ausführe:

Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/
Pulling fhem (ghcr.io/fhem/fhem/fhem-docker:buster)...
ERROR: manifest unknown


Der Teil in meiner yaml sieht so aus:

  #Hausautomation FHEM
  fhem:
    restart: always
    ports:
      - "$FHEM_PORT:8083"
      - "7072:7072"
      - "1883:1883"
      - "8090:8090"
      - "8383:8383"
      - "3002:3002"
    image: ghcr.io/fhem/fhem/fhem-docker:buster
    depends_on:
      - mariadb
    container_name: fhem
    volumes:
      - $DOCKERDIR/fhem:/opt/fhem/
    networks:
      t2_proxy:
        ipv4_address: 192.168.91.249
    environment:
      FHEM_UID: 1000
      FHEM_GID: 1000
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      GPIO_GID: 6002
      TZ: $TZ
      NPM_PKGS: "alexa-fhem tradfri-fhem alexa-cookie2"
    labels:
      ## Watchtower
      - "com.centurylinklabs.watchtower.enable=true"


Hab ich da jetzt einen Denkfehler? Hab bisher immer nur mit dem dockerhub gearbeitet
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 10 März 2022, 14:08:53
Zitat von: klugec am 10 März 2022, 09:16:34
Ich bekomme über docker-compose eine Fehlermeldung wenn ich die yaml ausführe:

Building with native build. Learn about native build in Compose here: https://docs.docker.com/go/compose-native-build/
Pulling fhem (ghcr.io/fhem/fhem/fhem-docker:buster)...
ERROR: manifest unknown



Ich vermute für die CPU-Architekur gibt es (noch) keinen Container. Hast du den Docker auf einen Raspberry versucht? ARM-CPU ... Teste mal mit dem originalen Image, das gibt es für Raspberry CPU
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: klugec am 10 März 2022, 17:40:27
Zitat von: kadettilac89 am 10 März 2022, 14:08:53
Ich vermute für die CPU-Architekur gibt es (noch) keinen Container. Hast du den Docker auf einen Raspberry versucht? ARM-CPU ... Teste mal mit dem originalen Image, das gibt es für Raspberry CPU

Ich nutze einen raspberry pi 4 8gb mit dem offiziellen pi OS 64-bit (buster). Fhem aus dem docker hub funktioniert ohne Probleme. Weiß nicht ob man mit einem github Image irgendwas anders machen muss?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 10 März 2022, 19:53:04
im Dockerhub steht beim offiziellen Image ARM64v8 - im ghcr.io/fhem/fhem/fhem-docker:buster steht was von linux/arm64

Ich finde den Zustand vom "offziellen FHEM Docker Basis Image" ziemlich verwurschtelt. Ich seh da nicht mehr durch. Das ist weder Basis noch für den Laien verständlich - aber ich will nicht meckern, ich habe keinen Ansatz zu helfen. Vielleicht versuch ich deswegen, die Sache mit dem Dockerfile zu verstehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 10 März 2022, 20:21:55
Zitat von: klugec am 10 März 2022, 17:40:27
Ich nutze einen raspberry pi 4 8gb mit dem offiziellen pi OS 64-bit (buster). Fhem aus dem docker hub funktioniert ohne Probleme. Weiß nicht ob man mit einem github Image irgendwas anders machen muss?
So wie es aussieht wurden die (dev)-Container nur für amd64 CPU erstellt aber nicht für die Raspberry ARM-CPU. Da musst du warten bis sich der Maintainer meldet.

Verwende erstmal das Original Image. Du kannst später immer noch ein anderes Image verwenden ohne dass du Daten verlierst.

Alternativ kannst du dir das Image selber erstellen. Dockerfile ist verfügbar ... lohnt vermutlich aber nicht. Weiß nicht wie viel Ahnung du davon hast.

Edit:
Teste mal dieses Image hier ... das ist auch als arm64 getaggt ... das lädt dann explizit arm64 für den rpi runter. Als Test ob die Manifest-Meldung noch kommt.

ghcr.io/fhem/fhem/fhem-minimal-docker:dev-buster@sha256:2d328e8c35060f8b2b4bcdbc819c0776b2bd8a5e35340c26c242ba2c18eb3ad0
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: klugec am 10 März 2022, 22:20:27
Zitat von: kadettilac89 am 10 März 2022, 20:21:55
So wie es aussieht wurden die (dev)-Container nur für amd64 CPU erstellt aber nicht für die Raspberry ARM-CPU. Da musst du warten bis sich der Maintainer meldet.

Verwende erstmal das Original Image. Du kannst später immer noch ein anderes Image verwenden ohne dass du Daten verlierst.

Alternativ kannst du dir das Image selber erstellen. Dockerfile ist verfügbar ... lohnt vermutlich aber nicht. Weiß nicht wie viel Ahnung du davon hast.

Edit:
Teste mal dieses Image hier ... das ist auch als arm64 getaggt ... das lädt dann explizit arm64 für den rpi runter. Als Test ob die Manifest-Meldung noch kommt.

ghcr.io/fhem/fhem/fhem-minimal-docker:dev-buster@sha256:2d328e8c35060f8b2b4bcdbc819c0776b2bd8a5e35340c26c242ba2c18eb3ad0

Ich habe es mal getestet. Das funktioniert komischerweise ohne Probleme.
Bei dem anderen Image steht ja auch Linux/ARM64 dabei, aber wieso das nicht funktioniert weiß ich nicht. Da bin ich nicht tief genug in der Materie drin
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 10 März 2022, 22:23:30
Zitat von: Otto123 am 10 März 2022, 19:53:04
Ich finde den Zustand vom "offziellen FHEM Docker Basis Image" ziemlich verwurschtelt.

Kannst Du das etwas präziser benennen was undurchsichtig ist?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 10 März 2022, 23:05:54
Zitat von: klugec am 10 März 2022, 22:20:27
Ich habe es mal getestet. Das funktioniert komischerweise ohne Probleme.
Bei dem anderen Image steht ja auch Linux/ARM64 dabei, aber wieso das nicht funktioniert weiß ich nicht. Da bin ich nicht tief genug in der Materie drin
Funktioniert es auch mit dem Namen ohne dem @sha-Teil?
ghcr.io/fhem/fhem/fhem-minimal-docker:dev-buster

Das ist nicht das Image von dir, sondern ein anderes. Ich weiß jetzt nicht woher du den anderen Link hast. Entweder es ist generell nicht mehr vorhanden, oder es wurde (damals) nicht für arm erstellt. Ich glaube das war eines der ersten in Github mit der Container-Registry.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 10 März 2022, 23:08:44
Zitat von: kadettilac89 am 10 März 2022, 23:05:54
Funktioniert es auch mit dem Namen ohne dem @sha-Teil?
ghcr.io/fhem/fhem/fhem-minimal-docker:dev-buster

Geht auch ohne. Alles was nach dem @ kommt, spezifiziert die Version.
Ich strebe an, sowas wie @3.0.0-buster oder @3.0.0-bullseye zu veröffentlichen.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 11 März 2022, 08:27:28
Zitat von: Sidey am 10 März 2022, 23:08:44
Geht auch ohne. Alles was nach dem @ kommt, spezifiziert die Version.

Der Test mit dem @sha-Teil war dazu gedacht es generell zu testen. klugec hatte mit einer anderen github-Version einen Manifest-Error, ich konnte die Version mit amd64 aber ziehen. Der mit/ohne sha-Test sollte nur seine Installation von docker-compose bestätigen.

Wenn manifest cpu amd64 + arm64 enthält müsste es gehen. Da es neuere Github-Versionen gibt habe ich auch nicht mehr das ältere Image sondern ein aktuelles zum Testen vorgeschlagen. Wenn es mit dem neueren auch ohne @sha geht (Test von mir angefragrt) dann braucht es keiner weiteren Analyse.



Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: klugec am 11 März 2022, 09:54:24
Zitat von: kadettilac89 am 11 März 2022, 08:27:28
Der Test mit dem @sha-Teil war dazu gedacht es generell zu testen. klugec hatte mit einer anderen github-Version einen Manifest-Error, ich konnte die Version mit amd64 aber ziehen. Der mit/ohne sha-Test sollte nur seine Installation von docker-compose bestätigen.

Wenn manifest cpu amd64 + arm64 enthält müsste es gehen. Da es neuere Github-Versionen gibt habe ich auch nicht mehr das ältere Image sondern ein aktuelles zum Testen vorgeschlagen. Wenn es mit dem neueren auch ohne @sha geht (Test von mir angefragrt) dann braucht es keiner weiteren Analyse.

Es funktioniert auch ohne den @sha teil. Nur so für mich, was bedeutet das jetzt?

Den anderen Link hatte ich aus Github
https://github.com/fhem/fhem-docker

docker pull ghcr.io/fhem/fhem/fhem-minimal-docker:buster
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 11 März 2022, 11:45:20
Zitat von: Sidey am 10 März 2022, 22:23:30
Kannst Du das etwas präziser benennen was undurchsichtig ist?
Ich will da niemanden angreifen, ich würde eher gern helfen, weiß aber nicht richtig wie. Ich weiß auch noch zu wenig... nicht nur von Docker sondern auch von Github  :-[
Aber wenn ich versuche als "Einsteiger" mir ein Bild zu machen welches FHEM Docker Image ich jetzt nutzen sollte?  ???
Die Frage taucht ja immer mal hier auf: welches Image nehme ich denn nun? So ganz knackig hat da aber keiner eine Antwort. ;)

Die Docker Hub Seite (https://hub.docker.com/r/fhem/fhem)  - 10 Monate nichts passiert, da steht unten in der Ecke auch noch Production Build Error.
Ok von dort, oder über Suche, oder diesen Monsterthread findet man dann die Github Seite (https://github.com/fhem/fhem-docker) - die Readme ist mittlerweile von Dir aufgeräumt - danke! Da war in meinem Kopf noch der Zustand von Anfang des Jahres. :)

Ich habe versucht den Code (Dockerfile entry.sh usw.) in Struktur und Inhalt zu verstehen um Erkenntnisse für meine Tests zu gewinnen - schwierig. ;) alles Historisch gewachsen? ;)
mMn ist da auch Code drin, der nicht das macht was gedacht war -> zum Test:
ls willi.txt 2>&1>/dev/null      # normale Ausgabe unterdrückt, aber Fehler wird trotzdem ausgegeben
ls willi.txt >/dev/null 2>&1     # keine Ausgabe
ls willi.txt 2>/dev/null         # keine Ausgabe von Fehlern
Könnte mich ja wieder mal in Pullrequest üben ;)

Ich denke vor allem, es ist kein Basis Image. Und mit minimal wird doch versucht das Monster wieder zu reduzieren - oder? Aber mag sein ich verstehe es falsch. Wie gesagt: nur meine Gedanken - keine Kritik.
Wäre der umgekehrte Weg nicht besser? Wirklich Basis neu aufbauen anstatt zu versuchen einen "FHEM all in one PC" im Docker abzubilden?
Ich war selbst vor einem guten Jahr sehr froh über dieses Image, was einfach so funktionierte. Aber es steckt ja offenbar ein großer Wartungsaufwand dahinter.
Ich habe die Image Dockerphilosophie mittlerweile als einzelne Scheibchen und nicht als ganze Brote verstanden.  :D

Vielleicht auch diesen Thread schließen und einen neuen aufmachen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 11 März 2022, 12:28:25
Zitat von: klugec am 11 März 2022, 09:54:24
Es funktioniert auch ohne den @sha teil. Nur so für mich, was bedeutet das jetzt?

Das bedeutet dass du jetzt eine funktionierende Configuration hast :)

Scheinbar ist bei dem anderen Image was falsch gewesen, beim Erstellen, testen ... was auch immer.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 11 März 2022, 18:28:44
Wenn man jetzt ein altes Image (wo alles drin war) in Verwendung hat und möchte auf ein neues umsteigen, sagen wir mal
docker pull ghcr.io/fhem/fhem/fhem-docker:bullseye
und man hat bisher alexa-fhem (Vereins) Connector (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa) im Einsatz. Was macht man dann genau?
-e NPM_PKGS="alexa-fhem" und alles rennt wieder?
Oder kann man auch https://github.com/fhem/alexa-fhem-docker als zweiten Container neben an stellen? Offenbar nicht? Zumindest stand das hier  (https://forum.fhem.de/index.php/topic,60452.msg1028003.html#msg1028003)mal.
Auf der Github Seite steht zwar auch der Link zum Wiki, aber im Wiki wird alexa-fhem als Container nicht erwähnt und man suggeriert: alles muss in einer Maschine. ???

Ich mach das mit der Umstellung für jemand anderes, ich will mich da möglichst vorbereiten - selbst habe ich alexa nicht  ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 11 März 2022, 18:41:42
Zitat von: Otto123 am 11 März 2022, 18:28:44
Wenn man jetzt ein altes Image (wo alles drin war) in Verwendung hat und möchte auf ein neues umsteigen, sagen wir mal
docker pull ghcr.io/fhem/fhem/fhem-docker:bullseye
und man hat bisher alexa-fhem (Vereins) Connector (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa) im Einsatz. Was macht man dann genau?
-e NPM_PKGS="alexa-fhem" und alles rennt wieder?
Oder kann man auch https://github.com/fhem/alexa-fhem-docker als zweiten Container neben an stellen? Offenbar nicht? Zumindest stand das hier  (https://forum.fhem.de/index.php/topic,60452.msg1028003.html#msg1028003)mal.
Auf der Github Seite steht zwar auch der Link zum Wiki, aber im Wiki wird alexa-fhem als Container nicht erwähnt und man suggeriert: alles muss in einer Maschine. ???

Ich mach das mit der Umstellung für jemand anderes, ich will mich da möglichst vorbereiten - selbst habe ich alexa nicht  ;)

Ich nutze den Minimal-Docker in dem weder npm noch google-home drin ist. Da reicht der Parameter. Ich weiß nicht ob in dem von dir genannten Image npm mit drin ist. Vermutlich schon, dann kannst npm weg lassen.

Wenn npm im Image drin ist, kannst die Fhem Erweiterungen auch im node.js nachinstallieren. Ich meine System->node.js ... da "set outdated" und dann "set install alexa-fhem" in deinem FAll.


            NPM_PKGS: "npm gassistant-fhem"


Die Frage zu alexa im separaten Container kann ich nichts sagen, ich nutze kein alexa.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 12 März 2022, 10:00:10
Zitat von: Otto123 am 11 März 2022, 18:28:44
Wenn man jetzt ein altes Image (wo alles drin war) in Verwendung hat und möchte auf ein neues umsteigen, sagen wir mal
docker pull ghcr.io/fhem/fhem/fhem-docker:bullseye
und man hat bisher alexa-fhem (Vereins) Connector (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa) im Einsatz. Was macht man dann genau?
-e NPM_PKGS="alexa-fhem" und alles rennt wieder?
Ja das sollte prinzipiell so funktionieren, allerdings nehme ich an, dass es sich nicht auf allen Varianten installieren lässt, sonst hätte ich es nicht aus dem Build rausgenommen.


Zitat von: Otto123 am 11 März 2022, 18:28:44
Oder kann man auch https://github.com/fhem/alexa-fhem-docker als zweiten Container neben an stellen? Offenbar nicht? Zumindest stand das hier  (https://forum.fhem.de/index.php/topic,60452.msg1028003.html#msg1028003)mal.
Ich habe alexa-fhem bisher ausschließlich über einen eigenen Container betrieben. Ich will doch nicht in meiner Hausautomatisierung einen direkten Zugriff von außerhalb.
Das funktioniert, wie im Thread beschrieben bis auf den automatischen restart des Prozesses, wobei ich den auch noch nie wirklich gebraucht habe.
Wenn das eine zwingend nötige Funktion ist, dann könnte man das aber sicherlich auch über eine named pipe oder einen http Endpunkt einbauen.

Zitat von: Otto123 am 11 März 2022, 18:28:44
Auf der Github Seite steht zwar auch der Link zum Wiki, aber im Wiki wird alexa-fhem als Container nicht erwähnt und man suggeriert: alles muss in einer Maschine. ???

Hmm ja, das stimmt. Das Wiki war vermutlich auch vor dem Container da.

Zitat von: Otto123 am 11 März 2022, 11:45:20
Aber wenn ich versuche als "Einsteiger" mir ein Bild zu machen welches FHEM Docker Image ich jetzt nutzen sollte?  ???
Die Frage taucht ja immer mal hier auf: welches Image nehme ich denn nun? So ganz knackig hat da aber keiner eine Antwort. ;)

Ich kann dokerhub leider nicht editieren, da mir die Berechtigungen fehlen. Die hat meines Wissens nach genau eine Person.
Würde hier eine Wiki Seite helfen die auf die Github Pages seite mit den dort veröffentlichten Images verweist?


Zitat von: Otto123 am 11 März 2022, 11:45:20
Ich denke vor allem, es ist kein Basis Image. Und mit minimal wird doch versucht das Monster wieder zu reduzieren - oder? Aber mag sein ich verstehe es falsch.
Wäre der umgekehrte Weg nicht besser? Wirklich Basis neu aufbauen anstatt zu versuchen einen "FHEM all in one PC" im Docker abzubilden?

Das Basis Image ist eher ein rundum Sorglos Paket, da gebe ich dir Recht.
Die Idee mit dem minimal Image kam mir, da ich den ganzen nodejs Krams im FHEM Image nicht brauche.

Ein Basis Image mit nur benötigtem aufzubauen fände ich durchaus interessant. Bisher ist mir aber nicht gelungen festzustellen was wird alles benötigt.
Als Anwender könnte ich erwarten, dass alles was mit dem mitgelieferten FHEM an Modulen dabei ist auch funktioniert. Das fängt bei der Vielzahl an PERL Modulen an, geht aber weiter da einige Module dann z.B. Python Kommandos aufrufen. Jetzt können wir natürlich das wiederum jedem selbst übelassen seine benötigten Module nach zu installieren, aber welchen Nutzen hat das image dann überhaupt wenn es jeder Modifizieren muss.

Zitat von: Otto123 am 11 März 2022, 11:45:20
Ich habe die Image Dockerphilosophie mittlerweile als einzelne Scheibchen und nicht als ganze Brote verstanden.  :D
Vielleicht auch diesen Thread schließen und einen neuen aufmachen?

1) Neuer Thread gerne
2) Für die Scheiben brächte es eine Art Erweiterungsmöglichkeit. Es gibt da ja Ansätze von linuxserver.io hinsichtlich Mods (https://github.com/linuxserver/docker-mods) Gänzlich verstanden habe ich es allerdings nicht und es ist mindestens eine Umstellung und größerer Aufwand für die Nutzer des Images.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 12 März 2022, 18:49:34
Zitat von: kadettilac89 am 11 März 2022, 18:41:42
Ich nutze den Minimal-Docker in dem weder npm noch google-home drin ist. Da reicht der Parameter. Ich weiß nicht ob in dem von dir genannten Image npm mit drin ist. Vermutlich schon, dann kannst npm weg lassen.

            NPM_PKGS: "npm gassistant-fhem"

Wenn ich den Code richtig lese: ist es eigentlich noch "schlimmer/komfortabler" :) er installiert einfach alles nach: nur alexa-fhem angeben, nodejs und npm kommen von selbst. also NPM_PKGS: "gassistant-fhem" sollte reichen. Aber eigentlich will ich das so nicht.
ZitatDie Idee mit dem minimal Image kam mir, da ich den ganzen nodejs Krams im FHEM Image nicht brauche.
Genau!
Ich denke Java und nodejs waren der Ausgangspunkt für die Entwicklung von docker. ;) Keiner will sich selbst um nodejs kümmern müssen. Insofern muss die Strategie sein: separate Container für jede nodejs Anwendung!
Aber im Falle alexa-fhem finde ich nur immer den Hinweis: der "Vereinsconnector " (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa) braucht alexa-fhem lokal - oder sagt bloß keiner wie es genau geht?
Na gut ich werde es testen  :-\ oder mich ergeben.
ZitatEin Basis Image mit nur benötigtem aufzubauen fände ich durchaus interessant. Bisher ist mir aber nicht gelungen festzustellen was wird alles benötigt.
Als Anwender könnte ich erwarten, dass alles was mit dem mitgelieferten FHEM an Modulen dabei ist auch funktioniert. Das fängt bei der Vielzahl an PERL Modulen an, geht aber weiter da einige Module dann z.B. Python Kommandos aufrufen. Jetzt können wir natürlich das wiederum jedem selbst übelassen seine benötigten Module nach zu installieren, aber welchen Nutzen hat das image dann überhaupt wenn es jeder Modifizieren muss.
Ich bin jetzt seit meinem ersten Schritt Anfang März auf einem ganz guten Stand. Aus meiner Sicht  bietet mein Image (https://github.com/heinz-otto/fhem-docker) alles was ich so in FHEM bisher betreibe, vielleicht müssen noch ein paar Perl Libs rein. Ich habe auch ein paar Gimmicks eingebaut, die ich im offiziellen Image vermisst habe. Ich habe aber auch viele - aus meiner Sicht - Kompromisse weggelassen.
Jedes Stück Code was ich so gefunden und adaptiert habe, wurde konsequent hinterfragt und ich habe wirklich bei fast null begonnen. Ich glaube jetzt ist nichts überflüssig und es läuft.
Plattformabhängigkeit ist bisher von mir nicht berücksichtigt, die gibt es bisher vielleicht auch nicht? Ich habe bisher auf arm getestet, probiere dann mal noch intel.

Wo ich absolut noch keinen Plan habe ist github packages und der gesamte build Prozess den es da offenbar im Hintergrund gibt. Mir ist nicht klar wie aus den Dateien die auf github  (https://github.com/fhem/fhem-docker)liegen die einzelnen packages  (https://github.com/orgs/fhem/packages?repo_name=fhem-docker)werden. :-[

Das aber alles - was in FHEM so vorhanden sein könnte - auch in einem Container funktioniert, halte ich fast für nicht ausführbar. Das ist neben der Vielfalt auch der Wettlauf von Hase und Igel.

Python
Habe ich nicht drin, wäre an sich kein Ding, bläht das Image auf...
Warum?  ??? Kann man nicht fertige python Container  (https://hub.docker.com/_/python)nebenanstellen? Die python Entwickler haben doch alle eine Schnittstelle zu FHEM, das braucht doch nicht im gleichen Container laufen? Die können doch prima ein eigenes Image liefern?
Das meinte ich mit Scheiben. (Das fhem Basis Image ist derzeit ein komplettes Brot)  ;D

Den Benutzer etwas nachinstallieren zu lassen - halte ich für einen Designfehler! Das wirft das Container Konzept über den Haufen. Der Gedanke, dass ich wegen alexa-fhem beim "Container frisch machen" eine halbe Stunde auf nodejs und Co warten muss bringt mir das Gruseln.  :'(
Normalerweise muss es doch nur zwei updates beim FHEM Container geben:
um FHEM zu pflegen
update                 # in der FHEM Kommandozeile
um das System zu pflegen
docker compose pull    # irgendwann, zeitunkritisch, kann auch Stunden dauern
docker compose up -d   # zeitkritsch, weil die Hausautomatisierung neu startet


Was steht hier ganz oben?  8)
ZitatFHEM ist ein Perl Server für die Haustechnik.
Derzeit hat mein Image knapp 290 MB und ich meine es ist alles drin. :) ich würde mich freuen wenn es jemand anschauen mag.

Schönes Restwochenende noch
Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 20 März 2022, 21:37:44
Hallo zusammen,
irgendwie bekomme ich es nicht hin auf mein /opt/fhem Verzeichnis zuzugreifen. So wie ich gelesen habe sollte man das Verzeichnis irgendwie ausserhalb des Containers legen?
Würde nun aber ungern mein FHEM nochmals neu auflegen. Wie kann ich aufs Verzeichnis zugreifen wenn es innerhalb des Containers liegt?
Habe mal ein Screenshot angehängt von meinem Volume details im Portainer.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 21 März 2022, 09:21:57
Hi,

was meinst Du mit zugreifen? Was willst Du denn tun?

Du kannst das auch umstellen und die Daten aus dem Docker Volume herauskopieren (der Pfad oben) diese in einem neuen Pfad (außerhalb der Docker Volumes) ablegen und diesen Pfad wieder in den Container mounten.

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 21 März 2022, 17:30:36
Zitat von: Otto123 am 21 März 2022, 09:21:57
Hi,

was meinst Du mit zugreifen? Was willst Du denn tun?


Gruß Otto

Aktuell will ich mein Zertifikat für mein Worx_Robbi irgendwie nach /opt/fhem in den Container bringen. So wie ich das bis jetzt gelesen habe müsste das bei mir nur über docker -cp funktionieren da mein Volume innerhalb des Containers liegt? Hoffe das habe ich so richtig verstanden. Jetzt könnte ich aber mittels docker -cp das ganze Verzeichnis /opt/fhem aus dem Container herauskopieren - ein Verzeichnis auf dem Host wählen und das ganze auslagern vom Container. Damit wäre es später einfacher solche Sachen zu erweitern?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 März 2022, 18:35:18
Dann sollte man grundsätzlich machen, das persistente Daten AUßERHALB des Containers liegen. Auch sich Ändernde Daten wie Logfiles etc. haben nichts in einem Container zu suchen. Das hat auch mit dem Schichtmodel des Containers zu tun  (Soll ich es wirklich hier ausbreiten?)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 21 März 2022, 18:41:09
Ok, dafür kannst Du aber jetzt auch unkompliziert die Konsole öffnen: Portainer / Containers / fhem Quick Actions auf Exec Console klicken. Dann nochmal auf connect und dort kannst Du die Datei auch klassisch mit scp kopieren ;)
scp user@host:DeinDateiname .Der Punkt am Ende ist wichtig! Damit landet die Datei im aktuellen Verzeichnis welches /opt/fhem sein sollte.

docker -cp hab ich noch nicht gemacht, geht sicher auch :)

Wie hast Du FHEM backup gelöst?
Alternative Idee: Mach ein backup mit FHEM, kopiere die Backupdatei mit scp weg und stelle sie außerhalb wieder her.

Viele Wege ... Aber wie Werner sagt: umstellen! Aber auch Zeit lassen und nichts kaputt machen :)

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 02 April 2022, 16:52:35
Ich wollte meine Docker-Instanz von fhem/fhem auf ghcr.io/fhem/fhem/fhem-docker:bullseye upgraden...
Nur will das ganze nicht mit der Fehlermeldung:
Starting FHEM ...
bash: line 1: cd: /opt/fhem: Permission denied
Can't open perl script "fhem.pl": Permission denied
Unable to start FHEM process - errorcode 13

Wenn ich wieder zurückgehe startet fhem ohne probleme...
Auch wenn ich das ganze praktisch nackt in einen neuen Ordner(ohne meine config) starten will ist das gleiche Problem.
Was mache ich falsch?
gruß anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 02 April 2022, 17:09:10
Schau mal nach welchem Benutzer dein FHEM-Verzeichnis/die Dateien darin gehören und unter welchem Benutzer der alte Container und unter welchem Benutzer der neue Container läuft.
Vermutlich ist da eine Diskrepanz und du kannst entweder den neuen Container so einstellen, dass der unter dem Benutzer des alten läuft oder du gibst per chown dem Benutzer des neuen Containers die Berechtigung für das FHEM-Verzeichnis.

Edit: Okay, bisschen komisch, dass es auch im leeren Ordner nicht funktioniert. Scheint ja aber alles ein Berechtigungsproblem zu sein, passen denn beim leeren Ordner die Berechtigungen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 02 April 2022, 17:22:21
beide haben den gleichen user und gleiche group (6061:6061)...
der einzige Unterschied ist der Mode der beim funktionierenden 2750 ist und bei dem leeeren neuen (der aber auch die gleiche Fehlermeldung zeigt) 0644
im ordner habe alle Mode 0640 außer fhem.pl das hat 0740 in beiden ordnern
gruß anton

läuft bei mir unter ubuntu server 20.04.4
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 02 April 2022, 17:30:01
0644 ist rw-r--r--, also für den owner nur read und write, kein execute.
Die fhem.pl muss ja aber ausgeführt werden, braucht also auch die execute permission.
Du müsstest das wenn dann also auf 744 ändern (oder 755, wenn sie nicht dem Benutzer gehört, der sie ausführt).
Ob ggfs. noch weitere Dateien die execute permission brauchen, oder dort 640 "genug" ist, weiß ich nicht, müsstest du dann testen, wenn FHEM einmal läuft.

Edit: Sorry, ich sollte das echt genauer lesen. Deine fhem.pl hat ja schon 7xx, das passt.
Aber er sagt ja auch
"cd: /opt/fhem: Permission denied"
das "cd"-Kommando erzeugt also schon den Fehler.
Deshalb 0644 vom Ordner mindestens auf 0744 stellen, dann passts.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 02 April 2022, 17:38:05
die einzig ausführbare hat ja 0740 - ist also für den besitzer ausführbar und 0640 reicht im allgmeinen auch sonst würde das image fhem/fhem ja nicht laufen und das tut es immerhin schon seit knapp 2 Jahren...

und den Ordner fhem auf 744 zu ändern hat auch nicht funktioniert da das start script die rechte wieder auf 2750 ändert. Wobei die 2 Stelle mit 2*7*50 ja sowieso ausführbar ist für den Besitzer...

ich bleib wohl besser bei buster unter fhem/fhem...
gruß Anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 02 April 2022, 19:48:49
und woweit ich es verstehe ändert das startup script die Dateirechte so das es eigentlich laufen sollte - tut es aber nicht...
mein docker-compose.yml
version: '3'

services:

###fhem

   fhem:
     container_name: fhem
     restart: always
     privileged: true
#     image: ghcr.io/fhem/fhem/fhem-docker:bullseye   # geht nicht außer fhem ordner auf 0740 stellen
     image: fhem/fhem
#     image: ghcr.io/fhem/fhem/fhem-minimal-docker:buster
     ports:
       - "8083:8083"
       - "8084:8084"
       - "8087:8087"
       - "1882:1882"
     networks:
       - datenbank
       - traefik_proxy
     volumes:
       - /mnt/1/SSDA/fhem:/opt/fhem
     devices:
       - /dev/bus/usb/001/002
     environment:
     # test 17-10-21
#        - NPM_PKGS: "npm@8.1.0"
# die Variablen werden allerdings nicht ausgewertet!!!
      - PUID=1000
      - PGID=1000
      - FHEM_PERM_DIR=0644
      - FHEM_PERM_FILE=0644
#       - APT_PKGS="libjson-perl libmp3-info-perl libnet-upnp-perl"
#       - CPAN_PKGS="MP3::Info"
     labels:
       - "autoheal=true"
       - "traefik.enable=true"
       - "traefik.backend=fhem"
       - "traefik.frontend.rule=Host:fhem.xxx.xy"
       - "traefik.port=8083"
       - "traefik.docker.network=traefik_proxy"
       - "traefik.frontend.headers.SSLRedirect=true"
       - "traefik.frontend.headers.STSSeconds=315360000"
       - "traefik.frontend.headers.browserXSSFilter=true"
       - "traefik.frontend.headers.contentTypeNosniff=true"
       - "traefik.frontend.headers.forceSTSHeader=true"
       - "traefik.frontend.headers.SSLHost=xxx.xy"
       - "traefik.frontend.headers.STSIncludeSubdomains=true"
       - "traefik.frontend.headers.STSPreload=true"
       - "traefik.frontend.headers.frameDeny=true"

networks:
  datenbank:
    external: true
  traefik_proxy:
    external: true

obiges funktioniert problemlos so wie es dasteht aber sobald ich fhem/fhem auskommentiere und eines der beiden anderen nehme läuft es nicht mehr...
gruß anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 02 April 2022, 20:03:34
Also ohne jetzt genau zu wissen, ob entry.sh etwas bei den jeweiligen images unterschiedlich macht:

Es ergibt für mich keinen Sinn, dass deine Env-Variable
FHEM_PERM_DIR=0644
auf 0644 steht.


entry.sh wendet 0750 nur dann an, wenn das nicht von dir über die Env-Variable überschrieben wird.
Siehe hier https://github.com/fhem/fhem-docker/blob/dev/src/entry.sh (https://github.com/fhem/fhem-docker/blob/dev/src/entry.sh) Zeile 21:
FHEM_PERM_DIR="${FHEM_PERM_DIR:-0750}"

Deshalb: Kommentier FHEM_PERM_DIR mal aus oder setz es auf 0750. Was passiert dann?

Edit:
Das was Zeile 21 da macht nennt sich anscheinend Shell Parameter Expansion, siehe hier: https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html (https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html)
${parameter:-word}
If parameter is unset or null, the expansion of word is substituted. Otherwise, the value of parameter is substituted.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 02 April 2022, 20:30:17
Vielleicht noch etwas zum Verständnis, weil du schreibst

Zitat von: antonwinden am 02 April 2022, 17:38:05die einzig ausführbare hat ja 0740

Das stimmt so nicht ganz – denn fhem.pl ist nicht das einzige, was ausführbar sein muss.
Directories müssen in der Regel auch ausführbar sein, damit man z.B. "rein" cd-en kann, oder darin ls ausführen kann.
Siehe https://unix.stackexchange.com/questions/150449/what-does-execute-permission-mean-on-a-folder (https://unix.stackexchange.com/questions/150449/what-does-execute-permission-mean-on-a-folder).

Wenn das fehlt geht z.B. cd nicht, was entry.sh aber auf Zeile 164 ausführt.
Deshalb auch die Fehlermeldung in deinem ersten Beitrag
bash: line 1: cd: /opt/fhem: Permission denied
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 02 April 2022, 21:21:38
stimmt
FHEM_PERM_DIR=0644
war der Übeltäter
danke anton
Titel: Docker auf der Syno - Installation GD CPAN
Beitrag von: Dirk070 am 14 April 2022, 16:22:25
Hallo zusammen,

ich hoffe, ihr könnt mir helfen. FHEM läuft auf der Syno mit diesem Docker Container.
Leider sind die Möglichkeiten auf der Syno recht eingeschränkt.

Ein Beispiel, für einen USB-Lesekopf (hier im Forum um den Stromzähler auszulesen) wäre ein Paramter für das Run-Command nötig gewesen:
o --device=/dev/bus/usb/001/002

--device ist hier leider nicht zulässig, siehe http://blog.pavelsklenar.com/how-to-install-and-use-docker-on-synology/ (http://blog.pavelsklenar.com/how-to-install-and-use-docker-on-synology/)
Ich habe dann die Settings exportiert und in der JSON den Teil hinzugefügt, das hat funktioniert.

devices" : [
       {
           "pathOnHost": "/dev/ttyUSB0",
           "PathInContainer": "/dev/ttyUSB0",
           "CgroupPermissions": "rwm"
       }
   ],


So, nun möchte ich hier aus dem Forum das Modul für die e-Paper-Displays nutzen (ESPEInk) und dazu braucht es GD for Perl https://metacpan.org/pod/GD (https://metacpan.org/pod/GD)
Laut Doku https://github.com/fhem/fhem-docker/ (https://github.com/fhem/fhem-docker/) sollte es so gehen:

-e CPAN_PKGS="App::Name1 App::Name2"

Laut einem Hinwies geht es auf der Syno so https://stackoverflow.com/questions/56833111/how-to-pass-command-parameters-with-arguments-for-e-g-param1-arg1-to-docker (https://stackoverflow.com/questions/56833111/how-to-pass-command-parameters-with-arguments-for-e-g-param1-arg1-to-docker)

execname --param1\=arg1

Also habe ich das entsprechend umgesetzt auf

execname --CPAN_PKGS\=App::GD

Container gestartet und im Log geschaut - keine Meldung, weder Success noch Error.

Wie kann ich kontrollieren, ob GD nun im Container verfügbar ist und kennt sich auf der Syno jemand mit dem korrekten Prozedere aus?
Wie man merkt habe ich noch eher wenig Erfahrung mit Docker.....Danke Euch daher vorab!!

Schöne Grüße
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 15 April 2022, 11:02:40
Kannst Du Dich auf der Syno in den Container einloggen?

Normalerweise geht es mit:
docker exec -it <Containername> /bin/bash
<Containername> und eventuell /bin/bash bitte anpassen.
Hinweis:
Bitte normalerweise nicht benutzen, aber für Debugzwecke sehr hilfreich
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 15 April 2022, 13:53:56
Danke für Deine Unterstützung, schaue ich mir an.
Ich habe jetzt auch Portainer auf der Syno installiert, um die Limitierungen der Syno-App zu umgehen.

In Portainer müsste man doch nun eine environment variable setzen, nach diesem Aufbau:
CPAN_PKGS="App::Name1

Also dann in name:
CPAN_PKGS

Und in value:
App::GD

Wäre das so in Portainer korrekt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 15 April 2022, 14:34:49
Guuuute Frage, kenne den FHEM Container und Portainer nicht. Bin ein "Shell-Futzi"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Dirk070 am 15 April 2022, 19:56:27
Danke Wernieman für Deine Hilfe.

In Portainer kommt man auch auf ein bin/bash Terminal.

Ein Hinweis, um die installierte Version von GD herauszufinden war: cpan -D GD

Das bringt folgendes Ergebnis:

Loading internal logger. Log::Log4perl recommended for better logging
Reading '/root/.cpan/Metadata'
  Database was generated on Fri, 15 Apr 2022 15:29:03 GMT
GD
-------------------------------------------------------------------------
        (no description)
        R/RU/RURBAN/GD-2.76.tar.gz
        /usr/lib/x86_64-linux-gnu/perl5/5.28/GD.pm
        Installed: 2.71
        CPAN:      2.76  Not up to date
        Reini Urban (RURBAN)
        reini.urban@gmail.com


Im ersten Moment dachte ich also, dass die Installation im Container mit der environment variable funktioniert hat.
Dann habe ich aber das selbe Kommando in meinem ursprünglichen Container (also ohne die envrionment variable) abgesetzt und bekam das identische Ergebnis.

Also entweder ist GD schon im Standard-Container enthalten oder ich prüfe mit dem Kommando nicht nur auf die Version, sondern installiere GD damit.

Könnte mir jemand helfen, hier Licht ins Dunkel zu bringen? Sorry, ich bin diesbezüglich (leider noch) Anfänger.....

EDIT:
habe gerade ein "cpan -l | grep GD" probiert und dies als Ergebnis bekommen:
GD      2.71
GD::Group       1
GD::Image       2.71
GD::Polygon     2.71
GD::Polyline    0.2
GD::Simple      undef


Also scheint tatsächlich GD bereits im Standard dabei zu sein, bis auf GD::Simple (wenn ich das undef richtig interpretiere).
Stimmt meine Vermutung?

Lässt sich das GD denn mit der enviroment variable updaten (auf 2.76) oder passiert dabei nichts, weil GD schon installiert ist?

Danke vorab und vielel Grüße
Dirk
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 16 April 2022, 16:39:44
undef heist nur, das er zum installierten kein Versionsnummer hat ... jedenfalls interpretier ich es so.

Wie Du per cpan updates .... mir nicht bekannt. Versuche aus "historischen Gründen" cpan zu vermeiden ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 19 April 2022, 14:00:12
Hallo,

ich bräuchte mal Hilfe beim Update meines Fhem-Dockers.
Und zwar versuche ich vergebens npm und nodejs auf einen aktuellen Stand zu bringen.

Alles was ich bisher dazu gelesen habe hat mich mehr verwirrt als geholfen.
Dazu kommt, dass der Docker auf einem QNAP-NAS läuft und nur über dieses kleine Terminal-Fenster Einzelbefehle annimmt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 19 April 2022, 15:58:12

Ich weiß, das reicht Dir nicht, aber mehr Info ergibt mehr Info :)
hast Du docker compose oder per docker "pur" ?

Docker compose ist recht einfach:
docker-compose.yml die Zeile image: fhem/fhem ändern in image: ghcr.io/fhem/fhem/fhem-docker:bullseye
docker-compose up -d
fertig.

docker pur etwas mehr :
docker stop ...
docker rm ...
docker pull ghcr.io/fhem/fhem/fhem-docker:bullseye
In Deiner docker Start Zeile den Image Namen austauschen z.B. von fhem/fhem:latest nach ghcr.io/fhem/fhem/fhem-docker:bullseye
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 20 April 2022, 11:03:54
docker Container "zerstören"
quelle für image ändern
neues Image ziehen ghcr.io/fhem/fhem/fhem-docker:bullseye
container starten
fertig


Es muss doch eine andere Möglichkeit geben als diese.
Dieses Prozedere habe ich in den letzten beiden Jahren aus verschiedenen Gründen schon mehrfach durch exerziert.

Mein Problem ist doch eigentlich nur, dass ich die beiden Devices "Fhem Installer Status" und "Node.js Package Update Status" nicht aktualisiert bekomme. Wofür gibt es diese Dinger wenn sie nicht funktionieren. Oder funktionieren Sie nur wegen dem NAS nicht?

Wenn ich dir mehr Informationen geben könnte, würde ich das gerne tun, aber beispielsweise sagt mir Docker compose und Docker pur rein gar nichts. Ich habe zwar in HTML und anderen Programmiermöglichkeiten Grunderfahrungen aber bin trotzdem nur ein einfacher Anwender ohne tiefergehende Kenntnisse.
Soll heißen: Ich wüsste weder den Unterschied, noch wie ich diesen herausfinden kann und schon gar nicht wie ich ggf. die genannte Datei finden sollte. Besonders wichtig, dass ich immer wieder nicht verstehe wie bzw. wo ein Befehl gerade eingegeben werden muss.

Wenn du spezielle Informationen brauchst versuche ich gerne diese beizubringen, aber ich brauche eine Info was genau und am besten wo genau ich es finde.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 April 2022, 11:12:05
Docker <> VM. Ja bei einer VM würdest Du so vorgehen. bei Docker gibt es aber fertige upgedatete (und normalerweise getestete) Container, warum sollte man dann einen Sonderweg gehen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 20 April 2022, 11:23:44
Zitat von: Superposchi am 20 April 2022, 11:03:54
docker Container "zerstören"
quelle für image ändern
neues Image ziehen ghcr.io/fhem/fhem/fhem-docker:bullseye
container starten
fertig


Es muss doch eine andere Möglichkeit geben als diese.

Gibt es, aber diese ist nicht im Sinne eines Containers. Der ist so gemacht, dass er einfach ausgetauscht wird. Einzelne Bestandteilen eines Containers zu erneuern ist nicht das, wofür Container gemacht sind.


Was ist denn der Grund, dass Du eine abweichende Vorgehensweise suchst?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 20 April 2022, 11:30:40
Zitat von: Superposchi am 20 April 2022, 11:03:54
Mein Problem ist doch eigentlich nur, dass ich die beiden Devices "Fhem Installer Status" und "Node.js Package Update Status" nicht aktualisiert bekomme. Wofür gibt es diese Dinger wenn sie nicht funktionieren. Oder funktionieren Sie nur wegen dem NAS nicht?
Das Image, welches Du verwendest ist alt - Asbach Uralt. Was Du beschreibst ist bei allen so, nicht nur bei Dir.
Das typische Prozedere wie man einen docker Container aktuell macht habe ich Dir erklärt.
Wenn Dir docker pur|cli (oder wie immer man die Kommandozeile bezeichnen mag) und docker-compose nichts sagen, muss es ja dann einen völlig anderen Weg geben wie Du docker auf deinem NAS betreibst!?

Du missverstehst ev. "das Prozedere" - es geht nicht um "neu einrichten", oder um "Verlust Deiner Daten". Es geht lediglich um ein neues Image. Deswegen die Empfehlung, wirf das alte weg und nimm ein neues.
Das Prozedere ist eine Sache von wenigen Minuten down time für Dein FHEM und bei schlechter Internetverbindung noch ein paar Minuten für das Image ziehen, was aber vor dem Wechsel passieren kann.

Wenn Du aber nicht sagen kannst, wie Du Dein (docker) System betreibst, kann Dir auch keiner gezielt helfen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 20 April 2022, 11:58:30
ZitatWas ist denn der Grund, dass Du eine abweichende Vorgehensweise suchst?
Der Grund ist einfach der, dass ich aus allgemeinen Computerabläufen keinen Sinn darin sehe etwas funktionierendes plattzumachen um etwas upzudaten. Der Begriff "Never change a running System" sagt dir doch bestimmt auch etwas, oder?

ZitatWenn Du aber nicht sagen kannst, wie Du Dein (docker) System betreibst, kann Dir auch keiner gezielt helfen.
Das NAS hat eine App "Container-Station". Darin wird der Fhem-Docker geladen und gestartet. Da alles unter dieser Oberfläche läuft bzw. innerhalb der Station kann ich kaum Angaben über die Art des Betriebs machen.

ZitatDas Image, welches Du verwendest ist alt - Asbach Uralt. Was Du beschreibst ist bei allen so, nicht nur bei Dir.
Das letzte Mal habe ich den Container vor ca. 4, max. 5 Monaten erneuert. Wenn er jetzt schon "uralt" ist, wie kann ich dann sicherstellen, dass der nächste Container den ich ziehe nicht wieder alte Komponenten enthält. Es kann ja kaum in 4-5 Monaten so viele Änderungen gegeben haben, dass der Container damals aktuell gewesen sein soll und jetzt uralt.

ZitatDu missverstehst ev. "das Prozedere" - es geht nicht um "neu einrichten", oder um "Verlust Deiner Daten". Es geht lediglich um ein neues Image. Deswegen die Empfehlung, wirf das alte weg und nimm ein neues.
Doch ich verstehe das Prozedere schon, habe es ja mehrmals gemacht. Ich verstehe nur die Logik dahinter nicht. In der gesamten Computerwelt bedeuten Updateprozesse einzelne Programme durch neuen Code zu ersetzen ohne das Betriebssystem zu erneuern.
Es kommt für mich von der Logik mit dem Schritt gleich statt ein Windowsupdate zu machen, Eine Komplettsicherung zu machen, Windows dann komplett zu löschen und inkl. der aktuellsten Änderungen neu aufzuspielen und anschließend sie Sicherung wieder einzuspielen.

ZitatDocker <> VM. Ja bei einer VM würdest Du so vorgehen. bei Docker gibt es aber fertige upgedatete (und normalerweise getestete) Container, warum sollte man dann einen Sonderweg gehen?
Für mich ist dieser Weg eher der Sonderweg, weil er eben nicht den üblichen Prozessen in der Computerwelt entspricht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 April 2022, 12:31:38
@Superposchi

ich empfinde deine Art und Weise ehrlich gesagt als ziemlich schnippisch und leicht arrogant in Anbetracht der Tatsache, dass du hier eigentlich Hilfe erbittest und schon mit gewissen docker-Grundbegriffen (compose, cli) und dem Konzept Probleme hast.
Dann mit der großen Keule der "gesamten Computerwelt" zu argumentieren, finde ich etwas abenteuerlich....

Ich versuche es trotzdem noch einmal, da ich auch FHEM auf einem QNAP betreibe.

Im Hintergrund der Container Station läuft ein ganz normales Dockersystem. Die Container Station ist nur eine Oberfläche. Du kannst dort den Container stoppen, das Image neuladen (=aktualisieren) und den Container über die Weboberfläche neu aufsetzen. Vielleicht braucht es das letzte nicht mal und es reicht ein einfaches downloaden des aktualisierten Images (weiß ich nciht, da ich alles über die Kommandozeile mache).

Container funktionieren grob gesagt so, dass alles gekapselt wird und einen Snapshot vom Zeitpunkt der Erstellung gebildet wird. Du baust das Image ja nicht neu, sondern lädst es herunter. Wenn es also vom Maintainer seit Jahren nicht gepflegt wird, dann bringt es auch nichts regelmäßig das selbe veraltete Image zu laden.
Daher der Hinweis von Otto auf ein neueres Image zu wechseln, welches gepflegt wird.

DA ich wie gesagt nicht mit der Container-Station direkt arbeite, kann ich nur den Tipp geben auf die QNAP Shell zu wechseln und dort dein Konfiguration in ein Compose-File zu schreiben. Das lässt sich aus meiner Sicht leichter pflegen, da man die Konfig später ändern / ergänzen, wenn es notwendig ist oder eben auch mal Teile zur Fehlersuche auskommentieren kann.
Falls die Shell nichts für dich ist, installiere Portainer über die Container Station und pflege deine Container darüber. Es bietet auch die Möglichkeit mit compose-Konfigs (heißt dort Stack) zu arbeiten, nur halt in einer schönen Weboberfläche. Ist ähnlich der Container Station aber bietet mehr Möglichkeiten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 20 April 2022, 12:43:59
@balli1187
Ich bin weder schnippisch noch arrogant. Ich habe lediglich auf die Frage geantwortet, weshalb ich das nicht als den normalen Weg betrachte. Und wenn du ehrlich zu gibst, gibt es in der gesamten IT-Welt keinen Updateprozess der so funktioniert. Allerhöchstens VM-Maschinen könnte man ansatzweise vergleichen. Daher ist daran auch nichts abenteuerlich oder sonst was.

ZitatWenn es also vom Maintainer seit Jahren nicht gepflegt wird, dann bringt es auch nichts regelmäßig das selbe veraltete Image zu laden.
Genau da ist aber der Hund begraben. Denn woran erkennt der Anwender ob ein Image regelmäßig gepflegt wird oder nicht. Soweit ich es bisher gesehen habe, werden weder Versionsnummern noch irgendwelche Aktualisierungsinformationen im Docker-Hub angezeigt. Der benutzte Container ist nach Angaben hier im Forum der Standard-Container für Fhem. Wenn es andere gepflegtere gibt, wäre eine Information interessant welche das sind. Es gibt immerhin eine beträchtliche Anzahl inzwischen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 20 April 2022, 13:20:46
Wenn das nicht arrogant ist, die Antworten auf Deine Fragen mit " ... wäre eine Information interessant  ..." abzutun :o

Lesen Lesen lesen ... wollen wollen wollen ...

Zu meiner Aussage: Dein Image ist alt - ich kann nichts dafür das auf dem Dockerhub nicht alles steht - aber so ist es im Leben - und immerhin steht dort

Dockerhub
ZitatMore information
You may visit the project site on Github to learn more about handling and optional configuration for this image.

Der Link dort in dieser Zeile  https://github.com/fhem/fhem-docker/
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 20 April 2022, 13:24:59
Zitat von: Superposchi am 20 April 2022, 12:43:59
Und wenn du ehrlich zu gibst, gibt es in der gesamten IT-Welt keinen Updateprozess der so funktioniert. Allerhöchstens VM-Maschinen könnte man ansatzweise vergleichen. Daher ist daran auch nichts abenteuerlich oder sonst was.

Nein, VMs würde man so updaten wie einen normalen Rechner auch.
Container sind vom Konzept her so gedacht, dass man sie hochfährt und statt einem Update löscht und neu hochfährt. Es gibt also bei Docker Container quasi kein Update, man ersetzt sie einfach.
Wieso und weshalb das so ist und wieso und weshalb das eine sehr gute Sache ist, würde hier so weit führen. Da hilft es eventuell die eine oder andere Einführung zu Docker zu lesen.
Eventuell nutzt du Docker so wie es nicht gedacht ist.

Zitat von: Superposchi am 20 April 2022, 12:43:59
Genau da ist aber der Hund begraben. Denn woran erkennt der Anwender ob ein Image regelmäßig gepflegt wird oder nicht. Soweit ich es bisher gesehen habe, werden weder Versionsnummern noch irgendwelche Aktualisierungsinformationen im Docker-Hub angezeigt. Der benutzte Container ist nach Angaben hier im Forum der Standard-Container für Fhem. Wenn es andere gepflegtere gibt, wäre eine Information interessant welche das sind. Es gibt immerhin eine beträchtliche Anzahl inzwischen.

Die letzte Aktualisierung sieht man z.B. dort: https://hub.docker.com/r/fhem/fhem/tags
Aktueller, und vor allem gepflegt, ist halt der, den Otto schon erwähnt hat: https://github.com/fhem/fhem-docker/pkgs/container/fhem%2Ffhem-docker
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 April 2022, 13:28:49
Container sind aber nun mal genauso gedacht. Ein gewisser Entwicklungsstand wird gekapselt und aus ausführbare Umgebung mit allem was für die Asuführung benötigt wird übergeben. Das Update wird dann durch Bauen eines neuen Image durchgeführt, welches du als Anwender dir wieder herunterladen kannst und die alte Umgebung entsorgst.
Das mag anders sein als das was du bisher so kennst aber vielleicht solltest du dann eher mal schauen welche Vorteile das bietet. Es bietet eben einige Vorteile, sonst wären Docker und Co nicht seit Jahren so beliebt.
Ich für meinen Teil kann nicht behaupten sämtliche Vorgänge/Möglichkeiten in der gesamten IT-Welt zu kennen aber wenn du das kannst...

Bei mir kommt das etwas arrogant rüber, wenn du gleichzeitig sagst, dass du nicht weist was "compose" bedeutet oder wie du an irgendwelche Informationen zu deinem System/Container kommst.
Als schnippisch empfinde ich solche Aussagen wie "Der Begriff "Never change a running System" sagt dir doch bestimmt auch etwas, oder?" ebenfalls gepaart mit den genannten Wissenslücken.
Aber gut, vielleicht ist das ja nur mein Empfinden. Mich würde es jedenfalls nicht wundern, wenn der weitere Support für dich sehr dünn ausfällt. Ist ja nur ein gut gemeinter Hinweis.

Also wenn ich auf Dockehub gehe und dort nach FHEM suche steht dort direkt unter der Bezeichnung wann des Image zuletzt geupdatet wurde. In dem Fall hier "a year ago". Innerhalb dieses Threads wurde auch schon mehrfach über die Nachteile dieses Images diskutiert, was letztlich zu einem neuen Image geführt hat. FHEM selbst ist leider nicht optimal für Container-Anwendungen konzipiert, was man schon daran sieht, dass man nach einer frischen FHEM-Installation (rapsi, etc.) auch nicht auf dem neuesten Stand ist, sondern erstmal updaten muss.
Damit hätten wir uns jetzt einmal lang und breit im Kreis gedreht aber es bleibt wieder dabei, dass Umstieg auf ein anderes Image dich weiter bringt als zu versuchen dieses hier aktuell zu halten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 20 April 2022, 15:42:44
@balli1187
Ich habe ja nicht behauptet, dass das schlecht ist oder keine Vorteile hat. Nur, dass es anders ist als sonst üblich. Und für jemand der sich nicht so tief in der Materie auskennt eben unlogisch. Und ich kenne sicher auch nicht alle Möglichkeiten in der IT-Welt, doch wenn solche allgemeinen Pfloskeln nicht verstanden werden liegt das meiner Meinung nach eher an nicht wollen, als Arroganz etc..
Bitte nicht falsch verstehen, aber ich habe schon festgestellt, dass viele User hier im Forum sehr speziell sind und auf Worthülsen, Sprichwörter oder ähnliches komisch reagieren. Ich bin zum Beispiel ein Logik-basierter Mensch. Alles was nicht Logisch ist wird erst mal von mir kritisch angesehen und hinterfragt. Doch hier sind viele eben anders gestrickt und ich verstehe nicht wie.

Aber ich würde es gerne verstehen warum du so empfindest. Darum wäre ich dankbar für eine Erklärung warum du die Unkenntnis von "compose" oder fehlende Informationen zum System/Container als arrogant empfindest. Ich würde das eher als Hilflos interpretieren.

Ich habe jedenfalls mal den genannten Docker runtergeladen. Leider klappt es nicht.
Wenn ich die Fehlermeldung richtig interpretiere, liegt es an fehlenden Zugriffsrechten. Muss man dafür im Docker-Hub angemeldet sein? Bisher konnte ich die Container auch ohne angemeldet zu sein ziehen.


Edit:
An einem fehlenden login liegt es nicht.
Ich bekomme immer folgende Fehlermeldung:
Background task error for image_pull fhem/fhem-docker:latest: 404 Client Error: Not Found ("pull access denied for fhem/fhem-docker, repository does not exist or may require 'docker login': denied: requested access to the resource is denied"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 20 April 2022, 16:32:54
Aktuelle Images gibt es derzeit nur in der Github Container registry:

Klappt denn ein

docker pull ghcr.io/fhem/fhem/fhem-docker:dev-bullseye

?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 20 April 2022, 16:35:13
Container sind eben anders gedacht. Für mich liest sich das alles so, als würdest du zu Porsche gehen und dich beschweren, dass das Zündschloss auf der falschen Seite ist. Das hat schließlich kein anderes Auto so.

Beim Lesen deiner ersten Posts habe ich den Eindruck, dass du dich zum einen beschwerst, weil Dinge nicht so sind wie du es kennst oder als richtig erachtest. Manche Sätze haben auch einen belehrenden Unterton, wobei ich bei der bereits zitierten Passage sogar fast davon reden würde, dass der Gegenüber "dumm gemacht" werden sollte.
Vor dem Hintergrund, dass du eben selbst eingeräumte Wissenslücken aufweist, empfinde ich diese Art als leicht arrogant.
Allgemeine Floskeln sehe ich da auch nicht. Container sind eben anders. Wenn ich in einem SQL-Forum schreibe, dass mein Code-Aufbau wie in Perl nicht funktioniert, werde ich auch nur die Antwort bekommen mich an SQL-Syntax zu halten. ES ist ja auch positiv zu sehen, dass dir die Leute hier schreiben, dass Container eben so nicht gedacht sind, denn du würdest viel Zeit mit dem Updaten innerhalb des Containers verbrennen und stündest nach jedem Neustart des Containers wieder bei 0.

Es wurde dir ja inzwischen auch von anderen ans Herz gelegt, vielleicht nochmal etwas zu den Docker Basics zu lesen, damit solche Fragen und Probleme garnicht erst aufkommen.

Zu dem anderen Contaienr kann ich nichts sagen, da ich den (noch) nicht in Nutzung habe aber da kannst du mal auf den letzten paar Seiten schauen. ich glaube dass es hier gerade erst Thema war.

Für mehr Hilfe solltest du dann aber auch etwa mehr von deinem Vorgehen (was und wie hast du es gemacht) und von deiner Fehlermeldung (Code-Tags) schreiben, sonst kann dir niemand helfen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 April 2022, 16:54:07
Zitat von: Superposchi am 20 April 2022, 11:58:30
Für mich ist dieser Weg eher der Sonderweg, weil er eben nicht den üblichen Prozessen in der Computerwelt entspricht.

Komisch, in der Docker-Computer-Welt wird genau dieser Weg gegangen ... also nix mit "üblichen Prozessen in der Computerwelt" .. und ja, ich habe beruflich damit zu tun

ZitatIch bin weder schnippisch noch arrogant. Ich habe lediglich auf die Frage geantwortet, weshalb ich das nicht als den normalen Weg betrachte. Und wenn du ehrlich zu gibst, gibt es in der gesamten IT-Welt keinen Updateprozess der so funktioniert. Allerhöchstens VM-Maschinen könnte man ansatzweise vergleichen. Daher ist daran auch nichts abenteuerlich oder sonst was.
Quod erat demonstrandum ... s.o.


@Otto:
Allerdings eine Kleinigkeit. Normalerweise läd man einen neuen Container, fährt dann den alten runter/den neuen hoch und Freit sich, das es funktioniert. Wenn nicht, dann fährt man eben den alten wieder hoch. Funktioniert nur eben nicht, wenn man den vorher löscht.

Natürlich sollte man nach einer Zeit X das System aufreumen, damit man nicht "mit dem ollen Schiedkrom" das System "verstopft"
Deine Meinung íst <> "gesamten IT-Welt" .... und ja, morgen mache ich genau so ein Update beruflich ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 20 April 2022, 17:50:22
Zitat von: Superposchi am 20 April 2022, 15:42:44
Background task error for image_pull fhem/fhem-docker:latest: 404 Client Error: Not Found ("pull access denied for fhem/fhem-docker, repository does not exist or may require 'docker login': denied: requested access to the resource is denied"
Das Image gibt es nicht, der empfohlene Link zum Image war
ghcr.io/fhem/fhem/fhem-docker:bullseye

Zitat von: Wernieman am 20 April 2022, 16:54:07
@Otto:
Allerdings eine Kleinigkeit. Normalerweise läd man einen neuen Container, fährt dann den alten runter/den neuen hoch und Freit sich, das es funktioniert. Wenn nicht, dann fährt man eben den alten wieder hoch. Funktioniert nur eben nicht, wenn man den vorher löscht.
Ja Werner ich weiß, aber ich ahnte auch schon den weiteren Verlauf :) und mein letzter Stand war auch, dass der kleine grüne Troll nicht willens ist zu beschreiben wie er sein docker bedient und er kein Terminal auf seiner NAS hat.
Solange man das Image nicht löscht (und das habe ich nicht empfohlen) kann man ja den alten container immer wieder starten. Also genau genommen wolltest Du sagen: man lädt erst das neue Image ... macht den neuen Aufruf ...
Ich muss es mir mal so irgendwo hinschreiben, spontan im Kopf ist halt immer das Vorgehen und nicht die exakte Abfolge.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 20 April 2022, 21:46:40
Zitatdass der kleine grüne Troll nicht willens ist zu beschreiben wie er sein docker bedient und er kein Terminal auf seiner NAS hat.
Was für mich der Grund ist, nicht mehr zur Lösung beizutragen. Ist nicht das erste mal.
Bzw: Ich bewundere immer Deine Gelassenheit!

Zitatman lädt erst das neue Image ... macht den neuen Aufruf ...
Exacta. Hat z.B. bei selbstgebauten Containern (per Dockerfile) sogar den Vorteil, wenn sie getakt sind, das man exakt zu einer Version springen kann.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 20 April 2022, 23:27:14
Vielleicht sollten wir das  ganze als Startpunkt nehmen und eine Wikiseite mit Hinweisen erstellen.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 21 April 2022, 09:01:12
ZitatContainer sind eben anders gedacht. Für mich liest sich das alles so, als würdest du zu Porsche gehen und dich beschweren, dass das Zündschloss auf der falschen Seite ist. Das hat schließlich kein anderes Auto so.
Nicht beschweren, aber darauf hinweisen, dass es eben nicht so ist wie man es gewohnt ist.

ZitatEs wurde dir ja inzwischen auch von anderen ans Herz gelegt, vielleicht nochmal etwas zu den Docker Basics zu lesen, damit solche Fragen und Probleme gar nicht erst aufkommen.
Habe ich probiert, das kannst du mir glauben. Doch leider scheitere ich bisher an der Dokumentation in englischer Sprache und in Deutsch habe ich noch nichts ausführliches gefunden. Mein Englisch ist guter Durchschnitt und reicht für den beruflichen Alltag aus, aber hierbei muss ich passen.

ZitatFür mehr Hilfe solltest du dann aber auch etwa mehr von deinem Vorgehen (was und wie hast du es gemacht) und von deiner Fehlermeldung (Code-Tags) schreiben, sonst kann dir niemand helfen.
Zitatnicht willens ist zu beschreiben wie er sein docker bedient und er kein Terminal auf seiner NAS hat
Falsch! Ich habe von Anfang an gesagt, das ihr mir sagen müsst was ihr benötigt da ich eben keine Ahnung habe was relevant ist. Das hat bisher niemand getan. Und ich kann nichts liefern, von dem ich nichts weis. Code-Snipsel gibt es in der Container-Station nicht. Es ist eine rein grafische Oberfläche. Man gibt das Image an den man laden/ziehen möchte und erstellt daraus einen Container, der nach dem starten zur Verfügung steht. Mehr ist da nicht. Also kann ich auch nicht mehr sagen.

Zitatghcr.io/fhem/fhem/fhem-docker:bullseye
Wird nicht akzeptiert. Ich kann als Quelle zum laden nur den hinteren Teil von z.b. "docker pull fhem/fhem", also das "fhem/fhem" (was ja wohl nicht aktuell ist) nutzen, der Rest wird offenbar vom System automatisch ergänzt. Daher wird alles andere nicht akzeptiert. Auch sucht die Container-Station ausschließlich auf dem Docker-Hub

ZitatKomisch, in der Docker-Computer-Welt wird genau dieser Weg gegangen
Und wieviel Prozent der IT-Welt machen Docer aus? 10%? 15%? Oder sogar deutlich weniger. Und in der gesamten IT-Anwendung, egal ob Windows, Linux oder Mac, ist das Vorgehen nun mal anders, weshalb es erstmal ein Sonderweg ist. Das ist doch weder Kritik, noch Beschwerde. es ist einfach ein Fakt.

Zitatdass der kleine grüne Troll
Sorry, ihr beschwert euch, dass ich angeblich arrogant bin? Ehrlich?
Ganz ehrlich, ich verstehe diese Welt nicht mehr, wenn etwas so verquer gewertet und in sich verdreht werden kann.
Das Zugeben von Unwissenheit wird als arrogant interpretiert, Hinweise als Beschwerde, aber selbst das Gegenüber beleidigen. Komische Welt!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 21 April 2022, 09:50:45
@Superposchi konzentriere Dich doch mal auf das Wesentliche, wenn schon ein Qnap User Dir ganz konkret in deutsch sagt was Du tun kannst:
Zitat von: balli1187 am 20 April 2022, 12:31:38
da ich auch FHEM auf einem QNAP betreibe.

Im Hintergrund der Container Station läuft ein ganz normales Dockersystem. Die Container Station ist nur eine Oberfläche. Du kannst dort den Container stoppen, das Image neuladen (=aktualisieren) und den Container über die Weboberfläche neu aufsetzen.
...  (weiß ich nciht, da ich alles über die Kommandozeile mache).

...
DA ich wie gesagt nicht mit der Container-Station direkt arbeite, kann ich nur den Tipp geben auf die QNAP Shell zu wechseln und dort dein Konfiguration in ein Compose-File zu schreiben. Das lässt sich aus meiner Sicht leichter pflegen, da man die Konfig später ändern / ergänzen, wenn es notwendig ist oder eben auch mal Teile zur Fehlersuche auskommentieren kann.
Falls die Shell nichts für dich ist, installiere Portainer über die Container Station und pflege deine Container darüber. Es bietet auch die Möglichkeit mit compose-Konfigs (heißt dort Stack) zu arbeiten, nur halt in einer schönen Weboberfläche. Ist ähnlich der Container Station aber bietet mehr Möglichkeiten.

Deine Welt ist in Ordnung - unsere ist schlecht. Wir kommen damit klar - Du kannst es nur versuchen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 21 April 2022, 09:58:32
Zitat von: Superposchi am 21 April 2022, 09:01:12
Und wieviel Prozent der IT-Welt machen Docer aus? 10%? 15%? Oder sogar deutlich weniger. Und in der gesamten IT-Anwendung, egal ob Windows, Linux oder Mac, ist das Vorgehen nun mal anders, weshalb es erstmal ein Sonderweg ist. Das ist doch weder Kritik, noch Beschwerde. es ist einfach ein Fakt.

Sorry, aber selbst bei der Deutschen Bahn laufen mittlerweile fast alle Anwendungen innerhalb von Docker Containern, die über entsprechende CI/CD-Umgebungen gebaut und bereitgestellt werden. Insofern ist das absolut normal.
Du darfst nur nicht Clients mit Servern gleichsetzen.
Vielmehr ist es heutzutage eher ein Sonderweg, wenn man NICHT mit Containern arbeitet.
Die IT-Welt hat sich in den letzten 5 Jahren ziemlich weiterentwickelt. Es würde der Hilfsbereitschaft dir gegenüber massiv helfen, wenn du einfach akzeptieren würdest, dass das, was du als "normal in der IT-Welt" betrachtest, halt nicht mehr normal ist.

Dir wurde aber doch auch schon gesagt, dass du halt von der Weboberfläche auf die Command Line wechseln musst.
Da findet man recht viele Information zu: https://bfy.tw/SwHS auch in einfachem Englisch oder sogar auf deutsch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 21 April 2022, 10:03:45
Zu den ersten beiden Zitaten will ich nicht mehr viel sagen.
Die Sache ist halt wie sie ist. Das es vielleicht am Anfang ungewohnt ist mag ja sein aber ich verstehe da auch dein Problem nicht so recht. Es entsteht dir ja kein Nachteil. Und es werden auch keine Ressource oder dergleichen verschwendet, wie es im realen Leben ist, wenn man einfach etwas wegwirft und neu kauft.

Es macht mich da ehrlich gesagt auch müde darüber zu diskutieren wie viel Prozent der IT-Welt nun Docker oder ähnliche Dienste ausmachen. Ich kann wie gesagt nicht behaupten mich da ausreichend auszukennen, um das zu bewerten und auf Grund deiner Wissenslücken glaube ich auch nicht, dass du das kannst.

Vielleicht hilft dir ja Youtube weiter, da findet man sicherlich auch etwas auf deutsch.

Wenn du das Image über die Container Station nicht laden kannst, solltest du vielleicht erstmal Hilfe im QNAP-Forum suchen oder anderweitig herausfinden, ob/wie das geht. Die wenigsten hier nutzen ein NAS als Host bzw. nehmen die Container-Station als Frontend. Daher bist du mit dem Problem hier erstmal an der falschen Adresse, da niemand eine Glaskugel hat und erahnen kann, was an deinem Rechner geschieht oder als Fehlermeldung angezeigt wird. Das ist jetzt nicht so böse gemeint wie es klingt aber wenn du nicht genügend Grundwissen aufbauen kannst, um ausreichend Informationen zu liefern, wird dir hier niemand helfen können.

Ich erneuere hier nochmal meinen Tipp über Portainer (oder die QNAP-Shell) zu gehen, denn dort kannst du auch andere Quellen angeben und man könnte dir sogar beim zusammenbasteln einer compose helfen.

ZitatSorry, ihr beschwert euch, dass ich angeblich arrogant bin? Ehrlich?
Ganz ehrlich, ich verstehe diese Welt nicht mehr, wenn etwas so verquer gewertet und in sich verdreht werden kann.
Das Zugeben von Unwissenheit wird als arrogant interpretiert, Hinweise als Beschwerde, aber selbst das Gegenüber beleidigen. Komische Welt!
Nein nicht deine Unwissenheit wird als Arroganz gewertet sondern das Belehren anderer, wie die gesamte IT-Welt funktionert, trotz offensichtlicher Wissenslücken. Zumindest ist das bei mir so. Beim Rest macht der Ton die Musik. Daher habe ich deine Hinweise als Beschwerde interpretiert. Leider konnte ich bisher keinerlei Einsicht feststellen, sondern du verteidigst deine Art und Weise obwohl es mehrfache Meldungen gab, dass diese anders aufgenommen wird als es möglicherweise gemeint war. Wie du Lesen kannst haben andere User deswegen bereits den Support eingestellt. Ich kann nicht verstehen, dass man dann trotzdem der Meinung ist, dass es an allen anderen liegt und nicht an einem selbst.
Aus meiner Sicht wäre das Ganze auch ganz schnell erledigt gewesen, wenn mal sowas wie "sorry, dass es bei euch so ankommt - so war es garnicht gemeint. ich hab nur das Konzept noch nicht so recht verinnerlicht und das macht mir etwas Probleme beim Verständnis." gekommen wäre. Kam aber leider nicht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 April 2022, 10:53:12
@Superposchi, das Thema hatten wir Ende 2020 schon in unterschiedlichsten Threads diskutiert. Es artet hier in eine Grundsatzdiskussion aus die hier nicht her gehört.

Fakt: du nutzt QNAP welches eine bescheidene Implementierung von Docker hat. Da hast du bei der Auswahl auf falsche Pferd gesetzt. Dafür kann hier keiner was. Da hilft auch keine Diskussion was im IT-Umfeld state of the art ist.

Möglichkeiten die dir zum Teil damals, und jetzt genannt wurden:
- Portainer ... wolltest du 2020 nicht weil du es nicht zum laufen bekommen hast
- Verwaltung über Shell
- ggf. eine VM oder LXC (in QNAP unterstüttz?) auf deinem NAS mit Linux drin und dann da drin nativ Docker aufsetzen. Damit auch QNAP-Docker außen vor lassen
- Hilfe in QNAP-Formen suchen. Zur Verwaltung bietet QNAP eine API an. Keine Ahung ob da Dokumentation auf Deutsch verfügbar ist ...

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 21 April 2022, 11:32:58
ZitatQNAP Shell zu wechseln
Sagt mir leider nichts.

Zitatinstalliere Portainer
Habe ich wie kadettilac89 schreibt früher schon mal probiert und keinen Zugriff auf den Fhem-Container bekommen. Offenbar ist wohl die Netzwerkstruktur hier ein Problem.

ZitatVielleicht hilft dir ja Youtube weiter, da findet man sicherlich auch etwas auf deutsch.
Leider auch nicht soweit ich bisher gesehen habe. Wobei ich natürlich nicht garantieren kann, alle möglichen Suchwörter ausprobiert zu haben.

Zitatsolltest du vielleicht erstmal Hilfe im QNAP-Forum suchen
Leider ist das QNAP-Forum nicht wirklich aktiv. Dort ist erfahrungsgemäß nicht wirklich mit Reaktionen zu rechnen.

Zitatwenn du nicht genügend Grundwissen aufbauen kannst, um ausreichend Informationen zu liefern, wird dir hier niemand helfen können.
Das ist mir klar, ich hatte nur die Hoffnung, dass mir jemand sagen kann was und wie ich liefern kann/sollte um zu lernen wie es geht.

ZitatNein nicht deine Unwissenheit wird als Arroganz gewertet sondern das Belehren anderer,
Also ich sehe nicht wo ich irgend jemand belehrt habe. Einzig habe ich auf die Frage warum ich den anderen Weg gehen wollte mit dem allgemein üblichen Spruch geantwortet, was aber teilweise auch als Witz gedacht war. Aber ja, ich gebe zu, ich habe ein Problem damit mich für etwas zu entschuldigen was in meinen Augen nie passiert ist. aber wenn es euch glücklich macht, entschuldige ich mich hiermit gerne für alles was auch immer ich gesagt haben soll.

Zitatdas Thema hatten wir Ende 2020 schon in unterschiedlichsten Threads diskutiert
Und genau da war die Lösung der Container, der sich eben als veraltet herausgestellt hat. Denn seit dem nutze ich diesen Container in verschiedenen Download-Versionen.

ZitatMöglichkeiten die dir zum Teil damals, und jetzt genannt wurden:
Das stimmt so nicht. Ich habe nie behauptet, dass ich Portainer nicht will. Ich bekomme es einfach nicht ans Laufen und außer dem Hinweis es zu installieren kam damals nichts weiter. Shell ist mir wie gesagt keinBegriff im Zusammenhang mit QNAP-NAS und ich kann mich auch nicht erinnern, dass es damals Thema war
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 21 April 2022, 11:49:32
Zitat von: Superposchi am 21 April 2022, 11:32:58
Sagt mir leider nichts.
https://www.google.com/search?q=qnap+shell
1. Treffer Offizielle qnap Seite
2. Treffer HowTo im qnap Forum
3. Treffer ff Jede Menge Videos bei Youtube

over & over :o
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 21 April 2022, 12:06:55
Zitat von: Superposchi am 21 April 2022, 11:32:58
Sagt mir leider nichts.
--> google "QNAP Shell" --> erster Treffer --> https://www.qnap.com/de-de/how-to/knowledge-base/article/how-to-access-qnap-nas-by-ssh

Du hast uns einige Beiträge zuvor vorgeworfen, wir würden "nicht wollen". ich habe den Eindruck du möchtest dir nicht beim lernen helfen lassen (Forum = Hilfe zur Selbsthilfe) sondern erwartest, dass jemand die Sachen für dich umsetzt.
Aber sei es drum, hier hast du die ERklärung, wie du dich mit deinem QNAP verbindest (admin-Konto nutzen) und dort die üblichen Docker-Befehle (ohne sudo) eintippen kannst. Da du aber schon mit dem Begriff "shell" nichts anfangen kannst, möchte ich den Warnhinweise geben hier vorsichtig zu sein. Da kann man auch was kaputt machen, wenn man einfach drauf los kopiert.

ZitatHabe ich wie kadettilac89 schreibt früher schon mal probiert und keinen Zugriff auf den Fhem-Container bekommen. Offenbar ist wohl die Netzwerkstruktur hier ein Problem.
Leider auch nicht soweit ich bisher gesehen habe. Wobei ich natürlich nicht garantieren kann, alle möglichen Suchwörter ausprobiert zu haben.
Kann ich nichts zu sagen, war ich nicht dabei. Was ich aus eigener Erfahrung (QNAP mit ca. 20 laufenden Container inklusive Portainer / FHEM) sagen kann ist, dass es geht.
ZitatLeider ist das QNAP-Forum nicht wirklich aktiv. Dort ist erfahrungsgemäß nicht wirklich mit Reaktionen zu rechnen.
Ich habe gute Erfahrung mit einer QNAP-Facebook-Gruppe gemacht. Vielleicht eine Alternative.

ZitatAlso ich sehe nicht wo ich irgend jemand belehrt habe. Einzig habe ich auf die Frage warum ich den anderen Weg gehen wollte mit dem allgemein üblichen Spruch geantwortet, was aber teilweise auch als Witz gedacht war. Aber ja, ich gebe zu, ich habe ein Problem damit mich für etwas zu entschuldigen was in meinen Augen nie passiert ist. aber wenn es euch glücklich macht, entschuldige ich mich hiermit gerne für alles was auch immer ich gesagt haben soll.
Weiterhin kein bisschen Einsicht, dass es an einem selbst liegen könnte.
Meinen Kindern würde ich jetzt sagen: Wenn du die Entschuldigung nicht Ernst meinst, kannst du es lassen.
ich würde das Thema dann auch ganz gerne sein lassen, bevor mir auch noch die Lust vergeht mit konstruktiven Kommentaren (siehe oben) zu einer Lösung beizutragen.
ZitatDas stimmt so nicht. Ich habe nie behauptet, dass ich Portainer nicht will. Ich bekomme es einfach nicht ans Laufen und außer dem Hinweis es zu installieren kam damals nichts weiter. Shell ist mir wie gesagt kein Begriff im
Zusammenhang mit QNAP-NAS und ich kann mich auch nicht erinnern, dass es damals Thema war
Ohne es über die Container Station selbst probiert zu haben, würde ich sagen: mache es genauso wie mit dem FHEM-Container über die Container Station. Das Prozedere ist ja das gleiche.
Ansonsten auch hier wieder
--> google "portainer qnap container station"
--> erstes Video --> https://www.youtube.com/watch?v=mIhPfMmiUB4
--> erster Treffer --> https://forum.qnapclub.de/thread/58355-howto-portainer-und-watchtower-auf-der-containerstation/

ich habe weder das eine noch das andere geprüft. Möglicherweise sind die Sachen nicht mehr aktuell aber dennoch zeigt es, dass man mit wirklich minimalem Eigenaufwand zu Informationen kommt, die einem bei der Selbsthilfe unterstützten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 April 2022, 14:59:29
@Superposchi
Was ich nicht ganz verstehe ist warum Du Docker verwendest wenn Du damit so Deine liebe Not hast. Warum dann nicht Raspi oder ein LXC.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 April 2022, 15:01:15
Mal was anderes. Auf Basis von Sidey unglaublich toller Arbeit habe ich das fhem-docker Kubernetestauglich ausgebaut.
Aktuell bin ich noch am testen, aber es läuft schon mal das Fundament. Allerdings Bullseye only und ohne CPAN.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 April 2022, 15:06:50
Wie testest Du die Kubernetestauglichkeit?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 April 2022, 15:13:48
Zitat von: Wernieman am 21 April 2022, 15:06:50
Wie testest Du die Kubernetestauglichkeit?

Habe aktuell ein Test Kubernetescluster. Ein Master und ein Worker. Ich will bis Ende des Jahres versuchen alle meine Services in einem Kubernetescluster laufen zu lassen.
Am Ende werden es wohl 3 Master und 2 Worker werden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 April 2022, 15:23:17
Da ich auch in die Richtung überlege .... und in der Vergangenheit schon mal gescheitert bin. Hast Du eine "nette" Doku dafür?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 21 April 2022, 16:13:34
ZitatDu hast uns einige Beiträge zuvor vorgeworfen, wir würden "nicht wollen". ich habe den Eindruck du möchtest dir nicht beim lernen helfen lassen (Forum = Hilfe zur Selbsthilfe) sondern erwartest, dass jemand die Sachen für dich umsetzt.
Wenn das so rüber kommt tut mir das leid. Ich hoffe einfach nur auf eine Art "Übersetzung" der ganzen Begriffe und ihrer Bedeutung. Die meisten Nachschlageseiten sind halt in Englisch und damit habe ich bei dem technischen Fachkram halt meine Probleme. Ich möchte es gerne selbst lernen, denn nur so behält man es auch. Aber dafür brauche ich leider fachkräftige theoretische Unterstützung.

ZitatDa du aber schon mit dem Begriff "shell" nichts anfangen kannst, möchte ich den Warnhinweise geben hier vorsichtig zu sein. Da kann man auch was kaputt machen, wenn man einfach drauf los kopiert.
Ich kenne den Begriff Shell und weiß auch um das Risiko. Allerdings kenne ich Shell nicht im Zusammenhang mit einem NAS. Hättest du ssh geschrieben wäre ich wahrscheinlich schneller drauf gekommen.

ZitatKann ich nichts zu sagen, war ich nicht dabei. Was ich aus eigener Erfahrung (QNAP mit ca. 20 laufenden Container inklusive Portainer / FHEM) sagen kann ist, dass es geht.
Das Problem liegt offenbar an meiner Netzwerkkonfiguration. Diese scheint wohl etwas komisch zu sein, doch ich weiß nicht wo genau bzw. wie ich es anders machen kann.

ZitatOhne es über die Container Station selbst probiert zu haben, würde ich sagen: mache es genauso wie mit dem FHEM-Container über die Container Station.
Da habe ich mich falsch ausgedrückt. Natürlich bekomme ich den Portainer-Container ans Laufen. Ich schaffe es aber nicht eine Verbindung von Portainer zu anderen Containern herzustellen.

ZitatWas ich nicht ganz verstehe ist warum Du Docker verwendest wenn Du damit so Deine liebe Not hast. Warum dann nicht Raspi oder ein LXC.
Der Grundgedanke war alles in einem Gerät zu haben (eigenen Webserver, Mailserver, Home-Automation, Netzlaufwerke etc.), darum das NAS. Doch beim Fhem hieß es dann, dass Fhem in einem Container laufen muss.
Hätte ich ursprünglich von dem Aufwand gewusst, hätte ich wahrscheinlich einiges anders gemacht. Doch nachdem ich jetzt das Ding für mehrere hunderte Euro da stehen habe ...

Was mich aber mal interessieren würde, warum ist dieser neue Container fhem/fhem-docker nicht wie die anderen im Docker-Hub angesiedelt? Das wäre doch einfacher, oder nicht?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 April 2022, 16:40:02
Zitat von: Superposchi am 21 April 2022, 16:13:34
Was mich aber mal interessieren würde, warum ist dieser neue Container fhem/fhem-docker nicht wie die anderen im Docker-Hub angesiedelt? Das wäre doch einfacher, oder nicht?

Wahrscheinlich weil eh auf Github entwickelt wird und hier auch alles automatisiert getestet werden kann. Ausserdem soll wohl, so habe ich mal gehört, Dockerhub für die Anbieter nicht mehr Kostenfrei sein.
Und am Ende kommt noch hinzu. Es gibt nicht nur Docker welcher diesen Container verwenden kann. Auch andere Container Runtime Engines können das Image verwenden. Ich benutze zum Beispiel Containerd und nicht Docker, kann aber das selbe Image verwenden.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 April 2022, 16:59:43
Zitat von: CoolTux am 21 April 2022, 16:40:02
Und am Ende kommt noch hinzu. Es gibt nicht nur Docker welcher diesen Container verwenden kann. Auch andere Container Runtime Engines können das Image verwenden. Ich benutze zum Beispiel Containerd und nicht Docker, kann aber das selbe Image verwenden.
Wobei das doch eher ein schwaches Argument ist. Auch andere Container Programme können mit Docker-hub umgehen ... oder?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 21 April 2022, 17:03:48
Zitat von: Wernieman am 21 April 2022, 16:59:43
Wobei das doch eher ein schwaches Argument ist. Auch andere Container Programme können mit Docker-hub umgehen ... oder?

Soweit ich weiß ja. Im Deployment File von Kubernetes kann ich auch Docker Hub als Registry für ein Image angeben.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: balli1187 am 21 April 2022, 19:50:18
Zitat von: Superposchi am 21 April 2022, 16:13:34
Das Problem liegt offenbar an meiner Netzwerkkonfiguration. Diese scheint wohl etwas komisch zu sein, doch ich weiß nicht wo genau bzw. wie ich es anders machen kann.
Da habe ich mich falsch ausgedrückt. Natürlich bekomme ich den Portainer-Container ans Laufen. Ich schaffe es aber nicht eine Verbindung von Portainer zu anderen Containern herzustellen.
Das klingt für mich sehr nebulös.
Von welchem Netzwerk redest du, deinem physischen (mit Router, NAS) oder einem Docker-Netzwerk?

Bei beidem wäre mir ziemlich unklar wie sich das mit dem FHEM-Container beißen sollte, wenn du sonst nichts (z.B. Datenbank-Container für logging) laufen hast.

Portainer ist ja nur eine GUI für Docker also im Prinzip das selbe wie die Container Station und Portainer und der FHEM-Container er müssen sich auch nicht zwingend "sehen" (wobei Portainer eigentlich per Definition alles sehen sollte).

EDIT:
Ich habe das jetzt mal mit einer ganz schmalen Variante bei mir getestet. Es dauert zwar ein wenig bis das Image geladen ist und die Initialisierung beim Containerstart durch ist aber der Container startet und ich komme über den Browser auch auf die FHEM-Instanz.

Ablauf:
- Portainer installieren (hast du ja bereits hinbekommen) und über den Browser öffnen
- dort "Stacks" --> "add new Stack" und das hier reinkopieren
version: '2'

services:
# =============== FHEM ===============
    FHEM:
        image: ghcr.io/fhem/fhem/fhem-docker:bullseye
        container_name: FHEM
        hostname: FHEM
        restart: always
        ports:
            - "8083:8083"

Danach solltest du über die IP deines NAS und den Port auf FHEM kommen.
Volumes für die persistenten Daten und sonstige Environment-Variablen musst du natürlich hinzufügen,. genauso wie ggf. benötigte Ports (alternativ mit network_mode: host arbeiten, dann wird einfach alles nach draußen geleitet).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 April 2022, 21:50:43
Zitat von: Superposchi am 21 April 2022, 16:13:34
Was mich aber mal interessieren würde, warum ist dieser neue Container fhem/fhem-docker nicht wie die anderen im Docker-Hub angesiedelt? Das wäre doch einfacher, oder nicht?

Ich habe keine Zugangsdaten zum dockerhub.
Die in Github integrierte registry wird über die Organisation "fhem" mit verwaltet.
Bei dockerhub ist das so nicht möglich und es gibt meines Wissens nach nur eine Person, welche das fhem Konto dort administriert (oder auch nicht mehr administriert)

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 April 2022, 21:53:45
Laut QNAP Anleitung können weitere Container registrys hinzugefügt werden:

https://www.qnap.com/en/how-to/tutorial/article/how-to-use-container-station

Wenn Du die Github Container registry hinzu nimmst, klappt vermutlich auch der Download von dem Image.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 22 April 2022, 04:40:58
Zitat von: Sidey am 21 April 2022, 21:50:43
Ich habe keine Zugangsdaten zum dockerhub.
Die in Github integrierte registry wird über die Organisation "fhem" mit verwaltet.
Bei dockerhub ist das so nicht möglich und es gibt meines Wissens nach nur eine Person, welche das fhem Konto dort administriert (oder auch nicht mehr administriert)

Grüße Sidey

Ich habe bei dockerhub ein Konto welches Besitzerrechte für die Dockerhub Organisation fhem besitzt. Wenn Du mir sagst was ich wie wo machen muss können wir das hochladen in die Github Action mit einbauen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: GammaTwin am 22 April 2022, 06:35:18
Grüße,

ich bin vielleicht spät dran - bei der hohen Antwortgeschwindigkeit :)

Zitat von: Superposchi am 20 April 2022, 11:03:54
Mein Problem ist doch eigentlich nur, dass ich die beiden Devices "Fhem Installer Status" und "Node.js Package Update Status" nicht aktualisiert bekomme. Wofür gibt es diese Dinger wenn sie nicht funktionieren. Oder funktionieren Sie nur wegen dem NAS nicht?

Superposchi:
Wenn Du den alten fhem:fhem Container am laufen hast und darin Deine beiden Problemkandidaten aktualisieren willst, kannst Du folgendes probieren:
- in den Container gehen, z.B. mit Portainer oder exec -it

Für den "Fhem Installer Status" folgendes ausführen
cpan-outdated -p | cpanm

Für "Node.js Package Update Status" ist es etwas aufwändiger
curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -
apt install -y nodejs
npm install -g npm


Danach nochmal in FHEM:
set fhemInstaller outdatedPerl
set fhemServerNpm outdated


Bei mir sind dann alle Versionen aktuell, sprich grün. Betreiben tue ich es allerdings nicht.

Diese gemachten Aktualisierungen sind nur so lange wirksam, bis Du den Container neu baust. Einen Reboot des Rechners überleben aber die Änderungen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 22 April 2022, 15:06:03
Hallo zusammen,

ich möchte FHEM als Testsystem auf einer Syno im Docker-Container installieren. Über "Docker Hub" bekomme ich auch einen FHEM-Container angeboten. Ist dieser aktuell oder muss ich den Container aus Github holen?

Laut Doku sollte doch auch "Docker Hub" aktuell sein oder?

Installation

Pre-build images are available on Docker Hub Reccomended pulling from Github Container Registry to allow automatic image for your system.


Viele Grüße
Jürgen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 22 April 2022, 15:08:47
Zitat von: juemuc am 22 April 2022, 15:06:03
ich möchte FHEM als Testsystem auf einer Syno im Docker-Container installieren. Über "Docker Hub" bekomme ich auch einen FHEM-Container angeboten. Ist dieser aktuell oder muss ich den Container aus Github holen?

Github, der andere ist ein Jahr alt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 22 April 2022, 16:03:27
Danke für die schnelle Info.

Ich habe es befürchtet. Nun benötige ich weitere Hilfe. Mir ist es bisher nicht gelungen, das Dockerfile aus github herunterzuladen. Gibt es diese Möglichkeit nicht?
Da wohl die Integrazion einer github-Registrierung in der Syno nicht möglich ist, würde ich gerne das Dockerfile direkt in die Syno über die GUI-Oberfläche laden. Den Weg über SSH würde ich nur um Notfall gehen wollen.

Viele Grüße
Jürgen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 22 April 2022, 17:09:38
Zitat von: juemuc am 22 April 2022, 16:03:27

Da wohl die Integrazion einer github-Registrierung in der Syno nicht möglich ist.

Hallo Jürgen,

Ich habe keine Synology, aber laut dieser Diskussion ist es möglich:

https://github.community/t/correct-link-to-add-to-docker-registry/160636/2
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 22 April 2022, 17:21:29
Hallo Sidey,

die Info hatte ich schon gelesen. Allerdings sehe ich dort keinen Lösungsweg. Ich verstehe das eher so, dass hier das nicht über eine Registrierung funktioniert:
Maybe the search is exactly the problem, as discussed here GHCR doesn't support the /v2/_catalog endpoint

Viele Grüße
Jürgen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 22 April 2022, 18:23:40
Zitat von: juemuc am 22 April 2022, 17:21:29
die Info hatte ich schon gelesen. Allerdings sehe ich dort keinen Lösungsweg. Ich verstehe das eher so, dass hier das nicht über eine Registrierung funktioniert:

Schade, ich hatte nicht bis zum Ende gelesen.
Über ssh und dann ein Docker pull sollte dazu führen, dass das angegebene Image in deiner GUI erscheint.

Ich hatte schon dazu tendiert, das veraltete Image im dockerhub zu löschen. Es scheint aber so, als ob einige nicht native Implementierungen mit der Github Registrierung nicht klar kommen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 22 April 2022, 22:54:25
Hallo Sidey,

installation und updates haben fast komplett funktioniert. Lediglich cpan lässt sich (noch) nicht installieren. Hier erhalte ich den Fehler "error 'installPerl App::cpanminus'.

Hast hierzu jemand einen Tipp?

Viele Grüße
Jürgen

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 23 April 2022, 20:18:15
Zitat von: juemuc am 22 April 2022, 22:54:25
Hallo Sidey,

installation und updates haben fast komplett funktioniert. Lediglich cpan lässt sich (noch) nicht installieren. Hier erhalte ich den Fehler "error 'installPerl App::cpanminus'.


Ich weiss nicht genau was Du mit "Installation" und "Updates" meinst.
CPAN ist im Image bereits installiert, da gibt es keinen Grund etwas zu installieren.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 24 April 2022, 16:50:56
Hallo Sidey,

ich habe die Tests abgebrochen, da dies für mich nicht die ideale Testumgebung ist. Trotzdem Danke für Deine Unterstützung.

Viele Grüße
Jürgen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 24 April 2022, 18:30:19
Zitat von: juemuc am 24 April 2022, 16:50:56
ich habe die Tests abgebrochen, da dies für mich nicht die ideale Testumgebung ist. Trotzdem Danke für Deine Unterstützung.

Hi Juemuc,

Da ich Schreibrechte im dockerhub erhalten habe, konnte ich bereits die ersten Images im dockerhub aktualisieren.
https://hub.docker.com/repository/docker/fhem/fhem

Die Tags `buster` und `bullseye` kommen später noch dazu.
latest wird allerdings nicht aktualisiert!

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 24 April 2022, 18:59:05
Ich habe vor kurzem alle Docker Container auf meinem Unraid Server analysiert und jeden Schreibvorgänge geloggt, um mal zu sehen welche Container besonders viel auf die Cache SSD schreiben. Der Fhem Container fällt da mit den regelmäßigen Health Check deutlich heraus. Leider kann man den Interval laut Readme nicht verändern, sondern den Check nur komplett ausschalten. Hat es einen bestimmten Grund, den Check alle 20 Sekunden laufen zu lassen oder wäre es auch ok, den Interval auf z.B. 1 Minute zu stellen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 24 April 2022, 19:12:58
Zitat von: kennymc.c am 24 April 2022, 18:59:05
Der Fhem Container fällt da mit den regelmäßigen Health Check deutlich heraus.


Du kannst den Intervall anpassen. Z.b. in compose:

https://docs.docker.com/compose/compose-file/compose-file-v3/#healthcheck


Das Script selbst schreibt aber Ansicht nichts. Sind das vielleicht die Logausgaben? Wie hast Du das analysiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 24 April 2022, 19:27:23
Zitat von: Sidey am 24 April 2022, 19:12:58
Das Script selbst schreibt aber Ansicht nichts. Sind das vielleicht die Logausgaben? Wie hast Du das analysiert.

Der Fhem-Log kann es nicht sein, da dort nicht so regelmäßig Meldungen erscheinen. Aber vermutlich die Logs des Health Checks selbst.
Die Messmethode stammt die aus diesem Unraid-Thread: https://forums.unraid.net/topic/110999-guide-on-how-to-stop-excessive-writes-destroying-your-cache-ssd/
Der Befehl dafür ist inotifywait -e create,modify,attrib,moved_from,moved_to --timefmt %c --format '%T %_e %w %f' -mr /var/lib/docker > /mnt/user/system/recent_modified_files_$(date +"%Y%m%d_%H%M%S").txt

Die Empfehlung von dort ist es, den Container mit dem Parameter --health-interval=1m zu starten. Das müsste dann die 20 Sekunden überschreiben?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 25 April 2022, 00:51:27
Zitat von: Sidey am 24 April 2022, 18:30:19
Die Tags `buster` und `bullseye` kommen später noch dazu.

Ich will nicht drängeln, ich komme nur nicht mehr mit, wegen der Versionen:

Auf: hub.docker.com, entspricht das:
- fhem/fhem:dev-bullseye -> "testing"?
- fhem/fhem:dev-buster -> "stable"?

Was für Versionen sind dann auf: github.com/fhem/fhem-docker/:
- ghcr.io/fhem/fhem/fhem-docker:bullseye
- ghcr.io/fhem/fhem/fhem-docker:buster

Oder ist fhem/fhem:dev-bullseye = fhem/fhem-docker:bullseye?

Ich habe mal mit "ghcr.io/fhem/fhem/fhem-docker:bullseye" rum gespielt, scheint zu funktionieren. Oder sollte ich besser warten, bis alles auf hub.docker.com eingerichtet wurde?  :-\

Vielen Dank, dass es mit dem Container weiter geht!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 25 April 2022, 01:03:06
Zitat von: LutzG am 25 April 2022, 00:51:27
Was für Versionen sind dann auf: github.com/fhem/fhem-docker/:
- ghcr.io/fhem/fhem/fhem-docker:bullseye
- ghcr.io/fhem/fhem/fhem-docker:buster

Oder ist fhem/fhem:dev-bullseye = fhem/fhem-docker:bullseye?

Weder noch. Die Images werden mit gleichem Tag identisch sein:
fhem/fhem:dev-bullseye = fhem/fhem-docker:dev-bullseye
fhem/fhem:dev-buster = fhem/fhem-docker:dev-buster
fhem/fhem:bullseye = fhem/fhem-docker:bullseye
fhem/fhem:buster = fhem/fhem-docker:buster

Das eine ist ein fhem auf Basis von Debian buster, das andere bullseye.

Wenn Du die von Github Container registry eingebunden hast,  brauchst Du nichts machen.
Ich aktualisiere dockerhub jetzt nur, weil nicht jeder eine registry einbinden kann :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 25 April 2022, 01:16:07
Zitat von: Sidey am 25 April 2022, 01:03:06
Wenn Du die von Github Container registry eingebunden hast,  brauchst Du nichts machen.
Ich aktualisiere dockerhub jetzt nur, weil nicht jeder eine registry einbinden kann :)

OK, verstanden!  8)

Zitat von: Sidey am 25 April 2022, 01:03:06
Das eine ist ein fhem auf Basis von Debian buster, das andere bullseye.

Was ist der "dev" Unterschied zum Beispiel bei bullseye:
- fhem/fhem-docker:dev-bullseye
- fhem/fhem-docker:bullseye
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 25 April 2022, 06:56:40
Zitat von: LutzG am 25 April 2022, 01:16:07
Was ist der "dev" Unterschied zum Beispiel bei bullseye:
- fhem/fhem-docker:dev-bullseye
- fhem/fhem-docker:bullseye

Der Zusatz Dev bedeutet, dass es aus dem development Branch kommt.
Wenn es Veränderungen gibt, dann landen sie zuerst in diesem Branch. Damit die Images unterscheidbar bleiben, bekommen die Image Tags ein dev- angestellt.
Du kannst davon ausgehen, dass Aktualisierungen in dev-buster zuerst verfügbar sind und erst später in buster bereitgestellt werden.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 25 April 2022, 11:47:26
Puh, ein Wochenende abwesend und schon kommt man nicht mehr hinterher.

@balli1187
Das Problem scheint wohl soweit ich das verstehe in der Kommunikation zwischen den Containern und dem Außenport bzw. untereinander zu sein. Es hängt wohl mit diesem von QNAP verwendeten virtuellen Switch zusammen.
Ich hatte den Portainer-Container installiert und geöffnet. Aber dann komme ich nicht mehr weiter.

Zitathttps://www.qnap.com/en/how-to/tutorial/article/how-to-use-container-station
Werde ich mir mal genauer anschauen, weil das ja zukünftig noch öfter passieren könnte.
Gibt es denn auf Github Container keine Möglichkeit die Dateien runterzuladen?
Ich kenne das z.B. von der Dreambox, dort kann man die Dateien als Zip herunterladen und manuell einpflegen.

ZitatDa ich Schreibrechte im dockerhub erhalten habe, konnte ich bereits die ersten Images im dockerhub aktualisieren.
https://hub.docker.com/repository/docker/fhem/fhem

Die Tags `buster` und `bullseye` kommen später noch dazu.
latest wird allerdings nicht aktualisiert!
Also ist das fhem/fhem-docker Image jetzt auf Docker-Hub zu finden? Zum laden kann aber docker pull fhem/fhem:bullseye verwendet werden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 25 April 2022, 12:17:11
Ich habe es mit "docker pull fhem/fhem:bullseye" probiert.

Wie gewohnt nimmt die Container-Station als Name nur ein "fhem/fhem:bullseye"
In den Images wird dann ein neues angezeigt, das aber den gleichen Namen wie das alte hat: "fhem/fhem"
Interessant ist, dass bei Version trotz dem "bullseye" beim ziehen "latest" steht und das Erstelldatum des Images (2017/03/02 03:08:12) sogar noch vor dem Erstelldatum des aktuell verwendeten "veraltetem" Image (2021/10/19 21:01:19) liegt.

Ist das jetzt aktuell oder nicht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 25 April 2022, 12:56:03
Zitat von: Superposchi am 25 April 2022, 11:47:26
Ich hatte den Portainer-Container installiert und geöffnet. Aber dann komme ich nicht mehr weiter.
Werde ich mir mal genauer anschauen, weil das ja zukünftig noch öfter passieren könnte.

du musst dir das _erst_ genauer anschauen und dann weitermachen, sonst hilft es nichts.
Dort gibt es auch einen Punkt "Adding an Image Registry", den musst du abarbeiten und dort die Github Registry hinterlegen. Anders klappt das einfach nicht.

Zitat von: Superposchi am 25 April 2022, 11:47:26
Gibt es denn auf Github Container keine Möglichkeit die Dateien runterzuladen?
Ich kenne das z.B. von der Dreambox, dort kann man die Dateien als Zip herunterladen und manuell einpflegen.

Das würde aber völlig am Konzept von Containern vorbeigehen.

Zitat von: Superposchi am 25 April 2022, 12:17:11
Ich habe es mit "docker pull fhem/fhem:bullseye" probiert.

Wie gewohnt nimmt die Container-Station als Name nur ein "fhem/fhem:bullseye"
In den Images wird dann ein neues angezeigt, das aber den gleichen Namen wie das alte hat: "fhem/fhem"
Interessant ist, dass bei Version trotz dem "bullseye" beim ziehen "latest" steht und das Erstelldatum des Images (2017/03/02 03:08:12) sogar noch vor dem Erstelldatum des aktuell verwendeten "veraltetem" Image (2021/10/19 21:01:19) liegt.

Ist das jetzt aktuell oder nicht?

solange keiner weiß, was du genau gemacht/geändert hast, kann auch niemand nachvollziehen, was gerade das Problem ist.
Schreib doch bitte so, dass man deine Schritte nachvollziehen kann.

Vermutlich wäre es einfacher, wenn du dir eine VM auf deinem QNAP erstellst. Dann hast du wieder die üblichen Update-Mechanismen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 25 April 2022, 13:23:04
ZitatDas würde aber völlig am Konzept von Containern vorbeigehen.
Wieso das? Ob ich den Container über die Oberfläche lade oder manuell auf mein System runterladen und dann "offline" installiere ist doch das gleiche.

Zitatsolange keiner weiß, was du genau gemacht/geändert hast, kann auch niemand nachvollziehen, was gerade das Problem ist.
Schreib doch bitte so, dass man deine Schritte nachvollziehen kann.
Entschuldigung, da ich keine anderen Wege kenne denke ich, dass es selbsterklärend ist. Also in Einzelschritten:
Die Oberfläche meines NAS geöffnet
Dort die Container-Station geöffnet
Auf Images gewechselt
Das Ziehen eines neuen Images geöffnet
Dort den Namen des Images eingegeben (es funktioniert wirklich nur der Name, also ohne das docker pull)
Nach dem Laden wird das Image angezeigt
Theoretisch wird dann ein Container aus dem Image erstellt - habe ich aber nicht gemacht, da eben die Daten wie angegeben nicht passten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kjmEjfu am 25 April 2022, 14:41:36
Zitat von: Superposchi am 25 April 2022, 13:23:04
Wieso das? Ob ich den Container über die Oberfläche lade oder manuell auf mein System runterladen und dann "offline" installiere ist doch das gleiche.

Nein, ist eben nicht das Gleiche. Liegt daran, wie Docker arbeitet.

Zitat von: Superposchi am 25 April 2022, 13:23:04
Entschuldigung, da ich keine anderen Wege kenne denke ich, dass es selbsterklärend ist. Also in Einzelschritten:
Die Oberfläche meines NAS geöffnet
Dort die Container-Station geöffnet
Auf Images gewechselt
Das Ziehen eines neuen Images geöffnet
Dort den Namen des Images eingegeben (es funktioniert wirklich nur der Name, also ohne das docker pull)
Nach dem Laden wird das Image angezeigt
Theoretisch wird dann ein Container aus dem Image erstellt - habe ich aber nicht gemacht, da eben die Daten wie angegeben nicht passten.

Haben wir aber nicht schon mehrfach festgestellt, dass dir dieser Weg kein positives Ergebnis liefern wird? Ist doch der gleiche Weg wie neulich. Wieso sollte da plötzlich ein neues Ergebnis rauskommen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 25 April 2022, 14:51:00
ZitatHaben wir aber nicht schon mehrfach festgestellt, dass dir dieser Weg kein positives Ergebnis liefern wird? Ist doch der gleiche Weg wie neulich. Wieso sollte da plötzlich ein neues Ergebnis rauskommen?
Weil der Container im docker-Hub wohl offensichtlich aktualisiert wurde. Es lässt sich ja auch im Vergleich zu früher ein neuer Container laden. Vorher wurde ja mit einer Fehlermeldung abgebrochen, jetzt ein Image geladen - offensichtlich ist nur die Frage ob es das richtige Image ist.

ZitatNein, ist eben nicht das Gleiche. Liegt daran, wie Docker arbeitet.
Dann erklär mir bitte warum die Container-Station diese Möglichkeit bietet wenn das so am Konzept vorbei ist.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 April 2022, 16:05:36
Eigentlich arbeitet Docker in einem Schichtmodel. Ein runtergeladener/Installierter Container dagegen nicht.
Wenn Du also z.B.
Debian
\- SMTP
|- FHEM
|- ....
Wir der Ubuntu teil nur einmal runtergeladen und für FHEM/SMTP/... jeweils nur die Änderungen. Ist eigentlich sogar verschachtelter als hier angedeutet. Mann Sieht diese Teilstücke, wenn man ein "docker pull" macht. Ein runtergeladener Container ist dagegen monolitisch.

Das es Syno einfach anders macht als andere, bedeutet nicht, das es gut ist ......
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Superposchi am 25 April 2022, 16:24:49
@Wernieman
Das heißt wenn ich einen Container ziehe, lade ich eigentlich nur einen gewissen Teil - richtig verstanden?

@all
Ich habe es jetzt auch hinbekommen das Image mit der Version Bullseye zu ziehen. Es hat folgendes Erstellungsdatum: 2022/04/24
Offenbar ist in der Container-Station ein Bug, der dazu führt, dass egal was man angibt immer die latest-Version gezogen wird wenn man unter Images ein Image zieht. Wenn man hingegen unter Erstellen nach einem Container sucht und dort auf Installieren klickt, dann kann man die verschiedenen Versionen auswählen und er zieht auch die ausgewählte Version. Dort werden auch alle vier neuen Versionen angezeigt.
In einem daraus erstellen Contaier kann ich dann auch fhem-alexa problemlos installieren. Heißt also erst mal die Daten aus dem alten Server auf den neuen übertragen und dann alles durchprobieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 25 April 2022, 16:25:53
Zitat von: Sidey am 25 April 2022, 06:56:40
Du kannst davon ausgehen, dass Aktualisierungen in dev-buster zuerst verfügbar sind und erst später in buster bereitgestellt werden.

Also:
-  fhem/fhem:dev-bullseye (buster) -> eher "testing" / wenn Mal was nicht funktioniert?
-  fhem/fhem:bullseye (buster) -> produktiver Einsatz?

Noch eine Frage wegen der npm Packete, die ja nicht mehr per Default im Container sind. Ich hab doch etwas Bammel, das produktive System umzustellen.  :-\

Ich verwende nur Alexa, (kein Google / Ikea / Homebridge). Also brauche ich doch für den Container nur:
-e NPM_PKGS="alexa-fhem alexa-cookie2" #(auf Github steht "alexa-cookie" ohne "2" ?)

Für Alexa verwende ich aber ab und zu "homebridgeMapping", brauche ich dann doch: homebridge, homebridge-fhem? Und ich habe noch "pm2 - 5.2.0", wo ich nicht weiß, ob ich das brauche.

Die kann ich aber sicher weg lassen;
- gassistant-fhem -> nur für Google?
- tradfri-fhem -> Ikea?

Vielen Dank für die Geduld! Lutz
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 April 2022, 16:39:40
Zitat von: Superposchi am 25 April 2022, 16:24:49
@Wernieman
Das heißt wenn ich einen Container ziehe, lade ich eigentlich nur einen gewissen Teil - richtig verstanden?

Nein ... wenn Du es komplett lädst, ist es ein monolitischer Block, siehe mein Beitrag
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 25 April 2022, 18:31:21
Zitat von: LutzG am 25 April 2022, 16:25:53
-  fhem/fhem:dev-bullseye (buster) -> eher "testing" / wenn Mal was nicht funktioniert?
-  fhem/fhem:bullseye (buster) -> produktiver Einsatz?

Könnte man so stehen lassen. Wenn allerdings niemand die dev Tags verwendet, wird auch niemand einen Fehler finden bevor er in die anderen Images wandert :)

Zitat von: LutzG am 25 April 2022, 16:25:53
Ich verwende nur Alexa, (kein Google / Ikea / Homebridge). Also brauche ich doch für den Container nur:
-e NPM_PKGS="alexa-fhem alexa-cookie2" #(auf Github steht "alexa-cookie" ohne "2" ?)

Anstelle im Image etwas zu installieren nur weil es geht, kannst Du auch dafür das speziell geschaffene Docker Image verwenden:
https://github.com/fhem/alexa-fhem-docker

Einfach alle Container in das gleiche Netzwerk hängen und gut ist.
So betreibe ich mein FHEM auch. FHEM Container, Alexa-FHEM Container und einen MariaDB Container in einem docker Netzwerk.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 25 April 2022, 22:26:06
Und genau DAS ist der Sinn von Docker. Kleine, Spezielle Container, welche auch (meistens) funktionieren, da genau so getestet
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 26 April 2022, 00:03:07
Zitat von: Sidey am 25 April 2022, 18:31:21
Anstelle im Image etwas zu installieren nur weil es geht, kannst Du auch dafür das speziell geschaffene Docker Image verwenden:
https://github.com/fhem/alexa-fhem-docker

Finde leider keine Anleitung, mit der ich das hin bekomme. :-[
Mein "Test" fhem-Container heißt "fhem2" (Installation hinter 2 Rutern)

Container antwortet auf http (nicht https):
{"header":{"namespace":"Alexa.ConnectedHome.Control","name":"UnsupportedOperationError","payloadVersion":"2","messageId":"f307b220-6454-4952-bf9c-XXXX20e1527"},"payload":{}}

Das Device:
defmod alexa alexa
attr alexa alexaFHEM-auth crypt:5e5dXXXXXXXXX60c545e2419
attr alexa alexaFHEM-config ./alexa-fhem.cfg
attr alexa alexaFHEM-host 172.19.0.2
attr alexa alexaFHEM-log ./log/alexa-%Y-%m-%d.log
attr alexa alexaMapping #Characteristic=<name>=<value>,...\
On=verb=schalte,valueOn=an;;ein,valueOff=aus,valueToggle=um\
\
Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
Hue=verb=stelle,valuePrefix=auf,values=rot:0;;grün:128;;blau:200\
Hue=verb=färbe,values=rot:0;;grün:120;;blau:220\
\
Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER\
Saturation=verb=sättige,values=AMAZON.NUMBER\
\
TargetPosition=verb=mach,articles=den;;die,values=auf:100;;zu:0\
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad\
\
Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
#Weckzeit=verb=stelle,valuePrefix=auf;;für,values=AMAZON.TIME,valueSuffix=uhr
attr alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
light=licht,lampen\
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
attr alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr alexa echoRooms #<deviceId>=<room>\

attr alexa fhemIntents #IntentName=<sample utterance>\
gutenMorgen=guten morgen\
guteNacht=gute nacht
attr alexa persons #<personId>=<name>\

attr alexa stateFormat alexaFHEM

setstate alexa stopped
setstate alexa 2022-04-25 23:39:53 alexaFHEM stopped


Fehlermeldung Portainer - alexa-fhem:
*** FHEM: connection failed: Error: read ECONNRESET
[4/25/2022, 11:32:05 PM] [FHEM2] trying longpoll to listen for fhem events
[4/25/2022, 11:32:05 PM] [FHEM2] starting longpoll: http://fhem2:8083/fhem2?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1650922325686
[4/25/2022, 11:32:05 PM] [FHEM2] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[4/25/2022, 11:32:31 PM] >>>> [srv]
[4/25/2022, 11:32:31 PM] ERROR: SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Server.processBody (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:327:26)
    at Server.<anonymous> (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:338:33)
    at IncomingMessage.emit (events.js:412:35)
    at endReadableNT (internal/streams/readable.js:1334:12)
    at processTicksAndRejections (internal/process/task_queues.js:82:21) from ::ffff:192.168.5.110
[4/25/2022, 11:32:31 PM] <<<< [srv] {"header":{"namespace":"Alexa.ConnectedHome.Control","name":"UnsupportedOperationError","payloadVersion":"2","messageId":"f307b220-6454-4952-bf9c-XXXXXXX527"},"payload":{}}
[4/25/2022, 11:32:35 PM] [FHEM2] trying longpoll to listen for fhem events
[4/25/2022, 11:32:35 PM] [FHEM2] starting longpoll: http://fhem2:8083/fhem2?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1650922355702
[4/25/2022, 11:32:35 PM] [FHEM2] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[4/25/2022, 11:33:05 PM] [FHEM2] trying longpoll to listen for fhem events
[4/25/2022, 11:33:05 PM] [FHEM2] starting longpoll: http://fhem2:8083/fhem2?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1650922385717
[4/25/2022, 11:33:05 PM] [FHEM2] longpoll error: Error: read ECONNRESET, retry in: 30000msec


Fehlermeldung Portainer - fhem2:
2022.04.25 23:40:06.025 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 172.19.0.2)
2022.04.25 23:40:13.019 3: alexa: using ssh cmd /usr/bin/ssh 172.19.0.2
ssh: connect to host 172.19.0.2 port 22: Connection refused
ssh: connect to host 172.19.0.2 port 22: Connection refused
2022.04.25 23:40:13.101 2: alexa: starting alexa-fhem: /usr/bin/ssh 172.19.0.2  -c /tmp/alexa-fhem.cfg -a xx:xx -s
2022.04.25 23:40:13.107 3: alexa: starting
2022.04.25 23:40:13.119 3: alexa: using logfile: ./log/alexa-2022-04-25.log
2022.04.25 23:40:13.131 3: alexa: read: end of file reached while sysread
2022.04.25 23:40:13.132 3: alexa: stopped
2022.04.25 23:40:33.013 3: alexa: using ssh cmd /usr/bin/ssh 172.19.0.2
ssh: connect to host 172.19.0.2 port 22: Connection refused


Fehlermeldung alexaFHEMlog:
*** CONFIG: parsed completely
[25/04/2022, 22.23.09] os.homedir()=/opt/fhem
[25/04/2022, 22.23.09] this is alexa-fhem 0.5.62
[25/04/2022, 22.23.09] connecting to FHEM ...
[25/04/2022, 22.23.09] [FHEM] defaults to: will not send proactive events
[25/04/2022, 22.23.09] [FHEM] trying longpoll to listen for fhem events
[25/04/2022, 22.23.09] [FHEM] starting longpoll: https://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON×tamp=1650918189949
[25/04/2022, 22.23.10] [FHEM] got csrfToken: csrf_549770843262937
[25/04/2022, 22.23.10] [FHEM] Checking devices and attributes...
[25/04/2022, 22.23.10] [FHEM]   executing: https://127.0.0.1:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=csrf_549770843262937&XHR=1
[25/04/2022, 22.23.10] [FHEM]   executing: https://127.0.0.1:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=csrf_549770843262937&XHR=1
[25/04/2022, 22.23.10] [FHEM] waiting for events ...
[25/04/2022, 22.23.10] [FHEM] Fetching FHEM devices...
[25/04/2022, 22.23.10] [FHEM] fetching: https://127.0.0.1:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=csrf_549770843262937&XHR=1
[25/04/2022, 22.23.10] [FHEM] longpoll ended, reconnect in: 200msec
[25/04/2022, 22.23.10] [FHEM] There was a problem connecting to FHEM (https://127.0.0.1:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=csrf_549770843262937&XHR=1).
[25/04/2022, 22.23.10] [FHEM]   401: Authorization Required
[25/04/2022, 22.23.10] [FHEM] There was a problem connecting to FHEM (https://127.0.0.1:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=csrf_549770843262937&XHR=1).
[25/04/2022, 22.23.10] [FHEM]   401: Authorization Required
[25/04/2022, 22.23.10] [FHEM] There was a problem connecting to FHEM (null)
[25/04/2022, 22.23.10] [FHEM]   401: Authorization Required
*** FHEM: connection failed: 401: Authorization Required
[25/04/2022, 22.23.10] Got SIGTERM, shutting down alexa-fhem...
[25/04/2022, 22.23.10] Reading alexaFHEM.ProxyConnection set to stopping;; alexa-fhem terminating
Unknown cipher type '/tmp/alexa-fhem.cfg'
Unknown cipher type '/tmp/alexa-fhem.cfg'
Unknown cipher type '/tmp/alexa-fhem.cfg'
Unknown cipher type '/tmp/alexa-fhem.cfg'


Seit 17 Uhr übe ich mit "alexa-fhem-docker". Das funktioniert ziemlich leicht schnell...   ???
-e NPM_PKGS="alexa-fhem alexa-cookie2"

Edit:
Die IP's:
172.19.0.2 alexa-fhem
172.19.0.3 fhem
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 26 April 2022, 08:16:46
Zitat von: LutzG am 26 April 2022, 00:03:07
Finde leider keine Anleitung, mit der ich das hin bekomme. :-[
Mein "Test" fhem-Container heißt "fhem2" (Installation hinter 2 Rutern)

Fehlermeldung Portainer - alexa-fhem:
*** FHEM: connection failed: Error: read ECONNRESET
[4/25/2022, 11:32:05 PM] [FHEM2] trying longpoll to listen for fhem events
[4/25/2022, 11:32:05 PM] [FHEM2] starting longpoll: http://fhem2:8083/fhem2?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1650922325686
[4/25/2022, 11:32:05 PM] [FHEM2] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[4/25/2022, 11:32:31 PM] >>>> [srv]
[4/25/2022, 11:32:31 PM] ERROR: SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Server.processBody (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:327:26)
    at Server.<anonymous> (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:338:33)
    at IncomingMessage.emit (events.js:412:35)
    at endReadableNT (internal/streams/readable.js:1334:12)
    at processTicksAndRejections (internal/process/task_queues.js:82:21) from ::ffff:192.168.5.110



Edit:
Die IP's:
172.19.0.2 alexa-fhem
172.19.0.3 fhem

Bei mir ist es schon eine Weile her, allerdings kann ich mich an keine größeren Probleme erinnern.
Eventuell erlaubt dein fhemweb den Zugriff nicht. Ich habe für den Zugriff von z.B. alexa-fhem ein eigenes FHEMWEB definiert in dem über das Attribut allowfrom definiert ist, wer es nutzen darf.

Hier ein Beispiel:

defmod WEBapi FHEMWEB 8088 global
attr WEBapi allowfrom localhost|alexa-fhem
attr WEBapi csrfToken none
attr WEBapi editConfig 0
attr WEBapi longpoll websocket
attr WEBapi room system
attr WEBapi title FHEM Web API
attr WEBapi verbose 3


Da laut deinen Fehlermerldungen ein Zugriff auf http://fhem2:8083/ nicht möglich ist, könnte es an der Erlaubnis liegen.
Was ich allerdings auch seltsam finde ist dass der Zugriff auf den Pfad /fhem2 versucht wird.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 27 April 2022, 00:10:39
Zitat von: Sidey am 26 April 2022, 08:16:46
Eventuell erlaubt dein fhemweb den Zugriff nicht.
[...]

Hier ein Beispiel:

defmod WEBapi FHEMWEB 8088 global
attr WEBapi allowfrom localhost|alexa-fhem
[...]

Damit bekomme ich auch keine Verbindung.  :(

Zitat von: Sidey am 26 April 2022, 08:16:46
Was ich allerdings auch seltsam finde ist dass der Zugriff auf den Pfad /fhem2 versucht wird.

Wenn der alexa-fhem Container "neu" startet (config gelöscht), kommt der Log in Portainer:
*** FHEM: connection failed: Error: getaddrinfo ENOTFOUND fhem
[4/26/2022, 11:17:33 PM] [FHEM] trying longpoll to listen for fhem events
[4/26/2022, 11:17:33 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1651007853119


Auf "fhem:8083" kann er den Container nicht finden, meiner heißt fhem2. Ich vermute "ENOTFOUND" weißt darauf hin? Darum habe ich in der:
...../Docker/volumes/alexa-fhem/_data/config.json

   [...]
  },
  "connenctions" [
   [...]
   "server": "fhem" #-> in fhem2 geändert
  ]


Dann ändert sich der Log:
*** FHEM: connection failed: Error: read ECONNRESET
[4/26/2022, 11:25:49 PM] [FHEM] trying longpoll to listen for fhem events
[4/26/2022, 11:25:49 PM] [FHEM] starting longpoll: http://fhem2:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1651008349179
[4/26/2022, 11:25:49 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec


Ping fhem2 funktioniert in der Portainer-Console vom alexa-fhem Container.

Den Container "fhem2" verwende ich, damit er die Anwesenheit der Rechner/Drucker außerhalb der DMZ an meinen "Haupt-fhem-server" in der DMZ meldet. Darum möchte ich ihn auch nicht umbenennen. Kann sein, dass ich da was verstellt habe.  ???

Ich werd mal die nächste Zeit auf einem nicht verwendetem Raspi mit den Containern rum spielen und die Default-Namen lassen. Vielleicht auch mit Docker Compose das "nachvollziehbarer" installieren - muss ich auch erst Mal noch lesen...

Vielen Dank erst Mal für die Hilfe!

Herzliche Grüße, Lutz

Edit:
Nicht daran gedacht, der Container ist noch "fhem/fhem:latest" von "2020-08-03" den ich bis jetzt mit "apt-get update && apt-get upgrade ..." aktualisiert habe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 27 April 2022, 22:12:56
Zitat von: LutzG am 27 April 2022, 00:10:39
Ich werd mal die nächste Zeit auf einem nicht verwendetem Raspi mit den Containern rum spielen und die Default-Namen lassen. Vielleicht auch mit Docker Compose das "nachvollziehbarer" installieren - muss ich auch erst Mal noch lesen...


1. Ich habe jetzt folgendes gemacht, dauer ca. 10 Minuten:

docker-compose.yml angelegt und darin ein Netzwerk "test_net" und zwei Services "fhem2" und "alexa-fhem2" definiert:


version: '2.3'

networks:
  test_net:
    driver: bridge
    # enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.28.0.0/28
          gateway: 172.28.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 !
  #

  # Minimum example w/o any custom environment variables
  fhem2:
    image: ghcr.io/fhem/fhem/fhem-docker:bullseye
    restart: always
    networks:
      - test_net
    ports:
      - "18083:8083"
    volumes:
      - "./fhem/:/opt/fhem/"
  alexa-fhem2:
    image: ghcr.io/fhem/fhem/alexa-fhem:2
    restart: always
    networks:
     - test_net
    ports:
      - "13000:3000"
    volumes:
      - "./alexa-fhem/:/alexa-fhem/"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Berlin


2. Dann habe ich die Container gestartet und den von dir besagten Fehler erhalten:


alexa-fhem2_1  | [4/27/2022, 10:01:50 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1651089710257
alexa-fhem2_1  | [4/27/2022, 10:01:50 PM] [FHEM] longpoll error: Error: getaddrinfo ENOTFOUND fhem, retry in: 20000msec
alexa-fhem2_1  | *** FHEM: connection failed: Error: getaddrinfo ENOTFOUND fhem


3. In xx den servernamen auf fhem2 angepasst.


  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "fhem2"
    }
  ]


4. Den Service "alexa-fhem" neu geartet, damit die aktualisierte Konfigurartion geladen wird:



alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM] trying longpoll to listen for fhem events
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM] starting longpoll: http://fhem2:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1651089858202
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] Server listening on: http://:::3000 for direct connections
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM] got csrfToken: csrf_772725298117442
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM] Checking devices and attributes...
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM]   executing: http://fhem2:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=csrf_772725298117442&XHR=1
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM]   executing: http://fhem2:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=csrf_772725298117442&XHR=1
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM] waiting for events ...
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM] Fetching FHEM devices...
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM] fetching: http://fhem2:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=csrf_772725298117442&XHR=1
alexa-fhem2_1  | [4/27/2022, 10:04:18 PM] [FHEM] no alexa device found. please define it.


Verbindung steht von alexa-fhem container zum fhem container.

Fhemweb entspricht hier dem default:

defmod WEB FHEMWEB 8083 global


So funktioniert es. Portainer nutze ich nicht, aber dort kannst Du bestimmt auch docker-compose hinterlegen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 28 April 2022, 01:12:27
Zitat von: Sidey am 27 April 2022, 22:12:56
1. Ich habe jetzt folgendes gemacht, dauer ca. 10 Minuten:

Ich übe schon den ganzen Tag... :o  Ganz, ganz lieben Dank!  :)

Fehlermeldungen sind weg, ich musste aber noch:

define alexa alexa
attr alexa alexaFHEM-host 172.28.0.3


sonst war das npm Packet: "alexa-fhem" nicht installiert.

Laut: https://wiki.fhem.de/wiki/FHEM_Connector_für_Amazon_Alexa (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa), soll bei der Definition des alexa-Device ein " SSH-Key", "Secret-Key", ... erzeugt werden. Kann es sein, weil bei mir schon Alexa läuft, dass eine Anmeldung an eurem Server nicht (noch Mal) möglich ist?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 13 Mai 2022, 13:34:42
Moin, habe mich auch versucht meine aktuelle FHEM Installation in einen Docker-Container zu ziehen.
Das hat bisher sehr gut funktioniert. Im Moment hänge ich bei alexa-fhem fest.

Erster Versuch war es das Package per npm im Container zu installieren. Grundsätzlich ging das.
Das ganze per Environment-Variable automatisch zu installieren hat dann aber nicht mehr funktioniert.

Also bin ich über den Hinweis hier im Thread auf den alexa-fhem Container übergegangen.
Leider funktioniert das bei mir bisher nicht so ohne Probleme. Wäre dankbar für Hinweise wo das Problem steckt.

--------------------------------------------------------------------------------------------------
Alternativ die Frage, warum ich "alexa-fhem" nicht per environment in docker-compose mit NPM_PKGS="alexa-fhem" installiert bekomme?
Zumindest quittiert das Device nach einem Recreate des Containers mit "alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'".

EDIT: Die Option über die Umgebungsvariable NPM_PKGS funktioniert mittlerweile. Von daher hätte ich eine funktionierende Option.
Aber grundsätzlich habe ich eigentlich Interesse daran alexa-fhem in einem eigenen Container laufen zu lassen.
--------------------------------------------------------------------------------------------------

Aktueller Stand. Hier ein Define und List vom Device:

define Alexa alexa
attr Alexa alexaFHEM-config ./alexa-fhem.cfg
attr Alexa alexaFHEM-host alexa-fhem [ALTERNATIV die ip, gleicher Fehler]
attr Alexa alexaFHEM-log %L/alexa-%Y-%m-%d.log
attr Alexa alexaMapping #Characteristic=<name>=<value>,...\
attr Alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
attr Alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr Alexa echoRooms #<deviceId>=<room>\
attr Alexa fhemIntents #IntentName=<sample utterance>\
attr Alexa persons #<personId>=<name>\
attr Alexa stateFormat alexaFHEM



Internals:
   FUUID      627e2c34-aaaa-bbbb-0cc6-f4b4e506e5205769
   FVERSION   39_alexa.pm:0.238200/2021-02-24
   LAST_START 2022-05-13 13:29:46
   LAST_STOP  2022-05-13 13:29:46
   NAME       Alexa
   NOTIFYDEV  global,global:npmjs.*alexa-fhem.*
   NR         311
   NTFY_ORDER 50-Alexa
   PARTIAL   
   STARTS     2
   STATE      stopped
   TYPE       alexa
   active     0
   alexa-fhem version 0.5.61
   logfile    %L/alexa-%Y-%m-%d.log
   CoProcess:
     cmdFn      alexa_getCMD
     name       alexaFHEM
     state      stopped
   READINGS:
     2022-05-13 13:29:46   alexaFHEM       stopped
     2022-05-13 12:00:20   alexaFHEM.bearerToken crypt:7b7374....01070d5556
     2022-05-13 12:00:20   alexaFHEM.skillRegKey crypt:7a0370240f0e205e1....57708737650780d555f0653
   helper:
Attributes:
   alexaFHEM-config ./alexa-fhem.cfg
   alexaFHEM-host 172.29.0.2
   alexaFHEM-log %L/alexa-%Y-%m-%d.log


Hier der Ausschnit des FHEM-Logfiles:

2022.05.13 12:39:39.019 3: Alexa: using ssh cmd /usr/bin/ssh 172.29.0.2
ssh: connect to host 172.29.0.2 port 22: Connection refused
ssh: connect to host 172.29.0.2 port 22: Connection refused
2022.05.13 12:39:39.073 2: Alexa: starting alexa-fhem: /usr/bin/ssh 172.29.0.2  -c /tmp/alexa-fhem.cfg
2022.05.13 12:39:39.080 3: Alexa: starting
2022.05.13 12:39:39.090 3: Alexa: using logfile: /opt/fhem/log/alexa-2022-05-13.log
2022.05.13 12:39:39.108 3: Alexa: read: end of file reached while sysread
2022.05.13 12:39:39.109 3: Alexa: stopped


Und hier das Alexa-Logfile. Den Fehler mit dem Cipher findet man 1-2 mal hier im Thread/Forum aber leider keine für mich ersichtliche Lösung.
(Die ganzen Devices habe ich mal weggelassen)

[13/05/2022, 11.06.24] using config from ./alexa-fhem.cfg
*** CONFIG: parsed completely
[13/05/2022, 11.06.24] os.homedir()=/opt/fhem
[13/05/2022, 11.06.24] this is alexa-fhem 0.5.62
[13/05/2022, 11.06.24] connecting to FHEM ...
[13/05/2022, 11.06.24] [FHEM] defaults to: will not send proactive events
[13/05/2022, 11.06.24] [FHEM] trying longpoll to listen for fhem events
[13/05/2022, 11.06.24] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652432784525
[13/05/2022, 11.06.24] [FHEM] got csrfToken: qBZXcla2WrxRAYM5Gf
[13/05/2022, 11.06.24] [FHEM] Checking devices and attributes...
[13/05/2022, 11.06.24] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=qBZXcla2WrxRAYM5Gf&XHR=1
[13/05/2022, 11.06.24] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=qBZXcla2WrxRAYM5Gf&XHR=1
[13/05/2022, 11.06.24] [FHEM] waiting for events ...
[13/05/2022, 11.06.24] [FHEM] Fetching FHEM devices...
[13/05/2022, 11.06.24] [FHEM] fetching: http://127.0.0.1:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=qBZXcla2WrxRAYM5Gf&XHR=1
[13/05/2022, 11.06.24] [FHEM] alexa device is Alexa
[13/05/2022, 11.06.24] [FHEM] mappings for Alexa: {}
[13/05/2022, 11.06.24] [FHEM] Alexa will not send proactive events
[13/05/2022, 11.06.24] [FHEM] Alexa uses ID: 62769401-f33f-xxxx-xxxx-bcebc6b5f872947c
[13/05/2022, 11.06.24] Server listening on: http://127.0.0.1:41595 for proxy connections
[13/05/2022, 11.06.24] *** SSH: checking proxy configuration
[13/05/2022, 11.06.24] sshautoconf: home=/opt/fhem, spath=/opt/fhem/.alexa, cpath=./alexa-fhem.cfg, sshpath=/opt/fhem/.ssh
[13/05/2022, 11.06.24] Passed config: {
  sshproxy: {
    description: 'FHEM Connector',
    ssh: '/usr/bin/ssh',
    options: [ '-i', '/opt/fhem/.ssh/id_rsa', '-p', 58824, 'fhem-va.fhem.de' ],
    'bind-ip': '127.0.0.1',
    server: Server {
      maxHeaderSize: undefined,
      insecureHTTPParser: undefined,
      _events: [Object: null prototype],
      _eventsCount: 3,
      _maxListeners: undefined,
      _connections: 0,
      _handle: [TCP],
      _usingWorkers: false,
      _workers: [],
      _unref: false,
      allowHalfOpen: true,
      pauseOnConnect: false,
      httpAllowHalfOpen: false,
      timeout: 0,
      keepAliveTimeout: 5000,
      maxHeadersCount: null,
      headersTimeout: 60000,
      requestTimeout: 0,
      _connectionKey: '4:127.0.0.1:0',
      [Symbol(IncomingMessage)]: [Function: IncomingMessage],
      [Symbol(ServerResponse)]: [Function: ServerResponse],
      [Symbol(kCapture)]: false,
      [Symbol(async_id_symbol)]: 90
    }
  },
  connections: [
    {
      port: 8083,
      server: '127.0.0.1',
      filter: 'alexaName=..*',
      webname: 'fhem',
      uid: 6061,
      name: 'FHEM'
    }
  ]
}
[13/05/2022, 11.06.24] sshautoconf: SSH key seems to exist
[13/05/2022, 11.06.25] sshautoconf: Our SSH key is known at the reverse proxy, good!
[13/05/2022, 11.06.25] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=%7B%24defs%7B%22Alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bjsonlist2%20Alexa%3B%7B%24defs%7B%22Alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=qBZXcla2WrxRAYM5Gf&XHR=1
[13/05/2022, 11.06.25] BearerToken '...44977' read from Alexa
[13/05/2022, 11.06.25] 39_alexa.pm is new version: true
[13/05/2022, 11.06.25] sshautoconf: completed successfully
[13/05/2022, 11.06.25] *** SSH: proxy configuration set up done
[13/05/2022, 11.06.25] Reading alexaFHEM.ProxyConnection set to starting;; starting SSH
[13/05/2022, 11.06.25] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=%7B%24defs%7B%22Alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20Alexa%20alexaFHEM.ProxyConnection%20starting%3B%3B%20starting%20SSH%3B%7B%24defs%7B%22Alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=qBZXcla2WrxRAYM5Gf&XHR=1
[13/05/2022, 11.06.25] Starting SSH with -R 1234:127.0.0.1:41595 -oServerAliveInterval=90 -i /opt/fhem/.ssh/id_rsa -p 58824 fhem-va.fhem.de
*** FHEM: connected
[13/05/2022, 11.06.25] [FHEM] got: 26 results
[13/05/2022, 11.06.25] [FHEM] Structure.Tischlampen is scene
[13/05/2022, 11.06.25] [FHEM] Structure.Tischlampen has
[13/05/2022, 11.06.25] [FHEM]   On [state;on,off]
[13/05/2022, 11.06.25] [FHEM] Structure.Tischlampen will not send proactive events
[13/05/2022, 11.06.25] [FHEM] Structure.Tischlampen uses ID: 6278ac15-f33f-f519-a25c-169ff81c57986934
  2022-05-13 11:06:25 caching: Structure.Tischlampen-state: off
[13/05/2022, 11.06.26] Reading alexaFHEM.ProxyConnection set to running;; SSH connected
[13/05/2022, 11.06.26] [FHEM]   executing: http://127.0.0.1:8083/fhem?cmd=%7B%24defs%7B%22Alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20Alexa%20alexaFHEM.ProxyConnection%20running%3B%3B%20SSH%20connected%3B%7B%24defs%7B%22Alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=qBZXcla2WrxRAYM5Gf&XHR=1
[13/05/2022, 11.06.26] *** SSH: proxy connection established
[13/05/2022, 11.06.26] SSH: Welcome at the reverse proxy!  This pseudoshell does not react to any input - do not get irritated.
Unknown cipher type '/tmp/alexa-fhem.cfg'





Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 13 Mai 2022, 16:49:25
Hallo Lutz,

du hast Dem Alexa Modul mitgegeben, dass es sich mit dem Container per SSH verbinden soll

attr Alexa alexaFHEM-host 172.29.0.2

Du hast aber keine Credentials eingerichtet, damit das anmelden dort klappt.
Du kannst das Attribut entfernen, dann wird nicht mehr versucht per SSH in den alexa-fhem-container zu verbinden.

Ansonsten wäre es prima, wenn die Zeitstempel der Logfiles zueinander passen.


Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 14 Mai 2022, 00:33:20
Hallo Sidey,

Zitat von: Sidey am 13 Mai 2022, 16:49:25
du hast Dem Alexa Modul mitgegeben, dass es sich mit dem Container per SSH verbinden soll

attr Alexa alexaFHEM-host 172.29.0.2

Du hast aber keine Credentials eingerichtet, damit das anmelden dort klappt.
Mit den "Credentials", da weiß ich jetzt nicht, was ich wo einrichten soll.  :-\

Ich hatte deine "docker-compose.yml" auf einem Testsystem installiert aber ohne den Eintrag, hatten die Container Probleme sich zu finden und im alexa-Modul war die Meldung dass "alexa-fhem" nicht installiert ist. So hatte ich es aus den Log-Datein gemeint zu verstehen. Aber nachdem ich die Amazon-Anmeldeseite nicht bekommen habe, habe ich mich nicht mehr getraut, mein Produktivsystem umzustellen. Die Einrichtung von alexa hatte damals auch nicht auf Anhieb funktioniert, dass war mir dann zu heiß.  :-\

Ich habe dann nur den Container gewechselt von:
fhem/fhem:latest --> ghcr.io/fhem/fhem/fhem-docker:bullseye

und die "Environment variables" gesetzt:
NPM_PKGS --> alexa-fhem alexa-cookie2 homebridge

für den Presence Container:
fhem/fhem:latest --> ghcr.io/fhem/fhem/fhem-minimal-docker:bullseye

danach liefen die Container wieder.

Zitat von: Sidey am 13 Mai 2022, 16:49:25
Ansonsten wäre es prima, wenn die Zeitstempel der Logfiles zueinander passen.

Das verstehe ich jetzt nicht. Holen sich die Container nicht die Zeit vom Wirt? Die SD-Karte hab ich leider schon wieder platt gemacht. ::)

Grüße Lutz
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 14 Mai 2022, 11:29:29
Zitat von: LutzG am 14 Mai 2022, 00:33:20
Hallo Sidey,
Mit den "Credentials", da weiß ich jetzt nicht, was ich wo einrichten soll.  :-\

Ok das ist nicht beschrieben. Ich habe da eine Idee, gib mir ein paar Tage, das sollte recht einfach machbar sein.
Du kannst das Attribut alexaFHEM-host entfernen. Der alexa-fhem container übermittelt die nötigen Daten an FHEM, die dann in der alexa definition angezeigt werden. Die SSH Verbindung ist dafür gedacht, dass man den node Prozess neu starten kann, was aber problemlos durch Neustarten des Alexa-Fhem Containers erledigt werden kann, sollte es jemals nötig sein (ich brauchte es bisher noch nicht).


Zitat von: LutzG am 14 Mai 2022, 00:33:20
Ich hatte deine "docker-compose.yml" auf einem Testsystem installiert aber ohne den Eintrag, hatten die Container Probleme sich zu finden und im alexa-Modul war die Meldung dass "alexa-fhem" nicht installiert ist. So hatte ich es aus den Log-Datein gemeint zu verstehen.

Die Meldung, bezieht sich auf das System auf dem das alexa-fhem Modul ausgeführt wird. Die Meldung, dass das NodeJs alexa-fhem nicht installiert ist, verhindert nicht die Funktionsfähigkeit von alexa-fhem.
Bei den Logdateien ist es wichtig, in die richten Logdateien zu schauen.
z.B. mit docker-compose logs alexa-fhem  wird as Log vom alexa-fhem Container angezeigt.
docker-compose logs fhem zeigt die vom FHEM Container an. GGf. hast Du die Container abweichend benannt, das weiss ich jetzt nicht.
Bei den Verbindungsdaten solltest Du auch mit hostnamen und nicht mit IP Addressen arbeiten.

Zitat von: LutzG am 14 Mai 2022, 00:33:20
Aber nachdem ich die Amazon-Anmeldeseite nicht bekommen habe, habe ich mich nicht mehr getraut, mein Produktivsystem umzustellen. Die Einrichtung von alexa hatte damals auch nicht auf Anhieb funktioniert, dass war mir dann zu heiß.  :-\
Verstehe, aber die Anmeldeseite öffnest Du doch auf einem beliebigem Rechner und hinterlegst dort die Anmeldedaten, die im alexa-fhem Modul angezeigt werden.

Zitat von: LutzG am 14 Mai 2022, 00:33:20
Ich habe dann nur den Container gewechselt von:
fhem/fhem:latest --> ghcr.io/fhem/fhem/fhem-docker:bullseye

Passt, habe ich auch so.

Zitat von: LutzG am 14 Mai 2022, 00:33:20
und die "Environment variables" gesetzt:
NPM_PKGS --> alexa-fhem alexa-cookie2 homebridge

Das mal wieder entfernen, das könnte sich in die quere kommen.

Zitat von: LutzG am 14 Mai 2022, 00:33:20
für den Presence Container:
fhem/fhem:latest --> ghcr.io/fhem/fhem/fhem-minimal-docker:bullseye

Zitat von: LutzG am 14 Mai 2022, 00:33:20
Das verstehe ich jetzt nicht. Holen sich die Container nicht die Zeit vom Wirt? Die SD-Karte hab ich leider schon wieder platt gemacht. ::)

Machen sie. Du hast aber einmal ein Logfile von 2022.05.13 12:39:39.073 und parallel von [13/05/2022, 11.06.24] gepostet. Das passte nicht zusammen.



Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 15 Mai 2022, 03:38:16
Hallo Sidey,

habe noch Mal die 3 Container (portainer, fhem, alexa-fhem) auf einem "frischem" RaspiOS lite installiert. Per ssh habe ich dann die Befehle abgesetzt. Vielleicht hab ich da schon Fehler gemacht?

sudo raspi-config   # -> Passwort ändern
sudo timedatectl set-timezone Europe/Berlin
sudo raspi-config --expand-rootfs
sudo reboot
sudo apt-get update
sudo apt-get upgrade
curl -fsSL get.docker.com -o get-docker.sh && sh get-docker.sh
sudo usermod -aG docker pi
sudo reboot

Testen ob es geklappt hat:

docker run hello-world
sudo apt-get install -y python3-pip python3-dev
sudo pip3 install docker-compose
docker-compose --version

Docker installieren:

docker pull portainer/portainer-ce:latest
docker volume create portainer_data
docker run -d -p 8000:8000 -p 9000:9000 -p 9443:9443 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

In Portainer dann die Container nach deiner "docker-compose.yml" https://forum.fhem.de/index.php/topic,89745.msg1219815.html#msg1219815 (https://forum.fhem.de/index.php/topic,89745.msg1219815.html#msg1219815) erstellt.

Anschließend in fhem erst Mal:

update
shutdown restart

NodeJs und das System aktualisiert, dann:

set allowed_WEB basicAuth administrator GeheimesPassWort
attr telnetPort globalpassword GeheimesPassWort


Ein paar Knöpfe für Start, Restart, Grundeinstellungen...

attr global language DE
attr WEB menuEntries Restart-Fhem,cmd=shutdown+restart,Update-Check,cmd=update+check,Update-Now,cmd=update,<br>Commandref,https://fhem.de/commandref_DE.html,Wiki,https://wiki.fhem.de,Forum,https://forum.fhem.de
attr WEB basicAuthMsg Bitte Benutzernamen und Passwort eingeben
attr WEB JavaScripts codemirror/fhem_codemirror.js
attr WEB codemirrorParam {"theme":"blackboard", "lineNumbers":true, "lineWrapping":true, "height":auto}
attr WEB title { if ($FW_room) { "LIVE: $FW_room" } elsif ($FW_detail) { "LIVE: $FW_detail" } else { "LIVE FHEM" } }
attr WEB HTTPS 1

Und wenn ich jetzt:

define alexa alexa

steht in dem State von alexa:

STATE: stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.

der Log von fhem:

2022.05.15 01:23:46.089 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 172.18.0.3)
2022.05.15 01:24:16.104 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 172.18.0.3)
2022.05.15 01:24:17.822 2: alexa: created default configfile: ./alexa-fhem.cfg
2022.05.15 01:24:17.843 2: alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
2022.05.15 01:24:17.858 2: alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
2022.05.15 01:24:46.123 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 172.18.0.3)
2022.05.15 01:25:16.134 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request (peer: 172.18.0.3)

der Log von alexa-fhem

*** FHEM: connection failed: Error: read ECONNRESET
[5/15/2022, 1:23:16 AM] [FHEM] trying longpoll to listen for fhem events
[5/15/2022, 1:23:16 AM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652570596065
[5/15/2022, 1:23:16 AM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[5/15/2022, 1:23:46 AM] [FHEM] trying longpoll to listen for fhem events
[5/15/2022, 1:23:46 AM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652570626080
[5/15/2022, 1:23:46 AM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[5/15/2022, 1:24:16 AM] [FHEM] trying longpoll to listen for fhem events
[5/15/2022, 1:24:16 AM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652570656093
[5/15/2022, 1:24:16 AM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[5/15/2022, 1:24:46 AM] [FHEM] trying longpoll to listen for fhem events
[5/15/2022, 1:24:46 AM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652570686118
[5/15/2022, 1:24:46 AM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET

Wenn ich deinen Vorschlag eingebe:

attr WEB allowfrom localhost|alexa-fhem

bin ich ausgesperrt.  :-[

Zitat von: Sidey am 14 Mai 2022, 11:29:29
Bei den Logdateien ist es wichtig, in die richten Logdateien zu schauen.
z.B. mit docker-compose logs alexa-fhem  wird as Log vom alexa-fhem Container angezeigt.
docker-compose logs alexa-fhem funktioniert bei mir nicht, ich habe die Container nicht mit "compose" erstellt. In Portainer erstellt das bei mir "Stacks" und die Ordner-Namen werden "bescheiden" umbenannt. Die Container habe ich -> Neuer Container -> darin alles eingetragen: Name, Port, Netzwerk, ... In Portainer kann ich die Logs ansehen / kopieren.
Zitat von: Sidey am 14 Mai 2022, 11:29:29
Du hast aber einmal ein Logfile von 2022.05.13 12:39:39.073 und parallel von [13/05/2022, 11.06.24] gepostet. Das passte nicht zusammen.
OK, hab ich jetzt verstanden! Ich hatte die Fehlermeldungen raus gesucht, die ich für Aussagekräftig hielt und bei den vielen Meldungen nicht auf die Zeiten geachtet.

Die Devices, alexa:
defmod alexa alexa
attr alexa alexaFHEM-config ./alexa-fhem.cfg
attr alexa alexaFHEM-log ./log/alexa-%Y-%m-%d.log
attr alexa alexaMapping #Characteristic=<name>=<value>,...\
On=verb=schalte,valueOn=an;;ein,valueOff=aus,valueToggle=um\
\
Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
Hue=verb=stelle,valuePrefix=auf,values=rot:0;;grün:128;;blau:200\
Hue=verb=färbe,values=rot:0;;grün:120;;blau:220\
\
Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER\
Saturation=verb=sättige,values=AMAZON.NUMBER\
\
TargetPosition=verb=mach,articles=den;;die,values=auf:100;;zu:0\
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad\
\
Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
#Weckzeit=verb=stelle,valuePrefix=auf;;für,values=AMAZON.TIME,valueSuffix=uhr
attr alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
light=licht,lampen\
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
attr alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr alexa echoRooms #<deviceId>=<room>\

attr alexa fhemIntents #IntentName=<sample utterance>\
gutenMorgen=guten morgen\
guteNacht=gute nacht
attr alexa persons #<personId>=<name>\

attr alexa stateFormat alexaFHEM

setstate alexa stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
setstate alexa 2022-05-15 02:38:49 alexaFHEM stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.


allowed_WEB:
defmod allowed_WEB allowed
attr allowed_WEB basicAuth SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
attr allowed_WEB basicAuthMsg Bitte Benutzernamen und Passwort eingeben
attr allowed_WEB validFor WEB

setstate allowed_WEB validFor:WEB
setstate allowed_WEB 2022-05-15 02:38:49 state validFor:WEB


Ich hoffe sehr, du kannst damit was anfangen?

Grüße, Lutz
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 15 Mai 2022, 19:22:11
Zitat von: LutzG am 15 Mai 2022, 03:38:16
Hallo Sidey,

habe noch Mal die 3 Container (portainer, fhem, alexa-fhem) auf einem "frischem" RaspiOS lite installiert. Per ssh habe ich dann die Befehle abgesetzt.

Ich habe das so jetzt auch nachgestellt.



Zitat von: LutzG am 15 Mai 2022, 03:38:16
In Portainer dann die Container nach deiner "docker-compose.yml" https://forum.fhem.de/index.php/topic,89745.msg1219815.html#msg1219815 (https://forum.fhem.de/index.php/topic,89745.msg1219815.html#msg1219815) erstellt.

Wenn Du dieses Beispiel verwendest hast, wo ich auch nur ein Verhalten nachgestellt habe, dann hat der fhem container den Namen fhem2.
Alexa-Fhem sucht im Standard aber nach einem Host mit dem Namen fhem.


Ich habe folgenden Stack angelegt:

version: '2.3'

networks:
  test_net:
    driver: bridge
    # enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.28.0.0/28
          gateway: 172.28.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 !
  #

  # Minimum example w/o any custom environment variables
  fhem:
    image: ghcr.io/fhem/fhem/fhem-docker:bullseye
    restart: always
    networks:
      - test_net
    ports:
      - "18083:8083"
    volumes:
      - "./fhem/:/opt/fhem/"
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:2
    restart: always
    networks:
     - test_net
    ports:
      - "13000:3000"
    volumes:
      - "./alexa-fhem/:/alexa-fhem/"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Berlin


Folgende fhem.cfg nach deinen Einstellungen:


attr global userattr alexaName alexaProactiveEvents:1,0 alexaRoom cmdIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global commandref modular
attr global dnsServer 127.0.0.11
attr global language DE
attr global logfile ./log/fhem-%Y-%m-%d.log
attr global modpath .
attr global mseclog 1
attr global nofork 0
attr global pidfilename ./log/fhem.pid
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define WEB FHEMWEB 8083 global
setuuid WEB 6280c5ff-f33f-6bf5-77ba-54c339d8380a3f22
attr WEB menuEntries Restart-Fhem,cmd=shutdown+restart,Update-Check,cmd=update+check,Update-Now,cmd=update,<br>Commandref,https://fhem.de/commandref_DE.html,Wiki,https://wiki.fhem.de,Forum,https://forum.fhem.de

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log Logfile
setuuid Logfile 6280c5ff-f33f-6bf5-28ed-51693c22bcd321aa

define autocreate autocreate
setuuid autocreate 6280c5ff-f33f-6bf5-efb0-8844413ad2ac7494
attr autocreate filelog ./log/%NAME-%Y.log

define eventTypes eventTypes ./log/eventTypes.txt
setuuid eventTypes 6280c5ff-f33f-6bf5-1da5-c0394e1b6f3c0c53

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 6280c5ff-f33f-6bf5-0337-f509a8ef46413e80
define DockerImageInfo DockerImageInfo
setuuid DockerImageInfo 6280c5ff-f33f-6bf5-4549-9805c24119fe59aa
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
setuuid fhemServerApt 6280c5ff-f33f-6bf5-8596-72113cfb9e3195f2
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 fhemServerNpm npmjs localhost
setuuid fhemServerNpm 6280c5ff-f33f-6bf5-6a4a-f29a6f4737e07112
attr fhemServerNpm alias Node.js Package Update Status
attr fhemServerNpm devStateIcon npm.updates.available:security@red:outdated npm.is.up.to.date:security@green:outdated .*npm.outdated.*in.progress:system_fhem_reboot@orange .*in.progress:system_fhem_update@orange warning.*:message_attention@orange error.*:message_attention@red
attr fhemServerNpm group Update
attr fhemServerNpm icon npm-old
attr fhemServerNpm room System
define fhemInstaller Installer
setuuid fhemInstaller 6280c5ff-f33f-6bf5-1751-6f107e95290f6421
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
define telnetPort telnet 7072
setuuid telnetPort 6280c5ff-f33f-6bf5-9d93-238b118590d5ebfb
define allowed_WEB allowed
setuuid allowed_WEB 6280c672-f33f-6bf5-d224-9f53d81c6cd61e29
attr allowed_WEB basicAuthMsg Bitte Benutzernamen und Passwort eingeben
attr allowed_WEB validFor WEB
define Alexa alexa
setuuid Alexa 6280c68d-f33f-6bf5-c48c-42feaf0760ebcd2f
attr Alexa alexaFHEM-config ./alexa-fhem.cfg
attr Alexa alexaFHEM-log ./log/alexa-%Y-%m-%d.log
attr Alexa alexaMapping #Characteristic=<name>=<value>,...\
On=verb=schalte,valueOn=an;;ein,valueOff=aus,valueToggle=um\
\
Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
Hue=verb=stelle,valuePrefix=auf,values=rot:0;;grün:128;;blau:200\
Hue=verb=färbe,values=rot:0;;grün:120;;blau:220\
\
Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER\
Saturation=verb=sättige,values=AMAZON.NUMBER\
\
TargetPosition=verb=mach,articles=den;;die,values=auf:100;;zu:0\
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad\
\
Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
#Weckzeit=verb=stelle,valuePrefix=auf;;für,values=AMAZON.TIME,valueSuffix=uhr
attr Alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
light=licht,lampen\
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
attr Alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr Alexa echoRooms #<deviceId>=<room>\

attr Alexa fhemIntents #IntentName=<sample utterance>\
gutenMorgen=guten morgen\
guteNacht=gute nacht
attr Alexa persons #<personId>=<name>\

attr Alexa stateFormat alexaFHEM


Das Log von alexa-fhem:

[5/15/2022, 7:20:31 PM] [FHEM] Fetching FHEM devices...
[5/15/2022, 7:20:31 PM] [FHEM] fetching: http://fhem:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=csrf_88333819439777&XHR=1
[5/15/2022, 7:20:31 PM] [FHEM] longpoll ended, reconnect in: 20200msec
[5/15/2022, 7:20:31 PM] [FHEM] There was a problem connecting to FHEM (http://fhem:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=csrf_88333819439777&XHR=1).
[5/15/2022, 7:20:31 PM] [FHEM]   401: Authorization Required
[5/15/2022, 7:20:31 PM] [FHEM] There was a problem connecting to FHEM (http://fhem:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=csrf_88333819439777&XHR=1).
[5/15/2022, 7:20:31 PM] [FHEM]   401: Authorization Required
[5/15/2022, 7:20:31 PM] [FHEM] There was a problem connecting to FHEM (null)
[5/15/2022, 7:20:31 PM] [FHEM]   401: Authorization Required
*** FHEM: connection failed: 401: Authorization Required


Jetzt klappt der Connect nicht, weil alexa-fhem das Passwort nicht kennt mit dem die Anmeldung an FHEM durchgeführt werden muss.
Lässt man das mit dem Passwort weg, dann klappt es.
Da Du eine hiervon abweichende Fehlermeldung hast, stoppe ich zunächst einmal an dieser Stelle.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 15 Mai 2022, 21:43:11
Zitat von: Sidey am 15 Mai 2022, 19:22:11
dann hat der fhem container den Namen fhem2.
Ich habe die Standard Namen (fhem, alexa-fhem ) / Ports (8083, 3000) verwendet, da außer portainer nichts weiter auf dem Raspberry läuft.

Zitat
Folgende fhem.cfg nach deinen Einstellungen:

attr global userattr alexaName alexaProactiveEvents:1,0 alexaRoom cmdIcon devStateIcon:textField-long devStateStyle icon sortby webCmd webCmdLabel:textField-long

Meine erste Zeile in der fhem.cfg lautet:

attr global userattr alexaName alexaProactiveEvents:1,0 alexaRoom cmdIcon devStateIcon:textField-long devStateStyle genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock,scene homebridgeMapping:textField-long icon sortby webCmd webCmdLabel:textField-long widgetOverride


Zitat
jetzt klappt der Connect nicht, weil alexa-fhem das Passwort nicht kennt
ich habe das attr allowed_WEB basicAuth gelöscht, fhem / Container neugestartet, keine Änderung, erst nach dem ich attr WEB HTTPS 1 gelöscht hatte, hat alexa-fhem fhem gefunden.

Der Log von alexa-fhem:
*** FHEM: connection failed: Error: read ECONNRESET
[5/15/2022, 9:05:12 PM] [FHEM] trying longpoll to listen for fhem events
[5/15/2022, 9:05:12 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652641512920
[5/15/2022, 9:05:12 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[5/15/2022, 9:05:42 PM] [FHEM] trying longpoll to listen for fhem events
[5/15/2022, 9:05:42 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652641542937
[5/15/2022, 9:05:42 PM] [FHEM] got csrfToken: csrf_190258082028199
[5/15/2022, 9:05:42 PM] [FHEM] Checking devices and attributes...
[5/15/2022, 9:05:42 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=csrf_190258082028199&XHR=1
[5/15/2022, 9:05:42 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=csrf_190258082028199&XHR=1
[5/15/2022, 9:05:42 PM] [FHEM] waiting for events ...
[5/15/2022, 9:05:42 PM] [FHEM] Fetching FHEM devices...
[5/15/2022, 9:05:42 PM] [FHEM] fetching: http://fhem:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=csrf_190258082028199&XHR=1
[5/15/2022, 9:05:43 PM] [FHEM] alexa device is alexa
[5/15/2022, 9:05:43 PM] [FHEM] alexa will not send proactive events
[5/15/2022, 9:05:43 PM] [FHEM] alexa uses ID: 62803a21-f33f-22e6-6cf8-add16053328e5194
[5/15/2022, 9:05:43 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22alexa-fhem%20version%22%7D%20%3D%20%220.5.61%22%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=csrf_190258082028199&XHR=1
[5/15/2022, 9:05:43 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Blist%20alexa%20.eventToken%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=csrf_190258082028199&XHR=1
*** FHEM: connected
[5/15/2022, 9:05:43 PM] [FHEM] got: 0 results
Preparing user environment ...
  - Creating symlink to config.json in /alexa-fhem/.alexa/config.json ...
Starting alexa-fhem ...
[5/15/2022, 9:06:14 PM] os.homedir()=/alexa-fhem
[5/15/2022, 9:06:14 PM] using config from /alexa-fhem/.alexa/config.json
*** CONFIG: parsed completely
[5/15/2022, 9:06:14 PM] this is alexa-fhem 0.5.61
[5/15/2022, 9:06:14 PM] connecting to FHEM ...
[5/15/2022, 9:06:14 PM] [FHEM] defaults to: will not send proactive events
[5/15/2022, 9:06:15 PM] [FHEM] trying longpoll to listen for fhem events
[5/15/2022, 9:06:15 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652641575328
[5/15/2022, 9:06:15 PM] Server listening on: http://:::3000 for direct connections
[5/15/2022, 9:06:15 PM] [FHEM] got csrfToken: csrf_190258082028199
[5/15/2022, 9:06:15 PM] [FHEM] Checking devices and attributes...
[5/15/2022, 9:06:15 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=csrf_190258082028199&XHR=1
[5/15/2022, 9:06:15 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=csrf_190258082028199&XHR=1
[5/15/2022, 9:06:15 PM] [FHEM] waiting for events ...
[5/15/2022, 9:06:15 PM] [FHEM] Fetching FHEM devices...
[5/15/2022, 9:06:15 PM] [FHEM] fetching: http://fhem:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=csrf_190258082028199&XHR=1
[5/15/2022, 9:06:15 PM] [FHEM] alexa device is alexa
[5/15/2022, 9:06:15 PM] [FHEM] alexa will not send proactive events
[5/15/2022, 9:06:15 PM] [FHEM] alexa uses ID: 62803a21-f33f-22e6-6cf8-add16053328e5194
[5/15/2022, 9:06:15 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22alexa-fhem%20version%22%7D%20%3D%20%220.5.61%22%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=csrf_190258082028199&XHR=1
[5/15/2022, 9:06:15 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Blist%20alexa%20.eventToken%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=csrf_190258082028199&XHR=1
*** FHEM: connected
[5/15/2022, 9:06:15 PM] [FHEM] got: 0 results


Hier meine fhem.cfg

attr global userattr alexaName alexaProactiveEvents:1,0 alexaRoom cmdIcon devStateIcon:textField-long devStateStyle genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock,scene homebridgeMapping:textField-long icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global commandref modular
attr global dnsServer 127.0.0.11
attr global language DE
attr global logfile ./log/fhem-%Y-%m-%d.log
attr global modpath .
attr global mseclog 1
attr global nofork 0
attr global pidfilename ./log/fhem.pid
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define WEB FHEMWEB 8083 global
setuuid WEB 62802833-f33f-22e6-8917-1596789d3a266501
attr WEB JavaScripts codemirror/fhem_codemirror.js
attr WEB codemirrorParam {"theme":"blackboard", "lineNumbers":true, "lineWrapping":true, "height":auto}
attr WEB menuEntries Restart-Fhem,cmd=shutdown+restart,Update-Check,cmd=update+check,Update-Now,cmd=update,<br>Commandref,https://fhem.de/commandref_DE.html,Wiki,https://wiki.fhem.de,Forum,https://forum.fhem.de
attr WEB title { if ($FW_room) { "LIVE: $FW_room" } elsif ($FW_detail) { "LIVE: $FW_detail" } else { "LIVE FHEM" } }

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log Logfile
setuuid Logfile 62802833-f33f-22e6-2f48-8545702047129528

define autocreate autocreate
setuuid autocreate 62802833-f33f-22e6-c3e0-d879eed81ccd7810
attr autocreate filelog ./log/%NAME-%Y.log

define eventTypes eventTypes ./log/eventTypes.txt
setuuid eventTypes 62802833-f33f-22e6-dc8a-4e84db521678c24f

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 62802833-f33f-22e6-d860-4774d2863e8f1199
define DockerImageInfo DockerImageInfo
setuuid DockerImageInfo 62802833-f33f-22e6-4111-9c466206a560ea0a
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
setuuid fhemServerApt 62802834-f33f-22e6-ca01-5d96f7119527b098
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 fhemServerNpm npmjs localhost
setuuid fhemServerNpm 62802834-f33f-22e6-655f-d219afe58eae179b
attr fhemServerNpm alias Node.js Package Update Status
attr fhemServerNpm devStateIcon npm.updates.available:security@red:outdated npm.is.up.to.date:security@green:outdated .*npm.outdated.*in.progress:system_fhem_reboot@orange .*in.progress:system_fhem_update@orange warning.*:message_attention@orange error.*:message_attention@red
attr fhemServerNpm group Update
attr fhemServerNpm icon npm-old
attr fhemServerNpm room System
define fhemInstaller Installer
setuuid fhemInstaller 62802834-f33f-22e6-9a46-e10c69cdd115717a
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
define telnetPort telnet 7072
setuuid telnetPort 62802834-f33f-22e6-cf55-49c9219e0687d49a
define allowed_WEB allowed
setuuid allowed_WEB 62802880-f33f-22e6-3c7b-89ea776cdc9fa0aa
attr allowed_WEB basicAuthMsg Bitte Benutzernamen und Passwort eingeben
attr allowed_WEB validFor WEB
define allowed_telnetPort allowed
setuuid allowed_telnetPort 628029fd-f33f-22e6-c7fd-1c405599ab34eefa
attr allowed_telnetPort globalpassword SHA256:3898758B:aXlhWlXEoxYs3UENCwCps06Pm+Kkg4pbVYSiW91eK+k
attr allowed_telnetPort validFor telnetPort
define alexa alexa
setuuid alexa 62803a21-f33f-22e6-6cf8-add16053328e5194
attr alexa alexaFHEM-config ./alexa-fhem.cfg
attr alexa alexaFHEM-log ./log/alexa-%Y-%m-%d.log
attr alexa alexaMapping #Characteristic=<name>=<value>,...\
On=verb=schalte,valueOn=an;;ein,valueOff=aus,valueToggle=um\
\
Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
Hue=verb=stelle,valuePrefix=auf,values=rot:0;;grün:128;;blau:200\
Hue=verb=färbe,values=rot:0;;grün:120;;blau:220\
\
Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER\
Saturation=verb=sättige,values=AMAZON.NUMBER\
\
TargetPosition=verb=mach,articles=den;;die,values=auf:100;;zu:0\
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad\
\
Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
#Weckzeit=verb=stelle,valuePrefix=auf;;für,values=AMAZON.TIME,valueSuffix=uhr
attr alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
light=licht,lampen\
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
attr alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr alexa echoRooms #<deviceId>=<room>\

attr alexa fhemIntents #IntentName=<sample utterance>\
gutenMorgen=guten morgen\
guteNacht=gute nacht
attr alexa persons #<personId>=<name>\

attr alexa stateFormat alexaFHEM

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Muenzi am 15 Mai 2022, 23:00:32
Hallo zusammen,

ich wollte mich mal auf einem älteren Raspi 3 mit dem Thema Docker beschäftigen.

Das grundsätzliche Setup ist eigentlich klar (FHEM Base + MySQL/MariaDb + MQTT + div Python Services).

Ich frage mich aber wie ich am besten UART für mein HM-MOD-RPI-PCB (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi) aktiviere und dem FHEM Container zur Verfügung stelle.

Hat dazu jemand Erfahrungen? Am meisten interessiert mich falls das jmd. auf einem Libreelec System hinbekommen hat, aber das ist kein Muss.

Beste Dank!
Muenzi
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 15 Mai 2022, 23:22:04
Zitat von: LutzG am 15 Mai 2022, 21:43:11
ich habe das attr allowed_WEB basicAuth gelöscht, fhem / Container neugestartet, keine Änderung, erst nach dem ich attr WEB HTTPS 1 gelöscht hatte, hat alexa-fhem fhem gefunden.

Um HTTPs zwischen dem alexa-fhem und fhem container verwenden zu können muss in der alexa-fhem.cg der Connections Abschnitt um SSL ergänzt werden:
"connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "fhem",
      "ssl": true
    }


https://wiki.fhem.de/wiki/Alexa-Fhem#Wie_kann_ich_via_Alexa-FHEM_auf_FHEM_zugreifen.2C_wenn_der_Port_mit_Benutzername.2FKennwort_gesch.C3.BCtzt_ist.3F

Authentication Parameter können dort auch ergänzt werden, aber das erscheint mir fragwürdig, Benutzername und Kennwort in das configfile zu schreiben.
Der Zugriff auf FHEM ohne Passwort kann durch eine allowed Liste eingegrenzt werden.






Zitat von: Muenzi am 15 Mai 2022, 23:00:32
Ich frage mich aber wie ich am besten UART für mein HM-MOD-RPI-PCB (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi) aktiviere und dem FHEM Container zur Verfügung stelle.

Ich habe es über ser2net gemacht, wenn alles auf dem gleichen System läuft, kannst Du aber auch einfach den UART Port als device in dem container bereitstellen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Muenzi am 16 Mai 2022, 00:13:24
ZitatIch habe es über ser2net gemacht, wenn alles auf dem gleichen System läuft, kannst Du aber auch einfach den UART Port als device in dem container bereitstellen.

Guter Hinweis, schaue ich mir mal an. Kannst du eine Doku empfehlen? Ansonsten bemühe ich mal Google.

Oder vielleicht hat ja auch jmd bereits ein docker-compose fertig? Bin noch relativ unbefleckt mit Docker und habe es eher für Python-Microservices verwendet und nicht für "komplexe" Setups mit mehreren miteinander kommunizierenden Komponenten.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 16 Mai 2022, 01:27:39
Zitat von: Sidey am 15 Mai 2022, 23:22:04
Um HTTPs zwischen dem alexa-fhem und fhem container verwenden zu können muss in der alexa-fhem.cg der Connections Abschnitt um SSL ergänzt werden:
Hab ich gemacht, auch "auth": {"user": "fhem", "pass": "fhempassword"}, eingetragen, alexa-fhem findet / verbindet sich mir fhem.

Das alexa device hab ich gelöscht, fhem / fhem-alexa neu gestartet, alexa wieder definiert.
State von alexa-fhem ist immer noch: stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'. Die alexaFHEM.bearerToken crypt:... / alexaFHEM.skillRegKey crypt:... werden nicht erzeugt, ich bekomme keine Anmeldeseite...  :(

Du hattest die "alte" ? Anleitung verlinkt? Oder nur wegen der "~/.alexa/config.json"?
Zitat von: Sidey am 15 Mai 2022, 23:22:04
https://wiki.fhem.de/wiki/Alexa-Fhem#Wie_kann_ich_via_Alexa-FHEM_auf_FHEM_zugreifen.2C_wenn_der_Port_mit_Benutzername.2FKennwort_gesch.C3.BCtzt_ist.3F (https://wiki.fhem.de/wiki/Alexa-Fhem#Wie_kann_ich_via_Alexa-FHEM_auf_FHEM_zugreifen.2C_wenn_der_Port_mit_Benutzername.2FKennwort_gesch.C3.BCtzt_ist.3F)

Ich war der Meinung, die ist veraltet und es soll die genommen werden? https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa)

Zitat von: Sidey am 15 Mai 2022, 23:22:04
Der Zugriff auf FHEM ohne Passwort kann durch eine allowed Liste eingegrenzt werden.

Anmeldung wäre mir schon lieber. Die Enkel sind gern an den "allowed" Rechnern...  ::)

Ich glaub, an dieser Stelle gebe ich auf und verschiebe die alexa-Docker-Geschichte auf später...  :-[  Die SD-Karte mach ich noch nicht platt, falls es noch Fragen gibt.

Herzlichen Dank für deine Geduld und dein Engagement!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 16 Mai 2022, 07:19:22
Moin Sidey, ich übernehme gerne ;-)
Grundsätzlich habe ich ja das gleiche Problem und habe eure ganzen Versuche mal nachgestellt.
Ich bekomme es auch nicht zum Laufen.

Portainer, frisch eure docker-compose.yml genutzt mit fhem2 und alexa-fhem2.
alexa-fhem2 verbindet sich zwar mit fhem2, das sieht in den Logs gut aus.


[5/16/2022, 7:07:24 AM] this is alexa-fhem 0.5.61
[5/16/2022, 7:07:24 AM] connecting to FHEM ...
[5/16/2022, 7:07:24 AM] [FHEM] defaults to: will not send proactive events
[5/16/2022, 7:07:24 AM] [FHEM] trying longpoll to listen for fhem events
[5/16/2022, 7:07:24 AM] [FHEM] starting longpoll: http://fhem2:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1652677644623
[5/16/2022, 7:07:24 AM] Server listening on: http://:::3000 for direct connections
[5/16/2022, 7:07:24 AM] [FHEM] got csrfToken: csrf_224896489440355
[5/16/2022, 7:07:24 AM] [FHEM] Checking devices and attributes...
[5/16/2022, 7:07:24 AM] [FHEM]   executing: http://fhem2:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=csrf_224896489440355&XHR=1
[5/16/2022, 7:07:24 AM] [FHEM]   executing: http://fhem2:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=csrf_224896489440355&XHR=1
[5/16/2022, 7:07:24 AM] [FHEM] waiting for events ...
[5/16/2022, 7:07:24 AM] [FHEM] Fetching FHEM devices...
[5/16/2022, 7:07:24 AM] [FHEM] fetching: http://fhem2:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=csrf_224896489440355&XHR=1
[5/16/2022, 7:07:24 AM] [FHEM] alexa device is Alexa
[5/16/2022, 7:07:24 AM] [FHEM] Alexa will not send proactive events
[5/16/2022, 7:07:24 AM] [FHEM] Alexa uses ID: 6281dbbc-f33f-28b4-698d-8edf5808dee7d71e
[5/16/2022, 7:07:24 AM] [FHEM]   executing: http://fhem2:8083/fhem?cmd=%7B%24defs%7fs%...
[5/16/2022, 7:07:24 AM] [FHEM]   executing: http://fhem2:8083/fhem?cmd=%7B%24defs%7B%...
*** FHEM: connected
[5/16/2022, 7:07:24 AM] [FHEM] got: 0 results


Die Connection die Richtung funktioniert, nicht aber anders herum. Muss man am Alexa-Device noch was einstellen, damit der nicht lokal sucht sondern auf den anderen Container geht? Am Alexa-Device in FHEM steht nach wie vor stopped; alexa-fhem not installed. install with sudo npm install -g alexa-fhem?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 16 Mai 2022, 09:47:26
Zitat von: HansDampfHH am 16 Mai 2022, 07:19:22

Die Connection die Richtung funktioniert, nicht aber anders herum. Muss man am Alexa-Device noch was einstellen, damit der nicht lokal sucht sondern auf den anderen Container geht? Am Alexa-Device in FHEM steht nach wie vor stopped; alexa-fhem not installed. install with sudo npm install -g alexa-fhem?

Die Verbindung von FHEM zum Node Prozess braucht es nicht.
Dass alexa-fhem in einem Container läuft, davon weiss das FHEM Modul halt nicht und die Meldung dass es installiert werden soll kann ignoriert werden.
Geht in dieser Konstellation denn irgendwas nicht, was gebraucht wird?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 16 Mai 2022, 09:57:56
Ah, das war mir nicht bewusst. Das teste ich nachher mal. Ggf. funktioniert es also bereits. Da hat mich die Meldung wohl in die Irre geführt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 16 Mai 2022, 10:26:38
Ne, zu früh gefreut. Mit 'get Alexa proxyKey' tut sich nichts. Auch ein verbose 5 bringt nichts, da das Device scheinbar überhaupt nicht aktiv ist (active 0).
Da kommt auch nichts im fhem oder alexa-fhem Logfile.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Muenzi am 18 Mai 2022, 01:58:36
Hallo zusammen, winzige Frage:

Gibt es eine Möglichkeit per post-init.sh fhem zu updaten? Ich dachte an sowas wie
perl /opt/fhem/fhem.pl 7072 "update all",
aber dafür müsste fhem ja schon laufen.

Und wenn ich es starte per command starte ist es ja im Vordergrund lässt keine weiteren Eingaben zu.

Use Case: Der Umstieg auf configDB funktioniert leider nicht, da erst configdb geupdated werden muss. Sonst beschwert sich fhem beim nächsten Start über eine fehlende Tabelle in der Datenbank.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 18 Mai 2022, 07:30:13
Zitat von: HansDampfHH am 16 Mai 2022, 10:26:38
Ne, zu früh gefreut. Mit 'get Alexa proxyKey' tut sich nichts.

Stimmt, ich kann das Verhalten so nachstellen.
Ich bleibe dran und finde heraus wie das funktioniert.

Zitat von: Muenzi am 18 Mai 2022, 01:58:36
Gibt es eine Möglichkeit per post-init.sh fhem zu updaten?
Im Moment funktioniert das nicht so einfach.
Es dürfte auch eher ein seltener Fall sein den Du beschreibst, denn das Image hat eine durchaus aktuelle FHEM Revision mit dabei und in den letzten Tagen habe ich keine Änderung hinsichtlich configdb gefunden.

Wenn Du den Container mit einem leeren FHEM vz. startest, wird die im Image enthaltene Revision verwendet. Dann hast Du ein FHEM mit Standard Konfig und kannst deine eigene Konfiguration manuell wieder in FHEM hinterlegen.
Alternativ startest Du FHEM temporär mit einer fhem.cfg und führst den Update Befehl aus.

Es sollte auch klappen, wenn Du den Update Befehl in die fhem.cfg schreibst mit der fhem gestartet wird.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: andreas.maurer am 20 Mai 2022, 07:43:44
Guten Morgen,

diese Nacht hat watchtower eine neues fhem image gezogen und installiert. Soweit so gut.

Allerdings ist die Firmata Unterstützung abhanden gekommen.
ZitatPerl module Device::Firmata not found, see Commandref for details how to fix

Ist das so geplant? Wie bekomme ich die wieder zurück?

Würde ungerne wieder von docker weg. Da funktioniert seit langen sehr gut.

Andreas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 20 Mai 2022, 08:34:01
Zitat von: andreas.maurer am 20 Mai 2022, 07:43:44
Allerdings ist die Firmata Unterstützung abhanden gekommen.
Ist das so geplant? Wie bekomme ich die wieder zurück?

Geplant war das nicht, dass latest aktualisiert wird. Ist jetzt halt passiert.

Bezüglich Firmata bin ich zwei Jahre zurück und habe auch damals keine Firmata CPAN Pakete im Image gefunden.

Du kannst das Paket unkompliziert über eine Umgebungsvariable beim Starten des Containers nachinstallieren :

-e CPAN_PKGS="Device::Firmata"

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Muenzi am 27 Mai 2022, 03:35:38
Zitat von: Sidey am 18 Mai 2022, 07:30:13
Es sollte auch klappen, wenn Du den Update Befehl in die fhem.cfg schreibst mit der fhem gestartet wird.

Super, sorry es hat ein wenig gedauert bis ich wieder Zeit dafür hatte.

Hat aber alles geklappt.

Als kleine "Gedächtnisstütze" habe ich zu meinem Setup mal ein Github-Repo aufgemacht. Vielleicht interessiert es ja jemanden, der sich auch erst in Docker einarbeiten muss. Oder ein Pro wie Sidey oder die anderen hier gibt Good-Practice Tipps.

https://github.com/StephanMuenzberg/fhem_docker
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 27 Mai 2022, 08:06:03
Zitatexpose:
        - "3306"
        - "33060"
    ports:
        - "3306:3306"
        - "33060:33060"
Warum gibst Du Deine MariaDB nach außen frei?  Sie muß doch nur von FHEM und Grafana erreicht werden können und das ist durch das Docker-Netzwerk doch schon möglich.

Hinweis:
Alles was nicht von Außen (Aus Docker Sicht) erreicht werden kann, kann nicht mißbraucht werden.

Und warum hast DU eine docker-compose im Repro?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Muenzi am 28 Mai 2022, 12:04:52
Hallo Wernieman,

das sind sehr gute Fragen.

Zitat von: Wernieman am 27 Mai 2022, 08:06:03
Warum gibst Du Deine MariaDB nach außen frei?  Sie muß doch nur von FHEM und Grafana erreicht werden können und das ist durch das Docker-Netzwerk doch schon möglich.

Hinweis:
Alles was nicht von Außen (Aus Docker Sicht) erreicht werden kann, kann nicht mißbraucht werden.

Aktuell entwickle ich noch am lebenden Herzen, habe also keine separaten Entwicklungs- und Produktivinstanzen. Das heißt, ich muss mich für die Entwicklung (v.a. Normalisierung der History Tabelle, Views usw., siehe Ordner fhem/config/init/sql/) an der DB irgendwie auf die MariaDB draufschalten. Natürlich geht das direkt über eine interaktive Docker-Session, aber dann würde alles über die CLI laufen und das wäre dann doch etwas unhandlich.

Ich gebe dir aber vollkommen Recht. In einem produktiven System sollten die Port-Freigaben abgeschaltet sein.

Zitat von: Wernieman am 27 Mai 2022, 08:06:03
Und warum hast DU eine docker-compose im Repro?

Das hat "historische" Gründe. Ich habe ewig gebraucht um eine brauchbare Docker-Compose für mein Raspi-Setup zu finden, die auch funktioniert hat. Damit ich die bei einem Datenverlust nicht wieder verliere habe ich sie drin gelassen. Aber es stimmt, eigentlich kann die raus, zumal ich mittlerweile auf docker-compose aus pypy umgestellt habe.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 31 Mai 2022, 21:47:34
Ich will mal vorsichtig vor einem unvorbereiteten Image Update warnen.
Auf Docker Hub gibt es offenbar seit 14 Tagen ein neues FHEM Image, das endet bei mir in einer Endlosschleife beim Start. Ich werde das noch näher untersuchen.

Der schnelle Weg zurück:
docker image ls
...
docker tag ImageIdDesNeuen-latest-Image fhem/fhem:newest
docker tag ImageIdDesAlten-<none>-Image fhem/fhem:latest
docker compose up -d


BTW: auch das neue deconzcommunity/deconz Image läuft bei nicht...

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 31 Mai 2022, 22:14:17
Zitat von: Otto123 am 31 Mai 2022, 21:47:34

Auf Docker Hub gibt es offenbar seit 14 Tagen ein neues FHEM Image, das endet bei mir in einer Endlosschleife beim Start. Ich werde das noch näher untersuchen.

Ja, das ist so passiert weil latest quasi immer das neueste ist.
Welche Docker Version verwendest Du auf dem Host? Ggf. ein Debian Stretch?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 31 Mai 2022, 22:28:08
System: PRETTY_NAME="Debian GNU/Linux 10 (buster)"
Docker: Server: Docker Engine - Community Engine:   Version:          20.10.14

ZitatJa, das ist so passiert weil latest quasi immer das neueste ist.
Die Begründung verstehe ich nicht ;) ein neues Image sollte ja nicht zwangsweise zum Funktionsverlust führen :)
Du meinst das neue Image ist bullseye und läuft nicht auf einem Buster Host? 🤔
Ich denke, ich habe andere bullseye Images auf Buster Host getestet...

Aber wie gesagt: ich schaue es mir noch in Ruhe an.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 31 Mai 2022, 23:19:02
Zitat von: Otto123 am 31 Mai 2022, 22:28:08

Die Begründung verstehe ich nicht ;) ein neues Image sollte ja nicht zwangsweise zum Funktionsverlust führen :)
Das war nicht die Begründung für den Funktionsverlust, sondern eher, dass latest beim letzten deployment mit aktualisiert wurde.

Zitat von: Otto123 am 31 Mai 2022, 22:28:08
Du meinst das neue Image ist bullseye und läuft nicht auf einem Buster Host? 🤔
Ich denke, ich habe andere bullseye Images auf Buster Host getestet...

Es gab da ein Problem mit einer alten Docker Engine und Images basierend auf Bullseye.
Leider habe ich es auf die schnelle nicht gefunden. Soweit ich mich erinnere war auf raspbian Strecke die docker engine zu alt für das bullseye Image . Da kam es auch immer zu reboots.
War halt eine Idee, dass es daran liegt.


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 Juni 2022, 22:46:20
Zitat von: Otto123 am 31 Mai 2022, 22:28:08
System: PRETTY_NAME="Debian GNU/Linux 10 (buster)"
Aber wie gesagt: ich schaue es mir noch in Ruhe an.

Ich habe auf einem amd64 System das fhem/fhem:latest problemlos gestartet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 Juni 2022, 22:54:20
Ich habe ja nicht gesagt, dass es generell nicht läuft. Aber wenn man in einer bestehenden Installation das Image neu zieht (altes Image war das alte von Julian) gibt es offenbar Inkompatibilitäten. Ich kenne einen weiteren Fall wo es so passiert ist...

Ich wollte lediglich
Zitat... mal vorsichtig vor einem unvorbereiteten Image Update warnen.
:D
Oder sagt man dazu anders wenn man ein aktuelleres Docker Image zieht und anwendet?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 Juni 2022, 22:56:01
Zitat von: Otto123 am 01 Juni 2022, 22:54:20
Ich wollte lediglich  :D
Oder sagt man dazu anders wenn man ein aktuelleres Docker Image zieht und anwendet?

Passt, die Warnung ist ja durchaus auch in Ordnung. Ich konnte den Fehler nur leider nicht nachstellen. Wenn Du weitere Erkenntnisse hast, dann her damit.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: GammaTwin am 02 Juni 2022, 09:48:14
Grüße,

es gibt auch ein "latest" buster-image:
fhem/fhem:buster
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 28 Juni 2022, 19:44:29
Ich hab festgestellt, dass wenn ich im WEB Device statt global eine bestimmte IP angebe, damit Fhem nur noch über diese IP erreichbar sein soll, der Health Status des Image nach kurzer Zeit auf unhealthy wechselt. Ich habe schon versucht DOCKER_HOST auf die entsprechende IP zu setzten. Gibt es einen anderen Weg, das selbe Ziel zu erreichen, wenn der Container im Host Modus laufen muss?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 28 Juni 2022, 21:27:06
Zitat von: kennymc.c am 28 Juni 2022, 19:44:29
Ich hab festgestellt, dass wenn ich im WEB Device statt global eine bestimmte IP angebe, damit Fhem nur noch über diese IP erreichbar sein soll, der Health Status des Image nach kurzer Zeit auf unhealthy wechselt.

Der Healthcheck läuft innerhalb des Containers gegen localhost.
Dieser Zugriff muss erlaubt sein.

Ich verstehe aber eventuell nicht exakt, was Du gemacht hast, also welche Attribut Du gesetzt hast.
Mich würde ebenso interessieren, was genau Du erreichen möchtest.


Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 29 Juni 2022, 19:40:38
Ich möchte wie erwähnt, dass Fhem nur über ein Netzwerk Interface erreichbar ist, da mein Server mehrere NICs besitzt und Fhem momentan über alle erreichbar ist.
Momentan ist das WEB Device so definiert:
WEB FHEMWEB 8083 global
Wenn ich es auf WEB FHEMWEB 8083 192.168.1.203 ändere bekomme ich das genannte Problem mit dem Health Check.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 29 Juni 2022, 22:33:03
Zitat von: kennymc.c am 29 Juni 2022, 19:40:38
Ich möchte wie erwähnt, dass Fhem nur über ein Netzwerk Interface erreichbar ist, da mein Server mehrere NICs besitzt und Fhem momentan über alle erreichbar ist.

Bevor wir uns hier missverstehen.
Hat der Host mehrere Netzwerkkarten oder der Container?

Momentan ist das WEB Device so definiert:
WEB FHEMWEB 8083 global
Wenn ich es auf WEB FHEMWEB 8083 192.168.1.203 ändere bekomme ich das genannte Problem mit dem Health Check.
[/quote]

Ist 192.168.1.203 die Adresse des Hosts oder des Containers?
Meist laufen die Adressen der Container in anderen Subnetzen als 192.168., daher die Nachfrage.


Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 29 Juni 2022, 23:05:51
Der Host hat mehrere Interfaces und der Container läuft auch im Host Mode also sollte auch kein Subnet für diesen Container existieren. 192.168.1.203 ist eine zugewiesene IP vom Router für eines der Interfaces.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 29 Juni 2022, 23:09:28
Zitat von: kennymc.c am 29 Juni 2022, 23:05:51
Der Host hat mehrere Interfaces und der Container läuft auch im Host Mode also sollte auch kein Subnet für diesen Container existieren. 192.168.1.203 ist eine zugewiesene IP vom Router für eines der Interfaces.


Okay verstehe.
Also es geht nicht, weil der Healthcheck versucht mit localhost zu verbinden, das aber nicht erlaubt ist:

https://github.com/fhem/fhem-docker/blob/890aff9e85cbaf3cc406c7b7979baa58f9d072c8/src/health-check.sh#L47


Wenn Du eine weitere Webdefinition erstellst und diese auf localhost bindest, sollte es gehen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 30 Juni 2022, 20:20:13
Ich hab jetzt ein neues WEB Device für Port 8085 erstellt und statt global localhost angegeben. Allerdings bleibt der Health Status trotzdem auf unhealthy. Muss ich den Port noch irgendwo angeben oder wird immer Port 8083 dafür genutzt und ich muss meinen Hauptport ändern? Auf dem Server und im Container kann ich auf Fhem via Port 8085 zugreifen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 30 Juni 2022, 20:34:26
Zitat von: kennymc.c am 30 Juni 2022, 20:20:13
Ich hab jetzt ein neues WEB Device für Port 8085 erstellt und statt global localhost angegeben.

Laut Commander muss dort eine IP Adresse angegeben werden.
In deinem Fall wäre das 127.0.0.1

Der Healthcheck findet den konfigurierten Port automatisch.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 01 Juli 2022, 19:09:22
Leider auch mit 127.0.0.1 statt localhost das selbe Problem
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 10 Juli 2022, 22:34:57
Zitat von: kennymc.c am 01 Juli 2022, 19:09:22
Leider auch mit 127.0.0.1 statt localhost das selbe Problem

Ich habe das nachgestellt und konnte keinen Fehler finden.

Ich brauche dafür wohl mehr Details.

Kannst Du deine fhem.cfg und deine docker-compose Datei bereitstellen?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 16 Juli 2022, 15:29:18
Docker läuft bei mir über Unraid. Der Befehl zum Starten des Containers ist:

/usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker create --name='fhem' --net='host' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e HOST_HOSTNAME="smartserver" -e HOST_CONTAINERNAME="fhem" -e 'CPAN_PKGS'='IO::Socket::SSL IO::Socket::Multicast XML::Simple Data::Peek Net::FTPSSL' -e 'LOGFILE'='./log/fhem-%Y-%m.log' -e 'FHEM_UID'='1007' -e 'FHEM_GID'='100' -e 'DOCKER_HOST'='192.168.1.203' -l net.unraid.docker.managed=dockerman -v '/mnt/user/appdata/fhem/':'/opt/fhem':'rw' --restart always --name fhem 'ghcr.io/fhem/fhem/fhem-minimal-docker:bullseye'


Die fhem.cfg ist im Anhang
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: elle am 03 August 2022, 14:44:52
Hallo zusammen,

um ein wenig Strom zu sparen, bin ich gerade dabei, meinen zentralen Server, auf dem u.a. FHEM derzeit als LXC Container laeuft, auf einen Raspi4 mit dietpi (Debian bullseye) als HostOS umzuziehen.

Dabei moechte ich u.a. FHEM als docker Container betreiben, aber habe mit dem /opt/fhem Volume ein seltsames Problem, das ich mir nicht erklaeren kann.

docker volume create fhem
docker run -d --name FHEM -p 8083:8083 -p 7072:7072 -p 8084:8084 -v fhem:/opt/fhem fhem /fhem:bullseye --restart unless-stopped
Das Teil laeuft und ist auch aus meinem LAN problemlos erreichbar:

root@heart:~# docker ps                                                                                                                                     
CONTAINER ID   IMAGE                          COMMAND                  CREATED          STATUS                    PORTS                                     
                                                                                                                                      NAMES                 
15c95a2422f6   fhem/fhem:bullseye             "/entry.sh start"        16 minutes ago   Up 16 minutes (healthy)   0.0.0.0:7072->7072/tcp, :::7072->7072/tcp,
0.0.0.0:8083-8084->8083-8084/tcp, :::8083-8084->8083-8084/tcp                                                                         FHEM                   


Um nun einige Customdateien aus meinem laufenden FHEM zu nutzen, habe ich sie in das Volumeverzeichnis auf dem Host kopiert, z.B.:

root@heart:~# rsync -av shc:/opt/fhem/FHEM/99_myUtils* /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM
root@heart:~# chown -R 6061:6061  /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM/99_myUtils* && ls -ltr /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM/99_myUtils*
-rw-r----- 1 6061 6061  11769 Feb  5 14:25 /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM/99_myUtils_IAC.pm.orig
-rw-r----- 1 6061 6061  15452 Apr 22 10:54 /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM/99_myUtils.pm
-rw-r----- 1 6061 6061  12572 Apr 28 22:07 /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM/99_myUtils_IAC.pm
-rw-r----- 1 6061 6061 151582 Jul 18 13:01 /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM/99_myUtils_Shutter.pm


Gehe ich mit

docker exec -it FHEM /bin/bash

in den Container hinein und liste mir die Dateien in /opt/fhem/FHEM, sehe ich die Dateien auch:

root@15c95a2422f6:/opt/fhem# ls -ltr FHEM/99_my*
-rw-r----- 1 fhem fhem  11769 Feb  5 14:25 FHEM/99_myUtils_IAC.pm.orig
-rw-r----- 1 fhem fhem  15452 Apr 22 10:54 FHEM/99_myUtils.pm
-rw-r----- 1 fhem fhem  12572 Apr 28 22:07 FHEM/99_myUtils_IAC.pm
-rw-r----- 1 fhem fhem 151582 Jul 18 13:01 FHEM/99_myUtils_Shutter.pm

Aber FHEM sieht sie nicht mit Eingabe von z.B.

reload 99_myUtils

oder

{`ls -ltr /opt/fhem/FHEM`}


Hat jemand eine Idee (vielleicht war das ja schon Thema in diesem Thread, aber bei 100+ Seiten koennte ich das uebersehen haben), woran das liegen koennte?!

Ich bin ratlos, allerdings auch noch nicht so in docker bewandert - Linux ist kein Problem fuer mich ...

Gruss
/elle
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 03 August 2022, 21:18:06
Zitat von: elle am 03 August 2022, 14:44:52
Hat jemand eine Idee (vielleicht war das ja schon Thema in diesem Thread, aber bei 100+ Seiten koennte ich das uebersehen haben), woran das liegen koennte?!


Ich selbe nutze kein docker run sondern docker-compose. Darum kann es sein dass mein Vorschlag nichts bringt.

Teste mal
1) Ohne ein eigenes volume sondern nur -v /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM:/opt/fhem (oder halt den persistenen Ordner mit deinen Daten)
2) welches Image ist das, sollte es nicht "docker ..... pull fhem/fhem:bullseye .... heißen? Du hast in deinem List ein Leerzeichen drin.


docker run -d --name FHEM -p 8083:8083 -p 7072:7072 -p 8084:8084 -v <vollständiger Pfad>/fhem:/opt/fhem pull fhem/fhem:bullseye --restart unless-stopped


Beim ersten Starten (erzeugen des Containers) von Fhem werden die Rechte gesetzt. Ich könnte mir vorstellen, dass hier bei deinen Schritten <Volume erstellen> - Rsync - Container starten ... Berechtigungen erneut gesetzt oder verbogen werden. Teste mal mit dem "nackten" docker run ob du  die Files siehst und ob du mit der demo-Config starten kannst. Erst dann würde ich mit dem reinkopieren deiner alten Installation beginnen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: elle am 03 August 2022, 21:59:23
Hi kadettilac89,

Zitat von: kadettilac89 am 03 August 2022, 21:18:06
Teste mal
1) Ohne ein eigenes volume sondern nur -v /mnt/dietpi_userdata/docker-data/volumes/fhem/_data/FHEM:/opt/fhem (oder halt den persistenen Ordner mit deinen Daten)
Das scheint tatsaechlich den Unterschied zu machen - ich werd' bekloppt... :o
Zitat
2) welches Image ist das, sollte es nicht "docker ..... pull fhem/fhem:bullseye .... heißen? Du hast in deinem List ein Leerzeichen drin.
Da scheint wohl beim Kopieren die Forensoftware ein Leerzeichen gekauft zu haben - im Originalaufruf ist das nicht mit drin ...

docker run -d --name FHEM -p 8083:8083 -p 7072:7072 -p 8084:8084 -v <vollständiger Pfad>/fhem:/opt/fhem pull fhem/fhem:bullseye --restart unless-stopped

So geht es tatsaechlich!
Zitat
Beim ersten Starten (erzeugen des Containers) von Fhem werden die Rechte gesetzt. Ich könnte mir vorstellen, dass hier bei deinen Schritten <Volume erstellen> - Rsync - Container starten ... Berechtigungen erneut gesetzt oder verbogen werden. Teste mal mit dem "nackten" docker run ob du  die Files siehst und ob du mit der demo-Config starten kannst. Erst dann würde ich mit dem reinkopieren deiner alten Installation beginnen.
Einfach reinkopieren werde ich nicht, sondern die Gelegenheit nutzen, aufzuraeumen und einiges zu optimieren. Da ist einiges doch mittlerweile recht wild gewachsen und bedarf einer Ueberarbeitung ... ;-)

Ausserdem aendert sich an anderen Stellen im System einiges, dass auch Einfluss auf FHEM hat - wie z.B., dass ich nicht mehr Unifi Video nutze (gibt es nicht fuer arm), sondern auf motioneye wechsele ...

Auf jeden Fall nochmal danke fuer den Schubser - auch wenn mir noch nicht so ganz klar ist, warum docker da nicht direkt auf das durch das Volume definierte Verzeichnis zugreift und vor allem im Filesystem des Containers alles richtig zu sein scheint - nur fhem.pl etwas voellig anderes sieht (wo auch immer das liegen mag) - verstehen wuerde ich es schon ganz gerne ...

Dann kann es ja morgen weitergehen - erst mal weiter mit ein bisschen Rose das Hirn fuer neue Schandtaten kuehlen  :)

/elle
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MichaelS am 19 August 2022, 19:52:38
Hallo allerseits,
ich schreibe jetzt auch mal rein da mein funktionierender Alexaskill nicht mehr will, seit dem update, und ich schon ewig an der Reaktivierung sitze.

(Habe den PI geupdatet und sonst alle container als "latest" -> Aktuellste Versionen parat)

Ich nutze docker-compose und damit die Beschreibung/Images von: https://github.com/fhem/alexa-fhem-docker.
Die container wurden alle gebaut, wobei ich direkt beim prüfen des "alexa-fhem"'s (MEINE_FHEM_IP:3000/) so etwas sehe:
{"header":{"namespace":"Alexa.ConnectedHome.Control","name":"UnsupportedOperationError","payloadVersion":"2","messageId":"04a3ee4d-b969-4489-9a74-d19c47d61eda"},"payload":{}}

1.) Könnte der Fehler dort bereits liegen?

In der FHEM-Weboberfläche habe ich den skill removed und neu aufgespielt.
Komisch ist dann bereits, dass alexaFHEM.ProxyConnection nicht bei den Readings erscheint... (der war vorher ja da und sollte dort immer erscheinen (?))

Den host habe ich natürlich auch im skill verknüpft ("attr Alexa alexaFHEM-host alexa-fhem"). Außerdem meine login credentials ("attr alexa alexaFHEM-auth user:pass")

Die alexa logs zeigen mir:
Unknown cipher type '/tmp/alexa-fhem.cfg'
in einer Endlosschleife.

Im logfile sehe ich das kein Zugriff auf den port 22 möglich ist:
2022.08.19 19:47:21.031 3: alexa: using ssh cmd /usr/bin/ssh alexa-fhem
ssh: connect to host alexa-fhem port 22: Connection refused
ssh: connect to host alexa-fhem port 22: Connection refused
2022.08.19 19:47:21.130 2: alexa: starting alexa-fhem: /usr/bin/ssh alexa-fhem  -c /tmp/alexa-fhem.cfg
2022.08.19 19:47:21.137 3: alexa: starting
2022.08.19 19:47:21.150 3: alexa: using logfile: ./log/alexa-2022-08-19.log
2022.08.19 19:47:21.164 3: alexa: read: end of file reached while sysread
2022.08.19 19:47:21.164 3: alexa: stopped


Ich denke das sollte euch für einen ersten Einblick reichen. Freue mich auf professionelle Hilfe :)

Grüße Michael
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 19 August 2022, 20:13:15
Zitat von: MichaelS am 19 August 2022, 19:52:38
Hallo allerseits,
ich schreibe jetzt auch mal rein da mein funktionierender Alexaskill nicht mehr will, seit dem update, und ich schon ewig an der Reaktivierung sitze.


Was steht denn im logfile von dem alexa-fhem-container?
Könntest ja auch mal das configfile posten, welches im alexa-fhem Container liegt.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MichaelS am 20 August 2022, 07:17:01
ZitatWas steht denn im logfile von dem alexa-fhem-container?

[8/19/2022, 7:37:51 PM] ERROR: SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Server.processBody (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:327:26)
    at Server.<anonymous> (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:338:33)
    at IncomingMessage.emit (events.js:412:35)
    at endReadableNT (internal/streams/readable.js:1333:12
    at processTicksAndRejections (internal/process/task_queues.js:82:21) from ::ffff:172.27.0.1
[8/19/2022, 7:37:51 PM] <<<< [srv] {"header":{"namespace":"Alexa.ConnectedHome.Control","name":"UnsupportedOperationError","payloadVersion":"2","messageId":"04a3ee4d-b969-4489-9a74-d19c47d61eda"},"payload":{}}


mein config file sieht so aus:

{
  "alexa": {
    "port": 3000,
    "name": "Alexa",
    "ssl": false,
    "keyFile": "/certs/alexa-fhem.key",
    "certFile": "/certs/alexa-fhem.crt",
    "nat-pmp": "",
    "nat-upnp": false,
    "applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXX$
  },
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "fhem"
    }
  ]
}


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 August 2022, 11:43:52
Zitat von: MichaelS am 20 August 2022, 07:17:01
[8/19/2022, 7:37:51 PM] ERROR: SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Server.processBody (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:327:26)
    at Server.<anonymous> (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:338:33)
    at IncomingMessage.emit (events.js:412:35)
    at endReadableNT (internal/streams/readable.js:1333:12
    at processTicksAndRejections (internal/process/task_queues.js:82:21) from ::ffff:172.27.0.1
[8/19/2022, 7:37:51 PM] <<<< [srv] {"header":{"namespace":"Alexa.ConnectedHome.Control","name":"UnsupportedOperationError","payloadVersion":"2","messageId":"04a3ee4d-b969-4489-9a74-d19c47d61eda"},"payload":{}}



Kannst Du das Log vom Containerstart bis zu den Fehlern posten?
Mit dem Ausschnitt kann ich zumindest nichts anfangen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MichaelS am 21 August 2022, 12:39:27
Klar, habe den container noch mal neu gebaut und meine ganzen device logs entfernt:

Preparing user environment ...,
  - Creating symlink to config.json in /alexa-fhem/.alexa/config.json ...,
,
,
,
Starting alexa-fhem ...,
[8/21/2022, 12:27:11 PM] os.homedir()=/alexa-fhem,
[8/21/2022, 12:27:11 PM] using config from /alexa-fhem/.alexa/config.json,
*** CONFIG: parsed completely,
[8/21/2022, 12:27:11 PM] this is alexa-fhem 0.5.62,
[8/21/2022, 12:27:11 PM] connecting to FHEM ...,
[8/21/2022, 12:27:11 PM] [FHEM] defaults to: will not send proactive events,
[8/21/2022, 12:27:12 PM] [FHEM] trying longpoll to listen for fhem events,
[8/21/2022, 12:27:12 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1661077632386,
[8/21/2022, 12:27:12 PM] Server listening on: http://:::3000 for direct connections,
[8/21/2022, 12:27:12 PM] [FHEM] got csrfToken: ,
[8/21/2022, 12:27:12 PM] [FHEM] Checking devices and attributes...,
[8/21/2022, 12:27:12 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&XHR=1,
[8/21/2022, 12:27:12 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&XHR=1,
[8/21/2022, 12:27:12 PM] [FHEM] waiting for events ...,
[8/21/2022, 12:27:12 PM] [FHEM] Fetching FHEM devices...,
[8/21/2022, 12:27:12 PM] [FHEM] fetching: http://fhem:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&XHR=1,
[8/21/2022, 12:27:12 PM] [FHEM] alexa device is alexa,
[8/21/2022, 12:27:12 PM] [FHEM] alexa will not send proactive events,
[8/21/2022, 12:27:12 PM] [FHEM] alexa uses ID: 62ffc750-f33f-3e71-971d-a137bb8a17b8f946,
[8/21/2022, 12:27:12 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22alexa-fhem%20version%22%7D%20%3D%20%220.5.62%22%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&XHR=1,
[8/21/2022, 12:27:12 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Blist%20alexa%20.eventToken%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&XHR=1,
*** FHEM: connected,
[8/21/2022, 12:27:12 PM] [FHEM] got: 17 results,
...


Dabei kommen die Logs hinzu, wenn ich meinen server mit dem port 3000 im browser aufrufe:
Zitat[8/19/2022, 7:37:51 PM] ERROR: SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Server.processBody (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:327:26)
    at Server.<anonymous> (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:338:33)
    at IncomingMessage.emit (events.js:412:35)
    at endReadableNT (internal/streams/readable.js:1333:12
    at processTicksAndRejections (internal/process/task_queues.js:82:21) from ::ffff:172.27.0.1
[8/19/2022, 7:37:51 PM] <<<< [srv] {"header":{"namespace":"Alexa.ConnectedHome.Control","name":"UnsupportedOperationError","payloadVersion":"2","messageId":"04a3ee4d-b969-4489-9a74-d19c47d61eda"},"payload":{}}

Persönlich sehe ich jetzt nichts...:/

Grüße
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 August 2022, 20:07:50
Zitat von: MichaelS am 21 August 2022, 12:39:27
Klar, habe den container noch mal neu gebaut und meine ganzen device logs entfernt:

Welche device Logs?
Bei mir kommen da noch Informationen zur Proxy Verbindung zum Vereinsserver.
Die fehlen hier.

Zitat von: MichaelS am 21 August 2022, 12:39:27
Dabei kommen die Logs hinzu, wenn ich meinen server mit dem port 3000 im browser aufrufe: 

Das ist kein Fehler, wenn Du nicht den passenden Payload mitgesendet hast.

Hast Du den Skill bei Amazon denn neu verbunden/ eingerichtet?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MichaelS am 21 August 2022, 21:23:01
ZitatBei mir kommen da noch Informationen zur Proxy Verbindung zum Vereinsserver.
Bei mir kommt nichts mehr.

Kann den Skill nicht einrichten:

Checking your key:
Status ActivationKey: Good Key
Checking connection status:
Status SSH: NOT online - no SSH session established
Status Reverse-Portmapping: -
Status nodejs-Connectivity: -
Status nodejs-Interaction: -

Naja, meine alten devices scheint er zu erkennen. Die logs habe ich entfernt:

z.B:
[8/21/2022, 9:18:46 PM] [FHEM] az_heizung1 has
[8/21/2022, 9:18:46 PM] [FHEM]   StatusLowBattery [battery]
[8/21/2022, 9:18:46 PM] [FHEM]   FirmwareRevision [firmware]
[8/21/2022, 9:18:46 PM] [FHEM]   TargetTemperature [desiredTemperature]
[8/21/2022, 9:18:46 PM] [FHEM]   TargetHeatingCoolingState [mode]
[8/21/2022, 9:18:46 PM] [FHEM]   CurrentHeatingCoolingState [undefined]


Ggf. hier noch mein compose file:

version: '2'
networks:
  fhem_net:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/28
          gateway: 172.27.0.1
        - subnet: fd00:0:0:0:27::/80
          gateway: fd00:0:0:0:27::1
services:
  fhem:
    networks:
      - default
      - fhem_net
    image: fhem/fhem:bullseye
    restart: always
    privileged: true
    ports:
      - "7072:7072"
      - "1883:1883"
      - "8083:8083"
      - "8087:8087"
    volumes:
      - "./fhem:/opt/fhem/"
    devices:
      - /dev/ttyAMA0
    environment:
      TZ: Europe/Berlin
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:2
    restart: always
    networks:
     - fhem_net
    ports:
      - "3000:3000"
    volumes:
      - "./alexa-fhem/:/alexa-fhem/"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Berlin


Vielleicht ist hie was im Braten...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: chrizza87 am 12 September 2022, 21:23:13
Zitat von: MichaelS am 20 August 2022, 07:17:01
[8/19/2022, 7:37:51 PM] ERROR: SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Server.processBody (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:327:26)
    at Server.<anonymous> (/usr/local/lib/node_modules/alexa-fhem/lib/server.js:338:33)
    at IncomingMessage.emit (events.js:412:35)
    at endReadableNT (internal/streams/readable.js:1333:12
    at processTicksAndRejections (internal/process/task_queues.js:82:21) from ::ffff:172.27.0.1
[8/19/2022, 7:37:51 PM] <<<< [srv] {"header":{"namespace":"Alexa.ConnectedHome.Control","name":"UnsupportedOperationError","payloadVersion":"2","messageId":"04a3ee4d-b969-4489-9a74-d19c47d61eda"},"payload":{}}


mein config file sieht so aus:

{
  "alexa": {
    "port": 3000,
    "name": "Alexa",
    "ssl": false,
    "keyFile": "/certs/alexa-fhem.key",
    "certFile": "/certs/alexa-fhem.crt",
    "nat-pmp": "",
    "nat-upnp": false,
    "applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXX$
  },
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "fhem"
    }
  ]
}


Späte Antwort, aber:

Dein JSON (config datei) ist nicht korrekt:
Zeile:
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXX$ <- das schließendete Anführungszeichen ( " ) fehlt

Oder nur beim "schwärzen" der ID passiert?

@Sidey:
Gibt es schon neue Erkenntnisse bzgl. Alexa-Fhem im seperaten Container und Vereinsserver connect über das alexa modul?

Dank dir schonmal im Voraus
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 12 September 2022, 22:27:15
Zitat von: chrizza87 am 12 September 2022, 21:23:13

@Sidey:
Gibt es schon neue Erkenntnisse bzgl. Alexa-Fhem im seperaten Container und Vereinsserver connect über das alexa modul?

Dank dir schonmal im Voraus

Was meinst Du mit Erkenntnissen.
Läuft bei mir seit Jahren problemlos :)

Was den beschriebenen Fehler von MichaelS angeht, fällt es mir schwierig, da im Log nichts zum connect zum Vereinsserver steht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: chrizza87 am 12 September 2022, 23:00:04
Zitat von: Sidey am 12 September 2022, 22:27:15
Was meinst Du mit Erkenntnissen.
Läuft bei mir seit Jahren problemlos :)

Was den beschriebenen Fehler von MichaelS angeht, fällt es mir schwierig, da im Log nichts zum connect zum Vereinsserver steht.

Danke für die schnelle Rückmeldung erstmal :-)

Okay. Ich hatte es so verstanden, dass das Scenario.
- Docker Instanz Fhem
- Extra Docker Instanz Alexa-Fhem
---Connect zu Vereinsserver über Docker Instanz Fhem mit Alexa Modul

generell nicht klappt, wie bei MichaelS. Ich habe zumindest das gleiche Problem. Habe seit etlichen Jahren die manuelle AWS Variante im Einsatz. Wollte für meine Eltern (Wohnen im gleichen Haus) dann einfach den "leichteren" Weg über den offiziellen Fhem Skill für ihre Geräte gehen, damit sie über ihre Alexa Devices verwendbar sind und sie nicht meine Geräte steuern können (und natürlich umgekehrt :) )
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 13 September 2022, 06:53:47
Zitat von: chrizza87 am 12 September 2022, 23:00:04

- Extra Docker Instanz Alexa-Fhem

Kannst Du das komplette Logfile und deine Konfig ab Start des containers dieser Instanz schicken ich kann dann ja mal mit meinem vergleichen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: chrizza87 am 13 September 2022, 16:58:48
Zitat von: Sidey am 13 September 2022, 06:53:47
Kannst Du das komplette Logfile und deine Konfig ab Start des containers dieser Instanz schicken ich kann dann ja mal mit meinem vergleichen.

hier mal das logfile vom alexa-fhem container:

Preparing user environment ...

  - Creating symlink to config.json in /alexa-fhem/.alexa/config.json ...

Starting alexa-fhem ...

[9/13/2022, 4:55:52 PM] os.homedir()=/alexa-fhem

[9/13/2022, 4:55:52 PM] using config from /alexa-fhem/.alexa/config.json

*** CONFIG: parsed completely

[9/13/2022, 4:55:52 PM] this is alexa-fhem 0.5.64

[9/13/2022, 4:55:52 PM] connecting to FHEM ...

[9/13/2022, 4:55:52 PM] [FHEM] defaults to: will not send proactive events

[9/13/2022, 4:55:52 PM] [FHEM] trying longpoll to listen for fhem events

[9/13/2022, 4:55:52 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1663080952364

[9/13/2022, 4:55:52 PM] Server listening on: https://:::3000 for direct connections

[9/13/2022, 4:55:52 PM] [FHEM] got csrfToken:

[9/13/2022, 4:55:52 PM] [FHEM] Checking devices and attributes...

[9/13/2022, 4:55:52 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&XHR=1

[9/13/2022, 4:55:52 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&XHR=1

[9/13/2022, 4:55:52 PM] [FHEM] waiting for events ...

[9/13/2022, 4:55:52 PM] [FHEM] Fetching FHEM devices...

[9/13/2022, 4:55:52 PM] [FHEM] fetching: http://fhem:8083/fhem?cmd=jsonlist2%20room%3D97_Eltern_Homekit&XHR=1

[9/13/2022, 4:55:52 PM] [FHEM] alexa device is alexa

[9/13/2022, 4:55:52 PM] [FHEM] alexa will not send proactive events

[9/13/2022, 4:55:52 PM] [FHEM] alexa uses ID: xyz

[9/13/2022, 4:55:52 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22alexa-fhem%20version%22%7D%20%3D%20%220.5.64%22%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&XHR=1

[9/13/2022, 4:55:52 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Blist%20alexa%20.eventToken%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&XHR=1

*** FHEM: connected

[9/13/2022, 4:55:52 PM] [FHEM] got: 16 results


config:

{
    "alexa": {
        "name": "xyz",
        "keyFile": "./certs/key.pem",
        "certFile": "./certs/cert.pem",
        "nat-pmp": "",
        "nat-upnp": false,
        "applicationId": "xyz",
        "oauthClientID": "xyz"
    },
    "connections": [
        {
            "name": "FHEM",
            "server": "fhem",
            "port": "8083",
            "filter": "room=97_Eltern_Homekit"
        }
    ]
}
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 13 September 2022, 22:06:22
Kannst Du in deiner Config bitte mal den Abschnitt mit sshproxy ergänzen:


{
    "alexa": {
        "name": "xyz",
        "keyFile": "./certs/key.pem",
        "certFile": "./certs/cert.pem",
        "nat-pmp": "",
        "nat-upnp": false,
        "applicationId": "xyz",
        "oauthClientID": "xyz"
    },

    "sshproxy" : {
        "description" : "FHEM Connector",
        "ssh" : "/usr/bin/ssh"
    },

    "connections": [
        {
            "name": "FHEM",
            "server": "fhem",
            "port": "8083",
            "filter": "room=97_Eltern_Homekit"
        }
    ]
}


Ich glaube, dann siehst Du im Logfile, dass die Instanz sich mit dem Vereinsserver verbindet.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: chrizza87 am 14 September 2022, 09:34:35
hey sidey,

danke für den tipp.

Habe es eingefügt und noch einiges anderes machen müssen (schreibrechte für ordner anpassen, ssh key erstellung etc etc). Dann ging es aber, jetzt ist der alexa-fhem Container mit dem Vereinsserver verbunden und ich kann über cie FHEM Oberfläche mir den Key anzeigen lassen für die Skill Verknüpfung.

Was ein bissl tricky war, es gab eine Fehlermeldung
Zitat"error; user homedir writable by group/other ('chmod 755 /alexa-fhem' required)"
, hier musste ich aber die Rechte 0700 setzen damit es ging (https://forum.fhem.de/index.php/topic,96510.0.html).

Wäre das eine Ergänzung wert in der Anleitung (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa), wie man den Connector mit alexa-fhem als docker Container verwendet? Ohne dich hätte ich das nämlich nicht hinbekommen. Dank dir nochmal vielmals :)

Gruß
chrizza
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 14 September 2022, 10:44:40
Hast Du es außen oder im Container gesetzt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: chrizza87 am 14 September 2022, 11:14:47
Zitat von: Wernieman am 14 September 2022, 10:44:40
Hast Du es außen oder im Container gesetzt?

Was genau meinst du?

Wenn der teil mit ssh-config, dann im Container mount in der config.json

Wenn rechte dann außerhalb, da ich es reinmounte an den Ort /alexa-fhem
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 14 September 2022, 11:46:35
Ich meinte eigentlich die Rechte für .ssh .. die Frage hast Du beantworten ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: chrizza87 am 14 September 2022, 20:28:57
alles klar  :P
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 14 September 2022, 20:55:21
Zitat von: chrizza87 am 14 September 2022, 09:34:35
hey sidey,

danke für den tipp.

Habe es eingefügt und noch einiges anderes machen müssen (schreibrechte für ordner anpassen, ssh key erstellung etc etc). Dann ging es aber, jetzt ist der alexa-fhem

Ich kann dem nicht ganz folgen.
Die benötigten sah Keys werden bei Bedarf beim Start des Containers erzeugt.
Dabei werden auch Berechtigungen für die SSH Keys gesetzt.

Ich würde gerne verstehen, was da nicht gepasst hat.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sedonion am 15 September 2022, 11:00:26
Darf ich mich da einklinken?
Ich stelle auch gerade um auf alexa-fhem im eigenen Container mit gleichen Problemen.

Schreibrechte auf das Verzeichnis musste ich auch setzen, aber auf dem Verzeichnis auf dem Host, das in den Container gemappt wird.

Mein Problem:
Der alexa-fhem Container liest brav die devices aus dem fhem Container aus.
Ebenso verbindet er sich mit dem Vereinsserver.
Aber: fhem kann die alexa-fhem.cfg nicht rüber kopieren.
Auch wenn ich alexaFHEM-sshUser fhem setze, verbindert er nicht.

2022.09.15 10:57:09 3: alexa: using ssh cmd /usr/bin/ssh 172.17.0.9
ssh: connect to host 172.17.0.9 port 22: Connection refused
ssh: connect to host 172.17.0.9 port 22: Connection refused


Was kann ich tun?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 15 September 2022, 11:38:10
Zitat von: Sedonion am 15 September 2022, 11:00:26
Aber: fhem kann die alexa-fhem.cfg nicht rüber kopieren.
Auch wenn ich alexaFHEM-sshUser fhem setze, verbindert er nicht.

Ich wüsste nicht wozu fhem die alexa-fhem.cfg kopieren wollte/sollte (oder dies täte).

alexa-fhem (der nodejs Teil) braucht diese Konfiguration, um zu wissen wo fhem läuft und wie darauf zugegriffen werden soll: fhem-connection
ebenso Einträge bzgl. der Verbindung zum Vereinsserver...

EDIT: sie liegt bei einer Installation von alexa-fhem normalerweise im Bereich wo fhem per "Edit Files" Zugriff hat, damit man die Konfiguration aus fhem heraus editieren kann (das war's soweit mir bekannt)...

Beides läuft doch?

Was das Alexa-Modul tut ist, sich um Start/Stop von alexa-fhem zu kümmern.
Normalerweise läuft das lokal bzw. kann man eben auch angeben, dass es auf einem anderen Rechner (und anderem User) läuft.
Dazu muss eine passwortlose ssh-Verbindung des Users fhem auf dem einen Host (dort wo fhem unter dem User fhem läuft) als User unter dem alexa-fhem auf dem anderen Host läuft bestehen.

Unter nicht Docker gibt es Anleitungen:
https://heinz-otto.blogspot.com/2020/09/ssh-mit-public-key.html
https://forum.fhem.de/index.php/topic,95291.15.html
usw.

Wie man sowas ziwschen 2 Docker Containern macht: keine Ahnung...

Hatte ich ja hier schon geschrieben: https://forum.fhem.de/index.php/topic,94817.msg1235032.html#msg1235032

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sedonion am 15 September 2022, 12:04:42
Zitat von: MadMax-FHEM am 15 September 2022, 11:38:10

Wie man sowas ziwschen 2 Docker Containern macht: keine Ahnung...

Hatte ich ja hier schon geschrieben: https://forum.fhem.de/index.php/topic,94817.msg1235032.html#msg1235032

Gruß, Joachim
Danke Dir.
Da hier sowohl chrizza87 als auch sidey diese Konstellation, in diesem Thread beschrieben, laufen haben, wollte ich hier nochmal nachfragen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 15 September 2022, 12:09:10
Zitat von: Sedonion am 15 September 2022, 12:04:42
Danke Dir.
Da hier sowohl chrizza87 als auch sidey diese Konstellation, in diesem Thread beschrieben, laufen haben, wollte ich hier nochmal nachfragen.

Mir bekannt ;)

Wollte eher darauf hinaus, dass es (vermutlich) nicht um das Kopieren einer Datei geht, sondern um das Starten eines Programmes (alexa-fhem)... 8)

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 15 September 2022, 12:12:48
Wobei es im Docker/Kubernetis Umfelt relativ ungewöhnlich ist, Infos per ssh unter Containern auszutauschen. z.B. ein geshartes Dateisystem ist da besser ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 15 September 2022, 12:28:35
Zitat von: Wernieman am 15 September 2022, 12:12:48
Wobei es im Docker/Kubernetis Umfelt relativ ungewöhnlich ist, Infos per ssh unter Containern auszutauschen. z.B. ein geshartes Dateisystem ist da besser ...

Wie geschrieben denke ich nicht, dass es um "Infos" oder Dateien/Dateiinhalte geht.

Sondern: das Alexa-Device in Container A also im fhem-Container (oder wie immer das heißt) "kontrolliert" (start/stop etc.) alexa-fhem (nodejs Programm) in Container B

Ohne Docker:

entweder lokale Installation von fhem und alexa-fhem -> ganz einfach

getrennte Installation, dann eben ssh-Zugriff ohne Passwort für fhem-User (A) auf B, damit das dort installierte alexa-fhem gesteuert werden kann (kenne/kann ich auch)

Wie das eben im Docker-Umfeld geht, ist das worum es (denke ich) hier geht...
(oder man sorgt dafür, dass alexa-fhem startet/läuft und ignoriert die Meldung des Alexa-Devices ;)  )

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 15 September 2022, 12:57:44
Ach sooo .... eigentlich startet bei Docker ein Container keinen 2. (Mit Ausnahme von speziellen Lösungen wie Docker2Docker). Du würdest auch keinen Server nehmen, der einen kompletten 2. hoch/runterfährt ... (Wobei es diesbezüglich bekanntlich Ausnahmen giebt)

Insofern kann ich hier auch nicht helfen ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 15 September 2022, 13:35:20
Naja es geht nicht drum einen Container zu starten, das würde das Alexa-Device in fhem (im fhem-Container) auch nicht "glücklich" machen.

Ich weiß nicht wie ich es sonst beschreiben soll, ich versuch's noch mal:

das Alexa-Device startet/stoppt per "Consolen-Commando" (= "Programmaufruf") das alexa-fhem "Programm".

Im einfachsten Fall ist beides auf dem selben System/Rechner/Server/... installiert, also das Alexa-Device (fhem) kann das dann einfach aufrufen.

Wenn man eine verteilte Installation auf "bare metal" hat, dann kann man das Alexa-Device in fhem so konfigurieren, dass es den (normalerweise simplen lokalen Aufruf) eben per ssh "remoten" kann.
(dazu muss aber fhem sich remote OHNE PW einloggen können und dann alexa-fhem ausführen dürfen)

Letzteres ist ja im prinzip simpel und mehrfach im Internet und fhem Forum beschrieben (gut nicht immer speziell für alexa-fhem / Alexa-Device aber das ist ja dann nur ein Attribut beim Alexa-Device, wenn eben PW-loser Zugang per ssh besteht).

Aber wie ist es, wenn man per ssh von einem Container ein Programm/Befehl/... in einem anderen Container aufrufen "möchte"?

Am einfachsten: der Container alexa-fhem läuft und dort ist alles ok (Verbindung zu fhem per http[ s ] besteht und Verbindung zum fhem-Vereins-Server besteht usw.) und alex-fhem wird automatisch gestartet UND man ignoriert einfach, dass sich das Alexa-Device (in fhem im fhem Container) "beschwert", dass eben alexa-fhem nicht laufen würde bzw. ja nicht mal installiert wäre.

Denn: esfunktioniert ja alles, nur das Alexa-Device ist "unzufrieden" und zeigt dies halt (zurecht? ;) ) an...

(diese Meldung ist "logisch", da ja das Alexa-Device im fhem Container keine alexa-fhem Installation finden kann, diese befindet sich ja im alexa-fhem Container)

Jetzt dürfen mal die Docker-Spezialisten ran ;)

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 15 September 2022, 14:04:11
Ein Conainter ist immer ein "Programm", d.h. wenn Du eben das "alexa-fhem Programm" stoppen, willst, stoppst Du eben den Container ..... so ist eben die Grundlage von Docker.

Du kannst auch einen Container so bauen, das er vergleichbar wie eine VM arbeitet, d.h. Du hast eine ssh-Server UND das "alexa-fhem Programm" in einem Container .. das entspricht nur eben nicht der "micro-Service" Docker Idee.

Was mir aber einfällt .. Du kannst den SSH-Aufruf doch auf den Host umleiten und dort dann den Container (und damit das "alexa-fhem Programm") starten/stoppen.

Wie man das nur in dem speziellen Umsetzt ... das müssen andere klären ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 15 September 2022, 14:18:18
Mir ist klar, dass ein Container auch nur ein Programm ist bzw. halt docker mit Parameter für den Container aufgerufen wird.

ABER: das Alexa-Device WEISS NIX VON DOCKER sondern will DIREKT das alexa-fhem Programm starten/prüfen (entweder lokal auf demselben Rechner oder halt per ssh / mehr ist nicht implementiert).

Das habe ja nicht ich so eingebaut, es ist halt nun mal so im Alexa-Modul implementiert.

D.h. solange es keine Möglichkeit gibt dem Alexa-Device (im fhem Container) irgendwie ssh-Zugriff DIREKT auf das "Programm" alexa-fhem (NICHT den Docker/Container!) zu geben wird das Alexa-Device einfach "beleidigt" bleiben.

Aber (noch mal): es funktioniert ja auch ohne das prima (es wird eben nur nicht angezeigt, dass alles eigentlich funktioniert).

Ich wollte ja nur Klarheit in den Sachverhalt bringen.

Ich selbst installiere lieber "bare metal"...
...bzw. nutze Docker nur wo es für mich Sinn macht (z.B. SW-Development für Generierumgebung: immer gleiche Voraussetzungen für alle die eine Generierung anwerfen usw.)...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 15 September 2022, 19:23:11
Zitat von: MadMax-FHEM am 15 September 2022, 14:18:18
ABER: das Alexa-Device WEISS NIX VON DOCKER sondern will DIREKT das alexa-fhem Programm starten/prüfen (entweder lokal auf demselben Rechner oder halt per ssh / mehr ist nicht implementiert).

Genau so ist das FHEM Alexa Modul gebaut.
Ich habe auch schon darüber nachgedacht, ob es sinnvoll ist, eine SSH Verbindung auf den alexa-fhem-container zu ermöglichen, allerdings stoppt man keine Programme in einem anderen Container.

Mir fällt auch nichts ein, wieso wir das bräuchten, denn der alexa-fhem-container kümmert sich ja bereits darum, dass die Alexa nodejs Komponente läuft und überwacht diese auch.

Die Anzeige im FHEM Modul könnte der Maintainer ändern und überwachen, ob sich das nodejs Alexa Programm verbunden hat.
Meinetwegen könnte ich auch eine Art Lebenszeichen aus dem Container an das Modul senden, wenn es eine passede Schnittstelle bietet.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 16 September 2022, 11:18:27
Hallo,

mal eine Frage zu -e PIP_PKGS="package1 package2":

Kann, oder besser: wie kann ich hier die --upgrade Option nutzen? Ich würde gerne ein pip install --upgrade pip machen... -e PIP_PKGS="--upgrade pip" wird wohl nicht funktionieren, oder doch?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 16 September 2022, 20:21:52
Zitat von: maddhin am 16 September 2022, 11:18:27
Kann, oder besser: wie kann ich hier die --upgrade Option nutzen? Ich würde gerne ein pip install --upgrade pip machen... -e PIP_PKGS="--upgrade pip" wird wohl nicht funktionieren, oder doch?

Was ist das Ziel, welches Du verfolgst?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 16 September 2022, 22:24:21
in diesem Fall um die aktuellste Version von PIP zu installieren. Ich kämpfe im Moment sehr damit fhempy (und insbesondere die dependency "cryptography") zu installieren. Das mag irgendwie alles nicht mit dem bullseye image (auf RPI2) zu funktionieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 17 September 2022, 12:57:30
Zitat von: maddhin am 16 September 2022, 22:24:21
in diesem Fall um die aktuellste Version von PIP zu installieren. Ich kämpfe im Moment sehr damit fhempy (und insbesondere die dependency "cryptography") zu installieren. Das mag irgendwie alles nicht mit dem bullseye image (auf RPI2) zu funktionieren.


Probier mal das debian Paket "libglib2.0" zu installieren. Wenn das nicht klappt, setze ich mir einen RPI2 auf und stelle es nach. Auf AMD64 klappts damit.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 17 September 2022, 13:43:44
Also libglib2.0-dev installiere ich schon über apt_pkgs:( Wie auch die anderen angegeben dependencies:

sudo apt install python3 python3-pip python3-dev libffi-dev libssl-dev libjpeg-dev zlib1g-dev autoconf build-essential libglib2.0-dev libdbus-1-dev bluez libbluetooth-dev git libprotocol-websocket-perl

Das tuts aber leider nicht. Habe auch python3-cryptography (apt) probiert und cryptography (und fhempy) über pip_pkgs.

Manuell (bash mit fhem user) habe ich pip (erfolgreich) geupdated, die manuelle Installation von cryptography, rust (über rustup) schlagen fehl, die Installation über das rust script funktioniert, cryptography checked trotzdem aber nicht, dass rust installiert ist.
Fhempy Installation scheitert an cryptography und grundsätzlich wird scheinbar nicht die aktuelle Version installiert, wenn unter .local schon eine Version runtergeladen wurde. Ich habe immer die 0.1.242 gehabt, bis ich sie manuell gelöscht habe. Dann wurde eine aktuelle 0.1.4xx runtergeladen.

Lieben Dank für die Hilfe!!!!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 18 September 2022, 22:36:56
Zitat von: maddhin am 17 September 2022, 13:43:44
Fhempy Installation scheitert an cryptography und grundsätzlich wird scheinbar nicht die aktuelle Version installiert, wenn unter .local schon eine Version runtergeladen wurde. Ich habe immer die 0.1.242 gehabt, bis ich sie manuell gelöscht habe. Dann wurde eine aktuelle 0.1.4xx runtergeladen.

Also ich habe da nun auch schon einiges experimentiert. Dauert ja leider auch immer etwas auf nem raspi2.

Ich würde ja vorschlagen, wir erzeugen ein docker image für fhempy, denn ich denke, das ganze bekommen wir sicher einmal hin aber das bei jedem Update des fhem images alles wieder zu rekonstruieren wird auf Dauer kein Spaß.
Dann kann man das auch mal compilieren und wirft die compiler anschließend weg :) 
So zumindest wäre meine Idee dazu.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 19 September 2022, 00:15:46
ein Docker Image für fhempy wäre super! @dominik hat mir hier https://forum.fhem.de/index.php/topic,122288.msg1235367.html#msg1235367 (https://forum.fhem.de/index.php/topic,122288.msg1235367.html#msg1235367) schon intensiv versucht zu helfen, aber irgendwie haut das mit Docker nicht hin. Als ich im Feb22 fhempy das erste Mal installiert hatte, lief alles auch mit dem Docker Image (damals noch das experimetal Image) wunderbar. Nur jetzt nach einem Fhem-Update (ich hatte seit ein paar Monaten keines mehr gemacht), ist irgendwo etwas kaputtgegangen.

Bzgl. Image kann ich helfen zu testen. @dominik kann sicherlich fachlich am besten helfen. Es macht auch Sinn sich mit ihm kurz zuschließen bzgl. wie zukünftige Updates in das Image kommen, etc.

Lieben Dank für die Hilfe! 
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 19 September 2022, 08:08:06
fhempy in einem eigenen Container würde sogar der Idee von Docker entsprechen.

Verwende zwar fhempy (aktuell) nicht, aber @Sidey, kann ich Dir helfen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 19 September 2022, 08:18:41
Das erste rudimentär Image ist erzeugt:

https://github.com/fhem/fhempy-docker

Aktuell ungetestet.
Todos sind noch einige, aber die erfasse ich in GitHub.

Wer mag es denn mal testen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 24 September 2022, 16:00:34
Zitat von: Sidey am 19 September 2022, 08:18:41
Wer mag es denn mal testen?

Leider hat es ein paar Tage gedauert, aber habe es heute mal getestet - leider erfolglos:

2022-09-24 13:28:15,068 - ERROR    - __main__: Failed to load fhempy
Traceback (most recent call last):
  File "/usr/local/bin/fhempy", line 132, in <module>
    import fhempy.lib.fhem_pythonbinding as fpb
  File "/usr/local/lib/python3.9/site-packages/fhempy/lib/fhem_pythonbinding.py", line 16, in <module>
    from . import fhem, pkg_installer, utils, version
  File "/usr/local/lib/python3.9/site-packages/fhempy/lib/pkg_installer.py", line 20, in <module>
    pip_lock = asyncio.Lock()
  File "/usr/local/lib/python3.9/asyncio/locks.py", line 81, in __init__
    self._loop = events.get_event_loop()
  File "/usr/local/lib/python3.9/asyncio/events.py", line 639, in get_event_loop
    self.set_event_loop(self.new_event_loop())
  File "/usr/local/lib/python3.9/asyncio/events.py", line 659, in new_event_loop
    return self._loop_factory()
  File "/usr/local/lib/python3.9/asyncio/unix_events.py", line 54, in __init__
    super().__init__(selector)
  File "/usr/local/lib/python3.9/asyncio/selector_events.py", line 50, in __init__
    super().__init__()
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 402, in __init__
    self._clock_resolution = time.get_clock_info('monotonic').resolution
PermissionError: [Errno 1] Operation not permitted
Exception ignored in: <function BaseEventLoop.__del__ at 0x7606c898>
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 686, in __del__
    _warn(f"unclosed event loop {self!r}", ResourceWarning, source=self)
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 424, in __repr__
    f'closed={self.is_closed()} debug={self.get_debug()}>'
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 1924, in get_debug
    return self._debug
AttributeError: '_UnixSelectorEventLoop' object has no attribute '_debug'


Das andere Problem ist etwas, dass das Image ziemlich groß ist - 1.4GB. D.h. der kleine RPI2 muss ganz schön rödeln bis das fertig ist:) Die Imagegröße ist jetzt natürlich keine Prio, aber eine Überlegung wert.

Noch eine Verständnisfrage: wenn das Image bzw. der Container dann läuft würde man ein define für fhempy machen, oder würde die z.B. Tuya Cloud Erweiterung dann automatisch den fhempy Server finden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 24 September 2022, 16:57:39
Zitat von: maddhin am 24 September 2022, 16:00:34
Leider hat es ein paar Tage gedauert, aber habe es heute mal getestet - leider erfolglos:

Das Paket libseccomp2 ist in deiner Version fehlerhaft und für die Meldungen verantwortlich.

Hier habe ich ein Vorgehen gefunden, wie ein aktuelleres Paket bezogen werden kann:

https://github.com/freqtrade/freqtrade/issues/6183#issuecomment-1016940306

Image Größe schau ich mir an, wenn es funktioniert. Ist halt ein Standard Python Container als Basis.

Was automatisches finden angeht, weiss ich nicht wie das arbeitet. Ich habe zum testen fhempy manuell in FHEM bekannt gemacht.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 24 September 2022, 18:24:27
Zitat von: Sidey am 24 September 2022, 16:57:39
Das Paket libseccomp2 ist in deiner Version fehlerhaft und für die Meldungen verantwortlich.
Danke für den Tipp, das manuelle Nachinstallieren hat das Problem gelöst!

Zitat von: Sidey am 24 September 2022, 16:57:39
Ich habe zum testen fhempy manuell in FHEM bekannt gemacht.
Dumme Frage: wie? Ich habe fhempy_local und den Server manuell gelöscht in FHEM. Soll ich jetzt wieder ein "define fhempy_local BindingsIo fhempy" machen, oder wird dann alles wieder installiert und das docker-fhempy ignoriert? Oder kann / soll man den Server manuell definieren? Sorry, ich stehe hier voll auf der Leitung und will nichts kaputt machen;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 24 September 2022, 20:09:48
Zitat von: maddhin am 24 September 2022, 18:24:27
Soll ich jetzt wieder ein "define fhempy_local BindingsIo fhempy" machen, oder wird dann alles wieder installiert und das docker-fhempy ignoriert?

Laut fhempy Dokumentation musst Du mir dem Hostnamen oder IP Adresse von deinem Container einrichten.

Wenn der Container fhempy lautet und sich im gleichen Netzwerk wir dein fhem Container befindet, dann geht es wie folgt:


define fhempy_peer_IP BindingsIo fhempy:15733 fhempy

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 24 September 2022, 21:31:42

Ok, dann kam bei mir die Fehlermeldung unten. Nachdem ich "libprotocol-websocket-perl" unter apt-pkgs eingetragen hatte, ging es dann. Ich hatte (fälschlicherweise???) alle dependencies von fhempy bei fhem entfernt. 

2022.09.24 20:59:04.299 1: reload: Error:Modul 10_BindingsIo deactivated:
Can't locate Protocol/WebSocket/Frame.pm in @INC (you may need to install the Protocol::WebSocket::Frame module) (@INC contains: ./FHEM/lib ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/arm-linux-gnueabihf/perl5/5.32 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl-base /usr/lib/arm-linux-gnueabihf/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at ./FHEM/10_BindingsIo.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/10_BindingsIo.pm line 13.

2022.09.24 20:59:04.300 0: Can't locate Protocol/WebSocket/Frame.pm in @INC (you may need to install the Protocol::WebSocket::Frame module) (@INC contains: ./FHEM/lib ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/arm-linux-gnueabihf/perl5/5.32 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl-base /usr/lib/arm-linux-gnueabihf/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at ./FHEM/10_BindingsIo.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/10_BindingsIo.pm line 13.

2022.09.24 21:00:18.018 1: reload: Error:Modul 10_BindingsIo deactivated:
Can't locate Protocol/WebSocket/Frame.pm in @INC (you may need to install the Protocol::WebSocket::Frame module) (@INC contains: ./FHEM/lib ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/arm-linux-gnueabihf/perl5/5.32 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl-base /usr/lib/arm-linux-gnueabihf/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at ./FHEM/10_BindingsIo.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/10_BindingsIo.pm line 13.


Nun scheint Tuya soweit zu funktionieren... Ganz lieben Dank schonmal dafür!!!!!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 24 September 2022, 22:01:05
Zitat von: maddhin am 24 September 2022, 21:31:42
Nachdem ich "libprotocol-websocket-perl" unter apt-pkgs eingetragen hatte, ging es dann.

Das ist im FHEM Docker Image bereits enthalten, nicht nötig, das mittels apt zu installieren.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: maddhin am 24 September 2022, 22:06:53
Zitat von: Sidey am 24 September 2022, 22:01:05
Das ist im FHEM Docker Image bereits enthalten, nicht nötig, das mittels apt zu installieren.

OK, dann weiß ich nicht, wo der Fehler war. Vielleicht hatte sich irgendwo was aufgehängt.

Fhempy funktioniert - auch ein Update. Tuya geht auch, aber bei Umlauten im device namen kapituliert das Modul bzw. legt keinen device an (Umbennen löst das Problem).
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: pipp37 am 25 September 2022, 12:54:17
Fehlermeldung: too many open files
Docker Container: fhem/fhem:3.0.3-buster

Für alle die mit dem Fehler kämpfen hier meine Lösung mit Docker Compose in einer Vmware-ESX-VM.

Funktionsweise:
Es wird die pre-start.sh beim Starten des Containers verwendet um das nofile Limit in der Datei /etc/security/limits.conf für alle User (auch den FHEM user) größer 1024 zu setzen.

Das könnte man auch in das nächste Docker Image einbauen.

Check der Limits mit:

# exec into container
docker exec -it fhem bash

# become user fhem
su - fhem

# check limits
ulimit -Hn
ulimit -Sn

# check open files from fhem
ls -l /proc/$(ps -ax | grep [f]hem | head -n1 | awk '{print $1}')/fd




Verzeichnis der docker-compose.yml und pre-start.sh = /docker/fhem

File: pre-start.sh 
chmod +x pre-start.sh


#!/bin/bash
echo "**** PRESTART ****"
if ( !  grep -q "# FHEM-MARKER #" /etc/security/limits.conf ); then
    echo "Setting NOFILE"
    echo "# FHEM-MARKER #"     >> /etc/security/limits.conf
    echo "* soft nofile 26677" >> /etc/security/limits.conf
    echo "* hard nofile 46667" >> /etc/security/limits.conf
    else
    echo "Setting NOFILE already done"
fi


File: docker-compose.yml


version: '2'
volumes:
  files:
    driver: local

services:
  fhem:
    container_name: fhem
    image: "fhem/fhem:3.0.3-buster"
    restart: always
    network_mode: "host"
    privileged: true

  volumes:
      - "files:/opt/fhem"
      - type: bind
        source: ./pre-start.sh
        target: /pre-start.sh

# change because fhem only 1024 - error too many open files
    ulimits:
      nproc: 65535
      nofile:
        soft: 26677
        hard: 46677

    environment:
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
      APT_PKGS: "mc libmime-lite-perl libsnmp-perl libnet-snmp-perl libsnmp-session-perl libwww-curl-perl snmp openssh-client htop pv lsof"


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 25 September 2022, 13:06:38
Zitat von: pipp37 am 25 September 2022, 12:54:17
Fehlermeldung: too many open files
Docker Container: fhem/fhem:3.0.3-buster

Hast Du denn herausbekommen warum so viele file handels offen sind?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: pipp37 am 25 September 2022, 13:22:00
Zitat
Hast Du denn herausbekommen warum so viele file handels offen sind?

Ja. Meine Installation läuft schon seit 2016 und es sind sehr viel Geräte drinnen, die per Autocreate angelegt wurden und nicht vorhanden sind.
Ich lasse zum Filelog auch noch ein DBLOG in eine Mysql DB laufen und habe gesehen, dass die Logfiles das Problem verursachen.

Die Text-Datei zeigt meine offenen Files.


Fhem wurde kürzlich upgedated.

Latest Revision: 26438

File                  Rev   Last Change

fhem.pl               26379 2022-09-03 15:40:42Z rudolfkoenig
################################## # $Id: 99_myUtilsEMONITOR.pm 2014-8 by Elektrolurch $
90_at.pm              25248 2021-11-21 10:29:01Z rudolfkoenig
98_autocreate.pm      23727 2021-02-12 20:31:37Z rudolfkoenig
98_cloneDummy.pm      13015 2017-01-08 20:26:33Z betateilchen
98_cmdalias.pm        16300 2018-03-01 08:48:21Z rudolfkoenig
00_CUL.pm             24815 2021-08-01 16:14:02Z rudolfkoenig
10_CUL_HM.pm          25977 2022-04-18 14:48:41Z martinp876
14_CUL_MAX.pm         22175 2020-06-13 17:32:49Z Wzut
14_CUL_REDIRECT.pm    18358 2019-01-20 20:21:05Z bjoernh
14_CUL_TCM97001.pm    26180 2022-06-29 15:00:03Z Ralf9
14_CUL_TX.pm          17102 2018-08-08 05:34:42Z rudolfkoenig
14_CUL_WS.pm          20918 2020-01-08 19:20:38Z rudolfkoenig
98_CustomReadings.pm  15098 2017-09-19 16:46:33Z HCS
95_Dashboard.pm       25965 2022-04-15 15:31:56Z DS_Starter
93_DbLog.pm           26289 2022-08-05 19:15:32Z DS_Starter
70_DENON_AVR.pm       25787 2022-03-06 17:06:35Z delmar
No Id found for 99_DockerImageInfo.pm
98_DOIF.pm            26435 2022-09-20 20:49:19Z Damian
98_dummy.pm           25606 2022-02-01 10:43:57Z rudolfkoenig
70_ENIGMA2.pm         18995 2019-03-22 20:09:53Z loredo
91_eventTypes.pm      23471 2021-01-04 19:24:21Z rudolfkoenig
01_FHEMWEB.pm         26246 2022-07-19 11:05:05Z rudolfkoenig
92_FileLog.pm         26329 2022-08-17 07:57:51Z rudolfkoenig
10_FS20.pm            14888 2017-08-13 12:07:12Z rudolfkoenig
73_GasCalculator.pm   25907 2022-04-01 07:40:25Z Sailor
14_Hideki.pm          25560 2022-01-25 21:43:09Z Sidey
98_HMinfo.pm          25978 2022-04-18 14:50:17Z martinp876
00_HMLAN.pm           25204 2021-11-09 05:41:42Z martinp876
98_HTTPMOD.pm         25994 2022-04-24 18:04:22Z StefanStrobel
02_HTTPSRV.pm         20110 2019-09-05 17:30:20Z neubert
98_IF.pm              12944 2017-01-03 12:56:17Z Damian
No Id found for 93_InfluxDBLog.pm
No Id found for 98_InfratecOut.pm
98_Installer.pm       20949 2020-01-12 09:53:11Z loredo
49_IPCAM.pm           24924 2021-09-06 08:47:51Z delmar
10_IT.pm              20839 2019-12-28 09:41:47Z bjoernh
98_JsonList2.pm       23727 2021-02-12 20:31:37Z rudolfkoenig
13_KS300.pm           20008 2019-08-17 10:24:14Z rudolfkoenig
32_mailcheck.pm       16299 2018-03-01 08:06:55Z justme1968
10_MAX.pm             23517 2021-01-13 15:38:49Z Wzut
00_MQTT.pm            24981 2021-09-16 16:06:15Z hexenmeister
10_MQTT_BRIDGE.pm     17362 2018-09-17 12:57:29Z hexenmeister
10_MQTT_DEVICE.pm     24952 2021-09-11 16:20:35Z hexenmeister
75_msgConfig.pm       18995 2019-03-22 20:09:53Z loredo
No Id found for 99_myUtils.pm
91_notify.pm          25888 2022-03-27 10:22:58Z rudolfkoenig
42_npmjs.pm           20933 2020-01-10 12:27:41Z loredo
41_OREGON.pm          18660 2019-02-19 22:44:37Z Sidey
70_PHTV.pm            18995 2019-03-22 20:09:53Z loredo
73_PRESENCE.pm        20782 2019-12-19 10:51:06Z markusbloch
70_Pushover.pm        20897 2020-01-06 12:16:20Z loredo
33_readingsGroup.pm   23844 2021-02-27 19:43:24Z justme1968
19_Revolt.pm          24864 2021-08-22 05:57:16Z yoda_gh
14_SD_WS07.pm         25485 2022-01-17 20:52:47Z Sidey
16_STACKABLE_CC.pm    18467 2019-01-31 08:02:51Z rudolfkoenig
98_statistics.pm      26211 2022-07-12 05:25:06Z Beta-User
99_SUNRISE_EL.pm      24249 2021-04-14 05:45:49Z rudolfkoenig
98_SVG.pm             26418 2022-09-18 14:35:20Z rudolfkoenig
32_SYSSTAT.pm         24779 2021-07-20 09:21:08Z justme1968
50_TelegramBot.pm     24867 2021-08-23 10:23:15Z viegener
98_telnet.pm          25754 2022-02-27 16:49:52Z rudolfkoenig
59_Twilight.pm        25067 2021-10-13 04:26:30Z Beta-User
98_UbiquitiMP.pm      14319 2017-05-19 19:44:53Z Wzut
98_UbiquitiOut.pm      8471 2015-04-23 17:46:01Z wzut
10_UNIRoll.pm         20792 2019-12-20 17:32:00Z rudolfkoenig
99_Utils.pm           24128 2021-04-02 16:29:11Z rudolfkoenig
98_version.pm         15140 2017-09-26 09:20:09Z markusbloch
91_watchdog.pm        26108 2022-06-01 08:25:03Z rudolfkoenig
98_weblink.pm         26403 2022-09-16 07:47:17Z rudolfkoenig
36_WMBUS.pm           25167 2021-11-01 16:43:20Z kaihs
71_YAMAHA_AVR.pm      21538 2020-03-29 09:12:10Z markusbloch

AttrTemplate.pm       25155 2021-10-30 12:48:21Z rudolfkoenig
Blocking.pm           23268 2020-12-01 11:48:48Z rudolfkoenig
Color.pm              20813 2019-12-22 18:42:10Z justme1968
DevIo.pm              26055 2022-05-17 20:12:20Z rudolfkoenig
GPUtils.pm            19666 2019-06-20 11:17:29Z CoolTux
HMConfig.pm           25160 2021-10-30 17:38:52Z martinp876
HttpUtils.pm          26420 2022-09-18 14:56:03Z rudolfkoenig
Meta.pm               21008 2020-01-18 10:22:10Z loredo
msgSchema.pm          21075 2020-01-29 19:46:59Z CoolTux
RTypes.pm             10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm      25286 2021-12-03 10:16:56Z rudolfkoenig
SubProcess.pm         14334 2017-05-20 23:11:06Z neubert
TcpServerUtils.pm     25866 2022-03-21 09:01:16Z rudolfkoenig
TimeSeries.pm         22980 2020-10-17 09:21:43Z neubert
WMBus.pm              25166 2021-11-01 16:04:05Z kaihs

doif.js                    24438 2021-05-14 18:08:18Z Ellert
fhemweb.js                 26334 2022-08-18 15:42:05Z rudolfkoenig
fhemweb_readingsGroup.js   15189 2017-10-03 17:53:27Z justme1968
svg.js                     23428 2020-12-27 22:07:20Z rudolfkoeni

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 26 September 2022, 09:50:33
ZitatDBLOG in eine Mysql DB
Aber die liegt doch bestimmt in einem eigenen Container ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: pipp37 am 26 September 2022, 11:45:22
ZitatDBLOG:
Aber die liegt doch bestimmt in einem eigenen Container ...
Ja, natürlich gibt es für die Mysql-DB, phpmydamin, mosquitto-mqtt, NodeRed  und die Influx-DB sowie für Grafana usw. jeweils eigene Docker Container in der Vmware-ESX Virtual Machine  mit  Ubuntu 16.04.
Das läuft so seit 2018 perfekt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 01 Oktober 2022, 12:49:33
Hey zusammen,
ich habe damals Anfangs für FHEM kein ausgelagertes Volume für Fhem benutzt und würde diese FHEM Installation nun gerne "auslagern".
Gibt es eine Möglichkeit die FHEM Daten aus dem Container in ein neues Volume zu kopieren? Dann Testweise einen neuen FHEM Container anlegen und die alte FHEM Insallation somit zu übernehmen?
Der Container läuft auf einen Synology NAS.
Habe mal 2 Screenshots von Portainer in dem man das FHEM Volume und ein InfluxDB Volume das ausgelagert ist sieht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 Oktober 2022, 13:46:33
Zitat von: michisa86888 am 01 Oktober 2022, 12:49:33
Hey zusammen,
ich habe damals Anfangs für FHEM kein ausgelagertes Volume für Fhem benutzt und würde diese FHEM Installation nun gerne "auslagern".
Gibt es eine Möglichkeit die FHEM Daten aus dem Container in ein neues Volume zu kopieren? Dann Testweise einen neuen FHEM Container anlegen und die alte FHEM Insallation somit zu übernehmen?
Der Container läuft auf einen Synology NAS.
Habe mal 2 Screenshots von Portainer in dem man das FHEM Volume und ein InfluxDB Volume das ausgelagert ist sieht.


docker cp fhem:/opt/fhem /pfad/auf/deiner/syno/fhem



https://www.synology-forum.de/threads/wie-wird-eine-datei-aus-einem-docker-container-zum-host-diskstation-kopiert.97330/
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 Oktober 2022, 13:47:09
Da gibt es sicher mehrere Wege. Einer:
Backup in FHEM machen.
über Portainer im FHEM Container auf die Shell wechseln
Das Backup über scp auf den Host oder woandershin kopieren.
Neuen FHEM Container machen, diesmal mit gemappten externen Pfad.
Backup zurückspielen
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 01 Oktober 2022, 14:39:25
Okay,
habe jetzt das ganze Volume nach /volume1/docker/fhem kopiert via docker cp.

Ist es nun gefahrenlos möglich das volume in Portainer zu löschen? Und das neue Volume hinzuzufügen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 01 Oktober 2022, 15:40:06
Zitat von: michisa86888 am 01 Oktober 2022, 14:39:25
Okay,
habe jetzt das ganze Volume nach /volume1/docker/fhem kopiert via docker cp.

Ist es nun gefahrenlos möglich das volume in Portainer zu löschen? Und das neue Volume hinzuzufügen?

ob das gefahrlos möglich ist musst du entscheiden. Wenn du alle DAten hast - ja.

Zur Sichgerheit kannst du in Synology aber den ganzen Container mit Inhalt exportieren. Sollte wirklich etwas fehlen kannst du diesen wieder importieren.

Du kannst auch den Container runter fahren und einen zweiten fhem Container mit dem Volumen erstellen und prüfen. Der erste Container bleibt dann erstmal bestehen. Du musst nur die Ports anders belegen da sie sonst doppelt wären.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 01 Oktober 2022, 15:48:43
Und genau das, mit einem 2. testen, ist genau der Sinn von Docker. Erst den 1. löschen, wenn der 2. läuft. Nennt sich "sanfte Migration"  ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 02 Oktober 2022, 22:12:35
Zitat von: maddhin am 24 September 2022, 16:00:34
Das andere Problem ist etwas, dass das Image ziemlich groß ist - 1.4GB. D.h. der kleine RPI2 muss ganz schön rödeln bis das fertig ist:) Die Imagegröße ist jetzt natürlich keine Prio, aber eine Überlegung wert.

So, ich habe mich der Imagegröße gewidmet. 185 MB hat das Image aktuell.
Es sah auch erst mal so aus, als ob es grundsätzlich funktioniert.
Das Image habe ich unter dem Tag v1.0 veröffentlicht:

ghcr.io/fhem/fhempy-docker:v1.0

Updates von fhempy führen dann 1x die Woche zu einer neuem Image.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 09 Oktober 2022, 09:51:37
Hallo zusammen,
ich möchte mal eine Anfänger-Frage stellen:
Habe Docker auf w11 installiert und den Container
fhem/fhem:latest   "/entry.sh start"   16 hours ago   Up 2 hours (healthy)   8083/tcp   naughty_mclean
zum laufen gebracht.
Leider komme ich nicht auf die Web-Oberfläche von Fhem localhost:8083/fhem wird abgelehnt, FW ist abgeschalten, Browser ist Chrome
Was kann ich tun??
Vielen Dank und viele Grüße!!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 09 Oktober 2022, 10:15:15
Kenne mich mit Docker unter Windows nicht aus ... aber wie hast Du den Container gestartet?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 09 Oktober 2022, 11:54:29
Über Docker für Desktop
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 09 Oktober 2022, 12:14:14
Zitat von: t.moori am 09 Oktober 2022, 11:54:29
Über Docker für Desktop
Kommst Du auf die Konsole?
Kannst Du aus dem Container heraus ein anderes Gerät im Nitzwerk erreichen?
Geht ein ssh auf die IP-Adresse des Containers?

VG
   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 09 Oktober 2022, 13:06:17
docker exec -it 95ec10110daa /bin/bash

/opt/fhem# ping 192.168.45.60 W11 ok
/opt/fhem# ping 172.22.240.1  vEth (WSL) ok

ssh von w11 oder aus container auf 172.22.240.1 geht nicht

ist die 172.22.240.1 die Adresse vom containet?

Danke!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 09 Oktober 2022, 13:14:45
Zitat von: t.moori am 09 Oktober 2022, 11:54:29
Über Docker für Desktop
Da wird die Firewall doch den Zugriff auf die Ports blockieren?!
Ich hatte das mal mit WSL durchgespielt und zum laufen bekommen. Bezüglich der Firewall Regeln müsste das ähnlich laufen:
https://heinz-otto.blogspot.com/2020/11/wsl-windows-linux-wie-macht-man-das.html

Mal schauen ob es mich juckt sowas auszuprobieren ;)

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 09 Oktober 2022, 13:33:45
Hi OTTO

C:\Users\frank>wsl -l -v
  NAME                   STATE           VERSION
* docker-desktop         Running         2
  docker-desktop-data    Running         2
 
C:\Users\frank>wsl --set-default-version 2
Informationen zu den wichtigsten Unterschieden zu WSL 2 finden Sie unter https://aka.ms/wsl2
Der Vorgang wurde erfolgreich beendet.
McAfee abgeschalten!
Gruß FW
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 09 Oktober 2022, 14:21:50
Zitat von: t.moori am 09 Oktober 2022, 09:51:37
Habe Docker auf w11 installiert und den Container
fhem/fhem:latest   "/entry.sh start"   16 hours ago   Up 2 hours (healthy)   8083/tcp   naughty_mclean
Irgendwie sehe in der Zeile jetzt nicht, dass es ein Portmapping gibt?

Was zeigt denn dies im Terminal Fenster?
docker container ls

Edit
Ich habe das nachgespielt:
Windows 11
Docker Desktop installiert: winget Docker.DockerDesktop
nach Neustart noch wsl 2 Kernel Update gemacht, nochmal neustart :(
Dann im Terminalfenster fhem gestartet:
docker run -d --name fhem -p 8083:8083 fhem/fhem:latest
Mit http:localhost:8083 komme ich auf fhem :) Firewall muss (noch) nicht manipuliert werden.

@Sidey Ich meine in der Readme https://github.com/fhem/fhem-docker gehören die docker pull Befehle nicht in folgende Zeile(Beispiel)
Zitatdocker run -d --name fhem -p 8083:8083 docker pull ghcr.io/fhem/fhem/fhem-docker:buster
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 09 Oktober 2022, 14:43:19
CONTAINER ID   IMAGE              COMMAND             CREATED        STATUS                 PORTS      NAMES
95ec10110daa   fhem/fhem:latest   "/entry.sh start"   21 hours ago   Up 7 hours (healthy)   8083/tcp   naughty_mclean
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 09 Oktober 2022, 14:51:10
Genau - Portmapping vergessen! Müsste so aussehen
Zitat0.0.0.0:8083->8083/tcp
Schau oben mein Start Kommando! Das ist aber auch noch nicht wirklich sinnvoll (da fehlt für meinen Geschmack ein Volume Mapping), aber für einen ersten Schuss reicht es :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 09 Oktober 2022, 15:01:29
C:\Users\frank>docker run -d --name fhem -p 8083:8083 docker pull ghcr.io/fhem/fhem/fhem-docker:buster
Unable to find image 'docker:latest' locally
latest: Pulling from library/docker
213ec9aee27d: Already exists
7b0dd730a5c3: Pull complete
4b90f8029a36: Pull complete
b2204c289e68: Pull complete
a75dcb107a37: Pull complete
3a173a06c313: Pull complete
44f3a1cb7a3f: Pull complete
a7d2f4b1d0b5: Pull complete
cd2ccc3f5575: Pull complete
Digest: sha256:b2343859b009730168704bf04dd705291539db39df5ccf840a91b647b72009fe
Status: Downloaded newer image for docker:latest
954757d0c2b6a8d28e6d733e5e14a7ecdd22c51644b43d7494fe2e94a50a61e3

Ergebnis:
container:
C:\Users\frank>docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?
Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?
Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 09 Oktober 2022, 15:04:24
Zitat von: Otto123 am 09 Oktober 2022, 14:21:50
@Sidey Ich meine in der Readme https://github.com/fhem/fhem-docker gehören die docker pull Befehle nicht in folgende Zeile(Beispiel)

Machst Du einen PR auf? Immerhin weißt Du ja schon genau wo es steht und wie es richtig ist nehme ich an :)

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 09 Oktober 2022, 15:12:50
@t.moori Nicht irgendwas kopieren und ausführen. Lesen und nachdenken :)
Diese Zeile war gemeint:
docker run -d --name fhem -p 8083:8083 fhem/fhem:latest
Die andere war eine Nachricht für Sidey ::)

@Sidey Ja mach ich :) edit: gemacht
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 09 Oktober 2022, 15:45:36
Vielen Dank,
war zu schnell und habe es korrigiert!!
Web-UI läuft!!
Viele Grüße!!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 09 Oktober 2022, 17:04:55
Weißt Du auch den Grund, warum es jetzt läuft und vorher nicht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 09 Oktober 2022, 17:32:42
@Werner Der Grund steht in #1683  ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 09 Oktober 2022, 20:04:17
Zitat von: Otto123 am 09 Oktober 2022, 15:12:50
@Sidey Ja mach ich :) edit: gemacht

Hi Otto,

ich habe jetzt noch keinen Pullrequest gesehen. Hast Du den gegen was anderes geöffnet als das FHEM Repository?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 09 Oktober 2022, 20:26:46
Zitat von: Sidey am 09 Oktober 2022, 20:04:17
Hast Du den gegen was anderes geöffnet als das FHEM Repository?
gegen meinen Fork  :-X
Ich bin nicht so fit in der (Zusammen)Arbeit mit Github  :-[

Ich hoffe jetzt stimmt es?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 09 Oktober 2022, 22:56:26
Zitat von: Otto123 am 09 Oktober 2022, 17:32:42
@Werner Der Grund steht in #1683  ;)
@Otto: ich weiß es .. nur ob der TA es verstanden hat, war meine Frage ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 10 Oktober 2022, 08:19:11
Guten Morgen,
Fhem läuft im Container!
Ich habe noch einen Container für einen ConBee2 angelegt und dieser läuft auch, ohne dev/serial Mapping.
Leider kann ich die lokale USB-Schnittstelle nicht mappen, in beide Containern gibt es kein Verzeichnis serial unter dev und so schmiert der Container ab, wenn ein dev Verzeichnis im Start-Skript aufgerufen wird.
Hat jemand eine Lösung??
Vielen Dank!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 10 Oktober 2022, 08:28:11
Wie Du Hardware von Windows z einem Linux-Container Mapps ...... guuute Frage und ich befürchte, das kann Dir keiner Beantworten ... oder jemand eine Idee?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 10 Oktober 2022, 09:01:50
Das unterstützt wsl derzeit leider nicht. Ich kenne keine Weg.
Docker Desktop für Windows eignet sich sicher gut für Test und Entwicklung von Containern ohne lokalen Hardware Zugriff. Man arbeitet aber irgendwie in der 3. Virtualisierung: VM-Plattform - WSL - Docker
Die VM Plattform (Hyper-V) unterstützt schon keine Einbindung von seriellen USB Schnittstellen. Lediglich Laufwerke kann man direkt einbinden.

Für den Anspruch ist Windows als Grundlage mMn der falsche Weg.

Edit: Aber die Erde dreht sich ja immer weiter und ich finde etwas zu usbipd:
https://www.xda-developers.com/wsl-connect-usb-devices-windows-11/
Keine Ahnung ob und wie es geht.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: t.moori am 10 Oktober 2022, 19:48:32
Hallo,
vielen Dank OTTO!!
Habe mal versucht deinem Link zu folgen, im Container fhem.
Ergebnis:
C:\Users\frank>wsl --list --verbose
  NAME                   STATE           VERSION
* docker-desktop         Running         2
  docker-desktop-data    Running         2

C:\Users\frank>usbipd wsl list
BUSID  VID:PID    DEVICE                                                        STATE
2-1    1cf1:0030  Serielles USB-Gerät (COM7)                                    Not attached

C:\Users\frank>usbipd wsl attach --busid 2-1
usbipd: info: Using default WSL distribution 'docker-desktop'; specify the '--distribution' option to select a different one.
usbipd: error: WSL 'usbip' client not correctly installed. See https://github.com/dorssel/usbipd-win/wiki/WSL-support for the latest instructions.

Ich bin auch diesen Link gefolgt, ohne Erfolg, mache erstmal ne Pause.
Viele Grüße!!

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 15 Oktober 2022, 11:24:17
Hallo zusammen,
ein mega großer Dank an all Eure tolle Arbeit.

Ich habe gerade mein neues QNAP NAS in Betrieb genommen und dort bei den Docker Containern einfach nach FHEM gesucht.
Ein Klick auf "installieren" und schon lief der Container ohne weitere Anpassungen, einfacher geht es nun wirklich nicht mehr.

Danke, Danke, Danke ... Man kann sofort mit der Migration beginnen :-)

VG  Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: TempuzFugit am 20 Oktober 2022, 19:42:52
Hallo zusammen,

schonmal vorab Sorry wenn ich die passende Antwort evtl. nicht in der Suche gefunden habe aber cih habe zwei Probleme bei denen ich momentan nicht weiter komme:

Ich betreibe Docker mit Portainer auf einer Synology und habe einen Raspberry PI3B+ mit Docker über Portainer Agent eingebunden.
Jetzt würde ich gerne auf dem Raspberry ein FHEM Docker Image installieren.
Meine yml-Datei sieht so aus:

version: '3'

services:

  fhem:
    image: ghcr.io/fhem/fhem/fhem-docker:bullseye
    container_name: fhem-og
    hostname: fhem-og
    restart: always
    ports:
      - 8001:8083
    volumes:
      - fhem_og:/opt/fhem/
    environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin
      APT_PKGS: sox libsox-fmt-all libsodium-dev gstreamer1.0-tools
      CPAN_PKGS: Crypt::Argon2 Crypt::NaCl::Sodium Alien::Base::ModuleBuild Alien::Sodium
    logging:
      driver: syslog
      options:
        syslog-address: "udp://192.168.4.12:514"
        tag: "{{.Name}}/{{.ID}}"

volumes:
    fhem_og:
      driver: local
      driver_opts:
         type: nfs4
         o: "addr=192.168.4.10,rw"
         device: ":/volume1/docker/fhem/og"



Problem 1: Nach Installation kann ich die Log Datei nicht aufrufen bzw. ist sie leer
Problem 2: Das Modul Doorbird kann ich nicht installieren.

Gibt es hier irgendeine Anleitung die ich noch nicht gefunden habe um das Doorbird Modul im Docker zu installieren?
Und was mache ich mit der Log Datei falsch bzw. fehlt mir eine Einstellung o.ä.

LG
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 20 Oktober 2022, 20:24:21
Zitat von: TempuzFugit am 20 Oktober 2022, 19:42:52
Meine yml-Datei sieht so aus:

Du kannst `ghcr.io/fhem/fhem/fhem-docker:3-bullseye` als Image versuchen. Das sollte auf deinem System laufen.
Wird aber vermutlich keine essentiellen Probleme beseitigen. Wäre nur ein aktuellerer Ausgangspunkt für die Fehlersuche.

Zitat von: TempuzFugit am 20 Oktober 2022, 19:42:52
Problem 1: Nach Installation kann ich die Log Datei nicht aufrufen bzw. ist sie leer
Du meinst im FHEMWEB den Menüpunkt richtig?
Dafür braucht es zwei Dinge in der fhem.cfg:


attr global logfile ./log/fhem-%Y-%m-%d.log

define Logfile FileLog ./log/fhem-%Y-%m-%d.log Logfile
attr Logfile nrarchive 7
attr Logfile room System


Zitat von: TempuzFugit am 20 Oktober 2022, 19:42:52
Problem 2: Das Modul Doorbird kann ich nicht installieren.

Das kann ich dir nicht sagen. Das schein ein paar nette Abhänigkeiten zu haben, die im Image vermutlich noch nicht berücksichtigt sind. Was mich wundert ist vor allem die Anpassung des SSH Servers. Am besten versorgst Du uns mal mit dem Logfile sobald das behoben ist, da wird hoffentlich vermerkt sein, warum das Modul nicht möchte.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: TempuzFugit am 21 Oktober 2022, 11:18:14
Logfile Fehler ist behoben, war eine unterschiedliche Benennung in der fhem.cfg

Mit den Doorbird Modulen komm ich aber irgendwie nicht weiter.

In den Environments habe ich folgendes eingetragen:
      APT_PKGS: sox libsox-fmt-all libsodium-dev gstreamer1.0-tools
      CPAN_PKGS: Crypt::Argon2 Alien::Base::ModuleBuild Crypt::NaCl::Sodium Alien::Sodium


Leider wird Version 2 von Alien ::Sodium installiert. Hat jemand einen Tip wie ich Version 1.0.8.0 installiert bekomme da das Doorbird Modul scheinbar diese Version benötigt

lg
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 Oktober 2022, 11:21:55
Zitat von: TempuzFugit am 21 Oktober 2022, 11:18:14

Mit den Doorbird Modulen komm ich aber irgendwie nicht weiter.

Leider wird Version 2 von Alien ::Sodium installiert. Hat jemand einen Tip wie ich Version 1.0.8.0 installiert bekomme da das Doorbird Modul scheinbar diese Version benötigt

Das Internet behauptet nach folgendem Syntax würde es gehen:
Alien::Sodium@1.0.8.0

Ich könnte die Pakete in das Image mit aufnehmen, wenn es keine Konflikte mit anderen Modulen gibt.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: TempuzFugit am 21 Oktober 2022, 12:07:36
Zitat von: Sidey am 21 Oktober 2022, 11:21:55
Das Internet behauptet nach folgendem Syntax würde es gehen:
Alien::Sodium@1.0.8.0

Vielen lieben Dank. Hat geklappt und Doorbird läuft :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mr2017 am 01 November 2022, 11:19:36
Hallo,

ich möchte meine FHEM-Installation auf Docker umstellen, scheitere gerade aber relativ früh bei der Einrichtung des DBlog Devices:

Ich starte einen frischen FHEM-Container, kopiere die (angepasste) db.conf nach /opt/fhem und versuche das Device mit


define logdb DbLog ./db.conf .*:.*


anzulegen. Das scheitert immer wieder mit

Can't open ./db.conf: No such file or directory

obwohl die Datei im richtigen Verzeichnis liegt und IMHO die korrekten Rechte hat:

-rwxrw-rw-  1 fhem fhem   2157 Nov  1 10:50 db.conf

Woran könnte das liegen? Vermute da habe ich noch irgendwo einen Knoten...

Danke für Eure Hinweise!





Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 November 2022, 11:29:39
Zitat von: mr2017 am 01 November 2022, 11:19:36
Ich starte einen frischen FHEM-Container, kopiere die (angepasste) db.conf nach /opt/fhem und versuche das Device mit
Im Container oder auf dem Host? ;)

Wie ist die Datei erstellt? Mit Windows oder linux?

Will der ./ nicht?  Ist egal - Sollte ja auch ohne funktionieren.
define logdb DbLog db.conf .*:.*
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schafy am 01 November 2022, 12:48:23
Hi,

mein FHEM Container meldet nur noch

su: Authentication failure
unable to start FHEM process - errorcode 1

Habe auch mal einen frischen Container deployed - gleiches verhalten. Ist FHEM:latest keine gute Wahl? Läuft in der Virtualisation Station auf QNAP.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mr2017 am 01 November 2022, 14:58:00
Zitat von: Otto123 am 01 November 2022, 11:29:39
Im Container oder auf dem Host? ;)

Wie ist die Datei erstellt? Mit Windows oder linux?

Will der ./ nicht?  Ist egal - Sollte ja auch ohne funktionieren.
define logdb DbLog db.conf .*:.*

Das Kopieren habe ich auf dem Host gemacht. Ist das ein Problem? Sorry wenn das eine blöde Frage ist - ist meine erste Docker-Umgebung...

Windows war nirgendwo im Spiel...

Ohne ./ gleiches Verhalten - die Datei wird nicht gefunden obwohl ich sie im Container sehe ?!? ...

Danke!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 01 November 2022, 15:23:33
im Container geguckt?
Sicherheitshalber: Wie hast Du geguckt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mr2017 am 01 November 2022, 15:25:46
Zitat von: Wernieman am 01 November 2022, 15:23:33
im Container geguckt?
Sicherheitshalber: Wie hast Du geguckt?

ls in der Konsole des Containers (in Portainer):

root@ddbcba0c1c83:/opt/fhem# ls -la
total 852
drwxr-x--- 14 fhem fhem   4096 Nov  1 10:50 .
drwxr-xr-x  1 root root   4096 Okt 26 19:57 ..
-rw-r-----  1 fhem fhem 383835 Okt 25 23:30 CHANGED
-rw-r-----  1 fhem fhem  46286 Okt 18 08:43 configDB.pm
drwxr-x--- 49 fhem fhem   4096 Okt 26 19:52 contrib
-rw-r-----  1 fhem fhem  18092 Okt 10 21:07 COPYING
-rwxrw-rw-  1 fhem fhem   2157 Nov  1 10:50 db.conf
drwxr-x---  3 fhem fhem   4096 Okt 26 19:52 demolog
drwxr-x---  4 fhem fhem   4096 Nov  1 10:37 docs
drwxr-x---  6 fhem fhem  20480 Nov  1 10:37 FHEM
-rw-r-----  1 fhem fhem   2207 Nov  1 10:37 fhem.cfg
-rw-r-----  1 fhem fhem    516 Nov  1 10:37 fhem.cfg.default
-rw-r-----  1 fhem fhem  25544 Okt 10 21:07 fhem.cfg.demo
-rwxr-----  1 fhem fhem 172543 Okt 10 21:07 fhem.pl
-rw-r-----  1 fhem fhem  18092 Okt 10 21:07 GPL_V2.txt
-rw-r-----  1 fhem fhem  28513 Okt 10 21:07 HISTORY
drwxr-x---  3 fhem fhem   4096 Okt 26 19:52 lib
drwxr-x---  2 fhem fhem   4096 Nov  1 10:37 log
-rw-r-----  1 fhem fhem  46102 Okt 25 23:30 MAINTAINER.txt
-rw-r-----  1 fhem fhem   5073 Okt 10 21:07 Makefile
drwxr-----  4 fhem fhem   4096 Nov  1 10:37 .npm
-rw-r-----  1 fhem fhem     25 Okt 10 21:07 .proverc
-rw-r-----  1 fhem fhem    935 Okt 10 21:07 README_DEMO.txt
-rw-r-----  1 fhem fhem    374 Okt 10 21:07 README.SVN
drwx------  2 fhem fhem   4096 Nov  1 10:37 .ssh
drwxr-x---  3 fhem fhem   4096 Okt 26 19:52 t
drwxr-x---  3 fhem fhem   4096 Okt 26 19:52 thirdparty
-rw-r-----  1 fhem fhem   2693 Okt 10 21:07 UPGRADE
drwxr-x---  6 fhem fhem   4096 Okt 26 19:52 webfrontend
drwxr-x---  8 fhem fhem   4096 Okt 26 19:52 www
root@ddbcba0c1c83:/opt/fhem#


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 November 2022, 15:30:46
warum ist die Datei ausführbar  ???

mach mal in FHEM (Oberfläche)
{qx(ls -lha db.conf)}
Ich meine die Fehlermeldung sagt er kann die db.conf nicht finden, aber er prüft die Datei, kann er einen Pfad in der config nicht finden und die Meldung leitet uns irre?
Benenne die mal um und mach eine neue:
In der console
mv db.conf db.conf.sav
touch db.conf
und dann noch mal dein define
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mr2017 am 01 November 2022, 15:41:32
Zitat von: Otto123 am 01 November 2022, 15:30:46
warum ist die Datei ausführbar  ???

mach mal in FHEM (Oberfläche)
{qx(ls -lha db.conf)}
Ich meine die Fehlermeldung sagt er kann die db.conf nicht finden, aber er prüft die Datei, kann er einen Pfad in der config nicht finden und die Meldung leitet uns irre?
Benenne die mal um und mach eine neue:
In der console
mv db.conf db.conf.sav
touch db.conf
und dann noch mal dein define

nach dem ls schreibt er ins log:

ls: Zugriff auf 'db.conf' nicht möglich: Datei oder Verzeichnis nicht gefunden
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mr2017 am 01 November 2022, 15:43:33
Zitat von: Otto123 am 01 November 2022, 15:30:46
warum ist die Datei ausführbar  ???

mach mal in FHEM (Oberfläche)
{qx(ls -lha db.conf)}
Ich meine die Fehlermeldung sagt er kann die db.conf nicht finden, aber er prüft die Datei, kann er einen Pfad in der config nicht finden und die Meldung leitet uns irre?
Benenne die mal um und mach eine neue:
In der console
mv db.conf db.conf.sav
touch db.conf
und dann noch mal dein define

Auf das ls schreibt er ins log:

ls: Zugriff auf 'db.conf' nicht möglich: Datei oder Verzeichnis nicht gefunden

Keine Änderung mit der neuerstellten db.conf - ich denke er meint tatsächlich die Datei selbst :

fhem@ddbcba0c1c83:~$ ls -la
total 852
drwxr-x--- 14 fhem fhem   4096 Nov  1 15:38 .
drwxr-xr-x  1 root root   4096 Okt 26 19:57 ..
-rw-r-----  1 fhem fhem 383835 Okt 25 23:30 CHANGED
-rw-r-----  1 fhem fhem  46286 Okt 18 08:43 configDB.pm
drwxr-x--- 49 fhem fhem   4096 Okt 26 19:52 contrib
-rw-r-----  1 fhem fhem  18092 Okt 10 21:07 COPYING
-rw-r--r--  1 fhem fhem      0 Nov  1 15:38 db.conf
-rwxrw-rw-  1 fhem fhem   2157 Nov  1 10:50 db.conf.sav
drwxr-x---  3 fhem fhem   4096 Okt 26 19:52 demolog
drwxr-x---  4 fhem fhem   4096 Nov  1 10:37 docs
drwxr-x---  6 fhem fhem  20480 Nov  1 10:37 FHEM
-rw-r-----  1 fhem fhem   2207 Nov  1 10:37 fhem.cfg
-rw-r-----  1 fhem fhem    516 Nov  1 10:37 fhem.cfg.default
-rw-r-----  1 fhem fhem  25544 Okt 10 21:07 fhem.cfg.demo
-rwxr-----  1 fhem fhem 172543 Okt 10 21:07 fhem.pl
-rw-r-----  1 fhem fhem  18092 Okt 10 21:07 GPL_V2.txt
-rw-r-----  1 fhem fhem  28513 Okt 10 21:07 HISTORY
drwxr-x---  3 fhem fhem   4096 Okt 26 19:52 lib
drwxr-x---  2 fhem fhem   4096 Nov  1 10:37 log
-rw-r-----  1 fhem fhem  46102 Okt 25 23:30 MAINTAINER.txt
-rw-r-----  1 fhem fhem   5073 Okt 10 21:07 Makefile
drwxr-----  4 fhem fhem   4096 Nov  1 10:37 .npm
-rw-r-----  1 fhem fhem     25 Okt 10 21:07 .proverc
-rw-r-----  1 fhem fhem    935 Okt 10 21:07 README_DEMO.txt
-rw-r-----  1 fhem fhem    374 Okt 10 21:07 README.SVN
drwx------  2 fhem fhem   4096 Nov  1 10:37 .ssh
drwxr-x---  3 fhem fhem   4096 Okt 26 19:52 t
drwxr-x---  3 fhem fhem   4096 Okt 26 19:52 thirdparty
-rw-r-----  1 fhem fhem   2693 Okt 10 21:07 UPGRADE
drwxr-x---  6 fhem fhem   4096 Okt 26 19:52 webfrontend
drwxr-x---  8 fhem fhem   4096 Okt 26 19:52 www
fhem@ddbcba0c1c83:~$
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mr2017 am 01 November 2022, 15:49:16
Zitat von: mr2017 am 01 November 2022, 15:41:32
nach dem ls schreibt er ins log:

ls: Zugriff auf 'db.conf' nicht möglich: Datei oder Verzeichnis nicht gefunden

Ich glaube jetzt habe ich die Ursache: Wenn ich ein ls in FHEM mache {qx(ls -lha)} dann bekomme ich Folgendes (andere GID) ?!?:

drwxr-xr-x 10 fhem dialout 4,0K Nov  1 07:24 .
drwxr-xr-x  4 root root    4,0K Okt 31 21:30 ..
-rw-r--r--  1 fhem dialout  46K Okt 31 08:02 configDB.pm
drwxr-xr-x 49 fhem dialout  16K Nov  1 07:24 contrib
drwxr-xr-x  3 fhem dialout 4,0K Nov  1 07:24 demolog
drwxr-xr-x  4 fhem dialout  12K Nov  1 07:24 docs
drwxr-xr-x  6 fhem dialout  76K Nov  1 07:24 FHEM
-rw-r--r--  1 fhem dialout 1,2K Nov  1 10:29 fhem.cfg
-rw-r--r--  1 fhem dialout  25K Okt 31 08:02 fhem.cfg.demo
-rwxr-xr-x  1 fhem dialout 169K Okt 31 08:02 fhem.pl
drwxr-xr-x  3 fhem dialout 4,0K Okt 17 16:17 lib
drwxr-xr-x  2 fhem dialout 4,0K Nov  1 00:00 log
-rw-r--r--  1 fhem dialout  46K Okt 31 08:02 MAINTAINER.txt
-rw-r--r--  1 fhem dialout  935 Okt 31 08:02 README_DEMO.txt
drwxr-xr-x  3 fhem dialout 4,0K Okt 17 16:18 restoreDir
drwxr-xr-x  8 fhem dialout 4,0K Okt 17 16:17 www


Woran kann das liegen?

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mr2017 am 01 November 2022, 16:16:27
Zitat von: Otto123 am 01 November 2022, 15:30:46
warum ist die Datei ausführbar  ???

mach mal in FHEM (Oberfläche)
{qx(ls -lha db.conf)}
Ich meine die Fehlermeldung sagt er kann die db.conf nicht finden, aber er prüft die Datei, kann er einen Pfad in der config nicht finden und die Meldung leitet uns irre?
Benenne die mal um und mach eine neue:
In der console
mv db.conf db.conf.sav
touch db.conf
und dann noch mal dein define

Das Problem lag mal wieder vor der Tastatur - da lief noch ein FHEM auf dem Host der für Testzwecke mal eingerichtet war - da kann ich die db.conf im Container lang ändern...

Danke an Alle die sich das trotzdem angesehen haben!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 01 November 2022, 18:45:29
Sorry aber irgendwie habe ich immer noch nicht das Problem/die Lösung verstanden ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 November 2022, 18:57:06
@Werner
ZitatIm Container oder auf dem Host? ;)
Er hat auf dem Host /opt/fhem und FHEM rennt
Und er hat im Container /opt/fhem und FHEM rennt (die Frage ist auf welchem Port / IP)

Beides hat nichts miteinander zu tun :o ;D
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: mr2017 am 01 November 2022, 20:32:51
Zitat von: Otto123 am 01 November 2022, 18:57:06
@WernerEr hat auf dem Host /opt/fhem und FHEM rennt
Und er hat im Container /opt/fhem und FHEM rennt (die Frage ist auf welchem Port / IP)

Beides hat nichts miteinander zu tun :o ;D

Genau so wars  - der Container lief natürlich auf einem anderen Port, das hatte ich aber im Eifer des Gefechts übersehen da ich die native FHEM-Installation gar nicht mehr auf dem Schirm hatte...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Hauswart am 03 November 2022, 10:57:15
Zitat von: volschin am 11 Mai 2020, 20:41:29
Hi zusammen,
ich habe meinen HM-CFG-USB2 jetzt für die Plattform amd64 dockerized. Falls jemand Interesse hat, habe ich das Image auch bei Docker-Hub (https://hub.docker.com/r/volschin/hmcfgusb) abgelegt.

Grüße
Veit

Hat jemand ein Compose-File für mich?


Edit: Derzeit verwende ich:
version: '3'


services:


  hmcfgusb:
    image: volschin/hmcfgusb:latest
    restart: always
    privileged: true
    ports:
      - "1234:1234"
    devices:
      - "/dev/usb/hiddev0:/dev/usb/hiddev0"



Ohne privileged habe ich es nicht hinbekommen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fhemjan am 09 November 2022, 14:40:38
Hallo,
weiß jemand ob der JeeLink v3c Stick mit dem fhem-Docker image funktioniert? Oder lieber die Classic Version nehmen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 09 November 2022, 17:51:08
Zitat von: fhemjan am 09 November 2022, 14:40:38

weiß jemand ob der JeeLink v3c Stick mit dem fhem-Docker image funktioniert?

Ich wüsste nicht, weshalb es nicht gehen sollte.
Wenn es Probleme geben sollte, dann machen wir es halt gangbar :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fhemjan am 10 November 2022, 11:02:11
Zitat von: Sidey am 09 November 2022, 17:51:08
Wenn es Probleme geben sollte, dann machen wir es halt gangbar :)
Genau so eine Antwort hab ich mir erhofft :) Danke, ich werde berichten
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schafy am 10 November 2022, 23:17:45
Hallo!

hat keiner eine Idee, woran das liegen könnte?

Zitat von: Schafy am 01 November 2022, 12:48:23
Hi,

mein FHEM Container meldet nur noch

su: Authentication failure
unable to start FHEM process - errorcode 1

Habe auch mal einen frischen Container deployed - gleiches verhalten. Ist FHEM:latest keine gute Wahl? Läuft in der Virtualisation Station auf QNAP.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 11 November 2022, 07:18:33
Zitat von: Schafy am 10 November 2022, 23:17:45
hat keiner eine Idee, woran das liegen könnte?

Vielleicht hat er das Image für die falsche CPU Architektur geladen.
Liest sich ja zumindest so, dass er den Container überhaupt nicht starten kann.
Mit qnap selbst kenne ich mich nicht aus, aber kannst Du herausfinden, welche CPU Architektur verbaut ist?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Schafy am 11 November 2022, 07:49:39
Es läuft ja, bis ich den Container neu starten muss.
Die QNAP läuft mit einem Celeron
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: choetzu am 13 November 2022, 15:32:00
Hallo,
bevor die das offizielle Docker Image installiere (bin am Anfang meiner Docker Reise), stosse ich mich bereits an einer Frage.

auf Github steht unter "Storage"

ZitatUsually you want to keep your FHEM setup after a container was destroyed (or re-build) so it is a good idea to provide an external directory on your Docker host to keep that data:

Hmm, aber genau deshalb erstellt man doch einen Container, damit alle Daten und Abhängigkeiten an einem Ort sind. Wieso sollte man - ausser der Container geht Flöte - das ausserhalb vom Container machen? Das würde doch dann auch der "Umzug" des Containers auf andere Systeme erschweren?

Hmm, vermutlich ein Denkfehler, aber ich komm grad nicht drauf. Danke für die Hilfe ;)

Lg C
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 13 November 2022, 16:00:08
Hi,

nicht ganz verstanden. ;) Die Daten im Container müssen ja irgendwo sein. Da gibt es aus meiner Sicht (mag sein, das hab ich auch noch nicht besser verstanden) drei Orte:
Wenn Du nichts angibst legt er das FHEM Directory im Container an. Ein Container ist aber so einen Art Einweg - Mietobjekt, es ist nicht dein PC! Der Container ist nicht "wertvoll", den wirfst Du weg und machst ihn neu, wenn was nicht geht.
Die einfachste Art für den OttonormalUser dürfte das Mapping eines Pfades sein. Dort liegen Deine Daten, Du kommst auch mal ran, kannst sie sichern und kopieren und auch in den neuen Container mitnehmen, wenn Dein alter nicht mehr gefällt und zerstört wird.

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 13 November 2022, 17:00:48
Zitat von: choetzu am 13 November 2022, 15:32:00
Hmm, aber genau deshalb erstellt man doch einen Container, damit alle Daten und Abhängigkeiten an einem Ort sind. Wieso sollte man - ausser der Container geht Flöte - das ausserhalb vom Container machen? Das würde doch dann auch der "Umzug" des Containers auf andere Systeme erschweren?
Bevor du anfängst such dir am besten mal bei Google ein paar Basics zu Docker.

Container - Laufzeitumgebung, kannst jederzeit neu downloaden UND wird bei jedem Update des Containers gelöscht und neu erstellt.
Verzeichnisse - deine persönlichen Daten.

Ich vergleiche es immer mit Word. Word als Programm kannst dir immer wieder neue installieren, das brauchst du nicht sichern oder aufheben. Die geschriebenen Dokumente musst du irgendwo permanent in einem separaten Verzeichnis abspeichern und auch ein Backup haben.

Wenn du den Container ohne lokale Verzeichnisse baust ist es so als würdest du Word und alle Dokumente in das Programmverzeichnis ablegen. Bei der Deinstallation von Word ist dann aber alles weg.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 13 November 2022, 17:30:21
Es gibt noch einen Nachteil für Dateien innerhalb des Containers:
Die Daten werden in "Layern" aufgehoben. Wenn Du also z.B. eine Datei "Änderst", wird sich gemerkt, das dort eine Änderung gemacht wurde, die Ursprünglichen Daten sind aber immer noch da.

Originaldaten | 1. Änderung | 2. Änderung | .... | X. Änderung

Stell Dir jetzt mal vor, Du hast 1.000 Änderungen gemacht, also 1.000 Layer ... bekanntlich wird dann der Container immer langsamer (vereinfacht ausgedrückt).

Wir hatten in meiner letzten Firma mit einem PHP5 Container genau solch ein Problem, der Session Key wurde im Container gespeichert. Nach 1/2 Jahr Laufzeit hat es mehrere Stunden gedauert, bis der Container "weg" war .... also ist "Im Container Speichern" nicht gut.

Und auch die Idee: "Dann nehme ich den Container mit" ist vergleichbar mit obigen Beispiel mit Word. Du würdest niemals Word (oder eine andere Software) von einem Rechner zum nächsten "mitnehmen", sondern von der Ursprungsquelle neu installieren. Nur die Daten nimmst Du mit.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 13 November 2022, 17:42:11
Hallo,

ich sehe bei den Docker-Versionen nicht mehr durch. Könnte mich bitte jemand aufklären, was ich in Portainer bei Image eintragen soll, dass:
- fhem/fhem:latest
- ghcr.io/fhem/fhem/fhem-docker:3-bullseye
- ghcr.io/fhem/fhem/fhem-docker:latest

scheint alles für mich das Gleiche zu sein, oder!?  :o

Viele Grüße,

Lutz
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: choetzu am 13 November 2022, 22:20:30
Hallo Otto123, Werniemann und Kadettilac89

habt ganz lieben Dank für Eure wertvollen Erläuterungen. Spätestens beim Beispiel mit Word fiel der Groschen.
Ich mach mich weiter schlau, installiere in der Zwischenzeit mal Portainer und Co und schmeiss das fhem/fhem drauf inkl. Angabe von opt/fhem ;)

Lg und schönen Abend
c

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 13 November 2022, 22:43:33
Zitat von: LutzG am 13 November 2022, 17:42:11
- fhem/fhem:latest
- ghcr.io/fhem/fhem/fhem-docker:3-bullseye
- ghcr.io/fhem/fhem/fhem-docker:latest


Im Moment verweisen die drei tags auf das gleiche Image.

3-bullseye bleibt immer ein bullseye Image.

Latest wird halt irgendwann mal auf was anderes verweisen. Möglicherweise kann es dort auch mal Änderungen geben, die zu Inkompatibilitäten führen.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: LutzG am 13 November 2022, 23:45:46
Danke Sidey, Klarheiten beseitigt!   :D

Zitat von: Sidey am 13 November 2022, 22:43:33
Latest wird halt irgendwann mal auf was anderes verweisen. Möglicherweise kann es dort auch mal Änderungen geben, die zu Inkompatibilitäten führen.

Also, wenn ich aktuell bleiben will, "latest", wo "Mal" (eher unwahrscheinlich und maximal kurzfristig) was nicht funktioniert...

Werden jetzt in Zukunft die Images:
- fhem/fhem:latest
- ghcr.io/fhem/fhem/fhem-docker:latest

immer auf das gleiche Image verweisen, oder kann es da doch Mal unterschiedliche Versionen geben?

Viele Grüße, Lutz
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 14 November 2022, 09:25:07
Sicherheitshalber:;
Viele Anfänger sehen ein Docker Image wie eine VM, das ist es aber nicht!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Stonemuc am 18 November 2022, 12:15:06
Hallo,

ich steige auch gerade auf Docker um und möcte meinen RPI auf meinen NAS Server umziehen lassen. Ich hab noch eine Frage - kann ich irgendwie aus FHEM auf das Logfile zugreifen? Ick kkann die Logs ja im Container sehen...aber wenn ich in FHEM auf logfile drücke, ist es leer...
Gibt es da eine Mögichkeit? Oder loggt ihr nur im Container mit?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 18 November 2022, 12:33:43
Hi,

das Logfile ist bei mir ganz normal in FHEM im Zugriff.

Zeig mal:
list Logfile|global logfile

Wenn da unterschiedliche Dinge stehen, wird es nicht funktionieren ;)

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Stonemuc am 18 November 2022, 21:41:41
Hallo Otto,

hier mal der Screenshot
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 18 November 2022, 21:44:06
Zitat von: Stonemuc am 18 November 2022, 21:41:41
Hallo Otto,

hier mal der Screenshot

Die eine Einstellung ist mit %d was den Tag im Monat angibt die andere ohne.
Wenn Du das angleichst funktioniert es.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 01 Dezember 2022, 23:22:16
Hallo,

kann fhem keine shell-Scripts mehr ausführen, wenn es im Docker Container läuft?
Ein shellscript soll in einem gemounteten Verzeichnis alte Backup-Files löschen. Das Script liegt unter /opt/fhem/scripts im Container und wird in Fhem in einem DOIF nach backup ausgeführt.


([11:00|Mo])
(
backup,
"sudo /opt/fhem/scripts/del_old_fhem_bkup.sh&"
)


Mit Fhem ohne Docker lief alles gut.
Gruß

Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 02 Dezember 2022, 00:01:41
Hallo Alex,

shellscripts kannst Du ausführen, aber im Container ist alles anders ;)

wer mounted und wo ist das gemounted? Im Container? Oder auf dem Host?

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 02 Dezember 2022, 18:52:19
Hi Otto,

es funktioniert jetzt, nachdem ich den find commandstring angepasst hatte.
Zum Hintergrund:
Also ich habe im Host in der fstab das /mnt/Fritz.Nas gemountet, welches in den Container als Volume definiert ist. Fhem kann dort die eigenen Backups erstellen, diese sind dann auf der Fritzbox. Funktioniert soweit. Im Anschluß nach dem Backup soll fhem alle Backup-File die älter als 15 Tage sind, löschen. Dies hat vor Umzug auf Docker mit
dem Aufruf eines shellscripts unter /opt/fhem/scripts/del_old_fhem_bkup.sh

"sudo /opt/fhem/scripts/del_old_fhem_bkup.sh&"
eigentlich funktioniert.
Das genannte Verzeichnis gehört fhem und die scriptdatei hat Ausführungsrechte für fhem.
Das script selbst:

find /mnt/Fritz.Nas/FHEM_Backup/FHEM-.*  -mtime +15 -type f -delete

führte zu
No such file or directory
Nach Änderung des Scripts auf:

find /mnt/Fritz.Nas/FHEM_Backup -name FHEM-.*  -mtime +15 -type f -delete

funktioniert es jetzt.
Vielen Dank erstmal.

Gruß

Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 03 Dezember 2022, 12:31:23
Wobei das 2. auch der Richtige Syntax ist ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: guhu am 03 Dezember 2022, 16:11:11
.. man mappt idR bei Docker ein Verzeichnis (können auch mehrere oder Dateien sein) mit dem Hostsystem, damit die relevanten Daten persistent sind. Du willst ja bestimmt nicht die fhem.cfg verlieren, nur weil Du den Container neu aufbaust. Das ist die Philosophie bei allen Docker Containern.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fhemjan am 11 Dezember 2022, 14:32:40
Ich habe seit ein paar Tagen das Problem, das sich mein Docker Container nicht mehr starten lässt. Es scheint mit dem cul868 zusammenzuhängen. Wenn ich etwas Zeit finde werde ich mich damit nochmal ausführlich auseinandersetzen müssen, aber vielleicht vorab die Frage:
Könnt ihr mit evtl. einen Tipp geben wo der Fehler liegen könnte wenn ich im Container-Log sowas bekomme
2022.12.03 23:27:09.397 3: cul868: Unknown code A1510008E7CD6B8B7B1BB00003B16A6468AADEB9F398B::-106:cul868, help me!
2022.12.03 23:27:09.566 3: cul868: Unknown code A0E0580022E336871CA100101000038::-106:cul868, help me!
2022.12.03 23:27:17.693 3: cul868: Unknown code A1950008F670565F0000101CA99570305244727F1348A8F158CB4::-105.5:cul868, help me!
2022.12.03 23:27:22.928 3: cul868: Unknown code A131200832D9BEEF00001000024CC3A374A090173::-103.5:cul868, help me!
2022.12.03 23:27:50.295 3: cul868: Unknown code A0CAD86701FC93F000000008B3D::-105.5:cul868, help me!
2022.12.03 23:28:01.805 3: cul868: Unknown code A1B10008E464A2DB7B1BB00000B1CA43573EA5D44FF6DEB6025D0A3F9::-105:cul868, help me!
2022.12.03 23:28:24.319 3: cul868: Unknown code A1E10008E3DEA8CB7B1BB0000B3C6DDC43CBA3FA62BEA6F4E63914334B54B72::-101:cul868, help me!
2022.12.03 23:28:24.462 3: cul868: Unknown code A06B7B1BB3DEA8C, help me!
2022.12.03 23:28:25.024 3: cul868: Unknown code A1714008E4487E94E38D700006A3AF7D6924609B572A3AF13::-96:cul868, help me!
2022.12.03 23:28:58.620 3: cul868: Unknown code A06AF6D0C3DEA8C, help me!
2022.12.03 23:28:58.685 3: cul868: Unknown code A1810008E3DEA8CB7B1BB0000B3C7240C810F7711B85A21ED6E::-102:cul868, help me!
2022.12.03 23:29:02.023 3: cul868: Unknown code A1E10008E3DEA8CB7B1BB0000B3C80CE997C41EC55C31AC263DF76A091D2C01::-101:cul868, help me!
2022.12.03 23:29:02.125 3: cul868: Unknown code A06AF6D0C3DEA8C, help me!
2022.12.03 23:29:23.695 3: cul868: Unknown code A1950008F670565F0000101CA99586F2591034D018F155D4DBB07::-104.5:cul868, help me!
2022.12.03 23:30:01.960 3: cul868: Unknown code A13120083AFB19EF0000100043062D134B6628E13::-101.5:cul868, help me!
2022.12.03 23:30:28.915 3: cul868: Unknown code A121200834487E9F0000100006A3B8143B6C35A::-95.5:cul868, help me!
2022.12.03 23:31:05.640 3: cul868: Unknown code A131200837A57A1F00001000020938EDB9067330D::-108.5:cul868, help me!
2022.12.03 23:31:15.774 3: cul868: Unknown code A131200834487E9F0000100006A3D7812657D67D9::-96:cul868, help me!
2022.12.03 23:31:28.188 3: cul868: Unknown code A131200833EA3FCF000010000C11816E491829E07::-106:cul868, help me!
2022.12.03 23:31:33.245 3: cul868: Unknown code A131200836225A4F000010000C30B074EE57B4A24::-101.5:cul868, help me!
2022.12.03 23:32:00.216 3: cul868: Unknown code A1610008F464A2DF0000100000B1D3A98A6E76788DD8879::-104:cul868, help me!
2022.12.03 23:32:00.293 3: cul868: Unknown code A1610008F464A2DAF4CE800000B1ECEEB8CE6FC88E9ED9F::-104.5:cul868, help me!
2022.12.03 23:32:00.446 3: cul868: Unknown code A1610008F464A2D49DAFD00000B1FADF99FBEAEB3865A63::-103:cul868, help me!
2022.12.03 23:32:01.231 3: cul868: Unknown code A1610008F464A2DF0000100000B2011C7B97FBA5E8FF6D8::-104:cul868, help me!
2022.12.03 23:32:01.320 3: cul868: Unknown code A1610008F464A2DAF4CE800000B21AC6351777D4EDC3943::-103.5:cul868, help me!
2022.12.03 23:32:01.483 3: cul868: Unknown code A1610008F464A2D49DAFD00000B22A79DB52A4B81258D88::-103.5:cul868, help me!
2022.12.03 23:32:02.609 3: cul868: Unknown code A1610008F464A2DF0000100000B231F4A96013858FAA792::-104.5:cul868, help me!
2022.12.03 23:32:02.695 3: cul868: Unknown code A1610008F464A2DAF4CE800000B241A1871C75AE2B324ED::-105:cul868, help me!
2022.12.03 23:32:02.796 3: cul868: Unknown code A06AF4CE8464A2D, help me!
2022.12.03 23:32:02.886 3: cul868: Unknown code A1610008F464A2D49DAFD00000B25E2B79541F2DEDD2FF2::-104.5:cul868, help me!
2022.12.03 23:32:03.988 3: cul868: Unknown code A1610008F464A2D49DAFD00000B26941B86FA3A1E96A32D::-105:cul868, help me!
2022.12.03 23:32:04.093 3: cul868: Unknown code A0649DAFD464A2D, help me!
2022.12.03 23:32:04.148 3: cul868: Unknown code A1B10008E464A2DB7B1BB00000B271C632AA7CB65B28C71329A92DF7E::-104.5:cul868, help me!
2022.12.03 23:32:04.247 3: cul868: Unknown code A06AF6D0C464A2D, help me!
2022.12.03 23:32:11.472 3: cul868: Unknown code A131200833DEA8CF000010000B3C9062FA64952AD::-101.5:cul868, help me!
2022.12.03 23:32:19.447 3: cul868: Unknown code A1950008F670565F0000101CA995996A6A33A81B5F341233604CF::-104.5:cul868, help me!
2022.12.03 23:32:45.256 3: cul868: Unknown code A2110008EAFB19EB7B1BB000430637EE470E94F7883C43858EF5552DD4BBF80A46EB3::-101:cul868, help me!
2022.12.03 23:32:45.347 3: cul868: Unknown code A1E10008EAFB19EB7B1BB00043064DCE9CC80F531F98E56B6BFB23D27216EF8::-101.5:cul868, help me!
2022.12.03 23:32:45.436 3: cul868: Unknown code A2110008EAFB19EB7B1BB00043065C01A1D019DB1E5184162E53381276FE3B89AD510::-102:cul868, help me!
2022.12.03 23:33:13.407 3: cul868: Unknown code A1C10008E6225A4B7B1BB0000C30C13E3C6F1966A9D8BA2ED139B1D062B::-101:cul868, help me!
2022.12.03 23:33:13.541 3: cul868: Unknown code A06B7B1BB6225A4, help me!
2022.12.03 23:33:14.013 3: cul868: Unknown code A06B7B1BB3EA3FC, help me!
2022.12.03 23:33:22.560 3: cul868: Unknown code A06B7B1BB3EC459, help me!
2022.12.03 23:33:30.301 3: cul868: Unknown code A0CAF86701FC93F000000008B3D::-107:cul868, help me!
2022.12.03 23:33:32.816 3: cul868: Unknown code A06B7B1BB2285DC, help me!
2022.12.03 23:33:37.116 3: cul868: Unknown code A1312008321DECEF000010000E6DB30912DE6D42C::-109:cul868, help me!
2022.12.03 23:33:43.553 3: cul868: Unknown code A13120083458A3EF0000100000601E6971FDF9662::-105:cul868, help me!
2022.12.03 23:33:43.598 3: cul868: Unknown code A1714008E4487E9458A3E00006A3FA424AC92268C3F75EAA1::-95.5:cul868, help me!
2022.12.03 23:33:49.817 3: cul868: Unknown code A1E10008E518020B7B1BB0057E65B81A48A75E976E03F0BAE793B86A3A0CB5B::-95.5:cul868, help me!
2022.12.03 23:35:00.699 3: cul868: Unknown code A1950008F670565F0000101CA995A8848ACA2D533B448E28A8EAC::-103:cul868, help me!
2022.12.03 23:36:26.958 3: cul868: Unknown code A1714008E4487E92AF40900006A40402A24C6D44B25D8B254::-96.5:cul868, help me!
2022.12.03 23:37:16.294 3: cul868: Unknown code A1C10008E3DEA8CB7B1BB0000B3CA265BA42BE5A5C69B133092A80DE1E1::-101.5:cul868, help me!
2022.12.03 23:37:16.416 3: cul868: Unknown code A06B7B1BB3DEA8C, help me!
2022.12.03 23:37:27.452 3: cul868: Unknown code A1950008F670565F0000101CA995B622D01863AE34A224758CBF9::-105.5:cul868, help me!
2022.12.03 23:38:12.310 3: cul868: Unknown code A0CB186701FC93F000000008B3D::-108.5:cul868, help me!
2022.12.03 23:38:13.623 3: cul868: Unknown code A131200832285DCF000010000E515AC1B62EF2651::-107.5:cul868, help me!
2022.12.03 23:39:39.973 3: cul868: Unknown code A1950008F670565F0000101CA995C869D7D464E93A6D06188EA78::-104.5:cul868, help me!
2022.12.03 23:40:22.809 3: cul868: Unknown code A13120083AFB19EF0000100043066810D2155BFF4::-101:cul868, help me!
2022.12.03 23:40:52.350 3: cul868: Unknown code A121200834487E9F0000100006A4262AFB95EC9::-96:cul868, help me!
2022.12.03 23:41:06.547 3: cul868: Unknown code A131200834487E9F0000100006A432681C3D804BB::-95.5:cul868, help me!
2022.12.03 23:41:15.811 3: cul868: Unknown code A0CB286701FC93F000000008B3D::-108:cul868, help me!
2022.12.03 23:41:54.828 3: cul868: Unknown code A131200836225A4F000010000C30D0DD9CFB987CF::-101.5:cul868, help me!
2022.12.03 23:42:28.160 3: cul868: Unknown code A1810008E415AAEB7B1BB000037B39A8B0608EBC41AC1E3BE3A::-105:cul868, help me!
2022.12.03 23:42:28.300 3: cul868: Unknown code A06B7B1BB415AAE, help me!
2022.12.03 23:42:36.959 3: cul868: Unknown code A131200833DEA8CF000010000B3CB670BE72B0DED::-102:cul868, help me!
2022.12.03 23:42:41.955 3: cul868: Unknown code A1950008F670565F0000101CA995DB0A457C8401E161458A1BC19::-103:cul868, help me!
2022.12.03 23:43:07.764 2: LuftdatenInfo (Luftdaten_BadNenndorf) - SDS011 position differs from other sensor position
2022.12.03 23:45:29.460 3: cul868: Unknown code A1950008F670565F0000101CA995EE6E8DD2114D45C1D8B8A7ADB::-106.5:cul868, help me!
2022.12.03 23:45:31.139 3: cul868: Unknown code A13120083518020F000010057E65C7340EF6641F5::-95.5:cul868, help me!
2022.12.03 23:45:43.388 3: cul868: Unknown code A2510008E670565B7B1BB01CA995F66808E26EB77677811059D38BDEE9173765842B59A3796D2::-105:cul868, help me!
2022.12.03 23:46:39.319 3: cul868: Unknown code A0CB486701FC93F000000008B3D::-107:cul868, help me!
2022.12.03 23:48:01.563 3: cul868: Unknown code A131200832285DCF000010000E5162B4E94B7FFA0::-105:cul868, help me!
2022.12.03 23:48:59.572 3: cul868: Unknown code A0CB586701FC93F000000008B3D::-105.5:cul868, help me!
2022.12.03 23:49:58.418 3: cul868: Unknown code A13120083464A2DF0000100000B2893F496FFBF7D::-104:cul868, help me!
2022.12.03 23:50:21.461 3: cul868: Unknown code A1950008F670565F0000101CA99619087938CE4E2F2DC4CFEFF16::-103.5:cul868, help me!
2022.12.03 23:50:24.103 3: cul868: Unknown code A13120083AFB19EF00001000430672DAB3B582AAA::-102.5:cul868, help me!
2022.12.03 23:50:30.777 3: cul868: Unknown code A121200834487E9F0000100006A4708289A2362::-95.5:cul868, help me!
2022.12.03 23:50:52.364 3: cul868: Unknown code A131200834487E9F0000100006A48790D1C100A19::-96:cul868, help me!
2022.12.03 23:51:05.323 3: cul868: Unknown code A0CB686701FC93F000000008B3D::-106.5:cul868, help me!
2022.12.03 23:52:25.714 3: cul868: Unknown code A1950008F670565F0000101CA9962DEA9347509BDC944350F45C5::-105:cul868, help me!
2022.12.03 23:52:27.799 3: cul868: Unknown code A131200836225A4F000010000C30EAB6EE000F3E8::-102:cul868, help me!
2022.12.03 23:52:41.758 3: cul868: Unknown code A131200833DEA8CF000010000B3CCE5DF4FEBB819::-101.5:cul868, help me!
2022.12.03 23:53:22.105 3: cul868: Unknown code A1312008321DECEF000010000E6DD9D9177CDF7BF::-105.5:cul868, help me!
2022.12.03 23:54:00.577 3: cul868: Unknown code A0CB786701FC93F000000008B3D::-106:cul868, help me!
2022.12.03 23:55:19.715 3: cul868: Unknown code A1950008F670565F0000101CA99632EDB67B8854466B9DEAFF1F9::-104:cul868, help me!
2022.12.03 23:56:41.582 3: cul868: Unknown code A0CB886701FC93F000000008B3D::-107.5:cul868, help me!
2022.12.03 23:56:56.908 3: cul868: Unknown code A1510008E7CD6B8B7B1BB00003B1701DB7825899844FF::-102:cul868, help me!
2022.12.03 23:56:57.045 3: cul868: Unknown code A06B7B1BB7CD6B8, help me!
2022.12.03 23:57:27.133 3: cul868: Unknown code A1714008E4487E92AF40900006A49834987F319D26A026883::-95.5:cul868, help me!
2022.12.03 23:57:59.220 3: cul868: Unknown code A1950008F670565F0000101CA996479F46A100D472AADF5BA71F3::-106:cul868, help me!
2022.12.03 23:59:08.086 3: cul868: Unknown code A0CB986701FC93F000000008A3D::-105.5:cul868, help me!
SIGTERM signal received, sending "shutdown" command to FHEM!
Waiting for FHEM process to terminate before stopping container:
2022.12.04 00:00:08.159 2: DbLog logdb - Last database write cycle due to shutdown ...
2022.12.04 00:00:08.797 2: DbLog logdb - no data for last database write cycle
2022.12.04 00:00:08.798 1: Server shutdown delayed due to logdb for max 10 sec

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 11 Dezember 2022, 14:42:40
Container-Log?

Sieht wie fhem-Log aus...

Wenn es im fhem Log stehen würde, würde ich sagen: dein CUL empfängt Dinge aus der Nachbarschaft (RSSI sehr schlecht -100 / -95 / ...), die er nicht versteht -> help me!

Ich weiß nicht wofür du den CUL verwendest, bei CUL_HM gibt es für sowas die vccu: https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU
(ob die alle diese Meldungen "abfangen" kann: keine Ahnung)

Anmerkung (offTopic): wenn CUL_HM würde ich bei Gelegenheit den CUL gegen z.B. das hier tauschen https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi geht auch per Netzwerk oder USB...
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_mit_USB-Adapter
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Betrieb_mit_einem_LAN-TTL-Wandler
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_.C3.BCber_das_Netzwerk
Bzw. eben spät. wenn es Missing Ack/Timeout RegisterRead Meldungen gibt ;)

Bei anderem Einsatz des CUL eben "dort" schauen was man gegen solche Meldungen tun kann (evtl. "irgendwas" auf "ignore" setzen)...

Evtl. hilft auch eine Forum-Suche nach CUL help me ;)

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 11 Dezember 2022, 14:43:34
Bei Homematic würde ich sagen: VCCU definieren.  ;)

Zu spät ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 11 Dezember 2022, 17:33:31
Aber er dürfte doch deswegen nicht abschmieren?

Und ein Docker-Log dürfte auch nicht schlecht sein ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 11 Dezember 2022, 18:04:12
ZitatIch habe seit ein paar Tagen das Problem, das sich mein Docker Container nicht mehr starten lässt.
Von abschmieren stand da nix.
Allerdings weiß ich  nicht was "nicht starten bedeutet" - ein FHEM Log wird ja geschrieben  ???
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Florian_GT am 18 Dezember 2022, 04:34:41
Hi,

ich habe seit einigen Tagen auch Docker in Verbindung mit FHEM in Verwendung. Ich habe das Problem, dass für die Benutzung von echodevice das NPM Paket alexa-cookie fehlt. Wieso ist das im Standard Image nicht mit enthalten?

Danke und Gruß
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 18 Dezember 2022, 09:00:08
Zitat von: Florian_GT am 18 Dezember 2022, 04:34:41
Ich habe das Problem, dass für die Benutzung von echodevice das NPM Paket alexa-cookie fehlt. Wieso ist das im Standard Image nicht mit enthalten?
Eventuell. weil es zu wenige verwenden???
Ich habe auch einige Pakete, die nicht im Container enthalten sind.
Leider scheint es auch einen Unterschied beim Python 3 zwischen einer Standard Debian installation und dem Container zu geben.

VG   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 18 Dezember 2022, 09:17:41
Zitat von: Florian_GT am 18 Dezember 2022, 04:34:41
Hi,

ich habe seit einigen Tagen auch Docker in Verbindung mit FHEM in Verwendung. Ich habe das Problem, dass für die Benutzung von echodevice das NPM Paket alexa-cookie fehlt. Wieso ist das im Standard Image nicht mit enthalten?

Danke und Gruß

EDIT: ups, sorry! Verwechselt... :-\

Es gibt wohl auch einen alexa-fhem Container.
Allerdings "mosert" dann das Alexa-Device in fhem, weil ja kein lokales alexa-fhem zu finden ist.
Funktionieren tut aber alles...

Wenn man damit leben kann ist das auch eine Möglichkeit...


Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 18 Dezember 2022, 11:15:33
Zitat von: Florian_GT am 18 Dezember 2022, 04:34:41
Ich habe das Problem, dass für die Benutzung von echodevice das NPM Paket alexa-cookie fehlt. Wieso ist das im Standard Image nicht mit enthalten?

Primär soll das docker Image den Betrieb von FHEM (Perl) ermöglichen.
Aus historischen Gründen, ist noch mehr als nur Perl und FHEM im Container.

Die NPM Pakete habe ich vor einiger Zeit aus dem Image entfernen müssen, da es sonst nicht möglich war, das Image fehlerfrei zu bauen.

Das Ziel für das echodevice wäre es, ein eigenes Image zu erzeugen, welches diese das nötige Programm enthält.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 22 Dezember 2022, 08:57:57
Hallo hab noch mal ne Frage zum Docker Image.

Ich verwende das fhem/fhem Docker Image, auf meinem Unraid Server, bin absolut zufrieden damit und alles läuft bestens.
Das einzige bei einem Update muss ich halt immer in er console dann alexa nachinstallieren
also das "sudo npm install -g alexa-fhem" zum glück schreibt er das immer ins REading rein sonst müsste ich jedesmal nachfragen ;)

und eine riehe von chmod 777 * muss ich überall machen (fhem, FHEM, www tabletui dir), da ich sonst nicht per Samba vom windows Rechner draufkomme.

Wie wäre die die korrekte vorgehensweise um das perfekt zu haben?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 22 Dezember 2022, 09:14:07
Für Alexa, siehe Doku:
https://github.com/fhem/fhem-docker/ (https://github.com/fhem/fhem-docker/)

Und Samba .. sorry aber ich würde es nicht machen (Gründe sind viel zu vielfältig um es hier zu schreiben)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 22 Dezember 2022, 10:38:07
Hmm so richtig habe ich nun nix gefunden für Alexa.
Oder meinst ich sollte den Befehl in /pre-init.sh reingeben?

wo muss diese datei liegen damit diese berücksichtigt wird?
im moment habe ich nur ein Directory mapping auf  /opt/fhem

Wie wäre der bessere weg? Ich möchte halt die Scripte so halbwegs bequem auf meinem Notebook bearbeiten (index.html und die 99_MyUtils.pm)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 22 Dezember 2022, 10:43:34
Eventuell ist der Abschnitt bzgl. npm-Modulen gemeint?

Aber gibt es nicht ein Docker für/mit alexa-fhem?

Dort dann in die alexa-fhem.cfg bei Connections das fhem im fhem-Container eintragen...
...im fhem-Docker beim Alexa-Device die Meldung: "not running..." ignorieren (es läuft ja ;)  )...

Sollte gehen, meine ich...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 22 Dezember 2022, 13:21:06
Zitat von: MadMax-FHEM am 22 Dezember 2022, 10:43:34
Aber gibt es nicht ein Docker für/mit alexa-fhem?

Gibt es, hier:
https://github.com/fhem/alexa-fhem-docker

Das ist auch der vorgesehene Weg.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 23 Dezember 2022, 07:39:37
Hmmm ein neues Docker Image, da habe ich irgendwie die Angst das ich dann Probleme bekommen werde die ganze USB Geräte wieder ans laufen zu bekommen.

Ich glaube ich versuche es nächste mal mit den NPM Module, weil die Installation dauert ja nicht lange.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 23 Dezember 2022, 08:09:07
Der alexa-fhem Docker hat (so ich das denke) doch "nur" alexa-fhdm "im Bauch"...
In der darin enthaltenen alexa-fhem Config "einfach" die Verbindung zu fhem im vorhandenen fhem-Docker eintragen und gut...

Im fhem (fhem-Container) dann ein Alexa-Device anlegen (damit die Attribute etc. da sind)...
Einzig dieses Device wird sich "beschweren" dass kein LOKALES alexa-fhem läuft (tut es ja auch nicht)...
Hat aber funktional keine Auswirkungen...

Oder bin ich falsch informiert?

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 23 Dezember 2022, 10:23:52
Zitat von: MadMax-FHEM am 23 Dezember 2022, 08:09:07
Oder bin ich falsch informiert?

Du bist richtig informiert. Über diesen Weg gibt es auch ein aktuelles nodejs.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 26 Dezember 2022, 13:33:04
Ich setzte auch gerade meine Docker Container neu auf.
Wenn ich die docker-compose von der Github-Seite nutze ist dort für Alexa-Fhem der Port 3000 drin.
Kann ich diesen ohne Probleme nur auf den Port 3001 legen? Den 3000 hat schon der Grafana Docker.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 26 Dezember 2022, 13:50:35
Zitat von: michisa86888 am 26 Dezember 2022, 13:33:04
Ich setzte auch gerade meine Docker Container neu auf.
Wenn ich die docker-compose von der Github-Seite nutze ist dort für Alexa-Fhem der Port 3000 drin.
Kann ich diesen ohne Probleme nur auf den Port 3001 legen? Den 3000 hat schon der Grafana Docker.

Nutzt du alexa-fhem mit dem Vereinsserver und "nur" Smart Home Skill (Fhem Skill) oder hast du Custom Skills laufen?
Wenn du KEINE Custom Skills laufen hast, also "nur" alexa-fhem Connector mit dem Fhem Skill nutzt, dann brauchst du Port 3000 überhaupt nicht "öffnen".
(Hast du überhaupt eine Port-Weiterleitung in deinem Router aktiv für Port 3000 und alexa-fhem?)

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 26 Dezember 2022, 22:53:56
Also aktuell nutze ich das Image CoolTux
ghcr.io/fhem/fhem-experimental:dev
In diesem ist Alexa ja integriert. Dort nutzte ich eigentlich nur den Fhem Connector Skill.

Will auch nur die aktuellen Images probieren, da das Image doch schon ein Jahr alt ist. Oder lohnt sich ein Umstieg überhaupt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 27 Dezember 2022, 00:17:19
Zu Docker bzw. welches "Image" nun besser ist kann ich nichts sagen...
Sondern nur was ich bzgl. Port bereits geschrieben hatte...

Und ob du Custom Skill verwendest oder einen eigenen Skill auf Amazon Lambda laufen hast und daher eine Portweiterleitung aus dem Internet benötigst weißt nur du...

Wenn du keine Custom Sachen hast und keinen Port offen/weitergeitet: wozu dann im Docker was freigeben? ;)

Welche Version von alexa-fhem läuft denn in deinem Container?
Wenn wechseln, dann halt wenn das "zu alt" ist/wäre...

Außer es läuft und du brauchst keine Features die in deiner Version nicht drin sind...

EDIT: aktuell dürfte 0.5.64 sein...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 27 Dezember 2022, 10:47:29
Okay das ist ja dann bei mir aktuell. Dann werde ich wohl mal vom Imagewechsel absehen:


alexa-cookie2 4.1.3
alexa-fhem 0.5.64
corepack 0.15.2
gassistant-fhem 3.0.5
homebridge 1.6.0
homebridge-fhem 0.5.38
npm 9.2.0
tradfri-fhem 0.1.9
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 27 Dezember 2022, 16:34:39
Zitat von: michisa86888 am 26 Dezember 2022, 22:53:56
Also aktuell nutze ich das Image CoolTux
ghcr.io/fhem/fhem-experimental:dev
In diesem ist Alexa ja integriert. Dort nutzte ich eigentlich nur den Fhem Connector Skill.

Das von dir benannte Image habe ich versuchsweise (experimentell) mal erstellt. Wie Du bereits bemerkt hast, hat das Image schon länger keine Security Updates mehr erhalten.

Für alexa-fhem gibt es ein eigenes Image mit aktuellem NodeJS. Updates gibt es in der Regel monatlich.
Die NodeJS Version im FHEM Container ist mittlerweile eol.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Florian_GT am 29 Dezember 2022, 17:18:44
Zitat von: Wernieman am 22 Dezember 2022, 09:14:07
Für Alexa, siehe Doku:
https://github.com/fhem/fhem-docker/ (https://github.com/fhem/fhem-docker/)

Und Samba .. sorry aber ich würde es nicht machen (Gründe sind viel zu vielfältig um es hier zu schreiben)

Ich muss dann sagen ich verstehe die Anleitung nicht so wirklich. Soll dass "NOTE..." darauf hinweisen, dass der darunter erwähnte Docker Container die notwendigen Pakete enthält? Ich habe jetzt per https://github.com/fhem/fhem-docker/#add-custom-packages die Pakete hinzugefügt, aber noch immer Probleme mit der Anmeldung an Alexa selbst. Naja mal schauen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 29 Dezember 2022, 17:33:36
Zitat von: Florian_GT am 29 Dezember 2022, 17:18:44
Ich muss dann sagen ich verstehe die Anleitung nicht so wirklich. Soll dass "NOTE..." darauf hinweisen, dass der darunter erwähnte Docker Container die notwendigen Pakete enthält?

Es gibt ein image für FHEM und ein Image in dem alexa-fhem installiert ist.
Die Images ergänzen sich, sie ersetzen sich nicht gegenseitig.

Das nachinstallieren von Paketen das ist eine Notlösung. Für alexa-fhem nicht nötig .

Welche Anleitung meinst Du eigentlich?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 29 Dezember 2022, 17:35:17
@Florian_GT: alexa-fhem oder (wie im anderen Thread) echodevice? Sind 2 komplett unterschiedliche Dinge!

Oder willst du beides mittels Docker?

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: sn0000py am 30 Dezember 2022, 11:26:16
Hallo, mal hier die performance Frage:
Wie lange sollt der start einer frischen FHEM installation dauern?
Bei mir dauert die ca 3 minuten auf einem Docker (Intel® Celeron® J4105 CPU @ 1.50GHz, 16 GiB, SSD Platte)

Dabei bleibt er laut log hier solange stehen

6. Enforcing file and directory permissions for /opt/fhem ...

ist das normal oder habe ich hier ein anderes problem?
Wie gesagt frisch installiert, und ein leeres Config.


Ereldigt, war ein zusätzlcihes Volume das in /opt/fhem/cache eingebunden wurde, das 60000 Files in diversen dirs beinhaltet hat - ohne dem startet es nun normal
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 05 Januar 2023, 03:22:44
Guten Morgen zusammen,

bin relativ neu im Thema Docker.
FHEM läuft schon mal im Docker.

Wenn ich jetzt benötigte Pakete installieren möchte, wie bekomme ich die rein?
Verstehe das noch nicht so richtig.

z.B. nutze ich den Speedtest mit Ookla, da der andere bei mir Probleme macht, wie bekomme ich das "installiert"?

Danke und Grüße
Gear
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 05 Januar 2023, 09:17:41
Hallo Gear,

sowas mache ich "extern" :) denn meiner Meinung macht es keinen Sinn in einem Docker Image Pakete zu installieren, es ist kein PC.
Siehe hier (https://heinz-otto.blogspot.com/2022/04/andocken-dinge-die-man-auerhalb-docker.html), ziemlich zum Schluss
Für ookla ist das ja ziemlich einfach ;)

Konsequenterweise könnte man auch einen Docker Container dafür bauen, es ist aber bloß eine Datei die nicht mal installiert werden muss. Ich verwende das dann so:
defmod MySpeedtest speedtest 1800
attr MySpeedtest comment {system ('ssh root@192.168.56.1 '.q('wget -qO speedtest.tgz https://install.speedtest.net/app/cli/ookla-speedtest-1.2.0-linux-armhf.tgz;;;;tar -zxvf speedtest.tgz speedtest;;;;./speedtest --accept-license --accept-gdpr -f json' &) ) }
attr MySpeedtest ookla 1
attr MySpeedtest path ssh root@192.168.56.1 ./
attr MySpeedtest room Status

In der Kommentarzeile steht das einmalige Setup "Script"

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 05 Januar 2023, 09:38:15
Zitat von: Gear am 05 Januar 2023, 03:22:44
Wenn ich jetzt benötigte Pakete installieren möchte, wie bekomme ich die rein?

Normalerweise werden keine Pakete nachinstalliert.
Wenn es halt überhaupt nicht ohne geht, dann kannst Du es als Umgebungsvariable beim Start des Containers mit angeben:

-e APT_PKGS="package1"


Vielleicht gibt es aber auch ein separates Image in dem dein Speedtest läuft?

Edit:
Hier wäre eines:
https://hub.docker.com/r/phlak/speedtest

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 05 Januar 2023, 10:42:49
---- OT Start ----
Langsam kotz mich Docker schon so ziemlich an.
Also, wahrscheinlich wegen meiner eigenen Blödheit...  :o
Wollte den Containern eigene IP + MAC geben, funzt nicht, MQTT in separaten Container läuft nicht...
(Ja, ich weiß FHEM kann das eigenständig... Nutze das aber auch noch anderweitig und muss das so oder so installieren)
---- OT End ----

Naja, ich nutze für einige Dinge Python, welche ich via Update von GIT hole.
Hier muss z.B. das pip FHEM installiert werden, wie in dem Thema von mir: https://forum.fhem.de/index.php/topic,123963.msg1185197.html#msg1185197
Benötigt wird z.B.:
sudo apt-get install python3-pip
pip3 install fhem


Bin mich noch am reinfuxen, aber langsam echt demotiviert....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 05 Januar 2023, 10:51:41
ZitatWollte den Containern eigene IP + MAC geben
Hört sich danach an, das Du denkst, das Docker eine VM ist. Dann kann ich Dir garantieren, das Du entäuscht werden wirst. Docker ist KEINE VM! Ja man kann einen Container so betreiben, aber das ist "Home-Bastel-Arbeit" und führt längerfristig zu Problemen.

Um einen Container extern erreichbar zu machen gibt es 2 sinnvolle Möglichkeiten.
1. Port Exposen, d.h. extern erreichbar machen (docker-compose.yml oder bei Aufruf)
2. Einen Proxy aufs Hostsystem

Es gibt nur Probleme bei Protokollen, die Unicast verwenden. Mann kann zwar dort mit oben genannten "Privileg" arbeiten, besser aber solche Protokolle nativ auf dem System betreiben (z.B. dhcp) .. oder durch passende andere ersetzen.

Nur so als Hinweis:
Am besten ein Container eine Software. Leider gibt es fertige Container, die es anders machen, nur sinnvoller ist es so. Stichwort "Microservices".

@Sidey
der Speedtest-Container hat nur den Nachteil, das er praktisch wie ein CLI arbeitet, also nicht als Deamon. Mann kann einen Container aus einem Container aufrufen, nur würde ich einem Anfänger dieses nicht empfehlen ... und im falle des FHEM-Container definitif nicht machen .......
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 05 Januar 2023, 11:00:11
Zitat von: Gear am 05 Januar 2023, 10:42:49

Hier muss z.B. das pip FHEM installiert werden, wie in dem Thema von mir: https://forum.fhem.de/index.php/topic,123963.msg1185197.html#msg1185197
Benötigt wird z.B.:
sudo apt-get install python3-pip
pip3 install fhem


Bis eben wusste ich nicht, dass es ein Python Paket mit dem Namen fhem gibt.
Wenn ich das richtig verstanden habe, fungiert es doch als eine Art Proxy.
Könnte das nicht problemlos in einem eigenen Container laufen und via TCP mit FHEM kommunizieren?

Ansonaten. Jeder Container bekommt eine eigene IPAdresse im Docker Netzwerk.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 05 Januar 2023, 11:09:18
@Wernieman

Ich kenne das so vom QNAP Docker: MAC Generieren + Bridge wählen
Dann meldet sich an der FritzBox ein "Netzwerk Gerät" mit der IP und der MAC.

Aber auf OMV mit Docker und Portainer ist das alles irgendwie anders, bzw. ich bin zu blöd.  ;D
Hatte bisher alles auf einem RPi4 ohne Docker, nun bin ich auf einen ODRIOD H3 gewechselt, weil der Pi mit 2 GB langsam zu schwach war...

@Sidey
Ob man das Python-Scrip auslagern kann ist eine gute Frage, glaube aber eher nicht.
Das Script wird quasi wie ein Paket behandelt, also per Update von GIT auf FHEM heruntergeladen. (Einfacher wegen Updates)
Dann wird das direkt aus FHEM aufgerufen und läuft als eine Art SUB.
Vermutlich müsste ich dann mein Script komplett umbauen...

"python3 /opt/fhem/FHEM/98_BackUp2FTP.py <fhemIP> <fhemPort> <fhemProtocol> <fhemUser> <fhemPass> <BackUp-Device> &"
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 05 Januar 2023, 11:28:19
Zitat von: Gear am 05 Januar 2023, 11:09:18
@Wernieman


Dann wird das direkt aus FHEM aufgerufen und läuft als eine Art SUB.
Vermutlich müsste ich dann mein Script komplett umbauen...

"python3 /opt/fhem/FHEM/98_BackUp2FTP.py <fhemIP> <fhemPort> <fhemProtocol> <fhemUser> <fhemPass> <BackUp-Device> &"

Eine Variante von Otto wäre, dass das Script nicht im Container sondern beispielsweise auf dem Host oder in einem anderen Container läuft.

Container können volumes untereinander teilen. Diese können auch auf dem Host liegen.

Ich mache es mittlerweile ganz anders und das gefällt mir bisher am besten:

Ich habe einen duplicati Container, in dem ich das FHEM Verzeichnis eingebunden habe.
Der Duplicati Container erledigt das Backup völlig unabhängig von FHEM nach einem Zeitplan und kopiert es auch mittels sftp auf ein anderes System. Schmiert FHEM ab, läuft das Backup trotzdem.
Die Datenbank wird über das DBrep Modul bereinigt (deduplizieren)
Da ein Backup der Datenbank so eine Sache ist, fertige ich jeden Tag von dem Vortrag einen Export an (auch über DBrep) was mit in dem Duplicati Backup landet.

Es gefällt mir so, weil ich im Container keine Dinge nachinstallieren oder konfigurieren müsste.
Alles läuft über normale Prozeduren der jeweiligen Images und der Host hat damit auch nichts am Hut.

Vielleicht hilft dir das ja bei deiner Lösungsfindung weiter.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 05 Januar 2023, 13:48:49
Zitat von: Gear am 05 Januar 2023, 10:42:49
Wollte den Containern eigene IP + MAC geben, funzt nicht, MQTT in separaten Container läuft nicht...
Klingt nach Hostmodus? Braucht man normal nicht, nicht für FHEM.
MQTT gibt es doch jede Menge Container? Was läuft denn da nicht? Nicht gleich aufgeben und selbst für Blöd erklären. Nachfragen, Problem schildern - meist ist der Ansatz zur Lösung bloß etwas anders ;)

Wie schon gesagt: es ist keine VM oder PC - es ist Docker. Da ist es alles etwas anders.  ;)
Aber wenn man das so hin nimmt und versucht zu verstehen - ist es genial.
Sicher aber auch nicht die die universelle Lösung für alles.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 05 Januar 2023, 13:55:37
Und wie mache ich das dann bei -e APT_PKGS="package1"?

sudo apt-get install python3-pip
pip3 install fhem


@Otto
Ne, ich gebe nicht auf, es frustriert nur...  :P

MQTT kann FHEM auch, ich weiß.
Nur nutze ich MQTT noch abseits von FHEM, darum brauche ich das separat.

MQTT wäre hier eher OT.
Theoretisch läuft es, also laut Portainer, wenn jetzt FHEM verbinden will, dann verbindet es, und verliert die Verbindung gleich wieder.
Habe das so auf einem anderen RPi ohne Docker getestet, da geht es, als von der Config her.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 05 Januar 2023, 14:01:36
Zitat von: Gear am 05 Januar 2023, 13:55:37
MQTT kann FHEM auch, ich weiß.
Nur nutze ich MQTT noch abseits von FHEM, darum brauche ich das separat.

MQTT wäre hier eher OT.
Theoretisch läuft es, also laut Portainer, wenn jetzt FHEM verbinden will, dann verbindet es, und verliert die Verbindung gleich wieder.
Habe das so auf einem anderen RPi ohne Docker getestet, da geht es, als von der Config her.
Das ist doch völlig ok, wenn man den MQTT lieber separat haben will. Dann mach doch einfach einen separaten Thread auf und beschreibe kurz Dein Scenario und was Du versucht hast.
Das haben viele so laufen, auch unter Docker.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 05 Januar 2023, 14:19:30
ZitatIch kenne das so vom QNAP Docker: MAC Generieren + Bridge wählen
Dann meldet sich an der FritzBox ein "Netzwerk Gerät" mit der IP und der MAC.
Also macht QNAP aus dem Container eine "Pseudo VM" ......

Der Vorteil von "fertigen" Containern ist normalerweise, das Du bei einem Update nicht den Container updatest, sondern einfach "nur" austauscht. Deshalb sollte der Container auch möglichst nachträglich nicht verändert werden .. denn nach jedem Update müsste man das bei seinen eigenen immer wieder machen.

Ansonsten stimme ich Otto zu, erkläre doch bitte nochmals, was Du genau willst ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 05 Januar 2023, 15:19:08
Zitat von: Wernieman am 05 Januar 2023, 14:19:30
Ansonsten stimme ich Otto zu, erkläre doch bitte nochmals, was Du genau willst ....

Also, auf meinem PRi4 (ohne Docker) nutze ich aktuell Python Scripte, um Dinge auszuführen.
Und um diese nutzen zu können, brauche ich "pip3 fhem", also vor der Nutzung muss ich das erstmal installieren:
sudo apt-get install python3-pip
pip3 install fhem


Meine Scripte möchte ich nicht in ein zusätzliches Docker auslagern, da installiere ich mir FHEM lieber direkt darauf ohne Docker.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 05 Januar 2023, 16:06:13
Zitat von: Gear am 05 Januar 2023, 15:19:08
Also, auf meinem PRi4 (ohne Docker) nutze ich aktuell Python Scripte, um Dinge auszuführen.
Und um diese nutzen zu können, brauche ich "pip3 fhem", also vor der Nutzung muss ich das erstmal installieren:
sudo apt-get install python3-pip
pip3 install fhem


Meine Scripte möchte ich nicht in ein zusätzliches Docker auslagern, da installiere ich mir FHEM lieber direkt darauf ohne Docker.
Moin,
ich habe das beim .yml so eingetragen

    environment:
      PIP_PKGS: "vallox_websocket_api fhem beautifulsoup4"
      CPAN_PKGS: "Crypt::OpenSSL::AES XML::Bare XML::Bare Protocol::WebSocket::Handshake::Server Crypt::Rijndael Crypt::Random --verbose"


Generell versuche ich immer alles aus Phyton direkt ins FHEM zu integrieren.

VG   Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 05 Januar 2023, 18:32:57
Moin!

Uh, ich glaube das kann mir helfen!
Muss ich gleich mal versuchen, Danke. :)

Grüße
Gear
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fhemjan am 07 Januar 2023, 00:52:22
Mal wieder eine kurze Frage von mir:
Möchte einen HmLAN einbinden. Muss ich dazu etwas am Cpntainer ändern um auf das Device im Netzwerk zugreifen zu können? Er gibt mir beim device ein disconnected in fhem.
Thread: https://forum.fhem.de/index.php/topic,130193.msg1256118.html#msg1256118
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 07 Januar 2023, 11:04:00
Zitat von: Gear am 05 Januar 2023, 18:32:57
Uh, ich glaube das kann mir helfen!
Muss ich gleich mal versuchen, Danke. :)
Hallo Gear,
generell ist so ziemlich alles im FHEM Docker Container bereits beinhaltet, jedoch benötigen einige Module trotsdem noch weitere Bibliotheken. Diese kann man dann wie beschrieben noch beim Erstellen des Containers dazu installieren lassen. Wenn der Container dann man aktualisiert wird wird das dann auch immer wieder nachgezogen. Über die Container Konsole solltest Du nichts manuell installieren, da Du das ansonsten jedes mal neu machen musst.

VG  Christian
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 07 Januar 2023, 11:24:25
@ch.eick
Hab das heute mal wie von dir beschrieben getestet, Läuft.

Mal so generell gefragt, begrenzt ihr die Ressourcen? (CPU + RAM)

Nutze aktuell 13 Container, beim DMS und den OCR-Containern begrenze ich die Ressourcen.

Edit:
Zur Hardware:
Odroid H3, 64 GB RAM, 500 GB NVME, 2x 1 TB SSD gespiegelt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 07 Januar 2023, 11:31:24
Zitat von: fhemjan am 07 Januar 2023, 00:52:22
Mal wieder eine kurze Frage von mir:
Möchte einen HmLAN einbinden. Muss ich dazu etwas am Cpntainer ändern um auf das Device im Netzwerk zugreifen zu können? Er gibt mir beim device ein disconnected in fhem.
Thread: https://forum.fhem.de/index.php/topic,130193.msg1256118.html#msg1256118
Nein, die Geräte können normal aufs Netzwerk zugreifen. Hier schreibst Du HMLAN im Link schreibst Du HMUARTLGW - das verwirrt. Das sind zwei völlig unterschiedliche Geräte.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ch.eick am 07 Januar 2023, 12:38:43
Zitat von: Gear am 07 Januar 2023, 11:24:25
Mal so generell gefragt, begrenzt ihr die Ressourcen? (CPU + RAM)
Ich habe einen RPI4 mit 4 GB RAM und einer 250 GB SSD, da gibt es nichts zu begrenzen :-)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 07 Januar 2023, 12:43:24
Ok, würdet ihr das begrenzen, wenn kein RPi genutzt werden würde? *lach*
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 07 Januar 2023, 13:06:35
Kommt auf den Container und die Software drauf an .. bei einigen Containern begrenze ich, bei an deren nicht ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: fhemjan am 07 Januar 2023, 14:44:09
Zitat von: Otto123 am 07 Januar 2023, 11:31:24
Nein, die Geräte können normal aufs Netzwerk zugreifen. Hier schreibst Du HMLAN im Link schreibst Du HMUARTLGW - das verwirrt. Das sind zwei völlig unterschiedliche Geräte.
Oh, sorry. Ich dachte das wäre das gleiche. Es ist ein HM-MOD-RPI-PCB mit LAN-TTL Adapter
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 09 Januar 2023, 12:34:01
Zitat von: Gear am 07 Januar 2023, 12:43:24
Ok, würdet ihr das begrenzen, wenn kein RPi genutzt werden würde? *lach*
Vermutlich ziehst du dir mit begrenzen mehr Komplexität rein als es dir nutzt. Solange Kapazität da ist, lass die Container auf Hardware zugreifen. Wenn kurz mal ein 100% Peak ist, who cares?

PRIVAT begrenze ich nciht. Die Container sollen sich das "unter sich" ausmachen. Ich habe aber ein Script per Cronjob das prüft ob ein Container Amok läuft und dann wird der neu gestartet.

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 09 Januar 2023, 17:43:49
@kadettilac89
Ja, das wäre mein Vorhaben.
Wobei ich das erstmal testen muss, da OCR + DMS schon gerne die CPU stressen. :P
> OCR + DMS hab ich eine begrenzung drin, da das nicht ganz so wichtig ist, FHEM und co. darf nutzen was sie bekommen.

Gibt es da was Fertiges oder hast du das selbst gebastelt?
> Also das Amok prüfen.

Sitze gerade eh am anderen Ende von Deutschland und kann eh nur per VPN nach Hause telefonieren.  8)

Danke!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 09 Januar 2023, 19:13:37
Zitat von: Gear am 09 Januar 2023, 17:43:49
@kadettilac89

Gibt es da was Fertiges oder hast du das selbst gebastelt?
> Also das Amok prüfen.


selbst gebastelt. Hab nichts fertiges gefunden und mir dann selber schnell ein Script gebastelt.
Edit: nicht fertiges was schlank war und meine Anforderungen erfüllt hat.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 09 Januar 2023, 22:31:51
Zitat von: Gear am 07 Januar 2023, 12:43:24
Ok, würdet ihr das begrenzen, wenn kein RPi genutzt werden würde? *lach*

Das hat mit dem RPI eher weniger zu tun.
Ich begrenze meinem FHEM Container den RAM. Das hat einen simplen Grund: Der Speicherverbrauch steigt stetig an.
Wenn ich den Container nicht begrenze, dann hat der Container irgendwann mal alle Ressourcen vom System geschluckt.

Wenn das RAM Limit erreicht ist, kann der Container nicht mehr allokieren was zu einem Neustart des containers führt.
Zugegeben, die Ursache liegt woanders, aber mir war das zu blöd, dass ein Container den Speicher schluckt.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 09 Januar 2023, 22:58:03
@Sidey
Den Gedanken hatte ich auch, mein DMS hatte im NAS immer den RAM verschluckt und nach dem Begrenzen ging es.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 16 Januar 2023, 11:09:18
Gibt es da Größen, die sinnvoll für FHEM einzustellen sind?
Ich habe zwar einen NUC mit i7 und 32 GB RAM, aber mittlerweile auch über 50 Container am Laufen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 16 Januar 2023, 15:17:49
Kommt auf die Software drauf an. Gibt wenig Pauschale Möglichkeiten, Dir da einen Rat zu geben.

Habe hier z.B. einen LIRC-Container sehr reduziert (braucht praktisch kein RAM), eine DB dagegen .....

Gucke Dir doch einfach mal mit "docker stats" die Auslastung der Container an.

WOW .. 50 Container .. was fährst Du denn so alles?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 17 Januar 2023, 10:10:33
Zitat von: volschin am 16 Januar 2023, 11:09:18
Gibt es da Größen, die sinnvoll für FHEM einzustellen sind?
Wie Wernieman gesagt hat, kommt auf die Fhem-Config an.

Meine Installation würde mit irgendwas zwischen 512 - 768 MB zurecht kommen, Ich habe nichts begrenzt. Ich monitore das aus Interesse.


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 19 Januar 2023, 10:27:33
Hallo zusammen,
ich habe da ein Verständnisproblem bei der Nutzung von FHEM im Docker.

Ich habe FHEM auf einer Synology im Docker Container laufen, funktioniet soweit auch sehr gut. Wenn ich nun aber einen Service der Synology nutzen bzw. einbinden möchte, kann ich den Service aber nicht erreichen. Andere Services im Netzwerk der Synology können aber erreicht werden.
Der Hinweis unter https://github.com/fhem/fhem-docker/#connect-to-docker-host-from-within-container (https://github.com/fhem/fhem-docker/#connect-to-docker-host-from-within-container) verwirrt mich leider mehr als das er mir hilft.

Sowohl die DNS Auflösung (google.com) im Container funktioniert, als auch ein Ping auf eine Beliebige IP im Netzwerk der Synology (192.168.178.nn).

Evtl. kann mir hier jemand helfen was ich tun muss um auf die IP des Hosts zuzugreifen.

IP des Containers (Bridge Mode): 172.17.0.6
IP des Hosts (Synology): 192.168.178.33
Verwendetes Modul: SSCAM https://wiki.fhem.de/wiki/SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station (https://wiki.fhem.de/wiki/SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station)

Vielen Dank für jeglichen Hinweis / Erklärung.

Thomas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 19 Januar 2023, 12:00:26
Hallo Thomas,

kannst Du denn den Host pingen? 192.168.178.33 und die 172.17.0.1

Ich vermute ja eher für die SSCAM fehlen Dir Perl Module? Was steht im Log?

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 19 Januar 2023, 12:14:36
Hallo Otto,

die 172.17.0.1 kann ich anpingen, nur eben die IP des Docker Hosts (192.168.178.33) nicht.
Daher die Vermutung das dies was mit Docker bzw. den im Link beschriebenen Optionen zu tun hat.

Die notwendigen Perl Module sind ebenfalls vorhanden.

Gruß, Thomas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 19 Januar 2023, 12:34:41
Würde eher auf ein Problem mit der Synology tippen .... (ein normales) Docker selber hat da keine Beschränkung
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 19 Januar 2023, 12:36:48
in dem Link geht es aber vor allem um Namensauflösung, Du redest ja vom Zugriff über IP Adresse.
Hat die Synology das Forwarding nicht aktiv?
Ich habe keine Synology, ich weiß nur vom Hörensagen: docker ist da speziell. :)

Bei meinem handgeklöppelten Docker Host funktioniert der Zugriff auf die IP des Hosts ohne Probleme.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: ThomasMagnum am 19 Januar 2023, 13:43:40
Vielen Dank erst mal für Euren Input.
Ich hatte eh vor in den nächsten zwei Monaten meine Synology zu aktualisieren, mal sehn ob sich das Ganze mit einer neuen Version erledigen wird.

Gruß, Thomas
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: GammaTwin am 21 Januar 2023, 18:24:03
Grüße,

ich habe zum Jahreswechsel von Ubuntu 18 auf 22 gewechselt. Docker wieder in Betrieb genommen und auch fhem/fhem. Lief sehr problemlos :)

Allerdings steigt der Container seitdem häufiger aus, der Container ist dann unhealthy. Die letzte Meldung lautet:
telnetPort: Can't open server port at 7072: Address already in use. Exiting.

Der Container läuft vorher aber tagelang problemlos. Ich habe als Netzwerktyp Host und Brigde probiert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 21 Januar 2023, 18:35:38
7072: Address already in use.
Läuft bei Dir etwas anderes, was den Port 7072 blockieren könnte?
Eventuell mal als root oder mit sudo (Wenn e zu dem Fehler kommt):
netstat -lntp | grep 7072
ss -tulpe | grep 7072
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: GammaTwin am 22 Januar 2023, 08:07:42
Dann warte ich mal auf den nächsten "Event" :)

Wenn ich FHEM im Netzwerktyp "Bridge" dürfte der Fehler aber überhaupt nicht auftreten, oder? Ich meine mich zu erinnern, dass dies einmal der Fall gewesen ist.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 23 Januar 2023, 09:05:21
Hast Du den Port rausgelinkt?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 23 Januar 2023, 10:59:48
Zitat von: GammaTwin am 22 Januar 2023, 08:07:42
Dann warte ich mal auf den nächsten "Event" :)

Wenn ich FHEM im Netzwerktyp "Bridge" dürfte der Fehler aber überhaupt nicht auftreten, oder? Ich meine mich zu erinnern, dass dies einmal der Fall gewesen ist.
Welches Setup hast du, Ubuntu nativ auf welcher Hardware? Oder irgend welche Virtualisierung dazwischen?

Ich hatte den blockierten 7072 auch ein paarmal, aber nie analyisiert da bei mir im Falle von unhealthy der Container sowieso neu startet. Bin seit einer Weile auf Debian Bookworm (ich weiß, testing) aber hatte die letzte Zeit keine Meldung mehr gesehen. Kann auch Zufall sein.

Alles aktuell bei dir? Ubuntu updates, Docker aktuell, nutzt du docker-compose, auch aktuell? Fhem-Container aktuell?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: GammaTwin am 24 Januar 2023, 19:48:21
Zitat von: kadettilac89 am 23 Januar 2023, 10:59:48
Welches Setup hast du, Ubuntu nativ auf welcher Hardware? Oder irgend welche Virtualisierung dazwischen?

Alles aktuell bei dir? Ubuntu updates, Docker aktuell, nutzt du docker-compose, auch aktuell? Fhem-Container aktuell?

intel-nuc, Ubuntu 22, docker, portainer (nutzt ja docker compose), alles aktuell.

Zitat von: Wernieman am 23 Januar 2023, 09:05:21
Hast Du den Port rausgelinkt?

Nein, habe ich nicht. Ich betreibe es mal Modus Bridge und schaue ob der Fehler wieder auftritt.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 28 Januar 2023, 19:38:15
Hiho,

ist gassistant und alexa-fhem nicht mehr im Basis Image enthalten? Hab eben meinen docker Server umgezogen da wurde das aktuelle Image gepollt und fhem meckert, dass ich alexa-fhem erst per npm installieren soll...
--- edit ---
Ach, habs Grad bei GitHub gelesen, muss wohl per variable installiert werden :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 28 Januar 2023, 20:18:11
Zitat von: link611 am 28 Januar 2023, 19:38:15
dass ich alexa-fhem erst per npm installieren soll...

Für Alexa-fhem gibt es einen separaten. Container.
NodeJS wird aus dem FHEM (Perl) Container in naher Zukunft verschwinden.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 28 Januar 2023, 20:51:01
Zitat von: Sidey am 28 Januar 2023, 20:18:11
Für Alexa-fhem gibt es einen separaten. Container.
NodeJS wird aus dem FHEM (Perl) Container in naher Zukunft verschwinden.

Grüße Sidey

den separaten Container hatte ich früher mal, aber dann war alexa-fhem ja im basis-image mit integriert.
Hab jetzt auch mal wie folgt versucht die nötigen Pakete zu installieren:


     environment:
       - APT_PKGS="libxml-bare-perl"
       - NPM_PKGS="alexa-fhem gassistant-fhem"


das funktioniert aber irgendwie nicht...
hab jetzt die Installation mit in die pre-init.sh rein gepackt, das scheint auch zu klappen :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 28 Januar 2023, 21:16:51
Zitat von: link611 am 28 Januar 2023, 20:51:01
den separaten Container hatte ich früher mal, aber dann war alexa-fhem ja im basis-image mit integriert.
Hab jetzt auch mal wie folgt versucht die nötigen Pakete zu installieren:


     environment:
       - APT_PKGS="libxml-bare-perl"
       - NPM_PKGS="alexa-fhem gassistant-fhem"


Alexa-Fhem ist schon lange nicht mehr im FHEM (Perl) Container integriert. Die Installation von Zusätzlichen Packages ist zu vermeiden. Nimm den Container für Alexa FHEM:

Aktuelleres NodeJS
alexa-fhem ist installiert
Zum Updaten einfach nur das neue Image laden und starten. Downtime ca. 3 Sekunden ;)

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 28 Januar 2023, 21:36:10
Zitat von: Sidey am 28 Januar 2023, 20:18:11
Für Alexa-fhem gibt es einen separaten. Container.
NodeJS wird aus dem FHEM (Perl) Container in naher Zukunft verschwinden.
Zitat von: Sidey am 28 Januar 2023, 21:16:51
Die Installation von Zusätzlichen Packages ist zu vermeiden.
Damit ist dann auch google assistant raus. Wird es dann einen separaten Container mit nodejs geben, oder muss das alles in Zukunft per Parameter nachinstalliert werden?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 28 Januar 2023, 21:52:54
Zitat von: kadettilac89 am 28 Januar 2023, 21:36:10
Damit ist dann auch google assistant raus. Wird es dann einen separaten Container mit nodejs geben, oder muss das alles in Zukunft per Parameter nachinstalliert werden?

Wer selbst Pakete installieren möchte, ist mit einer VM besser bedient. Ich bau das ja nicht aus, weil es so easy installiert werden kann.

NodeJS Images gibt es schon, Nutzbar werden die erst, wenn jemand ein Image mit einer spezifischen Anwendung erstellt.
Für google assistant ist mir jetzt keiner bekannt, aber ich nutze diesen Assistenten auch selbst nicht.


Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 29 Januar 2023, 22:03:07
Zitat von: Sidey am 28 Januar 2023, 21:16:51
Alexa-Fhem ist schon lange nicht mehr im FHEM (Perl) Container integriert. Die Installation von Zusätzlichen Packages ist zu vermeiden. Nimm den Container für Alexa FHEM:

Aktuelleres NodeJS
alexa-fhem ist installiert
Zum Updaten einfach nur das neue Image laden und starten. Downtime ca. 3 Sekunden ;)

Grüße Sidey

habs eben mal mit dem alexa-fhem Container probiert, bin aber kläglich gescheitert, habe hier das gleiche Problem wie schon einige vorschreiberlinge haben
die Connection vom alexa-fhem zum fhem Container funktioniert, aber der fhem Container bekommt keine SSH Verbindung zum alexa-fhem container...

{
  "sshproxy" : {
    "description" : "FHEM Connector",
    "ssh" : "/usr/bin/ssh"
  },
  "connections": [
      {
        "name": "FHEM",
        "webname": "fhem",
        "filter": "room=Alexa",
        "uid": "6062",
        "port": "8087",
        "server": "192.168.205.15"  <--- das ist die IP vom FHEM-Container
      }
    ]
}
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 29 Januar 2023, 22:26:43
Zitat von: link611 am 29 Januar 2023, 22:03:07
habs eben mal mit dem alexa-fhem Container probiert, bin aber kläglich gescheitert, habe hier das gleiche Problem wie schon einige vorschreiberlinge haben
die Connection vom alexa-fhem zum fhem Container funktioniert, aber der fhem Container bekommt keine SSH Verbindung zum alexa-fhem container...

Der fhem Container braucht keine SSH Verbindung zum alexa-fhem container

Folgende Definition ist nötig:

define alexa alexa
attr alexa alexaFHEM-host alexa-fhem


In der alexa-fhem.cfg (die im alexa-fhem container) ist der Eintrag des ssh_proxy nötig:
https://github.com/fhem/alexa-fhem-docker/blob/dev/src/config.json#L13

Anstatt IP Addressen zu hinterlegen, solltest Du den Namen des containers hinterlegen, IP Addressen ändern sich gerne mal.

Edit:
Hast Du in FHEM die Zugriffe auf den Port 8087 auch für alexa-fhem freigegeben?


Grüße Sidey

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 30 Januar 2023, 08:03:05
Zitat von: Sidey am 29 Januar 2023, 22:26:43
Der fhem Container braucht keine SSH Verbindung zum alexa-fhem container
naja, aber dann versucht mein alexa device alle paar sekunden das device zu starten, schlägt aber jedes mal mit dem Fehler dass er über Port 22 connecten kann fehl.
zudem bekomme ich anscheinend den falschen accesstoken, den von meiner vorherigen lokalen alexa-fhem installation und nicht den vom container...

Zitat von: Sidey am 29 Januar 2023, 22:26:43
Folgende Definition ist nötig:

define alexa alexa
attr alexa alexaFHEM-host alexa-fhem

brauch ich auch zwingend die definitionen mit dem Port 3000 etc? Das war doch damals für den Custom Skill, den ich eigtl. gar nicht mehr nutze...

Zitat von: Sidey am 29 Januar 2023, 22:26:43
In der alexa-fhem.cfg (die im alexa-fhem container) ist der Eintrag des ssh_proxy nötig:
https://github.com/fhem/alexa-fhem-docker/blob/dev/src/config.json#L13
Bei mir ist das die alexa-fhem.json, sollte ja auch passen oder nicht? Und wie oben geschrieben, ist der Wert für den Proxy drin.

Zitat von: Sidey am 29 Januar 2023, 22:26:43
Anstatt IP Addressen zu hinterlegen, solltest Du den Namen des containers hinterlegen, IP Addressen ändern sich gerne mal.

Habe mit der Docker Compose File feste IPs vergeben in den jeweiligen Netzen, weil ich schon Probleme mit der Namensauflösung hatte.

Zitat von: Sidey am 29 Januar 2023, 22:26:43
Edit:
Hast Du in FHEM die Zugriffe auf den Port 8087 auch für alexa-fhem freigegeben?


Grüße Sidey
ja, wie gesagt, alexa-fhem hat Zugriff auf fhem, aber oben genannte Probleme habe ich aktuell noch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 30 Januar 2023, 08:16:53
Zitat von: link611 am 30 Januar 2023, 08:03:05
naja, aber dann versucht mein alexa device alle paar sekunden das device zu starten, schlägt aber jedes mal mit dem Fehler dass er über Port 22 connecten kann fehl.

Schick doch bitte ein List von der Alexa Definition.
Vermutlich hast Du ein Attribute gesetzt, dass zu dem SSH Connect führt.
Das Alexa Modul selbst ist leider nicht docker aware. Bisher fehlte mir da einfach die Lust einen patch einzureichen.

Den Port 3000 brauchst Du nach außen nur für den custom Skill, sonst nicht.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 30 Januar 2023, 08:28:57
Zitat von: Sidey am 30 Januar 2023, 08:16:53
Schick doch bitte ein List von der Alexa Definition.
Vermutlich hast Du ein Attribute gesetzt, dass zu dem SSH Connect führt.
Das Alexa Modul selbst ist leider nicht docker aware. Bisher fehlte mir da einfach die Lust einen patch einzureichen.

Den Port 3000 brauchst Du nach außen nur für den custom Skill, sonst nicht.

Grüße Sidey

Internals:
   FUUID      5f10b08f-f33f-9205-0b5f-f9adc398bb900b97
   FVERSION   39_alexa.pm:0.238200/2021-02-24
   LAST_START 2023-01-30 09:59:00
   LAST_STOP  2023-01-30 09:59:00
   NAME       alexa
   NOTIFYDEV  global,global:npmjs.*alexa-fhem.*
   NR         270
   NTFY_ORDER 50-alexa
   PARTIAL   
   STARTS     14
   STATE      stopped
   TYPE       alexa
   active     0
   alexa-fhem version 0.5.64
   eventCount 28
   logfile    ./log/alexa-%Y-%m-%d.log
   CoProcess:
     cmdFn      alexa_getCMD
     name       alexaFHEM
     state      stopped
   READINGS:
     2023-01-30 09:59:00   alexaFHEM       stopped
     2023-01-30 09:40:05   alexaFHEM.ProxyConnection running; SSH connected
     2023-01-30 09:34:45   alexaFHEM.bearerToken crypt:XXXXXXXXXXXXXX
     2023-01-30 09:34:45   alexaFHEM.skillRegKey crypt:XXXXXXXXXXXXXX
   helper:
Attributes:
   alexaFHEM-auth crypt:XXXXXXXXXXXXXXXXXX
   alexaFHEM-config ./alexa-fhem.cfg
   alexaFHEM-host 192.168.205.17
   alexaFHEM-log ./log/alexa-%Y-%m-%d.log
   alexaMapping #Characteristic=<name>=<value>,...
On=verb=schalte,valueOn=an;ein,valueOff=aus,valueToggle=um

Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

Hue=verb=stelle,valuePrefix=auf,values=rot:0;grün:128;blau:200
Hue=verb=färbe,values=rot:0;grün:120;blau:220

Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER
Saturation=verb=sättige,values=AMAZON.NUMBER

TargetPosition=verb=mach,articles=den;die,values=auf:100;zu:0
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad

Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

#Weckzeit=verb=stelle,valuePrefix=auf;für,values=AMAZON.TIME,valueSuffix=uhr
   alexaTypes #Type=<alias>[,<alias2>[,...]]
light=licht,lampen
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
   devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
   echoRooms  #<deviceId>=<room>

   fhemIntents #IntentName=<sample utterance>
gutenMorgen=guten morgen
guteNacht=gute nacht
   group      Devices
   icon       alexa2
   persons    #<personId>=<name>

   room       System
   stateFormat alexaFHEM


hier noch das list vom Port 8087
Internals:
   BYTES_READ 10416
   BYTES_WRITTEN 1387261
   CONNECTS   49
   CSRFTOKEN  csrf_480562466812741
   DEF        8087 global
   FD         16
   FUUID      5c77c6ac-f33f-9205-8b6a-95d1906c8e3a8507
   NAME       WEBAlexa
   NR         182
   NTFY_ORDER 50-WEBAlexa
   PORT       8087
   STATE      Initialized
   TYPE       FHEMWEB
   READINGS:
     2023-01-30 08:23:50   state           Initialized
Attributes:
   HTTPS      0
   allowfrom  127.0.0.1|192.168.9.3|192.168.205.17


Hier noch das Log:

2023.01.30 10:00:00.029 3: alexa: using ssh cmd /usr/bin/ssh 192.168.205.17
ssh: connect to host 192.168.205.17 port 22: Connection refused
ssh: connect to host 192.168.205.17 port 22: Connection refused
2023.01.30 10:00:00.069 2: alexa: starting alexa-fhem: /usr/bin/ssh 192.168.205.17  -c /tmp/alexa-fhem.cfg -a xx:xx -s
2023.01.30 10:00:00.073 3: alexa: starting
2023.01.30 10:00:00.082 3: alexa: using logfile: ./log/alexa-2023-01-30.log
2023.01.30 10:00:00.093 3: alexa: read: end of file reached while sysread
2023.01.30 10:00:00.093 3: alexa: stopped



--- edit ---
was mir gerade noch aufgefallen ist, ich hab ja noch meine alexa-fhem.cfg im fhem Verzeichnis liegen, mit den alten Daten, hat es evtl. damit was zu tun? - hab die jetzt zur Sicherheit mal umbenannt, daher die Meldung dass alexa-fhem.cfg nicht gefunden werden kann.

--- edit2 ---
so, hab jetzt nochmal von vor meinem Umzug die alexa-fhem.cfg und fhem.cfg von der alten Maschine kopiert. der alexa-fhem container connected jetzt sauber zu amazon und befehle gehen auch wieder. aber ich habe weiterhin das ssh problem, ergo zeigt mir fhem, dass das device nicht läuft.
Habe das list alexa oben nochmal abgeändert zu dem, was jetzt aktiv läuft.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 30 Januar 2023, 10:22:22
Zitat von: link611 am 30 Januar 2023, 08:28:57
--- edit2 ---
so, hab jetzt nochmal von vor meinem Umzug die alexa-fhem.cfg und fhem.cfg von der alten Maschine kopiert. der alexa-fhem container connected jetzt sauber zu amazon und befehle gehen auch wieder. aber ich habe weiterhin das ssh problem, ergo zeigt mir fhem, dass das device nicht läuft.
Habe das list alexa oben nochmal abgeändert zu dem, was jetzt aktiv läuft.

Das kannst (musst) du einfach ignorieren... ;) :-\

Das Alexa-Device in fhem versucht ein (lokales) alexa-fhem zu starten: schlägt fehl (weil alexa-fhem in einem separaten Docker läuft / evtl. wenn ssh ohne Passwort dorthin geht/eingerichtet ist)

Ist aber nicht wichtig (ja unschön), da ja alexa-fhem im eigenen Container läuft und da dafür gesorgt wird, dass alexa-fhem gestartet wird/läuft...
(mehr macht das Alexa-Device auch nicht: starten und "überwachen")

Zusätzlich bekommt fhem durch das Alexa-Device noch ein paar Attribute: genericDeviceType/homebridgeMapping

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 30 Januar 2023, 11:04:37
Zitat von: MadMax-FHEM am 30 Januar 2023, 10:22:22
Das kannst (musst) du einfach ignorieren... ;) :-\

Das Alexa-Device in fhem versucht ein (lokales) alexa-fhem zu starten: schlägt fehl (weil alexa-fhem in einem separaten Docker läuft / evtl. wenn ssh ohne Passwort dorthin geht/eingerichtet ist)

Ist aber nicht wichtig (ja unschön), da ja alexa-fhem im eigenen Container läuft und da dafür gesorgt wird, dass alexa-fhem gestartet wird/läuft...
(mehr macht das Alexa-Device auch nicht: starten und "überwachen")

Zusätzlich bekommt fhem durch das Alexa-Device noch ein paar Attribute: genericDeviceType/homebridgeMapping

Gruß, Joachim

aber das Device ballert mir doch das Log zu.....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 30 Januar 2023, 12:47:30
Zitat von: link611 am 30 Januar 2023, 11:04:37
aber das Device ballert mir doch das Log zu.....

verbose setzen?

Attribut disable?
(weil das Device ja eh "nichts" tut)

-> Maintainer bitten auch Docker zu "unterstützen"?

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 30 Januar 2023, 14:09:12
Zitat von: MadMax-FHEM am 30 Januar 2023, 12:47:30
verbose setzen?

Attribut disable?
(weil das Device ja eh "nichts" tut)

-> Maintainer bitten auch Docker zu "unterstützen"?

Gruß, Joachim

Achsooooo das Device braucht es dann ja eigtl. gar nicht mehr =D, kann es ja dann theoretisch auch komplett löschen oder nicht?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 30 Januar 2023, 15:17:34
Zitat von: link611 am 30 Januar 2023, 14:09:12
Achsooooo das Device braucht es dann ja eigtl. gar nicht mehr =D, kann es ja dann theoretisch auch komplett löschen oder nicht?

Hmmm, ich weiß nicht genau wann die "Attribut-Erweiterung" mitkommt, ich denke mindestens 1x definieren (-> "Erweiterung" der Attribute -> userattr global) und dann löschen ist verm. ok.

Außer: du nutzt Cunstom Skill, dann brauchst du (verm.) einige Attribute AM Alexa-Device...

Interessant wäre zu testen, ob dann das "senden" neuer Devices an Amazon/Alexa funktioniert, auch wenn alexa-fhem "woanders" läuft.
Dazu ist das Alexa-Device schon brauchbar.
"Dumm" in der Konstellation ist halt, dass man nicht mehr schön alexa-fhem neustarten kann, wenn man Veränderungen vorgenommen hat.
Dann muss man "hier" halt immer alexa-fhem im eigenen Container nachstarten...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 30 Januar 2023, 17:20:51
Hallo Joachim,
kannst doch den Container über ssh von FHEm aus neu starten?

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 30 Januar 2023, 18:59:27
Zitat von: Otto123 am 30 Januar 2023, 17:20:51
Hallo Joachim,
kannst doch den Container über ssh von FHEm aus neu starten?

Gruß Otto

Kann schon sein...
...weiß ich halt nicht.

Bzw. halt nicht das Alexa-Device (soweit ich weiß)...

Hab hier ja auch nur angefangen mitzuschreiben, weil einiges unklar bzgl. alexa-fhem war (nicht erst jetzt sondern immer wieder mal)... 8)

Ich nutze lieber "bare metal" :)

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 30 Januar 2023, 22:56:37
Zitat von: MadMax-FHEM am 30 Januar 2023, 18:59:27
Bzw. halt nicht das Alexa-Device (soweit ich weiß)...

Wozu muss man den alexa deamon neustarten? Bei mir wird der nur neu gestartet, wenn ich das Image aktualisiere.

Zitat von: MadMax-FHEM am 30 Januar 2023, 18:59:27
Hab hier ja auch nur angefangen mitzuschreiben, weil einiges unklar bzgl. alexa-fhem war (nicht erst jetzt sondern immer wieder mal)... 8)

Das würde ich gerne im alexa-fhem container in die Doku aufnehmen.
Mit attr disable 1 läuft ja vermutlich alles problemlos.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 30 Januar 2023, 23:17:45
Zitat von: Sidey am 30 Januar 2023, 22:56:37
Wozu muss man den alexa deamon neustarten? Bei mir wird der nur neu gestartet, wenn ich das Image aktualisiere.

Neustart bzw. reload (oder eben set Alexa add Device), wenn du ein neues Device für Alexa konfigurierst, damit das an Amazon/Alexa "gemeldet" wird und dort "gefunden" werden kann...

Das wird (verm.) nur funktionieren, wenn das Alexa-Device alexa-fhem "steuern" kann?
(ob das immer [noch] notwendig ist, wenn man an der fhem Konfiguration etwas bzgl. Alexa ändert: keine Ahnung, ich mach das einfach schon aus Gewohnheit ;)  )

Zitat von: Sidey am 30 Januar 2023, 22:56:37
Das würde ich gerne im alexa-fhem container in die Doku aufnehmen.
Mit attr disable 1 läuft ja vermutlich alles problemlos.

Wenn ich da was beisteuern kann: gerne.
Wo?
Allerdings: ich kann nur mit Theorie dienen, testen kann ich nicht was ich beisteuere, da ich kein Docker verwende...
...aber alexa-fhem schon von Beginn an. 8)

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: link611 am 30 Januar 2023, 23:51:02
Also bisher läuft mit disable 1 alles sauber.

Ich hab bisher auch immer das device neu gestartet wenn ich neue Geräte zu Alexa hinzufügen wollte.

--- edit ----
Kann gerne für Tests bereitstehen :)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 31 Januar 2023, 09:26:13
Hallo,
Hin und wieder hängt sich bei mir Fhem im Container auf und bleibt stehen mit unhealthy und startet nicht automatisch neu.
Ich verwende das ganze unter Ubuntu Server mit dem Image ghcr.io/fhem/fhem/fhem-docker:bullseye
Im Log von Portainer sehe ich immer unterschiedliche letzte Zeilen vor dem Stillstand.
An was kann das liegen?
gruß anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 31 Januar 2023, 09:31:40
Zitat von: antonwinden am 31 Januar 2023, 09:26:13
Hallo,
Hin und wieder hängt sich bei mir Fhem im Container auf und bleibt stehen mit unhealthy und startet nicht automatisch neu.
Ich verwende das ganze unter Ubuntu Server mit dem Image ghcr.io/fhem/fhem/fhem-docker:bullseye
Im Log von Portainer sehe ich immer unterschiedliche letzte Zeilen vor dem Stillstand.
An was kann das liegen?
gruß anton
Wie definierst du "Stillstand". Ist der Container an sich noch erreichbar, kannst du dich per console noch zum Container verbinden? Läuft der Fhem-Perl-Prozess noch wenn der Container in unhealthy ist?

Warum sollte sich der Container selbst automatisch starten nur weil der healthcheck nicht "grün" ist? Wenn du das willst musst du das überwachen und triggern. Möglich zum Beispiel mit separatem Container "watchtower" der das übernimmt. Oder Docker an sich in Swarm laufen lassen was aber hiuer zu weit führt.

Edit, ich meinte den container "autoheal". Der startet bei rotem Healthcheck ... watchtower macht was anderes
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 31 Januar 2023, 10:57:06
Zitat von: antonwinden am 31 Januar 2023, 09:26:13
An was kann das liegen?
gruß anton

Du hast keine restart Anweisung hinterlegt?
Sowas wie restart: unless-stopped wäre vermutlich gut geeignet.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 31 Januar 2023, 10:58:25
Zitat von: Sidey am 31 Januar 2023, 10:57:06
Du hast keine restart Anweisung hinterlegt?
Sowas wie restart: unless-stopped wäre vermutlich gut geeignet.

Grüße Sidey
unealthy beim Healthcheck startet nicht wenn du always, on-error setzt. Nur wenn du innerhalb des Containers Prozess 1 killst.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: antonwinden am 31 Januar 2023, 12:39:07
restart ist auf unless -stopped (bei always das gleiche)
Ich dachte der Container startet automatisch neu wenn er unhealthy ist - zumindestens hab ich das so verstanden. wenn nicht ist alles klar.

Fhem ist nicht mehr erreichbar...

gruß anton
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 31 Januar 2023, 13:55:44
Zitat von: antonwinden am 31 Januar 2023, 12:39:07
restart ist auf unless -stopped (bei always das gleiche)
Ich dachte der Container startet automatisch neu wenn er unhealthy ist - zumindestens hab ich das so verstanden. wenn nicht ist alles klar.
Nein, er setzt nur den Health-Status auf unhealthy worauf du, je nach Docker-Umbegung, drauf reagieren kannst. Da Fhem Web nicht erreichbar ist wird ja der auf unhealthy gesetzt.

Meine Frage war, ob im Container noch der Fhem-Perl Prozess läuft. Es kann irgend etwas auf blocking gehen und dann läuft zwar Fehm, aber reagiert nicht mehr.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 31 Januar 2023, 14:14:56
Bevor du dich zu sehr auf Docker fixierst, erstmal normale Fehleranalse, gibts mehrere Threads im Forum und Wiki

https://wiki.fhem.de/wiki/Hilfe!_Mein_FHEM_funktioniert_nicht!#Wie_ist_die_Auslastung_des_FHEM-Servers

Zusätzlich, Loglevel erhöhen (verbose), freezmon/perfmon aktivieren um Freezes zu sehen ... Netzwerkprobleme? Hast du dns als Attribut gesetzt ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 31 Januar 2023, 22:34:56
Zitat von: Sidey am 30 Januar 2023, 22:56:37
Wozu muss man den alexa deamon neustarten? Bei mir wird der nur neu gestartet, wenn ich das Image aktualisiere.
Ich habe mal Alexa eingerichtet. Ich hatte da viele Fragezeichen im Kopf, am Ende lief es viel selbständiger als gedacht :)
Es gibt in der Readme und in den docker-compose ein paar Typos - die arbeite ich in den nächsten Tagen über github mal noch auf. ;)

Die Einträge im Log das alexa-fhem nicht gefunden wird - gab es nur zweimal beim Start. Ich habe das alexa device in FHEM nicht deaktiviert.

Wenn man in FHEM ein Gerät neu zu alexa zugeordnet hat, muss man den Container neu starten damit Alexa es im Anschluss findet.
Ich schau mir das an und mach mal ein HowTo !?

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 31 Januar 2023, 22:58:54
Zitat von: Otto123 am 31 Januar 2023, 22:34:56

Wenn man in FHEM ein Gerät neu zu alexa zugeordnet hat, muss man den Container neu starten damit Alexa es im Anschluss findet.

Reicht da nicht ein, Alexa suche neue Geräte?
Ich lege so selten was neues an, das ich in Alexa brauche ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 31 Januar 2023, 23:41:24
Zitat von: Sidey am 31 Januar 2023, 22:58:54
Reicht da nicht ein, Alexa suche neue Geräte?
Ich lege so selten was neues an, das ich in Alexa brauche ;)

Es ist "zweistufig":

alexa-fhem muss das Device in fhem "erkennen", dazu min. "reload" oder Neustart (gefühlt für den Anwender kein Unterschied)...

"melden" an Amazon bzw. auf "Anfrage" : Alexa suche...

Alternativ: set Alexa-Device add Device

Dadurch wird es direkt (ohne Alexa suchen zu lassen) an Alexa/Amazon weitergereicht...
(nutze ich aber eher selten / hat nicht immer zuverlässig funktioniert?)

Wobei (gefühlt) Alexa/Amazon auch ohne "Aufforderung" ab und an (einfach so) selber sucht...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 Februar 2023, 09:39:16
Ausgangspunkt: FHEM weiß nichts von Alexa, FHEM läuft im docker, Alexa ist neu "angemeldet" mit Alexa-App. (bei der Web Seite wie im Wiki empfohlen gibt es offenbar die Skills nicht mehr)

So habe ich es erlebt, erste Einrichtung:
Weiter im Betrieb:
Neues Gerät angelegt, Container neu gestartet, Alexa Geräte Suche (die ist schwer zu finden?), danach Gerät verfügbar. Ob es auch einfacher/anders geht habe ich jetzt erkannt. set alexa reload kommuniziert mit dem Container aber hat bei mir nichts bewirkt (Müsste man nochmal untersuchen wenn Joachim sagt es ist gleich restart))

Im laufenden Betrieb habe ich jetzt keine Log-EInträge vom alexa Device. Nur ein set alexa restart erzeugt einen Eintrag "alexa-fhem not installed ..."
@link611 Hast Du irgendwas definiert was diesen Befehl zyklisch auslöst?

Ansonsten ist im alexa Device auch die Welt in Ordnung, es zeigt die Kommunikation mit dem Vereins Connector an. Und das Reading mit dem Eintrag stopped; alexa-fhem not installed. - klar ist so. Weiß ich ja :)

Gruß Otto
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 01 Februar 2023, 16:18:28
Wenn ich Zeit hab, spiele ich mit einer "bare metal" (fhem und alexa-fhem auf demselben PI nativ installiert Installation mal durch...
Ob restart und reload tatsächlich "gleich" sind (zumindest bzgl. suchen/finden neuer Devices).

Was ich auch (noch mal) teste ist set Alexa add NewDevice

Damit sollen neue Devices direkt (ohne restart/reload) an Amazon gemeldet werden...

Ja, leider geht immer weniger per Web, vieles nur noch per App (oder Sprache: "Alexa suche smarte Geräte")...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: GammaTwin am 05 Februar 2023, 14:30:56
Zitat von: GammaTwin am 21 Januar 2023, 18:24:03
Grüße,

ich habe zum Jahreswechsel von Ubuntu 18 auf 22 gewechselt. Docker wieder in Betrieb genommen und auch fhem/fhem. Lief sehr problemlos :)

Allerdings steigt der Container seitdem häufiger aus, der Container ist dann unhealthy. Die letzte Meldung lautet:
telnetPort: Can't open server port at 7072: Address already in use. Exiting.

Der Container läuft vorher aber tagelang problemlos. Ich habe als Netzwerktyp Host und Brigde probiert.

Der Fehler ist erneut aufgetreten. Ich habe einen Thread dazu erstellt.
https://forum.fhem.de/index.php/topic,132048.0.html (https://forum.fhem.de/index.php/topic,132048.0.html)

Für Hilfe wäre ich dankbar.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 24 Februar 2023, 16:06:07
Hallo,
ich befinde mich gerade mitten im Wechsel vom damaligen Image das Cooltux gebaut hat auf aktuelles FHEM Image
Das ganze nun über folgende docker-compose gestartet und läuft auch soweit.
version: '2.3'

networks:
  fhem_net:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/28
          gateway: 172.27.0.1
        - subnet: fd00:0:0:0:27::/80
          gateway: fd00:0:0:0:27::1


services:
  # Minimum example w/o any custom environment variables of fhem container
  fhem:
    image: ghcr.io/fhem/fhem/fhem-docker:bullseye
    restart: always
    networks:
      - fhem_net
    ports:
      - "8083:8083"
      - "1883:1883"
    volumes:
      - "/volume1/docker/fhem/:/opt/fhem/"

# Minimum example w/o any custom environment variables of alexa-fhem container
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    restart: always
    networks:
     - fhem_net
    ports:
      - "3000:3000"
    volumes:
      - "/volume1/docker/alexa-fhem/:/alexa-fhem/"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Berlin

Nur alexa-fhem will nicht starten:
alexaFHEM     stopped

altes Alexa Gerät habe ich gelöscht und neues über
define alexa alexa
attr alexa alexaFHEM-host alexa-fhem
erstellt.

Normal müsste das Alexa-Device doch nun auf grün springen und dann kann ich Alexa mit FHEM neu verbinden oder?

Im alexa.log steht was von
Unknown cipher type '/tmp/alexa-fhem.cfg'
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 24 Februar 2023, 16:24:59
das alexaFHEM     stopped kannst Du vergessen, es gibt ja den Dienst nicht.
Das ist wichtig!
alexaFHEM.ProxyConnection running; SSH connected

Hast Du hier eine config stehen? /volume1/docker/alexa-fhem/
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 24 Februar 2023, 16:44:58
Zitat von: Otto123 am 24 Februar 2023, 16:24:59
alexaFHEM.ProxyConnection running; SSH connected
Okay das müsste ein Reading sein oder? Das fehlt aber
Internals:
   CFGFN     
   FUUID      63f8cef4-f33f-487e-8b86-0de27c80269f2a33
   FVERSION   39_alexa.pm:0.238200/2021-02-24
   LAST_START 2023-02-24 16:42:15
   LAST_STOP  2023-02-24 16:42:15
   NAME       alexa
   NOTIFYDEV  global,global:npmjs.*alexa-fhem.*
   NR         205
   NTFY_ORDER 50-alexa
   PARTIAL   
   STARTS     153
   STATE      stopped
   TYPE       alexa
   eventCount 310
   logfile    ./log/alexa-%Y-%m-%d.log
   CoProcess:
     cmdFn      alexa_getCMD
     name       alexaFHEM
     state      stopped
   READINGS:
     2023-02-24 16:42:15   alexaFHEM       stopped
     2023-02-24 15:51:32   alexaFHEM.bearerToken crypt:23000075010820522524770004277727
     2023-02-24 15:51:32   alexaFHEM.skillRegKey crypt:247600050407234e26210f010353712157535103247627544b23030925075b72547179750404232020
   helper:
   hmccu:
Attributes:
   alexaFHEM-config ./alexa-fhem.cfg
   alexaFHEM-host alexa-fhem
   alexaFHEM-log ./log/alexa-%Y-%m-%d.log
   alexaMapping #Characteristic=<name>=<value>,...
On=verb=schalte,valueOn=an;ein,valueOff=aus,valueToggle=um

Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

Hue=verb=stelle,valuePrefix=auf,values=rot:0;grün:128;blau:200
Hue=verb=färbe,values=rot:0;grün:120;blau:220

Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER
Saturation=verb=sättige,values=AMAZON.NUMBER

TargetPosition=verb=mach,articles=den;die,values=auf:100;zu:0
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad

Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

#Weckzeit=verb=stelle,valuePrefix=auf;für,values=AMAZON.TIME,valueSuffix=uhr
   alexaTypes #Type=<alias>[,<alias2>[,...]]
light=licht,lampen
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
   devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
   echoRooms  #<deviceId>=<room>

   fhemIntents #IntentName=<sample utterance>
gutenMorgen=guten morgen
guteNacht=gute nacht
   persons    #<personId>=<name>

   stateFormat alexaFHEM


Zitat von: Otto123 am 24 Februar 2023, 16:24:59
Hast Du hier eine config stehen? /volume1/docker/alexa-fhem/
ja dort steht eine config.json und zwei weitere ordner mit .alexa und .ssh
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 24 Februar 2023, 17:17:11
was mich wundert: altes Alexa Gerät habe ich gelöscht und neues über ...
Ich musste gar nichts tuns https://forum.fhem.de/index.php/topic,89745.msg1261398.html#msg1261398
Und bei mir gibt es dieses Attribute  attr alexa alexaFHEM-host alexa-fhem gar nicht. Bei mir wurde das alexa-fhem Device voll automatisch erzeugt.

Hat er irgendwie Deine alte alexa-fhem.cfg übernommen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 24 Februar 2023, 21:21:21
Zitat von: Otto123 am 24 Februar 2023, 17:17:11
was mich wundert: altes Alexa Gerät habe ich gelöscht und neues über ...
Ich musste gar nichts tuns https://forum.fhem.de/index.php/topic,89745.msg1261398.html#msg1261398
Und bei mir gibt es dieses Attribute  attr alexa alexaFHEM-host alexa-fhem gar nicht. Bei mir wurde das alexa-fhem Device voll automatisch erzeugt.

Hat er irgendwie Deine alte alexa-fhem.cfg übernommen?
Das mit dem Attribut steht so im Git, und ein paar Seiten davor hier auch im Thread. Sobald ich dieses Attribut lösche sagt er mir
alexaFHEM   stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.

Die alte alexa-fhem.cfg liegt im Ordner
/volume1/docker/fhem/fhem/alexa-fhem.cfg

Meine config.json sieht so aus, dort habe ich nichts geändert nach Containererstellung:
{
  "alexa": {
    "port": 3000,
    "name": "Alexa",
    "ssl": false,
    "keyFile": "/certs/alexa-fhem.key",
    "certFile": "/certs/alexa-fhem.crt",
    "nat-pmp": "",
    "nat-upnp": false,
    "applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  },
  "sshproxy" : {
    "description" : "FHEM Connector",
    "ssh" : "/usr/bin/ssh"
  },
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "fhem"
    }
  ]
}


Edit:
habe mal in der config.json anstelle des Containernamens die Container-IP von FHEM hinterlegt und nun bekomme ich ein neues Reading:
alexaFHEM.ProxyConnection

error; user homedir writable by group/other ('chmod 755 /alexa-fhem' required)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 24 Februar 2023, 22:49:49
wie gesagt, ich habe neu angefangen und alles wurde automatisch gemacht. Den Eintrag im Reading
alexaFHEM habe ich auch so. Das scheint ok zu sein. Das der attr Eintrag im git steht weiß ich...

Bei mir ist im Pfad fhem (container fhem) diese alexa-fhem.cfg entstanden:
{
   "sshproxy" : {
      "description" : "FHEM Connector",
      "ssh" : "/usr/bin/ssh"
   },
   "connections" : [
      {
         "name" : "FHEM",
         "uid" : 6061,
         "filter" : "alexaName=..*",
         "port" : 8083,
         "server" : "127.0.0.1",
         "webname" : "fhem"
      }
   ]
}
Ich habe an keiner config was geändert.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 25 Februar 2023, 10:12:06
Ja die alexa.fhem.cfg habe ich auch so ähnlich im fhem pfad
{
   "connections" : [
      {
         "filter" : "alexaName=..*",
         "port" : 8083,
         "name" : "FHEM",
         "server" : "127.0.0.1",
         "webname" : "fhem",
         "uid" : 6061
      }
   ],
   "sshproxy" : {
      "description" : "FHEM Connector",
      "ssh" : "/usr/bin/ssh"
   }
}


Mal ne blöde Frage? Wie sehe ich ob die Verbindung der beiden container geklappt hat wenn das Device alexa gestoppt ist?
Laut wiki sollten ja 4 Readings auftauchen
Bei mir fehlt eben dieses alexaFHEM.ProxyConnection komplett
Internals:
   FUUID      63f91735-f33f-487e-3cdb-324ae75ec9f534ee
   FVERSION   39_alexa.pm:0.238200/2021-02-24
   LAST_START 2023-02-25 10:11:50
   LAST_STOP  2023-02-25 10:11:50
   NAME       alexa
   NOTIFYDEV  global,global:npmjs.*alexa-fhem.*
   NR         169
   NTFY_ORDER 50-alexa
   PARTIAL   
   STARTS     27
   STATE      stopped
   TYPE       alexa
   active     0
   alexa-fhem version 0.5.64
   eventCount 55
   logfile    ./log/alexa-%Y-%m-%d.log
   CoProcess:
     cmdFn      alexa_getCMD
     name       alexaFHEM
     state      stopped
   READINGS:
     2023-02-25 10:11:50   alexaFHEM       stopped
     2023-02-25 10:03:17   alexaFHEM.ProxyConnection error; user homedir writable by group/other ('chmod 755 /alexa-fhem' required)
     2023-02-24 20:59:49   alexaFHEM.bearerToken crypt:23000075010820522524770004277727
     2023-02-24 20:59:49   alexaFHEM.skillRegKey crypt:247600050407234e26210f010353712157535103247627544b23030925075b72547179750404232020
   helper:
Attributes:
   alexaFHEM-config ./alexa-fhem.cfg
   alexaFHEM-host alexa-fhem
   alexaFHEM-log ./log/alexa-%Y-%m-%d.log
   alexaMapping #Characteristic=<name>=<value>,...
On=verb=schalte,valueOn=an;ein,valueOff=aus,valueToggle=um

Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

Hue=verb=stelle,valuePrefix=auf,values=rot:0;grün:128;blau:200
Hue=verb=färbe,values=rot:0;grün:120;blau:220

Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER
Saturation=verb=sättige,values=AMAZON.NUMBER

TargetPosition=verb=mach,articles=den;die,values=auf:100;zu:0
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad

Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

#Weckzeit=verb=stelle,valuePrefix=auf;für,values=AMAZON.TIME,valueSuffix=uhr
   alexaTypes #Type=<alias>[,<alias2>[,...]]
light=licht,lampen
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
   devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
   echoRooms  #<deviceId>=<room>

   fhemIntents #IntentName=<sample utterance>
gutenMorgen=guten morgen
guteNacht=gute nacht
   persons    #<personId>=<name>

   stateFormat alexaFHEM

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 25 Februar 2023, 10:16:03
Zitat von: michisa86888 am 25 Februar 2023, 10:12:06
Ja die alexa.fhem.cfg habe ich auch so ähnlich im fhem pfad

Also die alexa-fhem.cfg muss im Alexa-Fhem Container liegen.
Es ist möglich, die gleiche Datei auch im FHEM Container bereitzustellen, aber ausgewertet wird die nur im Alexa-FHEM Container.

Eventuell muss ich was an der Doku im Docker Container Repo anpassen, ich weiss aber gerade nicht genau was.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 25 Februar 2023, 13:09:24
ok, damit was sidey sagt kann es ja eigentlich nur ein Problem mit der config im alexa-fhem Container geben. Als Du die manipuliert hast, gab es ja auch eine Fehlermeldung bez. der Rechte.
Wie sieht es "im" Container aus, bei mir so:
docker exec -it alexa-fhem bash
root@36d1bbfb65e9:/alexa-fhem# ls -lha
total 20K
drwxr-xr-x 4 alexa-fhem alexa-fhem 4.0K Feb 17 21:32 .
drwxr-xr-x 1 root       root       4.0K Feb 17 21:32 ..
drwxr-xr-x 2 alexa-fhem alexa-fhem 4.0K Feb 17 21:32 .alexa
lrwxrwxrwx 1 root       root         11 Feb 17 21:32 alexa-fhem.json -> config.json
-rw-r--r-- 1 alexa-fhem alexa-fhem  631 Jan 31 20:07 config.json
drwxr-xr-x 2 alexa-fhem alexa-fhem 4.0K Feb 17 21:32 .ssh
root@36d1bbfb65e9:/alexa-fhem#
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 25 Februar 2023, 16:54:43
Habe die alexa-fhem.cfg mal in den alexa-fhem ordner kopiert.
Die Rechteausgabe gibt folgendes:
root@b15e72cfb8f9:/alexa-fhem# ls -lha
total 12K
drwxrwxrwx 1 alexa-fhem alexa-fhem 100 Feb 25 16:51 .
drwxr-xr-x 1 root       root       336 Feb 24 15:42 ..
drwxrwxrwx 1 alexa-fhem alexa-fhem  22 Feb 25 16:51 .alexa
-rwxrwxrwx 1 alexa-fhem alexa-fhem 310 Feb 25 10:06 alexa-fhem.cfg
lrwxrwxrwx 1 root       root        11 Feb 25 16:51 alexa-fhem.json -> config.json
-rwxrwxrwx 1 alexa-fhem alexa-fhem 637 Feb 24 21:27 config.json
drwxrwxrwx 1 alexa-fhem alexa-fhem 114 Feb 25 16:51 .ssh


Das Rechteproblem habe ich auch wenn ich den server wieder auf fhem zurückstelle in config.json
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 25 Februar 2023, 17:15:22
verwirrend - ich meine: eine alexa-fhem.cfg hat im alexa-fhem Container nix zu suchen. dort ist es die alexa-fhem.json -> config.json

Vielleicht solltest Du den alexa-fhem Container löschen, die alexa-fhem.cfg und das alexa Device im fhem Container löschen und einfach nochmal neu starten.
Wie gesagt: bei mir ging alles automatisch und läuft.
Ich weiß nur nicht was mit einer vorhandenen Registrierung beim Vereins Connector passiert? :-\

Ich weiß nicht, ob Deine extra Netzwerkeinstellung funktional ist, ich habe da keine. Docker compose erzeugt die ja auch automatisch.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 25 Februar 2023, 17:48:11
Also habe mal den alexa Container komplett platt gemacht. FHEM alexa device gelöscht und die alexa-fhem.cfg im fhem auch.
Neuer alexa-fhem container erstellt, ohne das extra netzwerk (auch beim FHEM Container entfernt)
Beide Container gestartet, in /fhem taucht nun wieder ohne ein define die alexa-fhem.cfg auf.
Dann define alexa alexa, das alexa-fhem host attribut dazu, bekomme nun aber wieder nicht das ssh Reading auf running
Habe nur die 3 Readings:
alexaFHEM
alexaFHEM.bearerToken
alexaFHEM.skillRegKey

Ich weiss langsam echt nicht weiter, aktuell bleibt nur die Lösung auf den alten FHEM Container zu wechseln dort lief alexa eigentlich problemlos

Was mich ein wenig wundert, eine alexa-fhem.json habe ich nicht, nur die config.json?
Und im alexa log habe ich eigentlich nur die Einträge
Unknown cipher type '/tmp/alexa-fhem.cfg'
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 25 Februar 2023, 18:11:25
Zitat von: michisa86888 am 25 Februar 2023, 17:48:11
Neuer alexa-fhem container erstellt, ohne das extra netzwerk (auch beim FHEM Container entfernt)
Beide Container gestartet, in /fhem taucht nun wieder ohne ein define die alexa-fhem.cfg auf.
Dann define alexa alexa, das alexa-fhem host attribut dazu, bekomme nun aber wieder nicht das ssh Reading auf running

Das Attribut alexaFHEM-host kannst Du löschen.

Das Aktuelle FHEM Image hat Version 3 und lautet `ghcr.io/fhem/fhem/fhem-docker:3-bullseye`


Mich würde mal vom alexa-fhem container folgendes interessieren:

- Logmeldungen
- Inhalt der Datei /alexa-fhem/config.json


Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 25 Februar 2023, 18:46:26
Zitat
Ich weiß nur nicht was mit einer vorhandenen Registrierung beim Vereins Connector passiert? :-\

Ohne Docker stecken die Daten in /opt/fhem/.ssh

Wie das bei Docker ist: keine Ahnung.

Bzw. liegen die Daten (auf jeden Fall) dort wo alexa-fhem (also das nodejs Zeugs) läuft...

Aber: deregistrieren und auch Skill deaktivieren und dann einfach "noch mal" sollte helfen (siehe alexa-fhem Connector Wiki oder auch dem Thread dazu)...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 25 Februar 2023, 21:52:26
Zitat von: Sidey am 25 Februar 2023, 18:11:25
Das Attribut alexaFHEM-host kannst Du löschen.

Das Aktuelle FHEM Image hat Version 3 und lautet `ghcr.io/fhem/fhem/fhem-docker:3-bullseye`


Mich würde mal vom alexa-fhem container folgendes interessieren:

- Logmeldungen
- Inhalt der Datei /alexa-fhem/config.json

Also im Alexa-fhem Container Log taucht folgendes auf:
*** FHEM: connection failed: Error: getaddrinfo ENOTFOUND fhem

[2/25/2023, 9:49:50 PM] [FHEM] trying longpoll to listen for fhem events

[2/25/2023, 9:49:50 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1677358190348

*** FHEM: connection failed: Error: getaddrinfo ENOTFOUND fhem

[2/25/2023, 9:49:50 PM] [FHEM] longpoll error: Error: getaddrinfo ENOTFOUND fhem, retry in: 30000msec


Grüße Sidey
Inhalt der config.json
{
  "alexa": {
    "port": 3000,
    "name": "Alexa",
    "ssl": false,
    "keyFile": "/certs/alexa-fhem.key",
    "certFile": "/certs/alexa-fhem.crt",
    "nat-pmp": "",
    "nat-upnp": false,
    "applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  },
  "sshproxy" : {
    "description" : "FHEM Connector",
    "ssh" : "/usr/bin/ssh"
  },
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "fhem"
    }
  ]
}

Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 25 Februar 2023, 22:07:44
Zitat von: michisa86888 am 25 Februar 2023, 21:52:26
Inhalt der config.json
{
      "name": "FHEM",


Der Alexa FHEM Container kann den Container FHEm nicht finden.
Wie nennt sich der Container bei dir und sind beide gleichen Netzwerk?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 25 Februar 2023, 23:24:37
zeig mal die Ausgabe von
docker compose ps
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 26 Februar 2023, 13:09:15
Zitat von: Sidey am 25 Februar 2023, 22:07:44
Der Alexa FHEM Container kann den Container FHEm nicht finden.
Wie nennt sich der Container bei dir und sind beide gleichen Netzwerk?

Grüße Sidey
Der Fhem Container heisst fhem.
Habe mal ein Screenshot angehängt von den beiden Containern. Beide befinden sich im Netzwerk "bridge"

Zitat von: Otto123 am 25 Februar 2023, 23:24:37
zeig mal die Ausgabe von
docker compose ps
Habe die beiden Container beim neuaufsetzen nicht mehr über docker-compose erstellt, sondern einzeln direkt in Portainer.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 26 Februar 2023, 23:22:59
Zitat von: michisa86888 am 26 Februar 2023, 13:09:15
Habe die beiden Container beim neuaufsetzen nicht mehr über docker-compose erstellt, sondern einzeln direkt in Portainer.

Teile doch bitte mal deine Portiner Stack Konfiguration.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 27 Februar 2023, 20:57:08
Zitat von: Sidey am 26 Februar 2023, 23:22:59
Teile doch bitte mal deine Portiner Stack Konfiguration.
Hab die Container eben nicht über Portainer Stack bzw. docker-compose erstellt. Habe in Portainer +add Container und dann eben die ganzen Einstellungen manuell angegeben.
Kann ich in Portainer irgendwie nie Info zum Container ausgeben lassen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 27 Februar 2023, 21:18:21
Zitat von: michisa86888 am 27 Februar 2023, 20:57:08
Hab die Container eben nicht über Portainer Stack bzw. docker-compose erstellt. Habe in Portainer +add Container und dann eben die ganzen Einstellungen manuell angegeben.


Darin wird das Problem liegen.
Mir wäre so kein Weg bewusst, wie Du dem Service einen Namen geben kannst.

Leg das ganze als Stack an, dann wird es auch gehen.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 28 Februar 2023, 10:27:43
In Ergänzung zu dem was Sidey sagt:
Der "Trick" an der gesamten Beispielkonfiguration (docker-compose.yml) sind die Servicenamen. Für die Namensauflösung habe ich zwar viele aber keine wirklich einfache Beschreibung gefunden. Irgendwann habe ich gelernt: die aller einfachste Art sind die Servicenamen innerhalb eines compose stacks - unabhängig von Hostnamen usw.
Man kann auch containernamen und hostnamen vergeben.
Man kann auch Hostnamen in die /etc/hosts der Container "injizieren"
Wenn man hier (https://docs.docker.com/compose/compose-file/) mal nach hostnames, services, links, aliases sucht - findet man einige Stellen mit Erklärungen. ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 01 März 2023, 20:42:22
So jetzt mal wieder alle Container platt gemacht und über Portainer Stack neu aufgesetzt
version: '2.3'

networks:
  fhem_net:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.27.0.0/28
          gateway: 172.27.0.1
        # - subnet: fd00:0:0:0:27::/80
        #   gateway: fd00:0:0:0:27::1


services:
  # Minimum example w/o any custom environment variables of fhem container
  fhem:
    image: ghcr.io/fhem/fhem/fhem-docker:3-bullseye
    restart: always
    networks:
      - fhem_net
    ports:
      - "8083:8083"
      - "1883:1883"
    volumes:
      - "/volume1/docker/fhem/:/opt/fhem/"

# Minimum example w/o any custom environment variables of alexa-fhem container
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    restart: always
    networks:
     - fhem_net
    ports:
      - "3000:3000"
    volumes:
      - "/volume1/docker/alexa-fhem/:/alexa-fhem/"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Berlin

Danach wieder ein define alexa alexa gemacht ->  alexaFHEM.ProxyConnection    error; user homedir writable by group/other ('chmod 755 /alexa-fhem' required)

root@c777aa3661a1:/alexa-fhem# ls -lha
total 8.0K
drwxrwxrwx 1 alexa-fhem alexa-fhem  72 Mar  1 20:34 .
drwxr-xr-x 1 root       root       336 Mar  1 20:22 ..
drwxrwxrwx 1 alexa-fhem alexa-fhem  22 Mar  1 20:34 .alexa
lrwxrwxrwx 1 root       root        11 Mar  1 20:34 alexa-fhem.json -> config.json
-rwxrwxrwx 1 alexa-fhem alexa-fhem 631 Mar  1 20:22 config.json
drwxrwxrwx 1 alexa-fhem alexa-fhem 114 Mar  1 20:34 .ssh


Log vom alexa-fhem container:
[3/1/2023, 8:34:37 PM] [FHEM] Sonoff_Absauganlage is switch

[3/1/2023, 8:34:37 PM] [FHEM] Sonoff_Absauganlage has

[3/1/2023, 8:34:37 PM] [FHEM]   On [undefined;on,off]

[3/1/2023, 8:34:37 PM] [FHEM] Sonoff_Absauganlage will not send proactive events

[3/1/2023, 8:34:37 PM] [FHEM] Sonoff_Absauganlage uses ID: 621fc9b7-f33f-487e-5e7f-5973c6544fd6c890

[3/1/2023, 8:34:37 PM] [FHEM] Steckdose_Stehlampe is switch

[3/1/2023, 8:34:37 PM] [FHEM] Steckdose_Stehlampe has

[3/1/2023, 8:34:37 PM] [FHEM]   On [undefined;on,off]

[3/1/2023, 8:34:37 PM] [FHEM] Steckdose_Stehlampe will not send proactive events

[3/1/2023, 8:34:37 PM] [FHEM] Steckdose_Stehlampe uses ID: 621fc8cf-f33f-487e-bfe8-b8a0a62b958e6201

[3/1/2023, 8:34:37 PM] BearerToken '...25ACC' read from alexa

[3/1/2023, 8:34:38 PM] Reading alexaFHEM.ProxyConnection set to error;; user homedir writable by group/other ('chmod 755 /alexa-fhem' required)

[3/1/2023, 8:34:38 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20alexa%20alexaFHEM.ProxyConnection%20error%3B%3B%20user%20homedir%20writable%20by%20group%2Fother%20('chmod%20755%20%2Falexa-fhem'%20required)%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=csrf_232909215449551&XHR=1


Irgendwie wieder das Rechteproblem??
Aufgefallen sind mir auch noch die Containernahmen siehe Bildanhang
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 01 März 2023, 21:02:15
die Containernamen sind ok. Du hast nichts definiert, da werden sie aus projekt (stack) service und index gebildet.

was ist eigentlich volume1?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 März 2023, 21:03:38
Zitat von: Otto123 am 01 März 2023, 21:02:15
die Containernamen sind ok. Du hast nichts definiert, da werden sie aus projekt (stack) service und index gebildet.

was ist eigentlich volume1?

Ich habe das Problem identifiziert. Ich werde was an entry.sh anpassen. Das sollte helfen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 März 2023, 21:46:11
Zitat von: michisa86888 am 01 März 2023, 20:42:22
So jetzt mal wieder alle Container platt gemacht und über Portainer Stack neu aufgesetzt
# Minimum example w/o any custom environment variables of alexa-fhem container
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest

Versuche mal folgendes Image:
ghcr.io/fhem/fhem/alexa-fhem:4.0.2


Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 01 März 2023, 21:55:08
Nun bekomme ich eine andere Rechte-Fehlermeldung
[3/1/2023, 9:53:04 PM] Reading alexaFHEM.ProxyConnection set to error;; Reverse Proxy replied with neither registered nor unregistered status: out:  err:Bad owner or permissions on /alexa-fhem/.ssh/config

[3/1/2023, 9:53:04 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20alexa%20alexaFHEM.ProxyConnection%20error%3B%3B%20Reverse%20Proxy%20replied%20with%20neither%20registered%20nor%20unregistered%20status%3A%20out%3A%20%20err%3ABad%20owner%20or%20permissions%20on%20%2Falexa-fhem%2F.ssh%2Fconfig%0D%0A%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=csrf_419843090778510&XHR=1


alexaFHEM.ProxyConnection     error; Reverse Proxy replied with neither registered nor unregistered status: out:  err:Bad owner or permissions on /alexa-fhem/.ssh/config
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 März 2023, 21:58:03
Zitat von: michisa86888 am 01 März 2023, 21:55:08
Nun bekomme ich eine andere Rechte-Fehlermeldung
[3/1/2023, 9:53:04 PM] Reading alexaFHEM.ProxyConnection set to error;; Reverse Proxy replied with neither registered nor unregistered status: out:  err:Bad owner or permissions on /alexa-fhem/.ssh/config


Lösche doch mal den alexa-fhem Ordner in deinem Volume1.

Ich habe das Gefühl, dass Du dort schon mal ein alexa-fhem mit anderer uid / gid gestartet hast.


Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 01 März 2023, 22:02:30
Genau das habe ich eben gemacht  :)
Denke jetzt hat es geklappt....
[3/1/2023, 9:59:27 PM] 39_alexa.pm is new version: true

[3/1/2023, 9:59:27 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=set%20alexa%20proxyToken%2081C39C57C7D2372F&fwcsrf=csrf_506916480081571&XHR=1

[3/1/2023, 9:59:27 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=set%20alexa%20proxyKey%207D824298-6BA11AF091BB4056-81C39C57C7D2372F&fwcsrf=csrf_506916480081571&XHR=1

[3/1/2023, 9:59:27 PM] sshautoconf: completed successfully

[3/1/2023, 9:59:27 PM] *** SSH: proxy configuration set up done

[3/1/2023, 9:59:27 PM] Reading alexaFHEM.ProxyConnection set to starting;; starting SSH

[3/1/2023, 9:59:27 PM] Starting SSH with -R 1234:127.0.0.1:40199 -oServerAliveInterval=90 -i /alexa-fhem/.ssh/id_rsa -p 58824 fhem-va.fhem.de

[3/1/2023, 9:59:27 PM] SSH setup completed with new bearer token

[3/1/2023, 9:59:27 PM] Reading alexaFHEM.ProxyConnection set to running;; SSH connected

[3/1/2023, 9:59:27 PM] *** SSH: proxy connection established

[3/1/2023, 9:59:27 PM] SSH: Welcome at the reverse proxy!  This pseudoshell does not react to any input - do not get irritated. 

[3/1/2023, 9:59:29 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%20FW_directNotify(%22%23FHEMWEB%3AWEB%22%2C%20%22location.reload('true')%22%2C%20%22%22)%20%7D&fwcsrf=csrf_506916480081571&XHR=1


Vielen Dank euch beiden schon einmal. Echt cooler support hier!!!

Noch eine Frage: Grafana liegt bei mir auch im Docker (Port 3000) - war nun die ganze Zeit aus. Beißt sich dieser dann mit alexa-fhem auf Port 3000?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 01 März 2023, 22:41:13
Der alexa-fhem Connector braucht keinen Port 3000 und auch die Weiterleitung nicht mehr.
Außer: du willst einen eigenen Smart Home oder Custom Skill betreiben...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 März 2023, 23:01:29
Zitat von: michisa86888 am 01 März 2023, 22:02:30
Vielen Dank euch beiden schon einmal. Echt cooler support hier!!!

Danke dass Du so viel ausprobiert hattest. Einen kleines Fehlerchen habe ich ja auch beseitigt.


Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 02 März 2023, 20:40:22
Ja gerne teste ich soviel, ich hatte ja schließlich auch das Problem  :)

Aber jetzt hätte ich noch ein anderes Thema. Meine nächste Baustelle wäre DBlog mit MySQL.
Würde MySql dann ebenfalls gerne in einem Container laufen lassen. Diesen Container könnte ich doch in die vorhandene Stack mit einbauen oder?
Bin mir nur unsicher was da mit rein soll, damit die Anbindung an FHEM dann funktioniert?
Sollte ich noch irgendwelche Enviroments in den FHEM Container mit aufnehmen?
environment:
      FHEM_UID: 6061
      FHEM_GID: 6061
      TIMEOUT: 10
      RESTART: 1
      TELNETPORT: 7072
      TZ: Europe/Berlin




Zitat von: MadMax-FHEM am 01 März 2023, 22:41:13
Der alexa-fhem Connector braucht keinen Port 3000 und auch die Weiterleitung nicht mehr.
Außer: du willst einen eigenen Smart Home oder Custom Skill betreiben...

Gruß, Joachim
Heisst das ich kann die Portfreigabe in meinem Stack löschen oder z.B. auf Port 3002 legen?
Kann mein Grafana so auf Port 3000 nicht starten
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 02 März 2023, 21:19:59
Zitat von: michisa86888 am 02 März 2023, 20:40:22
Würde MySql dann ebenfalls gerne in einem Container laufen lassen. Diesen Container könnte ich doch in die vorhandene Stack mit einbauen oder?


Pauschal gesagt, kannst Du mehrere Container im Stack definieren.
Die Konfigurationsoptionen sind je nach verwendetem Image unterschiedliche. Ich verwende ein mariadb Image von Linux-Server:

db:
    image: linuxserver/mariadb
    container_name: mariadb
    environment:                                                 
     - PGID=1003
     - MYSQL_ROOT_PASSWORD=xxxxxx
     - REMOTE_SQL="https://svn.fhem.de/trac/export/22390/trunk/fhem/contrib/dblog/db_create_mysql.sql"
     - TZ=Europe/London
    volumes:                                                     
     - ./data:/config
    restart: unless-stopped
    labels:
      - "diun.enable=true"
    networks:
     - fhem_net


Das kannst Du als Beispiel nehmen.
Den Datenbank Container lasse ich als User 1003 laufen, da ich noch ein Backup der Daten implementiert habe.

Erreichbar ist er im fhem_net und für FHEM unter dem Hostnamen "DB" erreichbar.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 04 März 2023, 12:02:35
Okay werde ich mal probieren. Kurze Frage noch dazu - sollte man das volume auch wieder auslagern aus dem Container?
Also z.B. bei mir:
  volumes:                                                     
- /volume1/docker/mariadb/:/data:/config
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 04 März 2023, 12:09:19
Zitat von: michisa86888 am 04 März 2023, 12:02:35
Okay werde ich mal probieren. Kurze Frage noch dazu - sollte man das volume auch wieder auslagern aus dem Container?
Also z.B. bei mir:
  volumes:                                                     
- /volume1/docker/mariadb/:/data:/config


Unbedingt ja. Das hatte ich ja in meinem Beispiel auch enthalten.
Daten in Containern sind flüchtig, nur was als Volume ausgelagert wird, bleibt erhalten, wenn ein neuer Container gestartet wird.

Einen neuen Container startest Du bei jeder Aktualisierung des Images, also so ~ 1-2 mal pro Monat.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 04 März 2023, 13:24:23
Okay, neuer Stack läuft soweit. Habt ihr vielleicht eine gute Anleitung wie man MariaDB und FHEM unter Docker einrichtet? Habe noch keine Erfahrung mit MySQL
Und gibt es für MariaDB auch eine Weboberfläche?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 04 März 2023, 14:27:09
Es gibt Programme zum Administrieren von mySQL per WEB, z.B. phpmysql, gibt aber noch vieieiele Andere. Ich persönlich würde es aber eher auf der Konsole machen ... so häufig geht man nicht an die Datenbank. mySQL und MariaDB selber haben keine Oberfläche.

(Und mit phpmysql habe ich  mir "damals" mal eine DB zerschossen ... und ein gebranntes Kind scheut das Feuer)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: GammaTwin am 04 März 2023, 15:11:39
Zitat von: Sidey am 25 Februar 2023, 18:11:25
Das Aktuelle FHEM Image hat Version 3 und lautet `ghcr.io/fhem/fhem/fhem-docker:3-bullseye`

Grüße,

ist dies das selbe image wie fhem/fhem?
oder ist ghcr.io etwas anderes als der Docker Hub?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 04 März 2023, 17:15:34
Zitat von: GammaTwin am 04 März 2023, 15:11:39
Grüße,

ist dies das selbe image wie fhem/fhem?
oder ist ghcr.io etwas anderes als der Docker Hub?

Die Images werden sowohl in docker hub als auch github container registry gespeichert. Sie sind somit identisch.

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 05 März 2023, 13:12:57
Zitat von: Sidey am 04 März 2023, 12:09:19
Unbedingt ja. Das hatte ich ja in meinem Beispiel auch enthalten.
Daten in Containern sind flüchtig, nur was als Volume ausgelagert wird, bleibt erhalten, wenn ein neuer Container gestartet wird.

Einen neuen Container startest Du bei jeder Aktualisierung des Images, also so ~ 1-2 mal pro Monat.

Grüße Sidey

Habe nun ein FHEM Device nach Wiki angelegt.
define logdb DbLog ./db.conf .*:.*

Dieses bekommt aber folgende Fehlermeldung:
state   DBI connect('database=fhem;host=db;port=3306','1003',...) failed: Access denied for user '1003'@'fhem-fhem-1.fhem_fhem_net' (using password: YES) at ./FHEM/93_DbLog.pm line 2553

db.conf habe ich angelegt und in /fhem abgespeichert.
%dbconfig= (
    connection => "mysql:database=fhem;host=db;port=3306",
    user => "1003",
    password => "xxxxxx",
);
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 05 März 2023, 13:41:36
Zitat von: michisa86888 am 05 März 2023, 13:12:57


db.conf habe ich angelegt und in /fhem abgespeichert.
%dbconfig= (
    connection => "mysql:database=fhem;host=db;port=3306",
    user => "1003",
    password => "xxxxxx",
);


Du müsstest den User 1003 mit dem genannten Passwort auf die Datenbank berechtigen.
Dann sollte es gehen.

Das verlinkte Script legt allerdings einen Nutzer mit dem Namen fhemuser an.


Details sieht: https://svn.fhem.de/trac/export/22390/trunk/fhem/contrib/dblog/db_create_mysql.sql

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: michisa86888 am 06 März 2023, 21:30:16
Zitat von: Sidey am 05 März 2023, 13:41:36
Du müsstest den User 1003 mit dem genannten Passwort auf die Datenbank berechtigen.
Dann sollte es gehen.

Das verlinkte Script legt allerdings einen Nutzer mit dem Namen fhemuser an.


Details sieht: https://svn.fhem.de/trac/export/22390/trunk/fhem/contrib/dblog/db_create_mysql.sql

Grüße Sidey
Okay indemfall habe ich das ganze auf den fhemuser geändert. Das Password für den root-user ist doch das das ich im Stack angegeben habe.
Will mich über Portainer auf die Konsole vom MariaDB Container schalten. Hier kommt es aber zu einem Rechteproblem:
root@a16319f0a176:/# mysql -u root -p
Warning: World-writable config file '/etc/my.cnf.d/custom.cnf' is ignored
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)


Der nächste Schritt wäre aber dann
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 07 März 2023, 12:53:33
Hallo zusammen! Ich hatte FHEM, Alexa, deCONZ und alles Mögliche und unmögliche begonnen zu "containerisieren". Alles funktioniert einwandfrei, nur FHEM-Alexa bekomme ich nicht auf die Reihe, obwohl es in der alten Installation, als ich noch keine Container verwendet habe klaglos gelaufen ist. Ehrlich: wegen Alexa will ich nicht zurücksteigen. Ich versuche das Ganze erstmal auf meinem Raspi-Testsystem zum Laufen zu bringen und habe hier die minimale Konfiguration und auch eine nahezu leere fhem.cfg.
Meine compose.yaml sieht so aus:
version: '3'
services:

  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    ports:
      - "8000:8000"
      - "9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
    restart: unless-stopped
#
#
  fhem:
    image: ghcr.io/fhem/fhem/fhem-docker:latest
    container_name: fhem
    hostname: fhem
    restart: always
    ports:
      - "1883:1883"
      - "8883:8883"
      - "8083:8083"
      - "8084:8084"
      - "8085:8085"
      - "7072:7072"
    volumes:
      - /opt/fhemdocker/:/opt/fhem/
    environment:
      FHEM_UID: 999
      FHEM_GID: 20
      TZ: Europe/Vienna
#
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    container_name: alexa-fhem
    restart: always
#    networks:
#     - fhem_net
    ports:
      - "3000:3000"
    volumes:
      - /opt/alexa-fhem/:/alexa-fhem/"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Vienna
#
volumes:
  portainer_data:
    name: portainer_data
    external: true

Nachdem alexa-fhem im Portainer als "healthy" angezeigt wird wechsle ich ins FHEM und finde dort:
defmod alexa alexa
attr alexa alexaFHEM-config ./alexa-fhem.cfg
attr alexa alexaFHEM-log ./log/alexa-%Y-%m-%d.log
attr alexa alexaMapping #Characteristic=<name>=<value>,...\
On=verb=schalte,valueOn=an;;ein,valueOff=aus,valueToggle=um\
\
Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
Hue=verb=stelle,valuePrefix=auf,values=rot:0;;grün:128;;blau:200\
Hue=verb=färbe,values=rot:0;;grün:120;;blau:220\
\
Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER\
Saturation=verb=sättige,values=AMAZON.NUMBER\
\
TargetPosition=verb=mach,articles=den;;die,values=auf:100;;zu:0\
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad\
\
Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
#Weckzeit=verb=stelle,valuePrefix=auf;;für,values=AMAZON.TIME,valueSuffix=uhr
attr alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
light=licht,lampen\
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
attr alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr alexa echoRooms #<deviceId>=<room>\

attr alexa fhemIntents #IntentName=<sample utterance>\
gutenMorgen=guten morgen\
guteNacht=gute nacht
attr alexa persons #<personId>=<name>\

attr alexa stateFormat alexaFHEM

setstate alexa stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
setstate alexa 2023-03-07 11:32:01 alexaFHEM stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
setstate alexa 2023-03-07 12:43:33 alexaFHEM.ProxyConnection running;; SSH connected
setstate alexa 2023-03-07 11:07:57 alexaFHEM.bearerToken crypt:xxxxxxxxxxxxxxx
setstate alexa 2023-03-07 11:07:57 alexaFHEM.skillRegKey crypt:xxxxxxxxxxxxxxxx


wobei mich das
setstate alexa stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
Das sollte doch nicht notwendig sein, da es im Docker läuft...???

besonders irritiert.
In meinem FHEM-Verzeichnis kommt keine alexa-fhem.cfg und auch meine /opt/alexa-fhem ist und bleibt leer?

Ich vermute, dass ich bei meiner "Erstinstalletion" damals noch ohne Docker irgend etwas nicht mitgeschrieben habe. Ich bitte um Hilfe. Danke
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 07 März 2023, 13:32:55
Zitat von: rallye am 07 März 2023, 12:53:33
wobei mich das
setstate alexa stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
Das sollte doch nicht notwendig sein, da es im Docker läuft...???

besonders irritiert.
Das ist nur "unschön" mal schauen ob wir das mal noch bereinigt bekommen.
Das ist wichtig:
Zitatsetstate alexa 2023-03-07 12:43:33 alexaFHEM.ProxyConnection running;; SSH connected
Ich meine alles ist gut und funktioniert bei Dir - teste einfach alexa
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 08 März 2023, 10:44:52
Jetzt hab ich die alexa-fhem Definitionen für den Container 1:1 in meine Produktionsumgebung, wo ich Alexa-Devices habe, übernommen. Mit dem identen Output wie im Testsystem. Das einfache Ausprobieren wie von @Otto, vorgeschlagen, also "Alexa, schalte das Küchenlicht ein" wird von Alexa mit "Küchenlicht reagiert gerade nicht" quittiert.
Im alexa-fhem Log im Portainer (das aktuelle alexaFHEMlog der Alexa-Definition in FHEM st leer) finde ich diese Zeilen:

.
.
  2023-03-08 10:25:16 caching: Licht.Kueche-state: on
[3/8/2023, 10:25:16 AM] [FHEM]     caching: On: 1 (as number; from 'on')
  2023-03-08 10:25:17 caching: Licht.Kueche-state: off
[3/8/2023, 10:25:17 AM] [FHEM]     caching: On: 0 (as number; from 'off')
.
.

Die Definition "Küchenlicht" (ein Shelly1) ist wie folgt:
defmod Licht.Kueche MQTT2_DEVICE shelly1_500291F09D8A
attr Licht.Kueche userattr floor floor_map haus haus_map structexclude
attr Licht.Kueche IODev MQTT_Shellies
attr Licht.Kueche alexaName Küchenlicht
attr Licht.Kueche alias Küchenlicht
attr Licht.Kueche comment Abgesehen vom richtigen Template (shelly1) müssen noch folgende Attribute\
"per Hand" gesetzt werden:\
- icon\
- room\
- group\
- alias\
- sortby\
Weiters für die structures: userattr floor floor_map haus haus_map structexclude\
\
Weiters:\
- event-on-change-reading .*\
- timestamp-on-change-reading state\
damit der Shelly nicht alle 30 Sekunden das Reading state incl. timestamp\
aktualisiert und somit die echte Ein- bzw. Ausschaltdauer berechnet werden kann\
\
Um die Kosten der Geräte hinter dem Shelly zu berechnen ist folgendes eingerichtet:\
attr userReadings:\
relay0_OnOffTime:relay0:.* difference {time_str2num(ReadingsTimestamp($NAME,"relay0","--?--"))}, relay0_OnTime:relay0:.* {(ReadingsVal($NAME,"relay0","xxx")) ne "on" ? (ReadingsVal($NAME,"relay0_OnOffTime","--?--")) + (ReadingsVal($NAME,"relay0_OnTime","--?--")) : (ReadingsVal($NAME,"relay0_OnTime","--?--"))}, relay_0_energy_kWh:relay0:.* {(ReadingsVal($NAME,"relay0_OnTime",0)/3600/1000.0)*10.56}, Kosten:relay_0_energy_kWh.* { sprintf("%.2f",(ReadingsVal($NAME,"relay_0_energy_kWh",0) + 0.0)*.5);;;;}\
Anm: die Readings werden nicht laufend, sondern erst beim Abschalten der Devices aktualisiert.\
\
relay0_OnOffTime: ist die Zeit in Sekunden zwischen 2 Schaltzyklen (Ein/Aus)\
relay0_OnTime:    ist die kumulierte Zeit in Sekunden für welche die Geräte eingeschaltet sind. \
                  Zum Anfang einer Periode (Monat/Quartal/Jahr) kann dieser Wert auf 0 gesetzt\
                  werden um die Kosten von 0 weg neu zu berechnen.\
relay_0_energy_kWh: wird aus relay0_OnTime berechnet, das die kommutierten Sekunden die ein Device eingeschaltet ist\
                    enthält. Zur Berechnung werden die Sekunden in Stunden (/3600) und die Watt in kW (/1000)\
                    umgerechnet. Der errechnete Wert wird mit dem Verbrauch in Watt des angeschlossenen\
                    elektrischen Verbrauchers multipliziert (z.B.: LED-Lampe mit 10.56W)\
Kosten:             die Kosten in Euro werden derzeit mit 0,5/kWh berechnet\
\
devStateIcon:\
{my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $total = ReadingsVal($name,"relay_0_energy_kWh","unknown");;;; my $cost = ReadingsVal($name,"Kosten","-100");;;; "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch Total: $total kWh / Kosten: $cost €</div>"}
attr Licht.Kueche devStateIcon {my $onl = ReadingsVal($name,"online","false") eq "false"?"10px-kreis-rot" : ReadingsVal($name,"new_fw","false") eq "true" ? "10px-kreis-gelb" : "10px-kreis-gruen";;;; my $light = ReadingsVal($name,"state","off");;;; my $total = sprintf("%.2f",(ReadingsVal($name,"relay_0_energy_kWh","unknown")));;;; my $cost = ReadingsVal($name,"Kosten","-100");;;; "<a href=\"http://".ReadingsVal($name,"ip","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Verbrauch Total: $total kWh / Kosten: $cost €</div>"}
attr Licht.Kueche event-on-change-reading .*
attr Licht.Kueche genericDeviceType switch
attr Licht.Kueche group Straßenebene
attr Licht.Kueche icon light_ceiling
attr Licht.Kueche model shelly1
attr Licht.Kueche readingList shellies/SH-Kuechenlicht/relay/0:.* state\
  shellies/SH-Kuechenlicht/relay/0:.* relay0\
  shellies/SH-Kuechenlicht/input/0:.* input0\
  shellies/SH-Kuechenlicht/online:.* online\
  shellies/SH-Kuechenlicht/announce:.* { json2nameValue($EVENT) }\
  shellies/announce:.* { $EVENT =~ m,..id...SH-Kuechenlicht...mac.*, ? json2nameValue($EVENT) : return }\
shelly1_500291F09D8A:shellies/SH-Kuechenlicht/info:.* { json2nameValue($EVENT) }\
shelly1_500291F09D8A:shellies/SH-Kuechenlicht/online:.* online\
shelly1_500291F09D8A:shellies/SH-Kuechenlicht/input_event/0:.* { json2nameValue($EVENT) }
attr Licht.Kueche room Infrastruktur
attr Licht.Kueche setList off:noArg shellies/SH-Kuechenlicht/relay/0/command off\
  on:noArg shellies/SH-Kuechenlicht/relay/0/command on\
  x_update:noArg shellies/SH-Kuechenlicht/command update_fw\
  x_mqttcom shellies/SH-Kuechenlicht/command $EVTPART1
attr Licht.Kueche sortby 7
attr Licht.Kueche timestamp-on-change-reading state
attr Licht.Kueche userReadings relay0_OnOffTime:relay0:.* difference {time_str2num(ReadingsTimestamp($NAME,"relay0","--?--"))}, relay0_OnTime:relay0:.* {(ReadingsVal($NAME,"relay0","xxx")) ne "on" ? (ReadingsVal($NAME,"relay0_OnOffTime","--?--")) + (ReadingsVal($NAME,"relay0_OnTime","--?--")) : (ReadingsVal($NAME,"relay0_OnTime","--?--"))}, relay_0_energy_kWh:relay0:.* {(ReadingsVal($NAME,"relay0_OnTime",0)/3600/1000.0)*15}, Kosten:relay_0_energy_kWh.* { sprintf("%.2f",(ReadingsVal($NAME,"relay_0_energy_kWh",0) + 0.0)*.5);;;;}

setstate Licht.Kueche off
setstate Licht.Kueche 2023-03-08 09:37:07 IODev MQTT_Shellies
setstate Licht.Kueche 2023-03-08 10:25:17 Kosten 0.02
setstate Licht.Kueche 2023-03-08 09:37:26 actions_stats_skipped 0
setstate Licht.Kueche 2022-01-08 15:50:03 attrTemplateVersion 20211030
setstate Licht.Kueche 2023-03-08 09:37:26 cfg_changed_cnt 0
setstate Licht.Kueche 2023-03-08 09:37:26 cloud_connected false
setstate Licht.Kueche 2023-03-08 09:37:26 cloud_enabled false
setstate Licht.Kueche 2023-03-08 09:37:27 event
setstate Licht.Kueche 2023-03-08 09:37:27 event_cnt 0
setstate Licht.Kueche 2023-03-08 09:37:26 fs_free 149345
setstate Licht.Kueche 2023-03-08 09:37:26 fs_size 233681
setstate Licht.Kueche 2023-03-08 09:37:26 fw_ver 20221027-091427/v1.12.1-ga9117d3
setstate Licht.Kueche 2023-03-08 09:37:26 has_update false
setstate Licht.Kueche 2023-03-08 09:37:26 id SH-Kuechenlicht
setstate Licht.Kueche 2023-03-08 10:29:26 input0 1
setstate Licht.Kueche 2023-03-08 09:37:26 inputs_1_event
setstate Licht.Kueche 2023-03-08 09:37:26 inputs_1_event_cnt 0
setstate Licht.Kueche 2023-03-08 09:37:26 inputs_1_input 1
setstate Licht.Kueche 2023-03-08 09:37:26 ip 192.168.57.223
setstate Licht.Kueche 2023-03-08 09:37:26 mac 500291F09D8A
setstate Licht.Kueche 2023-03-08 09:37:26 meters_1_is_valid true
setstate Licht.Kueche 2023-03-08 09:37:26 meters_1_power 0.00
setstate Licht.Kueche 2023-03-08 09:37:26 model SHSW-1
setstate Licht.Kueche 2023-03-08 09:37:26 mqtt_connected true
setstate Licht.Kueche 2023-03-08 09:37:26 new_fw false
setstate Licht.Kueche 2023-03-08 09:37:26 online true
setstate Licht.Kueche 2023-03-08 09:37:26 ram_free 39480
setstate Licht.Kueche 2023-03-08 09:37:26 ram_total 51688
setstate Licht.Kueche 2023-03-08 10:29:26 relay0 off
setstate Licht.Kueche 2023-03-08 10:25:17 relay0_OnOffTime 1
setstate Licht.Kueche 2023-03-08 10:25:17 relay0_OnTime 8703
setstate Licht.Kueche 2023-03-08 10:25:17 relay_0_energy_kWh 0.0362625
setstate Licht.Kueche 2023-03-08 09:37:26 relays_1_has_timer false
setstate Licht.Kueche 2023-03-08 09:37:26 relays_1_ison false
setstate Licht.Kueche 2023-03-08 09:37:26 relays_1_source input
setstate Licht.Kueche 2023-03-08 09:37:26 relays_1_timer_duration 0
setstate Licht.Kueche 2023-03-08 09:37:26 relays_1_timer_remaining 0
setstate Licht.Kueche 2023-03-08 09:37:26 relays_1_timer_started 0
setstate Licht.Kueche 2023-03-08 09:37:26 serial 79
setstate Licht.Kueche 2023-03-08 10:25:17 state off
setstate Licht.Kueche 2023-03-08 09:37:26 time 09:37
setstate Licht.Kueche 2023-03-08 09:37:26 unixtime 1678264647
setstate Licht.Kueche 2022-11-01 10:58:54 update_beta_version 20221014-081312/v1.12.1-rc1-gd2158aa
setstate Licht.Kueche 2023-03-08 09:37:26 update_has_update false
setstate Licht.Kueche 2023-03-08 09:37:26 update_new_version 20221027-091427/v1.12.1-ga9117d3
setstate Licht.Kueche 2023-03-08 09:37:26 update_old_version 20221027-091427/v1.12.1-ga9117d3
setstate Licht.Kueche 2023-03-08 09:37:26 update_status idle
setstate Licht.Kueche 2023-03-08 09:37:26 uptime 1803698
setstate Licht.Kueche 2023-03-08 09:37:26 wifi_sta_connected true
setstate Licht.Kueche 2023-03-08 09:37:26 wifi_sta_ip 192.168.57.223
setstate Licht.Kueche 2023-03-08 09:37:26 wifi_sta_rssi -52
setstate Licht.Kueche 2023-03-08 09:37:26 wifi_sta_ssid Internet

Durch das attr Licht.Kueche alexaName Küchenlicht sollte das Licht.Kueche als "Küchenlicht" bei Alexa bekannt sein.

In meinem ./fhem habe ich eine Datei namens alexa-fhem.cfg mit folgendem Inhalt:
{
   "connections" : [
      {
         "name" : "FHEM",
         "server" : "127.0.0.1",
         "uid" : 999,
         "webname" : "fhem",
         "filter" : "alexaName=..*",
         "port" : "8083"
      }
   ],
   "sshproxy" : {
      "ssh" : "/usr/bin/ssh",
      "description" : "FHEM Connector"
   }
}


Irgendetwas klappt da offensichtlich mit der "Übersetzung" der Alexa-Namen nicht. Oder?

Nachtrag:
Ich habe gerade eine interessante Entdeckung gemacht: alexa-fhem hat im docker ein Volumen angelegt ....
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 08 März 2023, 11:10:15
Etwas mehr Infos (Logauszug) bzgl. alexa-fhem wären interessant.

Also kann alexa-fhem (im alexa-fhem Container) den ssh aufbauen, also den Vereinsserver erreichen?
Müsste man (im Device sehen und auch) im alexa-fhem Log.

Dann: kann alexa-fhem (alexa-fhem Container) fhem (im fhem Container) erreichen? (sieht so aus). Was wird beim "Auslesen" des fhem durch alexa-fhem alles (und wie) gefunden? Würde man auch im alexa-fhem Log finden.

Dass das alexa-fhem Log im fhem-Container leer ist, ist logisch: dort läuft ja alexa-fhem auch nicht ;)

Dass beim Alexa-Device (im fhem Container) steht, dass alexa-fhem nicht läuft und installiert werden sollte/müsste ist ja dadurch auch logisch (-> Unschönheit, wurde ja bereits angesprochen).
Ein Alexa-Device im fhem Container ist eigentlich nicht nötig, was dadurch kommt sind halt die Attribute genericDeviceType/homebridgeMapping. Das sind aber "nur" Erweiterungen des userattr in global (könnten also auch anders dazugebracht werden) und auch nicht "vollständig", es fehlen wohl einige Dinge wie genericDeviceType media usw.

EDIT:
hier also (noch mal) kurz

alexa-fhem (das nodejs-Zeugs) läuft im alexa-fhem Container. Dieser muss halt dafür sorgen, dass alexa-fhem läuft und immer wieder gestartet wird, sollte es sich "ungewollt" beenden (das übernimmt normalerweise eben das Alexa-Device bei einer "bare metal Installation").
In der DORTIGEN alexa-fhem Konfiguration muss eingestellt sein, wie alexa-fhem die Devices in fhem (-> fhem Container) erreichen/auslesen und steuern kann.
Mir nicht ganz klar bzw. "unschön": wenn fhem mit Zugangsdaten abgesichert ist, dann wird das normalerweise ("bare metal") im Alexa-Device eingetragen und verschlüsselt abgelegt. Es gibt (gab zumindest) die Möglichkeit das auch bei der Connection in der alexa-fhem Konfiguration einzutragen. Dann halt in "plain Text" (unschön!).

fhem läuft im fhem Container (eh klar ;) ). Dort werden Devices mit den entsprechenden Attributen "versorgt" wichtig/Pflicht ist alexaName (bzw. eben passend zur "Filter-Einstellung" in der alexa-fhem Konfiguration [alexa-fhem Container]). Wenn die automatische Erkennung nicht reicht, bzw. besser ist es genericDeviceType zu setzen. Wenn man was anpassen muss, weil es falsch "interpretiert" wird (oder nicht/falsch/unpassend automatisch Erkannt wird), dann noch mit homebridgeMapping "nachhelfen".

Damit diese Attribute vorhanden sind, gibt es das Alexa-Device und dieses kümmert sich auch um Start/Stop/etc. von alexa-fhem (im "bare metal" Umfeld). Zusätzlich gibt es (neu) auch Aufrufe, um Devices an Amazon/Alexa zu "melden", damit diese "gefunden" werden (bzw. agr nicht mehr "gesucht" werden müssen: "Alexa suche smarte Geräte"). Dies geht im Docker Umfeld nicht (denke ich: Alexa-Device im fhem Container hat ja keinen Zugriff auf alexa-fhem im alexa-fhem Container). Wenn also in fhem (fhem Container) Devices für die Alexa-Sprachsteuerung vorbereitet wurden (Attribute vergeben) oder Änderungen vorgenommen wurden, dann muss alexa-fhem neu gestartet werden: alexa-fhem Container neu starten?
Ist halt im "bare metal" Umfeld angenehmer/einfacher bzw. sogar ohne Neustart machbar.
(nicht schlimm bzw. starte ich auch einfach alexa-fhem neu durch [ich habe "bare metal" / und bleibe auch dabei :)  ])

Hier sieht man, dass das Alexa-Device eigentlich (im Docker-Umfeld) nicht notwendig ist/wäre, sofern man irgendwie dafür sorgt, dass es eben die Attribute-Einträge im userattr in global gibt/gäbe :)

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 08 März 2023, 12:03:31
Zitat von: rallye am 08 März 2023, 10:44:52
Nachtrag:
Ich habe gerade eine interessante Entdeckung gemacht: alexa-fhem hat im docker ein Volumen angelegt ....
Zumindest das ist nicht in Ordnung mit Deiner Definition. Sieht bei mir so aus:
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 08 März 2023, 13:01:29
Zitat von: Otto123 am 08 März 2023, 12:03:31
Zumindest das ist nicht in Ordnung mit Deiner Definition. Sieht bei mir so aus:
Sehe ich auch so. Meine Definition lautet:
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    container_name: alexa-fhem
    restart: always
#    ports:
#      - "3000:3000"
    volumes:
      - /opt/alexa-fhem/:/alexa-fhem"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Vienna

und danach sollte dieses Volume eben nicht erzeugt sondern /opt/alexa-fhem genommen werden. Ich hab den Container und das Volume gelöscht, nach einem restart ohne alexa-fhem war das Volume nicht vorhanden, doch nach neuerlichem Hinzufügen von Alexa-fhem ist dieses Volume auch wieder da. Inhalt ist übrigens:
alexa-fhem.json  config.json
Das Log im Portainer beim Starten gibt keinen Hinweis darauf, dass ein volume erzeugt Wirt:
Preparing user environment ...
  - Generating SSH Ed25519 client certificate for user 'alexa-fhem' ...
  - Generating SSH RSA client certificate for user 'alexa-fhem' ...
  - Creating default config in /alexa-fhem/config.json ...
  - Creating symlink to config.json in /alexa-fhem/.alexa/config.json ...
Starting alexa-fhem ...
[3/8/2023, 12:40:37 PM] os.homedir()=/alexa-fhem
[3/8/2023, 12:40:37 PM] using config from /alexa-fhem/.alexa/config.json
*** CONFIG: parsed completely
[3/8/2023, 12:40:37 PM] this is alexa-fhem 0.5.64
[3/8/2023, 12:40:37 PM] connecting to FHEM ...

Ich denke, darum kümmere ich mich im 2ten Schritt, nachdem Alexa meine Devices wieder schaltet.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 08 März 2023, 13:09:37
/opt/alexa-fhem/ "darf" denn da wer? /opt hat ja per default nur rootdrwxr-xr-x   5 root root 4,0K Sep 27 17:25 opt
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 08 März 2023, 13:23:57
Zitat von: MadMax-FHEM am 08 März 2023, 11:10:15
Etwas mehr Infos (Logauszug) bzgl. alexa-fhem wären interessant.

Ich wollte euch nicht zumüllen  ;) aber du hast Recht!


Zitat von: MadMax-FHEM am 08 März 2023, 11:10:15
Also kann alexa-fhem (im alexa-fhem Container) den ssh aufbauen, also den Vereinsserver erreichen?
Müsste man (im Device sehen und auch) im alexa-fhem Log.
So wie ich das Log lese: ja. Aber ich muss ehrlich sagen, ich habe den damals lt. Instructions gesicherten Key nach dem Umstieg nirgends eingegeben sondern einfach die non-Docker-config 1:1 in die Dockerumgebung übernommen

Zitat von: MadMax-FHEM am 08 März 2023, 11:10:15
Dann: kann alexa-fhem (alexa-fhem Container) fhem (im fhem Container) erreichen? (sieht so aus). Was wird beim "Auslesen" des fhem durch alexa-fhem alles (und wie) gefunden? Würde man auch im alexa-fhem Log finden.

Dass das alexa-fhem Log im fhem-Container leer ist, ist logisch: dort läuft ja alexa-fhem auch nicht ;)

Dass beim Alexa-Device (im fhem Container) steht, dass alexa-fhem nicht läuft und installiert werden sollte/müsste ist ja dadurch auch logisch (-> Unschönheit, wurde ja bereits angesprochen).
Ein Alexa-Device im fhem Container ist eigentlich nicht nötig, was dadurch kommt sind halt die Attribute genericDeviceType/homebridgeMapping. Das sind aber "nur" Erweiterungen des userattr in global (könnten also auch anders dazugebracht werden) und auch nicht "vollständig", es fehlen wohl einige Dinge wie genericDeviceType media usw.

Hier mal das Log ab initialem Start von alexa-fhem
       
Preparing user environment ...
  - Generating SSH Ed25519 client certificate for user 'alexa-fhem' ...
  - Generating SSH RSA client certificate for user 'alexa-fhem' ...
  - Creating default config in /alexa-fhem/config.json ...
  - Creating symlink to config.json in /alexa-fhem/.alexa/config.json ...
Starting alexa-fhem ...
[3/8/2023, 12:40:37 PM] os.homedir()=/alexa-fhem
[3/8/2023, 12:40:37 PM] using config from /alexa-fhem/.alexa/config.json
*** CONFIG: parsed completely
[3/8/2023, 12:40:37 PM] this is alexa-fhem 0.5.64
[3/8/2023, 12:40:37 PM] connecting to FHEM ...
[3/8/2023, 12:40:37 PM] [FHEM] defaults to: will not send proactive events
[3/8/2023, 12:40:37 PM] [FHEM] trying longpoll to listen for fhem events
[3/8/2023, 12:40:37 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1678275637952
[3/8/2023, 12:40:37 PM] Server listening on: http://:::3000 for direct connections
[3/8/2023, 12:40:38 PM] [FHEM] longpoll error: Error: connect ECONNREFUSED 172.18.0.4:8083, retry in: 5000msec
*** FHEM: connection failed: Error: connect ECONNREFUSED 172.18.0.4:8083
[3/8/2023, 12:40:43 PM] [FHEM] trying longpoll to listen for fhem events
[3/8/2023, 12:40:43 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1678275643022
[3/8/2023, 12:40:43 PM] [FHEM] longpoll error: Error: connect ECONNREFUSED 172.18.0.4:8083, retry in: 10000msec
*** FHEM: connection failed: Error: connect ECONNREFUSED 172.18.0.4:8083
[3/8/2023, 12:40:53 PM] [FHEM] trying longpoll to listen for fhem events
[3/8/2023, 12:40:53 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1678275653041
[3/8/2023, 12:41:26 PM] [FHEM] got csrfToken: TheToken0815
[3/8/2023, 12:41:26 PM] [FHEM] Checking devices and attributes...
[3/8/2023, 12:41:26 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:26 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:26 PM] [FHEM] waiting for events ...
[3/8/2023, 12:41:26 PM] [FHEM] Fetching FHEM devices...
[3/8/2023, 12:41:26 PM] [FHEM] fetching: http://fhem:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:30 PM] [FHEM] alexa device is alexa
[3/8/2023, 12:41:30 PM] [FHEM] alexa will not send proactive events
[3/8/2023, 12:41:30 PM] [FHEM] alexa uses ID: 6252daf1-f33f-55a1-4a44-8f36a1f64b8663cf
[3/8/2023, 12:41:30 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22alexa-fhem%20version%22%7D%20%3D%20%220.5.64%22%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:30 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bget%20alexa%20proxyToken%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:30 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Blist%20alexa%20.eventToken%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:30 PM] Server listening on: http://127.0.0.1:38483 for proxy connections
[3/8/2023, 12:41:30 PM] *** SSH: checking proxy configuration
[3/8/2023, 12:41:30 PM] sshautoconf: home=/alexa-fhem, spath=/alexa-fhem/.alexa, cpath=/alexa-fhem/.alexa/config.json, sshpath=/alexa-fhem/.ssh
[3/8/2023, 12:41:30 PM] Passed config: {
  alexa: {
    port: 3000,
    name: 'Alexa',
    ssl: false,
    keyFile: '/certs/alexa-fhem.key',
    certFile: '/certs/alexa-fhem.crt',
    'nat-pmp': '',
    'nat-upnp': false,
    applicationId: [ 'amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX' ],
    oauthClientID: [ 'amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' ]
  },
  sshproxy: {
    description: 'FHEM Connector',
    ssh: '/usr/bin/ssh',
    options: [ '-i', '/alexa-fhem/.ssh/id_rsa', '-p', 58824, 'fhem-va.fhem.de' ],
    'bind-ip': '127.0.0.1',
    server: Server {
      maxHeaderSize: undefined,
      insecureHTTPParser: undefined,
      _events: [Object: null prototype],
      _eventsCount: 3,
      _maxListeners: undefined,
      _connections: 0,
      _handle: [TCP],
      _usingWorkers: false,
      _workers: [],
      _unref: false,
      allowHalfOpen: true,
      pauseOnConnect: false,
      noDelay: false,
      keepAlive: false,
      keepAliveInitialDelay: 0,
      httpAllowHalfOpen: false,
      timeout: 0,
      keepAliveTimeout: 5000,
      maxHeadersCount: null,
      maxRequestsPerSocket: 0,
      headersTimeout: 60000,
      requestTimeout: 0,
      _connectionKey: '4:127.0.0.1:0',
      [Symbol(IncomingMessage)]: [Function: IncomingMessage],
      [Symbol(ServerResponse)]: [Function: ServerResponse],
      [Symbol(kCapture)]: false,
      [Symbol(async_id_symbol)]: 160,
      [Symbol(kUniqueHeaders)]: null
    }
  },
  connections: [
    {
      name: 'FHEM',
      webname: 'fhem',
      filter: 'alexaName=..*',
      uid: '6062',
      port: '8083',
      server: 'fhem'
    }
  ]
}
[3/8/2023, 12:41:30 PM] sshautoconf: SSH key seems to exist

3, 12:41:34 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bjsonlist2%20alexa%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
*** FHEM: connected
[3/8/2023, 12:41:34 PM] [FHEM] got: 67 results
[3/8/2023, 12:41:34 PM] [FHEM] AVR_X2800H is soundbar
[3/8/2023, 12:41:34 PM] [FHEM] AVR_X2800H has
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Volume [volume;cached]
[3/8/2023, 12:41:34 PM] [FHEM]   Mute [mute]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Power [power]
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] AVR_X2800H will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] AVR_X2800H uses ID: 639c8717-f33f-55a1-b849-d03c766ca7dd64fb
  2023-03-08 12:41:34 caching: AVR_X2800H-volume: 51.5
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Volume: 52 (as number; from '51.5')
  2023-03-08 12:41:34 caching: AVR_X2800H-mute: off
  2023-03-08 12:41:34 caching: AVR_X2800H-power: off
[3/8/2023, 12:41:34 PM] [FHEM] AVR_X2800H-power not a number: off
  2023-03-08 12:41:34 caching: AVR_X2800H-state: disconnected
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.BD is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.BD has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.BD will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.BD uses ID: 00:15:8d:00:06:8b:8d:d3-01-0006
  2023-03-08 12:41:34 caching: Fenster.BD-battery: 98
  2023-03-08 12:41:34 caching: Fenster.BD-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.BD-temperature: 23
  2023-03-08 12:41:34 caching: Fenster.BD-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.KE is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.KE has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.KE will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.KE uses ID: 00:15:8d:00:06:8b:bb:ab-01-0006
  2023-03-08 12:41:34 caching: Fenster.KE-battery: 91
  2023-03-08 12:41:34 caching: Fenster.KE-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.KE-temperature: 23
  2023-03-08 12:41:34 caching: Fenster.KE-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.KU is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.KU has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.KU will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.KU uses ID: 00:15:8d:00:02:8d:6c:f7-01-0006
  2023-03-08 12:41:34 caching: Fenster.KU-battery: 100
  2023-03-08 12:41:34 caching: Fenster.KU-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.KU-temperature: 23
  2023-03-08 12:41:34 caching: Fenster.KU-humidity: 34.71
  2023-03-08 12:41:34 caching: Fenster.KU-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.DG is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.DG has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.DG will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.DG uses ID: 00:15:8d:00:06:8b:41:84-01-0006
  2023-03-08 12:41:34 caching: Fenster.Li.DG-battery: 100
  2023-03-08 12:41:34 caching: Fenster.Li.DG-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.Li.DG-temperature: 23
  2023-03-08 12:41:34 caching: Fenster.Li.DG-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.SO is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.SO has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom AirPressure [pressure]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.SO will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.SO uses ID: 00:15:8d:00:06:8b:b8:e8-01-0006
  2023-03-08 12:41:34 caching: Fenster.Li.SO-battery: 95
  2023-03-08 12:41:34 caching: Fenster.Li.SO-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.Li.SO-temperature: 25
  2023-03-08 12:41:34 caching: Fenster.Li.SO-pressure: 984
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom AirPressure: 984 (as number; from '984')
  2023-03-08 12:41:34 caching: Fenster.Li.SO-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.SW is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.SW has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.SW will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Li.SW uses ID: 00:15:8d:00:06:9b:16:6f-01-0006
  2023-03-08 12:41:34 caching: Fenster.Li.SW-battery: 100
  2023-03-08 12:41:34 caching: Fenster.Li.SW-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.Li.SW-temperature: 16
  2023-03-08 12:41:34 caching: Fenster.Li.SW-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.NW is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.NW has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.NW will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.NW uses ID: 00:15:8d:00:06:8b:85:8d-01-0006
  2023-03-08 12:41:34 caching: Fenster.NW-battery: 85
  2023-03-08 12:41:34 caching: Fenster.NW-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.NW-temperature: 26
  2023-03-08 12:41:34 caching: Fenster.NW-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Re.DG is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Re.DG has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Re.DG will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Re.DG uses ID: 00:15:8d:00:06:9b:1b:95-01-0006
  2023-03-08 12:41:34 caching: Fenster.Re.DG-battery: 100
  2023-03-08 12:41:34 caching: Fenster.Re.DG-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.Re.DG-temperature: 22
  2023-03-08 12:41:34 caching: Fenster.Re.DG-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Re.SW is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Re.SW has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Re.SW will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.Re.SW uses ID: 00:15:8d:00:06:8b:42:f3-01-0006
  2023-03-08 12:41:34 caching: Fenster.Re.SW-battery: 100
  2023-03-08 12:41:34 caching: Fenster.Re.SW-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.Re.SW-temperature: 21
  2023-03-08 12:41:34 caching: Fenster.Re.SW-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.SH is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.SH has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.SH will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.SH uses ID: 00:15:8d:00:06:93:b9:6c-01-0006
  2023-03-08 12:41:34 caching: Fenster.SH-battery: 100
  2023-03-08 12:41:34 caching: Fenster.SH-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.SH-temperature: 23
  2023-03-08 12:41:34 caching: Fenster.SH-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.SZ is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.SZ has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.SZ will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.SZ uses ID: 00:15:8d:00:06:8b:8e:58-01-0006
  2023-03-08 12:41:34 caching: Fenster.SZ-battery: 95
  2023-03-08 12:41:34 caching: Fenster.SZ-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.SZ-temperature: 23
  2023-03-08 12:41:34 caching: Fenster.SZ-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.WC is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.WC has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.WC will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.WC uses ID: 00:15:8d:00:02:a7:12:8e-01-0006
  2023-03-08 12:41:34 caching: Fenster.WC-battery: 100
  2023-03-08 12:41:34 caching: Fenster.WC-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.WC-temperature: 21
  2023-03-08 12:41:34 caching: Fenster.WC-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.WR is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.WR has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.WR will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Fenster.WR uses ID: 00:15:8d:00:02:8e:b2:4e-01-0006
  2023-03-08 12:41:34 caching: Fenster.WR-battery: 100
  2023-03-08 12:41:34 caching: Fenster.WR-reachable: 1
  2023-03-08 12:41:34 caching: Fenster.WR-temperature: 21
  2023-03-08 12:41:34 caching: Fenster.WR-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] FritzboxGuest is switch
[3/8/2023, 12:41:34 PM] [FHEM] FritzboxGuest has
[3/8/2023, 12:41:34 PM] [FHEM] FritzboxGuest will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] FritzboxGuest uses ID: 61e6ae67-f33f-55a1-444e-1d36594aecc76ca9
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.HR_Clima is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.HR_Clima has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Actuation [ValvePosition]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.HR_Clima will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.HR_Clima uses ID: CUL_HM.6A21E604
  2023-03-08 12:41:34 caching: HK_Vent.HR_Clima-desired-temp: 19.0
  2023-03-08 12:41:34 caching: HK_Vent.HR_Clima-ValvePosition: 0
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Actuation: 0 (as number; from '0')
  2023-03-08 12:41:34 caching: HK_Vent.HR_Clima-measured-temp: 20.0
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.VZ_Clima is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.VZ_Clima has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Actuation [ValvePosition]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.VZ_Clima will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.VZ_Clima uses ID: CUL_HM.6A200B04
  2023-03-08 12:41:34 caching: HK_Vent.VZ_Clima-desired-temp: 18.0
  2023-03-08 12:41:34 caching: HK_Vent.VZ_Clima-ValvePosition: 0
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Actuation: 0 (as number; from '0')
  2023-03-08 12:41:34 caching: HK_Vent.VZ_Clima-measured-temp: 20.9
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.WC_Clima is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.WC_Clima has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Actuation [ValvePosition]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.WC_Clima will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.WC_Clima uses ID: CUL_HM.63A11004
  2023-03-08 12:41:34 caching: HK_Vent.WC_Clima-desired-temp: 20.0
  2023-03-08 12:41:34 caching: HK_Vent.WC_Clima-ValvePosition: 36
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Actuation: 36 (as number; from '36')
  2023-03-08 12:41:34 caching: HK_Vent.WC_Clima-measured-temp: 20.7
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.WR_Clima is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.WR_Clima has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Actuation [ValvePosition]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.WR_Clima will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] HK_Vent.WR_Clima uses ID: CUL_HM.6A207804
  2023-03-08 12:41:34 caching: HK_Vent.WR_Clima-desired-temp: 18.0
  2023-03-08 12:41:34 caching: HK_Vent.WR_Clima-ValvePosition: 0
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Actuation: 0 (as number; from '0')
  2023-03-08 12:41:34 caching: HK_Vent.WR_Clima-measured-temp: 18.9
[3/8/2023, 12:41:34 PM] [FHEM] Licht.BD is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.BD has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.BD will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.BD uses ID: 61d9b6bd-f33f-55a1-c5ad-a63f44963aa9d236
  2023-03-08 12:41:34 caching: Licht.BD-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Balkon.EG is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Balkon.EG has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Balkon.EG will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Balkon.EG uses ID: 61d99525-f33f-55a1-dcdb-a6c7d02428b7612c
  2023-03-08 12:41:34 caching: Licht.Balkon.EG-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Balkon.OG is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Balkon.OG has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Balkon.OG will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Balkon.OG uses ID: 61d9b010-f33f-55a1-59bb-cb6e4701dce87d04
  2023-03-08 12:41:34 caching: Licht.Balkon.OG-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.DG is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.DG has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.DG will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.DG uses ID: 61d9b2b2-f33f-55a1-f9b9-e6abb6f91f5ef4a9
  2023-03-08 12:41:34 caching: Licht.DG-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.EZ is light
[3/8/2023, 12:41:34 PM] [FHEM] Licht.EZ has
[3/8/2023, 12:41:34 PM] [FHEM]   On [onoff;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   Brightness [bri]
[3/8/2023, 12:41:34 PM] [FHEM]   Hue [hue;hue;0-65535]
[3/8/2023, 12:41:34 PM] [FHEM]   Saturation [sat;sat;0-254]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Color Temperature [ct]
[3/8/2023, 12:41:34 PM] [FHEM]   colormode [colormode]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.EZ will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.EZ uses ID: Licht.EZ
  2023-03-08 12:41:34 caching: Licht.EZ-onoff: 0
  2023-03-08 12:41:34 caching: Licht.EZ-bri: 254
  2023-03-08 12:41:34 caching: Licht.EZ-sat: 0
  2023-03-08 12:41:34 caching: Licht.EZ-ct: 0
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Color Temperature: 154 (as number; from '0')
  2023-03-08 12:41:34 caching: Licht.EZ-reachable: 1
[3/8/2023, 12:41:34 PM] [FHEM] Licht.EZ_LED is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.EZ_LED has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.EZ_LED will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.EZ_LED uses ID: 61d98957-f33f-55a1-fa26-fd11bbff4f51efdf
  2023-03-08 12:41:34 caching: Licht.EZ_LED-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Garten is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Garten has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Garten will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Garten uses ID: 62332241-f33f-55a1-6703-7ec6e51a88221a67
  2023-03-08 12:41:34 caching: Licht.Garten-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Keller is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Keller has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Keller will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Keller uses ID: 623deb63-f33f-55a1-7187-60d572297a41c0ee
  2023-03-08 12:41:34 caching: Licht.Keller-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Kueche is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Kueche has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Kueche will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Kueche uses ID: 61d9a485-f33f-55a1-f785-8242bec208a51c2f
  2023-03-08 12:41:34 caching: Licht.Kueche-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Kuechentisch is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Kuechentisch has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Kuechentisch will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Kuechentisch uses ID: 61d9984b-f33f-55a1-881a-e5d3a82c42a966bf
  2023-03-08 12:41:34 caching: Licht.Kuechentisch-state: on
[3/8/2023, 12:41:34 PM] [FHEM] Licht.NW is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.NW has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.NW will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.NW uses ID: 61d9b4de-f33f-55a1-4216-55ce5000ba0a771f
  2023-03-08 12:41:34 caching: Licht.NW-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SO is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SO has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SO will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SO uses ID: 61daef6b-f33f-55a1-a365-773412c01594c03b
  2023-03-08 12:41:34 caching: Licht.SO-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SW is light
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SW has
[3/8/2023, 12:41:34 PM] [FHEM]   On [onoff;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   Brightness [bri]
[3/8/2023, 12:41:34 PM] [FHEM]   Hue [hue;hue;0-65535]
[3/8/2023, 12:41:34 PM] [FHEM]   Saturation [sat;sat;0-254]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Color Temperature [ct]
[3/8/2023, 12:41:34 PM] [FHEM]   colormode [colormode]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SW will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SW uses ID: Licht.SW
  2023-03-08 12:41:34 caching: Licht.SW-onoff: 0
  2023-03-08 12:41:34 caching: Licht.SW-bri: 26
  2023-03-08 12:41:34 caching: Licht.SW-sat: 0
  2023-03-08 12:41:34 caching: Licht.SW-ct: 367
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Color Temperature: 367 (as number; from '367')
  2023-03-08 12:41:34 caching: Licht.SW-colormode: ct
  2023-03-08 12:41:34 caching: Licht.SW-reachable: 1
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SZ is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SZ has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SZ will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.SZ uses ID: 61d9aadb-f33f-55a1-1344-62c76276bf16002e
  2023-03-08 12:41:34 caching: Licht.SZ-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Stehlampen is light
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Stehlampen has
[3/8/2023, 12:41:34 PM] [FHEM]   On [onoff;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   Brightness [bri]
[3/8/2023, 12:41:34 PM] [FHEM]   Hue [hue;hue;0-65535]
[3/8/2023, 12:41:34 PM] [FHEM]   Saturation [sat;sat;0-254]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Color Temperature [ct]
[3/8/2023, 12:41:34 PM] [FHEM]   colormode [colormode]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Stehlampen will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Stehlampen uses ID: Licht.Stehlampen
  2023-03-08 12:41:34 caching: Licht.Stehlampen-onoff: 0
  2023-03-08 12:41:34 caching: Licht.Stehlampen-bri: 77
  2023-03-08 12:41:34 caching: Licht.Stehlampen-hue: 6098
  2023-03-08 12:41:34 caching: Licht.Stehlampen-sat: 140
  2023-03-08 12:41:34 caching: Licht.Stehlampen-ct: 366
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Color Temperature: 366 (as number; from '366')
  2023-03-08 12:41:34 caching: Licht.Stehlampen-colormode: nonuniform
  2023-03-08 12:41:34 caching: Licht.Stehlampen-reachable: 1
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Terasse is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Terasse has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Terasse will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.Terasse uses ID: 623b4312-f33f-55a1-8ce3-0cf9fafc6084893d
  2023-03-08 12:41:34 caching: Licht.Terasse-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.WR is switch
[3/8/2023, 12:41:34 PM] [FHEM] Licht.WR has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.WR will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.WR uses ID: 61d9a91b-f33f-55a1-2fe6-9dbeec9e6b1276f9
  2023-03-08 12:41:34 caching: Licht.WR-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Licht.WZ is light
[3/8/2023, 12:41:34 PM] [FHEM] Licht.WZ has
[3/8/2023, 12:41:34 PM] [FHEM]   On [onoff;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   Brightness [bri]
[3/8/2023, 12:41:34 PM] [FHEM]   Hue [hue;hue;0-65535]
[3/8/2023, 12:41:34 PM] [FHEM]   Saturation [sat;sat;0-254]
[3/8/2023, 12:41:34 PM] [FHEM]   Custom Color Temperature [ct]
[3/8/2023, 12:41:34 PM] [FHEM]   colormode [colormode]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM] Licht.WZ will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Licht.WZ uses ID: Licht.WZ
  2023-03-08 12:41:34 caching: Licht.WZ-onoff: 0
  2023-03-08 12:41:34 caching: Licht.WZ-bri: 1
  2023-03-08 12:41:34 caching: Licht.WZ-sat: 0
  2023-03-08 12:41:34 caching: Licht.WZ-ct: 0
[3/8/2023, 12:41:34 PM] [FHEM]     caching: Custom Color Temperature: 154 (as number; from '0')
  2023-03-08 12:41:34 caching: Licht.WZ-reachable: 1
[3/8/2023, 12:41:34 PM] [FHEM] SW.Heizpumpe is switch
[3/8/2023, 12:41:34 PM] [FHEM] SW.Heizpumpe has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] SW.Heizpumpe will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] SW.Heizpumpe uses ID: 63820653-f33f-55a1-49c4-61cfb885e6a42c30
  2023-03-08 12:41:34 caching: SW.Heizpumpe-state: off
[3/8/2023, 12:41:34 PM] [FHEM] SW.Poolheizung is TemperatureSensor
[3/8/2023, 12:41:34 PM] [FHEM] SW.Poolheizung has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM] SW.Poolheizung will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] SW.Poolheizung uses ID: 62c6db66-f33f-55a1-d017-b0015ba427480138
  2023-03-08 12:41:34 caching: SW.Poolheizung-state: off
  2023-03-08 12:41:34 caching: SW.Poolheizung-temperature: 10.0
[3/8/2023, 12:41:34 PM] [FHEM] SW.Poolpumpe is switch
[3/8/2023, 12:41:34 PM] [FHEM] SW.Poolpumpe has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM] SW.Poolpumpe will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] SW.Poolpumpe uses ID: 62494dd6-f33f-55a1-521e-c9ed8d28e20d281f
  2023-03-08 12:41:34 caching: SW.Poolpumpe-state: off
[3/8/2023, 12:41:34 PM] [FHEM] Tempsensor.KE is TemperatureSensor
[3/8/2023, 12:41:34 PM] [FHEM] Tempsensor.KE has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM] Tempsensor.KE will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Tempsensor.KE uses ID: 00:15:8d:00:04:4c:04:07-01-0402
  2023-03-08 12:41:34 caching: Tempsensor.KE-battery: 95
  2023-03-08 12:41:34 caching: Tempsensor.KE-reachable: 1
  2023-03-08 12:41:34 caching: Tempsensor.KE-temperature: 18.01
[3/8/2023, 12:41:34 PM] [FHEM] TempsensorEingang is TemperatureSensor
[3/8/2023, 12:41:34 PM] [FHEM] TempsensorEingang has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM] TempsensorEingang will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] TempsensorEingang uses ID: 00:15:8d:00:04:1d:a7:58-01-0402
  2023-03-08 12:41:34 caching: TempsensorEingang-battery: 72
  2023-03-08 12:41:34 caching: TempsensorEingang-reachable: 1
  2023-03-08 12:41:34 caching: TempsensorEingang-temperature: 9.06
[3/8/2023, 12:41:34 PM] [FHEM] Therm.BD_Climate is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] Therm.BD_Climate has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] Therm.BD_Climate will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Therm.BD_Climate uses ID: CUL_HM.633F4C02
  2023-03-08 12:41:34 caching: Therm.BD_Climate-desired-temp: 18.5
  2023-03-08 12:41:34 caching: Therm.BD_Climate-measured-temp: 20.1
  2023-03-08 12:41:34 caching: Therm.BD_Climate-humidity: 51
[3/8/2023, 12:41:34 PM] [FHEM] Therm.DG_Climate is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] Therm.DG_Climate has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] Therm.DG_Climate will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Therm.DG_Climate uses ID: CUL_HM.633F5F02
  2023-03-08 12:41:34 caching: Therm.DG_Climate-desired-temp: 18.5
  2023-03-08 12:41:34 caching: Therm.DG_Climate-measured-temp: 21.3
  2023-03-08 12:41:34 caching: Therm.DG_Climate-humidity: 47
[3/8/2023, 12:41:34 PM] [FHEM] Therm.EZ_Climate is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] Therm.EZ_Climate has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] Therm.EZ_Climate will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Therm.EZ_Climate uses ID: CUL_HM.72657502
  2023-03-08 12:41:34 caching: Therm.EZ_Climate-desired-temp: 20.0
  2023-03-08 12:41:34 caching: Therm.EZ_Climate-measured-temp: 22.4
  2023-03-08 12:41:34 caching: Therm.EZ_Climate-humidity: 42
[3/8/2023, 12:41:34 PM] [FHEM] Therm.NW_Climate is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] Therm.NW_Climate has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] Therm.NW_Climate will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Therm.NW_Climate uses ID: CUL_HM.72658102
  2023-03-08 12:41:34 caching: Therm.NW_Climate-desired-temp: 18.0
  2023-03-08 12:41:34 caching: Therm.NW_Climate-measured-temp: 18.2
  2023-03-08 12:41:34 caching: Therm.NW_Climate-humidity: 47
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SO_Climate is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SO_Climate has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SO_Climate will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SO_Climate uses ID: CUL_HM.72655802
  2023-03-08 12:41:34 caching: Therm.SO_Climate-desired-temp: 18.0
  2023-03-08 12:41:34 caching: Therm.SO_Climate-measured-temp: 20.0
  2023-03-08 12:41:34 caching: Therm.SO_Climate-humidity: 41
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SW_Climate is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SW_Climate has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SW_Climate will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SW_Climate uses ID: CUL_HM.63407C02
  2023-03-08 12:41:34 caching: Therm.SW_Climate-desired-temp: 18.5
  2023-03-08 12:41:34 caching: Therm.SW_Climate-measured-temp: 19.6
  2023-03-08 12:41:34 caching: Therm.SW_Climate-humidity: 51
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SZ_Climate is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SZ_Climate has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SZ_Climate will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Therm.SZ_Climate uses ID: CUL_HM.72657102
  2023-03-08 12:41:34 caching: Therm.SZ_Climate-desired-temp: 17.0
  2023-03-08 12:41:34 caching: Therm.SZ_Climate-measured-temp: 18.1
  2023-03-08 12:41:34 caching: Therm.SZ_Climate-humidity: 55
[3/8/2023, 12:41:34 PM] [FHEM] Therm.WZ_Climate is thermostat
[3/8/2023, 12:41:34 PM] [FHEM] Therm.WZ_Climate has
[3/8/2023, 12:41:34 PM] [FHEM]   TargetTemperature [desired-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [measured-temp]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentHeatingCoolingState [undefined]
[3/8/2023, 12:41:34 PM] [FHEM] Therm.WZ_Climate will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Therm.WZ_Climate uses ID: CUL_HM.72657002
  2023-03-08 12:41:34 caching: Therm.WZ_Climate-desired-temp: 18.5
  2023-03-08 12:41:34 caching: Therm.WZ_Climate-measured-temp: 19.6
  2023-03-08 12:41:34 caching: Therm.WZ_Climate-humidity: 51
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.EZ is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.EZ has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.EZ will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.EZ uses ID: 00:15:8d:00:06:78:ef:1a-01-0006
  2023-03-08 12:41:34 caching: Tuere.Balkon.EZ-battery: 100
  2023-03-08 12:41:34 caching: Tuere.Balkon.EZ-reachable: 1
  2023-03-08 12:41:34 caching: Tuere.Balkon.EZ-temperature: 23
  2023-03-08 12:41:34 caching: Tuere.Balkon.EZ-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.SO is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.SO has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.SO will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.SO uses ID: 00:15:8d:00:06:8b:8d:d2-01-0006
  2023-03-08 12:41:34 caching: Tuere.Balkon.SO-battery: 100
  2023-03-08 12:41:34 caching: Tuere.Balkon.SO-reachable: 1
  2023-03-08 12:41:34 caching: Tuere.Balkon.SO-temperature: 23
  2023-03-08 12:41:34 caching: Tuere.Balkon.SO-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.SW is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.SW has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.SW will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Balkon.SW uses ID: 00:15:8d:00:06:8b:84:bf-01-0006
  2023-03-08 12:41:34 caching: Tuere.Balkon.SW-battery: 100
  2023-03-08 12:41:34 caching: Tuere.Balkon.SW-reachable: 1
  2023-03-08 12:41:34 caching: Tuere.Balkon.SW-temperature: 22
  2023-03-08 12:41:34 caching: Tuere.Balkon.SW-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Terasse.Li.WZ is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Terasse.Li.WZ has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Terasse.Li.WZ will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Terasse.Li.WZ uses ID: 00:15:8d:00:06:93:b5:f5-01-0006
  2023-03-08 12:41:34 caching: Tuere.Terasse.Li.WZ-battery: 100
  2023-03-08 12:41:34 caching: Tuere.Terasse.Li.WZ-reachable: 1
  2023-03-08 12:41:34 caching: Tuere.Terasse.Li.WZ-temperature: 22
  2023-03-08 12:41:34 caching: Tuere.Terasse.Li.WZ-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Terasse.Re.WZ is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Terasse.Re.WZ has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Terasse.Re.WZ will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.Terasse.Re.WZ uses ID: 00:15:8d:00:06:8b:8f:19-01-0006
  2023-03-08 12:41:34 caching: Tuere.Terasse.Re.WZ-battery: 100
  2023-03-08 12:41:34 caching: Tuere.Terasse.Re.WZ-reachable: 1
  2023-03-08 12:41:34 caching: Tuere.Terasse.Re.WZ-temperature: 23
  2023-03-08 12:41:34 caching: Tuere.Terasse.Re.WZ-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.VZ is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.VZ has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentRelativeHumidity [humidity]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.VZ will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] Tuere.VZ uses ID: 00:15:8d:00:06:8b:bb:97-01-0006
  2023-03-08 12:41:34 caching: Tuere.VZ-battery: 100
  2023-03-08 12:41:34 caching: Tuere.VZ-reachable: 1
  2023-03-08 12:41:34 caching: Tuere.VZ-temperature: 22
  2023-03-08 12:41:34 caching: Tuere.VZ-humidity: 48.07
  2023-03-08 12:41:34 caching: Tuere.VZ-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Ankleidezimmer is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Ankleidezimmer has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Ankleidezimmer will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Ankleidezimmer uses ID: 00:15:8d:00:09:1b:2f:c0-01-0006
  2023-03-08 12:41:34 caching: ZiTuere.Ankleidezimmer-battery: 100
  2023-03-08 12:41:34 caching: ZiTuere.Ankleidezimmer-reachable: 1
  2023-03-08 12:41:34 caching: ZiTuere.Ankleidezimmer-temperature: 19
  2023-03-08 12:41:34 caching: ZiTuere.Ankleidezimmer-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Badezimmer is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Badezimmer has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Badezimmer will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Badezimmer uses ID: 00:15:8d:00:09:1b:30:db-01-0006
  2023-03-08 12:41:34 caching: ZiTuere.Badezimmer-battery: 100
  2023-03-08 12:41:34 caching: ZiTuere.Badezimmer-reachable: 1
  2023-03-08 12:41:34 caching: ZiTuere.Badezimmer-temperature: 23
  2023-03-08 12:41:34 caching: ZiTuere.Badezimmer-state: open
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Gaestezimmer is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Gaestezimmer has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Gaestezimmer will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Gaestezimmer uses ID: 00:15:8d:00:06:93:b9:79-01-0006
  2023-03-08 12:41:34 caching: ZiTuere.Gaestezimmer-battery: 100
  2023-03-08 12:41:34 caching: ZiTuere.Gaestezimmer-reachable: 1
  2023-03-08 12:41:34 caching: ZiTuere.Gaestezimmer-temperature: 21
  2023-03-08 12:41:34 caching: ZiTuere.Gaestezimmer-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Keller is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Keller has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Keller will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Keller uses ID: 00:15:8d:00:09:1b:31:41-01-0006
  2023-03-08 12:41:34 caching: ZiTuere.Keller-battery: 100
  2023-03-08 12:41:34 caching: ZiTuere.Keller-reachable: 1
  2023-03-08 12:41:34 caching: ZiTuere.Keller-temperature: 22
  2023-03-08 12:41:34 caching: ZiTuere.Keller-state: open
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Schlafzimmer is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Schlafzimmer has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Schlafzimmer will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Schlafzimmer uses ID: 00:15:8d:00:09:1b:2f:b0-01-0006
  2023-03-08 12:41:34 caching: ZiTuere.Schlafzimmer-battery: 100
  2023-03-08 12:41:34 caching: ZiTuere.Schlafzimmer-reachable: 1
  2023-03-08 12:41:34 caching: ZiTuere.Schlafzimmer-temperature: 18
  2023-03-08 12:41:34 caching: ZiTuere.Schlafzimmer-state: open
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.WC is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.WC has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.WC will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.WC uses ID: 00:15:8d:00:09:1b:30:0d-01-0006
  2023-03-08 12:41:34 caching: ZiTuere.WC-battery: 98
  2023-03-08 12:41:34 caching: ZiTuere.WC-reachable: 1
  2023-03-08 12:41:34 caching: ZiTuere.WC-temperature: 26
  2023-03-08 12:41:34 caching: ZiTuere.WC-state: closed
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Wirtschaftsraum is ContactSensor
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Wirtschaftsraum has
[3/8/2023, 12:41:34 PM] [FHEM]   BatteryLevel [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   StatusLowBattery [battery]
[3/8/2023, 12:41:34 PM] [FHEM]   Reachable [reachable]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM]   ContactSensorState [state]
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Wirtschaftsraum will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] ZiTuere.Wirtschaftsraum uses ID: 00:15:8d:00:09:1b:30:68-01-0006
  2023-03-08 12:41:34 caching: ZiTuere.Wirtschaftsraum-battery: 100
  2023-03-08 12:41:34 caching: ZiTuere.Wirtschaftsraum-reachable: 1
  2023-03-08 12:41:34 caching: ZiTuere.Wirtschaftsraum-temperature: 21
  2023-03-08 12:41:34 caching: ZiTuere.Wirtschaftsraum-state: open
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug01 is switch
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug01 has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug01 will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug01 uses ID: 63b43f8e-f33f-55a1-fa23-85eb542a10c8bad1
  2023-03-08 12:41:34 caching: shellyplug01-state: on
  2023-03-08 12:41:34 caching: shellyplug01-temperature: 45.83
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug02 is switch
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug02 has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug02 will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug02 uses ID: 63a465db-f33f-55a1-f8c1-a89c34f31ed9d223
  2023-03-08 12:41:34 caching: shellyplug02-state: off
  2023-03-08 12:41:34 caching: shellyplug02-temperature: 20.53
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug03 is switch
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug03 has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug03 will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug03 uses ID: 63a44b1c-f33f-55a1-a8e3-6b5d5d4fcc27fe82
  2023-03-08 12:41:34 caching: shellyplug03-state: on
  2023-03-08 12:41:34 caching: shellyplug03-temperature: 28.60
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug04 is switch
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug04 has
[3/8/2023, 12:41:34 PM] [FHEM]   On [state;on,off]
[3/8/2023, 12:41:34 PM] [FHEM]   CurrentTemperature [temperature]
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug04 will not send proactive events
[3/8/2023, 12:41:34 PM] [FHEM] shellyplug04 uses ID: 63ac5749-f33f-55a1-e731-ff9a466311b3c4e1
  2023-03-08 12:41:34 caching: shellyplug04-state: on
  2023-03-08 12:41:34 caching: shellyplug04-temperature: 34.53
[3/8/2023, 12:41:35 PM] BearerToken '...17E91' read from alexa
[3/8/2023, 12:41:35 PM] [FHEM] got .eventToken
[3/8/2023, 12:41:35 PM] refreshing token
[3/8/2023, 12:41:35 PM] 39_alexa.pm is new version: true
[3/8/2023, 12:41:52 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bset%20alexa%20proxyToken%207508FECC3613C548%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
  2023-03-08 12:41:52 caching: shellyplug01-temperature: 48.36
[3/8/2023, 12:41:52 PM] [FHEM]     caching: CurrentTemperature: 48.36 (as number; from '48.36')
  2023-03-08 12:41:52 caching: shellyplug04-temperature: 34.58
[3/8/2023, 12:41:52 PM] [FHEM]     caching: CurrentTemperature: 34.58 (as number; from '34.58')
  2023-03-08 12:41:52 caching: shellyplug03-temperature: 28.78
[3/8/2023, 12:41:52 PM] [FHEM]     caching: CurrentTemperature: 28.78 (as number; from '28.78')
  2023-03-08 12:41:52 caching: Therm.DG_Climate-measured-temp: 21.4
[3/8/2023, 12:41:52 PM] [FHEM]     caching: CurrentTemperature: 21.4 (as number; from '21.4')
[3/8/2023, 12:41:52 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bset%20alexa%20proxyKey%207387FF3D-4450F6A92D564DD0-7508FECC3613C548%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:52 PM] sshautoconf: completed successfully
[3/8/2023, 12:41:52 PM] *** SSH: proxy configuration set up done
[3/8/2023, 12:41:52 PM] Reading alexaFHEM.ProxyConnection set to starting;; starting SSH
[3/8/2023, 12:41:52 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20alexa%20alexaFHEM.ProxyConnection%20starting%3B%3B%20starting%20SSH%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:52 PM] Starting SSH with -R 1234:127.0.0.1:38483 -oServerAliveInterval=90 -i /alexa-fhem/.ssh/id_rsa -p 58824 fhem-va.fhem.de
[3/8/2023, 12:41:52 PM] SSH setup completed with new bearer token
[3/8/2023, 12:41:52 PM] failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token. User may have revoked or didn't grant the permission.'
[3/8/2023, 12:41:53 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3B%7B%20FW_directNotify(%22%23FHEMWEB%3AWEB%22%2C%20%22location.reload('true')%22%2C%20%22%22)%20%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:53 PM] Reading alexaFHEM.ProxyConnection set to running;; SSH connected
[3/8/2023, 12:41:53 PM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20alexa%20alexaFHEM.ProxyConnection%20running%3B%3B%20SSH%20connected%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
[3/8/2023, 12:41:53 PM] *** SSH: proxy connection established
[3/8/2023, 12:41:53 PM] SSH: Welcome at the reverse proxy!  This pseudoshell does not react to any input - do not get irritated. 
  2023-03-08 12:42:03 caching: shellyplug01-temperature: 49.30
[3/8/2023, 12:42:03 PM] [FHEM]     caching: CurrentTemperature: 49.3 (as number; from '49.30')
  2023-03-08 12:42:04 caching: shellyplug04-temperature: 34.69
[3/8/2023, 12:42:04 PM] [FHEM]     caching: CurrentTemperature: 34.69 (as number; from '34.69')
  2023-03-08 12:42:05 caching: shellyplug03-temperature: 28.72
[3/8/2
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 08 März 2023, 13:32:54
Zitat von: Otto123 am 08 März 2023, 13:09:37
/opt/alexa-fhem/ "darf" denn da wer? /opt hat ja per default nur rootdrwxr-xr-x   5 root root 4,0K Sep 27 17:25 opt
Ja, eh (auf österreichisch ;) )
Aber die "Anderen" nehmen sich doch auch ihre Rechte!?

drwxr-xr-x 11 root root    4096 Mar  8 12:48 .
drwxr-xr-x 18 root root    4096 Jan 23 18:52 ..
drwxr-xr-x  2 6062    6062 4096 Mar  8 09:36 alexa-fhem
-rw-r--r--  1 root root    3311 Mar  8 12:39 compose.yaml
drwx--x--x  4 root root    4096 Jan 23 19:22 containerd
drwxr-xr-x  4 1111    1111 4096 Mar  8 13:15 deCONZ
drwxr-xr-x 17 fhem dialout 4096 Mar  8 11:33 fhem
drwxr-x--- 17 fhem dialout 4096 Mar  8 12:40 fhemdocker
drwxr-xr-x 14 root root    4096 Mar  8 12:34 homeassistant
drwxr-xr-x 14 root root    4096 Mar  5 10:17 homeassistant.sav
drwxr-xr-x  6 1883    1883 4096 Mar  2 16:08 mosquitto
drwxr-x---  3 fhem dialout 4096 Feb 27 09:58 opt-old

wobei: Homeassistant (verwende ich als Frontend für FHEM zwecks WAF  8) ) und deCONZ laufen privileged. Selbst alexa-fhem hat sich mit UID&GID=6062 "verewigt".
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 08 März 2023, 14:36:00
Zitat
[3/8/2023, 12:40:37 PM] Server listening on: http://:::3000 for direct connections
[3/8/2023, 12:40:38 PM] [FHEM] longpoll error: Error: connect ECONNREFUSED 172.18.0.4:8083, retry in: 5000msec

Brauchst du wirklich den Port 3000?
Nutzt du einen Custom Skill?
Einen eigenen (lokal "gehosteten") Smart Home Skill?

Wenn nein, dann ist der dazugehörige Eintrag in der alexa-config unnötig (tut aber auch erst mal nicht weh denke ich)...

Der zweite Eintrag

Zitat
[3/8/2023, 12:40:38 PM] [FHEM] longpoll error: Error: connect ECONNREFUSED 172.18.0.4:8083, retry in: 5000msec

Liest sich, also ob eben alexa-fhem (alexa-fhem Container) nicht auf das fhem (fhem Container) zugreifen kann.

Der Name "fhem" wird wohl zu IP 172.18.0.4 "aufgelöst" (ist das die IP unter der fhem zu erreichen ist/wäre?)...
...aber der Zugriff wird nicht zugelassen: User/PW aktiviert in fhem? Https?

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 08 März 2023, 18:16:00
Zitat von: MadMax-FHEM am 08 März 2023, 14:36:00
Brauchst du wirklich den Port 3000?
Nutzt du einen Custom Skill?
Einen eigenen (lokal "gehosteten") Smart Home Skill?

Wenn nein, dann ist der dazugehörige Eintrag in der alexa-config unnötig (tut aber auch erst mal nicht weh denke ich)...
Nein, ich habe keine Custom Skills. Woher das mot dem Port 3000 kommt ist mir nicht bekannt, denn in meiner alexa-fhem section in der. compose.yaml habe ich es mit "#" versehen. Die sieht so aus:
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    container_name: alexa-fhem
    restart: always
#    ports:
#      - "3000:3000"
    volumes:
      - /opt/alexa-fhem/:/alexa-fhem"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Vienna


Das docker inspect alexa-fhem
liefert folgende Ausgabe
docker inspect alexa-fhem
[
    {
        "Id": "fdf549cdb401db12a6255760e89b4cf5a5ba2281b65e7bf30679d4e689a64c44",
        "Created": "2023-03-08T11:40:26.27529189Z",
        "Path": "/entry.sh",
        "Args": [
            "start"
        ],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 462933,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2023-03-08T11:40:35.624134528Z",
            "FinishedAt": "0001-01-01T00:00:00Z",
            "Health": {
                "Status": "healthy",
                "FailingStreak": 0,
                "Log": [
                    {
                        "Start": "2023-03-08T17:59:28.631535788+01:00",
                        "End": "2023-03-08T17:59:29.057991271+01:00",
                        "ExitCode": 0,
                        "Output": "alexa-port(3000): OK"
                    },
                    {
                        "Start": "2023-03-08T17:59:49.081634651+01:00",
                        "End": "2023-03-08T17:59:49.526568276+01:00",
                        "ExitCode": 0,
                        "Output": "alexa-port(3000): OK"
                    },
                    {
                        "Start": "2023-03-08T18:00:09.57916001+01:00",
                        "End": "2023-03-08T18:00:09.932173243+01:00",
                        "ExitCode": 0,
                        "Output": "alexa-port(3000): OK"
                    },
                    {
                        "Start": "2023-03-08T18:00:29.940322612+01:00",
                        "End": "2023-03-08T18:00:30.44375213+01:00",
                        "ExitCode": 0,
                        "Output": "alexa-port(3000): OK"
                    },
                    {
                        "Start": "2023-03-08T18:00:50.470963573+01:00",
                        "End": "2023-03-08T18:00:50.836188579+01:00",
                        "ExitCode": 0,
                        "Output": "alexa-port(3000): OK"
                    }
                ]
            }
        },
        "Image": "sha256:233be9acde299e37430133d04ea2720f58a41b03ad9a63c97efd70590bf1933d",
        "ResolvConfPath": "/var/lib/docker/containers/fdf549cdb401db12a6255760e89b4cf5a5ba2281b65e7bf30679d4e689a64c44/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/fdf549cdb401db12a6255760e89b4cf5a5ba2281b65e7bf30679d4e689a64c44/hostname",
        "HostsPath": "/var/lib/docker/containers/fdf549cdb401db12a6255760e89b4cf5a5ba2281b65e7bf30679d4e689a64c44/hosts",
        "LogPath": "/var/lib/docker/containers/fdf549cdb401db12a6255760e89b4cf5a5ba2281b65e7bf30679d4e689a64c44/fdf549cdb401db12a6255760e89b4cf5a5ba2281b65e7bf30679d4e689a64c44-json.log",
        "Name": "/alexa-fhem",
        "RestartCount": 0,
        "Driver": "overlay2",
        "Platform": "linux",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "",
        "ExecIDs": null,
        "HostConfig": {
            "Binds": [
                "/opt/alexa-fhem/:/alexa-fhem\":rw"
            ],
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "json-file",
                "Config": {}
            },
            "NetworkMode": "opt_default",
            "PortBindings": {},
            "RestartPolicy": {
                "Name": "always",
                "MaximumRetryCount": 0
            },
            "AutoRemove": false,
            "VolumeDriver": "",
            "VolumesFrom": null,
            "ConsoleSize": [
                0,
                0
            ],
            "CapAdd": null,
            "CapDrop": null,
            "CgroupnsMode": "private",
            "Dns": null,
            "DnsOptions": null,
            "DnsSearch": null,
            "ExtraHosts": [],
            "GroupAdd": null,
            "IpcMode": "private",
            "Cgroup": "",
            "Links": null,
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": null,
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "Isolation": "",
            "CpuShares": 0,
            "Memory": 0,
            "NanoCpus": 0,
            "CgroupParent": "",
            "BlkioWeight": 0,
            "BlkioWeightDevice": null,
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 0,
            "CpuQuota": 0,
            "CpuRealtimePeriod": 0,
            "CpuRealtimeRuntime": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": null,
            "DeviceCgroupRules": null,
            "DeviceRequests": null,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": null,
            "OomKillDisable": null,
            "PidsLimit": null,
            "Ulimits": null,
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0,
            "MaskedPaths": [
                "/proc/asound",
                "/proc/acpi",
                "/proc/kcore",
                "/proc/keys",
                "/proc/latency_stats",
                "/proc/timer_list",
                "/proc/timer_stats",
                "/proc/sched_debug",
                "/proc/scsi",
                "/sys/firmware"
            ],
            "ReadonlyPaths": [
                "/proc/bus",
                "/proc/fs",
                "/proc/irq",
                "/proc/sys",
                "/proc/sysrq-trigger"
            ]
        },
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/226088a600524adfae03ae04a47e970dcec2d9642a475d6bfae3f9e9656c6635-init/diff:/var/lib/docker/overlay2/6753d03e3f840e5ae7a64faeb978358a81afd5ed99a7b796f3e202344458a60c/diff:/var/lib/docker/overlay2/a1e6fee80f5a0f24b2cdb0b2df6f902cffbcb681b94994f88b53bacf1c479d32/diff:/var/lib/docker/overlay2/a251cf07b5503895e7bf87c27ba7ac6e7d5d6f62116486c11385c4d582c6e7a4/diff:/var/lib/docker/overlay2/71d40369291b3d6b82424e2ed1064f97f6230ec80195ad03282777be5e7ffb2a/diff:/var/lib/docker/overlay2/a415940e64ef0a80aeddba9dc03c79629684a9a773deb0293aaf54adc0a78216/diff:/var/lib/docker/overlay2/50b435056b4adf9577dd40890f1ea24112ea6d6c84a72fe1616ca69bee74efbd/diff:/var/lib/docker/overlay2/c2b04d1732f6da633d0a9ebc87a3c0685bb00ae4da1b040fb145c8a948c6b69a/diff:/var/lib/docker/overlay2/ee09b0dc8b29d468324b8ed8bcbe87e29a6fe63d45a8000d194c14ca77c29ff0/diff:/var/lib/docker/overlay2/6598b1a96ed5b8194abdba8e0f29ede80a71cf05f3a971625c927c7e87d9f622/diff:/var/lib/docker/overlay2/759dcb3652439f17039aa171cabe9cb724221c9212b39d81730a534817c78044/diff:/var/lib/docker/overlay2/741f43680dcb27af1e4735291c336db156604dfbcbc0d1c12a41f4731c6d6b08/diff:/var/lib/docker/overlay2/ff196049f3a7d8cf8a2b7b5c9993717cd12b537437ceb1364902932097452656/diff:/var/lib/docker/overlay2/90e584432cd4d50e52dd0949d8f8223b81c400793be8b6a138132a5ff6ef715d/diff:/var/lib/docker/overlay2/aea368ccef58bfc667c53c8cc98fc727124540f549b2624c623a2094937e1682/diff:/var/lib/docker/overlay2/38cc87254b81b9dcf1a5635ad59eb5528d5d51f84b5962263698ba608b7e7f42/diff",
                "MergedDir": "/var/lib/docker/overlay2/226088a600524adfae03ae04a47e970dcec2d9642a475d6bfae3f9e9656c6635/merged",
                "UpperDir": "/var/lib/docker/overlay2/226088a600524adfae03ae04a47e970dcec2d9642a475d6bfae3f9e9656c6635/diff",
                "WorkDir": "/var/lib/docker/overlay2/226088a600524adfae03ae04a47e970dcec2d9642a475d6bfae3f9e9656c6635/work"
            },
            "Name": "overlay2"
        },
        "Mounts": [
            {
                "Type": "volume",
                "Name": "0ad672ccb62d1552e445c9e43c04e6093b9825ab79386ef83dcc292c17b17834",
                "Source": "/var/lib/docker/volumes/0ad672ccb62d1552e445c9e43c04e6093b9825ab79386ef83dcc292c17b17834/_data",
                "Destination": "/alexa-fhem",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            },
            {
                "Type": "bind",
                "Source": "/opt/alexa-fhem",
                "Destination": "/alexa-fhem\"",
                "Mode": "rw",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],
        "Config": {
            "Hostname": "fdf549cdb401",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": true,
            "AttachStderr": true,
            "ExposedPorts": {
                "3000/tcp": {}
            },
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": [
                "TZ=Europe/Vienna",
                "ALEXAFHEM_UID=6062",
                "ALEXAFHEM_GID=6062",
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "NODE_VERSION=16.19.1",
                "YARN_VERSION=1.22.19",
                "NODE_ENV=production",
                "TERM=xterm",
                "LANG=en_US.UTF-8",
                "LANGUAGE=en_US:en",
                "LC_ALL=en_US.UTF-8"
            ],
            "Cmd": [
                "start"
            ],
            "Healthcheck": {
                "Test": [
                    "CMD-SHELL",
                    "/health-check.sh"
                ],
                "Interval": 20000000000,
                "Timeout": 10000000000,
                "StartPeriod": 10000000000,
                "Retries": 5
            },
            "Image": "ghcr.io/fhem/fhem/alexa-fhem:latest",
            "Volumes": {
                "/alexa-fhem": {}
            },
            "WorkingDir": "/alexa-fhem",
            "Entrypoint": [
                "/entry.sh"
            ],
            "OnBuild": null,
            "Labels": {
                "com.docker.compose.config-hash": "85dab9e873047d91aaf434c331c089f9bf24c9135c77abceda916ea4d8ba05a6",
                "com.docker.compose.container-number": "1",
                "com.docker.compose.depends_on": "",
                "com.docker.compose.image": "sha256:233be9acde299e37430133d04ea2720f58a41b03ad9a63c97efd70590bf1933d",
                "com.docker.compose.oneoff": "False",
                "com.docker.compose.project": "opt",
                "com.docker.compose.project.config_files": "/opt/compose.yaml",
                "com.docker.compose.project.working_dir": "/opt",
                "com.docker.compose.service": "alexa-fhem",
                "com.docker.compose.version": "2.16.0",
                "org.fhem.alexa.authors": "https://github.com/justme-1968/alexa-fhem/graphs/contributors",
                "org.fhem.alexa.description": "Amazon alexa voice assistant support for FHEM",
                "org.fhem.alexa.documentation": "https://wiki.fhem.de/wiki/FHEM_Connector",
                "org.fhem.alexa.licenses": "GPL-2.0",
                "org.fhem.alexa.source": "https://github.com/justme-1968/alexa-fhem",
                "org.fhem.alexa.url": "https://fhem.de/",
                "org.fhem.alexa.vendor": "FHEM-linux/arm64",
                "org.fhem.alexa.version": "0.5.64",
                "org.opencontainers.image.authors": "https://github.com/fhem/alexa-fhem-docker/graphs/contributors",
                "org.opencontainers.image.created": "2023-02-25T17:51:38.093Z",
                "org.opencontainers.image.description": "A FHEM complementary Docker image for Amazon alexa voice assistant, based on Debian.",
                "org.opencontainers.image.documentation": "https://github.com/fhem/alexa-fhem-docker/blob/7c1f7b8bd32173d7d9a0b050d29fe00a31c00e18/README.md",
                "org.opencontainers.image.licenses": "MIT",
                "org.opencontainers.image.revision": "7c1f7b8bd32173d7d9a0b050d29fe00a31c00e18",
                "org.opencontainers.image.source": "https://github.com/fhem/alexa-fhem-docker",
                "org.opencontainers.image.title": "alexa-fhem-docker",
                "org.opencontainers.image.url": "https://github.com/fhem/alexa-fhem-docker",
                "org.opencontainers.image.vendor": "FHEM",
                "org.opencontainers.image.version": "4.0.1"
            }
        },
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "2592f63c27847b5ef9427996fc753d051b4fd14c76574e490bf697d96149e1aa",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {
                "3000/tcp": null
            },
            "SandboxKey": "/var/run/docker/netns/2592f63c2784",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "",
            "Gateway": "",
            "GlobalIPv6Address": "",
            "GlobalIPv6PrefixLen": 0,
            "IPAddress": "",
            "IPPrefixLen": 0,
            "IPv6Gateway": "",
            "MacAddress": "",
            "Networks": {
                "opt_default": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": [
                        "alexa-fhem",
                        "alexa-fhem",
                        "fdf549cdb401"
                    ],
                    "NetworkID": "850e43a27cf9a87e0e1c3c91f082ccaecac6ba7ea9c92b698b858f6119438b8a",
                    "EndpointID": "815c72ffc9e371407f51d445bc0c23d0a14b89d97ead244dfa769b103912cef3",
                    "Gateway": "172.18.0.1",
                    "IPAddress": "172.18.0.6",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "02:42:ac:12:00:06",
                    "DriverOpts": null
                }
            }
        }
    }
]
josef@RasPi-Server:/opt $


Zitat von: MadMax-FHEM am 08 März 2023, 14:36:00
Der Name "fhem" wird wohl zu IP 172.18.0.4 "aufgelöst" (ist das die IP unter der fhem zu erreichen ist/wäre?)...
...aber der Zugriff wird nicht zugelassen: User/PW aktiviert in fhem? Https?
User/PW ist nicht aktiviert. Mein FHEM ist "von aussen" über IP 192.168.57.30:8083 erreichbar. 192.168.57.30 ist die IP meines Raspi auf dem auch der Docker läuft. Die IP-Range 172.18.0.xxx wird im Docker intern vergeben - da habe ich keinen Einfluss drauf genommen und mich nicht weiter darum gekümmert - auch kein Netzwerk für den Docker definiert. Anbei meine gesamte compose.yaml
version: '3'
services:

  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    ports:
      - "8000:8000"
      - "9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
    restart: unless-stopped
#
  deconz:
    image: ghcr.io/deconz-community/deconz-docker:latest
    container_name: deconz
    restart: always
    privileged: true                # This is important! Without it, the deCONZ>
    network_mode: host
    volumes:
      - /opt/deCONZ:/opt/deCONZ
    devices:
      - /dev/ttyACM0                # This is the USB device that Conbee II is >
    environment:
      - TZ=Europe/Vienna
      - DECONZ_DEVICE=/dev/ttyACM0   # This is the USB device that Conbee II is>
      - DECONZ_UID=1111
      - DECONZ_GID=1111
      - DECONZ_WEB_PORT=8080
#
#
  fhem:
    image: ghcr.io/fhem/fhem/fhem-docker:latest
    container_name: fhem
    hostname: fhem
    restart: always
    ports:
      - "1883:1883"
      - "8883:8883"
      - "8083:8083"
      - "8084:8084"
      - "8085:8085"
      - "7072:7072"
    volumes:
      - /opt/fhemdocker/:/opt/fhem/
    environment:
      FHEM_UID: 999
      FHEM_GID: 20
      TZ: Europe/Vienna
#
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /opt/homeassistant:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped
    privileged: true
    network_mode: host
#
  mosquitto:
    image: eclipse-mosquitto
    container_name: mosquitto
    restart: unless-stopped
    volumes:
      - /opt/mosquitto:/mosquitto
      - /opt/mosquitto/data:/mosquitto/data
      - /opt/mosquitto/log:/mosquitto/log
    ports:
      - 1885:1885
      - 9001:9001
#
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    container_name: alexa-fhem
    restart: always
#    ports:
#      - "3000:3000"
    volumes:
      - /opt/alexa-fhem/:/alexa-fhem"
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Vienna
#
  sonos:
    image: ghcr.io/svrooij/sonos2mqtt
    restart: unless-stopped
    ports:
      - "6329:6329"
    environment:
      - SONOS2MQTT_DEVICE=192.168.57.77 # IP of my SONOS One - Service discover>
      - SONOS2MQTT_MQTT=mqtt://192.168.57.30:1883 #
#      # - SONOS2MQTT_DISTINCT=true # if your want distinct topics
      - SONOS_LISTENER_HOST=192.168.57.30 # Docker host IP
#      # - SONOS_TTS_ENDPOINT=http://sonos-tts:5601/api/generate # If you deplo>
#
  minidlna:
    container_name: miniDLNA
    restart: unless-stopped
    network_mode: host
    image: vladgh/minidlna
    volumes:
      - /mnt/share/dlnaAudio:/media/Audio
      - /mnt/share/dlnaPictures:/media/Pictures
      - /mnt/share/dlnaVideo:/media/Video
    environment:
      - MINIDLNA_MEDIA_DIR_1=A,/media/Audio
      - MINIDLNA_MEDIA_DIR_2=P,/media/Pictures
      - MINIDLNA_MEDIA_DIR_3=V,/media/Video
      - MINIDLNA_FRIENDLY_NAME=MiniDLNA-Docker
      - MINIDLNA_MAX_CONNECTIONS=8
      - MINIDLNA_SERIAL=08154711
#
volumes:
  portainer_data:
    name: portainer_data
    external: true


Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 08 März 2023, 19:13:20
Das mit dem Port 3000 war ja ein Eintrag im alexa-fhem Log und ist (daher) in der alexa-fhem.cfg eingetragen.
Hat nichts mit Docker etc. zu tun.
(außer, dass man die Freigabe/Weiterleitung, falls man das nutzen will, anders einrichten muss, also wie das bei Docker halt so geht)

EDIT: aber das ist kein Problem. alexa-fhem würde halt auf Port 3000 warten, dass eine "Anfrage" von Amazon/Alexa kommt. Wenn nichts kommt, auch gut ;)

Wenn fhem über 192.168.57.30:8083 erreichbar ist, klappt das damit dann auch vom alexa-fhem Container aus?
Wenn ja, dann einfach das in die alexa-fhem.cfg eintragen.

Das alles hat nicht so wirklich mit Docker zu tun.
Das was in der alexa-fhem.cfg im Docker von alexa-fhem steht muss passen...

Mehr kann ich nicht sagen, da ich kein Docker nutze...
(und immer mehr dabei bleibe :)  )

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 08 März 2023, 19:16:48
Zitat von: rallye am 08 März 2023, 13:23:57
Ich wollte euch nicht zumüllen  ;) aber du


on: http://:::3000 for direct connections
[3/8/2023, 12:40:38 PM] [FHEM] longpoll error: Error: connect ECONNREFUSED 172.18.0.4:8083, retry in: 5000msec


Der Alexa-fhem Container kann den FHEM Server nicht erreichen.

Sind in deiner compose / Stack Konfiguration denn beide im gleichen Netzwerk?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 09 März 2023, 10:33:26
Ich hab jetzt mehrmals alexa-fhem gelöscht und von Scratch wieder aufgebaut bis endlich mein Volume /opt/alexa-fhem/ akzeptiert wurde (777 war alexa-fhem wegen ssh zuviel und blieb daher im unhealthy mode stehen. 755 ist was alexa-fhem mag).
Nun habe ich auch Daten drinnen
josef@RasPi-Server:/opt/alexa-fhem $ ls -al
total 20
drwxr-xr-x  4 6062 6062 4096 Mar  9 09:26 .
drwxr-xr-x 11 root root 4096 Mar  9 09:00 ..
drwxr-xr-x  2 root root 4096 Mar  9 09:26 .alexa
drwxr-xr-x  2 6062 6062 4096 Mar  9 09:26 .ssh
lrwxrwxrwx  1 root root   11 Mar  9 09:26 alexa-fhem.json -> config.json
-rw-r--r--  1 root root  631 Mar  9 09:26 config.json
josef@RasPi-Server:/opt/alexa-fhem $ ls -al .alexa/
total 8
drwxr-xr-x 2 root root 4096 Mar  9 09:26 .
drwxr-xr-x 4 6062 6062 4096 Mar  9 09:26 ..
lrwxrwxrwx 1 root root   14 Mar  9 09:26 config.json -> ../config.json
josef@RasPi-Server:/opt/alexa-fhem $ ls -al .ssh/
total 32
drwxr-xr-x 2 6062 6062 4096 Mar  9 09:26 .
drwxr-xr-x 4 6062 6062 4096 Mar  9 09:26 ..
-rw-r--r-- 1 6062 6062  516 Mar  9 09:26 config
-rw------- 1 6062 6062  411 Mar  9 09:26 id_ed25519
-rw-r--r-- 1 6062 6062  110 Mar  9 09:26 id_ed25519.pub
-rw------- 1 6062 6062 3381 Mar  9 09:26 id_rsa
-rw-r--r-- 1 6062 6062  754 Mar  9 09:26 id_rsa.pub
-rw-r--r-- 1 6062 6062  897 Mar  9 09:27 known_hosts
aber ein alexa-fhem.cfg finde ich nirgends  :(

Zitat von: MadMax-FHEM am 08 März 2023, 19:13:20
Wenn fhem über 192.168.57.30:8083 erreichbar ist, klappt das damit dann auch vom alexa-fhem Container aus?
Würde ich gerne beantworte, weiss aber nicht wie ich das herausfinde

Zitat von: MadMax-FHEM am 08 März 2023, 19:13:20
Wenn fhem über 192.168.57.30:8083 erreichbar ist, klappt das damit dann auch vom alexa-fhem Container aus?
Wenn ja, dann einfach das in die alexa-fhem.cfg eintragen.
Genau die alexa-fhem.cfg finde ich nirgends. Auch im ./fhem-Verzeichnis nicht  :'(


Zitat von: Sidey am 08 März 2023, 19:16:48
Der Alexa-fhem Container kann den FHEM Server nicht erreichen.

Sind in deiner compose / Stack Konfiguration denn beide im gleichen Netzwerk?

Grüße Sidey

Ja, sie sind nicht nur im selben Netzwerk, sondern auch am selben Raspi im selben Container. Der Raspi ist in der Netzwerk-Range 192.168.57.xxx, im Docker baut sich das Netzwerk mit der Range 172.18.0.xxx auf.

LG Rallye
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 09 März 2023, 10:42:53
Naja, bei einer "bare metal" Installation liegt die alexa-fhem.cfg (und heißt auch so) unter /opt/fhem (wenn ich mich jetzt nicht täusche, ist ja erreichbar per Edit-Files / wie geschrieben: "bare metal")...

Wo das bei alexa-fhem Docker liegt/heißt -> keine Ahnung :-\

Inhalt bei mir (unverändert, automatisch angelegt / bei "bare metal" bzw. bei mir läuft beides auf dem selben PI):


{
"connections":
[
{
"port": "8083",
"webname": "fhem",
"uid": 999,
"filter": "alexaName=..*",
"server": "127.0.0.1",
"name": "FHEM"
}
],
"sshproxy":
{
"ssh": "/usr/bin/ssh",
"description": "FHEM Connector"
}
}


Gibt es bei dir eine Datei mit solchem/ähnlichen Inhalt?

Was du (verm.) anpassen musst:
port: kann passen. Außer im Docker-Umfeld wird (oder du tust es) anders gemappt/nach außen gegeben oder nat. du hast z.B. für alexa-fhem einen zusätzlichen/anderen Port eingerichtet
server: -> wie du aus dem alexa-fhem Container das fhem im fhem Container erreichen kannst
uid: -> kann auch passen bzw. scheint zu passen? Es wird ja erkannt, wenn Rechte (in .ssh) nicht passen. fhem hat bei "bare metal" Standardinstallation eben 999

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 09 März 2023, 10:43:42
Zitat von: rallye am 09 März 2023, 10:33:26
aber ein alexa-fhem.cfg finde ich nirgends  :(
Die ist es :)
Zitatlrwxrwxrwx  1 root root   11 Mar  9 09:26 alexa-fhem.json -> config.json
-rw-r--r--  1 root root  631 Mar  9 09:26 config.json

Die Container "unterhalten" sich über das interne Netzwerk, es wird der service fhem gesucht. Wenn der service im Stack anders heißt, das docker Netzwerk "kaputt" ist oder ähnliches, klappt das nicht.
Dein FHEM hat defmod WEB FHEMWEB 8083 global da stehen?
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 09 März 2023, 11:08:59
Zitat von: MadMax-FHEM am 09 März 2023, 10:42:53
Gibt es bei dir eine Datei mit solchem/ähnlichen Inhalt?
Wenn ich Otto folge:
Zitat von: Otto123 am 09 März 2023, 10:43:42
Die ist es :)
dann ist die Antwort: ja. Sieht aber so aus:
{
  "alexa": {
    "port": 3000,
    "name": "Alexa",
    "ssl": false,
    "keyFile": "/certs/alexa-fhem.key",
    "certFile": "/certs/alexa-fhem.crt",
    "nat-pmp": "",
    "nat-upnp": false,
    "applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXX>
  },
  "sshproxy" : {
    "description" : "FHEM Connector",
    "ssh" : "/usr/bin/ssh"
  },
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "fhem"
    }
  ]
}

Wenn ich dich richtig verstanden habe, dann muss ich das       "uid": "6062", auf       "uid": "999", (ich habe meinem FHEM auch im Docker die UID 999 verpasst) ändern.
Zitat von: Otto123 am 09 März 2023, 10:43:42
Dein FHEM hat defmod WEB FHEMWEB 8083 global da stehen?
Ja, genau so hab ich es definiert

LG Rallye
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 09 März 2023, 11:27:51
Jetzt bin ich (wahrscheinlich) einen Schritt weiter, nachdem ich das mit der UID "angepasst" habe. Sowohl in der Alexa-Definition von FHEM, als auch im alexa-fhem Log taucht die selbe Fehlermeldung auf:
defmod alexa alexa
attr alexa alexaFHEM-config ./alexa-fhem.cfg
attr alexa alexaFHEM-log ./log/alexa-%Y-%m-%d.log
attr alexa alexaMapping #Characteristic=<name>=<value>,...\
On=verb=schalte,valueOn=an;;ein,valueOff=aus,valueToggle=um\
\
Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
Hue=verb=stelle,valuePrefix=auf,values=rot:0;;grün:128;;blau:200\
Hue=verb=färbe,values=rot:0;;grün:120;;blau:220\
\
Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER\
Saturation=verb=sättige,values=AMAZON.NUMBER\
\
TargetPosition=verb=mach,articles=den;;die,values=auf:100;;zu:0\
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad\
\
Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
#Weckzeit=verb=stelle,valuePrefix=auf;;für,values=AMAZON.TIME,valueSuffix=uhr
attr alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
light=licht,lampen\
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
attr alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr alexa echoRooms #<deviceId>=<room>\

attr alexa fhemIntents #IntentName=<sample utterance>\
gutenMorgen=guten morgen\
guteNacht=gute nacht
attr alexa persons #<personId>=<name>\

attr alexa room Server
attr alexa stateFormat alexaFHEM

setstate alexa stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
setstate alexa 2022-04-10 15:59:59 .eventToken {"access_token":"Atza|IwEBIKro_28XkyF9OtzRQU5bsUBgqalBMFlXo5umsy5f84e8lUBjab2d1nt4eTJQDjplckByJDIDzItDWTnsH3WNX1cxBFiWU1rxte-XpP5QRI3ug3Z3FQiO7oyp1Is6xNcgJiJG4cSOc_E9MotjB72wOPW28ZAL4YzyER_ZL5A9vcvWZaHvw491gbhZDGRGg3-NWt55_d7R8ElIAMfOYb6wpvzjATQkBdQBUy8WMgAEfs2wglhVym0pvpeyRY8KPeaXCCC59cfiCJAnF8yFJPDNa0XX","refresh_token":"Atzr|IwEBIPM8ijeKNHh2Gs5aZvnEjH1FmOX6DlMWzJBts5TSajwGnz2PQYhiUdv-jq2r3zo640weKU-bILP-E5e2o7Z0bsx9sic5VLMU8GH5TZBCDfAR3vOl8A7pjtaHVuEvWqU20gmsHyR9wFBT40IeULM2hCYRT-WabR-TJ0KMPO_VANePytIppK586waK8AGFa1a70_0wijN9UWMbr7USjpxWxzjNX6NKDR0T_BIdw3lxN68re99F5bUURpr1VxG26iVlBjniIqZcawCzGqgBnoBpVjw4","token_type":"bearer","expires_in":3600}
setstate alexa 2023-03-09 10:25:11 alexaFHEM stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
setstate alexa 2023-03-09 11:12:57 alexaFHEM.ProxyConnection error;; Reverse Proxy replied with neither registered nor unregistered status: out:  err:ssh: connect to host fhem-va.fhem.de port 58824: Cannot assign requested address\

setstate alexa 2023-03-09 10:25:54 alexaFHEM.bearerToken crypt:xxxxxxxxxxxxxx
setstate alexa 2023-03-09 10:25:54 alexaFHEM.skillRegKey crypt:xxxxxxxxxxxxx


setstate alexa 2023-03-09 11:12:57 alexaFHEM.ProxyConnection error;; Reverse Proxy replied with neither registered nor unregistered status: out:  err:ssh: connect to host fhem-va.fhem.de port 58824: Cannot assign requested address\
(Übrigens: das alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'. ist bei mir immer noch da, obwohl ich den Container mittlerweile mehrmals neu "pulled" habe

Und im alexa-fhem-log
[3/9/2023, 11:12:52 AM] [FHEM] shellyplug02 is already published
[3/9/2023, 11:12:52 AM] [FHEM] no device created for shellyplug02 (MQTT2_DEVICE)
[3/9/2023, 11:12:52 AM] [FHEM] shellyplug03 is already published
[3/9/2023, 11:12:52 AM] [FHEM] no device created for shellyplug03 (MQTT2_DEVICE)
[3/9/2023, 11:12:52 AM] [FHEM] shellyplug04 is already published
[3/9/2023, 11:12:52 AM] [FHEM] no device created for shellyplug04 (MQTT2_DEVICE)
[3/9/2023, 11:12:52 AM] Reading alexaFHEM.ProxyConnection set to error;; Reverse Proxy replied with neither registered nor unregistered status: out:  err:ssh: connect to host fhem-va.fhem.de port 58824: Cannot assign requested address
[3/9/2023, 11:12:52 AM] [FHEM]   executing: http://fhem:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20alexa%20alexaFHEM.ProxyConnection%20error%3B%3B%20Reverse%20Proxy%20replied%20with%20neither%20registered%20nor%20unregistered%20status%3A%20out%3A%20%20err%3Assh%3A%20connect%20to%20host%20fhem-va.fhem.de%20port%2058824%3A%20Cannot%20assign%20requested%20address%0D%0A%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=TheToken0815&XHR=1
[3/9/2023, 11:12:57 AM] failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token. User may have revoked or didn't grant the permission.'
  2023-03-09 11:13:00 caching: shellyplug04-temperature: 34.42
[3/9/2023, 11:13:00 AM] [FHEM]     caching: CurrentTemperature: 34.42 (as number; from '34.42')
[3/9/2023, 11:13:01 AM] failed to refresh token: Error: getaddrinfo EAI_AGAIN va.fhem.de
  2023-03-09 11:13:06 caching: shellyplug01-temperature: 27.38
[3/9/2023, 11:13:06 AM] [FHEM]     caching: CurrentTemperature: 27.38 (as number; from '27.38')
  2023-03-09 11:13:07 caching: shellyplug03-temperature: 29.41
[3/9/2023, 11:13:07 AM] [FHEM]     caching: CurrentTemperature: 29.41 (as number; from '29.41')

Kann das damit zutun haben, dass ich einfach die "alte" Config genommen habe? Irgendwelche Einträge wg. Vereinsserver habe ich seit der Erstinstallation (damals nach MadMax-FKEM-Sprech: "bare-metal") nie wieder gemacht.
Beim Starten bleibt der Container übrigens sehr lange im "starting"-Mode

Danke, LG Rallye
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 09 März 2023, 11:31:06
Zitat
  "alexa": {
    "port": 3000,
    "name": "Alexa",
    "ssl": false,
    "keyFile": "/certs/alexa-fhem.key",
    "certFile": "/certs/alexa-fhem.crt",
    "nat-pmp": "",
    "nat-upnp": false,
    "applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXX>
  },

Ist nur für Custom Skill oder einem "eigenen" (lokalen) Smart Home Skill -> wenn du das nicht hast, dann kann das weg ;)

Bzgl. den uid der User kann ich nichts sagen, keine Ahnung wer wo wie was bei Docker hat...

und bei "server" steht "fhem" und das wird (laut alexa-fhem Log) eben als 172.18.0.4 "aufgelöst".
Wenn das vom alexa-fhem Container zum fhem Container nicht geht, dann geht das nicht...
...ob und wie das bei Docker sein muss/müsste: keine Ahnung.

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 09 März 2023, 11:36:32
Also die Installationsmeldung KANNST DU IGNORIEREN!

Es gibt ja im fhem Container (wo das Alexa Device definiert ist) KEINE alexa-fhem Installation!
(außer bei "bare metal")

alexa-fhem läuft ja im alexa-fhem Container und das weiß doch fhem bzw. das Alexa-Device dort nicht...

Also ignoriere die einfach!

Hattest du nicht schon mal eine ssh-Verbindung zum Vereinsserver?

Der Zustand war/ist wichtiger...

Ich weiß nicht genau was alexa-fhem bzgl. uid prüft.
Aber (so scheint es) zumindest mal die Rechte im .ssh Ordner auf den alexa-fhem im alexa-fhem Container "schaut".
Welcher das bei Docker ist: keine Ahnung

(bei "bare metal": /opt/fhem/.ssh)

Darin sind die Schlüssel für die "Anmeldung" am Vereinsserver...
Evtl. geht auch deregistrieren und neu registrieren (inkl. neu Verbinden des Skills)...
...zu der Fehlermeldung
Zitatsetstate alexa 2023-03-09 11:12:57 alexaFHEM.ProxyConnection error;; Reverse Proxy replied with neither registered nor unregistered status: out:  err:ssh: connect to host fhem-va.fhem.de port 58824: Cannot assign requested address\
gibt es einiges im Forum (und im alexa-fhem Wiki: Probleme usw.)...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 09 März 2023, 12:08:35

Zitat von: MadMax-FHEM am 09 März 2023, 11:36:32
Hattest du nicht schon mal eine ssh-Verbindung zum Vereinsserver?
Ja, ich hatte schon (in "bare-metal-Zeiten") bereits eine Verbindung zum Vereinsserver. Muss mal nachsehen ob ich noch eine alte Sicherung finde.
Zitat von: MadMax-FHEM am 09 März 2023, 11:36:32
Welcher das bei Docker ist: keine Ahnung
(bei "bare metal": /opt/fhem/.ssh)
Den .ssh gibt's auch beim Docker in der /alexa-fhem
Zitat von: MadMax-FHEM am 09 März 2023, 11:36:32
Evtl. geht auch deregistrieren und neu registrieren (inkl. neu Verbinden des Skills)...
Damit habe ich eine Nachmittagsbeschäftigung auch schon  ;)

Danke

LG Rallye
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 09 März 2023, 12:13:08
Naja, entweder eine alte Sicherung und dann "Rechte-passend" die alten .ssh Schlüssel in den Ordner /.ssh von alexa-fhem einbringen...
...oder (evtl. schneller? ;)  ) das mit der Registrierung und Skill usw. neu.

Du kannst ja mal suchen...
...und parallel im Forum lesen wie das geht/gemacht wurde und dann entscheiden 8)

Viel Erfolg!

Dann halt noch die Sache mit: alexa-fhem muss eben fhem erreichen können (Einträge "server" und "port" in der Config von alexa-fhem)...

EDIT: wenn dich die "nicht installiert Meldung" stört, dann eben KEIN Alexa-Device in fhem ABER die Einträge in attr global userattr (die das Alexa Device "mitbringt") übernehmen/eintragen...

Gruß, Joachim
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 09 März 2023, 18:10:47
Nachdem ich euch die letzten Tage mit meinem Docker so sehr gequält habe und wahrscheinlich auch teilweise zur Verzweiflung gebracht habe ist es mir nun gelungen alexa-fhem "non-bare-metal" in die Gänge zu bekommen. Für Interessierte hänge ich meine Konfigurationen hier rein:
compose.yaml:

version: '3'
services:

  fhem:
    image: ghcr.io/fhem/fhem/fhem-docker:latest
    container_name: fhem
    hostname: fhem
    restart: always
    network_mode: host
    volumes:
      - /opt/fhemdocker/:/opt/fhem/
    environment:
      FHEM_UID: 999
      FHEM_GID: 20
      TZ: Europe/Vienna
#
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    container_name: alexa-fhem
    restart: always
    network_mode: host
    volumes:
      - /opt/alexa-fhem/://alexa-fhem/
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Vienna


/opt/alexa-fhem/config.json

{
  "alexa": {
    "port": 3000,
    "name": "Alexa",
    "ssl": false,
    "keyFile": "/certs/alexa-fhem.key",
    "certFile": "/certs/alexa-fhem.crt",
    "nat-pmp": "",
    "nat-upnp": false,
    "applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXX>
  },
  "sshproxy" : {
    "description" : "FHEM Connector",
    "ssh" : "/usr/bin/ssh"
  },
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "999",
      "port": "8083",
      "server": "127.0.0.1"
    }
  ]
}

wobei ein chmod -r 755 /opt/alexa-fhem unbedingt zu machen ist. Und ein chown 6062:6062 -R /opt/alexa-fhem auch zwingend erforderlich ist. Anmerkung: das 6062 ist jene UID & GID die für alexa-fhem in der compose.yaml angegeben sind.
Änderungen in der /opt/alexa-fhem/config.json waren folgende:

Analyse & Lösungsschritte zu meinem Problem
Das Problem dem ich in meiner (noch) Unkenntnis/Unverständnich von Docker aufgelaufen bin war, dass ich sowohl FHEM als auch alexa-fhem nicht im
    network_mode: host
gefahren bin. Nach ungezählten Fehlversuchen eine Verbindung zwischen den Beiden zu bekommenhabe ich dann einfach mal die IP, welche vom Docker-internen Netzwerk an FHEM vergeben ist in "server" der /opt/alexa-fhem/config.json einzutragen - und kaum macht man's richtig, funktioniert's auch schon! Da bei jedem Neustart des Dockers die IPs neu vergeben werden konnte ich das so hardcoded nicht stehen lassen und habe mich eben für
    network_mode: host
entschieden und die Configs wie sie eben oben sind. Der Rest ist ein Klacks und hier => https://wiki.fhem.de/wiki/FHEM_Connector_für_Amazon_Alexa (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa) bestens beschrieben.

Ich werde in den nächsten Tagen versuchen den     network_mode: host wieder weg zu bekommen um den Traffic innerhalb des Portainers (ich hab auch noch Homeassistan, mosquitto, sonos2mqtt und weiss ich was da drinnen laufen) soweit als möglich abzuhandeln.

Allerbesten Dank an @Otto, @Joachim und @Sidey (insbesonders, dass ihr die Nerven nicht verloren habt  ;D )

Noch eine Anmerkung: ob "bare-metal" oder ""Container" ist eine Geschmacksache. MIR ist das schnelle Wiederherstellen der Umgebung im Falle eines Crashes (von welchem Stück HW auch immer) wichtig. Und da hab ich mich für den Docker entschieden  ;)
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 09 März 2023, 19:24:59
Wiederherstellen ok aber egal ob Docker oder "bare metal" : Backup!
Weil irgendwas musst du ja trotz Docker "einstellen"...
...und auch fhem hat ja Daten...
(und nur alexa-fhem ist nach einem Crash egal welcher mit passendem Backup bestimmt ebenso schnell wieder da, auch bei "bare metal" ;) )

Und die Einträge bzgl. externer Verbindung, "Stichwort": Port 3000 usw. kannst du ja auch noch mal "wegoperieren"...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 09 März 2023, 22:04:21
Hallo,

ich habe fhem in einem Docker Container am laufen und bräuchte innerhalb des fhem Containers die shell commands ip xxx.
Definiert ist der Container via docker-compose.yml
Also sowas wie

command: apt-get update && apt-get install -y iproute2

innerhalb des .yml files.
Das funktioniert aber nicht. Wie gelingt das "Nach-Installieren" von zusätzlichen shell-Kommandos denn?

VG

Alex
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 09 März 2023, 22:14:57
Zitat von: Homalix99 am 09 März 2023, 22:04:21
Wie gelingt das "Nach-Installieren" von zusätzlichen shell-Kommandos denn?

Über die Environmentvariable APT_PKGS, siehe https://github.com/fhem/fhem-docker#add-custom-packages (https://github.com/fhem/fhem-docker#add-custom-packages).

Entweder im compose-file

services:
  fhem:
    environment:
      APT_PKGS: "<Paketname>"


oder mit
docker run -e APT_PKGS='<Paketname>' ... ...
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 09 März 2023, 22:23:11
Zitat von: Homalix99 am 09 März 2023, 22:04:21
Hallo,

ich habe fhem in einem Docker Container am laufen und bräuchte innerhalb des fhem Containers die shell commands ip xxx.

Nachinstallieren von Paketen ist keine wirklich gute Lösung.
Wofür brauchst Du denn dieses Kommando?

Grüße Sidey
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 09 März 2023, 22:28:34
Perfekt, danke!!!
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 09 März 2023, 22:28:50
Zitat von: Sidey am 09 März 2023, 22:23:11
Nachinstallieren von Paketen ist keine wirklich gute Lösung.

Wieso denn nicht? Wenn es einen validen use-case gibt und man das im Kopf behält, falls später mal Probleme auftreten ...
Ist ja auch nicht so, als würde iproute2 irgendwas kaputtmachen.
Titel: Antw:Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 09 März 2023, 22:53:02
Zitat von: passibe am 09 März 2023, 22:28:50
Wieso denn nicht? Wenn es einen validen use-case gibt und man das im Kopf behält, falls später mal Probleme auftreten ...
Ist ja auch nicht so, als würde iproute2 irgendwas kaputtmachen.
Sehe ich auch so.
Ich brauche das, weil fhem im Container aus Netzwerksicht gebridged ist, aber bei mir die RTP-Pakete des SIP-client mit der Docker-Host Adresse versehen werden und Audio deswegen wahrscheinlich nicht funktioniert.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: toensi am 11 Mai 2023, 07:19:15
Hallo zusammen!
Vorab Besten Dank für´s Image FHEM. :=)
Meine Fhem Installation zieht grade zu Docker um, das meiste funktioniert, wie Alexa, Mqtt etc.
Nun zu meine eigentlichen PROBLEM :
Nach dem Start von FHEM bekomme ich folgende Fehlermeldung.

Messages collected while initializing FHEM:configfile: Cannot load module RESIDENTS
setuuid: Please define residents first
Cannot load module ROOMMATE
setuuid: Please define rr_XXX first
Cannot load module ROOMMATE
setuuid: Please define rr_Sarah first

Ich denke es liegt an der Rechte vergabe, diese wird jedoch nach Neustart vom Docker Container immer auf 0750 gesetzt, auch wenn ich eine Änderung auf 777 vornehmen geht es nicht.
Gruppe und Eigentümer sind denke ich gesetzt auf 1000

PLEASE Help !! Danke vorab .. :=)
Was kann ich tun, um das Problem zu lösen??
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 11 Mai 2023, 07:30:34
Wie hast Du denn rr_XXX und rr_Sarah in der Config definiert?

Stehen die auch in der fhem.cfg oder hast Du weitere Konfigdateien?

Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: toensi am 11 Mai 2023, 07:46:43
Danke für die schnelle Reaktion !:==) nice..

ich habe meine fhem config wie folgt.
include /opt/fhem/mycfg/00_mycfg.cfg

Im Ordner liegen die mehrere Dateien wie z.b.  : 00_Residents.cfg , 00_mycfg.cfg, 02_Cul.cfg, 03_alexa.cfg etc, --> diese werden auch geladen, das klappt.

Update :
define unter fhem.cfg ohne laden der Datei funtz. geht erstmal , suche weiter nach dem Problem. Besten und sooo.....

Gruß
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 11 Mai 2023, 11:29:32
Es liegt ganz sicher an der Reihenfolge der Includes.

Wenn Du alles in die FHEM.cfg überführst hast Du das Problem nicht.

Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 18 Mai 2023, 16:59:28
@Sidey

ich habe das Problem, meine Readings werden nicht gespeichert, wenn der Container neu gestartet wird.
> Hatte ein Thema gemacht: https://forum.fhem.de/index.php?topic=133468

Kannst du da weiterhelfen?

Nutze das aktuellste IMG von DockerHub.
Wenn FHEM über die Weboberfläche neu gestartet wird, dann werden die Readings geschrieben und ausgelesen.
Beim Neustart des Containers werden die Readings nicht gespeichert, somit werden die alten Readings geladen.

Meine Docker Compose / Stack (Portainer) für FHEM:
version: '3'
services:

  fhem:
    container_name: FHEM
    image: fhem/fhem:latest
    hostname: fhem
    restart: always
    deploy:
      resources:
        limits:
          memory: 1536m
    networks:
      internal:
        ipv4_address: 172.88.0.7
      external:
        ipv4_address: 192.168.200.119
    ports:
      - "8083:8083"
      - "7072:7072"
      - "6767:6767/udp"
    environment:
      PIP_PKGS: "fhem beautifulsoup4"
      PAN_PKGS: "Crypt::Cipher::AES or Crypt::Rijndael_PP"
    volumes:
      - /UserPath/FHEM:/opt/fhem

Vielen Dank und Grüße
Gear
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 27 Mai 2023, 15:20:03
Zitat von: Gear am 18 Mai 2023, 16:59:28@Sidey

ich habe das Problem, meine Readings werden nicht gespeichert, wenn der Container neu gestartet wird.
> Hatte ein Thema gemacht: https://forum.fhem.de/index.php?topic=133468

Kannst du da weiterhelfen?

Hallo Gear,

Ich habe ein neues Docker Image (Version 3.2.0-beta) bereitgestellt.
Diese beinhaltet eine Fehlerbehebung, dass der Container nicht gestoppt wird, sobald ein delayed shutdown gemeldet wird:

https://github.com/fhem/fhem-docker/pkgs/container/fhem%2Ffhem-minimal-docker/96002710?tag=3.2.0-beta-bullseye

Würde mich über einen Test und Rückmeldung freuen.

Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 29 Mai 2023, 18:46:30
Hallo Sidey,
habe das erst jetzt gesehen.
Würde das am kommenden WE testen und dir dann eine Rückmeldung geben!
> Hoffe das ist ok.

Vielen Dank und eine schöne Woche!
Grüße
Gear
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: globus243 am 31 Mai 2023, 14:12:26
Hallo Fhem-Gemeinde,

ich mag Docker sehr und versuche aktuell einen zustandslosen Fhem-Container zu bauen. Die Idee ist, das Konfiguration und alles was man ändern können muss, in einem Git-Repo liegt, und die Dateien dann beim Build statisch in das Container-Image kopiert werden. Das hat den Vorteil das der Host, auf dem Fhem läuft, komplett egal ist, Backup ist auch irrelevant, Experimente lassen sich so auch leichter durchführen, weil man einfach nur einen neuen Branch im Git aufmachen müsste und sollte man sich einmal sein Fhem zerschießen: redeploy, problem gelöst.

Bezüglich Datenspeicherung speichere ich alles was von interesse ist in einer zentralen MySQL-DB. Der Rest (hauptsächlich log-files) sind für meine Zwecke unwichtig. Ich benötige als für mein Fhem keinerlei Persistenz oder volumes.

Soweit klappt das super, ich habe allerdings probleme mit alexa-fhem. Aktuell verliert das alexa-device nach jedem Neustart (also löschen und neu deployen des Containers) seinen ProxyKey und erzeugt einen Neuen. Damit müsste man nach jedem Update/Neustart/Konfigchange den Skill neu anlernen, was ein dealbreaker für diese Lösung wäre.

Hier mein Dockerfile, wie ihr seht passiert hier nicht wirklich viel. Ein paar Pakete werden installiert, Environment wird gesetzt und der Inhalt vom src/ ordner wird an entsprechende Stelle im Image kopiert. Der Rest wird von der "entry.sh" beim Deployment erledigt die bereits bei fhem/fhem:latest dabei ist.
FROM fhem/fhem:latest

RUN apt-get update && apt-get upgrade -y \
    && apt-get install -y --no-install-recommends cpanminus \
    && cpanm --notest Amazon::SNS \
    && npm update -g \
    && npm install -g alexa-fhem alexa-cookie gassistant-fhem homebridge homebridge-fhem

COPY src/ /fhem/

ENV TZ="Europe/Berlin" \
    LOGFILE="./log/fhem-%Y-%m-%d.log" \
    FHEM_UID=6061 \
    FHEM_GID=6061

Datein die ich neben der reinen Fhem-Konfig noch im Repo habe und die ins Container-Image kopiert werden:
alexa-fhem.cfg
db.conf
.ssh/id_ras, id_ras.pub, id_ed25519, id_ed25519.pub, known_hosts, config
FHEM/www/codemirror/ # der codemirror editor
FHEM/www/gplot/ # meine graphs die in einer anderen Installation erstellt wurden
FHEM/83_KFL200.pm
FHEM/83_KFL200Node.pm
FHEM/controls_KFL200.txt

Die Datein kommen von einer klassischen Fhem Installation auf einer VM, die bis jetzt alles bei mir gesteuert hatte.

Permissions sollten ebenso passen:
root@263182cccaa3:/opt/fhem# ll .ssh/
total 32K
drwx------  2 fhem fhem 4,0K Mai 31 12:33 .
drwxr-x--- 16 fhem fhem 4,0K Mai 31 12:33 ..
-rw-r-----  1 fhem fhem  509 Mai 30 20:48 config
-rw-------  1 fhem fhem  411 Mai 30 20:48 id_ed25519
-rw-r-----  1 fhem fhem   98 Mai 30 20:48 id_ed25519.pub
-rw-------  1 fhem fhem 3,4K Mai 30 20:48 id_rsa
-rw-r-----  1 fhem fhem  742 Mai 30 20:48 id_rsa.pub
-rw-r-----  1 fhem fhem 1,4K Mai 31 12:33 known_hosts
root@263182cccaa3:/opt/fhem#

Das der ProxyKey sich bei jedem redeploy ändert war Anfangs logisch, basiert das ganze doch auf SSH-keys die, sollten sie nicht vorhanden sein, bei jedem deploy neu generiert werden. Ich habe also die SSH-Keys ebenfalls in meinem Repo abgelegt, sie werden beim Build auch ins Image kopiert und in der Laufzeiz benutzt. Den Skill habe ich dann mit dem neuen ProxyKey angelernt und es funktionierte erstmal. Dann der testweise redeploy und nun die Enttäuschung, ProxyKey ist wieder anders, Alexa-Skill müsste neu angelernt werden um wieder zu funktionieren.

Meine Vermutung ist, das die SSH-Keys noch nicht alles sind, dass irgendwo im Filesystem eine config, oder Ähnliches, liegt die beim re-deploy verloren geht. Ich habe schon stundenlang mit find die Dateien im Container nach dem Key durchwühlt aber nichts finden können.

Schätze, ich habe hier einfach nur eine Wissenslücke wie alexa-fhem genau arbeitet.
Jede Idee und Input ist herzlich willkommen.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 31 Mai 2023, 14:27:16
@globus243

Hast Du das Problem auch, wenn Du alexa-fhem im eigenen Docker Container verwendest?

PS: Ich möchte NodeJS (da veraltet) demnächst aus dem FHEM Image ausbauen.

Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: globus243 am 31 Mai 2023, 15:05:14
@Sidey, noch nicht ausprobiert. gucke ich mir als nächstes an. du meinst dieses hier, richtig: fhem/alexa-fhem?

Edit: sehe gerade das dieses Image ja die "alte" variante ist, fhem mit alexa zu verbinden (Mit offenem port, eigenem Skill, explizieter skill invocation, usw). Gibts das auch mit dem FHEM-connector wie hier  (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa)beschrieben?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 31 Mai 2023, 18:32:23
Zitat von: globus243 am 31 Mai 2023, 15:05:14Edit: sehe gerade das dieses Image ja die "alte" variante ist, fhem mit alexa zu verbinden (Mit offenem port, eigenem Skill, explizieter skill invocation, usw). Gibts das auch mit dem FHEM-connector wie hier  (https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa)beschrieben?

Was hat dich dazu gebracht anzunehmen, dass es nur mit der alten Variante geht?

Es funktioniert tadellos über den Vereins Connector. Wenn ich an der Beschreibung etwas verbessern kann, lass es mich wissen.

Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: globus243 am 31 Mai 2023, 19:12:54
ZitatEs funktioniert tadellos über den Vereins Connector. Wenn ich an der Beschreibung etwas verbessern kann, lass es mich wissen.

habe nicht gewusst das über die alexa-config.json die fhem-auth mitgegeben werden kann. habe das sonst über das alexa device innerhalb von fhem gemacht. beim durchscrollen hier (https://wiki.fhem.de/wiki/Alexa-Fhem#:~:text=%22auth%22%3A%20%7B%22user%22%3A%20%22fhemuser%22%2C%20%22pass%22%3A%20%22fhempassword%22%7D%2C) hats dann klick gemacht das ich den oberen teil im bsp gar nicht zwingend brauche usw. eventuell könnte man hier (https://github.com/fhem/alexa-fhem-docker/blob/dev/src/config.json) eine zweite bsp config ablegen, die den connector nutzt, um es zu verdeutlichen.

anyway... gleiche Problem, auch der fhem/alexa-fhem:latest erzeugt trotz selber ssh-keys jedesmal einen anderen proxykey, nach dem einreißen und neudeployen. Ich kann nur noch vermuten das irgendeine systeminterna zur erzeugung des ProxyKeys genuzt wird, die sich eben beim re-deploy ändert (der hostname ist es in diesem fall aber nicht).

als sanity test gerade nochmal probiert: wenn ich beiden containern ein verzeichnis im Dateisystem gebe in das sie schreiben können, via --volume. bekomme ich reproduzierbar, auch nach dem löschen das containers (daten bleiben natürlich im filesystem) und neudeployen, den selben proxyKey. warum geht das nicht, wenn ich die .ssh ordner für beide einfach beim build mit reinkopiere und kein volume definiere?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 Juni 2023, 08:27:01
Zitat von: globus243 am 31 Mai 2023, 19:12:54als sanity test gerade nochmal probiert: wenn ich beiden containern ein verzeichnis im Dateisystem gebe in das sie schreiben können, via --volume. bekomme ich reproduzierbar, auch nach dem löschen das containers (daten bleiben natürlich im filesystem) und neudeployen, den selben proxyKey. warum geht das nicht, wenn ich die .ssh ordner für beide einfach beim build mit reinkopiere und kein volume definiere?

Ich weiss es jetzt nicht genau, aber möglicherweise stehen die Daten in der "state-file" (https://wiki.fhem.de/wiki/Save)
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 01 Juni 2023, 08:46:41
Was ich mich gerade frage:
- Wenn Deine Daten im GIT liegen, wie bearbeitest Du die Config? Direktbearbeitung und nicht per FHEM?
- Liegen mit ssh-key auch alle Passwörter im GIT?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: globus243 am 01 Juni 2023, 10:03:52
Zitat von: Wernieman am 01 Juni 2023, 08:46:41Was ich mich gerade frage:
- Wenn Deine Daten im GIT liegen, wie bearbeitest Du die Config? Direktbearbeitung und nicht per FHEM?

Genau, einmal eingerichtet ändere ich meine Config so gut wie nie. Sollte es dochmal notwendig sein, kann man es in der Laufzeit testen und die Änderung dann im Git übernehmen, pushen, baut, deployed, fertig.

Zitat von: Wernieman am 01 Juni 2023, 08:46:41- Liegen mit ssh-key auch alle Passwörter im GIT

Ja, erzwungenerweise. Sollte die Grundidee laufen, überlege ich mir vlt wie man das mit Env-vars lösen könnte.

Zitat von: Sidey am 01 Juni 2023, 08:27:01Ich weiss es jetzt nicht genau, aber möglicherweise stehen die Daten in der "state-file" (https://wiki.fhem.de/wiki/Save)
leider nicht der ProxyKey, die skillRegKey und der BearerToken schon. Ich teste im laufe des Tages einmal was passiert, wenn ich diese Werte in meine config mit überneheme
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 01 Juni 2023, 11:38:58
Eventuell in der UniqueID Datei?

Gruß, Joachim
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: globus243 am 01 Juni 2023, 12:32:11
Zitat von: MadMax-FHEM am 01 Juni 2023, 11:38:58Eventuell in der UniqueID Datei?

Gruß, Joachim

Hey, UniqueID hatte ich bisher gar nicht in meiner config. probiere ich auch mit aus

Edit: Ich küsse deine Augen, das wars. UniqueId datei mit im repo, und ProxyKey ist jetzt immer der selbe. Vielen Dank!
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: MadMax-FHEM am 01 Juni 2023, 12:59:26
Oh, aha.
Dort speichern (manche) Module Credentials usw.

Wenn du keine Module mit "sowas" hast, dann fällt das auch nicht auf.

Gruß, Joachim
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 03 Juni 2023, 06:49:34
Zitat von: Sidey am 27 Mai 2023, 15:20:03Würde mich über einen Test und Rückmeldung freuen.

Hey Sidey,
hab eben mal das von dir genannte img genommen.

Fheler mit MQTT:
Messages collected while initializing FHEM:configfile: Cannot load module MQTT
setuuid: Please define Mosquitto first
Cannot load module MQTT_DEVICE
setuuid: Please define WEBZ.Licht.Decke first
...
...

Wegen des eigentlichen Problems schaue ich mal, Danke.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 03 Juni 2023, 09:36:20
Zitat von: Gear am 03 Juni 2023, 06:49:34
Zitat von: Sidey am 27 Mai 2023, 15:20:03Würde mich über einen Test und Rückmeldung freuen.

Hey Sidey,
hab eben mal das von dir genannte img genommen.

Ich habe heute Nacht ein neues bauen lassen, darin ist ein Fehler mit der Logauagabe behoben. Das Docker Logfile steigt sonst rapide an:

ghcr.io/fhem/fhem/fhem-docker:3.2.0-beta2-bullseye
Bezüglich deiner Fehler kann ich aber keinen Zusammenhang feststellen.
Das sieht eher so aus, als ob Konfigurationen fehlen.

Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 Juli 2023, 19:14:09
Zitat von: Gear am 03 Juni 2023, 06:49:34Hey Sidey,
hab eben mal das von dir genannte img genommen.

Hast Du denn hierzu neue Erkentnisse?


Viele Grüße
Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Gear am 11 Juli 2023, 14:39:43
Zitat von: Sidey am 01 Juli 2023, 19:14:09Hast Du denn hierzu neue Erkentnisse?

Ähm, sry total verpeilt zu antworten. (Viel um die Ohren + Gesundheit)
Habe das eben nochmal getestet, scheint immer noch zu bestehen.
Anbei ein Screen aus Grafana.

Blau markiert ist ein Neustart des Containers und Grün habe ich den Befehl ausgeführt: WriteStatefile

Grüße und Danke
Gear
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 03 August 2023, 17:10:15
Schönen Nachmittag zusammen! Ich lese und teste nun seit 2 Tagen und komme auf keinen grünen Zweig. Ich hatte eine funktionierende FHEM-Installation inclusive alexa-fhem (siehe meine Einträge aus letztem März). Nun habe ich eine PV-Anlage bekommen und musste, um fhempy ins selbe Netzwerk zu integrieren vom
network_mode: hostzu einem Docker-internen Netzwerk wechseln. Die Daten aus meiner Solaranlage kann ich nun auslesen, doch Alexa bekomme ich einfach nicht mehr hin. Zuerst antwortete sie immer, dass das angesprochene Gerät nicht reagiert dann habe ich mich in den Sogs u.s.w. "schlau" gemacht.
Mein /opt/compose.yaml sieht so aus (ich weiss, zu viele Informationen, doch ich möchte das big-picture herzeigen):
version: '3'
services:
#
#
##### ----- portainer ----- #################################################
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    ports:
      - "8000:8000"
      - "9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data
    restart: unless-stopped
#
#
##### ----- deconz ----- ######################################################
  deconz:
    image: ghcr.io/deconz-community/deconz-docker:latest
    container_name: deconz
    restart: always
    privileged: true                # This is important! Without it, the deCONZ>
    network_mode: host
    volumes:
      - /opt/deCONZ:/opt/deCONZ
    devices:
      - /dev/ttyACM0                # This is the USB device that Conbee II is >
    environment:
      - TZ=Europe/Vienna
      - DECONZ_DEVICE=/dev/ttyACM0   # This is the USB device that Conbee II is>
      - DECONZ_UID=1111
      - DECONZ_GID=1111
      - DECONZ_WEB_PORT=8080
#
#
##### ----- fhem ----- ########################################################
  fhem:
    image:  ghcr.io/fhem/fhem-docker:3-bullseye
    container_name: fhem
    restart: always
    volumes:
      - /opt/fhem/:/opt/fhem/
    environment:
      FHEM_UID: 999
      FHEM_GID: 20
      TZ: Europe/Vienna
    networks:
      internal:
    ports:
      - "8083:8083"
      - "8084:8084"
      - "1883:1883"
      - "8883:8883"
#
#
##### ----- homeassistant ----- ################################################
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /opt/homeassistant:/config
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped
    privileged: true
    network_mode: host
#
#
##### ----- mosquitto ----- ###################################################
  mosquitto:
    image: eclipse-mosquitto
    container_name: mosquitto
    restart: unless-stopped
    volumes:
      - /opt/mosquitto:/mosquitto
      - /opt/mosquitto/data:/mosquitto/data
      - /opt/mosquitto/log:/mosquitto/log
    ports:
      - 1885:1885
      - 9001:9001
#
#
#
#
##### ----- alexa-fhem -----## #################################################
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    container_name: alexa-fhem
    restart: always
    volumes:
      - /opt/alexa-fhem/:/alexa-fhem/
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Vienna
    networks:
      internal:
    ports:
      - 3000:3000
#
#
##### ----- FHEMpy FusionSolar ----- ###########################################
  fhempy-fusionsolar:
    image: ghcr.io/fhem/fhempy-docker_fusionsolar:releases-1.4-beta
    container_name: FHEMpy-fusionsolar
    hostname: fhempy-fusionsolar
    restart: always
    networks:
      internal:

##### ----- sonos ----- ########################################################
  sonos:
    image: ghcr.io/svrooij/sonos2mqtt
    container_name: sonos
    restart: unless-stopped
    network_mode: host
    environment:
      - SONOS2MQTT_DEVICE=192.168.57.77 # IP of my SONOS One - Service discover>
      - SONOS2MQTT_MQTT=mqtt://192.168.57.30:1883 #
#      # - SONOS2MQTT_DISTINCT=true # if your want distinct topics
      - SONOS_LISTENER_HOST=192.168.57.30 # Docker host IP
#      # - SONOS_TTS_ENDPOINT=http://sonos-tts:5601/api/generate # If you deplo>
#
#
##### ----- minidlna ----- #####################################################
  minidlna:
    container_name: miniDLNA
    restart: unless-stopped
    network_mode: host
    image: vladgh/minidlna
    volumes:
      - /mnt/share/dlnaAudio:/media/Audio
      - /mnt/share/dlnaPictures:/media/Pictures
      - /mnt/share/dlnaVideo:/media/Video
    environment:
      - MINIDLNA_MEDIA_DIR_1=A,/media/Audio
      - MINIDLNA_MEDIA_DIR_2=P,/media/Pictures
      - MINIDLNA_MEDIA_DIR_3=V,/media/Video
      - MINIDLNA_FRIENDLY_NAME=MiniDLNA-Docker
      - MINIDLNA_MAX_CONNECTIONS=8
      - MINIDLNA_SERIAL=08154711
#
#
##### ----- network definitions ----- ##########################################
networks:
  internal:
    driver: bridge
    ipam:
      config:
        - subnet: 172.99.0.0/16
          gateway: 172.99.0.1
          ip_range: 172.99.0.1/16
#
#
##### ----- volume definitions ----- ###########################################
volumes:
  portainer_data:
    name: portainer_data
    external: true
Meine FHEM-Daten liegen auf /opt/fhem
josef@RasPi-Server:/opt/fhem $ ls
CHANGED          alexa-fhem.cfg  demolog        fhem.cfg.prev    restoreDir
FHEM             backup          docs           fhem.pl          unused
GPL_V2.txt       cache           fhem.cfg       infrastruct.ics  wget-log
MAINTAINER.txt   configDB.pm     fhem.cfg.bak   lib              www
README_DEMO.txt  contrib         fhem.cfg.demo  log
und alexa-fhem hat ein Verzeichnis /opt/alexa-fhem
josef@RasPi-Server:/opt/alexa-fhem $ ls -al
total 24
drwxr-xr-x 4 6062 6062 4096 Aug  3 16:59 .
drwxr-xr-x 9 root root 4096 Aug  3 16:56 ..
drwxr-xr-x 2 6062 6062 4096 Aug  3 16:07 .alexa
drwxr-xr-x 2 6062 6062 4096 Aug  3 16:07 .ssh
lrwxrwxrwx 1 root root   11 Aug  3 16:07 alexa-fhem.json -> config.json
-rw-r--r-- 1 6062 6062  631 Aug  3 12:34 config.json
-rw-r--r-- 1 6062 6062  635 Aug  3 08:44 config.json.ok
config.json enthält:
  "alexa": {
    "port": 3000,
    "name": "Alexa",
    "ssl": false,
    "keyFile": "/certs/alexa-fhem.key",
    "certFile": "/certs/alexa-fhem.crt",
    "nat-pmp": "",
    "nat-upnp": false,
    "applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
    "oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  },
  "sshproxy" : {
    "description" : "FHEM Connector",
    "ssh" : "/usr/bin/ssh"
  },
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "fhem"
    }
  ]
}

und alexa-fhem.cfg in /opt/fhem
{
   "connections" : [
      {
         "server" : "fhem",
         "webname" : "fhem",
         "port" : 8083,
         "filter" : "alexaName=..*",
         "name" : "FHEM",
         "uid" : 6062
      }
   ],
   "sshproxy" : {
      "ssh" : "/usr/bin/ssh",
      "description" : "FHEM Connector"
   }
}
Nun starte ich den ganzen Zinober und bekomme keine Verbindung mehr zwischen fhem und alexa-fhem. im Alexa-log steht fortlaufend:
[8/3/2023, 5:00:04 PM] [FHEM] trying longpoll to listen for fhem events
[8/3/2023, 5:00:04 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1691074804722
[8/3/2023, 5:00:04 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[8/3/2023, 5:00:34 PM] [FHEM] trying longpoll to listen for fhem events
[8/3/2023, 5:00:34 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1691074834735
[8/3/2023, 5:00:34 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[8/3/2023, 5:01:04 PM] [FHEM] trying longpoll to listen for fhem events
[8/3/2023, 5:01:04 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1691074864743
[8/3/2023, 5:01:04 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[8/3/2023, 5:01:34 PM] [FHEM] trying longpoll to listen for fhem events
[8/3/2023, 5:01:34 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1691074894759
[8/3/2023, 5:01:34 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
Im FHEM-log steht fortlaufend:
2023.08.03 17:00:04 1: Connection refused from the non-local address 172.99.0.4:51726, as there is no working allowed instance defined for it
2023.08.03 17:00:34 1: Connection refused from the non-local address 172.99.0.4:45514, as there is no working allowed instance defined for it
2023.08.03 17:01:04 1: Connection refused from the non-local address 172.99.0.4:60548, as there is no working allowed instance defined for it
2023.08.03 17:01:34 1: Connection refused from the non-local address 172.99.0.4:36582, as there is no working allowed instance defined for it

Auch die Diskussionen auf Seite 105 dieses Threads haben mir nicht weiter geholfen. Ich habe auch den (nicht-?)Zusammenhang von /opt/fhem/alexa-fhem.cfg und /opt/alexa-fhem/config.json verstanden.

Danke für eure Unterstützung
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 03 August 2023, 17:28:54
So auf die Schnelle würde ich tippen, dass die Container nicht im Netzwerk internal angebunden sind.

Schau mal hier, da wird das Netzwerk als Liste referenziert:

https://github.com/fhem/fhem-docker/blob/250259436195b396af641e201f0cf0a098105f45/docker-compose.yml#L29

PS: Dein Subnetz ist ja ganze schön groß dimensioniert :)
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 03 August 2023, 18:00:08
Danke. Jetzt hab ich es deinem Vorschlag gemäß geändert (und das Subnetz gleich verkleinert):
  fhem:
    image:  ghcr.io/fhem/fhem-docker:3-bullseye
    container_name: fhem
    restart: always
    volumes:
      - /opt/fhem/:/opt/fhem/
    environment:
      FHEM_UID: 999
      FHEM_GID: 20
      TZ: Europe/Vienna
    networks:
      - fhem_net
    ports:
      - "8083:8083"
      - "8084:8084"
      - "1883:1883"
      - "8883:8883"

##### ----- alexa-fhem -----## #################################################
  alexa-fhem:
    image: ghcr.io/fhem/fhem/alexa-fhem:latest
    container_name: alexa-fhem
    restart: always
    volumes:
      - /opt/alexa-fhem/:/alexa-fhem/
    environment:
      ALEXAFHEM_UID: 6062
      ALEXAFHEM_GID: 6062
      TZ: Europe/Vienna
    networks:
      - fhem_net
    ports:
      - 3000:3000
##### ----- network definitions ----- ##########################################
networks:
  fhem_net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.99.0.0/24
          gateway: 172.99.0.1
          ip_range: 172.99.0.1/24

Das Ergebnis ist leider das Selbe.
2023.08.03 17:52:34 1: Connection refused from the non-local address 172.99.0.4:54006, as there is no working allowed instance defined for it
2023.08.03 17:53:04 1: Connection refused from the non-local address 172.99.0.4:51554, as there is no working allowed instance defined for it
2023.08.03 17:53:34 1: Connection refused from the non-local address 172.99.0.4:40708, as there is no working allowed instance defined for it
2023.08.03 17:54:04 1: Connection refused from the non-local address 172.99.0.4:59544, as there is no working allowed instance defined for it

bzw.
[8/3/2023, 5:53:04 PM] [FHEM] trying longpoll to listen for fhem events
[8/3/2023, 5:53:04 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1691077984083
[8/3/2023, 5:53:04 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[8/3/2023, 5:53:34 PM] [FHEM] trying longpoll to listen for fhem events
[8/3/2023, 5:53:34 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1691078014098
[8/3/2023, 5:53:34 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET
[8/3/2023, 5:54:04 PM] [FHEM] trying longpoll to listen for fhem events
[8/3/2023, 5:54:04 PM] [FHEM] starting longpoll: http://fhem:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1691078044109
[8/3/2023, 5:54:04 PM] [FHEM] longpoll error: Error: read ECONNRESET, retry in: 30000msec
*** FHEM: connection failed: Error: read ECONNRESET

Als Nachtrag noch meine Alexa-Definition in FHEM:
defmod alexa alexa
attr alexa alexaFHEM-config ./alexa-fhem.cfg
attr alexa alexaFHEM-log ./log/alexa-%Y-%m-%d.log
attr alexa alexaMapping #Characteristic=<name>=<value>,...\
On=verb=schalte,valueOn=an;;ein,valueOff=aus,valueToggle=um\
\
Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
Hue=verb=stelle,valuePrefix=auf,values=rot:0;;grün:128;;blau:200\
Hue=verb=färbe,values=rot:0;;grün:120;;blau:220\
\
Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER\
Saturation=verb=sättige,values=AMAZON.NUMBER\
\
TargetPosition=verb=mach,articles=den;;die,values=auf:100;;zu:0\
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad\
\
Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent\
\
#Weckzeit=verb=stelle,valuePrefix=auf;;für,values=AMAZON.TIME,valueSuffix=uhr
attr alexa alexaTypes #Type=<alias>[,<alias2>[,...]]\
light=licht,lampen\
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
attr alexa devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
attr alexa echoRooms #<deviceId>=<room>\

attr alexa fhemIntents #IntentName=<sample utterance>\
gutenMorgen=guten morgen\
guteNacht=gute nacht
attr alexa persons #<personId>=<name>\

attr alexa room Server
attr alexa stateFormat alexaFHEM

setstate alexa stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
setstate alexa 2023-08-03 17:50:46 alexaFHEM stopped;; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
setstate alexa 2023-08-03 16:32:49 alexaFHEM.bearerToken crypt:73240c057d5d52540901020350710b0a
setstate alexa 2023-08-03 16:32:49 alexaFHEM.skillRegKey crypt:042205707d5c27571c01050557020d0200710f0279747855591821760e097d0c06510d060e505426030a

Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 03 August 2023, 19:29:12
Zitat von: rallye am 03 August 2023, 18:00:08Das Ergebnis ist leider das Selbe.
2023.08.03 17:52:34 1: Connection refused from the non-local address 172.99.0.4:54006, as there is no working allowed instance defined for it
2023.08.03 17:53:04 1: Connection refused from the non-local address 172.99.0.4:51554, as there is no working allowed instance defined for it
2023.08.03 17:53:34 1: Connection refused from the non-local address 172.99.0.4:40708, as there is no working allowed instance defined for it
2023.08.03 17:54:04 1: Connection refused from the non-local address 172.99.0.4:59544, as there is no working allowed instance defined for it


Hier steht ja ziemlich genau, dass dein allowed Definition in FHEM den Zugriff verbietet. Hier solltest Du das Netzwerk hinterlegen über das  FHEM und alexa-FHEM kommunizieren.

Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 03 August 2023, 22:05:24
Noch etwas anderes:
Dein 172.99-Subnet ist kein Subnet innerhalb der RFC1918-Spezifikation. Das geht nur von 172.16.0.0 bis 172.31.255.255 (also 172.16.0.0/12).
Deshalb sagt die Fehlermeldung auch "non-local address".

Es bietet sich also an – neben der korrekten Konfiguration des allowed-Devices – auch darauf zu achten, dass bei Docker-Netzwerken alle Adressen tatsächlich privat (also RFC1918) sind. Das 172 am Anfang lädt nämlich dazu ein, dass man dahinter egal was veranstalten kann (so wie bei 10.0.0.0/8), aber das ist leider nicht der Fall (mir auch schon passiert).
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 04 August 2023, 07:15:18
Zitat von: Sidey am 03 August 2023, 19:29:12Hier steht ja ziemlich genau, dass dein allowed Definition in FHEM den Zugriff verbietet. Hier solltest Du das Netzwerk hinterlegen über das  FHEM und alexa-FHEM kommunizieren.

Grüße Sidey
Danke, das habe ich mir auch gedacht und gestern versucht ein allowed-device entsprechend zu definieren, wollte aber auf die Schnelle keine UIDs und PWs definieren bzw war mir nicht ganz klar welche ich für alexa-fhem nehmen soll. Hab's daher auf heute verschoben. Gut war's. Ich hab dann den Beitrag von @passible gesehen:

Zitat von: passibe am 03 August 2023, 22:05:24Noch etwas anderes:
Dein 172.99-Subnet ist kein Subnet innerhalb der RFC1918-Spezifikation. Das geht nur von 172.16.0.0 bis 172.31.255.255 (also 172.16.0.0/12).
Deshalb sagt die Fehlermeldung auch "non-local address".

Es bietet sich also an – neben der korrekten Konfiguration des allowed-Devices – auch darauf zu achten, dass bei Docker-Netzwerken alle Adressen tatsächlich privat (also RFC1918) sind. Das 172 am Anfang lädt nämlich dazu ein, dass man dahinter egal was veranstalten kann (so wie bei 10.0.0.0/8), aber das ist leider nicht der Fall (mir auch schon passiert).
und mich daran gehalten (172.16.57.0/24). Und kaum macht man's richtig, funktioniniert's auch schon  :) !!

Danke für Eure Unterstützung - fhempy & alexa-fhem laufen wie von mir gewünscht!

LG Rallye
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 09 September 2023, 18:40:57
Update zu den Docker Images.


Die Docker Images, welche in der Github container registry liegen, hatten lange Zeit ein "fhem" mehr in der Pfadangabe als eigentich gewollt:

Vor einigen Wochen habe ich das bereits angepasst.

Das FHEM Image wird auch nur noch unter dem gekürzten Namen aktualisiert, aktualisiert also bitte eure Image Quellen, die alten werden nicht mehr aktualisiert.

ghcr.io/fhem/fhem-docker:3-bullseye
ghcr.io/fhem/alexa-fhem:5

Kleiner Spoiler:
Ich arbeite auch bereits an einem Image auf bookworm Basis. Hier werden allerdings einige alten Zöpfe abgeschnitten und das Image wird sich auf den Betrieb von FHEM als Perl Programm fokussieren und nicht darauf ein vollständiges OS zu erhalten.

Viele Grüße
Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 11 September 2023, 00:19:29
Hallo Zusammen,

Ich habe heute das Update auf Docker Image 3.2.3-Bullseye gemacht. Leider startete damit alexa-fhem nicht mehr. Weder über die GUI noch über die CLI liessen sich nmp updates, upgrades oder installs machen. Das Modul alexa hat die alexa-fhem installation einfach nicht gefunden und es liess sich nichts installieren. Leider habe ich keine Zeit für eine große Fehlersuche, da ich ein ein paar Stunden in Urlaub fahre. (warum mache ich auch kurz vorher ein Update ;) )

Ich bin jetzt wieder auf 3.2.2-Bullseye zurück, damit läuft wieder alles wie es soll.

Sorry wenn ich hier nicht konkrete Infos liefern kann, aber vielleicht tritt der Fehler (wenn es denn einer ist) bei noch jemand auf.     
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 11 September 2023, 09:35:24
ich hatte es gestern bemerkt aber nicht weiter analysiert. Wenn man den Befehlt des Dockerfile zum installieren manuell ausführt dann zeigt es mehrfach "wait 20 sec" ... "wait 60 sec" .. an. Ich vermute weil es schon nodejs 16/18 gibt soll es darauf hinweisen, dass es obsolet ist. Das könnte beim Build des Image zu einem Timeout führen und dann fehlt npm/nodejs/gassistant/alexa ... das ganze was in dem Zweig rein käme.

Vielleicht ginge es, wenn man eine neuere Version verwendet. Wobei es dann bei den Paketen zu gassistant/alexa zu weiteren Fehlnen kommen könnte.

Wenn ich heute Abend Zeit finde teste ich es ggf. mal.

Zeile 452 ff
LC_ALL=C curl --retry 3 --retry-connrefused --retry-delay 2 -fsSL https://deb.nodesource.com/setup_14.x | LC_ALL=C bash -
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 11 September 2023, 12:41:38
Zitat von: Borkk am 11 September 2023, 00:19:29Hallo Zusammen,

Ich habe heute das Update auf Docker Image 3.2.3-Bullseye gemacht. Leider startete damit alexa-fhem nicht mehr. Weder über die GUI noch über die CLI liessen sich nmp updates, upgrades oder installs machen.

Hi,

Welche Architektur verwendest Du denn? Es wird nur für AMD64 inkludiert.

Mir fallen solche Fehler leider nicht auf, da ich das Image ohne Bodens verwende:

ghcr.io/fhem/fhem-minimal-docker:3.2.3-bullseye

PS: Mit der Nächsten auf Bookworm basierenden Version müssen diese Zusatzprogramme in einen eigenen Container überführt werden, da diese sich besser warten lassen.

Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 11 September 2023, 20:58:36
Zitat von: Sidey am 11 September 2023, 12:41:38Welche Architektur verwendest Du denn? Es wird nur für AMD64 inkludiert.

Mir fallen solche Fehler leider nicht auf, da ich das Image ohne Bodens verwende:

Läuft auf AMD64.

npm -v liefert fehlendes Modul 'timers/promises'. Das "Internet" sagt man solle auf node16 upgraden.

Fakt 1: node 14 ist schon aus der Wartung
Fakt 2: das verwendete Installationsscript "SCRIPT DEPRECATION WARNING"
Fakt 3: die neue Installationsroutine ist erst Node16 aufwärts verfügbar. Kompatibel zu gassistand? Alexa*-Module? ... https://github.com/nodesource/distributions#installation-instructions

Fraglich ob es lohnt hier das Dockerfile noch anzupassen wenn du sowieso nur noch mit "minimal" ohne diese Zusatzmodule weiter machen willst. Ggf. kannst du ein Rollback machen und die alte Version wieder in Dockerhub / Github als latest einchecken.

Ich habe nicht weiter mit dem Installationsscript getestet, ich bleibe auf einer älteren Version. Es gibt ja keine Probleme mit dem Container, es war nur eine neuere Basisversion von Debian.

Fehler (einfach npm -v)
npm -v
/usr/lib/node_modules/npm/lib/es6/validate-engines.js:31
    throw err
    ^

Error: Cannot find module 'timers/promises'
Require stack:
- /usr/lib/node_modules/npm/node_modules/@npmcli/agent/lib/util.js
- /usr/lib/node_modules/npm/node_modules/@npmcli/agent/lib/index.js
- /usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/remote.js
- /usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/cache/entry.js
- /usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/cache/index.js
- /usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/fetch.js
- /usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/index.js
- /usr/lib/node_modules/npm/node_modules/npm-registry-fetch/lib/index.js
- /usr/lib/node_modules/npm/lib/utils/replace-info.js
- /usr/lib/node_modules/npm/lib/utils/error-message.js
- /usr/lib/node_modules/npm/lib/utils/exit-handler.js
- /usr/lib/node_modules/npm/lib/cli-entry.js
- /usr/lib/node_modules/npm/lib/cli.js
- /usr/lib/node_modules/npm/bin/npm-cli.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:931:15)
    at Function.Module._load (internal/modules/cjs/loader.js:774:27)
    at Module.require (internal/modules/cjs/loader.js:1003:19)
    at require (internal/modules/cjs/helpers.js:107:18)
    at Object.<anonymous> (/usr/lib/node_modules/npm/node_modules/@npmcli/agent/                                                                                      lib/util.js:3:16)
    at Module._compile (internal/modules/cjs/loader.js:1114:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1143:10)
    at Module.load (internal/modules/cjs/loader.js:979:32)
    at Function.Module._load (internal/modules/cjs/loader.js:819:12)
    at Module.require (internal/modules/cjs/loader.js:1003:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/usr/lib/node_modules/npm/node_modules/@npmcli/agent/lib/util.js',
    '/usr/lib/node_modules/npm/node_modules/@npmcli/agent/lib/index.js',
    '/usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/remote.js',
    '/usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/cache/entry.js                                                                                      ',
    '/usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/cache/index.js                                                                                      ',
    '/usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/fetch.js',
    '/usr/lib/node_modules/npm/node_modules/make-fetch-happen/lib/index.js',
    '/usr/lib/node_modules/npm/node_modules/npm-registry-fetch/lib/index.js',
    '/usr/lib/node_modules/npm/lib/utils/replace-info.js',
    '/usr/lib/node_modules/npm/lib/utils/error-message.js',
    '/usr/lib/node_modules/npm/lib/utils/exit-handler.js',
    '/usr/lib/node_modules/npm/lib/cli-entry.js',
    '/usr/lib/node_modules/npm/lib/cli.js',
    '/usr/lib/node_modules/npm/bin/npm-cli.js'
  ]
}
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 11 September 2023, 23:15:11
Zitat von: kadettilac89 am 11 September 2023, 20:58:36npm -v liefert fehlendes Modul 'timers/promises'. Das "Internet" sagt man solle auf node16 upgraden.

Das gibt es nur für Node <= 14. Verstehe nicht wieso es jetzt zum Problem wird, aber letztendlich ist das ein weiteres Problem, mit dem installierten Node im FHEM Container. Angefangen hat das ganze ja irgendwie auf ARM Plattformen, dass es nicht mehr ging.

Zitat von: kadettilac89 am 11 September 2023, 20:58:36Fakt 3: die neue Installationsroutine ist erst Node16 aufwärts verfügbar. Kompatibel zu gassistand? Alexa*-Module? ... https://github.com/nodesource/distributions#installation-instructions
Node 16 ist auch schon veraltet. Alexa-Fhem funktioniert bei mir einwandfrei auf mit dem node-20.6 Image:

https://github.com/fhem/alexa-fhem-docker/tree/v5.0.5

Zitat von: kadettilac89 am 11 September 2023, 20:58:36Fraglich ob es lohnt hier das Dockerfile noch anzupassen wenn du sowieso nur noch mit "minimal" ohne diese Zusatzmodule weiter machen willst. Ggf. kannst du ein Rollback machen und die alte Version wieder in Dockerhub / Github als latest einchecken.

Ich verstehe die Idee, aber nur wegen dem Node Fehler das Image mit älteren Paketen zu verwenden empfinde ich nicht unbedingt als "gute" Idee.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 12 September 2023, 09:33:00
Zitat von: Sidey am 11 September 2023, 12:41:38Welche Architektur verwendest Du denn? Es wird nur für AMD64 inkludiert.

Mir fallen solche Fehler leider nicht auf, da ich das Image ohne Bodens verwende:

Ich habe alles auf einer Synology DS 220+ laufen. Bin von den RPI´s weg, wegen dem Speicher. In die Syno habe ich 32 GB gesteckt und ruhe ist :-)
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 12 September 2023, 21:14:49
Zitat von: Borkk am 12 September 2023, 09:33:00Ich habe alles auf einer Synology DS 220+ laufen. Bin von den RPI´s weg, wegen dem Speicher. In die Syno habe ich 32 GB gesteckt und ruhe ist :-)

Ich habe mir das angesehen. NPM 5.8 gibt es nicht mehr. Ein neueres NPM braucht auch ein neueres NodeJS. Irgendwo da wird vermutlich das Problem liegen.

Ich habe mal was probiert und ein Image zum Testen mit NPM 8.19 , NodeJS 16.20.2 gebaut:

ghcr.io/fhem/fhem-docker:3.3.0-rc1-bullseye
Ich freue mich über Rückmeldungen.


Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 12 September 2023, 22:45:00
feedback: node/npm fehler sind weg. gassistant startet wieder
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 14 September 2023, 22:09:08
habe es mal aus der Ferne eingespielt. alexa-fhem lässt sich starten. Nur das NPM Paket lässt sich nicht updaten/upgraden

Package Name   Installed Version   Update Version   Upgrade Version
npm           8.19.4                   10.1.0           10.1.0
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 14 September 2023, 22:17:59
Zitat von: Borkk am 14 September 2023, 22:09:08habe es mal aus der Ferne eingespielt. alexa-fhem lässt sich starten. Nur das NPM Paket lässt sich nicht updaten/upgraden

Du willst in einem Container auch keine Pakete upgraden, glaube mir :)
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 15 September 2023, 10:11:11
Ich glaube dir natürlich :-) Ich bin halt ein ordentlicher Mensch und schaue, dass in FHEM alle ,,Schilde" auf grün sind ;-). Es ist mir klar, dass dies flüchtig ist. Allerdings möchte ich positiv erwähnen, dass die FHEM Container bei mir eigentlich von Update zu Update sauber durchlaufen.

D.h. wenn du die Version 3.3.0 released, können wir wieder auf ...:latest umstellen?

Aber mal eine grundsätzliche Frage. Ich habe Homebridge in einem extra Container laufen und würde das im Grunde auch mit alexa-fhem machen können. Dann würde ich die Minimal Version des FHEM Docker Image nutzen. Macht das Sinn oder ist das quatsch. Ich hatte früher sogar in AWS einen Custom Skill am laufen, brauchte ihn aber nicht mehr, weil FHEM Connector alles konnte was ich brauche. Wie gesagt, eher eine grundsätzliche Frage, es läuft ja alles Prima auch wenn es nach einem Container Update manchmal etwas hakt.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 15 September 2023, 18:10:51
Zitat von: Borkk am 15 September 2023, 10:11:11Es ist mir klar, dass dies flüchtig ist.
Das ist ein Punkt, aber du legst bei jeder Änderung einen neuen layer an. Die alten Daten werden nicht gelöscht.


Zitat von: Borkk am 15 September 2023, 10:11:11D.h. wenn du die Version 3.3.0 released, können wir wieder auf ...:latest umstellen?

Hmm, ja theoretisch.
Verlass dich aber nicht darauf, dass latest immer nodejs liefert.
Zitat von: Borkk am 15 September 2023, 10:11:11Aber mal eine grundsätzliche Frage. Ich habe Homebridge in einem extra Container laufen und würde das im Grunde auch mit alexa-fhem machen können. Dann würde ich die Minimal Version des FHEM Docker Image nutzen. Macht das Sinn oder ist das quatsch.

Das ergibt auf jeden Fall Sinn, denn der alexa-fhem image hat andere Updatezyklen als Perl und dass erneuert Du dann einfach wenn es ein neues nodejs oder alexa-fhem gibt.

Grüße
Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 05 Oktober 2023, 14:09:22
Zitat von: Sidey am 15 September 2023, 18:10:51Das ergibt auf jeden Fall Sinn, denn der alexa-fhem image hat andere Updatezyklen als Perl und dass erneuert Du dann einfach wenn es ein neues nodejs oder alexa-fhem gibt.

Grüße
Sidey

Hallo Sidey,

meine Frage ist vielleicht ein wenig OffTopic aber evtl. kannst du mir ja dennoch helfen, zumal du das mit dem separaten alexa-fhem Image befürwortest. Ich würde gerne weiterhin den Community-Proxy verwenden, da die Einrichtung in AWS schon recht komplex ist und der Proxy gut funktioniert.

Ich habe also einen alexa-fhem Container aufgezogen und die .json Dateien entsprechend konfiguriert. Er startet, verbindet sich mit FHEM und bekommt auch Meldungen aus FHEM. In FHEM habe ich das Attribut alexaFHEM-host auf die IP Adressen des alexa-fhem Containers gelegt. (ich nutze in meinem Docker macVLAN Adressen). Scheinbar verbindet sich der Container auch mit dem Proxy.

[10/5/2023, 2:36:53 PM] *** SSH: proxy connection established
[10/5/2023, 2:36:53 PM] SSH: Welcome at the reverse proxy!  This pseudoshell does not react to any input - do not get irritated. 

Das alexa Modul meldet auch im Reading "alexaFHEM.ProxyConnection" running; SSH connected

Damit scheint es aber noch nicht getan zu sein, denn das alexa Modul in FHEM startet damit nicht. Im FHEM Log kommt immer:

ssh: connect to host 192.168.xxx.xxx port 22: Connection refused
2023.10.05 14:41:56 2: alexa: starting alexa-fhem: /usr/bin/ssh 192.168.xxx.xxx  -c /tmp/alexa-fhem.cfg
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 05 Oktober 2023, 18:59:25
Bitte entferne das Attribut "Attribut alexaFHEM-host"

alexa-fhem startet automatisch und verbindet sich mit dem in der JSON Datei angegebenen FHEM.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 06 Oktober 2023, 00:18:45
Hallo Sidey,

Ich hab das Attribut in FHEM gelöscht, das Modul sieht nun so aus:

alexa2.jpg

Ich glaube das der alexa-fhem Docker Container sauber startet, zumindest sieht das log gut aus:

[10/6/2023, 12:04:58 AM] BearerToken '...4F737' read from alexa
[10/6/2023, 12:04:58 AM] 39_alexa.pm is new version: true
[10/6/2023, 12:04:58 AM] sshautoconf: completed successfully
[10/6/2023, 12:04:58 AM] *** SSH: proxy configuration set up done
[10/6/2023, 12:04:58 AM] Reading alexaFHEM.ProxyConnection set to starting;; starting SSH
[10/6/2023, 12:04:58 AM] [FHEM]   executing: http://192.168.23.230:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20alexa%20alexaFHEM.ProxyConnection%20starting%3B%3B%20starting%20SSH%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=csrf_446694299222015&XHR=1
[10/6/2023, 12:04:58 AM] Starting SSH with -R 1234:127.0.0.1:42387 -oServerAliveInterval=90 -i /alexa-fhem/.ssh/id_rsa -p 58824 fhem-va.fhem.de
[10/6/2023, 12:04:59 AM] Reading alexaFHEM.ProxyConnection set to running;; SSH connected
[10/6/2023, 12:04:59 AM] [FHEM]   executing: http://192.168.23.230:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bsetreading%20alexa%20alexaFHEM.ProxyConnection%20running%3B%3B%20SSH%20connected%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=csrf_446694299222015&XHR=1
[10/6/2023, 12:04:59 AM] *** SSH: proxy connection established
[10/6/2023, 12:04:59 AM] SSH: Welcome at the reverse proxy!  This pseudoshell does not react to any input - do not get irritated. 

Ich bekomme jetzt aber nicht den FHEM-Connector Skill in der Alexa App verknüpft.

IMG_D5DE87977AD0-1.jpeg

Das hatte ich schon mal, damals musste ich irgendwie einen key unregistrieren. Hier hänge ich jetzt irgendwie ....

 
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 06 Oktober 2023, 00:45:04
Ich habs... hab das alexa Modul in FHEM komplett gelöscht und wieder angelegt. Danach fluppt es einwandfrei.

Prima :-)
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kennymc.c am 07 Oktober 2023, 15:16:13
Ich habe ein Problem mit einem Fhem-Modul (bisher nicht öffentlich verfügbar), dass u.a. das Perl Modul Net::Rendezvous::Publish::Backend::Avahi benötigt. Sobald ich dieses Perl-Modul mit installieren lasse, stürzt Fhem kurz nach dem Start, vermutlich beim Laden dieses Moduls, mit dieser Meldung ab:
org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directoryIch habe es schon mit fhem-minimal-docker:3-bullseye und dem fhem:latest Image vom Docker Hub versucht. Als APT Packages sind zusätzlich avahi-daemon und avahi-tools installiert. Der Container läuft im Host Netzwerk.
Mir ist aufgefallen, dass /run/dbus auch gar nicht im Container existiert. Hab versucht dbus als APT Paket mit zu installieren und es auch mal mir privilegierten Rechten versucht aber bisher kein Erfolg. Geht das mit dem Docker Image überhaupt?

Edit: Hab es hinbekommen und mich an diese Anleitung gehalten: https://github.com/mviereck/x11docker/issues/271. Also /var/run/dbus/system_bus_socket als Volumen im Container mappen und --security-opt apparmor=unconfined als zusätzlichen Parameter
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 21 Oktober 2023, 14:39:03
Ich nutze FHEM noch klassisch auf einem Intel NUC. Ich möchte aber gerne das System nach und nach in Docker Instanzen auf meine Synology portieren.
Mit Zigbee2Mqtt hatte ich angefangen. Vom NUC entfernt und in einem Docker Container angelegt, das ging reibungslos.

Ich würde nun erst gerne noch alexa-fhem in einem Docker Container mit dem noch klassischem FHEM verbinden. Das scheitert bisher.
Was habe ich gemacht:
- alexa-fhem per Docker Instanz bereitgestellt
- in der alexa-fhem Config auf meine FHEM Instanz auf dem NUC verwiesen

Ich sehe im Log von alexa-fhem bereits Meldungen über die Devices und Commandos.

Nun dachte ich, stelle ich noch in FHEM im alexa-Device alexaFHEM-host auf die Adresse des Docker-Containers um.
Das funktioniert aber nicht. Vielleicht habe ich die Zusammenhänge auch noch nicht verstanden.

Was muss ich am alexa-Device in FHEM noch einstellen/ändern?
Ist hier vielleicht Off-Topic, aber der letzte Schritt vor dem großen Umzug ;-)
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 Oktober 2023, 15:34:46
Zitat von: HansDampfHH am 21 Oktober 2023, 14:39:03Was muss ich am alexa-Device in FHEM noch einstellen/ändern?


alexaFHEM-host entfernen.
Sofern der Container den Hostnamen der FHEM Instanz auflösen kann, wird alles funktionieren.

Grüße Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 21 Oktober 2023, 15:50:53
Hm.
Im Docker läuft alexa-fhem
- in der config.json
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "192.168.148.24"
    }
  ]

Auf dem NUC klassisches FHEM
- im alexa-Device steht alexaFHEM-config ./alexa-fhem.cfg
   "connections" : [
      {
         "server" : "127.0.0.1",
         "filter" : "alexaName=..*",
         "port" : 8083,
         "webname" : "fhem",
         "uid" : 998,
         "name" : "FHEM"
      }
   ]

Laufen jetzt zwei Instanzen von alexa-fhem und sind mit FHEM verknüpft?
Ich glaube ich habe noch nicht verstanden wofür alexa-fhem ist. Ich dachte das sei die Schnittstelle FHEM <-> Alexa.
Und davon sollte es ja nur eine geben.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 Oktober 2023, 17:42:13
Zitat von: HansDampfHH am 21 Oktober 2023, 15:50:53Hm.
Im Docker läuft alexa-fhem
- in der config.json
  "connections": [
    {
      "name": "FHEM",
      "webname": "fhem",
      "filter": "alexaName=..*",
      "uid": "6062",
      "port": "8083",
      "server": "192.168.148.24"
    }
  ]

Auf dem NUC klassisches FHEM
- im alexa-Device steht alexaFHEM-config ./alexa-fhem.cfg.

alexa-fhem auf dem NUC brauchst Du nicht mehr. Die Konfig Datei somit auch nicht.

Was macht denn der Docker Container laut logs?
Vermutlich läuft der ja bereits einwandfrei.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 21 Oktober 2023, 17:50:25
Ja, ich denke der Container läuft wie er soll. Da kommen Readings von diversen Devices rein (Temperatur oder on/off).
Aber wie werde ich denn alexa-fhem auf dem NUC los? Einfach per 'npm uninstall' entfernen? Und dann zickt das FHEM alexa Device nicht rum?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 Oktober 2023, 19:28:14
Zitat von: HansDampfHH am 21 Oktober 2023, 17:50:25Einfach per 'npm uninstall' entfernen? Und dann zickt das FHEM alexa Device nicht rum?

Genau so würde ich es machen.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 21 Oktober 2023, 19:57:38
Wohl nicht der richtige Weg  :(
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 21 Oktober 2023, 20:12:48
die erste Meldung sind mMn Fake News ;) das kann man ignorieren.
Die zweite Meldung ist wichtig und richtig!
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 21 Oktober 2023, 20:22:09
Tatsächlich. Habe mich davon irritieren lassen.
Kommandos werden ausgeführt. Sauber, danke für eure Hilfe!
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 22 Oktober 2023, 18:09:38
Vielleicht doch zu früh gefreut. Nach einem Neustart von FHEM hat die Steuerung über Alexa nicht mehr funktioniert.
Das Attribut alexaFHEM.ProxyConnection am alexa-Device stand auf stopped. Also noch mal den alexa-fhem Docker-Container neu gestartet.

ProxyConnection stand wieder auf 'running; SSH connected' aber Befehle wurde dennoch quitiert mit 'Lampe reagiert gerade nicht'.
Im Log vom Docker-Container sehe ich allerdings Messages eintrudeln:

[10/22/2023, 6:00:16 PM] [FHEM]     caching: TargetTemperature: 21 (as number; from '21.0')
  2023-10-22 18:01:37 caching: LaCrosse_0D-temperature: 20.5

Jemand noch eine Idee, wie ich dem Problem auf die Spur komme?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 22 Oktober 2023, 18:15:47
Poste mal das Log vom Zeitpunkt als der Container gestartet wurde.
Da steht ob er sich mit FHEM verbinden kann.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 22 Oktober 2023, 19:42:39
Reicht so?
Preparing user environment ...
  - Creating symlink to config.json in /alexa-fhem/.alexa/config.json ...
Starting alexa-fhem ...
[10/22/2023, 5:55:07 PM] os.homedir()=/alexa-fhem
[10/22/2023, 5:55:07 PM] using config from /alexa-fhem/.alexa/config.json
*** CONFIG: parsed completely
[10/22/2023, 5:55:07 PM] this is alexa-fhem 0.5.64
[10/22/2023, 5:55:07 PM] connecting to FHEM ...
[10/22/2023, 5:55:07 PM] [FHEM] defaults to: will not send proactive events
[10/22/2023, 5:55:07 PM] [FHEM] trying longpoll to listen for fhem events
[10/22/2023, 5:55:07 PM] [FHEM] starting longpoll: http://192.168.148.24:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON&timestamp=1697990107908
[10/22/2023, 5:55:07 PM] Server listening on: http://:::3000 for direct connections
[10/22/2023, 5:55:07 PM] [FHEM] got csrfToken: abcdefg
[10/22/2023, 5:55:07 PM] [FHEM] Checking devices and attributes...
[10/22/2023, 5:55:07 PM] [FHEM]   executing: http://192.168.148.24:8083/fhem?cmd=%7BAttrVal(%22global%22%2C%22userattr%22%2C%22%22)%7D&fwcsrf=abcdefg&XHR=1
[10/22/2023, 5:55:07 PM] [FHEM]   executing: http://192.168.148.24:8083/fhem?cmd=jsonlist2%20TYPE%3Dalexa&fwcsrf=abcdefg&XHR=1
[10/22/2023, 5:55:07 PM] [FHEM] waiting for events ...
[10/22/2023, 5:55:07 PM] [FHEM] Fetching FHEM devices...
[10/22/2023, 5:55:07 PM] [FHEM] fetching: http://192.168.148.24:8083/fhem?cmd=jsonlist2%20alexaName%3D..*&fwcsrf=abcdefg&XHR=1
[10/22/2023, 5:55:08 PM] [FHEM] alexa device is alexa
[10/22/2023, 5:55:08 PM] [FHEM] alexa will not send proactive events
[10/22/2023, 5:55:08 PM] [FHEM] alexa uses ID: abc-def-ghi-jkl-mno
[10/22/2023, 5:55:08 PM] [FHEM]   executing: http://192.168.148.24:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22alexa-fhem%20version%22%7D%20%3D%20%220.5.64%22%7D%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=abcdefg&XHR=1
[10/22/2023, 5:55:08 PM] [FHEM]   executing: http://192.168.148.24:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bget%20alexa%20proxyToken%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=abcdefg&XHR=1
[10/22/2023, 5:55:08 PM] [FHEM]   executing: http://192.168.148.24:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Blist%20alexa%20.eventToken%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=abcdefg&XHR=1
[10/22/2023, 5:55:08 PM] Server listening on: http://127.0.0.1:38450 for proxy connections
[10/22/2023, 5:55:08 PM] *** SSH: checking proxy configuration
[10/22/2023, 5:55:08 PM] sshautoconf: home=/alexa-fhem, spath=/alexa-fhem/.alexa, cpath=/alexa-fhem/.alexa/config.json, sshpath=/alexa-fhem/.ssh
[10/22/2023, 5:55:08 PM] Passed config: {
  alexa: {
    port: 3000,
    name: 'Alexa',
    ssl: false,
    keyFile: '/certs/alexa-fhem.key',
    certFile: '/certs/alexa-fhem.crt',
    'nat-pmp': '',
    'nat-upnp': false,
    applicationId: [ 'amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX' ],
    oauthClientID: [ 'amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' ]
  },
  sshproxy: {
    description: 'FHEM Connector',
    ssh: '/usr/bin/ssh',
    options: [ '-i', '/alexa-fhem/.ssh/id_rsa', '-p', 58824, 'fhem-va.fhem.de' ],
    'bind-ip': '127.0.0.1',
    server: Server {
      maxHeaderSize: undefined,
      insecureHTTPParser: undefined,
      _events: [Object: null prototype],
      _eventsCount: 3,
      _maxListeners: undefined,
      _connections: 0,
      _handle: [TCP],
      _usingWorkers: false,
      _workers: [],
      _unref: false,
      allowHalfOpen: true,
      pauseOnConnect: false,
      httpAllowHalfOpen: false,
      timeout: 0,
      keepAliveTimeout: 5000,
      maxHeadersCount: null,
      headersTimeout: 60000,
      requestTimeout: 0,
      _connectionKey: '4:127.0.0.1:0',
      [Symbol(IncomingMessage)]: [Function: IncomingMessage],
      [Symbol(ServerResponse)]: [Function: ServerResponse],
      [Symbol(kCapture)]: false,
      [Symbol(async_id_symbol)]: 93
    }
  },
  connections: [
    {
      name: 'FHEM',
      webname: 'fhem',
      filter: 'alexaName=..*',
      uid: '6062',
      port: '8083',
      server: '192.168.148.24'
    }
  ]
}
[10/22/2023, 5:55:08 PM] sshautoconf: SSH key seems to exist
[10/22/2023, 5:55:08 PM] sshautoconf: Our SSH key is known at the reverse proxy, good!
[10/22/2023, 5:55:08 PM] [FHEM]   executing: http://192.168.148.24:8083/fhem?cmd=%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%201%3B%3Bundef%7D%3Bjsonlist2%20alexa%3B%7B%24defs%7B%22alexa%22%7D-%3E%7B%22active%22%7D%20%3D%200%3B%3Bundef%7D&fwcsrf=abcdefg&XHR=1
*** FHEM: connected
[10/22/2023, 5:55:08 PM] [FHEM] got: 19 results
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 22 Oktober 2023, 20:52:52
Sieht doch gut aus.
Vermutlich musst Du den Skill nur neu anlernen.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 22 Oktober 2023, 20:56:54
Ja, ich denke auch, dass alles soweit passt.
Du meinst den Alexa Skill fhem-connector? Einmal deaktivieren und neu aktivieren?
Oder habe ich das falsch verstanden?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 22 Oktober 2023, 20:57:46
Zitat von: HansDampfHH am 22 Oktober 2023, 20:56:54Ja, ich denke auch, dass alles soweit passt.
Du meinst den Alexa Skill fhem-connector? Einmal deaktivieren und neu aktivieren?
Oder habe ich das falsch verstanden?
Ja so meinte ich das
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 23 Oktober 2023, 19:01:05
Zitat von: HansDampfHH am 22 Oktober 2023, 20:56:54Ja, ich denke auch, dass alles soweit passt.
Du meinst den Alexa Skill fhem-connector? Einmal deaktivieren und neu aktivieren?
Oder habe ich das falsch verstanden?

Ja, du bekommst einen neuen ProxyKey und must den Skill neu aktivieren. U.U. läufst du dann in den gleichen Fehler wie ich (https://forum.fhem.de/index.php?msg=1288735 (https://forum.fhem.de/index.php?msg=1288735))

Hier hat mir geholfen, das Alexa Modul einmal komplett aus FHEM zu löschen, Fhem neu starten und dann wieder zu installieren. Bei mir läuft das seitdem brettstabil ;D

Ich habe übrigens schon vor einiger Zeit FHEM, Alexa, Homebridge uvm. auf meine DS218+ auf Docker umgebaut und habe es nicht bereut. Ich gebe dir den Rat (wenn du es nicht ohnehin schon vor hast) MacVlan als Netzwerktreiber im Docker zu verwenden. Das macht vieles einfacher, da jeder Container eine IP aus deinem LAN bekommen kann. Hab das für IPv4 und IPv6 eingerichtet. (IPv6 muss nicht sein, geht aber).

Ach und noch was, nachdem ich alexa-fhem in den Docker Container verbannt habe, starte ich FHEM als fhem-minimal Image. Das ist nur halb so groß, hat alles was ich brauche und ist gefühlt etwas performanter.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Wernieman am 23 Oktober 2023, 21:42:58
MacVlan hat für den Anfänger den Nachteil, das er denkt eine VM (und keinen Container) zu haben .... habe es selber z.B. nicht in Benutzung und bin definitiv kein Anfänger. Setze persönlich dann lieber ein Proxy davor.

Geht nur nicht, wenn man wirklich, für BroadCase Netzwerke, direkte Hardwarezugriff braucht

Bezüglich eines "fhem-Light-Containers" kann ich Dir zustimmen. Der andere ist einfach nur "too Big".
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 24 Oktober 2023, 06:50:36
Von fhem-light höre ich das erste mal. Habt ihr eine URL für mich? Würde mir das gerne mal ansehen und schauen was am Ende eingespart wird.
EDIT: Schon gut, habe gesehen, dass es ein Image ist. Mal schauen, ob ich das mal teste.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: CoolTux am 24 Oktober 2023, 10:24:38
Was ich gerne einmal ausprobieren würde ist ein Perl Container only und dann mal schauen ob FHEM damit laufen würde.
Einige Linux Systemnahe Module werden dann natürlich nicht mehr gehen. Frage ist halt, braucht man die.

https://hub.docker.com/_/perl
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 24 Oktober 2023, 17:07:52
@Borkk
"Ja, du bekommst einen neuen ProxyKey und must den Skill neu aktivieren...
Hier hat mir geholfen, das Alexa Modul einmal komplett aus FHEM zu löschen, Fhem neu starten und dann wieder zu installieren."

Also:
- npm uninstall -g alexa-fhem
- in FHEM das alexa-Device entfernt und FHEM neu gestartet
- das Alexa-Device wieder angelegt: define alexa alexa
- den Skill deaktiviert und mit neuem ProxyKey neu aktiviert

Ergebnis im Bild zu sehen. Sieht aus als entferne ich mich immer weiter.
Wo steckt denn mein Problem oder welcher Schritt fehlt mir noch?

Wenn ich alexa-fhem wieder installiere funktioniert es sofort.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 07 November 2023, 13:42:18
Hast du denn Alexa-fhem sauber in einem separaten Container laufen? Baut der Container eine Verbindung zum Fhem auf? Das kannst du im Echtzeit log im Docker ja prima sehen. Und du darfst das Attribut "alexaFHEM-host" nicht setzten, auch wenn es irgendwo so beschrieben steht.

Im Modul steht dann im Reading Alexa_FHEM:
stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
Das ist zwar nicht schön stört aber nicht.

Ich habe übrigens seit meinem letzten Post, min. ein FHEM Docker Image Update durchgeführt. Nach jedem Neustart lief Alexa einwandfrei, ohne das ich was tun musste. Mit dem im FHEM Image eingebauten Alexa-FHEM gab es immer mal Probleme und es musste meist neu installiert werden. So ist es prima. Es ist grundsätzlich eine gute Idee das FHEM-Minimal Image so schlank wie möglich zu halten.   
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 07 November 2023, 13:51:13
Zitat von: Wernieman am 23 Oktober 2023, 21:42:58MacVlan hat für den Anfänger den Nachteil, das er denkt eine VM (und keinen Container) zu haben .... habe es selber z.B. nicht in Benutzung und bin definitiv kein Anfänger. Setze persönlich dann lieber ein Proxy davor.

Geht nur nicht, wenn man wirklich, für BroadCase Netzwerke, direkte Hardwarezugriff braucht

Bezüglich eines "fhem-Light-Containers" kann ich Dir zustimmen. Der andere ist einfach nur "too Big".

Ich habe MacVlan sauber mit IPv4 und IPv6 konfiguriert und es laufen 18 Container völlig problemlos auf einem Host. Spätestens wenn man Raspberrymatic in den Docker holt braucht man MacVlan. Allerdings ist die Docker Implementierung von Raspberrymatic nicht wirklich schön. Auf der Syno läuft Raspberrymatic in einer VM. (sorry offTopic)

Einen Ngix ReverseProxy habe ich auch davor hängen. Der regelt aber eigentlich nur den Zugriff von aussen mit HTTPS und ClientZertifikaten.   
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 10 November 2023, 10:20:41
@Borkk
Ich wollte ja stückweise umziehen und erst mal nur alexa-fhem in einem Container nutzen.
Bin nun aber mit fhem und alexa-fhem komplett in Docker umgezogen. Nun funktioniert das ganze Set-Up.

Habe auch macvlan eingerichtet, das BOSE Modul suchte auf bereits belegten UDP Ports. Mit macvlan ist nun auch das gelöst.

Hat noch jemand eine gute Anleitung, wie ich nun aus dem Docker-Container auf die Host-IP komme? Das geht ja mit macvlan von Haus aus nicht.
Aber ich würde gerne an 2 API-Schnittstellen am Host kommen.

Edit:
Habe jetzt erst mal einen Node-Proxy auf meiner Synology laufen. Der API-Call geht also an die Synology, die den Request 1:1 an den "Host" weiterleitet.
Vielleicht nicht das eleganteste, aber reicht.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 10 November 2023, 14:16:42
Hallo! Ich verwende nun schon längere Zeit das Docker.Image FusionSolar für meine Solaranlage. Soweit läuft es sehr gut, allerdings habe ich einen Bug gefunden der mich ziemlich stört: Das Reading
daily_energy wird anstatt um Mitternacht erst um 1:00 Uhr zurück gesetzt. Da ich die täglichen Daten weiterverwende habe ich um 1:00 Früh bereits z.B. 34kWh produziert. Das stimmt nicht einmal im Sommer, wenn die Sonne schon um 4:30 aufgeht.
Anbei ein Log-Auszug:

2023-11-01_23:58:35 PV_Lohr daily_energy: 34.73
2023-11-01_23:58:35 PV_Lohr grid_phase_b_current: 0.0
2023-11-01_23:58:35 PV_Lohr grid_phase_a_current: 0.0
2023-11-01_23:58:35 PV_Lohr daily_to_grid_energy: 31.9
2023-11-01_23:58:35 PV_Lohr daily_grid_use_energy: 5.3
2023-11-02_00:00:32 PV_Lohr from_grid_power: 0.301
2023-11-02_00:00:32 PV_Lohr to_grid_power: 0
2023-11-02_00:00:32 PV_Lohr electrical_load: 0.301
2023-11-02_00:00:32 PV_Lohr grid_power: 0.301
2023-11-02_00:00:32 PV_Lohr inverter_output_power: 0.0
2023-11-02_00:00:32 PV_Lohr string_output_power: 0.0
2023-11-02_00:00:32 PV_Lohr daily_self_use_ratio: 34.81
2023-11-02_00:00:32 PV_Lohr station: NE=36213689
2023-11-02_00:00:32 PV_Lohr co2_saved: 1797.8607499999998
2023-11-02_00:00:32 PV_Lohr daily_self_use_energy: 2.83
2023-11-02_00:00:32 PV_Lohr daily_self_use_solar_ratio: 8.15
2023-11-02_00:00:32 PV_Lohr daily_use_energy: 8.13
2023-11-02_00:00:32 PV_Lohr grid_connected_time: 2023-07-26 11:10:27
2023-11-02_00:00:32 PV_Lohr installed_capacity: 10.5600
2023-11-02_00:00:32 PV_Lohr total_current_day_energy: 34.73
2023-11-02_00:00:32 PV_Lohr total_current_month_energy: 34.73
2023-11-02_00:00:32 PV_Lohr total_current_year_energy: 3784.97
2023-11-02_00:00:32 PV_Lohr total_lifetime_energy: 3784.97
2023-11-02_00:00:32 PV_Lohr battery_soc: 0
2023-11-02_00:00:32 PV_Lohr battery_power: 0
2023-11-02_00:00:32 PV_Lohr battery_charge_capacity: 0
2023-11-02_00:00:32 PV_Lohr battery_discharge_capacity: 0
2023-11-02_00:00:32 PV_Lohr grid_frequency: 0.0
2023-11-02_00:00:32 PV_Lohr power_factor: 0.0
2023-11-02_00:00:32 PV_Lohr pv1_input_current: 0.0
2023-11-02_00:00:32 PV_Lohr grid_phase_a_voltage: 0.0
2023-11-02_00:00:32 PV_Lohr output_reactive_power: 0.0
2023-11-02_00:00:32 PV_Lohr pv2_input_current: 0.0
2023-11-02_00:00:32 PV_Lohr active_power: 0.0
2023-11-02_00:00:32 PV_Lohr pv2_input_voltage: 0.0
2023-11-02_00:00:32 PV_Lohr mppt_1_dc_cumulative_energy: 1990.84
2023-11-02_00:00:32 PV_Lohr mppt_2_dc_cumulative_energy: 1921.16
2023-11-02_00:00:32 PV_Lohr pv1_input_voltage: 0.0
2023-11-02_00:00:32 PV_Lohr grid_phase_c_current: 0.0
2023-11-02_00:00:32 PV_Lohr grid_phase_c_voltage: 0.0
2023-11-02_00:00:32 PV_Lohr total_input_power: 0.0
2023-11-02_00:00:32 PV_Lohr grid_phase_b_voltage: 0.0
2023-11-02_00:00:32 PV_Lohr daily_energy: 34.73
.
.
.
.
2023-11-02_00:58:36 PV_Lohr daily_energy: 34.73
2023-11-02_00:58:36 PV_Lohr grid_phase_b_current: 0.0
2023-11-02_00:58:36 PV_Lohr grid_phase_a_current: 0.0
2023-11-02_00:58:36 PV_Lohr daily_to_grid_energy: 34.73
2023-11-02_00:58:36 PV_Lohr daily_grid_use_energy: 0.22
2023-11-02_01:00:32 PV_Lohr from_grid_power: 0.411
2023-11-02_01:00:32 PV_Lohr to_grid_power: 0
2023-11-02_01:00:32 PV_Lohr electrical_load: 0.411
2023-11-02_01:00:32 PV_Lohr grid_power: 0.411
2023-11-02_01:00:32 PV_Lohr inverter_output_power: 0.0
2023-11-02_01:00:32 PV_Lohr string_output_power: 0.0
2023-11-02_01:00:32 PV_Lohr daily_self_use_ratio: 0.00
2023-11-02_01:00:32 PV_Lohr station: NE=36213689
2023-11-02_01:00:32 PV_Lohr co2_saved: 1797.8607499999998
2023-11-02_01:00:32 PV_Lohr daily_self_use_energy: 0.0
2023-11-02_01:00:32 PV_Lohr daily_self_use_solar_ratio: --
2023-11-02_01:00:32 PV_Lohr daily_use_energy: 0.24
2023-11-02_01:00:32 PV_Lohr grid_connected_time: 2023-07-26 11:10:27
2023-11-02_01:00:32 PV_Lohr installed_capacity: 10.5600
2023-11-02_01:00:32 PV_Lohr total_current_day_energy: 0.0
2023-11-02_01:00:32 PV_Lohr total_current_month_energy: 34.73
2023-11-02_01:00:32 PV_Lohr total_current_year_energy: 3784.97
2023-11-02_01:00:32 PV_Lohr total_lifetime_energy: 3784.97
2023-11-02_01:00:32 PV_Lohr battery_soc: 0
2023-11-02_01:00:32 PV_Lohr battery_power: 0
2023-11-02_01:00:32 PV_Lohr battery_charge_capacity: 0
2023-11-02_01:00:32 PV_Lohr battery_discharge_capacity: 0
2023-11-02_01:00:32 PV_Lohr grid_frequency: 0.0
2023-11-02_01:00:32 PV_Lohr power_factor: 0.0
2023-11-02_01:00:32 PV_Lohr pv1_input_current: 0.0
2023-11-02_01:00:32 PV_Lohr grid_phase_a_voltage: 0.0
2023-11-02_01:00:32 PV_Lohr output_reactive_power: 0.0
2023-11-02_01:00:32 PV_Lohr pv2_input_current: 0.0
2023-11-02_01:00:32 PV_Lohr active_power: 0.0
2023-11-02_01:00:32 PV_Lohr pv2_input_voltage: 0.0
2023-11-02_01:00:32 PV_Lohr mppt_1_dc_cumulative_energy: 1990.84
2023-11-02_01:00:32 PV_Lohr mppt_2_dc_cumulative_energy: 1921.16
2023-11-02_01:00:32 PV_Lohr pv1_input_voltage: 0.0
2023-11-02_01:00:32 PV_Lohr grid_phase_c_current: 0.0
2023-11-02_01:00:32 PV_Lohr grid_phase_c_voltage: 0.0
2023-11-02_01:00:32 PV_Lohr total_input_power: 0.0
2023-11-02_01:00:32 PV_Lohr grid_phase_b_voltage: 0.0
2023-11-02_01:00:32 PV_Lohr daily_energy: 0.0

Das Problem hat sich mit Umstellung auf die Winterzeit "halbiert", denn in Zeiten der Sommerzeit war das Zurücksetzen immer erst um 2:00. Ich gehe daher stark davon aus, dass irgendwo eine hardcoded Abfrage mit GMT ist.

LG Rallye
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 10 November 2023, 15:05:32
Hallo Rallye,

was liefert denn dies in der FHEM Kommandozeile zurück?

{qx(date)}
Und dazu date in der cmdline vom Docker Host?

Gruß Otto
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 10 November 2023, 15:50:05
Hallo Otto, das liefert
Fr 10. Nov 15:45:23 CET 2023und ist die diente Zeit zu meinem Stand-PC, Mobiltelefon usw. Am Docker-Host habe ich 2 Minuten später die Ausgabe
Fri Nov 10 15:47:30 CET 2023
Die Idee hätte ich auch gehabt. doch alle anderen Readings mit "daily" werden um ca. 00:00 Uhr auf 0 gesetzt. Genau wie es sein soll bzw. auch bei daily_energy sein sollte

LG Rallye
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Otto123 am 10 November 2023, 15:53:45
Dann wird es was mit FusionSolar zu tun haben und nicht mit dem fhem Docker Image - oder ich verstehe das nicht :)
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: rallye am 10 November 2023, 16:48:51
Ich nehme an es hat mit der Programmierung des Moduls zu tun. Im Github habe ich im Modul fusionsolar_api.py mehrere "UTC"s gefunden, doch bin kann ich viel zu wenig Python als dass ich einen Fehler lokalisieren könnte. Ich habe aus dem Source-Code zumindest herauslesen können, dass das Reading "daily_energy" irgendwie (im Gegensatz zu vielen anderen Readings) dort nicht vorkommt. Damit bin ich am Ende meines Lateins (bzw. Pythons).
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 10 November 2023, 19:45:37
Zitat von: CoolTux am 24 Oktober 2023, 10:24:38Was ich gerne einmal ausprobieren würde ist ein Perl Container only und dann mal schauen ob FHEM damit laufen würde.
Einige Linux Systemnahe Module werden dann natürlich nicht mehr gehen. Frage ist halt, braucht man die.

https://hub.docker.com/_/perl
Das ist allerdings immer noch ein MB-Monster. So geht Perl-Image auch (11 MB).
https://hub.docker.com/r/avastsoftware/alpine-perl/tags

Das Problem ist, dass das Image mit dem reinpressen aller denkbaren Funktionalität riesig wird. Man bräuchte ein Konzept, das jeweils nur die Funktionalitäten in das Image lädt, die wirklich benutzt werden.

S6 init bietet dafür durchaus Ansätze, die z.B. linuxserver.io mit dem Nachladen von Images als Module ganz spannend nutzt.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 12 November 2023, 09:59:50
Mittlerweile laufen fhem und alexa-fhem ja in separaten Containern. Alles fein.
Beim anlegen von alexa, wird ein Logfile-Attribut gesetzt.
Ist das eigentlich normal, dass das tägliche Logfile (alexa-2023-11-12.log) nun leer ist wenn man alexa-fhem in einem separaten Container laufen lässt?

Ich brauche das nicht zwingend, würde das nur gerne verstehen.

Internals:
   FUUID      65474128-f33f-ca9c-e539783bbd8cbe87
   FVERSION   39_alexa.pm:0.238200/2021-02-24
   NAME       alexa
   NOTIFYDEV  global,global:npmjs.*alexa-fhem.*
   NR         39
   NTFY_ORDER 50-alexa
   STATE      stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
   TYPE       alexa
   active     0
   alexa-fhem version 0.5.64
   eventCount 5
   logfile    ./log/alexa-%Y-%m-%d.log
   CoProcess:
     cmdFn      alexa_getCMD
     name       alexaFHEM
     state      stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
   READINGS:
     2023-11-10 12:39:35   alexaFHEM       stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
     2023-11-12 09:27:55   alexaFHEM.ProxyConnection running; SSH connected
     2023-11-05 08:15:53   alexaFHEM.bearerToken crypt:0570060d22737b767320540d070550
     2023-11-05 08:15:53   alexaFHEM.skillRegKey crypt:01087271570578751c5b200f7004510502520072067423764b0477015c757f7273757653700d020252
   hmccu:
Attributes:
   alexaFHEM-config ./alexa-fhem.cfg
   alexaFHEM-log ./log/alexa-%Y-%m-%d.log
   alexaMapping #Characteristic=<name>=<value>,...
On=verb=schalte,valueOn=an;ein,valueOff=aus,valueToggle=um

Brightness=verb=stelle,property=helligkeit,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

Hue=verb=stelle,valuePrefix=auf,values=rot:0;grün:128;blau:200
Hue=verb=färbe,values=rot:0;grün:120;blau:220

Saturation=verb=stelle,property=sättigung,valuePrefix=auf,values=AMAZON.NUMBER
Saturation=verb=sättige,values=AMAZON.NUMBER

TargetPosition=verb=mach,articles=den;die,values=auf:100;zu:0
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

TargetTemperature=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=grad

Volume:verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent

#Weckzeit=verb=stelle,valuePrefix=auf;für,values=AMAZON.TIME,valueSuffix=uhr
   alexaTypes #Type=<alias>[,<alias2>[,...]]
light=licht,lampen
blind=rolladen,rolläden,jalousie,jalousien,rollo,rollos
   devStateIcon stopped:control_home@red:start stopping:control_on_off@orange running.*:control_on_off@green:stop
   echoRooms  #<deviceId>=<room>

   fhemIntents #IntentName=<sample utterance>
gutenMorgen=guten morgen
guteNacht=gute nacht
   group      Amazon
   icon       alexa
   persons    #<personId>=<name>
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 13 November 2023, 00:21:16
Na Du loggst ja jetzt vermutlich aus dem anderen Container woanders hin. Oder hast Du einen Volume-Mount mit Log-Umleitung auf diese Datei eingerichtet?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: HansDampfHH am 13 November 2023, 06:56:00
Ich glaube das Log-Attribut ist ein Überbleibsel meiner alten Konfiguration. Ich dachte, dass wurde nach dem Hochfahren des Containers so angelegt und mich gefragt, wo die Logs sind. Alles gut, Attr gelöscht.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Borkk am 24 Dezember 2023, 00:25:56
Zitat von: HansDampfHH am 10 November 2023, 10:20:41@Borkk
Ich wollte ja stückweise umziehen und erst mal nur alexa-fhem in einem Container nutzen.
Bin nun aber mit fhem und alexa-fhem komplett in Docker umgezogen. Nun funktioniert das ganze Set-Up.

Habe auch macvlan eingerichtet, das BOSE Modul suchte auf bereits belegten UDP Ports. Mit macvlan ist nun auch das gelöst.

Hat noch jemand eine gute Anleitung, wie ich nun aus dem Docker-Container auf die Host-IP komme? Das geht ja mit macvlan von Haus aus nicht.
Aber ich würde gerne an 2 API-Schnittstellen am Host kommen.

Edit:
Habe jetzt erst mal einen Node-Proxy auf meiner Synology laufen. Der API-Call geht also an die Synology, die den Request 1:1 an den "Host" weiterleitet.
Vielleicht nicht das eleganteste, aber reicht.

Ich hatte eine ganz Weile die Maria SQL_DB direkt auf der Synology laufen. Damit die Container darauf zugreifen konnten, habe ich eine Bridge anlegt. Das ganze lasse ich bei Start über eine Aufgabe im Aufgabenplaner beim Systemstart als root ablaufen.

#!/bin/bash
while ! /usr/local/bin/docker info >/dev/null 2>&1;
do
    sleep 5s
done

ip link add mvl-brg link eth0 type macvlan mode bridge
ip addr add "IP aus dem macvlan Bereich/32" dev mvl-brg
ip link set mvl-brg up
ip route add "mcvlan ip range/xx" dev mvl-brg


Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 01 Februar 2024, 17:26:22
Hallo zusammen,

ich versuche gerade FHEM im Docker-Container über Portainer einzurichten. Allerdings kann ich nicht einmal den Container erstellen. Der Vorgang bricht immer mit "CODE 500" ab.

Portainer + Docker ist in einer Ubuntu-VM installiert. Andere Container (z.B. PI-HOLE laufen). Nun wollte ich testweise FHEM als Container installieren. Hierzu habe ich "fhem/fhem:latest" als Dockerfile ausgewählt und Port  durchgereicht. Als Netzwerk ist "bridge" eingetragen.

Was fehlt?

Viele Grüße
Jürgen
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 01 Februar 2024, 18:13:58
Also Portainer spuckt 500 aus? Oder das FHEM-Webinterface?

Gibts irgendwelche Logeinträge?

Was passiert wenn du testweise den Container mit docker run startest?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 01 Februar 2024, 18:44:17
Die Antwort kommt von "Portainer". Logeinträge werden (soweit ich es sehen kann) nicht erzeugt.

Mit welchen Parametern soll ich docker run starten?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 01 Februar 2024, 19:16:20
Gibts da nicht Beispiele auf GitHub? Sorry, komme grade nicht dazu selbst zu schauen.
Alternativ auch mal checken ob du auch wirklich das richtige Image hast.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 01 Februar 2024, 20:19:44
Ich verstehe nicht ganz, was Du mit
ZitatHierzu habe ich "fhem/fhem:latest" als Dockerfile ausgewählt
meinst.

Hast du einen Stack definiert?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 01 Februar 2024, 20:24:39
Ich glaube er hat mit "Dockerfile" das Image gemeint. Deshalb auch meine Bitte, das zu überprüfen ...
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 02 Februar 2024, 14:39:13
ja mit fhem/fhem:latest meinte ich das Docker-Image und nein ich habe keinen Stack definiert.
Ich Versuche fhem mit "docker run" zu installieren.

Viele Grüße
Jürgen
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 02 Februar 2024, 14:49:20
Läuft dein aktuelles FHEM (also das ohne Docker) auf dem gleichen System? Stoppst du das vorher? Sonst kann es sein, dass der Port schon belegt ist.
Das scheint laut Google jedenfalls ein Problem zu sein, das andere Leute häufig haben, wenn sie so ne 500er Fehlermeldung von Portainer bekommen.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: juemuc am 02 Februar 2024, 15:19:31
Hallo passibe,

das war der entscheidende Hinweis  8) In dieser VM läuft auch mein FHEM-Testsystem. Manchmal ist die Lösung so einfach  :-[

Danke für die Hilfe.

Viele Grüße
Jürgen
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: joachimS am 21 Februar 2024, 18:18:35
Erstmal vielen Dank für den klasse fhem Docker container, habe ihn weitgehend am laufen:
https://forum.fhem.de/index.php?topic=137142.0 (https://forum.fhem.de/index.php?topic=137142.0)

Wäre es bitte möglich die Prereqs für das SIRD Modul zu installieren?
Siehe: Modul für WLAN Radios mit Frontier Silicon Chipsatz (https://forum.fhem.de/index.php?topic=79168.0)
Speziell fehlt das XML::Bare modul:
2024.02.21 17:46:42 1: reload: Error:Modul 17_SIRD deactivated:
 Can't locate XML/Bare.pm in @INC (you may need to install the XML::Bare module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl ./FHEM/lib) at ./FHEM/17_SIRD.pm line 16.
BEGIN failed--compilation aborted at ./FHEM/17_SIRD.pm line 16.
Text2Speech konnte ich definieren.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: kadettilac89 am 21 Februar 2024, 19:38:21
Zitat von: joachimS am 21 Februar 2024, 18:18:35Wäre es bitte möglich die Prereqs für das SIRD Modul zu installieren?
Siehe: Modul für WLAN Radios mit Frontier Silicon Chipsatz (https://forum.fhem.de/index.php?topic=79168.0)
Speziell fehlt das XML::Bare modul:


Warum lässt du benötigtes Paket nicht beim erstellen mit installieiren?

Add custom packages (https://github.com/fhem/fhem-docker?tab=readme-ov-file#add-custom-packages)
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: joachimS am 21 Februar 2024, 20:53:48
Zitat von: kadettilac89 am 21 Februar 2024, 19:38:21Warum lässt du benötigtes Paket nicht beim erstellen mit installieiren?

Add custom packages (https://github.com/fhem/fhem-docker?tab=readme-ov-file#add-custom-packages)
Das hat mich abgeschreckt:
Don't do this unless you really know what this does!
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: passibe am 21 Februar 2024, 21:54:29
Solange du da nix wildes machst und nur ein von dir benötigtes Perl-Paket nachinstallierst passiert da nix.
Falls du eine Abneigung gegen CPAN hast kannst du alternativ zu CPAN_PKGS du übrigens auch APT_PKGS benutzen, das debian-Paket zu XML::Bare heißt libxml-bare-perl.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 21 Februar 2024, 22:31:26
Hi,

Packages nachinstallieren ist ein antipattern für Docker und muss jedesmal wenn das Image geladen wird wiederholt werden.


Ich beschäftige mich gerade mit Version 4 des Images.
Darin ist das von dir erwähnte Perl Paket auch installiert:


ghcr.io/fhem/fhem-docker:4.0.0-beta1-bullseye

Gruß Sidey
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: joachimS am 21 Februar 2024, 22:42:19
Super!
Danke für die Antworten.
docker run -d --name FHEM -p 1883:1883 -p 8083:8083 -v fhem:/opt/fhem -e CPAN_PKGS="XML::Bare" --device=/dev/ttyACM0 fhem/fheminstalliert das XML prereq und SIRD tut nun.
Aber klar, ich warte auf den neuen Container
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 22 Februar 2024, 21:48:15
Hallo,
ich habe schon lange Fhem auf Docker am Laufen. Aber jedesmal, wenn der Docker Server neu gestartet wird, ist der Mountpoint zur Fritzbox weg und ich muss diesen innerhalb der Shell im Container wieder händisch einhängen. Bei restart des Fhem containers bleibt der mount erhalten.
Im File post-start.sh (Wird ja nach jedem Start des fhem-containers ausgeführt) ist der mount definiert:
mkdir /mnt/Fritz.Nas
mount -t cifs -o username=fhem,password=##fhembackupusr*,uid=6061,gid=6061,noserverino,sec=ntlmv2 //192.168.3.1/fritz.nas/Generic-FlashDisk-01/FHEM /mnt/Fritz.Nas

Wie kann es funktionieren?

Gruß

Alex

Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 22 Februar 2024, 22:10:45
Wie wäre es, wenn Du den Mountpoint über Docker und nicht innerhalb des Containers verbindest?
docker volume create \
--driver local \
--opt type=cifs \
--opt device=//192.168.3.1/fritz.nas/Generic-FlashDisk-01/FHEM \
--opt o=addr=uxxxxx.your-server.de,username=uxxxxxxx,password=*****,file_mode=0777,dir_mode=0777 \
--name vol-fritzbox

Ich habe es selbst nicht versucht, würde aber vermuten, dass es der empfohlene Weg ist, denn innerhalb von Containern sollte nichts verändert werden was beim Nächsten Laden des Containers auch vorhanden sein soll:


Falls Du compose verwendest, so sollte es damit gehen:
volumes:
  vol-fritzbox:
    driver_opts:
      type: cifs
      o: username={smbuser},password={smbpass},uid={UID for mount},gid={gid for mount},vers=3.0
      device: //192.168.3.1/fritz.nas/Generic-FlashDisk-01/FHEM

Quelle:
https://forums.docker.com/t/how-to-map-lan-network-share-to-docker-volume/97276/2


PS: Das Passwort änderst Du jetzt hoffentlich, nachdem Du es hier veröffentlicht hast.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 23 Februar 2024, 16:45:52
Hallo Sidey,

erstmal danke für Deine Nachricht.
Die Idee das mit Volumes zu lösen hörte sich gut an.
Habe ich soweit hinbekommen, dass zwar der Fhem Container wieder läuft, aber innerhalb des Fhem Containers funktioniert der mount leider nicht.
Folgendes compose-file:
volumes:
  vol-fritzbox:
    driver: local
    driver_opts:
      type: cifs
      o: username=fhem,password=xxxxxxxxx,uid=6061,gid=20,vers=3.0
      device: //192.168.3.1/fritz.nas/Generic-FlashDisk-01/FHEM

services:
    fhem:
        image: fhem/fhem:latest
        restart: always
        container_name: fhem
        hostname: FHEM-Docker
        privileged: true
        ports:
            - "8083:8083"
            - "8084:8084"
            - "7072:7072"
            - "5987:5987"
            - "5060:5060"
            - "5070:5070"
            - "5080:5080"
            - "139:139"
            - "445:445"
            - "1000:1000"
...

        volumes:
            - ./fhem/core/:/opt/fhem/
            - /etc/localtime:/etc/localtime:ro
            - /sys/class/gpio:/sys/class/gpio
            - /sys/devices/platform/soc/fe200000.gpio:/sys/devices/platform/soc/fe200000.gpio
            - /dev/serial/by-id:/dev/serial/by-id
            - vol-fritzbox:/mnt/Fritz.Nas:rw
...
Ein docker inspect volume zeigt dies:
docker volume inspect  fhem-docker_vol-fritzbox:
[
    {
        "CreatedAt": "2024-02-23T15:57:33+01:00",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "fhem-docker",
            "com.docker.compose.version": "1.29.2",
            "com.docker.compose.volume": "vol-fritzbox"
        },
        "Mountpoint": "/var/lib/docker/volumes/fhem-docker_vol-fritzbox/_data",
        "Name": "fhem-docker_vol-fritzbox",
        "Options": {
            "device": "//192.168.3.1/fritz.nas/Generic-FlashDisk-01/FHEM",
            "o": "username=fhem, password=xxxxxxxxx,uid=6061,gid=20,vers=3.0",
            "type": "cifs"
        },
        "Scope": "local"
    }
]

Nachdem dies nicht funktioniert hat, habe ich die Volume Def.
auf das ursprüngliche Format (hat ja früher funktioniert, nur nicht nach Host restart) abgeändert:
o: username=fhem,password=xxxxxxxxx,uid=6061,gid=20,noserverino,sec=ntlmv2

docker volume inspect  fhem-docker_vol-fritzbox
[
    {
        "CreatedAt": "2023-11-20T11:40:34+01:00",
        "Driver": "local",
        "Labels": {
            "com.docker.compose.project": "fhem-docker",
            "com.docker.compose.version": "1.29.2",
            "com.docker.compose.volume": "vol-fritzbox"
        },
        "Mountpoint": "/var/lib/docker/volumes/fhem-docker_vol-fritzbox/_data",
        "Name": "fhem-docker_vol-fritzbox",
        "Options": {
            "device": "//192.168.3.1/fritz.nas/Generic-FlashDisk-01/FHEM",
            "o": "username=fhem,password=xxxxxxxxx,uid=6061,gid=20,noserverino,sec=ntlmv2",
            "type": "cifs"
        },
        "Scope": "local"
    }
]

Aber leider auch ohne Erfolg
Vielleicht hat noch jemand eine Idee?

VG

Alex
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Homalix99 am 23 Februar 2024, 16:51:17
Sorry,

funktioniert doch.
War zu ungeduldig und habe zu schnell getestet.
Mein Beitrag Nummer #2014 ist deshalb obsolet.
Vielen Dank nochmals.

VG

Alex
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 23 Februar 2024, 23:22:23
Zitat von: Homalix99 am 23 Februar 2024, 16:51:17Sorry,

funktioniert doch.
War zu ungeduldig und habe zu schnell getestet.

Prima, welche Variante hat denn funktioniert?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 14 März 2024, 20:21:07
Bin gerade an der v4 Beta 6 des Images. Bei mir schlägt der Healthcheck fehl. Ich musste ihn deaktivieren, dann gibt es keine Probleme. Ich vermute, dass das mit der Telnet-Deaktivierung zusammenhängt.

Weiterhin fiel mir auf, dass ein
- PIDFILE=/run/lock/fhem.pid

Im compose-file auf run/lock/fhem.pid geändert wird. Das ist natürlich nicht Sinn und Zweck.
Eigentlich gehört das PID-file dort auch standardmäßig hin. Gibt es einen Grund, warum das in das log-Verzeichnis geschrieben werden soll?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 14 März 2024, 21:20:52
Zitat von: volschin am 14 März 2024, 20:21:07Bin gerade an der v4 Beta 6 des Images. Bei mir schlägt der Healthcheck fehl.

Kannst Du es noch mal mit dem TAG dev-bullseye probieren?

ghcr.io/fhem/fhem-docker:dev-bullseye
Wenn der Fehler dann immer noch existiert, würden mir mehr Details zu deiner FHEMWEB Konfiguration helfen.

Zitat von: volschin am 14 März 2024, 20:21:07Weiterhin fiel mir auf, dass ein
- PIDFILE=/run/lock/fhem.pid

Im compose-file auf run/lock/fhem.pid geändert wird. Das ist natürlich nicht Sinn und Zweck.

In welchem Compose File meinst Du?
Oder meinst Du entry.sh ?
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: volschin am 15 März 2024, 08:36:59
Zitat von: Sidey am 14 März 2024, 21:20:52Kannst Du es noch mal mit dem TAG dev-bullseye probieren?

ghcr.io/fhem/fhem-docker:dev-bullseye
Wenn der Fehler dann immer noch existiert, würden mir mehr Details zu deiner FHEMWEB Konfiguration helfen.
Das behebt das Problem.

Zitat von: volschin am 14 März 2024, 20:21:07Weiterhin fiel mir auf, dass ein
- PIDFILE=/run/lock/fhem.pid

Im compose-file auf run/lock/fhem.pid geändert wird. Das ist natürlich nicht Sinn und Zweck.

In welchem Compose File meinst Du?
Oder meinst Du entry.sh ?
[/quote]
In meinem docker-compose.yaml. In der Readme ist ja beschrieben, dass man den Pfad über environment setzen kann. In FHEM taucht dann stattdessen das run/lock/fhem.id auf, also ohne den führenden / für Root.
Titel: Aw: Offizielles FHEM Docker Basis Image für verschiedene Plattformen
Beitrag von: Sidey am 16 März 2024, 11:18:29
Zitat von: volschin am 15 März 2024, 08:36:59In meinem docker-compose.yaml. In der Readme ist ja beschrieben, dass man den Pfad über environment setzen kann. In FHEM taucht dann stattdessen das run/lock/fhem.id auf, also ohne den führenden / für Root.

Habe ich verstanden, ich bevorzuge es, die Themen zur beta Version hier zu diskutieren, dort dann auch mehr zu dem Pidfile Problem, welches ich noch nicht in Gänze gelöst habe:
https://forum.fhem.de/index.php?topic=137309.new#new