* of intermediate devices to reach more distant ones.
* ZigBee is typically used in low data rate applications that require long battery life and secure networking. \n\n
* ZigBee has a defined rate of 250 kbit/s, best suited for intermittent data transmissions
- * from a sensor or input device. \n See http://www.zigbee.org for more information.
+ * from a sensor or input device. \n See http://www.zigbee.org for more information.\n\n
*
* @section CAPI_NETWORK_ZIGBEE_MODULE_FEATURE Related Features
* This API is related with the following features:\n
*
* More details on using features in your application can be found in the <a href="https://developer.tizen.org/development/getting-started/native-application/understanding-tizen-programming/application-filtering"><b>Feature List</b>.</a>
*
+ * @section CAPI_NETWORK_ZIGBEE_MODULE_EXAMPLE Example
+ * This section describes how to use Zigbee API.
*
* @subsection CAPI_NETWORK_ZIGBEE_MODULE_CREATE_NETWORK Create Network
* To run the Zigbee coordinator, first create an instance through the zb_create function.
* \#include <zigbee.h>
*
* @section CAPI_NETWORK_ZIGBEE_ZCL_MODULE_OVERVIEW Overview
- * This API set consists of ZCL access API
+ * The ZigBee Cluster Library (ZCL) is intended to act as a repository for cluster
+ * functionality that is developed by ZigBee and, as a consequence, it will be a
+ * working library with regular updates as new functionality is added. A developer
+ * constructing a new application profile should use the ZCL to find relevant cluster
+ * functionality that can be incorporated into the new profile so as not to "re-invent
+ * the wheel". This also allows ZigBee profiles to be developed with more of an
+ * object oriented style approach.
+ *
+ * @subsection CAPI_NETWORK_ZIGBEE_ZCL_MODULE_CLIENT_SERVER_MODEL Client/Server Model
+ * Throughout the ZCL, a client/server model is employed.\n\n
+ *
+ * A cluster is a related collection of commands and attributes, which together define
+ * an interface to specific functionality. Typically, the entity that stores the attributes
+ * of a cluster is referred to as the server of that cluster and an entity that affects or
+ * manipulates those attributes is referred to as the client of that cluster. However, if
+ * required, attributes may also be present on the client of a cluster.\n\n
+ *
+ * Commands that allow devices to manipulate attributes, e.g. in this document the
+ * read attribute (@ref zb_zcl_global_read_attr) or write attribute
+ * (@ref zb_zcl_global_write_attr) commands, are (typically)
+ * sent from a client device and received by the server device. Any response to those
+ * commands, e.g. in this document the read attribute response (@ref zb_zcl_global_rsp)
+ * or the write attribute response (@ref zb_zcl_global_rsp) commands,
+ * are sent from the server device and received by the client device.\n\n
+ *
+ * Conversely, the command that facilitates dynamic attribute reporting, i.e. the
+ * report attribute command (@ref zb_zcl_global_config_report) is (typically) sent from
+ * the server device (as typically this is where the attribute data itself is stored)
+ * and sent to the client device that has been bound to the server device.\n\n
+ *
+ * The clusters supported by an application object within an application profile are
+ * identified through the simple descriptor (@ref zb_zdo_simple_desc_req,
+ * @ref zb_zdo_simple_desc_rsp), specified on each active
+ * endpoint of a device. In the simple descriptor, the application input cluster list
+ * shall contain the list of server clusters supported on the device and the application
+ * output cluster list shall contain the list of client clusters supported on the device.
*
* @section CAPI_NETWORK_ZIGBEE_ZCL_MODULE_FEATURE Related Features
* This API is related with the following features:\n
*
* More details on using features in your application can be found in the <a href="https://developer.tizen.org/development/getting-started/native-application/understanding-tizen-programming/application-filtering"><b>Feature List</b>.</a>
*
+ * @since_tizen 4.0
+ *
* @{
*/
#include <zcl/zb_zcl_type.h>
* \#include <zigbee.h>
*
* @section CAPI_NETWORK_ZIGBEE_ZDO_MODULE_OVERVIEW Overview
- * This API set consists of ZDO access API
+ * The ZigBee Device Object (ZDO) is simply the application running
+ * on endpoint 0 in every ZigBee device. (Remember, application endpoints are numbered
+ * 1 through 240.)\n\n
+ *
+ * This application, ZDO, keeps track of the state of the ZigBee device on and off the
+ * network, and provides an interface to the ZigBee Device Profile (ZDP), a specialized
+ * Application Profile (with profile ID 0x0000) for discovering, configuring, and
+ * maintaining ZigBee devices and services on the network.\n\n
+ *
+ * ZDO not only interacts with APS, but also interacts directly with the network layer.
+ * ZDO controls the network layer, telling it when to form or join a network,
+ * and when to leave, and provides the application interface to network
+ * layer management services. For example, ZDO can be configured to continue attempting
+ * to join a network until it is successful, or until a user-specified number-of-retries has
+ * occurred before giving up, and informing the application of the join failure.\n\n
+ *
+ * The over-the-air Application Profile supported by ZDO, called the ZigBee Device Profile
+ * (ZDP), is no different than any other, and in most stacks is handled just like any other
+ * application object on an endpoint. ZDP services are separated into client and server.
+ * Client side services (also called requests), are always optional in ZigBee, but many of the
+ * server side ZDP services (also called responses), are mandatory.
+ * Nearly every service follows the same pattern when used. A client device (the node which
+ * is doing the asking) first makes a request. The server device then sends the response back
+ * to the client device. The cluster number for the response is exactly the same as the cluster
+ * number for the request, but with the high bit set. For example, the ZDP command IEEE_
+ * addr_req(@ref zb_zdo_ieee_addr_req) is cluster 0x0001,
+ * and IEEE_addr_rsp (@ref zb_zdo_addr_rsp) is cluster 0x8001.\n\n
+ *
+ * It doesn't matter how many hops the nodes are from each other. The nodes A and B could
+ * be 10 hops away from each other, and the ZDP request/response mechanism will work
+ * in exactly the same way, just as it does for applications sending data on an application
+ * endpoint.\n\n
+ *
+ * For sleeping devices, the parents of the device keep track of the IEEE and short address
+ * of the child, and will respond for them. However, all other information about the sleeping
+ * device, such as the list of active endpoints, are not recorded by the parent and must be
+ * retrieved directly from the devices themselves.
*
* @section CAPI_NETWORK_ZIGBEE_ZDO_MODULE_FEATURE Related Features
* This API is related with the following features:\n
*
* More details on using features in your application can be found in the <a href="https://developer.tizen.org/development/getting-started/native-application/understanding-tizen-programming/application-filtering"><b>Feature List</b>.</a>
*
+ * @since_tizen 4.0
+ *
* @{
*/
*/
int zb_neighbor_table_desc_get_relationship(
zb_zdo_neighbor_table_desc_h handle,
- unsigned char* releationship);
+ unsigned char* relationship);
/**
* @brief Gets Permit joining value from neighbor table list record
*
* @brief Zigbee alarm cluster commands
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_ALARM_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_ALARM_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_ALARM_CLUSTER_MODULE_OVERVIEW Overview
+ * Attributes and commands for sending alarm notifications and configuring alarm
+ * functionality.\n\n
+ * Alarm conditions and their respective alarm codes are described in individual
+ * clusters, along with an alarm mask field. Where not masked, alarm notifications
+ * are reported to subscribed targets using binding.\n\n
+ * Where an alarm table is implemented, all alarms, masked or otherwise, are
+ * recorded and may be retrieved on demand.\n\n
+ * Alarms may either reset automatically when the conditions that cause are no
+ * longer active, or may need to be explicitly reset.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee basic cluster commands
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_BASIC_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_BASIC_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_BASIC_CLUSTER_MODULE_OVERVIEW Overview
+ * Attributes and commands for determining basic information about a device,
+ * setting user device information such as location, enabling a device and resetting it
+ * to factory defaults. \n\n
+ * Note: Where a physical ZigBee node supports multiple endpoints it will often be
+ * the case that many of these settings will apply to the whole node, that is they are
+ * the same for every endpoint on the device. In such cases they can be implemented
+ * once for the node, and mapped to each endpoint.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee color control cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_COLOR_CONTROL_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_COLOR_CONTROL_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_COLOR_CONTROL_CLUSTER_MODULE_OVERVIEW Overview
+ * This cluster provides an interface for changing the color of a light. Color is
+ * specified according to the Commission Internationale de l'Eclairage (CIE)
+ * specification CIE 1931 Color Space, Color control is carried out in terms of
+ * x,y values, as defined by this specification.\n\n
+ * Additionally, color may optionally be controlled in terms of color temperature, or
+ * as hue and saturation values based on optionally variable RGB and W color
+ * points. It is recommended that the hue and saturation are interpreted according to
+ * the HSV (aka HSB) color model.\n\n
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee global commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_GLOBAL_COMMAND_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_GLOBAL_COMMAND_MODULE_HEADER Requied Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_GLOBAL_COMMAND_MODULE_OVERVIEW Overview
+ * Global command frames are used for manipulating attributes and other general
+ * tasks that are not specific to an individual cluster.
+ * The command frames defined in this section. \n\n
+ * Each command frame shall be constructed with the frame type sub-field of the frame
+ * control field set to 0b00.\n
+ * All clusters (server and client) shall support generation, reception and execution
+ * of the Default response command.\n\n
+ * Each cluster (server or client) that implements attributes shall support reception
+ * of, execution of, and response to all commands to discover, read, and write these
+ * attributes. However, if no attributes with structured types are supported, it is not
+ * required to support the structured read and write commands.\n\n
+ * Implementation of commands to report, configure reporting of, and read reporting
+ * configuration of attributes is only mandatory if the cluster has attributes whose
+ * reportability is mandatory.\n\n
+ * Generation of these commands is application dependent\n
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee group cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_GROUP_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_GROUP_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_GROUP_CLUSTER_MODULE_OVERVIEW Overview
+ * The ZigBee specification provides the capability for group addressing. That is,
+ * any endpoint on any device may be assigned to one or more groups, each labeled
+ * with a 16-bit identifier (0x0001 . 0xfff7), which acts for all intents and purposes
+ * like a network address. Once a group is established, frames, sent having a DstAddrMode
+ * of 0x01, denoting group addressing, will be delivered to every endpoint assigned to
+ * the group address named in the DstAddr parameter of the outgoing send request
+ * on every device in the network for which there are such endpoints.\n\n
+ * Management of group membership on each device and endpoint is implemented
+ * by the APS, but the over-the-air messages that allow for remote management and
+ * commissioning of groups are defined here in the cluster library on the theory that,
+ * while the basic group addressing facilities are integral to the operation of the
+ * stack, not every device will need or want to implement this management cluster.\n\n
+ * Furthermore, the placement of the management commands here allows developers
+ * of proprietary profiles to avoid implementing the library cluster but still exploit
+ * group addressing.\n
+ * Commands are defined here for discovering the group membership of a device,
+ * adding a group, removing a group and removing all groups.\n\n
+ * Finally, the group cluster allows application entities to store a name string for each
+ * group to which they are assigned and to report that name string in response to a
+ * client request.\n\n
+ * Note that configuration of group addresses for outgoing commands is achieved
+ * using the APS binding mechanisms, and is not part of this cluster.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee IAS zone cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_IAS_ZONE_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_IAS_ZONE_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_IAS_ZONE_CLUSTER_MODULE_OVERVIEW Overview
+ * The IAS Zone cluster defines an interface to the functionality of an IAS security
+ * zone device. IAS Zone supports up to two alarm types per zone, low battery
+ * reports and supervision of the IAS network.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee identity cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_IDENTITY_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_IDENTITY_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_IDENTITY_CLUSTER_MODULE_OVERVIEW Overview
+ *
+ * Attributes and commands to put a device into an Identification mode (e.g. flashing
+ * a light), that indicates to an observer . e.g. an installer - which of several devices
+ * it is, also to request any device that is identifying itself to respond to the initiator.\n\n
+ * Note that this cluster cannot be disabled, and remains functional regardless of the
+ * setting of the DeviceEnable attribute in the Basic cluster.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee level control cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_LEVEL_CONTROL_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_LEVEL_CONTROL_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_LEVEL_CONTROL_CLUSTER_MODULE_OVERVIEW Overview
+ * This cluster provides an interface for controlling a characteristic of a device that
+ * can be set to a level, for example the brightness of a light, the degree of closure of
+ * a door, or the power output of a heater.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee on/off cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_ON_OFF_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_ON_OFF_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_ON_OFF_CLUSTER_MODULE_OVERVIEW
+ * Attributes and commands for switching devices between 'On' and 'Off' states.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee poll control cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_POLL_CONTROL_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_POLL_CONTROL_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_POLL_CONTROL_CLUSTER_MODULE_OVERVIEW Overview
+ * This cluster provides a mechanism for the management of an end device's MAC
+ * Data Request rate. For the purposes of this cluster, the term "poll" always refers to
+ * the sending of a MAC Data Request from the end device to the end device's parent.
+ * This cluster can be used for instance by a configuration device to make an end
+ * device responsive for a certain period of time so that the device can be managed
+ * by the controller.\n\n
+ * This cluster is composed of a client and server. The end device implements the
+ * server side of this cluster. The server side contains several attributes related to the
+ * MAC Data Request rate for the device. The client side implements commands
+ * used to manage the poll rate for the device.\n\n
+ * The end device which implements the server side of this cluster sends a query to
+ * the client on a predetermined interval to see if the client would like to manage the
+ * poll period of the end device in question. When the client side of the cluster hears
+ * from the server it has the opportunity to respond with configuration data to either
+ * put the end device in a short poll mode or let the end device continue to function
+ * normally.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee scene cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_SCENE_CLUSTER_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_SCENE_CLUSTER_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_SCENE_CLUSTER_MODULE_OVERVIEW Overview
+ * The scenes cluster provides attributes and commands for setting up and recalling
+ * scenes. Each scene corresponds to a set of stored values of specified attributes for
+ * one or more clusters on the same end point as the scenes cluster.\n\n
+ * In most cases scenes are associated with a particular group ID. Scenes may also
+ * exist without a group, in which case the value 0x0000 replaces the group ID. Note
+ * that extra care is required in these cases to avoid a scene ID collision, and that
+ * commands related to scenes without a group may only be unicast, i.e.: they may
+ *not be multicast or broadcast.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee thermostat cluster commands.
*
- * @section CAPI_NETWORK_ZIGBEE_ZCL_THERMOSTAT_MODULE_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_THERMOSTAT_MODULE_HEADER Required Header
* \#include <zigbee.h>
*
+ * @section CAPI_NETWORK_ZIGBEE_ZCL_THERMOSTAT_MODULE_OVERVIEW Overview
+ * This cluster provides an interface to the functionality of a thermostat.
+ *
* @since_tizen 4.0
*
* @{
*
* @brief Zigbee provides API for Binding.
*
- * @section CAPI_NETWORK_ZIGBEE_ZDO_BINDING_MANAGER_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZDO_BINDING_MANAGER_HEADER Required Header
* \#include <zigbee.h>
*
* @section CAPI_NETWORK_ZIGBEE_ZDO_BINDING_MANAGER_OVERVIEW Overview
- * This API set consists of ZDP device discovery API
+ * Binding provides a mechanism for attaching an endpoint on one node to one or more
+ * endpoints on another node. Binding can even be destined for groups of nodes. Then,
+ * when using APSDE-DATA.request, simply use the "indirect" addressing mode, and the
+ * request will be sent to each endpoint or group listed in the local binding table.\n\n
+ * The binding table is smart, and keeps track of both the short (16-bit NwkAddr) and long
+ * (IEEE) address of a node. If a destination device has changed its short address (either
+ * due to a ZigBee End-Device moving from one parent to another in ZigBee stack profile
+ * 0x01, or due to a address conflict in ZigBee Pro), the binding table entry is updated
+ * automatically to point to that new address.\n\n
*
* @{
*/
*
* @brief Zigbee provides API for Device Discovery.
*
- * @section CAPI_NETWORK_ZIGBEE_ZDO_DEVICE_DISCOVERY_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZDO_DEVICE_DISCOVERY_HEADER Required Header
* \#include <zigbee.h>
*
* @section CAPI_NETWORK_ZIGBEE_ZDO_DEVICE_DISCOVERY_OVERVIEW Overview
- * This API set consists of ZDP device discovery API
+ * The ZigBee Device Profile (ZDP) contains a set of commands for discovering various
+ * aspects about nodes in the network. The ZigBee specification calls these "device
+ * discovery services," which can be confusing because endpoints contain device IDs which
+ * really describe individual ZigBee applications running in that node. So, when you see
+ * ZDP Device Discovery, think node-wide (not application/endpoint specific) services.\n\n
+ *
+ * Device discovery services have a few things in common:\n\n
+ *
+ * - They provide additional information about a node.
+ * - They are all optional from the client side, but some server side processing is
+ * mandatory (a common subset among all ZigBee devices).
+ * - They are node-wide, and do not represent any particular application, or
+ * Application Profile residing on an endpoint in the node.\n\n
+ *
+ * The ZDP device discovery services are listed below in thi section. Notice that all the
+ * ZDP services on the client side are optional. ZigBee does not require that a node be able
+ * to send NWK_addr_req , for example. But on the server side of this equation (a node
+ * receiving a NWK_addr_req and responding to it), the ZDP service is mandatory.
+ *
+ * @since_tizen 4.0
*
* @{
*/
*
* @brief Zigbee provides API for Network Management.
*
- * @section CAPI_NETWORK_ZIGBEE_ZDO_NETWORK_MANAGER_HEADER Header
+ * @section CAPI_NETWORK_ZIGBEE_ZDO_NETWORK_MANAGER_HEADER Required Header
* \#include <zigbee.h>
*
* @section CAPI_NETWORK_ZIGBEE_ZDO_NETWORK_MANAGER_OVERVIEW Overview
- * This API set consists of ZDP network manager API
+ * The Network Management services are really handy optional services used for reading the
+ * various tables contained within ZigBee nodes, and to request certain common actions
+ *
+ * @since_tizen 4.0
*
* @{
*/
projects / platform / core / api / zigbee.git / commitdiff