Hannah — Open Source Smart-Home-Sprachassistentin
-
@Leonie
In der webui seh ich jetzt nichts:...skipping... Sep 24 23:57:23 iob gunicorn[1566344]: [2026-09-24 23:57:23 +0200] [1566344] [WARNING] Invalid request from ip=192.168.178.44: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] ssl/tls alert certificate unknown (_ssl.c:2711) Sep 24 23:57:23 iob gunicorn[1566344]: 192.168.178.44 - - [24/Sep/2026:23:57:23 +0200] "GET /settings HTTP/1.1" 200 58496 "https://192.168.178.122:5000/settings" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36> Sep 24 23:57:23 iob gunicorn[1566345]: [2026-09-24 23:57:23 +0200] [1566345] [WARNING] Invalid request from ip=192.168.178.44: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] ssl/tls alert certificate unknown (_ssl.c:2711) Sep 24 23:57:23 iob gunicorn[1566344]: [2026-09-24 23:57:23 +0200] [1566344] [WARNING] Invalid request from ip=192.168.178.44: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] ssl/tls alert certificate unknown (_ssl.c:2711) Sep 24 23:57:23 iob gunicorn[1566344]: 192.168.178.44 - - [24/Sep/2026:23:57:23 +0200] "GET /static/manifest.json HTTP/1.1" 200 976 "https://192.168.178.122:5000/settings" "Mozilla/5.0 (X11; Linux x86_64) AppleWeb> Sep 24 23:57:23 iob gunicorn[1566345]: 192.168.178.44 - - [24/Sep/2026:23:57:23 +0200] "GET /static/css/tailwind.css HTTP/1.1" 304 0 "https://192.168.178.122:5000/settings" "Mozilla/5.0 (X11; Linux x86_64) AppleWe> Sep 24 23:57:23 iob gunicorn[1566345]: [2026-09-24 23:57:23 +0200] [1566345] [WARNING] Invalid request from ip=192.168.178.44: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] ssl/tls alert certificate unknown (_ssl.c:2711) Sep 25 06:36:39 iob gunicorn[1566280]: [2026-09-25 06:36:39 +0200] [1566280] [INFO] Handling signal: term Sep 25 06:36:39 iob systemd[1]: Stopping hannah-webui.service - Hannah WebUI... Sep 25 06:36:39 iob gunicorn[1566344]: [2026-09-25 06:36:39 +0200] [1566344] [INFO] Worker exiting (pid: 1566344) Sep 25 06:36:39 iob gunicorn[1566345]: [2026-09-25 06:36:39 +0200] [1566345] [INFO] Worker exiting (pid: 1566345) Sep 25 06:36:39 iob gunicorn[1566280]: [2026-09-25 06:36:39 +0200] [1566280] [INFO] Worker (pid:1566344) was sent SIGTERM! Sep 25 06:36:39 iob gunicorn[1566280]: [2026-09-25 06:36:39 +0200] [1566280] [INFO] Worker (pid:1566345) was sent SIGTERM! Sep 25 06:36:39 iob gunicorn[1566280]: [2026-09-25 06:36:39 +0200] [1566280] [INFO] Shutting down: Master Sep 25 06:36:40 iob systemd[1]: hannah-webui.service: Deactivated successfully. Sep 25 06:36:40 iob systemd[1]: Stopped hannah-webui.service - Hannah WebUI. Sep 25 06:36:40 iob systemd[1]: hannah-webui.service: Consumed 2min 34.433s CPU time over 1d 11h 45min 43.603s wall clock time, 111M memory peak. Sep 25 06:36:40 iob systemd[1]: Started hannah-webui.service - Hannah WebUI. Sep 25 06:36:40 iob gunicorn[2602627]: [2026-09-25 06:36:40 +0200] [2602627] [INFO] Starting gunicorn 26.2.0 Sep 25 06:36:40 iob gunicorn[2602627]: [2026-09-25 06:36:40 +0200] [2602627] [INFO] Listening at: http://0.0.0.0:5000 (2602627) Sep 25 06:36:40 iob gunicorn[2602627]: [2026-09-25 06:36:40 +0200] [2602627] [INFO] Using worker: sync Sep 25 06:36:40 iob gunicorn[2602728]: [2026-09-25 06:36:40 +0200] [2602728] [INFO] Booting worker with pid: 2602728 Sep 25 06:36:40 iob gunicorn[2602738]: [2026-09-25 06:36:40 +0200] [2602738] [INFO] Booting worker with pid: 2602738 Sep 25 06:36:41 iob gunicorn[2602627]: [2026-09-25 06:36:41 +0200] [2602627] [INFO] Control socket listening at /opt/hannah/webui/.gunicorn/gunicorn.ctl Sep 25 17:48:46 iob gunicorn[2602627]: [2026-09-25 17:48:46 +0200] [2602627] [INFO] Handling signal: term Sep 25 17:48:46 iob systemd[1]: Stopping hannah-webui.service - Hannah WebUI... Sep 25 17:48:46 iob gunicorn[2602728]: [2026-09-25 17:48:46 +0200] [2602728] [INFO] Worker exiting (pid: 2602728) Sep 25 17:48:46 iob gunicorn[2602738]: [2026-09-25 17:48:46 +0200] [2602738] [INFO] Worker exiting (pid: 2602738) Sep 25 17:48:46 iob gunicorn[2602627]: [2026-09-25 17:48:46 +0200] [2602627] [INFO] Shutting down: Master Sep 25 17:48:46 iob systemd[1]: hannah-webui.service: Deactivated successfully. Sep 25 17:48:46 iob systemd[1]: Stopped hannah-webui.service - Hannah WebUI. Sep 25 17:48:46 iob systemd[1]: hannah-webui.service: Consumed 21.312s CPU time over 11h 12min 6.640s wall clock time, 108.1M memory peak. -- Boot 8f1eefb4dcad4b1ebf9ca3e5277ff2c4 -- Sep 25 17:49:33 iob systemd[1]: Started hannah-webui.service - Hannah WebUI. Sep 25 17:49:34 iob gunicorn[1292]: [2026-09-25 17:49:34 +0200] [1292] [INFO] Starting gunicorn 26.2.0 Sep 25 17:49:34 iob gunicorn[1292]: [2026-09-25 17:49:34 +0200] [1292] [INFO] Listening at: http://0.0.0.0:5000 (1292) Sep 25 17:49:34 iob gunicorn[1292]: [2026-09-25 17:49:34 +0200] [1292] [INFO] Using worker: sync Sep 25 17:49:34 iob gunicorn[1320]: [2026-09-25 17:49:34 +0200] [1320] [INFO] Booting worker with pid: 1320 Sep 25 17:49:34 iob gunicorn[1324]: [2026-09-25 17:49:34 +0200] [1324] [INFO] Booting worker with pid: 1324 Sep 25 17:49:35 iob gunicorn[1292]: [2026-09-25 17:49:35 +0200] [1292] [INFO] Control socket listening at /opt/hannah/webui/.gunicorn/gunicorn.ctl lines 107762-107801/107801 (END) -
Hey,
Wer hat denn Lust auf eine Sammelbestellung an den Satelliten bei PCBWay? Wenn das so klappt wie ich mir das vorstelle, müsste hier irgendwo eine Umfrage sein, falls nicht, bitte einfach diesen Beitrag zitieren. Das werte ich dann als Interesse.
Ich werde mich allerdings nicht selbst an der Beschaffung beteiligen, das hier dient lediglich dazu alle Interessenten zu sammeln.
Grundsätzlich gibt es eine Anleitung für das Bestellen: https://hannah-docs.leonie.network/components/satellite/pcb-order/ Für weitere Fragen bin ich aber natürlich ansprechbar.
Viele Grüße
-
Hallo Leonie,
hier endlich wieder mal eine gesammelte Rückmeldung zu diversen Themen:
@Leonie sagte: Notiert, wird auf DEBUG-Level runtergestuft bzw. nur bei echter Änderung geloggt.
Top, Danke - viel besser:)
Noch eine Beobachtung zum Thema logging - diese Meldungen trudeln relativ unregelmässig ein - wieso kommen die nicht alle gesammelt beim Startup?
07:57:33 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'ACTUAL' (state_id=matter.0.controller.123456789.ContactSensor-1.ACTUAL) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (Wert friert auf dem letzten Snapshot ein).
Eine beliebige Texteingabe auf den ioBroker State "hannah.0.satellites.rooms.all.announcement" müsste doch allen satelliten den text ansagen?
Mit dem announcement-State für den Raum in dem mein Satellite Lite ist gehts (hannah.0.satellites.rooms.hobbyraum.announcement) und auch direkt auf dem gerät (hannah.0.satellites.rooms.hobbyraum.desktop.announcement)Hue-Lampen / Saturation:
@Leonie sagte:
Danke, das ist nochmal ein gutes Argument mehr für das offene Saturation-Issue — zeigt, dass es nicht nur "nice to have" ist, sondern ohne eigenen Workaround gar nicht sauber geht. Ich nutze übrigens auch Hue-Lampen, aktuell aber nur noch über Zigbee2MQTT und da gibt es bspw. die Saturation gar nicht :DBei mir sind es IKEA Lampen, die offenbar nur HUE "sprechen". Ich muss sagen ich habe mir den Alias Adapter angesehen, aber bin nicht schlau draus geworden. Das muss ich mir nochmal genauer ansehen.
Kindersicherung per Speaker-ID:
Eine Idee dazu: das Trust-Level-System regelt aktuell rein Hannah-interne Rechte (z.B. User-Verwaltung ab Level 10, eigene Satelliten sehen ab Level 7) — auf einzelne States auszuweiten (z.B. "Licht an" braucht Trust 6, ein Kind hat nur 3) wäre ein komplett neues Anwendungsfeld dafür, keine kleine Erweiterung. Ist aber nichts Konkretes. Du bist hier praktisch der Erste mit echtem Mehrbenutzer-Alltag — wäre sowas für dich relevant, oder eher theoretisch interessant?
Genial, ist ja jetzt schon eingebaut - toll!
Mir fehlt natürlich noch das Gefühl wie sicher die Sprechererkennung überhaupt ist. Wenn die treffsicher ist, dann ist das perfekt. Wenn das nicht so zuverlässig klappt müsste Hannah bei bestimmten Sachen nach einem Kennwort, PIN oder so fragen das man in ioBroker bei der Hannah Config der empfindlichen Geräte dazu konfiguriert. Was natürlich bei Sprache alles bissle blöd ist. Oder notfalls halt einen Morse Code am Satellite eintippen oder so. Sprechererkennung mit Trustlevel ist aber das schickste.
Wenn die Kids versehentlich oder bewusst anfangen per Sprache Sachen zu kommandieren die man eigentlich nur für sich selber implementiert hat oder die "teuer" finde ich das richtig wichtig. Also z.B. das Hof-Tor, die Teichbewässerung, der Whirlpool, die Standheizung oder sicherheitsrelevanten Sachen (wie eine Scharfschaltung) zu spielen kann es doof werden.
Ich muss das also umgehend testen! :-)
Da fällt mir ein, vielleicht wäre auch generell bei ausgewählten Statusänderungen und zur Vorsorge bei "Missverständnissen" in der Spracherkennung so eine Art konfigurierbare Sicherheitsrückfrage "Bist Du sicher? Bitte bestätigen -> Bestätigt"?
Oder auch ein "Audit-Trail" oder eine Benachrichtigung an den Admin (per Telegram). Aber letzteres könnte man ja jederzeit selber ioBroker-Seitig implementieren.
Hannah-State-Base-Types / Settings-UI-Verständnis:
Ich verstehe es so, dass in den States (siehe Hannah UI, die Keys links) die implementierten Schreib und Lesefunktionen seitens Hannah hinterlegt sind die Hannah anwenden kann.
@Leonie sagte: Das ist im Kern richtig verstanden. Für die ausführliche Erklärung (was jeder Key kann, Wertebereiche, wann der Override nötig ist) plane ich aber eher das neue Handbuch als die Settings-UI selbst — dort passt eine ordentliche Erklärung besser hin als in Tooltips. Kommt.
Richtig gut und das Puzzle verständlich aufbereitet die Doku jetzt - vielen vielen Dank!
Richtig gut ist auch die neue Geräteliste in der WebUI, konsistent auffindbar und übersichtlicher und vollständigere Infos als im Log.
In der WebUI ist ja jetzt das Mapping rausgeflogen mit dem man Hannah-Keys auf eigene Keys mappen konnte. Nun muss man alles überschreiben und das kann u.U. recht viel werden, oder? Oder ist da doch die Empfehlung mit Aliasen oder diesem Script zu arbeiten um das zu vermeiden?
Es wäre glaube ich schon eine Vereinfachung in WebUI-Settings weiterhin mehrere STATE-names auf einen Hannah-State mappen zu können? (die UI erlaubte das mehrfache zuweisen nicht als das State Suffix Mapping noch drin war)
also falls current sowas wie eine Zahl ist
current = ACTUAL_HUMIDITY
current = ACTUAL_TEMPERATURE
solange diese letztlich mit dem Hannah-State-Base-Type "current" gleich gehandhabt werden können? Dann müsste ich weniger in ioBroker überschreiben?!
Und: Wenn ich mein ein Gerät mit mehreren States z.B. ein [light] mit ON, DIMMER, SATURATION etc. überschreiben muss, muss ich dann alles mehrfach an jedem State überschreiben?
@Leonie sagte: Da hab ich mir die Ursache genau angeschaut: deine Kontakt-Rolle ist bei Homematic einfach zu generisch ("state"), als dass Hannah das automatisch erkennen könnte — dafür gibt's aber schon einen Override-Mechanismus in ioBroker (common.custom), den du auf diesem State setzen kannst.
Ist nun mit "open" überschrieben und klapt nun, super!
Könnte Hannah bei Rolladen Level abfragen auch in "offen/zu" übersetzen statt 0% und 100% (nur noch alles dazwischen dann numerisch)? Das wäre etwas menschlicher/verständlicher.
Welche Fenster sind geöffnet? --> soll alle Fenster im System betrachten
11:09:20 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche Fenster sind geöffnet?'
11:09:20 [INFO] hannah.main: [textcmd] Text: 'Welche Fenster sind geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: Fenster | Wert: None | SpeakerUser: 2
11:09:20 [INFO] hannah.main: [2] Antwort (Query): 'Fenster im Kinderzimmer: geschlossen.'PASST NUN! das habe ich rausgefunden -> Im Kinderzimmer war das einzige Fenster welches nicht "Fenster -" oder "Fenster --" heisst. Nach dem Überschreiben aller Varianten mit schlicht "Fenster" hat Hannah nun nachgefragt welches ich meine.
Welche Rolläden sind geöffnet? Hier erfolgte ja keine Nachfrage, sondern Antwort mit Bezug aufs zuletzt angefragte Wohnzimmer. Das scheint tw. immer noch so:
23:37:05 [INFO] hannah.main: [textcmd] Text: 'Welche Rolläden sind geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:37:05 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'23:38:23 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:38:23 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'23:40:45 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: None | Gerät: None | Wert: None | SpeakerUser: 2
23:40:45 [INFO] hannah.main: [2] Antwort (Query): ---> hier nun eine Lange liste mit sämtlichen Rolladen in allen RäumenEs kam also erst nach einer Pause von ca. 2min dann die Antwort mit alle Rolläden - dh. Hannah behält den Kontext Wohnzimmer noch eine Weile, richtig?
Aber warum hier dann keine Nachfrage welcher Raum?23:47:12 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welcher Rolladen ist geöffnet'
23:47:12 [INFO] hannah.main: [textcmd] Text: 'Welcher Rolladen ist geöffnet' → Intent: Query | Raum: None | Gerät: rolladen | Wert: None | SpeakerUser: 2
23:47:12 [INFO] hannah.main: [2] Antwort (Clarification): 'Welchen Raum meinst du — Wohnzimmer oder Kinderzimmer?'Mit der Frage nach "Rolladen" kommt eine Rückfrage.
Ich vermute hier kommt Hannah durcheinander, weil es eben Rolladen gibt, aber auch Rolladen Seite etc.23:47:29 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche rollläden sind geöffnet'
23:47:29 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:47:29 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'Auch hier ohne Not wieder eine plötzliche Festlegung auf Raum Wohnzimmer.
Das Ganze ist ganz gut reproduzierbar.
"Welcher Rolladen ist geöffnet" -> fragt nach
"Welche rollläden sind geöffnet" -> legt sich auf Wohnzimmer fest, das verstehe ich nicht.
Der neue Windows-Lite-Satellite funktioniert bei mir klasse trotz Synology-Hürden und man hat damit einen tollen Vorgeschmack in Richtung Voice2Voice-Kommunikation bzw. vor allem sofortiger Voice-Rückantwort von Hannah und Smalltalk. Von hier aus heißt es jetzt: auf gehts zum Satellite :-)
Die für mich offenen Punkte mit "Sondergeräten" die ich bisher per VIS bedient habe schaue ich mir nun nochmal näher an was ich da selber scripten kann oder mit Aliasen etc.
Soviel wieder für heute - entschuldige die Themensprünge und alles was ich (noch immer) nicht ganz verstanden habe...
Danke für die Rückmeldungen und die tollen Fortschritte! -
Hallo Leonie,
hier endlich wieder mal eine gesammelte Rückmeldung zu diversen Themen:
@Leonie sagte: Notiert, wird auf DEBUG-Level runtergestuft bzw. nur bei echter Änderung geloggt.
Top, Danke - viel besser:)
Noch eine Beobachtung zum Thema logging - diese Meldungen trudeln relativ unregelmässig ein - wieso kommen die nicht alle gesammelt beim Startup?
07:57:33 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'ACTUAL' (state_id=matter.0.controller.123456789.ContactSensor-1.ACTUAL) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (Wert friert auf dem letzten Snapshot ein).
Eine beliebige Texteingabe auf den ioBroker State "hannah.0.satellites.rooms.all.announcement" müsste doch allen satelliten den text ansagen?
Mit dem announcement-State für den Raum in dem mein Satellite Lite ist gehts (hannah.0.satellites.rooms.hobbyraum.announcement) und auch direkt auf dem gerät (hannah.0.satellites.rooms.hobbyraum.desktop.announcement)Hue-Lampen / Saturation:
@Leonie sagte:
Danke, das ist nochmal ein gutes Argument mehr für das offene Saturation-Issue — zeigt, dass es nicht nur "nice to have" ist, sondern ohne eigenen Workaround gar nicht sauber geht. Ich nutze übrigens auch Hue-Lampen, aktuell aber nur noch über Zigbee2MQTT und da gibt es bspw. die Saturation gar nicht :DBei mir sind es IKEA Lampen, die offenbar nur HUE "sprechen". Ich muss sagen ich habe mir den Alias Adapter angesehen, aber bin nicht schlau draus geworden. Das muss ich mir nochmal genauer ansehen.
Kindersicherung per Speaker-ID:
Eine Idee dazu: das Trust-Level-System regelt aktuell rein Hannah-interne Rechte (z.B. User-Verwaltung ab Level 10, eigene Satelliten sehen ab Level 7) — auf einzelne States auszuweiten (z.B. "Licht an" braucht Trust 6, ein Kind hat nur 3) wäre ein komplett neues Anwendungsfeld dafür, keine kleine Erweiterung. Ist aber nichts Konkretes. Du bist hier praktisch der Erste mit echtem Mehrbenutzer-Alltag — wäre sowas für dich relevant, oder eher theoretisch interessant?
Genial, ist ja jetzt schon eingebaut - toll!
Mir fehlt natürlich noch das Gefühl wie sicher die Sprechererkennung überhaupt ist. Wenn die treffsicher ist, dann ist das perfekt. Wenn das nicht so zuverlässig klappt müsste Hannah bei bestimmten Sachen nach einem Kennwort, PIN oder so fragen das man in ioBroker bei der Hannah Config der empfindlichen Geräte dazu konfiguriert. Was natürlich bei Sprache alles bissle blöd ist. Oder notfalls halt einen Morse Code am Satellite eintippen oder so. Sprechererkennung mit Trustlevel ist aber das schickste.
Wenn die Kids versehentlich oder bewusst anfangen per Sprache Sachen zu kommandieren die man eigentlich nur für sich selber implementiert hat oder die "teuer" finde ich das richtig wichtig. Also z.B. das Hof-Tor, die Teichbewässerung, der Whirlpool, die Standheizung oder sicherheitsrelevanten Sachen (wie eine Scharfschaltung) zu spielen kann es doof werden.
Ich muss das also umgehend testen! :-)
Da fällt mir ein, vielleicht wäre auch generell bei ausgewählten Statusänderungen und zur Vorsorge bei "Missverständnissen" in der Spracherkennung so eine Art konfigurierbare Sicherheitsrückfrage "Bist Du sicher? Bitte bestätigen -> Bestätigt"?
Oder auch ein "Audit-Trail" oder eine Benachrichtigung an den Admin (per Telegram). Aber letzteres könnte man ja jederzeit selber ioBroker-Seitig implementieren.
Hannah-State-Base-Types / Settings-UI-Verständnis:
Ich verstehe es so, dass in den States (siehe Hannah UI, die Keys links) die implementierten Schreib und Lesefunktionen seitens Hannah hinterlegt sind die Hannah anwenden kann.
@Leonie sagte: Das ist im Kern richtig verstanden. Für die ausführliche Erklärung (was jeder Key kann, Wertebereiche, wann der Override nötig ist) plane ich aber eher das neue Handbuch als die Settings-UI selbst — dort passt eine ordentliche Erklärung besser hin als in Tooltips. Kommt.
Richtig gut und das Puzzle verständlich aufbereitet die Doku jetzt - vielen vielen Dank!
Richtig gut ist auch die neue Geräteliste in der WebUI, konsistent auffindbar und übersichtlicher und vollständigere Infos als im Log.
In der WebUI ist ja jetzt das Mapping rausgeflogen mit dem man Hannah-Keys auf eigene Keys mappen konnte. Nun muss man alles überschreiben und das kann u.U. recht viel werden, oder? Oder ist da doch die Empfehlung mit Aliasen oder diesem Script zu arbeiten um das zu vermeiden?
Es wäre glaube ich schon eine Vereinfachung in WebUI-Settings weiterhin mehrere STATE-names auf einen Hannah-State mappen zu können? (die UI erlaubte das mehrfache zuweisen nicht als das State Suffix Mapping noch drin war)
also falls current sowas wie eine Zahl ist
current = ACTUAL_HUMIDITY
current = ACTUAL_TEMPERATURE
solange diese letztlich mit dem Hannah-State-Base-Type "current" gleich gehandhabt werden können? Dann müsste ich weniger in ioBroker überschreiben?!
Und: Wenn ich mein ein Gerät mit mehreren States z.B. ein [light] mit ON, DIMMER, SATURATION etc. überschreiben muss, muss ich dann alles mehrfach an jedem State überschreiben?
@Leonie sagte: Da hab ich mir die Ursache genau angeschaut: deine Kontakt-Rolle ist bei Homematic einfach zu generisch ("state"), als dass Hannah das automatisch erkennen könnte — dafür gibt's aber schon einen Override-Mechanismus in ioBroker (common.custom), den du auf diesem State setzen kannst.
Ist nun mit "open" überschrieben und klapt nun, super!
Könnte Hannah bei Rolladen Level abfragen auch in "offen/zu" übersetzen statt 0% und 100% (nur noch alles dazwischen dann numerisch)? Das wäre etwas menschlicher/verständlicher.
Welche Fenster sind geöffnet? --> soll alle Fenster im System betrachten
11:09:20 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche Fenster sind geöffnet?'
11:09:20 [INFO] hannah.main: [textcmd] Text: 'Welche Fenster sind geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: Fenster | Wert: None | SpeakerUser: 2
11:09:20 [INFO] hannah.main: [2] Antwort (Query): 'Fenster im Kinderzimmer: geschlossen.'PASST NUN! das habe ich rausgefunden -> Im Kinderzimmer war das einzige Fenster welches nicht "Fenster -" oder "Fenster --" heisst. Nach dem Überschreiben aller Varianten mit schlicht "Fenster" hat Hannah nun nachgefragt welches ich meine.
Welche Rolläden sind geöffnet? Hier erfolgte ja keine Nachfrage, sondern Antwort mit Bezug aufs zuletzt angefragte Wohnzimmer. Das scheint tw. immer noch so:
23:37:05 [INFO] hannah.main: [textcmd] Text: 'Welche Rolläden sind geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:37:05 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'23:38:23 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:38:23 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'23:40:45 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: None | Gerät: None | Wert: None | SpeakerUser: 2
23:40:45 [INFO] hannah.main: [2] Antwort (Query): ---> hier nun eine Lange liste mit sämtlichen Rolladen in allen RäumenEs kam also erst nach einer Pause von ca. 2min dann die Antwort mit alle Rolläden - dh. Hannah behält den Kontext Wohnzimmer noch eine Weile, richtig?
Aber warum hier dann keine Nachfrage welcher Raum?23:47:12 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welcher Rolladen ist geöffnet'
23:47:12 [INFO] hannah.main: [textcmd] Text: 'Welcher Rolladen ist geöffnet' → Intent: Query | Raum: None | Gerät: rolladen | Wert: None | SpeakerUser: 2
23:47:12 [INFO] hannah.main: [2] Antwort (Clarification): 'Welchen Raum meinst du — Wohnzimmer oder Kinderzimmer?'Mit der Frage nach "Rolladen" kommt eine Rückfrage.
Ich vermute hier kommt Hannah durcheinander, weil es eben Rolladen gibt, aber auch Rolladen Seite etc.23:47:29 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche rollläden sind geöffnet'
23:47:29 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:47:29 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'Auch hier ohne Not wieder eine plötzliche Festlegung auf Raum Wohnzimmer.
Das Ganze ist ganz gut reproduzierbar.
"Welcher Rolladen ist geöffnet" -> fragt nach
"Welche rollläden sind geöffnet" -> legt sich auf Wohnzimmer fest, das verstehe ich nicht.
Der neue Windows-Lite-Satellite funktioniert bei mir klasse trotz Synology-Hürden und man hat damit einen tollen Vorgeschmack in Richtung Voice2Voice-Kommunikation bzw. vor allem sofortiger Voice-Rückantwort von Hannah und Smalltalk. Von hier aus heißt es jetzt: auf gehts zum Satellite :-)
Die für mich offenen Punkte mit "Sondergeräten" die ich bisher per VIS bedient habe schaue ich mir nun nochmal näher an was ich da selber scripten kann oder mit Aliasen etc.
Soviel wieder für heute - entschuldige die Themensprünge und alles was ich (noch immer) nicht ganz verstanden habe...
Danke für die Rückmeldungen und die tollen Fortschritte!Hey
wieso kommen die nicht alle gesammelt beim Startup?
Weil sie es nicht können. Die kommen wenn der ioBroker ein Statusupdate sendet und das passiert bspw. wenn du ein Fenster öffnest.
Eine beliebige Texteingabe auf den ioBroker State "hannah.0.satellites.rooms.all.announcement" müsste doch allen satelliten den text ansagen?
Tut es jetzt auch. Das war ein Bug :D
Mir fehlt natürlich noch das Gefühl wie sicher die Sprechererkennung überhaupt ist.
Ich werde eigentlich immer erkannt, allerdings ist das wohl keine Refrenz.
Ich muss das also umgehend testen! :-)
Auf jeden Fall und bitte melden, ich bin auf das Ergebnis gespannt :)
Oder auch ein "Audit-Trail"
Es gibt den ActivityLog. Darüber ist erkennbar welcher User wann was zu Hannah sagte. Grundsätzlich wird auch die Antwort da geloggt, nicht aber geschaltete ioBroker-Geräte.
eine Art konfigurierbare Sicherheitsrückfrage
Muss ich mir überlegen. Generell wäre so eine Confirmation bestimmt möglich, die grundlegende Infrastruktur ist vorhanden. Vielleicht kann man das so simpel bauen das man im ioBroker in den State-Settings eine Checkbox hat um das zu aktivieren. Soweit aber nur eine Idee geade.
Richtig gut ist auch die neue Geräteliste in der WebUI
Vielen Dank
In der WebUI ist ja jetzt das Mapping rausgeflogen
Ja, aus der WebUI wurde das entfernt. Ich verstehe den Punkt den du hast. Hilfreich wäre zu wissen wie der Adapter den State auflöst. Möglich das wir hier auf einer Altlast arbeiten. Eigentlich, in meinem Verständnis, sollte der Statename keinen größeren Wert haben, wenn denn der State ansonsten korrekt definiert ist, also bspw. die korrekte Rolle trägt.
Wenn du den LogCollector laufen hast, gib mir bitte Logs über den und zwar von Core und von ioBroker. Auch ein entsprechender Objectdump wird helfen.muss ich dann alles mehrfach an jedem State überschreiben
Eigentlich ist das Ziel das man gar nichts überschreiben muss, wenn denn die States ordentlich definiert sind. Ich halte mich da eigentlich an den ioBroker-Standard. Siehe den vorherigen Absatz.
Könnte Hannah bei Rolladen Level abfragen auch in "offen/zu" übersetzen statt 0% und 100%
Sollte sie eigentlich können. Klappt das bei dir nicht? Zeig mir gerne Logfiles von dem Versuch vielleicht kann ich dann sehen wo es hängt. Ich habe selbst leider keine Rollläden zum Testen.
Hannah behält den Kontext Wohnzimmer noch eine Weile, richtig
Heute morgen noch, ja. Jetzt nicht mehr. Gerne testen.
"Welche rollläden sind geöffnet"
Was passiert wenn du das gleiche bspw. mit Lichtern fragst, also "Welche Lichter sind an?" Teste bitte.
Sondergeräten
Dazu haben wir uns ja erst kürzlich wieder ausgetauscht :D Du darfst dich gerne nochmal dazu melden, wenn du irgendwo hängst ;)
Liebe Grüße
-
Also ich Währe mit einem Sateliten bei der Bestellung dabei.
Allerdings hab ich eine Bestellung mal bei PCBWay Durchgespielt, muss aber ehrlich sagen, ich bin zu Alt für den Sch...
Wenn jemand von euch eine Bestellung Anstoßen möchte, wie gesagt ich brauche 1 Stück.
Lasst uns doch hier durch "Zitieren" Feststellen wie viele Geräte ingesamt benötigt werden.
Gruß
Walter -
Also ich Währe mit einem Sateliten bei der Bestellung dabei.
Allerdings hab ich eine Bestellung mal bei PCBWay Durchgespielt, muss aber ehrlich sagen, ich bin zu Alt für den Sch...
Wenn jemand von euch eine Bestellung Anstoßen möchte, wie gesagt ich brauche 1 Stück.
Lasst uns doch hier durch "Zitieren" Feststellen wie viele Geräte ingesamt benötigt werden.
Gruß
Walter@Walter.O.
Für den ersten Test wäre ich auch aktuell bei einem Gerät. Später dann ggf. mehr -
Hey,
kurzer Nachtrag zu meiner Antwort oben, ich habe inzwischen in den Code geschaut und muss eine Aussage präzisieren.muss ich dann alles mehrfach an jedem State überschreiben?
Ich hatte geschrieben, dass man eigentlich gar nichts überschreiben muss. Das stimmt nur für States, deren Rolle Hannah kennt (z.B. switch.light, level.dimmer, value.temperature, sensor.window). Bei zu generischen Rollen wie state (dein Homematic-Kontakt) muss man überschreiben, und zwar so:
- Typ (light, socket, window usw.): einmal am Gerät oder am State, ein Eintrag reicht.
- Key (on, level, open usw.): pro State, weil jeder State im Gerät eine andere Rolle spielt.
Bei einem Licht mit ON/DIMMER/SATURATION also den Typ einmal setzen, den Key nur bei den States, die nicht automatisch erkannt werden.
current = ACTUAL_HUMIDITY
current = ACTUAL_TEMPERATUREDer Haken ist, dass ein Gerät (der Kanal/Ordner, in dem die States liegen) nur einen current-Platz hat. Liegen Temperatur und Feuchte im selben Kanal, überschreiben sie sich gegenseitig. Dafür wäre ein Mapping in der WebUI keine Lösung, das würde nur beide auf denselben Platz legen. Sauber ist es, die beiden auf getrennte Geräte zu legen (Alias), jeweils mit der passenden Rolle (value.temperature bzw. value.humidity).
Die Warnung mit ACTUAL (Matter ContactSensor-1) sieht mir nach demselben Fall wie beim Fenster aus: Die Rolle ist für Hannah zu generisch, also Override auf open. Ohne den Objektdump kann ich das aber nicht sicher sagen.
Könnte Hannah bei Rolladen Level abfragen auch in "offen/zu" übersetzen
Ich hatte geschrieben, das sollte sie eigentlich können. Präzisierung: Steuern geht ("Rolladen auf/zu" setzt 100%/0%), aber beim Abfragen nennt Hannah aktuell nur den Prozentwert. Deine Logs passen genau dazu. Eine Übersetzung in offen/zu (mit Prozent für alles dazwischen) gibt es noch nicht, ich schaue mir an, wie ich das sinnvoll mache.
Langfristig denke ich über ein Modell nach, in dem der Adapter Geräte anhand von Rolle, Raum und Function selbst zu typisierten Geräten (Licht, Thermostat, Sensor usw.) zusammensetzt. Dann wären Overrides die Ausnahme statt die Regel. Das ist noch Konzeptarbeit, aber genau dein Punkt ist einer der Auslöser dafür.
Liebe Grüße
-
Hey,
kurzer Nachtrag zu meiner Antwort oben, ich habe inzwischen in den Code geschaut und muss eine Aussage präzisieren.muss ich dann alles mehrfach an jedem State überschreiben?
Ich hatte geschrieben, dass man eigentlich gar nichts überschreiben muss. Das stimmt nur für States, deren Rolle Hannah kennt (z.B. switch.light, level.dimmer, value.temperature, sensor.window). Bei zu generischen Rollen wie state (dein Homematic-Kontakt) muss man überschreiben, und zwar so:
- Typ (light, socket, window usw.): einmal am Gerät oder am State, ein Eintrag reicht.
- Key (on, level, open usw.): pro State, weil jeder State im Gerät eine andere Rolle spielt.
Bei einem Licht mit ON/DIMMER/SATURATION also den Typ einmal setzen, den Key nur bei den States, die nicht automatisch erkannt werden.
current = ACTUAL_HUMIDITY
current = ACTUAL_TEMPERATUREDer Haken ist, dass ein Gerät (der Kanal/Ordner, in dem die States liegen) nur einen current-Platz hat. Liegen Temperatur und Feuchte im selben Kanal, überschreiben sie sich gegenseitig. Dafür wäre ein Mapping in der WebUI keine Lösung, das würde nur beide auf denselben Platz legen. Sauber ist es, die beiden auf getrennte Geräte zu legen (Alias), jeweils mit der passenden Rolle (value.temperature bzw. value.humidity).
Die Warnung mit ACTUAL (Matter ContactSensor-1) sieht mir nach demselben Fall wie beim Fenster aus: Die Rolle ist für Hannah zu generisch, also Override auf open. Ohne den Objektdump kann ich das aber nicht sicher sagen.
Könnte Hannah bei Rolladen Level abfragen auch in "offen/zu" übersetzen
Ich hatte geschrieben, das sollte sie eigentlich können. Präzisierung: Steuern geht ("Rolladen auf/zu" setzt 100%/0%), aber beim Abfragen nennt Hannah aktuell nur den Prozentwert. Deine Logs passen genau dazu. Eine Übersetzung in offen/zu (mit Prozent für alles dazwischen) gibt es noch nicht, ich schaue mir an, wie ich das sinnvoll mache.
Langfristig denke ich über ein Modell nach, in dem der Adapter Geräte anhand von Rolle, Raum und Function selbst zu typisierten Geräten (Licht, Thermostat, Sensor usw.) zusammensetzt. Dann wären Overrides die Ausnahme statt die Regel. Das ist noch Konzeptarbeit, aber genau dein Punkt ist einer der Auslöser dafür.
Liebe Grüße
-
Hier nochmal eine Erinnerung an die Umfrage zur Sammelbestellung - bei Interesse bitte eintragen!
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
504
Online33.1k
Benutzende83.9k
Themen1.4m
Beiträge