I’m in the middle of a migration from OpenHAB to HA and am therefore rather new to HA. This may be an obvious thing, but I don’t know where to look.
I have a number of ESP8622 driven lights around the house which are working great with ESPeasy and MQTT. As I need to do the migration from OpenHAB to HA on the live system and keeping both functional (until HA is fully functional) I need to retain them on ESPeasy until the migration is done and then move them one by one to ESPhome. This is the end goal but ESPhome is not supported in OpenHAB.
ESPeasy has a very nice function for a controlled fading between brightness levels. To control this, you send a message pwm,x,y,z to the topic ESPname/cmd where x=GPIO piny=brightness level from 0 to 1024 and y=fade time in milliseconds. The fade level I can set to the correct range using brightness_scale: 1024 and the GPIO pin and fade times are static. However, I do not know how to include the information in the message sent to the /cmd topic. For max brightness, I would want it to send pwm,14,1024,1500 for example, but it only sends 1024
I have managed to parse the messages sent using OpenHAB by specifying brightness_value_template: "{{value.split(',')[2]}}" so the dimmer slider is updating correctly when I’m controlling it from that side. Is there another parameter I can set to format the messages sent to the topic, not only received?
Yeah the MQTT documentation is severely lacking in examples/details, I wasted over 2 hours yesterday by trial and error trying to figure out Tasmota Publish commands, try something like this
topic: ESPname/cmd/pwm
payload: x,y,z
And if you work out the correct format please edit the documentation page with an example.
Thank you again Trevor! This is very helpful. I may have to go down that route.
The “template schema” was an excellent suggestion but unfortunately sparsely documented. It appears that this is quite limited in the available configuration variables. The following Entity almost works the way one would wish:
There are a couple of remaining issues with it. The first is that the scale is set to 0-255 and there is no available “brightness_scale:” variable or equivalent to set it to 1024. Therefore I have used the brightness*4 parameter to come close.
The dimmer values now worth as expected which is great. The second issue is strange, but while dimming works, when I click the “On” button in the interface, I receive an error that “brightness” is not available, even though it has been when using the brightness slider.
The last issue is that the: brightness_template: "{{value.split(',')[2]}/4}" does not appear to work at all. I.e., when I change the value in OpenHAB and see pwm,0,200,1500 for example, the dimmer value does not change. This is the least severe of the issues, but would be nice to sort out.
I totally agree with this. The MQTT is very much an after thought in ESPeasy. It has excellent support for sensors and other components and a quite good rules engine allowing on device automation and control.
I have used it together with rotary encoders with click buttons to build dimmable lamps which can be dimmed both directly on the lamp and through MQTT. This is the only reason why I stick with it. Otherwise I would have moved over to ESPhome.
I’m just wondering if maybe the brightness argument needs formatted, or maybe because you are just switching it on without a brightness yet its expecting one so maybe a variation on this to catch the case when you turn it on without “specifiying” a brightness, as in
command_on_template: >
{"state": "on"
{%- if brightness is defined -%}
, "brightness": {{ brightness }}
{%- endif -%}
{%- if red is defined and green is defined and blue is defined -%}
, "color": [{{ red }}, {{ green }}, {{ blue }}]
{%- endif -%}
{%- if effect is defined -%}
, "effect": "{{ effect }}"
{%- endif -%}
}
I don’t think that you are listening to the correct topic (state_topic)
The tip above for the "if brightness statement was exactly what was needed for the “On” button issues. It brought me one important step closer.
This is nog how the entity looks:
- platform: mqtt
name: ESP-KitchenSpots
schema: template
command_topic: "/LEDkitchenSpots/cmd"
state_topic: "/LEDkitchenSpots/status/"
brightness_template: "{{(((value_json.log.split(' ')[5]) | float )/4) | int }}"
command_on_template: >
{%- if brightness is defined -%}
pwm,0,{{((brightness/7.96875)**2)|int}},1500
{%- else -%}
pwm,0,1024,1500
{%- endif -%}
command_off_template: 'pwm,0,0,1500'
The calculation is weird, I know, but it is an exponential translation to allow for a linear dimming using PWM dimmers. That is working very well.
What I continue to struggle with is the feedback of the state.
It is correct that the ESPeasy does provide the state in a different topic. In this case /LEDkitchenSpots/status It is provided in json with the following , inconvenient structure:
{
“log”: “GPIO 0 Set PWM to 1024 durat”,
“plugin”: 1,
“pin”: 0,
“mode”: “PWM”,
“state”: 0
}
It is the “1024” I wish to extract from here and feed back to a range 0-255 (So I need to adjust the curve of this translation later as well. However, it fails to update anything from the json and there is no error messages in the log. Can you spot any mistake in my thinking?
A quick update. I created a script on one of the ESPeasy devices that feeds the raw PWM value to a separate MQTT topic to that I could take that integer directly in brightness_template: '{{ value }}' to ensure that it isn’t a json or string splitting issue. However, it still does not appear to do anything with this value.
So HA is either not seeing the state or not processing it properly
I would be confirming the state topic by sniffing using MQTT Explorer, so that you can see the structure and messages independently of both HA and OpenHAB;
Then in HA on the Integrations page select Configure from the MQTT card and subscribe to the state topic to confirm that HA is actually seeing the correct topic and payload;
Then in HA go to the Developer Tools page select the Template tab and paste your configuration for the light in the template editor to see how HA is processing it
