Ok, not sure if I can do it with the app inventor or just impossible but is there a way to filter out serial print ASCII characters like the 97 from showing up in my app drink status?
or am I just stuck with them. Also here is a copy of my blocks image if that helps.
Very new to this, been watching videos, reading everything I can find. If I need to upload the Arduino code...I can.
Thanks for any Help
Michael
I think we can assume that your Status Area is populated via data sent from the Arduino? If so, then yes, we need to see the .ino file.
Instead of all those buttons, why not use a List View? You also only need one Send Block.
Also, why send characters instead of integers? If integers were used, the code for each cocktail would be it's List Index....
Here is my .ino file. I'm still learning code and use app inventor...I've modified my .ino from someone else project that shared their code to add features that the original didn't have. The App inventor, I've never even used before till a few days ago, when I got my .ino file to properly compile. The original person that I based mine from shared their App Inventor code, but I could never get it to work with their original code, or mine, so figured out how create my own app, that actually connects and controls my arduino. Now their original code originally sent Dec # but I could never get my arduino to respond to, but was able to get it to work with characters. My current app, actually controls my Arduino like the original coders and...the Status Area, was kinda a after thought when I seen another app showing the serial print info but without the ASCII numbers and I thought it was kinda neat so I figured out how to add it to the app I created. Even the text to speech was just added today when I seen an tutorial on a YouTube video, and looked to see if I can add it to my app...was never a consideration till I seen it. As for sending integers, I really never thought or knew how...and it could be something to look into. I have no problem trying to learn to rewrite my arduino code as long as I don't have to redo the hardware part very much. Because I'd love to make it easier to change recipes and would love to do some sort of database so I wouldn't have to reload my arduino just to change recipes. This is going to be an ongoing project, and I'm sure not going to be the last iteration of it, so I know it will change the more I learn. Sorry this was so long winded and I hope I didn't come up cocky, I'm just starting to learn how to do more than blinky lights on my arduino and I knew this was a big leap from what I had already learned. Cocktail_16_pump_version.ino (17.6 KB)
The list view version is kinda interesting....studying it now to try to fully understand it though. Kinda understanding how it work. Please be patient with me, what I've learned so far has only been 3 days of learning so, once I get the basic it usually doesn't take very long.
You are doing really well.
I would say your ASCII char issue is due to the illegitimate use of sprintf, but the .ino you have posted does not seem to send anything to the App?
The Bluetooth data is sent in 'packets'. Each packet is approx 23 bytes and it's payload (your data) is 20 bytes. Ideally you want to send messages to the App as a single packet, so they have to be concise.
"Blue Hawaii in the making" is 25 bytes whereas "Blue Hawaii" is just 11 bytes. Even then, some cocktails have very long names - since those names are already known by the App and the App has sent a code to the board, there is no need for the board to send a message of this nature back to the App - just the "Drink is Ready!" message is enough, "Making Blue Hawaii" can be displayed directly by the App on send.
@Michael_s_Toybox Looking at your INO file, at the top of your loop is:
if(Serial.available() > 0){ // Checks whether data is comming from the serial port
state = Serial.read(); // Reads the data from the serial port
sprintf(state);
}
If you comment out that sprintf you should get the desired effect I would think.
Also, I'm generally confused about the use of sprintf here and that this even works at all. The general form of sprintf in the standard C library populates the memory of the first argument (taken as char *) with the format string at the second argument formatted with any remaining arguments. It seems like printf would be more appropriate.
There is a huge list of 'if' too, I have made an example using switch.
So, here is an updated Project and a matching updated Sketch. Using these methods makes it much easier to edit them. The Sketch now compiles but I have had to trust the pin-outs etc.
Cocktails2.aia (4.1 KB)
Cocktail_16_pump_v2.ino (12.1 KB)
yes, I realized after reading that was a messed up version....where the (sprintf) it should have been Serial.println
Chris, I like your code better, the only issue is anything after case 9, doesn't work., like case 11 just runs case 1 twice, and case 12 runs case 1 then 2
Can you debug that by printing the state variable to the Serial Monitor?
if(Serial.available() > 0)
{ //Checks for App data (serial port)
state = Serial.read(); //Reads data
Serial.println(state);
}
Ah no, cancel that - the code is good, but not the right code!
Try this:
if(Serial.available() > 0)
{ //Checks for App data (serial port)
state = Serial.parseInt(); //Reads data
Serial.println(state);
}The above should work given that it accepted 'text' sent by the App as a number. If it fails, then we can send an actual integer thus:
EDIT:
Use this Block Michael, Send1ByteNumber, as per Evan's Post.
.... and this Sketch:
Cocktail_16_pump_v3.ino (12.1 KB)
@ChrisWard I think the issue with your code is that Serial.read() will read a byte (as an int) off of the stream, whereas your switch statement compares the read value against individual characters. However, '10', '11', etc. are not "characters" and so the test against the state variable can never succeed. Instead, loop() will execute twice where state is 1 then 0 or 1 then 1, etc. for each character in the string you send because you are calling BluetoothClient1.SendText.
Instead, it might make more sense to call BluetoothClient1.Send1ByteNumber where the selection index will be interpreted as an integer between -128 and 127. Under this scenario, the switch can test cases 1, 2, 3, ...
Thanks Evan, re my previous post the .read mistake had already been discovered.
