[V4.5 IP8] MQTT: Empfehlung zur Strukturierung der Topics (Zendure SolarFlow)

[AndererStefan]

Hallo zusammen,

ich habe eine Frage dazu, wie ich im MQTT-Subsystem die Topics für ein Gerät am sinnvollsten strukturiere. Da man die Geräte nach dem Anlegen auf der Hauptebene ja nicht mehr bearbeiten kann, möchte ich gerne folgenschwere (aufwändige) Fehler vermeiden.

Konkret geht es hier um den AC-gekoppelten Batterie-Speicher "Zendure SolarFlow 2400 AC", aber eigentlich ist die Frage auch auf andere Geräte übertragbar.

Das Gerät sendet die Topics in folgender Struktur:


Wie ihr seht, ist in die Struktur auf 3. Ebene die Seriennummer des Gerätes eingebunden. Wie verpacke ich das am sinnvollsten? Ich denke zum einen an ein späteres Teilen der Geräte-Konfiguration, aber auch daran, dass evtl. das Gerät bei einem Defekt ersetzt werden könnte und ich nicht alles neu anlegen möchte.

Mir sind folgende Ansätze eingefallen:
1) Das Gerät mit "Zendure" anlegen und den Rest in das App Level Topic (z.B. /sensor/Hxxxxxxxxxx9/heatState) nehmen.
2) Mehrere Geräte "Zendure/sensor/Hxxxxxxxxxx9", "Zendure/switch/Hxxxxxxxxxx9" etc. anlegen und in den App Level Topics dann nur noch die letzte Hierachieebene also z.B. "/heatState" definieren.

Bei Variante 1) muss man alle Topics bearbeiten wenn man die Konfiguration auf eine andere Seriennummer anpassen möchte. Bei 2) hätte man die Möglichkeit beim Import des Geräteprofils das Topic zu ändern.
Falls ich das richtig verstehe, wäre bei Variante 1) die Änderung der Seriennummer in einer bestehenden Konfiguration zwar aufwändig, aber zumindest möglich (ohne alle Objektverknüfungen neu machen zu müssen). Bei Variante 2) muss man das Gerät mit allen Verknüfungen komplett neu anlegen, braucht aber die Seriennummer nur an einer Stelle anpassen.

Noch ein paar weitere Gedanken:
Die Schalter für unterschiedliche Prefix/Infix/Postfix Level helfen hier gar nicht, oder?
Das exportierte Geräte-Profil (*.json) kann man auch mit einem Texteditor bearbeiten, aber die Warnungen beim Import machen mich dann noch nervös (der TWS bemerkt die Bearbeitung, weil der Hash nicht mehr stimmt) und das ist nicht die elegante Art. Ich erinnere mich an Warnungen von Elabnet zu einem ähnlichen Vorgehen in anderem Kontext, weil so Prüfungen umgangen werden und es zu schwerwiegenden Fehlern kommen kann.

Übersehe ich noch etwas? Welches Vorgehen wäre "Best Practice"?

VG
Stefan

PS:
Ich weiß noch nicht, ob eine Selfmade-Steuerung über MQTT überhaupt der "richtige" Weg für mich ist. Das einfachste wäre sicher die Verwendung der Hersteller-Cloud mit einem kompatiblen D0-Lesekopf oder die Nutzung der HomeAssistant-Integration. Aber ich habe bereits einen D0-Lesekopf und die Daten im KNX und HA mag ich nicht. Aber um diese Frage des "wie steuern" solls hier gar nicht gehen. Ich evaluiere erstmal meine Optionen.

[gbglace]

Du bekommst also einen Stream an MQTT aus dem Zendure heraus, siehe Screenshot oben.

Jetzt willst Du diese Elemente neu sortieren und dann noch einmal per MQTT verschicken?

Wenn dem so ist, dann gibt der Zendure das Topic ja vor und damit den Aufbau des Selectors um sich ein TWS Objekt daraus zu bauen.

Ich bekomme meine Daten der Hauselektrik, von Tibber, vom Cerbo mit den ganzen Victron-HW Geräten, der Open DTU für einige Hoymiles WR, ein paar Moduszählern und einigen KNX Aktor Kanälen.

Das Schema der TWS Objekte ist da erstmal ganz losgelöst von der Quelle. Generisch um quasi einen großen Energieflussmonitor erstellen zu können.

Beim Victron Cerbo kann man alles mögliche an Objekten schreiben lassen, standardisiert was da rauskommt ist da auch nix.

[AndererStefan]

Moin,

nee, ich möchte die Daten nicht neu zusammenwürfeln und über MQTT neu versenden. Ich möchte im TWS ein MQTT Gerät konfigurieren, damit diese Daten vom TWS nutzbar sind. Ich bin unschlüssig, wie ich das am sinnvollsten anlege.

VG Stefan

Edit: Foto zur Variante 1) ergänzt:

[gbglace]

Wenn alles aus einem JSON selektierbar ist, dann alles ein Gerät und darunter einfach die Liste an Datenpunkte/Subscriptions mit den passenden Selektoren.

Bei mir ist das auch einmal Victron ESS und darunter ziehe ich dann alles raus was es gibt. GridZähler, Multiplusdaten, Speicherdaten (kommt demnächst primär aber vom BSC), Laderegler-Daten MPPTs, und gekopplter Fronius AC WR.


Bei der OpenDTU ist es anders die sendet zu jedem einzelnen Hoymiles WR ein eigenes Topic mit den entsprechenden JSONs.

Da habe ich dann auch entsprechend viele Geräte.

[Sun1453]

Ich würde mal sagen man könnte die Seriennummer auch als Parameter machen und den über die Logik Engine zuliefen lassen. Dann hast es maximal flexibel. Da würde dann auch Variante 1 kein Problem sein.

Logik würde ich das mit String zyklisch senden machen, damit der Wert immer vorhanden ist.

Später gibt es vielleicht dann auch mal ein System wo Statische Werte hinterlegt werden können, wo alle Subsysteme zugreifen können.

[AndererStefan]

@gbglace: ja, es ist technisch alles mit einem Gerät und aus dem Topic „Zendure“ abgreifbar, was ich brauche. Es gibt auch noch ein Topic „Homeassistant“ (nicht auf dem Screenshot). Das enthält aber „nur“ Meta-Daten (z.B. welche Werte zulässig sind), die zwar sehr hilfreich sind, aber die ich nicht im TWS brauche.

@Sun1453: das klingt nach der Art von Vorschlag auf die gehofft habe - geht das denn, bzw. wie benutze ich eine Variable im App Level Topic?

VG
Stefan


Edit: übrigens toll wie sich das Gerät per MQTT in den TWS integrieren lässt. Ich hab direkt per Router die Internetverbindung gesperrt. Es ist zwar noch etwas Fleißarbeit die Visu zusammenzustellen und eine Steuerung muss ich auch noch finden/bauen aber dafür bin ich Hersteller-Cloud-free.
Mit Homeassistant ging das vermutlich alles einfacher, weil irgendwer sicher schon irgendwas gemacht hat, aber HA ist mir zu „flatterhaft“.

[Sun1453]

Bin mir nicht ganz sicher aber kann heute auch nicht schauen aber bei HTTP Api war das mit <Parameter>.
Könnte also sein das man dies so auch beim App Level oder Post Fix eventuell nutzen kann. Also statt der Serien Nummer einfach das in den Level einbauen.
Am Wochenende kann ich mal auf dem Server schauen, ob das so klappt.

[AndererStefan]

Hi Michael,

ich würde mich freuen, wenn du auch noch mal nachschaust, aber ich hab mit einem <Parameter> nichts erreicht.
Bei der HTTP-API (Client) ist der Aufbau doch sehr anders als bei den MQTT-Geräten: Man definiert bei der HTTP-API dort eine "Ressource". Diese hat eine URI in der <Parameter> genutzt werden können. Anschließend fügt man Objekte hinzu, gibt bei diesen Objekten den <Parameter> als Selektor an und verknüpft das Objekt mit einem Wert aus dem Objektmanager (z.b. von einer Logik).

Ich habe noch etwas rumprobiert und eventuell einen Kompromiss gefunden. Ich fasse nochmal zusammen:
a) Bei meinem Gerät steht eine Seriennummer in der 3. Ebene der MQTT-Topics.
b) Ich möchte bei der späteren Weitergabe meines Profils nicht meine Seriennummer teilen (sowas kann oft zum errechnen von Passwörtern verwendet werden etc...).
c) Andere Benutzer sollen das Profil ohne "Hacks" (sprich editieren der json) direkt für sich nutzen können.
d) Ich möchte, falls das Gerät mal ersetzt werden muss, die Seriennummer in der bestehenden Konfiguration leicht anpassen können.

Daraus folgt:
- Die Seriennummer darf nicht im Main-Topic stehen, denn das kann man nicht nachträglich ändern. (d)
- Die Seriennummer darf aber auch nicht im App Level Topic stehen, denn die kann man beim Import nicht (zentral) ändern. Allenfalls durch bearbeiten jedes einzelnen App Level Topics, oder rumeditieren in der *.json-Datei. (b/c)

Eine mögliche Lösung: Die Seriennummer muss in den Infix Level?! Den Infix Level kann man sowohl beim Import anpassen, aber auch noch nachträglich. Ich könnte das Profil mit meiner "echten" Seriennummer erstellen, exportieren, importieren, die Seriennummer durch einen Platzhalter ersetzen und erneut exportieren um das Profil zu teilen.


Die Methode hat allerdings zwei mögliche Nachteile:
1) Das Interface hebt identische Infixes rot hervor, als wäre das ein Problem. - Das macht mich etwas nervös
2) Weil die Seriennummer auf der 3. Ebene steht, muss ich eigentlich mehrere (d.h. vier) Geräte anlegen und jeweils alles vor der Seriennummer in das Main-Topic legen. Der Infix muss für alle Topics eines Gerätes gleich sein, sonst kann man ihn nicht zentral ändern. (Zendure/sensor; Zendure/switch; Zendure/select; Zendure/number). Da weiß ich nicht ob die Aufteilung auf mehrere Geräte, die Benutzung verkompliziert.

Wie sind eure Gedanken dazu? Denke ich das unnötig kompliziert? Oder hab ich hier einen Spezialfall, für den es keine "gute" Lösung gibt und der eigentlich zusätzliche Features im TWS erfordert?

VG Stefan

[gbglace]

Mit HA hat man nur einen einfacheren Weg sich solche Geräte als Entität automatisiert anlegen zu lassen, dann aber mit den Datenpunkten irgendetwas anstellen, da ist der TWS dem HA weit überlegen.

[AndererStefan]

Ja, wie gesagt HomeAssistant mag ich nicht. Es ist toll was es da gibt und geht, aber für mich ist das nichts.

Scheinbar ist mein Problem wie ich hier am Besten die MQTT Topics beim TWS anlege sehr speziell oder nicht gut vorgebracht?

Ich würde mir eine kurze Info von Elabnet wünschen (@StefanW) - und sei es auch nur, dass man das Problem nicht versteht.

Aktuell zögere ich mit der Konfiguration weiter zu machen, weil ich mir denke vielleicht kommt ja noch ein wertvoller Tipp oder Hinweis …

VG Stefan