AttrTemplate und Sprachassistenten

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

Vorheriges Thema - Nächstes Thema

justme1968

ich mache mal diesen thread auf um zu besprechen wie wir AttrTemplate nutzen können um die konfiguration einzelner devices für die sprachassistenten insbesondere über homebridgeMapping zu vereinfachen.


bis jetzt gibt es hier die folgenden offenen punkte:

  • bestimmte templates nur anbieten wenn es das siri, alexa oder gassistant device gibt
    über neuen parameter im template z.b. prereq:. mit devspec -> wenn match wird das template zur auswahl angeboten. frage: auch perl code erlauben? {...} -> wenn true wird das template angeboten
  • wie komplex können/sollen die templates sein?
    können wir den folgenden anwendungsfall abdecken: ein device soll als schalter in die sprachsteuerung eingebunden werden, hat aber keine on und off kommandos sondern irgendetwas anderes. das template wird ausgewählt -> ein popup erscheint und fragt welches kommandos für 'schalte <name> ein'  für 'schalte <name> aus' verwendet werden sollen. name wird automatisch mit dem device namen gefüllt, die kommandos lassen sich über ein drop down aus den set kommandos auswählen.
  • neues globales attribut z.b. disableFeatures um AttrTemplate und eventuell andere dinge über eine zentrale stelle zu deaktivieren. @betateilchen: passt das so für dich?

welche wünsche gibt es noch ?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

justme1968

#1
erste ergänzung:

- in einem ersten schritt würde ich dir templates für alle devices sehen die sich nicht eindeutig automatisch behandeln lassen. also mqtt und dummys. als eine art ersatz für im wiki und forum dokumentierten homebridgeMapping die sich durch klick und eventuell ausfüllen auswählen lassen statt copy&paste.

- wenn sich das ganze bewährt kann ich mir vorstellen das auch die bisher automatisch erzeugten homebridgeMaping für häufige standard devices in templates abgelegt werden. diese sollten aber auf irgendeine art automatisch angewendet werden sobald ein device definiert wird das auf den filter passt und dessen vorbedingung erfüllt ist.

mit letzterem hätten wir dann auch einen generellen und flexiblen weg das setzen von attributen für neue devices aus dem modul code zu vermeiden.

module könnten dann auch passende default templates mit liefern. wenn wie zusätzlich noch an einer zweiten user stelle suchen würden können anwender diese templates auch modifizieren ohne das sie beim update überschrieben werden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Beta-User

Moin,

ich klinke mich mal - tendenziell eher lesend - hier ein, da es im ersten Schritt v.a. um MQTT2-templates zu gehen scheint. Erfahrung mit Sprachsteuerung ist aber 0.

(Meinung...):
Für mich wäre in dem Zusammenhang die erste Frage, ob es Sinn macht, das in ein (komplett) separate templates auszulagern, oder ob es nicht (aus Anwendersicht) geschickter wäre, das gleich "mitzuerledigen". Da wir bisher keine Möglichkeit hatten, zu unterscheiden, ob bzw. was in die Richtung Sprachsteuerung möglich war, sind die vorhandenen templates sprachsteuerungslos.

Im "Ausgangstemplate" wissen wir in der Regel, um was für eine Art Gerät es sich handelt (einfacher on/off-Aktor, Dimmer, Farbig...). Wäre es da nicht besser, quasi eine Art Optionenliste im Sinne einer Vorabprüfung einzubauen? Also zunächst abzufragen, ob bestimmte Optionen zur Verfügung stehen (also z.B. eine bestimmte Sprachsteuerung aktiv ist). Ins Unreine evtl. so:
option:OPTION1;{z.B. Perl-Code zur Prüfung, ob homekit aktiv ist mit boolscher Rückgabe}
Im weiteren Verlauf dann:
?OPTION1:set DEVICE attrTemplate xyz_Template_fuer_homekit_dimmer
In diesem Template könnte man dann das Raumatribut bei Bedarf erweitern uä...

Sowas verhindert natürlich nicht, dass jemand das xyz-template anwendet, obwohl homekit nicht installiert ist, aber im Zweifel versucht er damit ja nur, Attribute zusetzen, die es nicht gibt. Wäre nicht dramatisch.
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

dir idee ist gut. ich denke aber wir brauchen dann beides.

wenn es um mqtt geht würde das passen wenn es zum zeitpunkt des device anlegen schon den sprachasistenten gibt.

es passt aber nicht wenn der sprachassistent erst später angelegt wird, wenn ein weiterer dazu kommt und die config leicht unterschiedlich ist oder wenn es um ein normales device geht dem nachträglich ein komplexes mapping hinzugefügt werden soll oder allgemein wenn nachträglich nur ein einzelnes attribut gesetzt werden soll.

ich mache nachher noch mal eine aufstellung der einzelnen fälle und abläufe wie ich es mir vorstelle.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

betateilchen

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

  • neues globales attribut z.b. disableFeatures um AttrTemplate und eventuell andere dinge über eine zentrale stelle zu deaktivieren. @betateilchen: passt das so für dich?

ja, passt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Ist klar, dass man dann schon sowas wie ein bzw. mehrere komplexe tempates benötigt, um die unterschiedlichen Fälle abzudecken.

Mein Vorschlag ruft ja im Prinzip auch nur ein anderes template auf, das genauso auch separat funktionieren muß, nur eben beschränkt auf den Fall, dass es tatsächlich was nützt (und nicht Fehlermeldungen produziert). Da man attrTemplate auch später bzw. wiederholt ausführen kann, wäre auch der nachträglich wiederholte Aufruf nicht das große Problem, allerdings halt immer verbunden mit dem Risiko, dass eigene Einstellungen dann ggf. weg sind (eine Aufteilung in "Teil-templates" macht daher m.E. Sinn; z.B. die mqtt2-tasmota-templates sind übrigens heute bereits auch in der Weise "verschachtelt").

Was mir nicht ganz klar ist bzw. recht neu:
- Rudi hat neulich die filter-Funktion aufgebohrt, so dass man jetzt beliebige Abfragen auf das Device machen kann und nicht auf TYPE beschränkt ist. Wenn eine Sprachsteuerung userattr hinzufügt, müßte das via FILTER abfragbar sein, oder?
- attrTemplate setzt voraus, dass der jeweilige Devicetyp das unterstützt (also im Prinzip die setExtensions vorhanden sind). Ob das bei allen in Frage kommenden Zielgeräten der Fall ist?
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

Loredo

Schön wäre auch, wenn die extrem komplizierten HMCCU Templates dann endlich mal so definiert würden, dass sie auch Praxis tauglich sind.


Auch wäre es generell dann auch hilfreich, wenn der Benutzer eine Info bekommen würde, wenn normalerweise für das Modul Templates verwendet würden, für ein bestimmtes Subtype jedoch noch kein Template vorliegt (z.B. weil zu neu). Dann gibt es keine Verwirrung mehr und es ist sofort klar, dass einfach nur ein Template fehlt, der Template Support aber generell vorhanden ist.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

#7
Implementiert und eingecheckt:

- fhem.pl und FHEM/AttrTemplate.pm: "attr global disableFeatures attrTemplate"

- prereq:XXX
  Fals XXX den Form {.*} hat, wird sie mit AnalyzePerlCommand evaluiert, und muss 1 zurueckliefern, sonst ist XXX ein devspec, und muss ein Geraet finden.
  Falls mindestens ein prereq existiert, was nicht zutrifft, wird das betroffene Template aus dem Speicher entfernt.
  Die Auswertung erfolgt beim FHEM Start oder bei {AttrTemplate_Initialize()}, da devspec bei grossen Installationen fuer die Bestimmung der moeglichen Befehle zu teuer ist.

- option:XXX 
  Fuer die XXX Spec siehe prereq
  Die Auswertung erfolgt (im Unterschied zu prereq) beim Ausfuehren des attrTemplate Befehls, da devspec in diesem Fall nicht so teuer ist
  Die auf option: folgende Template-Befehle werden nur dann ausgefuehrt, falls die Bedingung wahr ist.
  Es koennen beliebig viele option: Zeilen pro Template vorhanden sein, die Letzte ersetzt(!) die Vorherige (also keine Verschachtelung).
  option wieder "ausschalten" kann man mit option:{1} oder option:global


Zitatkönnen wir den folgenden anwendungsfall abdecken: ein device soll als schalter in die sprachsteuerung eingebunden werden, hat aber keine on und off kommandos sondern irgendetwas anderes. das template wird ausgewählt -> ein popup erscheint und fragt welches kommandos für 'schalte <name> ein'  für 'schalte <name> aus' verwendet werden sollen. name wird automatisch mit dem device namen gefüllt, die kommandos lassen sich über ein drop down aus den set kommandos auswählen
Ja, bis auf "die kommandos lassen sich über ein drop down aus den set kommandos auswählen", die kommandos muss man noch eintippen.

ZitatWenn eine Sprachsteuerung userattr hinzufügt, müßte das via FILTER abfragbar sein, oder?
Im Prinzip ja, aber auf die "Setzbarkeit" (und nicht das Vorhandensein) eines Attributes zu pruefen ist nur was fuer Leidensfaehige (mit der devspec eval Option).

ZitatAuch wäre es generell dann auch hilfreich, wenn der Benutzer eine Info bekommen würde, wenn normalerweise für das Modul Templates verwendet würden, für ein bestimmtes Subtype jedoch noch kein Template vorliegt
Das geht jetzt mit option:, auch wenn nicht wirklich Template-Maintainer freundlich, da er in der Bedingung alle vorhandenen subtypes aufzaehlen und dann negieren muss.
Habe noch keine Idee, wie man das sonst elegant loesen koennte.

Beta-User

 :)
@Rudi: Klingt mal wieder spannend, was du da wieder gezaubert hast; bin mal gespannt, wann ich da was von gebrauchen werde...

@Loredo: Die Anmerkungen verstehe ich nicht so ganz. Hier geht es ausweislich des Thread-Titels um attrTemplate-templates, die "leben" bisher nur bei MQTT2_DEVICE und HTTPMOD. Oder habe ich was falsch verstanden?

@justme1968: Laß mich wissen, wenn ich in die beiden files (bzw. demnächst auch mysensors.template) irgendwas spezielles einbauen soll.
Wie wäre der optimale Ablauf (ausgehend von mqtt2.template) :
- Immer ein spezielles Sprachsteuerungstemplate "auf Verdacht" aufrufen, was ggf. Fehler produziert, wenn keine Sprachsteuerung vorhanden ist, oder
- option nutzen, um das vorab zu prüfen (ist vermutlich "sicherer"). Dabei ggf. die spezifischen Readings für bestimmte Schaltaktionen übergeben (z.B. was ist das Dimmer-Reading)?

Es wäre vermutlich zielführend, wenn dabei alle konfigurierbaren Sprachsteuerungen innerhalb eines templates geprüft würden bzw. die zugehörigen Attribute gesetzt, was jeweils (nur) erforderlich ist, müßte via option abprüfbar sein.

Was mir noch nicht ganz klar ist: Wird bei Aufruf eines option-templates aus einem anderen heraus irgendein option-setting zurück übergeben bzw. bleibt das beim weiteren Abarbeiten auf der aufrufenden Ebene erhalten, wenn im aufgerufenen zuletzt auf "falsch" gesetzt war?
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

rudolfkoenig

ZitatWird bei Aufruf eines option-templates aus einem anderen heraus irgendein option-setting zurück übergeben bzw. bleibt das beim weiteren Abarbeiten auf der aufrufenden Ebene erhalten, wenn im aufgerufenen zuletzt auf "falsch" gesetzt war?

Mir ist zwar etwas unwohl beim Aufruf von "set attrTemplate" aus einem template heraus, aber: option: wird nicht vererbt, es ist template "lokal".

Ich sehe gerade, dass du diesen rekursiven Aufruf in mqtt2.template extensiv verwendest.
Achtung:
- ich habe kein L_01_zigbee2mqtt_bridge_0x template gefunden, nur dessen Aufruf.
- der Aufruf von "set DEVICE attrTemplate A_01d_tasmota_ir" im Template A_01d_tasmota_ir fuehrt ziemlich sicher zum FHEM Absturz (endlos-rekursion).

Beta-User

Zitat von: rudolfkoenig am 02 April 2019, 13:08:40
Mir ist zwar etwas unwohl beim Aufruf von "set attrTemplate" aus einem template heraus, aber: option: wird nicht vererbt, es ist template "lokal".
Ich sehe gerade, dass du diesen rekursiven Aufruf in mqtt2.template extensiv verwendest.
Hmm, mir war zunächst auch nicht ganz wohl, aber bei der wachsenden Zahl der tasmota-templates war es schlicht anders so unübersichtlich, dass ich das dort als das kleinere Übel angesehen hatte, zumal wir am Anfang recht viele Änderungen hatten. Die immer an 5+ Stellen nachzupflegen, war ganz schön fehleranfällig...

Für den Aufruf "füge die für die Sprachsteuerung als Dimmer notwendigen Attribute hinzu" finde ich auch keine sooo negative Sache, das würde ja wieder für eine ganze Anzahl von templates ohne weiteres passen und dann schwer zu pflegende Doppelungen verhindern.

Zitat
Achtung:
- ich habe kein L_01_zigbee2mqtt_bridge_0x template gefunden, nur dessen Aufruf.
- der Aufruf von "set DEVICE attrTemplate A_01d_tasmota_ir" im Template A_01d_tasmota_ir fuehrt ziemlich sicher zum FHEM Absturz (endlos-rekursion).
Danke für die Hinweise, fixe ich zum nächsten update.
Zeigt halt die Kehrseite dieser recht offenen Methode...
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

Loredo

Zitat von: Beta-User am 02 April 2019, 12:45:52
@Loredo: Die Anmerkungen verstehe ich nicht so ganz. Hier geht es ausweislich des Thread-Titels um attrTemplate-templates, die "leben" bisher nur bei MQTT2_DEVICE und HTTPMOD. Oder habe ich was falsch verstanden?


Naja, André fragte ja nach Wünschen und ich wünsche mir, dass HMCCU beispielsweise umschwenkt ;-)
Ich hatte die leise Hoffnung, dass zap das hier lesen würde und sagen könnte, was ihm ggf. noch dafür fehlen würde (oder nicht). War nur aus dem "wenn schon gerade über Anforderungen gesprochen wird, dann mal noch abklopfen, was noch fehlen würde" heraus.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

ZitatWar nur aus dem "wenn schon gerade über Anforderungen gesprochen wird, dann mal noch abklopfen, was noch fehlen würde" heraus.
Habe ich auch so interpretiert, und wenn es "sinnvoll" machbar ist, dann werde ich Anforderungen implementieren.

Beta-User

Für den Fall, dass jemand an dieser Template-Sache arbeiten sollte (oder sonst seien Meinung kundtun):

Jüngst kam das Thema auf, dass einige (im Rahmen der MQTT2-templates) gerne wollten, dass sie ihre Leuchten "ohne Effekt" voreinstellen wollten, also ohne gleich anzuschalten, mindestens ein anderer wollte das allerdings anders haben (also den on-Befehl gleich mit absetzen) und wieder andere wollten beim Abschalten abdimmen (letzteres ist m.E. ein Spezialthema @ MiLight, wollte das nur erwähnen). In allen Fällen lies sich das technisch durch eine entsprechende Ergänzung bei den JSON-Blobs machen. 

Für die zweite Gruppe war das Thema homebridge im Hintergrund maßgebend.
(Details in dem shelly+MiLight-Threads, bei Bedarf gibt's auch Links dahin.)

Gelöst ist das ganze jetzt dadurch, dass  beides in der setList angeboten wird, aber eben mit dem Zusatz, wenn es auch "on" schalten soll, also z.B. "brightness_on", oder "rgb_on".

Damit kann zumindest der eine homebridge-User über ein entsprechendes mapping sein Zeug auch anschalten, wenn er eine Farbe ausruft.

Meine eigentliche Frage: Das ist jetzt "aus dem Bauch heraus" so entstanden, was die Namensgebung der setter angeht, und ich werde versuchen, das einigermaßen einheitlich zu machen.
Wenn jemand da aber bessere Ideen hat, um das für die Zukunft unter dem Gesichtspunkt späterer Berücksichtigung bei der Sprachsteuerung anders haben will: (zeitnahe) Vorschläge und Argumente wären willkommen...
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 problem dabei ist: wenn die kommandos nicht wie die readings heissen werden die zugehörigen widgets nicht mehr initialisiert. d.h. z.b. slider und drop downs zeigen nicht den aktuellen wert.

unabhängig davon: nicht alle sprachassistenden unterstützen eine solche unterscheidung überhaupt. homekit sendet z.b. immer automatisch noch ein on extra und es muss auf homebridge plugin seite abgefangen werden. auch unterstützen das nicht alle geräte. hue ignoriert glaube ich das setzen von werten bei ausgeschalteten lampen. zumindest in manchen firmware versionen.

alternativer vorschlag: ich glaube eine solche unterscheidung der kommandos ist gar nicht im frontend nötig (da man das interaktiv vermutlich sehr sehr selten nutzt: wenn ich auf einen knopf klicke oder das kommando gebe will ich ja das etwas passiert), sondern eher für bestimmte programmierte abläufe im hintergrund.


bei hue gibt es schon immer die möglichkeit mehrere kommandos auf einen schlag abzusetzen. dazu werden sie in einem einzigen set mit : getrennt. also z.b: set <name> hue 100 : sat 50 oder set <name> on : transitiontime 100. das lässt sich beliebig kombinieren. alle gesetzten parameter werden dann in einem einzigen aufruf an die bridge gesendet.

damit könnte man dann auch das setzen eines parameters mit einem explizit ein- bzw. aus schalten/lassen kombinieren wenn man den default nicht möchte (und wenn das device das unterstützt): set <name> rgb ff0088 : on bzw. set <name> rgb ff0088 : off oder set <name> color 3200 : off


ps: ja, man muss dazu in den modulen etwas anpassen. das muss man aber sowieso da ja immer alles auf einen schlag an das gerät geschickt werden muss. sonst gibt es unerwünschte zwischenzusände und es flackert.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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