Some applications might find the need for more advanced functionality than the QSL provides. The information on this page is intended to help better understand how the QSL works, making it easier to either customize it to your application or use it as an example to access the mote serial API directly. In both cases you should also have a look at Chapter 3 of the SmartMesh IP User's Guide to understand how to interface the SmartMesh IP mote, as well as the SmartMesh IP Mote Serial API Guide for a complete list of commands, replies and notifications.

State Machine

The core functionality of the QSL is implemented through a finite state machine (FSM). The different states of the FSM schedules a sequence of events, one after the other, where each event cause a certain command to be sent to the mote. The mote returns a corresponding reply to each command sent, and the contents of this reply is used to schedule the next appropriate event.

The mote also sends notifications that are handled asynchronously, which, based on the current state, also cause transitions between FSM states and scheduling of events.

Calls to the QSL API (except the simple isConnected and read) will put the FSM in the relevant initial state, before proceeding to kick the FSM until one of the end states are reached: CONNECTED or DISCONNECTED. A timeout for connect and send is also implemented to force the FSM into an end state, such that the user application can be sure that the call will return within a set limit.

A simplified state diagram is given below. The scheduling of events are noted by the sub-states inside the composite FSM states. Note that calls to the QSL API are marked blue.

Note that some transitions have been omitted for simplicity:

• Unexpected response codes in event replies cause transition to DISCONNECTED (except sendTo and getMoteStatus that transitions to SEND FAILED and RESETTING, respectively).
• RC_INVALID_STATE in join and search cause transition to RESETTING.