"How to split string, multiple values inside string to separate output."
In that conversation Nick had stated: " If you look closely at those messages, you'll see they all have a property called msg.parts.index - each with a unique value. The split node has split up your original message into a sequence of three messages - the msg.parts.index property shows its position in the sequence. You can make use of that property with the Switch node:
add a Switch node and set its property to msg.parts.index
add three rules to compare that value against 0, 1, 2"
However with my split data, my index values are continuing to climb......64,65,66,67......
How can I still use this approach to split my stream of strings?
That post is on the old forum which are kept so you can find solutions but locked. So you did the right thing to ask here.
It will be easier for people to suggest things to try if you can post an example of the input data.
This is an example of how I have the Switch Node set up:
The problem comes in when I reset the daily total or master total, those numbers can both fall into my second output criteria and then the dashboard gets messed up. If there is a way to ensure the three parts are positively separated all the time, I think I would be all set.
It sounds like you would do better to have a different topic on each type of reading -- then you can route them in your switch node by comparing msg.topic instead of msg.parts.index.
What node (or function code) are you using to interpret the stream?
Seems like it would work if you unchecked the "Handle as a stream of messages" option, but I'm not sure what the difference is...
From you screen shot, there is a msg-speed node between the tcp and split nodes -- what does that do? Anyway, I'm guessing that each tcp output msg.payload (before splitting) is a buffer or string containing the numbers separated by commas. In your debug window, if you click the raw button it will toggle between showing the raw bytes and a string of the data.
If each time you receive a msg from the tcp in node there are three values, I would just turn them into a single object with three named properties -- and avoid all the splitting and routing. Just pass the data object downstream and let each node pull out the part it needs.
The msg-speed was just something I found to see how fast the unit was sending data out. That will be removed. I like your idea about turning this into a single object, with named properties, I am just not sure what Nodes and setting to use to accomplish this?
Probably just a change node, but I'd need to see a sample of the raw output from the tcp in node. If you hover on the msg.payload object in the debug panel, you'll see some little buttons show up -- click on the "Copy" button to put the payload's JSON onto the clipboard... then paste it into a reply, surrounded by 2 lines that contain just 3 backtics (e.g. ```). That will keep Discourse from changing any of the formatting of the data.
Is the datatype shown in the debug panel a "Buffer" or "String"?
If I convert this byte array to a string, I see ' 0.3 tn/hr, ' (the data is between the quotes). So your tcp in node must already be splitting apart the 3 values you are seeking. This sounds alot like this current slack thread -- what process/hardware/code is generating the info that is sent to the tcp in node? Can you modify the data structure to be something easier to interpret?
There are limited options for changing the data stream from the equipment. I can basically separate the data by "comma" or " (their new-line). I will have to run it again and see what the datatype shows up as in the debug window. The one that you interpreted is the Rate, so the other two values must come separate as well. I just need to find a way to assign them to a variable or someway to keep them identifiable so that even if the values are equal, they are "uniquely" separate.
Yes, that was my concern also... and I wrongly assumed that all three values would be comma separated, but at least on the same line. Looks like that's not the case, and this is no longer a question about splitting streams into multiple values ;*)
So what can you use to identify what the values mean? If you use the order of arrival, and you miss just one transmission, then you are screwed. Is there nothing else in the received msg object to use as a key? Have you tried using the debug node to look at "the complete msg object"?
If all you have are some numbers arriving at random times, then your original switch logic may be the best you can do. Of course, you won't need the split node anymore...
Do you receive the 3 readings all within a few milliseconds of each other? If so, you could use the join node to group them into a single object (using the timeout option). If you want to post examples of all three types of msgs, with all of their properties, them someone else may have another approach. Good luck!
Ah, that was the reply I needed.......I went looking to see if I could identify the values by any other means. Instead of getting the second two values with no units, I was able to change a parameter and get one of the values with the units (tn). So I used two switch functions after the split....(it did not seem to work if I removed the split). The first switch looks to see if the value contains "tn".....two values do (tn/hr and tn)....I then used another switch function to break those apart looking to see if the value contained "hr". Now all three displays have there own values and there is no overlap following a totalizer reset.
