NRZ-2017-100-b7: DHT-Values sometimes not shown on valuepage

[dokape]

NRZ-2017-100-b7

Sometimes the DHT22 Values are not shown on value-Page.

on 10 measurements, 2 times the values are missed. next run / cycle the values are shown again. The values are also missing in own API. See attached screenshot of in Excel (badly) imported csv-file.

connected devices: OLED LCD HTU21 BME280 DHT22 SDS011 NEO6m

`Start reading GPS End reading GPS Start reading SDS011 PM10: 5.50 PM2.5: 2.77

End reading SDS011 Start reading DHT11/22 DHT22 couldn't be read DHT22 couldn't be read DHT22 couldn't be read DHT22 couldn't be read DHT22 couldn't be read

End reading DHT11/22 Start reading BME280 Temperature: 22.13 C Humidity: 41.67 % Pressure: 967.52 hPa

End reading BME280 Start reading GPS Lat/Lng: 47.737286,8.974895 Altitude: 431.30 Date: 11/11/2017 Time 11:30:33.00

End reading GPS Creating data string: WLAN signal strength: -42 dBm

Sending to custom api:

Start connecting to 192.168.200.2 Requesting URL: /data.php 11729146 {"esp8266id": "11729146", "software_version": "NRZ-2017-100-B7", "sensordatavalues":[{"value_type":"SDS_P1","value":"5.50"},{"value_type":"SDS_P2","value":"2.77"},{"value_type":"BME280_temperature","value":"22.13"},{"value_type":"BME280_humidity","value":"41.67"},{"value_type":"BME280_pressure","value":"96751.78"},{"value_type":"GPS_lat","value":""},{"value_type":"GPS_lon","value":""},{"value_type":"GPS_height","value":""},{"value_type":"GPS_date","value":""},{"value_type":"GPS_time","value":""},{"value_type":"samples","value":"215998"},{"value_type":"min_micro","value":"261"},{"value_type":"max_micro","value":"887264"},{"value_type":"signal","value":"-42"}]}

closing connection

End connecting to 192.168.200.2 Time for sending data: 600712 Start reading SDS011 End reading SDS011 Start reading GPS `

[ricki-z]

Please see issue #164 . This may be solved by connecting the DHT22 to the 5V pin.

[dokape]

Still with 3,27V:

third try gets data.

---

End reading SDS011 Start reading DHT11/22 DHT22 couldn't be read DHT22 couldn't be read Temperature: 23.30⸮C Humidity: 39.50%

[dokape]

GPS disconnected and deactivated: DHT and offen SDS values are missing. (Ca70%)

Going back to NRZ-2017-100-B4 (no GPS connected) is for last 26 measurecycles stable. Every cycles SDS and DHT data is shown and logged.

DHT is in 3.3V

[dokape]

"Longterm" test, > 330 measurement with older NRZ-2017-B4: from > 330 measurements: No Reboot, only 4 times the DHT22 Values were not read.

devices: SDS011, DHT22, BME280, HTU21, OLED and LCD, NO GPS.

Now checking same config with NRZ-2017-100-B8

[dokape]

Overnight-Test with NRZ-2017-100-B8: Mord than 300 cycles and no data lost. Reading data Form DHT was everytime successfull. (Logging in own raspi/Sendung to own API)

[dokape]

Test against with other nodeMCU

Minimal setup: SDS011, DHT22, OLED (for config/AP-test) NRZ-2017-100-B9: Still problems with DHT22 values. (just on 3.27V)

Conclusion: Sometimes it is running through with no problem, even with older Firmware as -100-b4 Sometimes it does not get DHT22 Data. This is on the same soldered board. I'm not really shure if this problem with lost data (problem reading data from DHT) is based on the power for the DHT. As there was not trouble with older firmwares I might suggest that there is a change between Beta 4 and beta 7 (BME280 and HTU21D have no probs) Is it perhaps a problem with definition of DS18B20 using the same port D7? Could it be possible to do more logging by calling the DHT22?

I will change my testboard to be able to switch to 5V.

[dokape]

I use for compiling the sourcecode the "DHT Sensor library from Adafruit" in Version 1.3.0 Going back to Version NRZ-2017-100-B4 the DHT22 is read without problems. (at 3.27V, measure at the DHT-pins)

Even with 5V the DHT delivers no data.

serial log: (NRZ-2017-100-B9)

---

Checksum is: 179 - should: 179 9 - 171 - ab - 171 . PM10 (sec.) : 17.50 PM2.5 (sec.): 7.60 End reading SDS011 Call sensorSDS Start reading SDS011 0 - 170 - aa - 170 . 1 - 192 - c0 - 192 . 2 - 75 - 4b - 75 . 3 - 0 - 0 - 0 . 4 - 173 - ad - 173 . 5 - 0 - 0 - 0 . 6 - 8 - 8 - 8 . 7 - 176 - b0 - 176 . 8 - 176 - b0 - 176 . Checksum is: 176 - should: 176 9 - 171 - ab - 171 . PM10 (sec.) : 17.30 PM2.5 (sec.): 7.50 PM10: 17.83 PM2.5: 7.57

End reading SDS011 Call sensorDHT Start reading DHT11/22 DHT22 couldn't be read DHT22 couldn't be read DHT22 couldn't be read DHT22 couldn't be read DHT22 couldn't be read

End reading DHT11/22 Creating data string: WLAN signal strength: -45 dBm

Sending to luftdaten.info (SDS):

Start connecting to api.luftdaten.info Requesting URL: /v1/push-sensor-data/ 526279 {"software_version": "NRZ-2017-100-B9", "sensordatavalues":[{"value_type":"P1","value":"17.83"},{"value_type":"P2","value":"7.57"}]} HTTP/1.1 403 Forbidden Date: Tue, 14 Nov 2017 09:33:52 GMT Server: Apache/2 Allow: POST, OPTIONS Vary: Accept Connection: close Transfer-Encoding: chunked Content-Type: application/json

28 {"detail":"Node not found in database."} 0

closing connection

[dokape]

Testing NRZ-2017-099 Master: DHT-Values are read. upgrade to NRZ-2017-100-B9: DHT-values are not read. No change on config, no change on hardware.

[dokape]

NRZ-2017-100-B10: Looks good. No Read-Error at serial log.

[dokape]

NRZ-2017-100-B11

Nur SDS011 und DHT22

Auf value-page werden die DHT-Daten angezeigt.

ich stecke auf meinem Test-Board den BME280 oder HTU21D dazu (stromlos) und aktiviere ihn, dann werden die DHT22 Werte nicht mehr angezeigt. Wackelkontakt etc schließe ich aus, das ist reproduzierbar, alle Sensoren sind auf einem verlöteten Board gesteckt, den DHT bewege ich nicht.

deaktiviere ich bei angesteckten HTU21D diesen im Konfigurationsmenü und führe keinen Reboot aus, Schwupps, sind die Daten vom DHT22 wieder da.

Das deutet IMHO auf eine nicht saubere Abfrage des DHT bei aktivierter I2C Abfrage ab. Oder hängt das mit der rotierenden Anzeige und Bewertung der höherwertigen Sensoren HTU21, BME280 gegenüber DHT22 zusammen? Diese werden bei der Auswahl für die Anzeige im Display bevorzugt.

[ricki-z]

Es gab ein Update der DHT Library (Version > 1.1.1)m daß wohl nicht mehr sauber mit dem esp8266 arbeitet. Ich habe die aktuelle Version mit der Library 1.1.1 übersetzt. Dort sollte das jetzt funtionieren.

[arouanet]

I have a similar setup (Airrohr sensor with SDS011, DHT22 and BME280), and I have recently noticed frequent gaps in temperature and humidity data looking at my local InfluxDB instance.

In almost all instances DHT22 data is the one missing, but I found at least one instance where BM280 data was missing instead. It could be just a coincidence though.

Here is an excerpt from the console log:

-- 0:cu.wchusbserial640 -- time-stamp -- Jun/09/18 15:23:35 --
PM10:  10.43
PM2.5: 9.40
----
DHT22 couldn't be read
DHT22 couldn't be read
DHT22 couldn't be read
DHT22 couldn't be read
DHT22 couldn't be read
----
Temperature: 21.82 C
Humidity: 100.00 %
Pressure: 1008.34 hPa
----
Creating data string:
WLAN signal strength: -77 dBm
----
[...]

Since the problem started occurring around 2018-06-03 07:00 CEST, it looks like it could be related to the release of firmware version NRZ-2018-103. Previous to this I was on version NRZ-2017-099 and the issue wasn't occurring.

[arouanet]

Following up on this, just letting you know that disabling firmware auto update and rolling back to version NRZ-2017-099 completely fixed the problem of missing DHT22 data for me.

[ricki-z]

The one wire protocol is very time dependent. So the additional functions in our firmware (and requests to the web interface) may be the reason for the missing values. The questions is: can we live with some missing values (< 5 to 10 %) or should we go back to version 099? The missing values may go away with another version of the DHT library. But all my DHT22 doesn't show missing values independent from the used library.

[dokape]

Den Effekt hab ich seit dem Update auch auf meinem live-Sytem. Seit dem Update auf v103, jetzt runde 28 400 Messungen sind immer ein paar Ausfälle dabei, die in der Regel mit dem nächsten Zyklus aber wieder angezeigt werden. Einen Grund dafür, oder wie man das provozieren kann, fällt mir nicht ein. Ich habe einen BME280 mit dran, der mir alternativ temp und feuchte anzeigt. Es scheint wohl nur in Kombination DHT22 UND BME280 zusammen aufzutreten.

Retour würde ich nicht gehen, aber beheben sollte man es in einer der nächsten Versionen.

[arouanet]

I should mention I'm also using the homebridge-airrohr Homebridge plugin as part of my setup, which queries http://feinstaubsensor-{id}.local/data.json every 3 minutes in order to collect sensor data. Maybe this could throw off the timing of the 1-Wire protocol if the HTTP query comes just at the wrong time and explain the sporadically missing DHT22 data?

I'm not sure why the problem doesn't occur with version NRZ-2017-099, though. Maybe the additional firmware code just makes it much more likely to occur. The fact that this only seems to occur on devices where both BME280 and DHT22 sensors are present is also interesting.

I agree that the problem is probably not widespread enough to warrant a rollback to version 099. I'm happy to do further testing if that helps, though.

[ricki-z]

@dokape, @arouanet could you please send me the chip IDs of your sensors and if the use of beta firmware is enabled? I would like to test different versions of the DHT library.

[ricki-z]

I have uploaded a new beta version. On my test system the missing values are gone. Could someone check this version (-B8).

[arouanet]

Hi @ricki-z, I have just sent you the chip ID of my sensor separately via email. I have enabled beta firmware and switched to NRZ-2018-104-B9.

[ricki-z]

Hi @arouanet until now this version seems to work without (or much less ) missing measurements.

[arouanet]

Hi @ricki-z, yes this seemed to have fixed it, thanks! I'm running into another problem since I switched to the beta, but I have opened a separate issue for that (#234).

[dokape]

Switches produktive to 104-b11 After more than 30 000 measure cycles on Version 103. ID 2063283

[ricki-z]

@arouanet @dokape I would like to get this version online as the release version. Is this version okay so far? My own sensor runs with that version since 3 days without restarts or any problems. But this sensor has only SDS011+BME280.

[dokape]

I'm not able to do deeper beta-test at the moment due to lack ot time :-( and some probs with my beta-test-system. It looks, as this version runs in standard config fine. But I have not info what is about displays and HTU-Sensor with this changed timing / compiling changes.

[dokape]

See #235 : No config site until first measure

[arouanet]

Hi @ricki-z, The problem of missing DHT22 data is completely solved for me in version -B11. I did notice a few restarts (2–4 times per day roughly), which I don't remember occurring before I switched to -B11, but maybe I simply didn't notice it among the missing DHT22 data.

I have just started logging again, and here is where the last reset occurred:

## Sending to madavi.de: 
Start connecting to api-rrd.madavi.de
Requesting URL: /data.php
xxxxxxx
{"software_version": "NRZ-2018-104-B11", "sensordatavalues":[...]}

Soft WDT reset

ctx: cont 
sp: 3fff2fb0 end: 3fff34b0 offset: 01b0

>>>stack>>>
3fff3160:  402428e4 00000000 3fff6ef4 00000255  
3fff3170:  00000255 00000000 00000000 fffffffc  
3fff3180:  0000005a 000005b4 00000000 401004d8  
[...]
<<<stack<<<

It looks like it crashed in sendData() while talking to api-rrd.madavi.de, before printing closing connection. Was it just killed by the watchdog because the server took too long to respond?

[arouanet]

I just had two other crashes while the firmware was attempting to send data to madavi.de. The first was another software watchdog timer reset (same as the previous one), and the second was an exception while trying to connect:

## Sending to madavi.de: 
Start connecting to api-rrd.madavi.de

Exception (29):
epc1=0x4000e1b2 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000004 depc=0x00000000

ctx: cont 
sp: 3fff2eb0 end: 3fff34b0 offset: 01a0

>>>stack>>>
3fff3050:  3fff2398 00000ff3 00000ff3 402450c3  
3fff3060:  00000208 3fffa244 3fffadb4 4024525c  
3fff3070:  00000104 00007d88 00000fb1 3fffa244  
[...]
<<<stack<<<

[dokape]

My productive Sensor is running version 104-b11 since 1530 cycles without restart.

[ropeters68]

I had the DHT22 problem only with the first measurement after a restart of the sensor (config: sds011/bme280 (temp. air inlet) and dht22 (air exit temp.) on release 107). However I moved the sensor a bit further from the accesspoint today (signal strength 74 dBm, signal quality 52%) now I have a significant drop out on DHT22 values (https://www.madavi.de/sensor/graph.php?sensor=esp8266-1029998-dht).

[dokape]

Firmware: NRZ-2018-104-B11 Mehr als 8000 Messungen, Fehler scheint nicht mehr aufzutreten.

[dokape]

FW -123b läuft seit Monaten stabil. Issue closed.