Hannah — Open Source Smart-Home-Sprachassistentin
-
Dann warte ich jetzt mal auf den builder, damit ich den mqtt
noch ans laufen kriege und mit dem IOB verbinden kann.Macht so Ja noch keinen Sinn.
Bestünde die Möglichkeit in der webui ein Eingabefeld einzurichten,
mit dem man Hannah schon mal Textbasiert testen kann ohne über
Telegram gehen zu müssen?
Nutze kein Telegram und möchte dies auch nicht.
Einen Satelliten hab ich ja auch noch nicht.Ach ja, bei der Sammelbestellung wäre ich auch mit dabei.
Erst einmal 1x zum testen 4 Stück wären dann für die Erweiterung vorzusehen.
@leonie
Danke für dein
Bin endlich von der -1 runter
-
Sneakpeak.
Nutze kein Telegram und möchte dies auch nicht.
Verständlich. Ich hab es eingebaut, weil ich es nutze und auch viele andere hier.
Es gibt eine Hannah-Shell:
https://github.com/NurPech/Hannah/blob/master/scripts/hannah_shell.pyVielleicht hilft die dir? Das einzige Problem dürfte nur sein, die ist davon abhängig das sie Zugriff auf die Core-Files hat.
Vielleicht nehme ich mir vor, daraus mal eine eigenständige "App" zu bauen. Vielleicht in Typescript oder Powershell, vielleicht als kompilierte Datei für Windows und Linux?Wer sich grad wundert, wie schnell sowas manchmal geht: Um 22:47 hatte ich hier noch geschrieben, dass ich an einem interaktiven Docker-Compose-Builder für die Installation dran bin — und tatsächlich, keine zwei Stunden später steht er schon live in der Doku. 😄
Komponenten anklicken, fertige docker-compose.yml bekommen, inklusive automatisch generierter Passwörter — kein Rumfrickeln mehr mit Profiles oder separaten Config-Dateien:
https://hannah-docs.leonie.network/manual/installation/#__tabbed_1_1
Viel Spaß beim Ausprobieren, und wie immer: Feedback gerne her damit.
Damit gibt es nun 3 Installationswege in der Doku:
- der wirklich einfache Weg mit Docker
- der etwas erweiterte Weg mit Docker
- der native Weg ohne Docker
Somit sollte für jeden was dabei sein
-
vielleicht als kompilierte Datei für Windows und Linux?
Das würde ich persönlich doch sehr gut heißen.
Wer sich grad wundert, wie schnell sowas manchmal geht: Um 22:47 hatte ich hier noch geschrieben, dass ich an einem interaktiven Docker-Compose-Builder für die Installation dran bin — und tatsächlich, keine zwei Stunden später steht er schon live in der Doku. 😄
Also ich wunder mich wie du das alles regelt:
a. Bist hier fast 24h online und reagierst immer zeitnah.
b. Kümmerst dich um dumme User fragen.
c. Erstellst nebenher mal eben ein neues Release.
d. Und jetzt programmierst noch gerade mal den Builder.
Komponenten anklicken, fertige docker-compose.yml bekommen, inklusive automatisch generierter Passwörter — kein Rumfrickeln mehr mit Profiles oder separaten Config-Dateien:
An der Stelle warst du mal wieder schneller als ich.
Die Passwörter kamen mir eben als ich das gelesen habe
auch gleich in den sinn. -
Hab gerrade den Builder getestet, lief soweit alles wunderbar durch.
Habe jetzt wohl zwei mosquitto container, von denen der -conig sich nicht starten lässt.
Deshalb bleibt der Status auf Achtung und wird nicht grün.
Ist das so gewollt oder noch ein Fehler?
-
Das ist korrekt. Das ist quasi ein Trade-Off den ich entschieden habe. Ich muss mir mal überlegen ob sich das smarter lösen lässt.
Hintergrund:
Bei meiner eigenen Software kann ich selbst entscheiden wie sie arbeitet und da kann ich auch selbst einbauen, das sie ihre Config nicht mehr File, sondern per Environment bekommen kann.Mosquitto ist jedoch eine Drittanbietersoftware und unterstützt dieses Verhalten von Haus aus nicht. Das führt zu zwei naheliegenden Optionen:
- Jeder Nutzer müsste manuell eine eigene mosquitto.conf anlegen.
- Ich würde eine eigene, angepasste Mosquitto-Image-Version pflegen.
Option 1 schied aus, weil ich den Anwendern des Generators unnötige Zusatzschritte ersparen möchte. Option 2 wollte ich ebenfalls vermeiden, um den Wartungsaufwand für ein eigenes Image gering zu halten.
Daher habe ich mich für einen Mittelweg entschieden:
Es gibt einen zusätzlichen Container (hannah-mosquitto-config), der beim Start einmalig die Konfigurationsdatei für Mosquitto generiert und sich danach regulär beendet, damit der Hauptdienst problemlos hochfahren kann.Für den Endanwender bedeutet das null Aufwand. Der Trade-off ist lediglich ein Container, der danach im Status „gestoppt“ verbleibt. Technisch ist das in Docker völlig unbedenklich, da der Job sauber erledigt wurde. Warum Synology das in seiner Oberfläche als Warnung interpretiert, ist etwas undurchsichtig – vermutlich ist das dort im Docker-Modul einfach so implementiert, dass beendete Container direkt ins Auge fallen.
-
Das ist korrekt. Das ist quasi ein Trade-Off den ich entschieden habe. Ich muss mir mal überlegen ob sich das smarter lösen lässt.
Hintergrund:
Bei meiner eigenen Software kann ich selbst entscheiden wie sie arbeitet und da kann ich auch selbst einbauen, das sie ihre Config nicht mehr File, sondern per Environment bekommen kann.Mosquitto ist jedoch eine Drittanbietersoftware und unterstützt dieses Verhalten von Haus aus nicht. Das führt zu zwei naheliegenden Optionen:
- Jeder Nutzer müsste manuell eine eigene mosquitto.conf anlegen.
- Ich würde eine eigene, angepasste Mosquitto-Image-Version pflegen.
Option 1 schied aus, weil ich den Anwendern des Generators unnötige Zusatzschritte ersparen möchte. Option 2 wollte ich ebenfalls vermeiden, um den Wartungsaufwand für ein eigenes Image gering zu halten.
Daher habe ich mich für einen Mittelweg entschieden:
Es gibt einen zusätzlichen Container (hannah-mosquitto-config), der beim Start einmalig die Konfigurationsdatei für Mosquitto generiert und sich danach regulär beendet, damit der Hauptdienst problemlos hochfahren kann.Für den Endanwender bedeutet das null Aufwand. Der Trade-off ist lediglich ein Container, der danach im Status „gestoppt“ verbleibt. Technisch ist das in Docker völlig unbedenklich, da der Job sauber erledigt wurde. Warum Synology das in seiner Oberfläche als Warnung interpretiert, ist etwas undurchsichtig – vermutlich ist das dort im Docker-Modul einfach so implementiert, dass beendete Container direkt ins Auge fallen.
der beim Start einmalig die Konfigurationsdatei für Mosquitto generiert und sich danach regulär beendet
Dann heute ich das aus deiner Aussage hoffentlich korrekt, das der nach dem ersten Start des mosquitto auch nicht
wieder benötigt wird?
Folglich könnte der Container gelöscht werden und die Anzeige wäre dann wieder Grün und alles i.O. !
-
Ich fürchte Hannah und ich verstehen uns nicht.
Habe auf dem Test IoB einen DP angelegt: alias.0.EnOcean.Schalten.Wohnzimmer.status als Bolean, Rolle: switch.light, Raum: Wohnzimmer, Funktion: Licht.
Über "hannah.0.textCommand" kann ich ja mit Hannah reden, Hallo -> "hannah.0.textAnswer": Willkommen zuhause!Sag ich Ihr allerdings "Licht Wohnzimmer an" -> sagt Sie nur "Keine Geräte gefunden."
Wo liegt denn hier mein Denkfehler!?!?
-
Der State sollte einen Raum und eine Funktion haben und beides musst du in den Admin-Settings auswählen: https://hannah-docs.leonie.network/components/iobroker-adapter/configuration/
Beziehungsweise:
https://hannah-docs.leonie.network/manual/smart-home-integration/ -
gut, der Adapter selbst kennt schon keine Devices bzw. hat Probleme diese zu lesen. Nimm mal alias.0.EnOcean aus den zusätzlichen Präfixes raus. Ein Objectdump von alias.0.EnOcean.Schalten.Wonzimmer (oder darüber) wäre hilfreich. Rein von deinem Screenshot kann ich keinen Fehler sehen.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
420
Online33.1k
Benutzende83.9k
Themen1.4m
Beiträge