Smartthings to Control4 Proof of Concept Video


(Patrick Stuart [@pstuart]) #1

Well, here it is…

A proof of concept video, where I can control a light via a Smartapp to a custom driver I wrote in LUA installed in a Control4 project.

Right now, the limitations are the local hubaction.

I can’t have it parse my entire project file from Control4, this is about 8 megs of XML data.

But I can get a device status by id and I can send commands to that device id, so what that means is…

If I know the device id, I can create a child devicetype for a switch or dimmer and then in Smartthings I can poll for the device status, on/off dimmer level, etc. and then send on, of or setlevel to my driver.

Anyway, enjoy the video, it is a major breakthrough for me… Now if we can just get the local hubaction to get more robust I could complete this integration…


Control4 Switches and Dimmers
(Chrisb) #2

Very cool @pstuart.

Am I correct in assuming that this is more-or-less an interface between a SmartThings setup and a Control4 setup? What I mean is that the SmartThings brains are talking to the Control4 brains and telling the Control4 brains to turn on a Control4 device?

Or is this SmartThings brains communicating directly to the Control4 device? Where you don’t need a Control4 setup, just individual Control4 devices?

I hope it’s the latter because:

http://www.control4.com/products/climate/C4-4SF120


(Ben Edwards) #3

We are adding that in an upcoming release. If only @adam could get some time!


#4

When you say ‘local hubaction’ do you mean a lower layer LAN socket hubaction vs the current RESTful hubaction?


(Geko) #5

Do tell us more about it. Phleeezzz… :smile:


#6

Doesn’t exist in the wild yet, but a method to allow for more control over raw TCP/UDP sockets vs current the HTTP RESTful interface that covers many common IoT devices such as Hue/Sonos/WeMo/TCP Lighting/etcetc…


(Geko) #7

I’m pretty sure some folks would beg on their knees for the raw socket access. :slight_smile: Ship it! :smile:


(Patrick Stuart [@pstuart]) #8

@chrisb
This is a psuedo interface between Smartthings talking to Control4 via a LUA driver I wrote to respond to HTTP GET requests on port 8088 and parse the response.

I am still working on getting Zigbee commands to work with Smartthings to the control4 devices, like the dimmer, switch, keypad, fan control, etc. This will require complete reverse engineering of their usage of zigbee, since it doesn’t seem to follow standards, even though they say they are HA certified, but this could turn around…

The API driver I wrote has the following commands:

-getAllDevices (gets an xml file of all devices in the Control4 project)

This is currently a huge response and the local hubaction GET can’t even handle it. BIG ISSUE!!!

-getDeviceInfo(int deviceId) (gets the current status of a device in the Control4 environment)
-getDeviceInfo(List deviceIds) (gets the current status of a list of devices)

-setDevice(int deviceId, string command, string value) (this sets a deviceId, command to the value provided)

Example Device 68 (a dimmer) can be turned on via command Power, value on, or can be set to a specific level via command Level, value 75%

Returns deviceID status.

-CustomAction(string Action)

This can send ANY action / command and internal control4 programming can be written off receiving this command.

So, this is how we can tie Smartthings mode’s to Control4 lighting scenes or custom programming.

So if mode change in Smartthings, send a GET request for /Mode/Night and then the control4 programming can trigger additional actions within the control4 world.

I can expand this further, but if a local hubaction is coming soon, then that is much easier to accomplish using port 5020 and turning Smartthings into a remote controller for Control4.


(Khaled Qari) #9

Any updates on this?


(Patrick Stuart [@pstuart]) #10

Yeah, not going to release it. SmartThings is too unreliable and lacks an official api for integration.