Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

(239.67 kB - runtergeladen 0 Mal.)

?

Kein Interesse an der "Babble/STT/TTS-Version"? Keine Zeit bisher? Übersehen?

[Prof. Dr. Peter Henning]

Bisher keine Zeit: Jahresabschluss meines Unternehmens, Umsatzsteuervoranmeldung, Endredaktion des neuen Buches, Vorbereitung Landesparteitag, Vorbereitung Lehre Wien. Und so unbedeutende Sachen wie Familie.

LG

pah

[JensS]

Generell finde ich es gut, das Modul für eine Mehrstufigkeit zu öffnen. Vorerst beschäftige ich mich allerdings mit Verbesserung der akustischen Erkennung und der Dialogfähigkeit.
In der SNIPS-Hermes-Referenz steht was zur Nutzung von Slots in continueSession. Die Info habe ich auch bei anderen HERMES-MQTT-Produkten gesehen, außer bei Rhasspy. Allerdings fand ich in bei Keinem einen Code dazu, die Daten auszuwerten. Scheint wohl ein ToDo von Snips gewesen zu sein...

Gruß Jens

[Prof. Dr. Peter Henning]

Generell finde ich es gut, das Modul für eine Mehrstufigkeit zu öffnen

Das sollte man genauer überlegen. Man könnte - so wie ich das vor etlichen Jahren mit OWX gemacht habe - ein generisches Sprachsteuerungsmodul haben, das zusätzlich spezifische Interface-Module kennt (z.B. Rhasspy) kennt und verschiedene Backends zum Schalten/Abfragen

LG

pah

[Beta-User]

Das sollte man genauer überlegen. Man könnte - so wie ich das vor etlichen Jahren mit OWX gemacht habe - ein generisches Sprachsteuerungsmodul haben, das zusätzlich spezifische Interface-Module kennt (z.B. Rhasspy) kennt und verschiedene Backends zum Schalten/Abfragen

Prinzipiell wäre das denkbar. Zumindest sind die meisten internen Strukturen bereits so aufgebaut, dass man die Funktionsblöcke relativ leicht wiederverwenden können sollte, und die zur Verfügung stehenden Optionen sind nach meinen Eindruck (der allerdings betr. andere Lösungen zugegebenermaßen sehr oberflächlich ist) sehr gut auf FHEM abgestimmt und bieten eine ziemliche Flexibilität in der Konfiguration von "speziellen Fällen" und Anforderungen. Da die Hauptkonfiguration "an den Devices" stattfindet (ggf. mehrsprachig), ist es mAn. auch vergleichsweise durchschaubar.

Der zentrale "mach was"-Dispatcher ist auch eher simpel, es müssen halt input-seitig passende Datenstrukturen geliefert werden... Der Teil sollte kein Hexenwerk sein, wenn denn passender Input kommt.

Antworten ist auch eher simpel, aber jeder Partner (im Moment: Rhasspy, "msg" und "external speak") hat dann doch im Detail etwas andere Anforderungen.

Die Hauptschwierigkeit ist vermutlich, aus Gesprochenem/Geschriebenem passende Datenstrukturen zu generieren bzw. ggf. dann auch die Gegenseite mit "slots" zu versorgen...

Bin für Vorschläge offen .

[JensS]

Die Hauptschwierigkeit ist vermutlich, aus Gesprochenem/Geschriebenem passende Datenstrukturen zu generieren bzw. ggf. dann auch die Gegenseite mit "slots" zu versorgen...

Durch die Schaffung eines generischen Sprachsteuerungsmoduls, welchem die Deviceattribute gDT, speechEnable, speechMapping, speechName, speechRoom, etc. zugeordnet sind, würde es einen Standard und eine Schnittstelle für div. Sprachsteuererungs-, Chat- und Bot-Module bieten. Rhasspy würde seinen Dienst dort zur Verfügung stellen und könnte dabei auf einen Datenbestand zurückgreifen bzw. müsste nicht selbst alles einsammeln. Die statischen Sentences wären eine andere Baustelle.

Mit deiner umfangreichen gDT-Generierung könnten bei Definition des zentr. Moduls, alle Devices vorbelegt und erstmal deaktiviert werden.

Gruß Jens

[Beta-User]

Durch die Schaffung eines generischen Sprachsteuerungsmoduls, welchem die Deviceattribute gDT, speechMapping, SpeechName, speechRoom, etc. zugeordnet sind, würde einen Standard und eine Schnittstelle für div. Sprachsteuererungsmodule, Chat- und Bot-Module bieten. Rhasspy würde seinen Dieste dort zur Verfügung stellen un könnte dabei auf einen Datenbestand zurückgreifen bzw. müsste nicht selbst alles einsammeln.

MAn: Jein.
Das zentrale Modul würde  dann das Einsammeln übernehmen, wobei - wie jetzt bei RHASSPY - mehrere Instanzen möglich sein müssen, um mehrere User (mit unterschiedlichen Berechtigungen), mehrere Sprachen, .... möglich zu machen. Im Prinzip würde man mAn. den eigentlichen Kern belassen und dann nur die "Schnittstellen" drumrum anders bedienen.

Wie hatte ich das sinngemäß neulich zum generischen "Messenger"-Interface geschrieben: RHASSPY etabliert eine "sprachliche Meta-Ebene", die man im Prinzip ohne weiteres generisch nutzen kann. Wobei "eine" eben verkürzt ist: es können auch "mehrere sprachliche Meta-Ebenen" sein, RHASSPY hat damit mAn. kein prinzipielles Problem...

Mit deiner umfangreichen gDT-Generierung könnten bei Definition des zentr. Moduls, alle Devices vorbelegt und erstmal deaktiviert werden.

Hmmm, zum einen: Es gibt ja auch weitere Lösungen, die ihr eigenes "homeBridgeMapping" kennen (das sich gelegentlich "beißt", wenn ich das v.a. bzgl. gassistant richtig verstanden habe). Müßte/könnte man ggf. auch berücksichtigen, ich habe bisher allerdings nicht die Notwendigkeit gesehen, mich da näher einzufuchsen.
Zum anderen sind im rhasspyMapping ja auch Antwortsätze drin. Wenn das so bleiben soll, muss das pro Instanz vorgehalten werden, eine "one-for-all"-Lösung geht dann nicht. Tendenziell sehe ich - abgesehen vom höheren Datenvolumen im Speicher - im Moment noch kein wirkliches Argument, warum man an der Stelle was anderes bauen sollte.

[Prof. Dr. Peter Henning]

RHASSPY hat damit mAn. kein prinzipielles Problem...

Na ja. Alle tappen immer noch Dunklen wegen der externen MQTT-Anbindung eines TTS-Service, auch im Rhasspy-Forum wird nur wild geraten

Babble habe ich inzwischen um Attribute für Devices erweitert:
- babbleDeviceType (fast dasselbe wie genericDeviceType. habe das nur temporär etwas stärker eingeschränkt, siehe unten)
- babblePlace (eben nicht der "Room" - sondern hier kann man auch einen Wert wie "hinter der Kellertür" ablegen)

Auf entfernten FHEM-Installationen kann man mit ein paar Codezeilen (z.B. in einer Datei 99_BabbleUtils.pm) einen Service installieren, der beim Aufruf von <ip>:8083/fhem/babble_devlist eine JSON-Struktur liefert, die im lokalen Data-Hash von Babble abgelegt wird. Damit kann Babble auch Devices steuern und abfragen, die auf den externen FHEM-Installationen liegen. Und zwar ohne dass ich sie Babble explizit bekannt mache.

Der Satz "Schalte das Licht hinter der Kellertür an" wird zunächst in die Struktur Gerät=licht, Verb=schalten, Ort=hinter der Kellertür transformiert (das ist die zentrale Aufgabe von der semantischen Analyse).

- Wenn dazu ein Kommando im Babble-Datenhash {DATA}{licht}{hinter der Kellertür}{schalten} vorliegt, wird das ausgeführt. Diese Möglichkeit ist deshalb wichtig, weil damit in der Babble-Weboberfläche von Babble beliebig komplizierte Kommandos definiert werden können, die lokal oder entfernt ausgeführt werden (eben nicht generische Kommandos)

- Wenn nicht, werden die von den auf den entfernten und der lokalen FHEM-Installation vorliegenden Devices mit babbleDeviceType=light durchsucht, ob eines den babblePlace=hinter der Tür hat, und ggf. dieses geschaltet (eben generische Kommandos)
- Wenn auch das nicht weiterführt, wird der Satz an den Chatbot weitergereicht

LG

pah

[JensS]

Na ja. Alle tappen immer noch Dunklen wegen der externen MQTT-Anbindung eines TTS-Service, auch im Rhasspy-Forum wird nur wild geraten

Die Notlaufvariante ist für mich derzeit die Naheliegendste. Das kann man vermutlich in rhasspyserver_hermes/__init__.py ab #537 verorten. Übrigens - wie sieht deine profile.json aus?

Gruß Jens

[Beta-User]

Na ja. Alle tappen immer noch Dunklen wegen der externen MQTT-Anbindung eines TTS-Service, auch im Rhasspy-Forum wird nur wild geraten

Zum einen: Ich hatte geschrieben, dass RHASSPY damit mAn. kein prinzipielles Problem hat, es ging nicht um Rhasspy...

Mein Bauchgefühl meint immer noch, das mit der Verwendung von "default" als "Einheits-siteId" wäre ein Problem, aber ich komme an der Stelle auch nicht zum Testen.

Deine neuen Attribute schaue ich mir bei Gelegenheit an, im svn war dazu nichts zu finden. Spontan finde ich
- die Doppelung zu genericDeviceType fragwürdig
- das mit "babblePlace" bedenkenswert (bisher habe ich sowas über Doppelungen am Device-Namen oder im rhasspyRoom gelöst)
- die Idee, auf "fremden" Instanzen was schalten zu können sehr interessant. (Komme von einem "Einheitssystem", da hat man sowas nicht unbedingt im Fokus. Das läßt sich bis auf weiteres nur dadurch lösen, dass man die betreffenden Devices in die Zielinstanz holt oder eine 2. Rhasspy-Instanz aufsetzt, die dann aber andere/eigene Intents bzw. Satelliten braucht).

[Prof. Dr. Peter Henning]

Ich habe mir noch ein paar weitere Gedanken über ein generisches Modul gemacht. Nennen wir es mal Nlui (NLU Intenthandler).

- Nlui wird mit 5 Parametern aufgerufen:
-- device = zu steuerndes/abzufragendes Gerät. Dabei kann es sich um ein generisches Device handeln (z.B. "Temperatur") oder um ein spezielles Device (z.B. "Depot")
-- place = Ort des Gerätes. Das kann ein Raum sein, muss aber nicht. Man könnte hier hierarchisch arbeiten, z.B. "Wohnzimmer" und "Wohnzimmer:Decke"
-- verb = durchzuführende Handlung, z.B. "stellen/setzen", "öffnen", "schließen", "sagen"
-- target = optionaler Wert, auf den das Gerät zu setzen ist, z.B. "xx Prozent", "yy Grad", bzw. welcher Wert abzufragen ist
-- sink = Gerät für die Weiterverarbeitung des Ergebnisses, auch das könnte wieder zweiteilig sein, z.B. "speak:SoundTouchEG"

Nlui sollte erstens natürlich über eine interne Liste der generischen Devices verfügen. Wobei mir die Frage in den Sinn kommt, ob wir so etwas im Wiki haben, Wenn nicht, sollte dies schnellstmöglich angelegt werden und als Standard für FHEM gelten.

Nlui sollte auch Übersetzungen vornehmen, je nach eingestellter Sprache sollte also

Nlui("Temperatur","Wohnzimmer","sagen","","speak:SoundTouchEG")

Nlui("temperature","Living Room","say","","speak:SoundTouchEG")

dasselbe bewirken.

Die Kombination aus device und verb bestimmt eindeutig das generische Device, z.B.

Nlui("Temperatur","Gästebad","stellen","21 Grad","confirm") => Generisches Gerät ist "thermostat" (Spezialfälle Ofen und Kühlschrank werden damit ebenso abgedeckt). Die Kombination von "thermometer"und "Gästebad" führt bei mir z.B. zum FHEM-Kommando "set GB.HMHz_Clima desired-temp 21". Wichtig ist mir, dass das dieses Kommando ggf. auf einer anderen FHEM-Installation ausgeführt wird. Die Bestätigung erfolgt durch ein kurzes "OK" auf dem Spracheingabesystem (ein Tablet, in der Regel).

Nlui("Temperatur","Außen","sagen","speak:Tab1.EG") ==> Generisches Gerät ist "thermometer". FHEM-Kommando auf der entfernten FHEM-Installation ist "speak('Tab1.EG','Die Temperatur im Außenbereich beträgt '.ReadingsVal('A.OWB.T','temperature',undef).' Grad')". Dazu muss das FHEM-Device A.OWB.T nur über das Attribut genericDeviceType=thermometer und room=Aussenbereich verfügen. Das Matching "Außen" = "Aussenbereich" wird in Nlui vorgenommen (geht bei mir über Reguläre Ausdrücke ODER die Levenshtein-Distanz)

Alle nicht-generischen Geräte können sehr viel kompliziertere Dinge ausführen: Beispiel:

Nlui("Depot","","sagen","Wert","speak:SoundTouchEG") => sprich den Wert des Depots sowie die prozentuale Veränderung zu gestern auf der SoundTouch im Erdgeschoss

Nlui("Haus","","stören","aus","confirm") => schalte das Haus in den Nichtstören-Modus und bestätige dies auf dem Default-Weg

Soweit erstmal meine Anforderungen.

Natürlich könnte es verschiedene Nlui-Module geben. Wenn man sich auf die obigen Parameter einigen könnte, würde man bei jedem sprachverarbeitendem System jeweils nur angeben "RHASSPY", oder "Babble" und würde das entsprechend dann so nutzen. Die Schnittstelle kann von mir aus auch MQTT sein, obwohl ich das nicht für zielführend halte - mindestens ein direkter Unterprogrammaufruf "RHASSPY_Nlui" oder "Babble_Nlui" sollte möglich sein.

LG

pah

[Prof. Dr. Peter Henning]

Sieh an, auch schon wach...

die Doppelung zu genericDeviceType fragwürdig

Das ist nur temporär, siehe den roten Text im vorigen Post.

die Idee, auf "fremden" Instanzen was schalten zu können sehr interessant.

Funktioniert bei Babble schon seit Jahren (Attribute remoteFHEM0...3)

Ist aber in meiner Bastelversion von Babble wesentlich erweitert. Auf dem Zielsystem muss nur

Code Auswählen Erweitern

########################################################################################
#
# 99_BabbleUtils.pm
#
# Collection of various routines for Babble purpose
# Prof. Dr. Peter A. Henning
#
# $Id: 99_BabbleUtils.pm 2022-01- pahenning $
#
########################################################################################
#
#  This programm is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  The GNU General Public License can be found at
#  http://www.gnu.org/copyleft/gpl.html.
#  A copy is found in the textfile GPL.txt and important notices to the license
#  from the author is found in LICENSE.txt distributed with these scripts.
#
#  This script is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
########################################################################################

package main;
use strict;
use warnings;
use POSIX;
use JSON;

sub BabbleUtils_Initialize($$)
{
  my ($hash) = @_;
 
  $data{FWEXT}{"/Babble_devlist"}{FUNC} = "Babble_GatherDevices";
  $data{FWEXT}{"/Babble_devlist"}{FORKABLE} = 0;
}

sub Babble_GatherDevices(){

  my %devlist = ();
 
  foreach my $dev (sort keys %defs) {
    my $name  = $defs{$dev}{NAME};
    my $type  = AttrVal($name,"babbleDeviceType",undef);
    #-- skip if empty babbleDeviceType attribute
    next if( !$type );
    #-- more Babble data
    my $place  = AttrVal($name,"room",undef);
    my $bplace = AttrVal($name,"babblePlace",undef);
    my $bname  = AttrVal($name,"babbleDevice",undef);
   
    $devlist{$dev}->{'type'}=$type;
    $devlist{$dev}->{'place'}=(defined($bplace))?$bplace:$place;
    $devlist{$dev}->{'bname'}=(defined($bname))?$bname:$name;
  }
  my $json = encode_json \%devlist;
  $FW_RETTYPE = "application/json";
  $FW_RET="";                                         
  FW_pO $json;
  return ($FW_RETTYPE, $FW_RET);         
}
1;
als Modul existieren, dann holt Babble sich die Liste der generischen Devcies und legt sie in sein Datenhash.

im svn war dazu nichts zu finden

Stimmt, das ist brandneu.

LG

pah

[Prof. Dr. Peter Henning]

die Doppelung zu genericDeviceType fragwürdig

Noch ein Nachtrag dazu. Es braucht m.E. drei Attribute

- ein genericDeviceType 
- ein NLU-friendly-Devicename ==> nluDevice
- einen NLU-bezogenen Ort ==> nluPlace

LG

pah

Edit: Ich habe hier https://wiki.fhem.de/wiki/Attribut_genericDeviceType#genericDeviceType mit einem solchen Wiki-Eintrag begonnen. ACHTUNG: Das ist noch nicht vollständig, das Ziel ist hier einen Konsens zu finden, der den unterschiedlichen Systemen (von A wie Alexa bis Z wie Rhasspy) als Standard dienen kann. Und ich würde gerne das FHEM-fremde "homebridgemapping" aus dieser Tabelle herauslassen, dass kann jedes der genannten Systeme selbst definieren.

[Beta-User]

Zu den Nlui-Ideen und -Anforderungen:

Meine Thesen:
- Es sollte ein "leading FHEM" (pro Sprache, "Server") geben können,  Nlui sollte einen Client-Modus beherrschen, über den das "leading FHEM" entfernte Konfigurationen abfragen und integrieren kann;
- (otionale) Mehrsprachigkeit ist Pflicht;
- Es braucht pro Sprache eine Nlui-Instanz
- Nlui hat ein "single point of entry" pro Sprache, (wenn der content potentiell für andere Instanzen gedacht sein könnte), es gibt pro Sprache also nur eine Nlui-"Server"-Instanz;
- Der "mach was"-Aufruf hat (in der Regel) mit benannten Parametern zu erfolgen (!)
- Das Gesamtsystem der Nlui-Optionen ist so auszulegen, dass beliebig viele Sprachen und Client-Systeme angebunden werden können, dabei kann FHEM_A für Sprache x "Server" (Zentralinstanz) sein, für FHEM_B aber Client (in einer anderen Sprache);
- Es sollte Optionen geben, im Prinzip beliebige Optionen aus einer Nlui-Instanz direkt auszuführen (ohne "dummy+x"-Geraffel), einschließlich beliebigem Perl-Code;
- interne Gruppen-Strukturen sind Pflicht.

- Nlui wird mit 5 Parametern aufgerufen:

MAn. ist das eine überflüssige Einschränkung. Häufig reichen 2-3 Angaben (aus vielen möglichen), um eine eindeutige Aktion ausführen zu können. Es sollte Aufgabe von Nlui sein, "richtig raten" zu können, was der User letztendlich will. Zu übergeben sind strukturierte Daten, würde "parseParams"-kompatible Schreibweisen vorschlagen, alternativ JSON-encoded. "Raten nach Stellung im Array" ist möglich, aber eine Notlösung. Prototypes für Parameter-Vorgaben gehen gar nicht (!). Die sind in diesem Kontext hier mAn. extrem fehleranfällig, sobald User ins Spiel kommen und damit hantieren sollen.

-- device = zu steuerndes/abzufragendes Gerät. Dabei kann es sich um ein generisches Device handeln (z.B. "Temperatur") oder um ein spezielles Device (z.B. "Depot")

"generische Devices" in diesem Sinne sind mAn. in mehrfacher Hinsicht ein Problem.
- es gibt effektiv keine Eindeutigkeit zwischen gDT und verfügbaren Optionen, v.a. nicht, wenn es um Abfragen geht. MAn. kann man das nur lösen, indem man die "Reading-Namen" normiert (z.B.: gemessene Temperatur ist immer "temperature", Ziel-Temperatur ist immer "desired-temp"). Sonst braucht man "für jeden Scheiß" einen readingsProxy (oder dev_proxy). Man denke an einen Raumthermostat (thermostat) oder einen Shelly/ZWave-Aktor mit externem Temp-Fühler (gDT: switch)
- "Device" in diesem Sinn kann auch eine Gruppe von Devices sein. Der Umweg über (z.B.) structure sollte unnötig sein, Nlui sollte wissen, wie man mit sowas umzugehen hat.

-- place = Ort des Gerätes. Das kann ein Raum sein, muss aber nicht. Man könnte hier hierarchisch arbeiten, z.B. "Wohnzimmer" und "Wohnzimmer:Decke"

Überlegenswert.

-- verb = durchzuführende Handlung, z.B. "stellen/setzen", "öffnen", "schließen", "sagen"

Muss ich mir erst eine Meinung zu bilden. Finde es als alleiniges Kriterium fehleranfällig, es sollte Möglichkeiten geben, Nlui eine klare "Absicht" mitzuteilen, wenn diese bekannt ist.

-- target = optionaler Wert, auf den das Gerät zu setzen ist, z.B. "xx Prozent", "yy Grad", bzw. welcher Wert abzufragen ist

Ja. Kann aber mehrteilig/mehrdeutig sein. Wünschenswert wäre eine Vorverarbeitung außerhalb Nlui und die Übergabe strukturierter Daten (Wert und (ggf.) Einheit getrennt).

-- sink = Gerät für die Weiterverarbeitung des Ergebnisses, auch das könnte wieder zweiteilig sein, z.B. "speak:SoundTouchEG"

agreed. Ist m.E. optional, Nlui kann das per default aus der "Quelle" der Anfrage herleiten. Diese ist (otional, aber erwünscht) zu übergeben.

Nlui sollte erstens natürlich über eine interne Liste der generischen Devices verfügen. Wobei mir die Frage in den Sinn kommt, ob wir so etwas im Wiki haben, Wenn nicht, sollte dies schnellstmöglich angelegt werden und als Standard für FHEM gelten.

a) die heute vorhandene Liste der gDT ist bereits "unendlich" (sensor, ContactSensor, Contact, ...);
b) die Festlegung einer sinnvollen Zahl von "supporteten gDT" wäre wünschenswert, Nlui kann ein "Standardisierungs-mapping" in diese gDT bereitstellen;
c) gDT => Option funktioniert häufig nicht (s.o.). gDT ist daher nur ein Anhaltspunkt, wichtiger sind aus meiner Sicht standardisierte Reading-Namen (bisher: keine konstruktive Resonanz auf meine diesbezügliche Initiative im Developer-Bereich (!)). Aus dem Reading-Namen ergibt sich die Abfrage-Möglichkeit, für setter ist der User zuständig (?).

Nlui sollte auch Übersetzungen vornehmen, je nach eingestellter Sprache sollte also

Nlui("Temperatur","Wohnzimmer","sagen","","speak:SoundTouchEG")

Nlui("temperature","Living Room","say","","speak:SoundTouchEG")

dasselbe bewirken.

Sehe ich skeptisch. Es dürfte kein Problem sein, Nlui eine "Übersetzung" für standardisierte allgemeine Begrifflichkeiten (Temperature=>temperature, sagen=>say, mach=>set) machen zu lassen. Das sollte aber relativ eng begrenzt sein, das Ziel immer Kleinschreibung/englische bzw. numerische Standardisierung (rot=>0).
Was mAn. nicht geht, ist die Übersetzung von "FHEM-Variablen" wie 'wohnzimmer=>"living room"'. Das ist mAn. Aufgabe des Konfigurators, das pro Sprache (je in einer eigenen Nlui-Instanz) festzuzurren.

Daher sehe ich das auch nicht als zwingend bzw. teilweise zu eng an:

Noch ein Nachtrag dazu. Es braucht m.E. drei Attribute

- ein genericDeviceType 
- ein NLU-friendly-Devicename ==> nluDevice
- einen NLU-bezogenen Ort ==> nluPlace

- Dass man (uU. mehrere!) "sprechbare Namen" (pro Sprache!) braucht, ist klar. Ist der Device-Name "unaussprechlich", ist es zwingend...
- Der "sprechbare Ort" kann sich bereits aus "room" ergeben. Das ist daher m.E. nicht zwingend. Wichtiger: ein Device kann sich (gleichzeitig) an mehreren Orten "befinden". Ich will sagen können: "Mach alle Lichter im Erdgeschoss aus"

Die Kombination aus device und verb bestimmt eindeutig das generische Device, z.B.

Nlui("Temperatur","Gästebad","stellen","21 Grad","confirm") => Generisches Gerät ist "thermostat" (Spezialfälle Ofen und Kühlschrank werden damit ebenso abgedeckt). Die Kombination von "thermometer"und "Gästebad" führt bei mir z.B. zum FHEM-Kommando "set GB.HMHz_Clima desired-temp 21".

Provokativ formuliert: Das paßt nur, we man das Beispiel passend wählt...
Was machst du, wenn im Wohnzimmer 2 oder Devices da sind, die "thermostat" sind?
Und wieso soll "mach wärmer" oder "mach leiser" nicht auch ausreichen?

Wichtig ist mir, dass das dieses Kommando ggf. auf einer anderen FHEM-Installation ausgeführt wird. Die Bestätigung erfolgt durch ein kurzes "OK" auf dem Spracheingabesystem (ein Tablet, in der Regel).

Remote-Anbidnung kann ich nachvollziehen, wie, wäre zu diskutieren.
Bestätigungsoptionen sind m.E. auch ein "Muss".

Nlui("Temperatur","Außen","sagen","speak:Tab1.EG") ==> Generisches Gerät ist "thermometer". FHEM-Kommando auf der entfernten FHEM-Installation ist "speak('Tab1.EG','Die Temperatur im Außenbereich beträgt '.ReadingsVal('A.OWB.T','temperature',undef).' Grad')". Dazu muss das FHEM-Device A.OWB.T nur über das Attribut genericDeviceType=thermometer und room=Aussenbereich verfügen. Das Matching "Außen" = "Aussenbereich" wird in Nlui vorgenommen (geht bei mir über Reguläre Ausdrücke ODER die Levenshtein-Distanz)

Das mit der Levenshtein-Distanz wäre was neues, der Rest sollte sich mit obigen allgemeinen Anforderungen abdecken lassen.

Alle nicht-generischen Geräte können sehr viel kompliziertere Dinge ausführen: Beispiel:

Prinzipiell stellt sich dann halt die Frage, wie man "nicht-generische Geräte" allgemein kenntlich macht bzw. der Server-Instanz mitteilen kann, dass/wie beliebiger Perl-Code auf der Remote-Instanz "ausgelöst" werden kann. In diese Richtung geht jedenfalls für Abfragen mein Vorschlag mit dem gDT "info".

Natürlich könnte es verschiedene Nlui-Module geben.

Wenn möglich, würde ich dafür plädieren, ein einziges Nlui-Modul bereitzustellen. Es ist (aus Usersicht) komplex genug, dieses dann jeweils zu konfigurieren, wir brauchen m.E. nicht auch noch mehrere Varianten...

Wenn man sich auf die obigen Parameter einigen könnte, würde man bei jedem sprachverarbeitendem System jeweils nur angeben "RHASSPY", oder "Babble" und würde das entsprechend dann so nutzen.

Wie gesagt: Der zu übergebende Parameter-Satz muss aus meiner Sicht flexibel im Sinne von "einige aus vielen" sein.

Die Schnittstelle kann von mir aus auch MQTT sein, obwohl ich das nicht für zielführend halte - mindestens ein direkter Unterprogrammaufruf "RHASSPY_Nlui" oder "Babble_Nlui" sollte möglich sein.

Ich hänge nicht speziell an MQTT und würde in jedem Fall innerhalb einer FHEM-Installation auch immer den direkten Programmaufruf bevorzugen (aber mit benannten Parametern bzw. der Übergabe eines Hashes!). Die Frage ist eher, wie man strukturierte Daten als Parameter an entfernte FHEM-Instanzen übergibt. Da ist MQTT/JSON für mich halt "easy", bin aber offen für andere Vorschläge.

[OT]
Nicht ernst gemeint, oder:

Code Auswählen Erweitern


package main;
[...]
use POSIX;


[/OT]

[Prof. Dr. Peter Henning]

- Es sollte ein "leading FHEM" (pro Sprache, "Server") geben können,  Nlui sollte einen Client-Modus beherrschen, über den das "leading FHEM" entfernte Konfigurationen abfragen und integrieren kann;

Das halte ich für wenig hilfreich, weil das bedeuten würde, entfernte Nluis auch zu konfigurieren. Das oben beschriebene Verfahren mit einem ganz schlanken Code auf Seite der Slaves, der keine Konfiguration benötigt, halte ich für nutzerfreundlicher

- (otionale) Mehrsprachigkeit ist Pflicht;

Ich bin einer der Wenigen, der in Module so etwas einbaut...

- Es braucht pro Sprache eine Nlui-Instanz

Das folgt schon aus der unterschiedlichen Grammatik

- Der "mach was"-Aufruf hat (in der Regel) mit benannten Parametern zu erfolgen (!)

Das ist zwar Folklore, aber dem werde ich mich nicht entgegenstellen.

- Das Gesamtsystem der Nlui-Optionen ist so auszulegen, dass beliebig viele Sprachen und Client-Systeme angebunden werden können, dabei kann FHEM_A für Sprache x "Server" (Zentralinstanz) sein, für FHEM_B aber Client (in einer anderen Sprache);

- Es sollte Optionen geben, im Prinzip beliebige Optionen aus einer Nlui-Instanz direkt auszuführen (ohne "dummy+x"-Geraffel), einschließlich beliebigem Perl-Code;

OK, Du meinst "Operationen", nehme ich an.

- interne Gruppen-Strukturen sind Pflicht.

Aber wir haben doch Gruppenstrukturen in FHEM - warum das Rad zum zweiten Mal erfinden? Siehe unten.

Zitat von: Prof. Dr. Peter Henning am Heute um 06:18:49
    - Nlui wird mit 5 Parametern aufgerufen:
MAn. ist das eine überflüssige Einschränkung.

OK

"generische Devices" in diesem Sinne sind mAn. in mehrfacher Hinsicht ein Problem.

Nein, wenn man es richtig macht, eben nicht. Schau mal in den (angefangenen) Wiki-Eintrag dazu

a) die heute vorhandene Liste der gDT ist bereits "unendlich" (sensor, ContactSensor, Contact, ...);
b) die Festlegung einer sinnvollen Zahl von "supporteten gDT" wäre wünschenswert, Nlui kann ein "Standardisierungs-mapping" in diese gDT bereitstellen;
c) gDT => Option funktioniert häufig nicht (s.o.). gDT ist daher nur ein Anhaltspunkt, wichtiger sind aus meiner Sicht standardisierte Reading-Namen (bisher: keine konstruktive Resonanz auf meine diesbezügliche Initiative im Developer-Bereich (!)). Aus dem Reading-Namen ergibt sich die Abfrage-Möglichkeit, für setter ist der User zuständig (?).

Habe ich im Developer-Bereich bisher nicht gesehen, muss ich mir ansehen. Ich wäre dafür, die gDT-Liste stark einzuschränken und nur für diese mandatorische Readings/Settings festzulegen

- Dass man (uU. mehrere!) "sprechbare Namen" (pro Sprache!) braucht, ist klar. Ist der Device-Name "unaussprechlich", ist es zwingend...
- Der "sprechbare Ort" kann sich bereits aus "room" ergeben. Das ist daher m.E. nicht zwingend. Wichtiger: ein Device kann sich (gleichzeitig) an mehreren Orten "befinden". Ich will sagen können: "Mach alle Lichter im Erdgeschoss aus"

Klar. Dafür habe ich (auch hierarchische) Structures.
"Schalte das Licht am Esstisch aus" geht direkt auf das Device, "Schalte das Licht im Erdgeschoss aus" geht auf die Structure. Ich halte gar nichts von einer zusätzlichen Gruppenbildung in Nlui, denn diese bräuchte wieder eine komplexe Ausführungslogik (z.B. zeitlicher Versatz von Devices, Propagation von Attributen und Befehlen etc.), die in "structure" schon existiert und das Nlui unnötig komplizieren würde.

Was machst du, wenn im Wohnzimmer 2 oder Devices da sind, die "thermstat" sind?

Wer so etwas macht, ist selbst Schuld. Pro Raum sollte es nur eine Stelle geben, an der man die Temperatur regelt - wenn nicht, muss eben "Wohnzimmer:Ostseite" und "Wohnzimmer: Westseite" unterschieden werden.

Und wieso soll "mach wärmer" oder "mach leiser" nicht auch ausreichen?

"Spiele Musik" mündet bei mir in einen Dialog, um weitere Parameter abzufragen.

Prinzipiell stellt sich dann halt die Frage, wie man "nicht-generische Geräte" allgemein kenntlich macht bzw. der Server-Instanz mitteilen kann, dass/wie beliebiger Perl-Code auf der Remote-Instanz "ausgelöst" werden kann. In diese Richtung geht jedenfalls für Abfragen mein Vorschlag mit dem gDT "info".

Geht in Babble längst im Web-Frontend.

Wenn möglich, würde ich dafür plädieren, ein einziges Nlui-Modul bereitzustellen. Es ist (aus Usersicht) komplex genug, dieses dann jeweils zu konfigurieren, wir brauchen m.E. nicht auch noch mehrere Varianten...

Na ja, Wettbewerb der Systeme. Ich bin immer für die Konfiguration auf der Web-Oberfläche, andere bevorzugen das Editieren einer Datei.

Wie gesagt: Der zu übergebende Parameter-Satz muss aus meiner Sicht flexibel im Sinne von "einige aus vielen" sein.

OK

POSIX

Ach, das ist eine Leiche in meinen leeren Modul-Templates.

LG

pah