lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
953 stars 224 forks source link

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

Open knickohr opened 1 year ago

knickohr commented 1 year ago

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 😵

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

(Wird weiter editiert, Geduld junger Padawan)

stefan123t commented 1 year ago

@knickohr ich warte ganz geduldig, versprochen :innocent: 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 commented 1 year ago

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 commented 9 months ago

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 commented 9 months ago

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 ?

knickohr commented 9 months ago

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 commented 9 months ago

@knickohr habe Deine Anmerkungen oben eingearbeitet. Hier noch der Hinweis auf die Diskussion Max. Leistung aller WRs zusammen anpassen #1608 https://github.com/tbnobody/OpenDTU/discussions/1608#discussioncomment-7988430

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.

knickohr commented 9 months ago

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 commented 9 months ago

Vorschlag :

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

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 commented 8 months ago

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 commented 8 months ago

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

knickohr commented 8 months ago

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 commented 5 months ago

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