best way to parse integers from serial? (serial has only 0,1,0... )

hello guys. i want to communicate with the arduino via a Bluetooth.
my goal is to send a serial, containing just for integers, separated by comas, that can have only 2 values. (0 or 1 ).
my code for now is this :

int LU=0;
int LD=0;
int RU=0;
int RD=0;


void setup() {
  
  Serial.begin(115200);
  Serial.setTimeout(50);
  
  
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
}

void loop() {


           if (Serial.available()>0 )
                {
                  int LU = Serial.parseInt();
                  int LD = Serial.parseInt();
                  int RU = Serial.parseInt(); 
                  int RD = Serial.parseInt();
                 
                
                if (LU==1) {digitalWrite(4,HIGH);}
                else{digitalWrite(4,LOW);}
                
                if (LD==1) {digitalWrite(5,HIGH);}
                else{digitalWrite(5,LOW);}
                
                if (RU==1) {digitalWrite(2,HIGH);}
                else{digitalWrite(2,LOW);}
                
                if (RD==1) {digitalWrite(3,HIGH);}
                else{digitalWrite(3,LOW);}
                
              
                
                Serial.print(LU);
                Serial.print(LD);
                Serial.print(RU);
                Serial.println(RD);
                
               }

}

as you can see, i can see, what the program parsed , every time that it receives.
i send a serial every 100ms. the problem is , that if i am sending : (1,0,0,0),
and then immediately send (0,1,0,0)
just for the first serial, i can see that the arduino understands (1,1,0,0) for some reason, witch is unacceptable, because in my application , this communication controls relays , which if the case (1,1,0,0) is to happen, they will short out. any idea why this could be happening??

read this - Gammon Forum : Electronics : Microprocessors : How to process incoming serial data without blocking -

If all the values are 0 or 1, sending 1,0,0,0 followed by 0,1,0,0 seems unnecessarily complex. 1000 in binary is 8. 0100 is 4. 0010 is 2. 0001 is 1. The other values can be made by adding two or more of these 4 numbers. 1111 is 15, etc. 15 in hex is F. So, you could send one hex character, instead of 7 characters, and convey the same information, unambiguously.

If you follow PaulS' advice and encode your four binary values as a single byte value then the problem is massively easier to implement since you no longer need to deal with message delimiting and parsing - you can just read each byte and extract the bit values from it.

The disadvantage is that the obvious encoding scheme would result in you using non-ascii values which makes manual input for testing purposes a bit awkward, but if you're sending these from some other application then I wouldn't consider that a significant issue.

The disadvantage is that the obvious encoding scheme would result in you using non-ascii values which makes manual input for testing purposes a bit awkward, but if you're sending these from some other application then I wouldn't consider that a significant issue.

Sending '0' to '9' and 'A' to 'F', and converting them to 0 to 15 doesn't seem like a difficult task, to me.

Your problem there is not the encoding.

Your problem is that as soon as the serial receives one character, you go and assume there
is a whole bunch of characters, and go and try to read them.

If you are expecting 8 characters, you have to wait until they all arrive. There are several
ways to do this.

Either wait until Serial.available() is 8 or more, or ( better IMHO ), read the serial
characters into a character array, and then try to get the ints from it after enough
characters arrive. This separates the serial receiving problem from the int parsing
problem.

Your problem is that as soon as the serial receives one character, you go and assume there
is a whole bunch of characters, and go and try to read them.

Actually, parseInt() will block, for a short while, waiting for serial data to become available. Relying on this is not a good idea, though. Reading what is available, and storing it in an array, for later processing, as you suggest, is a better idea.

Sending less data is a better idea, though.