Now I cannot access both the temperature and humidity at the same time using the switch node (perhaps with JSONata), I would like to have an option to just select the whole msg. In the beta the "has key" option" has been introduced that would work wonders in this situation.
Same goes for the inject node, I cannot simulate objects that don't have msg.payload as property.
Hi Nick, do you intend on permitting the inject to send to something other than payload? Ideally directly to msg like @bakman2 says. That would be a great help in testing (and many other scenarios too).
This would have to be considered on a node-by-node basis.
It is also the nodes that produce/accept 'non-payload' based objects, perhaps some documentation guidance could help to avoid this (ie. use msg.payload for input/output).
I obviously could change them using a change node first, but it would be nice to skip a step.
This would apply to the switch, range, change, template and rbe nodes only I believe (dashboard?).
For the inject node - example; I have a milight, node accepts msg.rgb (among others). With the inject node I could create a interval schedule, but because I cannot send msg.rgb it cannot not be used for this purpose (this is an example, there are other options for the node to make it work).
Don't forget we also add other metadata to the msg object (like _msgid) so it would not be guaranteed to be exactly as you set it.
One of the basic tenets of Node-RED is that the payload is where the "interesting" data is expected to be from node to node, with other properties being used to help "guide" that data - Other nodes should really expect this and be in line - but hey - authors are human and are free to do what they want.
But yes - a better inject has long been an idea - but needs to be simple... yet flexible.
I have observed a number of contrib nodes that, in wishing to preserve the incoming data (via payload), add any required input (for their node) via msg.xyz. I thought this was accepted behaviour?
I have done this for the node I am working on. Should I rethink this?
In general you should operate on the incoming payload and send your answer back out as the payload - ready for the next node. As noted if necessary you can add extra properties to help "describe" it if necessary. Also you should try to leave and other properties alone (unless of course you need to operate on them - i.e. only touch what your node needs to touch)
Perhaps this is considered trivial but in terms of best practice for node input (performing operations/changing parameters on the node), you are suggesting that only the first of the following is acceptable?
msg.payload.xyz
msg.node_name.xyz
msg.xyz
I understand that output should always be in the payload, and leave anything not needed to pass through unhindered.
I understand that output should always be in the payload
If the output 'should' always be in the payload, then the input 'should' also be in the payload (how else did it get there)
In practice what I find is that certain properties cannot be accessed in 1 go with a switch/change node. If for example the switch node would have the flexibility to use msg as input then there is no issue. Currently there is no blocking issue either, as one can change objects/properties, albeit with an extra step/node.
After all, the message is just an object that is passed between nodes. So, theoretically, you can do with it what you want. Just be aware, not to delete or overwrite properties, that are required by nodes downstream.
So it all comes down to conventions and common practices, msg.payload being one of them.
That makes it easier for the platform to be extended by custom nodes, and easier for the user to understand.
Should it? That's what I am asking. If you have an "intermediate" node that performs a certain task on the incoming payload, but requires "user intervention", and those user properties should not be passed on to the output ...
Should it? That's what I am asking. If you have an "intermediate" node that performs a certain task on the incoming payload, but requires "user intervention", and those user properties should not be passed on to the output ...
If this intermediate node cannot access msg.x but only msg.payload.x you need an another node to make it work. And you word it correctly: incoming payload
Th ideal world would be that you just string together a flow on nodes from input to output without having to configure anything, and then hit deploy and it works... - so they should all expect to operate on some property and pass it on to the next. We chose msg.payload to be that. Of course in the real world you may need extra hints on how to handle that data so you know what to do with it - hence metadata.
