Autor Thema: AttrTemplate und Sprachassistenten  (Gelesen 1208 mal)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19340
AttrTemplate und Sprachassistenten
« am: 31 März 2019, 16:23:19 »
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 ?
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
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19340
AttrTemplate und Sprachassistenten
« Antwort #1 am: 31 März 2019, 22:03:48 »
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.
« Letzte Änderung: 31 März 2019, 22:08:17 von justme1968 »
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: 7591
  • eigentlich eher user wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #2 am: 01 April 2019, 10:03:09 »
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_dimmerIn 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-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
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19340
Antw:AttrTemplate und Sprachassistenten
« Antwort #3 am: 01 April 2019, 10:11:44 »
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.
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 betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16063
  • s/fhem\.cfg/configDB/g
Antw:AttrTemplate und Sprachassistenten
« Antwort #4 am: 01 April 2019, 10:29:54 »
  • 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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg Stammtisch am 20.09.2019

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7591
  • eigentlich eher user wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #5 am: 01 April 2019, 10:30:37 »
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-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
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3649
  • ~ Challenging Innovation ~
Antw:AttrTemplate und Sprachassistenten
« Antwort #6 am: 01 April 2019, 10:50:40 »
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20886
Antw:AttrTemplate und Sprachassistenten
« Antwort #7 am: 01 April 2019, 19:19:32 »
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


Zitat
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
Ja, bis auf "die kommandos lassen sich über ein drop down aus den set kommandos auswählen", die kommandos muss man noch eintippen.

Zitat
Wenn 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).

Zitat
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
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.
« Letzte Änderung: 01 April 2019, 19:25:44 von rudolfkoenig »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7591
  • eigentlich eher user wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #8 am: 02 April 2019, 12:45:52 »
 :)
@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-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
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20886
Antw:AttrTemplate und Sprachassistenten
« Antwort #9 am: 02 April 2019, 13:08:40 »
Zitat
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?

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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7591
  • eigentlich eher user wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #10 am: 02 April 2019, 13:43:13 »
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-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
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3649
  • ~ Challenging Innovation ~
Antw:AttrTemplate und Sprachassistenten
« Antwort #11 am: 02 April 2019, 14:03:02 »
@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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20886
Antw:AttrTemplate und Sprachassistenten
« Antwort #12 am: 02 April 2019, 16:44:03 »
Zitat
War 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.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7591
  • eigentlich eher user wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #13 am: 25 Juni 2019, 19:17:04 »
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-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
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19340
Antw:AttrTemplate und Sprachassistenten
« Antwort #14 am: 25 Juni 2019, 19:36:24 »
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.
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: 7591
  • eigentlich eher user wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #15 am: 26 Juni 2019, 07:53:24 »
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.
Na ja, bei diesen MQTT-Clients ist das (imo derzeit) kein so großes Problem: Die melden nämlich bislang alle zurück, wenn ein Schaltvorgang erfolgt ist (zigbee2mqtt, vermutlich auch tasmota) bzw. der Funkbefehl abgesetzt wurde (sidoh-Bridge, vermutlich tasmota-RF-Bridge).

Und wenn man den setter in FHEMWEB anzeigt, bleibt der auch schön auf dem gesetzten Wert (den "Rückkanal" könnte man notfalls auch zusätzlich in die readingList eintragen).

Was unschön bleibt, ist der Umstand, dass man - je nach Typ - eine ganze Anzahl von Readings/setList-Einträgen hat, mit denen die user in der Regel nichts anzufangen wissen, die keine Sprachsteuerung nutzen...

Zitat
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.
Den ersten Teil verstehe ich leider nicht so richtig (braucht wohl auch nicht erklärt zu werden, s.u.). Die zigbee2mqtt-Software scheint jedenfalls auch "Hintergrundwerte" rauszuschicken (Interpretation eines im Hinterkopf befindlichen Userwunschs), ich kann aber nicht sagen, ob alle Bulb-Typen das dann verarbeiten (würde annehmen, dass da mal wieder jeder sein Süppchen...).

Zitat
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.
Ob es notwendig ist, kann ich nicht so recht beurteilen. So wie mir das in Erinnerung ist, gab es zuerst (einige) Leute, die gerne haben wollten, dass die Leuchten auch angehen, wenn man in FHEMWEB z.B. die Brightness verändert. Das hatte also noch gar nichts mit Sprachsteuerung zu tun.
Dann war diese Art des Schaltens irgendwann praktisch überall drin, und vor ein paar Tagen kam dann der erste, der getrennte Anweisungen haben wollte. Sein Argument war, dass dann das Schaltverhalten dem entspricht, was über alternative Schaltmöglichkeiten (war ein Shellybulb, wenn ich das richtig im Kopf habe, also über dessen Web-Interface oder das Shelly-Modul). War auch einleuchtend, zumal zeitgleich eine ähnliche Diskussion bei den MiLights hochkam (bei denen bis dato getrennt geschaltet wurde, die Bridge-firmware dann den kombinierten JSON-Blob auflöst und (technisch bedingt) zwei Funk-Befehle absetzt, die dann zu einem "Blitzen" führen (können, je nach vorher eingestellter Helligkeit)...)

Zitat
bei hue gibt es schon immer die möglichkeit mehrere kommandos auf einen schlag abzusetzen. [...]
Damit wären wir beim Kombinieren von Befehlen, korrekt.

Was m.E. (@MQTT(2)) keinen so großen Sinn machen würde, wäre die Kommandos nacheinander zu publishen, weil dann das potentielle Zeitversatzthema mit Blinken usw. zu erwarten wäre. Und da kommen wir zum großen Problem bei MQTT allgemein: es darf jeder seinen Client so programmieren, wie er lustig ist, und jeder User darf es dann noch weiter "kaputtkonfigurieren", wie er mag...
Es reicht also nicht, (jedenfalls, wenn man eine 100% funktionierende Lösung haben will), immer JSON-Blobs zusammenzukleben (was vielleicht noch ginge), sondern die müssen auch an die richtige Adresse (topic, was im Fall von JSON meist noch geht, weil es sich der Autor damit einfach machen wollte, was das "Zuhören" angeht), nein, es gibt mind. einen verbreiteten Grund-Typ, der dann ein ganz anderes Topic haben will und zu allem Überfluß dann auch noch ein anderes Format (tasmota-backlog). Da praktisch alle handelsüblichen WLAN-Devices ESP8266-basiert sind, kann man das vermutlich nicht gut ignorieren, weil doch eine erhebliche Zahl die Dinger umflasht (vermutlich meist tasmota oder evtl. ESPEasy, das ich aber praktisch gar nicht kenne)...


Wenn das alles zu kompliziert ist, kann ich auch den Maintainer spielen und schlicht (tendenziell wieder) das von der Mehrheit gewollte Verhalten ("on"-Befehl immer mitschicken) in den templates hinterlegen, und die, die das dann nicht wollen, müssen es halt einmal "Wegkonfigurieren" (oder man bietet ein alternatives template an). Aber eigentlich hielte ich es immer noch für sauberer, die Anweisungen jeweils getrennt zu halten bzw. sauber zu benennen.
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
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19340
Antw:AttrTemplate und Sprachassistenten
« Antwort #16 am: 26 Juni 2019, 08:54:37 »
Zitat
Und wenn man den setter in FHEMWEB anzeigt, bleibt der auch schön auf dem gesetzten Wert (den "Rückkanal" könnte man notfalls auch zusätzlich in die readingList eintragen).

sicher? lade mal die seite neu :)

mir ging es nicht um das beibehalten des wertes beim benutzen sondern wenn man neu auf die seite geht.


Zitat
Was unschön bleibt, ist der Umstand, dass man - je nach Typ - eine ganze Anzahl von Readings/setList-Einträgen hat, mit denen die user in der Regel nichts anzufangen wissen, die keine Sprachsteuerung nutzen...
ja. die liste wird ganz schnell riesig.

aber das ganze hat glaube ich eigentlich gar nichts mit sprachsteuerung zu tun. siehe unten.


Zitat
Ob es notwendig ist, kann ich nicht so recht beurteilen.
naja... warum sollte man irgendwo hin klicken oder etwas sagen ohne das es ein sichtbares ergebnis hat. aber vielleicht kann man das ja noch mal rausfinden.

wenn die hardware nicht damit umgehen kann wird es immer irgendwie blitzen. aber zumindest auf fhem seite könnte man schon mal alles vorbereiten damit es nicht unbedingt passiert d.h. vom benutzer ein kommando entgegen nehmen und so aufbereiten das es wenn möglich in einem rutsch abgeschickt wird.


die : syntax hätte halt den vorteil das sie prinzipiell alles kombinieren kann (auch mehr als zwei dinge) ohne das sich die kommando liste aufbläht. als allgemein gültige syntax für die grundbausteine sozusagen.

wer dann trotzdem noch ein interaktives kommando möchte könnte die mit cmdalias aus den bausteinen zusammen bauen. und nur genau die die er braucht.
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: 7591
  • eigentlich eher user wie "developer"
Antw:AttrTemplate und Sprachassistenten
« Antwort #17 am: 26 Juni 2019, 09:46:48 »
Hmm, das mit dem setter war zu kurz gedacht, und wir sind uns einig, dass wir hier eine vermischte Diskussion über Bedienphilosophien haben, die nur in Teilen originär was mit Sprachsteuerung zu tun hat.

Jedenfalls was die Steuerung von MQTT2_DEVICE angeht (soweit der User attrTemplate nutzen möchte), habe ich derzeit die Tendenz, jedes einzelne Element getrennt steuerbar zu halten, also nicht z.B. brightness und on zu einem Bedienelement zu verschmelzen und immer on zu setzen, wenn brightness verändert wird. Ich habe an sich kein Problem damit, das zukünftig anders zu handhaben, aber da das auch Auswirkungen auf die Sprachsteuerung hat, stelle ich diese Haltung hier auch mal zur Diskussion, kann ja auch FHEM-unlike sein...

Was aber jetzt FHEMWEB angeht: Dort werden derzeit (immer via template und im DeviceOverview) beide Elemente auch getrennt dargestellt, das devStateIcon gibt on/off wieder und es gibt einen brightness-slider (und ggf. im devStateIcon zusätzlich eine Info über den brightness-Stand). Will man anschalten, muß man via Dev-Overview typischwerise mind. on klicken, und danach den brightness-Wert ändern. Ist m.E. nicht tragisch, allenfalls umständlich (wer's anders haben will, kann es ja ändern).

Interne Logiken kann man so programmieren, dass sie ggf. "das richtige" (im Sinne der Usererwartung) tun. (Also ggf. direkte publishes an das IO vornehmen, selber den passenden JSON zusammenbauen oder eigene setter/getter nutzen).

Was jetzt den Teilaspekt Sprachsteuerung angeht, hatte ich verstanden, dass ein Sprachkommando brightness wegen des "Umbiegens" in dem entsprechenden Attribut dann einen anderen Befehl (hier: ein anderes Reading zu setzen, was einen anderen Befehl _an_ die Hardware zur Folge hat) abzusetzen. Der User denkt also, er setzt brightness.
Erhält die Hardware (oder zumindest die vorgeschaltete Bridge) den Befehl, liefert die was zurück. Hier konkret: sowohl den state wie auch den brightness-Wert, beides unter den dem User bekannten (und "angesprochenen") Readingnamen (nicht dem internen für die Sprachsteuerung gemappten). Für den ist also die Welt in Ordnung, auch wenn er sich hinterher FHEMWEB ansieht, wo ja nur brightness, nicht brightness_on im DeviceOverview zu sehen ist.

Kommt der Befehl nicht an, sollte die Realität ebenfalls der Darstellung in FHEMWEB entsprechen (es stehen dann die alten brightness- und state-Werte da).

Imo wäre damit die Welt eigentlich in Ordnung...
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
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}