That mean that we can set the color with an MQTT command like : zigbee2mqtt/0x0017880102320dd8/set/color #FF0000 because of the condition || (typeof value === 'string' && value.startsWith('#')))
But we can’t do zigbee2mqtt/0x0017880102320dd8/set/color 100,100,100 because the condition require a Property (a JSON key).
As OpenHAB can only send colorRGB and colorHUE values, for now, there is no solution to control the color of a bulb without ugly transformation.
I would love to write a Pull Request to z2m but there is no easy way to distinguish RGB (255,255,255) values from HSB one (360,100,100).
Other solution would be to found a simple way to send color as Hex (#FF0000) from OpenHAB.
It works multiple ways, I think RGB is the easiest:
zigbee2mqtt/item/set/color with the value in RGB hex (so #FF0000 will be full red). I’m currently trying to figure out how to make it work with the colorpicker because it works from mqtt but the colorpicker wants to send these hue & saturation values that I don’t fully understant.
It also works with JSON providing the values in this format
{r:“255”,g:“0”,b:“0”}
the new version zigbee2mqtt 1.9.0 supports: "color values in HSB/HSV/HSL notation"
// Hue, saturation, brightness (in HSB space)
"hsb": "360,100,100"
At the moment it seems you can not set HSB/HSV/HUE value directly. You still have to use JSON with surrounding ‘color’ tag. So it’s now working with a small formatting, but without ugly transformation.
here is the working configuration for my Osram RGBW bulb:
.things
Thing topic osramrgbbulb "osramrgbbulb" {
Channels:
Type switch : power "Power" [ stateTopic = "zigbee2mqtt/0x7cb03eaa00ada0df/state", commandTopic = "zigbee2mqtt/0x7cb03eaa00ada0df/set/", on="ON", off="OFF" ]
Type string : color "Color" [ stateTopic = "zigbee2mqtt/0x7cb03eaa00ada0df/color-hsb", commandTopic="zigbee2mqtt/0x7cb03eaa00ada0df/set" , formatBeforePublish="{\"color\":{\"hsb\": \"%s\"}}" ]
}
The new version 1.9.0 now also supports output of payloads as JSON and plain attributes with the following option in configuration.yaml:
experimental:
# Optional: MQTT output type: json, attribute or json_and_attribute (default: shown below)
# Examples when 'state' of a device is published
# json: topic: 'zigbee2mqtt/my_bulb' payload '{"state": "ON"}'
# attribute: topic 'zigbee2mqtt/my_bulb/state' payload 'ON"
# json_and_attribute: both json and attribute (see above)
output: 'json'
There is a error in the documentation, the option is called “attribute_and_json” and works as expected, payload is transmitted in both flavours.
That will help me with migrating from MQTT 1 to MQTT 2.x as well as from JSON to plain attributes.
when
Channel 'mqtt:topic:be6e02f3:Cube:action' triggered
then
I’m not 100% sure if that will make a difference but it’s what I use and it works so worth a try. Also what is triggered? You may need to add that after the word triggered like below where START is used.
when
Channel 'astro:sun:local:civilDusk#event' triggered START
then
Thank you,friends. I used item based driven rules and this work fine for me.
rule "Zigbee2Mqtt Cube action"
when
Item Cube_Action received update
then
logError("xiaomicube", "cube action fired")
switch(Cube_Action.state.toString) {
case "slide": {
Sorry, I should have been clearer when asking: I don’t get the ITEMS part specifically.
I understand how “thing” references mqtt channel.
E.g. zigee2mqtt//… etc
But having defined things, why does one need to reference items like this:
“mqtt:topic:broker:0x00158d00015aa9b5:click”
And sometimes like this:
“mqtt:topic:mosquitton:osramrgbbulb:color”
?