Serial Protocol - RapidConnect : Configuration of Device Types

The Module provides facilities for the Host to define and configure the application ZigBee logical device type and IEEE functional device type as well as support for specific endpoints, clusters and attributes.

Device Type

The Host may issue the Device Type Write command to the Module in order to configure the IEEE functional device type.

The Module may be configured to behave as either a Full-Function Device (FFD) or Reduced-Function Device (RFD). An FFD has facilities for routing network messages, while an RFD may only join a network as a non-routing End Node.

Sleepy Devices

Sleepy Devices require a more in depth look. Sleepy device behaviour should be well understood before developing your solution.

If the Host configures the Module as an RFD, it may additionally configure the Module to serve as either a non-sleepy or sleepy end device, with the latter configuration serving to conserve power should the given device be battery powered or otherwise consumption-sensitive.

Sending a serial frame will wake up the Module if it is sleeping. The Module will then stay awake for 5 milliseconds so the Host will have to send its desired serial frame within this period. One way to ensure the Module is awake to receive a command is to send the same frame twice within one second of each other. The first frame will be used to wake up the Module and the second frame will be processed.

For sleepy devices, there are four additional parameters that control the operation of the device. The parameters are:

  • App Nap Duration
  • App Hibernate Duration
  • Non-Sleeping Poll Interval
  • Poll Fail Trigger Rejoin Duration

The flow chart in the following figure illustrates how the parameters are chosen in a sleepy device.

Sleepy Parameters Flow Chart

Version 1.2 of the Home Automation Public Profile introduces the Poll Control cluster. This cluster provides a way to make the Module responsive on the network for a specific amount of time. In other words, a sleeping device may mostly remain in a low power consumption mode, but will still be able to respond promptly when asynchronous communication is desired. This is accomplished by means of differing poll rates, which is the frequency of MAC data requests from child to parent.

The Poll Control cluster has two attributes (ShortPollInterval and LongPollInterval) that are used to alter the poll rate of the Module.  The sleepy write commands (Sleepy Parameters Write CMD and Sleepy Hibernate Duration Write CMD) can also alter the poll rate of the Module. Both the cluster attributes and the sleepy write commands are used to change the value of the App Hibernate Duration parameter. It is this parameter that primarily determines the sleepy behavior of the Module. The flow chart shown below illustrates how the App Hibernate Duration parameter interacts with the Poll Control cluster.

App Hibernate Duration Parameter/Poll Control Cluster Relationship

Managing when the Module is in Fast Poll Mode is the sole reason for having the Poll Control cluster. The flow chart above shows that the Module goes into this responsive mode at startup and when the server cluster’s attribute, Check-inInterval, indicates it is time to ask any client-side clusters bound to the server if Fast Poll Mode is desired.

Please note that calling the serial protocol commands Sleepy Parameters Write CMD or Sleepy Hibernate Duration Write CMD may alter the poll rate of the Module but will not affect the Poll Control cluster attributes.

ZigBee Logical Device Types

The ZigBee logical device types and corresponding IEEE functional device types are shown in the following table.

Device Types

ZigBee Logical Device Type

IEEE Functional Device Type

Coordinator

Full-Function Device, Non-Sleepy

Router

Full-Function Device, Non-Sleepy

End Device

Reduced-Function Device, Non-Sleepy

Sleepy End Device

Reduced-Function Device, Sleepy

It should be noted that coordinators and routers share the same IEEE functional device type. The ZigBee logical device type will be determined when the application is prompted to either Form a network (become a coordinator) or Join a network (become a router).

Endpoints and Clusters

The Host may issue the Add Endpoint command to the Module to configure application support for an endpoint and related clusters operating on that endpoint. The application will support up to 32 endpoints and up to 100 clusters total across all active endpoints.

When the Host adds a cluster for which the application already has preconfigured support (i.e. Basic, Identify, On/Off, Control4 Large Network Support, etc.), the application automatically adds all mandatory attributes associated with that cluster and enables default message processing for the added cluster.

For example, if the Host adds the On/Off server cluster to a given endpoint, the application will automatically add the mandatory On/Off attribute to that cluster. Furthermore, the application will process incoming messages directed to that cluster such that the Host is kept notified of any change of state relating to its mandatory attribute (i.e., the On/Off attribute). In the case of this example, the notification is done via the On/Off State Update command.

The application currently provides automated support for the following clusters:

  • Basic Server 

  • Identify Server/Client

  • Commissioning Server 

  • Time Server/Client 

  • Power Configuration Server 

  • Alarms Server 

  • On/Off Server/Client

  • Level Control Server/Client

  • Thermostat Server 

  • Thermostat UI Configuration Server 

  • Fan Control Server 

  • Doorlock Server 

  • Poll Control Server/Client 

  • IAS Zone Server 

  • IAS ACE Server 

  • IAS Warning Device Server 

  • Ballast Configuration Server

  • Groups Server/Client

  • Scenes Server/Client

  • OTA Upgrade Server/Client

  • Diagnostics Server 

  • Control4 Large Network Support Client

Attributes

After adding the desired endpoints and clusters, the Host may issue the Add Attributes to Cluster command to the Module in order to add support for attributes on the specified cluster.

The application will support up to 300 attributes in sum total across all clusters.

When the Host adds an attribute to a cluster, the application will initialize that attribute with a default value corresponding to its given Data Type, as described in the following table. Please note that some of the default values are also invalid. This is to indicate that the value is unknown; that is, not yet set by the Host.

The Host may also configure the given attribute with any valid value, by issuing the Attribute Write command. Furthermore, the Host may query the given attribute’s value by issuing the Attribute Request command.

Attribute Data Types and Default Values

Attribute Data Type

Default Value

Genera Data (8, 16, 24, 32, 40, 48, 56, 64-bit)

All zeros (i.e., 0x00, 0x0000, etc.)

String

Empty string

Boolean

False

Bitmap

All 0’s

Unsigned Integer (8, 16, 24, 32, 40, 48, 56, 64-bit)

All 1’s (i.e., 0xFF, 0xFFFF, etc.)

Signed Integer (8, 16, 24, 32, 40, 48, 56, 64-bit)

Mot significant bit set to 1 (i.e., 0x80, 0x8000, etc.)

Enumeration (8, 16-bit)

All 0’s


Attribute Reporting

This How-To Article will describe the process of enabling Attribute Reporting on your device

1) Attribute Report Passthru Control Frame

Frame definition can be found here.
Send Frame(can use serial log component) with PH:03, SH:26 and value 0x01(enabled) via RapidHA Desktop.


2) Binding

A binding defines a source node and an endpoint(from which the attribute is being reported) and a destination node and endpoint(to which the attribute is being reported), as well as the cluster on which the attributes exist. This binding can be done in one of two ways.

RapidHA Desktop Binding Component

This is the easiest way to set an attribute binding.

  1. Form a network and join your third party devices to the network
  2. In the Devices view, select the Source device in the Device Management Table (the device from which attributes are going to be reported from)
  3. Select the Cluster that the attribute is on
  4. Select the Destination device in the Binding/Unbinding table, and specify the endpoint on that device where the cluster exists to report attributes to
  5. Click the Bind button 
  6. Observe the ZDO Unicast frame that configures the binding in the Serial Log

Send a ZDO Unicast Message

You can also send the ZDO Unicast message yourself in the ZDO Message tab

Example ZDO Bind Request:

Dest Address: Node Id

CommandId: 21

Payload Example: C1 38 F0 00 00 46 24 00 01 14 FC 03 42 17 01 00 00 46 24 00 01

Decode of payload: 

Source EUI: C1 38 F0 00 00 46 24 00

Source Endpoint: 01

clusterID: 14 FC

mode: 03

Destination EUI: 42 17 0 00 00 46 24 00

Destination Endpoint: 01

3) Configure Attribute Reporting

To configure you must send a ZCL message to the source node to let the device know what attribute needs to be reported.


Example ZCL Message Configure Attribute Report:
Dest Address: Node Id
Source Endpoint: 01
Dest Endpoint: 01
Cluster Id: 0x0500 (IAS Cluster)
Frame Control: Profile Wide, Client to Server
Command Id: 06 (Configure Reporting)
Payload to setup Zone Status attribute (0x0002): 00 02 00 19 01 00 fe ff
Decode of payload: 
direction: 00
attribute id: 02 00 (Zone Status Attribute 0x0002)
attribute type: 19 (bitmap 16)
min report: 01 00
max report: FE FF

If the user does not see a response, the user may have to close and reopen the com port after this step. After step 3 , ZCL Pass through commands should now be seen on the host application


On This Page

In This Space