MQTT Broker: Daten sammeln?

[Bot N. (botnec)]

Versuche mich gerade mit MQTT anzufreunden und habe schon einiges dazu 
gelesen. Was ich aber noch nicht verstanden habe, ob ein MQTT Broker 
Daten sammeln kann wenn ein Subcriber momentan nicht da ist. Gehen nicht 
weitergeleitet Daten verloren oder können diese (in Grenzen) 
zwischengespeichert werden?

[Mario M. (thelonging)]

Nennt sich "Retained Messages". Muss aber vom Sender veranlasst werden.

[Joachim S. (oyo)]

Nein, ein MQTT-Broker sammelt keine Daten. Das einzige, was geht, ist:

Wenn man eine MQTT-Nachricht mit dem "retain"-Flag verschickt, dann wird 
diese zwischengespeichert - und ein Subscriber, der in dem Moment, in 
dem diese Nachricht verschickt wurde nicht verbunden war, würde diese 
trotzdem erhalten, wenn er sich später verbindet.

ABER: Das funktioniert nur mit der jeweils LETZTEN Nachricht auf dieser 
Topic.
Sprich: Wenn in der Zeit, in der ein Subscriber verbunden war, 10 
Nachrichten mit dem "retain"-Flag auf Topic XY gepublisht wurden, dann 
würde der Subscriber, wenn er sich danach wieder verbindet, trotzdem nur 
die letzte dieser 10 Nachrichten erhalten.

[Bot N. (botnec)]

OK, danke sehr. So was habe ich vermutet.

[Rainer W. (rawi)]

Bot N. schrieb:
> Gehen nicht weitergeleitet Daten verloren oder können diese (in Grenzen)
> zwischengespeichert werden?

Es hindert dich niemand daran, einen Datenlogger aufzusetzen, der sich 
auf alle interessierende Topics bei MQTT-Server registriert und dann die 
Daten loggen kann, wenn der Server sie ihm schickt.

[Ein T. (ein_typ)]

Rainer W. schrieb:
> Es hindert dich niemand daran, einen Datenlogger aufzusetzen, der sich
> auf alle interessierende Topics bei MQTT-Server registriert und dann die
> Daten loggen kann, wenn der Server sie ihm schickt.

Es ging doch darum, keine Nachrichten zu verlieren. Wenn der Datenlogger 
die Daten nicht rechtzeitig abrufen kann, geschieht jedoch genau das.

Eine Lösung wäre, anstelle eines MQTT-Broker eine persistierende Message 
Queue wie Apache Kafka, RabbitMQ oder HiveMQ einzusetzen. Wenn ich das 
richtig sehe können HiveMQ und RabbitMQ auch MQTT sprechen und die 
Nachrichten persistieren -- keine Ahnung, ob beides zusammen möglich 
ist, Versuch macht kluch.

Meine Lösung für solche Aufgaben sind Redis-Listen. Die sind schnell 
weil In-Memory, mit den Befehlen [RL]POP und [RL]PUSH können LIFO- und 
FIFO-"Queues" realisiert werden, mit den [RL]MOVE und 
[RL]POPLPUSH-Befehlen auch Listen mit gerade bearbeiteten Datenpunkten 
bauen und dadurch abfedern, wenn ein Client während der Verarbeitung 
abstürzt.

Neben seinen Vorzügen hat Redis allerdings auch einen Nachteil: solange 
die Nachrichten nicht abgerufen worden sind, liegen sie im 
Arbeitsspeicher. Das wird bei zu wenig freiem Arbeitsspeicher 
problematisch, wenn Clients oder Netzwerkverbindungen ausfallen, oder 
Nachrichten schneller ankommen, als die Clients bzw. ihre 
Netzwerkverbindungen sie verarbeiten.

[Rainer W. (rawi)]

Ein T. schrieb:
> Wenn der Datenlogger die Daten nicht rechtzeitig abrufen kann,
> geschieht jedoch genau das.

Wenn der Broker nicht läuft, kann niemand Daten abrufen. Wenn die 
(Zwischen-)Speicherung der Daten nicht funktioniert, kann niemand Daten 
(zwischen-)speichern. Also muss man dafür sorgen, dass Broker und 
Datenlogger laufen - ganz einfach.

[N. M. (mani)]

Man könnte natürlich auch auf ein Konstrukt kommen wo jeder Publisher 
nicht nur einen Einzelwert sondern ein ganzes Array an Messwerten hält 
und publisht.
Dann könnte eine Zeit von (n-1)*fs überbrückt werden ohne etwas zu 
verlieren.

[Le X. (lex_91)]

N. M. schrieb:
> Man könnte natürlich auch auf ein Konstrukt kommen wo jeder Publisher
> nicht nur einen Einzelwert sondern ein ganzes Array an Messwerten hält
> und publisht.
> Dann könnte eine Zeit von (n-1)*fs überbrückt werden ohne etwas zu
> verlieren.

An und für sich eine akzeptable Idee, aber das funktioniert halt nur in 
Szenarien wo man jeden MQTT-Knoten selbst in der Hand hat.

[Oliver R. (superberti)]

Hi,

ich benutze seit vielen Jahren ein kleines Python-Skript, welches sich 
beim Broker für die Sensordaten anmeldet und dann die Daten in eine 
InfluxDB speichert (lokal oder auch auf einem VServer im Netz).

siehe:

https://github.com/Superberti/wetterstation/blob/master/raspi/MQTTNeelixBridge.py

Auf dem VServer läuft auch noch eine Grafana-Instanz, mit der man die 
gespeicherten Daten sehr hübsch darstellen kann.
Für mich die perfekte Lösung.