Offizielles FHEM Docker Basis Image für verschiedene Plattformen

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

Vorheriges Thema - Nächstes Thema

toensi

#1920
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ß

Sidey

Es liegt ganz sicher an der Reihenfolge der Includes.

Wenn Du alles in die FHEM.cfg überführst hast Du das Problem nicht.

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Gear

@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
> ODroid H3 => OMV => Docker => FHEM <
Fritz!Box 7590, Fritz!Repeater 6000, MQTT, RaspberryMatic, Zigbee2MQTT, ESP32, ESP8266, Shelly, Grafana ...
> 3D-Druck <

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Gear

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
> ODroid H3 => OMV => Docker => FHEM <
Fritz!Box 7590, Fritz!Repeater 6000, MQTT, RaspberryMatic, Zigbee2MQTT, ESP32, ESP8266, Shelly, Grafana ...
> 3D-Druck <

globus243

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.

Sidey

@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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

globus243

#1927
@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 beschrieben?

Sidey

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 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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

globus243

#1929
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 hats dann klick gemacht das ich den oberen teil im bsp gar nicht zwingend brauche usw. eventuell könnte man hier 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?

Sidey

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"
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Wernieman

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?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

globus243

#1932
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"
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

MadMax-FHEM

Eventuell in der UniqueID Datei?

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

globus243

#1934
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!