Closed GeStenZ closed 6 years ago
Ich kann diesen Fehler leider nicht nachvollziehen: https://www.madavi.de/sensor/graph.php?sensor=esp8266-13597771-bme280 https://www.madavi.de/sensor/graph.php?sensor=esp8266-13597771-sds011 Auf dieser Node läuft die Version NRZ-2017-99. Und auf über 300 Sensoren in Bulgarien, die alle ebenfalls diese Kombination nutzen. Der Fehler scheint also eher die Ausnahme denn die Regel zu sein. Bist du sicher, das du einen BME280 und nicht einen BMP280 erhalten hast? Die sehen bis auf einen Buchstaben ziemlich gleich aus.
Ich habe SDS, DHT und BME280 angeschlossen und aktiviert. Mit Software -099 läuft das sehr stabil. Ich habe über Wochen keine Notwendigkeit für einen Soft oder HardReset.
Könnte der SDS nen knacks haben? Oder eine schlechte Steckverbindung?
Ich habe bei meinem Sensor das gleiche Verhalten wie GeStenZ. Nach einer gewissen Zeit im Dauerbetrieb (2.5 Tage könnten hinkommen) werden für den SDS keine Werte mehr ausgegeben... Ich habe folgenden BME280 angeschlossen: https://de.aliexpress.com/item/Hohe-Genauigkeit-BME280-Digital-Sensor-Temperatur-Luftfeuchtigkeit-Luftdruck-Sensor-Modul-GY-BME280-I2C-SPI-1-8/32672210336.html
@Alive84 @GeStenZ : Könntet ihr eure Konfig hier posten? Und ob ihr regelmäßig Daten vom Sensor abruft (/data.json). Eigentlich kann es nur ein Stack Overflow sein, der sich sehr langsam aufbaut. Da wäre es gut zu wissen, bei welcher Funktion der auftritt.
Meine Config: Alles disabled, bis auf: SDS011 (Feinstaub) BME280 Auto Update DebugLevel: 3 Messintervall : 300 Dauer Routermodus: 600 Abgeholt werden die Daten vom FHEM-Modul LuftDatenInfo von der Sensor-IP alle 300 s. Die ganze Sache läuft testweise noch auf dem Schreibtisch.
Bei mir sind die Einstellungen, abgesehen vom Messintervall (default Wert 145), genau wie bei GeStenZ. Die Sensordaten werden alle drei Minuten per PHP Script im json Format (/data.json) abgerufen.
Das sieht dann doch sehr nach einem Fehler in der Auslieferung der /data.json aus. Ich schaue mir das bei der aktuellen Beta mal genauer an.
Das wäre ja fies zu testen. Nach 2-3 Tagen regelmäßigem Abruf Ausfälle.
Wenn es der Stack ist kann man dessen Größe bei jedem Schleifendurchlauf ausgeben lassen. Im Sourcecode der Beta Version am Ende die // in der Zeile // Serial.println(ESP.getFreeHeap(),DEC); entfernen.
Ich habe aktuell einen Test laufen mit 3 Displays (LCD1602, LCD2004, OLED), 5 Sensoren (SDS011, DHT22, BMP180, BME280, HTU21D) und 3 aktiven APIs (Luftdaten, Madavi, opensensemap). Die Daten werden durchgehend via HTTPS an die APIs geschickt. Aktuell bin ich bei knapp 2000 Messzyklen, also fast 3 Tagen. Noch nicht getestet ist der regelmäßige Abruf der /data.json.
Just a wild guess:
Biggest 32bit integer: 2147483647
2147483647 / 24 / 60 / 60 / 1000 = 2.485
Some int32 counter is increased every millisecond and gets reset after roughly 2.5 days.
Hallo die Runde
Wir können das Problem streichen. Es lag am Netzteil. - Ich habe einige Wochen Versuche gemacht und den Sensor an einem Raspi laufen gelassen, um die Debug-Ausgaben mitzuschneiden. Dort trat das Phänomen nicht auf. Zurück zum Netzteilbetrieb. Da war es wieder da. Nach einem Wechsel auf ein anderes USB-Netzteil lief der Sensor dann durch. Mit dem betroffenen Netzteil gab es einen Spannungseinbruch der Versorgungsspannung auf 4.4 V bis 4.5 V. Mit dem neuen Netzteil waren es nur 4.7 V. Offenbar reagiert der SDS irgendwann empfindlich auf diesen Einbruch. Seltsam nur, daß es immer etwa 2 Tage dauerte. Ich schließe damit das Thema.
Danke für die Unterstützung! ...und die Geduld.
Habe den Sensor mit einem DHT nachgebaut. Das ganze lief etliche Wochen ohne Probleme. Wegen der 99.9 % Luftfeuchte-Problematik habe ich den DHT22 entfernt und einen BME280 angeschlossen. In dieser Konfiguration (NRZ-2017-99) tritt nach etwa 2.5 Tagen reproduzierbar folgendes auf:
Habe testweise wieder auf den DHT umgestellt. Da läuft alles durch. Hängt sich hier die Messung eventuell in der Firmware auf (Zähler o.ä.), wenn ein BME280 aktiviert ist?
Ergänzung: Läuft mit einem Wemos D1 mini.