Modules#
EmberBeaconClassificationParams
Ember Common Data Types#
See ember-types.h for source code.
Miscellaneous Ember Types#
Type of Ember software version.
EmberReleaseTypeStruct Data that relates release type to the correct string.
EmberReleaseTypeStruct Data that relates release type to the correct string.
EmberReleaseTypeStruct Data that relates release type to the correct string.
EmberReleaseTypeStruct Data that relates release type to the correct string.
16-bit ZigBee network address.
802.15.4 PAN ID.
A structure containing the version information.
EmberReleaseTypeStruct Data that relates release type to the correct string.
Size of EUI64 (an IEEE address) in bytes (8).
Size of an extended PAN identifier in bytes (8).
Size of an encryption key in bytes (16).
Size of Implicit Certificates used for Certificate-based Key Exchange(CBKE).
Size of Public Keys used in Elliptical Cryptography ECMQV algorithms.
Size of Private Keys used in Elliptical Cryptography ECMQV algorithms.
Size of the SMAC used in Elliptical Cryptography ECMQV algorithms.
Size of the DSA signature used in Elliptical Cryptography Digital Signature Algorithms.
The size of AES-128 MMO hash is 16-bytes. This is defined in the core. ZigBee specification.
Size of Implicit Certificates used for Certificate Based Key Exchange using the ECC283K1 curve in bytes.
Size of Public Keys used in SECT283k1 Elliptical Cryptography ECMQV algorithms.
Size of Private Keys used SECT283k1 in Elliptical Cryptography ECMQV algorithms.
Size of the DSA signature used in SECT283k1 Elliptical Cryptography Digital Signature Algorithms.
Return type for Ember functions.
EUI 64-bit ID (an IEEE address).
The maximum 802.15.4 channel number is 26.
The minimum 2.4GHz 802.15.4 channel number is 11.
The minimum SubGhz channel number is 0.
The SubGhz scan duration is 5.
There are sixteen 802.15.4 channels.
A bitmask to scan all 2.4 GHz 802.15.4 channels.
The maximum channels per page are 27 page bits 31...27, channel bits 26...0.
Sub-GHz channel bitmasks for pages 28, 30, 31.
The maximum SubGhz channel number on pages 28, 30, 31 is 26.
SubGhz channel bitmasks for page 29.
The maximum SubGhz channel number on page 29 is 8.
The minimum SubGhz page number is 28.
The maximum SubGhz page number is 31.
A bitmask for the channel page within a channel mask.
A page-channel mask for a given page and channel mask.
A page-channel mask for a given page and channel.
The network ID of the coordinator in a ZigBee network is 0x0000.
A distinguished network ID that will never be assigned to any node. It is used to indicate the absence of a node ID.
The channel page value used to indicate just the 2.4GHz channels.
A distinguished EUI64 that is commonly used to indicate an invalid EUI64.
A distinguished binding index used to indicate the absence of a binding.
A distinguished network ID that will never be assigned to any node.
A distinguished network ID that will never be assigned to any node. This value is returned when getting the remote node ID from the binding table and the given binding table index refers to a multicast binding entry.
A distinguished network ID that will never be assigned to any node. This value is used when getting the remote node ID from the address or binding tables. It indicates that the address or binding table entry is currently in use but the node ID corresponding to the EUI64 in the table is currently unknown.
A distinguished network ID that will never be assigned to any node. This value is used when getting the remote node ID from the address or binding tables. It indicates that the address or binding table entry is currently in use and network address discovery is underway.
A distinguished address table index used to indicate the absence of an address table entry.
The endpoint where the ZigBee Device Object (ZDO) resides.
The broadcast endpoint, as defined in the ZigBee spec.
The profile ID used by the ZigBee Device Object (ZDO).
The profile ID used to address all the public profiles.
The maximum value for a profile ID in the standard profile range.
The broadcast table entry timeout, which specifies, in quarter seconds, how long an entry persists in the local device's broadcast table.
Ember's Manufacturer ID.
An invalid network index.
Use Ember's default duty cycle limit configurations.
ZigBee Broadcast Addresses#
ZigBee specifies three different broadcast addresses that reach different collections of nodes. Broadcasts are normally sent only to routers. Broadcasts can also be forwarded to end devices, either all of them or only those that do not sleep. Broadcasting to end devices is both significantly more resource-intensive and significantly less reliable than broadcasting to routers.
Ember Concentrator Types#
To configure non trust center node to assume a concentrator type of the trust center it join to, until it receive many-to-one route request from the trust center. For the trust center node, concentrator type is configured from the concentrator plugin. The stack by default assumes trust center be a low RAM concentrator that make other devices send route record to the trust center even without receiving a many-to-one route request. The assumed concentrator type can be changed by setting appropriate value to emberAssumedTrustCenterConcentratorType.
The decision made by the Trust Center when a node attempts to join.
The Status of the Update Device message sent to the Trust Center. The device may have joined or rejoined insecurely, rejoined securely, or left. MAC Security has been deprecated and therefore there is no secure join.
Notes the last rejoin reason.
Defines the lists of clusters that must be provided for each endpoint.
Either marks an event as inactive or specifies the units for the event execution time.
The type of method used for joining.
Defines the events reported to the application by the emberCounterHandler().
txPowerModes for emberSetTxPowerMode and mfglibSetPower#
The application should call emberSetTxPowerMode() with the txPowerMode parameter set to this value to disable all power mode options, resulting in normal power mode and bi-directional RF transmitter output.
The application should call emberSetTxPowerMode() with the txPowerMode parameter set to this value to enable boost power mode.
The application should call emberSetTxPowerMode() with the txPowerMode parameter set to this value to enable the alternate transmitter output.
The application should call emberSetTxPowerMode() with the txPowerMode parameter set to this value to enable both boost mode and the alternate transmitter output.
Counters Request Definitions#
This is the Initial Security Bitmask that controls the use of various security features.
This is the Extended Security Bitmask that controls the use of various extended security features.
This is the Current Security Bitmask that details the use of various security features.
This bitmask describes the presence of fields within the EmberKeyStruct.
This denotes the type of security key.
This denotes the status of an attempt to establish a key with another device.
This enumeration determines whether or not a Trust Center answers trust center link key requests.
This enumeration determines whether or not a Trust Center answers app link key requests.
This is a ZigBee application profile ID that has been assigned to Ember Corporation.
The types of MAC passthrough messages that an application may receive. This is a bitmask.
This function allows access to the actual key data bytes of the EmberKeyData structure.
This function allows access to the actual certificate data bytes of the EmberCertificateData structure.
This function allows access to the actual public key data bytes of the EmberPublicKeyData structure.
This function allows access to the actual private key data bytes of the EmberPrivateKeyData structure.
This function allows access to the actual SMAC (Secured Message Authentication Code) data of the EmberSmacData structure.
This function allows access to the actual ECDSA signature data of the EmberSignatureData structure.
This function allows access to the actual certificate data bytes of the Ember283k1CertificateData structure.
This function allows access to the actual public key data bytes of the Ember283k1PublicKeyData structure.
This function allows access to the actual private key data bytes of the Ember283k1PrivateKeyData structure.
This function allows access to the actual ECDSA signature data of the Ember283k1SignatureData structure.
This is a ZigBee application profile ID that has been assigned to Ember Corporation.
Ember's first private profile ID.
Ember's last private profile ID.
This is an EmberInitialSecurityBitmask value but it does not actually set anything. It is the default mode used by the ZigBee Pro stack. It is defined here so that no legacy code is broken by referencing it.
The short address of the trust center. This address never changes dynamically.
This is the legacy name for the Distributed Trust Center Mode.
This is the legacy name for the Trust Center Global Link Key.
This magic number prevents accidentally changing the key settings. The emberSetMfgSecurityConfig() API will return EMBER_INVALID_CALL unless it is passed in.
ZDO response status.#
Most responses to ZDO commands contain a status byte. The meaning of this byte is defined by the ZigBee Device Profile.
Network and IEEE Address Request/Response#
Defines for ZigBee device profile cluster IDs follow. These include descriptions of the formats of the messages.Note that each message starts with a 1-byte transaction sequence number. This sequence number is used to match a response command frame to the request frame that it is replying to. The application shall maintain a 1-byte counter that is copied into this field and incremented by one for each command sent. When a value of 0xff is reached, the next command shall re-start the counter with a value of 0x00.Network request: <transaction sequence number: 1> <EUI64:8> <type:1> <start index:1>IEEE request: <transaction sequence number: 1> <node ID:2> <type:1> <start index:1> <type> = 0x00 single address response, ignore the start index = 0x01 extended response -> sends kid's IDs as wellResponse: <transaction sequence number: 1> <status:1> <EUI64:8> <node ID:2> <ID count:1> <start index:1> <child ID:2>*
Node Descriptor Request/Response#
Request: <transaction sequence number: 1> <node ID:2> Response: <transaction sequence number: 1> <status:1> <node ID:2>// <node descriptor: 13>//// Node Descriptor field is divided into subfields of bitmasks as follows:// (Note: All lengths below are given in bits rather than bytes.)// Logical Type: 3// Complex Descriptor Available: 1// User Descriptor Available: 1// (reserved/unused): 3// APS Flags: 3// Frequency Band: 5// MAC capability flags: 8// Manufacturer Code: 16// Maximum buffer size: 8// Maximum incoming transfer size: 16// Server mask: 16// Maximum outgoing transfer size: 16// Descriptor Capability Flags: 8// See ZigBee document 053474, Section 2.3.2.3 for more details.
Power Descriptor Request / Response#
Request: <transaction sequence number: 1> <node ID:2> Response: <transaction sequence number: 1> <status:1> <node ID:2> <current power mode, available power sources:1> <current power source, current power source level:1>// See ZigBee document 053474, Section 2.3.2.4 for more details.
Simple Descriptor Request / Response#
Request: <transaction sequence number: 1> <node ID:2> <endpoint:1>Response: <transaction sequence number: 1> <status:1> <node ID:2> <length:1> <endpoint:1> <app profile ID:2> <app device ID:2> <app device version, app flags:1> <input cluster count:1> <input cluster:2>* <output cluster count:1> <output cluster:2>*
Active Endpoints Request / Response#
Request: <transaction sequence number: 1> <node ID:2>Response: <transaction sequence number: 1> <status:1> <node ID:2> <endpoint count:1> <endpoint:1>*
Match Descriptors Request / Response#
Request: <transaction sequence number: 1> <node ID:2> <app profile ID:2> <input cluster count:1> <input cluster:2>* <output cluster count:1> <output cluster:2>*Response: <transaction sequence number: 1> <status:1> <node ID:2> <endpoint count:1> <endpoint:1>*
Discovery Cache Request / Response#
Request: <transaction sequence number: 1> <source node ID:2> <source EUI64:8>Response: <transaction sequence number: 1> <status (== EMBER_ZDP_SUCCESS):1>
End Device Announce and End Device Announce Response#
Request: <transaction sequence number: 1> <node ID:2> <EUI64:8> <capabilities:1>No response is sent.
System Server Discovery Request / Response#
This is broadcast and only servers which have matching services respond. The response contains the request services that the recipient provides.Request: <transaction sequence number: 1> <server mask:2>Response: <transaction sequence number: 1> <status (== EMBER_ZDP_SUCCESS):1> <server mask:2>
Parent Announce and Parent Announce Response#
This is broadcast and only servers which have matching children respond. The response contains the list of children that the recipient now holds.Request: <transaction sequence number: 1> <number of children:1> <child EUI64:8> <child Age:4>*Response: <transaction sequence number: 1> <number of children:1> <child EUI64:8> <child Age:4>*
ZDO server mask bits#
These are used in server discovery requests and responses.
Find Node Cache Request / Response#
This is broadcast and only discovery servers which have the information for the device of interest, or the device of interest itself, respond. The requesting device can then direct any service discovery requests to the responder.Request: <transaction sequence number: 1> <device of interest ID:2> <d-of-i EUI64:8>Response: <transaction sequence number: 1> <responder ID:2> <device of interest ID:2> <d-of-i EUI64:8>
End Device Bind Request / Response#
Request: <transaction sequence number: 1> <node ID:2> <EUI64:8> <endpoint:1> <app profile ID:2> <input cluster count:1> <input cluster:2>* <output cluster count:1> <output cluster:2>*Response: <transaction sequence number: 1> <status:1>
Binding types and Request / Response#
Bind and unbind have the same formats. There are two possible formats, depending on whether the destination is a group address or a device address. Device addresses include an endpoint, groups don't.Request: <transaction sequence number: 1> <source EUI64:8> <source endpoint:1> <cluster ID:2> <destination address:3 or 10>Destination address: <0x01:1> <destination group:2>Or: <0x03:1> <destination EUI64:8> <destination endpoint:1>Response: <transaction sequence number: 1> <status:1>
LQI Table Request / Response#
Request: <transaction sequence number: 1> <start index:1>Response: <transaction sequence number: 1> <status:1> <neighbor table entries:1> <start index:1> <entry count:1> <entry:22>* <entry> = <extended PAN ID:8> <EUI64:8> <node ID:2> <device type, RX on when idle, relationship:1> <permit joining:1> <depth:1> <LQI:1>The device-type byte has the following fields: Name Mask Valuesdevice type 0x03 0x00 coordinator 0x01 router 0x02 end device 0x03 unknownrx mode 0x0C 0x00 off when idle 0x04 on when idle 0x08 unknownrelationship 0x70 0x00 parent 0x10 child 0x20 sibling 0x30 other 0x40 previous childreserved 0x10The permit-joining byte has the following fields Name Mask Valuespermit joining 0x03 0x00 not accepting join requests 0x01 accepting join requests 0x02 unknownreserved 0xFC
Routing Table Request / Response#
Request: <transaction sequence number: 1> <start index:1>Response: <transaction sequence number: 1> <status:1> <routing table entries:1> <start index:1> <entry count:1> <entry:5>* <entry> = <destination address:2> <status:1> <next hop:2>The status byte has the following fields: Name Mask Valuesstatus 0x07 0x00 active 0x01 discovery underway 0x02 discovery failed 0x03 inactive 0x04 validation underwayflags 0x38 0x08 memory constrained 0x10 many-to-one 0x20 route record requiredreserved 0xC0
Binding Table Request / Response#
Request: <transaction sequence number: 1> <start index:1>Response: <transaction sequence number: 1> <status:1> <binding table entries:1> <start index:1> <entry count:1> <entry:14/21>* <entry> = <source EUI64:8> <source endpoint:1> <cluster ID:2> <dest addr mode:1> <dest:2/8> <dest endpoint:0/1>If Dest. Address Mode = 0x03, then the Long Dest. Address will be used and Dest. endpoint will be included. If Dest. Address Mode = 0x01, then the Short Dest. Address will be used and there will be no Dest. endpoint.
Leave Request / Response#
Request: <transaction sequence number: 1> <EUI64:8> <flags:1> The flag bits are: 0x40 remove children 0x80 rejoinResponse: <transaction sequence number: 1> <status:1>
Permit Joining Request / Response#
Request: <transaction sequence number: 1> <duration:1> <permit authentication:1>Response: <transaction sequence number: 1> <status:1>
Network Update Request / Response#
Request: <transaction sequence number: 1> <scan channels:4> <duration:1> <count:0/1> <manager:0/2> If the duration is in 0x00 ... 0x05, 'count' is present but not 'manager'. Perform 'count' scans of the given duration on the given channels. If duration is 0xFE, 'channels' should have a single channel and 'count' and 'manager' are not present. Switch to the indicated channel. If duration is 0xFF, 'count' is not present. Set the active channels and the network manager ID to the values given. Unicast requests always get a response, which is INVALID_REQUEST if the duration is not a legal value.Response: <transaction sequence number: 1> <status:1> <scanned channels:4> <transmissions:2> <failures:2> <energy count:1> <energy:1>*
Unsupported#
Not mandatory and not supported.
ZDO configuration flags.#
Control which ZDO requests are passed to the application. These are normally controlled via the following configuration definitions:EMBER_APPLICATION_RECEIVES_SUPPORTED_ZDO_REQUESTS EMBER_APPLICATION_HANDLES_UNSUPPORTED_ZDO_REQUESTS EMBER_APPLICATION_HANDLES_ENDPOINT_ZDO_REQUESTS EMBER_APPLICATION_HANDLES_BINDING_ZDO_REQUESTSSee ember-configuration.h for more information.
Defines the maximum number of counters that are specified as reporting either on 2.4 GHz or Sub-GHz.
Defines the maximum number of counters that are specified as reporting either on 2.4 GHz or Sub-GHz.
Defines the maximum number of counters that are specified as reporting either on 2.4 GHz or Sub-GHz.
Defines the entropy source used by the stack.
Defines the maximum number of counters that are specified as reporting either on 2.4 GHz or Sub-GHz.
Defines the trust center APS encryption mode when sending a newer (alternate) network key to a device. The value settings below do not take effect when sending the initial network key during joining or rejoining.
Radio power mode.
Defines the maximum number of counters that are specified as reporting either on 2.4 GHz or Sub-GHz.
Defines the maximum number of counters that are specified as reporting either on 2.4 GHz or Sub-GHz.
Defines the maximum number of PHYs supported.
PHY index for 2.4 GHz radio interface, valid for simultaneous multi radio network.
PHY index for Sub-GHz radio interface, valid for simultaneous multi radio network.
Enumerations#
Defines the possible types of nodes and the roles that a node might play in a network.
The configuration advertised by the end device to the parent when joining/rejoining.
Defines the options that should be used when initializing the node's network configuration.
Options to allow/disallow rejoins using the default link key.
Options to use when sending a message.
Defines the possible incoming message types.
Defines the possible outgoing message types.
A type of command received by the stack.
indication of the action taken on a packet
A type of packet received by the stack.
Defines the possible join states for a node.