I love context variables and use these in combination with the change node to assign values to the context variables.
This solves a lot of issues without using function nodes.
1 Like
I am of the exact opposite opinion and virtually never use them, but I believe in the freedom of others to programme using the paradigm they prefer, provided I am not asked to approve 
Notice the solution with the Join node uses one less node than the alternative suggested (by @machadotiago) , as well as using no context variables and no function node, so I fail to see the advantage of using context, at least in this case.
Still share the opinion of machadotiago that using 5 basic nodes to get things done is ok. Perhaps it requires more nodes but enhances readability and ease of use.
PS : Join uses context internally (key/value) (and upstream specification of the topic key).
2 Likes
O fully agree with you, but I always encourage people, that are just starting at Node-RED, to try using âchangeâ and âswitchâ before going to function, and trust me, this is based on science 
.
We have been training companies to use Node-RED since almost 3 years, and we have changed the training materials a lot during this period. We have also many employees that were also trained this way, and today I know people in the manufacturing industry that program in Node-RED every single day and have never touched a single function node because they are âafraidâ of writing code. Thatâs why Iâm here trying to spread my message
Of course, there is nothing wrong with node context, which is entirely within one node and is not accessible by another node. When using flow/global context data hops from one node to another with no wire between or in a manner that bypasses the normal message passing paradigm, so the data flow is hidden. That is not the case when using node context.
Again, I agree with you, I have nothing against the âjoinâ node actually, but I usually prefer using context variables because of the fact you can easily see them in the context menu.
Isn't that an argument for encouraging people to learn how to do it? Sometimes it is the best way. No node-red programmer should be afraid of writing functions.
But in this case I am not suggesting using a function node (I did initially but was converted to Join and Switch).
I see both points in using a function node, as well as a switch node.
I am still not sure, if I replace the debug node with a LED light which format to use...
Is there a possibility to use a function node to change the output of the GPIO.Pin from 0 to 1 when reaching 50 degrees?
I looked through the whole Node Red forum and only found examples using a seperate on/off switch (so no automation).
In node red you have to think in smaller blocks of logic. Split the problem into parts, detecting > 50 (which you now have multiple possibilities to choose from) and switching the GPIO output.
Do you know how to switch the output using an Inject node?
I personally never worked with an inject node but I would use either the number option (1 or 0) or the boolean option to controll the led.
Well you need to experiment with the Inject node, that is the best way to test your flows as you are developing them.
So all you have to do is to modify the function node to send 0 or 1 in the payload.
If you can't work out how to do that post what you have so far, in the function node.
1 Like
Hey Colin,
I used the following formula:
if (msg.payload['Temperatursensor 1'] > 50 && msg.payload['Temperatursensor 2'] > 50) {
msg.payload= 1;
}
else
{
msg.payload= 0;
}
return msg;
and I'm able to switch the status of my LED. Thanks a lot for your help!!
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
