Monatsrückblick Juli / August 2026 ist online!

[Leonie]

Ihr Verrückten :D

Ich habe nun die letzten Stunden damit verbracht Container Images zu bauen. Habe die Services dafür verändert, meine Pipelines überarbeitet, aber hier ist nun das Composefile mit allem drin:

Spoiler

services:
 hannah-core:
   image: quay.io/m1kad0/hannah-core:latest
   container_name: hannah-core
   restart: unless-stopped
   pull_policy: always
   depends_on:
     mysql-db:
       condition: service_healthy
       required: false
     mosquitto:
       condition: service_healthy
       required: false
   ports:
     - "50051:50051"
   networks:
     - hannah_network
   volumes:
     - core_activity_audio:/app/activity_audio
     - core_audio_dumps:/app/audio_dumps
     - core_data:/app/data
     - ./core-config.yaml:/etc/hannah/config.yaml:ro

 hannah-webui:
   image: quay.io/m1kad0/hannah-webui:latest
   container_name: hannah-webui
   restart: unless-stopped
   pull_policy: always
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   ports:
     - "5000:5000"
   environment:
     HANNAH_WEBUI_SECRET_KEY: "SGVsbG8gV29ybGQhIFRoaXMgaXMgYSByYW5kb20gMTI4LWNoYXJhY3RlciBCYXNlNjQgc3RyaW5nIGNyZWF0ZWQgZm9yIHRlc3RpbmcgcHVycG9zZXMubmNlMXkyMw=="
     HANNAH_WEBUI_GRPC_HOST: "hannah-core"
     HANNAH_WEBUI_GRPC_PORT: "50051"

 hannah-telegram:
   image: quay.io/m1kad0/hannah-telegram:latest
   container_name: hannah-telegram
   restart: unless-stopped
   pull_policy: always
   profiles: ["full", "integrations", "telegram"]
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   volumes:
     - ./telegram-config.yaml:/etc/hannah-telegram/config.yaml:ro

 hannah-proxy:
   image: quay.io/m1kad0/hannah-proxy:latest
   container_name: hannah-proxy
   restart: unless-stopped
   pull_policy: always
   profiles: ["full", "with-proxy"]
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   volumes:
     - ./proxy-config.yaml:/etc/hannah-proxy/config.yaml:ro

 hannah-voiceid:
   image: quay.io/m1kad0/hannah-voiceid:latest-cpu
   container_name: hannah-voiceid
   restart: unless-stopped
   pull_policy: always
   profiles: ["full", "with-voiceid"]
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   volumes:
     - ./voiceid-config.yaml:/etc/hannah-voiceid/config.yaml:ro
     - hannah_mem:/mnt/hannah_mem

 hannah-timer:
   image: quay.io/m1kad0/hannah-timer:latest
   container_name: hannah-timer
   restart: unless-stopped
   pull_policy: always
   profiles: ["full", "with-timer"]
   depends_on:
     - hannah-core
   networks:
     - hannah_network
   environment:
     HANNAH_TIMER_HANNAH_ADDRESS: "hannah-core:50051"
     HANNAH_TIMER_LOG_LEVEL: "info"
   volumes:
     - timer_data:/app/data

 mysql-db:
   image: mysql:8.0
   container_name: hannah-db
   profiles: ["full", "with-db"]
   environment:
     MYSQL_ROOT_PASSWORD: secretpassword
     MYSQL_DATABASE: hannah_db
     MYSQL_USER: hannah_user
     MYSQL_PASSWORD: hannah_pass
   networks:
     - hannah_network
   volumes:
     - mysql_data:/var/lib/mysql
   healthcheck:
     test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-psecretpassword"]
     interval: 5s
     timeout: 5s
     retries: 5

 mosquitto:
   image: eclipse-mosquitto:2
   container_name: hannah-mosquitto
   profiles: ["full","with-mqtt"]
   restart: unless-stopped
   networks:
     - hannah_network
   ports:
     - "1883:1883"
     - "9001:9001"
   volumes:
     - mosquitto_data:/mosquitto/data
     - mosquitto_log:/mosquitto/log
     - ./mosquitto.conf:/mosquitto/config/mosquitto.conf:ro
   healthcheck:
     test: ["CMD-SHELL", "nc -z localhost 1883 || exit 1"]
     interval: 5s
     timeout: 3s
     retries: 5

volumes:
 core_data:
 core_activity_audio:
 core_audio_dumps:
 timer_data:
 mysql_data:
 mosquitto_data:
 mosquitto_log:
 hannah_mem:

networks:
 hannah_network:
   driver: bridge

Gestartet werden kann der ganze Stack bspw. so: docker compose --profile full up -d
Am Besten tauscht ihr dann auch entsprechende Secrets aus, alles in dem File ist von meiner Seite aus Demo, aber voll getestet.

Für VoiceID habe ich eine cpu-only Version bereitgestellt. Eine Version mit GPU-Unterstützung kann ich aktuell nicht bauen, zumindest nicht automatisiert.

Mitgestartet wird auch ein MySQL-Server, der für den Activity Log genutzt wird. Warum ein MySQL-Server? Weil Hannah bei mir komplett auf einem Raspberry Pi läuft und ich mit der Datenbank für den Activty Log, die naturgemäß eine Menge Schreiboperationen aufweisen kann, die SD-Karte nicht belasten will.
Außerdem wird ein Mosquitto, als MQTT-Broker gestartet. Ich denke der ein oder andere von euch wird bereits einen Broker einsetzen, für alle anderen, ist hier die Vorlage.

Ich habe euch auch gleich einen Service dazu gepackt, den ich noch nicht vorgestelt habe: hannah-timer. Das ist ein Timerbackend für Core. Der hält alle Timer die Core stellen mag persistent. Egal ob man Wecker stellt, ob man sich an irgendwas erinnern lassen möchte oder einfach nur einer Eieruhr stellt, dieser Service sorgt für die Integrität.
Warum ein eigener Service? In der Entwicklung hat sich gezeigt das Core bei mir öfter neustarten muss, auch bspw. aufgrund von Updates. Timer ist so stabil, das er bereits seit Monaten bei mir ohne Downtime laufen kann. Außerdem kann so die ganze Timer-Logik aus dem Core draußen bleiben. Timer informiert Core aktiv, wenn ein Timer abgelaufen ist und stellt ihm wieder die Informationen bereit, die Core braucht um Aktionen zu ergreifen.

Eventuell bekommen in Zukunft noch weitere Services Unterstützung fürs Environment. Ich verstehe schon, das es sich doof anfühlt bspw. für den Proxy eine Configdatei mit 6 Zeilen zu schreiben, während timer bspw. Environment-Variablen hat. Faktisch unterstützen die meisten Services es nicht, da sind dann Configs notwendig.

Und natürlich werden die Images jetzt nicht bei mir gehostet, das heißt, die sollten zu jeder Zeit abrufbar sein :D

Liebe Grüße
Leonie

[Leonie]

@manne01 sagte:

Meinen Telegram Account zu verbinden - es kommt "Bot domain invalid" und meine "lokale" Domain bei Telegram mit /setdomain zu verknüpfen macht doch irgendwie keinen Sinn? Zur Domainregistrierung finde ich kaum Infos.

Ich ziehe das nochmal nach.
Leider habe ich selbst keinen Einfluss auf das was Telegram verlangt. Hannah nutzt ein "Login with Telegram" in der WebUI für die Verknüpfung. Dafür benötigt der BotFather eine Domain, die Domain unter der die WebUI erreichbar ist.
Leider funktionieren da keine IP-Adressen und keine lokalen Domains. Telegram erfordert eine öffentliche überprüfbare Domain. Nicht falsch verstehen, die WebUI muss nur eine öffentliche Domain nutzen, nicht aus der Öffentlichkeit erreichbar sein.
Ja, ist nicht ideal, aber den Ablauf gibt leider Telegram vor.
Ich selbst habe glücklicherweise eine eigene Domain. Unter der kann ich meine WebUI aufrufen und Telegram ist glücklich. Damit ich die aber aufrufen kann, muss ich zu Hause sein. Aus dem Internet geht es nicht.
An der Stelle mag ich schonmal sagen, das eine DynDNS-Adresse bspw. von MyFritz! schon ausreichend ist, damit der BotFather zu Frieden ist.

Liebe Grüße
Leonie

[manne01]

Wow🤩 Freue mich riesig drauf das Compose einzurichten und melde mich wieder.
DANKE @Leonie !
Ich hoffe dass das den Anwenderkreis am Ende auch nochmal so deutlich erweitert wie ich mir das vorstelle👍

Okay, und eine Domain habe ich grundsätzlich schon auch, ich probiere es damit nochmal.

[OliverIO]

@Leonie sagte:

An der Stelle mag ich schonmal sagen, das eine DynDNS-Adresse bspw. von MyFritz! schon ausreichend ist, damit der BotFather zu Frieden ist.

wer einen port nach außen öffnet, sollte unbedingt einen
reverse proxy einsetzen um die Angriffsfläche zu verkleinern.
Weiterhin das noch mit fail2ban absichern, was aber ein wenig Beobachtung und Konfiguration erfordert

beides ist als dockercontainer verfügbar.
einen container mit dem reverse proxy ist sehr einfach
durch ein paar zusätzliche Anweisungen im docker compose welcher dann im internet auf anfragen horchen soll.
https://hub.docker.com/r/jwilder/nginx-proxy
https://hub.docker.com/r/linuxserver/fail2ban

kleine werbung in eigener Sache: Wer fail2ban mit einer webgui überwachen möchte kann sich diesen Container anschauen, leider ist die kommandozeile von fail2ban etwas grausam:
https://hub.docker.com/r/oweitman/fail2bancontrol
und zur Überwachung im iobroker:
https://github.com/oweitman/ioBroker.fail2bancontrol

[Leonie]

@OliverIO sagte:

wer einen port nach außen öffnet

Das muss es auch nicht. Davon habe ich nichts gesagt. Die Adresse muss existieren und hausintern erreichbar sein. Mehr nicht.

Ich habe nochmal alles überprüft und habe hier eine bessere Anqleitung/Erklärung:

Telegram-Konto mit Hannah verknüpfen — Setup & Voraussetzungen

Über die WebUI (/me) kann jeder Nutzer sein eigenes Telegram-Konto mit seinem Hannah-Account verknüpfen (z.B. für Benachrichtigungen). Damit der Button dafür überhaupt erscheint, muss der Betreiber der Hannah-Instanz vorher einmalig etwas einrichten.

Was man braucht

1. Einen Telegram-Bot (Token + Username)
2. Eine Domain, unter der die WebUI erreichbar ist
3. HTTPS auf der WebUI (Zertifikat darf selfsigned sein)
4. Bot-Daten in der WebUI-Konfiguration eingetragen

Schritt für Schritt

1. Bot bei BotFather anlegen

In Telegram mit @BotFather chatten, /newbot ausführen. Man bekommt danach:

• einen Bot-Token (z.B. 123456789:AAExxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
• einen Bot-Usernamen (z.B. MeinHannahBot)

2. Domain beim Bot freischalten

Ebenfalls bei BotFather: /setdomain ausführen und die Domain eintragen, unter der die WebUI erreichbar ist (z.B. hannah.mein-zuhause.duckdns.org).

Wichtig: Ohne diesen Schritt lehnt Telegram den Login-Versuch direkt ab, noch bevor er bei der WebUI ankommt.

3. Bot-Daten in der WebUI eintragen

In config.yaml:

```yaml
telegram_bot_token: "123456789:AAExxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
telegram_bot_username: "MeinHannahBot"
```

Oder bei Docker-Deployment als Umgebungsvariablen:

```
HANNAH_WEBUI_TELEGRAM_BOT_TOKEN=123456789:AAExxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
HANNAH_WEBUI_TELEGRAM_BOT_USERNAME=MeinHannahBot
```

Fehlt eines von beiden, zeigt /me nur den Hinweis "Telegram-Verknüpfung ist auf diesem Server nicht konfiguriert." — kein Fehler, einfach kein Button.

Häufige Fragen zur Domain

Reicht eine DynDNS-Domain (DuckDNS, No-IP, …)?
Ja. Telegram vergleicht die Domain nur als Text (das, was bei /setdomain hinterlegt wurde, gegen das, was die WebUI beim Login-Versuch mitschickt) — es wird nicht per DNS aufgelöst oder angepingt. Dass sich die IP dahinter ständig ändert, spielt also keine Rolle.

Muss das TLS-Zertifikat "echt" sein (Let's Encrypt o.ä.)?
Nein, ein selfsigned Zertifikat reicht. Grund: Telegrams Server verbinden sich nie direkt mit der WebUI. Der komplette Rücksprung läuft über den Browser des jeweiligen Nutzers:

1. Browser → oauth.telegram.org (Nutzer bestätigt dort den Login)
2. Telegram leitet den Browser zurück zur WebUI, mit den signierten Login-Daten im Gepäck
3. Ein kleines Skript auf der WebUI-Seite nimmt diese Daten entgegen und schickt sie an die WebUI

Der Browser ist es also, der die TLS-Verbindung zur WebUI aufbaut — nicht Telegram. Ein selfsigned Zertifikat funktioniert, solange der jeweilige Nutzer es akzeptiert (Klick durch die Warnung, oder eigene CA im Trust-Store).

Muss die WebUI öffentlich aus dem Internet erreichbar sein? Braucht es Portfreigabe?
Nein. Aus demselben Grund wie oben: Da nur der Browser des Nutzers die WebUI kontaktiert (nie Telegram selbst), reicht es, wenn der Browser die WebUI erreichen kann — z.B. im Heimnetz oder per VPN. Keine Portfreigabe, keine öffentliche Erreichbarkeit nötig.

Aber Achtung:
Die Domain, über die man auf die WebUI zugreift, muss exakt die sein, die bei /setdomain hinterlegt wurde. Wer mal über die DynDNS-Domain und mal über eine lokale IP/einen anderen Hostnamen auf die WebUI geht, bekommt den Login-Button nur bei der registrierten Domain zu sehen bzw. der Login schlägt sonst fehl. Ich muss allerdings auch sagen, dass das nur für die Verknüpfung selbst relevant ist. Ist der Account einmal verbunden, braucht man das Widget nie wieder, bzw. erst wieder, wenn man die Verbindung trennen möchte.

Der Ablauf beim eigentlichen Verknüpfen (zur Info)

1. Nutzer klickt auf /me den Telegram-Button → Redirect zu Telegram
2. Nutzer bestätigt dort den Login
3. Telegram schickt die signierten Daten zurück — technisch als URL-Fragment (#...), das kommt beim Server gar nicht an
4. Ein JS-Snippet auf der Seite liest das Fragment im Browser aus und leitet es als normalen Request an die WebUI weiter
5. Die WebUI prüft die Signatur (mit dem Bot-Token) und dass die Anfrage nicht älter als 5 Minuten ist
6. Passt alles → Konto ist verknüpft

Typische Stolperfallen

Problem	Ursache
Login-Button erscheint gar nicht	telegram_bot_token oder telegram_bot_username fehlt in der Config
Telegram bricht schon vor der WebUI ab	Domain bei /setdomain falsch/vergessen, oder stimmt nicht mit der tatsächlich aufgerufenen Domain überein
"ungültige oder abgelaufene Signatur"	Bot-Token in der Config falsch/vertippt, oder Nutzer hat länger als 5 Minuten gebraucht, um den Login bei Telegram zu bestätigen

[OliverIO]

@Leonie

Sorry, kannte bisher nur die webhook Methode um auch Nachrichten empfangen zu können.
Hab gesehen das es auch die long polling Methode gibt.
Dafür brauch man dann keinen Port nach außen.

[Walter.O.]

@leonie
Denkst du noch an mich?
Habe es gerade mal auf meinem Linux PC versucht,
das irritiert mich jetzt aber. Der core ist da ja noch garnicht draufgewesen.

curl -fsSL https://raw.githubusercontent.com/NurPech/hannah/master/core/deploy/install.sh | sudo bash
[sudo: authenticate] Passwort:
[INFO] Fetching latest core release from https://hannah-update.sgessinger.de (channel: core-stable) ...
[INFO] Latest version: v0.75.7
walter@walter-pc:~$ systemctl status hannah
Unit hannah.service could not be found.

[manne01]

Guten Morgen,

@walter.o. Dir vielen dank für die Infos und erste Fassung der Dockerfiles - das hatte mir ermöglicht direkt schonmal einen Durchstich zu machen von Spracheingabe Telegram bis funktionierender ioBroker-Statusänderung und Sprachrückgabe :)

@Leonie vielen Dank für die CI Pipeline und das Compose.
Ich find das klasse, besonders auch zB dass die diversen configs des Stacks jetzt nebeneinander liegen.
Es funktioniert damit schon einiges aber noch läuft die core nicht.

Folgende kleine Änderungen habe ich gemacht, damit es für mein Setup läuft:
a) Auskommentieren der Zeilen mit "profiles" - die blockieren wohl irgendwas im Synology Container Manager (Fehlermeldung beim compose-build dann "service mysql not found" o.ä.), scheinen auch optional zu sein
b) mosquitto broker auskommentiert, habe ich in iobroker schon
c) den volumes-Block unten gelöscht und stattdessen bei den Container-Definitionen die Unterordner (core_data/timer_data...) jeweils auf von mir erstellte Unterordner von /volume1/docker/hannah (in dem Verzeichnis in dem die compose liegt)

Was läuft:

• mysql
• webUI - jetzt mit static assets
• voiceid
• telegram
• proxy

Was läuft nicht (im sinne von container bleibt oben/terminiert nicht):

• hannah timer bringt fehler und terminiert regelmäßig (wartet der auf core?)

{"time":"2026-08-30T08:45:33.408807593Z","level":"INFO","msg":"starting hannah-timer","version":"dev","hannah_addr":"hannah-core:5051","db":"/app/data/timers.db"} 
{"time":"2026-08-30T08:45:33.409175976Z","level":"ERROR","msg":"opening store","err":"running migrations: unable to open database file (14)"} 

• die core, Log:

07:54:54 [INFO] hannah.main: Hannah Core dev
Traceback (most recent call last):
  File "/app/main.py", line 2257, i <module>
    main()
    ~~~~^^
  File "/app/main.py", line 101, in main
    init_db()
    ~~~~~~~^^
  File "/app/hannah/utils/db.py", line 216, in init_db
    db = get_db()
  File "/app/hannah/utils/db.py", line 201, in get_db
    db = Database.sqlite(DB_PATH)
  File "/usr/local/lib/python3.14/site-packages/pyorm/database.py", line 22, in sqlite
    return cls(dialect.connect(database=database, **kwargs), dialect)
               ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/pyorm/dialects/sqlite.py", line 21, in connect
    connection = sqlite3.connect(check_same_thread=False, **kwargs)
sqlite3.OperationalError: unable to open database file

Bin nicht sicher wie das gedacht ist - neben der mysql (wenn ich es richtig verstehe ist die nur für Activities) muss ja die WebUI/Core ihre Settings etc. irgendwo speichern. Wenn ich es richtig verstehe ist das eine kleine sqlite.db (hannah.db?)
Gefunden hab ich in der core-config.yaml "nur" eine Angabe für hannah_users.db ?

user_registry:
  db_path: "hannah_users.db"   # SQLite-Datei (relativ zum Arbeitsverzeichnis)
  sync_interval: 60            # Sekunden zwischen ioBroker-Abfragen

Ist da trotz des Namens alles drin? Oder gibts mehrere db.files? Im Code habe ich auch eine hanna.db gefunden und weitere (zb rooms/memory.db)

Auch müsste diese Datenbank ja noch aus dem Container raus und vom volume her auf den Host ausgelagert werden, so dass man auf dem Host alles wichtige außerhalb von Containern hat, backup machen kann etc.

Aufgefallen ist mir noch dass innerhalb des Ordners mysql_data ein Ordner hannah_db angelegt wurde, ist aber leer.
./core_data ist auch leer (gemountet in den Container nach /app/data)

Ich hoffe das sind nur noch Kleinigkeiten. Viele Grüße!

[Luxi]

Hallo @leonie
Vielen Dank erstmal einmal für deine tolle Arbeit.
Zum Thema Satelliten:

• wie weit bist du denn mit der Evaluierung von PCPway Zwecks dem Shared Projekt?
• könntest du die nötigen Dateien für eine Produktion zur Verfügung stellen?
  LG Luxi

[Leonie]

Hi,

@Walter.O. sagte:

Denkst du noch an mich?

Ja, aber ich habe auch ein Privatleben :)

@manne01 sagte:

Bin nicht sicher wie das gedacht ist

Beide Fehler kommen zu 100% von deiner Änderung mit den Volumes. Ja, der Volumeblock ist optional, schließlich beschreibt der names Docker Volumes die von compose verwaltet werden. Weil du aber lieber Bind mounts nutzten willst, musst du die Dateirechte entsprechend anpassen.

@manne01 sagte:

"nur" eine Angabe für hannah_users.db

Der Configwert existiert bereits seit langer Zeit nicht mehr und ist in der aktuellen config.example.yaml entfernt. In meiner Container-Version wird die Datenbank nach /app/data gespeichert, weil da das Volume eingehangen wird, ist die Datenbank dann peristent. Die dedizierte hannah_users.db wird nicht verwendet.

Die memory.db ist der Langzeitspeicher für das LLM. Sozusagen die low-budget-Variante einer VectorDB. Konfigurieren kannst du die bspw. so:

llm:
  db: "/app/data/memory.db"

@manne01 sagte:

innerhalb des Ordners mysql_data ein Ordner hannah_db angelegt

Das ist auch ein Fehler von dir ;) bzw. eine Eigenheit von Docker. Um dir mehr dazu zu sagen, müsstest du mir dein Compose File geben.

@Luxi sagte:

Evaluierung von PCPway

PCBway scheint ein guter Partner dafür zu sein

@Luxi sagte:

nötigen Dateien für eine Produktion

Hier habe ich einen Interessenskonflikt. Ja, die ESPs funktionieren, aber nicht fehlerfrei. Es gibt Bugs bei denen ich aktuell nicht weiß ob sie in er Firmware oder der Hardware liegen. Ich kann das Projekt dort anlegen, dann könnt ihr es bestellen, aber zu 100% glücklich bin ich noch nicht und das widerstrebt meinem Perfektionismus.

Liebe Grüße

[Leonie]

@walter.o.

Ich habe mir mal eben ein Ubuntu 26.04 installiert. Bei mir ist das Install-Script gesprächiger?

administrator@hannah-test:~$ curl -fsSL https://raw.githubusercontent.com/NurPech/hannah/master/core/deploy/install.sh | sudo bash
[sudo: authenticate] Password:
[INFO]  Fetching latest core release from https://hannah-update.sgessinger.de (channel: core-stable) ...
[INFO]  Latest version: v0.75.7
[OK]    Downloaded v0.75.7.
[OK]    Extracted to /opt/hannah/core.
[INFO]  Creating Python venv ...
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

    apt install python3.14-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

Failing command: /opt/hannah/core/venv/bin/python3

administrator@hannah-test:~$

Nach der installation von python3.14-venv, habe ich das nochmal gestartet:

administrator@hannah-test:~$ curl -fsSL https://raw.githubusercontent.com/NurPech/hannah/master/core/deploy/install.sh | sudo bash
[INFO]  Fetching latest core release from https://hannah-update.sgessinger.de (channel: core-stable) ...
[INFO]  Latest version: v0.75.7
[OK]    Downloaded v0.75.7.
[OK]    Extracted to /opt/hannah/core.
[INFO]  Installing Python dependencies ...
bash: line 85: /opt/hannah/core/venv/bin/pip: No such file or directory
 ls /opt/hannah/core/venv/bin/
python  python3  python3.14  𝜋thon
administrator@hannah-test:~$

Und siehe da, Pip wurde im venv nicht installiert. Eine kurze Recherche von mir ergab, das Ubuntu das aus Ressourcengründen nicht installiert.

Ein Befehl bringt Abhilfe:

administrator@hannah-test:~$ sudo /opt/hannah/core/venv/bin/python3 -m ensurepip --default-pip
Looking in links: /tmp/tmpjq2mpmmu
Processing /tmp/tmpjq2mpmmu/pip-25.1.1-py3-none-any.whl
Installing collected packages: pip
Successfully installed pip-25.1.1
administrator@hannah-test:~$ ls /opt/hannah/core/venv/bin/
pip  pip3  pip3.14  python  python3  python3.14  𝜋thon
administrator@hannah-test:~$

Dann läuft die Installation auch korrekt durch:

administrator@hannah-test:~$ curl -fsSL https://raw.githubusercontent.com/NurPech/hannah/master/core/deploy/install.sh | sudo bash
[INFO]  Fetching latest core release from https://hannah-update.sgessinger.de (channel: core-stable) ...
[INFO]  Latest version: v0.75.7
[OK]    Downloaded v0.75.7.
[OK]    Extracted to /opt/hannah/core.
[INFO]  Installing Python dependencies ...

[OK]    Python dependencies installed.
[INFO]  Creating system user 'hannah' ...
[INFO]  Created /etc/hannah — place your config.yaml there.
[OK]    Service unit installed.
[OK]    Installed v0.75.7. Place config.yaml in /etc/hannah and run:
[OK]      systemctl enable --now hannah
administrator@hannah-test:~$ sudo systemctl enable --now hannah
Created symlink '/etc/systemd/system/multi-user.target.wants/hannah.service' → '/etc/systemd/system/hannah.service'.
administrator@hannah-test:~$

Ubuntu scheint da ein paar Besonderheiten zu haben. Ich denke das ensurepip kann ich in den Install-Scripten einbauen. Die Paketinstallationen überlasse ich aber lieber euch.

Warum die Scripte bei dir komplett stumm bleiben, kann ich nicht sagen. Das muss irgendwas mit deinem System zu tun haben. Getestet habe ich auf stock Ubuntu 26.04, frisch installiert.

Liebe Grüße

[manne01]

@Leonie Danke Dir für die erneute und schnelle Rückmeldung!
Hab mir das mit den Datenbanken nochmal angeschaut und ja, mich hat folgendes verwirrt:
im COMPOSE ist überall "hannah":

mysql-db:
   image: mysql:8.0
   container_name: hannah-db
   profiles: ["full", "with-db"]
   environment:
     MYSQL_ROOT_PASSWORD: secretpassword
     MYSQL_DATABASE: hannah_db
     MYSQL_USER: hannah_user
     MYSQL_PASSWORD: hannah_pass

vs. in deinem Beitrag oben ist es "Activity-DB":

Mitgestartet wird auch ein MySQL-Server, der für den Activity Log genutzt wird. 

Ich dachte kurzzeitig die hannah.db soll auch in mysql oder würde dort automatisch erkannt etc. Nachdem ich nun aber annehme dass hannah.db eine sqlite ist und bleibt (und ja, die rechte fehlten, daher hat der core die nicht anlegen können) habe ich im compose alles mit "hannah-db" auf activity umgemünzt, damit da draufsteht was drin ist (also entsprechend der core-config in "activity_db" benannt und user usw. ebenso.)

Ich hoffe ich habe jetzt bzgl. der Datenbanken alles richtig verstanden!

Die Kerstin-Dateien musste ich noch daneben legen, das meldet ja auch das log. Wäre es eine Idee die standardmässig/als Default mitzuliefern? Ändern kann ja dann jeder selber.

Jetzt läuft jedenfalls alles mit dem neuen Compose und alle Container und Logs schauen happy aus! Jetzt muss ich wohl erstmal in ioBroker meine ganzen Objekte/Geräte kategorisieren... Ich vermute da ist erstmal das virtual device script (von dem ich bisher nur mal gelesen habe) hier die Empfehlung der Wahl?

Viele Grüße!

[Leonie]

Hi,
Ja, grade die Datenbanken sind etwas unglücklich benannt von mir. Der MySQL-server ist wirklich nur für den Activity Log. Alle anderen Daten liegen in einer sqlite. Zwar kann das Storage-Backend auch MySQL (sonst würde es den Activitiy Log gar nicht geben), das kam aber erst mit dem Log, da waren die anderen Teile schon zu weit. Und eine Migration zu schreiben, hatte ich bisher noch keinen Need. Und umbedingt einen externen MySQL-Server vorzuschreiben, während der Activity Log ja optional ist, kommt mir auch nicht passend vor.

@manne01 sagte:

Wäre es eine Idee die standardmässig/als Default mitzuliefern?

Ob ich die Daten mitliefern darf, weiß ich gar nicht, das müsste ich mit HuggingFace klären. Vermutlich dürfte aber nichts dagegen sprechen einen Downloader einzubauen für die Datei, der die automatisch ins Data-Dir bringt. Muss ich aber auch klären und Lizenzen sind ja immer so ein Thema.

@manne01 sagte:

Ich vermute da ist erstmal das virtual device script

Nein, nicht zwingend. Ich nutze ioBroker schon sehr lange und seit vielen Versionen. So gab es bspw. keine komfortable Möglichkeit für Aliase und ich hatte ioBroker bspw. für Hue-Leuchten genutzt. Wenn ich dann eine Leuchte getauscht habe, war die natürlich in der ObjektDB ein neues Objekt und ich musste alle Scripte, Trigger und Aktionen bearbeiten. Da habe ich dann das virtualDevice-Script hier im Forum gefunden, was im Prinzip Objekte "kopiert", also eigene Objekte, für physisiche Objekte erstellt. So habe ich das Objekt "Wohnzimmerlampe" das auf die Zigbee-Adresse 0x00001245 (willkürlich eingetippt) mappt. Wird "Wohnzimmerlampe" eingeschaltet, wird die Zigbee-Adresse geschaltet.
Was das Script mir auch bietet und warum ich es nicht missen will: Ich habe einen Zoo an smarter Hardware. Mensche Sensoren von Bosch, andere von Homatic, manche laufen über Tasmota und wieder andere kommen vom KNX. Was sich so über die Jahre historisch angesammelt hat. Alle verwenden aber unterschiedliche Daten. Fenstersensoren von Bosch melden bspw. "OPEN" und "CLOSED", Homematic liefert "true" und "false". Das Script kann mir das konvertieren, so das meine "virtuellen" Fenstersensoren immer true oder false haben, egal welche Hardware dahinter ist.
Das wiederrum gibt mir die Möglichkeit da sich in sämtlichen Scripten nicht darauf achten muss, welche Sensoren oder Aktoren ich benutze, weil ich ja alles auf ein spezifisches Format bringe.

Und weil ich eben dieses Script nutze und Hannah am Anfang ihrer Entstehung die States über MQTT empfing, habe ich auch bei ihr mit dem Script im Kopf gearbeitet. So kommt bspw. im initalpost die Vorraussetzung das man das Script nutzt.
Tatscählich hat sich Hannah in den Monaten aber stetig weiterentwickelt. So ist auch die MQTT-Anbindung zum ioBroker entfernt und durch den wesentlich mächtigeren Adapter ersetzt worden. Natürlich läuft in meinem Produktionssytem noch immer das virtual Device Script und das werde ich auch nicht abschalten. Getestet habe ich Hannah aber auch gegen einen nativen ioBroker, heißt mit nativen Geräten, ohne Konvertierungsscript.
Wichtig für Hannah ist, das die Geräte Räumen und die States Funktionen zugewiesen sind. Das ist mit einer gewissen Arbeit verbunden.
Im Adapter kann man dann die Kombination an Räumen und Funktionen wählen, die an Hannah gesendet werden. Der Adapter versucht dann quasi auf best-effort-Basis, die States in ioBroker zu interpretieren. Wird bspw. die Funktion "Fenstersensor" ausgelesen im Raum "Badezimmer", geht der Adapter davon aus, wenn es einen boolean-State gibt, das der offen/geschlossen repräsentiert. Das übersetzt der dann in das "Hannah-Protokoll" und sendet das an den Core. Der Core ist in der Beziehung also eigentlich recht "dumm", er verwendet genau die Daten die der Adapter sendet.
Das Verhalten vom Adapter kann man auf mehrere Arten beeinflussen. So kann man States bspw. eigene Eigenschaften hinzufügen, die dem Adapter mitteilen, wie er den State zu nutzen hat.
An der Stelle möchte ich anmerken, das ich nicht weiß mit welchen Geräten/welchen States der Adapter funktioniert, er tut es mit den Geräten die ich habe auf jeden Fall.

So, ist nun wieder recht viel geworden, aber ich hoffe das beantwortet deine Fragen.

Liebe Grüße

[manne01]

PS: eins ist mir grad noch aufgefallen - ffmpeg scheint im core-container noch zu fehlen. Aus dem core-log:

18:50:10 [INFO] hannah.grpc_server: [grpc] SubmitVoice von telegram:8752210440 (user=2, 85487 bytes)
18:50:10 [ERROR] grpc._server: Exception calling application: [Errno 2] No such file or directory: 'ffmpeg'
Traceback (most recent call last):
  File "/usr/local/lib/python3.14/site-packages/grpc/_server.py", line 608, in _call_behavior
    response_or_iterator = behavior(argument, context)
  File "/app/hannah/grpc_server.py", line 549, in SubmitVoice
    transcript, answer, intent_name, audio_ogg = self._handle_voice(
                                                 ~~~~~~~~~~~~~~~~~~^
        request.audio, user_id,
        ^^^^^^^^^^^^^^^^^^^^^^^
        channel_type=request.source_service or "grpc_voice", channel_id=request.source_user_id,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/app/main.py", line 1462, in _handle_voice
    proc = subprocess.run(
        ["ffmpeg", "-y", "-i", ogg_path,
         "-f", "s16le", "-ac", "1", "-ar", "16000", "-"],
        capture_output=True,
    )
  File "/usr/local/lib/python3.14/subprocess.py", line 555, in run
    with Popen(*popenargs, **kwargs) as process:
         ~~~~~^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/subprocess.py", line 1039, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        pass_fds, cwd, env,
                        ^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
                        gid, gids, uid, umask,
                        ^^^^^^^^^^^^^^^^^^^^^^
                        start_new_session, process_group)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/subprocess.py", line 1990, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'ffmpeg'

[Leonie]

Ist gefixt in Tag-Version 0.75.8 oder re-pull von latest

[manne01]

Danke dir! Auch für die Erklärung bzgl. Iobroker Geräte-Konfiguration!

Der ffmpeg-Fehler kommt jetzt nicht mehr und meine Spracheingaben werden korrekt angenommen. Allerdings ist mir noch eine Fehlermeldung aufgefallen die wohl doch nicht weg war bei meinem letzten Beitrag. Das erklärt auch warum nur der Text und keine Sprachnachrichten mehr an mich zurück kommen wenn ich welche absende:

23:46:17 [ERROR] hannah.tts: TTS-Backend 'piper' Initialisierung fehlgeschlagen: [Errno 2] No such file or directory: '/app/data/de_DE-kerstin-low.onnx.json' 

In meinem compose sieht es für core so aus:
volumes:
- ./core_activity_audio:/app/activity_audio
- ./core_audio_dumps:/app/audio_dumps
- ./core-config.yaml:/etc/hannah/config.yaml:ro
- ./core_data:/app/data

Im Unterverzeichnis core_data liegen die beiden "Kerstin-Dateien". Die Rechte passen.

In core config sieht es so aus:

  model: "/app/data/de_DE-kerstin-low.onnx"   # leer = TTS deaktiviert

Ich hab jetzt gefühlt alle Kombinationen durchkonfiguriert. Egal was ich konfiguriere, er lädt sie nicht. Komme leider nicht mehr weiter.

Viele Grüße!