Hallo,
ich habe einen ESP8266 (WeMos D1 Mini) Dieser funktioniert ganz gut und
verbindet sich sauber mit meinem WLAN... Ich programmiere in der Arduino
IDE 1.8.3
Das ganze sieht etwa so aus:
1
WiFi.begin(ssid,password);
2
3
while(WiFi.status()!=WL_CONNECTED){
4
delay(500);
5
Serial.print(".");
6
}
7
8
Serial.println("");
9
Serial.println("WiFi connected");
10
Serial.println("IP address: ");
11
Serial.println(WiFi.localIP());
Manchmal bekommt er aber nicht die IP vom DHCP wie erwartet:
192.168.178.80 sondern die 192.168.4.2
das ganze habe ich mit mehreren ESP Feststellen können.
Der Router (eine FritBox 7490 ca. 1Jahr alt) macht ansonsten im Netzwerk
keinerlei Probleme [und es werden Täglich mehr als 20 Geräte über WLAN &
LAN genutzt].
hat jemand eine Idee an was das liegen könnte? Evtl. soetwas schon mal
gehabt? <- wie gesagt... manchmal bekommt er die richtige IP
ich habe bereits ein weiteres Verfahren verwendet:
> WiFiMulti.addAP(ssid, password);
was exakt die selben Probleme verursacht...
Vielen Dank für jeden Tipp
baer schrieb:> 192.168.178.80 sondern die 192.168.4.2
Es gibt zwei Möglichkeiten:
1.) du hast einen zweiten DHCP im Netz (z.B. von einer NAS oder einem
zweiten WLAN-Router)
2.) in deinem Code steckt im falle dass keine IP vom DHCP kommt diese
Adresse drinn!
das mit dem DNS habe ich überprüft und die Geräte welche soetwas KÖNNTEN
ausgeschaltet!
Eine IP habe ich nicht vergeben... <- da auch nach mehreren neustarts
dann eben doch die richtige genommen wird (scheinbar willkürlich).
Das mit dem DNS war auch meine erste vermutung <- aber wenn es nicht die
Fritzbox macht, wüsste ich nicht "woher" ... außerdem hat sich noch kein
Smartphone, Notebook oder PC falsch eingewählt :/
Mit welchen Informationen könnte ich euch helfen mir zu helfen? Oder was
kann ich selbst testen?
baer schrieb:> Mit welchen Informationen könnte ich euch helfen mir zu helfen? Oder was> kann ich selbst testen?
Keine oder falsche MAC im DHCP Server für den ESP eingetragen.
192.168.4.x ist doch der IP Bereich des ESPs wenn man ihn im AP Modus
betreibt. 192.168.4.2 wäre demnach eine typische IP Addresse für einen
Client in einem standard "ESP-Netzwerk".
Eventuell verbindet sich dein ESP einfach je nach Signalstärke mit einem
anderern ESP der sich im AP Modus befindet.
baer schrieb:> Manchmal bekommt er aber nicht die IP vom DHCP wie erwartet:> 192.168.178.80 sondern die 192.168.4.2> hat jemand eine Idee an was das liegen könnte? Evtl. soetwas schon mal> gehabt? <- wie gesagt... manchmal bekommt er die richtige IP
Warum glaubst du, die eine IP-Adresse wäre "richtig" und die andere
nicht? Ein DHCP-Server gibt einem anfragenden Gerät erstmal nur
irgendeine IP-Adresse. Das muß keineswegs immer die gleiche sein. Genau
genommen ist es nur dann immer die gleiche, wenn man das im DHCP-Server
irgendwo konfiguriert. Letzteres ist bei Fritz-OS allerdings
vergleichsweise einfach.
Eventuell verbindet sich dein ESP einfach je nach Signalstärke mit einem
anderern ESP der sich im AP Modus befindet.
Das wird es sein. die ESPs sind standardmäßig Client und AP!
versuch mal
WiFi.mode(WIFI_STA)
im Arduino skech, damit ist ap deaktiviert.
Vorweg: Meine Erfahrung mit dem ESP8266 entstammt nicht der
Aduino-Variante. Ich hatte allerdings ein ähnliches Problem mit NodeMCU.
Die Lib des Herstellers verwendet ein RTOS um die Aktivitäten des
Programmierers und Hintergrund-Aktivitäten der Library zu koordinieren.
Dieses RTOS arbeitet nicht unterbrechend, sondern kooperativ. Wenn man
dem per Programm die Luft abschnürt, denn säuft der WLAN-Code der
Library ab, verpasst Ereignisse, und dessen Funktion wird Glücksache.
Wenn ein Programm also längere Zeit am Stück arbeitet, ohne dem RTOS
Raum zu geben, dann kann das zu Problemen führen. Das wäre der Fall,
wenn delay(500) blockierend arbeitet.
Bei NodeMCU bedeutet es, dass man nicht so sehr linear programmieren
sollte, also ein längere Zeit dauerndes Programm runterzuarbeiten,
sondern eventorientiert. Also nicht aktiv warten, bis etwas passiert,
sondern anlässlich der passenden Events die Aktion durchführen.
> WiFi.mode(WIFI_STA)
leider half auch das nicht...
(ebenso habe ich auch WIFI_AP und WIFI_AP_STA auch ohne erfolg getestet)
das mit der "esp eigenen" IP klingt gut. Aber ich weiß noch nicht wonach
ich suchen muss um dies zu verhindern...
Ich will halt das Teil an den verschiedensten Routern anschließen...
d.h. ich kann keine IP vordefinieren (welche dann im lokalen Netzwerk
auch IMMER erreichbar ist).
Fortsetzung:
Ich hatte das anfangs sehr ähnlich gemacht, nur eben in LUA. WLAN
starten und per Schleife und 1s Verzögerung abzuwarten, ob es kommt. Mal
tat es, mal nicht. Egal welche Konfiguration.
Was dann hingegen stabil funktionierte war ein Timer, der jede Sekunde
ein Stück Code startet und darin nachsieht, ob das WLAN da ist, und
darin dann die IP anzeigt.
baer schrieb:>> WiFi.mode(WIFI_STA)> leider half auch das nicht...
Das muss auch auf dem anderen ESP passieren, der irgendwo in der Nähe
als AP fungiert.
Normalerweise ist es aber so, dass ein ESP8266 sich den letzten Connect
merkt und diesen AP dann auch immer wieder kontaktiert.
Ich empfehle Dir, nach dem folgenden Schema vorzugehen:
1
WiFi.mode(WIFI_STA);
2
WiFi.disconnect();
3
delay(100);
4
WiFi.begin(ssid,key);
5
6
for(cnt=0;cnt<30;cnt++)// check 15 seconds if connected
7
{
8
if(WiFi.status()==WL_CONNECTED)
9
{
10
connected=true;
11
break;
12
}
13
14
delay(500);
15
}
Das heißt: mache vor dem Wifi.begin einen expliziten Disconnect. Dann
kann Dir kein anderer AP, zu dem Dein ESP irgendwann mal eine Verbindung
hatte, dazwischenfunken.
@A.K.
klingt Interessant... allerdings fällt mir gerade keine Möglichkeit ein,
das ohne Delay zu bewerkstelligen...
ich habe mal den Code etwas angepasst:
1
Serial.print("Connect to:");
2
Serial.println(ssid);
3
4
WiFi.mode(WIFI_STA);
5
WiFi.disconnect();
6
delay(1000);
7
8
WiFi.begin(ssid,pass);
9
inttimeout=20000;// => 20 Sekunden
10
boolwait=true;
11
longconnectStart=millis();
12
longconnTest=millis();
13
14
while(wait){
15
16
if(millis()>connTest+1000){
17
connTest=millis();
18
wait=WiFi.status()!=WL_CONNECTED;
19
Serial.print(".");
20
}
21
22
if(millis()>connectStart+timeout){
23
wait=false;
24
Serial.println("timeout");
25
}
26
27
delay(100);
28
29
}
auch hier verbindet er sich wieder SAUBER meistens mit der 192.168.4.2
wenn ich den delay zu kurz mache oder entferne, hängt er sich auf ...
@A. K.
Das was du beschrieben hast, ist weder eine Eigenart von Arduino noch
von der LUA Firmware sondern sie ergibt sich aus den SDK von Espressif
und der lwip Stack, auf den das Ganze aufbaut.
Nur so als Info.
Okay...
dumm von mir...
ich habe den Fehler gefunden!
=> in der Tat war von mir ein anderer ESP welcher den mode AP_STA hatte.
habe diesen auf STA umprogrammiert und jetzt scheint es zu passen :)
crazy
10001 dank für eure Hilfe... den Fehler hätte ich ohne euch NIEMALS
gefunden <- und gleichzeitig ne menge gelernt!
Ich möchte noch etwas ergänzen:
Bei der ESP Erweiterung für Arduino wurde delay() so umgeschrieben, daß
es wiederholt yield() aufruft, bis die gewünschte Zeit erreicht oder
überschritten wurde. Yield() wiederum übergibt die Kontrolle an die
Firmware von Espressif, die dann solange irgendwas macht, wie sie gerne
möchte. Deswegen kann delay() in Ausnahmefällen erheblich länger dauern,
als gewollt.
Wer PC's unter Linux oder Windows programmiert, kennt das, dort ist es
nämlich ebenso.
evtl. noch ein anderes Problem angehangen, weil hier so viele Könner
sind :)
nachdem ich nun endlich meine Verbindung habe, möchte ich auch, dass
MDNS funktioniert.
Das hat es auch schon mal, aber irgendwie geht es jetzt nicht mehr...
Auf was muss ich achten?
nachdem ich verbunden bin, starte ich den Responder:
if( MDNS.begin("mydnsname", WiFi.localIP()) )
Serial.println("MDNS responder started");
hier starte ich meinen tcp-server <- welcher auch gut über die IP
erreichbar ist.
Zuletzt füge ich noch den Service hinzu
MDNS.addService("http", "tcp", 80);
Hat hierfür noch jemand einen Tipp?
baer schrieb:> Ich will halt das Teil an den verschiedensten Routern anschließen...> d.h. ich kann keine IP vordefinieren (welche dann im lokalen Netzwerk> auch IMMER erreichbar ist).
Dann verstehe ich deine Frage schon gar nicht. Jeder Router kann
(vermutlich: wird) ein anderes Netzwerk konfiguriert haben oder doch
zumindest einen anderen Bereich an per DHCP vergebbaren IP-Adressen.
Unter diesen Voraussetzungen ist alles, worauf du hoffen kannst, daß der
Router dir überhaupt eine Adresse zuweist. Wenn der ESP dann von Dritten
erreichbar sein soll, muß er sich (seine IP-Adresse) irgendwo
registrieren. Prinzip DynDNS.
Was du übrigens noch gar nicht gesagt hast: ist der ESP denn in beiden
Fällen mit der Fritzbox verbunden? Taucht er da in der WLAN-Übersicht
auf? Denn das wäre das erste, was man checken müßte. Wenn der ESP nicht
mit dem richtigen AP spricht, dann kann er natürlich auch nicht den
richtigen DHCP erreichen.
Stefan U. schrieb:> Wer PC's unter Linux oder Windows programmiert, kennt das, dort ist es> nämlich ebenso.
Nur arbeiten Linux und Windows unterbrechend. Weshalb du aktiv
Schleifchen drehen kannst so lange du willst, ohne jedes yield, und
trotzdem andere Tasks drankommen. Aus dem gleichen Grund kann auch der
Scheduler präziser arbeiten, was Zeiten angeht. Im RTOS von Esperessif
hingegen hängt die Genauigkeit davon ab, wie häufig oder selten andere
Task yielden.
Beim ESP32 hat Espressif das Verhalten des FreeRTOS geändert, dessen SDK
arbeitet nun unterbrechend.
nur die Frage vergessen :D :D
ich erreich den esp zwar sauber über die ip, aber weder über
http://mydnsname/ noch über http://mydnsname.local/
<- ersteres hatte ich schon mal in funktionstüchtig
@Stefan Us (stefanus)
naja, das ging sowohl unter Android, alsauch Windows 10 ... leider nur
mal kurz <- dann hatte ich das obengenannte IP-Problem, anschließend hat
es nicht mehr funktioniert!
@Hax (Gast)
nun, ich wollte nichts installieren, weil es ja nicht bei mir (als
Entwickler) gehen soll, sondern überall.
> das Original habe ich getestet :/
aber gut, ich schaue weiter!
Falls jemand noch ne andere Idee...
> sondern einfach IP Adressen verwenden
einfach ist eben so eine sache... da diese vom DHCP zugewiesen wird,
kenn ich die nicht. Und ich kann nicht von jeden DAU erwarten, beim DHCP
zu erfragen, WIE die IP lautet :/
> da diese vom DHCP zugewiesen wird, kenne ich die nicht.
Du kannst den DHCP Server aber zumindest anweisen, in Zukunft immer die
selbe Adresse zuzuweisen. Und dann schreibt man sie einmal auf und gibt
sie allen bekannt.
> da diese vom DHCP zugewiesen wird, kenne ich die nicht.
Du kannst den DHCP Server aber zumindest anweisen, in Zukunft immer die
selbe Adresse zuzuweisen. Und dann schreibt man sie einmal auf und gibt
sie allen bekannt.
> Windows muss das nicht können... Android reicht mir :)
Android unterstützt mDNS nicht. Aber es gibt mehrere Libraries, die du
in deine eigenen Apps einbinden kannst.
@Stefan Us (stefanus)
falsch verstanden... dann kenn ICH die IP ja!
Wenn ich aber das Tool an Kunden herausgebe und ein Kunde hat nen
Speedport mit 1 PC und das ESP bekommt die IP 192.168.0.12
und ein anderer hat ne Fritzbox mit vielen PC bekommt die IP
192.168.178.71
... <- kurzum, je nach Netzwerk gibt es hier nahezu unendlich
Möglichkeiten
Zwar soll die App auch eine suche bekommen, aber deutlich Komfortabler
wäre natürlich nicht den kompletten Adressraum durchsuchen zu müssen :)
Stefan U. schrieb:> Du kannst den DHCP Server aber zumindest anweisen, in Zukunft immer die> selbe Adresse zuzuweisen. Und dann schreibt man sie einmal auf und gibt> sie allen bekannt.
Und sind damit auch im DNS unter dem im Router pflegbaren Namen bekannt.
Laut Wikipedia kann Windows 10 mDNS nur für Drucker:
"mDNS has also been implemented in Windows 10, but its use is limited to
discovering networked printers."
https://en.m.wikipedia.org/wiki/Multicast_DNS
baer schrieb:> Wenn ich aber das Tool an Kunden herausgebe und ein Kunde hat nen> Speedport mit 1 PC und das ESP bekommt die IP 192.168.0.12
Hast du schon eine Lösung dafür, das jedes WLAN sein eigenes
SSID/Passwort hat?
Ansonsten gibt es in der Fritzbox eine Einstellmöglichkeit, damit
WLAN-Geräte untereinander nicht kommunizieren dürfen. (Client isolation
oder so ähnlich) Ist das vielleicht aktiv?
Außerdem kannst du, wenn die lokale Suche erfolglos ist, immer noch über
Bande spielen. Also ein Server im Internet auf dem sich Tool und App
anmelden und kommunizieren können.
@yesitsme (Gast):
also wegen der unterschiedlichen SSID habe ich eine Lösung.
das ESP versucht sich mit dem WLAN zu verbinden, wird nach n Sekunden
kein WLAN gefunden, baut er sich selbst als offener AP auf... dort kann
man dann SSID und Passwort eingeben...
Ich habe jetzt in der Android-App spaßeshalber mal einen kompletten
Netzwerkscan gemacht, d.h. ich hol mit die Netzmaske und die IP, finde
den SUB-Netzwerkadressenraum raus und Prüfe ALLE möglichen IPs...
=> das Interessante dabei ist, dass ich das nahezu "GLEICHZEITIG" für
alle IPs (getestet mit bis zu 1000 IPs) machen kann und ein
"normaldurchschnittliches" Android 7 Smartphone nicht ins schwitzen
kommt (ebenso ist das Netzwerk an sich relativ entspannt geblieben).
Nach Spätestens 20 Sekunden habe die gesuchten IPs :)
daher alle Probleme gelöst <- sch*** auf DNS
> das ESP versucht sich mit dem WLAN zu verbinden, wird nach n Sekunden> kein WLAN gefunden, baut er sich selbst als offener AP auf... dort kann> man dann SSID und Passwort eingeben...
Mach Dir Gedanken, wie sich dieses Konstrukt nach einem Stromausfall
verhält.
Ich habe hier einen alternativen Ansatz der Dir eventuell auch gefällt:
http://stefanfrings.de/esp8266/index.html#wificonfigservice> Nach Spätestens 20 Sekunden habe die gesuchten IPs
Sicher, ist kein Wunder. Wie gesagt kenne ich das von Druckertreibern.
> Mach Dir Gedanken
^^ das habe ich doch
wie sich dieses Konstrukt nach einem Stromausfall
verhält
sowas wird es nicht geben (Stichwort USV), und falls doch gibt es andere
Probleme!
> ne, der Ansatz gefällt mir nicht... da ist meine Lösung deutlich komfortabler :)
und keine Angst, der Sicherheitsaspekt ist bei meinem Tool auch gedeckt... <- denn
auf die Steuerungsfunktionen darf NUR meine Software zugreifen. Den WLAN Zugang
könnte mit etwas Geschick jeder ändern <- juckt mich aber nicht!
baer schrieb:> sowas wird es nicht geben (Stichwort USV), und falls doch gibt es andere> Probleme!
lol, es wir gar nie nicht kein Stromausfall geben ;-)
Thread beobachten
Seitenaufteilung abschalten