the problem is that both topics are being published when i set the brightness which is very annoying - the light power is already on so no need to publish its status for brightness changes - is there any way to disable the “command_topic” in that case?
I can’t guarantee this is a solution but you may wish to experiment with the on_command_type option. It controls the behavior of what commands are transmitted to the device and in what order.
If you set it to brightness, it will only use brightness commands to turn the light on and off (it won’t use on and off).
just played with the on_command_type - it doesn’t help solve the problem. the optimal behavior i’m looking for is the following:
when the switch is set - ONLY publish to “command_topic”
when brightness is set - ONLY publish to “brightness_command_topic”
when RGB color is set from the palette - ONLY publish to “rgb_command_topic” (this just seems reasonable as when the switch is off - you cannot use the color palette to send RGB)
there is no need to publish two topics in any case - is this possible?
Unlikely with the default behavior of the MQTT Light component. It would be possible using an automation to monitor the light’s state and other attributes (brightness, rgb_color) and then publish only what you want when you want it.
you mean not use light component at all? is it possible to do automation on each control inside the light component separately (RGB palette, power switch, brightness scroll)?
Currently, MQTT Light will publish ON to home/smartlamp/setpower every time you adjust brightness or rgb. You don’t want it to do that. If the light is already on then no additional ON commands should be published to it.
The solution I am offering is to use an automation to suppress additional ON commands.
Modify the light’s configuration
In your configuration for light.smartlamp_light, change the command_topic from:
command_topic: 'home/smartlamp/setpower'
to:
command_topic: 'home/smartlamp/setpowerstate'
The topic’s name should simply be different from the one that actually controls the light.
Trigger: subscribes to home/smartlamp/setpowerstate.
Condition: checks if the received payload is different from the light’s current state.
Action: publishes the payload to home/smartlamp/setpower.
If the payload is the same as the light’s current state then the action is not executed. So if the light is already on, additional commands to turn it on will be suppressed.
just tried it but setpower is still publishing on rgb color choosing. is there a way to evaluate the values of the expression in value_template? how can i know it’s correct?
ok - just played a bit with it and the following does work:
value_template: “{{ (trigger.payload == ‘1’ and states(‘light.smartlamp_light’) == ‘off’) or (trigger.payload == ‘0’ and states(‘light.smartlamp_light’) == ‘on’) }}”
Had you revealed that information in your original post, or in a subsequent post, then it would’ve helped me to help you more effectively.
For example, I would not have to reverse-engineer why my solution failed to work when you replied “setpower is still publishing on rgb color choosing”. It didn’t work because you were using a different configuration from the one you shared in your original post. That’s never helpful to the people trying to help you.
Because the automation is now handling all turn_on/turn_off commands to the light, there’s no need to define payload_on and payload_off in the light’s configuration. The conversion of ON/OFF to 1/0 can be easily handled by the automation’s action.