[Docker / Container] echodevice

[Sidey]

Hallo,

ich möchte hier mein Projekt kurz vorstellen und auch die grundlegende Architektur erläutern, weil die Frage sonst vermutlich recht schnell aufkommt.

Der FHEM-Docker-Container ist in erster Linie darauf ausgelegt, Perl-Programme auszuführen. Das Modul `echodevice` und auch einige andere Lösungen nutzen zusätzlich weitere Laufzeitumgebungen, zum Beispiel Node.js.

Seit Version 5 des FHEM-Images ist kein Node Package Manager mehr im FHEM-(Perl-)Docker-Image enthalten. In der Vergangenheit bedeutete das meist, dass man sich dafür ein eigenes angepasstes Image bauen musste.
Das dorr enthaltene NodeJS (18) ist schon längst aus der Wartung.
Da hier auch mit Authentifizierungsinformationen handelt, sollte einem die Sicherheit der Software nicht völlig egal sein.

Nach einer kurzen Diskussion hier im Forum habe ich mich daher entschieden, das von `echodevice` verwendete `alexa-cookie2` in einen eigenen Hilfscontainer auszulagern. Das Ganze heißt `alexa-cookie-service`.

Der Service stellt eine REST-API zur Verfügung, über die die notwendigen Schritte für die Anmeldung am Amazon-Dienst umgesetzt werden können.

Projektlink: 
https://github.com/fhem/alexa-cookie-service

Grobes Integrationsmuster: 
FHEM / echodevice -> HTTP/REST -> alexa-cookie-service -> Amazon

Das bedeutet konkret:

- Das Modul `echodevice` bleibt im normalen FHEM-Container.
- Der separate Service-Container stellt per REST-API die Funktionen rund um `alexa-cookie2` bereit.
- FHEM ruft diese API bei Bedarf auf, anstatt Node.js-Code direkt im FHEM-Container auszuführen.

Die Motivation für die Trennung ist vor allem:

- Der FHEM-Container soll möglichst nah an einer klassischen und gut wartbaren FHEM-Laufzeitumgebung bleiben.
- Ein Node.js-Projekt bringt eine eigene Runtime, eigene Abhängigkeiten und meist auch einen anderen Release- und Update-Zyklus mit.
- Wenn man beides in einen einzigen Container packt, vermischt man zwei technisch unterschiedliche Aufgabenbereiche.
- Das macht Images größer, die Wartung aufwendiger und erschwert Updates, Fehlersuche und Debugging.
- Zusätzlich wird es unpraktisch, wenn man nur den Service neu starten oder aktualisieren möchte, ohne gleichzeitig die FHEM-Umgebung anzufassen.

Mit einem separaten Service-Container ist die Trennung sauberer:

- Der Node.js-Dienst kann in einer dafür passenden Umgebung laufen.
- Beide Komponenten können unabhängig voneinander gestartet, gestoppt und aktualisiert werden.
- Fehler lassen sich leichter eingrenzen, weil klarer ist, ob ein Problem aus FHEM oder aus dem Service stammt.

Mir ist wichtig, dass diese Entscheidung nicht als unnötige Verkomplizierung verstanden wird. Auf den ersten Blick könnte es einfacher wirken, alles in einen Container zu legen. Praktisch erkauft man sich diese vermeintliche Einfachheit aber oft mit mehr Aufwand bei Pflege und Betrieb.

Die Aufteilung in FHEM-Container und Service-Container ist daher eine bewusste Designentscheidung zugunsten von Stabilität, Wartbarkeit und klaren Zuständigkeiten.

Damit das aktuelle echodevice Modul mit der Integration weiter funktioniert, habe ich ein paar Hilfs Definitionen (HTTPMOD, notify, at) auf der Projektseite beschrieben.

Grüße Sidey