I am no expert, but in your long post, #3 last line of x10 log showed it had connected to your mqtt broker.
You can test by publishing an mqtt command via developer tools.
If working, the X10 addon log will show something like this
1 Like
Mark,
Thanks. I use HAOS, which has this crazy Docker layer on top of almost everything, and it seems that the real IP addresses and hostnames are opaque. That makes it very confusing to fill out these fields.
But the biggest confusion comes from the fact that the field in the UI is called 3 different things in the Mosquitto add-on, MQTT integration, and X10 to MQTT add-on .
In Mosquitto add-on, it is called hostname, and hardcoded. There is no way to change it :
In your add-on, it is called mqtt_host, and configurable :
In the MQTT integration, it is called broker :
I realize you only have control over your own add-on, so this is not your fault, but some consistency would go a long way to figuring things out.
I believe I matched all these to the same name, but things are not working yet, unfortunately.
Thanks for creating the add-on, and any help you can provide getting it to work.
Thanks. I did the publish exactly as you instructed.
Here is what the add-on log looks like afterwards :
Waiting for MQTT messages and monitoring for remote changes
Connected to MQTT broker, result code 0
Remote status change, publishing stat update: x10/stat/b1 is now OFF
Remote status change, publishing stat update: x10/stat/b2 is now OFF
Remote status change, publishing stat update: x10/stat/b1 is now ON
Remote status change, publishing stat update: x10/stat/b2 is now ON
Remote status change, publishing stat update: x10/stat/a1 is now ON
Remote status change, publishing stat update: x10/stat/b1 is now OFF
Remote status change, publishing stat update: x10/stat/b2 is now OFF
Remote status change, publishing stat update: x10/stat/a4 is now ON
Remote status change, publishing stat update: x10/stat/a4 is now OFF
Remote status change, publishing stat update: x10/stat/a4 is now ON
Remote status change, publishing stat update: x10/stat/a1 is now OFF
Not clear why it’s showing those status changes.
The b1 device didn’t change status while I was doing this, or any of the other X10 devices.
The a4 X10 device does not exist in my house, at least not as far as I know 
a2, a3, c1, c2, c3, c4, d1 and e1 exist, but are not shown in the list.
b1 is an XPS3 wall switch that controls my office light. If I press the switch manually, and turn it on or off, there is no update in the log.
If I use an RF remote and RF plug-in transceiver to turn that switch on or off, the add-on log does update.
Remote status change, publishing stat update: x10/stat/b1 is now ON
Remote status change, publishing stat update: x10/stat/b1 is now OFF
Remote status change, publishing stat update: x10/stat/b1 is now ON
Remote status change, publishing stat update: x10/stat/b1 is now OFF
Remote status change, publishing stat update: x10/stat/b1 is now ON
I still don’t see any X10 devices in the GUI under Configuration / Devices and services, unfortunately. Is there something else I’m missing ?
Actually, I see the “Office light switch” under “Overview” in the “Switch” section at the bottom. And I can operate it ! That works. It’s major progress. I also see another switch, “Office audio amplifiers”, which is X10 b2, that I defined in configuration.yaml, even though I didn’t perform another publish step for it.
It looks like I need to assign it a unique ID in order to manage it through the GUI, for example, assign it to a particular room, or use it as part of automations. I’m not sure how/where to assign that unique ID. The X10 to MQTT add-on doc didn’t shine light on this. Maybe it’s a normal HAOS or MQTT thing to do, but I just don’t know how.
Pressing any wall switch will NOT have any effect on Mark’s addon, the status of the light in HA UI won’t change either. The wall switch doesn’t need to send any powerline data when pressed, as it can control the light itself. No powerline data = no effect seen by addon.
As for unique ID, or other HA stuff, ask Mr goggle. Your addon is working, now comes the hard stuff of learning HA . Just remember HA is constantly being updated, so some answers from goggle may be out of date. To your previous query of backup, the goggle drive backup addon is supposed to be the best n easiest to setup. It is the one above the X10 addon in my previous screensnot.
Have fun (n some frustration, until you get the hang of it) 
Yes, it makes sense there would be no update in the plug-in in those cases. Unfortunately, seems like an X10 hardware limitation. I almost never press the XPS3 switch in my home theater due to its inconvenient location. That’s why it’s an X10 switch in the first place, to allow it to be turned on remotely.
The three XPS3 switches in my home theater on the other hand are controlled either from my IR543, RF remote, or by hand. And I guess the latest case means the switch state will not be correctly reflected in any automation program that uses the CM11. Too bad those switches aren’t 2-way devices, and there is no way to manually query the status.
Re: Google, believe me, I have been using Google a lot. It’s how I got to the state last night, where I was only short of the publish step that you provided. And I still haven’t seen that step mentioned in any other document I read, so I’m curious how you became aware of it.
As to the unique ID, the doc contradicts itself.
In one place, it says it can’t be changed. And in another, it says a few selected integrations allow the user to define a unique ID. Both on the same page, too.
Clicking the link to mqtt brings this page
No mention of unique_id even under advanced features .
Googling on change unique id home assistant mqtt brings this up :
Seems like some people got past it, but no working example of the switch configuration is shown.
However, there is a link to the MQTT switch configuration .
That one mentions that unique_id is optional .
I added it to my two switches in configuration.yaml, and restarted the server.
Still no X10 switches under Configuration / Devices and services.
The MQTT integration is there, but has no devices listed underneath it .
Finally, I went to the overview screen, and clicked on one of the switches, and the gear icon (settings). And now, the error message about missing unique_id is gone. Hallelujah ! I am able to change the area, and assign it to office. It doesn’t show in that room under overview until I refresh the browser with F5, though.
So yes, it looks like I finally figured it out. The number of steps required to do so was insane, though.
From a user experience point of view, it could/should have been so much simpler :
- a simple way to locate/install the X10 to MQTT integration, that works the first time around
- settings for the serial port / cm17_in use presented at the time the X10 MQTT add-on is installed
- if not already installed and configured locally, MQTT broker and integration automatically installed and auto-configured, maybe with autogenerated user and random password .
- some sort of GUI to create new X10 devices and input the X10 code, and name. Unique ID either auto-generated from switch name, or another separate field in the GUI.
- X10 devices should show somewhere under configuration/devices, like all others devices do
I am running into a problem with when editing existing device configuration in configuration.yaml .
I made some typos originally when I first set things up.
For instance, for the following device, I originally set it up as code c3, which is my terrace light, not backyard light. I fixed the definition in configuration.yaml to be code c4, which is the correct x10 code.
- platform: mqtt
name: "Backyard light"
state_topic: "x10/stat/c4"
command_topic: "x10/cmd/c4"
payload_on: "ON"
payload_off: "OFF"
retain: false
unique_id: backyard_light
Unfortunately, the new definition does not take. The backyard light switch in the UI continues to use code c3, and controls my terrace light, instead of my backyard light.
I have used the “check configuration” feature in HAOS, and the configuration is all OK.
I have tried to restart the X10 to MQTT gateway add-on.
I have tried to restart the Mosquitto MQTT add-on.
I have tried “restart server” in HAOS.
I have shutdown HAOS and rebooted the Pi with power off / on toggle.
None of those things have fixed the problem. The initial incorrect device configuration sticks.
I’m not sure where the problem lies, but if anyone knows of a solution, I would really appreciate it.
I’m in the process of switch house codes on several X10 devices to consolidate them all to 2 house codes instead of 5 house codes, so I’m going to run into this a lot.
I found that removing the Mosquitto broker add-on, and reinstalling it, solved the problem.
I’m wondering is there is a better solution as that seems a bit heavy-handed thing to do every time I need to do an X10 code swap. The issue affects the entity IDs and even the friendly name as well.
I was going to suggest deleting both devices from mqtt and re-adding them. The integration leaves persistent data in mqtt so that the last known state of the device can be the current state after a reboot. If you look for a program called MQTT Explorer you can actually watch the traffic and each entity as it changes, and delete misconfigured ones directly.
I’m intested testing mochad if you would package it or point me to a good source on how to package it. I’d be willing to test it. I have a lot of x10 stuff which has been super reliable. I’m slowing swtiching to zwave but the stuff has got very expensive I’m assuming because of the supply chain issues.
@markm I’ve been looking through the code for the Integration, finally figured out how the docker container worked and I’m thinking of trying to add basic dimming support since heyu already supports it. I want to make very sure though I don’t step on any toes here so I’d like to know you’re OK with me playing around in the code. Never used GitHub, never setup a repo, not sure how I’d even publish anything that I got working, 
1 Like
Go back to post 33 of this thread and you will find links to some X10 documentation which may be helpful in implementing dimming capability in the existing scripts.
I would be glad to test/evaluate your work if I can be of any assistance.
its going to drive me mad…
this is the mqtt broker log:
[19:15:53] INFO: Starting mosquitto MQTT broker...
1658592953: Warning: Mosquitto should not be run as root/administrator.
time="2022-07-23T19:15:53+03:00" level=debug msg="got 3 users from passwords file"
time="2022-07-23T19:15:53+03:00" level=debug msg="got 0 lines from acl file"
time="2022-07-23T19:15:53+03:00" level=info msg="Backend registered: Files"
time="2022-07-23T19:15:53+03:00" level=debug msg="new hasher: pbkdf2"
time="2022-07-23T19:15:53+03:00" level=info msg="Backend registered: HTTP"
time="2022-07-23T19:15:53+03:00" level=info msg="registered acl checker: files"
time="2022-07-23T19:15:53+03:00" level=info msg="registered user checker: files"
time="2022-07-23T19:15:53+03:00" level=info msg="registered superuser checker: files"
time="2022-07-23T19:15:53+03:00" level=info msg="registered acl checker: http"
time="2022-07-23T19:15:53+03:00" level=info msg="registered user checker: http"
time="2022-07-23T19:15:53+03:00" level=info msg="registered superuser checker: http"
time="2022-07-23T19:15:53+03:00" level=info msg="redisCache activated"
time="2022-07-23T19:15:53+03:00" level=info msg="started go-cache"
[19:15:53] INFO: Successfully send discovery information to Home Assistant.
[19:15:53] INFO: Successfully send service information to the Supervisor.
time="2022-07-23T19:16:29+03:00" level=debug msg="checking auth cache for x10"
time="2022-07-23T19:16:29+03:00" level=debug msg="to auth record: [97 117 116 104 45 120 49 48 45 120 49 48 218 57 163 238 94 107 75 13 50 85 191 239 149 96 24 144 175 216 7 9]\n"
time="2022-07-23T19:16:29+03:00" level=debug msg="checking user x10 with backend Files"
time="2022-07-23T19:16:29+03:00" level=debug msg="user x10 authenticated with backend Files"
time="2022-07-23T19:16:29+03:00" level=debug msg="setting auth cache for x10"
time="2022-07-23T19:16:29+03:00" level=debug msg="to auth record: [97 117 116 104 45 120 49 48 45 120 49 48 218 57 163 238 94 107 75 13 50 85 191 239 149 96 24 144 175 216 7 9]\n"
time="2022-07-23T19:16:29+03:00" level=debug msg="checking acl cache for x10"
time="2022-07-23T19:16:29+03:00" level=debug msg="to auth record: [97 99 108 45 120 49 48 45 120 49 48 47 99 109 100 47 43 45 97 117 116 111 45 57 67 69 49 69 69 54 54 45 53 68 56 68 45 51 52 70 69 45 56 52 57 67 45 68 56 56 67 55 65 53 53 55 50 57 69 45 52 218 57 163 238 94 107 75 13 50 85 191 239 149 96 24 144 175 216 7 9]\n"
time="2022-07-23T19:16:29+03:00" level=debug msg="Superuser check with backend Files"
time="2022-07-23T19:16:29+03:00" level=debug msg="Superuser check with backend HTTP"
time="2022-07-23T19:16:29+03:00" level=debug msg="http request approved for x10"
time="2022-07-23T19:16:29+03:00" level=debug msg="superuser x10 acl authenticated with backend HTTP"
time="2022-07-23T19:16:29+03:00" level=debug msg="setting acl cache (granted = true) for x10"
time="2022-07-23T19:16:29+03:00" level=debug msg="to auth record: [97 99 108 45 120 49 48 45 120 49 48 47 99 109 100 47 43 45 97 117 116 111 45 57 67 69 49 69 69 54 54 45 53 68 56 68 45 51 52 70 69 45 56 52 57 67 45 68 56 56 67 55 65 53 53 55 50 57 69 45 52 218 57 163 238 94 107 75 13 50 85 191 239 149 96 24 144 175 216 7 9]\n"
time="2022-07-23T19:16:29+03:00" level=debug msg="Acl is true for user x10"
this is the X10 to MQTT gateway log:
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[19:16:25] INFO: Configuring Heyu...
[19:16:25] INFO: CM11 is enabled
starting heyu_relay
Establishing MQTT to core-mosquitto port 1883...
(Using MQTT username x10)
Waiting for MQTT messages and monitoring for remote changes
Connected to MQTT broker, result code 0
and finally this is my entry in configuration.yaml
switch:
- platform: mqtt
name: "X10 G3"
state_topic: "x10/stat/g3"
command_topic: "x10/cmd/g3"
payload_on: "ON"
payload_off: "OFF"
retain: false
unique_id: X10_G3
i still cannot see this entity in Settings/Devices & Services/Entities
what am i doing wrong ? 
This may seem like a stupid question, but can you use the X10 switches to control other HA devises? Like a zigbee bulb through automation, or is this strictly to control X10 while having it in Ha?
The X10 switches switch 120/240Vac. You can just plug a regular bulb into them. I do use the X10 rf remote HR12A to control other HA devices via automation, scripts. HR12A control up to 16 HA entities.
Basically, any X10 remote can send 315Mhz X10 signal to this addon, which sends mqtt to HA. Non X10 devices can send mqtt to HA to control X10 switches.
Awesome, that’s just what I was looking for. Thanks!
Have any luck? I seem to be having the same issue.
I am using some 20+ year-old Leviton X10 4-button 6400 wall controllers as triggers in Home Assistant. The MQTT trigger is available for automations and scenes.
Not using the unique_id field in my yaml. Wondering if not using lower-case might your issue.
1 Like
I’ve read the entire thread and haven’t seen anyone else run into this problem.
My current setup is this add-on running on supervised HassIO running on VMware ESXi 6.7. Heyu is having trouble communicating with the serial port, a real serial port on /dev/ttyS0. I also tried a USB to serial adapter and got essentially the same results.
My troubleshooting so far:
-
docker execinto the add-on container. Runheyu infomultiple times. It responds once in a while but mostly times out. -
docker runa vanilla alpine container on a different docker host. Use--device=/dev/ttyS0to pass in the serial port. Build heyu using the same sequence this container uses. Heyu works reliably. -
docker runa vanilla alpine container by ssh’ing into HA. Build heyu as in step 2. Heyu is mostly unresponsive just like in step 1.
Is anyone here wiser in the ways of HassOS who might know what might be getting in the way?