Feature Request: MQTT-Analyse zur Minimierung & Angleichung Topics von AhoyDTU/OpenDTU

[knickohr]

Ich habe mal ein bißchen mit MQTT rumgespielt und das analysiert. Dabei sind mit ein paar Punkte sauer aufgestoßen :

Erst mal. Ahoy hat mit 14 Invertern knapp 1000 !!! Topics 😵

• Warum sind die Alarm-Messages retained ? Gibt’s dazu einen besonderen Grund ?
• Schön wäre es wenn man die Alarme in einen 4er-Päckchen zusammen fassen könnte. Also code, start, end und string in einem JSON. Macht das etwas übersichtlicher und gleich mal über 500 Messages weniger.
• Das last_success kommt mir noch zu oft. Es reicht eine einzige Message pro abgefragten Inverter, vor allem bei nicht antwortenden Invertern.
• Ebenso kann man die HW-Infos, FW-Infos und die GridProfile-Infos jeweils in einem JSON zusammen fassen.
• Auch die Inverterbezogenen Werte, wurde ja schon in der Wunschliste angeregt, optional auswählbar in ein JSON reinpacken.

Ich bin mir sicher ich finde noch ein paar mehr Topics die mir durch die Lappen gingen 😅

(Wird weiter editiert, Geduld junger Padawan)

[stefan123t]

@knickohr ich warte ganz geduldig, versprochen 😇 aber könntest Du dabei bitte auch überprüfen ob wir die MQTT Topics von Ahoy & OpenDTU gleichzeitig irgendwie vereinheitlichen können ?
Dann wären so tolle Dinge wie Dashboards und andere Auswertungen aus dem HomeAssistant, IOBroker, NodeRed oder was auch immer für beide Projekte von Nutzen.

[knickohr]

Nun, das ist (leider) in einem Satz gesagt : Ein Projekt muß seine Topics ändern.

Schon allein die Baumstruktur ist nicht identisch 😕

Hoffnung bringt vielleicht wenn beide Projekte auf die JSON-Payloads optional umstellen. Dann wäre der passende Zeitpunkt beide Parteien an einem gemeinsamen Tisch zu zerren und es festzulegen 😉

@lumapu @tbnobody

[stefan123t]

Die MQTT Topics von AhoyDTU sind im UserManual: https://github.com/lumapu/ahoy/blob/main/User_Manual.md
und die MQTT Topics von OpenDTU sind hier dokumentiert: https://tbnobody.github.io/OpenDTU-docs/firmware/mqtt_topics/

Müsste man mal nebeneinander stellen und mit nem diff vergleichen, was vergleichbar ist

[stefan123t]

Anbei der Vergleich der beiden dokumentierten MQTT Topics.
@knickohr kannst Du ggf. die beiden Tabellen bzw. die Topics überprüfen anhand einer aktuellen Version,
falls Du sowohl AhoyDTU als auch OpenDTU irgendwo am Laufen hast ?

• MQTT_Topics.xlsx
• AhoyDTU_MQTT_Topics.md
• OpenDTU_MQTT_Topics.md

[knickohr]

Auf die Schnelle habe ich noch den fehlenden undokumentierten Topic für Ahoy gefunden :

ctrl/power/[id] mit Payload 0/1
Schaltet den Inverter soft aus/ein, also ohne dieses Startgedöns, er ist sofort online

dis_night_comm gibt es als General nicht mehr, der heißt jetzt wieder alt : comm_disabled. Hier wird der Status von Night behaviour ausgegeben, also od die DTU nachts noch mit den Invertern kommuniziert.
Für die einzelnen Inverter gibt es weiterhin den dis_night_comm, das die Einstellung ausgibt.

General
comm_dis_ts fehlt auch noch
Timestamp, wann die DTU offline gegangen ist, nicht verwechseln mit comm_stop, das ist die „Sonnenuhr“

Total
total/Q_AC ist auch nicht in der Liste

[stefan123t]

@knickohr habe Deine Anmerkungen oben eingearbeitet.
Hier noch der Hinweis auf die Diskussion Max. Leistung aller WRs zusammen anpassen #1608
tbnobody/OpenDTU#1608 (comment)

Hier wäre eine Zusammenfassung mehrerer Wechselrichter oder Inverter zu einem / mehreren PV-Pools sinnvoll.
Damit könnte man dann auch das Power Limit je Inverter / PV-Pool für einen gewissen Zeitraum vorgeben.
Z.B.

• der Batterie Pool von Sonnenuntergang bis Sonnenaufgang mit 150 W Grundlast
• der restliche Zoo an PV-Panelen & Invertern bis zu einem max. Einspeisung von 600W / 800W je nachdem was der Gesetzgeber gerade für richtig befindet.
• man könnte auch den aktuellen Verbrauch (von einem SML / Shelly 3EM Pro) zu einem oder mehreren PV-Pools gegenrechnen für eine Nulleinspeisung / Zero-Export Control.

[knickohr]

Ja, korrekt, das sollte aber dann direkt in der DTU passieren und nicht außerhalb. Ich möchte in Zukunft die ganze Power-Limit Gedöns nur noch innerhalb der DTU gesteuert sehen. Einzig allein die Vorgabe des Limits, keine Nulleinspeisung wo sich das Limit andauernd ändert, könnten wir per MQTT übergeben. Ansonsten nur noch lesende Ausgaben über MQTT bezüglich Limit.

[knickohr]

Vorschlag :

Das Ganze immer als JSON, außer der letzte Punkt.

• Die ganzen General und Total in einem Topic
• Alarmdaten als Topic
• (Noch nicht vorhandene) Gridprofile als ein Topic
• Die Inverterdaten als Topic, wobei ich die Firmware und Hardwareinfos da raus lassen würde. Vielleicht zu den Gridprofilen dazu ?
• Die schreibbaren MQTT-Topics würde ich einzeln lassen

Dann hätten wir 3 inverterspezifische Topics, je nach Anzahl der Inverter entsprechend Vielfaches davon. Wobei 2 ja nur einmal abgefragt werden. Aktualisierung sobald neue Daten vorhanden.

Das General mit dem Total würde einmal die Minute reichen.

wären bei meinen 16 Invertern dann insgesamt 54 Topics, wobei sich nur 17 zeitlich wiederholen. Im Gegensatz zu aktuell über 1000 Topics.

Da OpenDTU doch nicht ganz so unterschiedlich erscheint, müßte man sich nur auf die Namensgebung einigen. Hat Ahoy oder OpenDTU keinen entsprechenden Wert würde ich dafür einen leeren Wert (Platzhalter) senden.

Ach ja, und bitte die Heuristikdaten mit in die Radio-Statistik aufnehmen 😉

[knickohr]

Das sieht schon mal gar nicht schlecht aus 👍

Auch wenn jetzt die HW und Firmware-Infos als JSON kommen, müssen sie nicht retained sein. Oder ist das so wichtig ? 😉

mqtt-retained.txt

[lumapu]

wenn sie nicht retained sind, dann verschwinden sie nach kurzer zeit für immer oder?

[knickohr]

Der Broker hält sie halt nicht vor. Genau genommen werden sie einfach nur raus geplärrt. Der Client muß sie dann einsammeln und selbst speichern.

Bei retained werden die Werte im Broker gespeichert. Und jedesmal wenn sich ein Client subscribed, bekommt er sie vor die Nase gepfeffert.

[knickohr]

JSON-Payload ist mit der 0.8.123 optional auswählbar 👍