Open blebbens opened 7 years ago
Wir möchten möglichst viele Sensoren haben, die 24 Stunden messen. Es ist aber kein Problem, das Router-WLAN abzuschalten. Der Sensor sollte die Verbindung wieder aufbauen, sobald das WLAN wieder da ist. Die Abschaltung des Sensor-WLANs zu programmieren erzeugt wieder einen "Spezialfall", der selten gebraucht wird, im Zweifelsfall die Stabilität der Firmware gefährdet und Speicher kostet, den wir gern für die Unterstützung weiterer Sensoren nutzen möchten.
Hi ricki-z, Auch ich habe eine WLAN Nachtabschaltung. Aktuell entstehen hierdurch Lücken in den Messungen. Wie wäre es, wenn man alle Werte grundsätzlich cached und nach der Messung versucht alle Werte aus dem Cache zu übertragen? Dies würde dieses Problem für viele lösen und die Daten wären für die Historie vollständiger. Wäre es sehr aufwendig einen Datencache hinzuzufügen?
Möchte WLAN zumindest nachts deaktiviert haben verstehe ich immer nicht, weswegen denn genau?
- Strom sparen? marginal
- Strahlung? alle Clients versuchen es dann mit maximaler Leistung
- Kinderschutz? Kann auch im Router richtig eingestellt werden
Na ja, aber generell sollte man dann über eine SD Karte nachdenken, das geht wohl.
Stand September 2017: Caching von Daten, die nicht gesendet werden können, wird in absehbarer Zeit nicht implementiert. Die Firmware belegt inzwischen die Hälfte des Speichers, zum bequemen Auto-Update der mehreren Hundert Sensoren wird das als deutlich wichtiger angesehen. Werden keine Daten gesendet, fehlen sie halt in der Datenbank. auf der maps.luftdaten.info werden nur nodes angezeigt, die in den letzten 5-10 Minuten Daten gesendet werden. Fehlende Daten sind daher zwar nicht schön, aber kein Beinbruch.
Die Größe der Firmware ist weniger der Grund. Wir wissen nicht, wie gut das Dateisystem (SPIFFS) arbeitet. Flash hat ja nur einen begrenzte Anzahl von Schreibzugriffen. Wir würden also beim Zwischenspeichern der Werte einen schnelleren Ausfall der NodeMCU riskieren.
Konnte das NTP Problem inzwischen gelöst werden? Müssen die Daten eigentlich im Dateisystem gepuffert werden, würde das RAM für 8 Stunden Puffer dafür nicht reichen?
Das NTP-Problem ist "gelöst". Wir prüfen nun erst, ob ein NTP-Server erreichbar ist, bevor die Zeit geholt wird. Und RAM ist einfach immer knapp. Schon ein 4096-Bit-Zertifikat statt eines 2048-Bit-Zertifikats lässt die Firmware wegen fehlendem RAM abstürzen. Das eine sind 512 Byte, das andere 256 Byte, also kein so großer Unterschied. Bei der normalen Konfiguration haben wir 4 4-Byte-Werte mal 24 Messungen pro Stunde, also mind. 384 Byte. Nach ca. 1-2 Stunden würde uns also der RAM ausgehen. Davon abgesehen ist die Datenbank aktuell nicht darauf ausgelegt, das Daten später eingefügt werden.
Das hört sich an als ob der ESP8266 schon ziemlich am Limit operiert. Können in diesem Fall noch andere Features eingebaut werden? Gibt es Ideen wie man diese Beschränkung umgeht?
Ich habe vom ESP8266 Nachfolger ESP32 gelesen der u.a. mehr Speicher anbietet. Er wird auch in den Issues hier öfter als Nachfolger erwähnt (z.B. die Issues #164, #231, #212). Gibt es konkrete Versuche die Firmware auf den ESP32 zu portieren?
Für die ESP8266 spezifischen Bibliotheken (ESP8266WiFi, ESP8266WebServer, ESP8266httpUpdate) gibt es Portierungen: Wifi, WebServer und httpUpdate
Eine Umsetzung auf den ESP32 ist in Arbeit. Dann wahrscheinlich gleich mit LoRaWAN-Unterstützung. Was den RAM angeht, sind einzelne Erweiterungen durchaus auch noch möglich. Das lokale Speichern der Messwerte ist nur wegen der Menge ein Problem. Für einen zusätzlichen Sensor benötigen kaum mehr RAM. Und vieles, was statisch ist, kann direkt aus dem Flash gelesen werden, wenn es benötigt wird.
Super, Danke für die Infos.
Hi,
Habe nun alles gem. Wiki im Betrieb inkl. DHT22 und OLED.
Eines wäre mir wichtig: Kann die NodeMCU in den sleep mode versetzt werden und beispielsweise halbstündlich/stündlich messen und auch erst dann WLAN aufbauen?
Möchte WLAN zumindest nachts deaktiviert haben und die NodeMCU länger im sleep modus betreiben durch weniger Messungen.