Ahoy DTU API Dokumentation?

Das interessiert mich auch. Auch ich würde aus dem DTU Projekt nur den SW-Anteil zur Kommunikation nutzen, den man braucht, um dem Hoymiles WR mitzuteilen, welche maximale Leistung er liefern soll.

Wenn die Projektersteller ihren Kram nicht dokumentieren wollen, kann man sich die Dokumentation auch selbst erarbeiten, dazu muss man sich halt den Sourcecode und andere Fragmente ansehen.

https://github.com/lumapu/ahoy

Man könnte natürlich auch versuchen, die Projektersteller zu kontaktieren und nachzufragen ...

Das kann man sich mal anschauen:

https://github.com/hoylabs/OpenDTU-OnBattery

Harald K. schrieb:

dazu muss man sich halt den Sourcecode und andere Fragmente ansehen.

Ist nicht leicht zu durchschauen...

Harald K. schrieb:

Wenn die Projektersteller ihren Kram nicht dokumentieren wollen, kann man sich die Dokumentation auch selbst erarbeiten, dazu muss man sich halt den Sourcecode und andere Fragmente ansehen.

Nach dem Motto, es gibt keine bessere Dokumentation als den Sourcecode selbst.

Ich werde es mal mit Open-DTU probieren. Immerhin scheint das API HTTP als Protokoll zu benutzen. Immerhin scheinen auch die Abfragen angegeben zu sein. Das ist schon mal ein Anfang, ich werde einfach mal probieren, was die Software darauf antwortet.

Fritz G. schrieb:

Nach dem Motto, es gibt keine bessere Dokumentation als den Sourcecode selbst.

Nun, wenn die Projektersteller den Schwerpunkt so gesetzt haben, wie sie ihn wohl gesetzt haben, dann muss man mit dem leben, was man finden kann.

Oder das Projekt links liegen lassen, denn wenn die Dokumentationsseite so "vollständig" ist, ist die Frage, ob denn die funktionale Seite vollständiger und gegebenenfalls sogar zuverlässig ist, nicht völlig ungerechtfertigt.

Wenn zu wenig Ressourcen da sind, wird in der Entwicklung priorisiert. Kenne ich, ist mein Job. Und dann leidet oft die Dokumentation als erstes, dann wird der Tunnelblick enger und irgendwann wird auch das Ziel kleiner, weil zwischendrin die Anforderungen abgespeckt werden, einfach, weil man überhaupt noch irgendwo ankommen möchte.

Oder das ganze ist 'ne Leiche, weil schon vor Erreichen irgendeines Ziels das ganze abgebrochen werden musste.

Sowas findet sich leider auch des öfteren auf Github & Co.

Hier, im vorliegenden Fall, scheint vor etwas über einem halben Jahr das letzte Mal was passiert zu sein; von da ist das letzte Release.

Das muss nicht bedeuten, daß das Ding tot ist -- es gibt exzellente Software, die mehrere Jahre lang nicht weiterentwickelt wurde und dennoch nutzbar ist (wie z.B. meine favorisierte 3d-Konstruktionssoftware openscad), aber ...

Was ich gern aus dem DTU Projekt rausholen würde ist des Abfragen / Senden des aktuellen Leistungslimits des HM, damit ich ihn steuern kann, wenn er an einer Batterie hängt. Das würde mir zunächst ausreichen.

Das Projekt ist über die Jahre aber so gewachsen und komplex geworden, dass ich mich schwer tue, genau das rauszuziehen.

Fritz G. schrieb:

Ich werde es mal mit Open-DTU probieren.

Das wollte ich auch gerade vorschlagen - OpenDTU hat sich irgendwie besser durchgesetzt als Ahoy und ist besser dokumentiert

Fritz G. schrieb:

Ich werde es mal mit Open-DTU probieren.

Versuche es mal mit Chat Gpt. Da bekommst du sehr schnell brauchbare Antworten, jedenfalls sehr viel schneller, als sich durch den Fred hier durch zu wühlen. Zumindest bis 04/2022 haben sie da auf Arduino entwickelt. Danach war ein schickes Web-Interface interessanter ;-)

Harald K. schrieb:

Wenn die Projektersteller ihren Kram nicht dokumentieren wollen, kann man sich die Dokumentation auch selbst erarbeiten, dazu muss man sich halt den Sourcecode und andere Fragmente ansehen.

Ja man kann Vieles. [Ironie] Man kann sich auch einen Knopf an die Backe nähen und ein Klavier dran hängen, dann weis man, wie schwer Musik ist. [/Ironie]

Fremden Quellcode analysieren ist in der Regel schon ein ein großer Aufwand, den man eigentlich nur betreibt, wenn es gar nicht anders geht bzw. es keinen Plan B gibt. Man muß sich in die Gedankenwelt des Entwicklers einarbeiten, was auch bei gut dokumentierten Sourcecode nicht immer ganz einfach ist. Dinge die für denjenigen der es verzapft hat völlig logisch sind, müssen das für andere eben nicht sein und genau das macht es am Ende schwer.

Ahoy DTU ist schon ein recht komplexes Projekt und man steigt da nicht so schnell durch. Ich habe mich auch schon daran versucht, weil die zu meinem Wechselrichter (TSUN) gelieferte SW mir nicht zugesagt hat, um es mal vorsichtig auszudrücken. Am Ende habe ich es sein gelassen und mich mit der Hersteller SW mehr oder weniger arrangiert.

🍀🥰💪

Fritz G. schrieb:

Über MQTT will ich aber nicht gehen, da ich für den dafür notwendigen Broker ja wieder über die Cloud gehen muss, wass den Sinn der DTU eigentlich schon wieder konterkariert.

Wieso willst du MQTT in die Cloud packen? Ist das so ein typisches Missverständnis wie "GIT geht nur über GitHub" und "HTTP/Web geht nur über Google"?

So ein MQTT-Server ist sehr leichtgewichtig, den kannst du z.B. auf deinem WLan-Router mitlaufen lassen, sogar eine Version für ESP32/ESP8266 gäbe es (PicoMQTT), die dort nebenbei laufen kann, ohne viele Resourcen zu brauchen. Natürlich kein Performance-Wunder am ESP8266, aber ein paar hundert Messages pro Sekunde mit >100kb/sec Durchsatz reicht für die meisten "Smart Home" Sachen dicke aus.