Hannah — Open Source Smart-Home-Sprachassistentin

Walter.O.

Wenn ich 192.168.178.122 eingebe kann ich mich nicht mehr einloggen.
Bei 127.0.0.1 geht es aber so wie schon beschrieben

Walter.O.

@Leonie sagte:

hast du die Config geändert und die WebUI neugestartet?

Ja

Walter.O.

Ich habe gerade mal den Rechner komplett neu gestartet, jetzt ist die WebUI OK

Walter.O.

Noch eine Frage zu #156 "das Mapping" Einstellungen Hannah.0 wo finde ich denn das?

Leonie

im ioBroker, bei dem State auf das Zahnrad klicken, da wo du auch History einstellst usw.

manne01

Hallo,

nun will ich mich mal wieder melden und hab vieles aufzuholen:

@manne01 sagte: wäre es nicht auch denkbar, den "Objektbaum" per RAG einem Modell

@Leonie sagte: Hannah ist primär so entwickelt, das die reine Sprachsteuerung kein LLM benötigt. Allerdings gibt es im NLU-Pfad die Möglichkeit das Hannah einen Satz nicht verarbeiten kann, also keine Regel trifft, und das dann zur Klassifizierung ans LLM sendet. Das kann dann wiederum über Tools auf die Gerätedaten zugreifen und genau das durchführen was du gemeint hast. Das ist aber bewusst nur als Fallbackpfad gebaut, weil ich nunmal nicht Amazon bin und einfach mal eben tausende Euro ausgeben kann um leistungsstarke Hardware für latenzarme Modelle zu betreiben.

Nachvollziehbar. Und ich finde auch gut dass Steuerungskommandos lokal und nachvollziehbar durchgeführt werden. Auf jeden Fall interessant, dass was in der Richtung bereits angedacht ist, toll! Die Modelle werden ja glaube ich schon teilweise auch immer leichtgewichtiger und für mittlere/kleinere Hardware zugänglich.

Ich habe auch noch über weitere Integrationen übers angebundene LLM nachgedacht, etwa die Anbindung eines lokalen RAG-Systems, welches zum Beispiel im Internet recherchieren kann oder sagen wir ich will Hannah fragen ob eine neue E-Mail für mich da ist. Da ist aber doch die Authentifizierung das Problem. Wie weit geht da die Stimmenerkennung oder könnte man Sprach-Passworte oder sowas einfordern und vor allem könnte man da irgendwas ans Modell-Provider durchreichen? Hast Du in die Richtung auch Überlegungen?

@Leonie sagte: Auch einen Cloud Service wie claude, GPT, perplexity oder sonstwas, wollte ich grundsätzlich nicht und will ich nach wie vor nicht. Zumal dann mein Haus auch von der Internetleitung abhängig wäre.

Ja, das würde ich auch nicht wollen.

@Leonie sagte: Aktuell hat der LLM-Pfad eine Latenz von ca. 10s bei mir. Das ist für ein wenig Nebenbei"gespräch" oder wenn die NLU einfach nicht den korrekten Pfad getroffen hat, für mich akzeptabel.

Ich finde 10s tatsächlich auch schon für Smalltalk relativ viel, bei mir ist es jetzt mit starker Hardware schneller. Vielleicht kann man es optimieren. Es wäre spannend da mal vergleichende Tests (Textkommando zu Textantwort, Sprachkommando zu Sprachantwort; jeweils Steuerung und LLM Talk; jeweils für ioBroker-Command-Objekt, Satelite und Telegram) zu machen und v.a. dann auch zu schauen wo wieviel Zeit verbraucht wird.

@Leonie sagte: Daher muss ich alle Fälle einzeln hinterlegen. Aber das ist quasi gar nicht so schwierig.

Klasse - es funktioniert ja schon richtig viel! Es ist natürlich umso besser, je natürlicher es wird (auch wenn es dabei relativ überschaubar einfach bleibt - ich hab da natürlich als Nicht-Entwickler gut reden...).

Die neue Nachfrage "Welcher Rolladen, links oder rechts?" ist super und viel besser als bisher, aber wenn ich beim Kommando schon "alle" drin habe fühlt sich diese Nachfrage natürlich komisch an. Sowas wie "alle" oder "beide" könnte doch direkt erkannt werden ODER dann auch als Antwort auf die Frage links/rechts akzeptiert werden? Aktuell muss man sich entscheiden.

So ganz konsistent klappt es auch noch nicht mit dem Nachfragen.
Teilweise ist mir die Erkennung heute glaube ich doch recht oft einfach auf Smalltalk gesprungen (und das LLM hat dann quasi halluziniert "Die Wohnungstüre ist verschlossen."). Ich muss aber nochmal in Ruhe bzw. etwas strukturierter testen.

@manne01 sagte: "Bitte setze die Rolläden im Schlafzimmer auf 50%" --> Thema 2 Rolläden oder alle 5 Geräte

@Leonie sagte: Der Fehler ist hier, das der Resolver korrekt 5 Geräte im Raum Schlafzimmer auflöst, aber die Kategorie "Rollläden" nicht. Und das dürfte aktuell gar nicht eingebaut sein. Das der Executor dann nur 3 Geräte gefunden hat, ist vermutlich auch nur logisch, weil nur drei (Rolläden+Lampe in meinem Beispiel) einen Level haben.

Das Problem scheint mir in der aktuellen Version gelöst, klasse! Trotzdem gab es auch wieder ein paar Unklarheiten.

Zum Teil werden glaube ich bei "alle" noch alle "on" Geräte geschaltet. Z.B. es gibt neben Lights noch ein Gerät namens "Musik". Ich habe es mit Radio versucht und hat geklappt. Aber nicht weil Radio verstanden wurde, sondern weil alles im Wohnzimmer "ausgeschaltet" wurde.

19:49:48 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8753330120 (user=2) — 'Schalte das Radio im RaumX aus'
19:49:48 [INFO] hannah.main: [textcmd] Text: 'Schalte das Radio im RaumX aus' → Intent: TurnOff | Raum: RaumX | Gerät: None | Wert: None | SpeakerUser: 2
19:49:48 [INFO] hannah.iobroker: execute: TurnOff, 4 Gerät(e) gefunden, state='on', value=False

Mir ist aber dann was dazwischengekommen. Ich teste bald nochmal.

Weitere Geräte habe ich aufgenommen mit denen ich nicht weiterkomme:

Ein Fenstersensor wird noch nicht korrekt verarbeitet, vermutlich weil er auch noch "gekippt" kann? Es wird aber auch offen und geschlossen nicht verarbeitet:

in ioBroker:
name: Fenster17.STATE
Role: state
tatsächliche Status: 2 = open; 1 = tilted; 0 = closed

im Hannah Log: Fenster17 -- () [window] — States: STATE

Ich nehme an, weil kein Status da war, war das in einer der letzten core-Versionen die Ursache war für

@manne01 sagte:
Auch noch spannend war heute -> Raum WC wurde erkannt, aber es wurde dann zum Kinderzimmer berichtet
(Verkürzt: 'Wie ist der Status vom Fenster im WC?' --> 'Fenster im Kinderzimmer: offen.'

Das ist relativ witzig, weil nachvollziehen kann ich das nicht.

Inzwischen kommt bei der Frage: "Ich weiß nicht ob Fenster -- im WC an oder aus ist", das ist ja richtig solange die Status nicht richtig zugeordnet sind.

Farbige Lampen

ioBroker states:
Irgendeinlicht.DIMMER (0-100)
Irgendeinlicht.ON (true/false)
Irgendeinlicht.TEMPERATURE (die Farbe, hex string mit farbcode - ginge auch als Irgendeinlicht.HUE mit dem Hue 0-360 Grad Wert)
Irgendeinlicht.SATURATION (0-100) -> für die Farbsättigung

Es wird im core-Log als Light aber nur mit level, on und color erkannt - SATURATION scheint mir nicht vorhanden zu sein und es ist mir noch nicht gelungen aufzunehmen. Ich muss aber zugeben, ich habe immernoch Schwierigkeiten die Zusammenhänge zu verinnerlichen, wie das Mapping der Settings in Hannah UI mit den State-Namen und den Rollen etc. zusammengehen. Es ist dann mehr so ein ausprobieren, als zu wissen, was man tut.

Ich weiß auch noch nicht was mir da helfen würde - vielleicht in der UI bei den Settings oben drüber etwas mehr reinschreiben und auch bei den "Keys" (on, level, ...) in den Settingszeilen evtl. dazuschreiben was dahinter steckt, was die dann "können"? Und was mache ich wenn ich (wegen vielerlei Technologien) mehrere Werte dort mappen müsste? Aber wie gesagt, ich überblicke es noch garnicht richtig.

@manne01 sagte:
17:45:31 [INFO] hannah.iobroker: · Fenster () [window] — States: STATE --> Funktioniert, Hannah weiß ob auf oder zu ist
17:45:31 [INFO] hannah.iobroker: · Tür () [door] — States: STATE --> "Das kann ich leider nicht beantworten".

@Leonie sagte: Kannst du mir bitte Details dazu geben?

Ich konnte es so leider nicht mehr nachvollziehen. Ich behalte das im Auge.

@Leonie sagte: Eigentlich ignoriert Hannah bewusst keine Zeichen, außer Satzzeichen und Groß und Kleinschreibung. Also Zahlen müssten durchgehen.

Wunderbar - ich habe jetzt meine Thermostate etc. die seitens Homematic "Thermostat 1" genannt werden einfach mit Bindestrichen unterschieden. Die braucht es fürs Matching zum Kommando nicht und so kann ich den Unterschied durch den Raum machen und brauche an der Stelle mir die Mühe mit Überschreibungen nicht zu machen.
Dabei hab ich nun aber festgestellt, dass ja die Zeichen nicht gefiltert, also noch noch da sind dann in der Ausgabe, aber es wird nicht ausgesprochen, das passt so.

@Leonie sagte: Tatsächlich haben meine Geräte aber auch keine Zahlen, dafür die merkwürdigsten Namen. Da heißt ein Fenster bspw. "Seite Straße" oder eine Lampe "Decke Garten".

Ja, da ist es auf jeden Fall gut wenn die Geräte auch bei vertauschten Namensteilen erkannt werden.

@Leonie sagte: Quasi nebenbei habe ich auch den VoiceID Rollout fertig gebaut. Der kann über die WebUI gestartet werden, benötigt aber mindestens einen verbunden Satelliten und bringt ohne sowieso nichts.

Sehr schön, Danke! Dann wird das ganze ja immer runder und zugänglicher.

@manne01 sagte: könnte man die Version der Komponenten beim Start ins Log schreiben

@Leonie sagte: Das ist eher nicht geplant. Da du Docker nutzt, kannst du ja die Versionen aus den Tags ablesen. Aktuell plane ich aber noch einen Health-Endpoint über den man bspw. Metriken für Grafana abholen kann. Ich könnte mir vorstellen das Versionsreporting an der Stelle zu tun.

Health Endpoint klingt sehr gut. Offen gesagt in Docker - hmm, so richtig sehe ich da keine Versionen, aber das kann wieder an Synology liegen...

@Leonie sagte: Kurzes Update zur Telegram-Verknüpfung
Für alle, die auch mit DynDNS partout keine Domain am Bot hängen haben wollen, überlege ich zusätzlich eine zweite Variante: ein Admin (Trust-Level 10) verknüpft den Telegram-Account eines Users manuell
Keine echte Verifikation durch Telegram mehr, reine Vertrauenssache zwischen Admin und User.
Wäre das für euch ein akzeptabler Trade-off, oder ist euch die fehlende Selbstbestätigung zu heikel?

Für mich klingt das gut, weil der Admin das sicher häufig z.B. für Mitbewohner/Kollegen einrichtet und verantwortet und die Kanäle dorthin ja recht klar sein sollten.

Trotzdem fände ich Alternativ zu Telegram für einfachere Setups und im lokalen Netz einen browserbasierten Web-Sprachchat ohne Login im Hannah-UI spannend (der dann auch mobil funktoniert). Den könnte man in Wandtablets einbinden oder auf dem Handy niedrigschwellig und unauthentifiziert nutzen. So wie den Schalter an der Wand. Ich sage das ohne zu wissen ob das technisch sauber machbar ist.

Zu den Satelliten: Welche "Reichweite" hat denn so ein Satellit (hörend und antwortend) - wenn man unterstellt dass man normal hört und keine Nebengeräusche hat? Es braucht schon einen pro Raum oder? Wie groß darf so ein Raum sein bzw. wie ist es bei "verbundenen Räumen, also mit offener Tür oder nur halbe Wand?

Noch eine Beobachtung: Wenn ich Hannah einfach per iobroker-Command-Object frage "Hallo Test 123" kommt dazu im Core Log kein Eintrag, kann das sein? Bei Telegram Sprache und Text klappt das. Die Antwort aufs ioBroker-Command kommt im Log
21:03:16 [INFO] hannah.main: [iobroker] Antwort (Smalltalk): 'Hallo Test 123'

Wie behandelst Du eigentlich raumübergreifende Gruppen? Also sowas wie "Alle Rolläden im Erdgeschoss"? "Alle Lichter im Garten"? Wie würde man solche Gruppen anlegen und steuern? Als eigener Raum?

Ist es richtig, dass die Wörter im Kommando dedupliziert werden wenn es um Steuerung/Matching geht? Also für die Zuordnung genügt "Schalte im Wohnzimmer den Rolladen Seite ein" wenn der Raum "Wohnzimmer" heisst, die Funktion "Rolladen" und das Gerät "Seite" ? Ich hatte die Funktion aus den Gerätenamen rausgenommen aber beim Bestätigen klingt das dann doof, z.B. "Seite wurde geschlossen". Gibt es da Best practise?

Könnte man beim Überschreiben oder irgendwo inline in den Gerätenamen auch Aliase definieren? Eine Funktion Musik könnte so auch als Radio gestartet werden. Oder Rolladen/Jalousie etc.

Tut mir leid, ist etwas viel geworden. Bis hoffentlich bald wieder!

Leonie

@manne01 ziemlich viel. Auf das meiste werde ich jetzt nicht eingehen.

Aber zu dem WebChat: Ich hatte die verrückte Idee Hannah einen IRC-Bot zu bauen. Also ja: Grundsätzlich kommuniziert bei Hannah alles über ein Protokoll das sich gRPC nennt. Das ist quasi ein Kommunikationsvertrag. Einfach gesagt, gibt es dort eine Nachricht, die nennt sich "SubmitText" und erwartet eine Antwort.
Wenn sich nun jemand findet, der Lust hat, einen WebChat zu programmieren, gebe ich das gerne ab. Dem Chat sollte es egal sein ob er nun seine Antworten per socket broadcastet oder per gRPC verschickt.
Das notwendige Proto-Paket, liegt für go, python und node bereits komplett fertig vor. Die Implementierungen kann man sich bei mir anschauen, das node-Paket wird bspw. im ioBroker-Adapter verwendet.

Walter.O.

Hallo Leonie
ich habe da mal (wieder) eine Frage, diesmal zu Telegram und die Einbindung einer Domain . Ich habe eine eigene .de Domain die aber auf keine webseite verweist. wie muss ich das machen das ich sie bei Telegram einbinde. gibt es da eine Deutsche Anleitung? Ich habe es schon versucht aber wenn ich in der webui auf verbinden gehe kommt immer (deprecated) Veraltet. Ich bekomme es einfach nicht hin.

Leonie

@manne01 danke, wie immer richtig viel Substanz dabei. Ich geh der Reihe nach durch, fasse aber ein paar Punkte zusammen, wo's passt.

RAG/Internet- & E-Mail-Integration + Auth:

@manne01 sagte:

Ich habe auch noch über weitere Integrationen übers angebundene LLM nachgedacht, etwa die Anbindung eines lokalen RAG-Systems

Aktuell nicht geplant, aber ich seh da einen Weg über das Skill-System, das ich sowieso vorhabe (gRPC-Skill-Server, Alexa-artiges Invocation-Routing): Wenn irgendwer Lust hat, einen Skill für z.B. Google Mail zu bauen — spricht von meiner Seite nichts dagegen. So ein Skill bräuchte dann wahrscheinlich seine eigene Userbase, die man über linkedAccount entweder mit dem Hannah-User oder direkt mit dem jeweiligen Account (Google o.ä.) verknüpft. Ist aber bisher nur ein Gedankenexperiment, nichts Konkretes.

Das LLM bekommt grundsätzlich schon mitgeteilt, mit welchem User es gerade spricht — insofern wäre eine Rechtebasis dafür schon da. Ob man dem LLM generell einen Internetzugriff geben will (technisch sicher machbar als Core-seitiges Tool) ist für mich aber nochmal eine andere, offene Frage — nicht ob's geht, sondern ob ich das will.

Latenz-Vergleichstests:

@manne01 sagte:

Es wäre spannend da mal vergleichende Tests

Guter Punkt, notiere ich mir — passt eigentlich ganz gut zu einem Health/Metrics-Vorhaben, das ich sowieso schon länger vor mir herschiebe. Konkrete Zahlen kann ich dir noch nicht liefern.

"Alle" schaltet zu viel ab (dein Radio/Musik-Beispiel):

@manne01 sagte:

19:49:48 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8753330120 (user=2) — 'Schalte das Radio im RaumX aus'

19:49:48 [INFO] hannah.main: [textcmd] Text: 'Schalte das Radio im RaumX aus' → Intent: TurnOff | Raum: RaumX | Gerät: None | Wert: None | SpeakerUser: 2

19:49:48 [INFO] hannah.iobroker: execute: TurnOff, 4 Gerät(e) gefunden, state='on', value=Falses ist tatsächlich ein Bug, danke für den Log — hab ich aufgenommen. Kurz zur Klarstellung: dass "Radio" nicht erkannt wurde, ist erwartbar, dein Gerät heißt ja "Musik". Der eigentliche Fehler ist, dass Hannah bei einem Nichttreffer trotzdem alles im Raum ausschaltet, statt "kenne ich nicht" zu sagen. Ist gemeldet und wird gefixt.

Fensterkontakt mit gekippt/offen/zu:

@manne01 sagte:

Ein Fenstersensor wird noch nicht korrekt verarbeitet, vermutlich weil er auch noch "gekippt" kann?

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. Das war für dich nur nicht auffindbar, deshalb bessere ich an der Stelle die Doku in der Settings-UI nach.

Und zu "gekippt" grundsätzlich: Das will ich Hannah bewusst nicht extra beibringen. Sicherheitsrelevant ist für mich nur offen-vs-zu, und ein gekipptes Fenster ist in der Hinsicht einfach offen. Sobald der Override sauber steht, meldet Hannah dir "offen" auch bei gekippt — technisch sogar ohne dass ich dafür Code ändern muss.

Farblampen / Saturation:

@manne01 sagte:

SATURATION scheint mir nicht vorhanden

Hab ich aufgenommen, aber noch offen ob ich's umsetze — ich nutze Saturation/Hue an meinen eigenen Lampen selbst nicht, rechne stattdessen direkt in Hex um. Falls es kommt, dann rein zusätzlich, ohne dass sich für bestehende Lampen was ändert.

Settings-UI/canonicalKey-Verständnis:

Nehme ich mir vor — Erklärtext zu den Keys und wann/wie der Override greift, mit deinem Fensterkontakt als Beispiel.

Zahlen/Sonderzeichen in Gerätenamen:

Freut mich, dass der Bindestrich-Trick bei dir funktioniert wie gedacht.

VoiceID-Rollout:

Danke fürs Feedback!

Telegram-manuelle-Verknüpfung:

Ok, mal schauen ob/wie ich das umsetze. Ist jedenfalls bei mir im Plan aufgenommen.

Satelliten-Reichweite:

@manne01 sagte:

Zu den Satelliten: Welche "Reichweite" hat denn so ein Satellit

Bei mir sind die Räume so 20–40m² groß, jeweils ein Satellit pro Raum, Akustik ist gut. Liege ich oben im Bett in der Südost-Ecke, hört mich der Satellit im Erdgeschoss in der Nordwest-Ecke — mit einem Treppenhaus dazwischen. Stehe ich im Wohnzimmer, kann ich mit dem Satelliten in der Küche reden. Beides so 20–50m Distanz. Die Antwort vom Satelliten hängt natürlich von den verbauten Lautsprechern ab. Ich habe welche im "fliegenden" Aufbau, mit billigen Lautsprechern, die sind relativ leise, ich habe aber auch welche mit dem finalen Design (Dayton Audio RS75-4), da ist die Akustik um vieles besser.

Cross-Room-Gruppen ("alle Rollläden im EG") + "alle"/"beide" bei Rückfragen:

@manne01 sagte:

Alle Rolläden im Erdgeschoss"?

@manne01 sagte:

ber wenn ich beim Kommando schon "alle" drin habe fühlt sich diese Nachfrage natürlich komisch an

Beides hängt für mich zusammen — ich hab eine Idee für automatische virtuelle Gruppen-Geräte pro Raum/Kategorie in der Pipeline, die genau das lösen würde: "alle Rollläden" würde dann auf ein echtes Gerät matchen, und die Links/Rechts-Rückfrage bräuchte den Sonderfall gar nicht mehr. Noch nicht umgesetzt, aber eingeplant. Etagen zu "bauen", steht auch auf meinem Plan, aber noch nicht schriftlich. Ein passendes Design habe ich auch noch nicht im Kopf.

Wort-Dedup / Funktion im Gerätenamen:

@manne01 sagte:

Ist es richtig, dass die Wörter im Kommando dedupliziert werden wenn es um Steuerung/Matching geht?

Kein echtes "Dedup" — Raum, Funktion/Kategorie und Gerät werden komplett unabhängig voneinander gegen denselben Satz gematcht, jeder sucht sein eigenes Vokabular, ohne dass die anderen Treffer "verbraucht" werden. Dein Setup mit "Rolladen"-freien Gerätenamen funktioniert deshalb.

Zur Ansage ("Seite wurde geschlossen" klingt komisch): Hannah sagt immer den rohen Gerätenamen an, nicht Funktion+Gerät. Willst du "Rolladen Seite" in den Ansagen hören, müsste das Gerät in ioBroker tatsächlich so heißen — das macht das Matching dann aber strenger: es braucht "Rolladen Seite" als zusammenhängende Wortfolge im Kommando, während ein reiner "Seite"-Name flexibler matcht (Reihenfolge/Position im Satz egal). Echter Trade-off, keine Bug-Frage.

Aliase (Musik↔Radio, Rolladen↔Jalousie):

@manne01 sagte:

Gerät namens "Musik"

Da bin ich zurückhaltend — eine offene Synonymliste will ich Hannah nicht beibringen, das wird schnell unwartbar. Ein Teil davon dürfte sich aber sowieso über die Gruppen-Geräte von oben erledigen. Bei dir wurde vermutlich der ganze Raum geschaltet, weil Hannah kein Gerät gefunden. Das müsste ein gelöster Bug sein, so das Hannah lieber nachfragt mit "Tut mir leid, das Gerät habe ich nicht gefunden, welches meinst du?", ich kann das aber gerne nochmal prüfen und ich weiß natürlich nicht welche Version du hast.

iobroker-Command-Object-Logging:

@manne01 sagte:

Noch eine Beobachtung: Wenn ich Hannah einfach per iobroker-Command-Object frage

Auch ein Bug, danke — eingehende Anfragen sollen da genauso geloggt werden wie bei Telegram/Satellit. Gemeldet.

Versions-Logging:

@manne01 sagte:

Offen gesagt in Docker

Das kommt nun darauf an wie du dein Compose-file geschrieben hast. Pinst du auf fixe Versionen? dann ist es einfach. Ansonsten müsste man das über die image digest nachschauen. Ich kann das gerne für dich übernehmen, aber du musst mir dafür deine verwendeten Digests geben.

@manne01 sagte:

Tut mir leid, ist etwas viel geworden. Bis hoffentlich bald wieder!

Ach, muss dir überhaupt nicht leid tun! Ehrlich gesagt sind mir solche gesammelten Rundumschläge deutlich lieber als wenn dasselbe Thema in zehn Salami-Beiträgen häppchenweise reintropft - so hab ich alles auf einmal im Kopf und kann in Ruhe durchgehen. Also: gerne öfter so ausführlich!
Bis demnächst!

@Walter.O. sagte:

ich habe da mal (wieder) eine Frage, diesmal zu Telegram

Hallo Walter, kein Problem, frag ruhig — dafür ist das Forum ja da!

Bei "(deprecated) Veraltet" muss ich leider erstmal passen, ohne mehr zu wissen. Könntest du mir zwei Dinge schicken, damit ich dir gezielt helfen kann?

Einen Screenshot von der Stelle in der WebUI, wo diese Meldung auftaucht (am besten mit der ganzen Seite drumrum) — dann seh ich genau, worauf sich "veraltet" bezieht.
Ein paar Infos zu deiner Domain: bei wem hast du sie registriert, und zeigt sie aktuell überhaupt schon irgendwohin (auf eine IP-Adresse, einen DynDNS-Dienst, o.ä.)?

Mit den beiden Sachen kann ich dir dann eine Anleitung schreiben, die auch wirklich zu deiner Situation passt — sonst rate ich womöglich am eigentlichen Problem vorbei.

Liebe Grüße

OliverIO

@Walter.O. sagte:

Hallo Leonie
ich habe da mal (wieder) eine Frage, diesmal zu Telegram und die Einbindung einer Domain . Ich habe eine eigene .de Domain die aber auf keine webseite verweist. wie muss ich das machen das ich sie bei Telegram einbinde. gibt es da eine Deutsche Anleitung? Ich habe es schon versucht aber wenn ich in der webui auf verbinden gehe kommt immer (deprecated) Veraltet. Ich bekomme es einfach nicht hin.

Das geht mit deiner Webseite nicht.
Dein telegram webhook, in einem deiner Container) muss über eine https Adresse erreichbar sein. Also ein offener Port in deinem Router, der dann an den entsprechenden Container weitergeleitet wird

Du benötigst

einen https DNS Domäne, deren ip Adresse mit deiner ip Adresse dynamisch aktualisiert wird (dyndns). Ggfs bietet dir dein routerhersteller da was kostenloses an. Ansonsten gibt es kostenlose Dienste die dir sowas machen.
dann noch ein https Zertifikat für diese domaine (bspw mit let's encrypt) die,laufen allerdings nach einiger Zeit ab und müssen erneuert werden. Das kann man sich aber automatisieren.

So bekommst du Anfragen zumindest mal an deinen Router.
3) Aus Sicherheitsgründen (wie weiter oben erwähnt) benötigst du dann noch einen reverseproxy

Und als weitere Sicherheitsmaßnahme empfehle ich noch fail2ban, so das spielkinder/scriptkiddies und auch professionelle Angreifer nicht zu viele Chancen haben den offenen Port auszutesten. Das macht allerdings notwendig die Zugriffe über die log files ein paar Tage zu beobachten und ggfs. weitere Filter Regeln hinzuzufügen.

Der offene Port leitet an den reverseproxy um.
Der Container der dann den telegram webhook enthält muss über zusätzliche env variablen dem reverseproxy bekanntgemacht werden. Das funktioniert mit dem Proxy Manager sehr gut. Der Proxy leitet dann die Anfrage an deinen webhook Container weiter.

Die Maßnahmen gewährleisten, das die angriffsfläche die dein offener Port bietet, so klein wie möglich gehalten wird und fehlerhafte Anfragen (die nicht durch telegram erfolgen, zeitnah abgeblockt werden)

Ich nutze

Habe mir die Container allerdings selber gebaut und nicht direkt von dockerhub gezogen. Das mache ich nur mit zertifizierten Container von dockerhub.

Für bessere fail2ban Überwachung
https://hub.docker.com/r/oweitman/fail2bancontrol
(Ist von mir)

Wenn du mehr Infos brauchst kann ich dir bei der Konfiguration helfen.
Habe hier mehrere Dienste mit offenen Ports laufen: n8n (und darin dann ein telegram trigger), immich, Nextcloud,etc.

Leonie

Nochmal: Man braucht keine Portforwardings dafür. Meine WebUI, die ich hoste, ist nicht übers Internet erreichbar, ich habe gar kein Portforwarding dafür.

Was ich allerdings habe, ist mein eigener DNS Server inhouse. Split DNS ist hier das Thema, das geht im Zweifel auch über die lokale Hosts-Datei.
Das Zertfikat kann auch selbst signiert sein, das ist vollkommen ausreichend. Dein PC muss dem Zertifkat vertrauen, Telegram wird die Seite niemals aufrufen. Im Prinzip muss der PC auch gar nicht dem Zertifikat vertrauen, es ist vollkommen ausreichend das die Webseite über https erreichbar ist, ob du dabei eine Zertfikatswarnung bestätigen musst, ist vollkommen egal.

Um aber @walter.o. zielgerichtet helfen zu können, brauche ich mehr Details über sein Setup.

OliverIO

@Leonie sagte:

Nochmal, Man braucht keine Portforwardings dafür

hatte mich auch gewundert. Weiß aber nicht was sich bei dir mittlerweile alles verändert hat.

Walter.O.

Hallo Leonie
Um aber @walter.o. zielgerichtet helfen zu können, brauche ich mehr Details über sein Setup.

Ich habe eine normale ubuntu 26..er mit Iobroker Installation, soweit mir bewusst ist habe ich kein Docker installiert. Ich habe mal Experimente damit gemacht aber das ist nicht meins.
Eine Duck DNS habe ich.

Was würdest du denn für weitere Infos brauchen?

Ich habe die Sache mit Telegram mal überdacht und bin zu dem Schluss gekommen, das es mit meinem Wissensstand ein zu hoher Aufwand für mich ist.
Es würden dann auch viele nachfragen kommen die dich von deiner Entwicklung abhalten können.
Ein Nutzen von Telegram aus der Ferner würde ich auch wohl kaum Nutzen wollen. Ich wüsste nicht was ich da mit hannah quatschen sollte.
Nur zum Testen ohne Sattelit ist wie gesagt der Aufwand über Telegram zu groß.

Sollte ich mich da irren bitte gerne bescheid geben.

Die Lösung mit einer Harware ESP32-S3-PCB und entsprechendes Zubehör entspräche eher meinen vorstellungen.

Ich würde aber ebenfalls mitbestellten bei Way, aber nur 1 Stück wenn schon Bestückt.
Wie viele haben wir da jetzt schon zusammen und wo lägen die Kosten dann?
Gibt es für das Gehäuse einen 3D Druckplan?

Leonie

Hii,

@Walter.O. sagte:

Was würdest du denn für weitere Infos brauchen?

bspw. einen Screenshot von der WebUI, mit Adresszeile, bzw. von der Seite wo die den Fehler mit "Deprecated" siehst.

Zum Thema, was man mit Telegram machen kann: Ich nutze es fast täglich. Sei es weil ich bspw. auf der Arbeit bin und wissen will ob noch irgendwelche Lampen an sind.
Was auch geht: Der Hannah-Adapter registriert sich im ioBroker als Notification-Empfänger. Wenn nun irgendwas, ein Script, ein Adapter, oder ioBroker selbst, eine Notification bspw. über den Notification Adapter erstellt, spielt Hannah den auf den Satelliten ab, aber kann auch die Textnachricht an Telegram senden. So bekomme ich bspw. Fehler oder Warnungen vom Haus auch wenn ich unterwegs bin.

Für mich ist Telegram und WebUI auch so ein wenig die Hannah-App für arme. Aktuell kann ich keine App programmieren und selbst wenn, dann wüsste ich aktuell nicht wie ich die App überhaupt mit Hannah verbunden bekomme, dann bräuchte ich wieder irgendein Portforwarding, was ich bekanntermaßen ablehne.
Irgendwann wird es aber eine App geben, die dann große Teile der WebUI und Telegram ersetzt. Ich habe bereits einen Plan dafür im Kopf, das ist aber noch sehr ferne Zukunft.

Zu dem Gehäuse:
Ich glaube ich habe das noch nirgends hier großartig gesagt, aber meine Gehäusedaten liegen im Repository: https://github.com/NurPech/Hannah/tree/master/hardware/Enclosure
Da liegen drei 3D-Modelle, benötigt werden dafür noch 4 Einschmelzmuttern M3 und 4 Einschmelzmuttern M2. Dazu noch passende Schrauben.

Und für alle die es nicht mitbekommen haben, mittlerweile habe ich auch den Schaltplan meiner Satelliten veröffentlicht: https://github.com/NurPech/Hannah/blob/master/hardware/Phase2/Hannah_Satellite_Rev5_Schematic.pdf

Und quasi nebenbei habe ich eine neue Dokumentation angefangen, die diesmal auch wirklich größer werden soll:
https://hannah-docs.leonie.network

Zu dem Bestellen:
Ich habe keinen Überblick. Ich habe vor einiger Zeit mal eine Art "Shared Order Organizer" gebaut, bzw. angefangen:

Die Idee ist, man kann sich mit seinem Google Account anmelden, jeder kann eine Sammelbestellung anlegen, jede Bestellung hat einen Titel, eine Beschreibung, Mindestmenge, Maximalmenge und eine Deadline.
Jeder kann sich an einer Sammelbestellung beteiligen. Man klickt einfach auf "teilnehmen", gibt an wie viele Produkte man haben möchte, gibt seine Adresse ein und wenn man möchte noch irgendeine Notiz.
Jede Bestellung hat einen Fortschritt und erst wenn die Bestellung vom Ersteller auf den Status "erhalten" gewechselt ist, werden die Adressen der Teilnehmer für ihn sichtbar.
Solange die Bestellung noch offen ist, kann man seine Teilnahme auch wieder zurückziehen, sobald die Bestellung auf "bestellt" gewechselt ist, geht das nicht mehr.

Ich würde mich ausdrücklich nicht am Handel, an der Bestellung oder dem Geldfluss beteiligen, auch könnte meine Plattform gar nicht am Geldfluss teilnehmen, aber ich könnten den Orgnaizer eben zur Verfügung stellen.

Da könnte dann jeder der Lust hat sich PCBs zu bestellen, offen sehen wie der Status ist.

Die Frage ist nur, wollt ihr sowas überhaupt haben, oder soll ich das einfach sein lassen?

manne01

Hallo,

hier von mir wieder eine Rückmeldung nach etwas Testen heute:

RAG/Internet- & E-Mail-Integration + Auth:
@Leonie sagte:
Aktuell nicht geplant, aber ich seh da einen Weg über das Skill-System,
Wenn irgendwer Lust hat, einen Skill für >z.B. Google Mail zu bauen
Das LLM bekommt grundsätzlich schon mitgeteilt, mit welchem User es gerade spricht — insofern wäre eine Rechtebasis dafür schon da. Ob man dem LLM generell einen Internetzugriff geben will >(technisch sicher machbar als Core-seitiges Tool) ist für mich aber nochmal eine andere, offene Frage — nicht ob's geht, sondern ob ich das will.

Das klingt doch alles schonmal gut. Ich würde vermutlich eher alle "Zusatzfunktionen" von dem einen LLM das an Hannah angebunden ist erwarten bzw. dort drin einbauen, oder? Also die Mails vom KI-Server "live" aus dem Mailserver ziehen lassen, Hannah hat diesen LLM hinterlegt und kann meine Sprachkommandos an das LLM senden, welches mit den Mails und meinen Dokumenten etc. angereichert ist. Die Core bräuchte dafür dann keinen Internetzugriff und auch keinen Skill - wenn ich das richtig überblicke. Aber das LLM-Backend müsste halt ganz grundsätzlich unterscheiden können wer gerade fragt und seine Rückmeldung bzw. seine Funktionen und Zugriffe da dran orientieren.

Dann ein paar Kleinigkeiten:

Kann ich diese minütlichen Meldungen im Core-Log loswerden:
11:43:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen

Ich glaube dann wird es übersichtlicher wenn man viel mit Kommando-> Antwort testet.

08:23:06 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'ACTUAL_TEMPERATURE' (state_id=hm-rpc.0.OEQ0299132.2.ACTUAL_TEMPERATURE) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (Wert friert auf dem letzten Snapshot ein).

Ich denke die logmeldung muss korrigiert werden -> ist jetzt im WebUI

Diese Fehlermeldung kommt, obwohl ich den State-Namen in ioBroker für Hannah überschrieben habe - ich denke das könnte entfallen?

11:33:03 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'Device-control' (state_id=dies.das.Device-control) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (Wert friert auf dem letzten Snapshot ein).

@Leonie sagte:
Settings-UI/canonicalKey-Verständnis:

Nehme ich mir vor — Erklärtext zu den Keys und wann/wie der Override greift, mit deinem Fensterkontakt als Beispiel.

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.
Ich nenne die mal Hannah-State-Base-Types. Die können in bestimmten Formaten lesen und schreiben.
Das Format das sie lesen und schreiben können sollte beschrieben werden, also welcher Hannah-State-Base-Types kann was. Illuminance -> was steckt dahinter? Wer list/schreibt einen String? Was ist der Werte Bereich, was ist das Zahlenformat (hex, 1-100, 0-1) , wo ist eine Aus/Eingabe dann zusätzlich mit "auf oder zu" verknüpft.
Weiterhin verstehe ich es so, dass Hannah versucht anhand der Objektdaten aus IoBroker den richtigen Hannah-State-Base-Types zuzuordnen. Und dies kann aber in iObroker am jeweiligen Objekt-State nach Gusto überschrieben werden.
Da sich in ioBroker über die Adapter eine Vielzahl verschiedener State-Abbildungen versammeln hängt der per Hannah steuerbare Funktionsumfang den Hannah zum lesen und steuern bietet also an der Vielzahl der Hannah-State-Base-Types, richtig?

Wenn ich es richtig verstehe, kann ich in der Hannah Web UI globale States Suffixe anders festlegen als Hannah es im Standard versteht in dem ich sie auf der rechten Seite ändere. Für alles weitere muss ich an den Objekten überschreiben.

Ich vermute und verstehe grundsätzlich, dass in Hannah nicht die ganze Welt als dann nötige Hannah-State-Base-Types-Implementierungen abgebildet werden soll.

Aber wäre es nicht schonmal eine Vereinfachung in WebUI-Settings mehrere STATE-names mappen angeben? (die UI erlaubt das nicht)
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 müssten die Hannah-State-Base-Types nicht eher "Zahl beliebig", "Dimmer 1-100", "Rolladen 0 zu bis 100% offen", "Schalter An/Aus", "Zustand offen/zu", "Lichtfarbe Hex" etc ... heissen?

Auch noch im Log:
LOG 08:24:09 [INFO] hannah.grpc_server: [grpc] ControlDevice: device='matter.0.controller.11922669628889360814.ExtendedColorLight-1' state='color' value='#00FF00'

Es wäre hilfreich, wenn Hannah hier im Log angibt, was sie wirklich schaltet - wäre das möglich also etwa so:
08:24:09 [INFO] hannah.grpc_server: [grpc] ControlDevice: device='matter.0.controller.11922669628889360814.ExtendedColorLight-1' state='color' value='#00FF00'
mappedStates = 'TEMPERATURE' (ggfs. alle gemappten falls das mit dem mehrfachen eine Idee ist)

@manne01 sagte:
SATURATION scheint mir nicht vorhanden

Hab ich aufgenommen, aber noch offen ob ich's umsetze — ich nutze Saturation/Hue an meinen eigenen Lampen selbst nicht, rechne stattdessen direkt in Hex um. Falls es kommt, dann rein zusätzlich, ohne dass sich für bestehende Lampen was ändert.

Die HUE-Lampen müssen rein :-) Ich dachte zunächst ich könnte die Farbe auch mit Hannahs Hex-Eingaben auf TEMPERATURE steuern, aber das klappt nicht.
Ich habe mir jetzt einen extra Datenpunkt erstellt den Hannah als Lampe sieht und mit Hex beschreibt und dann hört ein JavaScript mit und schreibt den HUE-wert, setzt die SATURATION etc.
Das klappt (und bringt meinen Kindern viel Spaß), aber m.E. sollte Hannah auch einen Hannah-State-Base-Type für Hex-Lampen haben.

Ansonsten müssten wir dann doch über eine feste Voraussetzung für Hannah in Form eines Device Scripts /Alias-Adapters etc. sprechen.

Und apropos Kinder: wäre über die Sprecher-Erkennung auch eine "Kindersicherung" denkbar. Also dass bestimmte Funktionen nur von bestimmten Sprechern ausgelöst werden dürfen?

Und wie ist das wenn ich ein "Gerät" habe, welches verschiedene States hat die ich aktivieren kann. Ich würde das Gerät gerne Medien nennen und dann zw. Musik, Fernsehen, DVD, Aus ... wählen können. Gestartet wird jeweils mit einem eigenen State den man auf true setzt. Das ist für mich etwas seltsam, aber im Adapter halt nunmal so abgebildet.
Also schalte im Wohnzimmer Medien auf Fernsehen oder schalte "Medien aus"
Die muss ich aktuell als mehrere Funktionen (inklusive "Aus") in ioBroker anlegen, dann im Hannah-Adapter aktivieren, dadurch an Hannah übergeben und dort als getrennte Geräte ansprechen. Funktioniert soweit, eine gestartete Aktivität schalte ihre Nachbarn automatisch aus) - aber ist das der richtige Weg? Oder sollte man das halt scripten oder den Adapter-Entwickler fragen?

@Leonie sagte: Zur Ansage ("Seite wurde geschlossen" klingt komisch): Hannah sagt immer den rohen Gerätenamen an, nicht Funktion+Gerät. Willst du "Rolladen Seite" in den Ansagen hören, müsste das Gerät in ioBroker tatsächlich so heißen — das macht das Matching dann aber strenger: es braucht "Rolladen Seite" als zusammenhängende Wortfolge im Kommando, während ein reiner "Seite"-Name flexibler matcht (Reihenfolge/Position im Satz egal). Echter Trade-off, keine Bug-Frage.

Das bringt mich zurück zu dem Thema, dass ich glaube dass es für menschliche Spracheingaben echt besser wäre, wenn die Wort-Reihenfolge beim Gerätenamen ignoriert werden könnte. Sonst muss man einfach zuviel vorher nachdenken und es wird "unnatürlich".

@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. Das war für dich nur nicht auffindbar, deshalb bessere ich an der Stelle die Doku in der Settings-UI nach.

Mit Webui v2.7.1 digest sha256:9dc646342fdc2db861b2dba0a6f5bc39b0543aef7e23302c7998c0c91fcd314e finde ich nun die ganze "states"-Liste in den Settings grade leider garnicht mehr :)
Ich hab dort nur noch "Automations", LLM, NLU, PRESENCE, Voice Enrollment.
Hoffentlich ist da nichts bei mir kaputt gegangen - ich hatte gestern nur Core aktualisiert, die WebUi erst heute.

Es gelingt mir leider aktuell noch nicht ein "konsistentes" Erlebnis zu erhalten:

Vorab - ich versuche immer ziemlich auf der neuesten Version zu sein, da laufend neue Releases kommen, klappt das nicht immer :)
Aktuell core digest sha256:2faf766deb92004be3ebee9250fa0f2e01ab2ec11e0a77956f375624a0c260a8 -> ich glaube das ist die von gestern 0.83.1 (2026-09-18)
Und frage immer per Texteingabe über Telegram. Dabei nutze ich aber meist die Spracheingabe meiner Handy-Tastatur, d.h. es kann - (wie wahrscheinlich auch beim Hannah STT) zu Erkennungsfehlern kommen (Rolläden -> rollläden)

Meine Testfälle:
Wie ist der Status von rolladen links im Keller --> PASST
Schliesse den Rolladen links im Keller -> das klappt

Welche Fenster sind im Wohnzimmer geöffnet? -> hier gibt es keine, nur eine Tür
11:06:44 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche Fenster gibt es im Wohnzimmer'
11:06:44 [INFO] hannah.main: [textcmd] Text: 'Welche Fenster gibt es im Wohnzimmer' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
11:06:44 [INFO] hannah.main: [2] Antwort (Query): 'Terrassentür im Wohnzimmer: geschlossen.'
Fallback zur Tür? Ist das gewünscht? Oder wieder weil Typ "open" für Türen und Fenster passt?

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

Hat Hannah noch das Wohnzimmer im Kontext? Dort gibt es kein Fenster -> warum dann ausgerechnet das Kinderzimmer - es gibt viele weitere Zimmer mit Fenstern? Da sind wir wieder beim Thema, die sind benannt mit "Fenster -" oder "Fenster --" -> alle von der Funktion her [window]

(Dasselbe passiert mit Frage nach geschlossen)

Welche rollläden [sic!] sind im Wohnzimmer geöffnet?
11:11:08 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche rollläden sind im Wohnzimmer geöffnet?'
11:11:08 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind im Wohnzimmer geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
11:11:08 [INFO] hannah.main: [2] Antwort (Query): 'Tür im Wohnzimmer: geschlossen.'

(Gerät/Funktion nicht erkannt wegen Mehrzahl oder Scheibweise von Rolläden?)

Späterer Versuch über Hannah-STT:
14:51:17 [INFO] hannah.main: [textcmd] Text: 'Welche Rollheiten sind im Wohnzimmer geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
14:51:17 [INFO] hannah.main: [2] Antwort (Query): 'Tür im Wohnzimmer: geschlossen.'
Selbes Ergebnis.

Wie ist der Status vom Rolladen im Wohnzimmer?
11:33:59 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Wie ist der Status vom Rolladen im Wohnzimmer?'
11:33:59 [INFO] hannah.main: [textcmd] Text: 'Wie ist der Status vom Rolladen im Wohnzimmer?' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
11:33:59 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Terrasse: 0 %.'
PASST!

Welcher Rolladen im Wohnzimmer ist geöffnet?
Selbe antwort. Passt auch!

Welche Rolläden sind im Wohnzimmer geöffnet? -> also nochmal die Frage von oben:
11:36:47 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche Rolläden sind im Wohnzimmer geöffnet?'
11:36:47 [INFO] hannah.main: [textcmd] Text: 'Welche Rolläden sind im Wohnzimmer geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
11:36:47 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Terrasse: 0 %.'
KLAPPT JETZT - aber warum??

Welche Rolläden sind geöffnet?
11:12:40 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche rollläden sind geöffnet?'
11:12:40 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet?' → Intent: Smalltalk | Raum: Wohnzimmer | Gerät: Fenster | Wert: None | SpeakerUser: 2
LLM war grade nicht verfügbar -> 11:12:40 [INFO] hannah.main: [2] Antwort (Smalltalk): 'Das kann ich leider nicht beantworten.'
(Gerät/Funktion nicht erkannt wegen Mehrzahl?)

Welcher Rolladen ist gerade geöffnet? -> jetzt mit Einzahl
11:13:51 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welcher Rolladen ist gerade geöffnet?'
hier kam im Log dann keine Meldung mehr a la → Intent: | Raum:| Gerät: | Wert: None | SpeakerUser
sofort übergabe an LLM, LLM war grade nicht verfügbar -> 11:12:40 [INFO] hannah.main: [2] Antwort (Smalltalk): 'Das kann ich leider nicht beantworten.'

Nun hat Hannah sich irgendwie auf smalltalk eingeschossen:
danach:
11:15:35 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welches Fenster ist geöffnet?'
dann
11:15:50 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welches Fenster im Wohnzimmer ist geöffnet?'
dann
11:16:59 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Wie ist der Status des Rolladen Terrasse im Wohnzimmer?'
(den gibt es im Wohnzimmer Geräteliste im Log -> 22:03:39 [INFO] hannah.iobroker: · Rolladen Terrasse () [blind] — States: level )

immer diesselbe Antwort -> Smalltalk, kann ich nicht beantworten (ich vermute hier würde mein auf kurze Antworten getrimmtes LLM nun auch halluzinieren und einen Status erfinden)

Etwas später:
Welcher Rolladen ist geöffnet?
12:55:01 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welcher Rolladen ist geöffnet'
12:55:01 [INFO] hannah.main: [textcmd] Text: 'Welcher Rolladen ist geöffnet' → Intent: Query | Raum: None | Gerät: Rolladen | Wert: None | SpeakerUser: 2
12:55:01 [INFO] hannah.main: [2] Antwort (Query): 'Rolladen im Kinderzimmer: 0 %.'

Noch später:
14:54:54 [INFO] hannah.main: [textcmd] Text: 'Welcher Rolladen ist gerade geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: Rolladen | Wert: None | SpeakerUser: 2
14:54:54 [INFO] hannah.main: [2] Antwort (Query): 'Rolladen im Kinderzimmer: 100 %.'

Warum? Woher kommt das "Wohnzimmer"? Und woher dann das Kinderzimmer? Vermutlich weil nur dort ein Gerät "Rolladen" ist, alle anderen heissen Rolladen links/rechts etc? Aber sollte das nicht auch über Typ "Blind" gehen?

Dann ist mir ein Fehler passiert:
12:56:45 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welcher Roller hat einen Seite ist geöffnet?'
12:57:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen

Da kam garkeine Antwort, kein Logeintrag! Auch keine LLM Übergabe. Soweit auch reproduzierbar:

12:59:59 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welcher Roller hat einen Seite ist geöffnet?'
13:00:01 [INFO] hannah.trigger_engine: TriggerEngine: 0 Trigger aus der Datenbank geladen

Etwas später dann:
14:57:34 [INFO] hannah.main: [textcmd] Text: 'Welcher Roller hat einen Seite geöffnet?' → Intent: Query | Raum: None | Gerät: Seite | Wert: None | SpeakerUser: 2
14:57:34 [INFO] hannah.main: [2] Antwort (Query): 'Seite im Wohnzimmer ist aus.'

Es ist einfach kaum wirklich reproduzierbar. Aber vielleicht muss ich auch anders testen. Aber so wie es jetzt ist, mit "halben Geräten" und "vorher überlegen wie ich genau anfrage" und so komme ich ehrlich gesagt nicht auf nen grünen Zweig. Müsste man eventuell die Typen wie [blind], [window] etc. mehr einbinden statt der Gerätenamen?

Zu den Satelliten: Danke für die Erfahrungen zur Raum-Abdeckung.

Bzgl. Bestellen bin ich an den Fragen gescheitert, die PCBway stellt. Ich kann Bausätze löten, aber alles andere soll vorbereitet sein.
Könntest Du die Angaben runterschreiben die man braucht oder kann man die evtl. dort voreinstellen?
Als ich zuletzt geschaut habe, war der Preis für die Mindestbestellmenge 5 Stück dann in Summe ca. 100 Dollar unglaublich niedrig, ich steige nicht durch.

Für eine Sammelbestellung - ist da nicht auch noch die Frage wie man Vorkasse und wegen Kursen und Anzahl Geräten stark schwankenden/gestaffelten Preise zusammenbekommt? Die erste Vorkasse wäre ja sehr hoch, die letzte sehr niedrig - und es sollen ja alle vom Sammelpreis profitieren. Dazu noch die vermutlich auch gestaffelten Versandkosten. Ansonsten müsste man üppig viel Vorkasse verlangen und eine Rückzahlung machen?

Viele Grüße

Leonie

Hallo manne01, danke für's gründliche Testen — damit konnte ich tatsächlich zwei konkrete Bugs finden und fixen, nicht nur raten. Der Reihe nach:

RAG/E-Mail-Architektur weitergedacht:

@manne01 sagte:

Das klingt doch alles schonmal gut. Ich würde vermutlich eher alle "Zusatzfunktionen" von dem einen LLM das an Hannah angebunden ist erwarten bzw. dort drin einbauen, oder?

Das trifft es eigentlich noch besser als mein letzter Gedanke mit dem Skill-System: ob ein LLM Internetzugriff hat, ist letztlich eine Eigenschaft des angebundenen LLM-Backends und seines System-Prompts, nicht etwas, das Hannah Core selbst als Feature bauen müsste. Core bräuchte dafür wirklich weder eigenen Internetzugriff noch einen Skill — das Backend müsste nur wissen, mit welchem User es spricht (macht es ja schon) und entsprechend gaten, was es darf.

Log-Spam (TriggerEngine, minütlich):

@manne01 sagte:

minütlichen Meldungen im Core-Log

Notiert, wird auf DEBUG-Level runtergestuft bzw. nur bei echter Änderung geloggt.

Stale Log-Meldung "fehlt in config.yaml's iobroker.state_names":

@manne01 sagte:

Ich denke die logmeldung muss korrigiert werden

Zwei Sachen hier: Der Text ist tatsächlich veraltet — seit Version 0.77.0 ist das gar kein config.yaml-Setting mehr, muss korrigiert werden. Aber dein Override in ioBroker behebt die Meldung selbst leider nicht — das ist ein bekanntes, tieferliegendes Problem: der Override wirkt nur auf die initiale Geräte-Erkennung, nicht auf einzelne Live-Updates danach, weil das zugrundeliegende Datenformat das Feld dafür schlicht nicht mitschickt. Bräuchte eine Erweiterung, ist noch nicht angegangen.

Hannah-State-Base-Types / Settings-UI-Verständnis:

@manne01 sagte:

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.

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.

ControlDevice-Log soll gemappten State zeigen:

@manne01 sagte:

Es wäre hilfreich, wenn Hannah hier im Log angibt, was sie wirklich schaltet

Sinnvoll, nehm ich mit auf.

Hue-Lampen / Saturation:

@manne01 sagte:

Die HUE-Lampen müssen rein :-)

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

Kindersicherung per Speaker-ID:

@manne01 sagte:

Und apropos Kinder

Ich hab da selbst keinen Anwendungsfall, ich lebe allein (bis Hannah lernt Katzen-Duftnoten zu interpretieren, bleibt das wohl so). 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?

"Medien"-Gerät mit mehreren Aktivitäten (Musik/Fernsehen/DVD/Aus):

@manne01 sagte:

Und wie ist das wenn ich ein "Gerät" habe, welches verschiedene States hat die ich aktivieren kann

Da muss ich nachfragen, um das einzuordnen — magst du nochmal genauer beschreiben, wie das bei dir in ioBroker konkret abgebildet ist (States/Datenpunkte)? Klingt für mich erstmal nach einem Trigger-Anwendungsfall, aber ich will nicht raten. Wichtig ist für mich auch wie Hannah das Device sieht. Ich arbeite bspw. auch mit mehreren States pro Gerät, bei mir werden die aber sauber diffenziert.

Fenster/Tür-Kategorie-Frage (Terrassentür):
Eine Vermutung von mir: möglicherweise ist deine Terrassentür bei Hannah als [window] statt [door] einsortiert (z.B. weil du sie in ioBroker unter einer "Fenster"-Funktion gruppiert hast). Kannst du das über deine Geräteliste im Log ([window]/[door]) gegenchecken?
Bei mir kann ich das nicht nachstellen. Türen und Fenster werden in meiner Installation korrekt differenziert.

Die zwei großen Bugs aus deinen Testfällen:
Deine ganze Testfall-Serie hat sich tatsächlich auf zwei konkrete, unabhängige Bugs zurückführen lassen, danke dafür:

Die Wortliste für "Rolladen"/"Rolläden" war unvollständig (nur die formal korrekte Dreifach-L-Schreibweise wurde erkannt) — behoben.
Wenn das LLM kurz nicht erreichbar war, ist die Klassifizierung fälschlich auf Smalltalk gefallen statt auf den LLU-unabhängigen Befehlspfad — dadurch sind auch eigentlich klar beantwortbare Fragen wie "Welcher Rolladen ist gerade geöffnet?" ins Leere gelaufen. Auch behoben.

Beide zusammen erklären den Großteil dessen, was sich für dich "zufällig" angefühlt hat.

@manne01 sagte:

Welche Fenster sind geöffnet? --> soll alle Fenster im System betrachten

Das klappt allerdings bei mir. Warum? Keine Ahnung. GIb mir bitte auch hier für deinen kompletten State-Dump aus dem Core-Log.

Sep 19 15:34:49 psrvhva01 python[196498]: 15:34:49 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:23014473 (user=3) — 'Welche Fenster sind geöffnet?'
Sep 19 15:34:49 psrvhva01 python[196498]: 15:34:49 [INFO] hannah.main: [textcmd] Text: 'Welche Fenster sind geöffnet?' → Intent: Query | Raum: None | Gerät: None | Wert: None | SpeakerUser: 3
Sep 19 15:34:49 psrvhva01 python[196498]: 15:34:49 [INFO] hannah.main: [3] Antwort (Query): 'Bad im Bad oben: geschlossen. Bad im Bad unten: geschlossen. Katzenfenster im Großer Raum: offen. Zimmer_Ost im OG Zimmer Ost: geschlossen. Zimmer_Sued im OG Zimmer Süd: offen. Schlafzimmer im Leonie Schlafzimmer: geschlossen. Schlafzimmer im Leonie Schlafzimmer: offen.'

Und ja, meine Devices haben merkwürdige Namen :D

Danke nochmal für die Ausdauer beim Testen — das war extrem hilfreich!

Liebe Grüße

duemchen

@Leonie sagte:

Ich würde mich ausdrücklich nicht am Handel, an der Bestellung oder dem Geldfluss beteiligen, auch könnte meine Plattform gar nicht am Geldfluss teilnehmen, aber ich könnten den Orgnaizer eben zur Verfügung stellen.

Gibt's in Deiner Umgebunge wirklich niemanden, der das zentral sammeln, Vorkasse und Gewinn abwickeln würde? Die Satelliten sind doch Kern der Geschichte? Und ich als doofer Vielleicht-Nutzer würde das dann nutzen und probieren. Momentan sehe ich viele Detaildiskussionen und bin und bleibe draussen. Nicht so zielführend, um eine größere Gemeinde zu bilden. Schade.

Leonie

@duemchen

Das Hauptmissverständnis liegt hier vermutlich genau bei diesem Punkt: Das ist kein kommerzielles Produkt, das ich vertreibe oder bei dem ich eine Sammelbestellung organisiere.

Es gibt ein Shared Project bei PCBWay, bei dem sich jeder die Platinen und auch die PCBAs direkt dort bestellen kann. Dass das bei Stückzahl 1 astronomisch teuer wird, liegt schlicht an den Fixkosten und daran, dass die Mindestmenge für solche Fertigungen fast immer bei 5 Stück liegt. Eine Anleitung dazu entsteht gerade ohnehin für die Doku.

Wer die Satelliten bauen will, kommt an diesen 5er-Paketen meistens gar nicht vorbei – ich habe im Laufe der Entwicklung auch etliche Versionen geordert, von denen viele Revisionen am Ende im Schrank gelandet sind, weil man sich Schritt für Schritt herantasten muss. Das ist eben der normale Weg bei solchen Prototypen.

Warum ich das aber nicht zentral für andere verwalte oder importiere, hat handfeste rechtliche Gründe:

Sobald ich das für Dritte abwickle, betreibe ich Elektronikhandel und bringe Geräte in Verkehr.

Ohne offizielle EMV-Messung, CE-Konformitätserklärung und den ganzen liebevollen bürokratischen Segen, den Brüssel für den legalen Betrieb so vorsieht, darf und will ich mir das schlicht nicht leisten. Das Risiko steht in keinem Verhältnis zu einem Hobby-Projekt.

Ich hatte zwar auch schon überlegt, ob man einen offiziellen Importeur oder Distributor für die Satelliten findet – ich fürchte nur, bei Unternehmen wie Reichelt oder Waveshare anzuzufragen, ob sie solche Platinen ins Sortiment aufnehmen, würde komplett ins Leere laufen. Die dafür nötige kommerzielle Stückzahl gibt der Markt für dieses Nischenprojekt aktuell schlicht nicht her.

Deshalb bleibt eben der Weg: Wer den Stückpreis senken will, muss sich entweder zusammentun oder eben selbst ein 5er-Paket ordern. Ich stelle die Hardware-Files, die Dokumentation und das Design bereit – die logistische und organisatorische Handhabung außerhalb muss aus rechtlichen Gründen zwingend bei der Community selbst liegen.

Wer den Weg über eine eigene kleine Bestellung (z.B. das 5er-Minimum) scheut oder sich nicht an Detaildiskussionen beteiligen will, für den ist der reine Selbstbau über das Public-Projekt aktuell schlicht die Hürde. Aber das ist eben der Kern von Open Source: Man bekommt die Vorlage frei Haus, die Verantwortung für die Umsetzung trägt man selbst.

Wenn du oder jemand anderes dazu noch konkrete Fragen habt oder das vertiefen wollt: Schreibt mir gerne jederzeit eine private Nachricht im Chat, da stehe ich für einen Austausch natürlich immer offen!

Liebe Grüße
Leonie

Walter.O.

@Leonie sagte:

@Walter.O. sagte:

ich habe da mal (wieder) eine Frage, diesmal zu Telegram

Hallo Walter, kein Problem, frag ruhig — dafür ist das Forum ja da!

Bei "(deprecated) Veraltet" muss ich leider erstmal passen, ohne mehr zu wissen. Könntest du mir zwei Dinge schicken, damit ich dir gezielt helfen kann?

Einen Screenshot von der Stelle in der WebUI, wo diese Meldung auftaucht (am besten mit der ganzen Seite drumrum) — dann seh ich genau, worauf sich "veraltet" bezieht

Hier beim Klick auf Verbinden Telegram.

Ergebniss:
URLals Text:

https://oauth.telegram.org/auth?bot_id=+++meine ID+++&origin=https%3A%2F%2F192.168.178.122%3A5000&request_access=write&return_to=https%3A%2F%2F192.168.178.122%3A5000%2Fme

Ein paar Infos zu deiner Domain: bei wem hast du sie registriert, und zeigt sie aktuell überhaupt schon irgendwohin (auf eine IP-Adresse, einen DynDNS-Dienst, o.ä.)?

Ich habe mir eine Duck DNS zum test eingerichtet: http://home-wollemen.duckdns.org
Diese ist in der FritzBox eingetragen aber sonst noch nichts gamacht auch keine Freigaben.

Mit den beiden Sachen kann ich dir dann eine Anleitung schreiben, die auch wirklich zu deiner Situation passt — sonst rate ich womöglich am eigentlichen Problem vorbei.

Liebe Grüße

Leonie

Danke dir, ich sehe warum. Gib mir bitte ein wenig Zeit, dann antworte ich dir passend

Community Forum

NEWS

Hannah — Open Source Smart-Home-Sprachassistentin

Support us

419

33.1k

83.8k

1.4m