MQTT

[truckl]

Wie in der Diskussion unter Features angeregt möchte ich hier kurz eine Verbesserung vorschlagen:

Ich fände das auch praktischer und hatte das Kevin schon gefragt.
Es verbraucht aber wohl etwas mehr Ressourcen auf dem kleinen RPI und deshalb hat er es flach aufgebaut.

Wenn es um Resourcenverbrauch geht fällt mir auf, daß die derzeitige Lösung für jeden einzelnen MQTT publish (also alle 10 Sekunden zwischen 5 und allen topics - je nachdem wieviel Werte sich geändert haben) die Command-Line von "mosquitto_pub" aufruft.
Dadurch wird jedes mal eine neue TCP-Verbindung zum Broker aufgebaut!

Das vergeudet zwar keine Resourcen im User-Space aber der TCP/IP Stack des RPI dürfte damit schon beschäftig sein. Selbst wenn es über das Loopback-Interface geht läuft da jedes Mal der komplette TCP handshake beim Aufbau und beim Abbau ein reset mit potentiellem Linger (siehe z.B. hier) des TCP-Sockets.
Weil ich denke, daß das nicht sein muß, hab ich dazu bereits einen Pull-Request als Verbesserungsvorschlag gestellt, der das Publish aller Topics via Python innerhalb einer einzigen Client-Connection macht.

In dem Python-Script zum Publish könnte man auch recht problemlos JSON-'Formatierung einbauen und einen Timestamp hinzufügen wie in dem oben schon zitierten Feature-Request angregt.
Auf der Client-Seite (Web, etc.) wäre der Aufwand die Auswertung von JSON einzubauen natürlich deutlich höher.
Aber MQTT steckt in OpenWB ja noch in den "Anfängen". Wäre es da nicht besser das vielleicht gleich noch aufzugreifen bevor dann später inkompatible Interface-Änderung in offiziellen Releases dagegen sprechen?

Versteht das bitte als konstruktive Punkte bei denen es nach meiner Erfahrung Probleme geben kann oder wo ich denke man könnte OpenWB noch besser machen als sie eh schon ist. Und wo immer ich mit meinen Kenntnissen (bin eher in C#, C++ und ein wenig Bash "zu Hause", aber leider nicht in Javascript und PHP) weiter komme, mache ich das gerne auch in Form von Pull-Requests bei denen die "Arbeit" schon gemacht ist.

Falls also doch noch JSON-Formatierung mit Timestamp kommen kann/darf, würde ich die Server-Seite (publish) dazu übernehmen.
Wenn man dabei etwas wie

Code: Alles auswählen

{
    "Timestamp": "2019-11-17T17:02:00+01:00",
    "Value": "1234.5"
}

nutzen würde, wäre auch auf der Client-Seite ein Ansatz denkbar bei dem die Bedeutung des Wertes nach wie vor nur über das MQTT-Topic definiert wäre und der Wert durch eine einzige, generische Parser-Methode zurückgeliefert werden könnte.
Dennoch hätte man volle Flexibilität zukünftig auch noch weitere Daten die direkt mit einem Wert verknüpft sind hinzuzufügen (denkbar wären hier z.B. erlaubte Bereiche/Min/Max-Werte für GUI Elemente).

[c2j2]

Zum "Neuanfang" mit MQTT:

Dürfte ich auch zu Bedenken geben, die Namen der Variablen (mal mit Kleinbuchstaben, mal Großbuchstaben, mal "%" vorn, mal mit Einheit, mal ohne, mal mit Einheit vorn und hinten ("ADirectModeAmps"), mal nur Einheit ("W"), mal mit Variablentyp ("boolDirectModeChargekWh"), mal ohne, mal in Gegenwart ("WhExportNr2"), mal Vergangenheit ("WhExported"), ...) zu "bereinigen"?

Es klingt trivial, aber es ist wirkt absolut wenig professionell (ich bin schon seit fast 40 Jahren mit Software-Erstellung beschäftigt), und so was kann sich schon mal entwickeln, aber wenn hier ein (MQTT)-Neuanfang passiert und die Namen eh neu vergeben werden können, sollte man die Gelegenheit nutzen. Je später, desto mehr Leute ärgert man.

Einfach Beschreibung des Zustands/Werts mit konsistenter Schreibweise, Einheit hinten dran? Oder egal was, aber bitte einheitlich.

[openWB]

@c2j2
Du meinst die, die in den Einstellungen konfigurierbar ist?
Noch nicht.
a)Ansonsten wird erstmal geprüft ob diese zwischen 6 & 32 A liegt um gültig zu sein
b)Nein, wird verworfen wenn ungültig
c)Das ist ein String, entweder "--" wenn nicht geladen wird/nicht benötigt, "xx Min" oder "x H xx Min"

Und recht hast du, ich gehe nochmal durch die Namen durch.

@truckl
Danke für den PR, die Änderung macht Sinn bzgl des publishen.

Ich bin allerdings gegen das "verJSON" der Daten.
Die Payload ist rund Faktor 10 höher mit minimalem Mehrwert. Einen Timestamp in separatem Topic ist allerdings in Ordnung. Gerne auch die Uptime.
Grundsätzlich ist immer davon auszugehen das der erhaltene Wert der aktuellste / gültige ist.
Das ist im LAN absolut egal. Nicht aber unbedingt wenn die Bandbreite dünn wird.
Mit MQTT haben wir ein schlankes Protocol, hier JSON drumrum packen würde bedeuten alles zu (de-)encodieren, mehr Daten zu verschicken, für wenig Mehrwert. Oder bitte darlegen was es rechtfertigt den Aufwand zu betreiben (separater Timestamp vorausgesetzt.

Diesen habe ich nun mal als openWB/system/Date bzw. openWB/system/Timestamp hinzugefügt.
Was wird präferiert?


@andreas_n
ich habe schlicht mal $(uptime) in "openWB/system/uptime" hinzugefügt. Dann kriegst da auch gleich die Load mit.

[truckl]

Die Payload ist rund Faktor 10 höher mit minimalem Mehrwert.

Ich verstehe die Argumentation mit dem Datenvolumen durchaus. Das ist klar höher.
Auf der anderen Seite: Es bleibt pro Topic immer noch ein Datenstrom von nur ein paar hundert Byte. Und was ist das heute schon?
Einzig wenn man getaktete Verbindungen zu Grunde legt (Mobilfunk) ist solch extreme Datensparsamkeit vielleicht ein Punkt. Dann aber würde vermutlich mehr eingespart wenn z.B. schlichtweg seltener oder nur wirklich nötige Topics gepublished würden. Das wäre dann aber ein Feature request "Publish-Intervall konfigurierbar machen". Topic-Filter kann schon jetzt einfach mit der MQTT-Bridge-Konfiguration erreicht werden.

Den Teil des Satzes mit dem "minimalen Mehrwert" teile ich so nicht. Ich denke einzelne Werte haben ohne Zeitstempel überhaupt keinen Sinn ... naja, das ist vielleicht übertrieben ausgedrückt ... was ich meine:
Veränderliche Daten (Ströme, Spannungen --> Leistungen, Zählerstände, ...) haben ohne Zeitstempel nur Wert wenn es reicht zu wissen daß es der "neueste verfügbare" Wert ist.

Aber der Vorteil von MQTT ist doch gerade daß es ein Quasi-Standard im IoT-Bereich ist.
So könnte von Alexa-Skins über InfluxDB-Anbindung oder SmartHome-Plugins alles mögliche entwickelt werden (Dinge die mir gleich als "nice to have" eingefallen sind als ich las, daß OpenWB MQTT kann). Oder gar irgendwelche weiterführenden Applikationen (auf deren Ideen zum jetzigen Zeitpunkt noch gar niemand gekommen ist). Alles Dinge welche die Akzeptanz von OpenWB als Plattform und so (hoffentlich) auch den Umsatz von snaptec erhöhen würden.
Grundvoraussetzung dafür ist allerdings daß die Information von der OpenWB so stichhaltig wie möglich ist. Denn was mache ich z.B. mit der Information eines Zählerstandes wenn ich nicht weis von wann der ist. Damit fällt der Wert für einzelne Einsatzzwecke komplett aus.
Außerdem sollte sich natürlich das Interface nicht ständig (inkompatibel) ändern damit Entwickler Planungssicherheit haben. Also denke ich "besser jetzt noch an die Zukunft denken als später inkompatible Änderungen riskieren" (und so potentielle Kunden vergraulen?).

Leider hilft es nicht, daß die OpenWB den aktuellen Zeitstempel in ein separates Topic published. Immerhin wird ja nicht jedesmal jedes Topic gepublished sondern nur bei Änderung der Werte. Der Zeitstempel hat also generell keine direkte Aussagekraft für den Zeitpunkt zu dem ein einzelner Wert gemessen wurde.

Bitte diese Aussage aber nun nicht dahingehend interpretieren daß dieses "Timestamp"-Topic gar nichts bringt. Für einzelne Zwecke hilft es durchaus und ich finde es gut daß es da ist.

Diesen habe ich nun mal als openWB/system/Date bzw. openWB/system/Timestamp hinzugefügt.

Ich glaub ich würde "openWB/system/Timestamp" bevorzugen. Aber nur, weil der Namen dann eher dem entspricht was drin ist (nämlich ein Date _und_ eine Time, könnte also auch noch "DateTime" heißen). Bessere Argumente dafür oder dagegen finde ich nicht

[c2j2]

@c2j2
Du meinst die, die in den Einstellungen konfigurierbar ist?
Noch nicht.
a)Ansonsten wird erstmal geprüft ob diese zwischen 6 & 32 A liegt um gültig zu sein
b)Nein, wird verworfen wenn ungültig
c)Das ist ein String, entweder "--" wenn nicht geladen wird/nicht benötigt, "xx Min" oder "x H xx Min"

Dann zu (a) wäre das schön, es zu haben, dann kann man in der UI die möglichen Werte auch anbieten - "verwerfen" eines zu hohen ist nicht toll, weil man dann nicht merkt, dass es einfach nicht gemacht wird. Notfalls an den Bereich anpassen. Aber wirklich verwerfen?

(b) ich meine alle möglichen Fehler, das habe ich falsch ausgedrückt. Keine Ahnung, was da alles passieren kann in der OpenWB-Elektrik. Fehlerstrom-Schutzschalter-Auslösung, ...

(c) das macht es schwer, das auszulesen und per Software auszuwerten. Zumal das dann sprachabhängig ist... und warum dann "H", aber "Min", und nicht "hrs" und "min" oder "h" und "m"? Der Wert sollte in der UI aufbereitet werden und nicht auf dem Daten-Server.

Zu JSON möchte ich auch noch schnell meinen Senf dazu geben, so wie ich das als MQTT-Client sehe: im Fall einer JSON-Versorgung *aller* relevanten Daten auf ein Mal (siehe go-eCharger MQTT) hat man wenigstens alle Werte auf einmal vom gleichen Zeitpunkt (der auch noch angegeben ist), und die Datenmenge beschränkt sich da auf eine Menge, die schätze ich in einer IP-Payload (1518 Byte) unterbringbar ist (die Keys sind max. 3 Zeichen kurz - gräßlich, aber effektiv).

Eine Zeitverschiebung verschiedener Daten kann ärgerlich sein, wenn man aufgrund z.B. aktuellen Werten von PV-Leistung und Stromexport einen neuen Ladestom berechnen will, aber die Informationen nicht zusammen "passen", z.B. weil der Pv-Wert älter ist und gerade eine Wolke angekommen ist oder so.

Man könnte das ja auf aktive Ladepunkte beschränken, oder 1+n Pakete, eins mit allgemeinen Informationen und n mit den Ladepunkt-Informationen aktiver Ladepunkte (inaktive retained).

Just my 2ct.

[openWB]

Auf der anderen Seite: Es bleibt pro Topic immer noch ein Datenstrom von nur ein paar hundert Byte. Und was ist das heute schon?

Nur weil alle verschwenderisch sind müssen wir das auch sein?

Einzig wenn man getaktete Verbindungen zu Grunde legt (Mobilfunk) ist solch extreme Datensparsamkeit vielleicht ein Punkt. Dann aber würde vermutlich mehr eingespart wenn z.B. schlichtweg seltener oder nur wirklich nötige Topics gepublished würden. Das wäre dann aber ein Feature request "Publish-Intervall konfigurierbar machen". Topic-Filter kann schon jetzt einfach mit der MQTT-Bridge-Konfiguration erreicht werden.

Das wiederum kann der Client entscheiden welchen Topics er subscribed.

Code: Alles auswählen

Den Teil des Satzes mit dem "minimalen Mehrwert" teile ich so nicht. Ich denke einzelne Werte haben ohne Zeitstempel überhaupt keinen Sinn ... naja, das ist vielleicht übertrieben ausgedrückt  :D ... was ich meine:
Veränderliche Daten (Ströme, Spannungen --> Leistungen, Zählerstände, ...) haben ohne Zeitstempel nur Wert wenn es reicht zu wissen daß es der "neueste verfügbare" Wert ist.

Wenn du frisch subscribest kannst du den Timestamp jedem Wert zuordnen (aktuellst).
Wenn dieser sich ändern kann du das wieder dem Timestamp zuordnen und hast den passenden Timestamp dazu.

Aber der Vorteil von MQTT ist doch gerade daß es ein Quasi-Standard im IoT-Bereich ist.

Richtig, ist es auch. Möglichst schlank. Ich sträube mich etwas Ursprungsseitig Overhead hinzu zu packen, die Payload zu erhöhen um Clientseitig den Aufwand zu erhöhen alles wieder auseinander zu drösseln.
Sollte von der CPU Auslastung Clientseitig auch geringer sein "onMessage" mit Timestamp zu verknüpfen als für alle Werte nen json Decoder laufen zu lassen.
Ich habe da Eingangs auch mit gespielt. Bei den Daten für den Live Graph merkt man es extrem.
Als .csv / raw sind die payload etwa 16-18kB. Als JSON rund 45-50kB. Ja, das klingt wenig, aber die Masse macht es

So könnte von Alexa-Skins über InfluxDB-Anbindung oder SmartHome-Plugins alles mögliche entwickelt werden (Dinge die mir gleich als "nice to have" eingefallen sind als ich las, daß OpenWB MQTT kann). Oder gar irgendwelche weiterführenden Applikationen (auf deren Ideen zum jetzigen Zeitpunkt noch gar niemand gekommen ist). Alles Dinge welche die Akzeptanz von OpenWB als Plattform und so (hoffentlich) auch den Umsatz von snaptec erhöhen würden.

Da denken schon einige Leute drauf rum und sind auch schon dabei
Ist hier aber wieder der Punkt das an jedem Ende erstmal ein JSON Decoder laufen müsste den man sich so sparen kann.

Grundvoraussetzung dafür ist allerdings daß die Information von der OpenWB so stichhaltig wie möglich ist. Denn was mache ich z.B. mit der Information eines Zählerstandes wenn ich nicht weis von wann der ist. Damit fällt der Wert für einzelne Einsatzzwecke komplett aus.

Weißt du doch -> Timestamp!

Leider hilft es nicht, daß die OpenWB den aktuellen Zeitstempel in ein separates Topic published. Immerhin wird ja nicht jedesmal jedes Topic gepublished sondern nur bei Änderung der Werte. Der Zeitstempel hat also generell keine direkte Aussagekraft für den Zeitpunkt zu dem ein einzelner Wert gemessen wurde.

Doch der Wert ist ja immer noch aktuell zum Timestamp, sonst hätte er sich nämlich geändert.
s.o., bei künftigen Änderungen ist der aktuelle Timestamp dann relevant.

Ich glaub ich würde "openWB/system/Timestamp" bevorzugen. Aber nur, weil der Namen dann eher dem entspricht was drin ist (nämlich ein Date _und_ eine Time, könnte also auch noch "DateTime" heißen). Bessere Argumente dafür oder dagegen finde ich nicht

Es ist beides drin.
Date ist:

Code: Alles auswählen

Mon 18 Nov 11:51:48 CET 2019

TimeStamp ist Unixtime:
1574074330


@c2j2

a) Ah okay, schau ich mir an.
b) Achso, Fehlerzustände meinst du.

Du meinst ein Topic in dem ein kompletter JSON mit allen Daten ist?
Das würde bedeuten das alle 10 Sekunden alle Werte verschickt werden. Das ist irgendwie wenig Smart.
openWB published definitiv nach jedem Auslesen aller Module. Daher ist die Konsistenz was da angeht schon gegeben.
Aber nicht jedes Modul und jeder Zähler verhält sich gleich (so nebenbei erwähnt)

[truckl]

Das wiederum kann der Client entscheiden welchen Topics er subscribed.

Nur wenn der Client gleich der Enduser ist der direkt die OpenWB kontaktiert. Da diese aber in einem privaten Netzt steht wird da wohl sehr oft eine Bridge dazwischen sein. Und der Bridge bleibt nur das "Superset" der Topics zu bridgen, also alles was potentiell jemals benötigt wird (ergo: oft wohl einfach alles).

Wenn du frisch subscribest kannst du den Timestamp jedem Wert zuordnen (aktuellst).
Wenn dieser sich ändern kann du das wieder dem Timestamp zuordnen und hast den passenden Timestamp dazu.

Und was ist mit Anwendungen die nicht kontinuierlich subscribed sind oder sein können?
Z.B. weil Werte nur einmal am Tag ausgelesen werden sollen? Oder weil man keine Kontrolle darüber hat wann und wie lange der Client läuft (Mobilgeräte die in den Powersave-Mode gehen oder die "App Optimieren", Clients die Teil einer anderen IoT Software sind und zyklisch aufgerufen werden, ...).

Grundvoraussetzung dafür ist allerdings daß die Information von der OpenWB so stichhaltig wie möglich ist. Denn was mache ich z.B. mit der Information eines Zählerstandes wenn ich nicht weis von wann der ist. Damit fällt der Wert für einzelne Einsatzzwecke komplett aus.

Weißt du doch -> Timestamp!

Aber doch nur unter der Voraussetzung daß ich Subscribe und dann warte bis sowohl ein Timestamp und der gesucht Wert quasi-gleichzeitig eintreffen.
Und was ist wenn gerade kein Auto lädt und sich der Wert daher nicht ändert? Wie lange soll ein Client nun warten um den Bezug herzustellen zu können? Könnte ja auch sein daß der Wert vom vorigen Jahr ist weil an einem LP nie mehr geladen wurde.
Und schlimmer noch: Der MQTT-Broker retained einen Wert für immer (oder bis seine Datenbank gelöscht wird). Was also, wenn in der OpenWB z.B. ein Topic entfallen ist (entfallener LP, Interface-Änderung, ... warum auch immer). Der Broker schickt dann trotzdem noch die Daten die er vor Ewigkeiten bekommen hat und man hat keine Chance zu erkennen daß diese veraltet sind und nie mehr aktualisiert werden.

Doch der Wert ist ja immer noch aktuell zum Timestamp, sonst hätte er sich nämlich geändert.
s.o., bei künftigen Änderungen ist der aktuelle Timestamp dann relevant.

Wie oben geschrieben: Du implizierst daß MQTT-Clients grundsätzlich immer beliebig lange connected sind. Ich glaube nicht daß das ein allgemeingültiger Fall ist.

Den Vorschlag von c2j2, eine einzige JSON-Nachricht mit allen Werten zu publischen fände ich einen guten Kompromiss. Hätte auch schon eine Idee wie ich das, falls akzeptabel, relativ einfach zu meinem Pull-Request hinzufügen könnte.

[openWB]

Ich versuche noch den Mehrwert zu erkennen.

Und was ist mit Anwendungen die nicht kontinuierlich subscribed sind oder sein können?
Z.B. weil Werte nur einmal am Tag ausgelesen werden sollen? Oder weil man keine Kontrolle darüber hat wann und wie lange der Client läuft (Mobilgeräte die in den Powersave-Mode gehen oder die "App Optimieren", Clients die Teil einer anderen IoT Software sind und zyklisch aufgerufen werden, ...).

Welchen Unterschied macht dann der Timestamp?

Nehmen wir den Zählerstand und einen Client der täglich um 15 Uhr abfragt.
Tag 1: 15 Uhr, Zählerstand 950kWh. Ladung ist noch aktiv bis 15:30.
Tag 2: 15 Uhr, Zählerstand 952kWh.
Wenn der Timestamp dabei ist weiß ich das der sich um 15:30 zuletzt geändert hat und seitdem gültig ist.
Ist der Zeitstempel nicht dabei weiß ich das er aktuell 952kWh beträgt und in den letzten 24 Stunden 2 kWh bezogen wurden.
Tag 3: 15 Uhr Zählerstand 952kWh. Wir laden ab 18-19Uhr mit 3kW.
Tag 4: 15 Uhr Zählerstand 955kWh.
Hier wissen wir mit Timestamp das seit 19Uhr Ruhe ist, ohne Timestamp das 3kWh geladen wurden seit gestern.

Der Mehrwert bzw. der Anwendungsfall wo es Sinn macht fehlt mir im Vergleich zum extra Aufwand.
Denke mal an die "echten" IoT Geräte, da heißt es sparsam sein.

Mobilgeräte wollen grundsätzlich immer den letzten Stand haben oder hast du ein Beispiel wo das nicht der Fall ist?
Der "Wahrheitsgehalt" ist ja immer noch gegeben, auch ohne Timestamp.

Aber doch nur unter der Voraussetzung daß ich Subscribe und dann warte bis sowohl ein Timestamp und der gesucht Wert quasi-gleichzeitig eintreffen.

Im Zeitpunkt des subscribens hast du ja schon valide Daten.

Und was ist wenn gerade kein Auto lädt und sich der Wert daher nicht ändert? Wie lange soll ein Client nun warten um den Bezug herzustellen zu können?

Garnicht, der Bezug ist doch sofort gültig. Nur weil ein Wert sich länger nicht ändert, ist er mit neuerem Timestamp nicht weniger gültig.

Könnte ja auch sein daß der Wert vom vorigen Jahr ist weil an einem LP nie mehr geladen wurde.

Dennoch ist der Zählerstand oder die Info 0 Watt oder "nicht steckend" doch gültig?

Der MQTT-Broker retained einen Wert für immer (oder bis seine Datenbank gelöscht wird). Was also, wenn in der OpenWB z.B. ein Topic entfallen ist (entfallener LP, Interface-Änderung, ... warum auch immer). Der Broker schickt dann trotzdem noch die Daten die er vor Ewigkeiten bekommen hat und man hat keine Chance zu erkennen daß diese veraltet sind und nie mehr aktualisiert werden.

Das ist ein anderes Thema. Hier kann es ein ab und an mal ein automatisiertes Aufräumen geben.

Wie oben geschrieben: Du implizierst daß MQTT-Clients grundsätzlich immer beliebig lange connected sind. Ich glaube nicht daß das ein allgemeingültiger Fall ist.

Eher gehe ich von aus das das nicht der Fall ist, daher auch überall retained.
Wenn ich nachhaltig loggen möchte gehe ich aber von durchgehendem subscribe aus.

Den Vorschlag von c2j2, eine einzige JSON-Nachricht mit allen Werten zu publischen fände ich einen guten Kompromiss. Hätte auch schon eine Idee wie ich das, falls akzeptabel, relativ einfach zu meinem Pull-Request hinzufügen könnte.

Das stellt aber MQTT bzw. dessen Sinnhaftigkeit in Frage.
Wenn ich alle 10 Sekunden alle Werte pushe, kann ich auch alle 10 Sekunden die JSON Api bemühen.
Einen Haufen Traffic für Werte die sich teils selten ändern.

[aiole]

Eine interessante Diskussion.

Als MQTT-Anfänger würde ich den traffic allerdings auch so gering wie möglich halten. Solange man clientseitig die Daten samt Gültigkeit ermitteln kann, ist doch alles gut.

Natürlich solll der openWB-MQTT zukunftsfähig sein, aber der Ursprung von MQTT ist doch der Minimalansatz, wenn ich das richtig recherchiert habe.

@truckl
Ist das so ein Aufwand, die Infos clientseitig aus den Minimaldaten zu validieren?

ps
Bei "Alexa-Skin" kam mir übrigens gleich die Galle, aber es war Deinerseits nur aus der Hüfte geschossen. Ich weiß, was Du meinst und Zukunftsoptionen sind natürlich wichtig.
Dennoch sollten wir immer daran denken, dass openWB vorrangig LOKAL läuft und Datensicherheit groß geschrieben wird. Bitte erwähne daher echte Zukunftsfeatures nicht mit solchen unsäglichen "Errungenschaften" wie Alexa und Co., die der Stasi in nichts nachstehen. (Ich spendiere Dir gern eine Führung in der ehemaligen "runden Ecke" in Leipzig.)

[openWB]

Wenn mir irgendwo etwas entgeht, klärt mich bitte auf

Datensicherheit und nicht lokal schließt sich nicht aus.
MQTT bietet Verschlüsselung und Authentifizierung. Ist damit optimal geeignet die Daten auch woanders hin zu senden.
Wer seine Daten wohin publisht entscheidet jeder selbst. Anwendungsfälle sind vielfältig.
Ich denke nur die sichere Basis dazu sollte von openWB bereitgestellt werden.
Und nur weil alle anderen Traffic ohne Ende verursachen und Ressourcen verschwenderisch nutzen (wenn ich mir mal den ELK Stack anschaue...) sollte openWB das nicht auch tun.
Natürlich sollen alle nützlichen und wichtigen Infos vorhanden sein.