Events
This section refers to the following sample application(s):
01-events
This application is new to OCSDK 1.2.0
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:
- advReceived notification: 01-search
- receive notification: 01-join and others
- timeIndication notification: 03-time
- txDone notification: 01-blink
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, such as 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.
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. As with other APIs, the event notification fields are sent in network order and therefore must be swapped for use in your application (e.g. for printing or testing).