mqtt2.speech.template:TINT GU-10 white

[TomLee]

Hallo,

aufgrund dieses Threads ist u. a. Definition entstanden.
Damit wird der Slider und Schalter in der Alexa App angezeigt, der Status von brightness (Alexa App/FHEM) stimmt auch überein , allerdings nur mit zusätzlichem userreadings.
Wenn man nur das jetzt vorgesehene homebridgemapping anwenden würde, gibts keinen Slider, keinen Schalter und auf 100% in der App entsprechen 100 von 254 im Device.

Wenn niemand einen besseren Vorschlag hat oder sagt das ist völliger Quatsch würd ich gerne das Beispiel als Grundlage für ein Template vorschlagen:

Code: [Auswählen]

defmod MQTT2_zigbee_gu10_1 MQTT2_DEVICE 0x00158d0003274a6c
attr MQTT2_zigbee_gu10_1 IODev MQTT2_Server
attr MQTT2_zigbee_gu10_1 alexaName decke1
attr MQTT2_zigbee_gu10_1 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_gu10_1 genericDeviceType light
attr MQTT2_zigbee_gu10_1 group Wohnzimmer
attr MQTT2_zigbee_gu10_1 homebridgeMapping Brightness=abrightness,cmd=brightness,max=255,minValue=0,maxValue=100
attr MQTT2_zigbee_gu10_1 icon light_control
attr MQTT2_zigbee_gu10_1 imageLink /fhem/deviceimages/mqtt2/404006-404008-404004.jpg
attr MQTT2_zigbee_gu10_1 model L_02a_zigbee2mqtt_light_dimmer
attr MQTT2_zigbee_gu10_1 readingList zigbee2mqtt/0x00158d0003274a6c:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_gu10_1 room MQTT2_DEVICE
attr MQTT2_zigbee_gu10_1 setList on:noArg zigbee2mqtt/0x00158d0003274a6c/set {"state":"ON"}\
off:noArg zigbee2mqtt/0x00158d0003274a6c/set {"state":"OFF"}\
brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/0x00158d0003274a6c/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr MQTT2_zigbee_gu10_1 setStateList on off
attr MQTT2_zigbee_gu10_1 userReadings abrightness {int(ReadingsNum("$name","brightness",0)/254*100)}
attr MQTT2_zigbee_gu10_1 webCmd brightness:toggle:on:off
Gruß

Thomas

[Beta-User]

Klinke mich mal ein...

Aus dem anderen Thread habe ich gelernt, dass man wohl noch mehr festlegen sollte...:

Da ist zum einen "factor", damit sähe das so aus, oder (?):

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,factor=2.55Wenn wir wirklich ein userReadings brauchen, hätte ich gerne einen sauberen Trigger (brightness) und eine Erklärung, warum wir durch 2.54 teilen und nicht durch 2.55.

Weiter ist in dem anderen Thread die Rede davon, dass man bei den zigbee2mqtt-Dingern (oder allg. wohl allem, das Großschreibung im state liefert?), noch was weiteres braucht:

Code: [Auswählen]

On=state,valueOn=ON,valueOff=OFF Ist das zwischenzeitlich überholt oder der Grund, warum das Icon nicht paßt?
Oder betrifft das nur eine der Sprachsteuerungsvarianten?

Zu guter Letzt im Vorgriff auf weitere Varianten:
Da ist auch die Rede davon, dass man color_temp irgendwie gesteuert bekommen könnte. Da die Geräte teilweise sehr unterschiedliche Wertebereiche zu nutzen scheinen: Es müßte möglich sein, da "etwas Perl" beizugeben und den jeweiligen Wertebereich des Sliders auszuwerten. "Man" müßte nur wissen, was die jeweiligen Schranken sind und wie man das am besten berechnet...

Fragen über Fragen, aber Danke für den Start, es ist sicher ein guter Anfang bzw. eine gute Anknüpfung für eine sinnvolle Diskussion, was es denn jetzt braucht...

(Und auch hier der Hinweis: ich nutze das nicht und bin auf Zuarbeit angewiesen...!)

[TomLee]

Mein Stand ist nach wie vor der von damals in dem verlinkten Thread, mir fiel das Beispiel einfach nur direkt ein nachdem ich gelesen habe das es ab Morgen die speech-Templates geben wird, die Lösung mit userReadings eventuell nicht der
optimale (aber funtionierende) Weg ist und hier dann der richtige Ort zum finden der korrekten Lösung ist.
Ich weiß nicht mehr wie das genau war mit factor=2.55, hatte damals halt doch nicht geklappt nachdem Andre das vorgeschlagen hatte, habs jetzt nicht nochmal ausprobiert.
Bei der Frage zum Trigger komm ich nicht mit, es gibt das Reading brightness das wäre dann der Trigger
durch 2.54 zu teilen hab ich gemacht weil von z2m immer 254 zurückkommt und nicht 255, keine Ahnung ob das so richtig ist die Status in der Alexa-App stimmen auf jedenfall immer überein.
zu

Code: [Auswählen]

On=state,valueOn=ON,valueOff=OFF
Hab mir das eben (das erste mal) auch mal in der Home-App angeschaut, hier passt auch alles, warum sollte man es dann angeben ?

[Beta-User]

Hmmm, bin mal gespannt, was sonst noch an Rückmeldung kommt, wie gesagt: ich kann das alles nicht testen oder nachvollziehen, und die Aussagen in dem anderen Thread sind irgendwie - zumindest - in meiner Wahrnehmung widersprüchlich und vermutlich unvollständig...

userReadings wäre schon eine mögliche Lösung, aber zum einen ist das auf dem attrTemplate-Weg nicht ganz so einfach, weil man dann ggf. was ergänzen muß und nicht einfach überschreiben kann. Jedenfalls sollte die Berechnung wg. 255/254 keine großen Unterschiede liefern, evtl. muß man halt statt int runden, und das Reading auch nur aktualisieren, wenn ein update für brightness kommt... Kurz: Wenn es einen anderen Weg gibt, würde ich gerne darauf verzichten, userReadings zu nutzen.

Das mit "On=..." habe ich nur an der anderen Stelle gelesen und dann nachgefragt, weil du hier angemerkt hattest, dass mit den jetzt vorgeschlagenen Vorgaben kein Slider oder Schalter da wäre.

Wäre super, wenn Du ggf. mal austesten könntest (einfach mit einer Kopie eines deiner Devices), was man denn jetzt als Minimal-Lösung benötigt?

[TomLee]

Code: [Auswählen]

defmod MQTT2_zigbee_gu10_Test MQTT2_DEVICE 0x00158d0003274a6c
attr MQTT2_zigbee_gu10_Test IODev MQTT2_Server
attr MQTT2_zigbee_gu10_Test alexaName anton
attr MQTT2_zigbee_gu10_Test devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_gu10_Test genericDeviceType light
attr MQTT2_zigbee_gu10_Test group Wohnzimmer
attr MQTT2_zigbee_gu10_Test homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,factor=2.55
attr MQTT2_zigbee_gu10_Test icon light_control
attr MQTT2_zigbee_gu10_Test imageLink /fhem/deviceimages/mqtt2/404006-404008-404004.jpg
attr MQTT2_zigbee_gu10_Test model L_02a_zigbee2mqtt_light_dimmer
attr MQTT2_zigbee_gu10_Test readingList zigbee2mqtt/0x00158d0003274a6c:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_gu10_Test room Homekit,MQTT2_DEVICE,Test
attr MQTT2_zigbee_gu10_Test setList on:noArg zigbee2mqtt/0x00158d0003274a6c/set {"state":"ON"}\
off:noArg zigbee2mqtt/0x00158d0003274a6c/set {"state":"OFF"}\
brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/0x00158d0003274a6c/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr MQTT2_zigbee_gu10_Test setStateList on off
attr MQTT2_zigbee_gu10_Test webCmd brightness:toggle:on:off

setstate MQTT2_zigbee_gu10_Test ON
setstate MQTT2_zigbee_gu10_Test 2020-02-04 11:06:28 brightness 100
setstate MQTT2_zigbee_gu10_Test 2020-02-04 11:06:28 linkquality 5
setstate MQTT2_zigbee_gu10_Test 2020-02-04 11:06:28 state ON
Die Sprach-Templates werden mir nach update und restart nicht angezeigt.

Ich verstehe filter (schon gestern) nicht, wieso sollte speechrecognTesting in der CID stehen ?
Kannst du mir bitte filter nochmal erklären hab mich lange nicht mehr mit beschäftigt und wieder alles vergessen.

Müssten sie nicht spätestens angezeigt werden wenn

Code: [Auswählen]

{my @devices=devspec2array("TYPE=(siri|alexa|gassistant)");;return 1 if $devices[0];;return 0}1 zurückgibt ?

Aber händisch das Template zuweisen klappt 

Es wird mit dem o. a. Device in der Home und Alexa-App der Slider und Schalter angezeigt, 100% in den Apps entsprechen dem Wert 100 im Reading brightness, factor=2.55 greift also nicht.

[Beta-User]

Hmmm, kannst du dann bitte nochmal die vorherige Variante ausprobieren? Also

Code: [Auswählen]

attr DEVICE homebridgeMapping Brightness=brightness::brightness,minValue=0,maxValue=255
Dass die templates nicht angezeigt werden, ist genau die Absicht hinter der irritierenden Filterangabe . Man soll sie notfalls alleine anwenden können, aber nicht isoliert sehen; sonst hätte ich weitere desc: aufnehmen müssen usw.. Das machen wir ggf. dann, wenn alles funktioniert bzw. einen Eintrag im Wiki, wie es funktioniert...

Der option:-Ausdruck (und die folgenden) verhindert nur, dass die folgenden Zeilen im template ausgeführt werden in einem Umfeld, das die Attribute nicht kennt bzw. dienen der Vorbereitung, falls einzelne Sprachsteuerunglösungen was spezielles brauchen...

[TomLee]

Hab das schonmal erwähnt, Licht ist nicht so mein Ding, aber das mit max 255 brightness interessiert mich jetzt und sollte auch geklärt werden.
Wenn ich aus FHEM auf 255 stelle und 254 zurückkommt, dann ist doch 255 falsch ?
Dann müsste das zigbee-Template entsprechend angepasst werden.

[TomLee]

ohne factor wird kein Schalter und kein Slider in der Alexa-App angezeigt, in der Home App hat sich nichts geändert (Slider und Schalter vorhanden, 100% in der App entsprechen brightness 100.

[Beta-User]

Hmm, spekulier.... ist es evtl. umgekehrt herum gemeint, also so:

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=255,max=100,factor=2.55und ggf. testweise:

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=255,factor=1.00Was diese seltsame 255 angeht: Das ist irritierend, dass was anderes zurückgemeldet wird wie gesetzt. Ich vermute, dass da intern 2x gerundet wird. Aber der Wertebereich an sich geht ziemlich sicher bis 255 (intern zum Senden an die Leuchtmittel dürfte das ein HEX-Wert sein). Von daher ist auch eine Division mit 2.55 m.E. "richtiger" als eine mit 2.54 (obwohl sich das auf das Ergebnis nur um Ausnahmefall auswirken wird).

Mir ist im Prinzip egal, was an der Stelle als setter in den attrTemplates steht; wäre ggf. besser, das in den zigbee2mqtt-Thread zu plazieren (ich habe meine eigenen Devices nach deCONZ umgezogen => testen ist schwierig). Aber unabhängig davon muß es möglich sein, ein passendes homebridgeMapping hinzubekommen...

[KölnSolar]

Ich kann ehrlich gesagt der Diskussion nicht ganz folgen, weil das bei mir schon so lange her ist...
Ich hab damals "irgendein" template übernommen und dann irgendwie an meine tint colored/color_temp angepasst. Es funktioniert seitdem blendend(ich hab auch kein update mehr von zigbeemqtt gemacht u. damals selber lokale Anpassungen vorgenommen !)

Mich wundert aber, dass das template so kompliziert ist.  Mein define sieht so aus

Code: [Auswählen]

define Deckenlamped MQTT2_DEVICE zigbee_tint-Id
attr Deckenlamped userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 room_map structexclude
attr Deckenlamped IODev MQTT_FHEM_Server
attr Deckenlamped devStateIcon {zigbee2mqtt_devStateIcon255($name,"")}
attr Deckenlamped getList state:noArg state zigbee2mqtt/tint-Id/get {"$EVTPART0"}\
  brightness:noArg brightness zigbee2mqtt/tint-Id/get {"$EVTPART0"}\
  color_temp:noArg zigbee2mqtt/tint-Id/get {"$EVTPART0"}\
  color:noArg color zigbee2mqtt/tint-Id/get {"$EVTPART0"}\
  scene:noArg scene zigbee2mqtt/tint-Id/get {"$EVTPART0"}
attr Deckenlamped icon light_control
attr Deckenlamped model L_02b_zigbee2mqtt_colorbulbWithoutColorTemp
attr Deckenlamped readingList zigbee2mqtt/tint-Id:.* { json2nameValue($EVENT) }\
  zigbee2mqtt/tint-Id/availability:.* availability
attr Deckenlamped room Wohnzimmer
attr Deckenlamped setList on:noArg zigbee2mqtt/tint-Id/set {"brightness":"150","transition":10}\
  off:noArg zigbee2mqtt/tint-Id/set {"brightness":"0","transition":10}\
  brightness:colorpicker,BRI,0,12,255 zigbee2mqtt/tint-Id/set {"$EVTPART0":"$EVTPART1","transition":10}\
  color_temp:colorpicker,CT,153,10,556 zigbee2mqtt/tint-Id/set {"$EVTPART0":$EVTPART1,"transition":10}\
  hex:colorpicker,HEX,0,15,255 zigbee2mqtt/tint-Id/set {"color":{"$EVTPART0":"#$EVTPART1","transition":10}}\
scene:1,2,3,4,5,6 zigbee2mqtt/tint-Id/set {"$EVTPART0":$EVTPART1}\
param:1,2 zigbee2mqtt/tint-Id/set {"$EVTPART0":20}\
alert:noArg zigbee2mqtt/tint-Id/set {"$EVTPART0":"0x01"}
attr Deckenlamped stateFormat {lc ReadingsVal($name,"state",0)}
attr Deckenlamped webCmd toggle:on:off:brightness:color_temp:hex
Vielleicht hilft es ja.....
Grüße Markus

[Beta-User]

Äh, (ratlos): ich kann da gar keine spracherkennungsspezifischen Dinge erkennen...

Ist das am Ende eine völlig unnötige Diskussion, weil die Reading-Namen schon sowieso passen und man damit wohl nur den "genericDeviceType light" setzen müßte?

[OT]
scene, param und alert sieht interessant aus...
k.A., was das bewirkt, aber wenn jemand "sowas" auch haben will, bau' ich's gerne noch mit ein.

(Bitte aber nicht hier weiter diskutieren, das gehört nach zigbee2mqtt)
[/OT]

[KölnSolar]

dann nur kurz zur Auflösung der von mir verursachten Verwirrung

ich kann da gar keine spracherkennungsspezifischen Dinge erkennen...

Ich spreche nicht mit den tints  ; ich kommuniziere über alexa/FHEM/Fb mit ihnen 

scene, param und alert sieht interessant aus...

das sind eher "meine" individuellen Entwicklungen und nicht allgemeiner zigbee2mqtt-Standard(soweit ich weiß)

sorry 

[Beta-User]

Schon, aber Alexa muß ja auch irgendwoher wissen, dass es sich um eine Lampe handelt und nicht um einen Rollladen oder eine Jalousie usw.  ...
Nur weil man eine "brightness" einstellen kann, kann alexa vielleicht gut raten, aber mehr ist nicht, oder? (Lustiger wird es dann mit pct...).

(Im Ernst: Es war die Anregung von justme1968, den genericType zu setzen, siehe Diskussion hier: https://forum.fhem.de/index.php/topic,99195.0.html)

[TomLee]

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=255,max=100,factor=2.55100% in der App sind 15 im Reading

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=255,factor=1.00100% in der App sind 100 im Reading

HaHa. kurios, nach einer Gerätesuche mit

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=100,max=255wurde mir kurz ein Slider und Schalter angezeigt,der nach kurzer Zeit wieder verschwunden ist, in dieser Zeit hab ich auf 100 % in der Alexa-App gestellt dann steht das im Alexa-Log:

Code: [Auswählen]

2020-02-04 13:01:47 caching: MQTT2_zigbee_gu10_Test-brightness: set 255
[2020-2-4 1:01:47 PM] [FHEM]     caching: Brightness: set 255 (as string; from 'set 255')
  2020-02-04 13:01:47 caching: MQTT2_zigbee_gu10_Test-brightness: 255
[2020-2-4 1:01:47 PM] [FHEM]     caching: Brightness: 255 (as string; from '255')
  2020-02-04 13:01:47 caching: MQTT2_zigbee_gu10_1-abrightness: 100
[2020-2-4 1:01:47 PM] [FHEM]     caching: Brightness: 100 (as string; from '100')
  2020-02-04 13:01:47 caching: MQTT2_zigbee_gu10_Test-brightness: 254
[2020-2-4 1:01:47 PM] [FHEM]     caching: Brightness: 254 (as string; from '254')
Alles korrekt in der APP und FHEM
Ich hab die ganze Zeit nur auf den Slider und Schalter geachtet und gar nicht per Sprache geschalten
Nachdem der Slider nicht zurückkommt bleibt ja nur per Sprache zu steuern, ein Anton auf 100% ergibt ebenfalls mit dem vorgesehenen homebridgemapping (ohne factor):

Code: [Auswählen]

2020-02-04 13:27:59 caching: MQTT2_zigbee_gu10_Test-brightness: set 255
[2020-2-4 1:27:59 PM] [FHEM]     caching: Brightness: set 255 (as string; from 'set 255')
  2020-02-04 13:27:59 caching: MQTT2_zigbee_gu10_Test-brightness: 255
[2020-2-4 1:27:59 PM] [FHEM]     caching: Brightness: 255 (as string; from '255')
  2020-02-04 13:28:00 caching: MQTT2_zigbee_gu10_Test-brightness: 254
[2020-2-4 1:28:00 PM] [FHEM]     caching: Brightness: 254 (as string; from '254')
Auch in der Home-App passt alles, am Ende gibts mit dem homebridgemapping nur das Manko das das kein Slider und Schalter in der Alexa-App angezeigt wird, sry.

[Beta-User]

Hmm, mysteriös, das alles...

Kannst du bitte mal testen, ob das auch ohne das homebridgeMapping geht? (Klingt danach, als würde das aus dem setter extrahiert, wenn nichts angegeben ist => unnötig => weglassen...?!?)

Und dann mal bitte noch das mit "On=..." wg. der Großschreibung, ich hege immer noch den Verdacht, das mag die App nicht und wir müssen an der Stelle nachregeln (sofern "ON" bzw. "OFF" zurückgemeldet wird; wenn es das sein sollte, wäre auch das mMn. besser in den allg. Automatismen aufgehoben).

Danach bitte jeweils die Gerätesuche durchführen, das scheint wichtig zu sein.

[TomLee]

Natürlich ist es kurios, darum gibts ja den andern Thread und bei mir ein userreadings.

Ohne homebridgemapping und mit genericeDeviceType light ist nur ein/ausschalten möglich, es wird ein Schalter angezeigt, auf Prozent stellen (per Sprache) geht nicht -> Anton unterstützt das nicht.

Mit

Code: [Auswählen]

On=state,valueOn=ON,valueOff=OFFist kein Unterschied zu ohne homebridgemapping

Um 100% sicher zu sein lösche ich das Gerät noch vor/nach (das ist egal) dem Neustart von alexa-fhem und dann wird die Gerätesuche angestossen. Bei der Home App kann man nix löschen, dort wird nur ein restart von homebridge gemacht.

[Beta-User]

Fasse also zusammen:

Bisher beste Variante ohne userReadings war

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=100,max=255Die nächste Preisfrage ist, ob das nur für alexa gilt oder allgemein?

Dein Vorschlag wäre, das zu ergänzen um das userReadings, dann gibt es auch "Knöpfe" in der app, richtig?

Wäre dann (vereinfacht) so:

Code: [Auswählen]

attr DEVICE homebridgeMapping Brightness=sr_brightness,cmd=brightness,max=255,minValue=0,maxValue=100
attr DEVICE userReadings sr_brightness:brightness.* {sprintf("%1$d", ReadingsNum("$name","brightness",0)/255*100)}
Vereinfacht deswegen, weil das userReadings neu setzt und nicht erst prüft, ob schon was (anderes) da steht... Für die attrTemplate-Variante bedeutet das, dass wir Perl/regex brauchen, um den aktuellen Inhalt des Attributs zu lesen und erforderlichenfalls zu ergänzen; völlig fehlerfrei wird das vermutlich nie gehen, weil sich komische Überschneidungen schlecht voraussagen lassen...

Dann wäre wieder die Frage, ob das nur für alexa relevant ist, oder ob alle diesen Umweg brauchen und was wir machen, wenn alexa das anders will als homebridge (oder wie auch immer das jeweils heißt...)?!?

[TomLee]

Jetzt wird aus kurios mysteriös 

Das sprintf ist nicht korrekt, in sr_brightness steht ein Fehler, kein Wert:

Code: [Auswählen]

Error evaluating MQTT2_zigbee_gu10_Test userReading sr_brightness: Global symbol "$d" requires explicit package name (did you forget to declare "my $d"?) at (eval 70855) line 1.
In der Alexa-App wird der Schalter und der Slider aber angezeigt das Gerät zeigt "Gerät reagiert nicht" an, ein aus schalten (über den Schalter) ist nicht möglich, wenn man mit dem Slider auf 100 Prozentwert stellt wird trotz das das Gerät nicht reagieren soll brightness (hä ) auf 255 gestellt, der Slider springt aber immer zurück auf 0 egal auf welchen Wert man gestellt hatte.
Mglw. liegts ja einfach nur an Amazon, schliesslich wurde der Slider vorhin ja auch ohne userreadings kurzzeitig angezeigt.

[Beta-User]

Das ist vermutlich dann weniger mysteriös, sondern tatsächlich ein Fehler, hatte Infos von hier wohl fasch verstanden: https://perldoc.perl.org/functions/sprintf.html...

Schlicht das $ raus sollte bei sprintf weiterhelfen:

Code: [Auswählen]

attr DEVICE userReadings sr_brightness:brightness.* {sprintf("%1d", ReadingsNum("$name","brightness",0)/255*100)}
Dass Hin- und Rückweg unterschiedlich sind (sr_brightness und brightness) ist völlig klar, nur klappt das eben nicht, wenn der Reading-Wert bullshit enthält...

[TomLee]

Code: [Auswählen]

attr DEVICE userReadings sr_brightness:brightness.* {sprintf("%1d", ReadingsNum("$name","brightness",0)/255*100)}
Hätte den Nachteil das wenn der Wert 254 von z2m zurückkommt sr_brightness dann auf 99 springt (es also keine Status 100 gibt), also doch mit 254 rechnen.

[Beta-User]

"%.0f" scheint die bessere Variante zu sein...

(Ich hätte den Code gerne so, dass er auch mit Devices funktioniert, die 255 "können").

Eben habe ich ein update ins svn geschubst, da ist das sowie als experimentelles feature die Erweiterung eines vorhandenen userReadings-Attributs drin, allerdings beides erst mal auskommentiert. Testen wäre mal wieder gut...

(Ich sollte mich wohl auch nochmal einlesen, was diese mappings betrifft, irgendwie werde ich den Verdacht nicht los, dass es ohne den Umweg userReadings gehen müßte).

[TomLee]

Hab die 3 # rausgenommen und das normale homebridgemapping auskommentiert, das Template angewendet und alles klappt wie vorgesehen

[Beta-User]

Thx.
Hat man also nichts an vorhandenen userReadings, geht erst mal alles gut. Um die weiteren Varianten auszutesten:

Kannst du auch nochmal nachsehen, ob mehrfaches Anwenden des attrTemplate mit folgenden Varianten jeweils klappt, wobei Zeile 84 auskommentiert bleiben darf:

- wenn nur der "neue" userReadings-Eintrag gesetzt ist; (=> keine Änderung)
- ein anderes userReading angelegt ist; (=> ergänzt mit neu, Komma-getrennt)
- ein anderes + der "neue" userReadings-Eintrag da sind? (=> keine Änderung)

Danke vorab!

[TomLee]

Wenn man Zeile 84 wieder auskommentiert ist alles wie du erwartest.

Wen bei Punkt 2 das userReadings ergänzt wird wäre es optisch ansprechender wenn das mit Zeilenumbruch passiert

[TomLee]

Mit

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,factor=0.39216
passt alles.

[TomLee]

Stop.

Bei homekit/siri stimmt was nicht, testen kann ich aber erst später.

[Beta-User]

Egal wie: Erst mal Danke für's austesten bis dahin!

Eventuell müssen wir das auch (teilweise) unterschiedlich machen für unterschiedliche sr-Varianten (oder besser: die Maintainer jeweils auf Probleme hinweisen, damit das für alle möglichst unproblematisch und einheitlich funktioniert).

Wenn wir damit dann hoffentlich bald soweit durch sind: Was wäre das nächste Thema? Farbtemperatur?
Ich habe dazu im Hinterkopf, dass man (für manche sr-Varianten?) einen normierten Wertebereich braucht. Wenn dem so wäre, müßte man ein attrTemplate bauen, das das parametrisiert ergänzt... (aber vorher sollten "wir" die Logik dazu verstehen...)

("blind" wäre auch noch ein Thema, da brauchen wir ein weiteres für "inverted"; das sollte eigentlich schnell gehen).

[Beta-User]

Stop.

Bei homekit/siri stimmt was nicht, testen kann ich aber erst später.

Verdacht: Wir brauchen da zusätzlich das "On=state,valueOn=ON,valueOff=OFF"
(Wäre zwar schade, weil wir dann sehr viel mehr Logik brauchen zur unterschiedlichen Handhabung von groß- und kleingeschriebenen states, aber dann ist das halt so...)

[TomLee]

Wenn wir damit dann hoffentlich bald soweit durch sind

Ich glaub nicht dran und bei den Lampen gibts keine Farbtemperatur hab nur brightness.
Nochmal zurück, gestern mit userreadings hat mit Alexa (per Sprache und Schalter/Slider) und in der Home-App per Schalter/Slider alles geklappt. Dazu muss ich sagen das ich Siri nie nutze per Sprache hatte ich gar nicht getestet, kam mir gar nicht in den Sinn.

Heute habe ich ein update von homebridge-fhem version 0.5.3 auf 0.5.10 gemacht, jetzt (mit dem userreadings) geht kein ein/ausschalten mehr per Schalter und mit dem Slider auf einen Wert stellen klappt auch nicht mehr, der Slider schaltet die Lampe an auf den gewünschten Wert springt dann aber in x-Schritten zurück auf 0% und schaltet die Lampe aus.
Per Sprache kann man ein/auschalten und einen Prozentwert stellen, kein Problem.
Nehm ich hier ( zum userreadings) das On=state,valueOn=ON,valueOff=OFF rein. Ist alles wie oben beschrieben nur das mit dem Schalter ein/ausschalten möglich ist.

Jetzt zum factor=0.39216
 

Code: [Auswählen]

Brightness=sr_brightness,cmd=brightness,max=255,minValue=0,maxValue=100,factor=0.39216
In der Alexa App ist es Glückssache den Schalter/Slider angezeigt zu bekommen, wenn sie angezeigt werden sind 39% (auch per Sprache) brightness 254.
 
In der Home App springt der Schalter immer zurück zum Ein-Zustand, tippt man mal schneller bekommt man es irgendwie hin doch einzuschalten.
Mit dem Slider sind 39% (und Sprache) auch brightness 254.


Mit

Code: [Auswählen]

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.

[Beta-User]

Ähm, das muß ich erst mal versuchen zu verstehen....

MAn. müßte es (ohne irgendwelche userReadings! 100%*factor 0.39=39%...) so sein:

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,factor=0.39216 On=state,valueOn=ON,valueOff=OFFDiesen Code sehe ich hier aber nicht?!? Tippsfehlerchen ?

Schade mit der Farbtemperatur, aber vielleicht meldet sich dazu ja jemand?

[TomLee]

Mit

Code: [Auswählen]

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

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

Code: [Auswählen]

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

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

[Beta-User]

Danke für die Rückmeldung. Dann checke ich also zeitnah am besten folgendes ein (ohne "max=255") (?):

Code: [Auswählen]

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"?)

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

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

[TomLee]

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.

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

Also:

Code: [Auswählen]

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

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

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

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

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

[TomLee]

OK, 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?

[TomLee]

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

Vielleicht:

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

Code: [Auswählen]

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

Code: [Auswählen]

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

Code: [Auswählen]

On=state,valueOn=ON,valueOff=OFFund

ich 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

Code: [Auswählen]

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?

[TomLee]

Zusammengefasst kommt , bis jetzt, nur

Code: [Auswählen]

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:

Code: [Auswählen]

On=state,valueOn=on,valueOff=offOder könnte man diese Variante auch für beides nehmen...?

[TomLee]

Laut dieser Aussage und meinem Verständnis

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.

Code: [Auswählen]

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

[TomLee]

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.

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

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

Code: [Auswählen]

Brightness=brightness::brightness,minValue=0,maxValue=100,max=255,delay=trueSoll dann besser das rein statt der aktuellen factor-Variante?

In der Beziehung stehe ich immer noch auf dem Schlauch...

[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 , 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.

[TomLee]

Hab mich ausnahmsweise mal gern mit dem Thema Licht beschäftigt, aber nur weil ich mehrere Dinge die ich im Laufe der Zeit im MQTT2 Kontext mitgenommen habe hier mal in der Praxis umsetzen konnte.

Spricht was dagegen diese "Operationen" am MQTT2-Device vorzunehmen (im Template zu übernehmen), um sich das lästige homebridgeMapping zu sparen:

defmod MQTT2_zigbee_gu10_3 MQTT2_DEVICE 0x00158d000340eac3
attr MQTT2_zigbee_gu10_3 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude wzdl wzdl_map
attr MQTT2_zigbee_gu10_3 IODev MQTT2_Server
attr MQTT2_zigbee_gu10_3 alexaName decke3
attr MQTT2_zigbee_gu10_3 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_gu10_3 devicetopic zigbee2mqtt/0x00158d000340eac3
attr MQTT2_zigbee_gu10_3 event-on-change-reading state,pct,ct
attr MQTT2_zigbee_gu10_3 genericDeviceType light
attr MQTT2_zigbee_gu10_3 getList state:noArg state $DEVICETOPIC/get {"state":""}
attr MQTT2_zigbee_gu10_3 group Wohnzimmer
attr MQTT2_zigbee_gu10_3 icon light_control
attr MQTT2_zigbee_gu10_3 imageLink /fhem/deviceimages/mqtt2/404006-404008-404004.jpg
attr MQTT2_zigbee_gu10_3 jsonMap color_temp:ct\
color_temp_startup:ct_startup\
brightness:pct
attr MQTT2_zigbee_gu10_3 model zigbee2mqtt_light_cct
attr MQTT2_zigbee_gu10_3 readingList $DEVICETOPIC:.* { json2nameValue($EVENT,'',$JSONMAP) }\
$DEVICETOPIC:.* { $EVENT =~ m,brightness..(\d+), ? {"pct"=>sprintf('%.0f',$1/2.55)} : undef }
attr MQTT2_zigbee_gu10_3 room MQTT2_DEVICE,Wohnzimmer
attr MQTT2_zigbee_gu10_3 setList on:noArg $DEVICETOPIC/set {"state":"ON"}\
off:noArg $DEVICETOPIC/set {"state":"OFF"}\
pct:colorpicker,BRI,0,5,100 {$EVTPART1=sprintf('%.0f',$EVTPART1*2.55);;qq($DEVICETOPIC/set {"state":"on","brightness":$EVTPART1})}\
ct_startup:coolest,cool,neutral,warmest,previous $DEVICETOPIC/set {"color_temp_startup":"$EVTPART1"}\
ct:colorpicker,CT,153,2,370 $DEVICETOPIC/set {"color_temp":"$EVTPART1"}\
effect:blink,breathe,okay,channel_change,finish_effect,stop_effect $DEVICETOPIC/set {"$EVTPART0":"$EVTPART1"}
attr MQTT2_zigbee_gu10_3 setStateList on off effect
attr MQTT2_zigbee_gu10_3 webCmd toggle:on:off:pct:ct
attr MQTT2_zigbee_gu10_3 webCmdLabel Helligkeit\
:

setstate MQTT2_zigbee_gu10_3 ON
setstate MQTT2_zigbee_gu10_3 2021-10-18 17:43:11 color_mode color_temp
setstate MQTT2_zigbee_gu10_3 2021-10-18 17:43:11 ct 250
setstate MQTT2_zigbee_gu10_3 2021-10-18 17:43:11 ct_startup 65535
setstate MQTT2_zigbee_gu10_3 2021-10-18 17:43:11 linkquality 191
setstate MQTT2_zigbee_gu10_3 2021-10-18 17:43:11 pct 100
setstate MQTT2_zigbee_gu10_3 2021-10-18 17:43:11 state ON

Damit wird jetzt ohne homebridgeMapping der Slider und Status in der APP korrekt angezeigt und auch die Auswahl der Farbtemperatur ist möglich.
Das ON/OFF groß geschrieben wird ist Alexa egal, wie das mit Homebridge aussieht kann ich nicht testen, hab ich deinstalliert zur Zeit.
Für pct hab ich mich entschieden nachdem ich mir hier die Zeilen ab 1944 ff. angeschaut (nicht verstanden/begriffen) habe.

[Beta-User]

Also:
- das mit ct macht in jedem Fall Sinn und ist schon im svn .
- das nach pct zu ziehen, hatte ich "damals" aus irgendeinen Grund verworfen, vermutlich auch um Rundungsprobleme beim Hin- und Herrechnen nach Möglichkeit zu vermeiden. Da wir das mapping ja dann auch irgendwann hinbekommen hatten mit dem factor, sehe ich das jetzt nicht als den großen Nachteil an, und man muss nicht jedesmal rechnen, sondern nur, wenn man wirklich per Sprache steuert.

Bin im Moment noch nicht so recht überzeugt, ob sich das lohnt (weil wenn, dann relativ kurzfristig: alles...). Vielleicht äußert sich dazu ja mal noch jemand?

Ad #1944: Das sieht mir nach einer pauschalen Umrechnungslogik anhand des setter-Namens (und teilweise des TYPE) aus. RHASSPY macht das ähnlich, und vermutlich wäre es nicht die große Aktion, MQTT2_DEVICE und brightness als Bereich von 0-255 einzupflegen. Müßte man justme1968 mal anpingen, wie er das sieht. attrTemplate @m2 zieht das jedenfalls afaik stringent durch, dass brightness immer bis 255 geht...

[TomLee]

Zum Verständnis, wenn mans genau nimmt sind die Quotes um $EVTPART1, in der payload des setter ct, doch bei numerischen Angaben nicht korrekt, auch wenns so in der Doku steht ?

[Beta-User]

  vermutlich könnte/müßte man jetzt irgendwo mal nach den Spezifikationen für JSON-Blobs suchen, um rauszufinden, wie die reine Lehre aussieht. An sich würde ich annehmen, dass du zumindest insoweit recht hast, dass die Quotes entfallen dürfen.

Aber da es zum einen so in der Doku zu stehen scheint und zum zweiten auch in der Praxis funktioniert, würde ich das jetzt nicht um der reinen Lehre willen anpassen, selbst wenn es ohne auch funktioniert (was anzunehmen ist, da es mit brightness ja auch geht).

[TomLee]

Code: [Auswählen]

ct_startup:coolest,cool,neutral,warmest,previous $DEVICETOPIC/set {"color_temp_startup":"$EVTPART1"}=>

Code: [Auswählen]

ct_startup:coolest,cool,neutral,warmest,previous $\DEVICETOPIC/set {"color_temp_startup":"$EVTPART1"}

[TomLee]

[OT]

... irgendwo mal nach den Spezifikationen für JSON-Blobs suchen

Wo stehen denn für dich /euch die Spezifikationen, JSON.ORG ?, wenn mir dort jemand zeigt wo genau steht das ein in Quotes angegebener numerischer Wert ein String ist, bekommt er ein DANKE und einen Lolly dafür.
[/OT]

[rudolfkoenig]

wenn mir dort jemand zeigt wo genau steht das ein in Quotes angegebener numerischer Wert ein String ist, bekommt er ein DANKE und einen Lolly dafür.

Ich habe in der Suchmaschine "JSON specification numeric" eingegeben, und raus kam https://json-schema.org/understanding-json-schema/reference/numeric.html
Wenn man JavaScript etwas kennt, dann ist das auch natuerlich: "1"+1 => "11", 1+1=2, kann man leicht in der JS-Console des Browsers ausprobieren.

[TomLee]

Wenn man JavaScript etwas kennt

Noch nicht mal etwas, ich hab bisher erfolgreich einen großen Bogen drum gemacht, gefällt mir auch nicht wenn ich darüber nachdenke, aufgrund das (gerade) du das erwähnst , werd ich mich jetzt erst recht ab und an auch mal darin einlesen/damit befassen, bleibt offensichtlich nicht aus (auch ohne FHEM (-Forum)).

Danke