Card Access Relay Zigbee

Devices & Integrations Connected Things
1

All,

First post, be kind… I’m a Control4 user and developer, mainly on the IP side, not zigbee.

I have a ton of Control4 devices and am playing around with a Card Access Sensor Model WCS10A-2-ZP

I was able to get it to pair as a “Thing” surprisingly and am getting a bunch of zigbee messages.

For example this keeps repeating:

C25D 0001 02 02 0C40 00 0B6A 00 00 0000 00 01 080009000A00

I am way out of my depth on parsing this or figuring out where to go from here.

I just can’t believe I got it to pair…

This device has a thermostat, external thermistor support, 2 different sensors and a common.

Any help in trying to figure out where to go from here would be greatly appreciated.

Thanks!

2

I know I asked ST before about a Control4 thing. They have a closed system in terms of their version of Zigbee. At the time the person I was communicating with mentioned that they had sent a message to Control4 to ask about their system and whether they would share their data. Control4 kinda ignored the message.

I think you’re in for a LOT of trial and error here unfortunately.

3

Yeah, control4 isn’t closed as much as it is undocumented for public consumption…

They do adhere to the Zigbee HA profile so does Card Access.

It’s just a matter of me trying to understand the command sets to send and parse the response of the devices.

I already have a ST smartapp sending commands to Control4, that wasn’t hard. Next will be querying the undocumented SOAP API for C4 via ST to poll devices and status.

This might be the best way to interact with Control4 zigbee and other devices, but I was plesantly surprised the Card Access device responded.

4

The first 16 bits are the profile id (0xC25D), followed by 16 bits for the cluster id (0x0010), then two bytes for the source (0x02) and destination endpoint (0x02) ids, respectively. Then a bunch of junk that I don’t remember :wink:

Then, from the back: A variable length payload (0x080009000A00), the attribute id (0x01) and the ZCL command (0x00). The command (0x00) stands for “read attribute”.

Your biggest problem is that the profile id 0xC25D is manufacturer specific (anything greater than 0xC000 is). The ZigBee HA profile id is 0x0104.

You can still try to reverse engineer the manufacturer specific profile, but you’re pretty much on your own. Obviously, the manufacturer specific profiles are not documented :frowning:

5

Also, @urman might have some ideas. Looping him in.

6

Thanks @florianz that helped a ton. I think the better option will be to write a control4 driver that can be polled via HTTP and query a device list, by type and build virtual “things” for each of the devices in the control4 ecosystem. Then I can also use this driver to send commands to control4 to fire off custom programing, etc.

I don’t think it will be very practical to use the control4 zigbee pro devices in ST but more like how HUE works, in the fact that even those the bulbs are zigbee, the HUE hub is the relay point to the lights and to 3rd party drivers…

It will be a bigger task then I wanted, but basic integration of systems shouldn’t be too hard to accomplish.

Besides, Control4 does media, tv’s, AVR’s and much more through their proxy system then the current interface of tiles in ST. However, I really like the automation and geofencing / user idenities that ST has and could be used to trigger events in Control4.

Unless there is significant demand, I think I’ll abandon hopes to reverse engineer the zigbee commands and just use Control4 controllers and a driver to access the devices.

7

So, I’ve been doing some more research on this…

I get a catchall response:

C25C 0001 C5 C5 0C40 00 FA69 00 00 0000 33 00 6536372073612063342E776330203066643174383030300D0A

which has a payload of

e67 sa c4.wc0 0fd1t8000

This is broken down into this

xxx = sequence number

sa = ?

c4.wc0 = control4 command

0fd1t8000 is broken down like this

0 = unknown, never seems to change
X where
f = contact open
c = both closed
d = 2nd closed
e = 1st closed
b = reed closed (mag), rest open
a = read and 1 closed, 2 open
9 = reed and 2 closed, 1 open,
d1 = unknown possibly battery level?
t = temp?
80 = temp one reading in hex? 128 in dec?
00 = ext temp reading

The question is how in the world would one convert a Hex Temp reading to Farhenheit?

The best I can come up with is this:

Hex 80 is 128 dec
128 / 5 = 25.4 C ?
25.4 C = 78.08 F

But this means the temp reporting is way inaccurate?

Anyone have any clues?

8

Do you know what temp the device is reporting? I mean is it showing up in your Control4 setup or can you put another sensor in the same location so you can get a reading? It might help to know what the temp is supposed to showing.

9

Roughly 71-76 degrees, values range from dec 128-131

10

Is there an “effective range” of temps? Like: “Temp sensor good from -10 to 100 degrees F”

Maybe the 80 hex (if it’s that) is an absolute value from 00 to FF (or whatever) with 00 = lowest temp it can sense and FF = highest temp it can sense?

It’s a long shot… but I can’t think of anything else. Obviously 80 is slightly off and 128 is way off for straight F numbers, and you’d probably be dead from heat if those were straight C number, or frozen solid if those were straight K numbers.

11

yeah, I’m sure its somethinng like that @chrisb But that would mean it is way too inaccurate. Not really surprising…

Too bad I have a lot of these around the house. Wish ST would have a contact sensor beyond a magentic sensor that is zigbee. Plenty of 3rd party options…