@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.