Has this changed recently? I’m looking for the simplest way to write a script in HA to set one of my WLED entities to a specific preset. Not looking for any of the complexity for drop downs in lovelace etc.
I thought i could do call service, mqtt publish and
topic: wled/Kitchen/api
payload: ‘[PS=02]’
but no joy - i think I’m confused! apologies if this is considered hijacking the thread? please advise.
Thanks
Hi! Very good approach. Do you mind to do some tutorial for users who know less about HA but want to add WLED card to their lovelace-gui?
Yes, I guess I was gonna have to do that at some point anyway. I realize that using this method would require more detail for the HA newcomers. In my opinion this method is easier since it doesn’t require MQTT and it can even be done without using file editor. To be honest, I haven’t been using HA that long myself, only about 3 months now. Regarding the tutorial, I will do a complete write-up sometime this week and I’ll leave a link here and in discord as well.
Hey mate,
Did you get this done? Would love to be able to see my presets and quite surprised actually that they don’t get pulled in automaticity.
Thanks!
Not yet sorry. Presets and palettes won’t get ‘pulled in’ automatically. That’s why I created input select helpers for them. In my tutorial I will show how to make input select entities in config yaml though since that is much faster. Its pretty much the same as drzzs guide on creating input selects in his wled mqtt video in yaml. If you would like to use helper instead though just create an input select helper and add a list of numbers to it, then use that helper in the automation (see my list of automations above) so that it wil function correctly. After that just add the helper to your wled entities card or whichever card you like. Changing the input in dropdown will trigger automation and set preset to corresponding number
Awesome!!!
Cant wait to see it 
Im only a couple of weeks into HA, so still not sure what helpers ect are.
The Dr ZZZ vid sounds interesting, maybe a little older though? I dont want to clutter up the config.yaml since its meant to be moved away from (even though everyone seems to be saying, add this to your config LOL)
Anyway, ill see how I go! Thanks for letting me know
If you can fire off an event which executes a script, you can use CURL to read / write WLED data using the json API. I use CURL with a different HA software package to send a json bundle which configures, and then calls a specific preset (like candycane for December, several of the “fire” effects for New Years Eve at midnight, and so on). The reason for the “configure” before calling is to make sure the specified preset is set as the startup preset so if WLED restarts for any reason, it will automatically use the correct preset.
You can use CURL to retrieve the current WLED configuration as a json bundle, save it, and then chop it up with values that need to change, save as a new json bundle, and use CURL to send that bundle on demand.
Sure, it would be nice if that were a built-in thing for HA software.
Until it is, it does not take that long to configure a hand-ful of special json bundles, give them good filenames, and then create & test the curl commands, put them into a script (batch file) with appropriate names.
Then anytime you want to automate something, schedule the right script(s) to execute at sunset (for exterior WLED installs) on the appropriate dates.
If you get really fancy, you can setup WLED to bring a car into the garage with the percent effect, and using a laser measurement input to another ESP8266/ESP32/RPi, update the % intensity until they are in the correct parking spot to close the garage door without closing the door on anything.
When the garage door is closed, WLED is doing whatever it normally does, but once the garage door opens and a car is detected entering the garage, a different preset running the % effect gets started, with the intensity sent from a different device.
Get really fancy and make that a usermod and connect the laser sensor to the WLED ESP.
Sorry, I totally forgot about this thread.
I now come back as a veteran after a long dark year of HA and WLED HAHAHA
I ended up using Node Red for so much of this, it just works well and its super easy to see what you’re actually doing.
I’m actually currently on the hunt for an Alexa notification ring effect so that I can use some WS2812s to light up when a hidden Alexa is triggered using Alexa Media Player last alexa state.
There is just so many cool things that can be done, I love it 
I don’t know who will benefit from this, but there’s now an easy way to set your preset.
Here’s my code for cycling through presets
This assumes your normal wled light is light.wled
action:
- service: select.select_option
target:
entity_id: select.wled_preset
data_template:
option: >
{% set list = state_attr('select.wled_preset','options') %}
{% set current = states('select.wled_preset') %}
{# don't break if unknown #}
{% if (not current is in(list)) %} {{(list|first)}}
{% else %}
{% for item in list %}
{# cycle through each item in the list of presets #}
{% if current == item %}
{#
If we're at the item in the list that's out current preset
output the next preset. If there is no next preset, default
to the first item in the list.
#}
{{ loop.nextitem|default(list|first) }}
{% endif %}
{% endfor %}
{% endif %}
Put more simply, you can call the service select.select_option against select.wled_preset with your preset name as the data.
hey
do you try to use a playlist command over HA ?
i have the problem that the command first works, but 10 seconds later he lost the connection and the command is dead, sometimes it works but its 4/10 times.
i use this code in my automation to change the playlist
service: select.select_option
target:
entity_id: select.wled_playlist
data:
option: pl_wipe_down
How often does this code run?
Does it run, check the return code from WLED, and then read the running preset to see if it actually is running, with maybe 0.1 seconds between calls (to prevent overloading WLED). If the preset it running, update the preset request so it does not fire (run) again until the current and actual preset are different?
I work (job) in a world where it is extremely easy to run something even while the requested change is in the process of changing - unless you track the state of the request AND track the requested and running presets.
Tracking a system state change makes it easy to know when requested change took effect, and then then TRIGGER requesting the change can be toggled from TRUE to FALSE.
This code used to run great untill august 2023 update, now it doesn’t anymore. Did something change that I need to adapt my code for?