Currently I’ve got lights connected via MQTT bridge to home-assistant. These lights accept dim ranges from 0-100 (%) which makes it a little rough to adjust with the current slider ranging from 0-255.
Maybe it’s possible to add properties to define a new value range of the slider in the config? I guess that more people than only me will appreciate this possibility.
Discussion already went a little further on github before closing due to new feature request rules.
Reopened from github
thanks for your quick response. I’ll give it a try when I get hass up and running again 
The option brightness_scale works perfect. Thank you 
My expectation is that there would be an associated UI control for this component with a toggle for the on/off state, and a slider for the brightness level. Am I missing something as I’ve yet to be able to get a slider to display on the UI?
- platform: mqtt
name: ac_dimmer
state_topic: "/demo/dimmer/switch"
command_topic: "/demo/dimmer/switch/set"
payload_on: "on"
payload_off: "off"
optimistic: true
brightness_state_topic: "/demo/dimmer/level"
brightness_command_topic: "/demo/dimmer/level/set"
brightness_scale: 100
brightness_value_template: '{{ value }}'
qos: 0
At the moment the UI needs two things to display the slider.
Well, no love yet. Still no slider on the UI. I’m running 0.17.3.
I see the MQTT events come in on the log. I can control the light state (on/off) via the UI toggle, from the Developer Console calling the mqtt.publish service directly (and the UI updates appropriately), or externally via a MQTT client (e.g. MQTT.fx). I can examine the current state of the light via the developer console and it appears as if the brightness attribute is being correctly updated when a new level comes in on the brightness command topic.
Maybe its about time to setup a dev env. Any pointers where to look in the UI code for this control would be appreciated.
As far as behavior, I suppose a configuration option to enable the behavior you want might be a good approach. In my particular case, I want to be able to control the on/off state independent of the brightness level. Brightness 0 doesn’t necessarily mean the same thing as off (in my case anyways).
FWIW, I am working with custom hardware that I’ve built to do AC dimmer control via an Arduino. Control and state is exposed from the Arduino via serial to a BBB where I have a Python bridge to MQTT.
I didn’t mention that the light switch in the UI has to be already turned on. Only then a slider will appear.
So here are the necessary steps in detail to make the slider appear. Unfortunately it doesn’t behave “naturally” yet.
on to topic /demo/dimmer/switch
30) to topic /demo/dimmer/level
Sending payloads to these topics only changes the display in the UI it doesn’t actually turn the lights on.
If you want to actually turn the lights on / change brightness append /set to your topics. This, however, doesn’t update the UI. (which is perfectly fine).
Maybe you can give a brief explanation of “how on a light with a brightness of zero” can be? I’m talking especially about lights in this case.
To use that behavior for other domains like, let’s say for example, the switch part of the control could turn a TV on/off and the slider controls the volume, it would make totally sense to not turn off the TV just because you’ve muted it.
But than again, we’re talking about another domain of devices and not about lights anymore.
Maybe you’ve got light regarded use-case, I can follow where a light can be “on” with 0% brightness and “off” with a brightness of 100%. I’d be more than happy to hear it.
Ah, in the detail box. Never thought to look in there. I was expecting it to be visible along with the on/off toggle in the so-called overview display. Besides it being hidden in the detail box and forcing an “off” at brightness 0, I suppose this is minimally sufficient.
This feels a bit like a component that is trying to enforce its own semantics on the device it is interfacing with rather than conforming to the interface that the device presents. For the various purpose built “light” components that interface with specific devices types, out of necessity the component must conform to the device interface. For a MQTT component, it seems that the whole point is to provide a highly customizable component that can be configured to conform to many different devices types that expose an MQTT interface.
One possibility might be a collection of “lights” that one wants to preset brightness and/or color) values and then turn them on or off as a group without loosing the presets. There is also an analogy from the physical world…I have a dimmer device that combines a traditional light switch with a dimmer. The dimmer control is a small slider next to the traditional switch which you can use to set the dimming level independent of turning the circuit on/off. (After discovering the hidden slider after writing this, in retrospect the existing MQTT light does remember these “presets” as a result of the retained nature of the payload in the brightness topic.)
I also have a case (albeit it might not be best described as a “light”) where the user visible range is 0-100 but 0 is not off. For example, as a dimmer or fan speed control, 0 might be mapped to a controller value that is the lowest practical setting that keeps the (e.g.) fan running. Presumably a lower controller setting might make the fan stall and thus we would want to avoid going below that minimum. In this case, 0 is semantically equivalent to “low” not “off”.
This brings up an issue that I’ve been thinking about…what makes something a “light” versus a “switch”? Possibly its just UI. Maybe its more to do with providing categorized purpose built components for devices that are actually “lights” or “switches” and conform to some standard HA protocol (turn_on/turn_off). This possibly makes less sense for a MQTT component IMHO as its purpose seems to be more generic in nature.
I’m wondering if it makes more sense to imagine a new “multi-channel controller” MQTT component? That is, a highly configurable/customizable component that exposes a “composite” of one or more control (and possibly sensing) channels. The current MQTT light component has hints of this already: there are 2 channels (RBG color control and brightness control). I think the idea would be to allow the user to define and configure the number and type of control channels and how they map to MQTT topics and payloads. I would also envision the ability of this component to deal with other attributes of the device it interfaces with. For example, to acquire and display attributes that the device might expose such as battery level, wireless signal strength, etc. Maybe this would appear in the UI as an “i” information icon that would flip the item over to an attributes display (something like what the MAC does). I could see this multi-channel composite controller component conforming to existing protocols such as turn_on/turn_off which would imply the ability to power on/power off the device. I suppose it might also be possible to implement the existing MQTT light/switch/lock etc. components as specializations of the multi-channel controller.
Anyways, just some thoughts. Maybe I’ll take a crack at implementing something like this as time allows. Thanks for your replies.
Here is my take on the light issue.
I am currently using ESP8266 modules with the EspEasy firmware with MQTT to control my LED lights. I also find that the light configuration is confined to presets situations that do not apply to many projets.
As an example, if I’m sending a pwm value to a gpio to control brighness i can no longer set it to on or off. For me, the ideal scenario would be that the UI just send a 0 pwm value whenever i want to turn off the light and sends the last sent pwm value when i turn it back on. I do believe that there must be a better way to control the behavior of the UI vs I/O in the case of lights.
I would suggest that you get rid of the mandatory state topic since you can send configuration via MQTT with a QOS that provide confirmation from the subscriber. To make sure the light has the right state, maybe just force the server to send a “payload: OFF” at startup (this could be configurable also) so optimistic mode can be accurate
on/off payload could also be set to the “brightness_command_topic” value
payload_on: light.test_brightness_command_topic
payload_off: “0”
Hope these suggestions can get this forward.
By the way, this piece of software is incredible, keep up the good work!!!
@bhaonvashon
regarding your preset brightness and color (for multiple lights) idea:
what you’re describing has already a proper solution. It’s scenes. You use them exactly for that. Preset plenty of values and recall them in an instant.
Besides that, it’s not possible to preset brightness / color with HA right now when the light is turned off. There are no UI elements displayed to do so. You can set brightness via mqtt, but that has no effect when you turn on the light.
As you said, the second use case concerns a fan / AC topic. The light-mqtt python script might be used as a template for AC tasks and altered according to these special requirements, but not the “light” itself.
Regardless of that I like your idea of having a generic mqtt device, which can add different functionalities by configuration.
Also the (i)-Button similar to the ones found on OS X widgets is a really good idea. Secondary information like battery status, last update, etc. could be placed there. I think this deserves its own feature request.
Hi
I was wondering if the brightness_scale can be configured using IR codes?
I am controlling a dimmer light switch which is controlled by an IR LED with codes for the levels of brightness and I have set up MQTT in the following manner to switch on and off the lights.
Switch:
I have the IR codes for various brightness levels and was wondering if I could use the brightness_scale to turn on and off the lights and adjust their brightness all in one?