|
Post by valveandy on Jul 14, 2015 20:05:19 GMT
Hi all Just a quick note about the node software, if you try using the dht22 sensor you may get garbage back. If you remove the third parameter from the initialization string all will be well. Anyway it worked for me Have fun all A
Papa: valveandy refers to a code line like this:
DHT dht(DHTPIN, DHTTYPE, 3); // initialise temp/humidity sensor for 3.3 Volt arduino
^ the third parameter
|
|
|
Post by papa on Jul 18, 2015 0:47:21 GMT
Good to see a little activity on this board. Most of us techies must be knee deep in summer activities. ;-)
Thanks for sharing this, valveandy. I made note of it in case I need that later.
|
|
|
Post by hannibal on Jul 25, 2015 22:50:27 GMT
Hi all Just a quick note about the node software, if you try using the dht22 sensor you may get garbage back. If you remove the third parameter from the initialization string all will be well. Anyway it worked for me Have fun all A valveandy, can you elaborate on the garbage you see? I see RH values of 1100%
|
|
|
Post by computourist on Aug 2, 2015 18:49:12 GMT
The third parameter is needed if you use the DHT at 3.3 Volts. If the supply voltage is 5 Volts you can omit the third parameter.
rgds, Computourist
Papa: Again, valveandy & computourist refer to a code line like this:
DHT dht(DHTPIN, DHTTYPE, 3); // initialise temp/humidity sensor for 3.3 Volt arduino
^ the third parameter
In this forum, we mostly use Arduino compatibles using 3.3 volt data lines. However, some forum members use an RFM69 radio breakout board on a 5 volt Arduino compatible.
|
|
|
Post by agecrabahaykubo on Jun 29, 2017 1:12:33 GMT
|
|
|
Post by papa on Jun 29, 2017 13:49:42 GMT
agecrabahaykubo, I'm moving this conversation to a thread about DHT22s (keeping related material together & easier to find).
You asked: "Should I change the #define HT to DHT22?"
Papa: It depends on what you mean. (Forgive me if I explain what you already know.)
It sounds like you refer to my node choices sketch line that says ... // #define HT // for DHT11 temp / humidity sensor, d4. d7 also w SLEEPY
Reminder: activating that line ^^ means UNcommenting it (remove // at the start).
These versions of that line will NOT do what you want ... #define HT // for DHT22 temp / humidity sensor, d4. d7 also w SLEEPY #define DHT22 // for DHT22 temp / humidity sensor, d4. d7 also w SLEEPY
You are correct if you mean, as is needed, to change DHTTYPE later on in the sketch.
If you did not mean change DHTTYPE, I suggest this to accomplish what you want ...
In the sketch, search for DHTTYPE & find a line like: #define DHTTYPE DHT11 // type of sensor or #define DHTTYPE DHT22
& change it to #define DHTTYPE DHT22 // type of sensor or #define DHTTYPE DHT11
The above change (in my node choices sketch OR computourist's original DHT End Node sketch) should let you use DHT22 sensor & preserve record of the other sensor.
In my node choices sketch, I'll consider whether to add separate early DEFINEs for DHT11 & DHT22.
|
|
|
Post by agecrabahaykubo on Jul 6, 2017 0:16:48 GMT
Hi papa,
So, I tried using DHT22 and change the type in the code
#ifdef HT // DHT11 sensor =======Papa moved for easier customizing============ #include <DHT.h> #define DHTPIN 4 // DHT data connection, in setup() uses internal pullup #ifdef SLEEPY #define DHTpower 7 // D7 periodically powers sensor on SLEEPY #define HTdelay delay(300); // settle DHT sensor (how long really needed? Gandalph: 300 ? ) #endif // ifdef SLEEPY #define DHTTYPE DHT22 // type of sensor, papa moved next line to setup() DHT dht(DHTPIN, DHTTYPE, 3); // initialise temp/humidity sensor for 3.3 Volt arduino #endif // ifdef HT but I got this error. I believe it is not from the DHT code change.
C:\..\Arduino\libraries\RFM69\RFM69_OTA.cpp:80:16: error: 'class SPIFlash' has no member named 'initialize'
if (!flash.initialize())
^
C:\..\Arduino\libraries\RFM69\RFM69_OTA.cpp: In function 'uint8_t HandleWirelessHEXData(RFM69, uint8_t, SPIFlash, uint8_t, uint8_t)':
C:\..\Arduino\libraries\RFM69\RFM69_OTA.cpp:124:9: error: 'class SPIFlash' has no member named 'blockErase32K'
flash.blockErase32K(0);
^
C:\..\Arduino\libraries\RFM69\RFM69_OTA.cpp:125:9: error: 'class SPIFlash' has no member named 'writeBytes'
flash.writeBytes(0,"FLXIMG:", 7);
^
C:\..\Arduino\libraries\RFM69\RFM69_OTA.cpp:174:50: error: 'class SPIFlash' has no member named 'blockErase32K'
if (bytesFlashed%32768==0) flash.blockErase32K(bytesFlashed);//erase subsequent 32K blocks (possible in case of atmega1284p)
It is a bit weird because I don't have this error messages before. I tried to upload the sketch in my spare UNO and it shows the same error.
|
|
|
Post by papa on Jul 6, 2017 15:16:18 GMT
agecrabahaykubo, you are correct that the error is not from the DHT22 edit.
When you get an error, search the sketch & possibly the internet for a key term in the error message, in this case, search for SPIFlash. As you can then see, the choices sketch has code including SPIFlashA & just SPIFlash (relevant to your error). SPIFlash is in a section of sketch that starts #ifdef MOTEMEM.
It looks like somehow you activated the MOTEMEM feature to use code for flashing & erasing the extra memory that is on a Moteino (Arduino compatible with pre-installed RFM69 radio & extra flash memory), but NOT on your Arduino compatible. MOTEMEM needs the SPIFlash.h library installed which you probably do not have & don't need because you don't have a Moteino.
I suspect that earlier in the sketch, you UNcommented (deleted //) & activated #define MOTEMEM.
Make sure the line #define MOTEMEM says // #define MOTEMEM
^^ This will probably fix your error. If not, look around for another way you accidentally activated the SPIFlash code.
BTW the OTA in the error message is short for Over the Air programming, a way to upload to a node via the RFM69 radios instead of a wired USB connection. For RFM69 radio nodes, it only works with (properly set up) Moteinos & Miniwireless devices that have extra on board memory.
|
|
|
Post by agecrabahaykubo on Jul 10, 2017 4:32:00 GMT
Hi papa,
I checked the sketch and #define MOTEMEM is commented. Not really sure what causing this error, I tried redownloading RFM69 library for an updated version but still no luck.
I then tried to use my older computer where I have older version of Arduino IDE (1.8.2) installed, this is also the same computer where i start working with this automation project. I connected my spare Uno and uploaded the mutichoice(NODE 2) sketch to it and it was a success.
I managed to update the sketch/code for DHT22 by changing the DHTTYPE but it only shows correct TEMP data and HUM data shows "Err". So I revert back to DHT11 code and both TEMP & HUM showed data.
Anyways thanks for your response I'll just stick to DHT11 for now.
|
|
|
Post by papa on Jul 10, 2017 12:38:12 GMT
I've never used a DHT22. Sometimes, if you wait a bit, errs turn into data. Adding a delay before the humidity is read may help. Find the sketch line: hum = dht.readHumidity(); Just before that line add a new line: delay(300); // delay 300 milliseconds or three-tenths of a second, avoid garbage ?? Upload, let it work a bit & see if it helps. If necessary, experiment with other values for the delay. Timing matters with DHT sensors. You may need a later DHT library. However as you have found, updates may fix some things & break other things that worked before the update. Then again where you had a later version IDE, you might also have a later DHT library that caused issues, requiring changes in the sketch's calls to the library. It may be just as well to "stick to DHT11 [& whatever else is working] for now." If you decide to return to trying the DHT22, you might look at this site which describes & makes allowances for the traits of these sensors. Be aware that site is using a 5 volt Arduino instead of 3.3 volt Arduinos that require a different timing parameter to be initialized: the 3 in DHT dht(DHTPIN, DHTTYPE, 3). 5 volt Arduinos use the default DHT sensor timing. Also see that site uses a physical pullup resistor when the Choices sketch does a pullup via coding. See the note about TWO ground connections for DHT22. (Not sure why the 2nd GND connection to the DHT22's NC pin. A few sites do that. Most don't. Data sheet does not say that. Maybe it's to reassure users bothered by unused pin. ) In the breadboard pic, see also the capacitor connected to power & ground which I assume is to even out the power supplied to the sensor. (With our nodes, sending & receiving via RFM69 radio or ESP8266 WiFi takes current. If a DHT read happens close to that, the DHT read might not have enough current & give garbage instead of data. A capacitor might help cope with that.) See this post on tweaking how well a DHT sensor works on a device. Forum readers, who out there has successful experience with the DHT22?
|
|