Auto-Provisioning
211
SWRU455A – February 2017 – Revised March 2017
Copyright © 2017, Texas Instruments Incorporated
Provisioning
•
The device is reset.
When the provisioning process is stopped due to host request or after inactivity time-out expires, the
device switches back to the role (AP/STA) that was active before the provisioning process was started. If
the process is stopped because a profile was successfully confirmed, the device switches to the role
defined by the host during the provisioning start command. After a provisioning process is successfully
stopped, a PROVISIONING_STOPPED event is sent to the host. The event is sent after the switching to
the desired role is done. The host application should wait for the PROVISIONING_STOPPED event before
issuing any additional commands. If the host application tries to issue a command during an active
provisioning process, the command is not served and an error is returned.
An example of stopping provisioning from the host application follows:
_i32 status;
status = sl_WlanProvisioning(SL_WLAN_PROVISIONING_CMD_STOP,
0,
0,
NULL, 0x0);
If
(0 > status)
{
/* handle error */
}
15.7 Auto-Provisioning
When the auto-provisioning connection policy is enabled, the networking subsystem automatically starts
provisioning process in the following cases:
•
The device was started without any saved profiles, and 2 seconds have passed without receiving any
command from host.
•
The device is in STA role, auto-start connection policy is enabled, the profile list is not empty, and the
device is disconnected from WLAN network for more than 2 minutes.
If the provisioning process is auto-started while in STA role, SC-only configuration mode is used. If it was
auto-started while in AP role, AP+SC configuration mode is used. Whenever a provisioning process is
auto-started by the networking subsystem, the SL_WLAN_PROVISIONING_AUTO_STARTED
provisioning status event is sent to the host. The auto-provisioning connection policy is enabled by default.
15.8 Delivering Feedback to the User
After the SimpleLink device has finished confirming a profile, it should send the confirmation result to the
provisioning smartphone app to report the user who configured the profile, whether the provisioning
process was successful or not.
When the provisioned SimpleLink device is able to connect to the configured wireless network and acquire
an IP address, it advertises itself using broadcast and multicast packets, and waits for the smartphone app
to contact it. The smartphone app should connect to the same wireless network that was configured to the
provisioned device, discover the device IP address by listening to its broadcasts, and send the device
internal HTTP server a GET request for the confirmation result.
If the smartphone app can get the confirmation result from the device, it notifies the user about the
successful provisioning, and on the side of the device, a successful confirmation result event is sent from
the networking subsystem to the host.
If the provisioned device cannot successfully connect to the configured wireless network, or if it is able to
connect to the configured wireless network, but the smartphone app did not receive the confirmation
result, the profile confirmation fails. When a profile confirmation fails, the confirmation fail reason is sent by
the networking subsystem to the host through an event, and the device waits for another profile
configuration attempt. At this point, the smartphone app still does not have the confirmation result,
because it was not able to find the provisioned device on the wireless network. To get the confirmation
result, the smartphone app may disconnect from the configured wireless network and try to directly
connect the SimpleLink device AP (possible only if AP-provisioning or AP+SC-provisioning configuration
modes are used). If the smartphone app was able to connect the SimpleLink AP, it sends the device
internal HTTP server a GET request for the confirmation result. If the profile confirmation failed because