AttrTemplate und Sprachassistenten

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

Vorheriges Thema - Nächstes Thema

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