Entwicklungen

Diese Seite ist nicht editierbar. Du kannst den Quelltext sehen, jedoch nicht verändern. Kontaktiere den Administrator, wenn du glaubst, dass hier ein Fehler vorliegt.
===== CoronaLuft - Luftqualität-Anzeige =====

{{:corona_display_smartphone_co2_luftqualitaet_app.jpeg?400 |}}"Ein Sensor zum Schutz vor Infektionen mit dem SARS-CoV-2-Virus?"- Reißerische Frage auf der Digitalzimmer-Website. Ganz so weit würde ich nicht gehen, aber:

Eine Ansteckung mit Corona kann auch durch die Luft erfolgen. Dabei spielt das Raumklima eine wichtige Rolle. [[https://www.tfa-dostmann.de/corona-virus-temperatur-luftfeuchtigkeit/|Externer Link]].
Hohe Luftfeuchtigkeit, niedriger CO<sub>2</sub>-Gehalt und mittlere Temperatur scheinen den Aerosol-Tröpfchen Einhalt zu gebieten.

Mit wenigen Bauteilen und etwas KnowHow habe ich mir eine Corona-Warn-Anzeige gebaut.

Grundlage ist ein ESP8266 (Wemos D1 mini), ein BME280 (Temperatur, Luftfeuchtigkeit und mehr), sowie ein CCS811 (CO<sub>2</sub>) - zusammen ca. 20€ (wenn man nicht im Ausland bestellt).

Zusätzlich sind inzwischen noch zwei LEDs und ein passiver Buzzer dazu gekommen.

Die Software macht den Rest, und die hat mich (mal wieder) am meisten Zeit und Nerven gekostet.

Funktionen:
  * die blaue OnBoard-LED blinkt jeweils zwei Mal im Intervall. Halbe Helligkeit für 'Wert in Ordnung', volle Helligkeit für 'Wert außerhalb des Normbereiches'. Das ganze mittels Pulsweitenmodulation (PWM).
  * mit den beiden LEDs wird es etwas einfacher. Eine dient zur Anzeige ob die Feuchtigkeit zu niedrig, die andere ob CO<sub>2</sub> zu hoch ist. Da die Feuchtigkeit fast immer unter den gewünschten 50% ist, gibt es dort nur an/aus. Bei CO<sub>2</sub> steigert sich die Blinkfrequenz bis sie komplett an ist. Da die LEDs ohne Vorwiderstand betrieben werden, zur Sicherheit nicht mit voller Leistung (PWM).
  * Wenn alles OK ist, 'atmet' die blaue LED im 6 Sekunden Rhythmus (Sinus und PWM) und die beiden LEDs sind aus.
  * Es wird ein Access-Point "CoronaLuft" aufgebaut, an den man sich anmelden kann. Statt einer Anmeldemaske (Captive Portal) erreicht man eine Übersichtsseite, von der aus man die grafische Darstellung der aktuellen Sensordaten erreicht.
  * Die Daten werden im ESP8266-SPIFFS Dateisystem gepuffert und die Grafische Anzeige, die mit Chartjs realisiert wurde, damit aktualisiert.
  * Es wird ein Fake-AccessPoint erstellt, der im WLAN-Fenster den Status der Luftqualität anzeigt. "CoronaLuft:WARN(CO2)" bzw. "CoronaLuft:WARN(Hyg)" oder "CoronaLuft:WARNUNG". Man kann sich mit diesen APs allerdings nicht verbinden!
  * Der Buzzer spielt ein paar Töne, wenn das CO<sub>2</sub> extrem hoch ist.
  * OverTheAir Update - so können neue SoftwareVersionen automatisch eingespielt werden
  * Software für ESP8266 und ESP32
  * Anbindung an Heimnetz-Router, ESPNOW Geräte und MQTT
  * Schwellwerte für CO<sub>2</sub>, Feuchtigkeit einstellbar

Vorteile:
  * unabhängig von Routern und WiFi-Netzen
  * Grundinfos optisch, Detailinfos über eine Webseite. Smartphone unabhängig. 
Nachteile:
  * Man muss sich mit einem 'fremden' WLAN verbinden und verliert damit kurzfristig eine mögliche andere WLAN-Verbindung.

Erweiterungen:
  * erweiterbar um die restlichen Sensor-Informationen. Dann müssen aber weitere Webseiten erstellt werden, da der Platz für Daten und Grafiken nicht reicht.
  * Schwellwert Einstellungen - wann wird aus dem 'atmen' ein Blinken, blitzen, klicksound, sound
  * Verbindung mit eduroam
  * Auslesen und schreiben der baseline des CO<sub>2</sub>-Sensors
  * Schnellerer http-server. Gefühlt dauert der erster Aufruf manchmal lange.
  * Den zweiten Core des esp32 nutzen

Erstes Prototyp-Gehäuse habe ich mit FreeCAD erstellt und Erwin hat es mir gedruckt. 
Jetzt brauche ich nur noch jemanden, es vermarktet :)

Warum ich es nicht selbst mache? Müsste mich selbständig machen, Papierkram, CE-Kennzeichen, Gewährleistung, Patentieren,...

=== SPIFFS plus RTC plus EEPROM ===
Ich nutze alle drei, obwohl ich nicht sicher bin, ob die den gleichen Speicherbereich nutzen. RTC um einen zweifachen Reset anders abzufangen; SPIFFS, um die Sensor-Daten zu speichern und die Grafik html-Library. Und jetzt EEPROM, um die Settings der App zu speichern. Könnte ich zwar auch in SPIFFS, aber EEPROM kenne ich noch nicht :)

Es sind wohl maximal 4096 bytes, aber das reicht mir.


<code>
|--------------|-------|---------------|--|--|--|--|--|
^              ^       ^               ^     ^
Sketch    OTA update   File system   EEPROM  WiFi config (SDK)
</code>

Um im EEPROM eine Zahl größer als 255 zu speichern braucht man 2 Bytes. Das speichert und liest man dann so:
<code>

  EEPROM.write(1, highByte(s_co2low));
  EEPROM.write(2, lowByte(s_co2low));


  s_co2low   = EEPROM.read(1)*256+EEPROM.read(2);
</code>
Sollten die gelesenen Werte nicht zu den geschriebenen passen, liegt es vielleicht an dem Aufruf, mit dem man die Anzahl der zu bearbeitenden Bytes setzt.
    EEPROM.begin(EEPROM_SIZE);

Ich musste den 'Double Reset Detector' nach dem OTA-Update ausführen, sonst hat er nach dem OTA immer gemeint, er wäre redetet worden
(ist aktuell wieder entfernt, da er Probleme macht).

mDNS: Ich frage nicht, ich habe es nur nach ewig langer Zeit zum laufen gebracht. Ob es die Reihenfolge war (MDNS.begin(myHostname) vor server.begin), oder eher die beiden Zeilen
  MDNS.addService("http", "tcp", 80); im init
  MDNS.update(); im loop
weiss ich nicht, aber es geht (endlich).

Der CO<sub>2</sub>-Sensor macht mir Kopfzerbrechen. Er schaukelt sich auf und nach dem Lüften kommt er schnell an den alten hohen Wert. (reset probieren?).

**Wenn man den Sensor von der Batterie trennt, wird der nächste Wert als Frischluft erkannt, egal wie schlecht sie ist!
Der Sensor braucht bis 20 Minuten, bis stabile Werte vorliegen.** Beide Infos sind aus dem Datenblatt.

Baseline ist der Wert, den er über die Zeit (24 Stunden) als Frischluft erkennt. Speichern und nach 20 Minuten wieder 'einsetzen'. Vorher führt es zu extrem hohen Werten, da es eine steil ansteigende und sich dann (20 min) abflachende Widerstandskurve ist. Da sich der Sensor über die Wochen verändert muss man immer mal wieder die Baseline abspeichern (siehe auch dort das [[https://cdn.sparkfun.com/assets/learn_tutorials/1/4/3/CCS811_Datasheet-DS000459.pdf|Datenblatt]]). 

Um die Daten zu verbessern habe ich den CCS811 auch von Version 1.1 (bekommt man [[https://github.com/maarten-pennings/CCS811/tree/master/examples/ccs811basic|hiermit]] raus)auf 2.0 [[https://github.com/maarten-pennings/CCS811/tree/master/examples/ccs811flash|geflashed]]. Danke an Marrten Hennings, dessen [[https://github.com/maarten-pennings/CCS811|CCS811 Library]] ich jetzt statt der von Adafruit nutze.

Das Übergeben der Werte machte Probleme, da man Temperatur und Feuchte erst umwandeln muss bei der Library. Habe ich nach dem Datenblatt gemacht.

Zwischenzeitlich hatte ich auf Asynchronen Webserver umgestellt, da gab es aber Probleme mit dem AccessPoint und schnellem Wechsel der Seiten, bzw. wenn mehrere Icons drin waren, die parallel geladen wurden. Dann rebootete der Chip dauernd.Sogar im Default-Webserver musste ich etwas auskommentieren, damit es keine Probleme gibt. 

Inzwischen habe ich einen weiteren Sensor MHZ-19B. Drei Sensoren, drei unterschiedliche Ergebnisse *Seufz* MHZ zeigt 600, und die anderen 1200 und 1800. Wer misst, misst Mist.

Inzwischen habe ich vier verschiedene Versionen des Raumluft Messgerät im Einsatz. Verschiedene Sensoren, unterschiedliche Prozessoren - von ESP 01 über esp8266 bis esp32 wroom und Memos D1 mini. Programmiert über die Arduino Oberfläche. Übertragen wird per Wi-Fi, ESP-Now, MQTT und Seriell.

Die kommunikation zwischen den Sensoren und dem Raspberry Pi der Heimautomation geschieht unter anderem mittels i2c.

Die Anzeigen gehen von Leuchtdiode über im Heimnetz eingebundene Webseiten - Webservice - bis hin zu eigenem Access-Point und dort dargestellten Webseiten mit Grafiken.

Stand 11/2020

~~DISCUSSION~~