In Part 1, I introduced an app that sends an SMS notification when your Fitbit battery is low. Part 2 covered the Authentication Flow of the process. This post describes how the device status is checked and communicated to the user.
The flow is as follows:
- The CloudWatch Scheduler kicks off a Lambda job that pulls registered users from the DynamoDB table. This information is based to a SNS topic, which in turn…
- …kicks off the Lambda function that obtains the Fitbit device info. The Fitbit api is called, and the resulting message is processed by the Lambda function. The device information is stored in and retrieved from the DynamoDB table as needed for processing and history tracking.
- If the result was a success then the a message is sent to the SNS topic for the subscribed user – assuming that the battery status is low AND the user has not already been notified.
- If a “Token Expired” error is returned, then the Lambda function passes the required information to the Refresh User SNS topic. The Lambda function again calls a Fitbit API; this time to refresh the token.
- If the token is refreshed, then the information is saved to the DynamoDB table and passed to the Get Device Info Topic (starting the process all over again)
- If a failure occurs, then a message is sent to the user, directing them to re-authorize the application to access their Fitbit account.