SmartThings Controls X10 Switch -- Demo


(Geko) #1

Here’s a preview of my X10 integration with SmartThings:

Raw TCP Socket Communications with sendHubCommand()
Is there an app for bridging x10 remote to ST?
Are X10 devices supported
X10 Bridge is Released [Obsolete]
Is there an app for bridging x10 remote to ST?
(Convinced ST will never be unbroken…) #2

Wait a minute… you’re doing this just via the transceiver?! No PLM.

(Edward Pope) #3

Yes, I am confused as well. What are you using to send commands to the X-10 system?

(Geko) #4

I use CM19A RF transceiver to send commands to TM751 shown in the demo, but it will also work with CM15A which can send X10 power line commands directly.

(Convinced ST will never be unbroken…) #5

So SmartThings is connecting to this via a PC or other device communicating with USB?

Throw us a bone here.

(Geko) #6

Yes, you got it :smile: I’m using Mochad X10 gateway running on a Linux box.

(Convinced ST will never be unbroken…) #7

LOL… I am not sure I would describe that as an x10/SmartThings integration, but I would like to see an example of your call to sendHubCommand. Specifically if a string like the one below could be received (note the trailing return).


(Geko) #8

Why not? SmartThings uses gateways to talk to many things, for example Nest, WeMo, DCS alarm panels, etc. Those are not “integrations”? What about IFTTT?

(Convinced ST will never be unbroken…) #9

I meant no offense; I would just categorize it as a bridge.

Now what about an example of that TCP call to sendHubCommand? (c;

(Geko) #10

None taken :slight_smile: Yes, it is a bridge (the is literally called “X10 Bridge”). And a bridge is a legitimate way of integrating two systems. :smile:

WRT your example, I don’t see a problem as long as it’s ASCII. The mochad command has a terminating carriage return and it works. I have not tried sending binary data yet though.

(Geko) #11

Oh… and one more thought. Have you tried terminating your command with '\r\n'? Some servers are very picky about line termination.

(Convinced ST will never be unbroken…) #12

yes… this is working to Global Cache iTach gateway:

sendHubCommand(new physicalgraph.device.HubAction("""$theCommandString\r\nHOST: $ip\r\n\r\n""", physicalgraph.device.Protocol.LAN, "${deviceNetworkId}"))

(Geko) #13

Sweet! I hoped it would. :slight_smile: Now, correct me if I’m wrong, but I don’t the "HOST: ..." is part of the iTach protocol. Why do you need it there?

(Convinced ST will never be unbroken…) #14

Cause I am specifying the ip:port there and not in deviceNetworkId? I figured out what I am using via the braille method.

(Geko) #15

So what’s wrong with deviceNetworkId? You pass it in the third argument anyway. It works for me.

(Convinced ST will never be unbroken…) #16

I am passing ‘1234’ with it (meaningless). I was under the impression sendHubCommand required that param (even if it was nonsense), but after testing I see that it isn’t (lot of misinfo floating about).

I just didn’t want to bother with the hex conversion, however I will when I build my multi-A/V system device type. (c;

(Geko) #17

That’s fine, but I believe that “HOST: …” is being sent to iTach, which may be harmless in this particular case, but is generally undesirable.

(Convinced ST will never be unbroken…) #18

Yeah… NC is showing it is. Ok… I’ll pull that and use deviceNetworkId.

(Patrick Stuart [@pstuart]) #19

So how are you specifying a port? In the DNI or the ip var?

(Convinced ST will never be unbroken…) #20

I was setting ip to “”. It has always worked, but I was always sending to an http server. So now I’ll just pop ‘0A000029:1386’ into the DNI and lose the HOST param.

Seems to work fine.