Control4 Keypad Zigbee Driver

Devices & Integrations
1

So, was able to pair one of my Control4 2 button Keypads via hub and zigbee.

However, all the thing does is send back catchall: commands.

Given the fact that I am sure Control4 doesn’t want to share the details of the device, anyone with zigbee parsing experience want to help figure this out?

This is what I got when parsing the catchall:

2:48:25 PM: trace SmartShield(clusterId: 0x0001, command: 0x35, data: [0x66, 0x64, 0x35, 0x20, 0x73, 0x61, 0x20, 0x63, 0x34, 0x2e, 0x6b, 0x70, 0x2e, 0x63, 0x63, 0x20, 0x30, 0x32, 0x20, 0x30, 0x31, 0x0d, 0x0a], destinationEndpoint: 0xc5, direction: 0x00, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0xc25c, senderShortId: 0xb1b5, sourceEndpoint: 0xc5, text: null)

2:48:24 PM: trace SmartShield(clusterId: 0x0001, command: 0x35, data: [0x66, 0x64, 0x34, 0x20, 0x73, 0x61, 0x20, 0x63, 0x34, 0x2e, 0x6b, 0x70, 0x2e, 0x62, 0x63, 0x20, 0x30, 0x32, 0x0d, 0x0a], destinationEndpoint: 0xc5, direction: 0x00, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0xc25c, senderShortId: 0xb1b5, sourceEndpoint: 0xc5, text: null)

2:48:24 PM: trace SmartShield(clusterId: 0x0001, command: 0x35, data: [0x66, 0x64, 0x33, 0x20, 0x73, 0x61, 0x20, 0x63, 0x34, 0x2e, 0x6b, 0x70, 0x2e, 0x62, 0x62, 0x20, 0x30, 0x32, 0x0d, 0x0a], destinationEndpoint: 0xc5, direction: 0x00, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0xc25c, senderShortId: 0xb1b5, sourceEndpoint: 0xc5, text: null)

2:48:22 PM: trace SmartShield(clusterId: 0x0001, command: 0x0a, data: [0x07, 0x00, 0x42, 0x1b, 0x63, 0x34, 0x3a, 0x63, 0x6f, 0x6e, 0x74, 0x72, 0x6f, 0x6c, 0x34, 0x5f, 0x6b, 0x65, 0x79, 0x70, 0x61, 0x64, 0x3a, 0x43, 0x34, 0x2d, 0x4b, 0x50, 0x32, 0x2d, 0x5a, 0x04, 0x00, 0x42, 0x08, 0x30, 0x33, 0x2e, 0x32, 0x32, 0x2e, 0x34, 0x31, 0x05, 0x00, 0x20, 0x05, 0x06, 0x00, 0x21, 0x24, 0x00], destinationEndpoint: 0x02, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0xc25d, senderShortId: 0xb1b5, sourceEndpoint: 0x02, text: null)

2:48:20 PM: trace SmartShield(clusterId: 0x0001, command: 0x35, data: [0x66, 0x64, 0x32, 0x20, 0x73, 0x61, 0x20, 0x63, 0x34, 0x2e, 0x6b, 0x70, 0x2e, 0x63, 0x63, 0x20, 0x30, 0x30, 0x20, 0x30, 0x31, 0x0d, 0x0a], destinationEndpoint: 0xc5, direction: 0x00, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0xc25c, senderShortId: 0xb1b5, sourceEndpoint: 0xc5, text: null)

2:48:19 PM: trace SmartShield(clusterId: 0x0001, command: 0x35, data: [0x66, 0x64, 0x31, 0x20, 0x73, 0x61, 0x20, 0x63, 0x34, 0x2e, 0x6b, 0x70, 0x2e, 0x62, 0x63, 0x20, 0x30, 0x30, 0x0d, 0x0a], destinationEndpoint: 0xc5, direction: 0x00, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0xc25c, senderShortId: 0xb1b5, sourceEndpoint: 0xc5, text: null)

2:48:18 PM: trace SmartShield(clusterId: 0x0001, command: 0x35, data: [0x66, 0x64, 0x30, 0x20, 0x73, 0x61, 0x20, 0x63, 0x34, 0x2e, 0x6b, 0x70, 0x2e, 0x62, 0x62, 0x20, 0x30, 0x30, 0x0d, 0x0a], destinationEndpoint: 0xc5, direction: 0x00, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0xc25c, senderShortId: 0xb1b5, sourceEndpoint: 0xc5, text: null)

2:47:19 PM: trace SmartShield(clusterId: 0x0001, command: 0x0a, data: [0x12, 0x00, 0x41, 0x02, 0x00, 0x00, 0x13, 0x00, 0x28, 0xc2, 0x00, 0x00, 0x20, 0x02, 0x01, 0x00, 0x21, 0x0a, 0x00, 0x02, 0x00, 0x21, 0x2c, 0x01, 0x03, 0x00, 0x20, 0x00, 0x0b, 0x00, 0x21, 0x2c, 0x01, 0x0c, 0x00, 0x20, 0x14, 0x13, 0x00, 0x28, 0xc2, 0x14, 0x00, 0x20, 0xff, 0x00, 0x00, 0x20, 0x02], destinationEndpoint: 0x02, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0c40, profileId: 0xc25d, senderShortId: 0xb1b5, sourceEndpoint: 0x02, text: null)

I am seeing that presses on the top and bottom button are being sent, and there is a polling event firing, but beyond that, don’t know where to go from here.

Any help would be greatly appreciated.

2 Likes
2

Have you tried putting:

zigbee.parse(description)?.text

in your parse routine and see what it returns?

I am just a new so am not sure exactly what that function does. But in my custom device type that returns the clear text that I send from amy arduino

1 Like
3

So the direct status from the device is

catchall: C25D 0001 02 02 0C40 00 7D47 00 00 0000 0A 01 0700421B63343A636F6E74726F6C345F6B65797061643A43342D4B50322D5A0400420830332E32322E3431050020050600212600

And if I convert

0700421B63343A636F6E74726F6C345F6B65797061643A43342D4B50322D5A0400420830332E32322E3431050020050600212600

from Hex to Ascii, I get

a�Bec4:control4_keypad:C4-KP2-Z�B03.22.41� �!&�

Which is a good reply… Not exactly how to convert this in groovy, but it appears this payload “data” is what I am looking for.

1 Like
4

Ah sick, I’ve been trying to get hands on with Control4 stuff. Since its from a dealer only it hasn’t been requested much (5-6 people). Which is too bad they don’t sell it more publicly.

Whats also a shame is it looks like they are using their entire own profile.

catchall: C25D 0001 02 02 0C40 00 7D47 00 00 0000 0A 01 0700421B63343A636F6E74726F6C345F6B65797061643A43342D4B50322D5A0400420830332E32322E3431050020050600212600

C25D = Manufacture Specific Profile, probably control4’s. We use HA (Home Automation)
0001 = Cluster 0001. In normal ZigBee this is Power Configuration, but it doesn’t look like thats what they are using it for
02 = Source Endpoint ID
02 = Destination Endpoint ID
0C40 = Special Options (not sure what)
00 = ??
7D47 = Network ID
00 = Cluster Specific (no) Probably because the entire profile is Manufacture Specific. Same for the next.
00 = Manufacture specific (no)
000A = Report Attribtue
01 = Pretty sure this means direction (to the hub)
Rest of it = Payload.

5

So. What are our options. You up for the challenge? I have access to control4 logging of ZigBee devices and how the whole system works. I was told they do conform to the ha profile but use ZigBee pro. What ever that means.

I have keypads, dimmers, switches, and much more that use ZigBee.

The cool thing is they are so easy to acquire on eBay. I would think this would be a fun project but my knowledge on ZigBee is very weak.

Any help would be greatly appreciated.

6

Ya screw it, I’m up for it. I can’t promise a lot of time right now, but I’m up for it.

If they do conform to the HA standard than that will make things easier as its a public standard. I say we start with the switch! Pair that sucker up!

7

Ok, sending you a pm to work through the logisitics…

8

Anything become of this project? Asking for a friend. :slight_smile:

9

Making slow… slow progress. @urman hasn’t been able to help much, think he’s a bit busy.

I have the data parsing from the catchall polls to see what is going on with the device.

I can get a response with a sattr command but nothing off a wattr or st cmd.

I know the payload commands for turning the dimmer on/off and set level, but can’t seem to figure out how the HA profile functionality works.

I’m not a zigbee expert, was hoping urman or someone else at ST could help on that angle…

However, last night I got the start of an API control4 driver working which creates a REST API in Control4 to get all devices, get a device status, and send device commands which should make it very possible to populate ST with all the “Things” from control4 and create the simple interface to manage status and control the devices.

Anyway, would love to figure out the zigbee side, but fustrated with lack of documentation, knowledge, expertise, etc.

10

Hopefully @urman will have more time to look at this and maybe also @doug-st - I would like to see if we could do anything cool between Control4 and SmartThings - even it was only to trigger mode changes and hello, home phrases.

11

That would be easy, assuming the control4 person has the ability to install a driver. Driver install is dealer only and requires composerPro.

I’m trying to avoid needing to install a driver but without raw sockets or at least the ability to send a SOAP request XML with a null byte at the end of it to port 5020 I can’t do anything from Smartthings end.

I have to write a driver in Control4 to receive the API calls and parse them…

If someone can get me a socket connection with simple responses using a hubaction local request, then this could work…

12

@JohnR

Looping you in here to discuss in a more appropriate thread…

def getClusters() {

"zdo active 0x${device.deviceNetworkId}"

}

This didn’t do anything… Not sure where to go from here…

John, have you already tried this with a Control4 device? I don’t want to beat a dead horse…

13

@JohnR and @urman

Ok, so I found that my Control4 controller has a zserver port open on 7900. I launched a raw socket connection to it and viola…

All the sending of commands to and from the zigbee mesh…

https://dl.dropboxusercontent.com/u/1401728/zserver-port7900-raw%20log.txt

Not sure if anyone can make heads or tails out of this. However, what did occur during this was me setting a dimmer to 75% and off a couple times in the Control4 Flash app.

So somewhere in there is the raw info sent to the dimmer…

Anyone want to take a stab at interpreting this raw zigbee data?

14

I didn’t get a chance to try the command yet. I don’t have any Control 4 devices. My plan is to get the command working with generic ZigBee HA devices and then let you run it against your control 4 devices and share the results.

15

Can you send commands to this port as well or only monitor? Do you know what any of your deviceIDs are in the c4 system? I imagine it would map to the ZigBee NodeIDs 0-0xFFFE(65534).

16

@doug

I don’t know if you can send commands directly to 7900, but I can via LUA in a driver using C4’s api for sure.

I can get a list of all my deviceID’s in ssh using zman no problem.

17

@Pstuart I noticed today while I was creating a custom device type that ZigBee end points and cluster configurations are visible in the Logs section under the developer tools. This happens when the device first joins the hub and we could use it to get an understanding of your device. Take a look at the 8th line down in the attached screen shot. You will see (ep_cnt:3, ep:01 02 03) this is telling us this device has 3 end points and their numbers are 1,2,3. The next three line above this line list out the details for each end point. If I can get this screen shot or your device when it binds to the network It will give us a list of the clusters it supports. I think you will have to delete your device from the SmartThings hub and restore it to factory settings. Then open this log file and go through the join process. Just as a heads up my device didn’t always report its end nodes i had to do this process several times to get it to work.

DeviceJoin.png715×425 29.3 KB

18

thing-ss.png813×387 28.7 KB

Ok, got same thing ep:01 c4 c5 c6

19

Also, figured out that the getClusters command:

"zdo active 0x${device.deviceNetworkId}"

Does return in the log, but not of the device the same thing…

see attached…

thing-ss2.png852×510 33.1 KB

20

Okay now we are getting somewhere, here is a break down of end point 01: (All numbers are Hex)

765×27 5.27 KB

01 = End Point number
0104 = Profile Number: Home Automation profile
0101 = Device Type: Dimmable Light
00 = Version: 00
07 = In Clusters: The next 7 numbers are inbound clusters (server Clusters)
0000 = Basic
0003 = Identify
0004 = Groups
0005 = Scenes
0006 = On/Off
0008 = Level Control
000A = Time
00 = out Clusters: No out clusters (client Clusters)

The other three end points C4 C5 C6 all have private profiles and their cluster numbers don’t tell us much.

It looks like this is a Light or powered plug with the ability to dim. The two clusters to focus on would be 0x0006 and 0x0008 on endpoint 0x01. Send cluster 0x0006 commands to end point 0x01 to turn the device on or off as well as poll the device and see if it is on or off. Send cluster 0x0008 commands to end point 0x01 to set or query the brightness of this device. The Phillips Hue (ZigBee HA) sample device type has examples of how to send to both of these clusters you should be able to modify it and you will be good to go.

I’m curious why this device has a Time cluster???