Set trigger node's delay time from context value

Sure, don't mind explaining at all! And great suggestion, but I'm using msg.topic later on in the flow to help track what device a TCP response came from. I'm sure there's another way to do it, but that's what I've got right now.

This part of the flow is meant to collect a bunch of information from a group of display hardware, projectors in this case, and save the states collected to context storage, to be accessed at anytime by other systems that need the information. Data collected are things like power state (on/off/warming), shutter state (open/closed), etc.

Essentially, it starts with a heartbeat, a timestamp at a regular interval. This passes through a function that, for each timestamp, generates as many individual JSON objects as I have queries to send, and sends those out evenly spaced over the course of the regular interval established at the inject node/timestamp. (This is why I would love to have a function that took its delay time from context, because then I could have an inject node create a regular 1sec pulse, and using a trigger and a function ready to send msg.complete, decide which of those timestamps pass through later on, to create whatever interval works best. By having that function grab that delay value from context, like the other nodes that are using it, I wouldn't have to change that interval time at several places during testing... just change one number around until i get the timing right.)

Then, each of those individual JSON objects pass through another function that replicates it 8 times, but gives each copy it's own network addressing information and sends it out via TCP. The responses from those devices come back via TCP (and if no connection, a catch node grabs the error and passes that), and the responses are parsed and saved to flow context.

Honestly, the way it is right now will work fine. I've just been trying to learn a bit more about writing functions within NR, as I've been able to simplify a good deal of things I've made in the past. And being able to set the delay time globally inside a single node lets me perform operations on that number inside however many nodes later, like divide the overall delay time by the number of messages being sent within that time to allow maximum spacing between them, for ex.

Thanks for reading and offering some wisdom!