AttrTemplate und Sprachassistenten

Begonnen von justme1968, 31 März 2019, 16:23:19

Vorheriges Thema - Nächstes Thema

Beta-User

So, mal ein erster Wurf, wie das ggf. ausehen könnte:

name:mqtt2_speech_recognition_type_switch
filter:TYPE=MQTT2_DEVICE:FILTER=CID=speechrecognTesting
option:{my @devices=devspec2array("TYPE=(siri|alexa)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType switch
option:TYPE=siri
option:TYPE=alexa

name:mqtt2_speech_recognition_type_light
filter:TYPE=MQTT2_DEVICE:FILTER=CID=speechrecognTesting
option:{my @devices=devspec2array("TYPE=(siri|alexa)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType light
option:TYPE=siri
option:TYPE=alexa

name:mqtt2_speech_recognition_type_light_255
filter:TYPE=MQTT2_DEVICE:FILTER=CID=speechrecognTesting
option:{my @devices=devspec2array("TYPE=(siri|alexa)");;return 1 if $devices[0];;return 0}
set DEVICE attrTemplate mqtt2_speech_recognition_type_light
attr DEVICE genericDeviceType light
option:TYPE=siri
option:TYPE=alexa
attr DEVICE homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=255

name:mqtt2_speech_recognition_type_blind
filter:TYPE=MQTT2_DEVICE:FILTER=CID=speechrecognTesting
option:{my @devices=devspec2array("TYPE=(siri|alexa)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType blind
option:TYPE=siri
option:TYPE=alexa

name:mqtt2_speech_recognition_type_thermostate
filter:TYPE=MQTT2_DEVICE:FILTER=CID=speechrecognTesting
option:{my @devices=devspec2array("TYPE=(siri|alexa)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType thermostate
option:TYPE=siri
option:TYPE=alexa

Annahmen waren:
- es ist entweder ein Gerät des Typs Siri und/oder alexa definiert. Das ist allerdings lt. Wiki nur empfohlen?
- alexa und siri "ticken" nicht zwangsläufig gleich (?), daher ist die optionale Unterscheidung mal eingebaut.

Diese attrTemplate würden dann aus den "normalen" heraus aufgerufen (wenn mehrere Kanäle vorhanden sind und das nicht sowieso mitkopiert würde jeweils dann für die einzelnen Kanäle), wären aber auch separat per Kommandozeile ausführbar, wenn man weiß, nach was man sucht; daher habe ich erst mal auch keine Beschreibungen usw. eingefügt.

(v.a.) @justme1968: Paßt das soweit, dass man das mal allg. in dem MQTT2-Thread zur Diskussion stellen kann?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

alexa und siri sind meiner meinung voraussetzung für alle weiteren automatismen. wer das nicht möchte muss jetzt schon alles mögliche von hand machen und kann dann halt auch keine templates verwenden. gleiches gilt für gassistant. letzteren kannst du eigentlich auch gleich mit aufnehmen.

die idee ist das die sprachassistenen für solch eine einfache konfiguration alle gleich arbeiten und das gleiche homebridgeMapping verendet werden kann. aber die unterscheidung schon mal vorzusehen schadet nichts.

von mir aus schaut das so weit gut aus. ich denke ihr solltet es einfach mal testen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

 :) OK, "Test" läuft, wird schon schiefgehen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

@justme1968:

Kannst du in diesen Thread bitte mal reinsehen (und "zum Auffrischen" in den dort von TomLee verlinkten)?
Habe auf den Hinweis dann das homebridgeMapping für den "255-er" noch vor dem heutigen update-Durchlauf "auf Verdacht" ergänzt um
attr DEVICE homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,factor=2.55

Insgesamt sind die Aussagen in dem "alten" Thread irgendwie mAn. inkonsistent, am Ende sollten wir halt sowas wie eine "best practice" in dem template drin haben, und da ist Raten nicht so zielführend...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

ich glaube du hast einen falschen thread verlinkt. schau bitte noch mal.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Mist, gemeint war der hier: https://forum.fhem.de/index.php/topic,108080.msg1020640.html#msg1020640

Im Kern beschränkt sich die Frage zwischenzeitlich darauf, ob es (nur bei alexa?) für brightness-255-Geräte ein userReading braucht, das brightness-0-255 (bzw. 254) auf eine 0-100%-Skala mappt. "factor=2.55) scheint nicht zu funktionieren (oder muß das hier dann der Kehrwert sein? Oder nur in eine Richtung wirksam => ähnliches Mapping mit Hashes wie bei eventMap?)...

(Habe auch versucht, die diversen Dokus zu homebridge, alexa usw. mal querzulesen, aber das ist ziemlich verwirrend, wenn man das nicht selbst im Einsatz hat.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

das reading wird mit factor multipliziert um auf dem internen wert zu kommen und der interne wert wird durch  factor geteilt um auf den fhem wert zu kommen. es muss also 0.39216 angegeben werden.

ich kann aber gerade nicht sagen ob es bei alexa (schon) eingebaut ist oder aktuell nur bei homekit/siri geht.

wenn man alexa-fhem mit -D startet (in alexaFHEM-params eintragen) sieht man im log genau was wie konvertiert wird.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Danke für die Rückmeldung, das scheint zu passen, allerdings wohl (auf die Schnelle) nicht mit homekit/siri (siehe die Rückmeldungen von TomLee).

Zur generellen Marschrichtung:
Eigentlich sind diese templates nicht MQTT2-Device-spezifisch. Sobald wir "ein paar" wirklich funktionierende haben (neben den bestehenden noch ein blind-inverted und evtl. color_temp), könnte man die praktisch für alle Device-Typen verwenden, die AttrTemplate "können" (also idR. via setExtensions unterstützen).

Damit könnte man die für die nachträgliche Ergänzung von Devices von user-Seite her genauso verwenden (Doku...?) wie für interne Aufrufe von beliebigen anderen attrTemplates aus (ggf. unter Übergabe von Wertebereichen oder Readingnamen?).

Wenn dem so wäre, würde ich die tendenziell in eine separate file auslagern, den Device-TYPE im Filter rausnehmen und statt auf die CID auf den Namen gehen (also diesen Teil weiter verstecken).

Meinungen? Übersehe ich mal wieder was wichtiges?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

es gibt hier: https://forum.fhem.de/index.php/topic,108455.0.html eine alexa-fhem test version mit der unter anderm minValue, maxValue und factor ausgewertet wird. damit sollten die templates jetzt tatsächlich für alexa und siri gleich funktionieren.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Danke für den update.

Dann warten wir mal, bis das soweit offiziell wird, oder? Gibt es irgendwas, was ich einstweilen tun oder vorbereiten könnte?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Beta-User am 06 Februar 2020, 10:24:38
Zur generellen Marschrichtung [...]
Gibt's dazu was neues oder Meinungen?

Sonst würde ich das in der geschilderten Richtung mal bei Gelegenheit vorbereiten.

Daneben hätte ich noch eine Frage wegen "alexaProactiveEvents": Das kann der user ja pro Device setzen, wenn er die Testversion von alexa-fhem im Einsatz hat. Wenn das ganze dann aus dem Teststadium rausgewachsen ist wäre das so eine Sache, bei der m.E. eine aktive Anfrage an den user Sinn machen würde: lokal setzen (ja/nein) oder gar nicht setzen (globale Vorgabe beachten).
(2. Frage:) Aus user-Sicht am einfachsten wäre das mAn. am elegantesteten, wenn ihm eine Auswahl angeboten bekäme, aus der er genau eine Option auswählen kann, und wenn er die Option auch nur dann wählen kann, wenn er bestimmte Voraussetzungen erfüllt. (@Rudi) Das gibt AttrTemplate derzeit nicht her, oder übersehe ich was? Mit par: sollten sich zwar ohne weiteres Abfragen realisieren lassen, aber dann als Freitexteingabe (=fehleranfällig), und wann ggf. par:-Anfragen aufgelöst werden, müßte ich mal nachsehen bzw. austesten (ist uU. auch nicht ganz einfach, wenn das so verschachtelt aufgerufen wird; bricht hier der user irgendwann zwischendurch ab, wird es uU. konfus).
Mal angenommen, das macht überhaupt Sinn: Wäre das viel Aufwand, sowas einzubauen, mit dem man eine zwingende Wahl aus verschiedenen Optionen anbietet?
(Das könnte dann auch genutzt werden, um z.B. die Abfrage des konkreten Alarm-Typs erst auf der Ebene festzulegen, was die Zahl der erforderlichen templates ggf. verringern könnte (obwohl der user vermutlich nicht versteht, warum er gefragt wird, ob es ein waterAlarm ist, wenn er einen Wasser-Sensor per attrTemplate konfiguriert).).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

justme1968

zu 2.: das ist inzwischen offiziell über die normalen updates (alexa-fhem und alexa modul) erhältlich.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

ZitatAus user-Sicht am einfachsten wäre das mAn. am elegantesteten, wenn ihm eine Auswahl angeboten bekäme, aus der er genau eine Option auswählen kann, und wenn er die Option auch nur dann wählen kann, wenn er bestimmte Voraussetzungen erfüllt. (@Rudi)
Ich habe AttrTemplates modifiziert:

- FHEMWEB Dialog umgebaut: jedes fehlende Parameter kann/muss in separaten Input-Feld eingegeben werden.

- falls ein Parametername mit RADIO_ anfaengt, dann wird sie als HTML radio input angezeigt.

- ungeloest: falls nur ein RADIO_ auswaehlbar ist, dann wird sie trotzdem angezeigt, und der Benutzer muss aus einem Element auswaehlen.

- Bug entdeckt: falls bei zwei Parametern der erste per Code gesetzt werden kann, dann wird beim set der Wert nicht fuer den Zweiten, sondern fuer den Ersten uebernommen.
=> Neuen Syntax eingefuehrt: set X attrTemplate templateName PARNAME=VALUE ...
Die alte Syntax bleibt erhalten, damit sollte man aber alle Parameter spezifizieren.

Das Template fuer den Screenshot schaut so aus:name:dummyTest-radio
filter:TYPE=dummy
desc:Radio test, with conditions
par:SUFFIX1;Suffix1-Text
par:SUFFIX2;Suffix2-Text
par:RADIO_TELNET;For telnets;{ devspec2array("TYPE=telnet") ? undef : 0}
par:RADIO_FHEMWEB;For FHEMWEBs;{ devspec2array("TYPE=FHEMWEB") ? undef : 0}
option:{ RADIO_TELNET }
attr DEVICE comment For telnet SUFFIX1 SUFFIX2
option:{ RADIO_FHEMWEB }
attr DEVICE comment For fhemweb SUFFIX1 SUFFIX2

Beta-User

Sehr cool! - V.a. auch was die über die "Radio" hinausgehenden Anpassungen angeht; das löst viele Probleme, v.a. vermutlich auch beim Verständnis der user, wenn dann doch mal eine Rückfrage von attrTemplate kommt (meistens geht es ja ohne...).
Für interne Zwecke dürfte der parametrierte Aufruf sehr hilfreich sein!

::) Mir ist gleich wie der die Phantasie (in Richtung Einrichtungsassistent) durchgegangen, aber jetzt muß ich erst mal sehen, wie diese Dinge am besten umzusetzen sind! Wird etwas dauern...

zu dem "Radio": Gedacht hatte ich das etwas anders, nämlich als Wahl einer Option, von der man nicht ohne weiteres vorhersehen kann, wie der user sich entscheidet und ob er es überhaupt haben will; muß vermutlich noch etwas darüber nachdenken, ob bzw. wie das mit der jetzigen Lösung umsetzbar, ist (vermute ja, aber etwas umständlich, und man kann auch nicht ohne weiteres mehrere Auswahl-Gruppen anzeigen, sondern müßte das auf mehrere Unter-templates verteilen).
Wenn es bei internen vorherigen Abfragen Ergebnisse gibt, wäre es noch eine weiteres Gimmik, wenn man das dann dort auch ganz deaktivieren könnte? (In Richtung Einrichtungsassistent: Dazu würde man - auf die Schnelle weitergedacht - noch benötigen "Aktiviere (z.B.) Telnet: ja/nein => wenn ja: Port? =>default 7072 vorgeben (Radio?) oder freie Eingabe).(Dto. z.B. für MQTT2_SERVER)).

(sind aber erst mal nur kurze Eindrücke, muß das erst praktisch weiter austesten und "hirnen", habe das nur kurz testweise überflogen).

Zum eigentlichen Thema des Threads:
Ihr habt bestimmt gesehen, dass die speech-recogn.-Dinge zwischenzeitlich erst mal kommentarlos in eine separate file gewandert sind. Wenn es nicht zeitnah Rückmeldungen gibt, dass dabei was kaputt gegangen ist, werde ich dann nach den Anpassungen auf das neue RADIO-feature@mqtt2 (und evtl. mysensors) auch mal zap und shojo dazu kontakten; zumindest die Basisdinge sollten damit ja dann stressfrei einzurichten sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So, jetzt habe ich mal die speechrecogn-file erweitert, allerdings ohne das groß testen zu können.

Was ich verstanden habe: Sensoren benötigen für alexa (nur dafür, oder?) entweder ein globales setting (ein Attribut-Wert am alexa-Device), oder lokale Attributwerte. Durch die jetzige RADIO-Struktur sollte diese Wahl abgebildet sein, was ich allerdings zur Vermeidung einer weiteren Fehlerquelle erst mal noch nicht eingebaut habe, wäre eine devspec2array-Abfrage zur Ermittlung des Devices bzw. Reading-Werts.

Dann brauchen die diversen Sensoren wohl ziemlich unterschiedliche mappings. Bin noch unschlüssig, was da am Ende die einfachste/am wenigsten fehleranfällige ist - mehr templates mit wenigen weiteren Angaben oder ein template, dem man dann "genericDeviceType" und "homebridgeMapping" (in toto) übergibt. Im Moment vermute ich, dass letzteres das einfachste ist, sonst braucht man zu viele par-Anweisungen.

Meine Bitte wäre, dass jemand mal testet, ob das so klappt mit der Übergabe auch der komplexeren Parametrierung, Syntax ist bei beiden "sensor"-templates in der desc?
(Klar könnte ich das sonst mit einem Testszenarium nachstellen, aber das müßte ich extra dafür bauen, und wollte eh' fragen, ob euch das ansonsten sinnvoll vorkommt... Falls jemand mitliest und testet, der hier nicht schreiben darf: Rückmeldung auch gerne im "Anregungen"-Thread zu mqtt2 bzw. dem "IKEA-Leuchte&Sprache"-Thread)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files