Hello,
I have the following workflow interfacing Amazon Alexa.
This is the path where the command is received
Here is Alexa Showing the replay
Following the execution of the command the “Device State” Triggers following the command execution
with the following stat at the end of the execution:
The webhook in the end of execution path following the device state Trigger is never recognized by Alexa
Any idea? The Payloads between the before and after execution are entirely different…
bt the way “shouldEndSession”: false in the first responding webhook…
Thanks
You’ve encountered some workflow fundamentals that can take a little time to fully understand.
First, let’s explain how a webhook is handled and ultimately replied to. When a webhook triggers a workflow, it places a replyId
on the payload at data.replyId
. When you use a Webhook Reply Node, this ID is how to tell the workflow which request to actually reply to. You can see this field in your first screenshot. For convenience, the Webhook Reply Node defaults to the value at data.replyId
, since it is the most common implementation.
When your workflow is triggered by the Device: State Trigger (second screenshot), there is no replyId
anywhere on the payload, so when you attempt to use the Webhook Reply Node, the workflow has no idea which request to reply to.
Multiple triggers in the same workflow generate their own payloads and payloads are entirely separate and independent. The only way to share data between separate runs of a workflow is to use Workflow Storage.
So in this case, the workflow triggered by the Webhook must store the replyId
in Workflow Storage so that a Webhook Reply Node in a different run is able to retrieve and use that value in its own Webhook Reply Node.
Thanks,
Suspected I was missing something basic… Reason why displayed the two debug nodes.
You could save half day of work if you elaborate on:
<<< The only way to share data between separate runs of a workflow is to use Workflow Storage.
So in this case, the workflow triggered by the Webhook must store the replyId
in Workflow Storage so that a Webhook Reply Node in a different run is able to retrieve and use that value in its own Webhook Reply Node.>>>
Thanks
@Nicolas_Assouad,
You can find a really good example and practice using Workflow Storage using the Workflow Lab:
You find example workflows for the lab on Github
Nice! Thanks for the update.
Thanks…
I got it going over the weekend by saving the original payload (the entire {{data}} and not {{data.replyid)) ) then restoring after the ““device state”” trigger node and then adding the local device status using the “Mutate” node prior to the last “webhook node”… Works great…
By the way, I have an open issue with the google home/assistant webhook reply…. Sent all the requested data… never got any answer.
Thanks for the outstanding support
1 Like