Control Hue bulb via MQTT

I have a dimmer item controlled by Philips Hue and I would like to control the bulb additionally via MQTT from my ESP32. I use the following channel configuration:

channels:
-id: Light
 channelTypeUID: mqtt:dimmer
 label: Terrassenlicht
 description: “”
 configuration:
 commandTopic: pixxiDisplayESP32/status/light
 postCommand: true
 min: 0
 stateTopic: pixxiDisplayESP32/cmd/light
 max: 100

This is linked to the mentioned dimmer item.

Partly it is working as expected:

  1. When I Change the dimmer value in Openhab’s item view, pixxiDisplayESP32/status/light follows - o.k.
  2. When my ESP32 publishs a value to pixxiDisplayESP32/cmd/light, the item value changes - o.k.

But for the second case (ESP32 publishs a value to pixxiDisplayESP32/cmd/light), pixxiDisplayESP32/status/light is not updated.

Could someone explain to me why there is no update in the second case? And how to configure it correctly, so that ESP32 sees the dimmer state, after it was updated by ESP32?

Thank you.

How are the two Channels linked to the Item?

It is only one channel, linked via the standard profile.

Due to your question I tried it with 2 separate channels to check if there are any differences. Also for the second case pixxiDisplayESP32/status/light is updated now.

Is there a limitation doing it with only one channel? Else no big issue using 2 channels.

btw: I missed in my initial post to show postCommand: true, this is now done.

If it’s only one channel linked to the Item, how are you controlling it though both Hue and MQTT?

that’s probably unnecessary and could be a problem. When that’s set to true state updates (i.e. the message that comes on the state topic) are converted to commands. And commands are not guaranteed to cause a state change in the Item. You don’t show the Item so :person_shrugging: If autoupdate is turned off the Item will never be updated. Even if autoupdate is on, the Item might not update depending on the Item’s current stage and what the command actually is.

It also risks creating an infinite loop.

Generally you want that property turned off. Then when a message is published to the state topic the Item updates based on that message. If you send a command to the item, that command is published to the command topic.

O.k., see your point, the second channel from the Hue Thing also links via the standard profile to the item.

Here for the item the Karaf Console output (not sure if an activated autoupdate would be visible)
Terrasseunten_Helligkeit (Type=DimmerItem, State=100, Label=Helligkeit, Category=Light, Tags=[Control, Light])

Not sure if this is correct for my application. When postCommand is set to false, only the item value is changing, but no change of the bulb brightness. When I publish a message to the state topic, I want both: changing the bulb brightness and that the command is published to the command topic.

Go to the Item in MainUI, click on the “code” tab.

That’s what the follow profile is for. Add the follow profile to the Item with the Hue Channel as the following channel. That will send updates to the Item as a command to the Hue Channel.

Consider this. You send an INCREASE Command to the Item. That get converted to 75 which gets published to the command topic. The ESP updates to 75 and publishes 75 to the state topic. OH gets the 75 on the state topic and with postCommand set to true a command gets sent to the Item. The command gets received by the MQTT binding which then publishes 75 again to the stateI want both: changing the bulb brightness and that the command is published to the command topic. topic. If the ESP then publishes the 75 to the state topic again and you are in an infinite loop.

If you need to command and update this light from both Hue and MQTT, you’re probably going to need a rule and proxy Items. If the updates need to be forwarded from the ESP to command Hue only the follow profile is what you need. Because updates from the Hue can not be received as commands, there is no way to synchronize both ways without a rule.

Thanks a lot for your responses @rlkoshak

This can’t happen. ESP will not publish the subscribed brightness again. There is no reason for such a loop.

I believe the mentioned (working) solution with the two channels is easier:

channels:
  - id: Light
    channelTypeUID: mqtt:dimmer
    label: Terrassenlicht
    description: ""
    configuration:
      postCommand: true
      min: 0
      stateTopic: pixxiDisplayESP32/ESP32toOH
      max: 100
  - id: Light_status
    channelTypeUID: mqtt:dimmer
    label: Terrassenlicht Status
    configuration:
      commandTopic: pixxiDisplayESP32/OHtoESP32
      postCommand: false
      min: 0
      max: 100

I adapted the topic names to make it clearer. Both channels are linked with the standard profile to the item.
If you agree so far, we are back to the initial question: Why is it not posible with one channel?

:person_shrugging: Probably because there’s interaction between the Hue Channel and the MQTT channel.

Then I’ll continue with the 2-channel approach.

Thanks again for your support Rick. I really appreciate your continous effort for OH and the community.