mqtt2.speech.template:TINT GU-10 white

Begonnen von TomLee, 03 Februar 2020, 18:34:44

Vorheriges Thema - Nächstes Thema

justme1968

mal abgesehen davon das ON und OFF auch an anderen stellen in fhem nicht automatisch erkannt werden und vermutlich probleme machen und es schön wäre sich hier zu einigen...

ich habe in alexa-fhem und homebridge fhem eingebaut das on und off unabhängig von der schreibweise erkannt sollten.

beim setzen des on und off kommandos wird aber nur die klein geschriebene variante verwendet.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Beta-User

Ja, ist schade, dass es da Inkonsistenzen gibt.
Gerade im MQTT-Bereich besteht halt das Problem, dass anderswo die Großschreibung bevorzugt zu werden scheint, was bei praktisch allen firmwares daher der default ist, und sich nur teilweise umstellen läßt...

Es wäre zwar möglich, das via MQTT2-attrTemplate zu vereinheitlichen, aber es müßten dann alle Betroffenen auch nachziehen... (und jemand müßte es machen, aber das ginge ggf. noch...)

Wie dem auch sei, m.E. lassen wir dann also definitiv die On-Mappings weg => das andere ist daher jetzt im svn, die "inverted"-blinds sind auch erst mal deaktiviert...
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

TomLee

ZitatOK, dann checke ich also demnächst "attr DEVICE homebridgeMapping Brightness=brightness::brightness,maxValue=100,factor=0.39216 delay=true" ein...

Dann ist ein/auschalten nur per Sprache in homebridge, möglich nicht per Schalter in der App.
Dazu braucht man dann das On=state,valueOn=ON,valueOff=OFF.

Alexa ist es Wurscht sie zeigt den richtigen Status des Schalter und schaltet ein/aus, auch ohne diese Angabe.

Beta-User

Hmm, hatte justme1968 so verstanden, dass das nach einem update dann demnächst passen sollte?
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

TomLee

Hab ich wohl überlesen, hier hat er das gesagt ?

Vielleicht:
Zitatich habe in alexa-fhem und homebridge fhem eingebaut das on und off unabhängig von der schreibweise erkannt sollten.

fehlinterpretiert ?

TomLee

Mit dem update wird der Slider jetzt immer angezeigt, auch wenn man einen Wert >50 % wählt.

Allerdings:

Mit der factor-Angabe gibt es immer folgendes Problem:
Brightness=brightness::brightness,delay=true,factor=0.39216

Alexa-App

egal auf was für einen Prozentwert man den Slider stellt, er springt immer um 1 Prozentwert zurück (nachdem der korrekte Wert zurückkommt von z2m), auf 0% stellen geht auch nicht, nur 1% (das dann brightness 3 nachdem der Wert von z2m kommt) und in der App schließlich dann 0%.

es ändert auch nix wenn man factor=100/254=0.393700 nimmt, gleiches Verhalten.

Home App

passt alles, aber auch hier sind 0% am Ende brightness 1

Mit
Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,delay=true

Alexa App

passt alles, bis auf das man auch hier per Slider nur 1% auswählen kann, was dann brightness 3 (nach Rückmeldung) sind, in der Alexa-App aber der Slider weiterhin auf 1% stehen bleibt.

Home-App

Hier kann man auf 0 % stellen das sind dann aber auch brightness 1 am Ende.

Und jetzt nochmal zu

On=state,valueOn=ON,valueOff=OFF
und
Zitatich habe in alexa-fhem und homebridge fhem eingebaut das on und off unabhängig von der schreibweise erkannt sollten.

Das update betrifft ja nur alexa-fhem, dann müsstest du dir das mal selbst anschauen, weil ohne klappts nicht, sonst würde ich es doch nicht ansprechen

Gruß

Thomas

TomLee

Mal ein Vergleich mit einem dummy

defmod du_t1 dummy
attr du_t1 alexaName ingwer
attr du_t1 genericDeviceType light
attr du_t1 homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,delay=true
attr du_t1 readingList brightness
attr du_t1 room Homekit,Test
attr du_t1 setList on off


Alexa-App

Alles passt, aber man kann nur auf 1% stellen was dann brightness 3 ergibt.Gleiches Verhalten wie beim MQTT2-Device.

Home-App

aber mit On=state,valueOn=ON,valueOff=OFF, alles passt, man kann auf 0% stellen was dann auch brightness 0 entspricht. Also ein anderes Verhalten wie beim MQTT2-Device welches nach der Rückmeldung brightness 1 ergibt.

Beta-User

Hmmm, bin zugegebenermaßen etwas ratlos, wie ich jetzt mit diesen Infos umgehen soll...

Gibt es konkrete Vorschläge/Wünsche, was an den jetzigen attrTemplate (ggf. für einzelne Sprachsteuerungsvarianten?) anzupassen?
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

TomLee

Zusammengefasst kommt , bis jetzt, nur

Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,delay=true
On=state,valueOn=ON,valueOff=OFF


dem Ideal nahe was man als User erwartet.

korrekter 100%/EIN/AUS- Status (oder sonstige Prozentwerte, außer 0% (da kommt bei Alexa per Sprache oder Slider am Ende brightness 3 raus der Status des Slider ist dann 1% und bei Siri/Home brightness 1, der Status des Sliders ist dann 0%) bei beiden Systemen, ob per Sprache oder Schalter/Slider.

Beta-User

Hm, ok, aber eine Frage habe ich dazu noch: Paßt das mit ON/OFF auf auch Geräte, die von vornherein Kleinschreibung verwenden/in Senderichtung brauchen?
Oder müßte es da so heißen:
On=state,valueOn=on,valueOff=off
Oder könnte man diese Variante auch für beides nehmen...?
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

TomLee

Laut dieser Aussage und meinem Verständnis

Zitat von: justme1968 am 08 Februar 2020, 17:27:13

ich habe in alexa-fhem und homebridge fhem eingebaut das on und off unabhängig von der schreibweise erkannt sollten.

beim setzen des on und off kommandos wird aber nur die klein geschriebene variante verwendet.

braucht man weder für Groß.- noch Kleinschreibung irgendein Mapping, beides sollte erkannt werden.
Bei alexa-fhem klappt das hier ja, bei homebridge-fhem (wie oft hab ich das jetzt schon erwähnt ?) nicht.

In Senderichtung wird also immer Kleinschreibung verwendet.
Das Mapping wird nur zum darstellen des korrekten Status benötigt wird.

On=state,valueOn=on,valueOff=off

kann also nicht verwendet werden bei Großschreibung und bei Kleinschreibung ist die Angabe sowieso obsolet.



Beta-User

OK, trotzdem bitte für Langsamdenker ohne Testumgebung wie mich der Reihe nach:

Wir brauchen den Teil On=state,valueOn=ON,valueOff=OFF denmach nur im Zweig homebridge-fhem, und - wenn ich das richtig verstanden habe - auch nur dann, wenn das FHEM-Device seinen state groß schreibt.

Konkreter gedanklicher Hänger, den ich immer noch habe: Ist das "erweiterte" mapping auch erfolgreich getestet mit einem Gerät, das on/off im state klein schreibt? Ist es dem egal oder klappt das dort nicht? So wie ich das bisher verstanden habe, haben wir nur ein Referenzgerät getestet, und das liefert state ON/OFF.

Sonst brauche ich nämlich eine Unterscheidung in den attrTemplates, das ist immer noch meine eigentliche 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

TomLee

ZitatWir brauchen den Teil On=state,valueOn=ON,valueOff=OFF denmach nur im Zweig homebridge-fhem, und - wenn ich das richtig verstanden habe - auch nur dann, wenn das FHEM-Device seinen state groß schreibt.

Korrekt, das heißt aber nicht das diese Angabe in ein Template soll, laut Aussage von Andre sollte es ja ohne funktionieren.


ZitatIst es dem egal oder klappt das dort nicht?

Sonst brauche ich nämlich eine Unterscheidung in den attrTemplates, das ist immer noch meine eigentliche Frage...

Natürlich klappt es dann nicht, darum mappt man ja.

Beta-User

 ::) OK, dann war ich (teilweise?) gar nicht der eigentliche Adressat...

Teilweise wegen dem hier:
Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,delay=true
Soll dann besser das rein statt der aktuellen factor-Variante?

In der Beziehung stehe ich immer noch auf dem Schlauch...
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

TomLee

Ja.

Ja, bis die Frage geklärt ist weshalb ON/OFF bei homebridge-fhem nicht ohne mapping erkannt wird, halt dann noch mit dem "erweiterten" Mapping, so war die Zusammenfassung in #53 gemeint.




Dann gehts ja weiter ;D, wenn man sich für die max/minValue Variante in einem Template entscheidet und der Fall einmal eintreten sollte irgendjemand wendet das Template auch wirklich an und dieser jemand sich näher damit beschäftigt, diesem irgendwann mal auffällt das auf 0% stellen per Sprache (Siri/Alexa) brightness 1 ergibt und nicht null.
Und per Slider in der Home-App man auf 0% stellen kann (0 kommt auch an) aber 1 von z2m zurückkommt, in der Alexa-App man nur bis 1% sliden kann, 3 in FHEM ankommt und 3 dann auch von z2m zurückkommt.

Alles Belanglosigkeiten, die mich ehrlich gesagt nicht die Bohne interessieren aber ich der Vollständigkeit erwähne.