I'm trying to make a Paul McWhorter lesson work 50 & 51. Getting a error I don't understand and 2 days of searching I can't figure it out

this is the error I'm getting, the code is below it...

/Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino:13:23: error: expected primary-expression before ')' token
DHT11 HT(sensePin,Type);
^
/Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino:18:7: error: expected initializer before '+' token
int dt+1000;
^
/Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino: In function 'void setup()':
/Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino:23:6: error: 'class DHT11' has no member named 'begin'
HT.begin();
^~~~~
/Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino: In function 'void loop()':
/Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino:32:3: error: 'tempf' was not declared in this scope
tempf=HT.readTemperature(true);
^~~~~
/Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino:32:3: note: suggested alternative: 'tempF'
tempf=HT.readTemperature(true);
^~~~~
tempF
/Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino:32:32: error: no matching function for call to 'DHT11::readTemperature(bool)'
tempf=HT.readTemperature(true);
^
In file included from /Users/mikmaster63/Documents/Arduino/sketch_jul22a_hum_lcd/sketch_jul22a_hum_lcd.ino:1:0:
/Users/mikmaster63/Documents/Arduino/libraries/DHT11/src/DHT11.h:53:7: note: candidate: int DHT11::readTemperature()
int readTemperature();
^~~~~~~~~~~~~~~
/Users/mikmaster63/Documents/Arduino/libraries/DHT11/src/DHT11.h:53:7: note: candidate expects 0 arguments, 1 provided

exit status 1

Compilation error: expected primary-expression before ')' token

#include "DHT11.h"
#define Type DHT11
#include <LiquidCrystal.h>
int rs=7;
int en=8;
int d4=9;
int d5=10;
int d6=11;
int d7=12;
LiquidCrystal lcd(rs,en,d4,d5,d6,d7);

int sensePin=2;
DHT11 HT(sensePin,Type);
float humidity;
float tempC;
float tempF;
int setTime=500;
int dt+1000;

void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
HT.begin();
delay(setTime);
lcd.begin(16,2);

}

void loop() {
humidity=HT.readHumidity();
tempC=HT.readTemperature();
tempf=HT.readTemperature(true);

lcd.setCursor(0,0);
lcd.print("Temp F= ");
lcd.print(tempF);
lcd.setCursor(0,1);
lcd.print("Humidity= ");
lcd.print(humidity);
lcd.print(" %");
delay(500);
lcd.clear();

Serial.print("Humidity: ");
Serial.print(humidity);
Serial.print("% Temperature ");
Serial.print(tempC);
Serial.print(" C ");
Serial.print(tempF);
Serial.print(" F ");

}

Where did you get this from?
It is pretty unususal to have a type as anargument...

Why not follow the suggestion???

Maybe = 1000;?

1 Like

Lesson 50 and 51 in what series? Perhaps post links to the videos.

Why this true here?

As others have pointed out this is the offending line. I found the video 50

Paul does use that line but it is an unfortunate use of “Type” which may have worked in an older version of the IDE, but doesn’t in a newer version.

Try replacing the word “Type” with something like “Model” in both places.

“Type” is probably a reserved word and shouldn’t be use for a constant or variable name.

When debugging it is best to address the first error reported first. The first error can cause cascading errors further along.

Edit: the line of code is discussed around 15:00 in the video. FYI.

1 Like

Adafruit lib, this method return temperature in fahrenheit if parameter TRUE

#include <LiquidCrystal.h>
int rs = 7;
int en = 8;
int d4 = 9;
int d5 = 10;
int d6 = 11;
int d7 = 12;
LiquidCrystal lcd(rs, en, d4, d5, d6, d7);

#include "DHT.h"
#define Type DHT11
#define sensePin 2
DHT HT(sensePin, Type);
float humidity;
float tempC;
float tempF;

void setup() {
  HT.begin();
  Serial.begin(9600);
  lcd.begin(16, 2);
}

void loop() {
  humidity = HT.readHumidity();
  tempC = HT.readTemperature();
  tempF = HT.readTemperature(true);

  lcd.setCursor(0, 0);
  lcd.print("Temp F= ");
  lcd.print(tempF);
  lcd.setCursor(0, 1);
  lcd.print("Humidity= ");
  lcd.print(humidity);
  lcd.print(" %");

  Serial.print("Humidity: ");
  Serial.print(humidity);
  Serial.print("% Temperature ");
  Serial.print(tempC);
  Serial.print(" C ");
  Serial.print(tempF);
  Serial.print(" F ");

  delay(500);
  lcd.clear();
}

DHT11 just takes 1 argument, pin number.

  • many other errors are because HT is undefined

replace the + with an =

change to tempF

1 Like

@kolaha's code with

  • an I2C LCD (too lazy to wire an old school LCD)
  • a DHT22 (had no DHT11)

and no other changes functions well.

"Type" is not a problem.

The constructor for a DHT object takes two arguments. Three, but the third is one of those you can leave off.

# include <LiquidCrystal_I2C.h>

# define I2C_ADDR    0x27
# define LCD_COLUMNS 16
# define LCD_LINES   2

LiquidCrystal_I2C lcd(I2C_ADDR, LCD_COLUMNS, LCD_LINES);

#include "DHT.h"
#define Type DHT22
#define sensePin 2
DHT HT(sensePin, Type);
float humidity;
float tempC;
float tempF;

void setup() {
  HT.begin();
  Serial.begin(9600);
  lcd.init();
}

void loop() {
  humidity = HT.readHumidity();
  tempC = HT.readTemperature();
  tempF = HT.readTemperature(true);

  lcd.setCursor(0, 0);
  lcd.print("Temp F= ");
  lcd.print(tempF);
  lcd.setCursor(0, 1);
  lcd.print("Humidity= ");
  lcd.print(humidity);
  lcd.print(" %");

  Serial.print("Humidity: ");
  Serial.print(humidity);
  Serial.print("% Temperature ");
  Serial.print(tempC);
  Serial.print(" C ");
  Serial.print(tempF);
  Serial.print(" F ");

  delay(500);
  lcd.clear();
}

HTH

a7

Can anyone explain me how this works?
Type is replaced by DH11 by the #define.
But DH11 is not a C strung and not a number...
So: what type does the library expect?
Is it an enum that is defined inside the library?

The source code of anyhting that goes into any sketch is on you machine, or you can look at the code, usually on GitHub.

/* Define types of sensors. */
static const uint8_t DHT11{11};  /**< DHT TYPE 11 */
static const uint8_t DHT12{12};  /**< DHY TYPE 12 */
static const uint8_t DHT21{21};  /**< DHT TYPE 21 */
static const uint8_t DHT22{22};  /**< DHT TYPE 22 */
static const uint8_t AM2301{21}; /**< AM2301 */

HTH

a7

Fine, but where is DH11 replaced by 11?
In the header of DHT library?

First, it's DHT11, not DH11.

# define Type DHT11

next, in the header are the manifest constants that I pulled out of that context in #13:


static const uint8_t DHT11{11};  /**< DHT TYPE 11 */

DHT11 is a variable that has the value 11. A static const unsigned 8 bit integer.

a7

Ah, thanks for your explanation.
I did not see this practice earlier.
It seems like a good way of making a library flexible.
I do not really see the pros of the #define Type DHT11. To me it is just obfuscating...

Here the idea is to put at the top of the sketch things that might change, so they can be easily edited.

Instead of needing to find the constructor (or even know about it) and replace the official constant there.

The writer is more or less forced to use # define for its text substitution, as we see, without looking one would not know that DHT22 was an integer to write, in the modern fashion

const byte Type = DHT22;

The worst is sketches that appear to have gone to enough trouble to make such changes, but fail somehow, so changing manifest constants is not sufficient.

In the end there is nothing better than knowing how to read code, and working with good code to begin with whether borrowed or stolen.

a7

Type is definitely not a good name....
SensorType would heve been immediately clear...
Type also is used as part of the C language (typedef). Int float etc. are also types...

I agree, but Case Counts, so this is a style issue, not anything the machine will complain about or refuse to do.

You should take it up with the library author, who uses type

  DHT(uint8_t pin, uint8_t type, uint8_t count = 6);

Actually, neither type nor Type is a reserved word. We can forgive the Ice Tea guy for not knowing better than to just avoid it so there is no confusion nor wasted words on the matter.

a7

Here it is clear. It gets unclear when it is in a #define at the top of a file where it is unclear what kind of type. So, I think it is up to OP to keep it or to rename Type to SensorType.