-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type of Alexa events #33
Comments
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. |
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: { 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:
Versus:
Versus:
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! |
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) |
Unfortunately the author here recently don't seem to be available, maybe he's busy and can't follow us.. |
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. |
Hi! You bring us good news, thank you! You said you use Openhub, I've never deal with it, does it works also with node red?
|
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. |
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. |
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. |
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. |
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. |
SUMMARY
I am trying to use this module with node-red-contrib-openhab2. It works but not fully. The issue is that I can't differentiate the type of Alexa events (such as turn on a light versus set the brightness to 50%). This means that I am limited to one type of event (on/off or brightness or color type). Looking at the code, I noticed that the topic is set to "":
}
Hello, I was wondering if it was possible to set the topic to the type of update sent to Alexa (I am making a big assumption of course, which is that Alexa is sending this info somehow). So, if I ask Alexa to turn on the light the topic would be "ON_OFF" or something and if I ask to sent the brightness to 50% it would be something like "PCT_BRI" and the same for Temperature and Color. This would allow me to write a function that would send the appropriate command to openhab2 based on the value topic? Is that possible. If not, how else can this be achieved?
ECHO DEVICES
Echo Dot 3rd gen
MODULE VERSION
CONFIGURATION
CONSOLE OUTPUT
STEPS TO REPRODUCE
EXPECTED RESULTS
ACTUAL RESULTS
The text was updated successfully, but these errors were encountered: