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

[duemchen]

@luxi
Review ist durch. Ich wollte 2 bestellen. (Leiterplatte sind wohl 5er Stückzahl) Wollen wir gemeinsam bestellen?

[Luxi]

Hi all,
Zur Info für alle interessierten hier ist der aktuelle Preis bei einem Stück:
"Thanks for your inquiry #T-5D2W1132151A-1unit-Hannah_Satellite.kicad_pcb_bom(2026-09-02).
Please check the attached quotation for 1 unit of assembled boards.
Price Details
Component Cost $62.85
Assembly Cost $29.00
PCB Cost $25.97
All Total 1 Units $117.82
Delivery Time 22-25 days
"
@duemchen gute Idee vielleicht schließt sich noch jemand an.

Ich frage direkt mal bei PCBway an ab welcher Stückzahl sich die Kosten senken.

[Leonie]

Theoretisch schon ab Stückzahl = 2, nur wird das PCBWay auch nicht bauen wollen, bzw. teuer machen.

Die Component Costs von 62,85$, kommt zum Größtenteil von den MOQs der Bauteile und dem Fakt das die Maschinen auch gerne mal 10 Bauteile "fressen" und erst das 11. Bauteil auf der Rolle dann auf die Platine kommt.

Die Assembly Costs sind ziemlich fix, das ist quasi der One Time Fee damit sie es bauen.

Die PCB Costs werden mit steigender Stückzahl immer kleiner werden. Die Fabrik kann keine runde Platine mit 88mm Durchmesser bauen, die müssen das auf Panels bringen. Die Standard Panelgröße ist so 400x500mm. Auf das Panel können sie auch die Hardware von anderen Kunden packen, aber der Verschnitt ist riesig, hier zahlt man quasi auch den Müll. Je weniger Verschnitt, desto günstiger.

[Rogni]

mal noch eine Frage, funktioniert das auch mit ali esp32-s3 Satelliten zum testen ?
Sammelbestellung bei pcb würde ich mitmachen

[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?