Hello Scott - why does the input need to be split if you are only collecting one value?
You are setting input twice - should only be once, the first (number of bytes = -1) being correct, delete the other.
We would need to see your micro controller script (Arduino Sketch), but also consider the possibility that the sensor itself could deliver spurious values. What element is the sensor detecting the temperature of?
Also, how often is the temperature being read? Time intervals should be the longest practical for best results (Clock1 in your code). The App time interval should be approx 20% faster than the microcontroller send time interval.
I forgot to mention that you should ensure the heat output by your device does not influence the output of the temperature sensor. That can happen in two ways - heat dissipation across the board reaching the sensor and/or cooled air from the cooling fan being emitted across the path of the sensor. Both are common mistakes.
First, thank you for your willingness to assist. I just started working with MIT App Inventor.
As you will see below, I made some changes on the AI2 side. I now do not get a readout, only a complaint from the App about bad arguments (operation select list item cannot accept the arguments:,["778|"],[1]).
#include "DHT.h" #define DHTPIN 2 // Digital pin connected to the DHT sensor #define DHTTYPE DHT11 // DHT 11
// Connecting up the DHT11 Temperature and Humidity Sensor --
// Connect pin 1 (far right) of the sensor to Ground
// Connect pin 2 of the sensor to VCC 5 volts
// Connect pin 3 (far left) to DHTPIN
Well, you are nearly there. The reason for the error message is that you do not receive a List of values, so the data should not be handled as though it were a List.
Your Serial Output is therefore wrong too and since the sensor reading is a float, it's best to send that value to the App. If you want to round the value to an Integer you can do that in the App.
Serial.print((f,2); // Send a Float value of 2 decimal places
Serial.println(); //Sends ascii character number 10 to tell App 'end-of-data'
The following snippet will hopefully be enough change to get your Project working but there is a lot more required to build a reliable App.
Note that updating a value every two seconds is hard for the eyes to tolerate. It is always the case that the time interval should be as long as is practical. I recall a student's App that was designed to water flowers periodically..... every second!
Hi Chris,
Thank you very much for the information and tips. It is most appreciated. I will try today to incorporate these changes today and hopefully get the app working soon.
I have a few more questions, if you con't mind.
First, do you know of an actual course I can take in order to get better at using MIT App Inventor?
Second, if you want to build an app for commercial applications, would you use MIT App Inventor or take another approach?
Thank you,
Scott
I actually would, yes. There might be some things that App Inventor could not deliver on adequately but I don't know of that many - probably the weakest part is in the area of action games, the Canvas could do with an overhaul but then there are languages dedicated to games so they are going to be the best choice most times.
I have been programming (mostly engineering software) with various languages for forty years - some you take to like a duck to water, some you really hate using.
With App Inventor you can build quickly. It's executable is reasonably lean and fast. It's learning curve is fairly smooth. It's free. Technical support is free. You get free grey hair and headaches thrown-in too. What's not to like?
Hi Chris,
I have a few questions about the blocks above that you provided, if you don't mind.
First, I am not sure where to find the "call Notifier1.ShowAlert" block. Please advise.
Also, would you please explaining what the "whenScreen1.inilization" blocks are doing?
Unfortunately, I am still having the same problem as before. The temp readout is fluctuating and getting readings like 83.66, 882.12, 2.12, etc.
Here is the Arduino code.
// Initialize DHT sensor.
DHT dht(DHTPIN, DHTTYPE);
void setup() {
Serial.begin(9600);
dht.begin();
}
void loop() {
// Wait a few seconds between measurements.
delay(2000);
// Read temperature as Fahrenheit (isFahrenheit = true)
float f = dht.readTemperature(true);
Serial.print(f,2); // sends a float value of 2 decimal places
Serial.println(); // Sends ascii character number 10 to tell App 'end-of-data'
}
Further ideas?
Again, thank you for your assistance.
Scott
In the Sketch, initialize value f outside of the loop (at the top of the Sketch).
Use the elapsed milliseconds method of timing the loop as per my example (instead of using delay())
Increase the loop interval - try 5 seconds
Whether or not that fixes the output, it's a more robust control. However, ultimately you could be looking at a hardware issue as I have previously described, or the sensor is not being fed the correct voltage/amps, or the sensor is faulty.
Hi Chris,
I have a different issue that has come up. I am not sure if the forum etiquette calls for me to set up a new post but I will start with you in case it is okay.
You just helped me get my App working well using digital temperature data from a DHT11 temperature sensor. I tried to use the same App to read digital data output (at the same 10 second rate) but sourced from a load cell. This is causing the App to freeze.
Any thoughts on why this might be happening?
Thank you.
Scott
Yes, should be a new Topic. Perhaps a change in the Sketch is causing the issue, the App wouldn't now what generates the data, but expects it to be the same format over the same time interval as before.
Taifun.
Good to know.