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

Beta-User

Zitat von: justme1968 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.
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...

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

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

Zitatbei 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-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

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


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


ZitatOb 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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Beta-User

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

Hallo zusammen,

ich hole mal diesen Beitrag wieder aus zwei Gründen wieder hoch...

1. @justme1968: Wir hatten neutlich bei Color.pm die Änderung des devStateIcon gemacht, mit der bei dimmbaren Devices vorranging "state" ausgewertet wurde, und nicht "pct". Vor ein paar Tagen tauchte was ähnliches bzgl. Homebridge auf, siehe https://forum.fhem.de/index.php/topic,94060.msg1016475.html#msg1016475. Vielleicht ist das aus Color.pm sinngemäß übertragbar?

2. Grundsätzlich wäre es nun m.E. an der Zeit, ggf. nochmal allgemeiner über den Sprachsteuerungsaspekt in den diversen attrTemplate-Files, v.a. auch für MQTT2 nachzudenken.
Kann aber sein, dass recht vieles zwischenzeitlich durch eine "sprachsteuerungstaugliche" Benennung der Readings erledigt ist, vor kurzem habe ich z.B. die Tasmota-Templates v.a. aus diesem Grund mit jsonMap-Attributen versehen.

Wenn da also was eingebaut werden soll, bitte melden...
(Ich kann und will aber nach wie vor mangels hier installierter Sprachsteuerungslösungen usw. nicht selbst testen).
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

erst mal kurz:

ich denke am besten ist es mehrstufig vorzugehen:

- readings und kommandos kompatibel zu bestehenden devices machen und nicht das rad immer neu erfinden
- wenn das nicht geht: ein passendes homebridgeMapping ins template bauen
- wenn das immer noch nicht reicht: code änderungen an den sprachassistenten. aber rückwärts kompatibel :)
  d.h.: wenn irgend wie möglich ohne abfrage des device typs um das verhalten fest zu programmieren sondern
          automatisches auslesen aus set/get liste und readings.

wo wollen wir das genau weiter diskutieren? hier? oder in dem verlinkten thread?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

Reading-Namen und Befehle sind in MQTT2 beliebig und einfach waehlbar, Wert-Anpassungen waeren aufwendiger.
homebridgeMapping waere im template auch kein Problem, aber vmtl. nicht noetig.
Mir (und vermutlich Beta-User) fehlt nur eine Liste der Readings/Befehle samt Wertebereich, die von den Assistenten "Out-Of-The-Box" verstanden werden.

Beta-User

Das faßt es m.E. ganz gut zusammen, meine sowieso fertige Langfassung dann danach...
Zitat von: rudolfkoenig am 28 Januar 2020, 12:45:42
Reading-Namen und Befehle sind in MQTT2 beliebig und einfach waehlbar, Wert-Anpassungen waeren aufwendiger.
homebridgeMapping waere im template auch kein Problem, aber vmtl. nicht noetig.
Mir (und vermutlich Beta-User) fehlt nur eine Liste der Readings/Befehle samt Wertebereich, die von den Assistenten "Out-Of-The-Box" verstanden werden.

Sehe das auch so, dass es mehrstufig ist, daher auch erst mal der Ansatz, das mit den Readings gradezuziehen. Es kamen in letzter Zeit auch wenig Rückmeldungen, die irgendwas mit Sprachsteuerung zu tun hatten. K.A., womit das zusammenhängt. Könnte sein, dass es entweder einfach ist, das mapping zu setzen, oder einfach so läuft?

Die generelle Diskussion dazu für MQTT2 sehe ich eher in dem "Anregungen"-Thread zu den mqtt2-templates. Macht aber nur dann Sinn, wenn wir irgendwas an Rückmeldungen und Infos von anderen Leuten brauchen, sonst ist es evtl. übersichtlicher, einfach hier zu bleiben?

Sofern du spezielle Ansatzpunkte aus dem verlinkten Shelly-Thread hast, kann ich dann von diesem Thread aus auch einen link setzen, dann brauchst du diesen nicht auch noch abbonieren, je nachdem ist da ziemlich viel Verkehr.

Ansonsten kann ich zu den übrigen Punkten wenig sagen, meine Anregung war nur, ggf. den allg. code anzupassen, _wenn_ man im Zusammenspiel von pct/brightness und state immer dieselben Probleme zu lösen hätte. _Ob_ das so ist, habe ich nicht geprüft (ich wüßte auch nicht, wo anfangen mit suchen, da mir das Zusammenspiel der einzelnen Teile nicht aus eigener Anschauung geläufig 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

justme1968

als einstieg ist vermutlich das hier: https://wiki.fhem.de/wiki/FHEM_Connector_für_Amazon_Alexa#Was_geht_alles_.3F und im besonderen jeweils der automatisch teil geeignet. es muss zwar noch einiges ergänzt werden, aber einige reading und kommando namen stehen da schon mal.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Beta-User

Danke, das hilft schon mal weiter, muß ich mir mal in Ruhe ansehen, sieht aber so aus, als wäre das meiste schon jetzt klar, auch wenn kein genericDeviceType gesetzt ist.

Das einzige, was mir beim ersten Überfliegen auffällt, ist dass brightness bei "light" nicht drin ist. Gerade das mqtt-Zeug "mag" aber die 255-er Variante... Evtl. läßt sich das ohne Nebenwirkungen für andere Modul-Typen noch integrieren? (Umrechnen auf MQTT2_DEVICE-Seite ist meistens nicht so dolle, weil dann recht viel Perl benötigt wird, v.a., weil diese Devices dann in der Regel auch noch JSON verwenden. Vermute, der 0-255-Wertebereich ist bei anderen Controllern der bevorzugte). Oder gibt es einen (anderen) Trick, als die alle auf "Brightness=brightness::brightness,minValue=0,maxValue=255" zu mappen?

Hmm, an sich wäre es aber auch kein allzugroßes Problem, dieses eine (oder beiden?) Attribut/e über ein einziges, intern aufzurufendes attrTemplate bei Bedarf zu ergänzen (bzw. die dort vorhandenen Angaben zu ergänzen!), wenn wir es mit einem solchen Gerät zu tun haben... (Eleganter wäre es, es ginge ohne ;D .)

(Ich hoffe, alle mqtt2-attrTemplates schon auf pct=0-100 und brightness=0-255 umgestellt zu haben, es gab da ein paar "spezielle" Devices, soweit ich mich entsinne).
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

unabhängig vom verstanden reading muss gericDeviceType jeweils passend gesetzt werden wenn es sonst nicht eindeutig ist. d.h. am reading pct alleine z.b. kannst du ja nicht erkennen ob es ein dimmer oder ein rollladen ist.

für den wertebereich wäre es am besten wenn er aus dem set ? erkennbar ist. also wenn z.b. der slider in fhem web auch richtig angezeigt wird. 
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Beta-User

Ok, Teil 1 leuchtet ein.

Dann sollten wir also in jedem Fall doch was einbauen...

Hatte zuerst überlegt, ob das übergreifend als allg. Spracherkennungs-attrTemplate-file Sinn macht, aber vermutlich verwirrt das am Ende eher, von daher neige ich grade dazu, einfach mehrere (im Moment mal drei oder vier) Grundtemplates zu erstellen, die intern aufgerufen werden (bzw. ggf. mit deren Hilfe man "nachrüsten" kann): Z.B. "mqtt2_speech_recognition_type_light" für ein ein/aus-Licht, "...dimmer" für dimmbar, "...shutter" für einen Rollladen (ggf. noch ...color?). (Oder macht es doch Sinn, das generisch auszulegen und dann mit der filter-Abfrage mehrere TYPE zuzulassen, wenn es denn paßt? @Rudi: ich weiß, dass dir diese internen Aufrufe suspekt sind, von daher: Deine Meinung?)

Was super wäre:
Könntest du ein getestetes Muster-template (für beide Spracherkennungen ::) , mit passenden "option:"-Anweisungen?) basteln, das dann die vorhandenen Attribute entweder ausliest und ergänzt oder ersetzt? Ich weiß leider nicht recht, ob man einfach überschreiben darf, dann wäre es recht einfach...
Meine Hoffnung wäre die, dass das schnell Rückmeldungen mit weiteren sinnvollen Vorschlägen geben wird, wenn wir wenige Beispiele in den allgemeinen Umlauf geben :) .

Ansonsten sind bei den MQTT2-templates die setter alle mit in der setList und daher über "set ?" abfragbar.
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

Wenn im attrTemplate Mechanismus was fehlt, um das Anlegen zu vereinfachen, bitte melden, und nicht rumherum bauen.

Beta-User

Zitat von: rudolfkoenig am 28 Januar 2020, 14:31:30
Wenn im attrTemplate Mechanismus was fehlt, um das Anlegen zu vereinfachen, bitte melden, und nicht rumherum bauen.
Danke für's Angebot. Im Moment sehe ich nicht, dass man was neues benötigen würde, aber erfahrungsgemäß denkst du immer noch mind. zwei Schritte weiter wie ich, und dementsprechend dauert es eben, bis hier auch der Groschen gefallen ist ;D (so er denn überhaupt fällt).

Empfindest du die Variante, intern immer wieder dasselbe attrTemplate (z.B. das noch imaginäre "mqtt2_speech_recognition_type_light") bei allen reinen on/off-Lichtern aufzurufen als "drumherum gebaut"?
Du scheinst den Mechanismus ja v.a. bei Tasmota recht kritisch beäugt zu haben, meine Erfahrung (auch jetzt beim Umstellen auf jsonMap) war die, dass das insgesamt recht gut klappt, weil man nur wenige Stellen anpacken muß, was Fehlermöglichkeiten reduziert. Der einzige Haken ist der, dass manche User Schwierigkeiten haben, das "richtige" template auszuwählen, weil eben recht viele, teils eigentlich nur für interne Zwecke gedachte templates in der Auswahlliste auftauchen. Aber dieser Nutzerkreis ist auch nicht für das "?" zu erwärmen...

Beim Schreiben kommt mir eine noch unausgegorene Idee: ein "hidden"-Flag...? Also aufrufbar, wenn man weiß, was man tut, aber für den Normalbetrieb nicht sichtbar? Hat aber nichts mit Spracherkennung zu tun, und ob man das für die Spracherkennungs-templates einsetzen sollte, wäre nochmal eine weitere Frage...
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

#28
Wofuer genau brauchst du hidden?
Fuer bestimmte Faelle kann man es mit sowas wie prereq:NAME=attrTestUmgebung simulieren.


Nachtrag:
Ich meinte filter:hidden :)

Beta-User

@Rudi:
Wie meistens: Danke für den Schubs, hatte die Funktionalität von filter: anders im Hinterkopf...
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, 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

justme1968

das attribut ist nur nötig wenn man die events auch an amazon schicken möchte um damit eine routine auszulösen.

aktivieren geht nur über das attribut im device. das attribut im alexa-device ist nur zum zeitweisen globalen deaktivieren.

die meisten bewegungsmelder und kontaktsensoren sollten automatisch erkannt werden. wenn nicht müsste das setzen von gnericDeviceType schon helfen. erst wenn das nicht reicht ist homebridgeMapping nötig.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Beta-User

Hmm, wie soll ich das deuten...?

Das klingt danach, als wäre das mit den "proactive events" eigentlich eine Art "Experteneinstellung", die man gar nicht über templates abbilden sollte?
(Ich werd's kommentarlos wieder ausbauen, wenn mir keiner in den Arm fällt, der es besser weiß).

Ansonsten würde ich die Zahl der "sensor"-templates auf zwei festlegen, nämlich eines, das nur via parametriertem Aufruf den genericDeviceType festlegt und ein zweites, das dann zusätzlich auch das komplette Mapping empfangen 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

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

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

Beta-User

Hi Andre,

kannst du das mal ansehen: https://forum.fhem.de/index.php/topic,108999.msg1031171.html#msg1031171

(Kurzfassung: Erwünscht wäre  eine Funktion in siri.pm, die den "siri-Raum" in die raum-Liste eines bestimmten Devices aufnimmt, den Raum aus der config.json liefert oder den aufbereiteten neuen Attributinhalt. Sowas in diese Richtung halt...).

siri_add_siriroom_to_rooms(<devicename>)
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

sorry. stehe gerade auf dem schlauch. was meinst du mit siri raum?

geht es darum ein device automatisch in den filter aus dem config.json zu bekommen?

wenn ja: das ist schwierig. der filter ist ja flexibel und kann alles mōgliche sein. ein raum, ein attribut, der device name, ... oder eine kombination als allem. also alles was laut devspec erlaubt ist. d. h. auch regen und filter.

dazu kommt dann noch das es pro config file mehr als eine connection zu fhem geben kann mit jeweils einem eigenen anderen filter und sogar mehr als ein config file bzw. homebridge instanz.  letzteres ist nötig weil pro homekit bridge nur 50 bzw. aktuell 100 devices oder services möglich sind.

(ich verwende z.b. pro raum eine eigene connection mit passendem namen um im log gleich zu sehen um welchen raum es gerade geht und zähle die devices einzeln oder in gruppen auf. )

eine beliebige bestehende konfiguration automatisch so zu ändern das genau ein device zusätzlich eingebunden wird ist so gut wie unmöglich.

erschwerend kommt hinzu das für siri
die default config noch nicht automatisch erzeugt wird und dir wiki beispiele von anfang anders als das config.sample file das ich mit ausliefere waren.

ich habe gerade keine gute idee wie wie hier etwas automatisieren können  das auch für bestehende installationen gilt.


vielleicht hilft erst mal drûber schlafen.

eventuell wird das ganze etwas einfacher wenn mir endlich eine gute varaiante einfällt die mehreren potentiellen instanzen per autostart aus fhem heraus zu steuern.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Beta-User

...puh, sehr abstrakt (ich bin bekennendermaßen auf dem Spracherkennungsauge blind, und was Äpfel angeht, auch noch taub...)

Kurz: ich habe den Eindruck langsam erahnen zu können, wie diffus das ganze zu greifen ist. Die Idee von TomLee war in der Tat, den "filter" anzuzapfen und dazu die Datei zu lesen. Dass das nur funktionieren kann, wenn dort eindeutige Angaben stehen, ist soweit einleuchtend, aber wenn filter devspec ist, kann man das mMn. im Rahmen von attrTemplate fast nicht mehr abbilden. Das wäre dann ggf. Aufgabe spezieller Dialogfelder und Routinen.

Drüber schlafen (würde vorschlagen: mehr wie einmal...) ist vermutlich hier erst mal eine gute Idee :) .

Bin ja erst mal sehr zufrieden, dass die Basis soweit funktioniert, dass Leute u.a. deswegen AttrTemplate-Unterstützung in ihre Module einbauen. Falls du da noch irgendwelche Anregungen hast, wäre es nett, wenn du die loswirst, bevor sich zu viele Leute an den jetzigen Stand gewöhnt haben ;D .
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