Hallo, ich muß eine IoT-Verbindung aufbauen, in der im Prinzip 1kB-Pakete bidirektional versendet werden müssen. Also einmal Meßwerte, ziemlich viele im eine Richtung. Steuerbefehle oder auch Einstellungssets in die andere Richtung. Aber eben auch man ein paar hundert oder tausend solcher 1kB-Pakete zum Firmwareupdate, bzw Auslesen eines Datenloggers. Welches Protokoll wäre da das am wenigsten ungeeignete?
Thomas V. schrieb: > Welches Protokoll wäre da das am wenigsten ungeeignete? Das, dass deinen Ansprüchen genügt. Was bedeutet bei dir IoT? LTE? LoRaWAN? NB-IoT? WLAN? GSM? LoRa ohne WAN? SPE? Ist es ein LAN oder ein WAN? Wie sieht es mit Sicherheit (Verschlüsselung, Signierung) aus?
:
Bearbeitet durch User
Mir geht's insbesondere ums Internet. LoRa, LTE oder GSM sind da zumindest wenig interessant. WLAN dagegen sehr, LAN durchaus denkbar. Sprich, die Steuerung ist über eine Schnittstelle im WLAN, bzw. Ethernet. Darüber soll zugeriffen werden(von PCs, Handys etc.). Sowie über einen Router und das Internet auch aus der ferne. Meine Frage geht zunächst auch um den grundsätzlichen Weg. MQTT ist wohl eher weniger geeignet, zumindest wenn es um größere Datenmengen geht. Es hat aber eben den Charme eines verbreiteten Standards. Nun wäre die Frage, ob man sowas mit einem anderen, vielleicht ähnlich verbreiteten Standard machen kann, der aber die Datenmengen überträgt. Oder wäre es sinnvoll, zu trennen. Heißt, eine normale Meßwertübertragung/Fernsteuerung via MQTT und größere Datenmengen über einen anderen Weg.
Ist auch ein Frage was auf beiden Seiten steht. Falls die Daten als Files uebertragen werden kommen die zB ueber TCP heil an, ueber UDP nicht Daher ist die erste Frage ist die vollstaendige Uebertragung wichtig ? Was ist die Moeglichkeit von Unterbrechungen, was ist die Wahrscheinlichkeit von Unterbrechungen. Bei Filetransfers ist die Vollstaendigkeit wichtig, wie lange es auch immer geht. Bei Audio, oder video darf ein Frame ausfallen, wichtig ist dass die Daten zeitnah kommen. Wie ich sagte ist TCP sicher, mit retries, UDP ist schnell Dann muesst man noch wissen wie's mit Sicherheit steht. Muss alles verschluesselt gehen ? Firmware muss wahrscheinlich sicher und vollstaendig sein, Messdaten vielleicht, vielleicht auch nicht. Denkbar ist auch alles als Webseite und Upload laufen zu lassen, dann were die Verschluesselung schon gemacht.
Ich würde das als REST-API per http(s) machen. Zumindest solange, bis mehrere "Messgeräte" oder auf MQTT ausgelegte Abonnenten geplant sind. Verbindung ist vmtl. schnell, Performance für Client-Anfragen vmtl. auch ausreichend. Konfiguration wird bei nur 1 Gerät durch MQTT auch nicht leichter. Bei MQTT bräuchtest halt noch den Broker. Für Logfiles und Firmwareupdates is es auch nicht gedacht.
Thomas V. schrieb: > MQTT ist wohl eher weniger geeignet, zumindest wenn es um größere > Datenmengen geht. Ich programmiere neue Firmware auf meine Knoten, indem den Inhalt der Intel-Hex-Datei über MQTT an eine MQTT-CAN-Brücke sende, dort parse, und dann binär über CAN an den Bootloader des Knoten schicke. Diese Hex-Dateien sind so zwischen 50k und 250k groß. Das MQTT-Protokoll hat damit keine Probleme; immerhin setzt es auf TCP auf. Allerdings musste ich dazu (weil meine MQTT-CAN-Brücke zu wenig RAM-Speicher für eine komplette solche Datei hatte) die Arduino-Bibliothek pubsubclient um die Möglichkeit des asynchronen Empfangs erweitern. LG, Sebastian
Das klingt interessant. Zumindest, was Firmeware-Updates angeht, ist das bis jetzt bei 350kB, Tendenz steigend. Wenn ich wenigstens erst mal das hätte, wär ich schon einen großen Schritt weiter. Wenn ich das jetzt richtig intertretiere, nimmst Du die Daten aus dem MQTT mit einem ESP oder sowas an und schiebst sie dann über den CAN wieder aus? So ähnlich wär's ja bei mir auch. Ich würde das über einen ESP machen wollen, der dann über RS232/485 an die Steuerung(en) weiterreicht. Den ESP würde ich zunächst auch so wählen, dass er genug Speicher zum Zwischenspeichern hat. Das hieße also, man kann von einem Client via Broker solche Datenmengen über das MQTT schicken! Gibt's da ein Stichwort, nach dem ich nach was zum Lesen googeln kann? Ich hab noch kein MQTT gemacht, bis jetzt aber nur von den Topics gelesen und die dürften dafür doch sicher nicht ausreichend sein, denke ich. Dann müßte es noch etwas anderes geben.
Vielen Dank an alle, die mir zu helfen versuchen! Man möge meine Unwissenheiten verzeihen aber wie realisiere ich einen Upload per HTML?
Thomas V. schrieb: > aber wie realisiere ich einen > Upload per HTML? per POST-methode. https://wiki.selfhtml.org/wiki/File_Upload oder du programmierst einen UNIX-Socket, der auf Port XXXX hört und alles schluckt, was dort ankommt. Damit kannst Du auch json, csv oder dergleichen verwenden.
Als erstes solltest du mal überlegen welche Endgeräte wie zugreifen sollen (VPN, offene Ports, Cloud, ...). Und was dort an Frontend notwendig ist. Und welche Daten du übertragen anzeigen verarbeiten möchtest. Irgendwelche MQTT-Viewer werden nur gängige Messages verarbeiten können. Wenn das bei dir - wie ich vermute - nicht der Fall ist kannst du ohne selbstentwickeltes Frontend auf Handy und PC erst mal wenig damit anfangen. Dann darfst du auf deinem "Messgerät" MQTT-Nachrichten an den Broker schicken und für die Endgeräte entsprechende MQTT-Apps entwickeln oder auf dem Broker ein Webfrontend basteln.
Angehängte Dateien:
-
t5_mqttexplorer_firmware.png
120 KB
Thomas V. schrieb: > Das hieße also, man kann von einem Client via Broker solche Datenmengen > über das MQTT schicken! Ja. Und das Tooling rund um MQTT verarbeitet das auch. Anbei ein solcher Firmwaretransfer wie er bei mit im MQTT Explorer aussieht. Die MQTT-Spezifikation definiert die maximale Größe eine MQTT-Übertragung durch den Maximalwert des Längenfelds, der 268435455 beträgt (https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html: "[...], no limit on the packet size is imposed beyond the limitations in the protocol as a result of the remaining length encoding and the protocol header sizes"). Thomas V. schrieb: > Ich hab noch kein MQTT gemacht, bis jetzt aber > nur von den Topics gelesen und die dürften dafür doch sicher nicht > ausreichend sein, denke ich. Bei MQTT ist das Topic sozusagen der Variablenname, und der Inhalt der Variablen wird Payload genannt. Im obigen Beispiel lautet das Topic t5/firmware/22472/flash, und die Payload enthält die 200kB des Intel-Hex-Text der Firmware. LG, Sebastian
:
Bearbeitet durch User
Ganz vielen herzlichen Dank für's erste. Ich habe jetzt erst mal ein paar Fährten, auf denen ich versuche, mich etwas tiefer einzulesen. Wird ein bißchen dauern. Zumal hier gerade wieder ein Anruf kommt "Wir brauchen bis nächste Woche ...." Ich versiche die zwei Tipps des Uploads mit HTML und der längeren Playloads in MQTT zu verinnerlichen und würde mich dann wieder melden. Nochmals vielen Dank, Ihr habt mir erstmal weitergeholfen!
Thomas V. schrieb: > IoT-Verbindung Eine “IoT-Verbindung” ist eine Verbindung zwischen physischen Objekten, die mit Sensoren, Software und anderen Technologien ausgestattet sind, um sie mit anderen Geräten und Systemen zu verbinden und Daten auszutauschen 123. Das Internet of Things (IoT) ist ein Netzwerk von solchen physischen Objekten, die miteinander verbunden sind, um Daten auszutauschen 1. Es gibt viele Anwendungen für IoT-Verbindungen, wie z.B. intelligente Haushaltsgeräte, vernetzte Autos, intelligente Städte und vieles mehr 123. Hehehe, willst Du uns auf den Arm nehmen?
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.