Type of Alexa events about node-red-contrib-amazon-echo

[Barabba11]

Hi, I've already noticed it to the author, but the issue was not solved. He simulates the Philips bulb and Alexa has already internal specifications what a Philips bulb is expecting to receive. Seems that Always Alexa tells him the brightness, even if the command is just "switch on". Looks really pity if true.
When Alexa just reboot and never had previous brightness settings of that light it uses 255, maximum.

[verjus]

I am studying the code and made some progress. As I understand, the author (thank you for creating this BTW!) is keeping a representation of the state of each item connected to the hub in the node context (he does initialize it to some arbitrary values but after the first command coming through Alexa, the state is updated). From what I understand, he does this so that the state can be compared with a new state sent through the input node. If the state is found to have changed, a command is sent to the item to update it to the new state (i.e. sync with the item state). However, this does not seem relevant to the issue. To find out more, I added a debug line in the code ( hubNode.warn(req); ) that informs on what Alexa is sending and I can see the following output:

{
"_body": true,
"_consuming": true,
"_dumped": false,
"_events": {},
"_eventsCount": 1,
"_parsedUrl": {
"_raw": "/api/c6260f982b43a226b5542b967f612ce/lights/d312bc835a7ee8/state",
"auth": null,
"hash": null,
"host": null,
"hostname": null,
"href": "/api/c6260f982b43a226b5542b967f612ce/lights/d312bc835a7ee8/state",
"path": "/api/c6260f982b43a226b5542b967f612ce/lights/d312bc835a7ee8/state",
"pathname": "/api/c6260f982b43a226b5542b967f612ce/lights/d312bc835a7ee8/state",
"port": null,
"protocol": null,
"query": null,
"search": null,
"slashes": null
},
"_readableState": {
"autoDestroy": false,
"awaitDrain": 0,
"buffer": {
"head": null,
"length": 0,
"tail": null
},
"decoder": null,
"defaultEncoding": "utf8",
"destroyed": false,
"emitClose": true,
"emittedReadable": false,
"encoding": null,
"endEmitted": true,
"ended": true,
"flowing": true,
"highWaterMark": 16384,
"length": 0,
"needReadable": false,
"objectMode": false,
"paused": false,
"pipes": null,
"pipesCount": 0,
"readableListening": false,
"reading": false,
"readingMore": false,
"resumeScheduled": false,
"sync": false
},
"aborted": false,
"baseUrl": "",
"body": {
"bri": 77
},
"client": "[internal]",
"complete": true,
"connection": "[internal]",
"headers": {
"accept-encoding": "gzip",
"connection": "close",
"content-length": "10",
"content-type": "application/json",
"host": "192.168.1.100",
"user-agent": "Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6529)",
"x-forwarded-for": "192.168.1.109",
"x-forwarded-proto": "http",
"x-real-ip": "192.168.1.109"
},
"httpVersion": "1.0",
"httpVersionMajor": 1,
"httpVersionMinor": 0,
"method": "PUT",
"originalUrl": "/api/c6260f982b43a226b5542b967f612ce/lights/d312bc835a7ee8/state",
"params": {
"id": "d312bc835a7ee8",
"username": "c6260f982b43a226b5542b967f612ce"
},
"query": {},
"rawHeaders": [
"Host",
"192.168.1.100",
"X-Real-IP",
"192.168.1.109",
"X-Forwarded-For",
"192.168.1.109",
"X-Forwarded-Proto",
"http",
"Connection",
"close",
"Content-Length",
"10",
"Content-Type",
"application/json",
"User-Agent",
"Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6529)",
"Accept-Encoding",
"gzip"
],
"rawTrailers": [],
"readable": false,
"res": "[internal]",
"route": {
"methods": {
"put": true
},
"path": "/api/:username/lights/:id/state",
"stack": [
{
"keys": [],
"method": "put",
"name": "",
"regexp": {
"fast_slash": false,
"fast_star": false
}
}
]
},
"socket": "[internal]",
"statusCode": null,
"statusMessage": null,
"trailers": {},
"upgrade": false,
"url": "/api/c6260f982b43a226b5542b967f612ce/lights/d312bc835a7ee8/state"
}

Changing the type of command (e.g. Alexa, turn on bulb / Alexa, set brightness to 50% / Alexa, set color to Cool White), shows that the only difference between the types of commands are in the body part:

"body": {
    "on": true
},

Versus:

"body": {
    "bri": 77
},

Versus:

"body": {
    ct: 199
},

This means that it is possible to track the type of update and pass it along with the message. This may be done in the topic part or other else. I will try to modify the code but I don't really know Javascript, unless someone beats me to it!

[Barabba11]

Bravissimo! Well done! )) More, I can see some IP addresses too! Is one of them the Alexa IP? If so it's possible to add to the same IP domain different Alexa but let them manage only some devices (for example curtains on the first and second floor, calling them with the same name)
May you say in your case which IP has your Alexa and which has your Raspberry? (If you run this under raspberry)

[Barabba11]

Unfortunately the author here recently don't seem to be available, maybe he's busy and can't follow us..

[verjus]

Yes, "192.168.1.109" is the Echo Dot 3 and "192.168.1.100" is the host running node-red. I also have a Raspberry Pi running Openhab2, but it doesn't show here because I connect the output of this module to the module node-red-contrib-openhab2 (via a function).

I have managed to hack the code to achieve what I wanted. It's actually surprising simple, mostly because the code is so well written. Here is a diff between the original and the modified one:

diff index.js index.js.or

13c13
<             // msg.topic = config.topic;
---
>             msg.topic = config.topic;
81c81
<               payloadHandler(hubNode, msg.payload.deviceid, "");
---
>               payloadHandler(hubNode, msg.payload.deviceid);
209,212c209
< 	var subject = "";
< 	if (Object.keys(req.body).length > 0 )
<           subject = Object.keys(req.body).toString();
< 	//hubNode.warn(req);
---
> 
224c221
<         payloadHandler(hubNode, req.params.id, subject);
---
>         payloadHandler(hubNode, req.params.id);
360c357
<     function payloadHandler(hubNode, deviceId, subject) {
---
>     function payloadHandler(hubNode, deviceId) {
366c363
<       msg.topic = subject;
---
>       msg.topic = "";

This hack allows me to achieve my desired results, which is to allow me to turn on the light, change the brightness, change the color temperature and the color of a lamp with a voice command ("Alexa, set brigthness of bulb to 10%") . For example, changing the brightness via Alexa now produces the following output:

{"on":true,"bri":125,"hue":21845,"sat":254,"ct":199,"colormode":"hs","rgb":[0,255,0],"payload":"on","deviceid":"d312bc835a7ee8","topic":"bri","_msgid":"2383fe0e.bace42"}

and changing the color temperature via Alexa produces:

{"on":true,"bri":64,"hue":21845,"sat":254,"ct":383,"colormode":"ct","rgb":[0,255,0],"payload":"on","deviceid":"d312bc835a7ee8","topic":"ct","_msgid":"eb4c0ea4.e95a7"}

It is now possible to write an adapter function for openhab2 or other system that looks at the message topic and picks up the correct value for the payload to be injected into an Openhab2 Out node:

var newMsg = {  payload: "",
                topic:"ItemCommand" };

switch (msg.topic) {
    case "on":
        newMsg.payload = msg.payload.toUpperCase();
        return ([newMsg, null]);
    case "bri":
        newMsg.payload = Math.ceil(msg.bri/256*100).toString();
        return ([newMsg, null]);
    case "ct":
        newMsg.payload = (100*(msg.ct-153)/(500-153)).toString();
        return ([null, newMsg]);                   
    default:
}

Note that these modifications could be integrated into the AmazonEchoDeviceNode of this module but it would make the module specialized towards openhab2. Modifying the code yourself is actually quite easy but it only saves writing an adapter function. On the other hand, it would be cool to be able to just install both modules, link them and enjoy! No coding required! Another option would be to incorporate the adapter function in the form of additional nodes for each major HA systems into this module.

This is a great module and I hope the author will consider incorporating the equivalent functionality into his module in the future.

[Barabba11]

Hi! You bring us good news, thank you!
I really hope the author will soon read this post and give his opinion about it!
I'm really looking for these two solutions, to pass the info of what exact command was provided and which IP address it generated it. To be honest it's not all, I need also to filter the IP address to let only one Echo find that device, so it's needed a deeper edit of the code.

You said you use Openhub, I've never deal with it, does it works also with node red?
What are numbers like "366c363" for?

means put new code and < remove that code?
In the first example you said Alexa 10% but you have "bri":125 (which is 49%)
Thanks for clearing

[verjus]

It's using the unix diff command. The numbers refer to the line number. But since the changes are limited you can do the changes manually with a text editor to the index.js file in the node-red module directory. The lines with a "<" are the changed version and the lines with a ">" are the original ones. Just search each lines and edit them. Yes, openhab2 works with node red when using the module node-red-contrib-openhab2 module. Yes, the IP address could be passed along but that would require more changes to the code. I am just using the msg.topic element to pass along the changed state but I am not sure it's appropriate. Let's see what the author says. Yes, the value of bri:125 is not consistent with the example, I picked the output of another command for the example.

[Barabba11]

Thanks for your kind reply, honestly I still a beginner of Javascript and I?m afaid to make mistakes, unfortunately the place where I'm using this module is at home of my client and I can't create him problems if after something can fail.. I have very few chances to experiment and using time while I'm at his place.
There is another additiona problem, which I'm really afraid of, it's the possibility to have as result different ID names of devices in Node Red, and Alexa will not recognixe them more, need to be searched again, and to do this I need to remove all devices, reset Alexa and search again (due to an Alexa recent bug), and the client has the account only.. so it's creating him problems, I asked him already twice, I don't want more. The only chance I have is to update manually the .js files, or upgrade, when the author will release a new update.
I really hope the author may introduce it and a IP filter on the device, by that IP the device may answer or not to that Alexa IP, means it can be recognized or not recoglized by that Alexa, means I can use the same name for devices in different Alexa connected to the same Node Red (for example "Alexa open the Curtains" instead of "Alexa open the curtains of the second floor")
Are maybe you interested to implement this? Thank you

[verjus]

I tried to see if the IP address coming req.header["x-real-ip"] corresponds to the Echo Dot picking up the voice command but unfortunately, it does not. It's always the same IP, not matter which Echo I talk to. I suspect it's the IP address of the Dot that did the discovery. I unplugged the Dot corresponding to that IP and tried to give a voice command. Interestingly, Alexa wasn't able to control my lights anymore. When I re-plugged that Echo, it worked again as before. Maybe there is a way to have bulbs discovered by different Echos by creating different sub-networks or initiating the discovery from different Echo Dots. Or maybe unplugging them and having each discover a different set. Doesn't seem likely to work well. We seem limited by the way Amazon designed it.

[Barabba11]

Thank you my friend to report it, sorry for my delay on answer. Yes itneresting, are both dots connected to the same Amazon account? If so as I believe probably Amazon will use the first Echo who searched and associated the device as a "gateway" to send device the commands. Maybe this is decided due to the limits a device may have, a limited number of associations for example. In this case to avoid any problems of compatibility with all devices they prefere that only one Echo. Since all should be connected to internet to understand the vocal command then we suppose all devices are always connected to network, so no issues if internet is ok for both Echo.
In my case I've different accounts and separated devices for each Echo, if I need the same deviced for both I'll create 2 devices in Node Red and connect the outputs together. Actually it's not possible to test this because there is no IP filter in the module, and both Alexa will recognize the same device. Did you ever find in the module script where module replies to Echo with onfos about the device (I suppose its ID), and is the ID generated from NR when we deploy for the first time the device on the flow? This is interesting..
Thank you

[datech]

Based on the changes introduced by #67, I consider that we can close this issue as meta attribute includes request input and changed device state attributes, which is entirely enough to distinguish different Alexa events/commands.

If you still prefer to use the topic attribute you might consider using @verjus modificatons.