Ich habe vor einigen Tagen den Build Prozess für das Docker Image überarbeitet, damit eine aktuellere Version von Perl bereitgestellt wird (5.36.3) anstelle von 5.32.
Neu ist auch, dass die nötigen CPAN Module vor dem erstellen des Images gesucht und installiert werden.
Wer würde das Image testen und Feedback geben?
Stand 29.04.2024:
ghcr.io/fhem/fhem-docker:4.0.0-beta10-bullseye
Die Releasenotes finden sich hier:
https://github.com/fhem/fhem-docker/releases
Hallo Sidey,
ich kann gerne Anfang nächster Woche testen.
Viele Grüße
Jürgen
Hallo Sidey,
ich habes mal auf einem "odroid m1s" installiert. Node-Updater zeigt eine neue Version von npm (10.5.0) an, geht aber nicht da node-Version nicht kompatibel (ist = 16.20.0, soll größer 18.27.0, aktuellste Version 21.6.2 bzw 20.11.1 LTS).
Teste mal weiter
mfg Jens
Danke,
Ich habe heute noch ein neues Image erstellt, da das alte mit dem neuen DoorBird Modul nicht funktioniert.
ghcr.io/fhem/fhem-docker:4.0.0-beta2-bullseye
An der NodeJS Version hat sich nichts geändert.
Bis jetzt keine Fehler gefunden :-)
mfg anton
Hallo Sidey,
es sieht gut aus. Mir sind keine Besonderheiten aufgefallen.
Viele Grüße
Jürgen
Version2 geht bei mir mit dblog - Version 5 nicht. Ich verwende Mariasql in einem eigenen Container
gruß anton
Zitat von: antonwinden am 07 März 2024, 08:52:30Version2 geht bei mir mit dblog - Version 5 nicht. Ich verwende Mariasql in einem eigenen Container
gruß anton
Danke, das Problem ist bereits erkannt und in Bearbeitung.
Ich warte im Moment auf eine Anpassung im DBLog Modul:
https://forum.fhem.de/index.php?topic=137375.new#new
Ich habe das beta5 Image noch mal neu erzeugt. Es ist nun auch wieder der MYSQL Datenbanktreiber installiert, damit klappts dann auch mit der Maria DB.
Hallo Sidey,
nachdem ich nun fast alles getestet habe, ist mir folgendes (für mich große) Problem aufgefallen.
"Das Sonos-Modul kann nicht geladen werden. Fehlermeldung Cannot load module SONOS"
Viele Grüße
Jürgen
Zitat von: juemuc am 09 März 2024, 21:31:19"Das Sonos-Modul kann nicht geladen werden. Fehlermeldung Cannot load module SONOS"
Auch mit beta5?
Stehen im Log eventuell noch ein paar Infos mehr?
Grüße Sidey
Hallo Sidey,
ja ich nutze schon die Beta5.
Hier die Infos aus dem log:
2024.03.09 21:47:15.841 1: reload: Error:Modul 00_SONOS deactivated:
This Perl not built to support threads
Compilation failed in require at ./FHEM/00_SONOS.pm line 137.
BEGIN failed--compilation aborted at ./FHEM/00_SONOS.pm line 137.
2024.03.09 21:47:15.841 0: This Perl not built to support threads
Compilation failed in require at ./FHEM/00_SONOS.pm line 137.
BEGIN failed--compilation aborted at ./FHEM/00_SONOS.pm line 137.
Viele Grüße
Jürgen
Hallo Sidey,
für die Sonos-Installation habe ich mir noch folgende Info notiert:
Zusatzpaket für Sonos-Speak:
sudo mkdir /mnt/SonosSpeak
sudo apt-get install samba samba-common-bin
smb.conf am Ende erweitern:
sudo nano /etc/samba/smb.conf
[SonosSpeak]
read only = false
path = /mnt/SonosSpeak
guest ok = yes
sudo systemctl restart samba
sudo chmod 777 /mnt/SonosSpeak
Wie muss ich das in der Docker-Version umsetzen?
Viele Grüße
Jürgen
Zitat von: juemuc am 09 März 2024, 21:48:43Hier die Infos aus dem log:
2024.03.09 21:47:15.841 1: reload: Error:Modul 00_SONOS deactivated:
This Perl not built to support threads
Ui, das ging aber noch nie im fhem Docker Container.
Den Hinweis zu den Threads im Wiki habe ich für einen Scherz gehalten.
Nunja, dafür werde ich ein separates Image bauen, was kein großes Problem ist.
Bezüglich deiner Samba Frage, würde ich dafür einen weiteren Container einrichten.
Sowas hier:
https://github.com/crazy-max/docker-samba
[/code]
[/quote]
Hallo Sidey,
bei mir wird der Inhalt des Logfile nicht angezeigt, muss ich noch Rechte oder so anpassen?
vG Jens
Ist bei mir auch so. Ich schauer mir das logfile dann im Portainer an. Die Anzeige über FHEM wäre natürlich schöner.
Viele Grüße
Jürgen
Zitat von: juemuc am 09 März 2024, 21:48:43Hallo Sidey,
ja ich nutze schon die Beta5.
So für Dich, Beta6 mit threaded Support:
ghcr.io/fhem/fhem-docker:4.0.0-beta6-threaded-bullseye
Zitat von: Newbie am 10 März 2024, 11:01:24Hallo Sidey,
bei mir wird der Inhalt des Logfile nicht angezeigt, muss ich noch Rechte oder so anpassen?
Hast Du was im Bereich Logging eingestellt.
Interessant wären die Einstellungen von Global und ggf. dem filelog.
Grüße Sidey
Zitat von: Sidey am 10 März 2024, 11:53:31Zitat von: juemuc am 09 März 2024, 21:48:43Hallo Sidey,
ja ich nutze schon die Beta5.
So für Dich, Beta6 mit threaded Support:
ghcr.io/fhem/fhem-docker:4.0.0-beta6-threaded-bullseye
Vielen Dank. Sonos-Devices werden angelegt.
Viele Grüße
Jürgen
Hallo Sidey,
in dieser Version fehlt leider "alexa".
"stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'."
Viele Grüße
Jürgen
Zitat von: juemuc am 10 März 2024, 14:39:34in dieser Version fehlt leider "alexa".
Das fehlt nicht, für Alexa gibt es einen eigenes Docker Image.
-> https://github.com/fhem/alexa-fhem-docker
Was die Fehlermeldung angeht, da kann ich nichts machen, das müsste im Alexa Moduls angepasst werden.
Grüße Sidey
Ah ok. Danke für die Info. Ich dachte, dass Alexa mit der Beta5 funktioniert hätte.
Jetzt muss ich mir das erst einmal ansehen.
Viele Grüße
Jürgen
Zitat von: juemuc am 10 März 2024, 16:57:34Ah ok. Danke für die Info. Ich dachte, dass Alexa mit der Beta5 funktioniert hätte.
Nein, das wurde schon in Version 3 des Images ausgebaut.
Hallo Sidey,
ZitatInteressant wären die Einstellungen von Global und ggf. dem filelog.
hatte da keine Änderungen an deinen Einstellungen vorgenommen. Die stimmten aber nicht überein
global = log/fhem-%Y-%m-%d.log
filelog= ./log/fhem-%Y-%m.log Logfilefilelog auf ./log/fhem-%Y-%m-%d.log geändert und schon funtioniert es
vG Jens
P.S.: für Homematic muss RPC::XML::Client händisch nachinstalliert werden
Zitat von: Newbie am 10 März 2024, 19:41:54hatte da keine Änderungen an deinen Einstellungen vorgenommen. Die stimmten aber nicht überein
global = log/fhem-%Y-%m-%d.log
filelog= ./log/fhem-%Y-%m.log Logfile
Ab der Nächsten Version:
Wenn der Container ohne ein FHEM im Volume geladen wird, dann legt er ein neues FHEM ab und wird in Zukunft auch das Logdevice patchen.
An bestehenden Installation muss der Nutzer es selbst anpassen (so wie bei dir).
Zitat von: Newbie am 10 März 2024, 19:41:54für Homematic muss RPC::XML::Client händisch nachinstalliert werden
Welches Modul genau braucht es, dann schau ich nach woran es liegt.
Zitat von: Newbie am 10 März 2024, 19:41:54P.S.: für Homematic muss RPC::XML::Client händisch nachinstalliert werden
Ich hab eben nachgeforscht, in dem Beta6 Image, sowohl mit threaded perl als auch normal ist der Client installiert:
cpanm RPC::XML::Client
RPC::XML::Client is up to date. (1.44)
Hallo Sidey,
kann ich nicht bestätigen.
Zitatimage.version 4.0.0-beta6-bullseye 2024-03-10 21:41:25
2024.03.10 21:44:39.096 0: Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: ./lib ./FHEM . /usr/local/lib/perl5/site_perl/5.36.3/aarch64-linux-gnu /usr/local/lib/perl5/site_perl/5.36.3 /usr/local/lib/perl5/vendor_perl/5.36.3/aarch64-linux-gnu /usr/local/lib/perl5/vendor_perl/5.36.3 /usr/local/lib/perl5/5.36.3/aarch64-linux-gnu /usr/local/lib/perl5/5.36.3 ./FHEM/lib) at ./FHEM/88_HMCCU.pm line 36.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 36.
vG Jens
PS:in der Container-Console:
root@9f4e077007ff:/opt/fhem# sudo cpanm RPC::XML::Client
--> Working on RPC::XML::Client
Fetching http://www.cpan.org/authors/id/R/RJ/RJRAY/RPC-XML-0.82.tar.gz ... OK
Configuring RPC-XML-0.82 ... OK
==> Found dependencies: XML::Parser, HTTP::Daemon, HTTP::Message, LWP
--> Working on XML::Parser
Fetching http://www.cpan.org/authors/id/T/TO/TODDR/XML-Parser-2.47.tar.gz ... OK
Configuring XML-Parser-2.47 ... OK
==> Found dependencies: LWP::UserAgent
--> Working on LWP::UserAgent
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/libwww-perl-6.76.tar.gz ... OK
Configuring libwww-perl-6.76 ... OK
==> Found dependencies: HTTP::Request, URI::Escape, HTTP::Cookies, HTTP::Request::Common, HTTP::CookieJar::LWP, HTTP::Date, LWP::MediaTypes, HTML::HeadParser, Try::Tiny, HTML::Entities, Test::RequiresInternet, Test::Needs, HTTP::Response, URI, Test::Fatal, HTTP::Status, HTTP::Daemon, Net::HTTP, WWW::RobotRules, File::Listing, Encode::Locale, HTTP::Negotiate
--> Working on HTTP::Request
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/HTTP-Message-6.45.tar.gz ... OK
Configuring HTTP-Message-6.45 ... OK
==> Found dependencies: LWP::MediaTypes, HTTP::Date, Try::Tiny, URI::URL, Clone, IO::HTML, Encode::Locale, Test::Needs, URI
--> Working on LWP::MediaTypes
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/LWP-MediaTypes-6.04.tar.gz ... OK
Configuring LWP-MediaTypes-6.04 ... OK
==> Found dependencies: Test::Fatal
--> Working on Test::Fatal
Fetching http://www.cpan.org/authors/id/R/RJ/RJBS/Test-Fatal-0.017.tar.gz ... OK
Configuring Test-Fatal-0.017 ... OK
==> Found dependencies: Try::Tiny
--> Working on Try::Tiny
Fetching http://www.cpan.org/authors/id/E/ET/ETHER/Try-Tiny-0.31.tar.gz ... OK
Configuring Try-Tiny-0.31 ... OK
Building and testing Try-Tiny-0.31 ... OK
Successfully installed Try-Tiny-0.31
Building and testing Test-Fatal-0.017 ... OK
Successfully installed Test-Fatal-0.017
Building and testing LWP-MediaTypes-6.04 ... OK
Successfully installed LWP-MediaTypes-6.04
--> Working on HTTP::Date
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/HTTP-Date-6.06.tar.gz ... OK
Configuring HTTP-Date-6.06 ... OK
==> Found dependencies: Time::Zone
--> Working on Time::Zone
Fetching http://www.cpan.org/authors/id/A/AT/ATOOMIC/TimeDate-2.33.tar.gz ... OK
Configuring TimeDate-2.33 ... OK
Building and testing TimeDate-2.33 ... OK
Successfully installed TimeDate-2.33
Building and testing HTTP-Date-6.06 ... OK
Successfully installed HTTP-Date-6.06
--> Working on URI::URL
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/URI-5.27.tar.gz ... OK
Configuring URI-5.27 ... OK
==> Found dependencies: Test::Needs, Test::Warnings
--> Working on Test::Needs
Fetching http://www.cpan.org/authors/id/H/HA/HAARG/Test-Needs-0.002010.tar.gz ... OK
Configuring Test-Needs-0.002010 ... OK
Building and testing Test-Needs-0.002010 ... OK
Successfully installed Test-Needs-0.002010
--> Working on Test::Warnings
Fetching http://www.cpan.org/authors/id/E/ET/ETHER/Test-Warnings-0.033.tar.gz ... OK
Configuring Test-Warnings-0.033 ... OK
Building and testing Test-Warnings-0.033 ... OK
Successfully installed Test-Warnings-0.033
Building and testing URI-5.27 ... OK
Successfully installed URI-5.27
--> Working on Clone
Fetching http://www.cpan.org/authors/id/G/GA/GARU/Clone-0.46.tar.gz ... OK
Configuring Clone-0.46 ... OK
==> Found dependencies: B::COW
--> Working on B::COW
Fetching http://www.cpan.org/authors/id/A/AT/ATOOMIC/B-COW-0.007.tar.gz ... OK
Configuring B-COW-0.007 ... OK
Building and testing B-COW-0.007 ... OK
Successfully installed B-COW-0.007
Building and testing Clone-0.46 ... OK
Successfully installed Clone-0.46
--> Working on IO::HTML
Fetching http://www.cpan.org/authors/id/C/CJ/CJM/IO-HTML-1.004.tar.gz ... OK
Configuring IO-HTML-1.004 ... OK
Building and testing IO-HTML-1.004 ... OK
Successfully installed IO-HTML-1.004
--> Working on Encode::Locale
Fetching http://www.cpan.org/authors/id/G/GA/GAAS/Encode-Locale-1.05.tar.gz ... OK
Configuring Encode-Locale-1.05 ... OK
Building and testing Encode-Locale-1.05 ... OK
Successfully installed Encode-Locale-1.05
Building and testing HTTP-Message-6.45 ... OK
Successfully installed HTTP-Message-6.45
--> Working on HTTP::Cookies
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/HTTP-Cookies-6.11.tar.gz ... OK
Configuring HTTP-Cookies-6.11 ... OK
Building and testing HTTP-Cookies-6.11 ... OK
Successfully installed HTTP-Cookies-6.11
--> Working on HTTP::CookieJar::LWP
Fetching http://www.cpan.org/authors/id/D/DA/DAGOLDEN/HTTP-CookieJar-0.014.tar.gz ... OK
Configuring HTTP-CookieJar-0.014 ... OK
==> Found dependencies: Test::Requires, Test::Deep
--> Working on Test::Requires
Fetching http://www.cpan.org/authors/id/T/TO/TOKUHIROM/Test-Requires-0.11.tar.gz ... OK
Configuring Test-Requires-0.11 ... OK
Building and testing Test-Requires-0.11 ... OK
Successfully installed Test-Requires-0.11
--> Working on Test::Deep
Fetching http://www.cpan.org/authors/id/R/RJ/RJBS/Test-Deep-1.204.tar.gz ... OK
Configuring Test-Deep-1.204 ... OK
Building and testing Test-Deep-1.204 ... OK
Successfully installed Test-Deep-1.204
Building and testing HTTP-CookieJar-0.014 ... OK
Successfully installed HTTP-CookieJar-0.014
--> Working on HTML::HeadParser
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/HTML-Parser-3.81.tar.gz ... OK
Configuring HTML-Parser-3.81 ... OK
==> Found dependencies: HTML::Tagset
--> Working on HTML::Tagset
Fetching http://www.cpan.org/authors/id/P/PE/PETDANCE/HTML-Tagset-3.22.tar.gz ... OK
Configuring HTML-Tagset-3.22 ... OK
Building and testing HTML-Tagset-3.22 ... OK
Successfully installed HTML-Tagset-3.22
Building and testing HTML-Parser-3.81 ... OK
Successfully installed HTML-Parser-3.81
--> Working on Test::RequiresInternet
Fetching http://www.cpan.org/authors/id/M/MA/MALLEN/Test-RequiresInternet-0.05.tar.gz ... OK
Configuring Test-RequiresInternet-0.05 ... OK
Building and testing Test-RequiresInternet-0.05 ... OK
Successfully installed Test-RequiresInternet-0.05
--> Working on HTTP::Daemon
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/HTTP-Daemon-6.16.tar.gz ... OK
==> Found dependencies: Module::Build::Tiny
--> Working on Module::Build::Tiny
Fetching http://www.cpan.org/authors/id/L/LE/LEONT/Module-Build-Tiny-0.047.tar.gz ... OK
==> Found dependencies: ExtUtils::InstallPaths, ExtUtils::Helpers, ExtUtils::Config
--> Working on ExtUtils::InstallPaths
Fetching http://www.cpan.org/authors/id/L/LE/LEONT/ExtUtils-InstallPaths-0.012.tar.gz ... OK
Configuring ExtUtils-InstallPaths-0.012 ... OK
==> Found dependencies: ExtUtils::Config
--> Working on ExtUtils::Config
Fetching http://www.cpan.org/authors/id/L/LE/LEONT/ExtUtils-Config-0.008.tar.gz ... OK
Configuring ExtUtils-Config-0.008 ... OK
Building and testing ExtUtils-Config-0.008 ... OK
Successfully installed ExtUtils-Config-0.008
Building and testing ExtUtils-InstallPaths-0.012 ... OK
Successfully installed ExtUtils-InstallPaths-0.012
--> Working on ExtUtils::Helpers
Fetching http://www.cpan.org/authors/id/L/LE/LEONT/ExtUtils-Helpers-0.026.tar.gz ... OK
Configuring ExtUtils-Helpers-0.026 ... OK
Building and testing ExtUtils-Helpers-0.026 ... OK
Successfully installed ExtUtils-Helpers-0.026
Configuring Module-Build-Tiny-0.047 ... OK
Building and testing Module-Build-Tiny-0.047 ... OK
Successfully installed Module-Build-Tiny-0.047
Configuring HTTP-Daemon-6.16 ... OK
Building and testing HTTP-Daemon-6.16 ... OK
Successfully installed HTTP-Daemon-6.16
--> Working on Net::HTTP
Fetching http://www.cpan.org/authors/id/O/OA/OALDERS/Net-HTTP-6.23.tar.gz ... OK
Configuring Net-HTTP-6.23 ... OK
Building and testing Net-HTTP-6.23 ... OK
Successfully installed Net-HTTP-6.23
--> Working on WWW::RobotRules
Fetching http://www.cpan.org/authors/id/G/GA/GAAS/WWW-RobotRules-6.02.tar.gz ... OK
Configuring WWW-RobotRules-6.02 ... OK
Building and testing WWW-RobotRules-6.02 ... OK
Successfully installed WWW-RobotRules-6.02
--> Working on File::Listing
Fetching http://www.cpan.org/authors/id/P/PL/PLICEASE/File-Listing-6.16.tar.gz ... OK
Configuring File-Listing-6.16 ... OK
Building and testing File-Listing-6.16 ... OK
Successfully installed File-Listing-6.16
--> Working on HTTP::Negotiate
Fetching http://www.cpan.org/authors/id/G/GA/GAAS/HTTP-Negotiate-6.01.tar.gz ... OK
Configuring HTTP-Negotiate-6.01 ... OK
Building and testing HTTP-Negotiate-6.01 ... OK
Successfully installed HTTP-Negotiate-6.01
Building and testing libwww-perl-6.76 ... OK
Successfully installed libwww-perl-6.76
Building and testing XML-Parser-2.47 ... OK
Successfully installed XML-Parser-2.47
Building and testing RPC-XML-0.82 ... OK
Successfully installed RPC-XML-0.82
32 distributions installed
root@9f4e077007ff:/opt/fhem# sudo cpanm RPC::XML::Client
RPC::XML::Client is up to date. (1.44)
root@9f4e077007ff:/opt/fhem# P.S.: P.S.: Test mit Laptop okay, auf dem "odroid M1S" fehlt die Datei
Hallo zusammen,
bei mir läuft die HMCCU ohne Probleme.
Viele Grüße
Jürgen
@all Danke für die Rückmeldungen, das ist sehr hilfreich.
Zitat von: juemuc am 10 März 2024, 22:12:00bei mir läuft die HMCCU ohne Probleme.
Du nutzt bestimmt das AMD64 Image, da sind die Abhängigkeiten installiert.
Im ARM64 und ARMv7, dagegen fehlen sie aufgrund eines oder zweier Fehler..
Hallo Sidey,
ich habe jetzt alexa-fhem als zweite Docker-Instanz am laufen. Mir ist jetzt nur nicht klar, wie ich die Verbindung herstelle, da ja der alexa-Connektor alles automatisch macht. Konkret geht es um folgende Punkte:
1. Im FHEM-Docker habe ich im alexa-Device "alexaFHEM-host" definiert. Ist erledigt.
2. In der Datei config.json müssen folgende Infos hinterlegt werden:
"keyFile": "/certs/alexa-fhem.key",
"certFile": "/certs/alexa-fhem.crt",Ich habe die beiden Dateien aus dem FHEM-Docker-Verzeichnis in das certs-Verzeichnis von alexa-fhem kopiert
3. Es müssen diese Daten ergänt werden:
"applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
"oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"Bei applicationID habe ich die xx durch den proxyKey ersetzt. Aber woher bekomme ich die oauthClientID? Ist der Rest korrekt?
Viele Grüße
Jürgen
Zitat von: juemuc am 11 März 2024, 15:53:36Hallo Sidey,
ich habe jetzt alexa-fhem als zweite Docker-Instanz am laufen. Mir ist jetzt nur nicht klar, wie ich die Verbindung herstelle, da ja der alexa-Connektor alles automatisch macht. Konkret geht es um folgende Punkte:
1. Im FHEM-Docker habe ich im alexa-Device "alexaFHEM-host" definiert. Ist erledigt.
2. In der Datei config.json müssen folgende Infos hinterlegt werden:
"keyFile": "/certs/alexa-fhem.key",
"certFile": "/certs/alexa-fhem.crt",Ich habe die beiden Dateien aus dem FHEM-Docker-Verzeichnis in das certs-Verzeichnis von alexa-fhem kopiert
3. Es müssen diese Daten ergänt werden:
"applicationId": "amzn1.ask.skill.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX",
"oauthClientID": "amzn1.application-oa2-client.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"Bei applicationID habe ich die xx durch den proxyKey ersetzt. Aber woher bekomme ich die oauthClientID? Ist der Rest korrekt?
Viele Grüße
Jürgen
Die Verbindung funktioniert ausschließlich von alexa-fhem -> fhem.
1. kein keyFile, kein certFile. Das Key file kopiert man auch nie irgendwo hin, es ist ein privater Schlüssel.
Wie in der Anleitung (https://github.com/fhem/alexa-fhem-docker/blob/dev/README.md#use-docker-composeyaml)angegeben ist nur in ./alexa-fhem/alexa-fhem.json der Servername und Port für einer FHEMWEB Instanz anzupassen.
Beide Container müssen sich dafür natürlich im gleichen Netzwerk befinden, sonst klappt die Kommunikation nicht.
Hallo Sidey,
Es funktioniert leider noch nicht. Ich erhalte folgende Meldungen:
Alexa-logfile:
"Unknown cipher type '/tmp/alexa-fhem.cfg'"
Fhem-Logfile:
ssh: connect to host alexa-fhem port 22: Connection refused
ssh: connect to host alexa-fhem port 22: Connection refused
2024.03.11 18:55:13.354 2: MyAlexa: starting alexa-fhem: /usr/bin/ssh alexa-fhem -c /tmp/alexa-fhem.cfg -a :hl␜Iw3␙B(M19b9 -s
Was mache ich falsch?
Viele Grüße
Jürgen
Zitat von: juemuc am 11 März 2024, 18:58:43Hallo Sidey,
Es funktioniert leider noch nicht. Ich erhalte folgende Meldungen:
Alexa-logfile:
"Unknown cipher type '/tmp/alexa-fhem.cfg'"
Steht das im alexa-fhem Container?
Das Attribut Alexa-host kannst Du löschen, es ist nicht notwendig.
Nein, das ist beides im FHEM-Container.
Wenn ich das Attribut Alexa-host lösche, kommt im Alexa-Device sofort
alexaFHEM stopped; alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'. 2024-03-11 20:23:27
Ausserdem gibt es in dem Verzeichnis ./alexa-fhem/ nur eine config.json. Wenn ich hier ssl nicht auf true setze, versucht er fhem mit http zu connecten, was natürlich nicht geht. Wenn ssl auf true steht, benötigt er die "key-/ und cert-Datei"
Viele Grüße
Jürgen
Hallo Sidey,
ich bin nun einen Schritt weiter. Ich wusste, dass FHEM mit Alexa mit einer Beta funktioniert hatte. Man muss nur bei den NODE.JS-Packages auch "alexa-fhem" installieren. Es wird also der separate Container nicht benötigt. Mit meiner kleinen Test-Instalation ohne https und allowed funktioniert es auch. In der normalen Umgebung kommt die Fehlermeldung "stopped; failed to connect to fhem: 401: Authorization Required"
UNd dies kann gelöst werden, wenn in der Datei alexa-fhem.cfg die Zeile "auth": {"user": "USER", "pass": "PASSWORD"},
eingefügt wird. Jetzt läuft es ;D
Vielen Dank für Deine Unterstützung.
Viele Grüße
Jürgen
Zitat von: juemuc am 11 März 2024, 22:02:37ich bin nun einen Schritt weiter. Ich wusste, dass FHEM mit Alexa mit einer Beta funktioniert hatte. Man muss nur bei den NODE.JS-Packages auch "alexa-fhem" installieren.
Als Lösung würde ich das nicht bezeichnen, denn in einem docker Container installiert man nichts nach.
Zitat von: juemuc am 11 März 2024, 22:02:37Es wird also der separate Container nicht benötigt.
Glaub mir, sobald Du im FHEM Container nichts mehr installieren kannst, oder kein nodejs mehr darin installiert ist, brauchst Du den separaten Container, der imho auch auf deutlich aktuellerem NodeJS läuft, weil das viel einfacher zu maintainen ist.
Hallo Sidey,
ok. Danke für die Info. Dann werde ich morgen mit dem separaten Container weiter testen. Habe ja jetzt Übung im Container erstellen O:-). Werde bestimmt noch mit weiteren Fragen kommen.
AKtuell habe ich zum Beispiel im "Docker Image Info" ein rotes Dreieck mit Ausrufezeichen. Ich weiß aber nicht warum. Wie finde ich das heraus?
Viele Grüße
Jürgen
Zitat von: juemuc am 11 März 2024, 22:15:54AKtuell habe ich zum Beispiel im "Docker Image Info" ein rotes Dreieck mit Ausrufezeichen. Ich weiß aber nicht warum. Wie finde ich das heraus?
Schau mal, ob das Attribut "devStateIcon" wie folgt gesetzt ist:
ok.*:security@green Initialized:system_fhem_reboot@orange .*:message_attention@redAnsonsten, könnte es auch sein, dass der Health Check nicht funktioniert. Das sollte im Log stehen.
Hallo sidey,
das passt alles. Der Container steht auf unhealthy. Ich finde aber die Ursache nicht. Hängt eventuell noch mit meinen "Alexa-Tests" zusammen.
Ich versuche die ganze Zeit mit "docker pull ghcr.io/fhem/fhem/alexa-fhem:v5.0.9" die aktuellste Version zu ziehen. Das fuktioniert aber nicht. Es kommt die Meldung "Error response from daemon: manifest unknown". Nur latest funktioniert. Die Version ist aber älter.
Viele Grüße
Jürgen
Zitat von: juemuc am 11 März 2024, 22:46:05Hallo sidey,
das passt alles. Der Container steht auf unhealthy. Ich finde aber die Ursache nicht. Hängt eventuell noch mit meinen "Alexa-Tests" zusammen.
Das liegt vermutlich daran, dass es keine
Zitat von: juemuc am 11 März 2024, 22:46:05Ich versuche die ganze Zeit mit "docker pull ghcr.io/fhem/fhem/alexa-fhem:v5.0.9" die aktuellste Version zu ziehen. Das fuktioniert aber nicht. Es kommt die Meldung "Error response from daemon: manifest unknown". Nur latest funktioniert. Die Version ist aber älter.
Ein fhem zu viel im Pfad.
Da habe ich die Readme wohl vergessen anzupassen.
ghcr.io/fhem/alexa-fhem:5.0.9
Hallo Sidey,
ich habe nun herausgefunden, dass der Container auf unhealthy geht, wenn ich in FHEM https aktiviere. Kann man das ändern? Ich habe hierzu einer neuen FHEM-Instanz nur das HTTPS-Attribut gesetzt. Sollte somit leicht reproduzierbar sein.
Viele Grüße
Jürgen.
Hallo Sidey,
jetzt habe ich alexa-fhem (5.0.9) und fhem (Beta6) getestet. In fhem habe ich nur die updates durchgeführt. alexa-fhem hat in fhem das Device alexa automatisch angelegt. Allerdings muss man noch das Attribut "alexaFHEM-host" noch anlegen, sonst kommt die "node-Fehlermeldung". Nach setzten des Attributes wird trotzdem die Verbindung nnicht aufgebaut. Ich erhalte folgende Fehlermeldungen in FHEM:
fhem-log:
2024.03.12 11:52:30.006 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
2024.03.12 11:52:30.026 2: alexa: starting alexa-fhem: /usr/bin/ssh alexa-fhem -c /tmp/alexa-fhem.cfg
2024.03.12 11:52:30.028 3: alexa: starting
2024.03.12 11:52:30.032 3: alexa: using logfile: ./log/alexa-2024-03-12.log
2024.03.12 11:52:30.037 3: alexa: read: end of file reached while sysread
2024.03.12 11:52:30.037 3: alexa: stopped
Alexa-log:
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'
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'
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'
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'
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'
Unknown cipher type '/tmp/alexa-fhem.cfg'
Unknown cipher type '/tmp/alexa-fhem.cfg'
Ich teste jetzt noch einmal mit alexa-fhem:latest
Viele Grüße
Jürgen
Zitat von: juemuc am 12 März 2024, 10:59:44ich habe nun herausgefunden, dass der Container auf unhealthy geht, wenn ich in FHEM https aktiviere. Kann man das ändern? Ich habe hierzu einer neuen FHEM-Instanz nur das HTTPS-Attribut gesetzt. Sollte somit leicht reproduzierbar sein.
Grundsätzlich kann der Healthcheck auch HTTPS. Gerade noch mal getestet :)
Ich habe folgendes Gerät zusätzlich definiert:
defmod WEBS FHEMWEB 8084 global
attr WEBS userattr DockerHealthCheck:0,1
attr WEBS DockerHealthCheck 1
attr WEBS HTTPS 1
Dann wird der Healthcheck Zusätzlich auch über Port 8084 ausgeführt und beide Ports können überwacht werden.
Du hast vermutlich etwas anders gemacht
Der Fehler
Zitat von: juemuc am 12 März 2024, 11:59:07Unknown cipher type '/tmp/alexa-fhem.cfg'
liegt hier dran:
Zitat von: juemuc am 12 März 2024, 11:59:072024.03.12 11:52:30.026 2: alexa: starting alexa-fhem: /usr/bin/ssh alexa-fhem -c /tmp/alexa-fhem.cfg
Aus irgendeinem Grund ruft alexa-fhem die ssh binary auf (/usr/bin/ssh) und versucht da das Argument -c zu setzen, was bei SSH die cipher-specification ist (https://linux.die.net/man/1/ssh), deshalb auch die die Fehlermeldung unkown cipher type.
Keine Ahnung wieso das passiert. Irgendwas scheint bei dir ganz grundlegend falsch zu sein. Am besten du löscht mal in FHEM dein alexa device und startest dann den alexa-fhem Container neu. Dann sollte das alexa-device in FHEM automatisch neu angelegt werden und alles sollte funktionieren.
Wenn es dann immer noch nicht funktioniert ist vermutlich etwas im alexa-fhem-Container nicht richtig konfiguriert.
Falls das der Fall sein sollte:
Es reicht, im compose file ein
volumes:
- ./alexa-fhem:/alexa-fhemeinzufügen und dann in das Verzeichnis deine config.json reinzulegen. Dann in FHEM nochmal das alexa-device löschen und dann den Container neustarten. Alles müsste dann automatisch passieren. Wobei, vermutlich musst du dann noch in der Alexa-App den Skill neu verknüpfen.
Hier mal meine config.json, wo du (vermutlich) nur die Einträge in <> ersetzen musst.
Falls du dir wegen des Hostnames unsicher bist, folgender Befehl gibt dir den aus:
sudo docker inspect <NAME DES FHEM CONTAINERS> | grep --after 3 DNSNamesconfig.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=..*",
"auth": {"user": "<FHEM-USER>", "pass": "<FHEM-PASSWORT>"},
"uid": "6062",
"port": "8083",
"server": "<HOSTNAME DES FHEM CONTAINERS>"
}
]
}
Hallo Sidey,
ich weiß nicht, was ich jetzt anders gemacht habe, aber aktuell ist alles "grün". Jetzt muss ich das Thema "Alexa" angehen.
Viele Grüße
Jürgen
Hallo zusammen,
ich habe nun fhem ohne https neu installiert. Danach habe ich Alexa-fhem neu eingerichtet. In der config.json habe ich nur die IP-Adresse von FHEM eingetragen. Es wird auch die Verbindung hergestellt und das Alexa-Device wird angelegt. Es stehen folgende Zeilen im log-file:
2024.03.14 19:18:11.916 2: alexa: created default configfile: ./alexa-fhem.cfg
2024.03.14 19:18:11.924 2: alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
2024.03.14 19:18:11.933 2: alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
Wenn ich jetzt im Alexa-Device den AlexaFHEM-host eintrage, kommen wieder die altbekannten Meldungen:
Unknown cipher type '/tmp/alexa-fhem.cfg'
Unknown cipher type '/tmp/alexa-fhem.cfg'
2024.03.14 19:25:52.011 3: alexa: using ssh cmd /usr/bin/ssh 192.168.110.101
ssh: connect to host 192.168.110.101 port 22: Connection refused
ssh: connect to host 192.168.110.101 port 22: Connection refused
2024.03.14 19:25:52.034 2: alexa: starting alexa-fhem: /usr/bin/ssh 192.168.110.101 -c /tmp/alexa-fhem.cfg
2024.03.14 19:25:52.037 3: alexa: starting
2024.03.14 19:25:52.040 3: alexa: using logfile: ./log/alexa-2024-03-14.log
2024.03.14 19:25:52.046 3: alexa: read: end of file reached while sysread
2024.03.14 19:25:52.046 3: alexa: stopped
Was läuft hier schief?
Viele Grüße
Jürgen
PS.: Das ganze läuft auf einer DS920+ mit einem macvlan-Netzwerk.
Zitat von: juemuc am 14 März 2024, 19:27:34Hallo zusammen,
ich habe nun fhem ohne https neu installiert. Danach habe ich Alexa-fhem neu eingerichtet. In der config.json habe ich nur die IP-Adresse von FHEM eingetragen. Es wird auch die Verbindung hergestellt und das Alexa-Device wird angelegt. Es stehen folgende Zeilen im log-file:
2024.03.14 19:18:11.916 2: alexa: created default configfile: ./alexa-fhem.cfg
2024.03.14 19:18:11.924 2: alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
2024.03.14 19:18:11.933 2: alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
Wenn ich jetzt im Alexa-Device den AlexaFHEM-host eintrage, kommen wieder die altbekannten Meldungen:
AlexaFHEM-host nicht eintragen!
Und in config.json keine IP Adressen sondern Namen hinterlegen.
Kommen denn im alexa-fhem container Fehler? Alles andere kannst Du vorerst ignorieren.
Hallo Sidey,
im Alexa-Fhem-Container sieht alles gut aus. Das Protokoll ist im Anhang. Im FHEM-Container kommen diese Meldungen:
2024.03.14 20:08:20.790 3: From the FHEM_GLOBALATTR environment: attr global pidfilename log/fhem.pid
2024.03.14 20:08:20.792 1: Including fhem.cfg
2024.03.14 20:08:20.793 3: logfile is readonly, it is set in the FHEM_GLOBALATTR environment
2024.03.14 20:08:21.057 3: WEB: port 8083 opened
2024.03.14 20:08:21.086 2: eventTypes: loaded 0 lines from ./log/eventTypes.txt
2024.03.14 20:08:21.396 3: AptToDate (fhemServerApt) - defined
2024.03.14 20:08:22.281 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2024.03.14 20:08:22.282 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2024.03.14 20:08:22.282 3: From the FHEM_GLOBALATTR environment: attr global logfile log/fhem-%Y-%m-%d.log
2024.03.14 20:08:22.282 3: From the FHEM_GLOBALATTR environment: attr global pidfilename log/fhem.pid
2024.03.14 20:08:22.283 1: Messages collected while initializing FHEM:configfile: logfile is readonly, it is set in the FHEM_GLOBALATTR environment
SecurityCheck:
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
Autosave deactivated
2024.03.14 20:08:23.498 1: usb create starting
2024.03.14 20:08:23.991 1: usb create end
2024.03.14 20:08:23.992 0: Featurelevel: 6.3
2024.03.14 20:08:23.992 0: Server started with 10 defined entities (fhem.pl:28598/2024-03-05 perl:5.036003 os:linux user:fhem pid:8294)
2024.03.14 20:08:57.303 1: MKDIR restoreDir/save/2024-03-14
2024.03.14 20:08:57.304 1: copy ./log/fhem.save ./restoreDir/save/2024-03-14/./log/fhem.save failed:No such file or directory
2024.03.14 20:12:57.879 2: alexa: created default configfile: ./alexa-fhem.cfg
2024.03.14 20:12:57.890 2: alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
2024.03.14 20:12:57.898 2: alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
Es will einfach nicht. Hast Du noch eine Idee?
Viele Grüße
Jürgen
Was genau funktioniert denn nicht?
Alexa-fhem macht was es soll und kann eine Verbindung zum Server herstellen:
[3/14/2024, 8:12:58 PM] Reading alexaFHEM.ProxyConnection set to running;; SSH connected
[3/14/2024, 8:12:58 PM] *** SSH: proxy connection established
[3/14/2024, 8:12:58 PM] SSH: Welcome at the reverse proxy! This pseudoshell does not react to any input - do not get irritated.
Die Fehlermeldung alexa: alexa-fhem not installed. install with 'sudo npm install -g alexa-fhem'.
kannst du einfach ignorieren. Es ist nur noch nicht richtig implementiert (wieso eigentlich nicht?), dass die verschwindet, wenn Docker verwendet wird.
Jetzt müsstest du eigentlich einfach nur noch in FHEM
get alexa proxyKeyausführen und kannst mit dem proxyKey dann deinen Skill über die Alexa-App verknüpfen.
Hallo passibe,
jetzt hat alles funktioniert. Ich wäre niemals auf die Idee gekommen, dass es trotz der Fehlermeldung im FHEM-Container funktioniert. Danke für Eure Hilfe.
Die Fehlermeldung sollte natürlich beseitigt werden. Das führt unweigerlich zu vielen Nachfragen (wie bei mir O:-) )
Jetzt werde ich noch mit https und allowed testen.
Viele Grüße
Jürgen
Jetzt hänge ich im nächsten Problem.
Die Kommunikation mit User/Psw hat noch funktioniert. Wenn ich jetzt aber auf https umschalte, startet alexa-fhem nicht mehr. Es kommt die Fehlermeldung
ZitatStartup rejected. Reason: Error: ENOENT: no such file or directory, open '/certs/alexa-fhem.key'
Was ist zu tun?
Viele Grüße
Jürgen
Hast du in der config.json irgendetwas geändert außer
"ssl": true,einzufügen?
Irgendwas muss noch passiert sein, damit alexa-fhem plötzlich im Verzeichnis "/certs" nach irgendwas sucht. Im GitHub-Repo gibt es nämlich kein "certs" (https://github.com/search?q=repo%3Ajustme-1968%2Falexa-fhem+certs&type=code), das muss also irgendwo sonst herkommen.
Am einfachsten ist es sicherlich, wenn du eine weitere FHEMWEB-Instanz ohne https einrichtest und dort dann nur Zugriffe von der alexa-fhem-IP zulässt. Ich weiß nämlich gar nicht, ob alexa-fhem überhaupt z.B. selbstsignierte Zertifikate usw. unterstützt.
Hallo passibe,
nein, mehr habe ich nicht verändert. Ich hatte auch versuchsweise das Verzeichnis eingerichtet, aber es wird nicht erkannt. Aus meiner Sicht müsste nur das "Cert-Verzeichnis" von FHEM eingebunden werden.
Viele Grüße
Jürgen
Ah, sorry, jetzt sehe ich was passiert ist:
Du hast oben im Abschnitt
"alexa": ["ssl": true gesetzt, richtig?
Das ist die falsche Stelle – da oben sollst/darfst du nichts ändern, wenn du nicht den Custom Skill benutzt, da geht es nur um die Verbindung zu den Amazon-Servern (bzw. der Verbindung der Amazon-Server zu dir/alexa-fhem).
Du musst im Abschnitt
"connections": [ein
"ssl": true,einfügen. Der Abschnitt kümmert sich nämlich darum, wie alexa-fhem mit FHEM kommuniziert – wie man daran sieht, dass du dort auch den FHEM-Hostnamen/Passwort eingibst, usw.
Wie gesagt kann es aber sein, dass alexa-fhem trotzdem noch meckert, falls du z.B. ein selbstsigniertes Zertifikat verwendest. Falls du nicht auf ein nicht-selbstsigniertes Zertifikat umsteigen möchtest/kannst hast du zwei Möglichkeiten:
1. Dein (Root-)Zertifikat im Container als trusted zu Markieren (googeln, erfordert ggfs. einige Docker-Kenntnisse) oder
2. wie gesagt eine FHEMWEB-Instanz ohne ssl zu benutzen, die nur "intern" läuft.
(@irgendjemand, der/die hier Moderator:in ist: kann man die letzten paar Posts dieses Threads ggfs. in ein eigenes Thema verschieben? Hat ja nichts mehr mit dem ursprünglichen Thema zu tun ...)
Hallo passibe,
danke für die Info. Ich werde dies noch testen und berichten.
Viele Grüße
Jürgen
Hallo passibe,
ja das war der entscheidende Tipp. Damit sind meine Tests erst einmal abgeschlossen.
Nochmals vielen Dank für Eure Unterstützung.
Ich nutze jetzt für den Container den offiziellen Link "ghcr.io/fhem/fhem-docker:dev-threaded-bullseye"
Es wäre schon, wenn die ALEXA-FHEM-Verbindung noch korrekt dargestellt werden könnte.
Viele Grüße
Jürgen
Zitat von: juemuc am 15 März 2024, 22:45:06Ich nutze jetzt für den Container den offiziellen Link "ghcr.io/fhem/fhem-docker:dev-threaded-bullseye"
Das ist eine Entwicklerversion und ändert sich aktuell stetig.
Ok. Danke für die Info.
Dann bleibe ich erst einmal bei der beta6.
Viele Grüße
Jürgen
Ich habe die beta7 erstellt.
Die ARM Plattformen haben nun auch alle nötigen CPAN Pakete
Weiterhin wurde ein Problem mit dem Health Check gelöst.
Offen ist noch ein Problem mit absoluten Pfadangaben, anstelle von relativen. Z.B. pidfile, da hat mein fix noch nicht alle Probleme beseitigt.
Hallo zusammen,
ich habe jetzt alle Devices aus meinem produktiven System problemlos übernehmen können. Auch die Verbindung zu Alexa-FHEM funktioniert. Leider geht der Status auf unhealthy. Ich kann aber keine Probleme erkennen. Gibt es einen Möglichkeit die Ursache zu finden?
Viele Grüße
Jürgen
Zitat von: juemuc am 17 März 2024, 15:54:46Leider geht der Status auf unhealthy. Ich kann aber keine Probleme erkennen. Gibt es einen Möglichkeit die Ursache zu finden?
Mit beta7?
Was sagt denn ein list der dockerinfo Definition?
Viele Grüße
Sidey
Hallo Sidey,
in FHEM ist alles auf "grün" nur in Portainer steht "unhealthy". Ich habe die Daten aus dem Produktiven FHEM immer blockweise übernommen. Lange Zeit war der Status in Portainer auch "healthy". Irgendeine Situation scheint dafür zu sorgen, dass Portainer auf einmal den Status "unhealthy" setzt. Ich versuche jetzt einmal die Übernahme der Daten in kleinere Schritte zu unterteilen um die Ursache zu finden. Es gibt ja auch in der Nutzung kein Problem. Ich wüsste halt nur gerne die Ursache.
Im logfile von FHEM ist auch nichts zu finden.
Viele Grüße
Jürgen
Zitat von: juemuc am 17 März 2024, 19:51:51in FHEM ist alles auf "grün" nur in Portainer steht "unhealthy".
Ich bleibe dabei, ein List von deinem dockerinfo würde schon weiterhelfen.
Danach weiss ich, in welche Richtung wir schauen müssen.
Grüße Sidey
Meinst die diese INfo?
Internals:
FUUID 65f5ae91-f33f-650f-c794-11f9f056228975f7
INFO_DIR /tmp
NAME DockerImageInfo
NR 44
NTFY_ORDER 50-DockerImageInfo
RESULT_FILE /tmp/health-check.result
STATE ok (3 successful, 0 failed)
TYPE DockerImageInfo
URL_FILE /tmp/health-check.urls
READINGS:
2024-03-17 14:33:50 container.cap.e audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot
2024-03-17 14:33:50 container.cap.i none
2024-03-17 14:33:50 container.cap.p audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot
2024-03-17 14:33:50 container.hostname FHEM
2024-03-17 14:33:50 container.hostnetwork 0
2024-03-17 14:33:50 container.id 40eebfa15dc02d7f5f90a006fdab79728b0168022433d922a75de4b834c5db75
2024-03-17 14:33:50 container.privileged 0
2024-03-17 14:33:50 id.gid 6061
2024-03-17 14:33:50 id.gname fhem
2024-03-17 14:33:50 id.groups [ "fhem": 6061, "tty": 5, "mail": 8, "dialout": 20, "audio": 29, "video": 44, "bluetooth": 6001, "gpio": 6002, "i2c": 6003 ]
2024-03-17 14:33:50 id.uid 6061
2024-03-17 14:33:50 id.uname fhem
2024-03-17 14:33:50 image.created 2024-03-16T08:42:08.985Z
2024-03-17 14:33:50 image.description A full blown Docker image for FHEM house automation system, based on Debian Perl -threaded-bullseye.
2024-03-17 14:33:50 image.documentation https://github.com/fhem/fhem-docker/blob/37a0a84856da58713246383c06fcd875429edc9f/README.md
2024-03-17 14:33:50 image.licenses MIT
2024-03-17 14:33:50 image.revision 37a0a84856da58713246383c06fcd875429edc9f
2024-03-17 14:33:50 image.source https://github.com/fhem/fhem-docker/
2024-03-17 14:33:50 image.title fhem-linux/amd64
2024-03-17 14:33:50 image.url https://hub.docker.com/r/fhem/fhem-linux/amd64
2024-03-17 14:33:50 image.vendor FHEM
2024-03-17 14:33:50 image.version 4.0.0-beta7-threaded-bullseye
2024-03-17 14:33:50 ssh-id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIE1yESZEhumuYPUUb+ZD3trP8DyMTHJrIJf32MYOj4Hz fhem@fhem-docker
2024-03-17 14:33:50 ssh-id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDlfLnpA3URiJIiZEYfbrwp6lLe6Xxt22MWH95rs463TjklB2Xj/EzdxtxXEh6u7N9wk7BlXuPrZOSF4JVSOtd3AFD4wQsmSNXFsm0J6vsUyohM4UyOSnfdNz9YOHTp1dDWYD32aB8K7SJAmFX5dIc5TyDuOe/ThGPmW8sLL54zYIo/vszeRnb2hZt4qNwxI3qDySYXlWqU/ycuWbfLxWtM+B4ysoxLM0Qrhr5/uGMOU38otAiLMp45MWWK9uBW9I4DgLBhMtrM3+olPXlD/LdygxOblmdM6XCcWf5L9l43vf+U0cLBWPm3S0oz83lkelrow+QT/FT5GBxAW0urZaS1Bg+1yJtLOBtQs90hBq4JeybjGkmjYV+kpXvzAY5NwSdRaJjY897DmcJYlgz0H1rA+z4rAVjtQMc1eVjlZPjQdh3ocaJNjMG6dAisM3f5htEERi/HjYqBhe+T9W0uV54tKcuxaCy14utK/sAWaRJtprDZl2cFKLgB9R38wC6XG7efInX8pfHEKY0vv4YtkRHd81yAr1gNCUxlnzYhPEfDFFSsPy3l0Pse7ct3d7sqTE9ogB2u8A+I6XCx4HSRIjVE5eYmE5wSyKXF0W994JLpFRehk//fp7wx/fi5MuB7BvCI3+ZyHh8tt9tduYOSQszEW/rnAs6Csi/mkufj0Qy2lw== fhem@fhem-docker
2024-03-17 14:33:50 sudoers [ "#", "# Allow installation of new packages", "# Allow updates", "# 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 upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/nmap", "# required by modules" ]
Attributes:
alias Docker Image Info
devStateIcon ok.*:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red
group System
icon docker
room Systemdaten
Viele Grüße
Jürgen
Zitat von: juemuc am 17 März 2024, 20:02:31Meinst die diese INfo?
Ja, die meinte ich.
Jetzt wissen wir, dass der helath Check drei FHEMWEB Instanzen überwacht.
Schau doch bitte einmal nach dem Inhalt in diesen beiden Dateien:
/tmp/health-check.result
/tmp/health-check.urls
Hallo Sidey,
nachdem ich noch einmal von vorne anfangen wollte um meine Schritte auch zu dokumentieren, kann ich aktuell nicht einmal mehr einen "Basis-Container Alexa-FHEM" mit einem "Basis-Container FHEM" verbinden.
Bei einer älteren Installation hat es geholfen, dass ich in Portainer einfach auf "Duplicate/Edit" gegangen bin und dann noch einmal auf "Deploy". Ich werde aber die Info von Dir im Hinterkopf behalten und dann auch hier berichten.
Viele Grüße
Jürgen
Hallo,
mir gelingt es nicht mehr Alexa-FHEM mit FHEM zu verknüpfen. Ich habe alles dokumentiert und hier angehängt. Ich hoffe, der Fehler liegt nicht bei mir ::)
Ein alexa-Device wurde in FHEM nicht angelegt.
Viele Grüße
Jürgen
Zitat von: juemuc am 18 März 2024, 17:39:52Ich habe alles dokumentiert und hier angehängt. Ich hoffe, der Fehler liegt nicht bei mir ::)
Ein alexa-Device wurde in FHEM nicht angelegt
1. Eine alexa-Fhem Definition must Du manuell anlegen.
2. Warum nutzt Du macvlan als Netzwerkverbindung?
3. Wozu aktualisiert Du nodeJS im Container?
4. Ist dein alexa-web passend zur alexa-Fhem config.json eingerichtet?
Hallo Sidey,
danke für die Infos. Ich war mir fast sicher, dass das alexa-Device automatisch angelegt wurde. Ich kann es aber nicht mehr nachvollziehen. Ich werde es mit einem selbst angelegten Device weiter testen.
macvlan nutze ich, damit ich auch für die Testinstallationen die gleichen Ports nutzen kann. Hatte damit noch keine Probleme.
NODEJS aktuallisiere ich nur, damit alles "grün" ist O:-)
In "alexa-web" ist eine Kopie von "web" mit einer Anpassung des Ports von 8083 uf 8093.
Viele Grüße
Jürgen
Auch wenn ich das alexa-device selbst in FHEM anlege, funktioniert es nicht. Die Log-Meldungen in alexa-fhem bleiben gleich.
Viele Grüße
Jürgen
Zitat von: juemuc am 18 März 2024, 20:29:16macvlan nutze ich, damit ich auch für die Testinstallationen die gleichen Ports nutzen kann. Hatte damit noch keine Probleme.
Da kann ich dir nicht folgen.
Standard ist, den alexa-fhem Container und den fhem container in ein Netzwerk zu bringen und die notwendigen Ports von fhem, nach außen erreichbar zu machen.
Zitat von: juemuc am 18 März 2024, 20:29:16NODEJS aktuallisiere ich nur, damit alles "grün" ist O:-)
Besser die nodejs definition löschen, zumindest ist jetzt bestätigt, dass diese Definition nur verwirrt.
Zitat von: juemuc am 18 März 2024, 20:29:16In "alexa-web" ist eine Kopie von "web" mit einer Anpassung des Ports von 8083 uf 8093.
Da ist dann auch das Problem zu suchen.
Wieso hast Du überhaupt eine separate Definition angelegt? Egal, die Angaben in der Definition müssen mit denen in der config.json überein stimmen:
Port und Hostname dürften stimmen, aber WEBNAME stimmt sehr wahrscheinlich nicht. Standard ist "fhem".
"connections": [
{
"name": "FHEM2",
"webname": "FHEM2",
"filter": "alexaName=..*",
"uid": "6062",
"port": "8093",
"server": "FHEM2"
}
]
Hallo Sidey,
jetzt habe ich es geschafft. Ich habe einfach die Definitionen aus der "alten" Konfiguration übernommen. Ich kann mir zwar nicht erklären was da jetzt anders ist, aber es funktioniert. Das alexa-Device wurde auch automatisch angelegt.
Ich habe ein eigenes Web-DEvice für alexa-fhem definiert, da ich mit https und Passwort zugreife. Die User/PSW-Info steht aber unverschlüsselt im Config-File für alexa. Mit dem eigenen Web-Device kann ich nun die Zugriffe von Alexa-Fhem besser einschränken (hoffe ich).
Viele Grüße
Jürgen
Hallo Sidey,
ich habe zwar nicht die beiden Dateien gefunden, dafür aber in Portainer unter "Inspect" folgende Infos:
"Health": {
"FailingStreak": 10,
"Log": [
{
"End": "2024-03-19T14:48:07.519644807+01:00",
"ExitCode": 1,
"Output": "Instance already running, aborting another one\n",
"Start": "2024-03-19T14:48:07.486258851+01:00"
},
{
"End": "2024-03-19T14:48:27.804237116+01:00",
"ExitCode": 1,
"Output": "Instance already running, aborting another one\n",
"Start": "2024-03-19T14:48:27.761884819+01:00"
},
{
"End": "2024-03-19T14:48:48.092185156+01:00",
"ExitCode": 1,
"Output": "Instance already running, aborting another one\n",
"Start": "2024-03-19T14:48:48.057024066+01:00"
},
{
"End": "2024-03-19T14:49:08.339831709+01:00",
"ExitCode": 1,
"Output": "Instance already running, aborting another one\n",
"Start": "2024-03-19T14:49:08.30228369+01:00"
},
{
"End": "2024-03-19T14:49:28.591953531+01:00",
"ExitCode": 1,
"Output": "Instance already running, aborting another one\n",
"Start": "2024-03-19T14:49:28.553926369+01:00"
}
],
"Status": "unhealthy"
},
Screenshot 2024-03-19 145224.png
Ich habe keine Ahnung wa hier passiert. Hast Du eine Idee?
Viele Grüße
Jürgen
Es sieht so aus, als ob der Healthcheck nicht abgeschlossen werden kann, bevor ein neuer gestartet wird.
Aber ohne mehr Details ist das alles raten
Zitat von: Sidey am 19 März 2024, 19:24:24Es sieht so aus, als ob der Healthcheck nicht abgeschlossen werden kann, bevor ein neuer gestartet wird.
Aber ohne mehr Details ist das alles raten
Hallo Sidey,
in den beiden Dateien steht leider auch nicht mehr:
ERROR (0 successful, 0 failed)
bzw.
https://localhost:8083/fhem/healthcheck
https://localhost:8093/fhem/healthcheck
https://localhost:8084/fhem/healthcheck
Wo kann ich weitersuchen?
Viele Grüße
Jürgen
Zitat von: juemuc am 19 März 2024, 19:34:27Wo kann ich weitersuchen?
Teile doch mal deine drei FHEMWEB Definitionen.
Hallo Sidey,
anbei die 3 Definitionen:
defmod WEB FHEMWEB 8083 global
attr WEB userattr DockerHealthCheck:0,1
attr WEB CssFiles pgm2/defaultCommon_jh.css
attr WEB DockerHealthCheck 1
attr WEB HTTPS 1
attr WEB column Wetter/Zeit:Wetter|Datum/Zeit,Mond,Pollenflug
attr WEB confirmJSError 0
attr WEB defaultRoom Statuszentrale
attr WEB hiddenroom Unsorted,Remote doc,Select style
attr WEB iconPath default:fhemSVG:openautomation:sscam
attr WEB longpoll websocket
attr WEB menuEntries Backup,/fhem?cmd=backup,Stop Shutdown,/fhem?cmd=%22net%20rpc%20abortshutdown%20-I%20ThinkPad%20-U%20shutdown-user%251FlE3lLJjZErxlCLOIAf%22,HUE reconnect,/fhem?cmd=set%20Philips_HUE%20reconnect
attr WEB sortRooms Bad Büro Esszimmer Flur Küche Schlafzimmer Wohnzimmer Wetter/Zeit
attr WEB stylesheetPrefix Default
defmod WEB_Alexa FHEMWEB 8093 global
attr WEB_Alexa userattr DockerHealthCheck:0,1
attr WEB_Alexa DockerHealthCheck 1
attr WEB_Alexa HTTPS 1defmod WEB_Antje FHEMWEB 8084 global
attr WEB_Antje userattr DockerHealthCheck:0,1
attr WEB_Antje CssFiles pgm2/defaultCommon_jh.css
attr WEB_Antje HTTPS 1
attr WEB_Antje column Wetter/Zeit:Wetter|Datum/Zeit,Mond
attr WEB_Antje confirmJSError 0
attr WEB_Antje defaultRoom Wohnzimmer
attr WEB_Antje hiddenroom IP Kamera,Alexa,AVM,TTS,Statuszentrale,Systemdaten,Sonos,Schaltzentrale,SIP,Parameter,MieleAtHome,Homematic,HUEDevice,Backup,Unsorted,Remote doc,Select style
attr WEB_Antje iconPath default:fhemSVG:openautomation:sscam
attr WEB_Antje sortRooms Bad Büro Esszimmer Flur Kammer Küche Schlafzimmer Wohnzimmer Wetter/Zeit
attr WEB_Antje stylesheetPrefix default
Viele Grüße
Jürgen
An denen liegt es nicht, ich tippe mal auf deine macvlan Konfiguration, das aber ist nur spekulation.
Das kann ich ausschließen.
Es muss an der FHEM.cfg liegen.
Ich habe jetzt einfach die letzten devices gelöscht und alles ist ok.
Jetzt muss ich sie sukzessive wieder hinzufügen 🙈
Viele Grüße
Jürgen
Zitat von: juemuc am 20 März 2024, 11:12:40Ich habe jetzt einfach die letzten devices gelöscht und alles ist ok.
Hast Du noch allowed Definition?
Man könnte auch den Health Check debuggen bzw. Den global verbose level erhöhen.
Hallo Sidey,
ich habe die Ursache gefunden. Es ist das HMCCU-Device gewesen. Hier werden im Hintergrund wohl sogenannte RPC-Server gestartet. Nachdem ich alle HM-Devices entfernt hatte, war alles ok.
Dann habe ich auf dem "Hauptsystem" nur die RPC-Server gestoppt und dann den Container neu deployed. Danach war wieder alles ok (healthy). Nach einiger Zeit scheinen aber die RPC-Server wieder "verrückt" zu spielen. Hast Du hier eine Idee oder ist hier zap (HMCCU-Maintainer) gefragt?
Ich habe FHEM auch unter PI-OS ohne Docker laufen. Kann ich hier was prüfen?
Viele Grüße
Jürgen
Zitat von: juemuc am 20 März 2024, 16:03:20Nach einiger Zeit scheinen aber die RPC-Server wieder "verrückt" zu spielen. Hast Du hier eine Idee oder ist hier zap (HMCCU-Maintainer) gefragt?
zap kann hier sicherlich mehr dazu sagen, was das HMCCU Modul macht.
Kannst Du den Befehl
netstat -xeW ausführen wenn das Problem vorhanden ist und auch vorher wenn es nicht vorhanden ist
Wo läuft denn deine HMCCU ?
Hallo Sidey,
hier zumindest die Info, wenn der Container auf unhealthy steht.
root@FHEM:/opt/fhem# sudo netstat -xeW
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path
unix 3 [ ] STREAM CONNECTED 18042019
unix 3 [ ] STREAM CONNECTED 18042022
unix 3 [ ] STREAM CONNECTED 18042020
unix 3 [ ] STREAM CONNECTED 18042017
unix 3 [ ] STREAM CONNECTED 18042018
unix 3 [ ] STREAM CONNECTED 18042021
Das Modul läuft in der aktiven FHEM-Instanz und verbindet sich mit piVCCU3 auf einem PI3B+ der eine CCU3 simuliert.
Die anderen Infos liefere ich morgen nach.
Viele Grüße
Jürgen
Zitat von: juemuc am 20 März 2024, 20:05:40hier zumindest die Info, wenn der Container auf unhealthy steht.
Unauffällig. Mein Gedanke war, dass irgendwelche Netzwerk Ressourcen verbraucht werden.
Mit lsof könnte man auch noch weiter schauen, aber das müsstest Du mal temporär mit apt install lsof installieren.
Wir brauchen mehr Debug Möglichkeiten, was den Health Check angeht, denn der scheint in einem zu langen Time Out zu hängen, auch wenn der nichts anderes macht, als jedes FHEM Web abzufragen.
Ich würde es auch gerne nachstellen, aber so einfach scheint mir das nicht, denn ich habe kein Docker Image für pivccu gefunden.
Hallo Sidey,
vorweg noch ein anderes Thema. Es fehlt mir wakeonlan. Ich habe mich schon gewundert, dass ich mit der Container-Installation keine Geräte mehr aufwecken kann. Kannst Du das bitte noch bereitstellen?
Dann zu den weiteren Tests. Ich schlage vor, dass ich in einer neuen Ubuntu-VM Docker und Portainer neu installiere und dort meine Container dann für weitere Tests bereitstellen. Da können wir dann alles installieren, was Du benötigst. Du piVCCU installiert sich aus meiner Sicht bereits als Container. Hier die Info dazu piVCCU (https://github.com/alexreinert/piVCCU)
Ich melde mich, wenn die Testinstallation steht.
Viele Grüße
Jürgen
Hallo Sidey,
die Testumgebung unter Ubuntu steht und der Fehler tritt auch hier auf. lsof ist defaultmäßig installiert.
Jetzt musst Du mir allerdings sagen, was ich tun muss. Du kannst mir auch gerne einen spezielle Container-Installation bereitstellen.
Viele Grüße
Jürgen
Hallo Jürgen,
Zitat von: juemuc am 21 März 2024, 09:16:18Es fehlt mir wakeonlan. Ich habe mich schon gewundert, dass ich mit der Container-Installation keine Geräte mehr aufwecken kann. Kannst Du das bitte noch bereitstellen?
das braucht man nicht zwingend im Container, im Container gibt es eben ein paar Einschränkungen. Ich denke im alten Image hat das auch nicht funktioniert? Ich habe hier mal eine paar Varianten aufgeschrieben, wie man WOL über den Host machen kann.
https://heinz-otto.blogspot.com/2022/04/andocken-dinge-die-man-auerhalb-docker.html
Gruß Otto
Hallo Otto,
da ich eine FB im Einsatz habe, würde ich dies gerne nutzen. Kannst Du hier (https://forum.fhem.de/index.php?topic=137607.0) weiter helfen?
Viele Grüße
Jürgen
Hallo zusammen,
in dem Zusammenhang habe ich auch festgestellt, dass ich keine "net-Kommandos" mehr absetzen kann um einen Shutdown auf einem PC durchführen zu können.
sh: 1: net: not found
Ich nutze:
net rpc shutdown ...und
net rpc abortshutdown ...
Welche Lösungen gibt es hierzu?
Viele Grüße
Jürgen
Zitat von: juemuc am 21 März 2024, 16:23:09da ich eine FB im Einsatz habe, würde ich dies gerne nutzen. Kannst Du hier (https://forum.fhem.de/index.php?topic=137607.0) weiter helfen?
nicht sofort - ich schaue später mal nach.
Das Problem mit net könntest Du auch prima über ssh zum Host machen. Das ist für mich so ein bisschen die Universal Lösung :)
Hallo Otto,
mein "Host" ist eine Syno 920+. Da möchte ich so wenig wie möglich ausserhalb des Containers laufen lassen. Da WOL über die Fritzbox nicht möglicht (siehe Kommentar im entsprechenden Thread) bin ich quasi auf WOL im Container "angewiesen". Warum muss ich Programme im Host definieren und aufrufen, wenn ich einen Container nutzen möchte? Ich verstehe dann den Sinn des Containers nicht mehr. Aber dies ist sicherlich ein Thema ausserhalb dieses Threads ;D
Für weitere Lösungsvorschläge bin ich immer offen.
Viele Grüße
Jürgen
Zitat von: juemuc am 21 März 2024, 17:22:46mein "Host" ist eine Syno 920+
Ein Host ist ein Host und ssh ist ssh :)
Einen Container verbiegt man nicht. Wenn der Host "nichts kann", mach einen extra Container der deine speziellen Wünsche abhandelt.
Der Weg im Docker ist Container neben Container zu stellen und nicht jeden Container zur EierlegendenWollmilchSau zu machen. ;)
Zitat von: juemuc am 21 März 2024, 13:54:57die Testumgebung unter Ubuntu steht und der Fehler tritt auch hier auf. lsof ist defaultmäßig installiert.
Jetzt musst Du mir allerdings sagen, was ich tun muss. Du kannst mir auch gerne einen spezielle Container-Installation bereitstellen.
Hmm, also in den Images ab Version 4 ist meiner Meinung nach kein lsof installiert.
Ich habe ein Image erstellt, in dem wir mehr Debug Ausgaben vom healthcheck erhalten:
ghcr.io/fhem/fhem-docker:4.0.0-debug-threaded-bullseye
Hallo Sidey,
werde ich morgen testen. lsof ist war natürlich nur im Host (Ubuntu) installiert.
Viele Grüße
Jürgen
Hallo Sidey,
hier die aktuellen Infos aus der neuen Version:
"State": {
"Dead": false,
"Error": "",
"ExitCode": 0,
"FinishedAt": "0001-01-01T00:00:00Z",
"Health": {
"FailingStreak": 7,
"Log": [
{
"End": "2024-03-22T13:33:56.934836443+01:00",
"ExitCode": -1,
"Output": "Health check exceeded timeout (10s): + '[' -e /var/run/health-check.pid ']'\n+ trap trapExitHandler SIGTERM EXIT\n+ echo 9735\n+ '[' -e /tmp/health-check.urls ']'\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8083/fhem/healthcheck\n+ fhemwebState=000\n+ '[' 28 -ne 0 ']'\n+ gRetMessage=' https://localhost:8083/fhem/healthcheck: FAILED (000);'\n+ gRetVal=1\n+ (( gFailedCnt++ ))\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8084/fhem/healthcheck\n",
"Start": "2024-03-22T13:33:46.801938795+01:00"
},
{
"End": "2024-03-22T13:34:27.084286471+01:00",
"ExitCode": -1,
"Output": "Health check exceeded timeout (10s): + '[' -e /var/run/health-check.pid ']'\n+ trap trapExitHandler SIGTERM EXIT\n+ echo 9762\n+ '[' -e /tmp/health-check.urls ']'\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8083/fhem/healthcheck\n+ fhemwebState=000\n+ '[' 28 -ne 0 ']'\n+ gRetMessage=' https://localhost:8083/fhem/healthcheck: FAILED (000);'\n+ gRetVal=1\n+ (( gFailedCnt++ ))\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8084/fhem/healthcheck\n+ fhemwebState=000\n+ '[' 28 -ne 0 ']'\n",
"Start": "2024-03-22T13:34:16.936565992+01:00"
},
{
"End": "2024-03-22T13:34:57.244727483+01:00",
"ExitCode": -1,
"Output": "Health check exceeded timeout (10s): + '[' -e /var/run/health-check.pid ']'\n+ trap trapExitHandler SIGTERM EXIT\n+ echo 9788\n+ '[' -e /tmp/health-check.urls ']'\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8083/fhem/healthcheck\n+ fhemwebState=000\n+ '[' 28 -ne 0 ']'\n+ gRetMessage=' https://localhost:8083/fhem/healthcheck: FAILED (000);'\n+ gRetVal=1\n+ (( gFailedCnt++ ))\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8084/fhem/healthcheck\n",
"Start": "2024-03-22T13:34:47.084994239+01:00"
},
{
"End": "2024-03-22T13:35:27.527834896+01:00",
"ExitCode": -1,
"Output": "Health check exceeded timeout (10s): + '[' -e /var/run/health-check.pid ']'\n+ trap trapExitHandler SIGTERM EXIT\n+ echo 9815\n+ '[' -e /tmp/health-check.urls ']'\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8083/fhem/healthcheck\n+ fhemwebState=000\n+ '[' 28 -ne 0 ']'\n+ gRetMessage=' https://localhost:8083/fhem/healthcheck: FAILED (000);'\n+ gRetVal=1\n+ (( gFailedCnt++ ))\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8084/fhem/healthcheck\n",
"Start": "2024-03-22T13:35:17.340902905+01:00"
},
{
"End": "2024-03-22T13:35:57.645487071+01:00",
"ExitCode": -1,
"Output": "Health check exceeded timeout (10s): + '[' -e /var/run/health-check.pid ']'\n+ trap trapExitHandler SIGTERM EXIT\n+ echo 9842\n+ '[' -e /tmp/health-check.urls ']'\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8083/fhem/healthcheck\n+ fhemwebState=000\n+ '[' 28 -ne 0 ']'\n+ gRetMessage=' https://localhost:8083/fhem/healthcheck: FAILED (000);'\n+ gRetVal=1\n+ (( gFailedCnt++ ))\n+ IFS=\n+ read -r fhemUrl\n++ curl --connect-timeout 5 --max-time 8 --silent --insecure --output /dev/null --write-out '%{http_code}' --user-agent 'FHEM-Docker/1.0 Health Check' https://localhost:8084/fhem/healthcheck\n",
"Start": "2024-03-22T13:35:47.530029982+01:00"
}
],
"Status": "unhealthy"
},
Nach einiger Zeit steht dies im logfile:
"Health": {
"FailingStreak": 124,
"Log": [
{
"End": "2024-03-22T16:55:08.247257776+01:00",
"ExitCode": 1,
"Output": "+ '[' -e /var/run/health-check.pid ']'\n+ echo 'Instance already running, aborting another one'\n+ exit 1\nInstance already running, aborting another one\n",
"Start": "2024-03-22T16:55:06.005732763+01:00"
},
{
"End": "2024-03-22T16:55:32.989772246+01:00",
"ExitCode": 1,
"Output": "Instance already running, aborting another one\n+ '[' -e /var/run/health-check.pid ']'\n+ echo 'Instance already running, aborting another one'\n+ exit 1\n",
"Start": "2024-03-22T16:55:28.25714174+01:00"
},
{
"End": "2024-03-22T16:55:55.490070395+01:00",
"ExitCode": 1,
"Output": "+ '[' -e /var/run/health-check.pid ']'\n+ echo 'Instance already running, aborting another one'\n+ exit 1\nInstance already running, aborting another one\n",
"Start": "2024-03-22T16:55:53.008567922+01:00"
},
{
"End": "2024-03-22T16:56:19.21266251+01:00",
"ExitCode": 1,
"Output": "+ '[' -e /var/run/health-check.pid ']'\n+ echo 'Instance already running, aborting another one'\n+ exit 1\nInstance already running, aborting another one\n",
"Start": "2024-03-22T16:56:15.493336171+01:00"
},
{
"End": "2024-03-22T16:56:39.586347746+01:00",
"ExitCode": 1,
"Output": "+ '[' -e /var/run/health-check.pid ']'\n+ echo 'Instance already running, aborting another one'\n+ exit 1\nInstance already running, aborting another one\n",
"Start": "2024-03-22T16:56:39.219082047+01:00"
}
],
"Status": "unhealthy"
},
Reicht dir diese Info oder benötigst Du noch mehr?
Viele Grüße
Jürgen
Die Infos reichen um meinen Verdacht zum bestätigen.
Die Anfragen mittels curl auf
https://localhost:8083/fhem/healthcheck
und
https://localhost:8084/fhem/healthcheck
werden nicht oder nicht schnell genug beantwortet .
Kannst Du mal manuell mittels CURL diese Anfragen senden und schauen was passiert?
Hallo Sidey,
ja mache ich gerne. Aktuell ist mein System nur mit der Installatin einer VM ausgelastet. Da macht die Abfrage keinen Sinn. Jetzt ist mir auch klar, warum das passiert. Das HMCCU-Modul lastet mein System immer wieder aus. Deswegen ist der Container ohne die HM-Devices auch "healthy".
Ich melde mich wieder mit den Ergebnissen.
Viele Grüße
Jürgen
Zitat von: juemuc am 22 März 2024, 22:34:52Das HMCCU-Modul lastet mein System immer wieder aus.
Hmm, ich weiss nicht genau wie dieses Modul arbeitet, aber ggf. blockiert es FHEM.
Dazu brauchen wir aber zap .
@juemuc
Grundsätzlich scheint mir das blockieren kein Problem vom Docker Image zu sein. Der Container wird halt nur entgegen nativer Installation auf seinen FHEMWeb Instanzen regelmäßig geprüft.
Hast Du in den
ccuflags das Flag nonBlocking
gesetzt?
Hallo Sidey,
ich erhalte auf der Syno bzw. in der VM folgende Meldung:
root@FHEM:/opt/fhem# sudo curl https://localhost:8083/fhem/healthcheck
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Die Ursache für scheint aber eher mein pi mit der piVCCU zu sein. Hier bleibt das System immer mal wieder stehen, wenn ich mit mehreren FHEMs zugreife.
Viele Grüße
Jürgen
Hallo Sidey,
habe gerade festegestellt, dass dieses Flag bei meinen Testinstallationen nicht (mehr) gesetzt war. Ich prüfe dies noch einmal. Danke für den Tipp.
Korrektur: War doch gesetzt.
Viele Grüße
Jürgen
Zitat von: juemuc am 23 März 2024, 14:28:49Hallo Sidey,
ich erhalte auf der Syno bzw. in der VM folgende Meldung:
Probier es mal mit --insecure für den curl Aufruf :)
Hallo Sidey,
bei Port 8083 erfolgt keine Ausgabe. Das Attribut DockerHealthCheck = 1. Bei Port 8084 ist das Attribut nicht gesetzt und es gibt folgende Ausgabe:
siehe Anhang
Viele Grüße
Jürgen
Zitat von: juemuc am 23 März 2024, 16:43:29Hallo Sidey,
bei Port 8083 erfolgt keine Ausgabe. Das Attribut DockerHealthCheck = 1. Bei Port 8084 ist das Attribut nicht gesetzt und es gibt folgende Ausgabe:
siehe Anhang
Default ist der Wert 1.
Der Anhang ist vermutlich nicht der richtige.
Das ist die Ausgabe, die ich mit curl --insecure https://localhost:8084/fhem/healthcheck erhalte. Habe es extra noch einmal geprüft.
Viele Grüße
Jürgen
Zitat von: juemuc am 23 März 2024, 17:55:28Das ist die Ausgabe, die ich mit curl --insecure https://localhost:8084/fhem/healthcheck
Achso, das ist das, was heruntergeladen wurde. Ja okay ist dein web Interface halt.
Ich dachte an das was in der Konsole steht, aber es scheint ja auf diesem Port problemlos zu funktionieren.
Was mit dem 8083 ist, verstehe ich aber auch nicht.
Hallo Sidey,
ich glaube, dass es keinen Sinn macht hier weiter zu "forschen". Mir wäre im Moment eine Lösung für das "WOL" und "net"-Kommando wichtiger. Hast Du hierfür eine Lösung? Ich wollte keine zusätzlichen Programme auf der Syno installieren.
Viele Grüße
Jürgen
Zitat von: juemuc am 23 März 2024, 20:15:26Mir wäre im Moment eine Lösung für das "WOL" und "net"-Kommando wichtiger.
Bezüglich wakeonlan hat dir Otto ein paar Vorschläge gemacht.
Das gehört nicht in den FHEM Container, denn es würde im Standardfall nicht funktionieren.
Hier gibt es ein Projekt, da kannst Du per MQTT einen WOL Proxy ansteuern.
Dieser Container müsste dann in das Netzwerk von dem Host.
FHEM und Alexa haben da nichts zu suchen.
https://github.com/dr3st/WOL-proxy
Für was wird das Net Kommando gebraucht?
Grüße Sidey
Hallo
Zitatwenn der Container auf unhealthy steht.
Im Zusammenhang mit der HMCCU tritt bei mir das Problem nur auf wenn das Volume-Mapping im Container selbst ist.
Volume-Mapping außerhalb vom Container auf z.B. /opt/fhem = kein unhealthy
vG Jens
Hallo Sidey,
mit dem net-Kommando fahre ich PCs im Netzwerk herunter, die vorher mit WOL aufgeweckt wurden. Ich schaue mir das mit dem WOL-Proxy einmal an.
Hallo Newbie,
Deine Aussage verstehe ich nicht ganz. Wie hast Du das Mapping definiert?
Viele Grüße
Jürgen
Zitat von: juemuc am 23 März 2024, 23:13:54Hallo Sidey,
mit dem net-Kommando fahre ich PCs im Netzwerk herunter, die vorher mit WOL aufgeweckt wurden.
Hast Du da mal ein Beispiel?
Ich hätte jetzt gedacht, dass ein Script sich per SSH auf einen anderen Rechner verbindet und ein shutdown auslöst.
Oder das ganze auch via MQTT realisieren.
Habe mal schnell gesucht und auch was interessantes und universelles gefunden:
https://github.com/albertnis/mqcontrol?tab=readme-ov-file
Grüße Sidey
Zitat von: Sidey am 24 März 2024, 08:53:13Hast Du da mal ein Beispiel?
net macht das ganze für Windows PCs über deren RPC Schnittstelle. Das würde aus einem Container sicher funktionieren (im Gegensatz zu WOL - ich denke das funktioniert eigentlich nicht). Ich meine es ist Bestandteil eines der samba Pakete.
Ich mache das mittlerweile auch alles mit ssh (ssh Server auf Windows aktiviert) weil es einfacher ist, man damit mehr machen und einheitlich auf Windows und Linux zugreifen kann. 8)
Gruß Otto
Zitat von: Otto123 am 24 März 2024, 10:57:32Zitat von: Sidey am 24 März 2024, 08:53:13Hast Du da mal ein Beispiel?
net macht das ganze für Windows PCs über deren RPC Schnittstelle. Das würde aus einem Container sicher funktionieren (im Gegensatz zu WOL - ich denke das funktioniert eigentlich nicht). Ich meine es ist Bestandteil eines der samba Pakete.
Ah, danke.
Ich hatte so etwas schon vermutet, aber war mir nicht sicher, weil es ja hauptsächlich für Windows PCs gedacht ist.
Ich habe die MQTT Lösung nicht ausprobiert, aber die erscheint mir viel universeller zu sein und es braucht keine shell geöffnet werden, die vermutlich FHEM auch noch blockiert um sowas zu realisieren.
Zitat von: Sidey am 24 März 2024, 11:08:47und es braucht keine shell geöffnet werden, die vermutlich FHEM auch noch blockiert um sowas zu realisieren.
Nein tut sie normal nicht. Man setzt in FHEM ja ein Shell Kommando ab, das wird im Hintergrund ausgeführt (commandref (https://fhem.de/commandref_DE.html#command))
Vor allem würde es dem Docker Konzept entsprechen.
"Ein Container macht nur eine Sache, die aber Richtig"
Gerade die "Eierlegende Wollmilchsäue" sind schlecht zu warten ... das war ja auch der Grund, für den Neuanfang ...
Hallo zusammen,
ihr habt mich überzeugt und ich habe den ssh-Server unter Windows11 installiert. Jetzt hoffe ich aber auch auf Eure Hilfe bei den nächsten Schritten 8) (gerne in einem separaten Thread).
- Wie kann ich nun per ssh einen shutdown auf einem Windows-Rechner automatisiert durchführen bzw. diesen auch abbrechen? Bisher habe ich diese Befehle genutzt:
Shutdown:
"net rpc shutdown -f -t 120 -C 'Der PC wird in 2 Min ausgeschaltet!' -I ThinkPad.lan -U shutdown-user%PSW"Abort Shutdown:
"net rpc abortshutdown -I ThinkPad -U shutdown-user%PSWf"
Manuell kann ich zumindest
shutdown /s /t 120 oder shutdown /a eingeben
Wenn ich Ottos Beiträge richtig verstanden habe, erfolgt aber das Aufwecken immer noch über WOL-Kommando, welches ich über einen anderen Rechner (z.B. PI) aufrufe.
Viele Grüße
Jürgen
shutdown Beispiel im WOL Device:
attr LPKW11 shutdownCmd "ssh heinz@lpkw11 shutdown /s"Du musst aber vorher ssh mit public key eingerichtet haben, ich habe das hier (https://heinz-otto.blogspot.com/2023/01/ssh-zugang-fur-fhem-uber-script.html) ziemlich umfangreich beschrieben und hergeleitet. Aber wenn ich das mit etwas Abstand lese: da muss ich noch etwas ergänzen.
Hallo Sidey,
ich bekomme beim Aufruf einer ssh-Verbindung zu meinem pi folgende Meldungen:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_ADDRESS = "de_DE.UTF-8",
LC_NAME = "de_DE.UTF-8",
LC_MONETARY = "de_DE.UTF-8",
LC_PAPER = "de_DE.UTF-8",
LC_TELEPHONE = "de_DE.UTF-8",
LC_MESSAGES = "en_DK.UTF-8",
LC_MEASUREMENT = "de_DE.UTF-8",
LC_TIME = "de_DE.UTF-8",
LC_NUMERIC = "de_DE.UTF-8",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
Nach meinen Recherchen sollte ein
locale-gen de_DE.UTF-8 fehlen. Dies kann ich aber unter dem User FHEM nicht ausführen.
Viele Grüße
Jürgen
Hallo Otto,
in fhem erhalte ich mit
{qx(locale)}LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES=en_DK.UTF-8
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
Das passt wohl nicht zusammen.
Viele Grüße
Jürgen
Zitat von: Sidey am 02 März 2024, 11:35:13Wer würde das Image testen und Feedback geben?
ghcr.io/fhem/fhem-minimal-docker:4.0.0-beta7-bullseye
Vorher auch "minimal". Jetzt etwas geringere CPU Last ...
Es wird kein Gateway gesetzt. Habe hier keine Env-Parameter die das beinflussen würden. host.docker.internal ist vorhanden.
Aus der Doku:
Set Docker gateway IPv4 address for gateway.docker.internal:
-e DOCKER_GW=172.17.0.1 << habe ich nicht als env gesetzt.
If this variable is not present, [b]the gateway will automatically be detected.[/b]
root@c6ccf0d9204d:/opt/fhem# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.19.0.6 c6ccf0d9204d
172.19.0.1 host.docker.internal
root@c6ccf0d9204d:/opt/fhem#
Mein Setup - LXC in Proxmox. Darin läuft Docker.
Hallo Sidey,
ich glaube meine Per-Warnungen kommen wegen den ENV-Definitionen. Wenn ich diese Überschreibe, hat das aber keine Auswirkung. Es bleibt der alte Wert stehen.
Kannst Du das noch anpassen? Dies betrifft im Besonderen die Werte für LANG, LANGUAGE und LC_MESSAGES. Oder wie kann ich die Werte selbst ändern?
fhem-ENV.png
Viele Grüße
Jürgen
ZitatOder wie kann ich die Werte selbst ändern?
Ändere doch die Einträge in ENV, dazu auf "Duplicate/Edit" gehen, ändern und dann auf "Deploy the Container" drücken.
Da konntest du auch über den Punkt "Volumes" den Speicherort deiner FHEM-Daten ändern.
Screenshot_20240326_183604.png
Hallo Newbie,
genauso hatte ich schon eine Änderung durchgeführt. Aber die Änderung hat nicht gezogen. Ich teste es noch einmal.
Zumindest weiß ich jetzt, dass es geht.
Viele Grüße
Jürgen
Hallo zusammen,
ich kann die ENV-Werte überschreiben wie ich will. Nach dem deployen sind wieder die alten werden drin. Hat noch jemand eine Idee?
Viele Grüße
Jürgen
Zitat von: juemuc am 26 März 2024, 19:14:42ich kann die ENV-Werte überschreiben wie ich will. Nach dem deployen sind wieder die alten werden drin. Hat noch jemand eine Idee?
Muss ich mir mal ansehen.
Gibt es dieses Verhalten mit der V3 auch oder nicht?
Hallo Sidey,
ist wohl bei "fhem/fhem:latest" auch so. Ich hoffe, dass ist die V3.
Viele Grüße
Jürgen
Zitat von: juemuc am 26 März 2024, 19:59:46ist wohl bei "fhem/fhem:latest" auch so. Ich hoffe, dass ist die V3.
Momentan ist das noch die V3.
Also bei mir klappt das überschreiben der Variable.
Habe LANGUAGE mit dem Wert des:en als Umgebungsvariable an den Container übergeben:
LANG=en_US.UTF-8
LANGUAGE=de:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES=en_DK.UTF-8
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
ok.
Ich versuche es morgen direkt ohne Portainer. Bisher habe ich die Änderungen immer über Portainer durchgeführt. Eventuell liegt hier das Problem.
Viele Grüße
Jürgen
Zitat von: juemuc am 26 März 2024, 22:53:15Bisher habe ich die Änderungen immer über Portainer durchgeführt. Eventuell liegt hier das Problem.
Ich habe es auch über Portainer gemacht und im Stack, was letztlich nur ein Compose ist, folgendes ergänzt:
environment:
LANGUAGE: de:en
Ich habe die Änderungen nun direkt auf der Syno in der Docker-Umgebung ohne Probleme durchführen können. Keine Ahnung warum dies über Portainer nicht funktioniert hat.
Viele Grüße
Jürgen
Hallo Sidey,
folgendes ist mir beim "logfile" noch aufgefallen:
- Ich habe den Pfad im ENV auf "/mnt/DS-Save/FHEM/log/fhem-%Y-%m-%d.log" geändert
- in "global" kommt aber nur "mnt/DS-Save/FHEM/log/fhem-%Y-%m-%d.log" an. Es wird also der erste "/" verschluckt. Somit muss ich auch bei der "Logfiledefinition" ohne den ersten Schrägstrich arbeiten.
Screenshot 2024-03-27 092107.png
Screenshot 2024-03-27 092245.png
Somit wird auch nicht der angegebene Pfad sondern im "opt"-Verzeichnis der Pad ./mnt/... angelegt. Kannst Du das ändern?
Viele Grüße
Jürgen
Hallo zusammen, ich nutze schon lange dankbar Sideys Docker container (allerdings mit Podman und angepassten Befehlen)
Seit der ghcr.io/fhem/fhem-docker:4.0.0-beta3-bullseye und der später aktualisierten ghcr.io/fhem/fhem-docker:dev-bullseye ist mein ZWAVE ZMEEUZBB nicht mehr zur Arbeit zu überreden obwohl Erkennung vorhanden an erster Stelle :root@ubupi:/opt/fhem# ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-xxxx_xxxx-xxxx -> ../../ttyACM1
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DEXXXXXXX-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-SHK_JeeLink_LaCrosse-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-STM32_MapleCUL_xxxxxxxx-if0x -> ../../ttyACM2
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-STM32_MapleCUL_xxxxxxxx-if0x -> ../../ttyACM3
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-STM32_MapleCUL_xxxxxxxx-if0x -> ../../ttyACM4
Waren da vielleicht Änderungen erfolgt welche auf das Z-WAVE durchschlugen?
Ein Wechsel zurürck auf ghcr.io/fhem/fhem-docker:4.0.0-beta2-bullseye machte alles wieder lauffähig - sollte aber nicht die dauerhafte Lösung sein.
Bin dankbar für Eure Ideen.
frink
Zitat von: frinkenstein am 01 April 2024, 05:45:24:root@ubupi:/opt/fhem# ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-xxxx_xxxx-xxxx -> ../../ttyACM1
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DEXXXXXXX-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-SHK_JeeLink_LaCrosse-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-STM32_MapleCUL_xxxxxxxx-if0x -> ../../ttyACM2
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-STM32_MapleCUL_xxxxxxxx-if0x -> ../../ttyACM3
lrwxrwxrwx 1 root dialout 13 Mär 21 21:15 usb-STM32_MapleCUL_xxxxxxxx-if0x -> ../../ttyACM4
Ich vermute, die Berechtigung stimmen nicht. Mit beta3 wurde das entry.sh Script getauscht, was den Container vorbereitet.
Kannst Du innerhalb des Containers die ls Befehle einmal mit beta2 und einmal mit beta3 ausführen, nachdem FHEM gestartet ist.
Viele Grüße
Hallöchen,
ich habe ein paar Tage gewerkelt und die gemeldeten Bugs bearbeitet.
Das sind die neuen Tags die ich erzeugt habe:
- 4.0.0-beta8-bullseye
- 4.0.0-beta8-threaded-bullseye
Hier sind die Release Notes (https://github.com/fhem/fhem-docker/releases/tag/v4.0.0-beta8).
Zitat von: juemuc am 27 März 2024, 09:23:40Hallo Sidey,
folgendes ist mir beim "logfile" noch aufgefallen:
- Ich habe den Pfad im ENV auf "/mnt/DS-Save/FHEM/log/fhem-%Y-%m-%d.log" geändert
- in "global" kommt aber nur "mnt/DS-Save/FHEM/log/fhem-%Y-%m-%d.log" an. Es wird also der erste "/" verschluckt. Somit muss ich auch bei der "Logfiledefinition" ohne den ersten Schrägstrich arbeiten.
Somit wird auch nicht der angegebene Pfad sondern im "opt"-Verzeichnis der Pad ./mnt/... angelegt. Kannst Du das ändern?
Gerne verifizieren, es sollte jetzt wie gewünscht funktionieren.
Zitat von: kadettilac89 am 26 März 2024, 09:56:06Es wird kein Gateway gesetzt. Habe hier keine Env-Parameter die das beinflussen würden. host.docker.internal ist vorhanden.
Danke für den Hinweis. Nach Analyse und Behebung hat das vermutlich noch nie funktioniert.
Mir ist zwar unklar, wofür der Hostname eines Gateways nützlich ist, aber es sollte mit der neuen Version wie in der README beschrieben funktionieren.
Viele Grüße
Sidey
Hallo Sidey,
die Pfadangaben für das Logfile sind nun korrekt.
Viele Grüße
Jürgen
Hallo Sidey,
ist leider schon etwas her - sorry für meine späte Antwort jetzt - Bastelzeit ist rar..
Die beta2 war bis jetzt die letzte die überhaupt durchstartet und läuft - mag natürlich podman geschuldet sein
ab beta3 bis beta8 und -dev von gestern bleibt der Start in einer Art Dauerneustartschleife gefangen
Ich versuchs mal mit Anhängen (wenn ich filtern könnte würd ichs machen)
Viele Grüße
frink
Zitat von: frinkenstein am 16 April 2024, 22:50:12Die beta2 war bis jetzt die letzte die überhaupt durchstartet und läuft
Ich kenne mich mit podman nun leider überhaupt nicht aus.
Hast Du den Container in einer frischen unveränderten FHEM Konfiguration gestartet oder ist das eine schon modifizierte.
Interessant wäre für mich, ob der Fehler auch mit einer neuen Installation Auftritt. Dann wissen wir besser, wo wir suchen müssen.
Grüße
Sidey
Hallo Sidey,
hab es auf ein Netzwerkproblem eingrenzen können - Ausgangspunkt war die Loginfo :
21:24:26 conmon: /entry.sh: line 823: DOCKER_GW: unbound variable
21:24:26 conmon: INFO: Patching /etc/hosts file with DOCKER_HOST and DOCKER_GW'
bis zur beta2 einschl. startet das dockerimage mit der podman option --net=host
sauber durch und ist mit localhost:8083 erreichbar
mit der beta8 und aktuellen dev müssen stattdessen mit dem podman start die docker parameter -e DOCKER_HOST= -e DOCKER_GW=
angeben werden um dann die cni-podman0 Netzwerkbrücke auf 10.88.0.1 und nach jedem Container-neustart hochzählend die hostip 10.88.0.x
(automatisch vergeben) zu erhalten und Zugang auf den dann durchgestarteten Container auf :8083 zu bekommen - echt unglücklich
und mit meinem Versuch und Irrtum-Wissen häng ich fest - da ein Blick von dir/euch drauf wär nett -
für heute ist erst mal schluss..
Grüße
frink
Zitat von: frinkenstein am 17 April 2024, 22:46:31Hallo Sidey,
hab es auf ein Netzwerkproblem eingrenzen können - Ausgangspunkt war die Loginfo :
21:24:26 conmon: /entry.sh: line 823: DOCKER_GW: unbound variable
21:24:26 conmon: INFO: Patching /etc/hosts file with DOCKER_HOST and DOCKER_GW'
Hat etwas gedauert, aber ich habe den Fehler identifiziert und behoben.
Heute Nacht wird ein neues `dev-bullseye` Tag erzeugt. (https://github.com/fhem/fhem-docker/actions/runs/8775573769)
In dieser sollte der Fehler behoben sein.
Wenn Du es bitte damit probieren würdest, wäre ich dir sehr dankbar.
Viele Grüße
Sidey
Aber ganz sicher werde ich das morgen testen!
Danke für deine Zeit.
Viele Grüße
frink
Hallo Sidey,
Ich teste gerade das image auf meiner synology mit portainer und docker-compose im Moment sieht die so aus:
version: '2.3'
services:
fhem:
image: ghcr.io/fhem/fhem-docker:4.0.0-beta9-bullseye
container_name: FHEM
restart: always
ports:
- "8083:8083"
- "7072:7072"
volumes:
- "/volume1/docker/fhem/:/opt/fhem/"
environment:
FHEM_UID: 6061
FHEM_GID: 6061
TIMEOUT: 10
RESTART: 1
TELNETPORT: 7072
TZ: Europe/Berlin
# CONFIGTYPE: configDB
LOGFILE: ./log/fhem-%Y-%m-%d.log
Wenn ich jetzt per cpan z.b.: Finance::Quote installieren möchte, wie kann ich das machen?
Gibt es da eine generelle Vorgehensweise, wenn ich Zusatzliche Software installieren möchte?
BTW: Das image läuft bei mir bis jetzt ganz gut.
Werde weiter testen.
Gruß
Hubert
Installation geht über Umgebungsvariablen. Schau einmal auf der GitHub Seite fhem/fhem-docker
Da findest Du die entsprechenden Infos.
Zitat von: carlos am 22 April 2024, 13:21:50Wenn ich jetzt per cpan z.b.: Finance::Quote installieren möchte, wie kann ich das machen?
Gibt es da eine generelle Vorgehensweise, wenn ich Zusatzliche Software installieren möchte?
Zitat von: CoolTux am 22 April 2024, 13:39:16Installation geht über Umgebungsvariablen. Schau einmal auf der GitHub Seite fhem/fhem-docker
Da findest Du die entsprechenden Infos.
Nur bis V3 gab es diese Variablen. Ab 4 deprecated - um welches es hier geht. Jetzt musst du ein eigenes Image bauen welches auf das Fhem-Image aufsetzt.
Since version 4 (https://github.com/fhem/fhem-docker#since-version-4)
To extand the image wirh a custom package for example, you have to use standard docker tools.
If you are defining a docker-compose.yml file describing your configuration, then you can add a build definition instead of starting the image from the registry:
With this, you will create a new image, and install any tool which you additional need:
Hallo Sidey -
deine Fehlerbehebung war sehr erfolgreich, der -dev fhem-Container ist wieder mit der podman option --net=host auf localhost:8083
oder aus der Ferne mit IP:8083 erreichbar. ;D
Danke dir!
Viele Grüße
frink
Zitat von: carlos am 22 April 2024, 13:21:50Wenn ich jetzt per cpan z.b.: Finance::Quote installieren möchte, wie kann ich das machen?
Gibt es da eine generelle Vorgehensweise, wenn ich Zusatzliche Software installieren möchte?
Wieso brauchst Du denn das Finance:quote Modul?
Beim Erzeugen des Images werden die notwendigen CPAN Module aus diversen Quellen gesucht und installiert.
In einem Docker Image wird nachträglich keine Software installiert.
Grüße Sidey
Auf der einen Seite sehr schade daß es nicht mehr mit Umgebungsvariablen geht. Ander seits ist aber auch konsequent und richtig. Ich wollte Mi eh eine eigene CI/CD Pipeline bauen.
Zitat von: carlos am 22 April 2024, 13:21:50Gibt es da eine generelle Vorgehensweise, wenn ich Zusatzliche Software installieren möchte?
Meine Meinung: egal ob es geht oder nicht - dann eben nicht docker nehmen - wenn man eigentlich einen "PC" braucht. Besser einen LXC Container oder eine VM verwenden und FHEM ganz normal per Setup installieren. In dem LXC oder der VM kann man machen was man will und es wirklich langfristig selbst warten. Docker ist dafür nicht gemacht, da nimmt man das Image (die App) vom Entwickler und fertig. ;)
Hallo,
Vorweg mein Produktiv FHEM läuft unter Proxmox im Container.
Da kann ich dann alles machen was ich will unter anderem Finance::Quote per cpan installieren um die Shares und Sharemaster module von PAH zu nutzen.
Ich habe testweise das docker image auf meiner Synology installiert und da hätte ich persöhnlich dann den Anspruch, dass ich da ebenfalls alle Möglichkeiten nutzen kann, die ich bei einer normalen Installation von FHEM habe.
Also zumindest die meisten Module die im SVN drin sind, auch wenn da noch zusätzliche Pakete installiert werden müssen.
Mir ist auch bewust, dass man hier mit einem Docker image Einschränkungen hinnehmen muss, aber es wäre doch gut, wenn man die so gering wie möglich halten kann.
Ich finde es auch gut, dass man hier mit dem Docker image eine zusätzliche einfachere Möglichkeit hat FHEM zu betreiben.
Deshalb teste ich es auch um hier meinen Betrag zu leisten.
Gruß
Hubert
Zitat von: carlos am 22 April 2024, 13:21:50Wenn ich jetzt per cpan z.b.: Finance::Quote installieren möchte, wie kann ich das machen?
Gibt es da eine generelle Vorgehensweise, wenn ich Zusatzliche Software installieren möchte?
Mal die Diskussion was man darf und was man lassen sollte ausgeblendet.
Es gibt die Möglichkeit per Startscript irgend welche Dinge zu unterschiedlichen Zeitpunkten auszuführen. Hier installiere ich mir meine Pakete nach seit es die Env-Möglichkeit nihct mehr gibt.
Initscripts (https://github.com/fhem/fhem-docker?tab=readme-ov-file#make-any-other-changes-during-container-start)
Make any other changes during container start
In case you need to perform further changes to the container before it is ready for your FHEM instance to operate, there are a couple of entry points for your own scripts that will be run automatically if they are found at the right place. In order to achieve this, you need to mount the script file itself or a complete folder that contains that script to the respective destination inside your container. See Docker documentation about Use volumes and Bind mounts to learn how to achieve this in general.
.....
Zitat von: carlos am 23 April 2024, 09:14:17Sharemaster module von PAH zu nutzen.
Von wo werden diese Module bezogen? Liegen die in einem Github Repository? Wenn ja, dann wäre es ein einfaches die Quelle auf nötige Packages zu finden.
Im Moment wird bei jedem build eine Github suche nach Repositorys mit FHEM Kennzeichnung gemacht. Die darin benannten Packages werden dann automatisch in dem Build berücksichtigt.
Zitat von: carlos am 23 April 2024, 09:14:17Also zumindest die meisten Module die im SVN drin sind, auch wenn da noch zusätzliche Pakete installiert werden müssen.
Das Image hat den Anspruch, dass alle SVN Module (außer die in contrib) lauffähig sind. Dazu werden alle Module gescannt und deren notwendigen Packages sind installiert.
Mir fallen nur zwei Gründe ein, wieso es mal nicht klappt
a) Das Image ist schon älter und unterstützt noch die die neue Packageabhängigkeit. (Aktuell eher unwahrscheinlich)
b) In dem Scan ist ein Bug und er hat ein notwendiges Package übersehen.
Geht aktuell eines der im SVN befindlichen Module nicht?
Zitat von: carlos am 22 April 2024, 13:21:50Wenn ich jetzt per cpan z.b.: Finance::Quote installieren möchte, wie kann ich das machen?
Gibt es da eine generelle Vorgehensweise, wenn ich Zusatzliche Software installieren möchte?
Zitat von: kadettilac89 am 23 April 2024, 12:32:56Es gibt die Möglichkeit per Startscript irgend welche Dinge zu unterschiedlichen Zeitpunkten auszuführen. Hier installiere ich mir meine Pakete nach seit es die Env-Möglichkeit nihct mehr gibt.
Stimmt, die gibt es. Man kann auch das entry Script ersetzen oder sich ein Volume für weitere CPAN Packages einrichten. Wer weiss wie es geht bekommt es hin, alle anderen sollten mit so was erst gar nicht anfangen.
Ich verstehe nur nicht, welche Notwendigkeiten gibt es denn, was in dem Container nach zu installieren?
Wenn das Image so nicht passt, wieso baut ihr dann ich einfach einen weiteren Layer bei euch lokal ein? So funktioniert es doch bei allen anderen Containern auch.
Grüße Sidey
Zitat von: Sidey am 23 April 2024, 21:31:22Ich verstehe nur nicht, welche Notwendigkeiten gibt es denn, was in dem Container nach zu installieren?
Wenn das Image so nicht passt, wieso baut ihr dann ich einfach einen weiteren Layer bei euch lokal ein? So funktioniert es doch bei allen anderen Containern auch.
Ich nutze die Docker Minimal und will nur zusätzliche Pakete drin habe die ich brauche. Vermutlich würde das "große" Image schon alles abdecken, aber ich bin "früher" schon ein paarmal durch npm, und andere Abhängigkeiten in Probleme gelaufen. Seit Fhem-minimal läuft es stabil. Wenn ich ein eigenes Image baue nehme ich mir die automatischen Updates durch watchtower wenn ein neues Image hochgeladen wird.
@Sidey
Na da habe ich ja jetzt eine größere Diskussion losgetreten.
Zur Klärung:
Die beiden module 95_Shares.pm und 95_ShareMaster.pm liegen im SVN (nicht contrib!) .
95_Shares.pm benutzt:
..
use Finance::Quote;
..
Dieses package kann man entweder über Debian apt installieren(nicht aktuell) oder über cpan.
Im Moment gibt es da leider ständig Anderungen, so dass man immer die aktuelle Version braucht.
ZitatDas Image hat den Anspruch, dass alle SVN Module (außer die in contrib) lauffähig sind. Dazu werden alle Module gescannt und deren notwendigen Packages sind installiert.
Mir fallen nur zwei Gründe ein, wieso es mal nicht klappt
a) Das Image ist schon älter und unterstützt noch die die neue Packageabhängigkeit. (Aktuell eher unwahrscheinlich)
b) In dem Scan ist ein Bug und er hat ein notwendiges Package übersehen.
Geht aktuell eines der im SVN befindlichen Module nicht?
Keine Ahnung ob hier dann b) zutrifft.
Wie schon gesagt, ich teste hier nur und versuche entsprechend Beiträge zu leisten.
Für mich persöhnlich es nicht unbedingt wichtig, da mein fhem nicht als docker image läuft.
Aber meiner Meinung nach sollte so ein image so vollständig wie moglich sein.
Gruß
Hubert
Zitat von: carlos am 24 April 2024, 10:33:42@Sidey
Na da habe ich ja jetzt eine größere Diskussion losgetreten.
Zur Klärung:
Die beiden module 95_Shares.pm und 95_ShareMaster.pm liegen im SVN (nicht contrib!) .
95_Shares.pm benutzt:
..
use Finance::Quote;
..
Dieses package kann man entweder über Debian apt installieren(nicht aktuell) oder über cpan.
Dieses Package ist im Build vorhanden.
Bevor sich das festsetzt.
Über APT installierte Perl Packages werden nicht mehr verwendet / geladen.
Grüße Sidey
Zitat von: carlos am 24 April 2024, 10:33:42Aber meiner Meinung nach sollte so ein image so vollständig wie moglich sein.
ZitatIch nutze die Docker Minimal und will nur zusätzliche Pakete drin habe die ich brauche.
Das ist der Konflikt der die Env-Parameter hervor brachte. Ist halt die Frage wohin man will. Der Split in minimal und normal ist schon ein guter Anfang dazu. Jedem Recht machen wird nie funktionieren.
ZitatAber meiner Meinung nach sollte so ein Image so vollständig wie möglich sein.
Bei einem Minimalsystem meiner Meinung gerade nicht. Sonst bekommen wir in die aktuelle Situation wieder, das es nicht mehr wartbar ist.
Eher kann man das Minimalsystem aufbohren mit Ergänzungen und als eigenständige Container anbieten. So machen es z.B. andere Projekte.
ich habe ja bisher nur etwas quer dazwischen geredet, aber jetzt wollte ich wirklich mal ein Image testen - aber irgendwie fehlt mir eine Info?
Ich meine: alles was auf der Seite https://github.com/fhem/fhem-docker an Anleitung mit "4" steht meldet
ZitatError response from daemon: manifest unknown
???
Auch was hier im Thread im ersten Beitrag steht funktioniert nicht.
OK nach etwas Frust und Suche: man muss hierhin gehen https://github.com/orgs/fhem/packages/container/package/fhem-docker
docker pull ghcr.io/fhem/fhem-docker:dev-threaded-bullseye Auch da ist der Rest vom Text nur zur Verwirrung? ;D
Ich wollte nicht meckern ich wollte es nur sagen weil es mir auffiel ;)
Zitat von: Otto123 am 24 April 2024, 21:31:53Auch was hier im Thread im ersten Beitrag steht funktioniert nicht.
Das wundert mich, kann mich nicht erinnern das gelöscht zu haben... Sollte ich aber vermutlich mal machen.
Aber ja, die Readme geht davon aus, dass es die V4 gibt, was ja nicht stimmt weil noch Beta.
Das ist nicht ideal, aber besser als wenn unter dem Tag V4 eine Beta kommt und jemand das nicht weiss.
Grüße Sidey
So, allen Testern zwischendurch auch vielen Dank an das fleißige Testen.
Ich habe gestern die Beta10 veröffentlicht, darin sind die zuletzt gemeldeten Bugs behoben:
ghcr.io/fhem/fhem-docker:4.0.0-beta10-bullseye
Da mir zum jetzigen Zeitpunkt keine Fehler bekannt sind werde ich mich um das Thema Imagegröße kümmern.
Viele Grüße
Sidey
Ich hätte da noch eine "Feature Vorschlag":
könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?
- damit würde sich der user eine eigene Dockerfile ersparen und hätte dennoch die Flexibilität, die bisher z.B. mittels ENV parametern bzw. auch notfalls auch apt od. cpan od. ... Möglichkeiten vor dem FHEM start...
der user startet dann "sein" image nur mittels run cmd. - Falls was nicht funktioniert, einfach den start-beforexxx.sh am docker-host löschen und er hat das standard image ohne mods...
eine post-xxx.sh kann man auch jetzt schon mit der V3 aus dem laufenden FHEM aufrufen.
l.g. erwin
Zitat von: erwin am 29 April 2024, 09:10:49Ich hätte da noch eine "Feature Vorschlag":
könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?
- damit würde sich der user eine eigene Dockerfile ersparen und hätte dennoch die Flexibilität, die bisher z.B. mittels ENV parametern bzw. auch notfalls auch apt od. cpan od. ... Möglichkeiten vor dem FHEM start...
der user startet dann "sein" image nur mittels run cmd. - Falls was nicht funktioniert, einfach den start-beforexxx.sh am docker-host löschen und er hat das standard image ohne mods...
eine post-xxx.sh kann man auch jetzt schon mit der V3 aus dem laufenden FHEM aufrufen.
l.g. erwin
Gibts doch schon, oder was fehlt?
Zitat von: kadettilac89 am 23 April 2024, 12:32:56Zitat von: carlos am 22 April 2024, 13:21:50Wenn ich jetzt per cpan z.b.: Finance::Quote installieren möchte, wie kann ich das machen?
Gibt es da eine generelle Vorgehensweise, wenn ich Zusatzliche Software installieren möchte?
Mal die Diskussion was man darf und was man lassen sollte ausgeblendet.
Es gibt die Möglichkeit per Startscript irgend welche Dinge zu unterschiedlichen Zeitpunkten auszuführen. Hier installiere ich mir meine Pakete nach seit es die Env-Möglichkeit nihct mehr gibt.
Initscripts (https://github.com/fhem/fhem-docker?tab=readme-ov-file#make-any-other-changes-during-container-start)
Make any other changes during container start
In case you need to perform further changes to the container before it is ready for your FHEM instance to operate, there are a couple of entry points for your own scripts that will be run automatically if they are found at the right place. In order to achieve this, you need to mount the script file itself or a complete folder that contains that script to the respective destination inside your container. See Docker documentation about Use volumes and Bind mounts to learn how to achieve this in general.
.....
Hi Sidey,
Es gibt 2 Arten von Images. Das "normale" und das "Threaded".
Bietet das threaded Perl irgend welche Vorteile? Was Threads sind weiß ich, mir gehts um die Motivation ein solches Image zu bauen.
Ich habe mit Beta9 das threaded mal genutzt und festgestellt, dass damit der Healthcheck auf unhealthy geht obwohl Fhem problemlos arbeitet und von außen erreichbar ist. Ich habe heute morgen den Container mit Beta10 am laufen und Health ist wieder OK. Ich habe aber nicht weiter analysiert. Hatte nur durch den unhealthy-Status dauern Restarts.
Ich habe das Minimal-Image im Einsatz ....
@kadettilac89
ZitatGibts doch schon, oder was fehlt?
Ja gibts, aber die Idee war dass man ohne
eigene compose und dockerfile auskommt.... - also möglichst nah am default...
l.g.erwin
Zitat von: erwin am 29 April 2024, 11:53:38@kadettilac89
ZitatGibts doch schon, oder was fehlt?
Ja gibts, aber die Idee war dass man ohne eigene compose und dockerfile auskommt.... - also möglichst nah am default...
l.g.erwin
Hast du dir meine Antwort durchgelesen und verstanden? Das muss du ja nicht
@kadettilac89
deine Antwort hab ich gelesen, aber evtl. kapier ich einfach nicht, wie man das ohne eigenen compose od. dockerfile lösen kann.
Vielleicht zeigst du mir den Weg.
Zitat von: erwin am 29 April 2024, 13:17:15@kadettilac89
deine Antwort hab ich gelesen, aber evtl. kapier ich einfach nicht, wie man das ohne eigenen compose od. dockerfile lösen kann.
Vielleicht zeigst du mir den Weg.
Initscripts (https://github.com/fhem/fhem-docker?tab=readme-ov-file#make-any-other-changes-during-container-start)
Wie auf der Seite vom Docker Container beschrieben ...
Je nachdem was du wann installieren willst suche dir einen Absprungspunkt aus ...
/pre-init.sh, /docker/pre-init.sh
/post-init.sh, /docker/post-init.sh
/pre-start.sh, /docker/pre-start.sh
/post-start.sh, /docker/post-start.sh
Ich binde den Ordner /docker und dort lege ich meine Scripte ab
volumes:
- /docker/docker_files/fhemscripts:/docker
Vermutlich ist das post-init.sh script der richtige Absprungspunkt für dich. Du erzeugts also ein kleines Script in dem apt-update && apt-install <dein paket> ... ausgeführt wird. Ohne dass du ein Dockerfile oder Änderung am Defaultimage machen musst. Dein Script muss nur so heißen wie auf Github beschrieben sonst wird es nicht ausgeführt.
Edit: du kannst dir im Prizip die alte Logik des Dockerfile aus 3.0 als Vorlage nehmen. Mein Script sieht aktuell so aus um ein paar Dinge zu installieren.
#!/bin/bash
#
#Since version 4
#To extand the image wirh a custom package for example, you have to use standard docker tools.
#nodejs sources
mkdir -p /tmp/keyrings/
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /tmp/keyrings/nodesource.gpg
NODE_MAJOR=20
echo "deb [signed-by=/tmp/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" > /etc/apt/sources.list.d/nodesource.list
#Upade before all packages
LC_ALL=C DEBIAN_FRONTEND=noninteractive apt-get update
#APT_PKGS: "nano libmodule-pluggable-perl libfinance-quote-perl iproute2"
LC_ALL=C DEBIAN_FRONTEND=noninteractive apt-get install -qqy --no-install-recommends \
nano \
libmodule-pluggable-perl \
libfinance-quote-perl \
iproute2
#NPM_PKGS: "gassistant-fhem"
LC_ALL=C DEBIAN_FRONTEND=noninteractive apt-get install nodejs -y
LC_ALL=C DEBIAN_FRONTEND=noninteractive apt-get install -qqy --no-install-recommends npm
npm install -g --unsafe-perm --production gassistant-fhem
#CPAN_PKGS: "Data::Peek Net::FTPSSL Protocol::WebSocket::Frame"
cpanm --notest \
Data::Peek \
Net::FTPSSL \
Protocol::WebSocket::Frame
#Cleanup apt
LC_ALL=C apt-get autoremove -qqy && LC_ALL=C apt-get clean
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* ~/.[^.] ~/.??* ~/* /etc/apt/sources.list.d/nodesource.list
OK, danke, noch ein volume od. file mounten, die ursprüngliche Frage war aber:
könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?wobei start-beforexxx.sh für die pre-init u. pre-start.sh files steht.
l.g. und danke erwin
Zitat von: erwin am 29 April 2024, 14:22:06OK, danke, noch ein volume od. file mounten, die ursprüngliche Frage war aber:
könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?wobei start-beforexxx.sh für die pre-init u. pre-start.sh files steht.
l.g. und danke erwin
Ich verstehe nicht warum die nicht die bereits bestehenden Absprungpunkte nutzen willst. Das ist ein einziger Mount. Das Image schreibt beim erstellen erst /opt/fhem. Das ist der Ordner der auch in Docker-compose als bind oder mount verwendet wird. Wie willst du überwschreiben und Berechtigungen sicherstellen wenn du schon Scripte ausführen kannst bevor eben dieser Ordner bereit gestellt wird und geladen wird?
Die gegebenen Scripte in einem eigenen Ordner bieten alle Möglichkeiten. Wenn du Sidey zusätzliche, redundante, Skripte einbauen will - gerne, überzeuge ihn. Ich möchte aber Rückwärtskompatibilität und die bestehende Pfade behalten.
Zitat von: erwin am 29 April 2024, 14:22:06könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?
Ich weiß zwar nicht welchen Vorteil du dir erhoffst. Technisch gesehen kannst du in docker-compose entrypoint mit deinem eigenen Script überschbeiben. Dann musst du halt das bestehende Script "entry.sh" mit deinem eigenen ersetzen. Damit kannst du alles selber steuern. Dann musst du kein zusätzliches Verzeichnis mounten.
Zitat von: kadettilac89 am 29 April 2024, 10:34:35Bietet das threaded Perl irgend welche Vorteile? Was Threads sind weiß ich, mir gehts um die Motivation ein solches Image zu bauen.
Wenn man es nicht unbedingt braucht, dann sollte man nicht die threaded Version von Perl verwenden.
Die Motivation ist, dass das 00_SONOS Modul funktioniert, da es threaded entwickelt wurde. Soweit ich weiss, ist es das einzigste Modul was dies benötigt.
Am besten ist es sicherlich, dann in diesem FHEM Container nur das Sonos Modul zu laden und eine zweite FHEM Instanz per FHEM2FHEM anzubinden, da man alle Nachteile des threaded perl erhält.
Hier noch die Details zu dem SONOS Modul ein paar Seiten weiter vorne. :)
https://forum.fhem.de/index.php?topic=137309.msg1306442#msg1306442
Zitat von: kadettilac89 am 29 April 2024, 10:34:35Ich habe mit Beta9 das threaded mal genutzt und festgestellt, dass damit der Healthcheck auf unhealthy geht obwohl Fhem problemlos arbeitet und von außen erreichbar ist.
Ja, das Problem haben wir schon mal mit dem HMCCU Modul glaube ich identifiziert. Das liegt aber eher weniger am Container, als daran wie die Module entwickelt wurden, denn wenn der Healthcheck nicht geht, dann gibt eine der FHEMWEB Instanzen keine Antwort.
Zitat von: erwin am 29 April 2024, 14:22:06könnte man nicht ein start-beforexxx.sh aus dem sowieso gemounteten /opt/fhem/ directory im standard dockerfile aufrufen?
Könnte ja, aber ich werde es nicht einbauen.
Schon die vorhandenen pre-init scripte sind ein antipattern. Irgendwann in naher Zukunft wird im Log erscheinen, dass die Nutzung nur noch kurze Zeit unterstützt ist.
Wer jetzt neu anfängt, dem kann ich nur dringend raten, die Standard Docker Mechanismen zu verwenden. Ihr tut euch einen Gefallen, auch wenn ihr es heute noch nicht wisst.
Wer weiss was er tut, der kann ein eigenes entryscript hinterlegen, jedem der nicht weiss was er da tut, der sollte das Image so verwenden wie es bereitgestellt wird und auch Abstand von den Anleitungen nehmen.
Oft gibt es bessere Alternativen, als zur Laufzeit in einem Container etwas nach zu installieren. In der Regel, findet sich für jedes Problem ein eigenes Image, welches genau dafür gemacht ist.
Eigentlich fällt mir überhaupt keine Notwendigkeit ein, unbedingt was in einem Container zu installieren. Maximal vielleicht, wenn ich was temporär debuggen muss, aber genau danach lade ich mein Image wieder und hab ne saubere Sache.
Grüße Sidey
Sidey, danke für die Antwort auf meine Frage zu Threaded
Danke Sidey,
deine Erklärung kingt logisch, ich bin im Docker environment nicht firm, daher sind solche statements: ... antipattern, in Zukunft...
sehr hilfreich!
l.g. erwin
Zitat von: Sidey am 29 April 2024, 21:54:38Ja, das Problem haben wir schon mal mit dem HMCCU Modul glaube ich identifiziert. Das liegt aber eher weniger am Container, als daran wie die Module entwickelt wurden, denn wenn der Healthcheck nicht geht, dann gibt eine der FHEMWEB Instanzen keine Antwort.
Bei mir ist kein HMCCU aktiv. Ich habe mir den Code angesehen. Vor dem Trap wird schon mit "exit 1" das ganze Bash Script verlassen, ein gesetztes PIDFILE wird nie wieder gelöscht (warum auch immer es noch aktiv ist). Die trap-Funktion wird nicht erreicht. Ich vermute du oder der Author wollte nur den Exit Code auf 1 setzen um dann im Trap darauf zu reagieren. Damit das funktioniert muss das Exit-Statement aber in Klammern.
Diese Korrektur meine ich.
#====================================================================================================================-
#--- Main script -----------------------------------------------------------------------------------------------------
[ -e $PID_FILE ] && { echo "Instance already running, aborting another one" ; (exit 1); } # run before installing traphandler!
trap trapExitHandler SIGTERM EXIT
Zitat von: kadettilac89 am 01 Mai 2024, 11:44:24Zitat von: Sidey am 29 April 2024, 21:54:38Ja, das Problem haben wir schon mal mit dem HMCCU Modul glaube ich identifiziert. Das liegt aber eher weniger am Container, als daran wie die Module entwickelt wurden, denn wenn der Healthcheck nicht geht, dann gibt eine der FHEMWEB Instanzen keine Antwort.
Bei mir ist kein HMCCU aktiv. Ich habe mir den Code angesehen. Vor dem Trap wird schon mit "exit 1" das ganze Bash Script verlassen, ein gesetztes PIDFILE wird nie wieder gelöscht (warum auch immer es noch aktiv ist). Die trap-Funktion wird nicht erreicht. Ich vermute du oder der Author wollte nur den Exit Code auf 1 setzen um dann im Trap darauf zu reagieren. Damit das funktioniert muss das Exit-Statement aber in Klammern.
Hmm, ich denke der Author ( ich bin es nicht ) wollte das Script beenden, wenn schon ein Prozess läuft.
Wieso sollte es helfen, in einer subshell einen Exit Status von 1 zu setzen?
Ich vermute auch, dass das Pidfile nur von dem Prozess gelöscht werden soll, der es gestartet hat.
Ist es denn so, dass ein Pidfile da liegt obwohl der Prozess beendet wurde?
Viel Grüße
Sidey
Zitat von: Sidey am 01 Mai 2024, 19:51:45Wieso sollte es helfen, in einer subshell einen Exit Status von 1 zu setzen?
Ich vermute auch, dass das Pidfile nur von dem Prozess gelöscht werden soll, der es gestartet hat.
Ist es denn so, dass ein Pidfile da liegt obwohl der Prozess beendet wurde?
Viel Grüße
Sidey
Ich kann auch nur vermuten was gewollt war. "Instance already running, aborting another one" besagt dass der von früher noch laufende Prozess gestoppt werden sollte. " run before installing traphandler!" vermutlich damit der Exitcode schon 1 ist bevor der trap registriert wird.
Bei mir was das PIDFILE über einen Tag alt. Als ich es manuell gelöscht hatte war der Container wieder healthy.
Vom Ablauf wäre es sinnvoll den trap zu Beginn der Verarbeitung zu registieren und dann erst die Checks auszuführen. Aber dagegen sprach irgendwas, warum sonst der Kommentar. Oder der Code hat sich geändert und der Kommentar war für was anderes gedacht.
Zitat von: kadettilac89 am 01 Mai 2024, 20:22:52Ich kann auch nur vermuten was gewollt war. "Instance already running, aborting another one" besagt dass der von früher noch laufende Prozess gestoppt werden sollte.
Nein, sehe ich nicht so. Es soll kein weiterer gestartet werden, wenn bereits einer läuft.
Daher auch das exit vor dem traphandler und das weil, ein rm auf das lockfile eingerichtet wurde.
Ich habe mich jetzt ein wenig belesen und vermutlich ist es eine race condition, da das pidfile handling nicht atomar genug realisiert wurde.
Ich habe mich dazu entschieden, eine verlässlichere Methode mittels flock zu implementieren:
https://github.com/fhem/fhem-docker/pull/231
Ich denke morgen gibt es dann auch ein Image mit dieser Anpassung.
Grüße Sidey
Das Image mit der Anpassung beim health check kann unter folgendem Tag geladen werden:
docker pull ghcr.io/fhem/fhem-docker:dev-threaded-bullseye
docker pull ghcr.io/fhem/fhem-docker:dev-bullseye
Viele Grüße
Sidey