Dabei wird per Interrupt eine Veränderung (FALLING) der LED Steuerleitungen überwacht. Zusätzlich wird an die Steuerleitung des Buzzers ein Ausgang gelegt. Optional kann der analoge Eingang zur Überwachung der Batteriespannung eingesetzt werden (Mindestens 200k Ohm Widerstand fehlen noch, dies hat aber rund 10µA (gemessen 6,96µA bei ~3,8V VBAT zur Folge). 3 volle LSD-NiMH kommen auf 4.4V ohne Last, nach Schottky-Diode 4.2V. Damit wäre vermutlich der geringe Ladestrom nicht übermäßig schädlich. Ein einfacher LiPo Akku mit Schutzschaltung dürfte ebenfalls hinreichend gut funktionieren.
Durch die zwei Spannungsversorgungen und sowie unterschiedlichen VCC Rails ergeben sich in der Signalverarbeitung Probleme:
1. Die ESP8266 GPIOs sind nicht 5V tolerant (https://www.espressif.com/sites/default/files/documentation/Espressif_FAQ_EN.pdf Punkt 5.14)
2. Die Spannungslevel nach einem unidirectionalen LevelShifter sind falsch (https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf Kapitel 5.1)
3. Die Spannungslevel funktionieren wenn die Batterien an Spannung verloren haben und die V_USB des wemos D1 mini die VCC vom RM370 übernimmt
4. Wenn das Wemos D1 Board ohne Spannung ist, schweben die einzelnen GPIO
Der Versuchsträger führt die Kabel nach unten hinaus, die wemos D1 mini Platine (3,5cm x 2,5cm) sowie der Logic Level Shifter (1,5cm x 1,5cm) passen auch auf den Batteriehalter innerhalb des Gehäuses. Problematisch ist die Kabelführung, da die Befestigungsschrauben das PCB ohne größere Spalte an das Gehäuse drücken. Wenn dünne Einzellitzen (z.B. wire wrapping wire 26AWG) genutzt werden, so können diese durch die vorhandenen Löcher der JTAG-Header gezogen werden. Alternativ kann je nach Stärke auch an der Platine zur LED Seite bzw. beim Buzzer nach oben hin Kabel durchgeführt werden.
Mittels Diode (1N400X) kann man den freien V+ Pin nutzen. Damit kann das PCB auch über die Versorgungsspannung betrieben werden. Es liegen dann ~4,2V am Batteriekasten an! Die Nutzung von zwei BAT43 Dioden würde einerseits geringere Spannungsverluste bedeutet, andererseits den Reverse Current in den Batteriekasten verhindern. Die 4.2V
## Verkabelung
| Funktion | Pin ESP | LLS | RM370 |
|-----------|-----------|-----|--------|
| rote LED | D7 | 3 | R8 TP |
| gelbe LED | D6 | 2 | R13 TP |
| grüne LED | D5 | 1 | R12 TP |
| Buzzer | D2 | 4 | R7 TP |
| GND | GND | GND | (-) |
| VCC RM370 | - | HV | D3 TP |
| 3V3 RM370 | - | LV | R35 TP |
| VUSB ESP | 5V 1N400X | - | V+ |
| Batterie | A0 200k | - | (+) |
Grundverbrauch liegt bei 20 bis 30 µA (Errechnet: I=0.000059), nach der Modifikation liegt der Verbrauch bei rund 69µA.
Der eigentliche CO-Melder wird nicht verändert, es werden lediglich die Zustände erfasst und per WLAN weitergeleitet. Hierbei kommt ESP-Now zum Einsatz, ein WiFi Vendor Frame Format, welches ohne AP auskommt. der Payload wurde in einer Struktur geordnet, sodass man eine Präamble, eine eindeutige Kennung, den codierten Zustand sowie ein Flag für geringe Batteriespannung mitteilen kann.
Maximal sind 20 Teilnehmer zugelassen, diese nutzen den Channel 3 und geben sich als AP mit der Kennung "CO-WARN" aus.
Der Sketch verarbeitet maßgeblich zwei folgende Aufgaben:
Hierzu werden die LEDs per Interrupt überwacht. In der Realität leuchten die LEDs nur kurz aber für einen Menschen erkennbar auf, dies ist aber zu lange für eine einmalige Interruptauslösung. Die Beschränkung auf FALLING funktionierte nicht wie erwünscht. Grundsätzlich wird in den Interrupts für die LEDs wird der Eigenzustand im Strukt rm370 ownState gespeichert, zusätzlich wird der globale Status angepasst.
Sollte der globale Status nicht dem Eigenen entsprechen, so wird der Buzzer aktiviert. Ist der Buzzer durch das System selbst schon aktiv bzw. die LED rot oder gelb leuchten, dann wird der Buzzer nicht beeinflusst.
Werden Nachrichten empfangen, so werden diese mit dem eigenen Status abgeglichen und bei Code 'rot' oder 'gelb' wieder per Broadcast weitergeleitet. Weiterhin wird geprüft, ob diese Kennung schonmal empfangen wurde.
