Hannah — Open Source Smart-Home-Sprachassistentin

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?

Community Forum

NEWS

Hannah — Open Source Smart-Home-Sprachassistentin

Support us

310

33.1k

83.8k

1.4m