search

lumapu / ahoy

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

Wishlist - Collection of changes / new functions #1199

Open lumapu opened 8 months ago

lumapu commented 8 months ago

I will collect all wishes to Ahoy in a combined issue. This first post will be edited to have everything merged together. You can answer in English or German.

⭐ new Features

⬆ Improvements

🪄 Individual Improvments (only a bunch of users will use it)

🕗 Obsolete Ideas

last update: 2024-06-09

knickohr commented 8 months ago

Bei Fragen, bitte fragen. Einiges ist vielleicht nicht gleich verständlich und bedarf einer Erklärung 😉

rejoe2 commented 8 months ago

Zu den JSON-Payloads für MQTT noch:

Plugins:

Akku-Betrieb:

BastyESP commented 8 months ago

Wir hatten ja mal über die Maximal Werte geschrieben, das ist ja mittlerweile implementiert, allerdings wäre es (gut die heiße Jahreszeit ist zwar Rum) es für die Inverter Temperatur noch schön.

Für meinen Teil der sich jeden Tag einen Screenshot je Inverter macht.... wäre löschen nicht um Mitternacht sondern bei Inverter start schön, denn Mitternacht wird bei Spätschicht manchmal eng...

Wesie commented 8 months ago

Wish: Anzeige der aktuellen Last neben der gerade erzeugten Watt. Die aktuelle Messung der Last im Stromnetz wird m.E. vielfach mit Sensoren, welche in Smart Home Zentralen wie homee , Home Assistent etc.. angemeldet sind, erfasst. Single Lösungen wie ein einzelnes Shelly sind auch möglich, jedoch vermutlich eher nur in der Anfangsphase von Smarthome anzutreffen. Um das Ganze auch in SW einfach zu halten, allein schon von der Maintance her (Bei Einzel-Gerätunterstützung: Protokolländerungen von x Geräten, hinzufügen von anderen Geräten bedeutet jedesmal Änderungen im Code, mehr Codezeilen, irgendwann Speicherplatzprobleme...), würde ich einen Webhook vorschlagen, mit welchem die Smarthome Zentralen die derzeitige Last zur DTU übermitteln können und entsprechenden dieser Wert zur Anzeige im Display und/oder auch für andere Feature (s. derzeitige Entwicklung der 0 Einspeisung) benutzt werden.

huaak commented 8 months ago

Hi, mich würde SML (gerne auch die aktuelle Hauslast vom Tasmota mit Lesekopf via Netzwerk senden lassen(weil Stromkasten und DTU vielleicht -wie auch hier- nicht direkt beisammen sind) und einbinden und verarbeiten..) interessieren..allerdings nutze ich keinerlei Smart Home Zentrale weil ich neben der DTU nichts anderes brauche, als ein paar Relais die Ertrags- oder Verbrauchszustandsabhängig von einem ESP mit Tasmota geschaltet werden. In der Verbindung mit SML lässt sich vielleicht ggf. auch Zero Export, wobei es mir persönlich nicht so tragisch ist, wenn Überschuss der nicht verbraucht wird rausgeht.

Interessanter wäre die Möglichkeit die Gesamtleistung von mehreren Invertern gemeinsam zu begrenzen..zb. bei Leuten die z.B. mit 3 300ern aktuell bis 600 w und demnächst 800w in die Hausleitung bringen möchten, oder mit mehreren Invertern in verschiedenen Ausrichtungen arbeiten (Hier wäre auch ein Timestamp bei der jeweiligen max. AC Powerangabe praktisch.) und ggf in einer Überschneidungphase im Sommer temporär für 1-2 Stunden zu viel Ertrag haben.

Was das Rücksetzen der Daten angeht fand ich besonders im Sommer Mitternacht auch teils recht früh und würde da eine Lösung beim Restart am nächsten Morgen oder bei Sonnenaufgang präferieren, oder zumindest die Möglichkeit den Reset in den Einstellungen auf 1, 2 Uhr oder Mitternacht UTC legen/verschieben zu können.

knickohr commented 8 months ago

Mit Hilfe der Nulleinspeisung kann man sich die aktuelle Leistung des Verbrauchs und der Erzeugung anzeigen lassen. Das funktioniert mit einem Hichi (Tasmota) oder dem Shelly 3EM. Wer die Nulleinspeisung nicht braucht, kann den Wert so hoch einstellen das er nie erreicht wird. Ist zumindest in den Pre-DEV Versionen (noch nicht verfügbar) möglich.

Achtung Spoiler 😂

image
Gubi2023 commented 8 months ago

https://github.com/lumapu/ahoy/issues/1123#issue-1867952141 fände ich immer noch sinnvoll

reserve85 commented 8 months ago

https://github.com/lumapu/ahoy/issues/1162 😃

Joh49 commented 8 months ago

Wunsch: zeitlich begrenztes Power Limit. Habe die Anlage auf 600W begrenzt, zum Laden einer Batterie oder beim Betrieb eines Stromverbrauchers sollte man die Leistung für 5 bis 300 Minuten auf einen Bedarfswert hochsetzen können und nach Ablauf der Zeit sollte das System wieder auf die normale Begrenzung oder einen einzustellenden Standardwert zurückkehren.

gone-for-coding commented 8 months ago

Ich finde es gut, dass in der Live-Ansicht nun einige Funktionen pro Wechselrichter verfügbar sind. Gerade für neue Nutzer ist das aber wahrscheinlich nicht ersichtlich, dass der Text klickbar ist. Ich würde mir eine optische Unterscheidung von regulärem Text wünschen.

Ich glaube es wurde schon viel diskutiert, aber eine Update-Funktion ohne den Umweg über einen Datei-Download nehmen zu müssen wäre großartig.

knickohr commented 8 months ago

Sendeleistung und Frequenz für den CMT einstellbar machen, siehe OpenDTU 😉

irrwitzer42 commented 8 months ago

TL;DR: Wunsch: aktuelles power-limit als prometheus Metrik exportieren

Long version: Ich nutze reserve85's grandios geilen ZeroExport daemon, dadurch erzeuge ich nur grob das, was ich brauche - mir fehlt aber jetzt in meiner Statistik (grafana dashboard) die Info, wieviel Strom ich hätte erzeugen können, wenn ich kein Limit gesetzt hätte. Sozusagen die verpasste Opportunitäts-Leistung ;-) Für die Berechnung, ob der Aufbau eines Speichers Sinn ergibt, wären diese Daten ganz nice.

Mir ist aber auch klar, dass das vielleicht nicht der richtige Ansatz ist (wegen der Reaktionszeit des Skriptes usw. dürfte das ordentlich auseinander laufen).

Wenn ich jedoch einfach nur ahoy_solar_Irradiation_ratio pro Panel mit dem jeweiligen Wp multipliziere und das aufaddiere, kommt das selbe dabei heraus, wie wenn ich direkt ahoy_solar_P_DC_watt aufaddiere. Entweder ich hab also einen Knoten im Hirn, oder auch der Irridiation-Wert wird anhand der vom WR gelieferten Leistung berechnet und ist somit schon dem Power-Limit unterworfen. Deshalb der Ansatz mit der Bitte nach einer Power-Limit Metrik.

Besten Dank an alle beteiligten für diese beiden genialen Projekte! Ich werde mich einbringen, wo ich es zu tun vermag.

Wesie commented 8 months ago

TL;DR: Wunsch: aktuelles power-limit als prometheus Metrik exportieren

Long version: Ich nutze reserve85's grandios geilen ZeroExport daemon, dadurch erzeuge ich nur grob das, was ich brauche - mir fehlt aber jetzt in meiner Statistik (grafana dashboard) die Info, wieviel Strom ich hätte erzeugen können, wenn ich kein Limit gesetzt hätte. Sozusagen die verpasste Opportunitäts-Leistung ;-) Für die Berechnung, ob der Aufbau eines Speichers Sinn ergibt, wären diese Daten ganz nice.

Mir ist aber auch klar, dass das vielleicht nicht der richtige Ansatz ist (wegen der Reaktionszeit des Skriptes usw. dürfte das ordentlich auseinander laufen).

Wenn ich jedoch einfach nur ahoy_solar_Irradiation_ratio pro Panel mit dem jeweiligen Wp multipliziere und das aufaddiere, kommt das selbe dabei heraus, wie wenn ich direkt ahoy_solar_P_DC_watt aufaddiere. Entweder ich hab also einen Knoten im Hirn, oder auch der Irridiation-Wert wird anhand der vom WR gelieferten Leistung berechnet und ist somit schon dem Power-Limit unterworfen. Deshalb der Ansatz mit der Bitte nach einer Power-Limit Metrik.

Besten Dank an alle beteiligten für diese beiden genialen Projekte! Ich werde mich einbringen, wo ich es zu tun vermag.

Nun, seit knapp 2 Tagen HA installiert (Adapter zu homee) Dort ist die eingespeiste Gesamtleistung und die aus dem Netz gezogene Leistung verfügbar. Ein virtuelles Device, welches die eingespeiste Watt berechnet und schon hat man im Dasboard Energy(default bei HA dabei den Überblick. Dies kann aber nicht in die DTU implementiert werden. HA dürfte sich jedoch dafür eignen entsprechende Befehle für die Einspeisung (und ggfls Batterieladung/Entladung) zu steuern .

MetaChuh commented 8 months ago

@irrwitzer42

geht einfacher:

man braucht nur die % drosselung loggen, und dann den ebenfalls geloggten p_ac wert durch diesen drossel % wert dividieren und dann mal 100 multiplizieren.

zusätzlich findet man im endpoint /api/inverter/id/0 (0-4 bei esp8266 oder 0-15 bei esp32) den wert max_pwr. dies ist der wert, den der jeweilige inverter liefern kann und sollte als maximum berechnungsausgabe genommen werden.

code-technisch:

$solar_ertrag_ungedrosselt = ($p_ac / $power_limit_read) * 100;

// failsafe: deckelung der theoretischen maximalleistung, falls % und W werte zeitlich nicht übereinstimmen,
// und dadurch zu hohe werte berechnet werden.
// ursache: latenz zwischen schneller hm inverter reaktion auf power limit befehle,
// und der wesentlich langsameren übertragung neuer hm p_ac messwerte)

if ($solar_ertrag_ungedrosselt > $max_pwr)
{
    $solar_ertrag_ungedrosselt = $max_pwr;
}

happy coding, sowie big kudos & greetings an @reserve85

simsasaile commented 8 months ago

Feature-Wunsch: Aktuelle Leistung direkt zu einem Webserver posten: Ich sende beispielsweise die Daten des Smart Meters (Hichi) mittels Tasmota-Scripts direkt zu der Logging und Visualisierungsplattform des OpenEnergyProjekts emonCMS. Da lässt sich dann eine schöne Eigenverbrauchsanzeige mit realisieren: ima_a486e32

Aber auch die Daten direkt zu pvoutput senden zu können, wäre sicherlich für viele eine spannende Option.

Update: Lese gerade von der Zero-Export Implementation, das könnte natürlich auch eine schöne Alternative sein, um eine Überschussanzeige, ähnlich wie in der Abbildung direkt lokal auf der AhoyDTU abzubilden.

DerDog89 commented 8 months ago

Wunsch: Möglichkeit per MQTT die Ahoy DTU neu zu starten. Ist aktuell ja nur manuell im System möglich.

MetaChuh commented 7 months ago

@DerDog89 der remote reboot befehl für die ahoy dtu im lokalen netzwerk ist: curl "http://dtu_ip/reboot"

(curl beispiel, jede art von http aufruf an diese url rebootet die dtu)

Starfoxfs commented 7 months ago

Wunsch: Das MQTT gesamt Payload als JSON wäre spitze (wie oben schon geschrieben), das würde vieles vereinfachen in Node-Red

Starfoxfs commented 7 months ago

Vielleicht noch eine Anregung bzw. ein Wunsch von mir:

Display Abschaltung bei Sunrise/Sunset Event, sprich wenn die Kommunikation zum Wechselrichter sowieso Offline ist dann Display Abschaltung. Bei Sunset dann wieder automatische Einschaltung von Kommunikation und Display.

knickohr commented 7 months ago

Bereits implementiert, siehe Display-Settings.

Starfoxfs commented 7 months ago

Ja cool, das hab ich noch gar nicht gesehen. :-)

SilverSurfer2000 commented 7 months ago

Auswahl (on/off) je Inverter, ob die Werte in 'total' eingerechnet werden (z.B. yield total).

(Ein Ausschluß einzelner Inverter aus den Totalwerten (z.B. bei Batteriebetrieb) dient der besseren Auswertungsmöglichkeiten der über mqtt: total gelieferten Werte in der Hausautomation).

hrolofs commented 7 months ago

wish: more shunshine for better diagrams ;-)

fsck-block commented 6 months ago

wish: mDNS support Damit man über den Namen und nicht nur über die IP-Adresse zugreifen kann.

Wünsche kann man sich auch selber erfüllen. mDNS support in PR #1262

juepi commented 6 months ago

Konfigurierbare Inverter-Timeouts wären toll, speziell im Akkubetrieb. Wenn die DC-Versorgung vom Inverter gekappt wird, dauert es momentan 15 Minuten, bis Ahoy-DTU den Inverter tatsächlich als "offline" markiert (<inverter-name>/available nach 5min Status 4, nach 15min Status 0). Speziell im Akkubetrieb (wo vermutlich ESP und Inverter oft recht nahe beisammen sind und daher eine stabile Funkverbindung gewährleistet ist) wäre es nett wenn man diese Timeouts deutlich reduzieren könnte.

knickohr commented 6 months ago

Konfigurierbare Inverter-Timeouts wären toll, speziell im Akkubetrieb. Wenn die DC-Versorgung vom Inverter gekappt wird, dauert es momentan 15 Minuten, bis Ahoy-DTU den Inverter tatsächlich als "offline" markiert (<inverter-name>/available nach 5min Status 4, nach 15min Status 0). Speziell im Akkubetrieb (wo vermutlich ESP und Inverter oft recht nahe beisammen sind und daher eine stabile Funkverbindung gewährleistet ist) wäre es nett wenn man diese Timeouts deutlich reduzieren könnte.

Also ich würde das sowieso nicht kappen, sondern sauber herunter fahren. Geht mit MQTT prima 😉

juepi commented 6 months ago

Also ich würde das sowieso nicht kappen, sondern sauber herunter fahren. Geht mit MQTT prima 😉

Hmm, wäre einen Versuch wert, weiß jemand wie viel Strom der Inverter bei einem derartigen "soft off" zieht (Zumindest der Funkteil des Inverters muss ja zu reaktivieren aktiv bleiben)? Nachdem ich das gerade in der Doku nicht finde, bitte um kurze Bestätigung dass das runterfahren über das Topic <TOPIC>/ctrl/power/<INVERTER_ID> = 0 geht, danke!

knickohr commented 6 months ago

Ja, das ist undokumentiert.

Korrekt, der Inverter „bleibt da“, aber eben im Status Offline. Meines Wissens sind es max. 3W was noch verbraucht werden.

Gubi2023 commented 6 months ago

z.Zt. werden bei jedem DTU-Neustart die Max-Werte gelöscht. Ich würde es sehr begrüssen, wenn man diese (tagsüber) erhalten könnte, da ich keine andere Speichermöglichkeit habe.

dtuuser commented 6 months ago

Besteht die Möglichkeit den Maxwert auch im Totalbereich erst auf Wunsch um 0 Uhr zurückzusetzen?

image

stefan123t commented 6 months ago

tbnobody hat bereits den noone2k Grid Profile parser im letzten OpenDTU release in commits tbnobody/OpenDTU@06651f3 und tbnobody/OpenDTU@00bc631 eingebaut. Es fehlen noch ein paar kleine Änderungen (unter Revisions).

Hier ist die Dokumentation für das DOWN_PRO 0x0E Command und INIT 0xFF SubCommand: https://github.com/lumapu/ahoy/wiki/Protocol#wie-wird-das-down_pro-0x0e--down_dat-0x0a-verwendet

Ein Beispiel Script für die Web API wäre:

espUrl="http://192.168.4.1/api"

def setGrid(iv):
    r = requests.post(espUrl + "/ctrl", json={
        "id": iv,
        "cmd": 0x0E, // DOWN_PRO
        "val": 0xFF, // INIT
        "payload": 0x0c 00 20 00 00 0b 08 fc 07 30 00 0f 09 f9 00 01 02 3f 00 32 0a 55 00 08 09 f9 10 00 13 88 12 8e 00 01 14 1e 00 01 20 00 00 01 30 03 02 58 09 cb 07 a3 13 92 12 8e 40 00 07 d0 00 10 50 00 00 01 13 9c 01 90 00 32 60 04 00 01 09 e2 0a 10 08 7e 80 00 00 00 08 44 01 2c 08 a0 09 6f 09 b4 01 2c 90 00 00 00 00 5f b0 00 00 00 01 f4 00 5f 70 02 00 01 27 10 a0 02 00 00 00 00 6e 8b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // remove spaces left for readability to have a single Hex/Binary blob
    })
    if r.status_code == 200:
        obj = r.json()
        print(obj)
    else:
        print(f"error http: {r.status_code}")

setGrid(0)
import requests
import json
technics42 commented 6 months ago

I would like to suggest removing calculated value of "irradiation" completely. This calculation doesn't make any sense, if your inverter is limiting power output and just calculates wrong value. This value just takes current power output of panel in relation of pre-entered max. peak power of panel. E.g. if your panel has 400Wp and inverter is limiting at 300W you will never get any useful value, it will be always limited at 75% - although real "irradiation" couldn't be better. On removing this irradiation one could also think about removing entering of peak values per panel.

knickohr commented 6 months ago

Es wird nichts entfernt, wer es nicht benötigt, braucht es nicht zu beachten 😉

technics42 commented 6 months ago

So you really want to keep calculating wrong values and also displaying them?! Wow, this definitively is a very strange attitude to me.

lumapu commented 5 months ago

Wie wäre es wenn wir es einfach korrigieren und die maximal mögliche Einstrahlung mit dem Limitfaktor ebenfalls reduzieren? Ich aus meiner Warte finde den Wert sehr hilfreich. Man könnte den Wert ja auch ausblenden, wenn ein Limit aktiv ist - dann sind alle glücklich

technics42 commented 5 months ago

This would only be percentage of max. possible power per inverter input. This is always limited by either Wp of module or max. inverter power input. It's not only if you define any power limit yourself. You even don't know exact max. possible Wp of any module - all modules do have tolerances. You currently are pretending a value with accuracy of 0.01%, while you cannot even get a real accuracy of 1%. In real life, you usually never get rated max. Wp of a module, so how to set real max. Wp of a module? While modules get older value of max Wp is also changing and of course this also depends on temperature all the time... To shorten this: it doesn't make sense to calculate this value and it's really not the "irradiation" you are calculating.

For what are you using this value? Why is it helpful for you? If you really want to stick to this value, then at least calculation should be corrected, accuracy should be adjusted and name should be changed to reflect the calculation itself (But I would strongly vote for removing this value at all.)

gone-for-coding commented 5 months ago

Die Argumente von @technics42 kann ich größtenteils nachvollziehen. Ich finde den Wert dennoch praktisch um schnell zu sehen, wie viel der Maximalleistung gerade anliegt. Die meisten werden die Module (deutlich) größer dimensioniert haben als das, was der Inverter pro Kanal schafft und man kann dann getrost den Maximalwert des Kanals einstellen und ggf. bei einem Limit herunterregeln.

Der Name ist allerdings sehr irreführend und ich wusste bis zu einem Blick in den Code auch nicht, was es sein soll. Vorschlag: Umbenennen in "Power %", als Ganzzahl und in der Doku einen Satz, dass es sich um die anteilige Leistung des Kanals in Prozent handelt.

technics42 commented 5 months ago

When changing "irradiation" to "power %", please keep in mind, we are talking about value per DC-input-channel. E.g. an 600W inverter with 2 channels does not have 2x300W at max for DC-input. It does limit AC power to approx. 2x300W and for example a HM-600 will reach about max. AC-power of 612W without any limits set. Which then is about max. DC-input of 2x320W - and this max. value is not documented by Hoymiles and may vary, depending on inverter types. One would also need to check, how this max. possible DC-value is really changed when using limits. Is it always the percentage of the max. value without limits, or do we always have some kind of offset? Please also keep in mind that limit setting on inverters is limiting all inputs. So I really can't imagine how this "power %" value could be used for triggering a change of power limits for your inverter.

knickohr commented 5 months ago

Folgende Punkte können aus der obigen Wunschliste wieder gestrichen werden weil sie nicht mehr nötig sind :

Zu dem Punkt hätte ich eine Frage :

Aufnahme weiterer Punkte :

lumapu commented 5 months ago

automatisches PA gibt's nicht, aber PA pro Inverter 😄. Lassen wir das automatisch weg oder machen wir den Haken raus?

knickohr commented 5 months ago

Mach die Automatik raus, ich schalte lieber manuell 😉

MetaChuh commented 5 months ago

wunschliste: frohe weihnachten, nicht stressen lassen, trotz weihnachten ;-), froh sein was wir alles haben, egal ob erreicht oder genutzt.

glg, metachuh

fsck-block commented 5 months ago

Wunsch: aktuelles power-limit als prometheus Metrik exportieren

Hallo @irrwitzer42 Noch interessiert an der Erweiterung?

Pro Inverter könnten die Werte für power_limit_read (float), power_limit_ack (boolean) und max_power (integer) relativ einfach in den Metriken bereitgestellt werden.

irrwitzer42 commented 5 months ago

Hi @fsck-block , ja! Das fände ich immernoch ziemlich cool! Dann könnte ich @reserve85 ‘ geniales zeroexport Tool auch von der anderen Seite her besser monitoren. Das macht zwar einen super job, aber aktiv Logfiles lesen ist nicht meine Lieblingsbeschäftigung ;)

Besten Dank nochmal an Alle Coder hier!

DanielR92 commented 5 months ago

Hallo lumapu,

feature wunsch auch von meiner Seite zum Aufschreiben:

Sobald man das erstemal die Ahoy-Seite aufruft (nicht im AP Mode). Sollte man via HTML eine Step-by-Step Wizard Einrichtung geleitet werden.

Damit Anfänger es hier etwas leichter haben... oder wäre der Aufwand zu viel des guten?

lumapu commented 5 months ago

@DanielR92 genau darüber habe ich auch schon öfter nachgedacht, das letzte Mal gestern 😉 Würde die User Experience bestimmt steigern, vor allem bis man mit dem heimischen WLAN verbunden ist ...

DanielR92 commented 5 months ago

Feature wish: Überall wo möglich ist hinter dem Text ein I für Inforamtion hinterlegen. Wie auf dem Foto als Beispiel:

grafik

fsck-block commented 5 months ago

Wunsch: aktuelles power-limit als prometheus Metrik exportieren

Hallo @irrwitzer42 Ich hab' mal den Prometheus EP soweit erweitert dass die Power Limit daten geliefert werden. Allerdings bin ich mir beim Wert ahoy_solar_inverter_power_limit_read {inverter="<name>"} etwas unschlüssig über den Wertebereich. Solange keine echten Daten bereitstehen arbeitet ahoy intern mit dem Wert 65535 und das wird dann auch so als Metrik geliefert: ahoy_solar_inverter_power_limit_read {inverter="<name>"} 65535 Der Wert wird dir vielleicht deine Darstellung etwas durcheinander bringen. Ich kann das auf einen anderen Wert abbilden aber was wäre denn ein guter Alternativwert?

irrwitzer42 commented 5 months ago

Hi @fsck-block

Vielen Dank schonmal für Deine Mühen! Wenn die ahoy nur im Falle fehlender Daten 65535 ausgibt und nicht auch im unlimittierten Fall (dann würde ich 100, bzw. 1 als Wert erwarten?), dann wäre es relativ einfach in der prometheus query einfach nur Werte < 65535 abzufragen - alles andere wird dann auch nicht visualisiert.

Ich würde daher sagen: für mich persönlich wäre es völlig in Ordnung, wenn Du 65535 einfach direkt durchreichst und keine eigene Logik einbauen musst.

Viele Grüße und allen hier an guadn Rutsch!

Andy-Op commented 5 months ago

Wunsch: Sunset und Sunrise inkl. einstellbarem Offset an GPIO33 als low/high oder anderem PIN ausgeben. Bei Zeiten zwischen Sunrise +/- Offset und Sunset +/- Offset = low, Bei Zeiten zwischen Sunset +/- Offset und Sunrise +/- Offset = high, Diese astronomische Uhr möchte ich als Indikator für eine Grundlast-Nachteinspeisung nehmen. Das Thema kommt ohnehin zunehmend. Wäre für mich ein Grund von openDTU hier her zu wechseln.

Relaissteuerung_Einspeisung_Balkonkraftwerk