All my home automation devices use the Z-Wave radio protocol (sockets, lights, shutters, sirens, etc ...) and only one uses the ZigBee protocol: the Philips Hue lamp purchased with my Echo Plus.

I also have other connected objects (Netatmo weather, Netatmo security, Foscam camera, GreenIQ, Harmony Elite) each with their own communication mode.
Mostly all these devices have a set of APIs and, thus, I can manage all these objects from my home automation box Fibaro.

ALL EXCEPT my Philips Hue bulb which is managed ONLY FROM my Echo Plus.

So here's the improvement I'm asking for: be able to locally control ZigBee devices connected to my Echo Plus.
I'm thinking about locally operating API set (192.168..). Locally, which means directly from my local network, without any cloud which could be down.

Here is an example calling a Fibaro API to light a lamp controlled by a Zwave module: "http://192.168.10.xx/api/callAction?DeviceID=296&name=turnOn" where 192.168.10.xx is the local address of my Fibaro box.

I think I am not the only one who ask this improvement and I hope it will be taken into account. This would "open" this ZigBee Hub to existing home automation solutions.

Regards

Simple voice control of DIY devices could be achieved if the Routines section of the Alexa App had an option to do an HTTP POST.

eg/ I have a home-made lamp (based on an ESP8266) which I currently control using a custom skill that drops the JSON payload to a Linux server which interprets it then does a HTTP POST to the lamp's URL with the required mode as a parameter. ("mode=candles"/"mode=off"/"mode=purple"...etc)

I could (and other hobbiests and educators could) much more easily have implemented this with an Alexa Routine identified by "make it candle time" with a line in the routine which would hike the command over to the lamp's URL without the need for the custom skill or my local server.

The POST option would need to accept a HOST:PORT combination in order to perform appropriate routing to devices once it hits someone's router.

This would open up opportunities for people to implement voice control of custom devices without the need to create a skill, have their own server or implement forwarding in AWS.

More than 1 million Bulgarian immigrants scattered across the globe are struggling to preserve their cultural identity/heritage and to pass it over to their children. There are Alexa skills (like "Bulgarian library" skill) which could help them teach BG-language to their children however currently Amazon does not allow access to this skill from anywhere except US,UK,CA,AU. Most of the world (Germany, France, Italy, Spain, etc) has no access to it. So, in this case splitting the globe into regions makes no sense whatsoever.

Would be greatly appreciated by thousands of people IF Amazon allows access to skills which are outside the physical "region" a given person currently resides into (without having to give up all other services tied to that region)

One way to accomplish this is:
As part of certification process, in "opt in for auto distribution" to have additional "exempt from local interaction-model requirement" checkbox along with "why you need this ?" text box where basically the developer could ask for a given skill to be distributed (say in Germany) even though only English interaction-model is implemented. This would be rare case anyway and Amazon still keeps the right to allow if reasonable or deny such request.

Thanks for consideration

A public S3 bucket is used to host skill icons, audio files, images, and videos for Alexa skills. This feature adds a new deploy target to the ASK CLI.

Configuration for the bucket name and region would be stored in '.ask/config'
$ deploy --target s3

The would sync all files and folders in a known local folder to the bucket at: https://s3.amazonaws.com/my-bucket/

The first time this is done, the bucket will be created and a CORS configuration applied.

Calling 'ask deploy' will also sync local folders and files to S3. Because the skill icon can be hosted in the S3 bucket, deploy to s3 will occur before the deploy of the skill.json file.

Behind the scenes, the following commands will be called:

make bucket

aws s3 mb s3://{bucket-name}/ --profile {aws-profile-name}

set CORS

aws s3api put-bucket-cors --bucket {bucket-name} --cors-configuration file://.deploy-s3/s3-cors.json --profile {aws-profile-name}

File: s3-cors.json
{
"CORSRules": [
{
"AllowedOrigins": ["*"],
"AllowedHeaders": ["Authorization"],
"AllowedMethods": ["GET"],
"MaxAgeSeconds": 3000
}
]
}

sync s3

aws s3 sync ./.deploy-s3 s3://{bucket-name}/ --profile {aws-profile-name} --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers

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.