Node.js 24 ist jetzt offiziell empfohlen!

[Leonie]

Und was heißt "du kommst nicht drauf"?

[Walter.O.]

Erledigt, hat nach 5 mal neu starten jetzt geklappt

[Leonie]

Hey,

Wer hat denn Lust auf eine Sammelbestellung an den Satelliten bei PCBWay? Wenn das so klappt wie ich mir das vorstelle, müsste hier irgendwo eine Umfrage sein, falls nicht, bitte einfach diesen Beitrag zitieren. Das werte ich dann als Interesse.

Ich werde mich allerdings nicht selbst an der Beschaffung beteiligen, das hier dient lediglich dazu alle Interessenten zu sammeln.

Grundsätzlich gibt es eine Anleitung für das Bestellen: https://hannah-docs.leonie.network/components/satellite/pcb-order/ Für weitere Fragen bin ich aber natürlich ansprechbar.

Viele Grüße

[manne01]

Hallo Leonie,

hier endlich wieder mal eine gesammelte Rückmeldung zu diversen Themen:

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

Top, Danke - viel besser:)

Noch eine Beobachtung zum Thema logging - diese Meldungen trudeln relativ unregelmässig ein - wieso kommen die nicht alle gesammelt beim Startup?

07:57:33 [WARNING] hannah.iobroker: Unbekannter State-Suffix 'ACTUAL' (state_id=matter.0.controller.123456789.ContactSensor-1.ACTUAL) — fehlt in config.yaml's iobroker.state_names, Live-Update wird verworfen (Wert friert auf dem letzten Snapshot ein).

---

Eine beliebige Texteingabe auf den ioBroker State "hannah.0.satellites.rooms.all.announcement" müsste doch allen satelliten den text ansagen?
Mit dem announcement-State für den Raum in dem mein Satellite Lite ist gehts (hannah.0.satellites.rooms.hobbyraum.announcement) und auch direkt auf dem gerät (hannah.0.satellites.rooms.hobbyraum.desktop.announcement)

Hue-Lampen / Saturation:

@Leonie sagte:
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

Bei mir sind es IKEA Lampen, die offenbar nur HUE "sprechen". Ich muss sagen ich habe mir den Alias Adapter angesehen, aber bin nicht schlau draus geworden. Das muss ich mir nochmal genauer ansehen.

Kindersicherung per Speaker-ID:

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?

Genial, ist ja jetzt schon eingebaut - toll!

Mir fehlt natürlich noch das Gefühl wie sicher die Sprechererkennung überhaupt ist. Wenn die treffsicher ist, dann ist das perfekt. Wenn das nicht so zuverlässig klappt müsste Hannah bei bestimmten Sachen nach einem Kennwort, PIN oder so fragen das man in ioBroker bei der Hannah Config der empfindlichen Geräte dazu konfiguriert. Was natürlich bei Sprache alles bissle blöd ist. Oder notfalls halt einen Morse Code am Satellite eintippen oder so. Sprechererkennung mit Trustlevel ist aber das schickste.

Wenn die Kids versehentlich oder bewusst anfangen per Sprache Sachen zu kommandieren die man eigentlich nur für sich selber implementiert hat oder die "teuer" finde ich das richtig wichtig. Also z.B. das Hof-Tor, die Teichbewässerung, der Whirlpool, die Standheizung oder sicherheitsrelevanten Sachen (wie eine Scharfschaltung) zu spielen kann es doof werden.

Ich muss das also umgehend testen! :-)

Da fällt mir ein, vielleicht wäre auch generell bei ausgewählten Statusänderungen und zur Vorsorge bei "Missverständnissen" in der Spracherkennung so eine Art konfigurierbare Sicherheitsrückfrage "Bist Du sicher? Bitte bestätigen -> Bestätigt"?
Oder auch ein "Audit-Trail" oder eine Benachrichtigung an den Admin (per Telegram). Aber letzteres könnte man ja jederzeit selber ioBroker-Seitig implementieren.

---

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

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.

@Leonie sagte: 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.

Richtig gut und das Puzzle verständlich aufbereitet die Doku jetzt - vielen vielen Dank!

Richtig gut ist auch die neue Geräteliste in der WebUI, konsistent auffindbar und übersichtlicher und vollständigere Infos als im Log.

In der WebUI ist ja jetzt das Mapping rausgeflogen mit dem man Hannah-Keys auf eigene Keys mappen konnte. Nun muss man alles überschreiben und das kann u.U. recht viel werden, oder? Oder ist da doch die Empfehlung mit Aliasen oder diesem Script zu arbeiten um das zu vermeiden?

Es wäre glaube ich schon eine Vereinfachung in WebUI-Settings weiterhin mehrere STATE-names auf einen Hannah-State mappen zu können? (die UI erlaubte das mehrfache zuweisen nicht als das State Suffix Mapping noch drin war)
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: Wenn ich mein ein Gerät mit mehreren States z.B. ein [light] mit ON, DIMMER, SATURATION etc. überschreiben muss, muss ich dann alles mehrfach an jedem State überschreiben?

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

Ist nun mit "open" überschrieben und klapt nun, super!

---

Könnte Hannah bei Rolladen Level abfragen auch in "offen/zu" übersetzen statt 0% und 100% (nur noch alles dazwischen dann numerisch)? Das wäre etwas menschlicher/verständlicher.

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

PASST NUN! das habe ich rausgefunden -> Im Kinderzimmer war das einzige Fenster welches nicht "Fenster -" oder "Fenster --" heisst. Nach dem Überschreiben aller Varianten mit schlicht "Fenster" hat Hannah nun nachgefragt welches ich meine.

Welche Rolläden sind geöffnet? Hier erfolgte ja keine Nachfrage, sondern Antwort mit Bezug aufs zuletzt angefragte Wohnzimmer. Das scheint tw. immer noch so:

23:37:05 [INFO] hannah.main: [textcmd] Text: 'Welche Rolläden sind geöffnet?' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:37:05 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'

23:38:23 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:38:23 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'

23:40:45 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: None | Gerät: None | Wert: None | SpeakerUser: 2
23:40:45 [INFO] hannah.main: [2] Antwort (Query): ---> hier nun eine Lange liste mit sämtlichen Rolladen in allen Räumen

Es kam also erst nach einer Pause von ca. 2min dann die Antwort mit alle Rolläden - dh. Hannah behält den Kontext Wohnzimmer noch eine Weile, richtig?
Aber warum hier dann keine Nachfrage welcher Raum?

23:47:12 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welcher Rolladen ist geöffnet'
23:47:12 [INFO] hannah.main: [textcmd] Text: 'Welcher Rolladen ist geöffnet' → Intent: Query | Raum: None | Gerät: rolladen | Wert: None | SpeakerUser: 2
23:47:12 [INFO] hannah.main: [2] Antwort (Clarification): 'Welchen Raum meinst du — Wohnzimmer oder Kinderzimmer?'

Mit der Frage nach "Rolladen" kommt eine Rückfrage.
Ich vermute hier kommt Hannah durcheinander, weil es eben Rolladen gibt, aber auch Rolladen Seite etc.

23:47:29 [INFO] hannah.grpc_server: [grpc] SubmitText von telegram:8751810120 (user=2) — 'Welche rollläden sind geöffnet'
23:47:29 [INFO] hannah.main: [textcmd] Text: 'Welche rollläden sind geöffnet' → Intent: Query | Raum: Wohnzimmer | Gerät: None | Wert: None | SpeakerUser: 2
23:47:29 [INFO] hannah.main: [2] Antwort (Query): 'Im Wohnzimmer: Rolladen Seite -: 30 %, Rolladen Doppeltür: 0 %.'

Auch hier ohne Not wieder eine plötzliche Festlegung auf Raum Wohnzimmer.

Das Ganze ist ganz gut reproduzierbar.
"Welcher Rolladen ist geöffnet" -> fragt nach
"Welche rollläden sind geöffnet" -> legt sich auf Wohnzimmer fest, das verstehe ich nicht.

---

Der neue Windows-Lite-Satellite funktioniert bei mir klasse trotz Synology-Hürden und man hat damit einen tollen Vorgeschmack in Richtung Voice2Voice-Kommunikation bzw. vor allem sofortiger Voice-Rückantwort von Hannah und Smalltalk. Von hier aus heißt es jetzt: auf gehts zum Satellite :-)

---

Die für mich offenen Punkte mit "Sondergeräten" die ich bisher per VIS bedient habe schaue ich mir nun nochmal näher an was ich da selber scripten kann oder mit Aliasen etc.

Soviel wieder für heute - entschuldige die Themensprünge und alles was ich (noch immer) nicht ganz verstanden habe...
Danke für die Rückmeldungen und die tollen Fortschritte!

[Leonie]

Hey

@manne01 sagte:

wieso kommen die nicht alle gesammelt beim Startup?

Weil sie es nicht können. Die kommen wenn der ioBroker ein Statusupdate sendet und das passiert bspw. wenn du ein Fenster öffnest.

@manne01 sagte:

Eine beliebige Texteingabe auf den ioBroker State "hannah.0.satellites.rooms.all.announcement" müsste doch allen satelliten den text ansagen?

Tut es jetzt auch. Das war ein Bug :D

@manne01 sagte:

Mir fehlt natürlich noch das Gefühl wie sicher die Sprechererkennung überhaupt ist.

Ich werde eigentlich immer erkannt, allerdings ist das wohl keine Refrenz.

@manne01 sagte:

Ich muss das also umgehend testen! :-)

Auf jeden Fall und bitte melden, ich bin auf das Ergebnis gespannt :)

@manne01 sagte:

Oder auch ein "Audit-Trail"

Es gibt den ActivityLog. Darüber ist erkennbar welcher User wann was zu Hannah sagte. Grundsätzlich wird auch die Antwort da geloggt, nicht aber geschaltete ioBroker-Geräte.

@manne01 sagte:

eine Art konfigurierbare Sicherheitsrückfrage

Muss ich mir überlegen. Generell wäre so eine Confirmation bestimmt möglich, die grundlegende Infrastruktur ist vorhanden. Vielleicht kann man das so simpel bauen das man im ioBroker in den State-Settings eine Checkbox hat um das zu aktivieren. Soweit aber nur eine Idee geade.

@manne01 sagte:

Richtig gut ist auch die neue Geräteliste in der WebUI

Vielen Dank

@manne01 sagte:

In der WebUI ist ja jetzt das Mapping rausgeflogen

Ja, aus der WebUI wurde das entfernt. Ich verstehe den Punkt den du hast. Hilfreich wäre zu wissen wie der Adapter den State auflöst. Möglich das wir hier auf einer Altlast arbeiten. Eigentlich, in meinem Verständnis, sollte der Statename keinen größeren Wert haben, wenn denn der State ansonsten korrekt definiert ist, also bspw. die korrekte Rolle trägt.
Wenn du den LogCollector laufen hast, gib mir bitte Logs über den und zwar von Core und von ioBroker. Auch ein entsprechender Objectdump wird helfen.

@manne01 sagte:

muss ich dann alles mehrfach an jedem State überschreiben

Eigentlich ist das Ziel das man gar nichts überschreiben muss, wenn denn die States ordentlich definiert sind. Ich halte mich da eigentlich an den ioBroker-Standard. Siehe den vorherigen Absatz.

@manne01 sagte:

Könnte Hannah bei Rolladen Level abfragen auch in "offen/zu" übersetzen statt 0% und 100%

Sollte sie eigentlich können. Klappt das bei dir nicht? Zeig mir gerne Logfiles von dem Versuch vielleicht kann ich dann sehen wo es hängt. Ich habe selbst leider keine Rollläden zum Testen.

@manne01 sagte:

Hannah behält den Kontext Wohnzimmer noch eine Weile, richtig

Heute morgen noch, ja. Jetzt nicht mehr. Gerne testen.

@manne01 sagte:

"Welche rollläden sind geöffnet"

Was passiert wenn du das gleiche bspw. mit Lichtern fragst, also "Welche Lichter sind an?" Teste bitte.

@manne01 sagte:

Sondergeräten

Dazu haben wir uns ja erst kürzlich wieder ausgetauscht :D Du darfst dich gerne nochmal dazu melden, wenn du irgendwo hängst ;)

Liebe Grüße

[Walter.O.]

Also ich Währe mit einem Sateliten bei der Bestellung dabei.
Allerdings hab ich eine Bestellung mal bei PCBWay Durchgespielt, muss aber ehrlich sagen, ich bin zu Alt für den Sch...
Wenn jemand von euch eine Bestellung Anstoßen möchte, wie gesagt ich brauche 1 Stück.
Lasst uns doch hier durch "Zitieren" Feststellen wie viele Geräte ingesamt benötigt werden.
Gruß
Walter

[micklafisch]

@Walter.O.
Für den ersten Test wäre ich auch aktuell bei einem Gerät. Später dann ggf. mehr

[Leonie]

Hey,
kurzer Nachtrag zu meiner Antwort oben, ich habe inzwischen in den Code geschaut und muss eine Aussage präzisieren.

@manne01 sagte:

muss ich dann alles mehrfach an jedem State überschreiben?

Ich hatte geschrieben, dass man eigentlich gar nichts überschreiben muss. Das stimmt nur für States, deren Rolle Hannah kennt (z.B. switch.light, level.dimmer, value.temperature, sensor.window). Bei zu generischen Rollen wie state (dein Homematic-Kontakt) muss man überschreiben, und zwar so:

• Typ (light, socket, window usw.): einmal am Gerät oder am State, ein Eintrag reicht.
• Key (on, level, open usw.): pro State, weil jeder State im Gerät eine andere Rolle spielt.

Bei einem Licht mit ON/DIMMER/SATURATION also den Typ einmal setzen, den Key nur bei den States, die nicht automatisch erkannt werden.

@manne01 sagte:

current = ACTUAL_HUMIDITY
current = ACTUAL_TEMPERATURE

Der Haken ist, dass ein Gerät (der Kanal/Ordner, in dem die States liegen) nur einen current-Platz hat. Liegen Temperatur und Feuchte im selben Kanal, überschreiben sie sich gegenseitig. Dafür wäre ein Mapping in der WebUI keine Lösung, das würde nur beide auf denselben Platz legen. Sauber ist es, die beiden auf getrennte Geräte zu legen (Alias), jeweils mit der passenden Rolle (value.temperature bzw. value.humidity).

Die Warnung mit ACTUAL (Matter ContactSensor-1) sieht mir nach demselben Fall wie beim Fenster aus: Die Rolle ist für Hannah zu generisch, also Override auf open. Ohne den Objektdump kann ich das aber nicht sicher sagen.

@manne01 sagte:

Könnte Hannah bei Rolladen Level abfragen auch in "offen/zu" übersetzen

Ich hatte geschrieben, das sollte sie eigentlich können. Präzisierung: Steuern geht ("Rolladen auf/zu" setzt 100%/0%), aber beim Abfragen nennt Hannah aktuell nur den Prozentwert. Deine Logs passen genau dazu. Eine Übersetzung in offen/zu (mit Prozent für alles dazwischen) gibt es noch nicht, ich schaue mir an, wie ich das sinnvoll mache.

Langfristig denke ich über ein Modell nach, in dem der Adapter Geräte anhand von Rolle, Raum und Function selbst zu typisierten Geräten (Licht, Thermostat, Sensor usw.) zusammensetzt. Dann wären Overrides die Ausnahme statt die Regel. Das ist noch Konzeptarbeit, aber genau dein Punkt ist einer der Auslöser dafür.

Liebe Grüße

[Jey Cee]

@Leonie sagte:

Langfristig denke ich über ein Modell nach, in dem der Adapter Geräte anhand von Rolle, Raum und Function selbst zu typisierten Geräten (Licht, Thermostat, Sensor usw.) zusammensetzt.

Dafür gibt es den type detector von ioBroker. Weis nicht ob du den schon kennst.

[Leonie]

Den habe ich auch gefunden :) Der steht auch in meinem Konzept bereits drin. Das Problem ist aber nicht ioBroker, sondern Hannah, sie muss das erstmal verstehen können :D

[manne01]

Hier nochmal eine Erinnerung an die Umfrage zur Sammelbestellung - bei Interesse bitte eintragen!