How can I reference a flow variable in a notify message?

[sdholden28]

I’m trying to pass a flow variable to a notify message that alexa will read and speak. I have the statement stored in flow.textToSpeak inside the flow. I’ve tried a number of different iterations of {“message”:" {{flow.textToSpeak}} "} in the jsonata expressions, but I either get an API error or Alexa actually says the word flow.textToSpeak instead of the value. What am I doing wrong here?

[erktrek]

Hey back! Sorry for the slow response… using the alexa_media addon in HACS. In Node-RED I use the HA “call service” node and pass it a JSONATA msg.payload from a “change” node like this:

{
   "data": {
       "message":"<amazon:emotion name='excited' intensity='medium'>" & payload & "</amazon:emotion>",
       "data":{"type":"announce", "method":"speak"},
       "target":["media_player.kitchen_echo_show","media_player.basement_echo"]
   }

}

Edit: I assume you can just use the Data property above and set this:

{
       "message":"<amazon:emotion name='excited' intensity='medium'>" & $flowContext("textToSpeak") & "</amazon:emotion>",
       "data":{"type":"announce", "method":"speak"},
       "target":["media_player.kitchen_echo_show","media_player.basement_echo"]
}

[erktrek]

I have also used the “node-red-contrib-alexa-remote2-applestrudel” and the “Alex Routine” node…

and the payload I pass via a template node is this:

<speak>Guest mode turned off.</speak>

BUT using JSONATA in the “Text” property above you’d do this instead of [msg.]“payload”:

"<speak>" & $flowContext("textToSpeak") & "</speak>"

[sdholden28]

Thanks so much!

& $flowContext("textToSpeak")

That’s the ticket. I’m not sure I would’ve ever found that. Is it documented somewhere? Applestreudel isn’t working currently, at least for the event nodes. There’s an open issue on the GitHub and I’m not sure when/if it’s going to be fixed. So I’m looking for alternatives and I actually stood up an instance of OpenHAB, which has nice Alexa events I can parse. I got through parsing the last command and the “which Alexa” issues, but this was the last piece in getting everything converted.

[erktrek]

Hmm thanks for mentioning the events - I just tested mine and sure enough not working…

I don’t really use them all that much though.

edit: but it would be very nice to have them work.

[sdholden28]

Biggest use case for me is fans. We have them throughout the house, and the family is used to saying “Alexa turn on the fan” in whatever room they’re in and have the fan come on. My first clue that there was an issue was numerous complaints that “none of the fans in the house work”. Wall switch works, specific device command via Alexa works, many rooms have lutron picos which turn on the fans, but “none of the fans in the house work at all”

[erktrek]

Yeah family can be harsh… My wife and daughter roll their eyes at me when I’m automating things but as soon as those things stop working the complaining starts…

I have the Nabu Casa subscription and was just messing around - created a toggle helper named testSwitch in settings/devices & integrations/helpers and then added an Alexa entry in the configuration.yaml with the input_boolean (toggle helper) like this:

cloud:
  alexa:
    filter:
      include_entities:
        - input_boolean.testswitch
    entity_config:
        input_boolean.testswitch:
            name: Test Switch
            display_categories: SWITCH

After restarting HA it shows up in Alexa! Now I can use my custom routines to toggle this virtual switch which is also exposed to Node-RED. Of course by adding the Alexa entry to configuration.yaml all the other exposed devices no longer appear so have to add them manually. This is better for me anyway - I like to keep the bare minimum of devices connected to Alexa.

edit: used this as a guide:

Alexa configuration

and this which helped me with “display_categories” property so the input_boolean doesn’t show up in Alexa as “Other”:

How do I create a virtual on off switch?

Hi @petro, I tried using this How do I create a virtual on off switch? - #13 by petro to expose a virtual switch to Alexa but it hasn’t worked for me. I have created the input_boolean and have been able to add it to a dashboard. I have successfully setup the local Alexa integration and Alexa has discovered many devices that it can now control. I have added the input_boolean to the alexa config: alexa: smart_home: locale: en-GB endpoint: https://api.eu.amazonalexa.com/v3/events …

[sdholden28]

That’s interesting. So how do you handle the “which alexa” part? Or am I missing something?

Edit: Have a look at this hacs component. I used it for a couple of things when I was still tying in devices from hubitat. GitHub - twrecked/hass-virtual: Virtual Components for Home Assistant

[erktrek]

Yeah I realized afterwards this does NOT help with the cool thing that AppleStrudel allowed you to do, namely filter by Echo device… sigh. It’s a stop gap measure at best.

[erktrek]

Also thanks for the link - that looks useful.

[sdholden28]

More links! There’s some workaround ideas at this link using another node

Alexa event node not firing reliably any more

And this one claims that an older version of applestrudel still works at the moment. I think I’m going to stick with my OpenHAB approach for the time being, but there’s certainly some options.

Alexa Remote2 event nodes not working (again)

[erktrek]

Mmmmm… reading through this. If you create a virtual “Alexa” switch (or bulb I guess) then trigger it in routines and use that event in NR to query the Strudels “other” node you can get the device info you need…

[erktrek]

It works!!!

[sdholden28]

New info from the applestrudel GitHub. Apparently a simple code change in the package can resolve the issue for now. Confirmed to work!

The reason this old fork works is because it uses an old style to connect, called V1, and the new alexa-remote2 uses V2 per default, it still has V1 in the code. This has nothing todo with the fork, it’s all in the alexa-remote2 lib, everyone uses.

If you want to change the behavior find alexa-remote2/alexa-wsmqtt.js, and change this.connectType2() to this.connectType1() in line 172. That should do the trick, no idea about what side effects this causes.

[erktrek]

Well shoot! I just created a work around… - great news though.

Created a basic subflow to encapsulate things. To the Alexa routines I’m using I added 3 actions: turn “Alexa Actions” switch on, wait 5 secs, turn switch off. This triggers a call to Strudels “Other” node i.e. “Get Activities” and sets a payload based on the contents…

[sdholden28]

Yeah I’m torn as well. Good news is I left my Alexa flows as is and copied them to new flows before making any changes, so I don’t have to undo what I’ve done to this point. I actually really like the result of the OpenHAB Alexa nodes. It’s fast and reliable. Triggers every time. Code seems to be maintained. BUT, I had a spare pi laying around that I put into service just for OpenHAB, and OpenHAB is NOT friendly in my opinion, especially having never used it. So the result is great but the journey was awful, and I’m not sure I want another platform to maintain if I don’t have to.

[erktrek]

Well at least there are options right? I’ve been curious about OpenHAB but have not messed around with it. Good to know your experiences thanks,

I made the change you suggested - just commented out the whole if-then block and put in the V1 statement. Can confirm things are now working again.