MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[gvzdus]

Ich weiß nicht: Ich hab' eigentlich schon goutiert, wenn - wie bei MAX, Hue oder HM - gleich alles an Attributen da war...
Und solange die Regeln a la "shellies/shellybulb_.*" eindeutig sind, also nur auf ein Template passen.

Hier noch ein 2. Wurf:

Code Auswählen Erweitern

# shellybulb using original firmware.
name:shellybulb
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/color/0/command off\
  on:noArg shellies/DEVNAME/color/0/command on\
  brightness:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
attr DEVICE webCmd toggle:on:off:brightness
attr DEVICE genericDeviceType light
attr DEVICE icon light_control


Damit lässt sich auch die Helligkeit regeln. Unschön: Der Slider springt aber immer wieder auf "0" zurück, während die Lampe das Kommando übernimmt. Liegt das vielleicht daran, dass das Reading "status_brightness" heisst, und nicht "brightness"? Kann ich da das Default überbügeln? Muss jetzt aber forumsmäßig offline gehen...

[rudolfkoenig]

Liegt das vielleicht daran, dass das Reading "status_brightness" heisst, und nicht "brightness"?

Ja.

Kann ich da das Default überbügeln?

Befehl und Reading sollten gleich sein, das kann man z.Bsp. mit einem userReading erreichen.

[Beta-User]

Na ja, laß uns nicht lange über Automatismen diskutieren, das müßte eh' jemand einbauen, der Perl wirklich kann...

Zum 2. Wurf:
- "status_brightness" userReadings ginge natürlich, aber könnte man das reading nicht auch anders vom Namen her umbiegen? Kann aber nicht sagen, ob das mit einer EventMap ginge (ähnlich Tasmota, z.B. Zeile 100 v. mqtt2.template). Dann könnte man nämlich auch ohne Umwege zigbee2mqtt_devStateIcon255() nutzen... (mit einem klickbaren icon).
- Es sollte nur drinstehen, was man wirklich per default benötigt (braucht man "attr DEVICE genericDeviceType light"?)
Vielleicht kannst du auch mal ein list von der Bulb liefern (möglichst nach einigen verschiedenen Schaltvorgängen im Webinterface+dem, was der Event-Monitor liefert, wenn der MQTT2-SERVER auf rawEvent .* steht), damit wir da eine bessere Vorstellung von dem bekommen, was da datenmäßig abläuft?

[gvzdus]

So, bevor ich nun wirklich los muss, hier der Trace. Ist aber echt einfach: Bei jeder Änderung, ob über MQTT (hier: Kommando ein) oder über das Webfrontend vom Device wird einfach ein Komplettstatus in JSON gepublisht. Kniffeliger ist, wie komplett beim Setzen der JSON-String sein muss.

Code Auswählen Erweitern

2018.12.10 10:47:23 4: Connection accepted from MQTT2_FHEM_Server_192.168.0.31_12787
2018.12.10 10:47:23 5: CONNECT: (0)(4)MQTT(4)(2)(0)<(0)(17)shellybulb-3CC533
2018.12.10 10:47:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 CONNECT V:4 keepAlive:60
2018.12.10 10:47:23 5: PUBLISH: (0))shellies/shellybulb-3CC533/color/0/status{"ison":false,"mode":"white","re
d":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}
2018.12.10 10:47:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC
533/color/0/status:{"ison":false,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":
6395,"brightness":100,"effect":0}
2018.12.10 10:47:23 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/co
lor/0/status:{"ison":false,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"
brightness":100,"effect":0}
2018.12.10 10:47:23 5: SUBSCRIBE: (0)(133)(0)&shellies/shellybulb-3CC533/color/0/set(0)
2018.12.10 10:47:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 SUBSCRIBE
2018.12.10 10:47:23 4:   topic:shellies/shellybulb-3CC533/color/0/set qos:0
2018.12.10 10:47:23 5: SUBSCRIBE: (0)(134)(0)*shellies/shellybulb-3CC533/color/0/command(0)
2018.12.10 10:47:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 SUBSCRIBE
2018.12.10 10:47:23 4:   topic:shellies/shellybulb-3CC533/color/0/command qos:0

2018.12.10 10:48:23 5: PINGREQ:
2018.12.10 10:48:23 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PINGREQ

2018.12.10 10:48:48 5: MQTT2_FHEM_Server: PUBLISH shellies/shellybulb-3CC533/color/0/command on
2018.12.10 10:48:48 5: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 => shellies/shellybulb-3CC533/color/0/command:on
2018.12.10 10:48:48 5: PUBLISH: (0)"shellies/shellybulb-3CC533/color/0on
2018.12.10 10:48:48 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC533/color/0:on
2018.12.10 10:48:48 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:on
2018.12.10 10:48:48 5: PUBLISH: (0))shellies/shellybulb-3CC533/color/0/status{"ison":true,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}
2018.12.10 10:48:48 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC533/color/0/status:{"ison":true,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}
2018.12.10 10:48:48 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:{"ison":true,"mode":"white","red":224,"green":209,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}

2018.12.10 10:53:25 5: PUBLISH: (0)"shellies/shellybulb-3CC533/color/0on
2018.12.10 10:53:25 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC
533/color/0:on
2018.12.10 10:53:25 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/co
lor/0:on
2018.12.10 10:53:25 5: PUBLISH: (0))shellies/shellybulb-3CC533/color/0/status{"ison":true,"mode":"color","red
":119,"green":99,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":32,"effect":0}
2018.12.10 10:53:25 4: MQTT2_FHEM_Server_192.168.0.31_12787 shellybulb-3CC533 PUBLISH shellies/shellybulb-3CC
533/color/0/status:{"ison":true,"mode":"color","red":119,"green":99,"blue":255,"white":0,"gain":100,"temp":63
95,"brightness":32,"effect":0}
2018.12.10 10:53:25 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/co
lor/0/status:{"ison":true,"mode":"color","red":119,"green":99,"blue":255,"white":0,"gain":100,"temp":6395,"br
ightness":32,"effect":0}


[Beta-User]

Kannst du mal nur  "{ json2nameValue($EVENT) }" in der readingList verwenden? Das Problem scheint ja "nur" das prefix zu sein...

(muß ich evtl. in der zigbee2mqtt-bridge auch noch gradeziehen, da ist das "log_" auch nicht sooo toll).

Generell: ein list wäre hilfreich .

[gvzdus]

Funzt so. Aber ich hatte halt kein readingList im Template, weil schon so vom Auto-Create zwei angelegt werden. Also, Zustand nach Auto-Create:

Code Auswählen Erweitern

attr MQTT2_shellybulb_3CC533 readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }\
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0


Attribut readingList gelöscht, neu eingegeben:

Code Auswählen Erweitern

shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT) }

Ergebnis: Brightness-Slider ist stabil, prima! Und die Werte sind auch alle da. Aber sobald das nächste Event reinkommt, schlägt Auto-Create wieder zu und baut ein:

Code Auswählen Erweitern

shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT) }
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0

daraus.

[Beta-User]

Na ja, wenn die Werte mit dem 2-zeiligen Ergebniscode sauber reinkommen (und raus), ist ja alles gut.
Dann kann man zur Vermeidung von Verwirrung ggf. beide Zeilen in das template aufnehmen, oder?
Oder gibt das irgendwie einen Kuddelmuddel?

[gvzdus]

Naja, hübsch ist halt anders. Erstens sind alle Werte doppelt aufgeführt, zweitens klappte es erst beim 2. Reload des Templates und Hin- und Herschalten.
Ich vermute, für zigbee2bridge ist nötig, dass AutoCreate auch für neue Topics, die schon zur Anlage von Geräten geführt haben, die Geräte weiter bei einem neuen Event bearbeitet? Sonst hilft ja nur, AutoCreate wieder abzuschalten, wenn man die readings ohne Redundanz übersichtlich haben will.

[osr]

also ich würde es auch sehr begrüßen wenn

{ json2nameValue($EVENT, 'status_') }

zumindest optional wieder auf

{ json2nameValue($EVENT) }

angelegt würde, so wie es vor kurzem war.

Man könnte ja neben dem autocreate noch einen Zusatzschalter definieren ob bei autocreate gepräfixed werden soll oder nicht.

Also z. B. mqttautoprefix 0 oder 1 in der Konfiguration.

[Beta-User]

Naja, hübsch ist halt anders. Erstens sind alle Werte doppelt aufgeführt, zweitens klappte es erst beim 2. Reload des Templates und Hin- und Herschalten.
Ich vermute, für zigbee2bridge ist nötig, dass AutoCreate auch für neue Topics, die schon zur Anlage von Geräten geführt haben, die Geräte weiter bei einem neuen Event bearbeitet? Sonst hilft ja nur, AutoCreate wieder abzuschalten, wenn man die readings ohne Redundanz übersichtlich haben will.

Hattest du zwischendurch mal alle Readings (oder das ganze Device) gelöscht? Nicht, dass wir hier "Altlasten" diskutieren, die bei neuen Devices mit "richtigem" attrTemplate gar nicht mehr auftreten. (Man könnte in das template auch einen entsprechenden Löschbefehl ziemlich zu Beginn reinschreiben: "deletereading DEVICE .*".

also ich würde es auch sehr begrüßen wenn

Kannst du das bitte in dem Bugs-Thread thematisieren? Wir versuchen hier nur Zuarbeit zu machen; jetzt im wesentlichen auf Basis des "as is" Zustands der Module.
Zur Erläuterung, warum ich meine, dass das hier falsch ist: Es sieht zwar auf die Schnelle danach aus, als würde hier was doppelt angelegt. Das glaube ich aber nicht (sonst wäre es m.E. auch ein Bug, der dann wieder woanders zu diskutieren wäre), sondern es sind bestehende Readings, die eben nur nicht mehr aktualisiert werden. Beide Teile der readingList sollten für jeweils andere Readings zuständig sein.

Trotz OT kurz meine Meinung zur Frage, ob die prefix-Sache an sich gut ist:
Die ganze Geschichte mit MQTT2 ist noch neu, wer jetzt schon eingestiegen war, hat halt ggf. Aufwand, Dinge umzustellen (entweder in der readingList usw. oder in den Eventhandlern). Das ist nicht schön, aber wenn wir das alle durchgestanden haben, gibt es weniger Verwirrung, weil jedes Reading eine eindeutige Quelle hat.
Zum "Verbiegen" haben wir die templates, das ist auch eine gute Sache (wenn auch noch nicht an jeder Ecke von jedem verstanden und daher eben noch mit Verbesserungspotential). Es hilft bereits jetzt vielen Einsteigern sehr.

Mir kommt die "Bridge"-Sache auch nicht als zu speziell vor. Betrifft zwar scheinbar nur zigbee2mqtt (und den "Exoten" ESP-Milight-Hub), aber da mqtt ein universelles Protokoll ist, dürften zukünftig noch deutlich mehr Dienste auftauchen, die irgendwo Daten einsammeln und dann unter ihrer Kennung weitergeben (das wäre btw. auch ein FHEM, das seine Devices via MQTT zur Verfügung stellt...).

Fazit: Finde es tendenziell besser, das so zu lassen wie es ist. Abschaltbar wäre mir persönlich zwar egal, aber vermutlich bildet das dann wieder eine Fehlerquelle für noobs, die vergessen haben, dass es da eine Option gab, die sie geschaltet haben.

@gvzdus:
Würdest du ein list liefern, könnte man die Zeitstempel sehen. So mußte ich die Glaskugel bemühen...

EDIT: Noch ein Vertreter einer MQTT-Bridge: MySensors (in der MQTT-GW-Variante)...

[gvzdus]

Bitteschön!

Code Auswählen Erweitern

nternals:
   CFGFN     
   CID        shellybulb_3CC533
   DEF        shellybulb_3CC533
   DEVICETOPIC MQTT2_shellybulb_3CC533
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 26
   MQTT2_FHEM_Server_TIME 2018-12-10 12:21:56
   MSGCNT     26
   NAME       MQTT2_shellybulb_3CC533
   NR         228
   STATE      brightness
   TYPE       MQTT2_DEVICE
   READINGS:
     2018-12-10 12:21:56   blue            255
     2018-12-10 12:21:56   brightness      100
     2018-12-10 12:21:56   effect          0
     2018-12-10 12:21:56   gain            100
     2018-12-10 12:21:56   green           99
     2018-12-10 12:21:56   ison            true
     2018-12-10 12:21:56   mode            white
     2018-12-10 12:21:56   red             119
     2018-12-10 12:21:56   shellies/shellybulb-3CC533/color/0 on
     2018-12-10 12:21:56   state           brightness
     2018-12-10 12:19:42   status_blue     255
     2018-12-10 12:19:42   status_brightness 18
     2018-12-10 12:19:42   status_effect   0
     2018-12-10 12:19:42   status_gain     100
     2018-12-10 12:19:42   status_green    99
     2018-12-10 12:19:42   status_ison     true
     2018-12-10 12:19:42   status_mode     white
     2018-12-10 12:19:42   status_red      119
     2018-12-10 12:19:42   status_temp     6395
     2018-12-10 12:19:42   status_white    0
     2018-12-10 12:21:56   temp            6395
     2018-12-10 12:21:56   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   genericDeviceType light
   icon       light_control
   readingList shellies/shellybulb-3CC533/color/0/status:.* {json2nameValue($EVENT)}
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shellybulb-3CC533/color/0/command off
  on:noArg shellies/shellybulb-3CC533/color/0/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
   webCmd     toggle:on:off:brightness

Ja, ich habe definitiv das Device gelöscht, gespeichert und restartet. Du (ich) sehe auch im Log bei jedem Status-Update:

Code Auswählen Erweitern

2018.12.10 14:04:47 5: MQTT2_FHEM_Server: dispatch autocreate:shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:{"ison":false,"mode":"white","red":119,"green":99,"blue":255,"white":0,"gain":100,"temp":6395,"brightness":100,"effect":0}


Der Prefix "status" ist ja da, weil das Topic am Ende "status" heisst - daher wird es in 10_MQTT2_DEVICE.pm geholt. Allerdings gibt es halt (möglicherweise mehrere) Devices, die nur ein einziges Topic haben, wo dann das Prefix für die garantierte Eindeutigkeit der readings nicht nötig ist.

Hoffentlich liest Rudolf das jetzt und entscheidet, wie man das am besten löst.

[Beta-User]

OK, der Reihe nach (kann aber auch sein, dass ich mich irre):

autocreate erkennt: "Ah, neues device" => readingList wird erstellt (mit prefix).
Dann template wird angewandt: "Ah, andere Umwandlung, neue Reading-Namen". Die werden dann befüllt, deswegen unterscheiden sich die Reading-Timestamps um 2 Minuten . Wäre es dasselbe Event, wäre es gleich (eine Sekunde Differenz max.).

Man könnte in das template auch einen entsprechenden Löschbefehl ziemlich zu Beginn reinschreiben: "deletereading DEVICE .*".

Kannst du daher das bitte noch versuchen? Dann sollten die alten Readings verschwinden und dann nur noch neue kommen .

Edit, um es noch spezifischer zu machen:

Code Auswählen Erweitern

# shellybulb using original firmware.
name:shellybulb
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
deletereading DEVNAME status_.*
...

[osr]

Also habe jetzt mal in my.template folgendes für meine Wemos hinterlegt:

name:WemosD1
filter:TYPE=MQTT2_DEVICE
attr DEVICE readingList \
  tele/DEVICE/LWT:.* LWT\
  tele/DEVICE/STATE:.* { json2nameValue($EVENT) }\
  tele/DEVICE/SENSOR:.* { json2nameValue($EVENT) }\
  stat/DEVICE/RESULT:.* { json2nameValue($EVENT) }
deleteReading DEVICE .*

Das Problem mit den STATE_ ... ist dass dann z. B. für POWER, POWER1, ... verschiedene Readings angelegt werden. Interessieren tut aber eigentlich nur der neueste. Wenn im STATE_POWER1 of on gesetzt ist, ist das der aktuelle Status für POWER1 egal ob vorhin mal ein cmd mit POWER1 kam mit off. Dadurch ist der Status immer richtig. Egal ob über ein cmd.../POWER subscribe oder ein RESULT oder ein STATE_ ein Wert kam, der neueste ist der Richtige. Dadurch kann man Störungen, wenn mal irgendwas nicht geklappt hat sauber erkennen und FHEM zeigt immer den korrekten Status an. Durch die ganzen Präfix-Geschichten unterlaufe ich das wieder. Deswegen ist die Sache mit dem hinzugefügten Präfix zwar sauber, aber zumindest für mich, nicht besser.

Wohin sollte ich das denn nun am besten Posten als Verbesserungsvorschlag mit der Konfiguration?

[Beta-User]

Wohin sollte ich das denn nun am besten Posten als Verbesserungsvorschlag mit der Konfiguration?

Rudi liest hier grundsätzlich mit. Von daher ist es "an sich" hier richtig.

Ein paar Anmerkungen, was mir auf die Schnelle auffällt:
- "WemosD1" ist eine bestimmte ESP8266-Hardware, auf der ganz unterschiedliche firmwares laufen können. Ist das Tasmota? Dann sollte der name: auch irgendwas mit Tasmota beinhalten . Wenn es was anderes ist, dann eben das.
- Eine kurze Erläuterung wäre nicht schlecht (Kommentare beginnen immer mit #).

Wenn ich das richtig verstanden habe, geht es dir um "tasmota_general_without_prefixes" (use this for "classic" behaviour of tasmota flashed devices to avoid any prefixes in reading names).

Optimal wäre ein Patch für mqtt2.template (howto), aber wenigstens Code-Tags (#-Taste oben) wären nett .

[gvzdus]

Und nun wieder der Kollege mit seiner ollen Lampe

Ja, die Idee mit dem "deletereading" im Template war gut. Denn der AutoCreate "verbessert" immer nur das "fehlende"

Code Auswählen Erweitern

shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
- damit kann man leben oder autocreate abschalten.

Inzwischen bin auch schon recht dicht vor dem Finale:
- Farbtemperatur funzt
- Aus den Einzelwerten für red, green, blue einen Wert "rgb" wie bei den anderen Kindern basteln, um den Colorpicker zu füttern, funzt.

Wo es hakt: das zigbee2mqtt_RGB2JSON gescheit weiterzuverarbeiten, um eine Farbe zu setzen. So, wie ich das definitiert habe, landet bei der Farbänderung

Code Auswählen Erweitern

2018.12.10 16:45:58 5: MQTT2_FHEM_Server_192.168.0.26_64922 shellybulb-3CC533 => shellies/shellybulb-3CC533/color/0/set:{"ison":"true","mode":"white","rgb":zigbee2mqtt_RGB2JSON(59ffac)}
im Logfile.

Gesamtsituation:

Code Auswählen Erweitern


Internals:
   CFGFN     
   CID        shellybulb_3CC533
   DEF        shellybulb_3CC533
   DEVICETOPIC MQTT2_shellybulb_3CC533
   IODev      MQTT2_FHEM_Server
   LASTInputDev MQTT2_FHEM_Server
   MQTT2_FHEM_Server_MSGCNT 63
   MQTT2_FHEM_Server_TIME 2018-12-10 16:45:28
   MSGCNT     63
   NAME       MQTT2_shellybulb_3CC533
   NR         271
   STATE      rgb
   TYPE       MQTT2_DEVICE
   OLDREADINGS:
   READINGS:
     2018-12-10 16:45:28   blue            255
     2018-12-10 16:45:28   brightness      52
     2018-12-10 16:45:28   effect          0
     2018-12-10 16:45:28   gain            100
     2018-12-10 16:45:28   green           99
     2018-12-10 16:45:28   ison            true
     2018-12-10 16:45:28   mode            white
     2018-12-10 16:45:28   red             119
     2018-12-10 16:45:59   rgb             7763FF
     2018-12-10 16:45:28   shellies/shellybulb-3CC533/color/0 on
     2018-12-10 16:45:59   state           rgb
     2018-12-10 16:45:28   temp            5290
     2018-12-10 16:45:28   white           0
Attributes:
   IODev      MQTT2_FHEM_Server
   genericDeviceType light
   icon       light_control
   readingList shellies/shellybulb-3CC533/color/0/status:.* {json2nameValue($EVENT)}
shellybulb_3CC533:shellies/shellybulb-3CC533/color/0:.* shellies/shellybulb-3CC533/color/0
   room       MQTT2_DEVICE
   setList    off:noArg shellies/shellybulb-3CC533/color/0/command off
  on:noArg shellies/shellybulb-3CC533/color/0/command on
  brightness:colorpicker,BRI,0,1,100 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
  temp:colorpicker,CT,3000,10,6500 shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","$EVTPART0":"$EVTPART1"}
  rgb:colorpicker,RGB shellies/shellybulb-3CC533/color/0/set {"ison":"true","mode":"white","rgb":zigbee2mqtt_RGB2JSON($EVTPART1)}
   userReadings rgb {sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}
   webCmd     toggle:on:off:brightness:temp:rgb