fhempy docker container

[sidey79]

Kann es sein, dass tinytuya in den Requirements fehlt?

Hier wird es importiert:

fhempy/FHEM/bindings/python/fhempy/lib/tuya/tuya.py

Line 7 in 6b3639e

from tinytuya import BulbDevice, Cloud, deviceScan

Hier wird von einem Problem im Container berichtet und da fehlt tinytuya:
fhem/fhempy-docker#33

[fhempy]

Hi,
alle Module installieren deren gebrauchte Packages erst beim Define. Daher sind die Packages immer im manifest.json hinterlegt.

Siehe:
https://github.com/fhempy/fhempy/blob/6b3639e76a0eb1c99f93cc73e746acaa3730cf3a/FHEM/bindings/python/fhempy/lib/tuya/manifest.json

[sidey79]

Verstehe, hmm klingt ungünstig.
Kenn mich mit Python nicht so gut aus.

Was ist denn die Voraussetzung, dass dieses Inatallieren beim define funktioniert?

[fhempy]

Das ist alles in requirements.txt drin. Ich habe mal das gesamte Log angefragt, wahrscheinlich hat die Installation von tinytuya nicht funktioniert.

[sidey79]

Das kann ich mir gut vorstellen, dass das installieren von etwas was nicht vorhanden ist, dann auch nicht funktioniert.

Da ich zu dieser Variante mit manifest.json nichts an Dokumenten finden konnte, weiss ich nicht wie das installieren abläuft.
Versucht der das packages aus einer registry zu laden und compilieren oder oder oder. :)

[fhempy]

python3 -m pip install PACKAGE

genau das wird ausgeführt, mehr nicht.

[sidey79]

Ok, das wird nicht funktionieren. Vielleicht kann ich die Requirements absuchen und vorher alles installieren, danke für die Aufklärung

[fhempy]

Kann im Docker nichts "live" installiert werden? Alles zu installieren von allen Modulen ist ein Overkill, das sollte man nicht machen.
Des Weiteren sollte das Update via FHEM ja auch funktionieren, d.h. fhempy selbst wird auch genauso aktualisiert.

[sidey79]

So ist das in einem docker Container nicht gedacht.

Der Container beinhaltet die komplette Applikation inkl. Laufzeitumgebung.
Möchte man die Applikation aktualisieren, dann startet man eine neue Version von dem Container Image.
Compiler habe in der Regel auch nichts in einem Container Image zu suchen auch wenn es nicht ausgeschlossen ist, dort welche zu installieren.
Änderungen innerhalb eines Containers sind nicht auf Persistenz angelegt. Wird der Container neu aus dem Image erstellt, sind änderungen wieder weg.

[fhempy]

Vielleicht findest du bei Home Assistant Hilfe. Die bieten auch Docker Container an und nutzen genauso die Installation wie es fhempy macht.

Ich würde es nämlich schade finden, wenn man den Container aktualisieren muss, nur weil man fhempy aktualisieren will. Das wäre aus User Perspektive etwas umständlich, da die Update Funktion in FHEM dann nicht mehr funktioniert.

[sidey79]

Den Container zu aktualisieren hat den Vorteil, dass alles was im Image enthalten ist, mit aktualisiert wird. Da braucht dann auch nichts mehr compiliert werden, der alte wird gestoppt der neue gestartet. Wenn es nicht läuft, lädt man einfach wieder den alten.
Dauert keine 5 Sekunden, bis der fhempy Container wieder läuft.
Bei Docker ist halt so, dass der host und nicht der container für die Aktualisierung Zuständig sind.

[fhempy]

Schau mal wie es bei HA gelöst ist, die machen die Installationen genauso wie fhempy. Dort habe ich auch die Lösung mit den on-demand Installationen abgeschaut.

[sidey79]

Was ich da weiß ist, sie haben ein wheel Repository und legen dort (alle?) Python Packages als fertiges wheel ab. Das führt natürlich dazu, dass es lokal nicht compiliert werden muss und sich das ganze auf Download und Installation reduziert. :)

Im Docker Image selbst konnte ich da nichts besonderes finden, sie installieren halt unter Angabe des Wheel Repositorys die benötigten Pakete. Ob da dann alles installiert wird oder nur ein Teil, da fehlt mir aktuell die detail Kenntnisse.

Meine Idee weicht davon nicht so groß ab, ich würde im build Prozess auch alle wheels erzeugen die in den Abhängigkeiten referenziert sind. Ein erster Test gestern Abend hat auch schon funktioniert. Dauert halt nur ewig, so dass ich einen cache aufbauen möchte.

Die Wheels würde ich dann allerdings direkt in das Finale Image installieren, denn eine nachträgliche Installation im laufenden Container, kann ja nichts, was im Image steckt ersetzen, sondern bei jeder Installation wird ein weiterer Layer über die vorhandenen gelegt und der Overhead steigt stetig an. Alternativ könnten wir alle Module die installiert werden auf ein separates Volume legen und dann mit viel Magie symlinks setzen, damit die Pakete geladen werden. Das wäre theoretisch möglich am einfachsten vielleicht auch für alle Pakete pauschal noch überschaubau, da nur ein Link nötig.
Cleanup der alten Pakete ist dann irgendwie Usersache und es gibt keinen einheitlichen Stand mit welchen Versionständen fhempy im Container läuft.

[fhempy]

Wie ist das jetzt zu verstehen? Download und Installation geht, aber nur compilieren macht Probleme?

Generell werden immer wheel Packages runtergeladen, außer es muss etwas gebaut werden, weil kein wheel existiert. Das ist wahrscheinlich der Fall bei einer der Crypto Abhängigkeiten bei bestimmten Systemarchitekturen bei tinytuya. Das kann es aber immer geben, das kannst nur schwer vermeiden.

Hier die HA Infos gefunden:
https://github.com/home-assistant/wheels

[sidey79]

Gehen tut alles, sowohl compilieren als auch herunterladen.
Das steht aber im Gegensatz zur Idee, die mit Docker Images einher kommt.

Die Ganze Idee ein docker Image für fhempy zu bauen kam ja daher, dass jemand versucht hatte, fhempy in dem "FHEM" Container zum laufen zu bringen. Für den FHEM Container wurden vor langer Zeit Entscheidungen getroffen die heute nur schwer auszubügeln sind.
In dem Container, der eher einem vollwertigen OS mit seinen 1,3 GB ähnelt, sind etliche Bibliotheken und compiler usw. vorhanden. Dennoch kann man da nicht einfach mal ein Paket (z.B. fhempy) zum laufen Bringen. Es ist eher ein Glücksfall ob es klappt oder nicht. Wenn wir den Weg nun für den fhempy container einschlagen, landen wir wirder bei den gleichen Problemen die der FHEM Container heute schon hat.

Der Hinweis mit den wheel Packages war, dass bei homeassistant wheels gebaut werden die in einem repository abliegen. Wenn ich annehme, dass dort alle packages als wheel abliegen, dann entfällt der compiler sowie die Bibliotheken, allerdings wird dann immer noch für jede Installation eines packages ein layer aufgebaut.

[jfmennedy]

Hi, ich klink mich hier mal ein. Ich habe fhempy im offiziellen fhem Container laufen und das fast problemlos, sowohl mit fhempy local als auch als Peer... Bin dann wahrscheinlich der Glücksfall... Ich habe auch den fhempy Container getestet. Lief soweit eigentlich ganz gut, jedoch wenn es eine exeption gab, hat sich der container schlafen gelegt und musste manuell neu gestartet werden.

[sidey79]

Ich habe auch den fhempy Container getestet. Lief soweit eigentlich ganz gut, jedoch wenn es eine exeption gab, hat sich der container schlafen gelegt und musste manuell neu gestartet werden.

Mit welcher Version des Images hattest Du dieses Verhalten?

[jfmennedy]

Oh schwierig zu sagen.. Das war die Version von vor ca 2 Wochen. Fhempy version um die 0.1.477..

[sidey79]

Hmm naja, seit Version 1.0 ist ein Health Check enthalten. Die gibt es seit 13 Tagen :)

https://github.com/fhem/fhempy-docker/releases/tag/v1.0

[jfmennedy]

OK, werde ich mal mein container aktualisieren und reaktivieren ;-)

Muss wohl schon die letzte Version installiert gehabt haben... Also auch mit health check startet der Container leider nicht neu..

[sidey79]

Für amd64 ist es wie immer recht einfach.
Die wheels lassen sich in vertretbarem Aufwand erzeugen und auch cachen.
Diese kann ich auch in das Image mit einbauen. Sind so 120 MB.

Installieren lassen sich die wheels allerdings nicht, was die bessere Lösung wäre, da es von manchen packages mehrere Versionen in den Abhängigkeiten gibt.
Ich könnte mir vorstellen, das manche Module daher
auch ohne docker Container nicht in Kombination laufen.

Auf ARM sieht das leider etwas anders aus.
Der Prozess läuft dort prinzipiell natürlich auch da, allerdings ist der Job nach 5h auf einen Fehler in irgend einem Paket gelaufen und konnte kein wheel erstellen.

Gefühlt bin ich also wieder am Ursprünglichen Problem der Abhängigkeiten der Python Pakete.

[fhempy]

Ich denke wir können das Issue hier schließen.

[sidey79]

@fhempy

Ich habe mich nun in die Tiefen von wheels, builds usw. begeben und kann ähnlich wie das home-assistant mach, prinzipiell alle wheels inkl. der in den Modulen referenzierten in einer Pipeline bauen lassen.

Nun habe ich das ganze versuchsweise mit google_weather durchlaufen lassen. Ich habe also alle wheels bauen lassen, die im Modul google_weather im manifest.json hinterlegt waren gebaut.
Dann habe ich natürlich auch alle wheels für die requirements von fhempy bauen lassen.
Am Ende habe ich ein docker image mit fhempy generiert in dem wheels für eine spätere Installation liegen.

Nach meinem Verständnis, hätte jetzt alles was fhempy zum starten braucht vorhanden sein müssen.
Ebenso sollte das Modul google_weather verwendet werden können, was zum Glück auch der Fall ist.

So etwa 9 millisekunden, nachdem fhempy im container gestartet wurde, wird das python Paket async-upnp-client vermisst:
https://github.com/fhem/fhempy-docker/actions/runs/3304324934/jobs/5453563233#step:12:72
Das fehlt auch weiterhin. Für die paar Sekunden in denen der rudimentäre Test lief war das dann wohl auch kein größeres Problem.

Mich wundert jetzt aber natürlich, das es einen Installationsversuch des Paketes gibt.
Fehlt das als Abhängigkeit in den requirements von fhempy oder habe ich was anderes übersehen?

[fhempy]

Hi,

async upnp Client ist hier:
https://github.com/fhempy/fhempy/blob/master/FHEM/bindings/python/fhempy/lib/core/manifest.json

[sidey79]

Ok, woher weiss ich, dass dieses Modul verwendet wird? Ich dachte bislang, die Module werden je nach Bedarf geladen. Je nachdem, was per define in FHEM definiert ist.

Ich könnte jetzt nicht finden, wo eine Abhängigkeit auf das Modul "core" vermerkt wird.
Hintergrund, ich will dir Abhängigkeiten passend erkennen, damit das, was benötigt wird auch in der Pipeline erzeugt wird.