The Split/Join node pair currently supports several modes and styles of operation. The Split can handle Strings, Arrays, or Objects - and returns one msg for each split segment.
Split Node
The Split node takes a single message and (currently) creates multiple messages. Note - currently that is the simple way to think of it... 1 in multiple out...
Proposal 1
Add support for Buffers to be split - let the split "target" be able to be specified as an array format - eg ["0x02","0xf2"] sort of thing (that is itself then parsed into a buffer) to use with buffer.indexOf...
implemented in enhanced split/join branch - Add ability to split a binary buffer object on a char or another buffer (specified by and array or string as above) - Keeps any remainder left over for next packet to arrive . As a result it can't provide a total number of parts in advance, but can provide a count. Provides a count when there is zero remainder.
Join Node
The Join node takes multiple messages and reassembles them into one.
The pair can work in automatic mode - where the join detects the relevant type and pieces of the split and rejoins them.
In Manual mode it can join things in several ways
- a string - created by joining the property of each message with the specified join character.
- an array.
- a key/value object - created by using a property of each message to determine the key under which the required value is stored. eg: joins a msg wth topic foo and payload 20 and topic bar and payload 40 to create {foo:20, bar:40} - Useful for joining simple measurement values eg from an MQTT topic space.
- a merged object - created by merging the property of each message under a single object. eg: joins {temp:20} and {humidity:68} into {temp:20, humidity:68}
All of these either wait for
- a counted number of messages, or
- a timeout, or
- a msg containing a property
msg.complete
before triggering the send of the joined message.
Proposal 1a - Accumulate object mode
Whilst broadly similar to the merged object mode, this would not wait for a count or timeout. It would instead send the accumulated object every time a new message arrives. This way the contents of an accumulated object can keep being updated (and sent) without the user having to resort to function nodes and context and so on.
For example a user wants to create the following object
"on": true,
"bri": 200,
"alert": "select"
}
from three different UI components - so a switch sends true/false - a slider sends a number 0-255 and a select box sends the "alert".
Using this new mode all three messages could be combined by the join node into the single object without having to resort to a function node and the use of context. Every time one of the inputs changes the complete updated object would be emitted.
In addition if a msg does arrive with a msg.completed property - then the accumulated msg is sent and then the object is reset. This is consistent with other modes.
Proposal 1b - Accumulate key/value pairs mode
Similar in to proposal 1, this should also be the equivalent but for the key/value mode of operation - ie allow use of a msg property (like the topic) to create the properties - this would be even simpler than Proposal 1a above for use with UI nodes, and general msgs that just have a topic and payload (for example MQTT inputs)
Potential implementation
These could be implemented,
- either as stand alone modes of operation. IE Accumulate objects and Accumulate key/value pairs. (see below)
- or as a sub mode of the exiting modes - for example by allowing a "special" use of a count of zero inputs to indicate "infinite" (ie send every time).
Currently both 1a and 1b are implemented in enhanced split/join branch as new modes. (IE separate discrete modes of operation)
Proposal 2
In the key/value mode(s) the outgoing msg.topic is currently set by the last to arrive msg. It should be possible to set a new overall msg.topic for the new merged object. (Actually it can be another property that is used as the key - not just topic - but the thinking is the same). implemented in enhanced split/join branch
Proposal 3
Enhance the Join node to have a name field - All nodes should have a name field - not sure why we forgot it here. implemented in 0.17 branch - as it was this that exposed the dashboard namespace issue