# Allow input other than msg.payload for the split node

**URL:** <https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481>\
**Category:** Feature Requests\
**Created:** [29 November 2021 21:10 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481 "2021-11-29T21:10:15Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![jmorris644](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jmorris644/32/31964_2.png) [@jmorris644](https://discourse.nodered.org/u/jmorris644)\
**Post date:** [29 November 2021 21:10 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/1 "2021-11-29T21:10:15Z")

</div>

It would be nice of the split node allowed input other than msg.payload as the other sequence nodes do.

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [30 November 2021 10:39 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/2 "2021-11-30T10:39:05Z")

</div>

My 2 cents  
I think you'll have to come up with a pretty good use case to get this one considered

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [30 November 2021 10:53 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/3 "2021-11-30T10:53:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [30 November 2021 13:50 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/4 "2021-11-30T13:50:40Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![jmorris644](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jmorris644/32/31964_2.png) [@jmorris644](https://discourse.nodered.org/u/jmorris644)\
**Post date:** [30 November 2021 13:50 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/5 "2021-11-30T13:50:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [30 November 2021 14:00 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/6 "2021-11-30T14:00:12Z")

</div>

> [@jmorris644](#):
>
> 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?

---

<div class="post-metadata">

**Author:** ![Seedling](https://avatars.discourse-cdn.com/v4/letter/s/9de053/32.png) [@Seedling](https://discourse.nodered.org/u/Seedling)\
**Post date:** [30 November 2021 14:13 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/7 "2021-11-30T14:13:06Z")

</div>

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.)

---

<div class="post-metadata">

**Author:** ![jmorris644](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jmorris644/32/31964_2.png) [@jmorris644](https://discourse.nodered.org/u/jmorris644)\
**Post date:** [30 November 2021 14:19 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/8 "2021-11-30T14:19:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jmorris644](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jmorris644/32/31964_2.png) [@jmorris644](https://discourse.nodered.org/u/jmorris644)\
**Post date:** [30 November 2021 14:27 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/9 "2021-11-30T14:27:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [30 November 2021 14:35 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/10 "2021-11-30T14:35:25Z")

</div>

> [@jmorris644](#):
>
> I would keep the output the same and put it in parts.

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.

> [@jmorris644](#):
>
> 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.

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:

```auto
const topicParts = msg.topic.split("/");
msg.myTopic = topicParts[2];
return msg;

```

---

<div class="post-metadata">

**Author:** ![jmorris644](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jmorris644/32/31964_2.png) [@jmorris644](https://discourse.nodered.org/u/jmorris644)\
**Post date:** [30 November 2021 15:03 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/11 "2021-11-30T15:03:13Z")

</div>

> [@knolleary](#):
>
> 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.

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.

> [@knolleary](#):
>
> 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:
> 
> ```auto
> const topicParts = msg.topic.split("/");
> msg.myTopic = topicParts[2];
> return msg;
> 
> ```

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.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [29 January 2022 15:03 UTC](https://discourse.nodered.org/t/allow-input-other-than-msg-payload-for-the-split-node/54481/12 "2022-01-29T15:03:38Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.