Firstly, use Serial.available() to tell if there is anything to read. Don't do 32 compares of the same character with -1.
Next, you can't compare two characters
if ('12' == val) {
this will not work.
Then what is the relevance of these "magic" numbers
Serial.write(byte(0x67)); //103 Relay 4
How about some #defines to make the code readable, there is no obvious relationship between 0x67, 103 and Relay 4
And what is the point of this
Serial.write(byte(0xfe)); //254
Just do
Serial.write(254);
No need to complicate things with HEX numbers and a comment.
But it seems we are at least slowly getting to the guts of what needs to be done.
There should be no need for 32 if blocks, if you can describe the relationship between the number received and the number sent all you need to do is receive the ASCII chars, convert to a number, and transmit that number.
So as I said above, what's the relationship between 0x67, 103 and Relay 4 for example. I assume there's a constant with a 4-bit field which holds the relay number, if we look at the first couple
0x6C is relay 1
0x6D is relay 2
no obvious 4-bit field for the relay number so maybe there's a magic reason that the numbers start with 108 (or maybe 107 as there is no relay 0)
So you can define something like this
#define RELAY_OFFSET 107
then use
Serial.write(byte(RELAY_OFFSET + 1)); //Relay 1
We still don't know what the offset is for but at least there's some readability to the code.
Do you always get 2 chars, or only one for values < 10? That makes a big difference to how the code would be written. Is there something that tells you the characters have been received, say a CR/LF pair or whatever. If the number of chars varies from 1 to 2 and there's no delimiting character you are in trouble.
Rob