Now is NOT the time to be making extra trips to ER. Be careful mate.
1 Like
Except I'm not a beta tester. Lol
Bad assumption on my part. 
No worries. Now that I have a few extra/unused hubs again I should sign up...
Good to know the change made it to the released beta btis though!
With more digging, I found a better trigger to use when Alexa starts and stops talking.
Msg.payload.description.summary contains the words that Alexa heard you say. If you use a switch node and do Regex matches with Alexa*, it seems to work as a trigger. Make sure to uncheck "ignore case" when you do the Matches Regex in Switch Node. It looks like the summary is in all lowercase but just in case.
Also, when Alexa is done with you, she will send a payload with a blank msg.payload.description.summary so I am using that to turn off light. It seems to happen about 5 seconds after she is done talking.
PS. Is it wrong I keep referring to this inanimate object as a she or her????
1 Like
@stephen_mutt , nice! thanks for that post
Using what you posted, an Alexa Event node dumping out to a debug node i see the payload and the description.summary as noted.
What would be the way to stop her from acting on the phrase?
So like for example as a test, I have this simple flow and I said "Alexa.. node red status" and i see that come through the debug console where I can write some code to act on it, but meanwhile she blabbed on about some audio book and started playing some audible content
[{"id":"2c70cd84.097ea2","type":"debug","z":"294e068a.106daa","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":400,"y":560,"wires":[]},{"id":"ed09d8b0.77e278","type":"alexa-remote-event","z":"294e068a.106daa","name":"Listen","account":"41ad82a9.09a59c","event":"ws-device-activity","x":150,"y":560,"wires":[["2c70cd84.097ea2"]]},{"id":"41ad82a9.09a59c","type":"alexa-remote-account","z":"","name":"Alexa Account","authMethod":"proxy","proxyOwnIp":"192.168.0.5,"proxyPort":"3456","cookieFile":"alexauth","refreshInterval":"3","alexaServiceHost":"pitangui.amazon.com","amazonPage":"amazon.com","acceptLanguage":"en-US","userAgent":"","useWsMqtt":"on","autoInit":"on"}]
Try this - Create a routine that recognizes that phrase but has no actions (or a dummy action).
1 Like
I agree. I think you would have to do something like @aaiyar suggested because I think the actions are within Alexa, not Node Red, where she is continuing to talk about some audio book.
That = clever! Yeah, that'll work
I just created an empty routine, well the only action was a 5 second delay, and that'll work perfectly.
1 Like
I would like to have the community input about node that can get AND set state (ex: mode or HSM nodes)
I opened an issue in github (to be easier to track) to explain and discuss about it
But you can answer here if you prefer
Thanks 
I guess you know my response 
I just converted my capture/restore RM rules to NR sequences. I’d like some assistance in making the capture more efficient.
Using an RGBW bulb as an example, right now, I am independently querying and storing (in variables):
- "switch" (on/off) and "colorMode" (CT/RGB)
- If the mode is CT, I query and store “level” and “colorTemperature”
- If the mode is RGB, I query and store “hue”, “saturation” and “level”
This means that for an RGBW bulb, I’m doing 4 (or 5) queries.
Is there a way to get all the information about the state of a bulb in a single query and then just parse and store the status information in the desired variables?
I gave the correct answer on github. Just use that and move forward.
(that was sarcasm, in case it was not obvious)
There is with HTTP GET commands, but not with the nodes in this integration.
That said, multiple device + change nodes vs a single node plus a function node/js code to parse seems about equal effort/complexity to me. And it is actually less hub stressful to do the multiple device block route (versus a separate HTTP Maker API call on the device), as the values are already cached on the node-red side anyway.
Also you might be able to wrap the details in a sub-flow to make it visually simpler, if it is simply too many blocks for your liking.
1 Like
Yeah - basically, I'm doing this right now (except in my sequences - there would be multiple change nodes instead of the single debug node):
And I wasn't sure if that was efficient.
Edit: Also is this function ok for this purpose? The output is what I want, but is this the right way to do it?
var msg1 = { payload: msg.attribute = "switch" };
var msg2 = { payload: msg.attribute = "colorMode" };
var msg3 = { payload: msg.attribute = "colorTemperature" };
var msg4 = { payload: msg.attribute = "level" };
var msg5 = { payload: msg.attribute = "hue" };
var msg6 = { payload: msg.attribute = "saturation" };
return [ [msg1], [msg2], [msg3], [msg4], [msg5], [msg6] ];It is technically OK to do that way, but why?
if you are going to have separate device nodes anyway, just make them have the command/attribute you want to begin with, instead of setting in a function node. Eliminate the function node altogether.
Another idea, is instead of having a bunch of change nodes, you could potentially just run the output into a single join node (array key by topic), then output the join node into a single variable. Then reference the elements of that new variable instead of 5 individual variables.
(I'm going to go test that last part right now.... BRB)
EDIT: Kind of like this:
1 Like
Got it! Thanks a bunch. Going to play with the join node now!
Although, you might need to do something more/different than just "topic" for the key, if all of the attributes are coming from the same device, as they would all have the same key....
I gave each of the device nodes a unique name based on the attribute being reported. So msg.topic will work.
I'd love to attribute that choice to foresight, instead of dumb luck 
