Hallo, ich habe vor, ein smartes Haussystem für mich zu bauen. Dabei soll jedes Gerät einen Mega328 + ESP bekommen. Auf dem ESP läuft dann samt Bootloader meine FW. Das Gerät kann dann an jeden Verbrauche angeschlossen bzw. dazwischengeklemmt werden. Soll auch Sensoren geben etc... 2 Platinen habe ich, eine seit etwas längerer Zeit im Einsatz zwecks FW Test. Das funktioniert nun alles gut, sodass ich die 2. gelötet habe. Nun habe ich ein Problem: Ich habe DHCP abgeschaltet am ESP8266 und ihm eine feste IP zugewiesen. Hat den Vorteil, dass ich am PC/App die IP hinterlegen kann und dann direkt zugreifen kann (da ich nicht herausgefunden habe, ob/wie man DHCP IPs finden kann, da die ESP auch immer als "Unknown" am Router angezeigt werden). Das ohne DHCP ist auch nicht schlimm, bei anderen Geräten seit Jahren ohne Probleme im Einsatz. Jetzt kommt aber das Problem: Nachdem ich das 2. Gerät angeschaltet hatte, konnte ich es wie erwartet steuern. Ich sende dabei an die feste IP einen String mit Kommando's und einem Namen. Das Gerät guckt dann ob sein Name = Empfangsname ansonsten ignoriert er den Befehl. Jetzt das Problem/merkwürdige: Am PC sende ich via TCP/IP über VisualBasic Terminal. Am Handy per APP auf Android via HTTP PUT Nun spielt es eine Rolle, ob ich erst das 1. und dann das 2. anschalte oder anders. Ich kann, sobald beide Geräte an sind (und die gleiche IP haben), per TCP/IP IMMER nur das zuletzt angeschaltete Gerät erreichen. Per APP geht nur das zuerst angeschaltete. HTTP GET geht ebenfalls nur das zuletzt angeschaltete Jetzt mal die total bescheuerte Frage: Was ist das bitte?! Warum geht das so komisch?! Wenn ich das 2. abschalte (oder das 1., also so das nur 1 an ist) geht via TCP, HTTP GET/PUT wieder alles wie gewohnt. Ich habe vor, von diesen Teilen ~ 10 zu verbauen. Zu beobachten ist nun auch, dass sobald 2. Geräte an sind, das eine ja Daten bekommt, das andere aber absolut nichts empfängt. Also die LED vom ESP blinkt nicht mal, es werden so wie es aussieht keine Daten weiter geleitet. Wo liegt das Problem? Geht das mit den gleichen IP's nicht? Sollte man beim ESP lieber DHCP anschalten und trzd. eine feste IP zuweisen oder macht das keinen Unterschied?
Normalerweise kann man in diesen Routern auch Namen vergeben. 1. Du schaltest einen ESP ein 2. Schaust im Router nach welche Zeile dazugekommen ist. 3. Kreuzt an "Dieser MAC immer die selbe IP-Addresse zuweisen" 4. Vergibst im Router einen Namen für diese IP (Der Router verteilt diesen Namen über DNS an alle Rechner.) 5. Du schaltest den nächsten ESP ein. ...
Grundlagen der Netzwerktechnik und so... Schon mal was von mac(nicht angefressene äpfel) und Arp und so gehört?
Marius D. schrieb: > Wo liegt das Problem? Geht das mit den gleichen IP's nicht? Du benutzt TCP/IP, ein Paket orientiertes Protokoll. Siehe: https://de.wikipedia.org/wiki/Transmission_Control_Protocol/Internet_Protocol Deine Erwartungshaltung mal zum Verständnis mal als Beispiel ein Postpaket: Du vergibst an alle deine Postfächer ( deine ESP8266 ) die gleiche Adresse, obwohl sie an unterschiedlichen Orten befinden. ( Was schon mal nicht als saubere Adressierung gelten könnte. Mehrere Personen mit z.B. der gleichen IBAN-Nummer ihres Kontos könnten auch Probleme bekommen ... ) Dann sendest du EIN(!!!) Paket und erwartest, das es GLEICHZEITIG(!!!) an mehrere Empfänger ( deine ESP8266 ) zugestellt wird. Die Empfänger sollen dann in dem Paket nachschauen ob es für sich bestimmt ist. TCP/IP macht das aber nicht mit. TCP/IP ist immer eine Punkt zu Punkt Verbindung. Was du nutzen könntest ist Multicast. Siehe: https://de.wikipedia.org/wiki/Multicast Ob du dafür einen Stack für ESP8266 findest, keine Ahnung.
Auch per Multicast wird es mit der gleichen IP Adresse nicht gehen... Zwei PCs mit der gleichen IP geben wenigstens eine Fehlermeldung aus, das es einen Adresskonflikt gibt - da der ESP das nicht macht, sind wir jetzt hier... ;-) Du brauchst für jedes Netzwerkgerät eine eigene IP oder musst dich auf anderen Ebenen, wie TCP/IP unterhalten... Also das einzig sinnvolle wäre, den DHCPClient von deinen ESPs mal richtig zu machen, das die sich mit einem Namen an deinem Router anmelden... Einige sind da etwas zickig, was das angeht (Fritzboxen hatten früher Probleme mit Linux Geräten - hat sich das inzwischen geändert?)... Und danach kannst du deine ESPs über ihre Namen ansprechen... Aus dem Zeitalter, wo man sich IP Adresse merken muss sind wir doch eigentlich raus - auch zuhause... ;-) Edit: Eine Idee noch, wo dir die IP egal sein kann... UDP Broadcast... Dann macht auch der Empfängernamen in deinem Datenpaket Sinn, du brauchst keine IP Adressen wissen usw... Du musst allerdings im gleichen IP-Bereich wie deine ESPs sein... Also von Unterwegs übers Internet gehts dann nicht mehr... Und auf UDP Pakete kann doch sicher auch der ESP lauschen? (noch nie was damit gemacht)
:
Bearbeitet durch User
Arthur schrieb: > Dann sendest du EIN(!!!) Paket und erwartest, das es GLEICHZEITIG(!!!) > an mehrere Empfänger ( deine ESP8266 ) zugestellt wird. Nein, auch so funktioniert IP nicht. Für die Übertragung hat jedes Device eine eigene Adresse, die MAC-Adresse. Die IP ist wieder nur eine Hilfsadresse. Aus dem Grund erreicht er mal das eine und mal das andere Device, je nachdem welche MAC-Adresse die Adressauflösung welcher IP zugeordnet hat. Da keine IP zwei MAC-Adressen (oder umgekehrt) zugeordnet sein kann, funktioniert die SubAdressierung über den Namen nicht, die Pakete gehen nur an ein Device, das zweite bekommt davon garnichts mit. Ein IP-Broadcast währe eine Möglichkeit das umzusetzten, aber da gibt es dann neue Probleme und sauber ist das auch nicht.
Wie wäre es schlichtweg mit einem Broadcast an alle Geräte im Netz? Deine Clints scheinen ja schon zu filtern, ob sie angesprochen werden. Dann ist die IP egal.
Boradcast hin oder her. Sauber wird es, wenn du deine Clints dazu bringst sich an der APP mit ihrer IP zu registrieren.
2 gleiche IP-Adressen in einem IP-Subnetz funktioniert nicht. Der saubere Weg ist, verschiedene IP-Adressen einzugeben oder DHCP zu nutzen. Falls Dein Router nicht die von DHCP vergebenen IP-Adressen "fest" machen kann, also immer wieder die gleiche IP-Adresse an die MAC-Adresse des ESP8266 zuweisen kann, dann solltest Du den Router wechseln. Broadcast hat hiermit überhaupt nix zu tun.
:
Bearbeitet durch User
Michael R. schrieb: > Auch per Multicast wird es mit der gleichen IP Adresse nicht gehen... Hatte ich auch nicht behauptet. Das gleiche Adressen nicht gehen hatte ich vorher im meinem Beispiel schon versucht darzulegen. Ok, hätte ich sicherlich auch noch viel deutlicher machen können, ist mir hinterher auch auf gefallen. Aber da ich nicht angemeldet bin konnte ich das nicht noch erweitern ...
Horst schrieb: > Nein, auch so funktioniert IP nicht. > Für die Übertragung hat jedes Device eine eigene Adresse, die Deswegen steht auch darüber: >> Deine Erwartungshaltung mal zum Verständnis mal als Beispiel ein Postpaket: Wie soll ich das denn noch vor tanzen? Ich habe auch weder das Handshaking noch das Schichtenmodel angesprochen sondern NUR auf Wikipedia verwiesen, wo der TO erstmal genug zu lesen hat. Das er sich mit TCP/IP beschäftigen sollte wurde weiter oben auch schon genannt. So, noch mal für alle: Das war ein Beispiel und kein Lehrbuch für den Netzwerk-Admin. Das man ALLES viel besser, deutlicher und ausführlicher schreiben kann ist mir auch klar. Deswegen gibt es dicke Bücher, tausende von RFCs ( von denen ich auch kein einziges erwähnt habe ) und all so ein Zeug. Mann mann mann ...
Fazit: Jeder ESP braucht eine eigene IP. Per MQTT verteilt man die Nachrichten an alle/einzelne IPs.
Hallo, viele Antworten, danke erstmal. TCP ist sockelorientiert, dass weiß ich. Das es damit ggf. Probleme gibt dachte ich mir schon, wäre auch halb so wild, dann programmiere ich das Terminal auch auf HTTP Befehle um. Hier wird viel auf TCP eingegangen, dass kann aber vernachlässigt werden. BTW: Alle Geräte haben den gleichen Port (2020). Viel interessanter hingegen ist HTTP GET/PUT. Dort ist es so wenn beide Geräte an sind, das per GET das 1. und per PUT das 2. Gerät erreicht werden kann (warum auch immer?!). Ich dachte eigentlich so: Wenn ich einem ESP die gleiche IP (und ggf./zwinglich) die gleiche MAC gebe, dann sind das für den Router die gleichen Geräte und es wird an beide das gleiche versendet. So war mein Plan. Als wenn ich im Bussystem die gleiche ID verteile, ist zwar nicht toll, geht aber. Meine Probleme sind jetzt wie folgt: 1. DHCP kann ich machen, das wäre kein Problem, aber wie ändere ich den Namen am ESP?! Das mit dem Router dort den Namen ändern kommt nicht in Frage, das ist super umständlich. Ich will eher Plug&Play. 2. Wenn ich den Namen geändert hätte, wie sende ich was bspw. an HTTP GET an den Namen. Normalerweise gebe ich ja die IP (die wäre mir ja unbekannt wegen DHCP) an. Im Normalfall würde ich sowas senden: http://192.168.1.205:2020/?FensterDATEN. Wie mache ich das wenn der zwar einen Namen hat ich die IP aber nicht weiß?! Wie gesagt, ich hatte in der Anfangszeit genau das selbe Problem. Ich habe nicht herausbekommen wie sich der Name ändern lässt oder sich dann das Gerät ermitteln lässt, sodass ich auf diese feste IP gewechselt bin (was bei Geräten wo man nur 1 hat ja auch wunderbar klappt):
Marius D. schrieb: > ormalerweise gebe ich ja die IP (die wäre mir ja > unbekannt wegen DHCP) an. Im Normalfall würde ich sowas senden: > http://192.168.1.205:2020/?FensterDATEN. Wie mache ich das wenn der zwar > einen Namen hat ich die IP aber nicht weiß?! dein stichwort ist DNS. aber du solltest dir die sache mit dem MQTT wirklich anschauen. das wird dein leben garantiert erleichtern..
Marius D. schrieb: > Ich dachte eigentlich so: Wenn ich einem ESP die gleiche IP (und > ggf./zwinglich) die gleiche MAC gebe, dann sind das für den Router die > gleichen Geräte und es wird an beide das gleiche versendet. So war mein > Plan. Vergiss es! Das, was du da Plan nennst, ist eine Dummheit. Dass dein Router/Netz das wegsteckt, ohne völlig zusammen zu brechen, ist eine Gnade deines Systems. Bitte mache einen Netzwerkgrundlagenkurs. Alternativ: Eine Hirnoperation, damit der kranke Gedanke/Plan da raus kommt. Sorry, für die Grobheit, aber es ist traurig mit anzusehen, wie sich jemand absichtlich selber Knüppel zwischen die Beine wirft, und dann auch noch darauf beharrt, wie toll die Idee doch ist.
Arduino F. schrieb: > Marius D. schrieb: >> Ich dachte eigentlich so: Wenn ich einem ESP die gleiche IP (und >> ggf./zwinglich) die gleiche MAC gebe, dann sind das für den Router die >> gleichen Geräte und es wird an beide das gleiche versendet. So war mein >> Plan. > Vergiss es! > Das, was du da Plan nennst, ist eine Dummheit. > > Dass dein Router/Netz das wegsteckt, ohne völlig zusammen zu brechen, > ist eine Gnade deines Systems. > > Bitte mache einen Netzwerkgrundlagenkurs. > Alternativ: Eine Hirnoperation, damit der kranke Gedanke/Plan da raus > kommt. > > Sorry, für die Grobheit, aber es ist traurig mit anzusehen, wie sich > jemand absichtlich selber Knüppel zwischen die Beine wirft, und dann > auch noch darauf beharrt, wie toll die Idee doch ist. Immer mit der Ruhe Junge. Sag mir wie dein Plan diesbezüglich ausschaut.
dunno.. schrieb: > Marius D. schrieb: >> ormalerweise gebe ich ja die IP (die wäre mir ja >> unbekannt wegen DHCP) an. Im Normalfall würde ich sowas senden: >> http://192.168.1.205:2020/?FensterDATEN. Wie mache ich das wenn der zwar >> einen Namen hat ich die IP aber nicht weiß?! > > dein stichwort ist DNS. > > aber du solltest dir die sache mit dem MQTT wirklich anschauen. das wird > dein leben garantiert erleichtern.. MQTT werde ich mir angucken, die Frage ist nur, ob ich dann noch via HTTP per App drauf zu greifen kann, geht das?
MQTT ist eine Middleware um Daten zwischen verschiedenen Anwendungen zu verteilen, das hat mit HTTP nichts zu tun. Willst Du HTTP weiterhin nutzen kannst Du dir einen Server schreiben, der die MQTT Daten zentral sammelt und via HTTP zur Verfügung stellt.
Thorsten schrieb: > MQTT ist eine Middleware um Daten zwischen verschiedenen Anwendungen zu > verteilen, das hat mit HTTP nichts zu tun. Willst Du HTTP weiterhin > nutzen kannst Du dir einen Server schreiben, der die MQTT Daten zentral > sammelt und via HTTP zur Verfügung stellt. Ah okay dann habe ich das grob verstanden. Ja sowas hatte ich massenweise am Anfang des Projekt durchgelesen. Ich bin davon weggegangen, da ich ja genau meine Plug&Play Lösung wollte. App installieren Gerät steuern. Am Reiter anderen Namen auswählen anderes Gerät steuern. Ohne großartige Konfig und Arbeit mit irgendwelchen Servern...
Marius D. schrieb: > Ah okay dann habe ich das grob verstanden. Ja sowas hatte ich > massenweise am Anfang des Projekt durchgelesen. Ich bin davon > weggegangen, da ich ja genau meine Plug&Play Lösung wollte. App > installieren Gerät steuern. Am Reiter anderen Namen auswählen anderes > Gerät steuern. Ohne großartige Konfig und Arbeit mit irgendwelchen > Servern... Dann bleib bei deinem bisherigen Konzept und gibt den ESP einfach feste unterschiedliche IP-Adressen, entweder direkt oder über entsprechende Konfiguration des DHCP Servers. Und wenn Du es komfortabel haben willst auch noch einen DNS Namen.
Thorsten schrieb: > Marius D. schrieb: >> Ah okay dann habe ich das grob verstanden. Ja sowas hatte ich >> massenweise am Anfang des Projekt durchgelesen. Ich bin davon >> weggegangen, da ich ja genau meine Plug&Play Lösung wollte. App >> installieren Gerät steuern. Am Reiter anderen Namen auswählen anderes >> Gerät steuern. Ohne großartige Konfig und Arbeit mit irgendwelchen >> Servern... > > Dann bleib bei deinem bisherigen Konzept und gibt den ESP einfach feste > unterschiedliche IP-Adressen, entweder direkt oder über entsprechende > Konfiguration des DHCP Servers. Und wenn Du es komfortabel haben willst > auch noch einen DNS Namen. Was ich nicht so ganz verstehe ist, folgendes: https://en.wikipedia.org/wiki/Multicast_address Hier steht was ich auch damals gelesen hatte, dass 224.0.0.1 für ALLE Hosts ist. Ich habe mal versucht, diese IP zu setzen, jedoch kann ich das Gerät dann via HTTP PUT/GET nicht mehr erreichen. Stehe irgendwie im Wald.
HTTP ist TCP basiert. Multicast/Broadcast funktioniert nur mit UDP.
Horst schrieb: > Da keine IP zwei MAC-Adressen (oder umgekehrt) zugeordnet sein kann, Umgekehrt geht. Ein Gerät kann (mit einer MAC) mehrere IP-Adressen haben. Marius D. schrieb: > Ich dachte eigentlich so: Wenn ich einem ESP die gleiche IP (und > ggf./zwinglich) die gleiche MAC gebe, dann sind das für den Router die > gleichen Geräte und es wird an beide das gleiche versendet. So war mein > Plan. Für den Router ist eine MAC nur EIN Ziel. Und nur dort schickt er ein Paket dafür hin. Sagst Du dem Router MAC XY ist nun dort, dann vergisst er die alte Position. Deshalb sind MACs weltweit unique. Alleine die ARP-Anfrage löst ein Chaos in Deinem Router aus. (Welcher ARP sprechen muss, um die Pakete richtig zu leiten.) IP ist ein wunderbares Protokoll, für das es schon alles gibt und man nicht neu erfinden muss. Die richtige Vorgehensweise, wenn Du keine Daten von Hand irgendwo (außer im Client) hinterlegen möchtest, ist: - Client holt sich per DHCP eine IP - Client meldet sich mit Namen und IP bei einem dynamischen DNS-Server - z.B. mit nsupdate - Andere Clients bekommen vom DNS die korrekte IP zum angefragten Namen - Über ARP bekommen sie auch die MAC https://de.wikipedia.org/wiki/DHCP https://de.wikipedia.org/wiki/Dynamisches_DNS https://de.wikipedia.org/wiki/BIND Installieren, konfigurieren, keinen Blödsinn produzieren. Gruß Jobst
:
Bearbeitet durch User
>Das mit dem Router dort den Namen ändern kommt nicht in >Frage, das ist super umständlich. Das ist nur Superlangweilig. Alle anderen Lösungen sind wesentlich interessanter - aber in Summe auch wesentlich aufwendiger. Wenn du experimentieren willst - baue dir ein System, das auf Broadcasts aufbaut und die locale hosts Datei für den Browser füllt. Das werden 6 interessante, lehrreiche Monate.
Marius D. schrieb: > TCP ist sockelorientiert, dass weiß ich. Das es damit ggf. Probleme gibt > dachte ich mir schon, wäre auch halb so wild, dann programmiere ich das > Terminal auch auf HTTP Befehle um. Hier wird viel auf TCP eingegangen, > dass kann aber vernachlässigt werden. > > BTW: Alle Geräte haben den gleichen Port (2020). > > Viel interessanter hingegen ist HTTP GET/PUT. > Dort ist es so wenn beide Geräte an sind, das per GET das 1. und per PUT > das 2. Gerät erreicht werden kann (warum auch immer?!). Dein Geschreibsel gibt so gar keinen Sinn. Bitte beschäftige Dich erst einmal mit den Netzwerkgrundlagen, OSI-Stack und so, dann sehen wir weiter. IP/TCP-IP/HTTP sind alles verschiedene Protokolle auf verschiedenen Netzwerkebenen. Das musst Du lernen. Ansonsten mache es lieber seriell ;-)
Jobst M. schrieb: > Für den Router ist eine MAC nur EIN Ziel. Und nur dort schickt er ein > Paket dafür hin. Sagst Du dem Router MAC XY ist nun dort, dann vergisst > er die alte Position. Deshalb sind MACs weltweit unique. MAC-Adressen sind nur innerhalb eines Ethernet-Netzwerkes relevant; der Router arbeitet auf IP-Adress- und nicht auf MAC-Adress-Ebene. Der PC des Nachbarn, der an einem anderen Router hängt, kann völlig problemlos exakt dieselbe MAC-Adresse haben. Der kann sogar die gleiche IP-Adresse verwenden wie der eigene PC, der Nachbar hat sein eigenes lokales Netzwerk, das durch den Router vom anderen Netzwerk isoliert ist. Wer aber MAC-Adressen auswertet, ist der Switch, der im Router eingebaut (oder nachgeschaltet) ist. Und der merkt sich, an welchem seiner Netzwerkports welche Netzwerkgeräte mit welcheb MAC-Adressen angeschlossen sind, damit er die Ethernetpakete an den richtigen Netzwerkports übertragen kann. Das ist nämlich eine der wesentlichen Eigenschaften eines Switches: Ethernet-Pakete werden nicht an allen Ports ins gesamte Netzwerk 'rausgeblasen, sondern nur an den jeweils korrekten Empfänger gesendet. Deswegen sieht ohne weitere Maßnahmen ein an einem weiteren Port des Switches angeschlossener Rechner auch nicht den Datenverkehr der ersten beiden Rechner. Die MAC-Adress-Tabelle, die der Switch verwaltet, ist natürlich deutlich größer als die Anzahl der Ports, weil pro Port auch mehr als ein Gerät zulässig sein muss - schließlich kann zwischen Port und Zielgerät ja noch ein weiterer Switch untergebracht sein. Auch auf Ethernet-Ebene gibt es Broadcast-Pakete, diese werden an allen Ports des Switches ausgegeben. Innerhalb eines Netzwerkes müssen MAC-Adressen eineindeutig sein, da sonst der Switch mit der Zuordnung seiner Ports durcheinanderkommt.
Rufus Τ. F. schrieb: > MAC-Adressen sind nur innerhalb eines Ethernet-Netzwerkes relevant; der > Router arbeitet auf IP-Adress- und nicht auf MAC-Adress-Ebene. Verdammt! Streiche Router, setze Switch! Danke für die Korrektur! Gruß Jobst
Pete K. schrieb: > Marius D. schrieb: >> TCP ist sockelorientiert, dass weiß ich. Das es damit ggf. Probleme gibt >> dachte ich mir schon, wäre auch halb so wild, dann programmiere ich das >> Terminal auch auf HTTP Befehle um. Hier wird viel auf TCP eingegangen, >> dass kann aber vernachlässigt werden. >> >> BTW: Alle Geräte haben den gleichen Port (2020). >> >> Viel interessanter hingegen ist HTTP GET/PUT. >> Dort ist es so wenn beide Geräte an sind, das per GET das 1. und per PUT >> das 2. Gerät erreicht werden kann (warum auch immer?!). > > Dein Geschreibsel gibt so gar keinen Sinn. Bitte beschäftige Dich erst > einmal mit den Netzwerkgrundlagen, OSI-Stack und so, dann sehen wir > weiter. > > IP/TCP-IP/HTTP sind alles verschiedene Protokolle auf verschiedenen > Netzwerkebenen. Das musst Du lernen. > > Ansonsten mache es lieber seriell ;-) Ja das weiß ich doch das das verschiedene Protokolle auf unterschiedlichen Ebenen sind. Ich habe in der FW alle 3 Varianten implementiert. Und die funktionieren ja auch. Das Problem liegt ja einfach nur in einem Punkt: Wenn ich DHCP mache würde alles laufen ohne Probleme. Jedoch bekomme ich dann an der APP/PC nicht mehr die Geräte ermittelt. Wenn ich das hinbekommen würde, dann wäre alles erledigt. Dann mache ich DHCP und fertig. Da das aber einfach nicht geklappt hat damals als ich angefangen habe mit dem ESP (vor 3 Jahren), bin ich zu der Variante der festen IP gegeangen. Die ist in APP und PC Terminal hinterlegt und das klappt. Die ist ja immer konstant: 192.168.x.y, y ist Geräteabhängig, x ist Routerabhängig, das wird aber alles automatisch in Routinen berücksichtigt.
> https://de.wikipedia.org/wiki/DHCP > https://de.wikipedia.org/wiki/Dynamisches_DNS > https://de.wikipedia.org/wiki/BIND > > Installieren, konfigurieren, keinen Blödsinn produzieren. > > > Gruß > > Jobst Ja da kommt wieder direkt das erste Problem. Beim ESP kann man den Namen einfach nicht ändern. Sowas dummes.... Das war damals schon mein Problem.
Marius D. schrieb: > Ja da kommt wieder direkt das erste Problem. Beim ESP kann man den Namen > einfach nicht ändern. Sowas dummes.... Das war damals schon mein > Problem. Schickst Du Daten ab oder tut der ESP das selbst ohne dass Du Einfluss hast? Wenn Du selber Daten verschicken kannst, ist das kein Problem. Ich kann mir nicht vorstellen, dass Dir das nicht klar ist. Und ich sehe aus Deinen Äusserungen, dass Du Dich noch nicht wirklich damit auseinander gesetzt hast. Gruß Jobst
Rufus Τ. F. schrieb: > Die MAC-Adress-Tabelle, die der Switch verwaltet, ist natürlich deutlich > größer als die Anzahl der Ports, weil pro Port auch mehr als ein Gerät > zulässig sein muss - schließlich kann zwischen Port und Zielgerät ja > noch ein weiterer Switch untergebracht sein. > > Auch auf Ethernet-Ebene gibt es Broadcast-Pakete, diese werden an allen > Ports des Switches ausgegeben. > > Innerhalb eines Netzwerkes müssen MAC-Adressen eineindeutig sein, da > sonst der Switch mit der Zuordnung seiner Ports durcheinanderkommt. Das ist mal eine Antwort die mal etwas hilft anstelle nur dumme Vorwürfe... Die MACs der Geräte sind eindeutig, die IP hatte ich nur gleich gesetzt, da ich dachte das er dass dann ignorieren würde ähnlich einem Bussystem mit 2 Teilnehmern gleicher ID - naja falsch gedacht. Dieses ganze DynDNS etc... kenne ich alles, will ich aber nicht. Das ist absolut kein Plug&Play für mich. Ich möchte mein Gerät anschalten, die App runterladen und steuern können. Ohne großes tramtram drum herum. Jetzt mal zur Frage: UDP so wie ich das sehe wäre dafür weitaus besser geeignet. Man könnte nun, so wie ich das verstanden habe, die gleiche IP (224.0.0.1) setzen (MAC ist ja weiterhin unique) und ich sende dann weiterhin mein Protokoll. Wenn man Fernzugriff will, müsste man doch theoretisch das über einen Server umsetzen können, oder? Würde das gehen?
>die gleiche IP (224.0.0.1) setzen
Nein, du begreifst absolut gar nichts!
Jobst M. schrieb: > Marius D. schrieb: >> Ja da kommt wieder direkt das erste Problem. Beim ESP kann man den Namen >> einfach nicht ändern. Sowas dummes.... Das war damals schon mein >> Problem. > > Schickst Du Daten ab oder tut der ESP das selbst ohne dass Du Einfluss > hast? > Wenn Du selber Daten verschicken kannst, ist das kein Problem. Ich kann > mir nicht vorstellen, dass Dir das nicht klar ist. > > Und ich sehe aus Deinen Äusserungen, dass Du Dich noch nicht wirklich > damit auseinander gesetzt hast. > > > Gruß > > Jobst Wie meinst du das mit den Daten? Ich schicke nur Daten an den ESP vom µC. Das sind entweder Konfig-Daten für den ESP (bspw. AP anschalten, AP Name einstellen usw...) oder Antworten an den Sender, bspw. wenn ich per App auf "AN" klicke dann schicke ich Feedback ob es an oder aus ist. Dieses Handling mache nur ich. Den Hostnamen des ESP kann man nicht via AT-Befehl ändern (zumindest was ich weiß). Auf dem ESP läuft eine Standartsoftware von Espressif. Der Name des ESP lautet immer ESP_82xxxx, die 4 x'er sind die letzten Nummern der MAC. Womit soll ich mich nicht beschäftig haben?
holger schrieb: >>die gleiche IP (224.0.0.1) setzen > > Nein, du begreifst absolut gar nichts! Ist korrekt, dann klär mich doch auf. Auf WIKI steht das das die IP für ALLE Geräte ist.
Marius D. schrieb: > UDP so wie ich das sehe wäre dafür weitaus besser geeignet. Nein. Marius D. schrieb: > Wenn man Fernzugriff will, müsste man doch > theoretisch das über einen Server umsetzen können, oder? Joar. Wie soll die Kommunikation bis zum Server stattfinden? Broadcast über das Internet? Wo ist da PnP, wenn erst ein Server installiert werden muss?? Marius D. schrieb: > Das ist mal eine Antwort die mal etwas hilft anstelle nur dumme > Vorwürfe... Du machst Dich ja selbst zur Zielscheibe. Ich bin raus ...
Marius D. schrieb: > Auf WIKI steht das das die IP für ALLE Geräte ist. Das ist die Adresse, an die gesendet werden muss. Nicht die Adresse, die bei den Geräten eingestellt werden muss. Nochmal zum Mitmeisseln: Du musst jedem Deiner Controller eine eigene IP-Adresse verpassen. Und wenn Du DHCP verwenden willst, und Deine Controller über einen eindeutigen Namen (und nicht IP-Adressen) ansprechen können willst, könnte das hier helfen: http://www.esp8266.com/viewtopic.php?f=6&t=617 Bei Verwendung der Arduino-Dinge wird das hier vermutlich helfen: https://www.reddit.com/r/esp8266/comments/3zl3pi/change_esp8266_network_name/
Rufus Τ. F. schrieb: > Marius D. schrieb: >> Auf WIKI steht das das die IP für ALLE Geräte ist. > > Das ist die Adresse, an die gesendet werden muss. Nicht die Adresse, > die bei den Geräten eingestellt werden muss. > > Nochmal zum Mitmeisseln: > > Du musst jedem Deiner Controller eine eigene IP-Adresse verpassen. > > Und wenn Du DHCP verwenden willst, und Deine Controller über einen > eindeutigen Namen (und nicht IP-Adressen) ansprechen können willst, > könnte das hier helfen: > > http://www.esp8266.com/viewtopic.php?f=6&t=617 > > Bei Verwendung der Arduino-Dinge wird das hier vermutlich helfen: > > https://www.reddit.com/r/esp8266/comments/3zl3pi/change_esp8266_network_name/ Achso, okay jetzt habe ich es verstanden. Danke dir. Also nochmal, dass es auch richtig sitzt: 1. Ich mache bei den Controllern DHCP, sie bekommen IP vom Router 2. Ich sende an die globale IP, dann werden diese Daten an ALLE Netzwerkteilnehmer gesendet Frage hier: Geht das nur bei UDP oder gibt/geht sowas auch via HTTP GET/PUT? Ja das mit den Namen beim ESP weiß ich, ich wollte aber die FW vom ESP nicht umschreiben - wenn alle Stricke reißen mache ich das, aber ich wollte auf der Seite einfach das originale nutzen - fertig. Programmiere in C, nutze/mag kein Arduino.
Marius D. schrieb: > 2. Ich sende an die globale IP, dann werden diese Daten an ALLE > Netzwerkteilnehmer gesendet Das setzt UDP voraus. Bei TCP werden vom Empfänger die empfangenen Daten quittiert und erst dann gelten die Daten vom Sender als korrekt gesendet. Nun stell' Dir das mal in einer Broadcast-Situation vor; der Sender weiß gar nicht, wieviele Empfänger es gibt, wie soll er da auf die Quittungen warten, um gegebendenfalls das Senden zu wiederholen? Nein, Broadcast geht nur mit UDP, und folglich nicht mit HTTP oder einem anderen Protokoll, das TCP voraussetzt. Warum aber willst Du so etwas überhaupt machen? Welches Problem meinst Du so lösen zu wollen?
:
Bearbeitet durch User
Jobst M. schrieb: > Marius D. schrieb: >> UDP so wie ich das sehe wäre dafür weitaus besser geeignet. > > Nein. > > > Marius D. schrieb: >> Wenn man Fernzugriff will, müsste man doch >> theoretisch das über einen Server umsetzen können, oder? > > Joar. Wie soll die Kommunikation bis zum Server stattfinden? > Broadcast über das Internet? > Wo ist da PnP, wenn erst ein Server installiert werden muss?? > > Marius D. schrieb: >> Das ist mal eine Antwort die mal etwas hilft anstelle nur dumme >> Vorwürfe... > > Du machst Dich ja selbst zur Zielscheibe. > > Ich bin raus ... Naja. Ich hatte ja geschrieben ich weiß es nicht und stehe im Wald brauche Hilfe. Es ist immer einfach jmd. anzugreifen anstelle mal vernünftig zu helfen. Wer letzteres nicht kann/mag sollte doch einfach gar nichts schreiben. Im Internet und gerade in Foren sind ja immer alle Rambo's.... Lachhaftes Phänomen was sich da über die Jahre entwickelt. Es ist kaum noch möglich mal Fragen oder Meinungen zu schreiben ohne direkt (und da ist YouTube der absolute Oberhammer) asozial beschimpft oder wie hier für dumm verkauft zu werden. Unterstes Niveau, mich persöhnlich stört das nicht weil im normalen Leben sind diese Leute immer die die ganz ganz ganz klein sind. ABER: Wenn man nur die sinnvollen Antworten nimmt, ist der Thread 3 Antworten lang UND (für andere die vll. genau die gleiche dumme Frage haben und sich nicht trauen zu schreiben), wäre es viel hilfreicher als immer so ein Müll überblättern zu müssen..... Als Vorbild können sich 98% der hier beteiligten Personen mal Rufus Τ. Firefly nehmen um mal einen (oder hier den einen) zu nennen. Das nennt man Konversation und Hilfeleistung.
Rufus Τ. F. schrieb: > Marius D. schrieb: >> 2. Ich sende an die globale IP, dann werden diese Daten an ALLE >> Netzwerkteilnehmer gesendet > > Das setzt UDP voraus. Bei TCP werden vom Empfänger die empfangenen Daten > quittiert und erst dann gelten die Daten vom Sender als korrekt > gesendet. > > Nun stell' Dir das mal in einer Broadcast-Situation vor; der Sender weiß > gar nicht, wieviele Empfänger es gibt, wie soll er da auf die Quittungen > warten, um gegebendenfalls das Senden zu wiederholen? > > Nein, Broadcast geht nur mit UDP, und folglich nicht mit HTTP oder einem > anderen Protokoll, das TCP voraussetzt. > > > Warum aber willst Du so etwas überhaupt machen? Welches Problem meinst > Du so lösen zu wollen? Ahh okay, jetzt habe ich das verstanden. Ich wusste nicht das die Daten immer quittiert werden bei den IP Protokollen. Nun gut, dann geht Broadcast natürlich nicht. Ich werde mal die PC-Software umschreiben auf UDP und das mit dem "Global Call" testen. Ich hoffe das funktioniert dann. Dann kann ich beim ESP auch DHCP machen. Ich muss sowas machen, da ich bei DHCP nicht weiß, welche IP das Gerät hat. Wenn ich den Hostnamen festlegen würde (setzt vorraus, dass ich dann erst die ESP-Firmware umschreiben muss) dann habe ich immer noch das Problem, dass ich nicht weiß, wie man anhand des Netzwerknamens die IP ausfindig macht. Ich hatte sowas testweise damals mal probiert, hat mir nicht den Erfolg gebracht. Am PC war das dann nicht wie gewünscht, dass ich alle im Netzwerk eingewählten Namen ermitteln kann und deren IP bekomme. Das ist das Problem warum ich dann auf feste IP gegangen bin. Bei dem Houssystem aber äußerst dummer Fehler.... Bei den Beleuchtungsgeräten war das bis dato gut da immer nur 1 Gerät vorhanden.
Wenn du DHCP nutzt, kannst du den Hostnamen auch einmalig auf dem DHCP Server festlegen. Wenn dann dort noch ein DNS Server integriert ist (wie bei einer Fritzbox o.Ä.) kannst du ohne weitere Arbeit über den Namen zugreifen. Auch wenn du oben schreibst, dass du dort nichts konfigurieren willst, ist das trotzdem dynamischer und "mehr Plug'n Play" als für jeden ESP eine eigene Firmware mit eigenem Namen bzw. Filterkriterium zu haben.
Marius D. schrieb: > jetzt habe ich das verstanden Nich wirklich. Marius D. schrieb: > wie man anhand des Netzwerknamens die > IP ausfindig macht Das nennt sich dann DNS, die passende Funktion auf dem PC wäre z.B. "getaddrinfo". Du kannst auch UDP und TCP koppeln. Dein PC(-program) sendet einen UDP-Broadcast, worauf alle aktiven ESP mit ihrem Namen antworten. Dann hast Du Deine Liste von Geräten samt zugehöriger IP und kannts anschließend auch via TCP mit ihnen kommunizieren. Wenn die ESP beim Start Ihren Namen per UDP-Broadcast auch einmal automatisch versenden, bekommt Dein PC auch später eingeschaltete Geräte mit.
guest schrieb: > Marius D. schrieb: >> jetzt habe ich das verstanden > > Nich wirklich. > > Marius D. schrieb: >> wie man anhand des Netzwerknamens die >> IP ausfindig macht > > Das nennt sich dann DNS, die passende Funktion auf dem PC wäre z.B. > "getaddrinfo". > > Du kannst auch UDP und TCP koppeln. Dein PC(-program) sendet einen > UDP-Broadcast, worauf alle aktiven ESP mit ihrem Namen antworten. Dann > hast Du Deine Liste von Geräten samt zugehöriger IP und kannts > anschließend auch via TCP mit ihnen kommunizieren. Wenn die ESP beim > Start Ihren Namen per UDP-Broadcast auch einmal automatisch versenden, > bekommt Dein PC auch später eingeschaltete Geräte mit. Ja das tuen sie in der Tat schon. Optional kann der Name und IP auch abgefragt werden. Das ist auch eine gute Idee. Ich bin gerade dabei mir UDP anzugucken und mal ein bisschen zu testen. Dann werde ich das umbauen/erweitern. Bis dato klappt das mit dem UDP senden schomal. Auch Broadcast geht. Sieht alles gut aus bis jetzt. Finde ich gut.
Kannst Du nicht DHCP nehmen und den Adressbereich nach deinem Port abscannen? Wenn sich die ESPs mit den richtigen Daten auf dem Port melden: IP merken ...
Bevor Du da noch dutzende Stunden Arbeit reinhängst: Mache es lieber gleich richtig, und benutze einfach MQTT, um Deine ESPs zu steuern. Mittlerweile gibt es fast jede Woche hier einen Thread, wo jemand ganz ähnlich wie Du ein Smart Home-System mit ESPs machen möchte, instinktiv erst einmal den Ansatz wählt, die ESPs über irgendwelche HTTP-Requests steuern zu wollen, und dabei dann auf irgendein Problem stösst. (Woher die IP-Adressen kennen? Wie kann ich mit einem einzigen Steuerbefehl gleich mehrere/viele ESPs steuern? Was mache ich, wenn ESPs nicht als Aktor, sondern als Sensor (z.B. Bewegungsmelder) fungieren sollen? usw.) Letztlich ist das ein schönes Beispiel für https://de.wikipedia.org/wiki/Law_of_the_instrument : Diese Leute kennen üblicherweise einfach MQTT noch nicht, HTTP dafür aber gut, also versuchen sie das Problem auf Teufel komm raus mit irgendwelchem HTTP-Gefrickel zu lösen - obwohl HTTP dafür nicht gut geeignet, MQTT aber geradezu ideal ist. Zwar hat auch MQTT Nachteile - z.B., dass man sich halt erst einmal kurz einlesen/einarbeiten muss, und zwingend einen Server benötigt, auf dem dann ein sogenannten "MQTT-Broker" (in der Praxis fast immer die Software "mosquitto") läuft. Trotzdem sollte man diesen Weg gehen, denn mit irgendwelchem HTTP-Gefrickel wird man bei einem Smart Home-System auf Dauer nicht glücklich werden - vermutlich spätestens dann, wenn man den ersten Sensor integrieren möchte.
Marius D. schrieb: > Ahh okay, jetzt habe ich das verstanden. Nein, wie dein Geschreibsel zeigt hast du immer noch einige Grundlagen nicht verstanden. Setz dich ein Wochenende hin und lerne OSI-Model, Ethernet und MAC-Adressen, IP, TCP, UDP, ICMP, DNS, DHCP und ARP, statt hier deine Zeit zu verschwenden. Oben drauf kannst du noch die Grundlagen von HTTP legen. Für Anfänger gut lesbar ist http://www.tcpipguide.com/, auch wenn die Seite hässlich ist und schon ein paar Jahre alt ist. Die Seite gibt es auch als Buch https://www.nostarch.com/tcpip.htm. Auch hier macht es nichts, dass das Buch schon älter ist. Die Grundlagen die du wissen musst haben sich nicht geändert. > Ich wusste nicht das die Daten > immer quittiert werden bei den IP Protokollen. Nein, werden sie nicht. > Nun gut, dann geht > Broadcast natürlich nicht. Broadcast oder Multicast gehen schon, wenn man (a) sie dafür verwendet wofür sie gemacht sind, (b) sie richtig implementiert hat und (c) es richtig konfiguriert ist. > Ich werde mal die PC-Software umschreiben auf > UDP und das mit dem "Global Call" testen. Ich hoffe das funktioniert > dann. Dann kann ich beim ESP auch DHCP machen. Diese Aussage ergibt keinen Sinn. > Ich muss sowas machen, da ich bei DHCP nicht weiß, welche IP das Gerät > hat. Doch, denn genau die hat der DHCP-Server gerade vergeben. > Wenn ich den Hostnamen festlegen würde (setzt vorraus, dass ich > dann erst die ESP-Firmware umschreiben muss) dann habe ich immer noch > das Problem, dass ich nicht weiß, wie man anhand des Netzwerknamens die > IP ausfindig macht. DNS. > Ich hatte sowas testweise damals mal probiert, hat > mir nicht den Erfolg gebracht. Am PC war das dann nicht wie gewünscht, > dass ich alle im Netzwerk eingewählten Namen ermitteln kann und deren IP > bekomme. Schon diese Formulierung "eingewählt" ... Was soll das sein? Da wählt sich nichts ein. Du hast die Konzepte nicht verstanden. > Das ist das Problem warum ich dann auf feste IP gegangen bin. Was auch gehen würde - wenn man es richtig macht. Mehreren Geräten die gleiche IP-Adresse zu geben ist nicht "richtig machen". Übrigens gibt es noch einen komplett anderen Satz von Konzepten, allgemein als Zero-Conf bezeichnet. Für Zero-Conf sollte man allerdings die oben erwähnten Grundlagen wirklich verstanden haben, sonst bekommt man das nicht mal im Ansatz richtig implementiert. Wobei sich diverse Fraktionen noch streiten, was in dem Zusammenhang "richtig" ist.
Auch wenn wir uns alle immer wieder wiederholen... MQTT. Da kann jeder ESP seine Sensorwerte anliefern und sich seine Schalt-Kommandos abholen, egal welche IP er vom Router bekommen hat. Und die Händie-App wird auch viel einfacher, weil sie nicht x verschiedene Endpunkte abklappern muss, sondern auch alles ganz Zentral an einer Stelle vorfindet. Web-App wird auch viel einfacher und "voll live und so", MQTT lässt sich über Websocket vom Browser ansprechen. Der MQTT-Server (mosquitto) ist dabei so klein, dass er problemlos auf dem Router mitlaufen kann, oder auf einem Raspi, auf einem NAS, was halt grad da ist.
Als ob hier MQTT das Allheilmittel wäre :-( Das ist Fanboy-Gelaber. Wer die Grundlagen (Ethernet, IP, TCP) nicht im Griff hat bekommt auch MQTT nicht zum Laufen. MQTT wird nämlich normalerweise über TCP gemacht (Ausnahme MQTT for sensor-networks). MQTT ist kein Allheilmittel wenn man sein Gerät nicht mal so weit konfigurieren kann, das es prinzipiell per TCP kommuniziert. Das heißt, es braucht unter anderem eine eindeutige IP-Adresse. Damit sind wir dann wieder am Anfang.
Hannes J. schrieb: > Als ob hier MQTT das Allheilmittel wäre Du vergisst, dass es für den ESP (egal ob LUA mit nodemcu, mit Arduino-Framework oder direkt auf der SDK) fertige MQTT-Bibliotheken gibt. Da ist das ganze Low-Level-Gefrickel soweit abstrahiert, dass es eben reicht nach 08/15-Standard Initialisierung des WLans die Server-IP zu setzen. Mehr hat man da mit IP, UDP, DNS, DHCP, TCP, ... nicht zu tun, alles Plug&Play und voll Arduino-Jünger-tauglich. Grundlagen kann & sollte man trotzdem lernen, aber hier geht auch "Erst machen, später verstehen", in bester Arduino-Manier.
Planlos schrieb: > Da ist das ganze Low-Level-Gefrickel soweit abstrahiert, dass es eben > reicht nach 08/15-Standard Initialisierung des WLans die Server-IP zu > setzen. Und wenn sich Netz und/oder die Server-IP ändern fängst Du an alle Deine netten Smart-Home-Gadgets ersmal mit ner neuen Software zu versorgen. Na schönen Dank auch.
Hannes J. schrieb: > MQTT ist kein Allheilmittel wenn man sein Gerät nicht mal so weit > konfigurieren kann, das es prinzipiell per TCP kommuniziert. Das heißt, > es braucht unter anderem eine eindeutige IP-Adresse. Damit sind wir dann > wieder am Anfang. Dass alle Geräte zwangsläufig eigene IP-Adressen haben müssen (ob nun per DHCP oder statisch festgelegt), ist klar. Mein Eindruck war aber, dass der Threadstarter diesen Irrtum mittlerweile durchaus eingesehen hat, und das gar nicht mehr weiter thematisiert werden muss. Und dass hier wirklich zuerst einmal handfeste Kenntnisse in unzähligen Bereichen ("OSI-Model, Ethernet und MAC-Adressen, IP, TCP, UDP, ICMP, DNS, DHCP und ARP, [...] HTTP" ) nötig sind, denke ich jetzt eher nicht.
guest schrieb: > Und wenn sich Netz und/oder die Server-IP ändern fängst Du an alle Deine > netten Smart-Home-Gadgets ersmal mit ner neuen Software zu versorgen. Na > schönen Dank auch. Mimimimimi. Heul doch. Oder vergib einen Hostnamen für den Server.
Hi, nachdem ich null Ahnung vom 8266 habe, was ist die ganze Zeit mit "Firmware umschreiben" gemeint, und eine FW pro Gerät? Das Ding hat doch einen EEPROM und g***l hat diesen link zu Tage gefördert wo sowohl der Name als auch die IP geändert wird. https://wolf-u.li/5585/konfiguration-einer-statischen-ip-fuer-den-esp8266-und-arduino/#more-5585 (Hostname ist ein anderer Thread auf der selben Seite) Gut, steht Arduino drüber was der TO nicht möchte, sollte aber doch auch in c gehen? 1) eine FW die eh geschrieben werden muss da eigene Funktionen/Sensoren/EA. 2) Name und/oder IP ins EEPROM 3) beim Start EEPROM lesen und verwenden und gut ist == 1 Firmware + unique EEPROM. Wo ist mein Denkfehler? Da steht auch, dass der Name = ESP + Teile der Mac Adresse ist, d.h. jedes Device sollte einen eigenen Namen haben der auch bei 0815 Routern immer zur gleichen IP führt wenn DHCP verwendet wird? Auf Github hab ich auch ne Lib gefunden die entweder ein bekanntes Netz aus dem EEPROM abruft oder bis dahin einen eigenen Accespoint zur Konfiguration per fester IP und http aufmacht. Also vielleicht nicht mal unterschiedliche EEPROMS? //hufnala P. S. wollte mit den vielleicht auch mal vornehmen :-)
Hannes J. schrieb > Broadcast oder Multicast gehen schon, wenn man (a) sie dafür verwendet > wofür sie gemacht sind, (b) sie c.... v Das ist super. Dann erkläre mir doch einfach mal wie das geht anstatt nur zu sagen dass es geht weil das interessiert keinen ich will Lösungen haben. Abgesehen davon ist dein Text genau so einer von denen die unnötige quatscherei sind. Man kann dies man kann dass man kann jedes und alles funktioniert das interessiert hier überhaupt gar keinen. Sag wie es geht oder spar solche Texte. Und um was zu implementieren braucht es keine Grundlage. Ich kenne das im groben und gut ist. Mehr habe und musste ich mich damit nicht beschäftigen. Mein Gedanke war nur falsch ich dachte es geht ähnlich einem Bussystem. x Geräte mit gleicher ID geht aber ist nicht toll... aber geht. Bei IP geht's nicht habe ich dann durch gemerkt aber rufus hat erklärt was ich nicht verstanden habe (als einziger alle anderen Texten nur Müll) und nun mache ich es mit udp und bis auf das Empfangen funktioniert es. Da muss ich nochmal gucken warum das nicht geht. Davon abgesehen hat du mein ganzes Konstrukt nicht verstanden oder bist mitten drin angefangen beim lesen sonst wurden solche unnötigen Texte und unqualifizierten antworten ab Kommentar: "ich werde mal pc software umschreiben" nicht kommen. Spar dir solche Texte in meinem Thread wenn du nur laberst.
Marius D. schrieb: > Dann erkläre mir doch einfach mal wie das geht anstatt > nur zu sagen dass es geht weil das interessiert keinen ich will Lösungen > haben. Genau DAS ist dein Problem. Es gibt unzählige Versuche hier, dir zu helfen. Das sind ANSÄTZE - keine "Lösungen". Dass dir keiner eine .hex für deinen µC gibt als Lösung sollte klar sein. Wenn du "den Namen" des ESP nicht mit deinen AT-Befehlen ändern kannst - warum schreibst du nicht einfach eine FW für den ESP und sparst dir uU gleich den ATmega ein? Für C gibt es mit dem SDK haufenweise Beispiele; oder du nimmst Lua, Python oder irgend einen anderen Kram für dein Projekt. Ich habe zwei dieser "Magic Home LED-Streifen-WiFi-Controller" [1]. Das ist einfach ein ESP8266 mit 3 Mosfets, nem LDO und IR-Receiver. Beim ersten Start errichtet er sein eigenes WLAN. Mit der App [2] kann man das Gerät einfach zu einem anderen hinzufügen. Beim Start der App schickt sie einen UDP-Broadcast raus und erfährt aus den Antworten, welche Geräte mit welchem Namen (JAAAA, sie lassen sich auch in der App umbennen!) und IP (sieht nur die App) da sind. Sollte der ESP sich nicht mehr zu dem AP verbinden können, macht er einfach wieder sein eigenes auf und man kann bspw. den geänderten WPA-Key eingeben. Warum bleibst du so sturr und lässt dir nicht helfen? :( PS: Kann die Teile nur empfehlen. Für den Preis bekommt man die weder selbst gebaut noch die FW. [1] https://www.aliexpress.com/item/Magic-Home-Wifi-LED-RGB-RGBW-Controler-DC12V-MIni-Wifi-24-IR-Key-Remote-Controller-for/32727072737.html?spm=2114.40010308.4.2.STQEeA [2] https://play.google.com/store/apps/details?id=com.Zengge.LEDWifiMagicHome&hl=de
Und, du glaubst wirklich, nach so einem Posting noch hilfreiche Antworten zu bekommen? Selbst, wenn du für diese Dienstleistung bezahlen würdest, wäre dein Verhalten anstößig/unhöflich. Tipp 1: Wenn du die Antworten nicht verstehst, dann fehlen dir Grundlagen. Fertig und aus. Da hilft kein Gejammere. Und kein mit den Füßen auf dem Boden rum stampfen, wie so ein 3 jähriges Kind.... Tipp 2: Martin Gerhard Reisenberg sagte: > Schreie nach Besserem, bis du es auch erhältst. > Das noch Bessere verabschiedet sich > rechtzeitig vor deinem Lärm. Marius D. schrieb: > Hannes J. schrieb >> Broadcast oder Multicast gehen schon, wenn man (a) sie dafür verwendet >> wofür sie gemacht sind, (b) sie c.... v > > Das ist super. Dann erkläre mir doch einfach mal wie das geht anstatt > nur zu sagen dass es geht weil das interessiert keinen ich will Lösungen > haben. > > Abgesehen davon ist dein Text genau so einer von denen die unnötige > quatscherei sind. Man kann dies man kann dass man kann jedes und alles > funktioniert das interessiert hier überhaupt gar keinen. Sag wie es geht > oder spar solche Texte. Und um was zu implementieren braucht es keine > Grundlage. Ich kenne das im groben und gut ist. Mehr habe und musste ich > mich damit nicht beschäftigen. Mein Gedanke war nur falsch ich dachte es > geht ähnlich einem Bussystem. x Geräte mit gleicher ID geht aber ist > nicht toll... aber geht. Bei IP geht's nicht habe ich dann durch gemerkt > aber rufus hat erklärt was ich nicht verstanden habe (als einziger alle > anderen Texten nur Müll) und nun mache ich es mit udp und bis auf das > Empfangen funktioniert es. Da muss ich nochmal gucken warum das nicht > geht. Davon abgesehen hat du mein ganzes Konstrukt nicht verstanden oder > bist mitten drin angefangen beim lesen sonst wurden solche unnötigen > Texte und unqualifizierten antworten ab Kommentar: "ich werde mal pc > software umschreiben" nicht kommen. > > Spar dir solche Texte in meinem Thread wenn du nur laberst.
Arduino F. schrieb: > Und, du glaubst wirklich, nach so einem Posting noch hilfreiche > Antworten zu bekommen? > > Selbst, wenn du für diese Dienstleistung bezahlen würdest, wäre dein > Verhalten anstößig/unhöflich. Du warst doch der erste der gepostet hat, dummes Zeug und wie die Axt im Wald. Also halt dich doch einfach raus, Junge. Davon ab. Ich habe schon LANGE alles was ich wollte. Läuft schon alles :) Rufus hat doch erklärt was unschlüssig war. Mehr wollte ich gar nicht. Keine Ahnung warum hier immer noch so viel geschrieben wird....
Icke schrieb: > Genau DAS ist dein Problem. Es gibt unzählige Versuche hier, dir zu > helfen. Das sind ANSÄTZE - keine "Lösungen". Dass dir keiner eine .hex > für deinen µC gibt als Lösung sollte klar sein. Brauche ich doch auch gar nicht, ich kann programmieren, davon ab läuft das ja alles und ist schon lange fertig. Ein Ansatz ist nicht zu sagen das es geht, sondern im groben wie. Es war ja nur der Gedankenfehler mit den gleichen IP's. Seit UDP ist alles ok. > Wenn du "den Namen" des ESP nicht mit deinen AT-Befehlen ändern kannst - > warum schreibst du nicht einfach eine FW für den ESP und sparst dir uU > gleich den ATmega ein? Für C gibt es mit dem SDK haufenweise Beispiele; > oder du nimmst Lua, Python oder irgend einen anderen Kram für dein > Projekt. Ich habe aber keine Lust die FW vom ESP zu ändern. Mein erstes Projekt mit dem ESP ist vor 4 Jahren. Dort habe ich das schon nicht machen wollen. > Beim > ersten Start errichtet er sein eigenes WLAN. Mit der App [2] kann man > das Gerät einfach zu einem anderen hinzufügen. Beim Start der App > schickt sie einen UDP-Broadcast raus und erfährt aus den Antworten, > welche Geräte mit welchem Namen (JAAAA, sie lassen sich auch in der App > umbennen!) und IP (sieht nur die App) da sind. > Sollte der ESP sich nicht mehr zu dem AP verbinden können, macht er > einfach wieder sein eigenes auf und man kann bspw. den geänderten > WPA-Key eingeben. Genau das was der kann habe ich bei meinen Geräten als ich mit dem ESP anfing (vor 4 Jahren) auch implementiert. Exakt das gleiche Schema abgesehen vom UDP, das mache ich jetzt ja. Das wusste ich nicht mit dem UDP Broadcast. Ich hatte das damals auch so implementiert, dass wenn der ESP sich nicht einwählen kann er den AP aufmacht. Dort kann man dann über APP/PC Terminal (automatische Routinen) eine "Netzwerkregistrierung" anklicken und dann die nötigen Daten eingeben. Dann verschwindet der AP und man kann es bedienen (ich hatte bis dato feste IP). Durch den UDP Broadcast werde ich das ganze nun dynamisch machen können. Hätte ich früher gewusst, dass es bei UDP Broadcast gibt, hätte ich das gleich so gemacht. Aber nun wird es nachgeholt! Und das war eigentlich auch nur die einzige Frage die schon lange beantwortet wurde..... > Warum bleibst du so sturr und lässt dir nicht helfen? :( Ich lasse mir gerne helfen. Aber nicht bei solchen Antworten die nicht auf meine Sachen eingehen. Rufus hat es getan und seit dem läuft's. MQTT kenne ich seit ewigen Jahren, wollte/will ich aber geziehlt nicht einsetzen. Wird mir aber 1000x vorgeschlagen, obwohl ich mehrfach gesagt habe das mein Konzept ein anderes ist. Dafür habe ich die App, PC-Terminal und µC-Firmware schon lange fertig und vollständig. Ich muss jetzt nur einmal alles von HTTP PUT auf UDP ändern und es geht. > PS: Kann die Teile nur empfehlen. Für den Preis bekommt man die weder > selbst gebaut noch die FW. Das ist bestimmt richtig. Ich baue aber gerne selber da ich dort einfach FW technisch machen kann was ich will. Aber trzd. danke für die Links. Sind auf jeden Fall interessant! > [1] > https://www.aliexpress.com/item/Magic-Home-Wifi-LED-RGB-RGBW-Controler-DC12V-MIni-Wifi-24-IR-Key-Remote-Controller-for/32727072737.html?spm=2114.40010308.4.2.STQEeA > [2] > https://play.google.com/store/apps/details?id=com.Zengge.LEDWifiMagicHome&hl=de
Marius D. schrieb: > MQTT kenne ich seit ewigen Jahren, wollte/will ich aber geziehlt nicht > einsetzen. Wird mir aber 1000x vorgeschlagen, obwohl ich mehrfach gesagt > habe das mein Konzept ein anderes ist. Ahja, soso. Zu Deiner Erinnerung hier nochmal die absolut einzige Stelle, an der Du selbst bislang MQTT erwähnt hast: > MQTT werde ich mir angucken, die Frage ist nur, ob ich dann noch via > HTTP per App drauf zu greifen kann, geht das? Wirklich unverständlich, wieso die anderen Forenten in Anbetracht einer solchen Aussage nicht sofort darauf gekommen sind, dass Du MQTT in Wahrheit schon "seit ewigen Jahren" kennst, also quasi voll der MQTT-Experte bist.
Joachim S. schrieb: > Marius D. schrieb: >> MQTT kenne ich seit ewigen Jahren, wollte/will ich aber geziehlt nicht >> einsetzen. Wird mir aber 1000x vorgeschlagen, obwohl ich mehrfach gesagt >> habe das mein Konzept ein anderes ist. > > Ahja, soso. Zu Deiner Erinnerung hier nochmal die *absolut einzige* > Stelle, an der Du selbst bislang MQTT erwähnt hast: > >> MQTT werde ich mir angucken, die Frage ist nur, ob ich dann noch via >> HTTP per App drauf zu greifen kann, geht das? > > Wirklich unverständlich, wieso die anderen Forenten in Anbetracht einer > solchen Aussage nicht sofort darauf gekommen sind, dass Du MQTT in > Wahrheit schon "seit ewigen Jahren" kennst, also quasi voll der > MQTT-Experte bist. Nein ich kenne es grob die es arbeitet und was die Idee ist. Das andere wollte ich mir nochmal angucken wie man es einrichtet so meinte ich das.
Man man man....... ich finds ja echt Klasse das sich immer mehr Leute die vorher evtl. nie mit Elektronik oder IT etc. auch nur irgendwas am Hut hatten sich durch Arduino, ESP breakout boards etc. dazu beflügelt fühlen "schöne neue" Dinge zu basteln, ABER es führt in den meisten Fällen, die ich bis jetzt beobachten durfte, immer nur zu einem "drauflosbasteln ohne Sinn und Verstand" bis jemand anderes es dann fixed. Das vorherige bitte nicht persönlich nehmen, ich bin auch kein Profi und war am Anfang genauso drauf, aber habe doch mit den Jahren feststellen müssen das es einfach Gold wert ist sich VORHER ein wenig mit den Grundlagen des Themas zu beschäftigen so dass man wenigstens ansatzweise nachvollziehen / verstehen kann was man da eigentlich tut. Diese wurde hier anscheinend NICHT getan. Ich weis es ist verlockend ein snippet hier und ein snippet da n bischen Strg-C / Strg-V, ein paar klicks in der IDE und schon "tatatataaaaa" ist das Projekt fertig und wenn man gaaaanz viel Glück hat läuft es auch aber wehe es hakt irgendwo dann beginnt der absolut vermeidbare HeadlessChickenDance. Dabei ist es eigentlich sooo einfach, es gibt zu fast allem irgendwie - irgendwo n Wikipedia Artikel oder ähnliches im Netz zu finden da muss man zwar auch ein wenig selber filtern was brauchbar ist aber das bekommt man mit der Zeit schon raus. Bücher sollen auch ganz gut funktionieren, habe ich mir sagen lassen. Die Menschheit wächst heute fast mit dem Smartphone in der Hand auf, aber weis sich nicht mal selbst zu helfen. Ich bin immer wieder erstaunt welche Blicke man erntet wenn man nach etwas gefragt wird, es selber nicht weis und empfiehlt : Befrag doch mal die Suchmaschiene deiner Wahl dazu, was anderes würde ich jetzt auch nicht tun. Wie???? echt??? das geht??? Informationen aus dem Internetz?? Wie nicht von Youtube??? Brauch ich dafür ne App?????? .... von meinem Geschwafel bitte nicht entmutigen lassen, macht bitte mit dem weiter was ihr tut, nur wer übt kann zum Meister werden, aber im Hinterkopf behalten, versucht wenigstens Euch selbst zu helfen bevor man hier einfach was postet von wegen n anderer wirds schon richten und so...
Wieso nimmst Du nicht espeasy oder ein ähnliches Paket? Da ist alles schon drin.
C.G. schrieb: > Man man man....... ich finds ja echt Klasse das sich immer mehr Leute > die vorher evtl. nie mit Elektronik oder IT etc. auch nur irgendwas am > Hut hatten sich durch Arduino, ESP breakout boards etc. dazu beflügelt > fühlen "schöne neue" Dinge zu basteln, ABER es führt in den meisten > Fällen, die ich bis jetzt beobachten durfte, immer nur zu einem > "drauflosbasteln ohne Sinn und Verstand" bis jemand anderes es dann > fixed. Das vorherige bitte nicht persönlich nehmen, ich bin auch kein > Profi und war am Anfang genauso drauf, aber habe doch mit den Jahren > feststellen müssen das es einfach Gold wert ist sich VORHER ein wenig > mit den Grundlagen des Themas zu beschäftigen so dass man wenigstens > ansatzweise nachvollziehen / verstehen kann was man da eigentlich tut. > Diese wurde hier anscheinend NICHT getan. Ich weis es ist verlockend ein > snippet hier und ein snippet da n bischen Strg-C / Strg-V, ein paar > klicks in der IDE und schon "tatatataaaaa" ist das Projekt fertig und > wenn man gaaaanz viel Glück hat läuft es auch aber wehe es hakt irgendwo > dann beginnt der absolut vermeidbare HeadlessChickenDance. > Dabei ist es eigentlich sooo einfach, es gibt zu fast allem irgendwie - > irgendwo n Wikipedia Artikel oder ähnliches im Netz zu finden da muss > man zwar auch ein wenig selber filtern was brauchbar ist aber das > bekommt man mit der Zeit schon raus. Bücher sollen auch ganz gut > funktionieren, habe ich mir sagen lassen. > Die Menschheit wächst heute fast mit dem Smartphone in der Hand auf, > aber weis sich nicht mal selbst zu helfen. > Ich bin immer wieder erstaunt welche Blicke man erntet wenn man nach > etwas gefragt wird, es selber nicht weis und empfiehlt : Befrag doch mal > die Suchmaschiene deiner Wahl dazu, was anderes würde ich jetzt auch > nicht tun. Wie???? echt??? das geht??? Informationen aus dem Internetz?? > Wie nicht von Youtube??? Brauch ich dafür ne App?????? > > .... von meinem Geschwafel bitte nicht entmutigen lassen, macht bitte > mit dem weiter was ihr tut, nur wer übt kann zum Meister werden, aber im > Hinterkopf behalten, versucht wenigstens Euch selbst zu helfen bevor man > hier einfach was postet von wegen n anderer wirds schon richten und > so... Der Thread ist eigentlich schon lange erledigt? Auf wen willst du diesen Text schließen? Auf mich? Da muss ich dich leider enttäuschen. Wie bereits gesagt, bei dem Internetprotokoll habe ich etwas drauf los geschossen, korrekt (aber auch NUR der Punkt mit den mehreren IP's die gleich sind). Alles andere (bspw. µC FW ~25kb + Bootloader via WLAN updatebar, App, Terminal alles in C/Java). Alles andere was ich seit mehreren Jahren am Laufen habe (TCP/HTTP Befehle) war ich tiefer in der Materie. Ich hätte natürlich mir damals mal UDP angucken sollen, dachte aber ist irrelevant wegen TCP/HTTP weil das gut lief.... Es nervt, weil man einmal drauf los geschossen hat, so einen Shit zu ernten. Mein Gott. Rufus hat es mir in 3 Sätzen erklärt und damit war die ganze Geschichte eignetlich erledigt und verstanden. Andere geilen sich hier auf habe ich das Gefühl. BTW: Arduino, Breakoutboards etc... kann ich überhaupt nicht ab. Gerade Arduino und diese "Sketch" was absolut nichts mit Programmierung zu tun hat. Ich fertige meine Schaltungen + Platinen selber seit zig Jahren und habe selbst Elektrotechnik an der Uni studiert...
Oliver S. schrieb: > Wieso nimmst Du nicht espeasy oder ein ähnliches Paket? Da ist alles > schon drin. FHEM habe ich bereits in Gebrauch für Fernzugriff und Weboberfläche. Allerdings mit eigenen Modulen passend für meine Firmwarebefehle...
Marius D. schrieb: > Das Problem liegt ja einfach nur in einem Punkt: > > Wenn ich DHCP mache würde alles laufen ohne Probleme. Jedoch bekomme ich > dann an der APP/PC nicht mehr die Geräte ermittelt. Wenn ich das > hinbekommen würde, dann wäre alles erledigt. Dann mache ich DHCP und > fertig. Da das aber einfach nicht geklappt hat damals als ich angefangen > habe mit dem ESP (vor 3 Jahren), bin ich zu der Variante der festen IP > gegeangen. Die ist in APP und PC Terminal hinterlegt und das klappt. Der DHCP-Client kann dem DHCP-Server einen Hostnamen übermitteln. Diesen Namen würde ein wohlerzogener Router/Gateway dann als Hostnamen im DNS registrieren. Keine Ahnung, wie die Übergabe des Hostnamens in Deiner Firmware implementiert werden muß und ob Dein Router/Gateway per DHCP übergebene Hostnamen im DNS einträgt, aber das wäre der korrekte Weg.
Jemand der behauptet dieser "Sketch" hätte nichts mit Programmierung zu tun, den kann man doch nicht ernst nehmen. Das Bild zeigt sich aber durch die ganze Lektüre dieses Threads.
> Diesen Namen würde ein wohlerzogener Router/Gateway dann als > Hostnamen im DNS registrieren. Ja, schön wär's. Meine drei vorherigen WLAN Router hatten das alle nicht gemacht. Weil mich (unter anderem) das so genervt hat, habe ich dieses mal tiefer in die Tasche gegriffen und eine Fritzbox gekauft, die kann das. Mitllerweilen bekommt man ja schon welche ab 50 Euro. > aber das wäre der korrekte Weg. Allerdings. Im Business Umfeld habe ich nie etwas anderes gesehen.
Wieso lässt du deine WLAN Module sich nicht bei einem zentralen Server registrieren? Generell würde ich für Automatisierung etwas mit MQTT/REST/etc. nehmen. Wozu der ATmega? Das kann entweder ein ESP8266 oder ein Dienst aufm Router/Pi/Thingspeak/Conrad Cloud/etc. sein. Marius D. schrieb: > BTW: Arduino, Breakoutboards etc... kann ich überhaupt nicht ab. Gerade > Arduino und diese "Sketch" was absolut nichts mit Programmierung zu tun > hat. Ich fertige meine Schaltungen + Platinen selber seit zig Jahren und > habe selbst Elektrotechnik an der Uni studiert... Gerade beim ESP8266 ist die Arduino IDE sehr schön da man hier einfach und schnell eine Anwendung die z.B. über einen HTTPS Post Sensorwerte übermittelt realisieren kann. Ich wüsste nicht wieso ich für so eine Anwendung eine Platine designen sollte und dann auch noch eine Toolchain aufsetzen sollte. Ist doch Zeitverschwendung. Aber ich seh schon, dann wäre es dir nicht elitär genug für dein abgehobenes Ego (keinen in diesem Thread interessiert, ob du Elektrotechnik/Gender Studies studiert hast).
Horst schrieb: > Marius D. schrieb: >> BTW: Arduino, Breakoutboards etc... kann ich überhaupt nicht ab. Gerade >> Arduino und diese "Sketch" was absolut nichts mit Programmierung zu tun >> hat. Das muss man nicht so ernst nehmen... Das ist die Abwertung eines Menschen, der (vermutlich) kein C++11 kann, und auch nicht sehen will. Ausblenden ist in solchen Situationen eine übliche Vorgehensweise. Und darum wird Arduino mal wieder verteufelt. Eine Abwertung um sich selber etwas zu erhöhen. Die Methode hat zwar kurze Beine, wird aber immer noch gerne genommen. Steckt wohl tief in der menschlichen Psyche. Ich finde das ok, es muss auch "andere" geben. Sonst wäre die Welt nicht so bunt, wie sie ist. Auch wenn ich es als sehr überheblich/vermessen empfinde, einem modernen C++ den Status einer Programmiersprache abzuerkennen.
Marius D. schrieb: > Der Thread ist eigentlich schon lange erledigt? > Auf wen willst du diesen Text schließen? Auf mich? Da muss ich dich > leider enttäuschen. Wie bereits gesagt, bei dem Internetprotokoll habe > ich etwas drauf los geschossen, korrekt (aber auch NUR der Punkt mit den > mehreren IP's die gleich sind). Alles andere (bspw. µC FW ~25kb + > Bootloader via WLAN updatebar, App, Terminal alles in C/Java). Alles > andere was ich seit mehreren Jahren am Laufen habe (TCP/HTTP Befehle) > war ich tiefer in der Materie. Ich hätte natürlich mir damals mal UDP > angucken sollen, dachte aber ist irrelevant wegen TCP/HTTP weil das gut > lief.... > Es nervt, weil man einmal drauf los geschossen hat, so einen Shit zu > ernten. Mein Gott. Rufus hat es mir in 3 Sätzen erklärt und damit war > die ganze Geschichte eignetlich erledigt und verstanden. Andere geilen > sich hier auf habe ich das Gefühl. > > BTW: Arduino, Breakoutboards etc... kann ich überhaupt nicht ab. Gerade > Arduino und diese "Sketch" was absolut nichts mit Programmierung zu tun > hat. Ich fertige meine Schaltungen + Platinen selber seit zig Jahren und > habe selbst Elektrotechnik an der Uni studiert... also nur um das klar zu stellen, ich wollte hier niemandem ans Bein pissen, es ist einfach nur eine Feststellung und dieser Thread war halt grad einfach da. Wie sehr du das auf dich beziehst bleibt völlig dir überlassen und wenn du ehrlich bist hab ich da gar nicht soooo viel "shit" abgelassen... Das solls dann aber auch dazu gewesen sein.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.