Moin zusammen, Ich habe einen Raspberry 4 und möchte gerne per Broadcast Daten vom ADC (Temperatur) versenden via WLAN. Egal welche infos GOOGLE gibt, ich lande immer beim Multicast und es funktioniert nicht wie gewollt. In Python scheint es generell nicht zu funktionieren. Habt ihr Quellen für einen UDP-Broadcast-Server der immer sendet auch wenn mal kein Empänger da ist? Viele Grüße aus dem Schwarzwald
UDP Broadcasts sind so ungefähr die einfachste Form der Kommunikation, die überhaupt per TCP/IP möglich ist. An 255.255.255.255 rausblasen und fertig.
:
Bearbeitet durch User
Welches Protokoll benutzt du denn für die Übertragung? Für Sensordaten bietet sich ja MQTT an, welches die Daten für jeden Subscriber sicher überträgt. Das scheint mir der sicherere Weg zu sein, auch, wenn kein Sub verfügbar ist.
Marco K. schrieb: > der immer sendet auch wenn mal kein Empänger da ist Charakteristisch für UDP gegenüber anderen Protokollen (z.B. TCP) ist dass es keinen Verbindungsaufbau gibt. D.h. um ein Paket zu senden ist es nicht relevant ob der angesprochene Empfänger wirklich präsent ist oder nicht.
Vom Prinzip her habe ich das benutzt: https://www.elektronik-kompendium.de/sites/raspberry-pi/2002171.htm Damit läuft der Sendemodus als AP Und das habe ich als Grundlage zum Senden verwendet. https://wiki.python.org/moin/UdpCommunication Wie gesagt ohne Empfänger, der halt ab und zu mal nicht da ist, Bricht er ab.
UDP Behr schrieb: > Charakteristisch für UDP gegenüber anderen Protokollen (z.B. > TCP) ist dass es keinen Verbindungsaufbau gibt. D.h. um ein > Paket zu senden ist es nicht relevant ob der angesprochene > Empfänger wirklich präsent ist oder nicht. Das habe ich verstanden, aber scheinbar mein das OS es muss Multicast verwenden, daher ist da schluss mit senden.
Marco K. schrieb: > Wie gesagt ohne Empfänger, der halt ab und zu mal nicht da ist, Bricht > er ab. Reinem UDP ist es schnurzpiepegal, ob jemand zuhört. Das kann erst eine Rolle spielen, wenn man auf UDP ein weiteres Protokoll draufsattelt, das unbedingt Zuhörer braucht.
Beitrag #6818786 wurde vom Autor gelöscht.
Marco K. schrieb: > Das habe ich verstanden, aber scheinbar mein das OS es muss Multicast > verwenden, daher ist da schluss mit senden. Nein, das Abbrechen ist Bestandteil der "User"-Implementierung, also ein (oder mehrere) Level über UDP. Und wenn es so ist kann "man" ja in diese Implementierung eingreifen. Was beim UDP selbst sich etwas schwieriger gestalten würde ....
Marco K. schrieb: > aber scheinbar mein das OS es muss Multicast > verwenden, daher ist da schluss mit senden. Broadcast oder Multicast ist ja per se schon "ziel-unabhängig", das heisst man schickt eine Nachricht hinaus ohne zu wissen ob es einer oder mehrere Teilnehmer hören und darauf reagieren. Daher darf man auch nicht erwarten dass überhaupt ein einziger antwortet und muss das in seiner eigenen Implementierung berücksichtigen.
Marco K. schrieb: > Moin zusammen, > > Ich habe einen Raspberry 4 und möchte gerne per Broadcast Daten vom ADC > (Temperatur) versenden via WLAN. > In Python scheint es generell nicht zu funktionieren. doch so:
1 | s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM) |
2 | s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) |
3 | s.sendto(data,("<broadcast>", port))
|
Sascha
(prx) A. K. schrieb: > UDP Broadcasts sind so ungefähr die einfachste Form der Kommunikation, > die überhaupt per TCP/IP möglich ist. UDP-Broadcasts laufen nicht über TCP/IP, sondern eben über UDP/IP. Marco K. schrieb: > https://wiki.python.org/moin/UdpCommunication Hast du die IP auf die Broadcast-Adresse deines Netztes geändert? Zeig doch mal, welchen Code du genau ausgeführt hast und wie deine Netzwerkkonfiguration aussieht.
Rolf M. schrieb: > UDP-Broadcasts laufen nicht über TCP/IP, sondern eben über UDP/IP. Danke für die Aufklärung, aber die Protokollfamilie heisst nun einmal TCP/IP, auch wenn weder UDP noch ICMP irgendwas mit TCP zu tun haben. https://de.wikipedia.org/wiki/Transmission_Control_Protocol/Internet_Protocol
(prx) A. K. schrieb: > Danke für die Aufklärung, aber die Protokollfamilie heisst nun einmal > TCP/IP, auch wenn weder UDP noch ICMP irgendwas mit TCP zu tun haben. Ok, also wieder sowas, das einfach falsch in den allgemeinen Sprachgebrauch übergegangen ist. War mir nicht bewusst. Ich werde mich aber trotzdem weigern, es "TCP/IP" zu nennen, wenn TCP dabei überhaupt nicht vorkommt.
Rolf M. schrieb: > Ok, also wieder sowas, das einfach falsch in den allgemeinen > Sprachgebrauch übergegangen ist. War mir nicht bewusst. Ich werde mich > aber trotzdem weigern, es "TCP/IP" zu nennen, wenn TCP dabei überhaupt > nicht vorkommt. Präziser ist Internet Protocol Suite, aber da erntest du vielfach nur fragende Gesichter.
Achtung, Falle: Viele/einige WLAN-Accespoints/-Router erlauben per Default keine direkte Kommunikation (per Broadcast) unter den Funk-Teilnehmern. D.h. die Clients sind voneinander isoliert. Kann man natürlich umschalten.
Dank Sascha habe ich durch Google die Lösung gefunden: https://wiki.pythonde.pysv.org/UDP-Broadcasts Zitat: 1 import socket 2 3 s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP) 4 s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, True) 5 s.settimeout(5) 6 7 s.sendto("hello", ("<broadcast>", 5555)) 8 try: 9 print "Response: %s" % s.recv(1024) 10 except socket.timeout: 11 print "No server found" 12 13 s.close() Wobei "hello" durch alles ersetzt werden kann. Vielen Dank euch allen
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.