Hannah — Open Source Smart-Home-Sprachassistentin
-
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.'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
-
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.'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
Hi,
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.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.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.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.
aber es wurde dann zum Kinderzimmer berichtet
Das ist relativ witzig, weil nachvollziehen kann ich das nicht.
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
-
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.'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
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.
-
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? -
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-AdressenKurzes 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?
-
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? -
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.
-
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?Welche Schreib Lese rechte müssen Ordner und .yaml haben?
Welche haben sie denn jetzt bei dir?
-
gib die Datei noch dem User von Hannah:
sudo chown hannah:hannah /etc/hannah/config.yamlund danach, falls nötig, den Core neustarten:
sudo systemctl restart hannahund dann wieder mit journalctl die Logs prüfen:
sudo journalctl -u hannahDu kannst darin mit den Pfeiltasten navigieren (hoch und runter), mit Shif+G ans Ende springen und mit q das journal verlassen.
-
gib die Datei noch dem User von Hannah:
sudo chown hannah:hannah /etc/hannah/config.yamlund danach, falls nötig, den Core neustarten:
sudo systemctl restart hannahund dann wieder mit journalctl die Logs prüfen:
sudo journalctl -u hannahDu kannst darin mit den Pfeiltasten navigieren (hoch und runter), mit Shif+G ans Ende springen und mit q das journal verlassen.
@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 -
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 -
ok, dann ist der Log den du gepostet hast nicht aktuell. Wenn du dir den Log nochmal anschaust, und die Pfeiltaste nach unten drückst, kommt da bestimmt mehr.
Deine Ausgabe zeigt aber: Hannah Core läuft, aber du solltest den ioBroker-Adapter auf Verison 1.1.4 updaten.
-
ok, dann ist der Log den du gepostet hast nicht aktuell. Wenn du dir den Log nochmal anschaust, und die Pfeiltaste nach unten drückst, kommt da bestimmt mehr.
Deine Ausgabe zeigt aber: Hannah Core läuft, aber du solltest den ioBroker-Adapter auf Verison 1.1.4 updaten.
1.1.4
Erlrdigt.
Nur wie komm ich an das Passwort wenn der log veraltert ist?
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; 22min ago Invocation: a75fe681ecf64a1ca92413d4df245f86 Docs: https://dev.kernstock.net/gessinger/voice/hannah Main PID: 4916 (python) Tasks: 26 (limit: 14909) Memory: 228.3M (peak: 334.3M) CPU: 8.757s 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:29:48 iob python[4916]: 20:29:48 [INFO] hannah.iobroker: · Terasse-Kipp () [temperature_sensor] — States: available, battery, contact, link_quality, msg_from_zigbee, opened, voltage, current, power_outage_count, trigger_c> Sep 15 20:29:48 iob python[4916]: 20:29:48 [INFO] hannah.iobroker: · Terassen Tür () [temperature_sensor] — States: available, battery, contact, device_query, link_quality, msg_from_zigbee, opened, voltage, current, power_outage_co> Sep 15 20:29:48 iob python[4916]: 20:29:48 [INFO] hannah.iobroker: · Wohnen-Temp () [temperature_sensor] — States: link_quality, msg_from_zigbee, battery, current, pressure, voltage, available Sep 15 20:29:48 iob python[4916]: 20:29:48 [INFO] hannah.iobroker: ──────────────────────────────────────────────────────────── Sep 15 20:29:48 iob python[4916]: 20:29:48 [INFO] hannah.trigger_engine: TriggerEngine: 167 States aus ioBroker-Snapshot übernommen (kein Trigger gefeuert) Sep 15 20:29:49 iob python[4916]: 20:29:49 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'temperatureC' (state_id=shelly.0.SHPLG-S#3CE90EC7E56A#1.temperatureC) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verwo> Sep 15 20:29:49 iob python[4916]: 20:29:49 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'temperatureF' (state_id=shelly.0.SHPLG-S#3CE90EC7E56A#1.temperatureF) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verwo> Sep 15 20:29:52 iob python[4916]: 20:29:52 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'Power' (state_id=shelly.0.SHPLG-S#FDC9B9#1.Relay0.Power) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (Wert fr> Sep 15 20:29:52 iob python[4916]: 20:29:52 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'uptime' (state_id=shelly.1.shellyplus2pm#ecc9ff608284#1.uptime) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (> Sep 15 20:29:57 iob python[4916]: 20:29:57 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'Timer' (state_id=shelly.0.SHPLG-S#3CE90EC7E56A#1.Relay0.Timer) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (W> ...skipping... ● 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; 22min ago Invocation: a75fe681ecf64a1ca92413d4df245f86 Docs: https://dev.kernstock.net/gessinger/voice/hannah Main PID: 4916 (python) Tasks: 26 (limit: 14909) Memory: 228.3M (peak: 334.3M) CPU: 8.757s 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:29:48 iob python[4916]: 20:29:48 [INFO] hannah.iobroker: · Terasse-Kipp () [temperature_sensor] — States: available, battery, contact, link_quality, msg_from_zigbee, opened, voltage, current, power_outage_count, trigger_c> Sep 15 20:29:48 iob python[4916]: 20:29:48 [INFO] hannah.iobroker: · Terassen Tür () [temperature_sensor] — States: available, battery, contact, device_query, link_quality, msg_from_zigbee, opened, voltage, current, power_outage_co> Sep 15 20:29:48 iob python[4916]: 20:29:48 [INFO] hannah.iobroker: · Wohnen-Temp () [temperature_sensor] — States: link_quality, msg_from_zigbee, battery, current, pressure, voltage, available Sep 15 20:29:48 iob python[4916]: 20:29:48 [INFO] hannah.iobroker: ──────────────────────────────────────────────────────────── Sep 15 20:29:48 iob python[4916]: 20:29:48 [INFO] hannah.trigger_engine: TriggerEngine: 167 States aus ioBroker-Snapshot übernommen (kein Trigger gefeuert) Sep 15 20:29:49 iob python[4916]: 20:29:49 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'temperatureC' (state_id=shelly.0.SHPLG-S#3CE90EC7E56A#1.temperatureC) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verwo> Sep 15 20:29:49 iob python[4916]: 20:29:49 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'temperatureF' (state_id=shelly.0.SHPLG-S#3CE90EC7E56A#1.temperatureF) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verwo> Sep 15 20:29:52 iosudo journalctl -u hannahb python[4916]: 20:29:52 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'Power' (state_id=shelly.0.SHPLG-S#FDC9B9#1.Relay0.Power) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (Wert fr> Sep 15 20:29:52 iob python[4916]: 20:29:52 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'uptime' (state_id=shelly.1.shellyplus2pm#ecc9ff608284#1.uptime) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (> Sep 15 20:29:57 iob python[4916]: 20:29:57 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'Timer' (state_id=shelly.0.SHPLG-S#3CE90EC7E56A#1.Relay0.Timer) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (W> ~
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
367
Online33.1k
Benutzende83.8k
Themen1.4m
Beiträge