MiLight/Easybulb/LimitlessLED Plugins

These plugins may be used to control MiLight/Easybulb/LimitlessLED Wifi-controlled LED lamps via a Wifi Bridge connected to your home network. The plugins emulate a Dimmable Light (with additional features) so may be controlled through Vera’s UI, scenes, PLXX plugins and some remote apps.

These lamps are being sold in most parts of the world but under various names. I have been assured by the manufacturer that Mi-Light, Easybulb and LimitlessLED are identical products.

There are three types of the lamp: MiLight White, MiLight RGB and MiLight RGB+W. The White version is an energy-efficient white lamp with a good dimming range and an adjustable colour temperature. The RGB version can give you some interesting lighting effects in a variety of colours but does not have a good white. The RGB+W version can be used for both coloured lighting and warm white. Some types of lamp are available in different power ratings (Watts). In addition to normal lamp styles, there are down-lighter and LED strip types available.

Each type of lamp has its own remote control but can also be controlled by Android and iOS apps through a WiFi Bridge. There are two models of Wifi Bridge: The earlier version could control four zones of White lamps and a single RGB zone; The latest version (V3) can additionally control four zones of RGB+W lamps. A zone may include multiple lamps that will be controlled together. Each of the plugin devices provides a Dimmable Light control for a single zone. Multiple devices can be created so that each zone may be controlled separately. Multiple devices of the same or different plugin types may be used with the same Wifi Bridge. Multiple Wifi Bridges may be used to cover larger areas or increase the number of zones.

The control protocol used by these lamps is one-way. This means that the plugin can only know the state of the lamps by what commands it has sent previously. If you control the lamps with a hardware remote or Smartphone app, the plugin will not know this. Should this happen, the plugin can be re-synchronized by selecting Min then Max and then resetting color and/or effects modes. The lamps can also be synchronized to the current Vera device settings by clicking the Sync button on the Control tab.

The plugin for the White lamps is available here: MiLightWhite

The plugin for the RGB lamps is available here: MiLightRGB

The plugin for the RGB+W lamps is available here: MiLightRGBW

Instructions for setting-up and operating the plugins are provided through the Help tab on the plugin’s panel under APPS → My apps. You can also find them here: MiLightWhite, MiLightRGB, MiLightRGBW.

Instructions for setting up the Wifi Bridges: Wifi Bridge Setup. This is also included in the plugin Help files.

For more details on the lamps, see: [url=http://forum.micasaverde.com/index.php/topic,14051.0.html]http://forum.micasaverde.com/index.php/topic,14051.0.html[/url]

Edit: 25/01/2014 11:00 - Uploaded revised Wifi Bridge Setup.pdf including new MiLight V4 Bridge.
Edit: 20/02/2014 17:35 - Changed links. Plugins now in App Store. Removed obsolete edit history.
Edit: 04/09/2014 18:38 - V1.1 of all three plugins to support UI7.
Edit: 18/09/2014 19:10 - V1.2 of all three plugins improves support of UI7.
Edit: 13/03/2015 11:25 - V1.3 of all three plugins released. Fixes display for UI7 7.0.5.

Hope I have the correct spot for this post:

@gengen ....The wireless bridge comes with a USB to micro USB cable but no power adapter. (Fortunately, I had plenty of those from other gadgets.) It has three LED's: Link Sys and PWR. The "PWR" LED blinks at an annoyingly fast rate. Fortunately I can put this device up-side-down to hide this lightl. The Web interface is a generic WIFI to UART bridge. I found documentation for it (in Chinese with some English) here: http://www.hed.com.cn http://www.hed.com.cn/cn/DownloadFile2_201110191524012427.aspx http://www.hed.com.cn/cn/DownloadFile_54.aspx

Basically, after you have gotten the device connected to your wireless network, it simply translates the UDP (or TCP) command comming from port 50000 to the wireless chip which is broadcasting a simple protocol to any bulbs which are paired with the remote or the bridge’s node ID. UDP is inherrently an unreliable protocol and I have already seen cases when one or more bulbs would not respond to a command. The bridge also has a TCP option which might provide a possible reliability vs speed trade-off…

@jouked
UDP has no checks by itself to guarantee delivery, opposed to TCP which automatically retransmits.

Thing is though, this is only needed when packets are dropped on the network. Within a house, this normally does not happen. On bigger networks this does happen, data traveling over different WAN links, congestion, speed differences, buffering etc. etc.

@gengen
I verified that TCP does indeed work if you set the mode in the bridge setup GUI to TCP. You need to save and restart the bridge in order to have the settings take effect.

TCP can indeed be somewhat more reliable even in a home network if WIFI is heavily used, or in a crowded area such as a highrise apartment. Of course, this will break compatibility with the IPhone apps which except UDP unless they are updated to support either UDP or TCP.

TCP does not change the requirement for a minimum 50ms wait between command packets.

The bridge also has telnet port through which you can send AT+ commands which control wifi and other bridge settings. For example, try
AT+WSCAN
Probably not very useful once you have set up the bridge.

Just so I can understand this: It appears the WiFi interface can be set up to use TCP/IP instead of UDP - in which case it would be more reliable. So why is UDP used in the first place? Is it just a case of UDP being more Plug in Play than TCP/IP? Can the Plugin be designed to suit both? I note the WeMo device is also UDP and Futzle was concerned over it’s reliability - can it also use TCP/IP Or am I misunderstanding all this?

UDP is faster, its fire and forget, and its connectionless. the wifi bridge supports TCP or UDP. just the apps are only using UDP at the moment.

UDP is still reliable… just think back to how many times you have played Battlefield3, it uses UDP for every movement and trigger, it is fairly solid and fast.

It’s more subtle than that. The difference between UDP and TCP is a lot like the difference between a text message and a phone conversation. With UDP you don’t get the knowledge that the message was delivered (until they text you back). With TCP you have a two-way conversation, with all the social effort that that entails.

Just like in real life where you would opt to share some knowledge via text message and some via a conversation, some kinds of network communication lend themselves more to UDP or TCP. Case in point: WeMo is built on UPnP, which specifies that discovery is done over UDP, but control is done over TCP. That’s just how it is.

Making UDP “reliable” is generally done by specifying that the receiver has to send back a confirmation packet, usually also by UDP. This is how UPnP discovery works. Built into that is the additional assumption that the sender might need to use a retry loop around the UDP send, just in case a packet got lost.

For some kinds of communication, you could conceivably send a text or pick up the phone; both would work. Likewise some devices supply both a UDP control method and a TCP control method. This is actually uncommon, since it’s twice the work to develop two protocols.

I’m excited to see that the development of plugins for this device has progressed so quickly (thanks developers!!!).

I was about to place an order for the RGB kit on limitlessled website today and noticed that the price jumped $30 over the weekend. What a bummer! I wish I would have ordered last week!

Don’t worry zekelion, the special will be on again next week. the $19 special ended on Monday, back to normal price of $29, up $10. The warm white/cool white adjustable White is still on special. They are a lot better brightness.

Regards,
-Hamish.
LimitlessLED.

I agree, well done. I would have to say this is the first proper integration into a deep and established automation system. Thanks RexBeckett, you rock. I’ll see what I can do, for you, in terms of direct brightness control, more groups, and status feedback in the next generation products we are designing.

@zekelion, the RGB Color bulb $19 special, ww/cw bulb $16, is now available on http://www.limitlessled.com this weekend.

Cheers,
-Hamish.
LimitlessLED.

I have uploaded a new set of files for the DimmableLight emulator for MiLight White zones (MiLightWU1). I had the device type incorrect in the first version so it did not show up as a trigger for scenes or PLxx plugins. The new version should work pretty much the same as an actual DimmableLight for both triggers and actions.

To turn the lamps on and off keeping the last setting for brightness, use the SwitchPower1 setTarget action with newTargetValue=0 for off and newTargetValue=1 for on.

To directly set the brightness level, use the Dimming1 setLoadLevelTarget action with newLoadlevelTarget=?? where ?? is the required brightness 0-100.

To use as a trigger, SwitchPower1 Status will be 0 if the lamp is off or 1 if it is on - even if the lamp was turned on or off using setLoadLevelTarget.

These lamps are designed to be permanently powered with all control performed through the remote interface. In many cases that will be fine. A problem can arise with guests, however, who may assume that the wall-switch should turn the lights on and off - not unreasonable. :slight_smile: If the lamp was turned off with the remote or one of the plugins, your guest may pound on the wall-switch all day…

There is a simple solution to this. Replace your regular wall-switch with a Z-Wave switch. Now make a scene that is triggered by the wall-switch turning on and set the action to turn on the lamps.

If you are using the MiLightWU plugin, the scene action will be: PowerSwitch1, SetTarget, newTargetValue 1

If you are not using the DimmableLight emulator, you can put four lines of Luup in the scene to turn on the appropriate zone. See the head of this thread for the required Luup and control code.

Now the wall-switch will behave as a guest might expect. The only snag being that, if they leave it turned off, your automation will need to turn in back on before your carefully crafted lighting scenes will work.

Wouldn’t it then be pointless to use the MiLight bulbs if you replaced the switch with a z-wave switch? You can then use any ordinary bulb and still have vera control of the switch.

  • Garrett

p.s. Just giving you a hard time! :slight_smile:

I have tried sending every conceivable newTargetValue to my Z-Wave light switches but I just can’t find the right number to either dim the lamps or change their color temperature. ;D

I’ve been watching these LEDS on whirpool, they seem amazing for the $$$$.

Now that there is a ZWave connection, they rock.
Placed an order for 3 and can’t wait to see them in action.

I have been trying very hard to like the standard DimmableLight UI but have failed. :cry: It doesn’t quite suit the way MiLight White works so I have made a couple of improvements for the MiLightWU1 DimmableLight emulator plugin. You will get this automatically if you download the plugin from the link in the first post and follow the installation instructions.

I used the standard UI originally in the belief that it would work better for mobile access but my new version works just as well on my phone so it may not have been necessary.

If you do want to use the standard UI for some reason, upload the file D_MiLightWD1.xml (included in the package) and set Upnp Device Filename: D_MiLightWD1.xml when creating the device. You can also change this for an existing device by editing device_file in the Advanced tab. Use D_MiLightWD1.xml for the standard device UI or D_MiLightWU1.xml for the new improved version. You will need to hit Save/Reload and refresh your browser page before the change is effective.

Not strictly about the PlugIn, however. if you are tempted to jump in, I noticed the Limitless have a Starter Package going for $58, a couple of LEDS, Bridge and Remote bundled up.
If this works the way I hope then it will save a fortune in Zwave switches… ;D

Mine arrived today, shipped across the Tasman. They were easy enough to set up, as was RexBeckett’s plugin (nice work, BTW; do you accept patches?).

The lights won’t replace my dearly loved incandescents yet. Like all LEDs, direction is an issue and when placed in a table lamp pointing up, they barely light up the table. And they are a bit bigger than a typical light bulb so they tend to poke out the top of the lampshade, further contributing to the patchiness of the light. At their dimmest they are still too bright for daylight wakeup-ramp usage. Finally, the build quality of the bayonet (B22) version is questionable; one is already going to have to go back because a pin snapped off.

To be fair, the same thing is probably going to happen with the LiFX lamps that I’ve been waiting months for. It looks like I am going to have to DIY my daylight-wakeup bedroom lighting.

The ability to control the colour temperature is, I admit, very alluring. I think it’s these lamps’ best selling point.

nice work, BTW
Thank you. I appreciate the feedback. Coming from someone with your level of experience makes it even more valued.
Like all LEDs, direction is an issue and when placed in a table lamp pointing up, they barely light up the table.
Yes, I agree. They all have hemispherical light distribution. I guess it contributes to the high efficiency. They do work much better as ceiling lamps. If you put them in a shade, it reflects enough light upwards to give a little ambiance.
do you accept patches?
I just noticed that I didn't respond to your question. I'm not sure whether this is a reference to boy-scouts or software bugs. If the former, you'd have to sew it on - I'm not good with needles. If the latter, sock it to me.

Mine arrived yesterday and after a couple of email exchanges with Hamish, I managed to get them up and running.
Rex’s Plugin works well except I’m used to seeing the bulb extinguished with OFF selected (is it just me that has noticed this?). ???

Are you referring to the Light icon in the plugin? Because the Lighting System is wireless IP UDP remote control, there is no status feedback, so you won’t know the status of the bulb if other remotes or iPhones change the light status directly.

Rex's Plugin works well except I'm used to seeing the bulb extinguished with OFF selected (is it just me that has noticed this?).
Which of the three four possible device types are you using: MiLightW; MiLightWU; MiLightWD; MilightRGB? Is your issue that the lamp doesn't go completely off? How are you issuing the [i]Off[/i] command: From the plugin UI; From a scene; From a mobile app?