WLED Binding: New bridge / thing version with global controls

This version of the binding is exactly the same as what is built into 3.3 Stable. Since it is newer than 3.2 Stable and older versions of openHAB, you can install it from the JAR link below to gain the newer BRIDGE and THING structure so you do not have a breaking change when you upgrade to 3.3 Stable.

Example Controls

Not all the controls fitted so there are more especially if you have RGBW strips.

Changelog (compared to 3.2 Stable version)

  • New global brightness and on/off ability
  • More sleep mode channels added
  • Bridge / Thing structure
  • Auto discovery of both the bridge and all the segments which can include the friendly names you can save in the V0.13.x firmwares.

How to upgrade

Due to the new bridge and thing structure this binding is not backwards compatible and may have issues if parts of the older binding are left in the cache. Do the following to ensure trouble free use.

  • Uninstall merged binding first
  • Clear the openHAB cache to remove traces of the older binding.
  • Install this new version
  • Remove all things and re-add them



Readme / Documentation
openhab-addons/README.md at wled · Skinah/openhab-addons (github.com)

Source code submitted for merging in this PR

[wled] Change to bridge/thing structure and add global controls by Skinah · Pull Request #12199 · openhab/openhab-addons (github.com)

I got an error during installation. Error Installation of add-on 132919 failed

Try cleaning the cache. The newer binding has large changes under the hood to use the BRIDGE / THING structure so if any cache from the old binding is around that may be the cause. I installed it successfully so if anyone else has trouble or success can u post? thanks…

Clear the Cache - Setup, Configuration and Use / Runtime - openHAB Community

I was able to reproduce this, it happens when you have the JAR in the addons folder already AND then you try to install it from the marketplace without removing the jar from that folder FIRST. Delete the jar from the addons folder and try again and it should work.

1 Like

thanks for the hint ! that was the problem :smiley: !

Bridge and segment configuration is working well, especially from the UI!

However, it’s possible that I misunderstand how this binding works, but I can’t seem to command an fx from a rule.

Here’s the Bridge:

UID: wled:json:500291ecab67
label: wled-test
thingTypeUID: wled:json
  pollTime: 5
  saturationThreshold: 0
  sortEffects: true
  sortPalettes: true

Here’s the segment:

UID: wled:segment:500291ecab67:27f98d5018
label: WLED Segment
thingTypeUID: wled:segment
  segmentIndex: 0
bridgeUID: wled:json:500291ecab67

I have linked a String Item to the fx Channel as below:

Within the UI I can go to this Item WLEDSegment_Effect and select an effect, and WLED responds as it should.

But from within a rule I try to send the name of the effect to the same Item WLEDSegment_Effect and the LED effect doesn’t change. I can see in the UI that the Item changes to the effect name I commanded in my rule, but a few seconds later it switches back to the old effect name. And the LEDs themselves remain on the old effect throughout.



events.sendCommand('WLEDSegment_Effect', 'Colorful');

How can I command a WLED effect from within a rule?


It turns out that, despite the Channel being of String type, it doesn’t expect the name of the effect to be commanded, but its numerical index. So for the example above, we would have to check the index on the linked webpage, and then send that number to the Item.


Presumably that’s intended, and if we wanted to use the effect names we’d have to implement our own transform?

I guess the binding could be changed to search through all the effect names when a command is sent, that is not implemented and your now the second person to get tripped up by this so I think it should be considered a bug to fix, OR be documented so it is clear in the docs for the binding.

As to why it is this way…

  1. The json API for WLED can not use the effect name, only the index number of the effect. The API requires the number to be used.

  2. openHAB framework (pretty certain this is true) does not allow options to be listed in the UI with a nice name, unless they are a STRING channel. So sending the effect number in quotes is needed because it is a STRING channel and not a number channel.

The binding could always work out the command is not a number and then do a search to find the number it needs based on the text. It could handle this automatically, it just requires extra coding for it to work that way and it would need to handle what happens if the effect was mis-spelled or missing.

Either of those options work for me. By way of explanation, I think the reason I was tripped up:

  1. The Channel is auto generated.
  2. Creating Equipment automatically from the Thing using the UI features creates a String Item.
  3. This String Item is populated with the name of the effect in the UI, without me explicitly creating any transformations.
  4. So I just assumed you could send that same String Item an effect name in return.

i have a problem with the channel for the white light, if i set a value in OH, it is accepted, but the slider jumps back to 0 after a few seconds, but the set value remains. it looks as if the set value is not reported back. i already tried to remove and add the things again.

Thanks for reporting, that would have happened in the merged binding as well as this one. I just fixed the bug and made a PR with the fix. Just remove the marketplace version and then install it again and it should then work.

1 Like

Thanks, i tested it and it works!

1 Like

Will this binding ever replace the official stable WLED binding?

If it passes a review it will become the official one, until then it stays in the marketplace so it can be used whilst the review is pending.

hi @matt1
can you provide example for the “old” openhab text config (thing file)?
i am a little bit lost with the new binding :sleepy:
thanks in advance

Try this which I have not tested it nor used textual in quite some time.

thing file

Bridge wled:json:strip1 [ address="", pollTime=10, saturationThreshold=0]
Thing wled:segment:segment0 "LeftSide" (wled:json:strip1) [ segmentIndex = 0]
Thing wled:segment:segment1 "RightSide" (wled:json:strip1) [ segmentIndex = 1]
1 Like

it works…thx for your help

Another working Things text config:

Bridge wled:json:w1 "WLED1 Bridge" [ address="", pollTime=3, saturationThreshold=0]{
    Thing segment segment0 "WLED1 Segment0"  [ segmentIndex = 0]
    Thing segment segment1 "WLED1 Segment1"  [ segmentIndex = 1]
1 Like

is it now merged with official wled binding or is this one still more up to date?

As the first post in this thread states it is merged in 3.3 stable and newer so this can still be used in older cores if people wish. It is no longer in the marketplace.

Ok, but I still see it in marketplace

That’s what I have under marketplace in 4.3.2

Strange as the published tag was removed ages ago. I have removed the binding tag as well so hopefully it goes otherwise we may need to report this as a marketplace bug.