Control X-10 switch with Luup code via Altsteon

I was just wondering if there is a way to control an X-10 switch utilizing Luup code through the vera ui using the altsteon client. I have an X-10 switch which I use for my pool light which I would like to keep if possible

You may be able to. The code to do it is written and in the daemon, but AFAIK it has never been tested. In the altsteon_instructions.txt file, look for the “send_x10” command description, which will list the syntax of the command you need. To send the command to Altsteon, you will want to use the plmSend() call that is exposed by the InsteonPlm.xml file. That call takes two parameters, the first one is a string that tags any debug output, so it doesn’t matter what you populate it with as long as you populate it. The second is the command you want to send. So, if you wanted to turn on device A1, you would use this command :

plmSend(“debug tag”, “plm send_x10 A 1 3”)

Altsteon will return an event code that indicates it heard the command. However, you would need to modify a fair bit of code to get it. And, in general, it is a meaningless message because X-10 isn’t ACKed. That said, if you wanted to build a module that others can use for their X-10 stuff, I would be happy to help you get hooked in all the correct places. I have held off because I don’t have any X-10 devices anymore, and I don’t want to release something that hasn’t been tested.

I had already read that documentation but was unsure how to write the code for example if I was to create a scene in Vera and use the Advanced tab. What code would I use to do it from there?

In theory, all of the LUA code runs in a single environment. So, the code that you would need is literally :

plmSend(“debug tag”, “plm send_x10 A 1 3”)

To turn on A1. If you want to do something else like turn it off, you would change the value set to ‘3’ to be one of the other values in the documentation. The second parameter in plmSend is the exact command you would send from the altsteon_cli, so you can test things from there. If you fire up the cli and type “plm send_x10 A 1 3” (without the quotes) you should turn on device A1.

If the command above doesn’t work, then it will take more work and some digging around in logs to figure out the right way to do it.

Just wanted to give you a quick update. I was able to successfully send X 10 commands to the client according to the client response. Although, I had to send two commands due to the non-zero command and parameters. I was also able to see that the client was receiving X 10 commands from my wireless X 10 control. Although, the light did not respond to the command. I believe this may be an issue with powerline transmission. Therefore, I am going to try to plug the powerlinc modem into to a different outlet and retest. I’ll keep you up to date.

I have finished my testing of the X-10 functionality of Altsteon. Here are my observations:

  1. As above I was unable to turn the X-10 switch on and Off through the Altsteon Client. In troubleshooting I was able to verify that the outlet that the PLM is plugged into was able to communicate with the switch. I verified this by using the free Houselinc software from Insteon. I was also able to review the Houselinc log and have attached it to this post. If you look towards the bottom you will see the codes that were sent to turn the X-10 switch on and off. I believe they are in Hex format. I’m not sure but I believe that Altsteon must convert the plm send_x10 A 1 3 command into Hex format. Although two commands would have to be sent to turn A1 on as follows:plm send_x10 A 1 0 and plm send_x10 A 0 3. When I send these commands in Altsteon it returns the following plm success 003b,02,63. The problem I believe in being unable to operate the switch is probably in the timing of the commands. You see from the client command prompt I can only send one command at a time(unless I’m unaware how to do it otherwise) and by the time I send the second command plm send_x10 A 0 3 I think it is too late to get the switch to respond properly. Therefore I tried to run a scene in Vera using the Luup tab with the following code:plmSend(“debug tag”, “plm send_x10 A 1 0”) plmSend(“debug tag”, “plm send_x10 A 0 3”) with no success.
  2. Also in testing the client it will show some of the Insteon and X-10 activity on the line. I noticed when I use my wireless keyfob remote to turn on the same X-10 switch I see the following commands reported in the client when I turn it on:plm:0032,02,41,01,00 and plm:0032,02,41,00,03. When I turn it off i see this:plm:0032,02,41,01,00 and plm:0032,02,41,00,0B.
    If you have any thoughts or solutions let me know thanks.

You get an A++++++ for a useful description of the issue. I wish the customers of my day job were so careful in their efforts! ;D

It looks like a couple people already downloaded the log, so it is possible someone is already looking at this. However, I am curious to see the logs as well, so I will take a look myself.

I suspect what I am going to find is that the way I expected the X10 code to work isn’t how it actually works. (Blind implementations are always fun like that. :wink: X-10 is a weird protocol because a single “command” requires two transmissions to work. The code was supposed to hide that detail and just do the right thing, but obviously it isn’t. The other thing that wouldn’t surprise me is if the documentation is either wrong or vague. There have been numerous times that I had to whip out HouseLink or other tools to see what they did.

Okay, I see the issue, and I think I just pushed a fix. We were only sending the first of the two commands needed to operate an X10 device. The code was all plumbed to send the second one, but it appears I was asleep at the wheel and didn’t quite finish it.

So, go ahead and grab any dev build time stampped after 20:00 tonight, give it a try, and let me know how it turns out.

Ok I will try it later today thanx

I tried the New build without success. All of the commands either return the error command failed, incomplete command or you can only send unit code or command. I have tried all of the following: plm send_x10 A 1 3, plm send_x10 A 1 0, plm send_x10 A 0 3, plm send_x10 41 00 03, plm send_x10 41 01 00, plm send_x10 41 01 03. I used the new builds: and Ready to try again when you are.

Some notes from X10 testing I did a while back with altsteon_cli. I did get it to control an X10 relay, but the timing is tricky as noted below.

[code]Commands are 1 or more sequential messages, 0 or more attention messages followed by action.

plm send_x10

Flag is either 0 (attention) or 0x80 (128) (action)

is 2 nibbles, (attention) or (action)

House & unit codes are further complicated by a nonstraightforward encoding.
Code House Unit Binary
0x6 A 1 0110
0xE B 2 1110
0x2 C 3 0010
0xA D 4 1010
Binary Code House Unit Action
0110 0x6 A 1 All Lights Off
1110 0xE B 2 Status = Off
0010 0x2 C 3 On
1010 0xA D 4 Preset Dim
0001 0x1 E 5 All Lights On
1001 0x9 F 6 Hail Acknowledge
0101 0x5 G 7 Bright
1101 0xD H 8 Status = On
0111 0x7 I 9 Extended Code
1111 0xF J 10 Status Request
0011 0x3 K 11 Off
1011 0xB L 12 Preset Dim
0000 0x0 M 13 All Units Off
1000 0x8 N 14 Hail Request
0100 0x4 O 15 Dim
1100 0xC P 16 Extended Data (analog)

altsteon_cli wants numbers in decimal.

So to send All Units Off to A it’s 0x60 0x80 which is plm send_x10 96 128

All messages in a sequence must follow within some small amount of time. A typical sequence is:
0x65 0x00 (attention)
0x62 0x80 (action)
which is attention=A7, action=AOn, which is plm_send_x10 101 0; plm send_x10 98 128 (typed/pasted as separate lines)

Not sure if it will be useful but there are a few plugins for EventGhost that have X10 support - you might want to check them out to see if how they handle the comms helps. I’d love to see X10 support for RF devices (I have an MR26a and many Motion Sensors)!

@dlarrick - There was a check in place that prevented you from doing a command and a unit code on the same line. I have removed those checks, and a new build should be kicked out at the top of the next hour. You will want to send a command with both the unit code and the command code in the same command line. This should cause two commands to get queued for Insteon, which should trigger the device. You do want to use an actual letter for the house code. There is a set of code in the daemon that translates that value to the correctly mangled value used by Insteon. So, give that a try.

You mentioned something about timing being tricky as noted below, but I don’t see anything about timing being in there. I know that you have a certain (small) amount of time that you have to send the two commands in. By changing the command the way I have, I believe we will send the commands fast enough.

@Aaron - Thanks for the link. Unfortunately Insteon handles the X-10 commands in a somewhat weird way, so the plugins would probably only be useful for trying to understand how some devices work. As for supporting RF devices with the Insteon PLM, it just isn’t possible. Insteon wireless devices run in the 900Mhz band, where X-10 devices run in the 300Mhz band. When the PLMs were designed and built, they didn’t put in the radio hardware that would be needed to communicate on the 300Mhz band. So, it is physically impossible for the PLMs to talk to the X-10 wireless devices directly. However, it is possible that if you use a transceiver you could do what you want to do. (But, I won’t promise anything, and we still need to get basic X-10 support working with the Insteon PLM, and to support something like the motion detector we would need to figure out the best way to translate the inbound X-10 commands in to something useful in the Vera.)

This link will take you to a transceiver :

Your other option might be to get a Firecracker and see if you can get it to work with the Vera using a USB serial converter. A quick Google of “x10 firecracker” turned up some places you can buy the firecracker for ~$5. It is unclear if it would work with Mochad, but I would be surprised if it didn’t.

I tried the new build and when using the following command, plm send_x10 A 1 3, there are no are commands right away, there is a long pause and then there is and are commands stating that the command was unsuccessful. Also my light did not respond, the off command also was unsuccessful plm send_x10 A 1 11.

Sorry about that, I threw that patch together quickly and didn’t have time to really test it. (Not that I can do a full test, but I can at least verify what is being sent.)

Turns out there were a couple more issues that I had not noticed previously. This time I verified things a bit more, so download the latest dev build and give it a shot. Here is output from the daemon when I ran the command (You can see this yourself by running the daemon with the “-f” and “-ddddd” arguments.) :

[TRACE] [7/2/2013 - 20:58:47] - CLIENT COMMAND : plm send_x10 A 1 11
[DEBUG] [7/2/2013 - 20:58:47] - Sending : 02636600
[TRACE] [7/2/2013 - 20:58:47] - To client : plm:003B,02,63 - PLM command success.
[DEBUG] [7/2/2013 - 20:58:47] - Sending : 02636380

Assuming I am following the documentation correctly, this should turn device A1 off. Based on your Houselinc log, A1 off looks like this :

2013-06-16 22:03:34,950 [HL] DEBUG - Sending X10 message: A1 Off
2013-06-16 22:03:34,950 [HL] TRACE - Sending X10 command: A1
2013-06-16 22:03:34,950 [HL] DEBUG - 02 63 66 00
2013-06-16 22:03:34,970 [3 ] DEBUG - Rx: PLM Ack, 02 63 66 00 06
2013-06-16 22:03:35,470 [HL] TRACE - Sending x10 command: AOff
2013-06-16 22:03:35,470 [HL] DEBUG - 02 63 63 80
2013-06-16 22:03:35,480 [3 ] DEBUG - Rx: PLM Ack, 02 63 63 80 06

It looks to me like we are doing the right thing now. So let me know if it works with a real device.

If it works, I can point out the down side of the implementation and we can discuss how to resolve it.

I have tried the new build with the daemon in listening mode and obtained the same results you did. Unfortunately the light did not respond. What I noticed, and I don’t know if it makes a difference, but the bytes sent by Altsteon are all together without spaces and those reported by houslinc have spaces between them. Could this be the last piece of the puzzle?

Hey scravot,

The output from both Altsteon and HouseLinc are binary values that are converted to text for human consumption. Using spaces between the byte is more of a style thing.

Unfortunately, if we are sending the same bytes that Houselinc is and the X-10 devices aren’t responding, then there is either some kind of timing issue, or something else that isn’t obvious.

I dug around in my garage and basement to see if I happened to have any X-10 gear that escaped my last cleaning binge. All I found was a motion sensor, which won’t do any good without a wireless bridge. So, I think the only way we are going to get X-10 support working is if someone with X-10 & Insteon gear that can program steps forward to get it going.

Sorry… I wish there was more I could do. :frowning:


I tried this over the weekend, with no luck either. I suspect that the daemon is now sending the commands too quickly back-to-back. Or that some other command could intervene in the queue.

If you’ll email me your mailing address I’ll mail you a couple X10 plugin modules. dougremoveme at parkercatremoveme dot orgremoveme minus all the 'removeme’s. No strings – if they help you figure this out, great; if not, you can throw them out as well as I can.


That’s cool. How would I go about editing the Daemon. I’m not a coder but sometimes I can figure things out. I could always try to make it work. Let me know what tools I need to edit the daemon etc. I have a PC. Thanks.

Have a look here for starters:

  • Garrett