Autor Thema: AttrTemplate und Sprachassistenten  (Gelesen 2933 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9289
  • eigentlich eher "user" wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #30 am: 29 Januar 2020, 13:29:31 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20002
Antw:AttrTemplate und Sprachassistenten
« Antwort #31 am: 30 Januar 2020, 19:18:58 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9289
  • eigentlich eher "user" wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #32 am: 03 Februar 2020, 16:39:48 »
 :) OK, "Test" läuft, wird schon schiefgehen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9289
  • eigentlich eher "user" wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #33 am: 04 Februar 2020, 10:17:10 »
@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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20002
Antw:AttrTemplate und Sprachassistenten
« Antwort #34 am: 05 Februar 2020, 17:28:49 »
ich glaube du hast einen falschen thread verlinkt. schau bitte noch mal.

FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9289
  • eigentlich eher "user" wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #35 am: 06 Februar 2020, 08:24:24 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20002
Antw:AttrTemplate und Sprachassistenten
« Antwort #36 am: 06 Februar 2020, 08:44:02 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9289
  • eigentlich eher "user" wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #37 am: 06 Februar 2020, 10:24:38 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 20002
Antw:AttrTemplate und Sprachassistenten
« Antwort #38 am: 15 Februar 2020, 18:47:33 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9289
  • eigentlich eher "user" wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #39 am: 17 Februar 2020, 12:47:10 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9289
  • eigentlich eher "user" wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #40 am: Gestern um 12:01:00 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

 

decade-submarginal