MQTT2+Shelly: erste Konfiguration und template-Entwicklung

Begonnen von miggun, 03 Dezember 2018, 21:05:34

Vorheriges Thema - Nächstes Thema

Beta-User

Habe mal den sL-Vorschlag als "dimUp" bzw. "dimDown" eingebaut. Damit sollte man durch ein "einfaches" mehrzeiliges devStateIcon fast denselben Effekt erzielen können (aber ohne Rundung, ggf. muß die Schreibweise noch angepaßt werden).

Ich hoffe mal sehr, dass der Shelly bei 109% dann eben auch ein 100% liefert (bzw. 0% bei -8) und nichts seltsames anstellt ;D .

Da im Template der dimmer-slider drin ist, wollte ich das UI nicht ebenfalls via Template "zwangsweise" erweitern.

Ansonsten bist du hier schon richtig, wobei das mit dem dreifachen Icon (evtl. in der einfacheren Form mit den "icon-kompatiblen" (?) settern) ganz gut ins Wiki passen könnte.

ÜBERHAUPT:
Vor "langem" habe ich mal einen Wiki-Artikel gebastelt: https://wiki.fhem.de/wiki/DeviceOverview_anpassen
Damals hatte ich verwendet, was grade verfügbar war... heute würde ich sagen: "suboptimal".

Daher: Hat jemand Lust, die vollständige Konfiguration eines MQTT2_DEVICE "zu Fuß" Schritt für Schritt zu erläutern? Ist zwar mit setList und readingList etwas "speziell", aber sonst...? Mein Lieblingsdevice dabei wäre ein einkanaliger Shelly mit Strommeß-Funktion (oder erst ein Kanal aus einem Mehrkanaligen und dann als "Bonus" die weiteren Kanäle). Im Ergebnis darf dann gerne rauskommen, was auch ein attrTemplate machen würde, man muß also nix erfinden, aber eben z.B. ein paar Screenshots machen.
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

stratege-0815

Hallo zusammen,
zuerst einmal ihr habt hier ja schon großartiges geleistet. Ich habe meinen Shelly Dimmer über mqtt2 blitzschnell einrichten können.
In FHEM tut er auch alles was er soll, leider gibt es via Homebridge in Apple Home zwei Fälle die nicht funktionieren bzw. wo in Apple Home der Status nicht richtig upgedatet wird.

Fall1: Der Dimmer wurde via Apple Home oder FHEM eingeschaltet. Schalte ich den dimmer nun direkt am Schalter aus updatet auch der Status in FHEM, aber nicht in Apple Home.

umgekehrt dazu

Fall2: Der Dimmer ist ausgeschaltet, Schalte ich den dimmer nun direkt am Schalter ein updatet auch der Status in FHEM, aber nicht in Apple Home.

Apple Home ist bei mir die "Enduser GUI" mit dem besten WAF, daher will ich auch dort alles richtig dargestellt haben. Zum Beispiel für en Fall2 müsste ich dann in Apple Home den Dimmer erst einmal anschalten (obwohl er ja tatsächlich schon an ist) um ihn dann via Apple Home ausschalten zu können.

Ich habe den Dimmer über das Template eingerichtet und kein zusätzliches homebridge Mapping aktiv.

Beta-User

Vorab mal Danke für das Feedback - auch im Namen aller, die hier und anderswo ihren Inut geliefert haben, damit das läuft wie es läuft :) .

Was das Sprachsteuerungsthema angeht: Aktuelles template verwendet? Fragen (sireName usw.) beantwortet?
Oder ging da was schief?

(MaW: ein "list -r" wäre - wie meistens - förderlich, um die Glaskugel vorher zu putzen...).

Wenn das in diesen Basisangaben grundsätzlich paßt, ist es m.E. kein Problem, das wir hier in diesem Rahmen lösen können. Das wäre dann vermutlich besser im Sprachsteuerungsbereich aufgehoben.
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

ZitatIch habe den Dimmer über das Template eingerichtet und kein zusätzliches homebridge Mapping aktiv.

Zeig doch mal deine jetzige Definition, weil hier war noch ein merkwürdiges homebridgeMapping aktiv.
Hab die Zusammenhänge auch noch nicht ganz verstanden, bin aber der Meinung zu sehen das wir das hier gemeinsam lösen können, vermutlich ? ohne homebridgeMapping.

Gruß

Thomas

Beta-User

@TomLee: Danke für die Rückkoppelung.

@stratege-0815:

Wenn ich schlechtgelaunter Moderator hier in diesem Bereich wäre, würde ich mir jetzt überlegen...

Kurz:
Cross- und Doppelpostings sind an sich sch..., und vielleicht noch tolerabel, wenn man das entsprechend kennzeichnet. Aber ohne Hinweis, grade mal 20 Min. nach dem anderen Post? Finde jedenfalls ich "nicht gut"...
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

flummy1978

Holla,

freut mich, dass ich mit meinem Beispiel zur Bequemlichkeit / Funktionserweiterung dazu beitragen konnte  ( Ich glaube das dürfte meine erste "Verwendung" in einem offiziellem Modul sein  ::) )

Bin nicht sicher ob ich das wirklich richtig verstanden habe:
Zitat von: Beta-User am 01 April 2020, 10:57:50
Daher: Hat jemand Lust, die vollständige Konfiguration eines MQTT2_DEVICE "zu Fuß" Schritt für Schritt zu erläutern? Ist zwar mit setList und readingList etwas "speziell", aber sonst...? Mein Lieblingsdevice dabei wäre ein einkanaliger Shelly mit Strommeß-Funktion (oder erst ein Kanal aus einem Mehrkanaligen und dann als "Bonus" die weiteren Kanäle). Im Ergebnis darf dann gerne rauskommen, was auch ein attrTemplate machen würde, man muß also nix erfinden, aber eben z.B. ein paar Screenshots machen.[/b]
Ich kann mir nicht vorstellen, dass viele die Geräte von Hand anlegen *grübel*

Ehrlicherweise glaube ich, dass viele (Anfänger) dort so handeln werden wie ich das auch gemacht habe:
Template benutzen, rausschmeissen was man nicht braucht und ggf erweitern. Ich finde die Template sehr sehr sinnvoll und bedingt dadurch, dass man am Anfang nicht weiß was man alles braucht, sehr hilfreich.

Falls ich Blödsinn verstanden habe, bitte nochmal um Erklärung ;)

Viele Grüße
Andreas

Beta-User

Na ja, mein Gedanke ist folgender:

Viele haben Schwierigkeiten was nach ihren Vorstellungen umzukonfigurieren. Dann fangen sie "irgendwo" an - "lustigerweise" sehr häufig am falschen Ende...

Eine _mögliche_ Ursache ist die, dass (noch) nirgends so richtig erklärt wird, wie die Dinge aufeinander aufbauen. Das ist in weiten Teilen eigentlich gar nicht MQTT2_DEVICE-spezifisch, sondern (jedenfalls zu großen Teilen) eigentlich bei jedem FHEM-Device "gleich". Und mein damaliger Versuch im Wiki geht zwar in diese Richtung, war aber nicht optimal, weil diese HM-Teile nicht so verbreitet sind wie heute die Shelly (oder Tasmota)...

Das soll also dazu dienen, an einem Gerät, mit dem die User "vertraut sind" zu Erläutern, was attrTemplates (im Ergebnis) machen - so kann man die Zusammenhänge besser verstehen und dann auch auf andere Geräte übertragen (und zwar in der richtigen Reihenfolge...). (Und gerade wegen der attrTemplate kann man ja auch immer wieder zurück auf einen definierten Zustand, das fördert hoffentlich den Spieltrieb ;D ).

Ansonsten bin ich sehr froh, dass die Devise "Template anwenden, fertig das Gericht" gelebte Praxis ist und habe auch keine Pläne, das nicht weiter in diese Richtung zu supporten :) .

Nun klarer, was mein Gedanke dabei ist?

(Falls jetzt die Frage kommt: warum nicht mit einem Tasmota?
Weil man den Shelly "as is" verwenden kann - ist ein typisches Einsteigergerät. Microcontroller umzuprogrammieren ist meistens nicht grade der Start in die FHEM-Welt...
Und wir brauchen irgendwie wieder eine aktuelle Einsteigerdoku, oder sehe ich das falsch?)
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

stratege-0815

Hallo zusammen,
ja, ihr habt Recht. Das war nicht gut doppelt zu posten - sorry dafür. :-[

Ich habe das Thema hier "zusätzlich" gepostet weil ich es hier besser aufgehoben glaubte. Das MQTT Template macht wirklich einen super Job und bis auf die genannte Einschränlung geht auch alles auf Anhieb direkt ohne homebridge-mapping. Daher dachte ich auch es hier eher lösen zu können.

Zitat von: TomLee am 03 April 2020, 12:13:11
[...]bin aber der Meinung zu sehen das wir das hier gemeinsam lösen können, vermutlich ? ohne homebridgeMapping.[...]

Das war dabei auch meine Idee, je weniger Mapping um so besser.

Gerne versuche ich hier noch einmal das Problem zu schildern und liefere hier das gewünschte "list -r".


define Dimmer_Schlafzimmer MQTT2_DEVICE shellydimmer_D45DA1
attr Dimmer_Schlafzimmer IODev myMQTT2_SERVER
attr Dimmer_Schlafzimmer devStateIcon {my $lderr = ReadingsVal($name,"loaderror","true") eq "true"?"10px-kreis-rot":"10px-kreis-gruen";;;; my $light = ReadingsVal($name,"ison","false") eq "true"?"on":"off";;;; my $cons = ReadingsVal($name,"light_0_power","unknown");;;; FW_makeImage($lderr)."<a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a><div>Leistung: $cons</div>"}
attr Dimmer_Schlafzimmer genericDeviceType light
attr Dimmer_Schlafzimmer icon light_control
attr Dimmer_Schlafzimmer jsonMap brightness:pct
attr Dimmer_Schlafzimmer model shellydimmer
attr Dimmer_Schlafzimmer readingList shellies/shellydimmer-D45DA1/light/0/status:.* {json2nameValue($EVENT,'',$JSONMAP)}\
  shellies/shellydimmer-D45DA1/temperature:.* temperature\
  shellies/shellydimmer-D45DA1/temperature_f:.* temperature_f\
  shellies/shellydimmer-D45DA1/overtemperature:.* overtemperature\
  shellies/shellydimmer-D45DA1/overload:.* overload\
  shellies/shellydimmer-D45DA1/loaderror:.* loaderror\
  shellies/announce:.* { $EVENT =~ m,..id...shellydimmer-D45DA1...mac.*, ? json2nameValue($EVENT) : undef }\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/online:.* online\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/announce:.* { json2nameValue($EVENT) }\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0:.* light_0\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0/power:.* light_0_power\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0/energy:.* light_0_energy\
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/input/0:.* input_0
attr Dimmer_Schlafzimmer room Homekit,MQTT,Schlafzimmer
attr Dimmer_Schlafzimmer setList off:noArg shellies/shellydimmer-D45DA1/light/0/command off\
  on:noArg shellies/shellydimmer-D45DA1/light/0/command on\
  pct:slider,0,1,100 shellies/shellydimmer-D45DA1/light/0/set {"turn": "on","brightness": $EVTPART1}\
  x_mqttcom shellies/shellydimmer-D45DA1/command $EVTPART1
attr Dimmer_Schlafzimmer webCmd pct:on:off

setstate Dimmer_Schlafzimmer off
setstate Dimmer_Schlafzimmer 2020-03-31 21:37:31 brightness 20
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 fw_ver 20200309-104554/v1.6.0@43056d58
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 has_timer false
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 id shellydimmer-D45DA1
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:54 input_0 0
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 ip 192.168.1.62
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 ison false
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 light_0 off
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 light_0_energy 854
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 light_0_power 0.00
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 loaderror 0
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 mac F4CFA2D45DA1
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 mode white
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 new_fw false
setstate Dimmer_Schlafzimmer 2020-04-03 11:04:08 online true
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 overload 0
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 overtemperature 0
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 pct 50
setstate Dimmer_Schlafzimmer 2020-04-03 15:13:12 state off
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 temperature 52.20
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 temperature_f 125.96
setstate Dimmer_Schlafzimmer 2020-04-03 15:49:15 timer_remaining 0


Zitat von: Beta-User am 03 April 2020, 11:30:17
Was das Sprachsteuerungsthema angeht: Aktuelles template verwendet? Fragen (sireName usw.) beantwortet?
Oder ging da was schief?

Es handelt sich nicht um ein Sprachsteuerungsproblem. Es geht um eine Synchronisierung bestimmter Statusänderungen von FHEM nach Apple Home. (Ich hoffte hier würden vielleicht auch andere Benutzer ihre Shelly Devices über die Apple Oberfläche steuern)

Ich habe hier den Shelly Dimmer mit einem Taster verbunden und den "one button mode" im shelly konfiguriert. Wenn der Dimmer per Tasterdruck am Schalter oder über FHEM eingeschaltet wird wird dieser Status auch in FHEM dargestellt, kommt aber nicht in der Apple Oberfläche an.

Schalte ich über Apple Home den Dimmer ein, stimmt auch dort der Status. Beim Ausschalten über FHEM oder den physischen Schalter passiert dann wieder der gleiche Effekt, in Apple Home wird nicht synchonisiert. Der letzte Status bleibt unverändert.

Ich hoffe ich habe das jetzt verständlich erklärt.


flummy1978

Holla,

ein wenig klarer wird es jetzt (glaube) ich schon. Wenn es darum geht den Einsatz des MQTT Templates vorzustellen und mit Screenshots etc zu untermalen, kann ich es gern mal probieren, muss allerdings auch dazu sagen, dass es ein paar Tage dauern kann bis ich dazu komme UND ich auch schon ewig lang keine Dokus / Erklärungen etc geschrieben hab, so dass ich das vorab jemandem Erfahrenem mal in die Hand drücken müsste ;)

Grüße
Andreas

TomLee

Bin mir nicht sicher, kann mich aber ja jemand verbessern wenn das Käse ist:

Ändere mal

shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0:.* light_0\
zu
shellydimmer_D45DA1:shellies/shellydimmer-D45DA1/light/0:.* state\

weiß nicht ob das nötig ist, vorsichtshalber würd ich aber homebridge noch neustarten.

stratege-0815

Zitat von: flummy1978 am 03 April 2020, 20:26:39
Holla,

ein wenig klarer wird es jetzt (glaube) ich schon. Wenn es darum geht den Einsatz des MQTT Templates vorzustellen und mit Screenshots etc zu untermalen, kann ich es gern mal probieren, muss allerdings auch dazu sagen, dass es ein paar Tage dauern kann bis ich dazu komme UND ich auch schon ewig lang keine Dokus / Erklärungen etc geschrieben hab, so dass ich das vorab jemandem Erfahrenem mal in die Hand drücken müsste ;)

Grüße
Andreas

Hallo Andreas,
Welche Bilder und Screenshots kann/sollte ich dazu beisteuern?

Ich werde auch dem Hinweis von TomLee noch nach gehen.

Gruß Jan

Beta-User

Zitat von: flummy1978 am 03 April 2020, 20:26:39
Holla,

ein wenig klarer wird es jetzt (glaube) ich schon. Wenn es darum geht den Einsatz des MQTT Templates vorzustellen und mit Screenshots etc zu untermalen, kann ich es gern mal probieren, muss allerdings auch dazu sagen, dass es ein paar Tage dauern kann bis ich dazu komme UND ich auch schon ewig lang keine Dokus / Erklärungen etc geschrieben hab, so dass ich das vorab jemandem Erfahrenem mal in die Hand drücken müsste ;)
Muß es wohl nochmal anders erklären:

Es geht NICHT darum, die Anwendung des attrTemplate-features zu zeigen, sondern Attribut für Attribut zu erläutern, welche Wirkung es jeweils funktional und optisch hat. (Teilweise muß man es wohl sogar Zeile für Zeile innerhalb eines Attributs machen, z.B. wenn es um "state" geht...).
Dabei spielt die Reihenfolge eine gewisse Rolle, man muß sich also überlegen, wann welches Element an der Reihe ist usw..

Das ganze muß auch nicht schnell gehen, und screenshots kann man nebenbei machen.

Formal wäre das Ziel, einen Satz Dateien zu haben:
- Den Artikel im Wiki-Quelltextformat (Beispiel: https://wiki.fhem.de/w/index.php?title=DeviceOverview_anpassen&action=edit). Ist ein bißchen "Blindflug", wenn man das noch nie gemacht hat, aber c&p m.E. kein Hexenwerk, notfalls bitte einen Wiki-Zugang beantragen (oder mal schauen, gibt bestimmt irgendwo einen Onlin-Parser, den man nutzen kann)...
- Die zugehörigen screenshots/Bilder. Da wäre eine  sinnvolle Namensvergabezu überlegen, dass es im "Wiki-Namespace" auch halbwegs klar ist, für was das "media"-Element steht.
- "Super-addon" wäre, ggf. das ganze noch mit dem als Beispielartikel genannten irgendwie zu "verbinden", genaue Vorstellungen wie, habe ich noch nicht, das bleibt ggf. auch eurer Fantasie überlassen (einfacher Link, einige (optische?) Teile hier, andere (funktionale?) da...

Nochmal: Das ganze soll möglichst so sein, dass ein Anfänger ohne große FHEM-Kenntnisse, wie wir sie alle mal waren, das einfach nachbauen kann und hoffentlich den einen oder anderen "aha"-Effekt hat...
(Wenn erfahrenere diesen Aha-Effekt auch haben: umso besser...)

Ich schau dann gerne nochmal drüber, auch bei Zwischenversionen, kein Ding :) .

Jetzt klarer?
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

flummy1978

Moinsen,

japp jetzt ist es um einiges klarer geworden. Da muss ich aber sagen, dass ich in diesem Fall tatsächlich der falsche Ansprechpartner wäre. In manchen Bereichen komme ich selbst kaum klar mit der Funktion und bin froh dass diese vorgegeben ist. Andere Bereiche wiederum les ich etwas dazu bis ich es verstehe und passe es dann an (wie zB die dimmUp dimm Down Funktion).

Ansonsten sieht meine Vorgehensweise bei allen (MQTT) Geräten so aus:

Gerät einbinden -> Autocreate abwarten -> erstelltes Log löschen -> überlegen was ich an dem Gerät alles angezeigt / geloggt /etc werden soll -> Template auswählen laden und testen -> Events etc anpassen -> devStateIcon anpassen ... fertig. Bisher habe ich fast nie was vermisst. Wenn doch, hab ich ne Lösung gefunden wie ich das lösen könnte. Anfängerfreundlich Alle Attribute Schritt für Schritt erklären und auswählen, das würde ich mir dann leider doch nicht zutrauen ;(  - Dafür bi ich einfach selbst zu viel Anfänger....

Viele Grüße
Andreas

Beta-User

...es war nur eine Frage, und du darfst selbstredend "nein" sagen.

Ich behaupte aber mal, dass dich das zwar einige Zeit kosten wird, du aber selbst einen großen benefit davon haben würdest, weil dann die Dinge wirklich klar wären... (Die Basics hast du nach meinem Eindruck soweit "drauf", dass das klappt (nicht ohne Frust, klar, aber im Ergebnis...))
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

87insane

#614
Hallo zusammen...

(Vermutlich) seit dem letzten shelly Firmware Update, kann ich meine shelly rgbw2 nicht mehr sauber über fhem schalten. Der komplette RGB Bereich macht nix. Im shelly selber geht es.

Der setlist Eintrag ist:
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/shellyrgbw2-661CD3/color/0/set {\"mode\":\"color\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellyrgbw2-661CD3/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}

Der string aber auf dem Zweig:
{"ison":true,"has_timer":false,"timer_remaining":0,"mode":"color","red":13,"green":215,"blue":255,"white":0,"gain":100,"effect":0,"power":10.10,"overpower":false}

Glaube hier wurden nur die werte (hex/RGB) angepasst oder?

Edit: https://shelly-api-docs.shelly.cloud/#shelly-rgbw2-mqtt

So hätte er es gern laut doku:
{ "mode": "color", /* "color" or "white" */
"red": 0, /* red brightness, 0..255, applies in mode="color" */
"green": 0, /* green brightness, 0..255, applies in mode="color" */
"blue": 255, /* blue brightness, 0..255, applies in mode="color" */
"gain": 100, /* gain for all channels, 0..100, applies in mode="color" */
"white": 0, /* white brightness, 0..255, applies in mode="color" */
"effect": 0, /* applies an effect when set */
"turn": "on" /* "on", "off" or "toggle" */ }

Da kann man im mqtt Teil auch nochmal alles sehen. Entweder steh ich gerade auf dem Schlauch oder verstehe was komplett falsch.

Gesendet von meinem LM-G810 mit Tapatalk