Announcement

Collapse
No announcement yet.

Multiple Alexa devices, how to tell them apart?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Multiple Alexa devices, how to tell them apart?

    This has been discussed in multiple thread but I thought I'd start one where all of the ideas on how to do multiple Alexa devices and tell them apart.

    Many have said there is no way to tell because Alexa devices don't supply that information. Well, that is totally false. Alexa does supply a unique identifier for every Alexa device. I've spend the last few days checking this out and running tests with other Alexa developers. In fact, I've even taken my copy of the HomeSeer Skill and pointed it to a site so I could see exactly what Alexa was sending to the HomeSeer endpoint.

    What follows is the JSON data that's sent to HomeSeer when any command for HomeSeer is issued to Alexa.
    Code:
    {
    	"version":"1.0",
    	"session":{
    		"new":true,
    		"sessionId":"amzn1.echo-api.session.087ce255-8deb-4501-9049-7cc0d64b2167",
    		"application":{"applicationId":"amzn1.ask.skill.52286855-6161-4a62-85f0-96d3336131bf"},
    		"user":{
    			"userId":"amzn1.ask.account.AENF...EX7A",
    			"accessToken":"2713...0448"
    		}
    	},
    	"context":{
    		"AudioPlayer":{"playerActivity":"FINISHED"},
    		"System":{
    			"application":{
    				"applicationId":"amzn1.ask.skill.52286855-6161-4a62-85f0-96d3336131bf"
    			},
    			"user":{
    				"userId":"amzn1.ask.account.AENF...EX7A",
    				"accessToken":"2713...0448"
    			},
    			"device":{
    				"deviceId":"amzn1.ask.device.AFUW...TZOA",
    				"supportedInterfaces":{
    					"AudioPlayer":{}
    				}
    			},
    			"apiEndpoint":"https://api.amazonalexa.com"
    		}
    	},
    	"request":{
    		"type":"IntentRequest",
    		"requestId":"amzn1.echo-api.request.b3155f56-cb1e-47b3-adc2-0f79b2906dc5",
    		"timestamp":"2017-07-13T19:24:46Z",
    		"locale":"en-US",
    		"intent":{
    			"name":"ParseText",
    			"confirmationStatus":"NONE",
    			"slots":{
    				"TextToParse":{
    					"name":"TextToParse",
    					"value":"turn on the dining room light",
    					"resolutions":{
    						"resolutionsPerAuthority":[{
    							"authority":"amzn1.er-authority.echo-sdk.amzn1.ask.skill.52286855-6161-4a62-85f0-96d3336131bf.HOMESEER_PHRASE",
                               				 "status":{
                                					"code":"ER_SUCCESS_NO_MATCH"
    							}
    						}]
    					},
    					"confirmationStatus":"NONE"
    				}
    			}
    		}
    	}
    }
    If you check the "context" section you'll find the following:
    Code:
    			"device":{
    				"deviceId":"amzn1.ask.device.AFUW...TZOA",
    				"supportedInterfaces":{
    					"AudioPlayer":{}
    				}
    			},
    In that piece of JSON text is the deviceId. The deviceId you see "amzn1.ask.device.AFUW...TZOA" has been edited as the real deviceId is much longer. This deviceId will remain the same until the echo is disabled on your account. If it is reenabled a new deviceId will be assigned.

    So HomeSeer does have access to the deviceId and thus can identify which Echo sent the command. The next issue is how to use this information.

    We can't use it as is since it's just way too long and not human friendly. What we need is to convert the deviceId into an echo name. One of the developers gave me an idea on that and I modified it a bit.

    Basically you need to issue a command on every echo so that HS will name that echo with something more useable. The simple way is to issue a voice command like "Alexa, ask HomeSeer to name me "Echo One". When HS received this command it would map the Alexa sending the request deviceId to "Echo One". You just need to use this command on every Alexa device you are using.

    Now we have something we can live with.

    So this is some food to work with. Now we can think about how this would be used. I have some ideas but I'll let others post ideas first.

    OMT, I don't know if deviceId is sent from the smart home api but I'm trying to find out. What I do suspect however is that it will have a different deviceId than the HomeSeer Skill so both would have to be mapped.
    Last edited by Timon; July 14, 2017, 03:52 AM.
    HomeSeer Version: HS3 Standard Edition 3.0.0.548
    Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
    Number of Devices: 484 | Number of Events: 776

    Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
    3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
    4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
    3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave

    Z-Net version: 1.0.23 for Inclusion Nodes
    SmartStick+: 6.04 (ZDK 6.81.3) on Server

    #2
    Unless you write your own endpoint, there is nothing that can be done using the current Homeseer Alexa Skills. HST have confirmed that all JSON requests from your Echo terminate at the HS servers and only the decoded text is sent to Homeseer.

    Passing deviceId and possibly other JSON information is on HST's 'to-do' list but I have not been given a time frame.
    Jon

    Comment


      #3
      Originally posted by Timon View Post
      Now we can think about how this would be used.

      OMT, I don't know if deviceId is sent from the smart home api but I'm trying to find out.
      Just confirming that yes, an echo's deviceId is exposed only if you enable the Device Address API on your skill. The most obvious way to use this (in a home automation context) is to manipulate devices in the same room without having to provide the full device name.

      However, deviceId is NOT (currently) provided when using the Smart Home Skill API...

      Comment


        #4
        Some of the newer APIs take advantage of DeviceID. For example, when you enable the Alexa API for the Dish Hopper, you need to specify which Alexa devices can control it. Presumably because when Dish enables you to register multiple Hoppers/Joeys you can program which Alexa devices control which.

        Comment


          #5
          Yeah, as long as it's a skill, and not the Smart Home API. So, I'm assuming when using the Hopper, you have to say something like "Alexa, tell Dish/Hopper to..." ?

          Unlike the Harmony Remote integration which uses the Smart Home Skill, allowing "Alexa, turn on Fox News" to be said to any echo in the house, but it only controls the TV which the Harmony is hooked up to.

          If you were to build your own skill, you'll see a section in the developer console to enable the device address API. What that does is allow your skill to access either the full home address or zip code that the user entered for their device. The purpose is for apps that can do some sort of product delivery, or respond to requests that need your zip code.

          Enabling that address API just so happens to also provide the deviceId, so that's the only way to get access to it right now. I don't use the HomeSeer skill anymore, but I'm pretty sure the Device Address API is not enabled (unless they've made changes recently) because if it were, then when enabling that skill, you'd be prompted for the skill to have permissions to access your device's address.

          I only use the Smart Home API (and I wrote my own) and can say for sure, that the ability to enable the Device Address API option is not present when building your own Smart Home Skill API. I've also dug through all the information provided when responding to requests using the Smart Home API and there is no device identifying information provided.

          So, as of right now, if you want the echo device's ID, it has to be done through a skill (not Smart Home API), and you'd have to build your own skill rather than using HomeSeer's.

          Comment


            #6
            Originally posted by jon00 View Post
            Unless you write your own endpoint, there is nothing that can be done using the current Homeseer Alexa Skills. HST have confirmed that all JSON requests from your Echo terminate at the HS servers and only the decoded text is sent to Homeseer.

            Passing deviceId and possibly other JSON information is on HST's 'to-do' list but I have not been given a time frame.
            The Alexa skill does not change but yes HomeSeer does need to capture the deviceId, which is already in the JSON packet, and do something with it. One of the points with this thread is for use to put forth some ideas on how we would like to see it implemented.

            This is the tricky part since all the HS server seems to do is pass the voice string to HS3. Somehow the Echo name would have to be passed but HS never even passed that from their own speaker clients.
            • So I see the following changes needed.
            • The HS server has to accept the deviceId from Alexa and convert it so something usable.
            • The speaker client protocol needs to be updated to allow a deviceId to pass.
            • The deviceId needs to be passed to HS3.
            • HS3 needs to make this available to any addons.

            Personally I think the best thing would be to encode a translated version of the deviceId in the voice string. The simplest way to do that is to make the voice string a JSON packet. Maybe something like this.

            {
            "version":"1.0.0",
            "deviceName":"What ever you want to call it",
            "voiceCmd":"Turn on the lights"
            }
            The above assumes that the deviceName has been translated. Example, for an Alexa the device name would have been translated from the deviceId. This way speaker clients, Google devices, Alexa or any other such device will work as they would all get translated.

            Oh, I would encourage HomeSeer to make this available to any developers so they could develop new VR devices which would not even need to come through the cloud such as Matrix Voice. With Matrix Voice developers could create a device that not only would respond to local commands for HS3 but can act as a Echo as well. So you would have two activation words, Alexa and if you want HomeSeer. So if you said "HomeSeer turn on the family room lights" it would but if you said "Alexa, play music" that would be sent to Amazon to process.

            Originally posted by DevinH View Post
            Just confirming that yes, an echo's deviceId is exposed only if you enable the Device Address API on your skill. The most obvious way to use this (in a home automation context) is to manipulate devices in the same room without having to provide the full device name.

            However, deviceId is NOT (currently) provided when using the Smart Home Skill API...
            I'm sorry to have to say this but you're wrong that you have to enable the Device Address API on your skill in order to get the deviceId. BTW, at first I though the same thing. I don't have Device Address enabled and the deviceId always comes through. This has been completely verified through developers that have developed many Alexa skills, They all say, and my test verified, that the deviceId ALWAYS comes through. I also verified that the deviceId changes whenever you enable the skill.

            The JSON packed I posted in my first post is exactly what I received from a query on my Echo and I DID NOT have Device Address enabled during the test. The only thing I changed was the actual codes since they had my device information in them plus the fact the codes are extremely long.

            Enabling the Device Address API only adds the ability to get the owners physical street address, zip code and state and has NOTHING to do with the deviceId field.

            I'm still checking if the deviceID, could be a different name, is passes when it comes to Smart Home Skills so I would comment if your right or wrong on this but I will find out.
            Last edited by Timon; July 16, 2017, 11:27 AM.
            HomeSeer Version: HS3 Standard Edition 3.0.0.548
            Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
            Number of Devices: 484 | Number of Events: 776

            Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
            3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
            4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
            3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave

            Z-Net version: 1.0.23 for Inclusion Nodes
            SmartStick+: 6.04 (ZDK 6.81.3) on Server

            Comment


              #7
              Interesting discussion. I've highlighted this thread to Wade who would be implementing the HS3 changes.
              Jon

              Comment


                #8
                Originally posted by Timon View Post
                I'm sorry to have to say this but you're wrong that you have to enable the Device Address API on your skill in order to get the deviceId. BTW, at first I though the same thing.
                Then that's a change they've made at some point. The reason I (and probably you) thought that is because that was indeed how it worked at some point.

                I'm not wrong on the Smart Home Skill API part of it though, for I've been actively developing using that API for quite some time. I do think it will become available at some point though, for it's a highly requested feature.

                Comment


                  #9
                  Originally posted by DevinH View Post
                  Then that's a change they've made at some point. The reason I (and probably you) thought that is because that was indeed how it worked at some point.

                  I'm not wrong on the Smart Home Skill API part of it though, for I've been actively developing using that API for quite some time. I do think it will become available at some point though, for it's a highly requested feature.
                  It's totally possible that a change was made. The only reason I know now that deviceId comes through was through the help of another developer. He let me access his end point debugging system so I could see the actual ISON data that was being sent to HomeSeer. He doesn't write any smart home apps so he's not setups to debug that data.

                  Still I would think they most have, or will have, a way to tell which Alexa device sent the command.
                  HomeSeer Version: HS3 Standard Edition 3.0.0.548
                  Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
                  Number of Devices: 484 | Number of Events: 776

                  Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
                  3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
                  4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
                  3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave

                  Z-Net version: 1.0.23 for Inclusion Nodes
                  SmartStick+: 6.04 (ZDK 6.81.3) on Server

                  Comment


                    #10
                    Originally posted by Timon View Post
                    Still I would think they most have, or will have, a way to tell which Alexa device sent the command.
                    Yeah, you'd think. It's even more irritating now, knowing they do it for general skills, which, I have no interest in using for home automation.

                    Here's a sample of the data I just captured while requesting the office light to be turned on.

                    event:
                    Code:
                    {
                      "header": {
                        "namespace": "Alexa.ConnectedHome.Control",
                        "name": "TurnOnRequest",
                        "payloadVersion": "2",
                        "messageId": "df10baf6-c517-4ef9-a570-9509e1220e48"
                      },
                      "payload": {
                        "accessToken": "Atza|I.......",
                        "appliance": {
                          "applianceId": "OfficeLight",
                          "additionalApplianceDetails": {
                            "deviceId": "4"
                          }
                        }
                      }
                    }
                    context:
                    Code:
                    { callbackWaitsForEmptyEventLoop: [Getter/Setter],
                      done: [Function: done],
                      succeed: [Function: succeed],
                      fail: [Function: fail],
                      logGroupName: '/aws/lambda/HollowaySmartHome',
                      logStreamName: '2017/07/18/[$LATEST]733ccbd8923c4350aa8c6e038db9df93',
                      functionName: 'HollowaySmartHome',
                      memoryLimitInMB: '128',
                      functionVersion: '$LATEST',
                      getRemainingTimeInMillis: [Function: getRemainingTimeInMillis],
                      invokeid: '6ae6e405-6b58-11e7-a5b9-d776f09afb12',
                      awsRequestId: '6ae6e405-6b58-11e7-a5b9-d776f09afb12',
                      invokedFunctionArn: 'arn:aws:lambda:us-east-1:...' }

                    The 'deviceId' in that event object is my own custom attribute, which maps to the switches ref value in homeseer. I use that, instead of the built-in 'applianceId' field because custom fields aren't required to be distinct... and so I can map multiple device names to a single device id.

                    But yeah... there's nothing there that identifies the echo device.

                    However, I'm using payload v2, and I'm now starting to see some references to payload v3. I'm wondering if v3 was recently introduced with the Echo Show and it's new abilities. I'll have to investigate that more. *Edit: nevermind v3 is just for "Entertainment Devices" right now.
                    Last edited by DevinH; July 20, 2017, 04:28 PM.

                    Comment


                      #11
                      I'd suggest you mask your lambda arn. As it stands, a malicious actor could create a skill pointing at your arn and wrack up charges on your AWS account.


                      Sent from my iPhone using Tapatalk

                      Comment


                        #12
                        Originally posted by Timon View Post
                        I also verified that the deviceId changes whenever you enable the skill.
                        Couple of questions and comments
                        1. What did you mean by the quote above?
                        2. Did you ever verify or otherwise the deviceID inside a SmartHome Skill?


                        With the advent of payload 3, things have gon eto a new level, allowing a smarthome skill to control AV and other non on/off/dim devices. Add in the deviceID and there are the basics for a powerful true home-control-by-voice with homeseer being the execution arm.

                        s.

                        Comment


                          #13
                          Payload v3 is only for entertainment devices right now. You still have to use v2 for other things. Even then, v3 does not contain device Id info. You can see what all it provides here:

                          https://developer.amazon.com/public/...-message-guide

                          Comment


                            #14
                            Originally posted by skavan View Post
                            Couple of questions and comments
                            1. What did you mean by the quote above?
                            2. Did you ever verify or otherwise the deviceID inside a SmartHome Skill?
                            The deviceId is assigned to the Alexa device when it's enabled on your account. If you disable the Alexa device then reenable the same device it will get a new deviceId.

                            No, as far as I can see there is no deviceId for SmartHome API so currently only Skills have a deviceId.

                            IMHO, Amazon engineers were totally asleep at the wheel when they didn't include a way to know which Echo device sent the message in the original design. Even now the way for endpoints to identify which Echo devices is overly complex. It should be just a simple name that you give your devices when you assign them to your account.
                            HomeSeer Version: HS3 Standard Edition 3.0.0.548
                            Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
                            Number of Devices: 484 | Number of Events: 776

                            Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
                            3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
                            4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
                            3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave

                            Z-Net version: 1.0.23 for Inclusion Nodes
                            SmartStick+: 6.04 (ZDK 6.81.3) on Server

                            Comment


                              #15
                              I agree that the entire industry is asleep with all of this technology. Mainly because many of them do not understand the use cases that folks like us want to use this technology.

                              Like others have stated, the Alexa development team never thought that this technology would be as successful as it has been.

                              The main reason it is so successful or used or used in terms of its popularity is because it is "open" technology. This is unlike other technologies like SIRI and such. Though, I have managed to get SIRI to do most of the things that I really care about. But, I just get sick to my stomach thinking about what Apple could do if they would just hire certain more of developers on the SIRI team in terms of what they could achieve.. I mean, with 230 billion $$$ in cash, one would think that there should not be any limits to these technologies.

                              Whatever... Oh well.
                              HomeSeer 2, HomeSeer 3, Allonis myServer, Amazon Alexa Dots, ELK M1G, ISY 994i, HomeKit, BlueIris, and 6 "4k" Cameras using NVR, and integration between all of these systems. Home Automation since 1980.

                              Comment

                              Working...
                              X