Der neue Monatsrückblick für September 2026 ist online!

[Leonie]

Hi!

Schau am besten mal oben in Beitrag #43 rein – da hatte ich genau zu dem Thema schon mal ein paar Details aufgeschrieben. 😉

Die Kurzversion:
Ein nacktes AliExpress-DevKit läuft out-of-the-box nicht, weil die Firmware zwingend zwei Mikrofone und einen I2S-Verstärker erwartet.

Du kannst dir das Ganze zum Testen mit einem ESP32-S3-DevKitC-1 und den passenden Breakouts auf einem Breadboard zusammenstecken (Dafür gibt's im Repo sogar ein eigenes Kconfig-Profil).

Wenn du aber eine saubere, kompakte Lösung ohne fliegende Kabel und Rauschen willst, fährst du mit der PCBWay-Sammelbestellung für die Rev 5 definitiv am besten!

Liebe Grüße

[Jey Cee]

@Leonie sagte:

Ein nacktes AliExpress-DevKit läuft out-of-the-box nicht, weil die Firmware zwingend zwei Mikrofone und einen I2S-Verstärker erwartet.

Was ist den mit dem hier: https://www.waveshare.com/esp32-S3-audio-board.htm
Das sieht für mich so aus als wären Mikrofone und Verstärker per I2S angebunden. Das ist vom Preis auch sehr interessant.

[Rogni]

@jey-cee , genau das meinte ich mit Ali Express Teil.

https://de.aliexpress.com/item/1005009901543357.html?spm=a2g0o.tm1000063736.appPushSupportRecommend.1.b76a20aaOM4qeP&gps-id=appPushSupportRecommend&_t=gps-id%3AappPushSupportRecommend&isseo=y&pdp_ext_f={"order"%3A"151"%2C"eval"%3A"1"%2C"sceneId"%3A"57346"%2C"fromPage"%3A"recommend"}&pdp_npi=6%40dis!EUR!21.66!19.49!!!24.51!22.05!%402103877917884213426418075e0ff2!12000050524718050!rec!DE!!ABXZ!1!0!n_tag%3A-29910%3Bd%3A401729f5%3Bm03_new_user%3A-29895&utparam-url=scene%3AappPushSupportRecommend|query_from%3A|x_object_id%3A1005009901543357|_p_origin_prod%3A

https://de.aliexpress.com/item/1005009578368362.html?spm=a2g0o.detail.pcDetailTopMoreOtherSeller.4.5476iea4iea42R&gps-id=pcDetailTopMoreOtherSeller&scm=1007.40050.354490.0&scm_id=1007.40050.354490.0&scm-url=1007.40050.354490.0&pvid=e592de53-642e-46f8-ae08-247c44dfcb04&_t=gps-id%3ApcDetailTopMoreOtherSeller%2Cscm-url%3A1007.40050.354490.0%2Cpvid%3Ae592de53-642e-46f8-ae08-247c44dfcb04%2Ctpp_buckets%3A668%232846%238110%231995&isseo=y&pdp_ext_f={"order"%3A"648"%2C"eval"%3A"1"%2C"sceneId"%3A"30050"%2C"fromPage"%3A"recommend"}&pdp_npi=6%40dis!EUR!68.03!65.99!!!516.94!501.44!%402103877917884213489488219e0ff2!12000056553679001!rec!DE!!ABXZ!1!0!n_tag%3A-29910%3Bd%3A401729f5%3Bm03_new_user%3A-29895&utparam-url=scene%3ApcDetailTopMoreOtherSeller|query_from%3A

[manne01]

Denke auch wir sollten hier mal das Interesse sammeln. Ich würde mich auf jeden Fall auch gerne anschließen bei einer Sammelbestellung, sagen wir mal 3 Stück.

[Walter.O.]

Beim PCBWay bin ich erstmal raus, muss mit der Rente etwas Rechnen.
Waveshare Währe okay.

[jwerlsdf]

ich würde ebenfalls mitbestellen, aber nur 1-2 Stück.

[zahnheinrich]

Wäre auch mit 2 Stück dabei!

[duemchen]

in Sammelbestellung bin ich auch gern mit 1 dabei.
Vielleicht kann eine/r aus dem Erfinderteam, der sich mit PCBWay Bestellungen auskennt,
per Vorkasse paypal einsammeln und auslösen?

Waveshare wäre mir natürlich auch lieber, aber wer wird das anpassen in den nächsten Wochen ? Gibts da Hoffnung?

[Mario64]

Hallo :-)

Mal so in die Runde gefragt: Muss die PCB für die Satelliten rund sein ??
Rechteckig ... wäre weniger Abfall bei der Produktion (Preis runter).

JLCPCB wäre vielleicht auch eine Alternative. Ich hab dort schon mehrere PCB produzieren lassen und bin sehr zufrieden.

Nur mal so als kleiner Einwurf.

Gruss vom Mario ;-)

[Leonie]

Hi Mario,

Zu JLCPCB vs. PCBWay:
Ich habe meine Prototypen fast alle bei JLCPCB fertigen lassen und bin mit der Qualität absolut zufrieden. Allerdings ist JLCPCB beim Bestücken (Assembly) im Vergleich zu PCBWay preislich oft sogar einen Ticken teurer. Der Hauptgrund, warum ich das Projekt aber bei PCBWay bereitstelle, ist deren exzellentes „Shared Projects“-Portal. Bei JLCPCB/OSHWLab ist das Verteilen von kompletten Bestückungsdaten für die Community extrem frickelig. Bei PCBWay klickt man auf „Order“ und es läuft einfach. (Die Daten liegen zwar auch schon auf OSHWLab, aber PCBWay ist aktuell der sauberste Weg für alle).

Zum runden Design (88 mm, 4 Layer, 24 RGB-LEDs):
Weil es genau so mein fertig durchdachtes Design für das Gehäuse und das Gesamtkonzept ist. Ein rechteckiges Board spart beim Nackt-FR4 vielleicht zwei Cent, passt dann aber weder in das Gehäuse noch zum integrierten LED-Ring. Man könnte die Platine theoretisch auch mit 7x8m fertigen lassen, wenn man denn eine Fabrik dafür findet und glaubt, das noch in ein Gehäuse zu bekommen. 😉

Das ist das Schöne an Open Source: Die Vorlage bei PCBWay ist mein schlüsselfertiges Angebot an die Community. Wer genau dieses Paket möchte, klickt auf Bestellen – und wer es lieber eckig, günstiger oder ganz anders haben will, darf sich auf GitHub gerne die Firmware anschauen und ein eigenes Layout zeichnen!

@Jey-Cee sagte:

https://www.waveshare.com/esp32-S3-audio-board.htm

Das hat mit der Rev 5 leider kaum etwas gemein.

Die größten Hürden:

Andere Audio-Architektur: Das Board verwendet die Codecs ES7210 und ES8311. Meine Firmware nutzt stattdessen Direkt-I2S für die Mics (DevKit) oder TDM über einen ADAU7118 (Rev 5) und den MAX98357A. Mit bloßem Pins-Ummappen ist es da nicht getan – dafür bräuchte die Firmware komplett neue Codec-Treiber. Außerdem steckt da ein nicht unterstützter Portextender drauf, auch der müsste in der Firmware programmiert werden.

Speicher: Das Waveshare hat nur 8MB Flash (WROOM-1-N8R8) statt der 16MB Flash der Rev 5 (N16R8).

Peripherie: Kamera und Display werden von der Firmware gar nicht angesprochen, dafür fehlt ein Button und die komplette Sensorik.

Das DevKit-Setup bleibt also weiterhin der einzige valide Bastel-Pfad ohne Rev 5 Platine.

@Rogni sagte:

https://de.aliexpress.com/item/1005009578368362.html?spm=a2g0o.detail.pcDetailTopMoreOtherSeller.4.5476iea4iea42R&gps-id=pcDetailTopMoreOtherSeller&scm=1007.40050.354490.0&scm_id=1007.40050.354490.0&scm-url=1007.40050.354490.0&pvid=e592de53-642e-46f8-ae08-247c44dfcb04&_t=gps-id%3ApcDetailTopMoreOtherSeller%2Cscm-url%3A1007.40050.354490.0%2Cpvid%3Ae592de53-642e-46f8-ae08-247c44dfcb04%2Ctpp_buckets%3A668%232846%238110%231995&isseo=y&pdp_ext_f={"order"%3A"648"%2C"eval"%3A"1"%2C"sceneId"%3A"30050"%2C"fromPage"%3A"recommend"}&pdp_npi=6%40dis!EUR!68.03!65.99!!!516.94!501.44!%402103877917884213489488219e0ff2!12000056553679001!rec!DE!!ABXZ!1!0!n_tag%3A-29910%3Bd%3A401729f5%3Bm03_new_user%3A-29895&utparam-url=scene%3ApcDetailTopMoreOtherSeller|query_from%3A

Der ReSpeaker XVF3800 ist zwar ein starkes Board für Konferenzräume und wird gerne für Sprachassistenten verwendet, ist aber für das Projekt aktuell aus mehreren Gründen ungeeignet:

Preis: Für ~66 € bekommt man, bei der richtigen Stückzahl, fast zwei komplett bestückte Rev 5 Platinen inklusive Sensorik und LED-Ring.

Architektur: Die Mikrofone hängen an einem dedizierten XMOS-DSP-Coprozessor. Die Audiodaten werden dort verarbeitet und völlig anders an den ESP32 weitergereicht als bei meinem Direkt-I2S-Setup. Meine Firmware unterstützt diesen Coprozessor schlichtweg nicht.

Liebe Grüße

[Jey Cee]

@Leonie danke für die Ausführliche Erklärung.

[Rogni]

@leonie vielen Dank für die Antwort.
Da ich momentan mit dem WoMo unterwegs bin, kümmere ich mich in 14 Tagen mal drum bei pcbWay durchzusteigen.
Gibt es für das Ganze eigentlich schon ein Gehäuse ?? Erhöht den WAF erheblich ;-)

[Leonie]

Theoretisch habe ich eines designed, ja. Ich weiß gerade nur nicht ob die Daten auf github liegen, das muss ich prüfen.

[manne01]

Hi @Leonie,

ich habe nun auch die voices soweit erfolgreich enrollt. (Musste dazu auf meinem Rechner noch ein python env erstellen und div. Sachen installieren aber hat geklappt. Auch musste ich für docker noch den Port aus dem Hannah-Netzwerk herausgeben Richtung Host damit der voice-Server vom Desktop aus erreichbar ist. Das könnte ggfs. noch in die Doku.). Kann man das irgendwie testen wie gut das klappt - per Telegram? Also Hannah fragen wer ich bin oder so? Oder gibts bestimmte Logmeldungen?

Auch STT habe ich inzwischen "lokal remote" am laufen mit einem speaches-Container, der könnte auch TTS.
In der core_config steht bei TTS "piper (lokal/offline) | azure | polly" - kann ich auch das lokal remote laufen lassen, oder macht das keinen Sinn?

Nun aber zu meiner aktuellen Hauptbaustelle, die Geräte, ihre Räume, Funktionen, Rollen und States.
Du hattest ja in #75 schon einiges erklärt. Ich habe nun viel rumprobiert und leider noch wenig erreicht. Meine Geräte werden je nach Filter im Hannah-Adapter erfolgreich zu Hannah übertragen und - im Log sichtbar - nach Räumen sortiert. Im Log werden auch die Status angezeigt die sie mitbringen, z.B. "[INFO] hannah.iobroker: · Rolladen Balkonfenster () [blind] — States: DIRECTION, INHIBIT, INSTALL_TEST, LEVEL, STOP, WORKING". -> sind aber alles "unbekannte State-Suffixes.

Ich erhalte im core-log z.B. "[WARNING] hannah.iobroker: Unbekannter State-Suffix 'LEVEL' (state_id=hm-rpc.0.NEQ1234567.1.LEVEL) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (Wert friert auf dem letzten Snapshot ein)." -> das düfte sich zwischenzeitlich auf die WebUI Settingstabelle beziehen, aber was muss ich in dem Fall tun?

Im Hannah-WebUI-Settings habe ich eine Mappingtabelle für Iobroker state_names gesehen, es steht aber für Key und Value links und rechts immer dasselbe drin und ich weiß nicht was was ist. Hier habe ich bisher nichts geändert.
Im Hannah-Adaper habe ich nichts gesehen wo ich State-Suffixes konfigurieren könnte.

Das Virtual Device Script oder den Devices Adapter für Aliases oder ähnliches verwende ich aktuell nicht.

Ich mache ein Beispiel:
Ich habe ein Schlafzimmer mit 3 Rolladenaktoren, einem Thermostat und einigen Schaltern. Diese Geräte sind alle auch dem Raum Schlafzimmer zugeordnet. Ein typisches Kommando wäre nun "Wie ist der Status des Rolladen im Schlafzimmer Seite?" (Rolladen am seitlichen Fenster) oder "Öffne den Rolladen Balkonfenster im Schlafzimmer"

An Hand von was bezieht Hannah das nun auf meine Gerätelandschaft? Nimmt sie den Geräte-Namen auseinander (etwa "Rolladen Seite" im Zimmer "Schlafzimmer")? Kann ich "seite" oder "seitlich" sagen und spielt die Reihenfolge der Wörter im Gerätenamen eine Rolle?

Wie verhält es sich mit den States? Wie wird von meinem IoBroker Objekt (mit Hilfe der Hannah-Settings?) ein Status abgefragt oder gesetzt?

Mein Beispiel-Rolladen sieht in iobroker so aus (Ich habe als Sensoren und Aktoren vor allem Geräte von Homematic):

hm-rpc.0.NEQ7777777.1.LEVEL
Name: "Rolladen Seite.LEVEL"
Typ: State
Rolle: level.blind
Raum: Schlafzimmer
Funktion: Rolladen
Wert: 57% # also halb zu

Das Gerät hm-rpc.0.NEQ7777777. hat natürlich noch viel mehr Datenpunkte (siehe oben im Log) - die lasse ich jetzt mal bewusst außen vor.

@Leonie sagte:

Das Verhalten vom Adapter kann man auf mehrere Arten beeinflussen. So kann man States bspw. eigene Eigenschaften hinzufügen, die dem Adapter mitteilen, wie er den State zu nutzen hat.

Aber wie? Bei Fragen nach STATE und LEVEL sagt mir Hannah bei Frage nach dem Status immer, sie weiß nicht ob ... an oder aus ist. An was erkennt Hannah ob es true/false oder ON OFF oder Werte 1-100 zurückgibt? An der Role? Welche Roles kennt Hannah? Kann ich welche hinzufügen?

Wie geht man generell am besten vor? Einfach alles übertragen an Hannah? Oder schön ausgewählt nur die jeweiligen States die man benötigt? Ich habe nun für den ersten Test-Raum den ich zu Hannah übertrage alle anderen Geräte entfernt, damit ich da irgendwie etwas den Überblick behalte...

Soviel mal von mir heute

[Leonie]

Hii,

vielen Dank fürs Testen und die ausführliche Rückmeldung! Der Reihe nach:

Docker-Port für den Voice-Server
Das ist aktuell nur nötig, weil EnrollVoiceprint (der eigentlich vorgesehene Weg über Hannah selbst) noch nicht end-to-end verdrahtet ist — der einzige heute funktionierende Enrollment-Weg ist ein Standalone-Script, das direkt mit der VoiceID-REST-API spricht, und dafür muss der Port eben erreichbar sein. Sobald Enrollment sauber über Hannah läuft, sollte der manuelle Port-Umweg wieder wegfallen — das kommt also nicht dauerhaft in die Doku, sondern eher auf die Liste für's richtige Fertigstellen von VoiceID-Enrollment.

Voice-Enrollment testen
Das lässt sich über Telegram aktuell grundsätzlich nicht überprüfen — der Speaker-ID-Abgleich (VoiceID) hängt komplett am Satelliten-Audio-Pfad. Alles was über Telegram reinkommt (Text wie Voice-Message) rührt VoiceID gar nicht an. Sobald du einen Satelliten hast, ist das testbar; ohne einen bringt dir das Enrollment aktuell schlicht noch nichts.

TTS „lokal remote" über speaches
Piper/Azure/Polly sind aktuell die einzigen Backends — ein generisches HTTP/OpenAI-kompatibles Backend gibt's noch nicht. Wäre grundsätzlich sinnvoll, ist aber ein neues Feature, kein Konfigurationsproblem bei dir.

State-Suffixe / state_names-Tabelle
Zur Tabelle: links steht der feste, kanonische Name, den Hannahs Code intern erwartet (on, level, color, ...) — den änderst du nicht. Rechts trägst du den tatsächlichen State-Suffix ein, den deine Geräte verwenden. Bei dir wäre das für den Rolladen z.B. "level": "LEVEL" (dein Homematic-Rolladen nutzt LEVEL, nicht level).

Beim Code-Review ist mir aber aufgefallen, dass das aktuell wahrscheinlich nicht reicht: Die Übersetzung über state_names greift offenbar nur beim Lesen (Status abfragen), nicht beim Schreiben (Rolladen tatsächlich steuern) — dort sucht Hannah weiterhin nach dem kanonischen Namen und findet nichts, unabhängig von der Konfiguration. Das würde erklären, warum dir Status-Abfragen „unknown" liefern, und passt auch dazu, dass Steuerbefehle vermutlich (noch) gar nicht ankommen. Ich hab das als Bug eingetragen, aber noch nicht an echten Daten verifiziert — wäre klasse, wenn du mir einen Objekt-Export deines Rolladens geben könntest (ioBroker Admin → Objekte → das Device-Objekt anklicken → Objektbaum als JSON exportieren, also die Kette hm-rpc.0.NEQ.../1 + .../1.LEVEL). Mit den echten common.role/common.name-Werten kann ich das sauber nachvollziehen und fixen.

Wie findet Hannah das Gerät im Satz?
Es findet kein Parsing nach Kategorie+Lage statt, sondern ein einfacher Textabgleich: Der komplette Gerätename (wie in ioBroker als Friendly Name hinterlegt) muss als zusammenhängender Ausdruck im gesprochenen Satz vorkommen — Groß-/Kleinschreibung egal, aber Reihenfolge der Wörter im Namen muss stimmen. Bei „Rolladen Balkonfenster" matcht „Öffne den Rolladen Balkonfenster im Schlafzimmer", aber nicht „Öffne den Balkonfenster-Rolladen". Synonyme wie „seite"/„seitlich" werden nicht erkannt, außer sie stehen wortwörtlich so im Gerätenamen. Der Raum wird davor separat und unabhängig erkannt, die Reihenfolge Raum/Gerät im Satz spielt keine Rolle.

Falls dir mal ein Gerätename für Sprachbefehle ungünstig ist: aktuell gibt's dafür keinen Override, nur für die Kategorie (common.custom["hannah.0"].type). Hab ich als Feature für den Adapter eingetragen — kommt aber noch nicht.

Rollen/States
Die Kategorie-Erkennung (blind/light/socket/climate/...) läuft komplett im Adapter über common.role deines States — bei dir hat das schon funktioniert, dein Rolladen wurde korrekt als blind erkannt (level.blind-Rolle). Die Liste ist im Adapter-Code fest hinterlegt, aber grundsätzlich erweiterbar — falls dir eine Rolle fehlt, sag Bescheid.

Alles übertragen oder gezielt auswählen?
Dein Vorgehen (erstmal nur einen Test-Raum übertragen) ist genau richtig — würde ich auch so empfehlen, bis die Basis für dich rund läuft. Mehr Geräte bringen erstmal nur mehr Rauschen beim Debuggen.

Meld dich mit dem Objekt-Dump, dann schau ich mir das konkret an!

Liebe Grüße

[manne01]

Hi,

seltsam, ich hatte vor ca. einer Woche ja bereits erfolgreich einen Rolladen per Telegram geschlossen und Hannah hatte mir das auch per Telegram bestätigt.

Den Objektbaum sende ich Dir per Chat.

In den States vom WebUI habe ich STATE mal bei open hinterlegt und LEVEL bei level.

Und die aktuelle Logausgabe von Hannah-Core zu meinem Beispielrolladen:
10:15:30 [INFO] hannah.iobroker: · Rolladen Seite () [blind] — States: LEVEL

STATE und LEVEL werden auch nicht mehr moniert. Aber z.B. noch sowas:
10:15:30 [INFO] hannah.iobroker: · Thermostat WT2:2 () [climate] — States: ACTUAL_HUMIDITY, ACTUAL_TEMPERATURE

Ich habs mir auch weiter weiter angesehen und folgendes festgestellt:

In ioBroker bei den Objekten gibt es ja typischerweise ein Gerät z.B. NEQ... unterhalb von dem sind dann Unterpunkte z.B. 1 / 2 und unterhalb von diesen sind dann die einzelnen States/Datenpunkte.

Wichtig scheint mir:
Der Raum kann, muss aber nicht dem ganzen Gerät zugeordnet sein, nur ab der Unterstruktur (z.B. "1", einschließlich) und allem darunter. Wenn man auf die z.B. "1" den Raum setzt ist der dort in schwarzer Schrift, der drunterliegende "Objektbaum" erbt diesen Raum dann (graue Schrift).
Die Funktion muss nur den States/Datenpunkten zugeordnet sein, die man in Hannah haben möchte.
Oder andersrum gesagt, wenn man beides aufs nötige reduziert kann man sich im ioBroker Objektmanager und im Hannah Log besser orientieren - und wir implementieren nur Zustände die man auch wirklich braucht.

Eine "vererbte Funktion" genügt meiner Erfahrung nach nicht! Die Funktion muss tatsächlich am gewünschten State direkt gesetzt werden (und also in schwarzer Schrift angezeigt werden)!

Noch etwas: Ich synchronisiere die Homematic Geräte aus der CCU mit hm-rega. Das mache ich jetzt "seit Hannah" nur noch für die Namen, nicht die Räume und schon garnicht die "Gewerke". Denn Räume und Gewerke werden sonst zu flächendeckend auf die Objekte gesetzt. Und genau das will ich ja nun in IOBroker machen. Für die Namen finde ich den Sync aber gut, damit man auch in der CCU noch etwas Überblick und Einheitlichkeit hat.
Ich habe dabei auch Mehrfachkontakt-Übertrager, die mir zB Fenster-Status von Fenstern mehrerer Räume übermitteln. Wenn ich dort die einzelnen Fensterkontakte mit "Fensterkontakt" benenne, erlaubt die CCU keine Doppelbelegungen und fügt hinten was an so dass "Fensterkontakt 1" oder "Fensterkontakt 2" rauskommt. Ich hab es noch nicht getestet, aber ich vermute es käme in dem Fall keine Match zu Stande wenn man diese Ziffer nicht dazusagt. Ignoriert der Hannah-Adapter beim Matching zufällig reine Ziffern oder Sonderzeichen aus den Gerätenamen?

[Leonie]

Wie testest du? Ich meine du nutzt aktuelle Telegram? testest du per Textchat, per Voicechat oder per Menü? Je nachdem weiß ich auf welchem Pfad ich suchen muss.

Update bitte deinen Core auf Version 0.77.0 und den Adapter auf 1.1.1. Beide beinhalten Fixes für deinen beschrieben Fall. Außerdem habe ich eine UI eingeführt, die es auf einfache Art und Weise ermöglicht die Informationen über den State zu ändern. Das geht über die erweiterten Einstellungen der States:

Sind die Einstellungen nicht aktiviert oder einzelne Teile nicht gefüllt, versucht der Adapter sein Bestes um anhand der Stateinformationen an den Typ zu kommen.

[manne01]

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

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

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

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

Die Statusabfrage und setzen klappt jetzt sehr viel besser:

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

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

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

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

Viele Grüße und schönen Abend!

[Leonie]

Hi manne01,

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

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

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

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

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

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

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

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

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

Danke nochmal fürs genaue Hinschauen!

[Luxi]

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