The Alexa Skills Kit for Node.js includes support for creating a DynomoDB table to hold attribute values across sessions. To create the table dynamically, the Lambda function is typically given DynamoDBFullAccess permissions.

This feature is to remove the table creation code from ASK SDK Node and move it to the ASK CLI as part of the deploy command. This will allow the lambda function to have reduced permissions to insert rows, read, write, and delete.

Configuration for the table name and region would be stored in '.ask/config'

The command would be:
$ deploy --target dynamoDB

This would create the table if it does not exist and update the role associated with the lambda function to include only the permissions it needs.

Calling 'ask deploy' will also deploy to DynamoDB (if the config includes a table name). Deploy to Dynamo would occur after deploy to lambda so that the function permission could be set.

I'm getting intent failures with no corresponding error messages in logs (using alexa-skills-kit-sdk-for-nodejs and Lambda).

In troubleshooting, it looks like I may be exceeding the max allowed size of the JSON Response object. I see from the docs that the total size of your response cannot exceed 24 kilobytes.

I'm using session attributes to store data I need, and in some circumstances that data is larger than 24kb. The same documentation as referenced above says: When returning your response, you can include data you need to persist during the session in the sessionAttributes property. The attributes you provide are then passed back to your skill on the next request.

We need a way to store more than 24kb between intents in a session and not pass it in as part of the JSON Request object. Obviously if it goes in to the request it is going to come out as part of the response object and exceed the size limit.

I already persist data with DynamoDB, pulling in data to a new session each time. I don't want to have to go to the DB after every intent in the same session!

We have a use case to put Alexa devices into many rooms and write custom Alexa skills to serve different responses and perform database updates based on which room they are in. As a result, we need to uniquely identify each Alexa in order to identify the room. We have look into various work around:
1) use "context:System:device:deviceId" which is specific to each skills and changes when the skills disable/enable.
2) use different userid to identify different Alexa but this would mean having many user accounts if the deployment is big
3) when Skill detects unknown "context:System:device:deviceId", expect user to use a certain utterance to provide the room information and register the new id in database.

However, none of these are scalable nor reliable so a real unique device ID for each Alexa would be desirable. Thanks!

When developing a skill in non-english language (e.g. Spanish), many times our skill needs to speak back to the user with a name or an english native word that doesn't have a local translation or that you want the skill to pronounce correctly in English.

Case 1: Names

"Hola, el nombre del autor es Miles Peter Andrews"

I'd really love if my skill would not butcher the name of that author like it does right now when trying to say that in Spanish mode.

Case 2: Teaching English Skills

"Hoy vamos a aprender voz pasiva. Repite conmigo: The lunch was prepared by John"

I'd like to address my hispanic students trying to learn English with my awesome skill in Spanish but obviously when I need the skill to say something in English it should be able to do it properly.

So, it'd be great if we could mix languages with something like:

"Hola, el nombre del autor es <lang="english">Miles Peter Andrews</lang>"

or

"Hoy vamos a aprender voz pasiva. Repite conmigo: <lang="english">The lunch was prepared by John</lang>"

Allow users to link their social media accounts (Facebook, Twitter, Instagram, etc) in the Alexa App itself. Then allow skills to query which accounts are linked and request permission to use those links, without requiring each skill to perform account linking separately (and perhaps not even exposing the account details to the skill, for greater privacy!).

This would allow a skill to request permission to post to Facebook, for example, to share their new high score. The skill would request this permission at the time of the interaction, and the approval would be delegated to Amazon's built-in handling (to make sure the skill did not deceive the user into granting permission). Once permitted, the skill would be able to use an Amazon API that would in turn call the social media API.

This would abstract this common interaction away from each skill, provide greater consistency, and encourage organic growth of skills.

When a routine is triggered (e.g. motion detected) i would like to be able to run one of multiple possible routines (sub routines) depending on variable i could set in others.

For example i run a routine when i go to bed that turns off my lights and plays soft music for an hour. I would like to be able to also set the variable $inbed = true and then in my motion detected routine have if $inbed then table light on else all lights on and then my wake up/alarm routine can set $in_bed = false as well as turning on my lights and playing an alarm sound.