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...)
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.
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!?
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.
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.
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.
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.
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!)
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.
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!!!".
Es ist wichtig, wann das Signal entstanden ist, daher der Timestamp.
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.
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)
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.
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.
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?
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
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 im Beitrag #7539793:
1-2 Mal pro Stunde ist doch selten, oder nicht? Oder sind dir die 5-8
Sekunden (selten) zu viel.
