My latest project is to be able to somewhat control my RaspberryPi with my Alexa devices. While playing around, I ended up wanting to store data associated with the Amazon account. I decided to explore storing data with two retention policies: data kept for the session and data kept forever. Here is how I ended up storing data in Alexa-triggered Lambda for those two scenarios. As always, the source code used for this experiment can be found in my GitHub repository.
Identifying the user
I saw two identifiers that were interesting: the userId and the personId. According to the documentation, userId is the identifier associated with the account of the user. On the other side, the personId is used to represent the human that executed the command. Therefore, multiple personIds can be associated with the same userId.
Alexa Skill setup
In order to be able to test both storage policies, I needed a few different intents. I decided to keep it simple and went with the following:
- Add: adds one to a session counter and returns the new value
- Current: returns the value of the counter
- Forget: resets the counter
- Persist: stores the value of the counter in a persistent database
- Restore: restores the value of the counter from the persistent database
Lambda environment setup
As with all my other projects, one of my main goals here was to learn a little something. Therefore I decided to try a few new technologies this time around. My previous test with Alexa was done using Python and handled HTTP calls directly.
In order to shake things up, I decided to go with: Node.js and the Alexa SDK. This meant a new language and using the official SDK instead of raw HTTP queries.
For the persistent storage, I wanted something that was easy to use, simple, and, most importantly, free. I decided to go with DynamoDB.
Handling session storage
The session storage is available through the JSON payload received and returned by your lambda. Using the Alexa SDK makes managing these attributes easy through the attribute manager.
In order to read a value from the session, you can use the attribute manager:
|
1 2 3 |
const attributes = handlerInput.attributesManager.getSessionAttributes(); const current_value = attributes.current_value; let text = `Current value is ${current_value}`; |
You can write to the session through the same object:
|
1 2 3 4 |
const attributes = handlerInput.attributesManager.getSessionAttributes(); const current_value = attributes.current_value || 0; attributes.current_value = current_value + 1; handlerInput.attributesManager.setSessionAttributes(attributes); |
Getting a new Alexa session
While testing this skill, I ended up having to reset my session a few times. The simplest way to do so is to say: Alexa, exit. This will give you a new sessionId and reset all stored session attributes.
Handling persistent storage
Reading and writing to DynamoDB is almost as easy as writing to the session storage.
In order to write to the database, you need to build the parameters and pass these to the put function of an instance of AWS.DynamoDB.DocumentClient. The following is an example of that flow:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
const userId = Alexa.getUserId(handlerInput.requestEnvelope); var params = { TableName: DynamoTableName, Item: { 'Client' : userId, 'Value' : current_value } }; try { await Dynamo.put(params).promise(); } catch(error) { // handle error } |
You can then read the value following the same pattern: build the params and pass those to the get function of the instance.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
const userId = Alexa.getUserId(handlerInput.requestEnvelope); var params = { TableName: DynamoTableName, Key:{ "Client": userId, } }; let value = undefined; try { let entry = await Dynamo.get(params).promise(); value = entry.Item.Value; } catch(error) { // handle error } |