Probleme mit Interrupt (Türklingel)

[Silva (Gast)]

Guten Morgen,

ich habe vor einiger Zeit eine Türklingelüberwachung aufgebaut. Diese
basiert auf einem Wemos D1 Mini (ESP8266). Ich verwende vier Dioden und 
einen Lastwiderstand um die Wechselspannung (12V) gleichzurichten, 
danach geht das auf einen Optokoppler (PC817), der widerrum an dem Wemos 
D1 Mini hängt.
Beim drücken des Klingelknopfes erfolgt eine Benachrichtigung per MQTT.

Ich habe aktuell keine Bilder vom Aufbau, da ich momentan nicht zuhause 
bin.

Nun ist es jedoch so, dass wenn ich den Klingelknopf drücke in ca. 1/3 
der Fällen keine Benachrichtigung erfolgt, anscheinend wird auch der 
Interrupt nicht ausgelöst. Der ESP ist während der Zeit jedoch per 
Netzwerk erreichbar, es werden auch keine MQTT Pakete verschickt (habe 
ich mitgesnifft).

Der Code sieht in etwa wie folgt aus (nur die relevanten Teile):

/* Doorbell state */
volatile byte doorbell_state = HIGH;

/* Timer */
Timer t;

/* Setup functipn */
void setup() {
  /* Startup delay */
  delay(100);

  /* Set CPU frequency */
  system_update_cpu_freq(CPU_FREQ);

  /* Deactive LED_BUILTIN */
  pinMode(LED_BUILTIN, OUTPUT);  
  LED_OFF();

  /* Initialize serial */
  initSerial();

  /* Connect to WIFI */
  initWifi();
  if(!connectWifi()) {
    /* Show WIFI status */
    wifiStatus();
    
    _print(F("Failed."));
    ESP.restart();
    delay(10);
    while(1);
  }

  /* Display WiFi status */
  wifiStatus();

  /* Initialize mqtt */
  mqtt.begin(MQTT_RECEIVER, client);

  /* Initialize OTA */
  #ifdef USE_OTA
  initOTA();
  #endif

  /* Initialize sensors */
  /* Pull-up doorbell PIN to prevent floating input */
  pinMode(DOORBELL_PIN, INPUT_PULLUP);

  /* Attach interrupt handler to doorbell PIN */
  _debug("Attaching interrupt");
  attachInterrupt(digitalPinToInterrupt(DOORBELL_PIN), ISR_doorbell, FALLING);

  /* Setup timers */
  t.every(60*1000, sendMQTTHello);
}

/* Loop */
void loop() {
  /* Handle OTA */
  #ifdef USE_OTA
  handleOTA();
  #endif

  /* Check doorbell state */
  if(doorbell_state == LOW) {
    doorbell_state = HIGH;
  
    /* Send data */
    _debug("PIN changed to low");

    /* Send doorbell state */
    sendDoorbellState(true);

    /* Delay some time before reattaching interrupt */
    delay(500);

    /* Re-attach interrupt handler to doorbell PIN */
    attachInterrupt(digitalPinToInterrupt(DOORBELL_PIN), ISR_doorbell, FALLING);
  }

  /* Update timer */
  t.update();
}

/* Doorbell ISR */
void ISR_doorbell() {
  /* Disable interrupt */
  detachInterrupt(digitalPinToInterrupt(DOORBELL_PIN));
    
  /* Set state to low */
  doorbell_state = LOW;
}

Hat jemand eine Idee wo ich ansetzen könnte?

Vielen Dank!

[Silva (Gast)]

push Jemand eine Idee? :)

[Johannes S. (Gast)]

wofür ist das detachInterrupt und re-Attach in der loop? Normalerweise 
reicht es einmal den Int scharf zu schalten.

[Silva (Gast)]

Ich habe das so als "einfachen" debounce verwendet, könnte das ein 
Problem darstellen?

[Johannes S. (Gast)]

bin kein Arduino/ESP Experte, aber im detach passiert schon einiges.
Ein einfaches debounce wäre in der loop erst nach dem MQTT senden und 
warten den 'doorbell_state = HIGH;' auszuführen.

[Silva (Gast)]

Danke, das werde ich heute abend mal testen!

[Silva (Gast)]

Hallo zusammen,

so ich habe den Code jetzt gestern mal wie folgt verändert, das Problem 
scheint etwas besser geworden zu sein, jedoch besteht es immer noch (ca. 
jedes 6 Klingeln führt nicht zu einer Benachrichtigung):

/* WiFi client */
WiFiClient client;

/* MQTT */
MQTTClient mqtt(2000);

/* Doorbell state */
volatile byte doorbell_state = HIGH;

/* Enable ADC_VCC mode */
ADC_MODE(ADC_VCC);

/* Timer */
Timer t;

/* Setup functipn */
void setup() {
    /* Startup delay */
  delay(100);

  /* Set CPU frequency */
  system_update_cpu_freq(CPU_FREQ);

  /* Deactive LED_BUILTIN */
  pinMode(LED_BUILTIN, OUTPUT);  
  LED_OFF();

  /* Initialize serial */
  initSerial();

  /* Connect to WIFI */
  initWifi();
  if(!connectWifi()) {
    /* Show WIFI status */
    wifiStatus();
    
    _print(F("Failed."));
    ESP.restart();
    delay(10);
    while(1);
  }

  /* Display WiFi status */
  wifiStatus();

  /* Initialize mqtt */
  mqtt.begin(MQTT_RECEIVER, client);

  /* Initialize OTA */
  #ifdef USE_OTA
  initOTA();
  #endif

  /* Initialize sensors */
  /* Pull-up doorbell PIN to prevent floating input */
  pinMode(DOORBELL_PIN, INPUT_PULLUP);

  /* Attach interrupt handler to doorbell PIN */
  _debug("Attaching interrupt");
  attachInterrupt(digitalPinToInterrupt(DOORBELL_PIN), ISR_doorbell, FALLING);

  /* Setup timers */
  t.every(60*1000, sendMQTTHello);
}

/* Loop */
void loop() {
  /* Handle OTA */
  #ifdef USE_OTA
  handleOTA();
  #endif

  /* Check doorbell state */
  if(doorbell_state == LOW) {
    /* Debug information */
    _debug("PIN changed to low");

    /* Send doorbell state */
    sendDoorbellState(true);

    /* Reset doorbell state */
    doorbell_state = HIGH;
  }

  /* Update timer */
  t.update();
}

/* Doorbell ISR */
void ICACHE_RAM_ATTR ISR_doorbell() {
  static unsigned long last_interrupt_time = 0;
  unsigned long interrupt_time = millis();

  /* Debounce handling */
  if(interrupt_time - last_interrupt_time > DEBOUNCE_TIME) {
    /* Set state to low */
    doorbell_state = LOW;
  }

  last_interrupt_time = interrupt_time;
}

Hat jemand noch eine Idee? Ich glaube langsam fast nicht mehr, dass es 
am
Code liegt...


Danke für alle Antworten!

[Johannes S. (Gast)]

testest du immer mit der Klingelschaltung oder einem einfachem Taster 
gegen GND um das Senden auszulösen?
Kommt das Hello immer durch? Beim ESP gibt es ja das Standardproblem das 
der eine gute Versorgung braucht und möglichst noch einen 
Pufferkondensator über das Board.

[Silva (Gast)]

Hi!

Also ich teste immer direkt mit der Klingel, der ESP ist inzwischen fest 
eingebaut. Die Hellos kommen immer durch, ja. Ich habe den Traffic 
komplett mitgesnifft (tcpdump). Es scheint einfach so, dass der 
Interrupt manchmal nicht ausgelöst wird und daher auch keine Daten 
gesendet werden.

Der Aufbau ist übrigens auf einer Platine, alles ist fest verlötet. Ich 
habe diese nochmals geprüft, Kontakte sind soweit ich das gesehen habe, 
alle in Ordnung, habe auch alles - soweit sinnvoll - durchgemessen.

Gibt es evtl. konzeptionell noch etwas, was ich falsch machen könnte?

Der Aufbau ist wie gesagt eigentlich sehr einfach, vier Dioden als 
Brückengleichrichter, ein Lastwiderstand, danach auf den Optokoppler 
(PC817), der geht dann direkt an den ESP. Der ESP hängt an einem 
separaten, stabilisierten  5V Netzteil (kann max 15W liefern).

Viele Dank!

[Johannes S. (Gast)]

Und der PC817 hat einen passenden Vorwiderstand? Ein kleiner Elko wäre 
auch sinnvoll, der GL liefert ja eine pulsierende Gleichspannung und der 
Int wird mit 100 Hz getriggert.

[Silva (Gast)]

Hallo,

ja einen passenden Vorwiderstand hat er. Elko ist aktuell keiner 
verbaut,
dieser dann direkt nach dem Brückengleichrichter und vor dem 
Optokoppler?
Von der Größe reichen vermutlich ein paar uF oder?


Danke für deine Hilfe!

[Theor (Gast)]

Silva schrieb:
> [...] Es scheint einfach so, dass der
> Interrupt manchmal nicht ausgelöst wird und daher auch keine Daten
> gesendet werden.
>
> [...]

Es scheint mir (sic!) sinnvoller die Schaltung aus dem Gleichrichter, 
Widerstand und Optokoppler zunächst einzeln zu testen. Falls Du ein 
Oszilloskop hast, würde ich, mir das Signal nach dem Optokoppler 
anschauen.
So erkennst Du auch, ob und was für ein Prellen evtl. vorkommt und ob 
Deine  Entprellung durch einfaches Warten, tatsächlich hinreicht. (Im 
allgemeinen ist das eher nicht der Fall).

Sinnvoll scheint mir das deswegen, weil Du eine vergleichsweise komplexe 
Kette von Funktionen (Hardware und Software) im Moment von einem Ende 
(Klingeltaster) zu anderen Ende (Netzwerk-Paket) testest und darin, eben 
weil soviel in dieser Kette steckt, auch viel schief gehen kann.
Du erwähnst auch immer wieder, dass die Netzwerkfunktionen wohl gegeben 
sind, was mir den Eindruck vermittelt, dass Du trotz Deiner Worte 
darüber einen Zweifel nicht ganz ausschliessen kannst. Könnte ich auch 
nicht.
In solchen Fällen geht "man" so vor, dass man zunächst die 
Einzelfunktionen testet, bzw. die Kette schrittweise verlängert bzw. 
vervollständigt.
Dann, im nächsten Schritt, nur eine LED aufleuchten lassen, wenn die 
Betätigung erkannt wurde.

[Silva (Gast)]

Hi Theor,

danke für deine Antwort. Ja das wird vermutlich das sinnvollste sein. 
Ich hatte das natürlich vor dem Einbau auch getestet, aber wohl nicht 
ausführlich genug. Ich werde mal versuchen ein Oszi auszuleihen und mir 
das Signal anzusehen, das kann aber ein paar Tage dauern.

Ich hatte hauptsächlich auch geschrieben, damit jemand mal den Code 
+berfliegt, manchmal ist es ja so, dass man einen Fehler selbst einfach 
nicht  sieht und jemand anderem fällt das dann sofort auf.

Vielen Dank!

[Johannes S. (Gast)]

Silva schrieb:
> Danke für deine Hilfe!

keine Ursache, ich bastel auch an Funkkomponenten fürs Haus und die Idee 
ist gut. Ich benutze nur RFM Module und wollte versuchen den Klingelpuls 
als Stromversorgung zu nutzen ohne zusätzliches Netzteil.

Vor dem Einbau teste ich sowas auch erst länger, wie auch von Theor 
vorgeschlagen.

Bei dem Analogkram nutze ich auch gerne LTSpice, da kann man das schnell 
mal virtuell zusammenlöten. In diesem Fall hängt es natürlich vom 
Optokoppler und dem R ab, aber 10-22 µ / 50 V sollten reichen.

[Johannes S. (Gast)]

ohne Elko ist klar das 100 Ints/s ankommen, da ist das Tasterprellen 
nicht das Problem. Und ob der ESP solche Interruptraten mag weiss ich 
nicht, im Hintergrund will der ja sein WLAN bedienen.

[Anal Phabet (Gast)]

Johannes S. schrieb:
> SimuGLohneElko.png

Gemnial diese LTSpice Plots bei denen die Knoten einfach
durchnumeriert sind. Da weiss man gleich wo man suchen muss.

[Silva (Gast)]

Danke für die ganzen Tipps, ich werde mir das heute abend nochmal
 genauer ansehen und berichte dann!

[Johannes S. (Gast)]

Anal Phabet schrieb:
> Gemnial diese LTSpice Plots bei denen die Knoten einfach
> durchnumeriert sind. Da weiss man gleich wo man suchen muss.

Sorry, war jetzt nur quick + dirty zusammengeklickt, natürlich kann man 
den Netzen Namen geben und auch Labels setzen. Hier ist so einfach das 
man hoffentlich sieht was gemeint ist, die Ausgangsspannung und im 
anderen Beispiel ist noch der Strom durch den 1k R.

[Michael U. (amiga)]

Hallo,

ist das eine Mischung für die ArduinoIDE?
Dein Handling verstehe nur teilweise. initWifi() vernisse ich, welchen 
MQTT-Client Du benutzt weiß ich im Moment auch nicht.
Ich habe da bei mir mal ziemlich lange einen ähnlichen Effekt gesucht, 
WiFi war connected und MQTT nicht. Da ich generell bei MQTT lastWill 
benutze, fiel es mir nur daran auf, daß mir der Broker die 
Offline-Message schickte obwohö FEHM bei Ping-keepalive alles ok 
meldete.

Allerdings müßte ich dazu Dein Konzept verstehen. Was macht der ESP 
sonst noch alles außer Klingel abfragen?

Gruß aus Berlin
Michael

[Silva (Gast)]

Hallo Michael,

ich habe nicht den kompletten Code gepastet, sondern nur die 
(hoffentlich) relevanten Stellen, insbesondere das Interrupt Handling.

Um die Fragen zu beantworten:

- Der ESP triggert eine MQTT Meldung, wenn jemand die Türklingel 
betätigt

- Der ESP schickt regelmäßig eine MQTT Meldung (Hello), diese wird alle 
60
Sekunden versendet und kommt auch immer an

Das initWifi() / connectWifi() sieht so aus:

/* Initialize WIFI */
void ICACHE_FLASH_ATTR initWifi() {
  /* Set station mode */
  WiFi.mode(WIFI_STA);
  WiFi.disconnect();

  #ifdef USE_STATIC
  IPAddress ip;
  IPAddress gateway;
  IPAddress subnet;
  IPAddress dns;

  ip.fromString(_WIFI_IP);
  gateway.fromString(_WIFI_GATEWAY);
  subnet.fromString(_WIFI_SUBNET);
  dns.fromString(_WIFI_DNS);
 
  WiFi.config(ip, gateway, subnet, dns);
  WiFi.hostname(_WIFI_HOSTNAME);
  wifi_station_set_hostname(_WIFI_HOSTNAME);
  #endif
}

/* Connect to WIFI */
bool ICACHE_FLASH_ATTR connectWifi() {
  WiFi.begin(_WIFI_SSID, _WIFI_PASS);
  
  uint8_t i = 0;
  uint8_t status = WiFi.status();
  while(status != WL_CONNECTED && i++ < MAX_WIFI_ATTEMPTS-1) {
    _print_args("-> Error: WIFI status: %d (%s)\n", status, mapWifiStatus(status).c_str());
    
    status = WiFi.status();
    delay(1000);
  }

  return i != MAX_WIFI_ATTEMPTS;
}

Die sendDoorBellState Funktion erstellt nur einen JSON buffer und ruft 
dann sendMQTT(JsonObject &json) auf, diese Funktion ändert den Buffer 
nochmals (fügt einige Daten wie DEVICE_NAME, VERSION, Free Heap Space 
hinzu).
Dannn wird geprüft, ob bereits eine WLAN und MQTT Verbindung besteht 
(falls nicht, werden diese erneut aufgebaut) und dann wird das MQTT 
publish durchgeführt.

Als MQTT Lib verwende ich https://travis-ci.org/256dpi/arduino-mqtt

Tatsächlich hatte ich auch erst in Verdacht, dass die MQTT Pakete nicht 
ankommen, davor hatte ich die ArduinoMQTT Lib verwendet (und dort btw 
auch die MQTT Packet Size entsprechend erhöht).

Danke!

[Rainer W. (rainer_w)]

Silva:

>Ich verwende vier Dioden und
>einen Lastwiderstand um die Wechselspannung (12V) gleichzurichten,
>danach geht das auf einen Optokoppler (PC817), der widerrum an dem Wemos
>D1 Mini hängt.

Irgendwo könnte man noch eine Anzeige LED machen die bei Tasterdruck 
leuchtet. Das ist Überschaubarer.

>Tatsächlich hatte ich auch erst in Verdacht, dass die MQTT Pakete nicht
>ankommen

Diesen Verdacht könnte man öfter haben. Eine Haustürklingel kann auch 
mal lange nicht benutzt werden.
Deshalb würde ich regelmäßig Pakete senden und zum Beispiel zählen (ggf. 
mit Zeit vergleichen) Hier dann eventuell auch eine LED.

[Tierfreund (Gast)]

Rainer W. schrieb:
> Eine Haustürklingel kann auch
> mal lange nicht benutzt werden.
> Deshalb würde ich regelmäßig Pakete senden...

Man könnte aber auch die Stereoanlage volle Pulle sporadisch von der 
Steuerung einschalten lassen, etwa des Nachts zwischen 1 und 5 Uhr. Dann 
kommt der Nachbar und drückt den Klingelknopf mit Sicherheit und auch 
fest genug.

[Rainer W. (rainer_w)]

Tierfreund:
>Rainer W. schrieb:
> Eine Haustürklingel kann auch
> mal lange nicht benutzt werden.
> Deshalb würde ich regelmäßig Pakete senden...

>Man könnte aber auch die Stereoanlage volle Pulle sporadisch von der
>Steuerung einschalten lassen, etwa des Nachts zwischen 1 und 5 Uhr. Dann
>kommt der Nachbar und drückt den Klingelknopf mit Sicherheit und auch
>fest genug.

Übertagungs oder Verbindungsprobleme können immer mal auftreten.
Besser wenn man sich darauf einstellen kann.

Ich schreibe von einer Bereitschaftsanzeige mit Verbindungsprüfung. Ohne 
Geräusche. Wie oft am Tag (oder alle wie viel Tage) das sein soll weiß 
ich nicht.

>Nachts zwischen 1 und 5 Uhr

Je nach dem was einfacher ist.

[Rainer W. (rainer_w)]

Vor meinem Beitrag hatte ich übersehen das sie Verbindungsprüfung
 bereits größten teils existiert.

>/* Setup timers */
>t.every(60*1000, sendMQTTHello);
.....
>- Der ESP schickt regelmäßig eine MQTT Meldung (Hello), diese wird alle
>60
>Sekunden versendet und kommt auch immer an


Das hatte ich überlesen. sorry.

Klingeltrafo Gleichrichter sind  schon da.
Erweitert man diese Platine um einen Eingang und  einen Ausgang 
+Transistor+Relais
hat man seine Schaltung komplett in der Meldekette der 
Verbindungsprüfung. Und es ergeben sich Vorteile wie die 
Nachrüstmöglichkeit einer Anwesenheitsanzeige.

Den zweiten Interrupt Eingang kann man dann zusätzlich über einen 
normalen Eingang  abfragen (wenn es Interrupt sein soll).

[Johannes S. (Gast)]

eine andere Frage ist ob das Klingeln überhaupt per Interrupt gemeldet 
werden muss, Polling mit zB. 20 ms sollte auch locker reichen 
(Kondensator hinter dem GL vorausgesetzt).
Oder den WakeUp Pin nutzen und den ESP ständig schlafen lassen, dann 
läuft der auch mit Batterien lange.

[Michael U. (amiga)]

Hallo,

mir ist der Aufwand z.B. beim WiFi-Connect etwas unklar.
Die Frage, warum Interrupt würde ich auch stellen. Der ESP läuft ja 
ohnehin durch, da kann man auch den Pin einfach im Loop abfragen.
Ob man eine feste IP nutzen will oder DHCP weiß man bei solche einem 
Projekt ja auch und macht das Setup eben entsprechend.

Ich nutze bei Sachen, die im Deepsleep mit Akku laufen den PubSubClient, 
ansonsten AsyncMQTT. Allerdings schicke ich per MQTT auch keine Romane. 
;)

Zurück zum Grund meiner Frage. Wenn WiFi einen reconnect macht, das 
macht der ESP ohnehin alleine wenn man es ihm nicht verbietet, meldet 
WiFi.status(); WL_CONNECTED wenn die Verbindung steht.
Bei DHCP kann es aber passieren, daß er zu diesem Zeitpunkt noch keine 
gültige IP hat. Wenn jetzt sofort ein MQTT connect folgt läuft der gegen 
die Wand...

Ich schicke beim WLAN und MQTT connect als erstes MODULNAME/Status 
online und MODULNAME/RSSI Rssi-Wert. Außerdem wird generell lastWill 
gesetzt auf MODULNAME/Status offline, keepAlive vom MQTT ist meist auf 5 
Minuten gesetzt.

Für die Bearbeitung der Topics ist ohnehin bei mir FHEM zuständig, da 
kann der lastWill notfalls einen Hinweis auf den Ausfall anzeigen. 
Außerdem läuft für alle ESP in FHEM ein ping-Timer, der alle Minute die 
Clients anpingt und bei Bedarf Alarm schlägt, wenn keine Antwort kommt.

Gruß aus Berlin
Michael