Set trigger node's delay time from context value

Hi! I'm using a universally-set delay time stored in flow context, which works great with delay nodes as they can be overridden with the msg.delay property, but not so much with the trigger node.

I've been trying to write a function that acts like the trigger node, and have learned a bunch from this thread showing use of setTimeout, but the piece I'm missing is that, when the trigger node is configured to "do nothing" upon receipt of a message, wait x time and then send something else out, it effectively ignores all other incoming messages received during that delay time.

Anyone know a way to either set the trigger node's delay time via a stored value, or write a function to do the same?

Thanks!

Not sure what the end goal is for your 'problem', but there is a checkbox to extend the delay when new messages arrive.

I'm setting a bunch of delay nodes dynamically, using values stored in flow context, and I'm trying to figure out a way to write a function that performs like a trigger node (upon message in, do nothing, wait x time, then send something else), but allow for that x time to be defined by a value stored in context.

Ok so

  1. a message comes in to your function node - dont care what that message is i assume ?
  2. You then check the Context variable for the delay amount and wish to pause for that amount of time
  3. You then proceed on with the function and send out a message as an ouput (that message had nothing to do with the input ?)

What happens to other messages that are received whilst you are paused ? Dont care ?

Craig

  1. Nope, don’t care what the incoming message is, and so far it’s been just a timestamp. I just needed something going at a regular interval.

  2. Correct, the pause would be dictated by the value in context storage.

  3. Doesn’t matter what happens to the effectively ignored messages.

The purpose of this was to be able to modulate the delay time of a regular timestamp coming out of an inject node. Later on in the flow, those single messages are replicated 8 times and given different properties by another function, for the purpose of collecting data from a series of display hardware.

Though now that I’m reading about other JavaScript methods (total beginner), I’m seeing setInterval. Maybe I can lose the inject node altogether, and create a variable pulse from the function alone...?

The function node will need a incoming message to start it's processing. If nothing is connected to it's input it will never run

Sure, makes sense. But given a single bang from an inject node, is it possible to write a function, with a variable delay time, that will output continually using setInterval? Or am I barking up the wrong tree?

I'm setting a bunch of delay nodes dynamically, using values stored in flow context

sidenote: You can reduce the 'bunch' to one by using mgs.topic to differentiate between delays.

For your function; you can use a delay node (with msg.delay) together with a trigger node ?

Perhaps you should describe what the purpose of your flow is, what are you trying to achieve (other than a dynamic trigger)

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!