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.