Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[Wernieman]

War das jetzt "normales docker" oder Synology?

[persching]

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.

[Wernieman]

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

[persching]

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

[volschin]

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?

[kadettilac89]

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.

[volschin]

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

[volschin]

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.

[volschin]

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.

[persching]

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:

Code Auswählen Erweitern

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

und meine restlichen Probleme haben sich erledigt nachdem ich ein

Code Auswählen Erweitern

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

[MCh76]

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

Code Auswählen Erweitern

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

[guhu]

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.

[Loredo]

Ich würde sagen sowohl das Docker Log und auch die FHEM Logdatei sind die ersten Anlaufpunkte das weiter zu analysieren.
Ersteres geht prima über portainer.io.

[balli1187]

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

Code Auswählen Erweitern

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

[Loredo]

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.