Getting started with device types?

@dlieberman can you please give more direction on the fingerprint values?

I am done testing, and now want to know what are acceptable values should I want my device to play well on this network. Please be specific with each type of fingerprint value (types, ranges of values, format, scope, …):

  • Endpoint
  • Profile
  • Device
  • Version
  • In-Clusters
  • Out-Clusters
  • None-Clusters

If certain fingerprint fields are not relevant to the smartthings hub/network/apis, then can you please edify us with some perspective as to what they are, and why they are on the IDE? (or where to find more information about them)?

I looked in the documentation and it says almost nothing about fingerprints.

I repeat, I am almost ready to go to production, and need to know this information.

Thank you,
Karl Miller

Thanks for more information about fingerprints

@karlmiller – The fingerprinting fields are specifically for Zigbee devices, so that we can properly identify them as they are being paired. What kind of device are you building? How is it connecting to SmartThings?

@dlieberman - It connects right now via a ThingShield.

Which brings up another question (still need the original question answered about what goes in each of those fingerprint fields and in what context):

How does one go about separating the prototyping part of the thingshield from the parts needed.  Is there a schematic for that?
How do I get those parts separately for building into a production device for manufacturing with a 2-layer PCB?

Thanks,
Karl

@karlmiller - Right, I wasn’t avoiding your question - but I wanted to better understand how you were connecting your device to SmartThings to determine who to bring in to best answer your questions. If you’re building an IP-connected device, for instance, the fingerprinting fields aren’t necessary at all.

To make sure that you get the right answers for your ThingShield-based device, I’ll ask @urman to join the conversation.

-d

A lot of the fingerprinting has to do with the ZigBee spec and how manufactured make their devices. ZigBee has Clusters, which is a group of settings, information, and commands for a bunch of different type of applications. So humidity has its own cluster, thermostats have their own cluster, switches and etc.

Mainly there are two types of cluster traffic (in or out). The ZigBee spec actually defines them as “server and client” Server, or In Clusters define information that the hub can speak to the device. Client, or Out Clusters define what the device itself supports. For example Over The Air updates (OTA) is client (out) cluster 0019. Using a combination of devices that have certain in/out clusters, we can define what type of device it is.

The devices manufacturer defines what it actually does and what clusters it uses. Same for the Z-Wave information. There are a preset description of what a device is capable of, which we match to the appropriate handler.

  • Endpoint - Endpoints are like network ports for ZigBee. They route specific cluster information and settings through specific endpoints
  • Profile - ZigBee defines the value of each profile. For example, ZigBee HA (Home Automation) is profile 0104.
  • Device - Mostly used for Z-Wave
  • Version - Also Mostly used for Z-Wave
  • In-Clusters - Clusters like Switch (0006) and Level Control (0008) go here.
  • Out-Clusters - Clusters like OTA (0019) or Time (000A) go here.
  • None-Clusters - Yet another Z-Wave one.

In the case of the shield. The only fingerprint you will be able to get is ThingShield. The reason is, the shield actually never changes. So the ZigBee part of it stays static, while the Arduino is the only change. The Arduino and ThingShield is great for prototyping, but if the Raw ZigBee module we program to is available on Digi-Key and the ZigBee specs are public.

http://zigbee.org/Standards/ZigBeeHomeAutomation/Overview.aspx

Here is also the ZigBee cluster library where the actions of clusters are defined.

http://www.zigbee.org/Products/ZigBeeClusterLibraryDownload.aspx

@urman - Thanks for the information. Am I understanding you correctly, that I would only require the ZICM357SP2-1 module wired up to an arduino to create a smartthing device that would behave just as the ThingShield does (using the SmartThings arduino library)?

On the fingerprint side, let’s use the example of my arduino + ZICM357SP2-1 and a relay + a reed switch as a garage door opener;
I see I don’t need to worry about the device, version and none-cluster fields.
I also see I would need to put 0104 in the Profile field.
Considering this device would only talk with the SmartThings hub, what values are going to be correct for this custom smartthings device for the following fields? :
Endpoint
In-Clusters
Out-Clusters

After doing that, am I restricted to certain device-types?

Thanks,
Karl

@karlmiller The ZICM357SP2-1 would have to have our firmware in order to use it like a shield.

There are two levels. The ZICM357SP2-1 firmware, which is Ember based and developed in C. The firmware for the shield (and multi/motion/presence) was developed by us and programmed onto them by our programming jig. This firmware defines the devices capabilities for fingerprinting.

The other level is during the pairing process, the device tells the hub its ZigBee information, which is then matched to a device handler. So the handler doesn’t define the devices ZigBee information, it can only read them to the proper device handler.

So since the shield has our firmware on it, right now it will always define as ThingShield.

What kind of development did you have in mind? If you wanted to take a project off of the breadboard, you will most likely need to get a development kit from one of the ZigBee capable platforms.

1 Like