ich will Daten zwischen zwei ESP32 hin und her schicken. Ansatz war ESP-now, was im Prinzip auch funktioniert.
Auf Grund der Räumlichkeiten kommt im WLAN ein Repeater zum Einsatz.
Nach meinem Verständnis sollten die ESP damit überall hinkommen, da sie die ETH-Broadcastadresse verwenden und diese ja überall ankommen sollte?
ESP und WLAN sollten auf dem gleichen Kanal laufen, aber leider funktioniert es nicht.
Ich sehe auch auf dem Adapter vom Laptop keine Brodcasts ankommen, was ja eigentlich auch sein sollte.
Hat irgend jemand schon mal ESP-now im Meshnetzwerk verteilt und kann helfen?
Oder das Problem aufzeigen?
Einen Repeater habe ich nicht, aber an meiner Fritz!Box hängen PowerLAN-Adapter mit WLAN, die dank Mesh so tun, als seien sie die Fritz!Box. Mit Läppi und ESP32 funktioniert das.
Sollte diese Konstellation Deiner Fragestellung entsprechen, könnte ich mit zwei ESP32 durch die Gegend laufen und schauen, was passiert. Dazu bräuchte ich zwei Programme von Dir.
Ich habe zwar schon mal ESP-NOW probiert, aber da war Mesh noch nicht im Einsatz.
wenn es eh einen Repeater gibt - nehm ich an du hast dort ohnehin ein TCP/IP basierendes Netzwerk. Warum brauchst du dann noch ESP-NOW? Bleib bei TCP oder UDP.
Ansonsten wenn Interesse besteht, hab ich auch mal mit ESP-NOW und in einer (selbstgeschriebenen) Mesh Konfiguration experimentiert, wo jeder Node node genutzt wird und Messages relayed - rein ESP-NOW - keinerlei andere WIFI Infrastruktur.
Naja, die Client-Server-Beispiele die ich gefunden habe gehen nicht <-> ...
Ich will konkret in die eine Richtung Messwerte übertragen, in die andere im Falle der Existenz einen Terminalarm mit entsprechendem Text.
Jetzt bin ich völlig irritiert, mir kam noch der Gedanke, dass ESP-now so weit unten angesiedelt ist und deshalb nichts zu sehen ist.
Aber es setzt erst in Schicht 3 ein, unten läuft also ganz normal Ethernet.
Aber auch ein schnell gezogener Sniffer auf ESP-Basis sieht kein Pakete???
Ich stelle in Kürze welche ein, muss erst mal bereinigen.
Ja, wobei mich Termin: etwas irritiert, hier kommen bei mir kryptische Daten, das es mit dem korrektem Text klemmt.
Auf jeden Fall dürfen sich die ESP nicht direkt erreichen, das ist ja mein Problem.
Wenn Du einen guten Sniffer hast ...., ich sehe ums verre.... die Pakete nicht.
Naja, warum muss dann die entsprechende Bibliothek eingebunden werden?
Du verwechselst hier Begriffe.
ESP-now setzt wie das was der Laie unter WLAN/WIFI versteht auf Schicht 2 OSI auf.
Was ich hier durchleiten will sind Broadcast auf dem physical layer wie sie z.B. auch arp von TCP/IP verwendet.
Das hat nichts mit dem Weg über Router oder Gateway zu tun.
Außerdem habe ich daten_ausgeben() in die callback function now_daten_empfangen verschoben, will ja nicht 10 Sekunden warten.
Dir ist Dein Problem glasklar, ich bewundere es, aber was ich anhand der Daten im seriellen Monitor erkennen können soll, habe ich leider noch nicht verstanden.
Naja, die Auswirkungen, das Problem ist mir ein Rätsel.
Rein von meinem Verständnis her sollten die Pakete ankommen.
Oder ich verstehe etwas grundlegend falsch .....
Verstehe ich nicht, was sollte da zu "erkennen" sein?
Es wird lediglich ausgegeben was der "Gegner" sendet, im "Ernstfall" wären das Daten die zu verarbeiten sind.
@Plumps
Daran hatte ich gestern gar nicht gedacht, auch im auf TCP/IP basierenden WLAN kommunizieren die Teilnehmer direkt miteinander.
Lediglich wenn der Andere außerhalb des über MAC-Adressen erreichbaren Bereiches liegt kommt der Router ins Spiel.
ESP-now braucht und nutzt nicht ein anders bereit gestelltes Netzwerk. Du kannst zwei ESP mit Akku irgendwo auf einem Feld miteinander kommunizieren lassen.
Daher ist es völlig irrelevant, ob du einen Repeater für dein WLAN im Einsatz hast. Die Kommunikation findet nicht über dein vom Router/Repeater zur Verfügung gestellten Netz statt.
Die Kommunikation findet nur PeerToPeer statt. Die Teilnehmer müssen sich innerhalb ihrer eigenen Reichweite befinden.
Deine Ausführungen sind zum größten Teil korrekt, Du ziehst aber durch Deine Vermischung von WLAN und WIFI die falschen Schlüsse.
Was Du als "anders bereit gestelltes Netzwerk" bezeichnest ist in den meisten Fällen ein normales Heimnetz basierend auf TCP/IP, einem Protokoll der höheren Schichten.
Dieses wird i.d.R. durch einen AP bereitgestellt.
Dieser AP setzt aber wie Du im Link oben sehen kannst genau wie ESP-now in der Transportschicht auf den physical layer (802.11) auf. Auf dem eigenen Rechner kann man im Gerätemanager sehen was dieser benutzt.
Außerdem legt er einen Kanal fest, in dem das Netzwerk arbeitet, also sendet und empfängt.
Nichts anderes macht ESP-now mit peerInfo.channel = 0;, es legt einen Kanal fest, auf dem mit dem physical layer gearbeitet, also gesendet und empfangen wird.
wird ESP-now auf den zuvor ermittelten Kanal des jeweiligen AP eingestellt, beide arbeiten jetzt auf dem gleichen Kanal und dem gleichen physical layer.
Ein Repeater macht nichts anderes als Pakete des physical layer jeweils auf "die andere Seite" zu schaufeln, im Falle eines MESH-Netzes auf dem Kanal, den der AP vorgibt.
Da aber AP und ESP auf dem selben Kanal arbeiten ....
Die Variable termin_alarm habe ich im Wintergarten mit einer LED visualisiert. Befinden sich beide ESP32 nebeneinander, blinkt diese LED und Daten werden ausgetauscht. Wechsle ich mit dem ESP32 für den Wintergarten in den Keller neben den PowerLAN-Adapter mit Mesh, kommt keine Verbindung zustande.
Entspricht die SSID der des Routers, verwenden die ESPs den vom Router verwendeten Kanal 6. Bei ausgeschaltetem WLAN wird Kanal 1 gewählt, ESP-NOW funktioniert bei kleiner Entfernung dennoch.
Bisher war ich davon ausgegangen, die Teilnehmer von ESP-NOW identifizieren sich über die MAC-Adresse. Das finde ich hier aber bei FF FF FF FF FF FF (in hex) nicht bestätigt. Vermutlich verbirgt sich das in den mir unbekannten Schichten
Das ist der Kern meines Problems, warum auch immer gehen die Daten nicht über einen Repeater.
Das ist der Sinn des Scans und der Änderung des Kanals. Der Repeater wird ja vom AP auf den verwendeten Kanal eingestellt und transportiert entsprechend den physical layer hin und her. Zumindest in der Theorie .
Sollte auch bei größeren, soweit eben die Sendeleistung der ESP reicht.
Dem ist auch so, genau wie bei TCP/IP. Da die MAC-Adresse aber im physical layer (802.11) werkelt und ESP-now darauf aufsetzt funktioniert es auch so. Einzelne ESP werden über die MAC-Adresse angesprochen, d.h. nur der ESP mit der betreffenden MAC erhält die Daten.
0xFF:0xFF:0xFF:0xFF:0xFF.0xFF ist das Pedant zur IP x.x.x.255, damit werden alle Clients im Netz angesprochen und können auf die Daten zugreifen.
Willst Du einen Alarm im Hause über ESP-now auslösen schicke das Paket an die Broadcastadresse und alle ESP klingeln los.
Jepp, da ich jetzt weiß das es nicht meine Mesh-Konfiguration ist.
Muss ich halt sehen ob ich es mit http get und post hinkriege.
auf einem ESP32 sollte das aber ziemlich einfach sein.
am Client gibst du die zu übermittelnden Daten in den body (tag=value&tagB=valueB)
am Server verwendest du server.hasArg() und server.arg() zum Extrahieren der Daten.
Oder du schickst die Daten verpackt in einem JSON, dann muss der Server das JSON parsen können (ArduinoJSON wird bekannt sein).
.