Differentiate between "On", "Off" and "DIM" or other commands about node-red-contrib-amazon-echo

[verjus]

If you don't want to make the changes above yourself, you can use the version in my fork above. The only files I've modified from the original are index.js and index.html. So you would need to simply replace these two files in the directory /home/pi/.node-red/node_modules/node-red-contrib-amazon-echo/ and restart node-red. Be advised that I made 2 other changes to the original. The first change is that I require each amazon-echo-device node id (nodeid) to be given a friendly name in the configuration step. This friendly name (FriendlyName) can be anything and just needs to be unique. For example, Hue_5 or KitchenLight. I use zigbee2mqtt and set the same name in node-red as in zigbee2mqtt for consistency and simplicity. The reason I made this modification is that I can now send an input message to the echo-hub node of the form: Payload:{"on":true, "bri":11, "nodeid": "Hue_5"}. If I set the topic to Brightness, this will set the brightness of the bulb with FriendlyName Hue_5 in this example. If topic is left blank, than the state is simply updated internally, without changing the bulb state. This is the second modification I made to the code. If you don't use the input node, ignore all this and just set friendly names once for each node.I have tested these modification extensively and they work well for me and my setup. Also, if you now look at http://<NODE_RED_IP>/api/pi, you will see that the friendly name is used as well. This lets you find the relationship between FriendlyName and the name Alexa uses (name). A side effect (I've not tested this) is that maybe you don't need to do the rediscovery when making changes as long as you don't add new lamps in Alexa.

Let me know if you have more questions.

[verjus]

Hello Datech,

Thank you for given us this opportunity to comment.

Your implementation is conceptually different from what I tried. The way I approached this was to simply pass along the body of the request from Alexa (req.body) to the msg.payload.

If I understand correctly, in your implementation you update the current state with the request from Alexa as before, but you than look for differences between the updated state and previous state. The differences are reported in the changed attribute of the output msg.

I am not sure about this (I haven't tested it) but doesn't this introduce a dependency on the previous state? If the previous state was changed by the input node, for example on:false, and Alexa is asked to turn off that lamp, nothing will be reported in changed, right?

Wouldn't it be simpler to just pass along the req.body from Alexa?
Or keep the "changed" attribute but also pass along the request from Alexa (req.body) in msg.payload as above?

[verjus]

I agree, but for me, however, it is more intuitive to just pass along the request from Alexa (with the current state). That way, if I say turn off the light, I get the new state and the command that was used to change the state in the payload. The command is more important to me than the state because the state might not always be in synch with the physical state. It is also more intuitive to have the this command in the msg.payload. It is also more consistent with other systems, such as Openhab, that require a command in input. I have switched to Zigbee2mqtt and it can do both.

I think both work and are more or less equivalent. I just find it more intuitive to receive the new state along with Alexa's request in the message payload.

Finally, I wanted to thank you again for publishing and maintaining this great software that I enjoy using every day!

[verjus]

Not sure why. Do you see the expected info when you look at <IP_address>:80/api/pi ?
In my case, I see:

{"lights":{"Hue_1":{"state":{"on":false,"bri":254,"hue":0,"sat":254,"effect":"none","xy":[0,0],"ct":199,"alert":"none","colormode":"ct","mode":"homeautomation","reachable":true},"swupdate":{"state":"noupdates","lastinstall":"2019-10-04T16:11:36"},"type":"Extended color light", "name":"Kitchen Light", "modelid":"LCT007","manufacturername":"Philips","productname":"Hue color lamp","capabilities": (...),
"Hue_1" is the Friendly Name and "Kitchen Light" is the Alexa Name.

Also, when you put a debug node at the exit of the Alexa Hub, do you see any message coming through? You should see something like:
{"on":false,"bri":254,"hue":0,"sat":254,"ct":199,"colormode":"ct","rgb":[255,0,0],"payload":{"on":false},"deviceid":"Hue_1","topic":"","_msgid":"xxxxxxxxxxx"}

The deviceid should match the friendly name ("Hue_1" in my case).

The state information is kept in a flow context (see here for more info). You can see that context by looking under "Context Data" in the Node Red panel (under the arrow pointing down all the way to the right. You should see under Flow something like:

Hue_1 | { on: false, bri: 254, hue: 0, sat: 254, ct: 199 … }

My last thought is that if you don't have any output at all, maybe the code is not running properly. It might be that when you download the file, you introduced some funny characters or formatting and the code doesn't run because of an error. Make sure you downloaded the code in raw mode from github and maybe conpare the downloaded version with the original or make the edits yourself starting from the original code. Start by just changing the function payloadHandler(hubNode, deviceId, body) as described above.

[thePhilipp]

put a debug node behind the alexa node and set it from msg.payload to full msg. then you can see, there is also a msg.bri. you can seperate this value with a function node and send it to the bri objekt in iobroker

[MosesHill]

I know, but it is still not possible. Take this scenario:
"Alexa, turn on the Light". "Alexa, dim the Light to 25%".
The user now changes the dim manually to 50% in the room. And later turns the light off manually.
"Alexa, turn on the Light" - this will now give 25% Light.
If instead your node would differentiate between ON, OFF and DIM, it would be possible to only send the ON command and thereby keep the Light at the 50% as it was intedend.

[thePhilipp]

ok I understand. Does the manual dimmer give any feedback to ioBroker? Then you could save that value and send it in the next time, turn on the light. What kind of hardware setup do you have?

[thePhilipp]

you could also try what happens if you just leave the msg.bri away. So filter out the value via a function node. I will also try it

[MosesHill]

The physical switches/dimmers... in my house must remain intact (working) even if network, MQTT server ... do not work. So that is why they must be able to work separately. When I use the physical switch and the digital system (Alexa, remote or what ever) in a mix all the time, only the physical dimmer is allowed to remember the last dim setting.
And there is no feedback from for example a LIVOLO component - only a 433Mhz control signal TO the switch/dimmer.

So there must be a ON command (setting it to the last dim % selected) and a DIM command to change the Dim %.

The OLD Contrib_Alexa_Local had that feature by a parameter called "On_Off_Command", which was true if the command was either "ON" or "OFF" and false if it was a "DIM" command.

[verjus]

I had a similar requirements so I modify the code as follows, which is along the same lines you're asking. The modification is simple and entails passing the variable body, which contains the Alexa response, to the msg.payload. The original handler is:

    function payloadHandler(hubNode, deviceId) {

      var msg = getDeviceAttributes(deviceId, hubNode.context());
      msg.rgb = colorSHB2RGB(msg.hue, msg.sat, 254);
      msg.payload = msg.on ? "on" : "off";
      msg.deviceid = deviceId;
      msg.topic = "";

      hubNode.send(msg);
    }

I've modified it as follows:

    function payloadHandler(hubNode, deviceId, body) {

      var msg = getDeviceAttributes(deviceId, hubNode.context().flow);
      msg.rgb = colorSHB2RGB(msg.hue, msg.sat, 254);
      msg.payload = body
      msg.deviceid = deviceId;
      msg.topic = "";

      hubNode.send(msg);
    }

Then in the portion of the code that handles the Alexa put, modify the call to the handler from:

app.put('/api/:username/lights/:id/state', function (req, res) {

        setDeviceAttributes(req.params.id, req.body, hubNode.context());

        var template = fs.readFileSync(__dirname + '/api/hue/templates/lights/se

        var data = getDeviceAttributes(req.params.id, hubNode.context());

        var output = Mustache.render(template, data);
        output = JSON.parse(output);

        res.json(output);

        payloadHandler(hubNode, req.params.id);
      });

to:

      app.put('/api/:username/lights/:id/state', function (req, res) {

        //hubNode.warn(req);
        setDeviceAttributes(req.params.id, req.body, hubNode.context().flow);

        var template = fs.readFileSync(__dirname + '/api/hue/templates/lights/se

        var data = getDeviceAttributes(req.params.id, hubNode.context().flow);

        var output = Mustache.render(template, data);
        output = JSON.parse(output);

        res.json(output);

        payloadHandler(hubNode, req.params.id, req.body);
      });

As you can see, req.body contains the Alexa payload that is put to the node red server. This variable is passed along to the function payloadHandler in a a new variable called body and is assigned to the payload (msg.payload = body).

The result is that if you ask Alexa to turn on the lights, you'll receive something like this:

{"on":true,"bri":254,"hue":0,"sat":254,"ct":199,"colormode":"ct","rgb":[255,0,0],
"payload":{"on":true},
"deviceid":"Hue_3","topic":"","_msgid":"891b1c63.e68a6"}

and

if you change the brightness, you get:

{"on":true,"bri":128,"hue":0,"sat":254,"ct":199,"colormode":"ct","rgb":[255,0,0],
"payload":{"bri":128},
"deviceid":"Hue_3","topic":"","_msgid":"238455e2.7ca5ca"}

That way, you have the entire state and the portion that was changed in the payload, just as you requested.

You can just make these modification to the index.js code in your installation. I've created my own branch with this and other modifications here, BTW.

[MosesHill]

Yes verjus !
That was exactly, what I need. Thank you.
Tried it out and it works just fine.

[Barabba11]

thank you verjus for your kind contribute!
Can you please tell me, is it just necessary to stop node red, overwtite the file /home/pi/.node-red/node_modules/node-red-contrib-amazon-echo/index.js with yours, and start again the node?
Thank you

[Barabba11]

Thank you for your kind reply! As you tested and introduced some new features I hope Datech will include your ready code to his next release! :) I see he's back here )))

[Barabba11]

One question yes, now this friendly id name is saved in the backup (export of flow) too? Because another limitation of this module is that it lets node red assign an ID, and every time it will be different. Probably because of this if you restore a backup you have to delete all devices stored in Alexa and recognize them again..
Have you tried it? Thanks

[verjus]

I checked and it appears to be saved in the backup, since the friendly name is part of the configuration of each node. I have not tried but if I had to guess, I would say it should work. On Monday, September 23, 2019, 11:06:45 PM PDT, Barabba11 <[email protected]> wrote: One question yes, now this friendly id name is saved in the backup (export of flow) too? Because another limitation of this module is that it lets node red assign an ID, and every time it will be different. Probably because of this if you restore a backup you have to delete all devices stored in Alexa and recognize them again.. Have you tried it? Thanks — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Barabba11]

thanks for your answer. Unfortunately to be sure it's needed to delete the flow and import it again, but doing it you risk to rediscover all devices of Echo again.
The key is to understand what ID is sent to Echo as the device itself, did you may discover it in the code? Is sent the ID Node Red creates automatically for the new node placed on the flow? If so maybe your friendly name will not be used/sent.
Maybe a solution is to backup the actual flow file, in case the restore will not work you may overwrite it with the old one. Unfortunately I can't make these tests as the Raspberry is located alsewhere ((

[Barabba11]

@verjus I have a problem here,
I stopped node red, copied (overwrite) index.html and index.js, the origina updated author's ones, started but I don't see any difference downloaded from the previous version, still no difference in the packets output from the node when I say "Alexa switch on.. or alexa change intensity to.. ", maybe the author still not update them yet?
I've tried yours and I have no output at all!! I checked inside modules, there is possible to change the node name and the topic, in the hub only th port and enable input. I put back the recent original files and again I have output.. What is going wrong here?? amazing
Thanks for help

[Barabba11]

With the author's one I got also strange behaviour. The forse command I told Alexa is to regulate intensity, I had the vale on:false (with the proper bri value), I tried again, again false (but proper bri value), I told switch on and it went on:true, I told to change bri, it did with on:true. I told to swithc off, it gave on:false, I told to change intensity and this time on went true and bri was correct as always..
Is the problem may come from Alexa? Strange

[Barabba11]

@verjus with your script, from HUB
object
on: true
bri: 128
hue: 0
sat: 254
ct: 199
colormode: "ct"
rgb: array[3]
payload: object
deviceid: "8fa94a2de60c4"
topic: ""
_msgid: "a12d78b9.557078
Topic always "" with a on/off command or BRI

Author HUB output:
on: false
bri: 128
hue: 0
sat: 254
ct: 199
colormode: "ct"
rgb: array[3]
percentage: 50
payload: "off"
deviceid: "8fa94a2de60c4"
topic: ""
_msgid: "b06742ab.d5a81"
After starting node red, Echo was not restarted, told only command to change intensity, on is false (??)

object
on: true
bri: 128
hue: 0
sat: 254
ct: 199
colormode: "ct"
rgb: array[3]
percentage: 50
payload: "on"
deviceid: "8fa94a2de60c4"
topic: ""
_msgid: "d0f2c280.d773"
With command switch it on

object
on: true
bri: 153
hue: 0
sat: 254
ct: 199
colormode: "ct"
rgb: array[3]
percentage: 60
payload: "on"
deviceid: "8fa94a2de60c4"
topic: ""
_msgid: "6f720478.c0d0dc"
told to change intensity to 60%

[Barabba11]

I checked again, there is a bug in the script, if after restart is told to change intensity it will keep the on to false. After switching it on, off and give intensity again it goes to on true.

[verjus]

Hi Barabba11,
If you're using my version, you need to set the friendly name in the node configuration. Here is what I get in output after asking Alexa to turn on the light:
{"on":true,"bri":254,"hue":0,"sat":254,"ct":199,"colormode":"ct","rgb":[255,0,0],
"payload":{"on":true},
"deviceid":"Osram",
"topic":"zigbee2mqtt/Osram/set","_msgid":"66c8301c.d9e5e"}

Here is the output after a change of brightness:

{"on":true,"bri":52,"hue":0,"sat":254,"ct":199,"colormode":"ct","rgb":[255,0,0],
"payload":{"bri":52},
"deviceid":"Osram",
"topic":"zigbee2mqtt/Osram/set","_msgid":"fa2cb487.dd0f08"}

Note the payload. The first time it contains {"on":true}, which is what was asked from Alexa and the second one, "payload":{"bri":52}, which corresponds to setting the brightness to 20%.
Also, note that the deviceID contains the friendly name that I assigned in the node configuration (Osram).

The output you show is not consistent with my version. Maybe you are not getting any output because you haven't set the friendly name and the node doesn't get a match on names.

[Barabba11]

Thank you a lot for your kind quick answer, how can I set the friendly name? In the node there isn't such option, only the name of the node and the msg.topic that it will return as output. Should I delete all nodes and drag to flow new nodes? Only in that way the friendly name will appear in the options?

Another thing, which I suppose I haven't catch right, after set the friendly name somehow, will the Node Red export it as backup and an eventually restore of the flow will not mean to reset alexa and configure it again from reset?

Last one: have you checked if the bug affects your script too? Stop and start node red, and give as first command to Alexa the intensity, check your msg.on if is false.
Thank you!

[verjus]

I don't think you need to delete the nodes. After replacing the original index.js and index.html and restarting Node Red, you need to refresh the browser so that it reloads the modified index.html. Force reload or close and re-open the browser. You should than see the option to enter a friendly name in the configuration of each Echo Device Nodes. Set it to anything you want, as long as it's unique. Also, try a few times sending a request via Alexa so that the context is set for each node (you can check in Node Red under Context Data on the left panel with a arrow pointing down). BTW, this name is independent from the name of the node, which is used by Alexa. In my setup, I give it the same friendly name that I use with Zigbee2mqtt. This provides me with easy integration. From what I understand, the original author chose a different approach, using the name of the name as an alternative.

Hope this helps!

[Barabba11]

thank you, it helps, I'll try as soon as I can!
So seems the Alexa will get the ID of node, so export/import isn't possible, the only way to backup seems copy the flow .js file

[datech]

@MosesHill, @verjus, @Barabba11

Please, let me know if the changes introduced in #64 will work for you.

[Barabba11]

Agree. If I may suggest, it would be great to pass on an object all possible parameters that Alexa sending, and let us filter them to catch what we may find can be useful.. I don't know if for example there can be also the IP source address..
Thank you!

[datech]

On the questions:

"If the previous state was changed by the input node, for example on:false, and Alexa is asked to turn off that lamp, nothing will be reported in changed, right?"

Yes, the changed attribute will be empty, but do we really need to do something with the payload if the devices state is not updated?

"Wouldn't it be simpler to just pass along the req.body from Alexa?
Or keep the "changed" attribute but also pass along the request from Alexa (req.body) in msg.payload as above?"

Having changed values could help you if you want to know how the state is modified.
For example:

• the color is changed from green to red
• the brightness is changed with more than 20%
• the device color mode is changed from ct to hs

The Alexa input or the input payload, if you send it directly to the hub, is already visible in the output, because the state is modified based on the requested values

[Barabba11]

Datech can you please provide us the command? It will really simplify also my flow, thanks. Moreover I don't need to fail the first time after reload because I don't have a previous value to compare.
About the first value, have you checked the bug returning an on:false if the command asked Alexa was a bri only?

[datech]

Definitely, it is more natural to think about the input instead of the changed attributes.

I will include the request also.

[Barabba11]

@vejus I still have no results, sorry, I overwritten the files, started again NR and yes with a refresh of the page I?m able to see freindly name. I put inside lijasdkljasdk as unique name, I told different requests to Alexa, I restarted again, no outputs coming.
By the way I haven't understand what you meant with "Also, try a few times sending a request via Alexa so that the context is set for each node (you can check in Node Red under Context Data on the left panel with a arrow pointing down)", what is this and what is this for? I don't think it's crucial to have an output..

[Barabba11]

Thanks for your help, I know what you mean, I can assure you the files are dragged fom the zip file (winrar) and dropped to MobaXterm_Personal_11.0, in the same way I extract the Datech files and it become work again, so no dubts about that.
You're telling me that putting a dubug node on HUB will give friendly name, how HUB knows it? I thought it was a parameter of the device node, but maybe the script telling HUB to use it. Because I'm thinking if this friendly name you should specify too in Alexa app, so Echo sends it and that's why it exit from HUB..
You're suggesting me to place a debug node after hub, I did with Datech in past, I will with yours too.
As well I'll access the <IP_address>:80/api/pi ? and check
And context data ad you suggested, I?ve found it now.

On monday, I can't before ((( I hope to have success, but it's very stange.
I hope that Datech may realease his script with command too.. thanks for that )

[Barabba11]

@datech any chances to see your module ready to send commands sent by echo? Thank you!

[datech]

#67 Meta attribute is included in payload output

Released in v0.1.9