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.
...
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)
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.
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.
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 ...
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.
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/DHCPhttps://de.wikipedia.org/wiki/Dynamisches_DNShttps://de.wikipedia.org/wiki/BIND
Installieren, konfigurieren, keinen Blödsinn produzieren.
Gruß
Jobst
>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.
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?
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?
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...
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.
