It would be nice of the split node allowed input other than msg.payload as the other sequence nodes do.
My 2 cents
I think you'll have to come up with a pretty good use case to get this one considered
This raises questions to which the answer is not obvious. Consider for example if you asked it to split an array in msg.payload.values. Would it then send multiple messages with each value from the array in that message's msg.payload.values or would they be in msg.payload? I think it might all get rather complicated to configure.
I back this request. I don't like having to shift an array using a change node to put it into payload.
At face value, I see no technical reason why this could not easily be added and maintain compatibility (i.e. default to msg.payload)
The specific use case that I ran into was that I wanted to parse a MQTT subscription topic. Because the split node only handles msg.payload and the MQTT node maintains the subscription topic in msg.topic I could not use the split node. Unless I wanted to do a save and replace of msg.payload.
Are you proposing that if it were to split msg.topic then the split value would be kept in msg.topic for each message in the stream?
Without distracting from the specific feature request, what is the scenario where you want a separate message for each part of an MQTT topic?
I support this request. I currently have to bracket each split/join pair with Change nodes, so I see how being able to assign a property to the Split node (and include it in msg.parts) would make things more convenient. When you are dealing with arrays within arrays within arrays within arrays within arrays, all the change bracketing gets a bit tedious... (for an example for such array-ception, just take a look at despatch advices.)
I have a topic that I subscribe to that uses a + sign as the 3rd part of the MQTT topic. I wanted to extract that part of the MQTT topic in order to act on it.
The specific example is home automation. I am reading the activity of the switches and dimmers in my house. So my MQTT topic to monitor activity is "lights/stat/+/POWER". As the 3rd part of the topic changes based on the specific switch that is activated I needed to extract that.
I missed your question, I would keep the output the same and put it in parts. I do not see a need to replace msg.topic.
With the Split node today, if you provide msg.payload="a/b/c" and configure it to split using / then you'll get three messages with msg.payload set to a, b and c.
If the node allows you to pick a different property, then it would follow each message in the sequence has to have the split value somewhere on the message. And for consistency that would probably mean replacing the property that has been split.
To be honest, the split node is not the best solution for this. If all you need to do is get the value of the 3rd part of the topic, then splitting that one message into multiple messages means you are create multiple copies of the whole message that you'll be instantly discarding.
I would suggest a Function node could be used to extract that part of the topic:
const topicParts = msg.topic.split("/");
msg.myTopic = topicParts[2];
return msg;
I had not used this node before. In reading the sidepanel my interpretation was that a msg.parts was created containing the different components. I had not realized that the node output multiple msg.payloads.
So maybe some of the others that have replied to this message can provide better rationale for the change.
This is a good recommendation. What I ended up doing was saving the msg.topic into a database and then using a generated field to grab the 3rd element. This process better fit my need.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
