I have a zigbee colour LED and with MQTT explorer I’m able to:
Get the status: zigbee2mqtt/lamp/get {"state": ""} Turn it on/off: zigbee2mqtt/lamp/set {"state": "on"} / {"state": "off"} Change brightness: zigbee2mqtt/lamp/set {"brightness": VALUE} Change color: zigbee2mqtt/lamp/set {"color":{"x":"","y":""}}
Now I’d like to have some sort of dimmer for brightness and some way to select the color of the led in OpenHab.
I know I have to manually create a thing and a channel for each of these actions, when doing it so, I get confused with so many parameters.
I’ve seen some examples in the forum and I believe I could re-use and adapt some code, but not sure about the syntax, as it seems different (maybe different release? I’m using 4.2.0)
A Color Item can receive the same commands as a Dimmer and a Switch so you can use a Color Item as if it were a Dimmer or a Switch.
You don’t say what UI you are using though so it’s hard to say what the best approach may be. Are you using MainUI or sitemaps? Only the automatically built Overview tabs or creating your own pages?
The overall approach may change based on how you want to display and control the Item for these actions.
But in general yes, you will need to create at least a Channel for for the Color channel and you will need transformations to convert between HSB color coordinates which OH uses to what ever coordinate system zigbee2mqtt uses.
zigbee2mqtt is relatively popular so I’m sure there are examples online.
Once you have a color Channel working correctly, the oh-colorpicker widgets can be configred to show all the controls you need to control the light’s color, dimming, and on/off.
That is the syntax for .things files. If you choose to use .things files you’d place that information in a text file under $OH_CONF/things.
If you are using managed Things (i.e. through the UI) every possible property is presented to you in the form you see when you create the Channel. You just need to map the properties to the field in the form. The mappings should be relatively obvious (stateTopic maps to “Subscription Topic”, transformationPattern maps to “Incoming transformation pattern”, and so on).
If it’s a transformation that can be fully defined inline (e.g. JSONPATH) you put it into the form. So for transformationPatteron="JSONPATH:$.state" you’d enter JSONPATH:$.state in the field under “Incoming transformation pattern”.
Many transformations require reference to information stored elsewhere (e.g. a file of mappings, a script to run to transform the data). You can create those through Settings → Transformations or put them into a file under $OH_CONF/transformations.
The format of these files depends on the transformation being used.
Transformations are not always installed by default so be sure you have the add-ons installed. The script transformations (e.g. JS) come with the automation add-on (e.g. JS Scripting).
Assuming MainUI widgets, see oh-colorpicker-card - Color Picker Card | openHAB for standalone widget options and oh-colorpicker-item - Color Picker List Item | openHAB for list item widgets (i.e. the widgets that appear in the cards on the Locations, Equipment, and Properties tabs). You can customize these widgets by setting the “default X widget” metadata on the individual Item. Notice among the options are many different ways to choose color and brightness of the light.
Also be sure to check the marketplace. There are many light color control widgets you can install and use instead of configuring your own.
I’m still in the phase where I define the things and channels in the settings. I’m not in the UI phase yet.
My understanding is that if I define things “correctly” (although it seems there are many ways to be “correct”), the semantics will make its magic. The overview tab in the GUI shows the lamp and after I defined a “state” channel, an “item” appeared automatically to turn it on and off.
(I’m assuming an “item” is something that interacts with the channel)
Now I’m trying to create another channel for brightness, and I have no idea where to define the
{"brightness": VALUE}
part in the OH configuration. I’d say it would be in the channel definition, rather than in the UI, right? (I’m assuming that in the UI I’d only need to fill in the VALUE, not the parameter name)
I couldn’t find a way to past a picture here, but this is where I’m standing at the moment:
Created thing manually. It’s a Zigbee color led strip.
Created the state channel. An item was created automatically and I can turn the lamp on/off in the equipment default GUI. Semantics did her magic.
Now I’d like to create a channel for brightness. The mqtt topic is the same, but where do I define the brightness field?
UID: mqtt:topic:4fc98e3aee:e4aa4b2ee0
label: TV Light teste
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:4fc98e3aee
location: Living Room
channels:
- id: TV_Light_State
channelTypeUID: mqtt:switch
label: State
description: Light state
configuration:
commandTopic: zigbee2mqtt/TVLight/set
retained: true
qos: 1
stateTopic: zigbee2mqtt/TVLight/get
So, in other words, before messing with GUIs I’d like to have the semantics/things/channels properly defined so I have my life easier later on. Does this make sense?
I was just reading my own topic and this critical doubt appeared:
Should a channel be used for each of the device parameters or should a channel be simply “set” and “get”, and the parameters such as “brightness”, “state”, “color”, etc are passed to it via “items”?
In other words, what is the best practice?
a) Define a channel for “State”, another for “brightness”, and so on?
b) Define a generic channel that receives the parameters and its values?
Definitely make sure you read and understand the Concepts section of the docs. Words like Thing, Item, Link, Rule, Transformation, Persistence, Widget, etc are all terms of art in openHAB. They have very specific meanings in OH and interact in very specific ways.
The semantic model is something that is related to Items. It has nothing to do with Things.
It will be hard for you to understand what is going on and hard for us to help if you don’t have a basic understanding of these terms and how they interact.
This continues to show a lack of understanding. In addition to the concepts page, going through the Getting Started Tutorial is another important step.
If you are using managed configs (e.g. you are using MainUI to create/configure Things, Items, et al) you use the UI to do everything. If you are using .things, .items, et al to define your configuration, then you would use the UI to configure nothing that is already in those text files.
But the UI in this context is just the means through which you create/modify the configuration. So yes indeed, you would define {"brightness": VALUE} in the UI as part of the configuration for the MQTT Channel that is expected to publish and subscribe to such messages.
It is my understanding that zigbee2mqtt can be configured to use the Home Assistant standard for MQTT communication. When enabled, OH will automatically discover and configure the MQTT Things to work with zigbee2mqtt.
Beyond that, I cannot recommend strongly enough to look at one of the zigbee2mqtt tutorials on this forum because it can be challenging to get the MQTT config right as I understand it. Of course, the Zigbee binding could also be an option too if you are working with true Zigbee devices as opposed to Zigbee “like” devices.
Items don’t usually just get created on their own. Do you mean you use “add equipment to model” to create the Item?
You need to create a new Channel and choose “dimmer” as the type for the channel. You’ll need to configure a state transformation to extract the value from the JSON (JSONPATH) on incoming values and a command transformation to convert the raw number comming from OH to the JSON expected by the device.
You might need a REGEX filter in front to ignore messages that are on the same topic which are not brightness related.
When I talk about using the GUI, you are already doing this. You are using the UI to create/configure the Things. If you were not, you would be writing .things files using a text editor.
This too is covered in the concepts section of the OH docs.
A Thing represents a whole device. Each sensor and each actuator on the device is represented by a separate Channel. Channels get linked to Items. Just about everything else in OH works with Items.
* `color_xy`: To control the XY color (CIE 1931 color space) publish a message to topic `zigbee2mqtt/FRIENDLY_NAME/set` with payload `{"color": {"x": X_VALUE, "y": Y_VALUE}}` (e.g. `{"color":{"x":0.123,"y":0.123}}`). To read the XY color send a message to `zigbee2mqtt/FRIENDLY_NAME/get` with payload `{"color":{"x":"","y":""}}`. Alternatively it is possible to set the XY color via RGB:
* `{"color": {"r": R, "g": G, "b": B}}` e.g. `{"color":{"r":46,"g":102,"b":150}}`
* `{"color": {"rgb": "R,G,B"}}` e.g. `{"color":{"rgb":"46,102,150"}}`
* `{"color": {"hex": HEX}}` e.g. `{"color":{"hex":"#547CFF"}}`
Hope it helps someone that has the same difficulty as myself.
