Initial contribution WiFi LED device binding

[monnimeter]

Hello all,

I'm almost done working on a binding for WiFi enabled LED controllers. These devices are sold with different labels like Magic Home LED, UFO LED, LED NET controller etc.

The binding supports communication in both directions: it can set values (hue, saturation, brightness) and it also can read the color and status of the LED if it was set by i.e. an external App.

By reverse engineering an Android App I found out how to discover the devices, so the binding also implements a DiscoveryService :)

I'm actually testing the things and trying to finalize the code and make everything ready for a pull request.

Ideas, suggestions etc. are welcome :)

Regards, Osman

PS: I saw that some days ago a binding for openHAB 1 was announced https://community.openhab.org/t/ld382-led-controller-binding/4354

[hakan42]

Could you give some links, maybe amazon or aliexpress, where such hardware might be bought?

I am thinking of replacing my milight bulbs which have only one-way communication.

[monnimeter]

I bought this one. Works well, so I decided it's worth spending time for making a binding. XCSOURCE DC 12V 24V Magic LED WIFI Controller für RGB RGBW RGBWW LED... http://www.amazon.de/dp/B00Q7STR4E/ref=cm_sw_r_em_udp_awd_LbowwbMT10W5Z

[magcode]

Hi, I have developed the OH1 Version for the LD382 binding.

https://github.com/magcode/openhab/tree/master/bundles/binding/org.openhab.binding.wifilight

Not sure if you can reuse something from this code.

Do you support both versions of the controller?

My idea was that more controllers might be supported by this binding (such as the older LW-12). I like the solution in FHEM ("wifilight") Also refer to http://knx-user-forum.de/forum/supportforen/openhab/41213-lw-12-led-controller-binding.

[monnimeter]

Hi @magcode,

thank you for your feed back. IMHO my binding supports only newer devices (like the one I've got)... I think they are sometimes refered as "v3" or LD382A devices - but I'm not really sure about the naming.

I had a look in the forum and I think I could extend the binding to also support LW-12 and/or LD382 devices (send different data telgrams depending on configuration). Could or would you then please test it with an "older" device?!

AFAIK the older devices do not have a two-directions communication and I'm not sure if they support automatic discovery.So at the end it may be that the end user will have to configure those things manually.

I'll also have a look into your code and see what could be reused for this task.

Thank you.

[magcode]

Yes, I have the older LD382 and would be happy to test it with your binding/OH2.

Implementation should be easy as it is just one "0x0F" that must be omitted. Autodiscovery: At least the Android app scans the network and finds my controller. So I assume it will work as well with the older device.

Some questions:

1) LD382 supports some predefined "programs" which can be called according to http://www.emessaging.biz/blog/?p=629. Any plans to implement it? (I'd like to have the "Red Strobe Flash" as a alarm signal in my room)

2) Do you support any fading/dimming/smooth color changing? I tried but its rather hard without proper mathematics skills ;-) The FHEM guys seem to have a really cool solution. https://github.com/herrmannj/wifilight/blob/master/FHEM/32_WifiLight.pm

[monnimeter]

Initially I was not sure if supporting the "programs" is a good / useful idea... but your use case (= alerting) sounds good and convinced me to do it :) For that purpose I will add two additional channels: program (as number) and speed (as dimmer).

Please tell me more about your 2nd question. What do you mean with fading / dimming / smooth color changing exactly?! How does the use case look like?

Additional info: new devices support RGB plus a separate channel for (warm) white. I'll add support for that 4th channel (as Dimmer).

[monnimeter]

Here we go - the actual state: I'm about to finalize my work (incl. support for LD382 and LD382A) and hopefully push the binding during the next day(s)...

[magcode]

Nice! This is more or less what I did for OH1. I'm already using the white channel for an extra warm white strip.

What do you mean with fading / dimming / smooth color changing exactly?!

It would be nice to let the binding dim the different levels. Lets say I turn on "white". The binding could know that the old state of "white" is zero. The new percentage value is 60%. So it would dim from 0 to 60% within 2 seconds or so. The same could be possible for rgb. However this is just nice to have and not so easy to implement. You will need some queue.

[monnimeter]

Pull request for initial contribution placed: https://github.com/openhab/openhab2/commit/8f4fe97f5286478c6652c5da3b1944b3e9b67900

Please test it and let me know if and how it works with the "older" devices.

The dimming / fading feature is not implemented. But I've got an idea how to do it. Will implement it during the next weeks (as soon as I've some spare time).

[vmartinvega-pivotal]

Hi all,

I recently bought a wifi led controller which I am not sure if it is compatible with this addon implementation, alghouth I would be able to adapt it. My concern now is to know if this addon implementation (openhab 2) is compatible with openhab 1.8, that is, can I install it in the 1.8 runtime and wait for it to work? or do I have to modify the code to have it running in 1.8 runtime?

Best regards

[monnimeter]

This binding is made for openhab 2. You cannot deploy it within the older runtime.

[magcode]

For OH1.8 you can try:

https://github.com/magcode/openhab/releases/tag/wflda

https://github.com/magcode/openhab/tree/master/bundles/binding/org.openhab.binding.wifilight

add to openhab.cfg:

wifilight:LD382.type=LD382A

[vmartinvega-pivotal]

Many thanks for your info. I got the code for OH1.8 (https://github.com/magcode/openhab/tree/master/bundlees/binding/org.openhab.binding.wifilight) and I modified the code to be compatible with ld382A (I got WiFiLEDDriver and LEDStateDTO classes) from the implementation done for OH2. With this implementation I can Turn On/Off the led but I cannot change the led color, brightness and so on... Has someone tested the binding for ld382A?

@monnimeter Did you test the binding (your WIFILEDDriver class for ld382A protocol?

Regards

[monnimeter]

I've got only LD382A devices... so the the driver is tested and works well within the OH2 binding. The support for LD382 (without A) was added later - but I've never tested it (s. above).

[xylo]

Hi. I'm very interested in getting my LD382A to work with OH1.8 or OH2.

@magcode Your last post sounds as your addon (https://github.com/magcode/openhab/tree/master/bundles/binding/org.openhab.binding.wifilight) supports the LD382A, too. However, I don't see any LD382A related code in the repository. Maybe you forgot to push your changes up?

@monnimeter At the moment you pull requests has some merge conflicts. Do you plan to fix those conflicts? If not, I would like to do that.

[xylo]

@monnimeter I fixed the merge conflicts in my local openhab2-addons repository (I just commented out the method WiFiLEDHandler.postInitialize). I'm not sure if this is the best option. However, the addon works again.

Anyway. I saw an On/Off switch in your screenshot posted above. Did you handle the switch via rules?

[monnimeter]

Hi @xylo. Nice to hear you fixed the issues :+1: The On/Off switch in the screen shot was created automatically by the PaperUI. In real life I'm handling switches via rules.

[xylo]

@monnimeter I would like to add a switch channel to simplify the On/Off procedure and a color fading feature as suggested by @magcode. I wonder if it's better to let the user set the fading time via a configuration option or via a channel. Another feature I might add is a color correction, since the red channel of my LED stripes is very weak and so I never get exactly the color I want.

Moreover, I would like the addon to be integrated in openHAB and if possible with the features mentioned above. Thereto I forked the openhab2-addons repository and added your addon files. However, this means that the version history of your files get lost in my repository. :( On the other hand, merging both projects via git seems to be quite complicated. Therefore I would like to avoid that. Is this OK for you? When I push my changes up to github.com I will add a link to your project page to point out the origin.

[xylo]

I implemented the color fading and created another pull request: https://github.com/openhab/openhab2-addons/pull/755

There are now two drivers for controlling the LEDs which can be selected in the thing configuration. The "CLASSIC" driver is the one of @monnimeter. It implements the bi-directional status update, white and color channels, as well as program feature.

I skipped some of these features in my "FADING" driver, because they do not really fit in or have annoying side effects. Those skipped features are the program feature and the status synchronization from the controller to openHAB. The first one is IMO not really needed if you have color fading. The latter one is at the moment skipped to avoid conflict during the fading. I wanted to avoid that intermediate LED states during fading are suddenly changing the LED state set by the user. I think it's better to always show the target state. But that's something one can still improve. One could allow the bi-directional updates while not fading.

The fading duration and number of fading steps can be set in the thing configuration. For more details, take a look at the readme on https://github.com/xylo/openhab2-addons/tree/master/addons/binding/org.openhab.binding.wifiled

Moreover, I added a "power" channel to the "FADING" driver which allows for turning the light off and on without loosing the last LED state. Turning on or off means fading in or out.

[monnimeter]

755 fixes and enhances this PR. Thank you @xylo and @PH89.

[Tazzios]

Where can i find a .jar file of the org.openhab.binding.wifiled ?

(Sorry, Im new to openhab. Still struggling with openhab. Rried some compiling but have no idea what im doing/ should do)

[xylo]

@fsdfasf Here is a compiled version of the patched wifiled (see #755). You need to put it into the addons folder of your openhab2 distribution.

[Plus06]

Where can I find the add ons folder in a openhab2 installation? Sry. I'm quite a newbie. Is copying the .jar-file the only action I need to do? Thanks in advance for your support

[xylo]

@Plus06 I assume you installed openhab2 via apt-get. In this case you have to put the .jar file into /usr/share/openhab2/addons. Maybe you have to restart openhab2 afterwards. Then the binding should be listed in the PaperUI under Configuration->Bindings as "WiFi LED Binding".

[chris-si]

Hi, I have a question regarding controlling the controller with rules and sitemaps.

Which and how do I have to send values from a rule/sitemap to my controller (wifiled:wifiled:ACCF23XXXXXX:power/color) to change the color or power it on or off? I want to use my dash button to change to specific colors. Before I had the led controller I used an Arduino Uno with ethernet shield and transmitted the values for the colors via MQTT (for example 44, 10, 0 for RGB).

The openhab log shows me something similar with 4 values. 13:55:56.299 [INFO ] [ifiled.handler.AbstractWiFiLEDDriver] - RGBW: 22, 4, 1, 0

Can I send values as easy as I did it before with simple numbers to the controller?

[monnimeter]

Hi @chris-si,

thank you for using and testing this binding. The good news is: yes, you can!

Here's an example from my setup... it needs at least two items:

Number WO_Scene "Scene" <scene> (WO, PERSIST) // Trigger für scene.rules
Color WO_Licht_LED "LED-Licht" <colorwheel> (WO) {channel="wifiled:wifiled:AC1111111111:color" }

This is the relevant line from the sitemap:

Selection item=WO_Scene mappings=[0="Aus", 1="Kino", 2="Hell", 3="Sun"]

And this is the relevant rool:

rule "living room"
when
    Item WO_Scene received command
then
    logInfo("scenes", "[living room] WO_Scene received command: " + receivedCommand)
    if (receivedCommand == 0) {
        sendCommand(WO_Licht_LED, OFF) /* Aus */
    } else if (receivedCommand == 1) {
        sendCommand(WO_Licht_LED, "0,70,20") /* Kino */
        sendCommand(WO_Licht_LED, ON)
    } else if (receivedCommand == 2) {
        sendCommand(WO_Licht_LED, "0,0,100") /* Hell */
        sendCommand(WO_Licht_LED, ON)
    } else if (receivedCommand == 3) {      
        sendCommand(WO_Licht_LED "20,100,20") /* Orientierungslicht */
        sendCommand(WO_Licht_LED, ON)
    }
end

As you can see, you can send commands like ON and OFF, but also color values. The color values are not RGB but HSB values.

Regards, Osman

[xylo]

@chris-si In case you downloaded my compiled jar file you also have to define a "Switch" item for the "power" channel and set this channel to ON.

Additional Items:

Switch` WO_Licht_LED_power "LED-Schalter" {channel="wifiled:wifiled:AC1111111111:power" }

In your rules you can either use

sendCommand(WO_Licht_LED_power, ON/OFF)

instead of

sendCommand(WO_Licht_LED, ON/OFF)

or set the WO_Licht_LED_power channel once to ON and keep using

sendCommand(WO_Licht_LED, ON/OFF)

Note that WO_Licht_LED_power turns all channels (RGB and white) ON/OFF.

[Legacytrx]

Hi guys,

I have used the current github version and testeded it on another RGB WIFI module, the WIFI370. Unfortunately the protocol is not fully alike, but it took me a day to adapt it to make the first color adjustment via openhab2. So the question, shall I do it as a seperate binding or shall we extend the WIFILED binding. I am not sure how much modifications that would mean though, I am new to JAVA :-).

Maybe I should have added the module I bought: https://shop.ledwarehouse.se/rgb-wifi-dimmer-144w-12v-24v.html

Frank

[chris-si]

@monnimeter @xylo

Thanks for the example. With the code you provided the binding works very well. I just had to figure out that the three value aren't RGB values but "color/saturation/brightness" values :)

[emcandrew]

Love this binding... quick question though...

I'm trying to control a mixed white led string. The warm leds are on the white channel and the cool leds are on the white2 channel.

The way to control the temperature of the lights is by a combination of the two channels (e.g. 10% white, 25% white2).

I'm trying to set the channels in series. It would look something like this:

if (KitchenCabinets_power.state == OFF) { KitchenCabinets_power.sendCommand(ON); Thread::sleep(50) } KitchenCabinets_white.sendCommand(new PercentType(10)) KitchenCabinets_white2.sendCommand(new PercentType(25))

My thing is configured as:

Thing wifiled:wifiled:F0FE6B2319F0 [ ip="192.168.0.123", port=5577, pollingPeriod=3000, protocol="LD686", driver="CLASSIC", fadeDurationInMs=1500, fadeSteps=100 ]

My items are configured as:

Switch KitchenCabinets_power "Power" {channel="wifiled:wifiled:F0FE6B2319F0:power"} Dimmer KitchenCabinets_white "Warm White" {channel="wifiled:wifiled:F0FE6B2319F0:white"} Dimmer KitchenCabinets_white2 "Cool White" {channel="wifiled:wifiled:F0FE6B2319F0:white2"}

Everything works ok individually, but when I try to execute as above, the warm lights come on first, then shut off as the cool lights come on. (white comes on, then shuts off when white2 comes on)

Anyone have any ideas?

[xylo]

@emcandrew I have to admit that I never tested the white2 channel. I hoped it will work like the other channels. I will look into it.

[emcandrew]

Thanks xylo...

If there's anything I can do to assist, please let me know!

[rvt]

@emcandrew: I posted on the forum aswell, but I have possible a fix for this issue:

Everything works ok individually, but when I try to execute as above, the warm lights come on first, then shut off as the cool lights come on. (white comes on, then shuts off when white2 comes on)

The problem is with the calculation of the precent values that are done with Integers rather than using floating point values. I also have a fix for a issue where if you set the RGB and white color you see two updates instead of one.

see: https://github.com/rvt/openhab2-addons/commit/b85a5102cdabd90e045a81bbfb126a57d969e7eb

It's still WIP...

[tagazok]

Hi, I am considering buying this item It uses LD121E, does anyone know if this is supported by the addon? :)

[rvt]

tagazok,

I see this device as french only so it might be a copy of something else. However, what I don't seem to find on the amazon page is if this device is wifi enabled. From what it looks like it's IR only (also based on http://demoxcs.com2.hk/p_detail.php?id=493)

[tagazok]

Oh, you are right, there is no mention of wifi anywhere. Thanks, I will try to find another one compatible then :)

[rvt]

Tagazok, if you have a bit technical background (you don't need a lot though) you can consider the Airlux devices and re-flash them with new code that support MQTT then you will get a much more reliable device connection whise....

[m4rky-m4rk]

Hi, I am new to Openhab2. I installed the binding with the hope it works in the EasyColor WiFi adaptor for RGBW LED strips eg https://www.instyleled.co.uk/wifi-receiver/

I can control the strip via EasyLighting phone app but although the Thing shows the WiFi LED as Online with the Fading driver and the log shows commands being sent the RGB receiver doesn't respond. I tried the various settings but no joy. Should it work with this binding or am I out of luck?

I tried to find out a bit more about the adaptor but only discovered that it has HF-A11 WiFi module.

Also found this which might be relevant but its two years old: https://github.com/openhab/openhab1-addons/pull/4286