There seems to be a variance in the timing of the ESP8266 core cycles and this is reflected on the First read, read wait then read again appears to provide a much more stable output with the exclusion of the third parameter provided to the library....
The advantage of this is the "Pin Multiplexer" internal to the ESP8266 will be in a settled state.....
The data from this channel was very erratic but this seems to have sorted most variances, I still have a dodgy sensor...
http://api.thingspeak.com/apps/matlab_visualizations/41029Code: Select all//////////////////////////////
// DHT11 / AMS2301 is at GPIO2
//////////////////////////////
#define DHTPIN 2
// Uncomment whatever type you're using!
#define DHTTYPE DHT11 // DHT 11
//#define DHTTYPE DHT22 // DHT 22 (AM2302)
//#define DHTTYPE DHT21 // DHT 21 (AM2301)
// init DHT; 3rd parameter = 16 works for ESP8266@80MHz
DHT dht(DHTPIN, DHTTYPE); ;
long int spdcount = ESP.getCycleCount();
delay(1);
long int spdcount1 = ESP.getCycleCount();
long int speedcnt = spdcount1-spdcount;
//Use this to get the "current timing"
delay(50);
pfTemp = dht.readTemperature();
pfHum = dht.readHumidity();
delay(2010);
pfTemp = dht.readTemperature();
pfHum = dht.readHumidity();
float a = 17.67;
float b = 243.5;
float alpha = (a * pfTemp)/(b + pfTemp) + log(pfHum/100);
pfDew = (b * alpha)/(a - alpha);