Have you considered what I suggested earlier about using Regex to sort that?
No worries, I just finished a workaround and coded the exact suggestion you did (adding a hash for channel in between msg.sender.id and msg.sender.type).
Note that four new properties are added to the message:
Please check if you manage to import and test this flow: exported-flow-2.txt (163.6 KB)
1 Like
It was just a simple way i used to filter out the messages i dont need. Some of the messages have empty payload. So in the begining when i tryed i just checked for the word success first. but not sure it is needed. Have considered and tryed to fix it but had no idea how to do it. Cant really understand how your fix works but will play with it tomorrow and see if i can learn from it and use it. Thanks for the example.
Hi Paul,
Thanks, but as @Lost said it is not doable to change the payload upfront I generated the required data with other JavaString JavaScript methods.
That works great. You make it look to easy when i have been strugeling to get it to work without success, but have learned a bunch.
Thanks again.
Great. As a matter of fact, I have learned too from this interesting use case, so thank you.
As it is working well you may want to change this setting in the switch node. It will make the node to stop checking the rules when the match is done. It will save a few CPU cycles.
Hi Andrei.
I've not suggested that the payload is changed upfront!
I'm using regex to put the existing payload into a valid json format, and that then enables it to be parsed correctly.
So using regex in my example above;
payload: "{ channel: 1, success: true, level: 66 }"
becomes;
object
channel: 1
success: true
level: 66
which is then much easier and more reliable to parse.
I'm not suggesting that my idea is better than yours 
but I spent over an hour working on this (my own learning experience), and wondered why you were dismissive of this approach.
1 Like
OMG, my bad Paul. I thought you were only giving an example of how the ideal payload would look like. I did not know (I did not connect the dots) that the REGEX you proposed would already do the transformation. The solution I used to break down the payload is not ideal as it is susceptible to the payload construction. If tomorrow the owner of node-red-contrib-hdl removes a single space from the payload my the solution will stop working. Your solution is a way more robust. The problem to transform this string "{ channel: 1, success: true, level: 66 }" into a JSON or a JavaScript object is not trivial indeed. I spend some time trying to transform it on a perfect formatted JSON but was defeated and I gave up. Then I considered to transform it in an object using eval() or Function() but every reference in the internet discouraged using such method. Finally, I ended up using split() even not being a fan of this kind of usage. Thank you so much. 
Hi Paul, I am playing with your REGEX as certainly, I will use it in the future.
I guess I will need to refresh my knowledge on REGEX as I could not get how come that a single and short line like this var a = pay.replace((/([\w]+)(:)/g), "\"$1\"$2"); can be so "smart" to add double quotes only in the property keys (not in the values). It is brilliant.
It looks for the ':' and then puts the double quotes around the word before it.
I see now. Very smart indeed. Thanks !
The second Regex rule - (a.replace((/'/g), "\"")) isn't really necessary in this case, but as we have no control over the format of the node-red-contrib-hdl payload, I added it to ensure that any single quotes ' are replaced by double quotes " should the format change in future.
Once in the correct json format, I'm using JSON.parse to create a json object.
Paul
