Geräte und Komponenten / MQTT / statisches Topic-Naming

[caran17]

Hallo zusammen,

nachdem ich mich anfangs mit dem Thema MQTT etwas schwer getan und damit auch schon mal meine Konfiguration ungwollt überschrieben habe, habe ich mich mittlerweile näher mit dem Thema beschäftigt. Mittlerweile stellt mein kleines Programm die Werte für die Geräte Zähler, Wechselrichter und Speicher nicht nur als JSON zur Verfügung, sondern publisht sie auch via MQTT.

Jetzt würde ich gerne auch in der openWB die Werte nicht mehr per JSON holen, sondern mich dort auf die entsprechenden MQTT-Topics subscriben.

Dafür gibt die openWB unter "Konfiguration - Geräte und Komponenten" entsprechende Topics vor, bei mir wäre das z. B. "openWB/set/counter/12/get/power". Ich müsste also in meiner Applikation diese Topics so benennen, wie von der openWB vorgegeben. Und hier liegt mein Problem. Mein Verständnis von MQTT ist genau anders herum, nämlich dass der Publisher die Topics vorgibt und der Subscriber sie so nimmt, wie sie sind. Korrigiert mich, wenn ich hier falsch liege. Aber so herum ergbit es meiner Meinung nach wesentlich mehr Sinn, da ja einer der Vorteile von MQTT ist, dass man die Werte nur einmal publishen muss und sich beliebig viele "Clients" darauf subscriben können. Wenn jetzt jeder Subscriber vorgibt, wie die Topics lauten müssen, müsste man ja für jeden Subscriber die Werte erneut publishen, das klingt für mich falsch. Erschwerend kommt hinzu, dass man in dem Topic-String sogar die interne openWB-ID des jeweiligen Geräts angeben muss. Wenn man einmal etwas in der Konfiguration ändert (Gerät löschen und wieder neu anlegen), würde das bedeuten, dass der Publisher seine Topics ändern muss.

Wäre es nicht viel sinnvoller, wenn man die Topics in der openWB einfach angeben könnte, so wie man das ja z. B. auch für die JSON-Pfade kann?

[aiole]

openWB verwendet MQTT hauptsächlich für seine interne Kommunikation. Von extern zu steuern, ist eher Sonderfall - sprich Integration in andere MQTT-tools. Dahingehend legt die topics openWB fest.

Es gibt ganz neu eine http-API die http auf MQTT übersetzt. Aber auch dort muss das openWB definierte topic verwendet werden.

[caran17]

Hallo aiole,
die grundlegende Funktion (openWB subscribed sich auf die entsprechenden Topics) existiert ja aber durchaus. Die Topics dynamisch zu machen, scheint mir, ohne das natürlich zu wissen, nicht aufwändig und würde einen deutlichen Mehrwert bringen. Ich kann aber verstehen, dass andere Themen dringender sind.

So lange die Integration so bleibt, werde ich erstmal bei der JSON-Variante bleiben.

[Gero]

die grundlegende Funktion (openWB subscribed sich auf die entsprechenden Topics) existiert ja aber durchaus.

Wo passiert das denn? Oder meinst Du, dass sich die openWB auf gewisse Topics seines internen mosquittos subsribed? Das ist dann aber interne Programmierung und hat nichts mit draußen zu tun. (Ein MQTT-Zähler wird angelegt und die openWB subsrcibed darauf. Nun schreibt jemand in den mosquitto.)

Die Topics dynamisch zu machen, scheint mir, ohne das natürlich zu wissen, nicht aufwändig und würde einen deutlichen Mehrwert bringen.

Eigentlich sind die Topics ja dynamisch. Man kann mehrere Wechselrichter - sie unterscheiden sich dann durch die vergebene ID. Der Mehrwert ist da, wo man beliebig viele davon anlegen kann.

Technisch gesehen könnte man sicherlich in der Konfiguration einer jeden Komponente eine alternatives Topic angeben, unter dem der oder die Werte dieser Komponente zusätzlich gepublished wird. Schwieriger wird es bei der Sache, wenn die openWB z.B. einen MQTT-Zähler subsrcibed. Da müsste dann der frei angegebene Name gültig sein und der von openWB generierte deaktiviert werden. Zusätzlich müsste man dann noch die Eindeutigkeit der Topics sicherstellen. Geht alles, ist aber aufwendig.

Und wofür das alles? Wenn Du in einer großen Installation immer mal wieder die Komponenten der openWB anlegst und dann mit den IDs durcheinander kommst, dann solltest Du über einen Zwischenbroker nachdenken, der das Mapping von openWB-Topic mit ID zu einem fixen ohne erledigt. Bei den meisten ist es ja so, dass sie einmal konfigurieren und es dann gut sein lassen.

Die IDs findest Du übrigens auch in den Ladelogs usw. Wenn Du da immer mal neu konfigurierst, bekommst Du die auch nicht mehr so einfach übereinander.

[caran17]

Hallo Gero, ich glaube, ich meinte etwas anderes, aber vielleicht habe ich es auch nicht ganz verstanden.

Worum es mir geht: Einstellungen -> Konfiguration -> Geräte und Komponenten. Hier kann ich ja die Daten von bereits vorhandenen Zählern, Wechselrichtern und Speichern einbinden, so dass die openWB z. B. weiß, wie viel Strom gerade importiert oder exportiert wird, wie voll der Speicher ist, etc. Es geht also um Werte, die von anderen Geräten zur openWB gelangen sollen, nicht um Werte, die von der openWB kommen.

Wenn die Geräte, wie bei mir, nicht direkt in "Verfügbare Geräte" auftauchen, gibt es generische Geräte, wie z. B. Json, HTTP oder eben auch MQTT. Wenn man hier MQTT auswählt, geht es also darum, dass ein anderes Gerät die Werte per MQTT publisht und die openWB sich auf bestimmte Topics subscribed.

Und da finde ich es eben merkwürdig, dass openWB die Topics festlegt und nicht das Gerät, welches die Daten "sendet". Ntürlich sollten sich die Topics nicht überschneiden, das hat aber nichts mit der openWB zu tun. Wenn zwei Geräte auf die gleichen Topics publishen würde, hätte man auch ohne openWB das Problem, die Geräte nicht unterscheiden zu können.

Ist das einigermaßen verständlich, was ich meine? Oder habe ich da ein Verständnisproblem?

[Gero]

Du kannst beliebig viele MQTT-Geräte anlegen. Die Implementierung ist nun einmal so, dass der openWB-MQTT-Broker das Schreiben der Messwerte in gewisse Topics vorsieht.

Anders herum - also wenn die openWB Topics subscriben würde, müsste jeder zusätzlich einen eigenen Broker laufen haben. Wenn irgendwelche Geräte per MQTT ihre Werte herausgeben, wollen sie das immer in einen Broker schreiben. Vielleicht kann man zusätzlich auch noch das Topic konfigurieren, in das geschrieben wird. Shellies sind ein gutes Beispiel dafür. Man hat letzten Endes das Gerät, einen Broker und dann noch die openWB.

Viele Programme kônnen direkt auf ein beliebiges Topic in einen Broker schreiben. (So wie ein Shelly) Auf diese Art entfällt der Zwang zu einem eigenen Broker.

Unter dem Strich ist die gewählte Implementierung vom gesamt-Setup her einfacher, weil der zusätzliche Broker entfällt.

Eins noch: wenn du ein Gerät haben solltest, was seine Werte in einem bestimmten Topic bereitstellt, ist das ein Gerät - so wie die openWB - mit einem eigenen Broker. Das ist dann ein bisschen zu gut ausgestattet, das Gerät. Normalerweise gibt es immer nur einen Broker der alle Werte managed und nicht je Gerät einen.

[caran17]

Ah, ich glaube, so langsam dämmert mir, was mein Denkfehler ist. Sorry, dass ich mich da etwas schwer tue.

Für mich war es bisher so bei MQTT: es gibt einen Broker in der Mitte (bei mir ein mosquitto). Darauf publishen Geräte und andere subscriben sich darauf. So war auch hier mein Verständnis davon.

Aber anscheinend ist es gar nicht so, sondern die openWB nutzt hier einen eigenen Broker. Stimmt, ich habe auch nirgendwo den mosquitto-Host eingetragen. Dann macht es natürlich auch Sinn, dass die openWB die Topics vorgibt. Und meine Applikation müsste dann auch nicht in den mosquitto, sondern direkt in den openWB-Broker schreiben, oder ich bräuchte so eine bridge. So irgendwie, oder? Dieser Teil erzeugt bei mir nach wie vor Kopfaua. Ein Broker in der Mitte verstehe ich, aber dass dann die Geräte selbst z. T. noch Broker haben, die dann irgendwie auch untereinander kommunizieren, macht es mir vom Verständnis her schwierig, aber ich lerne ja noch.

Aber jetzt habe ich eine Idee, warum die Implementierung so ist. Und davon, dass das, was ich mir vorstelle, etwas doch sehr anderes ist.

[Gero]

Normalerweise hast du in einer Installation nir einen einzigen Broker. Alle publishen darauf ihre Zustände und alle subscriben darauf. Das ist schön, weil man dann nur einen einzigen Amsprechpartner hat.

Die openWB ist da ein bisschen anders, denn sie bringt ihren eigenen Mosquitto mit, weil die Programmierung sich den Mosquitto nicht nur als Messwertspeicher sonden auch als Konfigurationsspeicher ausgesucht hat. Auch die Werte des Graphen auf der Homepage liegen im mosquitto. Genauso wie die IP-Adressen etc der Wechselrichter, Speicher etc.

Du kannst der openWB sagen, sie möchte bitte alle ihre Topics in einen anderen Broker spiegeln. Dort ist es dann ein Teilbaum. Das macht man aber nur in Ausnahmefällen, durch die Bridge-Funktion machen sich viele mehr kaputt als dass es ihnen nutzt.

Wenn Geräte einen eigenen Broker mitbringen hilft das meistens nicht viel, denn dann muss man in der eigenen Programmierung mehrere Broker abfragen statt nur einem Broker mot mehreren Topics. Ist halt eine höhere Netzwerkbelastung, weil Verbindungen zu vielen Broker offengehalten werden müssen. Administrativ ist es egal - ob man Broker-Adressen umkonfiguriert oder Topics, ist letzten Endes egal. Angefasst ist es.
Aber für jemanden mit nur einem MQTT-Gerät ist es hilfreich, denn so spart man sich den eigenen mosquitto.

[caran17]

Danke dir für die Erklärung, so langsam habe ich ein Bild davon.

Wobei, um auf den Ausgangswunsch zurückzukommen: es würde doch trotzdem nichts dagegen sprechen, dass sich die openWB die Werte auch wahlweise aus einem anderen, vorhandenen Broker zieht, oder? Ich fände, das wäre ein tolles neues Feature, um die openWB noch offener für die Außenwelt zu machen.

[Gero]

Du könntest ja im Feature Request Bereich so etwas mal vorschlagen: „MQTT ext. Broker“ bei dem man den Broker und die dort zu abonnierenden Topics für das jeweilige Gerät angeben kann.

Und vielleicht dabei auch das Gerät benennen, welches so einen Broker mit verbaut hat.