Wishlist - Collection of changes / new functions

[lumapu]

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

• [x] MqTT optinal gesamt Payload als JSON
• [ ] Zero Export (für jeden Inverter)
• [x] night behaviour für jeden Inverter (für Batterieeinspeisung interessant)
• [x] optional automatisches PA für jeden Inverter (abhängig von der Heuristik)
• [x] Ausgabe der Statistikdaten/Heuristikdaten pro Inverter über MQTT, gerne als JSON
• [ ] #1666
• [ ] Auslesen gängiger BMS-Systeme (Daly, Vicron, ...)
• [ ] Nullen der Tageswerte (doppeltes 0x52-Kommando lt. "Control instruction Zeilen 110ff")
• [ ] Löschen von Alarmen (falls möglich, afaik nicht dokumentiert).
• [x] Maximaltemperatur der Inverter
• [x] Uhrzeit wann max-power erreicht wurde anzeigen
• [ ] weitere Option die Vortageswerte zurückzusetzen: bei Inverter start, evtl. auch nur Offset von Mitternacht
• [ ] MqTT subscribe um aktuelle Last im Haus in Ahoy verfügbar zu haben (z.B. für Display, Anzeige in der WebUI, ZeroExport)
• [ ] Active Power Control über mehrere Inverter hinweg
• [ ] Acknowledge für Inverter-Power commands, wenn verfügbar: on / off / restart
• [ ] Zeitlich begrenztes Power-Limit (quasi Timer für x-Minuten / Stunden)
• [ ] publish der aktuellen Leistung an Webserver wie z.B. OpenEnergyProject, PVOutput
• [x] #1667
• [x] lesen und anzeigen der Grid Profile Settings je Inverter
• [ ] editieren und aktualisieren des Grid Profile pro Inverter
• [x] mDNS support
• [x] automatische Erkennung des IRQ (interrupt) Pins des NRF
• [ ] Inverter State-Machine Timeouts konfigurierbar (aktuell fix auf 5min und 15min)
• [x] Step-by-Step Wizard Einrichtung
• [x] Custom Link
• [ ] Buttons für 600 / 800W Leistungsbegrenzung
• [ ] Tooltip mit Uhrzeit auch für Max-Power der Module
• [ ] RX Modus, um einer anderen DTU zuzuhören
• [ ] Script Sprache implementieren, um individuelle Anpassungen ohne Firmwareänderung zu ermöglichen (geht das überhaupt?)
• [ ] #1633
• [ ] #1572
• [ ] #1554

⬆ Improvements

• [x] Einbau der NRF24 Heuristik (@oberfritze)
• [x] Radio-Statistik für jeden Inverter individuell
• [x] NRF24 PA für jeden Inverter individuell
• [x] CMT Frequenz und Leistung einstellbar
• [x] Power-Limit als Prometheus Metrik exportieren
• [ ] Inverter Kommunikations Timeouts konfigurierbar machen (speziell für Akkubetrieb benötigt)
• [ ] GPIO3 bei CMT optional machen
• [x] reset max Wert in Total (WebUI) erst um Mitternacht
• [ ] remove / rename 'Irradiation'
• [x] Ausgabe der loss-Daten über MQTT ähnlich oder mit den Statistikdaten/Heuristikdaten
• [x] Erweiterung der max. Anzahl der Inverter für den ESP32-S3 (Fusion Board)
• [ ] #1668
• [x] Powerlimit mit einer Kommastelle beim Schreiben über MQTT
• [ ] download history graph data
• [x] Hex Dump von Grid Profile
• [x] protect Active Power Control if password is set
• [ ] Pixel-Shift + Motion sensor option (both at the same time)
• [x] Übertragung Total Max Power über MqTT
• [ ] Übertragung Total Blindleistung über MqTT
• [ ] #1669
• [ ] Pixel shift und Motion Sensor simultan
• [ ] RF24 RSSI per MqTT (evtl. true / false)
• [ ] no pa+lna Option, da manche nRF chips startFastWrite() nicht richtig unterstützen
• [ ] IP Adresse auf dem Display nur die erste Minute anzeigen, oder evtl. Auswahl was angezeigt werden soll
• [ ] Ajax von /live auf Websockets umstellen, evtl. zuerst das Invtervall separieren von dem Abfrageintervall
• [ ] Temperatursensoroffset, um Wechselrichter (in der Anzeige) kalibrieren zu können
• [ ] Intervall auch auf der /history Seite anzeigen
• [x] HTML Titel soll devname enthalten
• [ ] Gateway als NTP Server fallback - ohne Option
• [ ] neuer Status Standby, wenn ein Inverter manuell ausgeschaltet wurde
• [x] #1614

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

• [ ] Auswahl der Inverter, die auf dem Display summiert werden sollen
• [ ] Zentrale Eingabe, um alle Inverter auf einen bestimmten Prozentsatz zu limitieren

🕗 Obsolete Ideas

• [ ] Full Refresh für ePaper über MQTT triggerbar
• [ ] full Refresh beim Booten für ePaper nur bei cold Boot)
• [ ] Einbau eines Debug-Levels für die serielle Konsole

last update: 2024-06-09

[knickohr]

• JSON payload optional wählbar
• Zero Export (für jeden Inverter)
• Einbau der Heuristik
• Statistik für jeden Inverter (bereits in 61 drin ?)
• PA für jeden Inverter
• night behaviour für jeden Inverter (für Batterieeinspeisung interessant)
• optional automatisches PA für jeden Inverter (abhängig von der Heuristik)
• Ausgabe der Statistikdaten/Heuristikdaten pro Inverter über MQTT, gerne als JSON
• Einbau eines Debug-Levels für die serielle Konsole
• Und ein ganz spezielles (persönliches) Feature : Full Refresh beim Booten für ePaper nur bei cold Boot)
• Und gleich noch eins (spezielles persönliches) : Full Refresh für ePaper über MQTT triggerbar
• Ach ja : unterbinden der lästigen last_success Meldungen. Nur für jeden Inverter, nicht für alle, und dann auch nur wenn sich der Wert geändert hat. Ganz speziell jene die kommen wenn sich ein Inverter nicht meldet oder diese noch in der Startphase sind. Dann donnern pro payload immer alle last_success für alle Inverter gleichzeitig raus. Siehe auch Issue #1124

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

[rejoe2]

Zu den JSON-Payloads für MQTT noch:

• pro Inverter ein Topic, gesendet wird immer dann, wenn sich was ändert (und dann alles geänderte auf einmal)
• Die AhoyDTU bekommt (je?) einen eigenen Topic für den ESP-Zustand und ggf. die Summen-Felder

Plugins:

• SML (analog Tasmota? Ein separates script hatte auch @Oberfritze in der all-in-one drin; das müßte man ggf. konfigurierbar machen?)
• Auslesen gängiger BMS-Systeme (Daly, Vicron, ...)

Akku-Betrieb:

• Nullen der Tageswerte (doppeltes 0x52-Kommando lt. "Control instruction Zeilen 110ff")
• Löschen von Alarmen (falls möglich, afaik nicht dokumentiert).

[BastyESP]

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]

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]

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]

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 😂

[Gubi2023]

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

[reserve85]

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

[Joh49]

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]

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]

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

[irrwitzer42]

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]

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]

@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]

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:

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]

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

[MetaChuh]

@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]

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

[Starfoxfs]

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]

Bereits implementiert, siehe Display-Settings.

[Starfoxfs]

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

[SilverSurfer2000]

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]

wish: more shunshine for better diagrams ;-)

[fsck-block]

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]

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]

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]

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]

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]

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]

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