Sorry Rex, I should have made myself more clear.
It’s the UI that has the globe “illuminated”. ;D
Now, if we could only “hack” the Bridge so we can access multiple RGB’s… 
It's the UI that has the globe "illuminated".I thought you'd found a bug for me to fix. ;)
I set the icons for MiLightW and MiLightRGB to fixed ones because there is no feedback from the lamp to steer different states - as mentioned by LimitlessLED. These two plugins were just intended to emulate the remotes via the bridge for experimenting.
The icon state for MiLightWU is driven from the dim level. I personally hate the way that normal dimmer UIs turn the lamp on and off by changing the dim level to 100% or 0% defeating the object of the dimmer module retaining its last level setting. So, I use the PowerSwitch1 SetTarget action to turn the lamps on and off whilst leaving the dimmer setting alone - so the icon reflects what the lamp will do when it is switched back on. ;D It would be very easy to fix this by adding another state variable to drive the icon. I’ll consider whether this has any implications for mobile apps - probably not. Watch this thread for news.
Meanwhile, if it bugs you, you could always switch to using the D_MiLightWD1.xml device_file which uses the standard DimmableLight UI so sets the level to 0% for off and 100% for on. See: this post.
Now, if we could only "hack" the Bridge so we can access multiple RGB's....That would be nice but don't hold your breath. I suspect that the one-RGBlamp-per-bridge limitation is in the design of the lamp rather than the bridge.
BTW: I do plan to write a DimmableLight type plugin for the RGB lamps. The issue at the moment is how to achieve color control in a sensible way. I may just steal @intveltr’s good work on the Hue plugin. ;D It isn’t high on my priority list at the moment as I’m not actually using the RGB lamp apart from when testing stuff. If anyone is waiting for this, do let me know.
I have uploaded a new version of MiLightWU1 to the link in the first post. This plugin provides a DimmableLight-type device that looks and behaves similar to a normal dimmer but with added features. The upload includes updated instructions for installation and use.
New features
There is now a button on the Control tab to set Nightlight mode.
There is now an input field and button to set Color Temperature in degrees-K (2700-5000).
SetNightMode is now available as an action for use by scenes and other plugins.
SetColorTemperature is now available as an action for use by scenes and other plugins.
You can now set zone to 0 to control all four zones simultaneously.
The device UI icon now reflects the complete lamp state - not just the dim level.
I think this plugin now fully supports the features of the White MiLight/Easybulb/LimitlessLED lamps. Barring bug fixes or suggestions for new features, I’m not planning any more changes. I now intend to implement similar functionality for the RGB version of these lamps.
Hi RexBeckett,
I’ve had a chance to play with the current version of the White light files. They look damn good. Here’s some feedback.
So far your device file still announces itself as a UPnP DimmableLight1 device. You’ll need to change that to use your own device type string. The reason is that MiOS will only associate one static JSON file with each device type. Hence if you stick with the same device type as other dimmable lights then you can only change the dashboard appearance of all dimmable lights on Vera, including normal Z-Wave ones. So change D_MiLightWU1.xml like this:
<deviceType>urn:schemas-dcineco-com:device:DimmableLight:1</deviceType>
<staticJson>D_MiLightWU1.json</staticJson>
<Category_Num>2</Category_Num>And change D_MiLightWU1.json like this:
"DeviceType": "urn:schemas-dcineco-com:device:DimmableLight:1",
"device_type": "urn:schemas-dcineco-com:device:DimmableLight:1"With both those changes I see your new UI. Remote apps will still work because you haven’t changed the services, and it’s the services that remotes (should) look at, not the device types. Setting the category helps there too, as in my code snippet.
You may as well delete all the Get… actions from the service and implementation files. As you’ve seen from another thread, Vera can’t return anything from an action, by MCV’s design.
I notice when I turn the light on from 0% to 10% that it goes right up to full brightness and then down to 10%. I know why you’ve done it that way, but it messes with my plans to create a wakeup-ramp light with these lamps. WAKE UP!!! I mean, (wake up). I’m thinking that if the plugin were to alter the “off” behaviour so that it dims the lamp down to the lowest setting before sending the “off” packet, then it could just send the “on” packet rather than “full” when turning the lamp back on again. The tradeoff is that turning the lamp off becomes a fade rather than instant. What do you reckon? (Edit: I see the phrase “personally hate” coming up again in 3, 2, 1…)
Pet peeve: It’s not “Degrees Kelvin”. It’s just “Kelvin”, symbol “K”.
Hi futzle,
Thank you very much for your constructive feedback. I really appreciate the guidance.
OK on the device types. I don’t have any real dimmers so didn’t see a problem. I’ll change the device types as you suggest.
You may as well delete all the Get... actions from the service and implementation files. As you've seen from another thread, Vera can't return anything from an action, by MCV's design.I had been wondering about that. I think I copied the idea from another plugin believing it to be necessary. I'll remove them.
I notice when I turn the light on from 0% to 10% that it goes right up to full brightness and then down to 10%. I know why you've done it that way, but it messes with my plans to create a wakeup-ramp light with these lamps. WAKE UP!!! I mean, (wake up). I'm thinking that if the plugin were to alter the "off" behaviour so that it dims the lamp down to the lowest setting before sending the "off" packet, then it could just send the "on" packet rather than "full" when turning the lamp back on again. The tradeoff is that turning the lamp off becomes a fade rather than instant. What do you reckon?Funny you should mention that. I'm just coding the RGB version of this plugin and realised that I'd missed doing that in the white version so I went back and changed it. I'll upload it when I've fixed the other bits. Do yourself a favour and don't try using the RGB lamps in your bedroom. They go to full brightness whenever you change the white/colour/effects mode and I can't drag them down quick enough to avoid the semi-strobe effect. Not what you want first thing in the morning. :o
Pet peeve: It's not "Degrees Kelvin". It's just "Kelvin", symbol "K".Now you're just being picky. I went to a lot of trouble to put the degree symbol into the json. OK, it may not be SI but they only changed it in 1967 and I learned the previous form at school. We measure colour using the CIE XYZ color space defined in 1931 when degrees-K was standard practice. To be equally picky, SI defines it as kelvin not Kelvin. :P I shall give due consideration to removing the offending glyph.
Thanks again for taking the trouble to tell me this stuff.
OK @zedrally and anyone else who’s interested, the dimmable-light plugin for the RGB lamps is ready for testing. This is probably an alpha test. It’s working fine on my system but it is new so may need a tweak or two. The download link is on the first post in this thread. Look for MiLightCU1.
Like its brother for white lamps, this plugin emulates a dimmable-light but with additions to support the features of the RGB lamp. The extra features are set on the device’s Control tab - or by action calls from scenes and other plugins. Functions are provided to set Hue for coloured light, EffectsMode for disco-type effects, EffectsRate for the speed of the effects and White to do what its name suggests. There is also an Enroll button for use when enrolling a new lamp onto a WiFi Bridge.
As with the white dimmable-light, the plugin cannot read the state of the lamps so must assume it alone is controlling them. If you change the state of the lamps with a hardware remote or MiLightRGB plugin, things will get out of sync. You can resynchronise any parameter by setting the value to zero. This will reset the lamp to the minimum setting for that parameter after which you can set the value you want. The dimming level and EffectsRate are automatically resynchronised whenever the EffectsMode is changed to work around an oddity in the lamp behavior.
@futzle, this plugin incorporates all the changes you suggested for the white version and there is no mention of degrees-Kelvin. ;D
Thanks Rex, but RL work calls until Monday for in depth testing. 
UI looks great.
If you already downloaded the files for MiLightCu1, go get the latest version. I fixed a bug.
I have uploaded a new version of MiLightWU1 (dimmable-light emulator for white lamps). This version incorporates the changes suggested by @futzle so it will play nicely with normal dimmers.
It should now give a much nicer response to setting the LoadLevelTarget to 0. This should give you a smooth fade down and finally switch the lamp off. If, when a lamp has been dimmed to 0, you set a LoadLevelTarget of 100, the lamp will switch on at full brightness. If, however, you set a value of 99 or less, the lamp should fade smoothly up to this value.
I’ve also added an Enroll button to add new lamps to the WiFi Bridge. At other times, the button does the same as On.
Finally, in deference to @futzle, the color temperature is now labelled Color Temp. K and the button is Set K. ;D
If you have this plugin installed, please upload all four new files (D_MiLightWU1.xml, D_MiLightWU1.json, I_MiLightWU1.xml and S_MiLightWU1.xml and then Save/Reload followed by a browser page reload.
This works great. I’ll have to tie up the Wakeup Ramp plugin to it and see how well it works. Wonder if I can make it ramp the colour temperature at the same time… (Another Vera UI shortcoming, you can’t have more than one slider; otherwise it’d be cool to be able to adjust the colour temperature by dragging a slider.)
Finally, in deference to @futzle, the color temperature is now labelled [b]Color Temp. K[/b] and the button is [b]Set K[/b]. ;D
We in the SI cabal thank you.
This works great. I'll have to tie up the Wakeup Ramp plugin to it and see how well it works.It's worth a try. Bear in mind that the lamp only has ten steps from 5% to 100% so you won't get a long, smooth fade. The color temperature is also done in ten steps. BTW: There is a hidden feature in the color temperature processing. If you set it below 2700, it will force a resynchronisation of the lamp's color temp setting and leave it at 2700. This may be important if you are sending it ramping values. If you started at 2699 then you would be sure it was correctly synchronised.
(Another Vera UI shortcoming, you can't have more than one slider; otherwise it'd be cool to be able to adjust the colour temperature by dragging a slider.)Yes - if I coulda, I woulda. I'm trying really hard to use the standard json UI features but suspect that, before too long, I shall find myself reaching for js to overcome the limitations. It is [u]so[/u] annoying not to be able to write stuff into the input textboxes!
We in the SI cabal thank you.You are very welcome. Thanks for the feedback. Please let me know if you trip over any bugs.
I got the wifi controller also. But only i dont get it paired with my device.
Pairing according to the devices is don with the remote by touching button number 5 (s + ) but pairing according to the wifi module is by pressing button 3 ( b + ) but i dont get it paired.
Even when i try to do s + in the mobile app i still don’t get it paired.
I know this is offtopic but i dont really know an other place to ask it 
`
Giving it some extra tries… i got it working using the s + key
Hi RexBeckett
Great job on the plugin but so far I have failed to get it to work - I will keep trying!! You can read my post about WiFi problems here re: the LimitLess LED versus WeMo:
http://forum.micasaverde.com/index.php/topic,14508.msg114343.html#msg114343
A quick question - what is the difference between the two “IP” entry fields in the Advanced Tab - one up the top and the other down with the port number?
If the LimitLess people are listening: your B22 bulbs could be slightly more tapered where the white plastic meets the bayonet metal shell, rather than the small plastic lip at the junction. Compare to one of these where the plastic tapers right to the shell:
http://www.ledbenchmark.com/display.php?id=6&name=OSRAM+LED+Superstar+Classic+A+50+Advanced
I have some lamp sockets where the LimitLess LED can’t be plugged in, whereas the linked to bulb above can be and it’s the slight lip that makes the difference. Not a problem with the Edison screw types.
thanks for the feedback a-lurker, yes this week we are designing a more tapered 8W brighter white and rgb versions of B22.
Cheers,
-Hamish.
LimitlessLED.
Can someone verify that these are the correct settings on the LimitLess LED web page - they seem OK to me? I ask, only because FireFox was causing me all kinds of grief with what was grayed out and what was not. I had to resort to Windows Exploder!!
Auto Mode Settings:
Auto Mode Enable : checked
Protocol: UDP
C/S Mode: SERVER
Server Address: 0.0.0.0 (grayed out)
Tcp Link TimeOut: 120
Port Number: 50000
Further questions - am I correct in saying, that you don’t need the remote control to Enroll the bulbs - that is: you can just use the Enroll/Light On button in the Plugin? Do the LEDs on the bridge flash or do anything when it receives(UDP)/sends(bulb) commands? How can you verify that the bridge is receiving commands from the plugin - anything in the log file?
I too had to give up on Firefox and use Safari. The installation instructions say to use Safari or Chrome, so clearly the web page in the firmware wasn’t tested on all platforms.
Hope this might help.
I had all sorts of problems here as well, luckily Hamish was spot on with his advice and very prompt as well.
I’m using Chrome and Android. The IP for the bridge is 192.168.0.100
The xxx.xxx.1.100 appears to be a apple thing.
Screen shot attached for bridge settings.
I used the remote to Enroll the LEDS firstly, had a lot of problems here as well as there was residual current in the wiring, the solution was to disconnect (unscrew) the LEDS, then reconnect, follow the procedure. Then used the PlugIn once I verified all was OK.
@zedrally - thanks for that it confirmed I was on the right track.
OK after much messing around it “appears,” that starting from scratch, that neither the white or RGB plugin will enroll any of the LED bulbs. I had to make use of the Android app “WiFi controller 2.0” to get things working:
https://play.google.com/store/apps/details?id=com.cdy.client.remoteLed
I enrolled just one bulb using the phone app and from then on I could use the Vera Plugins to enroll either white or RGB bulbs. Beside the ip address and port number, the phone app wanted a username? I can only assume that first time round the phone app is setting up something additional in the WiFi bridge, that we don’t know about.
Assuming I haven’t messed up, it would be nice to know what this is, so that the plugins could be modified to be totally independent of the phone app. So anyone who is a first time user please try to enroll a bulb, using the Vera Plugins, before accessing the bridge with any phone app and see what happens.
It would also be productive, if the WiFi bridge “Sys” LED could be used to indicate when a UDP datagram has just been received. The flash rate on the bridge power LED is somewhat annoying as well.
All great stuff and the plugins work well.
EDIT: not sure I have this correct. It may be the case that I’m just too slow with the Enroll button or the two seconds you have is actually shorter? I’m finding the enrollment process to be inconsistent.
I can’t remember being asked for user name, however if I was, then I would have entered the default for the bridge.
IIRC, it was admin, 1234.
Hopefully, someone else can chip in here and verify it.
If anyone is interested in a Python API for the LimitlessLED lights, checkout my new Python-WiFi-LEDs package.
You can install it via pip install wifileds or via the source at GitHub - joaquincasares/python-wifi-leds: A cross-vendor Python library for WiFi LED products..
Full documentation can be found in the README.md in the root of the project, wifileds/limitlessled/README.md, and test files located at the GitHub link.
Hope this helps someone and if you have anything you’d like to add, I’ll happily be accepting pull requests! 