ich habe mehrere ESP01S im Einsatz und möchte eine Erweiterung
einführen, bin aber nicht sicher ob das funktioniert.
Bisher betreibe ich die WiFi Module einfach via TCP Server(CIPSERVER).
Das alles via AT+ Kommandos mit kleinen MSP430. Klappt soweit einwandfrei.
Mittlerweile habe ich im lokalen Netzwerk mehrere Geräte die sich
mittels Multicast miteinander unterhalten. Es wäre schön, wenn ich
mit den ESP01S einige dieser Datensätze mit verwenden könnte.
Bin quasi Neuling mit dem ESP01S und habe jetzt folgende Frage:
könnte der ESP01S meinen TCP Server bedienen wie bis jetzt, aber
gleichzeitig auf einem anderen Port UDP Multicast Message mitlesen?
Danke für die Rückmeldungen.
Wenn es so einfach wäre.
Die Dokumente kenne ich alle.
Bin kein Experte aber meine Experimente mit dem ESP01S zeigen,
dass einfaches UDP sicher kein Problem ist, aber Multicast scheint
anscheinend doch etwas komplizierter zu sein. Im Moment suche
ich nach einer Möglichkeit "to Join the Multicast group" mit
AT Commandos meiner AT-FW (1.7.5) zu bewerkstelligen. Irgendwie muss
man wohl eine IGMPv2 "Membership report message" schicken
um an der Multicast Gruppe teilzunehmen.
Irgendwie muss
man wohl eine IGMPv2 "Membership report message" schicken
um an der Multicast Gruppe teilzunehmen.
Ich bin ebenfalls kein kein großartiger Experte auf diesem Gebiet, aber so wie ich Multicast bisher verstanden habe, ist die "Membership report message" nur für die Router auf dem Wege bis zu den Sendern wichtig, damit sie die Pakete weiterleiten und nicht verwerfen. Die Sender von Multicastmessages haben ja keine Ahnung davon, wer alles diese Pakete empfängt, die senden blind an eine Port/Class-D-Adress-Kombi. Da aber die Teilnehmer alle innerhalb Deines Subnetzes liegen und kein Router durchquert werden muß, braucht es m.M.n diese Anmeldung nicht. Es muß lediglich ein UDP-Socket auf dem benutzten Port und der benutzten Class-D-Adresse aufgemacht werden. Dafür gibt es wohl auch Protokolle, aber ein wiresharc-mitschnitt sollte die ebenso sichtbar machen.
(Mein Stand des Wissens ohne jede Garantie)
Danke für den Hinweis, dann brauche ich in diese Richtung
nicht weiter zu suchen. Hatte nur in Wireshark besagte Message
gelegentlich von meinem PC als Sender gesehen.
Irgendwie klappt es aber nicht mit dem passenden Setup beim
ESP01S. Irgendwie sehe ich schon was multicastmäßiges, aber
das ist eben nur eine Teil dessen was man sehen müsste. Da
gibt auch für mich Wireshark nicht viel mehr her.
Vermute immer mehr, dass die AT-FW das doch nicht unterstützt.
Werde mich mal bei AI-Thinker erkundigen.
Als ich vor ein paar Jahren Multicast probiert habe ging es auf dem
ESP8266 nicht. Weder mit der AT Firmware noch mit Arduino.
Das wäre wirklich schade!
Will aber im Moment noch nicht aufgeben. Zumal ich vielleicht nahe
dran bin. Die Multicast Message die ich beim ESP01S sehe,ist die
gleiche die ich auch in Wireshark sehe, bevor ich am PC ein bestimmtest
Programm starte. Danach sind in Wireshark alle gewünschten
Messages sichtbar. Also muss beim ESP8266 noch irgend was fehlen,
denke ich.
Dann mach doch eine eigene Firmware für den ESP, die nur die Kommunikation macht, und vorverarbeitet an den MSP weiterleitet. Dann hast du auf dem ESP alle Freiheiten bzgl. TCP, UDP, Multicast, kannst evtl. auch noch HTTP oder Modbus/UDP dahin auslagern, aber behältst die eigentliche Logik im MSP.
Protokoll zwischen ESP und MSP kannst du dann frei wählen, entweder an das AT-Kommand-Set angelehnt oder was eigenes, für den Anwendungsfall effizienteres...
Interessant. Einmal das Thema UDP Multicast auf dem ESP8266, und darüber hinaus das Thema UDP Multicast auf WiFi. Denn du wirst js zwischen PC und ESP01S noch einen AP haben, oder? Und die haben so ihre eigenen Schwierigkeiten mit echtem Multicast über Funk. Zum Beispiel, mit welcher Rate sie senden sollen ...
Interessant. Einmal das Thema UDP Multicast auf dem ESP8266, und darüber
hinaus das Thema UDP Multicast auf WiFi. Denn du wirst js zwischen PC
und ESP01S noch einen AP haben, oder? Und die haben so ihre eigenen
Schwierigkeiten mit echtem Multicast über Funk
Bin nicht sicher ob ich verstehe was damit gemeint ist.
Grundsätzlich muss MUlticast mit dem ESP funktionieren, zumindest nach
AT-Command Doku:
"If the remote host over the UDP is an IPv4 multicast address
(224.0.0.0 ~ 239.255.255.255), the ESP device will send and
receive the UDPv4 multicast."
Kann aber sein, dass meine AT-FW etwas anders draus macht!
Meine Idee ist, Multicast Messages von Geräten in meinem Netzwerk
(SMA Wechslerichter, SMA HomeManager, SMA-Energy Meter) nur mithören
und nur bestimmte Daten daraus für eigene Zwecke zu verwerten. Selber
"reden" möchte ich nicht. Es hat mit dem PC eigentlich nichts zu tun.
Der fungiert im Moment nur als Wireshark Host zum Verfolgen des
ETH Datenstroms und gleichzeitig ist da mittels USB-Adapter der ESP01S angeschlossen via Terminalprogram.
Grundsätzlich muss MUlticast mit dem ESP funktionieren, zumindest nach
AT-Command Doku:
Bist du sicher dass du diese Version der Firmware verwendest? Die AT Firmware vom ESP8266 wird (soweit ich das sehen kann) seit 2020 nicht mehr weiter entwickelt!
Aktuelle Version vom ESP32 ist 3.2, währen der ESP8266 bei 2.2 hängen geblieben ist.
Links oben kannst du die Version der Doku auswählen. Die 1.7.5 steht dort leider nicht zur Verfügung. Im oben verlinkten Dokument von Version 1.3 steht jedenfalls nichts von multicast.
Meine Idee ist, Multicast Messages von Geräten in meinem Netzwerk
(SMA Wechslerichter, SMA HomeManager, SMA-Energy Meter) nur mithören
und nur bestimmte Daten daraus für eigene Zwecke zu verwerten
Sowas in der Art dachte ich mir schon.
Funktioniert am PC problemlos, müsste ich mit dem ESP mal ausprobieren...
Falls du Beispiel-Code zum Parsen Speedwire (EnergyMeter) -> OBIS-Kennzahlen brauchst, hab ich auch noch rumfliegen, aber ebenfalls NodeJS. Ist aber auch kein Hexenwerk.
und es gibt dort scheinbar keinen String-Konstruktor von Char* und Länge...
d.H. dort das Speedwire-Parsen ergänzen, und schon kriegt dein MSP auf der seriellen z.B. schön vorbereitete und leicht zu verabeitende Datenhäppchen
"<OBIS-Kennziffer>=<Wert>\n"
Da aber die Teilnehmer alle innerhalb Deines Subnetzes liegen und kein Router
durchquert werden muß, braucht es m.M.n diese Anmeldung nicht.
Das stimmt nicht, selbst ein Switch muss die UDP Pakete für die Multicast Group Membership auswerten (IGMP snooping). Das klingt erstmal strange, da ein Switch normalerweise nur auf Layer 2 arbeitet, aber wenn es um Performance und Resource usage geht, dann wird das Layering eben manchmal durchbrochen.
Der Stromzähler (im Keller) über Wlan an einem AmpliFi-Repeater (Consumer-Marke von Ubiquiti), Switch, langes Kabel, TP-Link-Router mit OpenWRT am Arbeitsplatz, dem ich auf die Schnelle noch eine SSID für das VLan gegeben habe an dem auch der AP im Keller hängt.
Wenn bei dir Stromzähler und ESP im selben Wlan hängen, darauf achten dass da keine "Client Isolation" konfiguriert ist. Wenn der Stromzähler per LAN-Kabel dran hängt, ist das natürlich egal.
Nachtrag, wg. dem IGMP-Snooping Hinweis:
Der Switch ist auch nix besonderes, nicht managebar, irgendein Plaste-Consumer-Krempel eben. Ob der das macht oder nicht, kann ich nicht sagen.
Recht herzlichen Dank für die unterschiedlichen interessanten Beiträge
zu meinem Problem.
Da ich paar Tag mit anderen Dingen beschäftigt bin und deshalb mein
Hobbyprojekt zur Seite legen muss, komme ich Mitte nächste Woche wieder
darauf zurück und bitte speziell Εrnst B. mir dann paar Fragen zu
seiner Lösung zu beantworten. Mir fehlen da noch paar Randbedingen.
Durch Zufall habe ich jetzt eine Lösung für mein Problem gefunden,
dass möglicherweise weitere Nachfragen hier bei den Experten nicht
mehr nötig macht.
Bei folgendem Link gibt es eine programmierbare AT-FW Version 2.2.0 .
Sie lies sich sofort programmieren und liefert die Mulicast-Daten die
ich erwarte.
Habe aber nur kurz getestet und übernehme keine Garantie. Meine
Testkommandos musste ich etwas umstellen, da es anscheinend die
"..._CUR" AT-Kommandos nicht mehr gibt.
Werde weiter testen ob meine SW noch zu den anderen AT Kommandos passt.
Vielleicht hilft das anderen Interessierten weiter.
Bin quasi Neuling mit dem ESP01S und habe jetzt folgende Frage:
könnte der ESP01S meinen TCP Server bedienen wie bis jetzt, aber
gleichzeitig auf einem anderen Port UDP Multicast Message mitlesen?
Der ESP ist auch schon bald 10 Jahre auf dem Markt. Unter welchem Stein warste die letzte Zeit?
Jo, erstemal das Rad neu erfinden.
dann "pio run" zum kompilieren, "pio run -t upload" zum Installieren auf dem ESP.
Oder, falls du platformio als VSCode-Plugin benutzt, einfach die entsprechenden Knöpfchen drücken.
Source passt noch nicht 100%ig, Debugausgaben könnten den MSP430 stören, und die int64-Rechnung hat wohl noch irgendein Problem.
Entweder so ein Programmierstöpsel wie im Anhang, oder du verbindest RX, TX, GND mit einem USB->Seriell(TTL) Wandler, und stellst die nötigen Brücke zum Start im Bootloader-Modus her (GPIO0 auf LOW)
Ich habe mittels Platformio einmal ein File erzeugt und mit UPLOAD
in den ESP8266 programmiert. Wenn ich jetzt am Programm Änderungen
durchführe wird zwar mit BUILD das File fehlerfrei compiliert, aber
beim UPLOAD ist wieder das alte File programmiert. Ich habe nur
zwei Print-Kommandos eingefügt für MAC und IP. Diese werden aber
anscheinend nicht ausgeführt.
Muss ich da noch was machen dass das neue File übernommen wird?
Wo finde ich den die Beschreibung der z.B. WiFi Kommandos die hier
verwendet werden? Ich habe zwar Dokumentation gefunden, aber die
passt irgendwie nicht zu dem Code.
Ich habe den Code oben "als Gag" auf eine Viertelstunde zusammengestöpselt, und dabei einige JS->C++ Übersetzungsschritte per KI erledigen lassen.
Ich selber benutze keinen ESP zum Mitlesen von Speedwire, und habe es auch nicht vor.
Ich selber habe weder einen SMA Homemanger noch Ladesäule, nur einen "SMA EnergyMeter"-kompatiblen Stromzähler, der scheinbar manche Details doch anders macht.
Ich leiste keinen persönlichen Support für das Beispielprogramm oder SMA Anlagen.
Nicht per PN, nicht per EMail, auch nicht gegen Geld.
Wenn ihr Fragen zum Code habt, stellt sie hier im Forum, und sendet mir Keine PN.
Danke.
Und vorher hier vorbeischauen, das Problem mit komischen Feldbezeichnern nach dem 144er-Versionsfeld ist da schon gelöst.