Hallo! Ich möchte von einem Gerät ca. alle 0,5s eine Nachricht per MQTT an einen Mosquitto-Server senden. Die Abstände zwischen den Nachrichten müssen nicht exakt eingehalten werden, aber mehr als 1s sollten sie nicht sein. (Eine Überschreitung führt nicht zur Katastrophe, sollte aber so selten wie möglich vorkommen...) Ich habe dazu den ESP32 und einen SIM7000G ins Auge gefasst. Habt ihr Erfahrungen mit dieser Kombination? Könnt ihr mir vielleicht sagen, worauf ich achten sollte, um möglichst wenig Aussetzer zu haben? (Die Anwendung ist mobil, aber stets in einem mit Mobilfunk gut abgedeckten Gebiet...) Danke im Voraus! Pat
Pat schrieb: > Ich habe dazu den ESP32 und einen SIM7000G ins Auge gefasst. Verwende eine Übertragungsschicht, deren Latenz du selber im Griff hast. Mobilfunk gehört nicht unbedingt dazu. Wenn du es in dem Zeitraster brauchst, sende einen Zeitstempel mit. Oder überlege, ob du es wirklich so schnell brauchst.
Ein ESP01 Modul in meinem Stromzähler macht alle 1s ein Update auf der Weboberfläche, bei Tasmota lässt sich m.W.n. der MQTT Abstand aber nicht so eng einstellen.
Helmut -. schrieb: > Verwende eine Übertragungsschicht, deren Latenz du selber im Griff hast. Danke für den Tipp, leider bin ich allerdings auf das Mobilfunknetz angewiesen, da das Gebiet, das abgedeckt werden soll, einfach zu groß ist. Es muss eine ganze Stadt abgedeckt werden. Ich dachte auch schon an LORA, aber wegen der Gebäude in Kombination mit der Größe des Gebietes ist das einfach keine Option. Aber es muss doch möglich sein, über Mobilfunk innerhalb einer Sekunde etwas zu übertragen!? Man kann ja über das Mobilfunk auch telefonieren, das braucht ja viel weniger Latenz!? Rüdiger B. schrieb: > Ein ESP01 Modul in meinem Stromzähler macht alle 1s ein Update auf der > Weboberfläche, bei Tasmota lässt sich m.W.n. der MQTT Abstand aber nicht > so eng einstellen. Danke für deine Erfahrung!
Magst Du denn verraten, aus welchem Grund so eine häufige und schnelle Übertragung notwendig ist?
Das ist wie immer hier im Forum Streng geheim, jemand könnte ja die Idde klauen. Spielen wir einfach mit dem Gedanken das Radioaktivität und Position erfasst wird.
Pat schrieb: > Aber es muss doch möglich sein, über Mobilfunk innerhalb einer Sekunde > etwas zu übertragen!? Wenn du im Monat 2,7 Millionen Gespräche aufbaust oder 750 Stunden mit deiner Flatrate telefonierst, wird dir dein Anbieter den Vertrag noch vor der ersten Abrechnung kündigen. Pat schrieb: > Es muss eine ganze Stadt abgedeckt werden. Ich dachte auch schon an > LORA, aber wegen der Gebäude in Kombination mit der Größe des Gebietes > ist das einfach keine Option. Na, wenn LoRa bzw. LoRaWAN nicht genau dafür erfunden wurde.... Aber auch hier: solche Datenraten = Nö. Die Werte eine Stunde speichern und als Klotz übertragen ist keine Option? Warum bitte muss man von einem Fahrzeug aus eine Live-Verbindung haben? Das ist das Ziel von 5G (Jede Milchkanne und so), aber selbst da ist es weder Live noch Dauerhaft geplant, einfach weil das Netz das nicht hergibt.
Vielleicht ist es auch zweimal pro Sekunde ein Ultra-Hochauflösendes
Bild?
> The MQTT protocol itself defines a MQTT PUBLISH payload size limit of 256MB.
Ohne weitere Einschränkung seitens des TO:
512 Megabyte / Sekunde geht nicht über Mobilfunk. Das SIM7000G limitiert
schon bei deutlich weniger als einem Tausendstel davon.
Insofern: Nein, geht im Allgemeinen nicht. Aber vielleicht hat der TE ja
einen ganz speziellen Sonderfall, in dem es doch geht.
Sorry, dass ich das nicht gleich schrieb: ein Paket hat nur ca. 100-200 Byte, wenn man die reine Payload hernimmt... Es geht nur darum, dass die Pakete sich nicht mehr als 0,5 Sekunden verspäten sollen, also dass die Verbindung stabil bleibt.
Pat schrieb: > Aber es muss doch möglich sein, über Mobilfunk innerhalb einer Sekunde > etwas zu übertragen!? Meistens schon. Manchmal nicht. Pat schrieb: > dass die Pakete sich nicht mehr als 0,5 Sekunden verspäten Das musst du mit deinem Handynetzanbieter/Verbindungsprovider vereinbaren. Der wird dir das nicht (auch nicht für viel Geld) garantieren. Pat schrieb: > Es geht nur darum, dass die Pakete sich nicht mehr als 0,5 Sekunden > verspäten sollen, also dass die Verbindung stabil bleibt. Beschreib doch mal das Problem, und eben nicht nur deinen derzeitigen Lösungsansatz für das Problem.
:
Bearbeitet durch Moderator
Pat schrieb: > Es geht nur darum, dass die Pakete sich nicht mehr als 0,5 Sekunden > verspäten sollen, also dass die Verbindung stabil bleibt. Das kannst du im Mobilfunk Netz vergessen. Es wird nur zeitweise zufriedenstellend funktionieren.
Steve van de Grens schrieb: > Das kannst du im Mobilfunk Netz vergessen. Es wird nur zeitweise > zufriedenstellend funktionieren. Warum? Man kann doch auch über Mobilfunk Videotelefonate führen!? Wie gesagt, dass es nicht zu 100% immer klappt, das ist ganz klar. Was ich vor allem wissen möchte, ist, was ich tun kann, dass es so gut klappt wie technisch MÖGLICH. Also z.B. welche Einstellungen ich beim SIM7000G vornehmen soll, was ich in einem selbst gehosteten Mosquitto konfigurieren kann, etc., damit wirklich nur mehr die absolut unvermeidbaren Latenzen übrig bleiben. (Es gilt ja auch bei einer Verzögerung > 0,5s -> je kürzer, umso besser!) Lothar M. schrieb: > Beschreib doch mal das Problem Es sollen Datenpakete mit 100-200 ASCII-Zeichen 2x pro Sekunde von einem Fahrzeug zu einem Server gesendet werden. Dies soll insbesondere während der Fahrt (bei max. 50km/h) ebenfalls möglich sein. Es ist wichtig, dass diese Datenpakete in den meisten Fällen rechtzeitig (<0,5s Latenz) ankommen. Wenn mal nicht, dann so zeitnah wie möglich.
Ich würde das mit normalem MQTT over HTTP(S) probieren und entsprechende Zeitstempel mitschicken. Wenn man die Zeitpunkte der Messung sehr genau braucht oder die Latenz messen möchte, dann beide Seiten (Sender und Server) mit GPS-Zeit synchronisieren. Das wird dann gehandhabt wie normaler HTTP(S)-Datenverkehr wie bei einem Handy, aber wie schon geschrieben wurde, die einzelnen Pakete kommen mal schneller und mal langsamer an. Anders geht's am Ende wahrscheinlich sowieso nicht bzw. wird aufwendig und sehr sehr teuer. Man könnte sich natürlich einen eigenen Datenfunk-Kanal registrieren, mit genug Sendeleistung reicht es dann für eine Stadt... aber bezahlen will man das nicht.
Warum über http(s)? Minimiert das Verzögerungen gegenüber normalem MQTT(S)? Wie sieht es aus mit den Funkstandards? Ist zB 5G zuverlässiger, als 4G? 4G zuverlässiger als 3G bzw 2G? 4G hat ja auch noch Abstufungen mit Advanced, etc… Könnte da jemand vielleicht einen Überblick geben? So genau, dass man sogar die Uhr des Servers synchronisieren muss, muss es nicht sein. Es geht nicht um jede Mikrosekunde. Die Daten haben ohnehin einen Timestamp, das ist nicht das Problem. Es geht mehr um die Echtzeit (Abweichungen bis 1s stören wenig, darüber hinaus wird‘s unangenehm) -Beobachtung von Signalen aus dem Fahrzeug.
Pat schrieb: > Es > geht mehr um die Echtzeit (Abweichungen bis 1s stören wenig, darüber > hinaus wird‘s unangenehm) -Beobachtung von Signalen aus dem Fahrzeug. Weisst du was "Q" - ev. schaust Du auch nur zu viel James Bond?
Angehängte Dateien:
Über LTE Basisstation 1km entfernt
Pat schrieb: > Man kann doch auch über Mobilfunk Videotelefonate führen!? Ja kann man. Diese funktionieren einigermaßen zufriedenstellen, weil sie besonders priorisiert werden. Auf die Priorisierung hast du als "kleiner Mann" aber keinen Einfluss. Wenn du das Netz mal eine ganze Woche lang durch testest, bekommst du ein eigenes klares Bild. Dann musst du nicht über Vermutungen diskutieren. Ich habe das gemacht und ich kenne das Ergebnis.
Das ist doch die Lösung: Am Fahrzeug eine Kamera, die die Zeiger filmt. Das geht mit höchster Prio durchs Netz, also live wie gewünscht. Am anderen Ende ein Fernseher der das ganze anzeigt und ein RPi mit Kamera beobachtet das Bild und via KI erkennt er die Zeigerstellungen. Das kann man dann per LAN mit geringster Verzögerung als MQTT weitergeben. Problem gelöst! Oder? Komisch finde ich, das keine genaue Zeit erforderlich ist, aber Zeitstempel mitgegeben werden. Dann muss man unter einer Sekunde Latenz bleiben, sonst wirds unangenehm. Nimmt aber ein Übertragungsprotokoll und -system das vor Zuverlässigkeit kaum noch laufen kann. Das wirkt immer mehr wie eine hemdsärmelige "VW, BMW und Mercedes können das nicht, aber ich schon"-"Lösung", oder ein klassisches XY-Problem "ich will das das so geht!!!".
MQTT war für sowas nit gemacht.
Also, um da einige Unklarheiten auszuräumen: 1. Es ist wichtig, wann das Signal entstanden ist, daher der Timestamp. 2. Das Signal wird für einen bestimmten Zweck live verarbeitet (daher das Verzögerungslimit) und für einen bestimmten anderen Zweck später, das ist zeitunkritisch. 3. Es ist wichtig, dass das Signal so gut wie möglich mit einer Verzögerung von höchstens 0,5s-1s ankommt. Wenn mal nicht, ist's nicht so schlimm, solange das selten ist. --------------------------------------------------------------- Ich habe heute einen ersten Test gemacht und bemerkt, dass es zuallermeist gut läuft, ab und an (ca. 1-2 Mal pro Stunde) jedoch Nachrichten erst ca 5-8 Sekunden später eintreffen (dann aber alle auf einmal). Wodurch kann das verursacht werden? (Der Test war noch statisch am Fensterbrett) Wäre das mit MQTT over HTTP besser?
Also sorry... aber solange Du mir nicht plausibel erklärst, zu welchem Zweck diese Messwertblöcke zeitkritisch innerhalb von 0,5s ankommen müssen, bin ich raus. Ich werde Dir mir den bereits rausgerückten Informationen alleine auch gar nicht weiter helfen können, denn > Ich habe heute einen ersten Test gemacht und bemerkt, dass es > zuallermeist gut läuft, ab und an (ca. 1-2 Mal pro Stunde) jedoch > Nachrichten erst ca 5-8 Sekunden später eintreffen > (dann aber alle auf einmal). ist genau was ich erwartet hatte bzw. ich hätte angenommen, daß diese Hiccups noch deutlich öfter vorkommen. Erst recht wenn die Daten von einer Karre übermittelt werden sollen, die sich durch eine Stadt bewegt. Stichworte Netzlast und Funkzellenwechsel. Den eigenen Datenfunkkanal auf einer zugewiesenen Frequenz möchtest Du ja nicht... das ist dann natürlich Pech.
Was genau übertragen wird ist doch irrelevant. Es sind 100-200 ASCII-Zeichen, die zeitnah von einem fahrenden Straßenfahrzeug bei max 50km/h zu einem Server müssen. Mehr Info braucht man doch nicht, um das eigentliche Problem zu diskutieren. Wenn ihr mir nicht helfen wollt, sagt es einfach. Ich habe gedacht, wir können uns austauschen. Ich hätte auch meine Ergebnisse hier mitgeteilt. Dann könnten andere auch was davon haben. Aber ich war wohl zu optimistisch, dass soetwas möglich ist. Noch vor einigen Jahren hat man hier echt Hilfe bekommen. Seht euch mal StackOverflow an. Es steht dort die Frage und darunter die Antwort. Keiner schreibt, man solle doch eine Uhr filmen und per Video übertragen. Und niemand jammert, dass nicht das ganze Programm, sondern nur der relevante Teil hochgeladen wurde. So bekommt man auch Hilfe, wenn man nicht sein ganzes Projekt der Öffentlichkeit vorstellt oder gar zur Verfügung stellt. Es wird einfach geholfen und Hunderttausende können dort ihre Problemchen nachschlagen, die sie beim Programmieren haben. Die fragen dann nicht mehr. Soetwas bräuchte man auch für Elektrotechnik. Ich bin enttäuscht.
:
Bearbeitet durch User
GRRRRRRRRRR **keyboard abbeiß** > Was genau übertragen wird ist doch irrelevant. Stimmt. Mir ist egal WAS Du da übertragen willst. Ich hätte gerne gewusst WARUM bzw. warum das so zeitkritisch ist. > Mehr Info braucht man doch nicht, um das > eigentliche Problem zu diskutieren. Mein Problem ist, daß ich Dein Problem nicht verstehe. Ich kann nicht einschätzen, ob eine zeitkritische Übertragung über irgend einen Internet-basierten Kanal wirklich erforderlich ist, oder ob man eine Lösung finden kann, die weniger zeitkritisch ist, so daß dieser Übertragungsweg ausreichend gut funktioniert. > Wenn ihr mir nicht helfen wollt, sagt es einfach. Kommt jetzt die Heulsusen-Nummer? Vergisses! **Schrotflinte durchlad** > Ich hätte auch meine Ergebnisse hier mitgeteilt. > Dann könnten andere auch was davon haben. Wenn es ein so offenes Projekt ist, wieso kannst Du dann nicht offenlegen, was Du vor hast? Ist es so geheim? Hängt für Dich eine größere Geldmenge dran? Kleiner Tip, die Wichtigkeit eigener Projekte für andere wird sehr oft massiv überbewertet. Ich kann mir z.B. nichts vorstellen, wofür ich jetzt gerade eine zeitkritische Übertragung irgendwelcher Messdaten aus meinem Auto besonders dringend brauchen würde. Ich wüsste daher auch nichts, wieso ich Dir eine Idee oder was immer Du das hast "klauen" sollte. > Aber ich war wohl zu optimistisch, dass soetwas möglich ist. > Noch vor einigen Jahren hat man hier echt Hilfe bekommen. **augenroll** > Seht euch mal StackOverflow an. Es steht dort die Frage und > darunter die Antwort. Na dann geh zu StackOverblow und poste Deine Anfrage dort genau so, wie Du sie hier gepostet hast. Der Tag ist ja noch jung, heute abend will ich die Antwort sehen. Viel Glück! > Keiner schreibt, man solle doch eine Uhr filmen > und per Video übertragen. Habe ich auch nicht. > Und niemand jammert, dass nicht das ganze Programm, sondern nur > der relevante Teil hochgeladen wurde. So bekommt man auch Hilfe, > wenn man nicht sein ganzes Projekt der Öffentlichkeit vorstellt > oder gar zur Verfügung stellt. Dann haben die es wahrscheinlich geschafft, genug benötigte Information zur Verfügung zu stellen oder das Projekt offengelegt, wie es zur Nutzung der Schwarmintelligenz manchmal erforderlich ist. Ich kann Deine Sorgen ja verstehen, ich bin auch kein Fan davon und ich möchte Dich auch nicht überreden, irgendwas offenzulegen (ehrlich gesagt, so sehr interessiert es mich noch nicht mal persönlich, ich habe genug andere Projekte, die ich erstmal fertig kriegen muss). Aber wenn ich bei einem Problem nicht weiterkomme, dann geht's manchmal nicht anders und dann lege ich es auch offen. Oder ich gebe es einem Freund, der mit der Thematik (bei mir z.B. Mechanik, ganz besonders Feinmechanik) besser klarkommt als ich. Sicherlich kommen bei einem Forum dann Stimmen wie "na das ist ja lame" oder "wozu brauchst du sowas, niemand will sowas haben" und Argumente wie "weil ich es schön finde" oder "ich will wissen wie das funktioniert" stoßen auf wenig Gegenliebe - aber wenn nur einer dabei ist, der hilft, dann hat es sich schon gelohnt. Gerade dieser Fall ist in diesem Forum sehr häufig, hat leider mit dem Aussperren von Gästen etwas abgenommen, aber meistens findet sich irgend eine einzelne Person, die das Problem sehr zufriedenstellend für ein "danke dir" lösen kann. Mach Dir mal Gedanken drüber, oder gib ein (gutes!!, bitte nicht mit viel Rätsel raten) Beispiel für ein vergleichbares Projekt oder Anwendungszweck. Dann kannst Du Deines geheim halten. Also warum muss die Bereitstellung einer Information aus einer mobilen Quelle auf einem MQTT-Server so dermaßen zeitkritisch erfolgen. > Es wird einfach geholfen und Hunderttausende können dort ihre > Problemchen nachschlagen, die sie beim Programmieren haben. Wie gesagt, dann mach das doch. Du hast aber kein Problemchen beim Programmieren (z.B. wie man eine double precision floating point division auf einer 8 Bit CPU hinkriegt könnten Dir hier viele sofort erklären), sondern Du hast ein Infrastruktur-Problem. Dir steht kein Datenkanal mit ausreichend geringer Latenz und gleichzeitig hoher Zuverlässigkeit zur Verfügung. Es gibt nun zwei Wege, das Problem anzugehen: Entweder man schafft sich so einen Datenkanal - das halte ich für eher schwierig bzw. sehr aufwendig (Funk) oder teuer (kommerzieller Funk) - oder man sucht eine Möglichkeit, die ohne eine derart schnelle bzw. höchst zuverlässige Verbindung auskommt. Wenn es die Datensätze hergeben (z.B. beim GPS-Tracking eines Autos oder bei einer Temperaturüberwachung), könnte man aus vorangegangenen Datensätzen z.B. versuchen, zukünftige Datensätze vorauszuberechnen und diese so lange anzunehmen, bis sie von mit Zeitstempel eintreffenden realen Datensätzen korrigiert werden (und eine neue Vorausberechnung angestoßen wird). Oder lässt sich der MQTT-Server mobil am Ort der Datenquelle betreiben? Dann verschiebt sich die Verbindungslatenz-Problematik zur weiteren Datenverarbeitung, zwischen Datenquelle und MQTT-Server ließe sich dann eine sehr gute (weil kurze) Verbindung herstellen. Aber leider sind solche Überlegungen komplett hinfällig weil man nicht weiß worum es bei Deinem ach so großartigen Geheimprojekt geht, ob so ein Ansatz dabei möglich ist oder ob man doch was ganz anderes braucht und ich jetzt wieder nur 'nen dummen Spruch von Dir bekomme, daß ich mit meiner Vermutung der Echtzeitüberwachung der Auspufftemperatur Deines Elektroautos leider daneben gelegen habe. > Die fragen dann nicht mehr. Soetwas bräuchte > man auch für Elektrotechnik. Eine große Tüte Mitleid. Schade, habe ich gerade keine mehr da. > Ich bin enttäuscht. Ich auch. Da probiert man zu helfen und dann kommt sowas hier. Aber kennt man ja nicht anders. Und nein, ich will kein Mitleid dafür, ich überlebe in diesem Forum schon jahrelang ohne. Man gewöhnt sich (leider) an alles.
Pat schrieb: > Was genau übertragen wird ist doch irrelevant. Es sind 100-200 > ASCII-Zeichen, die zeitnah von einem fahrenden Straßenfahrzeug bei max > 50km/h zu einem Server müssen. Mehr Info braucht man doch nicht, um das > eigentliche Problem zu diskutieren. Weißt Du, hier schlagen ziemlich häufig Menschen auf, die zwar keine Ahnung haben, wie sie etwas machen sollen, sich aber schon sehr fest auf eine ganz bestimmte Teillösung festgelegt haben. Vermeintlich haben sie alles andere bereits gelöst, nur dieser eine kleine Teil... also... Dabei stellt sich bei näherem Hinterfragen oft heraus, daß nicht nur diese eine Teilaufgabe, sondern schon der ganz grundsätzliche Lösungsansatz eher suboptimal ist, und die ungelöste Teilaufgabe bei einem anderen Ansatz gar nicht notwendig wäre. Insofern wäre es sicherlich sinnvoll, wenn Du etwas präziser ausführen könntest, was Du eigentlich vorhast. > Wenn ihr mir nicht helfen wollt, sagt es einfach. [...] > Ich bin enttäuscht. Und Du glaubst wirklich, es würde irgendwen weiterbringen, wenn Du denen, die Dir helfen sollen, zuerst Informationen vorenthältst und Dich dann bitterlich über deren angeblich mangelnde Hilfsbereitschaft beklagst?
Mich irritiert die Widersprüchliche Angabe zur benötigten Übertragungszeit: > Wenn mal nicht (innerhalb 0,5s-1s ankommt), ist's nicht so schlimm, > solange das selten ist. Und direkt danach schreibst du im selben Beitrag: > bemerkt, dass es zuallermeist gut läuft, > ab und an (ca. 1-2 Mal pro Stunde) jedoch Nachrichten erst > ca 5-8 Sekunden später eintreffen 1-2 Mal pro Stunde ist doch selten, oder nicht? Oder sind dir die 5-8 Sekunden (selten) zu viel. Vielleicht drückst du dich mal eindeutig aus, was du wirklich brauchst.
:
Bearbeitet durch User
Die Anforderungen sind ueberzogen, nicht bezahlbar. Ein konzeptueller Furz. Reich Details rueber. Wir sortieren dann raus, wie man's machen sollt.
:
Bearbeitet durch User
Ich stelle mir gerade vor das du 8 Stunden lang die sekündlichen Daten beobachtest.
Da ist dann eine Echtzeit Auswertung dahinter. - Wenn der Wagen fuer eine Sekunde von der Route abweicht, wird er .. abgebremst und blockiert, verriegelt, allenfalls selbstzerstoert. - Es werden alle kommenden Ampeln immer auf .. rot oder gruen geschalten - Ein Angestellter ueberwacht jeden Datensatz Alles nicht-Echtzeit-, kann eigentlich im Auto aufgezeichnet werden Alles Echtzeit- kann eigentlich im Auto selbst ablaufen Autos verfolgen wie im Film .. aber ja doch. Allerdings kann das Watsup schon von selbst
:
Bearbeitet durch User
Pat schrieb: > Seht euch mal StackOverflow an. Es steht dort die Frage und darunter die > Antwort. Für viele Fragen ist Stackoverflow tatäschlich der bessere Ort. Dort reicht es, wenn man eine abstrakte und kontextunabhängige Frage stellt, solange sie einigermaßen präzise ist. Dann gibt es auch eine ebenso präzise Antwort auf diese Frage. Diese Sensationsgier, den TE erstmal für blöd erklären und ihn sich bis auf die Unterhose nackig machen zu lassen, das gibts da tatsächlich nicht. Ich denke nicht dass du hier sämtliche Details liefern musst, aber ein bisschen Quantifizierbares (wie oft sind Ausfälle in welcher Länge OK?) sollte noch kommen. Mit deinen Angaben würde ich nämlich der Meinung von Steve anschließen und auch sagen es passt wie es ist. Steve van de Grens schrieb: > 1-2 Mal pro Stunde ist doch selten, oder nicht? Oder sind dir die 5-8 > Sekunden (selten) zu viel.
:
Bearbeitet durch User
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.