Welches Protokoll?

OP (Firma: Vollmar Elektronik) #7592119
Lesenswert?

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?

OP (Firma: Vollmar Elektronik) #7592246
Lesenswert?

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.

#7592269
Lesenswert?

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.

#7592291
Lesenswert?

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.

#7592321
Lesenswert?

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

OP (Firma: Vollmar Elektronik) #7592382
Lesenswert?

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.

#7592416
Lesenswert?

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.

#7592418
Lesenswert?

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

Angehängte Dateien:
OP (Firma: Vollmar Elektronik) #7592575
Lesenswert?

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!

(Firma: Papier & Knalltüten Manufaktur) #7592710
Lesenswert?

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?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren