Neue Adresse: die ioBroker-Webseite liegt jetzt auf iobroker.com

[manne01]

Wow - vielen Dank @leonie für die Fixes und erneuten Erweiterungen. Ich habe Adapter und Core aktualisiert. Hinweis zu dem Screenshot mit dem Override für Hannah oben -> das ist eine UI an den Objekten, da wo auch History-Einstellungen sind (also nicht im Hannah-Adapter suchen wie ich zunächst...)

Ich denke der Core wurde aktualisiert - aber könnte man die Version der Komponenten beim Start ins Log schreiben - dann könnte man die besser validieren?

Aktuell teste ich mit Text-Messages per Telegram (wegen des noch gefühlt zu langen Roundtrips für Sprache zu Sprache) -> aber mich wundert welche Unterschiede es dort gibt? Solange die Sprache korrekt zu Text erkannt wird müsste es doch dasselbe sein wie eine direkte Textmessage, oder nicht?

Auch das Überschreiben von meinem "Rolladen Seite 1" klappt - und im Core-Log werden sie dann wie korrigiert aufgelistet.
Über die kanonischen State-Keys müsste ich noch mehr wissen was die jeweils machen, vielleicht kannst Du einen Link auf die Code-Stelle senden?

Die Statusabfrage und setzen klappt jetzt sehr viel besser:

"Wie ist der Zustand des Rolladen links in der Küche?" -> "Rolladen links im Küche: 100%" -> Top
"Bitte setze den Rolladen links in der Küche auf 50%?" -> "OK, 1 Gerät(e) geschaltet") -> Top
"Bitte schließe den Rolladen links in der Küche?" -> "Das kann ich leider nicht beantworten"
Kriegt man das irgendwie auch auf Auf und Zu gemappt?

"Wie ist der Zustand des Rolladen Seite im Schlafzimmer?" -> "Rolladen Seite im Schlafzimmer: 43%" -> Top
"Wie ist der Zustand des Rolladen Balkontür im Schlafzimmer?" -> hier wurden (mit einer Kopie derselben Textmessage) einmal alle Rolladen-Status im Schlafzimmer durchgegeben und mal nur der von der Balkontür. --> Etwas Eigensinn ist schonmal da :-)

Per Sprache wurde der Zusatz "Seite" mal nicht verstanden "[INFO] hannah.main: [grpc/voice] Transkript: 'Setze den Rolladen seit hier im Schlafzimmer auf 0%.' " raus -> da wurden dann alle Rolläden zugefahren.
Hat Hannah versucht alle 5 Geräte im Schlafzimmer auf 50% zu setzen? Das Log ist da widersprüchlich zur selben Anfrage:
"[INFO] hannah.main: [2] Antwort (SetLevel): 'OK, 3 Gerät(e) geschaltet.' "
vs.
"[INFO] hannah.iobroker: execute: SetLevel → 5 Gerät(e), state='level', value=50.0"

So oder so, auf der Basis schaue ich jetzt mal weiter nach viel mehr Objekten, dann auch mal außerhalb Homematic.

Viele Grüße und schönen Abend!

[Leonie]

Hi manne01,

danke für den ausführlichen Testbericht, das hilft enorm!

Zu den kanonischen State-Keys: Das sind die semantischen Rollen, auf die ein einzelner State intern reduziert wird — die Liste ist (aktuell): on, level, color, colorTemp, current, expected, illuminance, open, iaq, co2_equiv, voc_equiv, power. Kurz zur Bedeutung:

• on — einfacher Schalt-Zustand (an/aus)
• level — Prozentwert (Dimmer, Rolladen-Position, Lautstärke-Basis)
• open — Fenster/Tür offen-Flag
• current/expected — Ist-/Soll-Temperatur bei Thermostaten
• iaq/co2_equiv/voc_equiv — Luftqualitäts-Werte
• power — Wattverbrauch

Das Feld ist "freeSolo", d.h. die Liste ist nicht abschließend, falls dein Gerät etwas braucht das nicht dabei ist, kannst du frei einen Wert eintragen — wichtig ist nur, dass Hannah intern etwas mit dem Namen anfangen kann (aktuell eben genau diese zwölf).

Zu den drei gemeldeten Problemen — hab ich mir angeschaut, alle drei sind nachvollziehbar:

1. "schließe den Rolladen" — Bug bestätigt. Aktuell wird Öffnen/Schließen-Vokabular gar nicht auf die Prozent-Steuerung gemappt, das baue ich nach. Eine Frage dazu: bei deinem Rolladen-Actor, bedeutet level=0 bei dir "zu" oder "auf"? Das ist je nach Adapter/Actor unterschiedlich konfiguriert, will das nicht falsch herum einbauen. Dazu kommt noch das ich gar keine Rolladen-Aktoren besitze, ich baue das also quasi im Blindflug.

2. "Seite" → "seit" löst Aktion auf alle Rolläden aus — das ist tatsächlich ein grundsätzliches Problem: wenn ein Gerätename nicht erkannt wird, kann Hannah aktuell nicht unterscheiden zwischen "du wolltest bewusst alle Geräte" und "die Erkennung hat dein gemeintes Gerät verschluckt". Das ist kein Fünf-Minuten-Fix, sondern eine echte Design-Frage (z.B. Rückfrage statt Blindausführung, wenn unbekannte Reste im Satz übrig bleiben) — steht auf der Liste, wird aber etwas dauern.

3. "3 Gerät(e) geschaltet" vs. 5 im Log — Verdacht: das ist eigentlich kein Zähl-Bug, sondern zwei unterschiedliche Zahlen mit ähnlichem Wortlaut im Log (gefundene Kandidaten vs. tatsächlich erfolgreich geschaltete). Könntest du mir die genaue Log-Zeile schicken, die mit "execute: ... → N Gerät(e), state=..." beginnt? Dann kann ich das zweifelsfrei bestätigen.

Zur Ausgangsfrage: Text- und Sprachweg laufen durch dieselbe NLU-Pipeline, das Ergebnis sollte bei identischem Text also identisch sein — Unterschiede zwischen den beiden Wegen sind daher selbst ein Hinweis auf einen Bug, nicht auf gewollte Unterschiede. Falls dir da was auffällt, gerne auch melden.

Danke nochmal fürs genaue Hinschauen!

[Luxi]

@duemchen Ich würde as Prototypen zwei Stück nehmen. Hast du ne Idee wie wir eventuell die anderen Interessenten mit ins Boot holen ohne die Übersicht zu verlieren.

[manne01]

Hallo Leonie,

mal ganz blöd gefragt, statt die ganzen Geräte und Status alle detailliert abzubilden und dann in Hannah alle Spezialitäten von möglichen menschlichen Anfragen per Code zu interpretieren - wäre es nicht auch denkbar, den "Objektbaum" per RAG einem Modell zugänglich zu machen und dann das Modell ermitteln zu lassen was gemeint ist? Denn ansonsten muss man sich doch schon sehr genau ausdrücken und kann keine Synonyme verwenden (oder müsste Synonyme für Geräte, Raumnamen und Funktionen pflegen können)

zu 1: bei Homematic-Rolladenaktoren die ich einsetze (HM-LC-Bl1-FM) ist der LEVEL wie weit sie offen sind, also quasi der Lichteinfall: bei Level 100% der Rollladen ist vollständig offen/oben (maximale Helligkeit / freie Sicht). Und 0% bedeutet der Rollladen ist vollständig unten/geschlossen. Das mag bei den Aktoren anderer Hersteller natürlich anders sein.

zu 2: ja, nachvollziehbar. Wenn ich mir was wünschen darf - solange das Wort "alle" nicht im Kommando ist, müsste er eher nachfragen. Nach dem Motto "Im Zweifel lieber weniger machen."

Wenn sowas nicht geht müsste man sich wohl irgendwie (z.B. mit dem eingebauten Kategorie bzw. Raum/Funktions)-Manager eine neben "Rolläden" eine zusätzliche Funktion "AlleRolläden" oder so bauen oder einen "Raum" = "Erdgeschoss". Die einzelnen Räume und Funktionen sind ja im Objektbaum als enum.x.y angelegt, d.h. man könnte so auch "AlleRolläden" oder "Erdgeschoss" an Hannah geben und Kommandos drauf absetzen?

zu 3:

20:05:48 [INFO] hannah.main: [grpc/voice] Transkript: 'Bitte setze die Rolläden im Schlafzimmer auf 50%.' 
20:05:48 [INFO] hannah.main: [textcmd] Text: 'Bitte setze die Rolläden im Schlafzimmer auf 50%.' → Intent: SetLevel | Raum: Schlafzimmer | Gerät: None | Wert: 50.0 | SpeakerUser: 2 
20:05:48 [INFO] hannah.iobroker: execute: SetLevel → 5 Gerät(e), state='level', value=50.0 
20:05:48 [INFO] hannah.main: [2] Antwort (SetLevel): 'OK, 3 Gerät(e) geschaltet.' 

@Leonie sagte:

Zur Ausgangsfrage: Text- und Sprachweg laufen durch dieselbe NLU-Pipeline, das Ergebnis sollte bei identischem Text also identisch sein — Unterschiede zwischen den beiden Wegen sind daher selbst ein Hinweis auf einen Bug, nicht auf gewollte Unterschiede. Falls dir da was auffällt, gerne auch melden.

Mache ich!

Auch noch spannend war heute -> Raum WC wurde erkannt, aber es wurde dann zum Kinderzimmer berichtet:
17:47:06 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:1234567498 (user=2) — 'Wie ist der Status vom Fenster im WC?'
17:47:06 [INFO] hannah.main: [textcmd] Text: 'Wie ist der Status vom Fenster im WC?' → Intent: Query | Raum: WC | Gerät: Fenster | Wert: None | SpeakerUser: 2
17:47:06 [INFO] hannah.main: [2] Antwort (Query): 'Fenster im Kinderzimmer: offen.'

und
17:45:31 [INFO] hannah.iobroker: · Fenster () [window] — States: STATE --> Funktioniert, Hannah weiß ob auf oder zu ist
17:45:31 [INFO] hannah.iobroker: · Tür () [door] — States: STATE --> "Das kann ich leider nicht beantworten".

Jetzt stellt sich natürlich die Frage was man alles selber überschreibt und was evtl. auch noch an der Erkennung optimiert werden kann :) Am liebsten wäre mir natürlich garkeine Überschreibungen. Ich hab tatsächlich inzwischen rechtviele "Fenster 1" bei denen ich die Zahl wegnehmen muss. Du hattest noch nicht gesagt, ob es irgendwas gibt, was Hannah aus dem Gerätenamen ignoriert. Ein Leerzeichen reicht nicht, aber ein Punkt oder Bindestriche müssten doch vielleicht ohnehin ignoriert werden?

Viele Grüße

[Leonie]

Hi,

@manne01 sagte:

wäre es nicht auch denkbar, den "Objektbaum" per RAG einem Modell

Hannah ist primär so entwickelt, das die reine Sprachsteuerung kein LLM benötigt. Allerdings gibt es im NLU-Pfad die Möglichkeit das Hannah einen Satz nicht verarbeiten kann, also keine Regel trifft, und das dann zur Klassifizierung ans LLM sendet. Das kann dann wiederum über Tools auf die Gerätedaten zugreifen und genau das durchführen was du gemeint hast.
Das ist aber bewusst nur als Fallbackpfad gebaut, weil ich nunmal nicht Amazon bin und einfach mal eben tausende Euro ausgeben kann um leistungsstarke Hardware für latenzarme Modelle zu betreiben. Auch einen Cloud Service wie claude, GPT, perplexity oder sonstwas, wollte ich grundsätzlich nicht und will ich nach wie vor nicht. Zumal dann mein Haus auch von der Internetleitung abhängig wäre.
Aktuell hat der LLM-Pfad eine Latenz von ca. 10s bei mir. Das ist für ein wenig Nebenbei"gespräch" oder wenn die NLU einfach nicht den korrekten Pfad getroffen hat, für mich akzeptabel. Aber zu viel um eine Lampe zu steuern. Natürlich würde ich gerne die Latenzen eher auf nahe 0s bringen, aber siehe die vorherige Aussage.
Daher muss ich alle Fälle einzeln hinterlegen. Aber das ist quasi gar nicht so schwierig. Im Prinzip arbeitet die Intentbildung auf Basis von Schlüsselwörtern mit Kontext und "zu" oder "auf" sind einfach nicht definiert aktuell.

@manne01 sagte:

Das mag bei den Aktoren anderer Hersteller natürlich anders sein.
Das ist witzigerweise genau der Grund warum ich mit diesen virtual Devices arbeite. Damit kann mir vollkommen egal sein, was die Hardwarehersteller an Daten verwenden, ob nun 0% auf oder geschlossen ist oder ob 1 oder 0 an ist. Durch die virtual Devices, kann ich jeden State, egal welches Herstellers, auf den Datentyp bringen den ich ich brauche.
Aber natürlich kann ich das nicht vorschreiben. Auf jeden Fall wäre das eine Aufgabe für den Adapter, evtl. mit einer kleinen UI zum Definieren.
So das Hannah intern immer mit ihr bekannten Werten arbeitet. Aber auch das ist aktuell komplex für mich.
Ich kann das gerne so einbauen dass das für dich passt.

@manne01 sagte:

Wenn ich mir was wünschen darf

Darfst du. Ich denke auch, wenn kein klarer Auftrag für eine Gruppe von Geräten erkannt wird, der Resolver aber mehrere Geräte auflöst, sollte nachgefragt werden. Die technische Pipeline für Rückfragen existiert bereits nur wird sie dafür aktuell nicht genutzt.

Danke für den Log. Darf ich wissen wie viele Geräte du im Schlafzimmer hast und was das für welche sind?
Bspw. zwei Rollläden, eine Lampe, eine Steckdose und eine Tür?
Der Fehler ist hier, das der Resolver korrekt 5 Geräte im Raum Schlafzimmer auflöst, aber die Kategorie "Rollläden" nicht. Und das dürfte aktuell gar nicht eingebaut sein.
Das der Executor dann nur 3 Geräte gefunden hat, ist vermutlich auch nur logisch, weil nur drei (Rolläden+Lampe in meinem Beispiel) einen Level haben.

@manne01 sagte:

17:45:31 [INFO] hannah.iobroker: · Fenster () [window] — States: STATE --> Funktioniert, Hannah weiß ob auf oder zu ist
17:45:31 [INFO] hannah.iobroker: · Tür () [door] — States: STATE --> "Das kann ich leider nicht beantworten".

Kannst du mir bitte Details dazu geben? Gerne auch privat. Nur damit ich weiß was in einem Objectdump welches Gerät ist. Außerdem benötige ich bitte den exakten genutzten Wortlaut.

@manne01 sagte:

aber es wurde dann zum Kinderzimmer berichtet

Das ist relativ witzig, weil nachvollziehen kann ich das nicht.

@manne01 sagte:

was Hannah aus dem Gerätenamen ignoriert

Eigentlich ignoriert Hannah bewusst keine Zeichen, außer Satzzeichen und Groß und Kleinschreibung. Also Zahlen müssten durchgehen. Tatsächlich haben meine Geräte aber auch keine Zahlen, dafür die merkwürdigsten Namen. Da heißt ein Fenster bspw. "Seite Straße" oder eine Lampe "Decke Garten". Auch kann ich den von dir beschrieben Fehler nicht nachvollziehen, ich habe den kompletten Gerätepfad durchgeschaut.
Kannst du mir bitte den Startlog von Hannah Core geben? Bzw. den Teil nach dem der Adapter connected ist? Also der Teil in dem alle bekannten Geräte aufgelistet werden.

Quasi nebenbei habe ich auch den VoiceID Rollout fertig gebaut. Der kann über die WebUI gestartet werden, benötigt aber mindestens einen verbunden Satelliten und bringt ohne sowieso nichts.

Liebe Grüße

[Leonie]

@manne01 sagte:

aber könnte man die Version der Komponenten beim Start ins Log schreiben

Ich habe das bisher vollkommen übersehen, sorry dafür.

Das ist eher nicht geplant.
Da du Docker nutzt, kannst du ja die Versionen aus den Tags ablesen.

Aktuell plane ich aber noch einen Health-Endpoint über den man bspw. Metriken für Grafana abholen kann. Ich könnte mir vorstellen das Versionsreporting an der Stelle zu tun.

[Walter.O.]

Hallo zusammen, ich bin zwar derzeit noch im Rügen Uhrlaub aber mal eine Frage , wie komm ich denn in die Webui?
Ach ja, wie ist das beim Telegram_Bot mit der Domain auf sich, sprich wie sieht diese aus (eine Webdomain im sinne von meinedomain.de)?
Wie groß ist denn mittlerweile das Bestellvolumen bei PCBWay und damit der Einzelpreis?

[Leonie]

Hi,
Die WebUI ist direkt per IP erreichbar, ganz ohne Domain — http://<IP-deines-Hosts>:5000 im Browser, Port 5000 ist der Standard. Domain/HTTPS brauchst du dafür nicht.
Willst du allerdings die Telegram Account-Verknüpfung nutzen, musst du eine Domain verwenden, ganz im Sinne von meinedomain.de. Das muss allerdings keine kostenpflichtige Domain sein, der BotFather von Telegram akzeptiert auch dyndns-Adressen

Kurzes Update zur Telegram-Verknüpfung, weil das Thema hier ja schon mal aufkam: Domain (auch DynDNS) bleibt Pflicht fürs offizielle Login-Widget, daran ändert sich nichts.

Für alle, die auch mit DynDNS partout keine Domain am Bot hängen haben wollen, überlege ich zusätzlich eine zweite Variante: ein Admin (Trust-Level 10) verknüpft den Telegram-Account eines Users manuell — braucht nur die Telegram-User-ID (holt man sich z.B. über @userinfobot). Keine Domain, kein Widget.

Der Haken: beim Widget bestätigt der User selbst per Telegram-Login "ja, das bin ich" — bei der manuellen Variante fällt das weg, der Admin trägt einfach ein, was der User ihm sagt. Keine echte Verifikation durch Telegram mehr, reine Vertrauenssache zwischen Admin und User.

Wäre das für euch ein akzeptabler Trade-off, oder ist euch die fehlende Selbstbestätigung zu heikel?

[Walter.O.]

Hallo, ich mal wieder.
wird das Username Passwort für web UI irgendwo festgelegt? Wenn ich einen Namen und ein pw eingebe kommt
"Hannah Core nicht erreichbar Hannah Core antwortet gerade nicht. Bitte versuche es in Kürze erneut." oder ist das eine andere Fehlermeldung?
Wo würde ich nach dem Core Update Suchen?

[Leonie]

Ich bin mir nicht sicher ob ich die Frage korrekt verstehe. Beim ersten Start erstellt der Core einen User mit dem Namen admin und generiert ein Passwort. Das Passwort wird dann im Log ausgegeben. Wenn du das nicht weißt, wird es kompliziert.
Weitere Nutzer lassen sich dann in der WebUI anlegen. Anmelden mit dem admin und dem Startpasswort und die Userverwaltung öffnen.

Um Updates der Komponenten kümmert sich AutoDeploy, wenn es denn auch konfiguriert ist. Alternativ kannst du einfach die install-Scripte erneut ausführen.

[Walter.O.]

wo finde ich den Log

[Leonie]

im journald

sudo journalctl -u hannah

[Walter.O.]

Ich habe das Problem , das der Log sagt "kann config.yaml nicht finden"
Die Datei liegt aber im hannah ordner.
Welche Schreib Lese rechte müssen Ordner und .yaml haben?

[Thomas Braun]

@Walter.O. sagte:

Welche Schreib Lese rechte müssen Ordner und .yaml haben?

Welche haben sie denn jetzt bei dir?

[Leonie]

Die Datei muss standardmäßig nach /etc/hannah/config.yaml

[Walter.O.]

@Leonie
Liegt in /etc/hannah/
drwxr-xr-x 2 hannah hannah 4096 Sep 14 09:29 hannah

-rw-r--r-- 1 root root 9034 Sep 14 09:29 config.yaml

[Leonie]

gib die Datei noch dem User von Hannah:

sudo chown hannah:hannah /etc/hannah/config.yaml

und danach, falls nötig, den Core neustarten:

sudo systemctl restart hannah

und dann wieder mit journalctl die Logs prüfen:

sudo journalctl -u hannah

Du kannst darin mit den Pfeiltasten navigieren (hoch und runter), mit Shif+G ans Ende springen und mit q das journal verlassen.

[Walter.O.]

@Leonie
Hab ich so gemacht wie du geschrieben hast incl. restart.

Sep 13 19:13:07 iob systemd[1]: hannah.service: Scheduled restart job, restart counter is at 2.
Sep 13 19:13:07 iob systemd[1]: Started hannah.service - Hannah Voice Assistant Core.
Sep 13 19:13:07 iob python[1681018]: 19:13:07 [INFO] hannah.main: Hannah Core dev
Sep 13 19:13:07 iob python[1681018]: 19:13:07 [ERROR] hannah.main: Config nicht gefunden: /etc/hannah/config.yaml
Sep 13 19:13:07 iob systemd[1]: hannah.service: Main process exited, code=exited, status=1/FAILURE
Sep 13 19:13:07 iob systemd[1]: hannah.service: Failed with result 'exit-code'.
Sep 13 19:13:17 iob systemd[1]: hannah.service: Scheduled restart job, restart counter is at 3.
Sep 13 19:13:17 iob systemd[1]: Started hannah.service - Hannah Voice Assistant Core.

Was mich da irritiert ist das Datum Sep 13 19:13:17
Müsste doch aber Sep 15 20:10 sein

[Leonie]

Schick mir bitte die Ausgabe von "sudo systemctl status hannah"

[Walter.O.]

@Leonie sagte:

Schick mir bitte die Ausgabe von "sudo systemctl status hannah"

sudo systemctl status hannah
● hannah.service - Hannah Voice Assistant Core
     Loaded: loaded (/etc/systemd/system/hannah.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-09-15 20:07:45 CEST; 10min ago
 Invocation: a75fe681ecf64a1ca92413d4df245f86
       Docs: https://dev.kernstock.net/gessinger/voice/hannah
   Main PID: 4916 (python)
      Tasks: 26 (limit: 14909)
     Memory: 225.2M (peak: 334.3M)
        CPU: 6.990s
     CGroup: /system.slice/hannah.service
             ├─4916 /opt/hannah/core/venv/bin/python main.py -c /etc/hannah/config.yaml
             └─4931 /opt/hannah/core/venv/bin/python -c "from multiprocessing.resource_tracker import main;main(10)"

Sep 15 20:10:03 iob python[4916]: 20:10:03 [INFO] hannah.residents_manager: Residents: walter1 (Roomie) Stimmung None → 5.
Sep 15 20:10:03 iob python[4916]: 20:10:03 [WARNING] hannah.grpc_interceptors: [grpc/version] Proto-Version-Mismatch auf '/hannah.HannahService/GetSatellites': erwartet '9', erhalten '7' — nur geloggt (enforce=False)
Sep 15 20:11:01 iob python[4916]: 20:11:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen
Sep 15 20:12:01 iob python[4916]: 20:12:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen
Sep 15 20:13:01 iob python[4916]: 20:13:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen
Sep 15 20:14:01 iob python[4916]: 20:14:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen
Sep 15 20:15:01 iob python[4916]: 20:15:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen
Sep 15 20:16:01 iob python[4916]: 20:16:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen
Sep 15 20:17:01 iob python[4916]: 20:17:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen
Sep 15 20:18:01 iob python[4916]: 20:18:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen