Neu im Blog: Was die neue Website alles kann

[Leonie]

Hii,

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

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

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

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

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

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

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

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

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

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

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

Liebe Grüße

[manne01]

Hi,

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

Den Objektbaum sende ich Dir per Chat.

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

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

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

Ich habs mir auch weiter weiter angesehen und folgendes festgestellt:

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

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

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

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

[Leonie]

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

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

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

[manne01]

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

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

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

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

Die Statusabfrage und setzen klappt jetzt sehr viel besser:

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

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

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

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

Viele Grüße und schönen Abend!

[Leonie]

Hi manne01,

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

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

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

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

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

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

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

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

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

Danke nochmal fürs genaue Hinschauen!

[Luxi]

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

[manne01]

Hallo Leonie,

mal ganz blöd gefragt, statt die ganzen Geräte und Status alle detailliert abzubilden und dann in Hannah alle Spezialitäten von möglichen menschlichen Anfragen per Code zu interpretieren - wäre es nicht auch denkbar, den "Objektbaum" per RAG einem Modell zugänglich zu machen und dann das Modell ermitteln zu lassen was gemeint ist? Denn ansonsten muss man sich doch schon sehr genau ausdrücken und kann keine Synonyme verwenden (oder müsste Synonyme für Geräte, Raumnamen und Funktionen pflegen können)

zu 1: bei Homematic-Rolladenaktoren die ich einsetze (HM-LC-Bl1-FM) ist der LEVEL wie weit sie offen sind, also quasi der Lichteinfall: bei Level 100% der Rollladen ist vollständig offen/oben (maximale Helligkeit / freie Sicht). Und 0% bedeutet der Rollladen ist vollständig unten/geschlossen. Das mag bei den Aktoren anderer Hersteller natürlich anders sein.

zu 2: ja, nachvollziehbar. Wenn ich mir was wünschen darf - solange das Wort "alle" nicht im Kommando ist, müsste er eher nachfragen. Nach dem Motto "Im Zweifel lieber weniger machen."

Wenn sowas nicht geht müsste man sich wohl irgendwie (z.B. mit dem eingebauten Kategorie bzw. Raum/Funktions)-Manager eine neben "Rolläden" eine zusätzliche Funktion "AlleRolläden" oder so bauen oder einen "Raum" = "Erdgeschoss". Die einzelnen Räume und Funktionen sind ja im Objektbaum als enum.x.y angelegt, d.h. man könnte so auch "AlleRolläden" oder "Erdgeschoss" an Hannah geben und Kommandos drauf absetzen?

zu 3:

20:05:48 [INFO] hannah.main: [grpc/voice] Transkript: 'Bitte setze die Rolläden im Schlafzimmer auf 50%.' 
20:05:48 [INFO] hannah.main: [textcmd] Text: 'Bitte setze die Rolläden im Schlafzimmer auf 50%.' → Intent: SetLevel | Raum: Schlafzimmer | Gerät: None | Wert: 50.0 | SpeakerUser: 2 
20:05:48 [INFO] hannah.iobroker: execute: SetLevel → 5 Gerät(e), state='level', value=50.0 
20:05:48 [INFO] hannah.main: [2] Antwort (SetLevel): 'OK, 3 Gerät(e) geschaltet.' 

@Leonie sagte:

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

Mache ich!

Auch noch spannend war heute -> Raum WC wurde erkannt, aber es wurde dann zum Kinderzimmer berichtet:
17:47:06 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:1234567498 (user=2) — 'Wie ist der Status vom Fenster im WC?'
17:47:06 [INFO] hannah.main: [textcmd] Text: 'Wie ist der Status vom Fenster im WC?' → Intent: Query | Raum: WC | Gerät: Fenster | Wert: None | SpeakerUser: 2
17:47:06 [INFO] hannah.main: [2] Antwort (Query): 'Fenster im Kinderzimmer: offen.'

und
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".

Jetzt stellt sich natürlich die Frage was man alles selber überschreibt und was evtl. auch noch an der Erkennung optimiert werden kann :) Am liebsten wäre mir natürlich garkeine Überschreibungen. Ich hab tatsächlich inzwischen rechtviele "Fenster 1" bei denen ich die Zahl wegnehmen muss. Du hattest noch nicht gesagt, ob es irgendwas gibt, was Hannah aus dem Gerätenamen ignoriert. Ein Leerzeichen reicht nicht, aber ein Punkt oder Bindestriche müssten doch vielleicht ohnehin ignoriert werden?

Viele Grüße

[Leonie]

Hi,

@manne01 sagte:

wäre es nicht auch denkbar, den "Objektbaum" per RAG einem Modell

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. 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.
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. Aber zu viel um eine Lampe zu steuern. Natürlich würde ich gerne die Latenzen eher auf nahe 0s bringen, aber siehe die vorherige Aussage.
Daher muss ich alle Fälle einzeln hinterlegen. Aber das ist quasi gar nicht so schwierig. Im Prinzip arbeitet die Intentbildung auf Basis von Schlüsselwörtern mit Kontext und "zu" oder "auf" sind einfach nicht definiert aktuell.

@manne01 sagte:

Das mag bei den Aktoren anderer Hersteller natürlich anders sein.
Das ist witzigerweise genau der Grund warum ich mit diesen virtual Devices arbeite. Damit kann mir vollkommen egal sein, was die Hardwarehersteller an Daten verwenden, ob nun 0% auf oder geschlossen ist oder ob 1 oder 0 an ist. Durch die virtual Devices, kann ich jeden State, egal welches Herstellers, auf den Datentyp bringen den ich ich brauche.
Aber natürlich kann ich das nicht vorschreiben. Auf jeden Fall wäre das eine Aufgabe für den Adapter, evtl. mit einer kleinen UI zum Definieren.
So das Hannah intern immer mit ihr bekannten Werten arbeitet. Aber auch das ist aktuell komplex für mich.
Ich kann das gerne so einbauen dass das für dich passt.

@manne01 sagte:

Wenn ich mir was wünschen darf

Darfst du. Ich denke auch, wenn kein klarer Auftrag für eine Gruppe von Geräten erkannt wird, der Resolver aber mehrere Geräte auflöst, sollte nachgefragt werden. Die technische Pipeline für Rückfragen existiert bereits nur wird sie dafür aktuell nicht genutzt.

Danke für den Log. Darf ich wissen wie viele Geräte du im Schlafzimmer hast und was das für welche sind?
Bspw. zwei Rollläden, eine Lampe, eine Steckdose und eine Tür?
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.

@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".

Kannst du mir bitte Details dazu geben? Gerne auch privat. Nur damit ich weiß was in einem Objectdump welches Gerät ist. Außerdem benötige ich bitte den exakten genutzten Wortlaut.

@manne01 sagte:

aber es wurde dann zum Kinderzimmer berichtet

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

@manne01 sagte:

was Hannah aus dem Gerätenamen ignoriert

Eigentlich ignoriert Hannah bewusst keine Zeichen, außer Satzzeichen und Groß und Kleinschreibung. Also Zahlen müssten durchgehen. 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". Auch kann ich den von dir beschrieben Fehler nicht nachvollziehen, ich habe den kompletten Gerätepfad durchgeschaut.
Kannst du mir bitte den Startlog von Hannah Core geben? Bzw. den Teil nach dem der Adapter connected ist? Also der Teil in dem alle bekannten Geräte aufgelistet werden.

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.

Liebe Grüße

[Leonie]

@manne01 sagte:

aber könnte man die Version der Komponenten beim Start ins Log schreiben

Ich habe das bisher vollkommen übersehen, sorry dafür.

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.

[Walter.O.]

Hallo zusammen, ich bin zwar derzeit noch im Rügen Uhrlaub aber mal eine Frage , wie komm ich denn in die Webui?
Ach ja, wie ist das beim Telegram_Bot mit der Domain auf sich, sprich wie sieht diese aus (eine Webdomain im sinne von meinedomain.de)?
Wie groß ist denn mittlerweile das Bestellvolumen bei PCBWay und damit der Einzelpreis?

[Leonie]

Hi,
Die WebUI ist direkt per IP erreichbar, ganz ohne Domain — http://<IP-deines-Hosts>:5000 im Browser, Port 5000 ist der Standard. Domain/HTTPS brauchst du dafür nicht.
Willst du allerdings die Telegram Account-Verknüpfung nutzen, musst du eine Domain verwenden, ganz im Sinne von meinedomain.de. Das muss allerdings keine kostenpflichtige Domain sein, der BotFather von Telegram akzeptiert auch dyndns-Adressen

Kurzes Update zur Telegram-Verknüpfung, weil das Thema hier ja schon mal aufkam: Domain (auch DynDNS) bleibt Pflicht fürs offizielle Login-Widget, daran ändert sich nichts.

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 — braucht nur die Telegram-User-ID (holt man sich z.B. über @userinfobot). Keine Domain, kein Widget.

Der Haken: beim Widget bestätigt der User selbst per Telegram-Login "ja, das bin ich" — bei der manuellen Variante fällt das weg, der Admin trägt einfach ein, was der User ihm sagt. 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?

[Walter.O.]

Hallo, ich mal wieder.
wird das Username Passwort für web UI irgendwo festgelegt? Wenn ich einen Namen und ein pw eingebe kommt
"Hannah Core nicht erreichbar Hannah Core antwortet gerade nicht. Bitte versuche es in Kürze erneut." oder ist das eine andere Fehlermeldung?
Wo würde ich nach dem Core Update Suchen?

[Leonie]

Ich bin mir nicht sicher ob ich die Frage korrekt verstehe. Beim ersten Start erstellt der Core einen User mit dem Namen admin und generiert ein Passwort. Das Passwort wird dann im Log ausgegeben. Wenn du das nicht weißt, wird es kompliziert.
Weitere Nutzer lassen sich dann in der WebUI anlegen. Anmelden mit dem admin und dem Startpasswort und die Userverwaltung öffnen.

Um Updates der Komponenten kümmert sich AutoDeploy, wenn es denn auch konfiguriert ist. Alternativ kannst du einfach die install-Scripte erneut ausführen.

[Walter.O.]

wo finde ich den Log

[Leonie]

im journald

sudo journalctl -u hannah

[Walter.O.]

Ich habe das Problem , das der Log sagt "kann config.yaml nicht finden"
Die Datei liegt aber im hannah ordner.
Welche Schreib Lese rechte müssen Ordner und .yaml haben?

[Thomas Braun]

@Walter.O. sagte:

Welche Schreib Lese rechte müssen Ordner und .yaml haben?

Welche haben sie denn jetzt bei dir?

[Leonie]

Die Datei muss standardmäßig nach /etc/hannah/config.yaml

[Walter.O.]

@Leonie
Liegt in /etc/hannah/
drwxr-xr-x 2 hannah hannah 4096 Sep 14 09:29 hannah

-rw-r--r-- 1 root root 9034 Sep 14 09:29 config.yaml

[Leonie]

gib die Datei noch dem User von Hannah:

sudo chown hannah:hannah /etc/hannah/config.yaml

und danach, falls nötig, den Core neustarten:

sudo systemctl restart hannah

und dann wieder mit journalctl die Logs prüfen:

sudo journalctl -u hannah

Du kannst darin mit den Pfeiltasten navigieren (hoch und runter), mit Shif+G ans Ende springen und mit q das journal verlassen.