I am going to have to check this one out! Been wanting this forever!
I will install the new version this week to try.
I currently don’t use the binding, but it is because wled does not work in my setup so I am not using wled any where.
Looks like this release may have many of the features I need to use it.
Thanks for reporting it works, will have to find some time in a week to try it out.
You can link multiple controls of different types to the same color channel. Just link up a slider and also a on/off switch to the same color channel and you can already have separate controls. The advantage of having a single color channel is that Google and Alexa can then change all aspects using the same tagged name.
Yes the binding lacks that support and I have not begun to look into what is needed to be done.
Nothing really. it does everything I need it to already.
You do NOT need to define in the sitemap, the binding has it hard coded already so leave out the mapping in the sitemap and it should work just fine.
That’s on the “to do” list so any changes made to the FX names and ordering in the firmware are automatically updated in the binding. In the past firmwares, the list was only available via http calls, so it means giving the binding the IP to the esp8266 that WLED is running on so it can fetch and parse the lists.
Have not seen it yet and I have no idea what it does ?!?
A feature I have been wanting to add is the ability to override the FX if I ask google to change to a certain colour. The binding just changes to SOLID before the colour change.
Wow I had no idea. This is awesome!
The RGBW value can be set with &W=(0-255). Unfortunately (at least for me) the xml answer of is always -1. But the answer to mqtt/c is a #xxxxxxxx (8 digits long) and the last value is the W.
In the new firmwares of WLED, the effects and palettes are available on the JSON API.
WLED has a “live” mode where it receives direct LED data via TCP or DMX or Arnet or E.131 (e.g. for a Ambilight/Hyperion behind a TV). Of course it is nice to “stop” this and set a different colour/animation - thats what they call “live override” and it can be set with a JSON POST to /json/state - “{“lor”:1}” (1 being live override is ON, 0 live override is OFF). That way it could be automated to when the TV is actually on to use the live mode and otherwise a different colour.
Could be done with decrease increase commands. 
Uploaded new version now with hopefully decrease increase command support on the color channel. Please post if it does work as I have not tested it.
It works perfectly fine, thanks. Only thing i noticed is, that the sliders in the app and/or browser arent updated.
Sorry for the delay in my reply, as this was something I wanted to explain more in depth as it shows the trend of the WLED project to ignore MQTT and the move to HTTP. Below I have linked some bug reports I made a while back and it is linked to what your wanting as any change to the state of the LEDS should be published back to MQTT to inform all clients of the change. If that message was getting sent the control your wanting to work would be getting updated ! You can test that by turning the light off and back on via Openhab’s control and noting if the new state was finally sent through…
Yes, I could force the changes from the binding, but if ever fixed you would possibly then get 2 movements looking like a glitch if there were any rounding differences between what the binding calcs and the MQTT message. My opinion is better to move the control once and it should mirror the MQTT published state, it also makes sense when you consider the WLED may be turned off so the state only really gets changed when the WLED comes back online.
Any change of a state SHOULD get the state published and be correct. This is not happening.
This is effecting multiple controls that I know of, however sadly the bug reports I made are badly named to get attention as I am probably the only one that cares enough to post.
Someone should open a new bug report that states this is effecting a number of controls including basic brightness after testing in the latest firmware to ensure the report is correct, then multiple users that care about MQTT support should be posting to show the support and need for the changes.
I think I’m being an idiot.
I would like to set this binding up and configure it using files only.
I have a things file called bridge.things which defines the connection to the Mosquitto MQTT broker:
Bridge mqtt:broker:MosquittoMqttBroker "Mosquitto MQTT Broker" [
host="192.168.1.92",
secure=false,
port=1883,
qos=0,
retain=false,
clientid="OpenHAB2",
keep_alive_time=30000,
reconnect_time=60000,
username="",
password=""
]
The WLED MQTT settings are as below:
I would like to define the WLED thing and channels in a new things file called wled.things. I do not want to add it to bridge.things, as that bridge is used for other things too which are in their own separate files (such as Tasmota and zigbee2mqtt devices). Is that possible? What would the syntax look like in wled.things to connect the wled thing to the MQTT broker thing?
I thought I was being clever by mixing the example on Github and what I already do for the Tasmota and zigbee2mqtt things as below:
Thing wled ami "LED strip" (mqtt:broker:MosquittoMqttBroker)
Alas, this doesn’t seem to create a valid thing. Log entry below:
10:52:28.443 [INFO ] [del.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'wled.things', using it anyway:
Provide a thing UID in this format:
<bindingId>:<thingTypeId>:<thingId>
10:52:28.456 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'wled.things'
In PaperUI there is no new thing created.
Any help is much appreciated, which I will in turn submit as a PR to the github README.
Can you explain what is not clear at the readme linked below and I will happily edit it? There is an example to follow. One thing people commonly mis understand is that this binding does not use the MQTT binding at all, and this binding will create its own connection to your broker/mosquito.
Ah, that’s the bit I’m missing I think. I’ll give it a go.
Regarding the README, there’s an empty space for Thing Configuration which I was hoping to be able to fill up… (I see your edit - looks good!)
Edit: All working using the examples in the README. It’s probably still worth having an explicit note somewhere appropriate in the README to let people know that this binding doesn’t use the MQTT binding. I’ll have a think how best to integrate that with the current file and send a PR.
Hi Matt !
This binding works like a charm. Really helpful. Thanks a lot for that.
I can see that about 100 effects or so get listed on the OH interface, however there are more effects in the wled 10.0 release. That might need updation.
Also I think a great addition to the features would be to be able to save presets from the OH interface. That would mean little to no need for wled’s native interface anymore after setup once. I understand this would take up a lot of your precious time, but this would really be worthwhile.
Yes a user helped with a PR just recently (changes are correct but in the wrong file) and I need to do some testing and make a new build with the changes in it. If you know that any other changes are needed besides the ones in this PR please drop me the names and numbers and I’ll make the update soon…
Are you able to outline what change this would be? ie X mqtt message gets sent to save it to X location…
Also does the feature have the equal feature in the HTTP api? it seems more and more likely that this needs to be fully redone for http.
Sure, I would copy the list from the wled code though your idea about automatic listing of effects would be really awesome to have in this binding.
Pull req Done.
Yes, to save a preset to some location, send message
PS=1
to topic/api
and current settings get saved to preset location 1.
Another thing I noticed is that 25 presets are listed in the binding however wled supports only 16. Please have a look at that too.
New build ready for testing:
Hello to all,
First time using this great binding with Wled. I have one question/issue and it is when I disconnect my Wled board the offline status is correctly published to the Mqtt broker in the status topic, however the Thing in Openhab stays online. Is this expected?
Could you be so kind and give me a hand on this?
Thanks in advanced for all your help.
Best regards.
The binding does not use that to determine on/offline. Instead it follows if the broker can be reached on your network. Any control moved is queued up at the broker and sent when the broker can talk to the device again.
Can you raise a GitHub issue for this?
Hello @matt1,
Thank you for your explanation.
Issue raised:
If you need any help for the testing I am glad to help.
Thanks.
Hey @matt1 !
I just found out that wled has been forked for making a Sound Reactive LED strip.
Saw Videos on youtube and I was just remarkably overwhelmed.
I found out that a microphone preamp module needs to be added to the already working wled setup and after that playing music makes the LEDs dance to it. There are tons of effects related to this sound reactive feature along with all the other previous 111 effects already sported by WLED itself.
This seems incredible to me.
Just ordered a Microphone Preamp module to check it out. Really excited.
Attaching a YT vid. Take a look
https://www.youtube.com/watch?v=dLx8aD8mhhQ
Hi !
I am using esp32 board and max4466 microphone with ws2812 and trying the Sound Reactive fork of WLED. Its the best upgrade one can get for these led strips. In addition to the regular WLED, the SRWLED has about 20 more effects which react to Music and also has option to connect LEDs in a two dimensional matrix and have a bunch of effects supporting that too. It is really something that you should check out yourself and these can go into the binding if you will.