Daintree Light Sensor Demo Application Note

Transcription

1 Application Note Daintree Light Sensor Demo Application Note Daintree Light Sensor Demo Application Note Introduction Daintree Wireless Lighting Network The first time a light sensor joins a network, the Daintree ControlScope software will go through a calibration using the light sensor and all the dimmable lights in the room to determine the dim percentage as the light changes in the room. Once calibrated, the ControlScope software can then adjust the dimmable lights automatically as the light sensor reports different illuminance measurements. Hardware Requirements 1. CEL Universal Evaluation Board 2. EM357 Module that plugs into CEL Universal Evaluation Board (ZICM357SP0, ZICM357SP2, or ZICM357P2) 3. Ember ISA3 (for downloading) Software Requirements The Daintree Light Sensor Demo Application Note describes the features of the Daintree Light Sensor Demo Software and how to create it. The Daintree Light Sensor Demo Software is written for CEL's EM357 Module, a module based on Silicon Laboratories EM357 System On Chip (SoC), to be compliant with Daintree Network s solution for lighting control. The architecture behind the Daintree solution is a ZigBee Home Automation Network, supporting devices that are a part of the ZigBee Home Automation Profile. The light sensor participates in a Home Automation Light Network. The network may consist of a gateway, dimmable lights and a light sensor. The gateway, also known as the Wireless Access Controller (WAC) is provided by Daintree Networks. The light sensor interacts with the gateway and the gateway then controls the dimmable lights based on light readings. The light sensor powers up looking for a network to join, if it is not already part of a Private Area Network (PAN). Once the WAC allows the light sensor device to join its network, the WAC configures the light sensor to report illuminance measurements. 1. Ember Insight Desktop Software, Version IAR ARM Workbench, Version Ember Stack, Version or later Daintree Light Sensor Demo Application Note 1

2 Features 1. Based on the ZigBee Home Automation Profile with Light Sensor as the device type 2. Supports the Commissioning Cluster in addition to the ZigBee Home Automation Profile 3. A push button to restore device to factory defaults after holding it down for a minimum of three to four seconds 4. Supports the ZigBee PRO specification (stack supplied by Ember) 5. Supports the optional User Descriptor ZigBee Device Profile command addition to the mandatory ZigBee Device Profile commands 6. Supports Frequency Agility through the Ember ZigBee stack; no application level code needed 7. Supports responses to Many to One route requests through the Ember ZigBee stack; no application level code needed 8. Mains powered device; the device does not sleep 9. Fragmentation 10. Attribute reporting per ZigBee specification 11. A-mode commissioning (automatically searches for a network to join without user intervention) 12. Provisioning is not needed as this device is a server and only responds to commands sent to it 13. Over-the-Air (OTA) firmware upgrade using Daintree OTA specification 14. The Device has routing capabilities (supported by the Ember ZigBee Stack) 15. Uses the ADC in the EM357 chip to read the light sensor Creating the Demo The software is based on the sample software created by the Ember Appbuilder Application that is a part of the Ember Insight Desktop; some understanding of the Ember Insight environment, the ZigBee HA Profile, ZigBee Pro specification and the ZigBee Cluster Library is presumed. Daintree supplies a proprietary cluster for their OTA firmware upgrade, therefore, the Daintree Cluster needs to be installed if starting from a fresh install of the Ember stack. Contact Daintree for installation instructions. The code provided by CEL already has the Daintree Cluster installed. Ember Appbuilder The Daintree Light Sensor Demo Software is created from the Ember Appbuilder Application. Using the appropriate installed stack version, the Appbuilder creates an IAR Project with framework code that supports the ZigBee Home Automation Profile for a light sensor device. The steps to create the project are as follows: Step 1 Make sure the version of the Ember stack you want to use is installed along with the latest version of Ember Insight Desktop. The Ember Insight Desktop contains the Appbuilder application. Step 2 Configure Appbuilder Software to point to the appropriate Ember stack version. Click Add to enter the directory where the stack version is installed. Once completed, you will see the stack version appear in the list. See screenshot below of the list of available stacks: Daintree Light Sensor Demo Application Note 2

3 Figure 1 Daintree Light Sensor Demo Application Note 3

4 Step 3 Select the stack version to use. The Daintree Light Sensor Demo uses EmberZNet 4.6 GA EM35X stack selection. Figure 2 Step 4 Start configuring the Daintree Light Sensor Demo using the Appbuilder. See the following screen shots from the Appbuilder Software for the Daintree Light Sensor Demo. ZigBee Cluster Configuration The ZigBee device type for a light sensor used in the Daintree Light Sensor Demo is an end device. The light sensor will not route within the mesh network. For the Daintree Light Sensor Demo the light sensor is not mobile, and since it is not battery powered, it does not sleep. There is only one endpoint, the Home Automation (Profile ID = 0x0104) Light Sensor (Device ID = 0x0106). The ZCL device type is normally a HA light sensor but Daintree has some special cluster requirements in addition to the clusters for a HA light sensor that forces a ZigBee Custom ZCL device type. A typical HA light sensor requires the following clusters: 1. Basic Server Cluster 2. Identify Server Cluster 3. Illuminance Measurement Server Cluster The Daintree Light Sensor Demo requires the following additional clusters: 1. Commissioning Server Cluster 2. Daintree OTA Server Cluster Daintree Light Sensor Demo Application Note 4

5 Figure 3 Daintree Light Sensor Demo Application Note 5

6 Figure 4 Daintree Light Sensor Demo Application Note 6

7 Each cluster has mandatory attributes and optional attributes. Appbuilder highlights optional attributes with boxes in the attribute table. Checking the boxes in Column F indicates that the attribute will be saved to the internal flash. Checking the boxes in Column S indicates that the attribute is to be applied to all endpoints; this saves on storage space. Checking the boxes in Column B will include min/max boundaries for that attribute. Daintree requires the following additional optional attributes to be supported; see screenshots below. Basic Cluster: 1. Application Version 2. Stack Version 3. Hardware Version 4. Manufacturer Name 5. Model Identifier 6. Date Code 7. Power Source Figure 5 Daintree Light Sensor Demo Application Note 7

8 Commissioning Cluster: 1. Short Address 2. PAN ID Figure 6 Daintree Light Sensor Demo Application Note 8

9 Stack Configuration Home Automation Security is selected since the device is part of a Home Automation Network. The specification versions are all the latest versions by default. The Home Automation profile specifies the radio channels and those are automatically selected by Appbuilder. We will be implementing FCC power restrictions for certain channels when the node joins the network. Set the Extended PAN ID to Fixed with all 0 s (per Daintree requirement) and enable serial commands for sending ZDO messages. This will allow the use of a CLI to send ZDO messages which is helpful for debugging. The Long Poll interval should be set to one minute and the Application Response Timeout to be one second. This selection only affects a mobile or sleepy end device. It has no effect on a plain end device. Debug printing should be enabled to aid in debugging during the development phase. You can go back and disable it once the product is in production. We enable everything under Debug printing for the Cluster debugging and certain ones we are interested in for the General purpose areas. Other settings include Enable bindings and Enable receive statistics. Daintree specifies that the number of bindings to be eight. The rest can be the defaults shown. Daintree Light Sensor Demo Application Note 9

10 Figure 7 Daintree Light Sensor Demo Application Note 10

11 Figure 8 Daintree Light Sensor Demo Application Note 11

12 HAL Configuration The HAL Configuration is for the Ember Evaluation Board. The same configuration works for the CEL Evaluation Board. The bootloader must be an Application bootloader. This tells the application that an application bootloader is needed. The application bootloader is used for OTA firmware upgrade. The application receives the image and stores it in an external EEPROM. It is then told by the sending device to boot into the bootloader. The application bootloader boots up, updates the application image from the external EEPROM and starts execution of the new image. The other type of bootloader is the Serial UART. It expects to get the firmware image from the UART not an external EEPROM. Make sure the CEL application bootloader is downloaded into the EM357 Module for the light sensor. The Peripheral Configuration assigns some default behavior for two push buttons and a heartbeat LED. Disable all of those. We will assign our own behavior to them. The application serial port is used for connecting a terminal emulator and is by default on Port1. Virtual UART is through the ISA3 box for Insight Desktop to open a serial connection. We are using the default UART settings for the Demo. The GPIO register configuration is per hardware settings. The defaults are per the Ember Evaluation Board settings which also work for the CEL Universal Evaluation Board for the purpose of this Demo. Note: The exception of PC5 should be Alt Out to enable TxActive signal on the radio. Daintree Light Sensor Demo Application Note 12

13 Figure 9 Daintree Light Sensor Demo Application Note 13

14 Plugins Silicon Laboratories supplies code that may be used "as is" or with minor changes for certain features. The "as is" code is certifiable. These code samples are called "plugins". Using a certifiable plugin means you do not need to code in support for the feature. The Daintree Light Sensor Demo uses the following plugins: 1. Daintree OTA Server Cluster ( as is code, no changes needed) 2. Fragmentation ( as is code, no changes needed) 3. General Response Commands ( as is code, no changes needed) 4. Identify Server Cluster ( as is code, no changes needed) 5. Reporting Cluster ( as is code, no changes needed) Certain plugins require support in the form of callbacks where the developer needs to supply code to the hardware or the application specific functions. Those are in the form of "defined callbacks". The plugins used that have callbacks needing code are as follows (although the option is to do nothing within the callback and therefore no code is necessary): 1. Daintree OTA Server Cluster (see Figure 10) 2. Reporting Cluster (See Figure 11) Daintree Light Sensor Demo Application Note 14

15 Figure 10 Daintree Light Sensor Demo Application Note 15

16 Figure 11 Callback Configuration In addition to the defined Callbacks from the plugins, certain callbacks can be enabled to the application for special handling. Examples are main init for special hardware initialization or main tick for checking for a button press. The "Callback Configuration" tab lists the available callbacks that can be exposed to the application level for special handling. Some of the callbacks are already used in the plugin and are not exposed. The checked boxes, in Figure 12, are used in the Daintree Light Sensor Demo. A good rule is if you suspect you may need a callback, enable the callback. Users can leave the callback unpopulated with no code without causing any damage. Daintree Light Sensor Demo Application Note 16

17 Figure 12 Daintree Light Sensor Demo Application Note 17

18 Figure 13 Daintree Light Sensor Demo Application Note 18

19 Includes The "Includes" tab gives the user the opportunity to include any external files into the generated project. We are including the file illuminance.c into the project. This file has code specific to the light sensor. By including this file, future regeneration of the Appbuilder will have this file in the build. Also included are #defines to use from the stack. They are included in the generated application header file and do not need to be part of the compiler or linker definitions in the generated project file. EMBER_AF_ENABLE_CUSTOM_COMMANDS - Allows the developer to add in their own commands via the custom CLI command EMBER_AF_ENABLE_FRAMEWORK_EEPROM_INTERFACE - Enables EEPROM API support EMBER_APPLICATION_HANDLES_UNSUPPORTED_ZDO_REQUESTS - Passes to the application unsupported ZDO requests so that the developer can write code to support them. There is a list of ZDO IDs that the Ember stack supports. This list is part of the ember-types.h file that is located in the Ember Application Framework. EMBER_APPLICATION_HAS_BUTTON_HANDLER - The developer will supply a button handler routine to the existing code Figure 14 Daintree Light Sensor Demo Application Note 19

20 Step 5 Generating the IAR Project and base source code for modification. Clicking the Generate button creates a list of files and an IAR Project under the directory app\builder\daintree_ Light_Sensor_Mains_Powered for this particular demo code. The directory name comes from the device name in the Appbuilder GUI. Under app\builder\daintree_light_sensor_mains_powered directory the generated application level source code and IAR Project starts with the device name Daintree_Light_Sensor_Mains_Powered. IAR Project and Modifying Code Once the IAR Project has been created, open the IAR Project (.eww file) to start modifying code. All of the file changes are limited to the Daintree_Light_Sensor_Mains_Powered_callbacks.c file. Note: Refer to the Silicon Laboratories Application Framework, Version 2 Developer Guide for more detailed information on the structure of the software and how the callbacks interact with the software generated. The files that were changed for the Daintree Light Sensor Demo are as follows: 1. app\builder\daintree_light_sensor_mains_powered\daintree_light_sensor_mains_ Powered_callbacks.c 2. app\builder\daintree_light_sensor_mains_powered\daintree_light_sensor_mains_ Powered_endpoint_config.h Modifying Appbuilder Generated Code Appbuilder generates an application layer callback file in the following directory app\builder\daintree_light_sensor_ Mains_Powered for the developer to add in their specific code changes. The callback APIs are the ones selected from the Appbuilder plugin tab and callback tab. The file is named Daintree_Light_Sensor_Mains_Powered_callbacks.c. It uses the generated supporting.h files: 1. Daintree_Light_Sensor_Mains_Powered.h 2. Daintree_Light_Sensor_Mains_Powered_endpoint_config.h 3. Daintree_Light_Sensor_Mains_Powered_board.h Daintree_Light_Sensor_Mains_Powered.h is the application header file and contains all the #defines used in the generated code. You can add to this file your own #defines but the file gets overwritten upon regeneration from Appbuilder. It is better to put any #defines in the "Appbuilder Include" tab. Daintree_Light_Sensor_Mains_Powered_endpoint_config.h is the profile/cluster/attribute configuration file. One of the default attributes in this file needs to be changed to the Daintree recommended value. This file needs to be re-edited each time there is a re-generation of code from Appbuilder since this file is overwritten upon re-generation. Daintree Light Sensor Demo Application Note 20

21 Daintree_Light_Sensor_Mains_Powered_board.h contains register settings for the EM357 GPIO pins related to the board. This file is generated based on the Appbuilder HAL Configuration GPIO register configuration settings. This file also is overwritten when regenerated from Appbuilder. Daintree_Light_Sensor_Mains_Powered_endpoint_config.h The change made to Daintree_Light_Sensor_Mains_Powered_endpoint_config.h is for startup defaults that are different from the ZigBee spec. Specifically, the Commissioning Cluster Startup Control attribute should be 3 according to the Daintree requirements. The comments in the file will guide you to the correct startup attribute that was changed. Daintree_Light_Sensor_Mains_Powered_callbacks.c The Daintree_Light_Sensor_Mains_Powered_callbacks.c is where all the callbacks reside. This file is generated as a result of the selections from the Appbuilder plugin tab and the callbacks tab. Any additional support functions are also included in this file. By default this file is not regenerated but can be if enabled to do so. If adding additional callbacks, save the original, include the callback file as part of the regeneration and then merge in the code back in from the saved version. Not all callback functions need to be filled in even though they exist in the.c file. A particular callback function may not be needed but in case it is, the callback is included. If not using a particular callback, do not fill in the function call. It will only get called and then return from the function call. The following is a list of the function calls that are filled in for the Daintree Light Sensor Demo: emberafprezdomessagereceivedcallback emberafstackstatuscallback emberafmaininitcallback emberafclusterinitcallback emberafmaintickcallback emberafillummeasurementclusterserverinitcallback emberafillummeasurementclusterservertickcallback emberafcommissioningclusterrestartdevicecallback emberafcommissioningclusterresetstartupparameterscallback emberafcommissioningclusterserverinitcallback emberafcommissioningclusterservertickcallback emberafjoinablenetworkfoundcallback emberafscanerrorcallback emberafstartsearchforjoinablenetworkcallback emberafcontinuejoinablenetworksearchcallback emberafnetworkfindoperationcompletecallback emberafpluginreportingconfiguredcallback emberafplugindaintreeotainitialiseotaattributescallback emberafplugindaintreeotawriteeepromcallback emberafplugindaintreeotareadeepromcallback Daintree Light Sensor Demo Application Note 21

22 emberafprezdomessagereceivedcallback The callback emberafprezdomessagereceivedcallback()handles incoming ZDO messages before giving them to the application. The Ember stack automatically handles mandatory ZDO commands but can pass up optional commands to the Application layer. The Daintree Light Sensor Demo handles the optional command USER_DESCRIPTOR_REQUEST in this callback by creating the response message with the user descriptor info and sends it out via unicast. The return code for this function call indicates that the message has been handled and the application does not have to handle it. emberafstackstatuscallback The callback emberafstackstatuscallback()handles the status returned by the stack. The Daintree Light Sensor Demo is only interested in the following statuses from the stack: EMBER_NETWORK_UP EMBER_NETWORK_DOWN EMBER_CHANNEL_CHANGED Based on these statuses, the state machine will need to be updated which is described in emberafmaintickcallback(). For the EMBER_CHANNEL_CHANGED status, the power level is changed based on the new channel due to FCC limitations for the module on certain channels. The FCC restrictions can be found in the CEL Module Datasheets. emberafmaininitcallback The callback emberafmaininitcallback()allows the developer to initialize its own software structures and hardware. For the Daintree Light Sensor Demo, initialize the EEPROM and determine what type of EM357 Module is being used by reading in manufacturing data stored in the form of tokens within the EM357 internal flash. There are three types of Modules supported: ZICM357SP0, ZICM357SP2, and ZICM357P2 (see the CEL Module Datasheets for a description of each). emberafclusterinitcallback The callback emberafclusterinitcallback()is called when a cluster is initialized. It gives the application an opportunity to take care of cluster initialization procedure. This function does not differentiate between client or server type of clusters. You can do your own cluster initialization within this function or do it in the cluster specific init callback. To demonstrate the use of this function, the Daintree Light Sensor Demo checks for the Basic Cluster ID and initializes the Application Version Attribute if the ID matches. This Basic Cluster initialization could also be done in a different callback function provided from one of the selections in the Callback configuration tab under Basic Cluster heading. This selection was not chosen for the Daintree Light Sensor Demo, but uses the init in this callback. The Illuminance Measurement Cluster and the Commissioning Cluster were selected to show the developer that there are options available to add the code. Daintree Light Sensor Demo Application Note 22

23 emberafmaintickcallback The callback emberafmaintickcallback()is the developer s hook into the Ember Application Tick. The Ember Appellation Tick is not based on any timer tick. It is more of an application poll. The Daintree Light Sensor Demo uses this callback for continuous checking of a button press and to start the process of searching for a network to join by starting the A-mode commissioning state machine. The A-mode commissioning initial state is NOT_JOINED within this callback and the state changes to SEARCHING_FOR_ NETWORK if the stack indicates the device is not part of any network. If the stack indicates that the node is part of a network, the state is changed to JOINED. Once the state machine has started from this callback, control of the state machine is handed over to the Commissioning Cluster. Control reverts back to emberafmaintickcallback() when the device is no longer part of the network. There are three states defined for A-mode commissioning: 1. NOT_JOINED The node has not joined a PAN 2. SEARCHING_FOR_NETWORK - The node is searching all channels looking for a PAN to join 3. JOINED The node has joined a PAN emberafillummeasurementclusterserverinitcallback The callback emberafillummeasurementclusterserverinitcallback()is generated from the Callbacks tab because it was selected under the Illuminance Measurement Cluster heading. If this callback did not exist, then Illuminance Measurement Cluster initialization would be done in emberafclusterinitcallback(). Within this callback the min and max attributes for the Illuminance Measurement are configured. An initial reading of the light sensor is taken and saved as the MeasuredValue attribute. If reporting information exists, the sampling interval is restored using the minimum reporting interval from the reporting information. This takes care of an accidental reboot. The node is still part of the network and the current state before reboot needs to be restored. Lastly, set up a timeout for the next measurement for this particular cluster. emberafillummeasurementclusterservertickcallback The callback emberafillummeasurementclusterservertickcallback() is used to read the Analog to Digital Converter (ADC) connected to the light sensor. It is scheduled for the minimum reporting interval specified by the WAC when the WAC configured attribute is reporting on the device. The values from the ADC are in millivolts and need to be converted to a hexadecimal representation of a lux, a unit of illuminance. The hexadecimal value is defined in the Illuminance Measurement Cluster section of the ZigBee Cluster Library specification. A table is created using a lux meter to create a lux-to-millivolt conversion table. The measurements are done in an office environment. By controlling the amount of lighting available a lux meter is used to provide the lux value and the ADC is read to provide the voltage. It Daintree Light Sensor Demo Application Note 23

24 is not easy to control the amount of light so the values are rough estimates. Silicon Laboratories has provided Hardware Abstraction Layer APIs halreadadcblocking() and halconvertvaluetovolts() for reading the ADC and converting the value to volts. Our light sensor is connected to ADC0 on GPIO PB5, which is also the temperature sensor. A jumper on the CEL Universal Evaluation Board enables the light sensor and disables the temperature sensor. emberafcommissioningclusterrestartdevicecallback The callback emberafcommissioningclusterrestartdevicecallback() is called when a packet is received, parsed and determined to be a Commissioning Cluster Restart Device command. This callback allows the developer to handle the command as though there is no usable spec-compliant plugin provided. The Daintree Light Sensor Demo handles this callback based on the interpretation of the ZigBee Commissioning Cluster recommendations, which is to restart the device however the developer wishes. emberafcommissioningclusterresetstartupparameterscallback The callback emberafcommissioningclusterresetstartupparameterscallback()is called when a packet is received, parsed and determined to be a Commissioning Cluster Reset Startup command. This callback allows the developer to handle the command as though there is no spec-compliant usable plugin provided. The Daintree Light Sensor Demo handles this callback based on the interpretation of the ZigBee Commissioning Cluster recommendation, which is to reset the startup parameters to its default values. emberafcommissioningclusterserverinitcallback The callback emberafcommissioningclusterserverinitcallback()allows the developer to do any Commissioning Cluster specific initialization. For the Daintree Light Sensor Demo, an application timer tick is scheduled for the Commissioning Cluster. emberafcommissioningclusterservertickcallback The callback emberafcommissioningclusterservertickcallback()is the Commissioning cluster-specific application tick. The Daintree Light Sensor Demo uses this callback for the following: 1. Handle delayed events for restarting the device at a later time 2. Handle updating the A-mode Commissioning state machine; this tick callback takes over the A-mode commissioning state machine from the main tick callback once the Commissioning Cluster has been initialized To restart a device, the Daintree Light Sensor Demo checks the Commissioning Cluster startup attribute and acts according to its setting per the ZigBee Commissioning Cluster specification. Note: There are other ways to handle restarting a device; the server tick callback is just one example. Daintree Light Sensor Demo Application Note 24

25 emberafjoinablenetworkfoundcallback The callback emberafjoinablenetworkfoundcallback() is called by the framework on behalf of the Ember form-andjoin library to notify the application that a network has been found a joinable network. The Daintree Light Sensor Demo will join the first available network and will call Ember API emberafjoinnetwork() to join the network. This callback includes the FCC restrictions that are implemented for the various module types. The FCC restrictions are found in the CEL Module Datasheets. emberafscanerrorcallback The callback emberafscanerrorcallback()is called by the framework on behalf of the Ember form-and-join library to notify the application if an error occurs while scanning. Usually the error occurs because no network was found and all the channels have been searched for that scan. If there are separate scans that need to be done, it is in this callback that the next start channel is specified. The Daintree Light Sensor Demo will then restart the search of a network to join beginning with the new start channel. An example would be the ZICM357SP2 Module with a scan that was initiated starting at channel 11. Upon entering this callback, the next channel to scan would be channel 25. Once this callback is entered after channel 25 is finished, the next channel to start scan would be channel 11 again. This channel scanning state machine continues to update to the next channel as long as this callback is called. This is part of A-mode commissioning; continue the search forever. emberafstartsearchforjoinablenetworkcallback The callback emberafstartsearchforjoinablenetworkcallback() is called by the framework to search for joinable networks. In this callback the Daintree Light Sensor Demo will call the Ember API emberscanforjoinablenetwork() to start the scan given a bit map of the channels to scan. The FCC restrictions are put in place here before the scan is initiated. A separate scan is initiated for each channel or set of channels that have a FCC restriction. There is a flag indicating the state of the join process in regard to when to continue searching and when to stop. The two states are: 1. NETWORK_FIND_NONE Not looking for a network to join 2. NETWORK_FIND_JOIN Looking for a network to join emberafcontinuejoinablenetworksearchcallback The callback emberafcontinuejoinablenetworkssearchcallback()is called by the framework to instruct the application to continue its joinable network search. The Daintree Light Sensor Demo will call the Ember API emberscanfornextjoinablenetwork() to continue the search. emberafnetworkfindoperationcompletecallback The callback emberafnetworkfindoperationcompletecallback()is called by the framework when the network find operation is complete. The application can cleanup in this callback. The Daintree Light Sensor Demo cleans up by setting the state to NETWORK_FIND_NONE, releasing any buffers used, and disabling any events that might be scheduled. Daintree Light Sensor Demo Application Note 25

26 emberafpluginreportingconfiguredcallback The callback emberafpluginreportingconfiguredcallback()notifies the application that an attribute reporting entry has been configured. It is in this callback that the light sensor s monitoring interval is overwritten with the minimum value of the reporting entry. An example of reporting could be a minimum reporting interval of one second and a maximum reporting interval of five minutes (or 300 seconds). The light sensor will re-configured to be read every second based on the minimum reporting interval. emberafdaintreeotainitialiseotaattributescallback The callback emberafdaintreeotainitialiseotaattributescallback()initializes the Daintree OTA attributes. The Basic Cluster Manufacturer ID attribute is initialized to CEL string. The Daintree Cluster Application Version attribute is initialized to a version string in the form of W.X.Y.Z, (e.g., ). The Daintree Cluster Hardware Version attribute is initialized to the version string, EM357LS. emberafdaintreeotawriteeepromcallback The callback emberafplugindaintreeotawriteeepromcallback()writes data to EEPROM using the Ember API emafeepromwrite(). emberafdaintreeotareadeepromcallback The callback emberafplugindaintreeotareadeepromcallback()reads data from EEPROM using the Ember API emafeepromread(). Hardware Abstraction Layer API The Daintree Light Sensor Demo Software provides an application layer push button handler called halbuttonisr()to handle SW0 push button detection. The interrupt service routine passes into halbuttonisr() the state of the button (pressed or released) and button number (0 or 1). A flag is set indicating the state so that a tick callback routine can poll on that flag and take action. CLI Commands The framework allows the developer to add CLI Commands into its current list of CLI Commands via the custom command. There are two CLI Commands added for debugging: 1. custom dumpversion Prints the firmware version string 2. custom dumpillum Prints the Illuminance Measurement Cluster reporting value, the lux value and the measured value in millivolts; all values are in hexadecimal format Daintree Light Sensor Demo Application Note 26

27 The two function calls that service the above commands are: 1. emafclidumpfwversioncommand() 2. emafclidumpillumcommand() References Daintree 1. Daintree Networks ZigBee Device Requirements, Revision 0.8 Silicon Laboratories Application Framework, Version 2 Developer Guide Applicaiton Development Fundamentals ZigBee 1. IEEE Standard ZigBee Home Automation Profile Specification, Version 1.2, Revision ZigBee Cluster Library Specification, Revision 3 4. ZigBee Specification, Revision 19 CEL 1. ZICM357P2 Datasheet 2. ZICM357SPx Datasheet Revision History Revision Date Description Page(s) A /13/12 Initial Release. N/A Professional Grade Wireless Radio Solutions California Eastern Laboratories 4590 Patrick Henry Drive Santa Clara, CA (408)