WiFi LED Binding requires Thread Sleep in Rules

After updating my OpenHAB installation to the latest version (running on Raspbian), I encountered an issue with my RGB controller that used to work flawlessly before the update.

Setup and Problem:

I use several rules to control the RGB values. For example:

rgbcontroller.sendCommand("240,100,10") // Set to blue

Previously, this worked perfectly to change the RGB color (e.g., turning blue when a button in the Hab-Panel-UI is pressed).

However, after the update, the behavior has changed:

  • The RGB values are sent to the item, and both the logs and the item state show the correct values as expected.
  • But the color of the RGB controller does not change, even though the item reflects the intended value (e.g., “blue”).

Observations:

The strange part is that if I manually change the RGB values using the slider in the Main UI, everything works fine. The logs in DEBUG mode show no difference between the working (manual change) and non-working (rule-based change) cases.

Workaround:

To make the rules work, I had to modify them as follows:

  1. Add a Thread::sleep(500) (500ms delay) after sending the command.
  2. Add a postUpdate("VALUE") for the item after the sleep.

For example:

rgbcontroller.sendCommand("240,100,10")
Thread::sleep(500)
rgbcontroller.postUpdate("240,100,10")

Without the sleep or the postUpdate, the RGB controller does not update its color, even though the item visibly changes in the UI. A shorter sleep sometimes works, but it’s inconsistent.

Question:

Does anyone have an idea why this is happening? Is there a way to avoid adding Thread::sleep to every rule? It feels inefficient, and the system used to work fine without it.

Any insights or suggestions would be greatly appreciated!

Thanks in advance! :blush:

What is this “RGB Controller”? Which binding? Ughh, sorry it’s in the title “Wifi LED Binding”

This was the recent change made to the binding:

Ehm alright… What do I have to do?
After reading I don’t know what to should do

I reverted the changes from that PR and built a jar. Please test and see if your problem is gone, then we can look at figuring out how to make the PR be backwards compatible.

  • Uninstall the official binding
  • Download this file and remove the .txt extension, then drop it into your addons folder

org.openhab.binding.wifiled-4.3.3-SNAPSHOT.jar.txt (41.0 KB)

Do you see something different in the debug logs when you add / remove the postUpdate? If you spot one more “Setting LED State to XXX” and that is ends with a 00 byte, then it could be because your LED doesn’t support write modes other than 0x00 (so the exact reverse of my bulb, which doesn’t support 0x00). I didn’t change anything else than this last byte.
Maybe posting your logs could help to debug this.

thanks, it did solve the issue perfectly!

what exactly solved the issue?

How could this be solved to support both? Maybe Thing configuration?

Yes, I thought about a new config option. If it’s set, we always use 0x00. I didn’t want to make this option when I did the changes because I didn’t want to add complexity if it wasn’t needed. It’s also a bit hard to word that option clearly as it’s a low-level thing…
It could also be a new protocol (there are 3 protocols in the configuration for now, each having their own small particularities).

EDIT: It seems to be a real thing as I found a mention to rgbwprotocol in flux_led, the implementation I took for reference. I’ll try to add the config option to “always overwrite both color & whites”, like flux_led.

I’ve added the new config option. @Caffeineshock, could you try to install this new org.openhab.binding.wifiled-4.3.3-SNAPSHOT.jar, enable the “RGBW Variant” in your thing options, then test if your rule works as expected?

The source code is on my v4.3.x-wifiled-fix-rgbw-variant branch.

i installed to version you linked in a previous post, which i also marked as the solution

i will try this version in the next few days and will report