I did a quick search and didn’t see anything directly related, so I thought I’d ask here. What’s the “best” way to trigger a specific Node-RED flow from PAC Control?
I know that I can do time-based polling, but that’s not a great fit for my application. I’m wondering if my best option is to use PAC Control to write/touch a file and then have my Node-RED flow set up to run when it detects a change to the file.
Are you looking for sub 1 second response? If so I wonder what the rest of the flow looks like…
But if you can take 1 second, just poll with an inject node the PAC Control read node thats looking at an int32 and then follow that with a switch node that passes it onto the flow when the values is the ‘go-trigger’ value.
The one var in PAC Control could in this way fire off different flows pretty smoothly.
@Beno: no, I don’t need sub 1 second response, so your solution is probably the simplest. Guess I was just wondering if there was a solution different than polling.
You are going to have some sort of poll regardless.
You can poll a var or you can poll the file read, but you are going to have to poll something.
I mean, if you really don’t want to poll and are ready to really look at a nice learning curve, there is always the Node-RED API.
One final question: is there some reason I wouldn’t want to use an HTTP In node since it’s pretty simple to perform a simple GET request from within PAC Control?
You could have a UDP listener in Node-Red and send off a UDP packet from PAC Control when you want the flow to run.
Philip beat me to it… UDP would be better than TCP, you have to really manage those socket connections from PAC. The TTL (Time To Live) can bite you when you least expect it. Also opening and closing the HTTP stuff has a fair bit of overhead compared to UDP.
@philip: I’m not too familiar with using UDP in this way. When you say send off a packet, is this more than sending a character to a UDP communication handle:
SetCommunicationHandleValue(handle, "udp:55555");
OpenOutgoingCommunication(handle);
TransmitChar('x', handle);
CloseCommunication(handle);
Then allowing UDP traffic on the chosen port number and setting up the UDP listener in Node-RED?
No, that is pretty much it.
I would need to look up the docs / experiment to determine if you would want to open and close the handle on the UDP connection - they are technically connectionless. I would probably open it and never close it.
On UDP, the connection isn’t closed on errors - so you can leave it open. From PAC Control help:
Many applications never close a communication handle once they are opened. If a communication fault were to occur on an unbound communication handle, the handle continues to remain open and may still be used to resume communications. If the communication handle was bound, it too remains open and datagrams will be received once the network problem is corrected.
Use TransmitString instead of TransmitChar or call TransmitNewLine after using TransmitChar. TransmitChar only adds the character to the buffer.
@philip & @Beno: Thank you for the help. I got this UDP method set up, and I like it because I can send a string “command” to a Node-RED flow and branch off in a variety of different directions based on the command sent. That saves me from having to poll a number of different PAC variables.
I am looking to do pretty much the same thing as @varland but am getting in above my head….
Thanks in advance for any pointers.
A few things I noticed:
eth0 and tun0, but that’s the only difference.int32 variable to an empty string. Try converting your int32 to a string first and use the string. Also, I’m using TransmitString, not TransmitChar. Also make sure there were no weird copy/paste issues with curly quotes.Hopefully this helps. Let me know if anything else comes up and I’m happy to help.
I don’t think you need firewall rules when communicating on localhost.
The SetCommunicationHandleValue only needs done one time, or you can just put the string in the Initial Value on the variable definition.
Use TransmitString like varland said - TransmitChar only adds the character to the outgoing buffer, it doesn’t actually send it.
For more reference, when I use this code in my application, I’m sending a string like status;1222;319.35986;471.12216;8.03261 via TransmitString. On the Node-RED side, I split the string on semicolons, branch based on the “command” (value before the first semicolon), and then handle the rest of the data as needed. That allows me to use a single port and a single UDP listener for a variety of functions within Node-RED. Some of those flows send data to other systems, while others end up pushing data back into variables via the PAC Write nodes.
I feel this setup accomplished what I wanted originally, which was to come up with a way to trigger a Node-RED flow from PAC Control without relying on periodic polling from Node-RED. I actually have the OptoScript code that @grant1 pasted in a subroutine named StartNodeREDFlow (creative, I know). s_Command is passed in as a string literal and ch_NodeRED is defined within the subroutine. I use it in about 10 different places in my strategy and have been really happy with it since deploying it two years ago.
Thank you @philip and @varland for the pointers.
Just to be clear, does my OptoScript block need to be connected with arrows in my flow? Or can it just sit off to the side as it presently is. If it’s in my flow, then I’ll put it just after Start_Feeder_Command changes.
My revised block is:
if (not Start_Feeder_Command == “”) then
SetCommunicationHandleValue(“udp:localhost:55555”, ch_NodeRED);
OpenOutgoingCommunication(ch_NodeRED);
TransmitString(Start_Feeder_Command, ch_NodeRED);
endif
@philip You wrote:
Can you clarify what you mean? Should I change my OptoScript above?
Yes or it will never run.
Put the “udp:localhost:55555” in the variable definition and you can delete that line. It probably won’t matter if you leave it though.
Define your communication handle like this:
Doing this means you can eliminate the SetCommunicationHandleValue command from your OptoScript code. Your code will be marginally more efficient, and you get the benefit that if you reuse that communication handle in other places, you have one central definition. Mine is initialized in the code because it’s inside a subroutine and subroutine instance variables aren’t persistent, but there’s no reason not to do it like @philip said.
Once you connect your block with arrows in PAC Control, you should be able to add a debug node after your UDP listen node in Node-RED and see the messages coming across.
Everything works now. To recap…
Eliminated the UDP firewall rule (not required since I’m using localhost)
Put udp:localhost:55555 in the Initial Value box of the communication handle ch_NodeRED
Created string variable called Start_Feeder_Command_String
Put this into the OptoScript block
if (not Start_Feeder_Command_String == "") then
OpenOutgoingCommunication(ch_NodeRED);
TransmitString(Start_Feeder_Command_String, ch_NodeRED);
endif
