Something very weird is happening to my messages enroute

[Trying_to_learn]

Folks, this is as convoluted as it gets.

NR 3.0.2
RasPi
Buster

pi@TelePi:~ $ node -v
v14.18.1
pi@TelePi:~ $ 

Yes, I am a bit of a subflow adict. I also have a node resend last message installed for the exact reason it says in it's documentation.
It is handy to debug

The story - as briefly as I can:
Something isn't working and I am trying to find out where it is failing.

I got this node (node-red-contrib-resend-last-msg) to help me.
It was kind of working but also not.

I've been chasing my tail and I can not understand why what I am seeing is happening.

I send a message over MQTT:

{"payload":{"payload":"TimePi temperature","device":"TimePi","what":"health","event":"TimePi TEST MESSAGE - over temperature.","colour":"red","state":"1","led":"rgb,7,10,10,0","priority":1},"topic":"EVENT/HEALTH/TimePi","_msgid":"27a9de74ce449fbd"}

So all the extra stuff is also received.
Good/Bad? Dunno, but it works - well, AFAIK, it does.

It is received at the remote end and stuck through a JSON node.

This is what I receive and you can also see the problem happening here too, but weirdly further down this branch it is all ok.

I get this:

{"payload":"TimePi temperature","device":"TimePi","what":"health","event":"TimePi TEST MESSAGE - over temperature.","colour":"red","state":"1","led":"rgb,7,10,10,0","priority":1}

Great! All is good in the world.

It goes through other nodes and I get what I want for that branch of the flow.
I go back a bit and from the RAW message, I send it else where on the same machine and things go awry.

Sorry for the messy tab.
I was running in ever decreasing circles trying to find out what is/was going on.

(Screen shot)
See the incoming message.
ALL is good.
Ignore my subflow as for a while I thought it was causing the problem.
Also ignore the resend last message node. Same.

I put/send the message through a switch node and it has reformatted the message.
See the red lines.

The msg.payload has become msg.payload.payload{}

WHY? HOW?

If I put back my subflow it happens after it rather than after the switch node.

(See second screen shot)

If I open B it is the same as A message format.

But you can see in the GREEN debug node, it is as I received it in the first screen shot.

I've been putting debug nodes every where, can't see why it is happening.

Anyone?

[jbudd]

One of those debug nodes shows the whole message, the other shows just msg.payload.
So we can't be certain that they are displaying the same message (by comparing msgid).

Could you be getting two messages arriving at the Machine Health LED link in, when you expect just one?

[Trying_to_learn]

I appreciate your reply but I've been sitting here for .... a few hours.

Of which debug node do you speak?
At least on which screen shot?

[jbudd]

I was looking at the one with the green tick and red cross superimposed, the second picture.

Actually, the one with the green tick is only showing msg.payload.
And it has msg.payload.payload, msg.payload.device etc. So I think that means your problem is not arising at that part of the flow.

[Trying_to_learn]

This one?

In green:
fan led message (green) is the complete message received.
You can see the flat message structure.
payload
device
what
event
colour
state
and so on.

In the RED message
the message structure has changed and their paths are then
msg.payload + the original paths.

Sorry, this all started 4 hours ago. I forced myself to get breakfast and then I started looking at this problem.

I found bugs with what I had done - as that part of the code had never really been tested.
OVERHEAT SHUTDOWN.
And I didn't get any logs. (Even worse)

But moving on, I was testing the messages sent - and I did have the foresight to include a TEST parameter.
So I send it and see what happens and where the messages go.

I'll leave out all the other things and though they may be part of this bigger problem, I can't see how/why so I am not including them as I fear it will only further confuse you as they are other things.

So I am seeing the flat (normal?) message (green). It goes through a node (basic switch) and it comes out with a payload prefix on the paths of the message that went into that node.

[Trying_to_learn]

Yes, sorry.

Ok, so that maybe has helped.

I'll do more digging.

[jbudd]

@Trying_to_learn

In green:
fan led message (green) is the complete message received.

Are you sure? See my blue arrows:

[Trying_to_learn]

Sorry, as I posted I only just saw/noticed that.

It may be that I need to know how to convert the message back to what it was when I sent it.

[Trying_to_learn]

I THINK I've worked it out.

After realising that problem things have taken a whole new (better?) view and I have to sit down and check what I've just seen.

THANKS!

[jbudd]

Always good to step away from the screen, focus your eyes on the distance and kick the cat/brew coffee for a while

(no cats were hurt in the making of that sentence)

[Trying_to_learn]

Thanks though.

I was a bit blinded by the state of the debug nodes and after I opened them all up to show the full message things started to fall into place.

I know I am not helping myself with some of the things I am doing with MQTT messages, but it kinda helps the learning curve.

SOLUTION:

I was sending a complex message over MQTT. Which is a bad idea with how I was doing it.
At the other end I wasn't decoding the message correctly which lead to a lot of heart ache.

After being shown the mistake, I fixed it with a function node to restore the original structure of the message and all things now seem to work.