New Amazon Dot

[Ron Haley]

Just received the new amazon dot. Works great, easy setup giving I had the Echo.
Is there any way to distinguish within CQC which one is making the request? I'd rather not have to keep telling CQC which room I'm in.

[Ron Haley]

So I setup a new lamda function, just a change of key, and a new skill referencing the new lamda function with the new key and activated via a new invocation name. All works except CQC doesn't like the new key. All the information, including the new key, is passed to CQC correctly - it's in the log.

Am I missing something, or can't this be done?!

[Dean Roddey]

I'm not sure it will work to try to create two sets of backend functionality and use separate skills as a means to try to differentiate them. Well, if you did, you'd probably have to also load a separate web server on another machine and point the second one at it, on a separate IP address and all that. Otherwise they both come back to the same web server which can only have one configuration file.

[Ron Haley]

It seems to work except you have a key check in there

[Dean Roddey]

The check is a useful security feature, so I wouldn't want to get rid of that. In the end, given the many folks would have a number of these devices, setting up separate skills and maintaining them over time probably isn't a very viable solution either. Amazon really needs to add device identification info to make that work right. Then we can just include it in the information passed long to your action.

If more folks complain about it, maybe they'll do it. I've suggested it the questionaire thing they send out periodically.

[Ron Haley]

As you can see, it gave me everything I wanted. AAAAAA is the new key. Also, if I use the old key, the new lamda and skill work!

Perhaps we can put the keys in the config file for verification?
{
CQCWebSrvC, CQCWebSrvC_EchoHandler.cpp.791, Status/App Status
Key=AAAAAA, Intent=CQCSetOnIntent, Phrase=lights, Value=on
}
10/20 12:29:11-bedroomserver, CQCWebSrv, CQCWebSrvWorkerThread1
{
CQCWebSrvC, CQCWebSrvC_EchoHandler.cpp.804, Status/App Status
Rejected Echo request due to bad key
}

[Ron Haley]

BTW, even with my limited skills, it took just a few minutes to replicate the lamda function and skill And this would be another function that CQC can do but the standard Elexa can't. Who knows how long Amazon will take, if ever, to implement.

[Dean Roddey]

It's not hard to replicate. But, if you had 6 of them, and later we introduce some substantial improvements, you'd have to go back through them all again and make sure you got everything updated correctly.

On the other thing above, that's to be expected. If the incoming message doesn't have the key indicated in the config file, then it will be rejected. There can only be one config file, so there can only be one key. So the other one will always be rejected. If you use the same key in both of them, then they would both match the one in the config file.

But, you'd still only have one config file, so you couldn't have separate actions per source Echo device, unless you set up another web server instance on another machine.

We could of course update the config file to support multiple keys, with separate sections for each key, for folks who are willing to do it this way. But that would have to wait a while.

[Ron Haley]

I was thinking exactly that - multiple keys in the config file. Then we can make decisions on what to do based on the key. Turn on the lights would mean something for one key but different for another. Different lights, audio player, TV etc.
The other option is to allow "" for key in the config file. That rids the check.

[Ron Haley]

Or just check the first "n" characters, and the remaining characters for differentiation.