mqtt2.speech.template:TINT GU-10 white

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

Vorheriges Thema - Nächstes Thema

TomLee

ZitatMit

Brightness=brightness,cmd=brightness,max=255,minValue=0,maxValue=255,factor=0.39216
On=state,valueOn=ON,valueOff=OFF


In der Alexa-App ist es weiterhin Glückssache das der Slider/Schalter angezeigt und wenn, ist er nach kurzer Zeit verschwunden und wird gesucht. Aber sliden konnte ich einmal und 100 % sind brightness 254, auch per Sprache  :)

In der Home-App ist ein/ausschalten problemlos möglich, beim sliden sind 39% weiterhin brightness 254. :-\

Das betrifft was du meinst Brightness=brightness::brightness ist nur die Abkürzung von Brightness=brightness,cmd=brightness und es muss maxValue=255 sein nicht maxValue=100

Beta-User

Hmm, dann weiß ich auch nicht; heute morgen war maxValue=100 noch (in Teilen...) ok gewesen, deswegen war ich dahin zurück. Verwirrend...
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

Ich verstehe, ich hab jetzt aber Stunden daran rumgespielt es klappt nicht mehr.

Es ist ja auch nicht tragisch das der Slider in der Alexa-App "noch" nicht dargestellt wird. Schön ist das das homebridgdmapping jetzt greift. Dumm bloss das es nicht in homekit will.

Zum Verständnis: Wir versuchen einen Slider/Schalter anzuzeigen den Amazon standardmässig ohne extra Einstellungen nicht anzeigt, wegen den 254.

Den slider für bspw. genericDeviceType blind gibts erst seit ein paar Wochen (ohne irgendwelche Verrenkungen/homebridgemapping).

Für einen Homematic-Dimmer braucht man bspw. nichts machen und der Slider/Schalter wird angezeigt, weil es dort nur bis 100 geht, meine Erklärung

TomLee

Nochmal zum Verständnis:

Ich habe in der Alexa-App eine Gruppe Wohnzimmer.
In dieser Gruppe befinden sich 3 dieser Leuchten
In einer Gruppe befindliche, mit genericDeviceType light definierte Geräte lassen sich unabhängig vom vergebenen alexaName mit dem generischen Namen Licht per Sprache ein/ausschalten oder auf Prozent stellen. Das nutze ich täglich.
Das ein/auschalten dieser Geräte per Sprachbefehl ist ohne besondere Einstellungen (homebridgeMapping) möglich und wird alleine anhand von on/off in der setList erkannt.
Möchte ich  diese auch mit Prozentangabe per Sprache steuern war meine bisherige Lösung mit userreadings von nöten.
Ich habe jetzt das zuletzt vorgeschlagene homebridgeMapping (angepasst auf die (kurze) Variante die du erwartet hattest)
Brightness=brightness::brightness,minValue=0,maxValue=255,max=255,factor=0.39216
On=state,valueOn=ON,valueOff=OFF
auf eines dieser 3 Geräte angewendet.
Mit "Echo, Licht ein/auschalten" oder "Echo, Licht auf x Prozent" passiert jetzt mit nur dem homebridgemapping in diesem einen Gerät, das gleiche wie in den 2 anderen mit userreadings. Ziel erreicht, homebridgemapping greift was hier im Thread das Ziel war. Kein Mensch (zumindest ich nicht, oder wenige) geht in die App um per Slider/Schalter zu steuern.
Ärgerlich das es mit homebridge-fhem nicht klappt. Es wäre super wenn jetzt Andre was dazu sagen würde, ich als kleines Licht sage entweder stimmt jetzt auf dem Weg alexa-fhem -> Amazon etwas nicht (aber das passt ja jetzt) oder von homebridge-fhem zu homebridge, in anderen Worten, wie das Andre im anderen Thread schon angedeutet hat, es ist in homebridge-fhem noch nicht eingebaut.

Beta-User

Jetzt wegen "On=..." betr. "ON"/"on" noch eine Frage:
Wenn es in der App mit den Slidern sowieso nicht geht, braucht man das dann überhaupt?

(Wie geschrieben: Wenn wir ON und on bei der Adressierung der templates unterscheiden müssen, wird es sehr viel komplizierter. Was keine positiven Auswirkungen hat, sollte man daher m.E. weglassen.)

Und eine Frage zu maxValue=255 bzw. =100. Das schien auch mit 100 ok zu sein (bis auf die slider, die aber sowieso fehlen, oder?). Wenn das "woanders" (homekit?) positive Auswirkungen hat, weil z.B. dort die min/max-Werte auch nummerisch angezeigt werden, sollte (?)/könnte man das auch auf 100 lassen. An sich finde ich bei Helligkeitswerten 0-100 als einheitliche Bedienanzeige eingängiger für die user...

Aber wie gesagt: Blinder und Farbe...
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

deine kombination von factor und maxValue passt nicht.

entweder: entweder factor=0.39216 um von 255 auf 100 zu skalieren und dann auch maxValue=100 verwenden, oder factor weg lassen und mit maxValue=255 arbeiten.

ersteres sollte in alexa-fhem und homebridge-fhem gehen, letzteres vermutlich aktuell nur in homebridge-fhem.

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

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

Beta-User

Danke für die Rückmeldung. Dann checke ich also zeitnah am besten folgendes ein (ohne "max=255") (?):
attr DEVICE homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=100,factor=0.39216

Kannst du auch was zu color_temp sagen? Muß/sollte man da den Wertebereich irgendwie "normalisieren"?

(Wenn ich das in dem anderen Beitrag so lese, klingt das danach, als sollte man die Rollladen-Sache erst mal noch hintanstellen/weglassen, oder...? Insbesondere für die "invertierten"?)
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

so sollte es mit alexa und siri funktionieren.

farbtemperatur geht entweder über kelvin oder mired. das wird aber automatisch erkannt und intern umgerechnet. du musst also am wertebereich nichts selber machen wenn es eins von den beiden ist.

rolläden sollten komplett gehen. das invertieren ist ein prinzipielles problem das sich aktuell nicht lösen lässt. wenn der aktor richtig rum angeschlossen 100 als zu ansieht muss man mit den bekannten einschränkungen leben. in alexa heisst der parameter nicht umsonst öffnungsgrad statt position.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Beta-User

OK, was brightness angeht.

Rollläden invertiert lasse ich weg, das Problem soll der betreffende user dann jeweils selbst lösen, es sei denn, es schlägt jemand irgendwann mal was funktionierendes vor...

kelvin und mired kennt mqtt2.template bisher nicht, auf die Schnelle gibt's nur hex, color, rgb. und color_temp. Ich lasse die Leuchten erst mal auf light, da findet sich im Zweifell dann schon was, oder?
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

#39
Zitatentweder: entweder factor=0.39216 um von 255 auf 100 zu skalieren und dann auch maxValue=100 verwenden, oder factor weg lassen und mit maxValue=255 arbeiten.

Vor deiner Antwort hatte ich mal minValue=0,maxValue=255,max=255 weggelassen ob und um zu schauen was automatisch erkannt wird.

Also:

Brightness=brightness::brightness,minStep=5,factor=0.39216
On=state,valueOn=ON,valueOff=OFF


Hiermit kann man per Sprache (Alexa und Siri) ein/ausschalten und auf Prozent stellen.Alles korrekt.

Der Status von Ein/Aus und brightness wird in Home korrekt angezeigt.

In der Home App kann man mit dem Schalter ein/ausschalten (ohne On=state,valueOn=ON,valueOff=OFF ist das nicht möglich, per Sprache ein/auszuschalten ist es aber nicht nötig) und sliden ( also festhalten und ziehen) ist bedingt möglich, das hab ich aber mit einem Homematic-Dimmer auch und ich glaube man muss minStep noch mit dazunehmen ( und noch >5 wählen), weil beim sliden (festhalten und ziehen) jeder Prozentwert an homebridge-fhem übertragen wird und der Slider ein merkwürdiges verhalten zeigt.

In der Alexa App wird der Slider angezeigt solange brightness <100 ist ( hier ändert sich auch nix wenn man umstellt auf minValue=0,maxValue=255, ohne factor), der Status ist 100 Prozent bei brightness 100, es wird also nicht korrekt skaliert.

Wenn man aber per Slider auf einen Prozentwert stellt, sagen wir 50 % dann wird korrekt auf 127 gestellt, es wird korrekt skaliert.

Beta-User

OK, jetzt habe ich eben den ersten Teil (Brightness=brightness::brightness,minStep=5,factor=0.39216) eingecheckt, weniger scheint wirklich mehr zu sein...

Was "On=state,valueOn=ON,valueOff=OFF" betrifft, bin ich unsicher. Das Testdevice sendet Großscheibung zurück, wenn der Befehl ankam. Stellt sich die Frage, ob das auch paßt, wenn das nicht der Fall ist. Meine Vermutung: nein, paßt nicht...

Wir bräuchten also eine Unterscheidung. Da das aber nicht nur Lichter betrifft, ist das vermutlich ein weiteres attrTemplate, das dann nur für den Groß-/Kleinschreibungsteil zuständig wäre und ggf. dann das Mapping erweitert?

Frage: Hast du ein Device, das Kleinschreibung verwendet? (z.B. ein einfacher Tasmota-Zwischenstecker müßte es tun, muß keine Lampe sein).

(zu der Anfrage via pm: Sorry, ich will mich wirklich nicht mit der Spracherkennung selbst befassen, auch nicht testweise, und schon gleich nicht mit unterschiedlichen Endgeräten, insbesondere nicht mit Äpfeln... Aber wir sind hier m.E. auf einem guten Weg, das paßt aus meiner Sicht, auch wenn manches schwer zu verstehen und schreiben 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

bei HomeMatic sollte man für slider immer delay=true setzen dann wird der wert erst dann an fhem gesendet wenn sich der slider 0.5 bzw. 1 sekunde nicht mehr bewegt hat.

der grund ist: wenn man bei hm zu schnell hintereinander sendet kommt sich das senden des aktuellen wertes und der empfang des letzten ack in die quere.


für alexa sind es immer % werte. die gehen nur bis 100. deshalb funktioniert alles darüber nicht. in homekit kann man die obergrenze frei wählen. deshalb geht da auch 255. -> kleinster gemeinsamer nenner: 100 als obergrenze und factor angeben.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

TomLee

Danke.

Also klappt es deswegen nur mit dem userreadings


Jetzt fehlt noch die Erklärung zu on/off->ON/OFF.

Es ist doch so, wenn Kleinschreibung zurückkommt passt alles und man braucht kein Mapping.
Warum es hier aber jetzt per Sprachbefehl (Alexa/Siri) klappt und nur für den Ein/Aus Status in Home benötigt wird, in der Alexa-App aber der korrekte Status ohne Mapping dargestellt wird, versteh ich noch nicht.

TomLee

@Beta-User

das minStep sollte wieder raus aus dem Template, das ist Geschmackssache.
Das delay=true aber ein muss, sonst ist der Slider (in der Home-App) nicht korrekt bedienbar.

Beta-User

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

Zu dem on/ON noch:
Hier ist das "Problem", dass FHEM-seitig praktisch immer zum Steuern Kleinschreibung erforderlich ist, aber die Rückmeldung vom Aktor dann in der ON/OFF-Variante kommt. Ergo müßte man jetzt entweder
- hergehen, und das mit "ein bißchen Perl" so korrigieren, dass in "state" Kleinschreibung verwendet wird;
- den Sprachsteuerungen (vollends) beibiegen, dass ON und on in den Zuständen in "state" dasselbe sind, aber das Kommando trotzdem klein sein muß (da könnte der Unterschied (?) zwischen "Home" und "alexa" herkommen?) oder
- ein asynchrones Mapping (homebridge-bezogen) definieren. (Hier könnte man testen, ob FHEMWEB-eventMap ON:on OFF:off ausreichend wäre; glaube das aber nicht, denn das ist "Kosmetik", die "oberhalb" des levels greift, auf dem das homebridgeMapping ansetzt, wenn ich die Zusammenhänge richtig verstanden habe...)

Tendenziell wäre es m.E. am zielführendsten, die korrekte Interpretation von "großen" Statusinfos  auf Ebene der Sprachsteuerungslösung zu erledigen, und nicht speziell zu mappen. Kann damit aber auch falsch liegen, und "jemand" müßte es anstoßen bzw. dann vor allem auch umsetzen :) .
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