Zigbee2mqtt revisited: No more ugly transformations

Did you try adding the following to your channel?

formatBeforePublish="{\"color\":{\"hsb\": \"%s, %s, %s\"}}"

(just copied and updated from the linked post)

yes, this i smy thing konfiguration, but no mqtt message is send after i change the colour :confused:

Type string : color "Color" [ stateTopic="zigbee2mqtt/Osram_Livingroom/color-hsb", commandTopic="zigbee2mqtt/Osram_Livingroom/set/", formatBeforePublish="{\"color\":{\"hsb\": \"%s, %s, %s\"}}" ]

Just to check:

  • How are you changing the colour? If it’s a Sitemap, what’s your configuration?
  • How do you know an MQTT message isn’t sent? What are you using to monitor this?

EDIT:

I guess you need to change your Channel type to color, not string, and therefore your Item type to Color also. Here’s what just worked for me:

thing channel

Type color : color "Color" [
    stateTopic="zigbee2mqtt/Osram_Livingroom/color-hsb",
    commandTopic="zigbee2mqtt/Osram_Livingroom/set/",
    formatBeforePublish="{\"color\":{\"hsb\": \"%s, %s, %s\"}}"
]

item

Color cColour "Colour" {channel="mqtt:topic:colourtest:color"}

sitemap

Default item=cColour label="Colour"

When changing the colour on the sitemap widget, I see the following in MQTT Explorer:

image

So the MQTT message is sending!

1 Like

i use mqttfx to sniff the mqtt traffic, in one of the last oh2.5 updates the color was broken, so i have setup it like that and this was working in oh2.5 with a string, with color type and this formatbeforepublish it is now working in OH3 :slight_smile: Thank you

Thanks for fantastic instructions guys!
I was able to get all up and running and finally have my StelPro line voltage Zigbee thermostat fully integrated into Openhab (happy to share configuration if anybody is interested.)

At the same time I am having trouble controlling SmartThings outlet (model OTP04, should be similar to SmartThings IM6001-OTP05 control via MQTT | zigbee2mqtt.io ).
Device is configured in zigbee2mqtt, I can see and control it from mosquitto_pub (plus relevant log entries):

mosquitto_pub -h localhost -t "zigbee2mqtt/smartthings_plug/set/state" -m "ON"
Zigbee2MQTT:info  2020-12-30 11:25:52: MQTT publish: topic 'zigbee2mqtt/smartthings_plug/state', payload 'ON'
Zigbee2MQTT:info  2020-12-30 11:25:52: MQTT publish: topic 'zigbee2mqtt/smartthings_plug/linkquality', payload '108'
mosquitto_pub -h localhost -t "zigbee2mqtt/smartthings_plug/get/state" -m ""
Zigbee2MQTT:info  2020-12-30 11:24:10: MQTT publish: topic 'zigbee2mqtt/smartthings_plug/state', payload 'ON'

However trying to control or monitor it from openhab does not result in any activity. Here is what I have in .things:

Bridge mqtt:broker:MyMQTTBroker [host="localhost", secure=false] {
    Thing topic SmarthingsOutlet "SmartThings Outlet" @ "Family Room" {
        Channels:
            Type switch : state "state" [ stateTopic = "zigbee2mqtt/smartthings_plug/get/state", commandTopic = "zigbee2mqtt/smartthings_plug/set/state", on="ON", off="OFF" ]
            Type number : linkquality "linkquality" [ stateTopic = "zigbee2mqtt/smartthings_plug/linkquality" ] 
    }
    // StelPro configuration is here...
}

And .items:

Switch Smarthings_Outlet_State "Smarthings Outlet State" {channel="mqtt:topic:MyMQTTBroker:SmarthingsOutlet:state"}
Number Smarthings_Outlet_Linkquality "Smarthings Outlet Linkquality" {channel="mqtt:topic:MyMQTTBroker:SmarthingsOutlet:linkquality"}

Any thoughts on what I am doing wrong?

Thanks all and Happy New Year, Vadim

change this to

`stateTopic = "zigbee2mqtt/smartthings_plug/state"`

The stateTopic is passive - won’t command anything in the get topic - so you need to subscribe to the main state topic to successfully receive the state.

But also: you may be hitting the bug where Things files aren’t properly loaded by openHAB after a save. Restart your openHAB for a quick fix, or do this.

1 Like

Thank you thank you thank you!
Combination of your suggested change and a restart did the trick, now all is working perfectly!

1 Like

Hey guys.
I’m desperate and need more eyes for this. I don’t understand what’s broken there.
I’m using zigbee2mqtt on my OH2.5 for some xiaomi devices and octoprint server. Everything works fine. Now I’m trying to set up OH3. So I did copy of my items and things files for new OH3 version. mosquitto works fine. I’m able co connect and I can see topics. But I don’t understand why I have everywhere NULL values in zigbee Items.


I’m using same bridge for zigbeemqtt and octoprint server, and octoprints channels works just fine. There are correct values in items. But zigbee devices not.
log from zigbee2mqtt looks also ok:

Any idea what I have wrong there?

Ok, it seems working after few hours :confused:

Can you advise how to adopt the color transform to OH3?
My thing:

UID: mqtt:topic:OH_MQTT:Hue_Go1
label: Hue Go 1
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:OH_MQTT
channels:
  - id: state
    channelTypeUID: mqtt:switch
    label: Status
    description: null
    configuration:
      commandTopic: zigbee2mqtt/Hue_Go1/set/state
      stateTopic: zigbee2mqtt/Hue_Go1/state
      postCommand: true
  - id: HueGo1_Brightness
    channelTypeUID: mqtt:dimmer
    label: Helligkeit
    description: null
    configuration:
      commandTopic: zigbee2mqtt/Hue_Go1/set/brightness
      min: 0
      stateTopic: zigbee2mqtt/Hue_Go1/brightness
      max: 253.98
      off: disabled
      on: enabled
  - id: HueGo1_ColorTemp
    channelTypeUID: mqtt:dimmer
    label: Farbtemperatur
    description: null
    configuration:
      commandTopic: zigbee2mqtt/Hue_Go1/set/color_temp
      min: 100
      stateTopic: zigbee2mqtt/Hue_Go1/color_temp
      max: 499.96
  - id: HueGo1_Farbe
    channelTypeUID: mqtt:color
    label: Farbe
    description: ""
    configuration:
      commandTopic: zigbee2mqtt/Hue_Go1/set/
      stateTopic: zigbee2mqtt/Hue_Go1/color-hsb
      onBrightness: 70

It works as long as I have the three other channels & items (for my Hue). As soon as I add your channel example from post #154 the thing will return an error message saying
" Status: OFFLINE
CONFIGURATION_ERROR
Remove and recreate: mqtt:topic:OH_MQTT:Hue_Go1:HueGo1_Farbe "

Thanks, this solution seems to be the cleanest so far!

Hi,
this guide had converted me to use zigbee2mqtt, purchase USB zigbee dongle, and ditch Xiaomi smart home hub. Thank you very much.

I have almost everything working, but there is only 1 that I still have problem. I have xiaomi wall switch, without battery. A command from OH do change the physical state, but OH state does not change. I suspect it is because of mqtt published the command and state almost instantly. Can anyone give pointer to me to fix that?

Thing topic xmbackyardsw "XM Backyard Switch" @ "Hall"
    {
        Channels:
            Type switch : state "state" [ stateTopic = "zigbee2mqtt/backyard_switch/state", commandTopic="zigbee2mqtt/backyard_switch/set/state", on="ON", off="OFF" ]
            Type string : action "action" [ stateTopic = "zigbee2mqtt/backyard_switch/action" ]
            Type string : click "click" [ stateTopic = "zigbee2mqtt/backyard_switch/click" ]        
            Type number : linkquality "linkquality" [ stateTopic = "zigbee2mqtt/backyard_switch/linkquality" ]               
    }
Switch	Light_SF_Backyard	"Backyard light"	<light>	(Group_XMSwitch, Group_LightsF2, Group_OutdoorLights)	["Lighting"]	{ channel="mqtt:topic:mosquitto:xmbackyardsw:state" }

2nd question:
How to set request to get device state/consumption/etc?
I know there is /zigbee2mqtt/deviceID/get channel, but does not know how send this get command periodically.

@WeirdlyChosen I had what sounds like the same issue with a Hue switch. It would send the triggered state, but immediately clear it and OpenHAB would miss the triggered state 75% of the time. This is what worked for me, since a Command is different than a State change:

  // Add "",postCommand=true" to incoming things like switches to make them generate OpenHAB commands instead of just state changes
  Thing topic test_hueswitch {
      Type string : click [ stateTopic="zigbee2mqtt/test_hueswitch/action", postCommand=true]
      Type number : battery [ stateTopic="zigbee2mqtt/test_hueswitch/battery"]
      Type number : counter [ stateTopic="zigbee2mqtt/test_hueswitch/counter"]
      Type number : linkquality [ stateTopic="zigbee2mqtt/test_hueswitch/linkquality"]
  }

Now my rule can check on command received instead of on state changed. OpenHAB doesn’t miss commands like it misses too-fast state changes.

From MQTT Things and Channels - Bindings | openHAB

  • postCommand: If true, the received MQTT value will not only update the state of linked items, but command it. The default is false. You usually need this to be true if your item is also linked to another channel, say a KNX actor, and you want a received MQTT payload to command that KNX actor.

Thank you for insight of postCommand, it really reduce the line length of the code compared commandTopic channel.
Unfortunately, this does not really help in my case. Using commandTopic channel send command to item, switch changed, but the state return back to old state. Same with using postCommand.

has someone add a osram rgbw bulb in the gui?
how do i need to create the channel?

when i use HSB Color as channel type

image

and color mode HSB
image

with the transformation
{“color”: {“hsb”: “%s,%s,%s”}}

i get an configuration error:

When adding an mqtt:dimmer channel for a zigbee light brightness value,
I use 0 as min value and 254 as max value for the channel.

There are two problems with 3.1.0 M3:

  • Values from 0 to 100 are converted to 0 to 254, but the value contains decimals e.g 152.76 . Zigbee2mqtt seems to handle this well, but I did define formatBeforePublish: “%d” so only integers should used. The %d seems to be ignored.
  • An item created for this mqtt:dimmer channel has a range of 0-254. I’d expect (and want) it to have a range of 0…100. For this item, the value of 100 already pushes a message with the value 254 to mqtt. A higher values of the dimmer slider are ignored by zigbee2mqtt, because they result in values above 254.
UID: mqtt:topic:1d261ff3ba:zitkamer_plafond_lamp
label: Zitkamer plafond lamp
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: offline
  availabilityTopic: zigbee2mqtt/bridge/state
  payloadAvailable: online
bridgeUID: mqtt:broker:1d261ff3ba
location: Zitkamer
channels:
  - id: state
    channelTypeUID: mqtt:switch
    label: State
    description: ""
    configuration:
      commandTopic: zigbee2mqtt/zitkamer_plafond_lamp/set/state
      stateTopic: zigbee2mqtt/zitkamer_plafond_lamp/state
      off: OFF
      on: ON
  - id: brightness
    channelTypeUID: mqtt:dimmer
    label: Brightness
    description: ""
    configuration:
      commandTopic: zigbee2mqtt/zitkamer_plafond_lamp/set/brightness
      min: 0
      formatBeforePublish: "%d"
      stateTopic: zigbee2mqtt/zitkamer_plafond_lamp/brightness
      max: 254

Any idea’s?
Also please let me know if I am doing something wrong.

use formatBeforePublish: “%s”

add by the item these metadata:

Thanks, but you are showing exactly why I love openHAB :slight_smile:

The fact ‘Things’ are not the end-devices, like (all?) other HA systems, but you create them yourself as ‘Items’ and have great power on how they are composed (maybe of different things), represented, behave and offered to e.g. Google and Alexa.

I know there are virtual devices possible on some systems, but to make them work well in a bi-directional way (setting / reading values as if it is a ‘normal’ device) requires a lot of manual work which often includes a lot of scripting.

So sorry, I forgot to mention your proposal is the ‘solution’ I am using. :blush:

But IMHO this is a solution that uses an item to fix a ‘broken’ thing channel, which is again what openHAB was ‘made for’. Still I’d expect if I configure a channel as percentage (which results in mqtt:Dimmer) and specify the abolsute min and max, stating the max value must represent 100%, the channel has a range of 0…100 when repesented to items and hides the fact it internally uses 0…254

Agree?

Sorry I don’t agree, zigbee2mqtt reflects the zigbee standard as mqtt. So brightness values should be 1…254 (0 is officially not legal, but most devices accept is as turn-off value)
The mqtt generic binding offers a percentage channel (Dimmer) which as far as I understand should always give a 0…100 range. If the underlying mqtt topic uses a different range, it should be translated, so channel 0…100 to min…max of topic, while also respecting the formatting setting.
This is how I understand the documentation, but in my case this seems not to work.
The strange thing is then when I look at the openHAB code (I didn’t do any debugging on it yet), this is also how I’d expect it to work…

did you create a issue at github?