DatenĂĽbertragung
Im Jitsi-Call ganz richtig gesagt wurde ja, dass die Datenübertragung keine zentrale Funktion einer CO_2-Ampel ist. Im Prinzip genügt es völlig, wenn mit Farben angezeigt - und evtl. noch mit einem Piepen drauf aufmerksam gemacht wird, wenn gelüftet werden sollte. Daher:
Erste Eskalationsstufe:
- bunte LED
- Buzzer (Stufe 1b)
Zweite Eskalationsstufe:
- Lokale Anzeige des Messwerts (LCD / OLED / …)
Dritte Eskalationsstufe:
- DatenĂĽbertragung nach aussen (WLAN / LoRaWAN)
So lange man auf der ersten oder zweiten Eskalationsstufe bleibt, ändert sich auch meine vorhin geschriebene Beurteilung zur CPU grundlegend … dann tut’s ein kleiner Mikrocontroller (Arduino Uno / Nano / Microchip PIC / …) locker.
FĂĽr die DatenĂĽbertragung nach aussen gibt es grundlegend die Alternativen WLAN oder LoRaWAN (andere Alternativen: noch nicht drĂĽber nachgedacht oder schon verworfen).
Dafür spricht, dass schon interessante Werte dabei heraus kommen die dann mit schönen bunten Graphen im Klassenzimmer oder im Direktorat blinken können. Dagegen spricht, dass schon interessante Werte dabei herauskommen, die dann irgendwo herumliegen und die irgendwie mittel-leicht-sicher abgelegt werden sollten. Wär ja blöd, wenn jemand anhand der Sensor-Daten verfolgen kann, dass die erste Schulstunde um 07:45 anfängt <hüstel>. Jetzt kann gerne eine beliebig ausgedehnte Datenschutz-Diskussion folgen.
WLAN hat im Vergleich zu LoRaWAN vor Ort einen hohen Konfigurations- und administrativen Aufwand, daher ist LoRaWAN schon sinnvoll, macht die Material-Kosten halt um ca. 10 bis 20 Euro je Ampel teurer.
Die Geräte können bei der Herstellung vorprogrammiert werden und schicken dann sobald ein Gateway erreichbar ist ihre Daten ohne weiteren Konfigurations- oder sonstigen Aufwand ins TTN. Von dort kann (muss nicht) sie der jeweilige “Endkunde” dann mit MQTT oder auf einem der anderen vom TTN angebotenen Wege abholen und kann unkompliziert seine schicken Graphen zaubern oder die Daten in Moodle integrieren. Da ist noch kurz zu klären bzw. bei der Programmierung zu berücksichtigen, ob und wie das beim TTN noch unter “fair use” fällt oder schon darüber hinaus geht. Die notwendige Infrastruktur ist kein Hexenwerk und sollten wir im Netzwerk hinbekommen können, auch wenn’s natürlich nicht vom Himmel fällt.
Am Ende ist es meiner Meinung nach sinnvoll, wenn man in die Richtung geht, auf einer Trägerplatine einen Layout-Teil für LoRaWAN zu berücksichtigen … und den Bereich nur bei einem Teil der am Ende hergestellten Ampeln (je nach Bedarf) zu bestücken. Auf der Platine stört der unbestückte Bereich nicht … und bei Bedarf hat man (auch nachträglich noch) die Option, den Bereich zu bestücken - oder eben auch nicht.
In einer “handverdrahteten” LowLevel-Variante kann man das ähnlich tun, indem irgendwo ein optionaler Montageplatz für ein LoRa-Shield (z.B. Dragino) vorgesehen ist.
