Node.js 24 ist jetzt offiziell empfohlen!

[Walter.O.]

OK, läuft. erstmal.
Jetzt habe ich noch einen Keller_water_detector , Zigbee.
Wie kann man Battery Status Low , Remaining battery in %, und Water leak detected

Welcher Kanonischer State-Key
Welche Gerätekategorie
bei den einzelnen Datenpunkte

[Leonie]

Aktuell gar nicht. Die Typen sind aktuell nicht unterstützt. Du könntest bspw. einen Trigger anlegen mit der StateID von battery_remaining und Hannah darauf reagieren lassen:

Genau so auch bspw. für water leak detected, da könnte Hannah eine Ansage machen, das ein Wassereinbruch erkannt wurde.

Eine Abfrage per Sprache oder Text wird von der NLU stand jetzt aber nicht unterstützt.

[Walter.O.]

Super Danke

[Leonie]

🚀 Update: das hat sich seit dem 24. August getan

Hallo zusammen,

seit meinem letzten Update am 24. August ist wieder einiges passiert – diesmal sogar so viel, dass der Beitrag etwas länger wird. Viel steht hier auch über die letzten Seiten schon verstreut, aber an der Stelle nochmal gebündelt. Holt euch einen Kaffee ☕

Drei große Brocken haben den Monat bestimmt: Container-Images, eine komplett neue Dokumentation und der Log Collector. Dazu kommen jede Menge neue Funktionen und Bugfixes, von Hannah Core 0.75.1 bis 0.87.5.

---

🐳 Container-Images für alle Komponenten

Das Thema kam hier im Thread immer wieder auf, und ihr hattet recht: Eine native Installation per install.sh ist nicht jedermanns Sache. Deshalb gibt es jetzt für alle Komponenten fertige Multi-Arch-Images (amd64 + arm64) auf quay.io – Core, WebUI, Proxy, Telegram, VoiceID, Timer, Log Collector und die Teams-Bridge.

Die ersten Tage waren… lehrreich. Das erste Image-Release ist direkt beim Zusammenbauen der Multi-Arch-Manifeste gescheitert, dem Proxy-Image fehlte die C-Bibliothek, die sein Binary brauchte, VoiceID wollte auf arm64 mehrere Gigabyte CUDA-Treiber installieren (für eine Grafikkarte, die es gar nicht gibt 🙃), und der Admin-Zugang beim ersten Start tauchte im Container-Log nicht auf. Das ist inzwischen alles behoben.

Was euch das Leben leichter macht:

• Jede Einstellung per Umgebungsvariable – config.yaml ist für Core, Telegram, Proxy und VoiceID jetzt optional. Alles lässt sich direkt in der docker-compose.yml setzen.
• Eine Compose-Datei mit Profilen – Core und WebUI laufen immer, alles andere schaltet ihr per Profil dazu (with-proxy, with-voiceid, with-timer, with-logcollector, … oder einfach full).
• Compose-Generator in der neuen Doku: Häkchen setzen, was ihr haben wollt, und ihr bekommt eine fertige docker-compose.yml inklusive zufällig erzeugter Passwörter.
• Core startet jetzt auch sauber, wenn der MQTT-Broker beim Hochfahren noch nicht erreichbar ist (vorher Absturz – bei Docker Compose leider der Normalfall).

---

📚 Die neue Doku: hannah-docs.leonie.network

👉 https://hannah-docs.leonie.network

Das war ehrlich gesagt der größte Zeitfresser des Monats. Bisher lag das Wissen über Hannah verstreut in READMEs, Changelogs und meinem Kopf. Jetzt gibt es ein richtiges Handbuch – geschrieben für Leute, die Hannah betreiben wollen, nicht nur für Entwickler.

Was schon drin ist:

• Installation per Docker oder nativ, Schritt für Schritt
• Jede Komponente mit Übersicht, Installation und Konfiguration – inklusive einer ehrlichen Einschätzung, ob ihr sie überhaupt braucht (Ja, Empfohlen oder Bei Bedarf)
• Satelliten-Platine bestellen – eine Anleitung für die Rev. 5 bei PCBWay, plus Inbetriebnahme (Antenne, Stromversorgung, Flashen direkt aus dem Browser)
• Anleitungen für WebUI-Themen wie Wecker, Satelliten-Verwaltung, Kontoverknüpfung usw.

Ein netter Nebeneffekt: Beim Schreiben sind mir eine ganze Reihe Bugs aufgefallen. Beispiel-Configs, die Einstellungen beschrieben haben, die gar nichts tun, fehlende Vorlagen im Release, Installer, die sich ohne Fehlermeldung verabschiedet haben. Doku schreiben ist offenbar auch Qualitätssicherung 😅

Die Doku ist noch lange nicht fertig. Sie liegt auf GitHub, wer also etwas findet oder ergänzen möchte: Pull Requests und Issues sind herzlich willkommen!

---

📋 Neu: der Log Collector

Wer hier schon mal einen Fehler gemeldet hat, kennt das Spiel: „Kannst du mal die Logs von Core schicken? Und vom Adapter? Und vom Proxy? Ungefähr um welche Uhrzeit war das?“ Damit ist jetzt Schluss.

Der Log Collector ist eine neue, optionale Komponente – quasi ein Flugschreiber für Hannah. Alle Komponenten schicken ihm ihre Logs, er hebt sie eine Weile auf (standardmäßig 7 Tage bzw. höchstens 256 MB), und bei Bedarf gibt er sie als ein einziges Archiv heraus.

• Kein Einrichtungsaufwand bei den Komponenten – der Log Collector meldet sich bei Hannah an, und Hannah teilt allen anderen mit, wohin sie ihre Logs schicken sollen.
• Download direkt in der WebUI – als Admin (Trust-Level 10) erscheint oben der Eintrag Logs. Dort wählt ihr Komponenten und Zeitraum aus und bekommt ein .tar.gz.
• Datenschutz eingebaut – was im Haushalt gesagt wurde (Transkripte) und Raum-/Anwesenheitsdaten (Metadaten) sind standardmäßig nicht im Archiv und müssen bewusst dazugewählt werden. Passwörter und Tokens werden schon vor dem Versand herausgefiltert.
• Alles bleibt bei euch – nichts verlässt eure Installation.
• Unterstützt von Core, WebUI, ioBroker-Adapter (ab 1.2.0), Telegram, VoiceID, Proxy, Timer, AutoDeploy und der Teams-Bridge.

Mein Wunsch an euch: Wenn ihr künftig ein Problem meldet, hängt gern so ein Log-Bundle an – ohne Transkripte und Metadaten reicht das fast immer. Das spart uns allen viel Hin und Her 🙏

---

✨ Neue Funktionen

• Anwesenheit komplett neu – Hannah entscheidet jetzt selbst, wer zu Hause ist. Als Quelle taugt jeder Ja/Nein-Datenpunkt aus ioBroker (WLAN, Fritzbox, Türkontakt, Bewegungsmelder, …) sowie Hannahs eigene BLE-Erkennung. Weil nicht jeder Sensor gleich zuverlässig ist, bekommt jede Quelle pro Person ihre eigene Gewichtung, und Hannah wägt die Signale gegeneinander ab. Eine Karenzzeit fängt kurze Aussetzer ab. Kein Hin- und Herspringen mehr zwischen „da“ und „weg“, nur weil ein einzelner Sensor mal kurz wackelt. Die Quellen stellt ihr pro Person in der WebUI ohne Code ein.
• „Gute Nacht“ und „Guten Morgen“ – Hannah kennt jetzt den Schlafstatus und gleicht ihn in beide Richtungen mit dem Residents-Adapter ab. Trigger können die Anwesenheit auch direkt setzen.
• Trigger antworten dort, wo gesprochen wurde – eine Ansage kann jetzt an den „angesprochenen Satelliten“ gehen, statt immer an einen festen Raum.
• Rollläden verstehen – „öffnen“, „schließen“, „hoch“, „runter“, „rauf“ funktionieren jetzt. Aktoren, die 0 % als offen interpretieren (manche Homematic-/KNX-Geräte), lassen sich im Adapter als „invertiert“ markieren. Und ja: „Rolladen“, „Rollläden“ und „Rolläden“ werden jetzt alle erkannt 😄
• Hannah fragt nach, statt zu raten – gibt es einen Gerätenamen in mehreren Räumen, oder könnte „hoch“ sowohl den Rollladen als auch den Lüfter meinen, fragt sie jetzt nach. Ein verhörter Gerätename („Rolladen seit“) wird unscharf abgeglichen, statt einfach alles im Raum zu schalten.
• „Lerne meine Stimme“ – ein geführter Dialog am Satelliten für die Sprechererkennung. Hannah stellt ein paar Fragen und lernt aus euren Antworten, direkt aus der WebUI gestartet.
• Konten verknüpfen, aber einfach – Telegram verknüpft ihr jetzt per Klick auf einen Link aus der WebUI (kein BotFather-Domain-Gefummel mehr), Microsoft-Konten über eine normale Anmeldung.
• Neue Wege, mit Hannah zu reden:
  • Chat im Terminal – Hannah am PC per Tastatur anschreiben
  • Lite-Satellit – ein Satellit als PC-Programm, mit Mikrofon und Lautsprecher des Rechners. Eine Alternative zum vollwertigen Satelliten, z. B. am Schreibtisch oder zum Testen, bevor die Platine da ist
  • Microsoft Teams – Hannah im Teams-Chat anschreiben. Das ist die einzige Komponente, die aus dem Internet erreichbar sein muss, deshalb bitte vorher den Sicherheitsabschnitt in der Doku lesen
• Adapter-Einstellungen mit Formular – Name, Gerätekategorie und Rolle eines Datenpunkts für Hannah lassen sich jetzt im normalen „Benutzerdefinierte Einstellungen“-Dialog setzen, ohne Expertenmodus.
• Piper lädt Stimmen selbst herunter, und kurze Antworten landen im Cache, sodass sie auf dem Pi schneller kommen.

---

🔧 Satellit

Ein Satellit, der abstürzt, hat bisher genau null Spuren hinterlassen. Das ist jetzt anders: Seit Core 0.79.6 schreibt die Firmware bei einem Absturz einen Coredump in einen eigenen Flash-Bereich, den ich danach abholen und auswerten kann. Dafür musste einmalig die Partitionstabelle angepasst werden, und das hat erst im dritten Anlauf geklappt: einmal hat sich der Satellit selbst für ein kaputtes Update gehalten und zurückgerollt, einmal hat ESP-IDF das Schreiben der Partitionstabelle schlicht verweigert (eigentlich eine sinnvolle Schutzfunktion). Mit 0.79.8 läuft es.

Und der Coredump hat sich sofort gelohnt: Satelliten mit aktivem BLE-Scan sind gelegentlich mit einem Stack Overflow im Bluetooth-Task neu gestartet. Mit dem Dump war die Ursache schnell gefunden und ist seit 0.80.3 behoben.

Kleine, aber feine Änderung: PTT funktioniert jetzt auch bei stummgeschaltetem Satelliten. Wer direkt am Gerät steht und die Taste drückt, meint es ernst 😉

---

🛡️ Stabilität

Mein persönlicher Favorit: Hannah hat sich gelegentlich selbst zugehört. Das Echo ihrer eigenen Antwort – oder ihre Stimme im Mikro eines anderen Satelliten – landete als neuer Befehl bei ihr. Jetzt kennt sie ihre eigene Stimme über VoiceID und ignoriert sich selbst (Core 0.75.12).

Außerdem:

• Falscher Raum – „Licht aus“ ohne Raumangabe konnte ein Gerät in einem ganz anderen Raum schalten. Ein nicht gefundener Gerätename hat im schlimmsten Fall den ganzen Raum ausgeschaltet. Beides ist behoben.
• Keine überlappenden Ansagen – spielt ein Satellit gerade etwas ab, werden neue Ansagen nicht mehr einfach darübergelegt.
• Absturz nach längerer Laufzeit – „unable to open database file“ / „File descriptor limit reached“: Datenbankverbindungen wurden nicht sauber geschlossen, besonders unter Python 3.14 (Core 0.86.1).
• Nach einer Rückfrage („Welchen Raum meinst du?“) gehen Statusfragen jetzt nicht mehr verloren, und Hannah antwortet mit dem echten Status statt „Keine Geräte gefunden“.
• Schaltbestätigung ist jetzt ein schlichtes „OK.“ statt einer Geräteanzahl, die oft nicht gestimmt hat.
• Diverse Installer-Fixes: Ubuntu-venvs ohne pip, stilles Abbrechen bei Rate-Limits, fehlende Config-Vorlagen im Release.

---

📦 Aktuelle Versionen

Komponente	Version
Hannah Core	0.87.1
WebUI	2.10.0
ioBroker-Adapter	1.2.0
Proxy	0.87.5
Telegram	0.87.3
VoiceID	0.87.4
AutoDeploy	0.87.5
Timer	0.3.0
Log Collector	0.2.2
Teams Bridge	0.1.0

Ein großes Dankeschön an alle, die hier im Thread testen, Fehler melden und Ideen einbringen – ohne euch gäbe es die Container-Images jetzt noch nicht ❤️

Viele Grüße
Leonie

[Walter.O.]

Hey Leonie, wollt gerade mal Updaten.
Nach Installation von:
curl -fsSL https://raw.githubusercontent.com/NurPech/hannah/master/core/deploy/install.sh | sudo bash
Hannah Core soll sein 0.87.5 , ist bei mir 0.8.7.1

[Leonie]

Ich habe die Tabelle korrigiert. Für den Core ist Version 0.87.1 aktuell. Ursprünglich hatte ich die falsche Version genannt. Danke dir

[Walter.O.]

Dann noch, Ich komm nicht mehr auf die Webui

[Leonie]

Hast du Logs?

[Walter.O.]

@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)

[Leonie]

Und was heißt "du kommst nicht drauf"?

[Walter.O.]

Erledigt, hat nach 5 mal neu starten jetzt geklappt

[Leonie]

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

[manne01]

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 :D

Bei 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äumen

Es 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!

[Leonie]

Hey

@manne01 sagte:

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.

@manne01 sagte:

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

@manne01 sagte:

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.

@manne01 sagte:

Ich muss das also umgehend testen! :-)

Auf jeden Fall und bitte melden, ich bin auf das Ergebnis gespannt :)

@manne01 sagte:

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.

@manne01 sagte:

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.

@manne01 sagte:

Richtig gut ist auch die neue Geräteliste in der WebUI

Vielen Dank

@manne01 sagte:

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.

@manne01 sagte:

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.

@manne01 sagte:

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.

@manne01 sagte:

Hannah behält den Kontext Wohnzimmer noch eine Weile, richtig

Heute morgen noch, ja. Jetzt nicht mehr. Gerne testen.

@manne01 sagte:

"Welche rollläden sind geöffnet"

Was passiert wenn du das gleiche bspw. mit Lichtern fragst, also "Welche Lichter sind an?" Teste bitte.

@manne01 sagte:

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

[Walter.O.]

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

[micklafisch]

@Walter.O.
Für den ersten Test wäre ich auch aktuell bei einem Gerät. Später dann ggf. mehr

[Leonie]

Hey,
kurzer Nachtrag zu meiner Antwort oben, ich habe inzwischen in den Code geschaut und muss eine Aussage präzisieren.

@manne01 sagte:

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.

@manne01 sagte:

current = ACTUAL_HUMIDITY
current = ACTUAL_TEMPERATURE

Der 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.

@manne01 sagte:

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

[Jey Cee]

@Leonie sagte:

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.

Dafür gibt es den type detector von ioBroker. Weis nicht ob du den schon kennst.

[Leonie]

Den habe ich auch gefunden :) Der steht auch in meinem Konzept bereits drin. Das Problem ist aber nicht ioBroker, sondern Hannah, sie muss das erstmal verstehen können :D

[manne01]

Hier nochmal eine Erinnerung an die Umfrage zur Sammelbestellung - bei Interesse bitte eintragen!