Join node doesn't continuously send messages

I have a node red flow to change the thermostat based on outdoor weather. It works when I deploy a new node graph, but it doesn’t seem to update dynamically throughout the day. I think the problem is the join node.

An example poll state node:

The red box shows timely updates. The blue box on the right usually stays stale. (All are fresh in the pic bc I just deployed.)

Thanks for any help.

Not sure what the solution is but you should update your post to tag it with Node-Red for others to see.

It looks like you have no controls on your join node other than a 1 minute timeout.
You have not posted anything about your function nodes, but my guess is that the function node after the join node require input from all three parts of the flow before the join node .
With your setup then that will not be sure to occur.
It might work in the beginning, but polling data from pirateweather takes long than polling from your own local sensors, so the sync on the polling will slide over time and at one point be more than 1 minute, so you will only get part of the info you need.

You should change your flow to an inject node with a timer set and then pull the info from your sensors in serial, so the flow is not split up.

I have always found the join node to be particularly difficult to get to work as I want.

The secret, I believe, is in getting the settings exactly right when using the manual mode. This is especially important when trying to create a key/value object, using the msg.topic field.

The manual join can be after a number of parts.

  • so counting 3 means that 3 different messages with different topics must arrive
  • the node will queue inbound messages, wait until 3 have arrived, and then fire, clearing its queue

The timeout join can be a after a number of seconds (it’s seconds, not minutes)

  • so timeout of 1 second means that 1 second will elapse from the arrival of the first message to firing
  • after firing, the node clears its queue

Now, the problem I have found by experimenting is that these two settings can conflict unless it is exactly one or the other.

You have ‘and every subsequent message’ ticked, which seems to turn on the after message parts (even though nothing is set in the count box) and prevents the timeout from working correctly after the first fire.

To make this node work, you MUST either set number of parts, and leave timeout blank, or set message parts and leave timeout blank. That includes the ‘every subsequent message’ as well.

So, if you are using timeout, then all three sensors must change within the 1 second for all three to be joined. I would suggest increasing this a bit, and turn off ‘every subsequent message’. It should then work.

However, the parts may be a better option for you. Using 3 parts means the node waits for 3 messages. Usually this would get out of sync - say two fire, then nothing happens until the third fires which could be much later. This is where the ‘every subsequent message’ might work really well for you.

If you set

  • After a number of message parts to 3
  • and every subsequent message TICKED

then, the node will first fire when 3 (different topic) messages have arrived
and, then it will fire for every single new message, with all three messages combined, using the new message plus the most recent other two.

Hope this fixes it for you !

1 Like

We can’t see the function node after the join node, but I bet it require one value from exactly each of the sensors and that will not work with “each subsequent message”.

Yes I am sure the function node requires one value from exactly each of the sensors.

So,
Three inputs, join 3 messages.
Press ‘one’ - nothing happens
Press ‘two’ - nothing happens
Press ‘three’ - bingo, out pops an object with 3 messages joined

Then…
Press ‘one’ - bingo, out pops an object with 3 messages joined - the new ‘one’ together with the current ‘two’ and the current ‘three’

I tested it - works for any input message causing a join of the new message with the retained existing others.

So, if any of the input sensors change, then the updated message gets passed to the function and the calculation can be triggered again. Is this not what is wanted?

1 Like

The problem is in the sliding of timers i. The first nodes.
They are set to deliver data with 15 minutes interval, but they are taking different lengths to complete. Local sensors are much faster than cloud services.
This will eventually mean that you have two replies from the same sensor md be missing one of the others.

A join node can generally not be used with time critical flows.

Thanks everyone.

Is this the recommended way?

I’m used to Python. In Python I would have

temp1 = get_temp(sensor1)
temp2 = get_temp(sensor2)
temp3 = get_temp(sensor3)
outdoor_weather = get_outdoor()

if my_func(temp1, temp2, temp3, outdoor_weather) is True:
    # do something
else:
    # do something else

Still new to nodered/JS so I appreciate any assistance.

This is the safe way.
With a serial flow you avoid timing issues.
When you split a flow, then they become independent of each other and they can move with different speed.
Joining them requires a lot of thinking about the flow and the timing on the split flows and also with handling of multiple activations of the flow before the previous ones are done.

You can do pretty much the same in Node Red.
I suggest you find the context data icon in the upper right corner and click it and then click the refresh icon next to the global section.
You will then see all the global variables made available to Node Red from HA.
These can be extracted and changed with global.get and global.set commands in function nodes.