How would I do this without a flow variable?

I don't want to have to pass the payload to the remote site. I just want to get a value from the header to decide what to do with my payload.

[{"id":"7acf375.df4f8c8","type":"http request","z":"298b76dd.fb448a","name":"Is TV On?","method":"GET","ret":"txt","paytoqs":false,"url":"http://remotehost:remoteport/tvon","tls":"","persist":false,"proxy":"","authType":"","x":320,"y":80,"wires":[["47b4537.75c07ac"]]}]

Hi, you only posted a HTTP Request node (was there supposed to be more flow?)

Any how, if you are only interested in a particular value & want to decide whether to pass the msg or not, then you can use a switch node and copy the path from the message using the "copy path" button on the item of interest.

It might help us to help you, if you show us an example message and tell us what value should allow the msg to be passed and what value should cause the msg to be blocked.


There’s a great page in the docs that will explain how to use the debug panel to find the right path to any data item.

Pay particular attention to the part about the buttons that appear under your mouse pointer when you over hover a debug message property in the sidebar.


I knowingly left out the return of the HTTP request. It's a concrete example, but my question is generic. This is a subflow, and I simply want to be able to pass the input to the subflow to one of the 2 outputs, depending on the http response. In this case, the response is either "true\n" or "false\n". I could pass the payload to the remote host and have it sent back in a header, but there's no reason that the remote host needs it, so I'd rather not send that back and forth.

I guess what I don't know is, if I set msg.random_variable and pass that into the http request node, does that variable come back out (and not send it to the remote host) along with the response? I could have tried that, but it didn't occur to me as a possibility until just now.

I believe it does pass through (without going to host).

And as you say, easy enough to test.

1 Like

OK, yep. Looks like it is passed along. I haven't tested whether it is in the msg on the remote host, but I assume it's not. Thanks.

1 Like

Incidentally, I wrote this because I have found cec-client and tvservice to be unreliable. cec just sometimes hangs forever and no other cec-client or tvservice commands can get through when that happens. Happens only once in awhile, but enough to be annoying. The remote host in this case is a node-red instance running on my mac connected to another HDMI port of the same TV, and I learned today that I can infer whether the TV is on or off based on the output of:

tell application "System Events" to return (display name of first desktop is "LCD TV")

So I created a flow that creates a webhook that returns the osascript isTVOn.scpt output in a header in the response.