-
Notifications
You must be signed in to change notification settings - Fork 0
Initial steps
As it turned out, I already had a D1 Mini NodeMCU ESP8266 module in hand, along with a no-name generic DHT shield for it. These were ordered from AliExpress sometime in the past year or so.
The only assembly work required was soldering suitable headers in place. I used the long-pin female headers for the D1 and ordinary male headers, long pins on the "bottom" side, for the DHT shield. This allows the two boards to be plugged together in a tight little package.
I signed up for an account on Weather Underground. I encountered a glitch while trying to register a personal weather station on the site...it seems to not work correctly with Chrome. Switching to Firefox enabled me to successfully register a PWS but I had to make guesses about the exact altitude and height. We're very near the top of a hill which the geo data says is 511 ft elevation.
A description of the upload protocol for wunderground.com can be found at:
http://wiki.wunderground.com/index.php/PWS_-_Upload_Protocol
In general, I was expecting to start with the code used at this Hackster.io project:
https://www.hackster.io/13699/autonomous-weather-station-with-esp8266-90f8b3
which is a more ambitious project than I'm starting with, but has the right sort of aspirational goals: solar powered, battery backup, etc.
There's a repository associated with above project at: wero1414/ESPWeatherStation
It uses the Arduino IDE for the programming. I've got to set up my Arduino IDE to enable it to handle ESP8266. The instructions for that I found at: https://learn.sparkfun.com/tutorials/esp8266-thing-hookup-guide/installing-the-esp8266-arduino-addon
So I added, in preferences, the additional board manager: http://arduino.esp8266.com/stable/package_esp8266com_index.json and went through the steps to install this as an available board manager.
I then downloaded the wero1414 repo mentioned above and started whacking away at the code to customize it for my location and reduced functionality. I placed the IDs and PASSWDs in a separate my.secret file that won't upload to GitHub because of an entry in .gitignore. I'll add a my.secret.example file to show what mine looks like, but without giving away any secrets.
Looking at the back of my DHT shield, I can see that the data connection is wired to pin D4.
So, it's smoke test time. How many errors did I introduce? First problem is no DHT.h file. Where should I look for one? It seems like the Adafruit one is reported to work.
The next problem is how to handle the my.secret file containing IDs and PASSWDs. That ended up being a real tailchaser. I thought I was chasing an IDE problem because my #include directive was not working. Choosing to name the file "my.secret" for the convenience of .gitignore seems not to have been a good idea. Instead, it appears it needs to have a .h suffix for it to work. Then I spend about 2 hours trying to figure out why it couldn't find the .h file - and in the end it turned out that I had a comma instead of a period in the source file.
And the Adafruit DHT library requires an Adafruit unified sensor library. Got that, now.
So now the code compiles successfully, downloads successfully, and starts to run. The WiFi attachment fails. Let's see what form the password parameter has to take for it to work. It wasn't the password, it was the SSID - As I originally set it up, it's ALL CAPS, so once I corrected the secret.h file, I have a connection!!!!
Next problem: the readings from the sensor are coming in as "NAN"s. Let's crank down the sleep time to see if that repeats itself, to 60 seconds. That will also check whether we can get ourselves out of deep sleep or if I have to add something to the Reset line.
I thought the WiFi problem was fixed, but it's now inconsistent. Sometimes it connects, sometimes it doesn't. No clues other than to try again.
Inspecting the DHT shield, it says it's a SM2302 on the plastic grid covering the sensor. Try changing the DHT type to SM2301 so the library will maybe start to do the right thing.
Because I have it plugged into a breadboard, I can connect D0 to RST which is supposed to be part of what's needed for deep sleep to work. As I understand it, the board should essentially reboot from scratch when it wakes up from deep sleep, so the serial noise characters may indicate something, but it means I shouldn't have to worry about restarting or resetting things in the loop code.
While waiting to figure things out, I added filename and timestamp reports to the console output. I also put a limit on how long it waits to connect to wifi of about 60 seconds. I've now seen it wake up from sleep. There's some chatter on the serial output first, then it looks like a regular reboot occurs. Still need to check if this is affected by the connection between D0 and RST and whether the D0 to RST connection affects ability to download new code. Still getting NAN results from the sensor after changing to the DH22 define.
OK, it looks like uploads always fail when D0 -> RST connection is in place. And if the D0 -> RST connection is not in place, it does seem to wake up from deep sleep and chatters on the serial console, but it doesn't start the uploaded code. So it looks like we have to remove the jumper to upload code and put it back in before the first wakeup. Actually, it's not so critical when the connection goes back in. It will wake up when the D0 -> RST connection is restored even if the sleep has expired for a while, then go on with the normal cycle.
Code compiles and downloads. It has successfully connected to WiFi (I can see that a DHCP address was assigned to it) at least once, but it hasn't connected lately. I tried rebooting the routers to see if they had gotten tired of hearing from it, but that didn't help. So no reliable WiFi at this point.
The DHT22 setting is still not successfully reading anything from the sensor. I've never seen a result come back that was not "NAN". Didn't work as DH11, either. There's some evidence that DHT22 and SM2302 are supposed to work the same. So this aspect has to be debugged as well.
I think I've solved the WiFi problem. I discovered how to turn on some debugging printouts for the WiFi system and spotted that the connection gets established at wakeup before my code even starts to run. If we are already connected, we do not want to run the .begin routine. Wifi is now working.
Breadcrumb: https://github.com/esp8266/Arduino/issues/2186
I've had the DHT_DEBUG set for a while but never see anything from that library. Will have to dig some more to find out what the problem is. DHT is NOT working.
OK, on the D1 Mini, the pin labeled D4 corresponds with GPIO2. Changing the value of DHTPIN back to 2 gave me sensible temperature and humidity values. I changed the sleep interval to 900 seconds (15 minutes) and plugged the device in on the outlet on the screened porch. It apparently takes a while for wunderground.com to start showing reports for you, so I probably can't expect to see anything there until tomorrow. Will have to capture an report the status of the GET transaction if no results show up.
DHT Works. WiFi Works. Reporting to Weather Underground status UNKNOWN
Uploaded code to GitHub, now using WeatherStation02 as project name; forked from wero1414 and renamed but I had already created WeatherStation01 with a different license.