Hi!
Thank you both for examples
@E1cid sadly this is not what I had hope for 
I know that there is a MQTT support in the node red itself, but the broker is not a first class citizen of node red (is not builtin) and also... I do not want to use MQTT in all "trafic" in NR itself, this is why we have flows and wires to not use external tools, right?
@Steve-Mcl I know that there are some mechanisms in switch node itself to check the structure of a topic, but still they are not so straightforward as simple #+ wildcards in MQTT that is why I'm confused, because there is no reason not to include them IF the use-case is similar to MQTT's topics...
And @Steve-Mcl you'r answer is, for me, the worst I can think of 
because if I should use what I need (or what fits me best) there is no reason whatsoever of having payload and topic field in the first place... It looks like someone had an idea and lost interest in it half way through 
But the end note that you added is great, I have an idea on how to handle my messages, similar to yours.
But still this is a little bit odd for me that there are no rules like for example
"use payload to store your data, topic to store the location", "topic should have a structure as ...", "copy content of payload to msg._orig in every subflow to properly handle errors" "use topic config/... to pass config to nodes" "don't do xxx because you will burn yourself' or something
still, thank you for answers
Br,
Bartoszek
