Home Assistant Add-On: X10 (CM11) to MQTT Gateway

Home Assistant Add-on: X10 to MQTT Gateway

This add-on allows for on and off control of X10 via a CM11a (serial) interface using MQTT.

I’m not sure how many of us still have X10 in our smart homes (I don’t), but I wrote this for a friend who has a handful of them still left and was stuck in a venv environment because of the need for the ‘heyu’ executable.

Note that this supports and was tested with the CM11a, which is a RS232 serial device and uses the legacy ‘heyu’ for control under the covers. You can easily connect this using a USB-to-serial cable. It may work with the CM17 “Firecracker”, but that has not been tested as I don’t own one.

It does NOT support direct USB interfaces like the CM15 or others.

If there is interest in CM15 support (which is usually handled by ‘mochad’), I would be willing to package that up as an add-on as well, although I have no way to test as I don’t have a CM15. Let me know if you’re interested and would be willing to help test.

Installation

This is currently in my own repository. Within Home Assistant, select Supervisor -> Add-On Store -> … (upper right) -> Repositories. Add the following URL:

https://github.com/mmotley999/hassos-addons

The “X10 to MQTT Gateway” add-on should appear at the bottom of the Add-On list.

Installation is just like any other Add-On and supports all the typical platforms with pre-built Docker Hub containers using the Home Assistant add-on build script: armhf, armv7, aarch64, amd64, and i386. It was tested on aarch64 (Rpi 4).

Configuration

There are a few items to configure that are outlined in the documentation, specifically the serial port that is connected to the CM11a and MQTT details like hostname, authentication, and topics for commands and status.

If using the Mosquitto add-on, you can leave the host at the default (‘core-mosquitto’). MQTT username and password is technically optional, but the Mosquitto Add-On requires authentication by default.

Operation

Add either switch or light MQTT components in Home Assistant. Only ON and OFF are supported. Sorry, no support for dimming.

Example for house code G7 using the default command and state topics:

switch:
  - platform: mqtt
    name: "X10 Switch"
    state_topic: "x10/stat/g7"
    command_topic: "x10/cmd/g7"
    payload_on: "ON"
    payload_off: "OFF"
    retain: false

The Add-On will also continually monitor for X10 commands that happen outside of Home Assistant (for example, from X10 remote control devices) and update the status of the Home Assistant entity accordingly via the MQTT state topic. NOTE: The state topic is published with the Retain flag so that the entity status is correct when Home Assistant restarts.

Support

Feel free to use this community topic for comments or suggestions, or if you found it useful in your setup!

This is my very first Add-On, and frankly my first real Python script (which is the main process that runs), so be easy on me.

2 Likes

Was able to add your repository to my Supervisor Add-on Store, but no entry or entries are added to my available add-ons (neither Official nor Community).

I appreciate your efforts very much as I have been frustrated trying to add X10 capability to my HA installation. I have done the heyu installation on a Raspberry Pi running Raspian several years ago to emulate a Hue bridge to that Alexa can access my X10 devices.

Had no success integrating heyu into my Home Assistant because I guess it runs in a docker container - and four weeks into my configuration I have no desire to sttart over again.

Hi Mark,

I’m the past weeks busy trying to get your add-on in my home assistant, but without success.
When I follow your instruction (adding your link) it goes wrong in the search part of the supervisor tab

I get the error message (In Dutch) :
Geen resultaten gevonden (no results ) in Official add-ons.
Geen resultaten gevonden in Home Assistant Community Add-ons.

It looks that Home assistant can’t look outside his own Add-on area block.

I’m running PI 4 ( with some older versions Home assistant but also updated to the latest version. ) all are giving the same error message.

Can you help me whit some advice. Probably a alternative to load and run your add-on.

My current home automatization is X10 and I want to migrate this to Home assistant.

Regards Ton O

@tarzan_nojane and @tono55, when you add the repository, it will show underneath the Community group. See attached screenshot.

Annotation 2021-04-24 144132

Hi Mark
Thanks for your reply. Your answer does not work for me. I have had once such a respons in a previous home assistant version, but having other problem issues with updates I left the X10 approach at that time. I can’t reproduce that earlier result after a number of updates of Home Assistant. So adding your link as url under supervisor add-on store creates the error message : no results in official add-ons and No results in Home assistant Community Add-ons. Probably the uodate version of Home Assistant is the course.
Is their a manual way to install your add-on?

Regards Ton O

Hi Mark,
first off, thank you very much for your efforts in making this add-on. I am currently running heyu in rasbian (without hassio). My hassio is on a different Pi.

I was able to install your add-on following your instructions without any problem, on the Pi with current version of hassio (core-2021.4.6, supervisor supervisor-2021.04.0, Home Assistant OS 5.13).

However, your add-on does not work with the CM17 “Firecracker". In heyu, the commands for CM17 is fon and foff. Your add-on clearly only allows for on, off.

Using CM17 with FON, your add-on log shows:
Received: x10/cmd/b7 FON
Invalid command or home code

Using CM17 with ON command, get this error instead:
Received: x10/cmd/b3 ON
Sending X10 command to homecode B3
Unable to send address bytes
Error running heyu, return code: 1
Device Status Update: x10/stat/b3

Then using my old 1st generation, and flaky CM11A, log shows:
Received: x10/cmd/b3 ON
Sending X10 command to homecode B3
Device Status Update: x10/stat/b3
Received: x10/cmd/b3 OFF
Sending X10 command to homecode B3
Device Status Update: x10/stat/b3

So, your add-on seems to work for CM11A, as it should. Hassio show state changes for both CM11A and CM17A (from the mqtt msgs, I suppose).

However, the physical switch does not respond, even when plugged into the same outlet as my CM11A. That most likely is due to that CM11A being a flaky one, that’s why I don’t use it anymore.

Can you update, or point me on how to modify, your add-on to accept FON/FOFF to use the CM17?
Also, what does the error “Unable to send address bytes” when using the CM17 means?

Regards.

@yeeCdn thanks for this. I’m actually not much of an X10 expert (I don’t use it in my home and wrote this for a friend who has a few remaining X10), so this is very helpful.

I think I may be able to make a modification to support this, as it seems straightforward. I don’t have one of these modules, so would you be willing to be my tester? :slight_smile:

Hi Mark,
Of cos, I am willing to be your tester. As I mentioned before, the only difference in Heyu commands for CM17 is fon and foff instead of just on and off for the CM11A.

The CM17 is a one way device, not connected to AC line, so it can’t respond back to Heyu. It just sends out X10 rf signals over 310MHz. So the Heyu monitor feature will obviously not work. That’s ok for anyone using the CM17, I think. Certainly for me :grinning:

Thanks for your help in advance.

Hi Mark,
Newbie mistake. Had posted to the thread instead of replying to you. Of cos, I am willing to be your tester. Pls see my post in the thread.

Ok, so I’ve added an ‘x10mqttbeta’ addon that has the basic changes for the CM17A.

To see it, make sure my repository is added, then perform a ‘Reload’ from the 3-dot menu on the Add-On Store screen.

Note that it will take a while to install since I haven’t pre-compiled the containers (it is build-on-device) and haven’t tested this at all other than to make sure it starts (after dealing with all my silly Python mistakes…I’m such a newb with it)

Enable the ‘cm17_in_use’ toggle, make sure the main (non-beta) add-on is stopped, then start and give it a try and let me know how it works!

Hey Mark,
Yahoo!! It works beautifully :+1: :+1: :grinning:
Thank you very very much.

I assume you will update the original and remove the beta eventually. If not, there is just one problem, not affecting functionality. After starting it, the beta is not visible in the Supervisor - Dashboard screen like the original version. It is only visible in the Add-On screen.

For those people with both CM11A and CM17, does this work with both simultaneously, or only one at a time? The CM17 has a pass through on its DB9 connector. So, in theory someone could connect both. Don’t know how that would actually work, since I don’t have a working CM11A.

For me, you just make my day. Once again, thank you!!

Great to hear, and thanks for testing!

Yes, I’ll update the original one to a newer version and remove the other addon… adding it temporarily was the only way I knew how to do it quickly because I’m also a Github newb. :slight_smile:

Regarding using both daisy-chained… that’s a good question! The heyu docs do mention this, and I’m thinking out loud here that it should work?

The big advantage of the CM11 is that it listens and reports on any X10 activity it sees on the power lines. My add-on fires up a ‘heyu monitor’ process in the background and uses a regular expression to capture any X10 on/off activity, which sends an update via MQTT accordingly. This helps keep everything in-sync… for instance, I tested with a very old X10 remote, and toggling my test appliance module via the remote also reflected the change in Home Assistant (e.g. the on/off state updated automatically).

I have not removed this functionality in the version you tested (even though the CM17A doesn’t support monitoring). If your CM11 can still listen to X10 (but may not be transmitting well) and you’re willing to play with it, perhaps give a whirl and let me know?

Hi Mark,
Hmm, good idea. I will test out daisy-chain and report back. Tho’ failure to listen may just mean my cm11 is kaput. I suspect its interface to the powerline is faulty, since its serial side can respond to your addon.

Hi Mark,
you are a genius! Daisy chain CM11A to CM17 works :smiley:

Beta Addon log below. First 4 lines using CM17 to send codes from your beta addon. Still working as expected. The rest of lines, using a standard X10 model HR12A wireless remote. The Hassio light status changes accordingly for all of those. Yahoo!

Received: x10/cmd/b3 OFF
Sending X10 command to homecode B3
Remote status change, publishing stat update: x10/stat/b3 is now OFF
Device Status Update: x10/stat/b3
Remote status change, publishing stat update: x10/stat/b3 is now ON
Remote status change, publishing stat update: x10/stat/b3 is now OFF
Remote status change, publishing stat update: x10/stat/b3 is now ON
Remote status change, publishing stat update: x10/stat/b3 is now OFF

Also, my previous note that the beta addon did not show up in Supervisor-Dashboard along other installed addon’s is no longer correct. After a restart, it showed up there together with the original version.

Thanks man. You did a fantastic job, man!! :+1: :+1: :clap: :clap:

ps not sure if your friend has notice that used this way, the CM11A don’t need those 2 AAA batteries anymore.

Great! I’ll push the update, and also update the docs to reflect the fact that they work together.

Once you see a version change in the main x10mqtt add-on, you can go ahead and uninstall the BETA version and apply the update… the primary version will be exactly the same code as the BETA.

Ok, the update should be live, version 0.2.0. May need to do a Reload on the Add-On Store screen for it to show.

Thanks again for your help in testing, I hope it helps!

Thanks. Much appreciated your effort in first making this addon, then improving it.

Kudos for the fine work and documentation. Thanks to the latest beta update, I am able to get this installed for my CM17A only setup. The logs indicate it appears to be working. I have added the following to my configuration.yaml, but neither a device nor an entity are created:

switch:
  - platform: mqtt
    name: "Counter"
    command_topic: "x10/cmd/b7"
    payload_on: "ON"
    payload_off: "OFF"
    retain: false

Is there something else that I am missing? It is also not obvious to me how to add multiple devices/entities.

After adding it to configuration.yaml file did you execute Configuration > Server Controls > Reload Manually Configured MQTT Entities? (Or restart Home Assistant?)

Thanks for response. Yes, I first tried Reload Manually…, and I have both restarted HA and rebooted the RPi.

Thanks to Mark’s detailed documentation, I took another look at my System > Hardware info and noticed that the Serial-USB adapter had replaced my Nortek zigbee/z-wave stick as ttyUSB0 in my system. I corrected the configuration of the X10MQTT Gateway add-on and restarted, but still do not “see” the “Counter” (kitchen counter) X10 device that I am trying to configure.