@electrik: I found the solution. It was my misunderstanding of your advice. As you mentioned to add the \n then I thought it is the \n in the configuration of the Serial-Ouput Node, see here:
In the Output section you can "Add Character to output message". Apparently this is not equivalent to adding \n into the
payload itself. Now my paload looks like this:
and the Node is receiving it, great 
Thank you very much for your help @electrik
Thanks for your feedback frits.
This is what I found searching this forum and already replied to my own post, but it takes some time the post to become visible.
With best regards
Alberto
Currently I implemented some nodes sending data to a Serial-Gatway connected to a RasPi.
I'm running Node-Red on this RasPi and and the data area stoet into InfluxDB. Everything is working fine.
So now I'm trying to send some data from Node-Red to an example node.
First I verified that the node is working fine, when sending data to the Gateway.
For sending the data I'm using following flow:
It sends the number 275 to my Node_ID 29. The type is V_VAR1.
The Node-Red Debug shows, what is sent:
The loop in the node is a state machine, where I added a wait() just to slow it down while testing.
The cases are empty functions so nothing happens there.
void loop()
{
Serial.println("Runinng Main Loop");
wait(3000);
// Main-Lopp for state-machine
switch (Current_State)
{
case CHECK_LEVEL: Check_Water_Level(); break;
case FILL_WATER: Check_Water_Level(); break; //same function for both cases.
case PUMP_ON: Pumping(); break;
case SUSPEND: Suspend(); break;
case REMOTE_CONTROL: Remote_Control(); break;
case SLEEP_MODE: Start_Sleep_Mode(); break;
}
}
The receive function includes only some print commands to show me when the data was received:
void receive(const MyMessage &message)
{
Serial.println( "Message received: ");
Serial.println( message.type);
Serial.println( message.getUInt());
}
Unfortunately nothing happens, when I'm injecting the data in Node-Red.
I scanned the forum but didn't find the right postings helping me to understand, what my error is.
Thanks in advance for any advice.
@frits: if the MQTT GW do not support the dynamic ID assignement, then what happened to my other sensors (those based on the Nano) 
They got the Node_IDs from the GW. All the sensors are on the same GW.
@frits : This is my first GW, but during my early experiments I run it as an Ethernet GW, then I reconfigured to MQTT.
Currently I don't have a controller running but I'm using Node-Red + Influx-DB + Grafana.
So probably during these first experiments, while in Ethernet mode, the Node_IDs were distributed.
I will erase the EEPROMs by the next opportunity and will check the behaviour of my Nano sensors after re-boot.
Thanks for your explanation frits, it helped me to learn more about MySensors.
@electrik: I found the solution. It was my misunderstanding of your advice. As you mentioned to add the \n then I thought it is the \n in the configuration of the Serial-Ouput Node, see here:
In the Output section you can "Add Character to output message". Apparently this is not equivalent to adding \n into the
payload itself. Now my paload looks like this:
and the Node is receiving it, great
Thank you very much for your help @electrik
@electrik: I don't thing that it is necessary to connect to PC. I have MY_DEBUG active on the Gateway, and because I'm receiving also the traffic, I could see, if there would be something.
Here is my receive path:
When I trigger the sending of data to the sensor node, the "From Gateway" node does not provide any output. So, I will assume that the Gateway is not reacting at all.
@electrik: The wait() statement was just added, because I was not sure whether maybe the jumping into the empty functions will be the problem, while in one of the posts I read that wait() is written this way that receive() is not affected.
Yes, receiving the data from the Sensor-Node 29 in Node-Red is working fine and very fast.
Yes I also tried with different characters added at the end (no character, \r, \n ) all tested, no effect.
What concerns deactivating of a node in Node-Red, when you open the dialog-box to edit the node, there is a checkbox at the bottom, where you can make this node inactive. Based on your posting I tried also with deleting the node, but also with no effect on the outcome.
@electrik I just deactivated the receiving Node, but without any effect on the observed behavior.
My understanding of the serial interface is, that it is bi-directional so it should work in both directions.
But the next question arising for me is, what the Arduino-Nano, which is running as the Serial-Gateway in my configuration, is doing, when on its the serial-interface something arrives, what is to be transmitted via the radio.
I used the GatewaySerial script without any changes except of the setting of the RF24_Channel.
Currently I implemented some nodes sending data to a Serial-Gatway connected to a RasPi.
I'm running Node-Red on this RasPi and and the data area stoet into InfluxDB. Everything is working fine.
So now I'm trying to send some data from Node-Red to an example node.
First I verified that the node is working fine, when sending data to the Gateway.
For sending the data I'm using following flow:
It sends the number 275 to my Node_ID 29. The type is V_VAR1.
The Node-Red Debug shows, what is sent:
The loop in the node is a state machine, where I added a wait() just to slow it down while testing.
The cases are empty functions so nothing happens there.
void loop()
{
Serial.println("Runinng Main Loop");
wait(3000);
// Main-Lopp for state-machine
switch (Current_State)
{
case CHECK_LEVEL: Check_Water_Level(); break;
case FILL_WATER: Check_Water_Level(); break; //same function for both cases.
case PUMP_ON: Pumping(); break;
case SUSPEND: Suspend(); break;
case REMOTE_CONTROL: Remote_Control(); break;
case SLEEP_MODE: Start_Sleep_Mode(); break;
}
}
The receive function includes only some print commands to show me when the data was received:
void receive(const MyMessage &message)
{
Serial.println( "Message received: ");
Serial.println( message.type);
Serial.println( message.getUInt());
}
Unfortunately nothing happens, when I'm injecting the data in Node-Red.
I scanned the forum but didn't find the right postings helping me to understand, what my error is.
Thanks in advance for any advice.
@frits : This is my first GW, but during my early experiments I run it as an Ethernet GW, then I reconfigured to MQTT.
Currently I don't have a controller running but I'm using Node-Red + Influx-DB + Grafana.
So probably during these first experiments, while in Ethernet mode, the Node_IDs were distributed.
I will erase the EEPROMs by the next opportunity and will check the behaviour of my Nano sensors after re-boot.
Thanks for your explanation frits, it helped me to learn more about MySensors.
@frits: if the MQTT GW do not support the dynamic ID assignement, then what happened to my other sensors (those based on the Nano) They got the Node_IDs from the GW. All the sensors are on the same GW.
Thanks! this made the change. Now the ID is 25 as intended.
But how to explain that a Node_ID of 3 was set, when the #define statement was after the MySensors?
I also tried with the static Node_ID 24, there was no change in the behaviour. Then I tried with 25 and it is working now.
#define MY_RADIO_RF24
#include <MySensors.h>
#define MY_NODE_ID 25
#define OPEN 1
#define CLOSE 0
But the Node_ID seems to be 3 and not 25. 
16 MCO:BGN:INIT NODE,CP=RNNNA---,FQ=8,REL=255,VER=2.3.2
28 TSM:INIT
28 TSF:WUR:MS=0
36 TSM:INIT:TSP OK
38 TSF:SID:OK,ID=3
40 TSM:FPAR
45 ?TSF:MSG:SEND,3-3-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
653 TSF:MSG:READ,0-0-3,s=255,c=3,t=8,pt=1,l=1,sg=0:0
659 TSF:MSG:FPAR OK,ID=0,D=1
2054 TSM:FPAR:OK
2054 TSM:ID
2056 TSM:ID:OK
2058 TSM:UPL
2062 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2070 TSF:MSG:READ,0-0-3,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2076 TSF:MSG:PONG RECV,HP=1
2078 TSM:UPL:OK
2080 TSM:READY:ID=3,PAR=0,DIS=1
2086 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2095 TSF:MSG:READ,0-0-3,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2103 TSF:MSG:SEND,3-3-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.3.2
2111 TSF:MSG:SEND,3-3-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2164 TSF:MSG:READ,0-0-3,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2172 TSF:MSG:SEND,3-3-0-0,s=5,c=0,t=0,pt=0,l=0,sg=0,ft=0,st=OK:
2181 MCO:REG:REQ
Is there a kind of offeset in the ID?
Alberto
I successfully implemented a MQTT gateway on a PI and my Nano based sensors are working fine. 
As a next step I'm trying to build a Pro mini 3.3 V based sensor.
However the allocation of the node id seems not to work.
The protocol received on the serial interface of the Pro mini looks always like this:
__ __ ____
| \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| | | | |_| |___| | __/ | | \__ \ _ | | \__ \
|_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/
|___/ 2.3.2
16 MCO:BGN:INIT NODE,CP=RNNNA---,FQ=8,REL=255,VER=2.3.2
28 TSM:INIT
28 TSF:WUR:MS=0
36 TSM:INIT:TSP OK
38 TSM:FPAR
40 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
339 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
346 TSF:MSG:FPAR OK,ID=0,D=1
2050 TSM:FPAR:OK
2050 TSM:ID
2052 TSM:ID:REQ
2056 TSF:MSG:SEND,255-255-0-0,s=4,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
4063 TSM:ID
4063 TSM:ID:REQ
4067 TSF:MSG:SEND,255-255-0-0,s=223,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
6074 TSM:ID
6074 TSM:ID:REQ
6078 TSF:MSG:SEND,255-255-0-0,s=186,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
8085 TSM:ID
8085 TSM:ID:REQ
8089 TSF:MSG:SEND,255-255-0-0,s=149,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
10096 !TSM:ID:FAIL
10098 TSM:FAIL:CNT=1
10100 TSM:FAIL:DIS
10102 TSF:TDI:TSL
20105 TSM:FAIL:RE-INIT
20107 TSM:INIT
20113 TSM:INIT:TSP OK
20115 TSM:FPAR
20119 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
21071 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0
21078 TSF:MSG:FPAR OK,ID=0,D=1
22128 TSM:FPAR:OK
22130 TSM:ID
22130 TSM:ID:REQ
22134 TSF:MSG:SEND,255-255-0-0,s=114,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
24143 TSM:ID
24143 TSM:ID:REQ
24147 TSF:MSG:SEND,255-255-0-0,s=79,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
26157 TSM:ID
26157 TSM:ID:REQ
26161 TSF:MSG:SEND,255-255-0-0,s=45,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
28170 TSM:ID
28170 TSM:ID:REQ
28174 TSF:MSG:SEND,255-255-0-0,s=10,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
30183 !TSM:ID:FAIL
30185 TSM:FAIL:CNT=2
I tried with a new upload of the code, but the results is always the same.
(As mentioned above the other sensors are working fine).
Is there something else I have to consider, while using a Pro mini instead of a Nano?
Thanks in advance for your feedback.
Alberto