UPDATED Amazon Echo X10 Home Control

In my original post last August I detailed how I was able to control my X10 equipment with an Amazon Echo.  Now with the release of BWS Systems’ ha-bridge version 2.0.0+ we can make script calls! This is awesome news, I no longer need an Apache server and PHP installed on my RPi to make the exec() commands to call the HEYU scripts, I can make them from the ha-bridge. I’ll show you how.

It should be noted that you will need a physical Amazon Echo, Dot, Tap or Google Home to discover your ha-bridge devices. Discovering devices with just a Fire TV or Fire Stick with voice remote will not be successful. However, after discovery by an Echo or Dot, you will be able to use the Fire TV with voice remote to control your discovered devices.


If you use the ha-bridge, I urge you to Donate to BWS Systems (Donate link at bottom), the ha-bridge is distributed freely and continuously updated.


Step 1 – Raspberry Pi goodness?

RPiThe first step is to get your Raspberry Pi up and running. There are plenty of guides how to download and install either NOOBS, or RASPBIAN on a memory card for your RPi, so I won’t go into those details unnecessarily. Suffice it to say, you’ll need to have your RPi booted into Raspbian and configured to your location and language, including SSH enabled.

Once you have the RPi working you can SSH (remote) into it and log in as the user Pi. For PC you can use PUTTY, or MAC use the Terminal Window to SSH into the Pi. At this point I would also recommend you update and upgrade your RPi, by entering the following:

  • $ sudo apt-get update
  • $ sudo apt-get upgrade

I also recommend changing the default password.

Once updated and upgraded, power down your RPi, and make all the following connections:

  • Install batteries into the CM11A
  • Plug the control cable into the CM11A jack
  • Connect the Serial Adapter to the X10 CM11A’s serial cable
  • Plug the CM11A into a wall socket
  • Plug the USB to Serial Adapter into the RPi

In my original post I detail the parts I used, but I recommend USB TO RS-232 DB9 Serial Adapter = $15 Plugable brand – don’t go cheap here.

Power your RPi back on, and SSH back into it.

Step 2 – Heyu turn on my lights!

Let’s install heyu, which is a text-based console program for remotely controlling lights and appliances in the home or office. I put heyu in a directory I created named ‘src’.

Here are the steps I completed:

  • $ ls -l /dev/ttyUSB0
  • You should get something like the following:
    crw-rw---T 1 root dialout 188, 0 Aug 10 20:44 /dev/ttyUSB0
    Make note* of the last part, you’ll need it later.
  • $ mkdir src
  • $ cd src/
  • $ wget https://github.com/HeyuX10Automation/heyu/archive/v2.11-rc2.tar.gz
    (Or current version)
  • $ tar xfvz v2.11-rc2.tar.gz
  • $ cd heyu-2.11-rc2/
  • $ sh ./Configure.sh

The installer will run, make a cup of coffee.

  • $ make

More installation, drink the coffee you made.

  • $ sudo make install

You should then see the following:

I did not find a Heyu configuration file.
Where would you like the sample Heyu configuration file installed?
1. In directory /home/pi/.heyu/
2. In subdirectory .heyu/ under a different user home directory
3. In directory /etc/heyu (for system-wide access)
4. No thanks, I'll take care of it myself
Choice [1, 2, 3, 4] ?

Enter 3 for system wide access, and you’ll see:

Creating directory /etc/heyu
The sample configuration file will be installed as /etc/heyu/x10config

The next question the program will ask is the following:

I will add the TTY port for your CM11 to the config file
Specify /dev/ttyS0, /dev/ttyS1, etc., or the word dummy
To which port is the CM11 attached?

Enter /dev/ttyUSB0 (or whatever you noted* earlier).

Next we need to make the /etc/heyu directory writable:

  • $ sudo chmod -R 777 /etc/heyu

Now you can test the install, enter $ heyu info, and you should get an output with details about the heyu install that look similar to the following:

Heyu version 2.11-rc1
Configuration at /etc/heyu/x10config
Powerline interface on /dev/ttyUSB0
Firmware revision Level = 1
Interface battery usage = 0:00 (hh:mm)
Raw interface clock: Sat, Day 212, 14:07:35
(--> Civil Time: Sat 01 Aug 2015 15:07:35 EDT)
Uploaded schedule will expire in 154 days.
Housecode = M
0 = off, 1 = on, unit 16.......8...4..1
Last addressed device = 0x0002 (0000000000010000)
Status of monitored devices = 0x0042 (0000000000010001)
Status of dimmed devices = 0x1112 (1110000000010000)

Now let’s test to see that you can turn a light on and off. My housecode is M, but use your chosen housecode. Try the following: $ heyu on M2 and the module set to M2 should turn on, alternatively $ heyu off M2 and the module set to M2 should turn off.

You can configure your setup and upload schedules to your CM11A.

Step 3 – Hue talking to me?

X10 does not ‘interface’ with any technology that the Amazon Echo can control.  Crush from BWS Systems forked and created the ha-bridge.  It is a Phillips Hue emulator that runs as a java file (.jar) so it can be run on virtually any device.  The Amazon Echo will discover the emulator as a Phillips Hue bridge, and discover the configured devices.  When asked, the Echo will call the configured ON,OFF or DIM URL for each discovered device, this can now be script calls brilliant!  I can make the HEYU calls directly from the bridge.

The following steps download and get the bridge to run on the RPi:

Navigate to your root directory:

  • $ cd

Make a new directory named habridge:

  • $ mkdir habridge

Then navigate to the habridge directory:

  • $ cd habridge

Now download the latest JAR into the directory, you can get the latest here:

  • $ wget https://github.com/bwssytems/ha-bridge/releases/download/v5.1.0/ha-bridge-5.1.0.jar

Then rename the jar file to something ‘generic’ so we don’t have to keep changing the auto-start script when we download a new version:

  • $ mv ha-bridge-5.1.0.jar ha-bridge.jar

Now we want the ha-bridge to auto-run after reboot on your RPi, you will need to get it added into a startup script. Let’s do that now, enter the following command:

  • $ nano starthabridge.sh

Add the following to this file:
cd /home/pi/habridge
rm /home/pi/habridge/habridge-log.txt
nohup java -jar /home/pi/habridge/ha-bridge.jar > /home/pi/habridge/habridge-log.txt 2>&1 &
chmod 777 /home/pi/habridge/habridge-log.txt

Press CTRL + X, select to save the file. Then execute the following commands:

  • $ chmod u+x starthabridge.sh
  • $ sudo passwd root

Enter your RPi password (it asks twice). Next we’ll change to superuser to finish our install and autostart:

  • $ su -

It will ask you for the root password that you just created in the previous step. Enter it.
Your terminal will now switch to root@raspberrypi, enter the following commands:

  • # sudo su
  • # touch /etc/systemd/system/habridge.service
  • # chmod 664 /etc/systemd/system/habridge.service
  • # cd /etc/systemd/system/
  • # nano habridge.service

Add the following to this new file:
Description=HA Bridge
ExecStart=/usr/bin/java -jar -Dconfig.file=/home/pi/habridge/data/habridge.config /home/pi/habridge/ha-bridge.jar

Press CTRL + X, select to save the file. Then execute the following commands:

  • # systemctl daemon-reload
  • # systemctl start habridge.service
  • # systemctl enable habridge

The service should have now started and will start every time you plug in or reboot your RPi. If you want to check the status of the service type:

  • # systemctl status habridge.service -l

To return to normal user and leave superuser, enter the following command:

  • # cd
  • # exit

Once you’ve got the bridge running, add discoverable devices. The bridge comes with a configurator to make adding and editing devices a snap. As of release 3.2.0, the default HTTP port for the bridge is 80, to navigate to it I enter my RPi’s IP address in a modern browser (like Chrome, not MS EDGE):


Note: Now that the default HTTP port is 80, the “:80” portion is NOT required, this is the default HTTP port. Prior releases 3.1.0 and older use the default HTTP port of 8080.


The bridge supports dim commands from the Echo. The bridge returns three variable options, they are: ${intensity.percent} (for 1-100), ${intensity.byte} (for 0-255) or ${intensity.math} (for 0-255). By saying, “Alexa, dim the kitchen lights to 50%” that percentage will be passed in the ‘Dim URL’.  I’ve chosen to use ${intensity.math}, with X10 the dimming gets a bit tricky since X10 dim/bright is from 1 to 22. The ${intensity.math} allows me to manipulate the returned variable to fit my X10 needs, namely using ${intensity.math(((X*-22)/255)+22)} will get me the correct output.

Enter the Name of your new device, the On URL and the Off URL, and click Add Device. For my example device of M2, I would enter the following:

  • Name: kitchen
  • Device Type (Informational): Execute Script/Program
  • Map Type (Legacy): Execute Command/Script/Program
  • On Items:
    • Type: Execute Command/Script/Program
    • Target Item: heyu on M2

    Click the green “Add” button to the right.

  • Dim Items:
    • Type: Execute Command/Script/Program
    • Target Item: heyu dimb M2 ${intensity.math(((X*-22)/255)+22)}

    Click the green “Add” button to the right.
    (See Notes below…)

  • Off Items:
    • Type: Execute Command/Script/Program
    • Target Item: heyu off M2

    Click the green “Add” button to the right.

Click the ‘Add Bridge Device’ button. That’s it, you configured your first device.  Add all your devices.

Note 1: I chose to use dimb, this turns the X10 module on first then dims to the requested level. The dimb command more closely follows how Philips HUE dim commands will work with Alexa, since successive X10 dim commands will progressively dim the module to maximum dim level. Philips HUE devices will go dim or bridge to the reach the requested dim level rather than successively getting dimmer, hence the usage of the dimb command in my example.
Note 2: If using the X10 wall switch WS467 I suggest using obdim because these switches have a last dim level memory.

Step 4 – Alexa take control!

alexaOnce you have a device(s) configured, it’s time to tell your Amazon Echo to discover your devices.  Simply say, “Alexa, discover my devices”, she will go into discovery mode (approx. 20 second), and find the devices you’ve configured above.  Of note, you can manage the devices the Echo has discovered by visiting: http://echo.amazon.com going to ‘Settings’ -> ‘Smart Home’, or directly at http://echo.amazon.com/#smart-home.  This can be helpful if you remove or rename a device on your Hue Bridge Emulator.

Once discovered, the fun can begin, ask Alexa to turn your lights on and off!  For me house code M2 is my kitchen.  So I can say, “Alexa, turn on the kitchen”, and viola they turn on.

Step 5 – Easy ha-bridge version updates?

So, how do you update the ha-bridge jar file when a new release comes out? I’ll show you, replace the {version} text below with the version you wish to download.
Navigate to the ha-bridge folder:
$ cd habridge
Halt the ha-bridge systemctl service:
$ sudo systemctl stop habridge
Download the latest ha-bridge from github:
$ wget https://github.com/bwssytems/ha-bridge/releases/download/{version}/ha-bridge-{version}.jar
Rename the current ha-bridge file for reference:
$ mv ha-bridge.jar ha-bridge_LAST.jar
Rename the one you downloaded to the generic “ha-bridge.jar”:
$ mv ha-bridge-{version}.jar ha-bridge.jar
Restart the ha-bridge systemctl service:
$ sudo systemctl start habridge


Below I’ll compile information discovered along the way.

  • If you already have a real Phillips Hue bridge, you have to disconnect it first before searching for devices. – (Thanks Mitch)
  • If most of your X10 stuff is setup to run off radio, you can install a CM17A inline with the CM11a. – (Thanks Mitch)
  • The X10 “All lights on” command is: heyu lightson – (Thanks Mitch)
  • If your RPi is on WiFi, you’ll need to have Alexa and the Pi on the same wifi SID. This was essential. These days almost everyone uses WPA2 with AES so you need to reconfigure raspbian a bit ( https://coderwall.com/p/v290ta/raspberry-pi-wifi-setup-with-wpa2-psk-aes ). – (Thanks Elmer)
  • Java 8 is required for the ha-bridge to run. To check your Java version type $ java -version if it is not JAVA 8, then enter the following command $ sudo apt-get install oracle-java8-jdk. If you are getting “Unsupported major.minor version” error messages, then enter $ sudo update-alternatives --config javac and $ sudo update-alternatives --config java. This will set your RPi to use Java 8 globally. – (Thanks Max)
  • To control multiple modules (m1, m3, m4, m8, m10 & m16 for example) with one command, create the On and Off URLs just like any other module On/Off, but use this format for the house unit portion of the URL: heyu on m1,3,4,9,10,16. This will act on each device from one command. Also if you have units in succession, like m3, m4, m5 & m6 it can be expressed as m3-6. – (Thanks Frank)
  • Using the Raspberry Pi with a Firecracker CM17A is possible. HEYU is Firecracker compatible, you need to use the HEYU Firecracker “f” command construct. The ‘turn’ command also supports the CM17A commands fon, foff, fdim, fbright, flightson, flightsoff, falloff, and the applicable “fast” implementations of these commands. William reports, “I installed between the cm11 and the usb/serial interface, plugged in a receiver module tuned to appropriate house code and transmits a much stronger signal over the powerline. I had to change the scripts in the HA Bridge from “heyu on A1” to “heyu fon A1” or off to foff to activate the firecracker and viola it works.” (Thanks William)

I wrote a complimentary Bridge Control interface coded in PHP, that post is here.  It allows you to control all your configured ha-bridge devices on any PC, tablet or phone connected to your home’s internet.

713 thoughts on “UPDATED Amazon Echo X10 Home Control

  1. Hi Corey thank you so much I have 0 experience with Linux being a dos man, the only problems I experienced were of my own making (typo’s etc) I have been using x10 devices for the past 30+ years for Christmas lights etc but will now get much more use out of them

  2. Corey – I know your posts have been up for a while, and many people have already praised you more eloquently than I can, but I had to add my own praise. I am very much indebted to you for your superb tutorial! I have been a home automation enthusiast since the early 1980s (yes! with some of my X10 equipment dating to the late 70s!). I have almost 100 X10 devices installed in my home so the cost of replacing it all with new technology was prohibitive. I did buy a few WeMo switches and enjoyed the integration with Alexa, so I searched until I found your articles on how to “Alexafy” X10. After numerous repairs to my decaying switches (the house/unit code internal metal fingers separate from the plastic dials over time), and with your Raspberry Pi interface, I now have a house that is (almost) equivalent to a new technology system, at very little additional cost. So this is a LONG way to say THANK YOU VERY MUCH. I appreciate your work and your detailed instructions. I’m an electrical/computer engineer but I followed your instructions to the letter and the system worked the FIRST TIME I booted it. Wow, I couldn’t be happier!

    1. Sam,

      I was in the same boat in July/August of 2015. I too am a long time X10 fan, bought an Echo and wanted to control my X10 with it. I searched the web with no great results. There were “to-do” list control options, but that was sloppy. I wanted native control. I originally found the amazon-echo-ha-bridge built by armzilla on Github that worked. It natively spoofed as a Philips HUE bridge. BWS Systems forked it making it lighter and feature packed. He and I have collaborated on it ever since, meaning, I ask for enhancements and he graciously supports them! LOL!!! Anyway, I wrote my tutorial because I wanted X10 fans, like yourself, to be able to control their gear with an Echo too.

      I have also written a Python script that updates the state of my X10 equipment in the ha-bridge, since I control my X10 with remotes, and schedules. This way they are in sync. I run this script on a cron job every 15 mins. I’ll post that soon.

  3. Corey,
    I wanted to install this process on another SD card and as I went through the process I believe I stumbled on an error in your updated instructions. This statement returns an error when executed “tar xfvz heyu-v2.11-rc2.tar.gz” as the name is not found. This modified statement “tar xfvz v2.11-rc2.tar.gz” worked fine and I was able to successfully complete the procedure on my second SD card.

  4. For all those with LD11 modules – which have the extended X10 functions – the dim command can be replaced with:

    heyu xpreset E1 ${intensity.math(62-(((X*-62)/255)+62))}

    Where the ‘E1’ is whatever house/unit code you have. I have added the extra (62-(…. bit at the front, otherwise they work backwards – “set to 20%” gives 80% brightness and vice-versa. I’ve used 62 instead of 63, otherwise a “set to full” will mean an instant change to full brightness – not cool.

    Hope that helps someone.

    1. Andy,

      Thanks for sharing! I’ll add this info to the Notes at the end of the post.

    2. Hi Andy,
      Yes, that’s very helpful because I have several unit that use extended codes and Corey’s “dim” syntax was not working. Only problem I have is that Alexa will correctly set the level on one light in a room, but will not change the level on another light in the same room! Any ideas why that might be?

        1. The X-10 signal is getting to the one unit that does not recognize “Dim”, because from the HA Bridge (running on a Chrome browser), I can command the light on and off with no problem. It is only the “Dim” command, and only that one light. All other lights, including others in the same room as the culprit light, respond to “On”, “Off” and “Dim” with no problems, both from the Bridge and through Alexa. So that leads me to believe it’s something other than the X-10 signal.

          1. OK, I am figuring this out. The lights that won’t respond to Andy’s command above are on Insteon switches. They will work if I use Corey’s “obdim” command, but it’s not pleasant that they blast on to full brightness and then dim to the desired percentage. Why won’t the “dim” command work (it doesn’t)? How can I get around having them come on first to full bright and then dim?

            1. You can just use “dim”. I use obdim to more closely mimic the dimming memory level of a HUE bridge AND I also have WS467 wall switches that have dim memory. If I send successive dim commands to an X10 module from the ha-brige it will progressively get dimmer, where the ha-bridge sends out and keeps track of the dim percent last sent (like a real HUE) which is not necessarily the percent at which my X10 modules will be actually dimmed to.

              You should also understand that I recommended you read my other post because the lack of response to extended dim as you described is a symptom of signal clashing, especailly if you use the X10 XPCR coupler repeater. This was in the “The XPCR does other things poorly” list, items 2 and 3 “Creates signal clashing when repeating extended X10 signals” and “Signal delays and bright/dim issues”. I was not indicating that you had a lack of signal.

            2. Thanks, Corey, I did go back and read your entire post and I will get a Boosterlinc and a better phase coupler. Would the fact that the only 3 switches that will not respond to “Dim” (but DO respond to “Obdim”) are Insteon be the key, or some other reason? “Dim simply will not work with those 3 switches.

            3. There can be many reasons the three Insteon modules/switches don’t respond to dim, but do respond to obdim. How did you format your dim command? The dim command is as follows: heyu A1 dim ${intensity.math(((X*-22)/255)+22)}. They may each be on the same phase (leg) of your home’s electrical service which may have a noisy device or signal sucker plugged in on that phase. The signal on that phase (leg) of your home’s electrical service may be the bridged phase and the signal is not reaching that phase as well. The obdim command is different from the simple dim command, and the Insteon devices may respond (listen) better after the on then full bright commands that make up the first two of the three parts of the obdim command.

            4. I had the “Dim” commands formatted exactly as you indicated. Relative to phase coupling, when I installed my automation controller (HAI Omni Le), sensors and switches, I also installed a Leviton HCA02 coupler-repeater. That’s been in service for probably 15 years and the indicator lights show that it is still functioning properly. Is the Signallinc 2406H significantly better?

              In a list of Heyu direct commands, I saw a notation that some switches simply will not respond to “Dim” unless the unit is first turned on “full” by the “OB” part of “OBDim”. Perhaps that is the problem?

          2. So just create two entries for your Dim Items. The first would be and ON, and the second DIM.

            1. That does allow the “Dim” to work, but it still turns the light on full before dimming. However, it gets to the requested dim level quicker than using “obdim”, which is a plus. I guess there is no way to get around having the light come on at full-brightness before dimming.

            2. Thanks, Andy, you are correct that the Insteon switches don’t seem to support the xpreset command. I have tried several of the other heyu direct commands, but nothing seems to allow the dim function from the “off” state, except “waking up” the switch with an “on” command. As I mentioned, the disadvantage of that is the light coming on first to full brightness before dimming to the desired level. Wish there were some way around that but I have not been able to figure it out at this point.

            3. Have you tried two DIM commands? Maybe the device just needs to “wake up”?

            4. It may have just come to me!!! Try the reverse…OFF then BRIGHT! Let me know.

            5. Also, the math will need to be reversed for BRIGHT.

            6. Ok, I tried it on my X10 devices and no beans, let me know if you have any success. Also you could try an OFF then DIM too.

            7. OK, making progress. “Off/Dim” did not work, nor did “Dim/Dim”, but “Off/Bright” seems to do the job. As you mentioned, Corey, the logic seems to be backward, because if I say “Brighten to 70%”, the light comes on at 30%. Since you have more experience manipulating the formula, perhaps you can suggest the modification necessary to make that work more logically 🙂
              Thanks again for helping so much with this!

            8. So the reverse math would be ${intensity.math(((X*22)/255)-22)}. This results in a bright value up from 1 rather than a dim value down from 22.

            9. OK, so now here is what is happening, (and this is all done by going through “Alexa”). Using the “Off” command joined with the “Bright” command as one “Dim Item” in the HA Bridge, if I use your revised formula, the light does not turn on at all from the “Off” state. If I tell Alexa to turn it on first, and then say “Dim” (no matter what level) the light turns completely off.

              If I use the combined “Off” / “Bright” sequence in the Bridge “Dim” Item, and your original formula, “Brighten to 30%” or “Brighten 30%” gives 70% brightness, and “Dim to 70%” or “Dim 70%” gives 30% brightness. And it seems as if Alexa sometimes responds to “Dim”, but not always. I can live with this and just “think backwards” when asking Alexa to “Brighten”…the more I tell her to brighten, the dimmer the light will be! But I can’t figure out why your revised formula has the effect it does…turning off the light completely no matter what level I specify.

            10. Ok, so I checked my ‘reversed’ formula, I got it wrong! It should be ${intensity.math(22-((X*22)/255))}, sorry about my error.

            11. BTW, my first ‘reversed’ formula was returning a negative number, this is why the device would always go off.

            12. Corey, replying to your May 9 entry, yes, now that I have entered your revised formula, Alexa seems to understand. Even though we are using “Brighten” as the syntax, she understands it as a “Dim” command. If I were to say “Alexa, brighten the living room lights 70%”, she will set them at 30% because she understands the command to be “Dim by 70%”. So I just have to remember that even though we wrote the “Dim” syntax as “Brighten”, I have to tell her to “Dim” and then it all makes sense.
              And thanks very much for all of your help!

  5. So, in order to allow Alexa to turn x-10 lamp/appliance modules on/off do you really need something to translate the commands into RF which then get pushed to a transceiver, which then get pushed to modules on the power line? I’m looking to use a Raspberry Pi and ha-bridge to bridge the gap from Alexa to X-10 modules. Does the CM119a (along with the proper software on the Raspberry Pi) push the on/off commands down the power line to the x-10 lamp/appliance modules? Or do I need something else?

    1. Where did you get the RF -> Transceiver -> module -> powerline chain of events from in the post? My post directs using a CM11a plugin wall controller hard wired to the RPi – period.

      1. Sorry, I’ve been reading a lot of posts on this topic. Got them confused with your solution.

        1. So, maybe a more generic question. Will using one of these devices (cm11a, etc.) hard wired to the RPi allow me to trigger my X-10 modules on/off using the proper software? I’m just trying to gather the list of hardware items I need.

          I was worried I also needed a RF transceiver as well as the cm11a. I had found references to the cm19a in other posts. With that, I’d probably need the RF transceiver. So, it sounds like if I used the cm11a, that would allow me to translate the Alexa commands to x-10 via that device. Similarly, it sounds like you could use the cm19a but that pushes the commands via RF, hence the requirement for something to move those commands to the powerline.

          1. I use a Firecracker CM17a inline with my serial to USB adapter for the CM11a to allow both RF and Powerline commands from the same RPi.

  6. Ok. Thanks Corey. I was hoping to get away from the serial interface. I don’t have any RF X-10 needs. I have a pile of X-10 modules/switches controlled by a timer/controller. I’m a RPi newbie, looking to assemble the right, minimak number of components to do this. I literally want to be able to go from Alexa (Echo) to RPi, running the HA-Bridge, down the powerline to my X-10 modules/switches. I don’t have any dimming requrements — just want simple on/off. I just ordered a RPi 3 kit to start this process.

    1. So, it sounds like I can do something similar. Get a serial to USB adapter to do the translation, etc. I just want to keep the hops (which equate to potential points of failure) to a minimum.

      1. Hi Corey,

        Finally got all of my components ordered and delivered, followed your instructions and it works like a charm! Thanks for sharing the information. Got it running on a RPi 3 initially. Going to try to get it running on a RPi Zero next. Will likely build one of these for my father as well, but he has the requirement to do RF devices, which this will support as well with a CM17A. Again, thanks for sharing. Nice to be able to still use all of this old X-10 stuff and not have to replace all of the modules I have.

        1. Awesome, glad you got it working.

          I’d use an RPI Zero W, it has wifi 802.11 b/g/n built in, no need to get from micro USB to wifi adapter. Plus this leaves the micro USB for the CM17A, no need for a USB shield or hub.

          1. I got the RPi Zero W all set as well. Works like a charm! Thanks for posting this solution!

          2. Cool, you are the first person I know with the ha-bridge on a Zero W, enjoy!

        2. One last quick question. Do you ever find that you have to periodically reboot the RPi on a regular basis? I guess what I am asking is that should I schedule a reboot chron job or something periodically?

  7. Corey. Great Job. I follow your instructions and Alexa Works great. Thank you very much. I was looking in the internet and found that Alexa could control the TV using a raspberry and Habridge devices. Could it be posible to have both of them working on the same raspberry unit? I don’t want to bother you or abuse of your generosity sharing your knownledge, but it is posible to have the same instructions for Alexa to control a TV?
    Best Regards,

    1. Diego,

      I control my TV with a Harmony Hub, which now has native Alexa skills. I also use the Harmony Helper built into the ha-bridge to add entertainment system controls not available in the native Alexa skills. So it is possible to use one Raspberry Pi for both.

          1. The Harmony Hub is great, easy to setup and it controls all my entertainment devices. Between it and the Heyu X10 bridge, I pretty much have all the home automation I need.

  8. HI Corey,

    I have your original version of this bridge working on a Raspberry Pi 2 and now wanted to get the new and improved version working on a new Raspberry Pi 3. I am good to go all the way to getting Heyu to talk and it can command X10 modules from the Pi command line.
    The challenge I am having is getting the HA-Bridge to run. When attempting to start it will crash and exit with a code 100. Reloaded it and tried 2 revisions (4.1.4 and 4.2.1) with the same results.
    The actual response is: habridge.service: main process existed, code=exited, status=100/n/a
    Unit habridge.service entered failed state.
    I have tried re-entering each step and verifying the configuration files but no joy.
    Any suggestions?

    1. What version of Raspbian are you running of the RPi 3? The ha-bridge does not work with the LITE version of PIXEL. Have you completed the $ sudo apt-get update and $ sudo apt-get upgrade?

      1. I did that step first but to be sure I did it again and get the same result that the habridge crashes. I am running Debian 8.0 but not sure why the bridge will not boot. I am trying v4.2.1 which shows to be the latest. Not sure what to try next as the heyu works. I must be missing something.

        1. Let’s check to make sure you have the correct version of java. Enter $ java -version and tell me what is returned.

          1. java version “1.8.0_65”
            Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
            Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)

          2. Well progress. I got the bridge running but now am having trouble adding my first device… I have a device added and Alexa sees it but it gives an error when trying to test it on the bridge and Alexa cannot command it.
            It doesn’t seem to be saving my heyu on m12 command. I have played with the legacy settings but there are a few choices that I am not sure about.
            On the bridge device edit screen there are on dim and off that have several choices and do not save whatever it put in there. So based on the selection of legacy map type I am working to put the heyu commands in there. It saves the command there but doesn’t work and I get an error when testing the device. Is there a detailed screenshot of an X10 device setup? I am not sure of the HTTP header, verb or content type and have tried several variations with no luck.

            The device setup fields are below with some of the choices that I am looking for under the legacy section.

            HTTP Headers format like: [{“name”:”A name”,”value”:”a value”}]
            Http Verb —Please select— GET PUT POST
            Content Type —Please select— application/atom+xml application/x-www-form-urlencoded application/json application/octet-stream application/svg+xml application/xhtml+xml application/xml * multipart/form-data text/html text/plain text/xml */*
            Content Body On heyu on m12
            Content Body Dim Content Body Dim for specific GET/PUT/POST type
            Content Body Off

          3. That is the correct java, glad you got it to start.

            Let’s change where your devices are being saved. On the Bridge Control page, in the Device DB Path and File input, enter:


            , then click Save.

            Now to enter a new heyu device on the Add/Edit Page, enter the following:

            • Name: kitchen
            • Device Type (Informational): Execute Script/Program
            • Map Type (Legacy): Execute Command/Script/Program
            • On Items:
              • Type: Execute Command/Script/Program
              • Target Item: heyu on M12
            • Dim Items:
              • Type: Execute Command/Script/Program
              • Target Item: heyu obdim M12 ${intensity.math(((X*-22)/255)+22)}
            • Off Items:
              • Type: Execute Command/Script/Program
              • Target Item: heyu off M12


            That’s it, no Legacy Fields need to be used.

  9. Corey,

    That helped for sure. I was missing a critical step of clicking ‘add’ under the manage field at the far right of the items field. It wasn’t saving my heyu commands when I went back to review it after it failed to work.

    So for me I needed to know to click the add under the manage field for each item and then click update bridge item to save the changes.

    It is working now and looking forward to adding my other devices.

    I always had my existing bridge done the older way on a separate Pi so this was an upgrade project. My wife would not be able to live without the first bridge. (Thanks to you) It is very useful and impressive to friends and family!

    Now my next challenge is including the TV into the mix…

    Thanks again!


    1. Glad you figured out the missing step. I’ll update my post to include clicking “Add”.

      The new UI is a bit cluttered, another user has forked the repo and is working to improve the UI, so hopefully it’ll get more clear.

      It definitely upped the WAF (Wife Approval Factor) of all my ‘tinkering’, with the Echo it is more user friendly.

      For the TV, the easiest option is the Harmony Hub. The Echo has a few skills for it now, which you can enhance with the ha-bridge.

  10. G’Day Corey,
    Can you help me? I have just found your blog, followed the installation to the letter with dismal results. I have absolutely no clue about programming so copy & paste are the only options available to me. I have just installed a clean copy of Home assistant via youtube video. All seems to be working. I also have a XTBM signal meter for X10. I have been involved with X10 since 3 Jan 1990 & presently have 40+ modules (appliance) driven by “Homevision”. Everything works great. Being in australia we use 240VAC & use a TW523 device for X10 communication. max distance is 200mtr reasonable reliable. Today I connected a Winplus HA125 and Eon3 CM12AU programmable computer controller to the power line. Each are supposed to be identical to a CM11A. They are not! After getting everything loaded ready to test with the heyu on H2 command I don’t get a response. My signal analyzer sees the H2 on command with but with errors. (bad start command). From that I assume that all is ok from the RaspberryPi3 the device comes with its own USB to device cable (which works with other software {{ on a Windows7}} computer. Do you think the problem might be software considering the devices might be looking for a slightly different protocol? I am really keen to get my copy of home assistant working with all my X10 stuff. No use me ordering an American version of CM11A as it is 110VAC bus also 60Hz which will probably affect the zero crossing output of the device. Next step is to thank you for your tutorial as even a dummy like myself could make it load without lessons in lynux etc. Perhaps when Amazon Echo is available out here I’ll have a crack at voice commands. Sorry for the ramble Regards, Greg

    1. Hey Greg,

      I do see that HEYU should work with the “CM12A”, I don’t know if there is a difference with the “U” being the “CM12AU”? Here is a direct quote from the HEYU Manual, “220 Volt versions of the CM11A are sold in Europe as variously named CM11x models (depending on AC plug style) and in the UK as the CM12U”. I do know that only a few controllers work with HEYU.

      Another thought is do you have the correct USB device registered with HEYU? What do you get when you enter $ ls -l /dev/ttyUSB0 in the command line? If no response, try $ ls -l /dev and scroll through the list until you find something like “ttyUSB” with a number at the end.

      There is another popular X10 control library, that being MOCHAD. It is very similar to HEYU, but I am not sure it works with any the X10 controllers you listed.

      Can you communicate (control) X10 modules with Homevision from a URL (Not a GUI)?

      Can you communicate (control) X10 modules with Home Assistant from a URL (Not a GUI)?

      If yes to either above, you can put those control URLs into the ha-bridge to control your X10.


      1. Hi Corey,

        HOORAR! My solution was to start Hassbian from scratch on a new SD card. I again followed your instruction to the letter & can now access X10 via a terminal window (as per your test). In HomeAssistant I can now switch on/off devices through switch: platform: command line. Many MANY thanks for your drive to keep me going. I am unable to access the configurator & I don’t understand what it does or how it works but the overall output does exactly what I need to continue.

        1. Awesome, glad you got HEYU to work with your gear!

          The configurator the GUI for the ha-bridge software. It is the “bridge” between HEYU and the Amazon Alexa smart home control. The ha-bridge spoofs on your network as if it were a Philips Hue Bridge allowing control of non-Hue devices with an Amazon Echo as if they were Hue devices.

  11. Corey, I really appreciate your work to produce the X-10 tutorial. I ran through all of the setup instructions and was able to get the Ha Bridge to load, but when I reboot my RPi, the bridge does not start automatically. Going through the steps again, when I say to save the startup file I get a message: “unknown lvalue “wantedBY” in section [Install]. I am also having trouble adding devices to the bridge, even when I put in exactly what you show in your example for “kitchen”. I am wondering what is the best way to troubleshoot these issues, and I should say that while I am pretty knowledgeable about computers, I don’t have much of any experience with programming or with Linux, so if you can tailor your comments for a newbie, that would be great.

  12. Corey…further information re my problem. I can control my X-10 switches with Heyu and that works just fine.
    If I “enable habridge” and , I get the following:
    “The unit files have no [Install] section. They are not meant to be enabled using systemctl.
    Possible reasons for having this kind of units are:
    1. A unit may be statically enabled by being symlinked from another unit’s .wants or .requires/ directory
    2. A units purpose may be to act as a helper for some other unit which has a requirement dependency on it.
    3. A unit may be started when needed by activation (socket, path, timer, D-bus, udev, scripted systemctl cal…)

    1. Can you try $ uname -a on the command line and tell me what version of Raspbian you are using?

      1. Sure, Corey. It is “Linux raspberrypi 4.4.50-v7 #970 SMP Mon Feb 20, 2017 army 71 GNU/Linux”
        I also should mention that when I connect with putty from my windows 7 laptop, it takes some time for the command line to come up, and then when I enter user “pi” there is quite a pause, and then another long pause after I enter the password. And when I type a command, at first maybe only the first character of the command is displayed and then after maybe 10 seconds of waiting, the remaining characters are displayed. This behavior has only started occurring recently.

        1. That’s a newer version than my system is running! (Linux raspberrypi 4.4.34+ #930 Wed Nov 23 15:12:30 GMT 2016 armv6l GNU/Linux) I’m doing an update and upgrade as I type this now.

          It sucks, but I think your system has a problem with the systemctl and slow SSL symptoms, it looks like it’s time to reflash your memory card with Raspbian and start over. Make sure it’s Raspbian with PIXEL, not the LITE version. If you have a NOOBS card then just do a reset and then $ sudo apt-get update and $ sudo apt-get upgrade

          1. OK, I re-formatted the SD, reinstalled Raspbian and followed your tutorial again. Heyu is working and I think the Bridge is starting automatically. But I installed one device on the bridge to test it, using exactly the format in your “kitchen” example, and when I went to test it, received the following error message: “Request error, Pleae look in your habridge log: error {“type”:6, “address”:”/lights1″, “description”:”error on calling out to device”, “parameter”:”/lights/1state”}.” Was I supposed to add more/other information on the “add device” page?

          2. Hey Corey,
            Regarding the message I sent earlier today…you hadn’t mentioned in your tutorial that when adding devices the “Count” must be specified (I decided to try “1”) and that the “HTTP Verb” must also be specified (I selected “GET”). So when I populated those two fields, saved and tested…BINGO! Perhaps you might add that bit of information in the tutorial, although likely most people (who aren’t “newbs” like me) will know that intuitively.

          3. One more item…the dim command doesn’t seem to work as well as I expected. Do you mean that the bridge only dims to 3 different levels? Does some number need to be substituted for “X” in the dim command you outlined>

          4. That’s wierd:
            – Count is if you want multiple executions > 1.
            – HTTP verb is for URLs and TCP, this is an EXEC command.
            I was able to create a new device with no problem. I think you missed the clicking of the green “Add” button after filling out the details in the “On Items”, “Dim Items” and “Off Items”, which I did not specify in my instructions. I’ll add that now.

            The dim command converts to what X10 modules can operate to, from 1 to 22. The math operation takes the 0 to 255 output of the bridge and converts it to 1 to 22 based on closest whole number. The obdim command turns the light on each time, then full bright, then dims to the resulting number 1 to 22.

      2. In regard to your April 11 reply to my question, I was in fact clicking the green “Add” button, but despite that, unless I added a “count” and the “GET” in the appropriate boxes, the device would not add.

        1. This then has me baffled. You did not miss anything that needed to be chosen or clicked.

          Have you gotten the dim command to work to your needs?

          1. No, the dim command does not seem to work at all. Using my HAI controller I can send a “light level” command which will dim the light, but then once it is dimmed, an “on” command from heyu will not turn it to “100% on”. And it is strange that my HAI gives me choices of “Brighten” in 1-9 steps, “Dim” with the same 9 steps, and “Light Level” with a range of 0-100%, yet from “off” “Brighten” does not work, and “Light Level” does, and from 100% “on” “Dim” does not work but “Light Level” does.
            I am really puzzled!

            1. Also, as a complete newbie to heyu and the bridge, in your dim command where you say “X*-22”, are you putting in a value for “X” in your actual command, and what does the “*” do? Could you give a specific syntax example?

            2. Hey, sorry for the delay in replies, was away on a Spring Break vacation with the family.

              The “*” is multiply. So the “X” is the value from Alexa for the requested dim from 1 to 255. My X10 modules need a value from 1 to 22. So I needed to convert it, plus the higher the X10 dim number the dimmer it goes, which is backwards from what is received from Alexa. This is why I multiplied the “X” by negative twentytwo (X*-22).

              I’m glad you got it all working, enjoy!

          2. Hey, I stumbled onto something in the posts above. “Andy” had mentioned an “xpreset” command, and I tested it with one of my units and it works fine. It appears to do what my HAI “light level” command does, so if I am at a light level of, for example 20%, I can enter “dim to 100%” and the light goes full-bright. Just like I wanted!

            Next problem, I ask Alexa to discover my devices and she does not find any. She says to press a button on my HUE device….does something have to be done in the HA bridge to make the devices discoverable?

            1. I re-initialized the bridge and now Alexa has discovered everything. It’s all working perfectly! Thank you very much for all of the work you have put into this project…it’s really neat!!!

  13. Great write up Corey. Will be purchasing parts today. Since you are spoofing the Phillips Hue Bridge, will this prevent you from using Phillips Hue Bridge in the future or will you still be able to discover other Phillips Hue devices? You have a note that says to disconnect Phillips Hue Bridge, guessing once you reconnect, those will still be recognized. When discovering new Phillips Hue devices, would you need to disconnect other bridges and the raspberry pi? Thanks!

    1. You can still use a real Philips HUE Bridge, just need to turn it off during the discovery of the ha-bridge. The ha-bridge will even communicate with the real Philips HUE bridge.

  14. Hi Corey, I have had everything working using Alexa, but for some reason Alexa started to show the discovered devices offline. I removed all devices from the HA Bridge and added just one new one, the device works fron the HA Bridge software but Alexa wont discover the device. Any ideas please.

    1. Have you tried power cycling the Raspberry Pi, network router and Alexa device(s)? If not give it a try.
      Have you added a real Philips HUE bridge to your network? It will interfere with the discovery of the ha-bridge if powered on during discovery.
      Has your router’s firmware updated?
      Have you tried to do $ sudo apt-get update and $ sudo apt-get upgrade recently? If not do both, then power cycle your Raspberry Pi.

      1. Hey Corey,
        Sorry to bother you, but starting today I started having the exact same issue as Barry. Did the same as he did. Heyu working fine, ha-bridge working fine, but in Alexa app my 5 devices were showing offline. I removed and tried rediscovery, and they aren’t found. IP address is correct, everything else in ha-bridge looks correct. I upgraded to ha-bridge 4.5.0, did an update/upgrade on the Pi, power cycled everything. At a loss. I did see that yesterday I believe Alexa did something to the API on their end to now support voice commands for changing color on Hue, TP-Link, and one other. There are some reports on the homeautomation Reddit that Hue version 1 is having issues. Since ha-bridge is emulating what looks to be an early Hue version I wonder if there is some connection? At a loss as to what else to try…
        Thank you, sir.

        1. Annnddd…. it’s back to normal.

          Weird it didn’t affect any of my TP-Link switches, etc., but only the RasPi/X10 stuff. Who knows–ghosts in the machine.

          1. Do you know what version you were using before going to v4.5.0? A few releases back the ha-bridge device IDs were simplified from multiple to simple autonumber digits, to more closely mimic the real Philips HUE bridge numbering nomenclature.

            Alexa seems to periodically update the device list, especially HUE devices on it’s own, maybe after firmware updates to Alexa, I don’t know? I wonder if your devices got renumbered and Alexa got a bit confused with your device numbering, but that wouldn’t explain the working TP-Link devices.

            Like you said (one of my own favorites) ghosts in the machine. Glad it’s back to working!

Leave a Reply

Your email address will not be published. Required fields are marked *