PlatformIO-Projekt für ein ESP32 DevKitC V4 mit ESP32-WROOM-32 und Arduino-Framework. Die Ausgänge steuern über Optokoppler die bereits im VXR-9000 programmierten CW-Nachrichten.

Die Eingangskanäle OK1–OK3 des Schaltplans haben je einen 470-Ω-Vorwiderstand an 5 V und einen 10-kΩ-Pull-up des Transistorausgangs nach 3,3 V. Türkontakt geschlossen bzw. aktives TX_ATT ziehen den zugehörigen GPIO auf LOW.

Die Ausgangskanäle OK1–OK3 sind im Schaltplan als PC814 mit bidirektionalen Eingangs-LEDs vorgesehen. GPIO HIGH treibt über 470 Ω eine LED gegen GND; der Transistor verbindet den VXR-PIO-Pin mit GND. Die Widerstandsnetzwerke auf der VXR-Seite werden entfernt.

Die drei PIO müssen am Funkgerät als Eingänge für die passenden CW-Nachrichten konfiguriert sein.

Im vorliegenden Schaltplan sind ESP32-GND, Optokoppler-GND und VXR-GND miteinander verbunden. Die Optokoppler bewirken hier deshalb keine galvanische Trennung zwischen ESP32 und Funkgerät. Das DevKitC darf entweder über USB oder über seinen 5-V-Pin versorgt werden; Espressif warnt vor gleichzeitiger Speisung über mehrere Versorgungswege.

• Beim Einschalten wird der aktuelle Türstatus gelesen. Eine offene Tür wird sofort für die Ansage vorgemerkt; ausgelöst wird sie erst, wenn das Relais frei ist.
• Solange eine Tür offen bleibt, wird ihre Ansage alle DOOR_REPEAT_INTERVAL_MS erneut angefordert. Beide Türen haben getrennte Timer; bei gleichzeitiger Öffnung wechseln sich die Ansagen ab. Ist TX_ATT aktiv, wartet der Controller und fasst ausstehende Wiederholungen je Tür zusammen.
• Beim Schließen einer Tür verfallen noch ausstehende Ansagen dieser Tür. Die Relaiskennung ist unabhängig vom Türzustand: PIO-3 wird nur bei aktivem TX_ATT ausgelöst, sobald seit der letzten PIO-3-Auslösung RELAY_ID_INTERVAL_MS vergangen sind (Vorgabe: 10 Minuten). Inaktive Zeiten zählen mit. Ist die Kennung bei Wiederaufnahme des Sendebetriebs bereits fällig, wird sie sofort ausgelöst. Nach einem Controller-Neustart gilt sie bei der ersten aktiven Sendung als fällig.
• Für eine Türansage werden der zugehörige Eingang PIO-1 oder PIO-2 und EXT_PTT gleichzeitig aktiviert und für DOOR_ANNOUNCEMENT_HOLD_MS gehalten (Vorgabe: 11 000 ms). Danach werden beide Ausgänge freigegeben.
• Türansagen beginnen nur, wenn TX_ATT inaktiv ist und mindestens 500 ms Sendepause vergangen sind. Während Sprache, Relaiskennung oder einer anderen Sendung bleiben PIO-1, PIO-2 und EXT_PTT inaktiv; eine fällige Türansage bleibt vorgemerkt. Gleichzeitig wird nur ein Türtext ausgelöst.
• PIO-3 für die Relaiskennung bleibt ein 250-ms-Impuls und steuert EXT_PTT nicht. Die Relaiskennung darf während einer bereits laufenden Sendung ausgelöst werden.
• Auf tuerstatus wird ein retained JSON-Payload veröffentlicht, zum Beispiel {„innen“:„offen“,„aussen“:„geschlossen“}. Das geschieht nach jeder entprellten Statusänderung, nach MQTT-Wiederverbindung und spätestens nach MQTT_STATUS_INTERVAL_MS bei bestehender Verbindung (Vorgabe: 10 Minuten). Während einer Netzstörung wird der letzte aktuelle Zustand nach Wiederverbindung veröffentlicht.
• Die Türkontakte werden 40 ms entprellt. Alle laufenden Zeiten werden mit millis() verwaltet; es gibt kein delay().

• Das WLAN wird beim Start eingerichtet. Bei Verbindungsverlust versucht der Controller alle 15 Sekunden eine Wiederverbindung. Nach WIFI_MAX_ATTEMPTS erfolglosen Versuchen (Vorgabe: 20; etwa fünf Minuten) startet das Board neu und beginnt die Versuche erneut. Ein erneutes WiFi.begin() während eines laufenden Verbindungsversuchs wird vermieden.
• Bei unterbrochener MQTT-Verbindung wird alle 5 Sekunden erneut verbunden. Nach MQTT_MAX_ATTEMPTS fehlgeschlagenen Verbindungsversuchen (Vorgabe: 20) startet das Board neu. Der TCP-Verbindungsversuch ist auf 3 Sekunden, der MQTT-Leseversuch auf 2 Sekunden begrenzt. Nach erfolgreicher Verbindung wird der aktuelle Türstatus sofort erneut auf tuerstatus veröffentlicht. Während eines PIO-Impulses beginnt kein neuer MQTT-Verbindungsversuch.
• Ein Task-Watchdog überwacht den Programm-Loop. Bleibt er länger als WATCHDOG_TIMEOUT_MS stehen (Vorgabe: 30 Sekunden, mindestens 10 Sekunden), startet der ESP32 neu. Nach dem Neustart liest der Controller die Eingänge neu und setzt die Ausgänge zunächst auf LOW.
• Der serielle Monitor (115200 Baud) zeigt den Neustartgrund einschließlich eines durch WLAN oder MQTT ausgelösten Neustarts, den Watchdog-Status sowie die Verbindungsversuche. Für eine Vor-Ort-Prüfung WLAN oder Broker kurz abschalten und die Wiederverbindung sowie die erneute MQTT-Meldung beobachten.

1. In include/config.h das WLAN-Passwort bei WIFI_PASSWORD eintragen.
2. WIFI_SSID ist DB0SL-Wlan
3. MQTT_HOST ist 192.168.144.21
4. Der lokale Broker verwendet keine Anmeldung; MQTT_USER und MQTT_PASSWORD bleiben leer
5. DOOR_REPEAT_INTERVAL_MS, RELAY_ID_INTERVAL_MS, MQTT_STATUS_INTERVAL_MS sowie optional WATCHDOG_TIMEOUT_MS, WIFI_MAX_ATTEMPTS und MQTT_MAX_ATTEMPTS können dort angepasst werden; Intervalle sind in Millisekunden, die Verbindungsgrenzen sind Anzahlen.
6. Mit ./build.sh build kompilieren und linken.
7. Mit ./build.sh all bauen, auf das ESP32 DevKitC V4 flashen und anschließend den seriellen Monitor mit 115200 Baud öffnen.