Configuring the MiLight/LimitlessLED/EasyBulb wireless bridge

MiLight Bulb E27 We have seen in a previous article how nice it is to control the lights in your home using the Raspberry Pi and MiLight/LimitlessLED/EasyBulb Wi-Fi enabled LED bulbs. We have also seen how you can do some automation, like replacing your alarm clock with automatically turning on the light bulbs, to wake up more gently. But there is one important device that needs to be set up correctly for these things to work well. As we know, the MiLight/LimitlessLED/EasyBulb wireless LED bulbs do not actually contain a Wi-Fi receiver. They respond to radio signals (over 2.4 GHz) which are sent to them either by a simple remote control or by the MiLight wireless bridge. So to enable controlling them over Wi-Fi, the data must go through the wireless bridge.

There are two possible problems with the MiLight wireless bridge in its default configuration, as it comes out of production:

1. It uses a dynamic IP address inside the LAN.

2. In some systems the wireless bridge is trying to communicate with the outside world, which causes the lights to automatically turn off again and again.


Assigning a static (fixed) IP address to the MiLight/LimitlessLED/EasyBulb wireless bridge

MiLight Wireless Bridge With Static IP

By default the wireless bridge uses a dynamic IP address allocated to it by your wireless router. This is not a problem per se, it is actually a great thing, as long as you are controlling the bridge with your phone, which automatically finds the device, because you don’t have to go through the hassle of configuring it. But if you happen to be an advanced user and wish to send commands to the MiLight wireless bridge from a computer, like the Raspberry Pi, then you have to address it with its IP address. And if that IP address is allocated dynamically, meaning that it might change every time the router or the bridge itself reboots, this becomes a problem.

So we need to allocate a static (fixed) IP address to the bridge. If you have a router which allows you to map devices (MAC addresses) to IP addresses, then you can simply go into the router’s configuration page (usually you can do this by accessing from a web browser), find the section which allows these mappings to be defined, find the MiLight bridge in the list of devices connected to the router (using its name) and assign it the IP address of your choice.

Unfortunately some routers don’t allow mapping devices to fixed (static) IP addresses. Not all hope is lost in this case, because the devices can request a fixed IP address for themselves. The MiLight wireless bridge V3 (black label) can do this too:

1. Access the wireless bridge’s configuration page. First you have to find its current IP address by looking at the list of devices connected to the router. After that you can access the config page by going to MiLight_IP/home.html in you web browser. For example if you see the MiLight bridge in your router’s device table with IP address, then go to in your browser.

2. If the config page is in Chinese, you should see a small button labeled “EN” in the top right corner, with which you can switch to English.

3. Go to the “STA Interface Setting” section.

4. Change the “WAN Connection Type” to “static (fixed IP)“.

5. Fill the 3 fields that appear:

5.a. IP address: the desired fixed (static) IP address (for example

5.b. Subnet mask: a suitable subnet mask, for example

5.c. Default Gateway: the IP address of your default gateway.

6. Click “Apply“.

7. Power off (unplug) the MiLight wireless bridge and wait a few seconds.

8. Power on (plug back in) the wireless bridge. after a few seconds the “Link” LED should light up and everything should work fine. The bridge will now always have the static IP address that you have assigned to it.


Finally, if your router does not allow assigning a static IP address to the MiLight bridge and you have a V4 bridge (not V3), then you plain out of luck, because the feature of being able to configure a fixed IP address has been disabled in the new version of the bridge (V4 – green label). In this case you cannot use the bridge with a fixed IP address.


Preventing the wireless bridge from communicating with the outside world and turning the lights off automatically

MiLight/LimitlessLED/EasyBulb Wireless Bridge

It seems that the MiLight wireless bridge is sometimes attempting to communicate with the outside world (send/receive data from outside the LAN). In some systems this has the unwanted side effect of automatically turning off some MiLight bulbs after a few seconds or minutes after they have been turned on. And this happens again and again, as the bridge is trying to communicate with the outside world (by the way, it’s a good question why it tries to do this and what it’s sending/receiving…). This means that we need to prevent the MiLight wireless bridge from being able to communicate with devices outside the LAN.

If your router allows it, the simple solution is to block the wireless bridge in the router’s firewall section from accessing addresses outside the LAN. If the router does not have this feature, but you have a V3 MiLight bridge, you can still do this by taking away from the bridge the knowledge of where the gate to the outside world is. In other world, giving it a default gateway address which either does not exist or points back into the LAN. Follow the steps from above, configure the bridge to use a static IP address and in the Default Gateway field (5.c.) simply type or some not used IP address in the LAN.

Again, if your router cannot block the MiLight bridge from going outside the LAN and you have a new bridge (V4, not V3), then you’re out of luck, because the new bridge (V4 – green label) does not allow this configuration to be made.

I personally sincerely hope that in the next versions of the MiLight/LimitlessLED/EasyBulb wireless bridge the feature of configuring the bridge from the web browser will be re-introduced and it will allow again to be configured with a static IP address. I don’t really understand why they have removed this feature in the first place… Well, anyway, if your wireless bridge can be configured using one of the above methods, then you can easily control it from a computer (like the Raspberry Pi) and enjoy automating the lights in your home. Have fun!


Wake up gently to gradually increasing light

The problem

No alarm clocks!

Don’t you just hate it when you’re in a deep, relaxing sleep, dreaming of beautiful things… resting… not even remotely close to waking up… and then suddenly, without any preparation or warning, the alarm clock (or phone or whatever other device) starts buzzing, singing, screaming, making an awful racket, and, like a hand reaching after you into the depth of your sleep, drags you out of it instantly and makes you resent the day from the moment it begins? Well, God knows I hate it. It’s a brutal, merciless, sadistic way of waking somebody up. And yet we do it to ourselves on a regular basis. It has even been proven scientifically that when you wake up instantly from a deep sleep, you’re going to feel a lot more tired throughout the day, compared to when you wake up gently, gradually, slowly making the transition from deep sleep to a completely awaken state. Surprisingly enough, even though many millions of people go through this unpleasant process daily, I’ve never seen an alarm clock which tries to achieve a gentle awakening by starting to emit some extremely low, pleasant sounds and then slowly increasing the volume (over several minutes) to a powerful noise, which cannot be ignored anymore. This is probably because most of us are quite sensitive to sound and we would wake up more or less instantly anyway.


The solution

MiLight LED Bulb With Green Check Mark

Nevertheless there is a solution. Humans have evolved to sleep well in the dark and wake up easily in the light, so waking up to the increasing level of light in our room is a natural and much more pleasant experience. Unfortunately the sun rises at a different moment of the day every day throughout the year, usually sooner then we wish to wake up in the summer and later in the winter. This makes the sun an unsuitable wake up device for the modern man. But hey, since we’re in the modern age, we’ve got lost of technology around us and those of us lucky enough to have some remote controlled, dimmable light bulbs, have the possibility to simulate the rising of the sun by programming the light bulbs in our rooms to turn on at a specified moment of the day. The bulbs can be turned on a few minutes before our wake up time, and then the intensity of their light gently, gradually increased, until they flood the room with light so bright that it cannot be ignored anymore. The good old alarm clock or phone can be set to scare the hack out of us a few minutes after the bulbs shine brightly, just in case we’re too tired to react to the light and wake up. Believe me, I’ve been using this method for a few months now, and it’s a blessing!


The implementation

So let’s see how it can be done. Remember when I told you about the MiLight/LimitlessLED/EasyBulb LED bulbs? Also, do you remember that I’ve taught you to control them with a Raspberry Pi? Well then, things couldn’t be more simple, could they? The Raspberry Pi is a Linux computer which can easily be set up to execute actions at specified times (in this article I explain the usage of cron), so all we need now is a script which simulates the sunrise by turning on our bulbs and then gradually increasing the intensity of their light. Did I hear you thinking about how such a script can be written? Let us look at one of many ways to do it:

#The zone where the lights will be turned on (1 to 4 or 0/ALL for all zones)

#The duration of the lowest intensity (first) step (in seconds)

#The duration of the lower intensity steps (in seconds)

#The duration of the higher intensity steps (in seconds)

/soft/milight/milight $zone b 1
sleep $durationLowestIntensity

for i in `seq 2 9`; do
/soft/milight/milight $zone b $i
sleep $durationLowerIntensity

for i in `seq 10 19`; do
/soft/milight/milight $zone b $i
sleep $durationHigherIntensity

The above script turns on the MiLight bulbs and increases the intensity of their light in 3 phases:

1. In the first phase the lights are kept at minimum level for a longer period of time to give you a chance to start coming out of deep sleep.

2. In the second phase the intensity is increased slowly up to around half of the maximum level, to stimulate the waking up process even more.

3. Finally, in the third phase, the intensity is increased fast until maximum level is reached, to increase the chances of noticing it, even by deep sleepers.

Of course, you can change the parameters (like which zone to turn on and the duration in seconds for the steps in each phase) by editing the script and assigning different values to the variables at the beginning of the script. In the above form it can be downloaded from here.

It uses the milight RGBW command line utility for Linux, which I have presented in a previous article: Home Automation: Using the Raspberry Pi to control the lights in your home over Wi-Fi

To execute the script at predefined times, for example at a given hour on each weekday (working day), you just have to save it somewhere and use cron to call it at the moments of your choice. To do this, log in to your Raspberry Pi and open the cron schedule file:

sudo crontab -e

Add a line like this:

45 5 * * 1-5 /soft/scripts/milight/

In this example the script is saved as /soft/scripts/milight/ and it will be executed once on every day from Monday to Friday (1-5) at 5:45 (AM).

That’s it, you’re done!


Final notes

The solution presented in this article uses a specific type of light bulbs (MiLight RGBW LED bulbs) controlled over Wi-Fi by a specific type of computer (Raspberry Pi or generally a Linux machine). But the idea itself is generic. You could theoretically use other types of dimmable light bulbs and another type of controlling machine, as long as you can get them to communicate with each other. However, your bulbs would most likely have to be dimmable LED bulbs and in order to communicate with a controller that can establish schedules, they would most likely have to be controlled over a computer network (probably through Wi-Fi) and using radio waves, otherwise you’ll end up with a whole bunch of ugly cables. Finally, there probably isn’t a computer which is better suited for this purpose (controlling the light bulbs) than the Raspberry Pi (considering how cheap, small, noiseless and power efficient it is), except maybe some other similar single-board micro computers, devices from the same category, which you may already have lying around at home.

Whatever kind of light bulbs you have and however you choose to control them, try implementing a solution for waking up to increasing light, rather than to a sudden sound alarm. You are very likely to like it and get rid of your old alarm clock forever.


Raspberry Pi rebooting itself when it becomes unreachable from outside networks

RPI Shooting Linux Penguin


If you have a Raspberry Pi in a remote location, far away from where you are, then it’s important to be able to reach the Pi from the distance (from outside networks) all the time. Unfortunately things can go wrong. For example it might happen that the modem or the router to which the remote Pi is attached temporarily looses the Internet connection and sometimes the Pi’s network interface is not able to automatically recover from this problem and reconnect. Or there could be some trouble on the Pi itself which could cause the connection to be lost and not recovered. No matter how well things are set up, it could always happen that the Raspberry Pi goes offline and thus becomes unavailable from the distance. This is a problem, because the only way to get the machine back online is to go to the remote location and reboot it. That means wasted time and possibly also unnecessary fuel consumption (for traveling to the Pi’s location). If the Pi is used in headless mode (no screen, keyboard or mouse attached), then the problem is even more serious because you cannot communicate with the Pi, so the only way to reboot it is to pull the power plug, which is not a healthy thing to do. You should always shut down the OS from software before removing power:

sudo shutdown -h now

Failure to do this may result in damage to the SD card (it happens rarely, but it does happen sometimes).

So if we need our remote Raspberry Pi (or maybe even a local Pi) to recover the lost connection, it must be able to reboot itself whenever the problem of connection loss occurs. In some cases it might be enough to just restart the network interface service instead of rebooting:

sudo service network restart

However, in other cases something else might be stuck, so the safest solution (from the point of view of recovering online availability) is the brute method of the Raspberry Pi rebooting itself (unless of course some software runs on it which should not be restarted if it can be avoided).

The most important questions that need to be answered before we can implement the solution are:

    • How long is the Pi allowed to be offline before it decides to reboot itself?
    • How can the Pi detect that it’s unreachable from an outside network?
    • How can the Pi reboot itself?


Executing tasks periodically and automatically

To execute a task periodically and automatically on the Raspberry Pi (and on Linux in general), you have to add a cron job. cron is the Linux system scheduler, which executes the tasks specified in its list periodically. To edit the list of scheduled cron tasks, open it with the following command:

sudo crontab -e

If you need to add a new scheduled task, add a line to the bottom of the file, in the following form:

Minute Hour DayOfMonth Month DayOfWeek Task

Every line contains 6 words. The first 5 words form a pattern which defines when to run the task and the last word is the path to the task (script, program) to be executed.
The time pattern formed by the first 5 words is quite flexible. You can use wildcards (*) instead of each word, lists of values, intervals of values or single values. A few examples:

    • 0 17 10 3 1 – executes the example script at 17:00 on the 10th of March if it falls on Monday
    • 0 17 * * 1 – executes the example script at 17:00 every Monday
    • 0 17 * * * – executes the example script every day at 17:00
    • 15 * * * * – executes the example script every hour, when the minute equals 15
    • 0,15,30,45 – executes the example script every hour, when the minute equals 0,15,30 or 45
    • 0 17-20 * * * example sh – executes the example script at 17:00, 18:00, 19:00 and 20:00, every day
    • */15 * * * * – executes the example script every 15 minutes
    • * * * * * – executes the example script every minute

As you can see from these examples, the smallest scheduling interval allowed by cron is 1 minute. When you open the cron tab with sudo (sudo crontab -e), you are actually opening the root user‘s cron tab, so the tasks added to the list will be executed as root. For more details about cron, see the related Wikipedia page.


Attempt to guarantee online availability of the Raspberry Pi

The simplest approach to getting around the loss of online availability is scheduling a periodic reboot. This can be done by adding a cron job to the root’s cron tab:

sudo crontab -e

Add the following line to the bottom of the cron file:

0 0 * * * /sbin/shutdown -r

Finally save and close the cron file (in case of nano CTRL+o, CTRL+x)

The above line schedules a system reboot once a day, every day, at midnight (minutes=0, hours=0).

The main problem with this approach is that it just executes a blind reboot periodically, without checking if it’s really needed. In most cases it won’t be needed, the reboot will be unnecessary. It’s not the best of ideas to do this. It might not be a tragedy to execute an unnecessary reboot once a day, but what if the Internet connection is lost soon after the reboot? Can we afford to not have online availability for the next almost 24 hours? Probably not. But that means that we would need to schedule a more frequent reboot, perhaps every 4 hours. The Pi would keep rebooting itself (mostly unnecessarily) quite frequently. So this solution is just not good enough.

A better approach would be for the Pi to check if it can access the outside world and only reboot itself if it cannot. For example it could periodically try to download the main Google search page (, or some other page that is almost for sure available online all the time. In case it could not download the given page, it would reboot itself. Unfortunately this solution isn’t good enough either because what we’re interested in is being able to access the Pi from outside, not the Pi accessing the outside world (the other direction of communication).


A real solution

And so we arrive to the final solution, which is for the Raspberry Pi to periodically check if it has been successfully accessed from outside and reboot itself if it hasn’t been accessed from outside for more than a given period of time. Unfortunately this means that somebody has to access the Pi from time to time, otherwise it will think that it’s unreachable and reboot itself. If the Pi only reboots itself when it detects that it has not been accessed for a fairly long period of time (perhaps 24 hours), then a human user could log onto it every day to prevent the rebooting when it’s accessible. This can work, but it’s a bit inconvenient. It’s a lot better if a second Raspberry Pi, located in an outside network, periodically logs into the first Pi and executes a command which leaves some trace behind to let the first Pi know that it has been accessed from the outside and that it should not reboot itself. Unfortunately for this solution a second Raspberry Pi is needed, but the good thing is that the solution can be implemented both ways, meaning that both Pis can keep each other in check. If the possibility of communication is lost in ether direction, the Pi that becomes inaccessible will see that the other one did not log into it for more than the allowed time frame and it will reboot itself.


The actual implementation

The first thing that we need is a shell script that resides on the Pi which must be accessible from outside. This script will check its own last modification time and reboot the Pi if more time has elapsed since the last modifiation than allowed. Using the modification time of the script to decide whether a reboot is needed or not is convenient because no other file is needed. Below is a shell script to achieve this (also available for download here):

# How many minutes to allow to pass before rebooting the machine?

# How many minutes of warning (broadcast to logged in users) before actual reboot?

# Obtain the time when this script was last touched
t_last_touch=`stat -c %Y $0`

# Calculate the difference in seconds between
# the current time and the time of the last touch
t_diff_sec=$(( $(date +”%s”) – $t_last_touch ))

# Calculate the difference in minutes
t_diff_min=$(( $t_diff_sec / 60 ))

# Display the elpased time
echo “Time elapsed since the last modification of ${0##*/}: $t_diff_min min ($t_diff_sec sec).”

# If more than the given number of minutes have elapsed
# since the last login, then reboot the machine
# Give logged in users 5 minutes to save their stuff
# (5 minutes warning before the actual reboot)
# Touch this script file before reboot to reset the counter
if (( $t_diff_min >= $MAX_MINUTES_SINCE_LAST_TOUCH ))
touch $0

Let’s assume that this script is saved as /soft/scripts/
Make sure that the script’s access rights are set properly, so that the users who need to run it can do so. For example you may allow it’s owner and the users who are in the owner’s group read/write/execute the script and everybody else just read it:

sudo chmod 774 /soft/scripts/

The second thing that we need is a cron job that executes this script periodically. For example the below line executes the script every 15 minutes:

0,15,30,45 * * * * /soft/scripts/

Note that it’s safer to execute it when the system time minute value equals 0, 15, 30 or 45 than to execute it simply every 15 minutes (*/15 for the minute pattern is less safe than 0,15,30,45) because if something goes wrong and the reboot timer is not reset to 0 after a reboot, then you will still have a maximum of 15 minutes to log in and fix the problem. If the cron entry’s minute pattern would be */15 instead, then the script would run again after every reboot, and if the timer were not reset, it would keep rebooting the machine in an infinite loop.

The third thing needed on the Pi for which we are trying to guarantee online availability is resetting the reboot counter to 0 after each reboot, so that after a reboot the checking script does not think that it needs to reboot the Pi again. To achieve this, open the /etc/rc.local script file (which is executed by the operating system automatically after every reboot) and add a line to it which modifies the rebooter script’s last modification time:

open the file: sudo nano /etc/rc.local
add the line: touch /soft/scripts/
save the file: CTRL+o
and exit the editor: CTRL+x

Finally, one last thing is needed: on the second Raspberry Pi (which keeps the first one in check) a periodic task must be scheduled to log into the first Pi and update the modification time of the rebooter script. In other words, we must add a cron job to the second Pi to execute a remote command over SSH on the first Pi, to update the modification time of the script. If the first Pi becomes inaccessible, the second Pi will fail executing this remote command and the modification time of the rebooter script residing on the first Pi will not be updated, which will cause the periodically executed rebooter script to reboot the fist Pi after a while. Log into the second Pi and add the needed line to the crontab:

sudo crontab -e
add the line: */30 * * * * ssh [email protected] ‘touch /soft/scripts/’
save it and close the editor (in case of nano CTRL+o, CTRL+x)

This line will cause the second Pi to log in every 30 minutes as user1 into the first Pi (reachable at the address and update the modification time of the rebooter script.

For this to work, the user from the second Pi must be able to log in without a password, as a trusted user, onto the first Pi as user user1, via SSH. The cron job is executed as root, so both the root user and user1 must be granted passwordless SSH access to the first Pi, when logging in automatically as user1 onto the first Pi. To understand why this is needed, how it works and for a guide to help you set up the passwordless, automatic SSH login, read this article.



In the form presented above the script reboots the Pi on which it exists if more then 4 hours have passed since it was last modified, but it detects this only when it is run by cron. In our example we scheduled the script to run every 15 minutes. This means that the maximum time for which the Pi can be offline (in the worst case) is a little less than 4 hours and 15 minutes. The second Pi tries to update the rebooter script’s modification time every 30 minutes, which gives it about 8 attempts to successfully update it before a reboot. SSH connections may sometime fail, but 8 opportunities should be more than plenty. The good thing about this setup is that if the connection between the two machines fails temporarily (let’s say for 2 hours), but then it recovers, the Pi won’t be rebooted unnecessarily because the second Pi will still have time to update the modification time of the rebooter script. Of course, these values (4 hours, 15 minutes, 30 minutes) can be tailored to you own needs, but keep in mind that if the time allowed by the rebooter script to pass before it reboots the machine is very short, then there might not be enough buffer for temporary SSH connection failures. Also, it’s not very healthy for the Pi to reboot itself very frequently. The second Pi should probably not touch the rebooter script’s modification time very frequently because the Raspberry Pi uses and SD card as long term storage medium and SD cards allow a limited amount of writes along their lifetime, so the number of writes should be minimized when possible. Don’t take this too seriously, though. The number of writes supported by modern SD cards is quite huge.



To test that your setup works, you can manually run the rebooter script from the terminal on the first Pi (which hosts the rebooter script). When not enough time has elapsed for a reboot, it displays the number of seconds/minutes elapsed since the last modification. If everything works well, you should see this counter reset after each 30 minutes (when the other Pi logs in and updates the script’s modification time). You should also see the counter reset after a reboot.


Home Automation: Using the Raspberry Pi to control the lights in your home over Wi-Fi


Raspberry Pi + Wi-Fi Bulb = Automated House


The problem

Ever since I can remember, I have always wanted to control the lights in my home from a central location and in an automated manner, namely from a computer. But there were just too many obstacles which have prevented me from achieving this… until now. The biggest problem was the need for pairs of wires to run from each light to the computer. That meant a lot of wires (which translates to a lot of money, but also to a big, messy block of wire endings at the computer) and it also meant digging/drilling/cutting into the walls to hide the wires from sight.

Problem: Cables and Money

It was the only possible solution because the current had to run from each light to the device that switches them on and off, so there was no way to avoid this big mess. Also, there was another problem. You want to be able to control the lights spontaneously and quickly whenever you need to, which means that the controlling computer has to be up and running all the time, which is a waste of power (and money) and permanent noise in the room where the command center is established, which is usually a room in which you want peace and quiet or maybe even to sleep in. Finally, let’s not forget that in spite of the strong desire to automate my lights, I never wanted to spend a fortune on it. So for many years an elegant and affordable solution has eluded me… until the Christmas of 2013.


Raspberry Pi

Fortunately the technology related to home automation has progressed enormously in the last few years and new pieces of hardware have been developed which provide easy solutions to the above problems. The first important piece of the puzzle has emerged at the beginning of the year 2012, when the Raspberry Pi computer was officially released.

Raspberry Pi

The Raspberry Pi is a small, noiseless computer, which has a very low power consumption (typically 1-2 Watts) and is very lightweight. It takes up little space in the room and most importantly it is cheap (the official price is 25$ for model A and 35$ for model B). In other words it is the perfect choice for a computer to control the lights in your home. Some may argue that it is not very easy to use because it runs Linux (not Windows), but the truth is that Linux is really easy once you get the hang of it and it is very reliable, making it a good choice for home automation projects.


Wireless bulb sockets

The other very important component of this home automation solution is the ability to control the lights in a wireless manner, preferably both from home and from far away. Wireless sockets for light bulbs have appeared on the international market not so long ago. These are bulb sockets (E27, E26, E14, B22, etc.) which you screw into the existing socket and then you install your light bulb into these sockets. They contain radio receivers and you can use a remote to switch the socket on and off, putting your light bulb in an on or off state.

Wireless Socket

The good thing about these sockets is that you can keep your existing light bulbs. The not so good thing is that they will be a bit bulky and ugly unless you have a large lamp to conceal them. Also, I’ve never seen wireless bulb sockets so far which can be controlled with anything but simple radio signal transmitters, meaning that you can only send commands to them from your home. If you want to turn them on and off from far away, you need to reverse engineer their protocol and use a radio transmitter on your Raspberry Pi to send them the same signals that their remote is sending. Time consuming and cumbersome. Unless, of course, there are wireless bulb sockets out there which have an open specification which lets you know what signals to send, but I’ve never seen one until now. Finally, all that these wireless sockets can do is to turn the lights on and off, which is great in itself, but if you have higher aspirations, like dimming the lights or changing their color, then the sockets are not a good enough solution.


Wireless LED bulbs

Luckily there’s another technological development that has progressed rapidly in the last few years: wireless LED bulbs. These are light bulbs which can be controlled through radio signals directly (no special socket required). Most of them support dimming and changing the light color, which is a beautiful thing to do.

Wireless Bulb with Remote

The ones that we’ve seen until now were quite similar to the wireless sockets in the sense that the way you could control them was through a wireless remote. Unfortunately this meant that if you wanted to control them from a central computer (which also gives you the ability to control them from outside your home), you also had no choice but to reverse engineer their protocol and send the appropriate signals from a radio transmitter attached to the computer, which is hard to do. The fact that these bulbs produce light using LEDs is a good thing because they are very energy efficient and last for many years, but until recently it was also their major drawback because they just weren’t bright enough and could be used only for ambient lighting.


Smart Wi-Fi LED bulbs

Three brands of wireless LED bulbs stand out today from the rest: Philips HUE, LifX and MiLight / LimitlessLED / EasyBulb. There are two main characteristics that separate these three from the usual wireless LED bulbs: they are bright enough for comfortable everyday use and they can be controlled over Wi-Fi (not just with a remote that sends radio signals).

Smart Wi-Fi LED bulbs

Unfortunately none of them is perfect, each of them has smaller or bigger weaknesses, but they are good enough to be used in home automation projects. Philips HUE was the first to show itself to the public. Unfortunately, because it was the only such product on the market for some time, it’s price is ridiculously high, so high that I would not buy it unless I had money to throw away. But it is also the one that has the most versatile smart phone app. LifX was the second to emerge. It is bright (over 1000 Lumens) and promises a very versatile and comfortable smart phone app (for Android and iPhone). It’s price is much less compared to HUE, but it’s still high (89$ for a bulb). The biggest problem of LifX, however, is that you have to order it well in advance and wait months until you get your bulb.



And so we arrive to the wireless LED bulb which I prefer to use in my home automation projects. In different parts of the world it has different names: MiLight, LimitlessLED and EasyBulb. Unlike HUE or LifX, this bulb has quite a fair price (somewhere around 25-40$ for a bulb depending on where and when you buy it) and it is available today, not months from now, something that the manufacturers take pride in. It has been developed over the last couple of years and it is still being improved. MiLight is a bit less luminous compared to HUE and LifX, with the most recent RGBW bulb producing 800-850 Lumens at full brightness, but I’ve tested it myself and it is surprisingly bright (in spite of the specs), fit for everyday lighting. Its colors are very nice, saturated and vivid and the brightness can be set in fine steps.

Here is the presentation video for MiLight bulbs, to give you an idea of how it looks and what can be done with it:

The way I encountered MiLight was through the kindness and benevolence of Santa. A very special person, who knows that I’m a big fan of home automation, has whispered to him that some WiFi LED bulbs would make me happy. And they did, when Santa put 3 9W RGBW Milight bulbs, a wireless remote and a V3 wireless bridge under the Christmas tree this year (2013). Actually, I’m more excited about these MiLight bulbs than Santa or myself would have ever imagined because they look so nice and they are surprisingly bright. Also, they are very easy to communicate with, which finally allowed me to turn my dream of automating the lights in my home into reality. Getting such a wonderful present for Christmas came as an overwhelming surprise. After a few days of experimenting and reading about them I realized that, when coupled with a Raspberry Pi, the MiLight system can be turned into an affordable and elegant light automation solution.


MiLight technical details

So let’s take a look at the technical details. The MiLight system consists of 3 main parts:

The MiLight system

The new 9W RGBW wireless LED bulb contains 15 white LED chips and 9 RGB LED chips. While the white ones give a strong and pleasant warm white light that can be used for everyday lighting, the RGB LEDs are perfect for setting the mood in the room. Inside the bulb, which is quite heavy, by the way, there is also a 2.4 GHz radio wave receiver, which is waiting for commands from the wireless remote or from the wireless bridge. Available socket types are E27, E26 (Edison screw), E14 (through adapter) and B22 (bayonet mount). The new 9W RGBW LED bulb is said to last over 50.000 hours (about 25 years of regular usage), consumes about 10W at full brightness and  about 0.3W when turned off (but listening to commands), making it a good long term money saver. Of course, it can also be turned off from the regular wall switch, in which case it does not consume any power but it also won’t respond to wireless commands. It has a very pleasant warm white tone and also 255 distinct other color shades. A “party mode” is also available, in which the bulb will automatically cycle through the colors. I personally find the 9W RGBW lights to be the best, but MiLight also has simple 6W white and RGB bulbs for sale.

The wireless remote or the wireless bridge are needed to control the bulbs. One of them is sufficient, but it’s more comfortable if you have both. The wireless remote is the simpler, conventional way of sending radio signals to the bulbs, but it’s also the quickest one because you can simply pick up the remote and press it’s buttons. The Wi-Fi bridge is needed if you wish to control the bulbs from a smart phone, from a computer or from some  other Wi-Fi enabled device. It also provides the ability to play with the lights from far away (from outside home). The Android and iPhone apps are available as free downloads. They aren’t extremely optimized for user comfort, but still they are relatively fun to use and cover all the basic functions (on/off, brightness, colors, disco mode, etc.). Both the wireless remote and the smart phone apps (which by the way don’t seem to be available for (some) tablets) can command a maximum of 4 bulb groups (zones). Each group can contain hundreds of bulbs and all groups can be controlled by several remotes or wireless bridges. But if you need more than 4 zones in your home, then you’ll have to get more than one remote or wireless bridge.


Why MiLight?

So why would we use exactly MiLight with the Raspberry Pi to automate the lighting in our home? Well, first there are the obvious reasons: it’s affordable, bright enough, the colors look great, lasts very long and it’s energy efficient. Also, it can be controlled over Wi-Fi from home and from far away. But there is one very important thing that makes the MiLight wireless bridge very suitable to use in more advanced home automation projects: it is very easy to communicate with and it has an open API, in the sense that the commands which it uses to control the bulbs are publicly available on the LimitlessLED website’s developer section. This is why it’s easy to send commands from a Raspberry Pi to the wireless bridge and control the bulbs through it. The Pi simply has to send the known UDP command messages to the bridge, which will translate them into radio signals understood by the bulbs. No need to guess or reverse engineer the protocol, it’s all documented. No need to transmit radio signals from the Pi directly, the wireless bridge does that for us if we send messages to it through UDP.



Raspberry Pi, MiLight wireless bulb and MiLight wireless bridge

Our lighting automation system will consist of the following components:

This means that the cost of the system starts from a minimum of around 140-150$, depending on where you manage to get the components from and what you use exactly, but also on how many and what kind of LED bulbs you attach to the system.


How it works

After getting the Raspberry Pi up and running (there are many guides out there about how to do this, but it is very simple, works mostly out of the box), you can log into it either directly (if you attach a monitor and a keyboard to it) or via SSH if you use it in headless mode. The great thing about connecting to it via SSH is that you can do it locally, in your home network, but also from outside networks, through any SSH client. On Windows machines I use the putty SSH client and on Android devices I use Juice SSH, both of them being simple and working great. To communicate with the MiLight wireless bridge, we will need to run some software on the Raspberry Pi which sends UDP messages to the it. I have created such a simple command line Linux program, simply called the “MiLight/LimitlessLED/EasyBulb RGBW v3.0/v4.0 Command Line Utility”.

The binaries can be downloaded from here.


The C++ source files are also available for download here, in case you wish to tweak them.


Yes, it’s all completely free!


The MiLight/LimitlessLED/EasyBulb RGBW v3.0/v4.0 Command Line Utility

MiLight Linux command line utility

This lightweight command line Linux program can be used to send commands to the MiLight RGBW light bulbs, one at a time, through the MiLight wireless bridge v3.0/v4.0  (not compatible with earlier versions of the bridge). The program consists of two files:

    • milight – the executable
    • milight.conf – the configuration file

The configuration file simply contains three lines of text. The first line is the address (IP) of your MiLight bridge in your local area network. It is assigned through DHCP by default but it can be set to a fixed local IP address. You can find and set this IP address using your router’s configuration page. By default it is assumed to be, but it is likely that your router will assign a different IP address to the MiLight bridge. The second line is the port number on which the communication occurs with the MiLight wireless bridge. By default it is 8899, but it can be changed through the MiLight bridge‘s configuration page (at by default). The third line can be used to output the command that was sent to the wireless bridge. When the third line contains the text “VERBOSE”, the utility will write the sent command, the destination IP address and the destination port number to the standard output.

If you ever forget the arguments with which you can call the milight command line utility, just call it without any parameters and it will tell you how to use it:


The optional ZONE argument specifies which bulb zone the command refers to. If this argument is omitted, the command is considered to refer to all zones. Possible values:
ALL/0 – All zones
1 – Zone 1
2 – Zone 2
3 – Zone 3
4 – Zone 4

The COMMAND argument specifies the command to be sent to the given bulb zone. Some commands require a parameter (see below). Accepted commands:
ON – Turn the bulbs in the given zone on.
OFF – Turn the bulbs in the given zone off.
WHITE/W – Set the color of the bulbs in the given zone to white.
DISCO/D [+/-] – If no parameter is specified, turn disco mode on. The ‘+‘ optional parameter increases the disco speed. The ‘‘ optional parameter decreases the disco speed.
BRIGHTNESS/B VALUE – Set the brightness of the bulbs in the given zone.
The VALUE mandatory parameter specifies the brightness and must be an integer number in the range 1-19.
COLOR/C VALUE – Set the color of the bulbs in the given zone. The VALUE mandatory parameter specifies the color and must be an integer number in the range 0-255.

For example, if you wish to turn on all lights, call:

./milight on

If you wish to turn off all the lights, call:

./milight off

If you wish to set the brightness of the lights in zone 2 to minimum, call:

./milight 2 b 1

If you wish to set the color of the lights in zone 2 to some kind of blue, call:

./milight 2 c 5


Why combine MiLight with Raspberry Pi?

You might be wondering why it is a good idea to use a Raspberry Pi to control your MiLight bulbs when it’s quite easy and fun to use them even without a Raspberry Pi, and they can be controlled in a wireless manner anyway, from home or from away, using the wireless remote or a smart phone. Well, the command line utility presented above is very basic and might not impress much at first sight, but once you get it working, it opens a world of endless possibilities. To mention just a few:

    • It can be used to transmit various predefined sequences of commands to the bulbs.
    • It can be called from a fancy web page which will allow you to control your lights over the web (you’ll need a web server on the Pi for this, perhaps Apache or Tomcat? See this article if you need a basic guide).
    • It can be used to turn lights on or off based on a schedule (at given hours of the day).
    • It can send commands to the LED bulbs in response to events triggered by sensors (such as motion, temperature, etc).
    • You can call the command line utility when you receive an e-mail and blink your lights to notify you.
    • You can turn the lights on automatically when somebody enters the room or when the sun goes down.
    • You can attach a microphone to the Raspberry Pi and issue voice commands to control your lights in the most comfortable way ever.

The possibilities are endless. With a little bit of knowledge and imagination, you can have the most modern lighting system that exists today, with MiLight LED bulbs controlled by a Raspberry Pi. Have fun 🙂


Final word

I realize that this article sounds a bit like advertisement for the Raspberry Pi and for the MiLight LED bulbs. Even though this was not my original intention, I don’t mind that it turned out this way… they both are great devices which help us live a more interesting life. I like to believe that both were created with innovation in mind and the purpose was much more than just to sell a product. I like to believe that both were invented to help us unleash our own creativity and to create more advanced devices. Both of them have reasonable prices and appeal to the mind of the technology oriented people. So, yes, I do like them very much and I like to advertise them, even though there’s nothing in it for me, except the thought that through my article other people will get to know and enjoy these technological wonders, just like I do 🙂 .

Special thanks to NailGlaze for making me acquainted with MiLight and for the most wonderful Christmas present I could ever imagine!