Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

This section refers to the following sample application(s):

  • 01-events

Your application can register callback functions to handle a number of notifications generated by the OCSDK stack.   The 01-events sample demonstrates handling event notifications - the application will attempt to join and print event notifications as they come in.  There are additional samples that demonstrate handling of other types of notifications:

Details on event notifications can be found in the SmartMesh IP Mote API Guide.

The 01-events Sample Application

The application requires an available network configured with matching network ID to see a broad range of events. The mote will print a summary of the event, state, and alarm fields from event notifications it receives.

Events app, ver 1.2.0.1
Event received - events: 0x0001, state: 0x01, alarms: 0x0000
Joining...
13311 : Joining
Event received - events: 0x0100, state: 0x03, alarms: 0x0000
14339 : Connected
27037 : Active
Event received - events: 0x0020, state: 0x05, alarms: 0x0000
Event received - events: 0x0080, state: 0x05, alarms: 0x0000
...


Events 

  • 0x0001 - boot
  • 0x0100 - join started
  • 0x0020 - operational
  • 0x0080 - service change

States

  • 0x01 - idle
  • 0x03 - negotiating
  • 0x05 - operational

If you issue a mote reset command from the manager (e.g. via CLI command reset mote n), you can observe the mote disconnecting.  The mote will reset after a short delay:

Event received - events: 0x0010, state: 0x06, alarms: 0x0000
Disconnecting: 1

Events 

  • 0x0010 - disconnected

States

  • 0x06 - disconnected

Implementation Details

The 01-event sample application uses the Helper Modules to initialize the CLI Module and for interaction with the local interface. Because the application installs an event handler, the local module does not receive the boot event, and so the application must handle all local module tasks (joining on its own. Note that this prevents the local module from printing the stack version banner.

The application still initializes the local module in the loc_task_init() as some local module functions are used (e.g. registration of the event handler callback function eventNotifCb()), but we pass fJoin = JOIN_NO to prevent the local module from attempting to join and NULLs for the other parameters. 

The application also defines a reset CLI command to easily reset the mote.

It uses a single task (eventTask) that:

  • Issues the join command
  • Waits in a while(1) loop.

All activity takes place in the eventNotifCb function - it parses and stores the event in the app_vars global variables struct, and prints the event notification.  In a more complex design, it might copy the event notification, and post a semaphore for action by another task - e.g. storing persistent configuration when a disconnect event is received.  Note that as with other APIs, the event notification fields are sent in network order, and must be swapped for use in your application (e.g. for printing or testing).
  • No labels