Bluetooth data colision

Hi! I'm doing my final project for college and I started to have some problems and hope someone can help me. My task is to build "smart room", control LEDs, Light bulb, get temperature on request, and
possibly electronic door lock everything controlled trough bluetooth and smart phone (android). So with LED shield I managed to put LEDs in function (with 3 sliders in app R,G,B) so I moved on controlling light bulb with relay module and that is where all stopped. I guess it's because of analog/digital data collision.
I'm doing app in "MitAppInventor 2".
Is it even possible to do something like it's imagined?

CODE:

#include <SoftwareSerial.h>

int bluetoothTx = 0;
int bluetoothRx = 1;
int val=0;

SoftwareSerial bluetooth(bluetoothTx, bluetoothRx);

void setup()
{
pinMode(3,OUTPUT); // Crvena LED
pinMode(5,OUTPUT); // Zelena LED
pinMode(6,OUTPUT); // Plava LED
pinMode(8,OUTPUT); // Bulb - relay

digitalWrite(3,LOW);
digitalWrite(5,LOW);
digitalWrite(6,LOW);
digitalWrite(8,LOW);

//Setup usb serial connection to computer
Serial.begin(9600);

//Setup Bluetooth serial connection to android
bluetooth.begin(9600);
}

void loop()
{

//Read from bluetooth and write to usb serial
if(bluetooth.available()>= 2 )
{
unsigned int color1 = bluetooth.read();
unsigned int color2 = bluetooth.read();
unsigned int color = (color2 *256) + color1;
Serial.println(color);

if (color >= 1000 && color <1255){
int blue = color;
blue = map(blue, 1000,1255,0,255);
analogWrite(6,blue);
Serial.println(blue);
delay(10);

}

if (color >=2000 && color <2255){
int green = color;
green = map(green,2000,2255,0,255);
analogWrite(5,green);
Serial.println(green);
delay(10);

}

if (color >=3000 && color < 3255){
int red = color;
red = map(red, 3000, 3255,0,255);
analogWrite(3,red);
Serial.println(red);
delay(10);

}

// LIGHT BULB

if (color == 4002){
digitalWrite(8,LOW);
delay(10);
}
if (color == 4001){
digitalWrite(8,HIGH);
delay(10);

}
}

}

--EDIT-- I use bluetooth module HC-06 and arduino UNO

I guess it's because of analog/digital data collision.

What data do you think is running into other data?

    unsigned int color1 = bluetooth.read();

The read() method returns an int. The reason it does so is so that it can return a negative value to indicate "Hey, stoop, there was nothing to read!". Storing that in an unsigned variable is not the mark of the sharpest crayon in the box.

Since you DO check that there is data, the data is in the low order byte, so there is no need to waste space on anything larger than a byte.

    int blue = color;
    blue = map(blue, 1000,1255,0,255);

This doesn't make sense to me.

int blue = map(color, .... would make sense.

Is it even possible to do something like it's imagined?

It's far simpler to send ASCII data, and do the parsing on the Arduino side. The way your code is structured, to light an RGB LED, you need to send 6 bytes, and make three or more passes through loop() to read the red value, the green value, and the red value, AND god forbid that a byte gets lost.

Sending "<RGB: 39, 145, 118>" involves more bytes, BUT, you have a chance to recover from a dropped byte. Suppose that the G goes missing. You can tell that when the packet type (the part before the colon) is RB, instead of a known value (RGB). Suppose that the 4 gets lost. Well, that really isn't a big deal. The green LED will not be as bright as you expect, so you'll diddle with the green slider in the app, and it will send the packet again.

You could also send "<P: 3, 1>" to turn Pin 3 on or "<P: 5, 0>" to turn Pin 5 off.

What data do you think is running into other data?

Problem starts when I want to turn light bulb on or off. I think it's because LED part has analogWrite and bulb part has digitalWrite and they use same variable "color" . I tried to use diferent variables but then nothing worked.

Serial monitor: Imgur: The magic of the Internet

I think it's because LED part has analogWrite and bulb part has digitalWrite and they use same variable "color"

No, that is not the problem. The value of color is used to decide what action to take. The value of color is not affected by the choice made, or what data is used by that choice.

It would appear (to me) that the code that sends 4001 or 4002 is sending additional bytes after the value, whereas the code that sends other values is not sending any additional bytes. It might be interesting to print the actual byte values before they are used to produce color.

When I change digitalWrite to analogWrite in bulb part : LEDs work, relay is not working, but numbers dont mix, everything looks like it's fine. That's why I'm so confused with this analog/digital part..

serial monitor: Imgur: The magic of the Internet

Deadpool123:
I guess it's because of analog/digital data collision.
I'm doing app in "MitAppInventor 2".
Is it even possible to do something like it's imagined?

CODE:

#include <SoftwareSerial.h>

int bluetoothTx = 0;
int bluetoothRx = 1;
int val=0;

SoftwareSerial bluetooth(bluetoothTx, bluetoothRx);

I have no idea what you mean by "analog/digital data collision", and I have no idea about what you want to do but, whatever it is, it is likely that it won't work because you are using software serial on the hardware serial ports.

it is likely that it won't work because you are using software serial on the hardware serial ports.

Damn. How did I miss that? That's usually one of the first things I look for.

Thank You guys. I changed software serial library to hardware and everything works fine now.
I just have one question now, since english is not my first language I have read some data sheets but I just don't understand it enough.
Can You please explain me difference between software serial and hardware serial libraries easiest You can? Why it works now?

Thank You once more. You helped me a lot :slight_smile: :slight_smile:

Can You please explain me difference between software serial and hardware serial libraries easiest You can? Why it works now?

Serial data is a stream of bytes. A byte is a collection of bits. A bit is either 0 or 1. The way that the data arrives makes the receive pin HIGH or LOW for some period of time.

The pin changing state triggers an interrupt. For hardware serial, that interrupt is handled by the hardware. For software serial, that interrupt is a pin change interrupt. In the pin change interrupt handler (there is one for all the pins that support pin change interrupts), the handler has to first figure out which pin caused the interrupt, and, if it is a pin of interest, what the change was.

Since the hardware interrupt handler has a lot less work to do (dealing with just one pin), it is much faster than the software interrupt handler, which has to deal with a lot of pins, ignoring most of them.

The issue, in your case, was not one of hardware vs. software serial. It was one of trying to do software serial at the same time, on the same pins, as hardware serial.

Just as you can't connect two LEDs to one pin, and expect to be able to blink them at different speeds, you can't use one pin to do both hardware and software serial.

Deadpool123:
Can You please explain me difference between software serial and hardware serial libraries.

You don't need to call a library for hardware serial. I believe there was a time when you did but, if you are doing that now, you should upgrade to the current IDE.

You can get information on software serial here https://www.arduino.cc/en/Reference/SoftwareSerial
but the only thing you really need to know is that it is something you only use as a last resort or, at best, as a temporary measure.