Autor Thema: AttrTemplate und Sprachassistenten  (Gelesen 843 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7191
  • 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-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19266
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: 7191
  • 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-T5740@stretch, aktuelles FHEM + ConfigDB | CUL_HM@VCCU | MySensors: seriell, v.a. 2.3.1@RS485 | MQTT2: MiLight@ESP-GW + zigbee2mqtt | SIGNALduino | MapleCUN | ZWave
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

 

decade-submarginal