NodeMCU UDP Paket senden + deepsleep

[HaWe]

fangen wir doch mal ganz elementar an:
welche Versionen hast du?
Arduino IDE (1.8.6 ?)
welches nodeMCU board (nodeMCU 1.0 = ESP-12E?)
welche esp8288 board core Version (2.4.0 oder 2.4.2 ?) ( <<< 2.4.2 funktioniert bei mir nicht, nur 2.4.0)
hast du die neuesten libs für #include <ESP8266WiFi.h> und #include <WiFiUdp.h> ? https://github.com/esp8266/Arduino/t...SP8266WiFi/src

kannst du auch dieses (umgekehrte) Besipiel aus 6/2018 probieren : https://github.com/esp8266/Arduino/b...p-examples.rst ?

falls wir hier nicht weiter kommen:
poste mal deinen issue hier bei den Fachleuten/Entwicklern: https://github.com/esp8266/Arduino/issues

[d2x]

Arduino IDE 1.8.3
nodeMCU Board ist das ESP-12E
ESP8266 Board Core Version : Wo kann ich die Versionsnummer checken?
Die lib ESP8266WiFi von Ivan Grokhotkov ist Ver 1.0 und beinhaltet scheinbar auch die WiFiUdp.h . Über die Biblithekenverwaltung nicht updatebar.

Ich habe das Beispiel 1:1 probiert und bekomme immer zuverlässig eine Antwort !!!

Ich fürchte wir kommen weiter

Was ist jetzt der Unterschied? Im Großen und Ganzen würde ich sagen, arbeitet das Beispielscetch mit remoteIP() und remotePort() ... ich hatte in meinem Code auch eine direkte IP (allerdings vom Router) getestet, habe aber auch das Problem gehabt. Ich versuche mal die IP vom Laptop. Bisher dachte ich eigentlich immer das sei egal.... ich probiere es mal.

EDIT:

Fehler gefunden!
Es muss scheinbar die richtige Adresse der Gegenstelle, in meinem Fall die des Laptops, angegeben werden. Es kommt dann jedes Paket an. Kann mir jemand erklären wieso ich die Pakete nicht zuverlässig / vollständig sehen kann wenn diese an Broadcast oder an eine andere IP adressiert sind ? Was macht "Broadcast" denn dann für ein Sinn, wenn es nicht ankommt?

EDIT2:

Mein Code aus dem 1.Beitrag läuft damit allerdings immer noch nicht zuverlässig.....
Es scheint am deepSleep zu liegen. Ohne geht es und mit kommt wieder nur ab und zu ein Paket an.

[Moppi]

Mit dem Deep Sleep ist das so eine Sache. Es gibt verschiedene Schlaf-Modi, auch das Netztwerkmodul vom nodeMCU kann abgeschaltet werden. Er benötigt Zeit um alles wieder in Betrieb zu nehmen und die Verbindung muss wieder hergestellt werden. Vielleicht bist Du an irgendeiner Stelle einfach zu schnell. Musst überall zum Probieren mal längere Pausen einbauen und gucken, ob es dann funktioniert. Dann rausfummeln, wo er mehr Zeit benötigt, als Du dachtest.

Deine Daten waren:

IPAddress IPudp (255, 255, 255, 255);
IPAddress IPlocal (192, 168, 10, 201);
IPAddress IPdns (192, 168, 10, 1);
IPAddress IPgateway (192, 168, 10, 1);
IPAddress IPsubnetmask (255, 255, 255, 0);

Dein Netz ist 192.168.10. Dein Paket sollte per Broadcast an 192.168.10.255 gesendet werden, damit es innerhalb DEINES Netzes an jeden Teilnehmer verteilt wird. Ich glaube, Du bringst den Router ganz schön durcheinander.

MfG

[d2x]

Guten Morgen Moppi,

das war tatsächlich anfangs so. Ich habe mir das auch für die Fehlerbehebung irgendwo abgeguckt.

Ich habe jetzt noch mal getestet:

-ohne deepSleep an 192.168.10.255 -> Pakete kommen nur sporadisch an
-ohne deepSleep an 192.168.10.68 -> Pakete kommen alle an.

-mit deepSleep muss noch etwas anderes faul sein. Was, muss ich noch herausfinden....
Die Resetleitung ist aber angeschlossen, so viel kann ich schon mal sagen

[Moppi]

Guten Morgen auch!

Wenn die Pakete an eine bestimmte Adresse alle ankommen, werden sie auch alle vom nodeMCU verschickt. Egal, ob sie nach .68 oder nach .255 verschickt werden, sie werden immer alle verschickt. Das nodeMCU ist nicht für die Verteilung zuständig.

Die Resetleitung ist aber angeschlossen, so viel kann ich schon mal sagen

Vielleicht stehst Du auf selbiger

Gibt es beim Router oder was Du verwendest Einstellungen zu Broadcast-Nachrichten oder etwas, das was mit Broadcast zu tun hat? Zeitliche Limits oder irgend etwas?

Normalerweise hat man in einem Netzwerk ja mehrere Teilnehmer. Was passiert, wenn Du nur noch einen Empfänger für die UDP-Pakete hast? Kommen dann alle Pakete dort an?

MfG

[HaWe]

ESP8266 Board Core Version : Wo kann ich die Versionsnummer checken?
Die lib ESP8266WiFi von Ivan Grokhotkov ist Ver 1.0 und beinhaltet scheinbar auch die WiFiUdp.h . Über die Biblithekenverwaltung nicht updatebar.

nur zur Info, da das Problem ja offenbar jetzt woanders lokalisiert wurde:
- die board core Version kannst du über den Boardverwalter sehen, einstellen und installieren: ESP8266 eingeben, unter "Info" stehen dann verschiedenen cores zur Auswahl.
- du kannst auch direkt von der github Seite die aktuellen libs einzeln downloaden und ins libraries Verzeihnis kopieren; gerade weil ESP8266 nicht von den Arduino.cc Leuten stammt, werden im library manager nicht immer die aktuellsten libs in der IDE bereitgestellt.

Und damit klinke ich mich gleich wieder aus...

[d2x]

Vielleicht stehst Du auf selbiger

Ich hoffe dem ist nicht so

Gibt es beim Router oder was Du verwendest Einstellungen zu Broadcast-Nachrichten oder etwas, das was mit Broadcast zu tun hat? Zeitliche Limits oder irgend etwas?

Normalerweise hat man in einem Netzwerk ja mehrere Teilnehmer. Was passiert, wenn Du nur noch einen Empfänger für die UDP-Pakete hast? Kommen dann alle Pakete dort an?

Es kommen ca. 90% der Pakete an Broadcast an wenn ich Laptop und NodeMCU über einen Android-Hotspot laufen lasse.
Scheinbar frisst meine Hardware die Pakete :

Der Accesspoint läuft mit einem Open-WRT, der Router ist eine Fritzbox. Ich habe gerade mal durchgesehen und nichts mit Braodcast gefunden.. Die Firewall ist im Open-WRT-AP ausgeschaltet.

@HaWe: vielen Dank
Boardversion ist die 2.4.0

[Moppi]

Du kannst natürlich mit dem nodeMCU die Pakete auch an jeden Rechner einzeln schicken. Wenn das besser funktioniert. Oder Du schickst jedes Paket 3mal, damit es min. einmal ankommt, bis das Problem gefunden ist.

MfG

[HaWe]

Du kannst natürlich mit dem nodeMCU die Pakete auch an jeden Rechner einzeln schicken. Wenn das besser funktioniert. Oder Du schickst jedes Paket 3mal, damit es min. einmal ankommt, bis das Problem gefunden ist.

MfG

oder solange wiederholt senden, bis alle ein ack zurückgesendet haben

[Klebwax]

Als Empfänger habe ich bereits meinen Laptop eingesetzt und habe dazu netcat (Linux) benutzt: "netcat -ul 5005".

Das ist das Problem. netcat spielt nicht gut mit UDP-Boadcasts. Mit "socat" klappt das besser.

MfG Klebwax