Solar Passthrough with 2 Victrons

[dirk-schulz]

Hey, there,
OpenDTU on battery is really a great solution and solar passthrough is from the initial idea great.

But with more than one Victron solar passthrough can only consider one of my two Victrons. Result is, that the energy from the second victron only charges the battery and will not directly be used to set the inverter limit in dynamic power limiter.
(see my solution in this discussion: 360 )

@helgeerbe: Is there any chance, that I can publish e.g. via MQTT the summed up panel energy of all victrons to OpenDTU, so that this value can be used by dynamic power limiter instead of the value determined by serial communication from the Victron?

Otherway arround would be to connect the second victron also to opendtu, but it supports currently only one victron. Or any plans to add this feature?
(I tested to sync both victrons via bluetooth with the hope to get both values or the summed up value of both over the one serial connection. But the serial output of any of the victrons only includes values from the one connected victron.)

[schlimmchen]

Is there any chance, that I can publish e.g. via MQTT the summed up panel energy of all victrons to OpenDTU, so that this value can be used by dynamic power limiter instead of the value determined by serial communication from the Victron?

This is not implemented. Although, this might make sense. It would allow to support the solar passthrough feature with other charge controllers as long as the user takes care that their respective output power is available through MQTT. However, this needs significant changes in the configuration: It makes little sense to configure the source for the solar energy being produced within the DPL settings. So a new page/controller "Solar Power" must be implemented that can either read from VE.Direct or from MQTT. In the latter case, additional settings (topic) must be set. This is no easy task to do properly.

Or any plans to add this feature?

Yes, this was discussed a multitude of times and many people are interested in this, which is understandable. I also find this a very interesting feature to implement, but there are much more pressing issues to attack first, at least for me. So, how are your C++ skills? 😉

[dirk-schulz]

@schlimmchen
Sorry, schwenke mal auf Deutsch, wenn's okay ist.
Hmmm, meine C++ Kenntnisse sind etwas eingestaubt. Zumindest gab es da noch kein GitHub. Würde mich aber nicht scheuen, was Neues zu probieren. (bin halt kein Programmier-Profi)

Wenn ich den Quellcode nach Quersichtung richtig deute, müsste die Weichenstellung in der powerlimiter.cpp bei der Funktion getSolarChargePower() erfolgen. Diese zieht, wenn canUseDirectSolarPower() true, sich stumpf den Strom und Spannung vom Victron und ermittelt daraus die aktuellen Panel Leistung. Im Logic Case 2+5 wird dieser dann herangezogen um das Limit zu setzen/beeinflussen.
Hier könnte man auch z.B. mit neuer boolean Variablen canUseRemoteSolarPower() auch noch einen mqttRemoteSolarPower Wert hinzurechnen. (wenn also sowohl ein Victron Seriell dran ist + den MQTT Wert z.B. von Home assistant oder anderer mqtt Quelle)

Klar, man müsste eine Konfigseite bauen (in configuration.cpp + .h?), wo man zwischen VE.Direct und MQTT wählen kann (z.B. canUseRemoteSolarPower()). Und das MQTT lesen müsste man integrieren mit Variablen, die den mqttRemoteSolarPower beinhaltet. Und natürlich eine config Variable für die MQTT topic.

Was ich noch nicht verstanden habe: Habt ihr ein Namenskonzept oder wie stellt ihr eine Überschneidung mit dem OpenDTU master sicher? Denn da sind ja in den .json die Übersetzungen für die Webseite, die ebenfalls um die neuen Config-Parameter ergänzt werden müsste.
Meintest Du das so? Habe nur ehrlich gestanden noch nicht mit GitHub zwecks Quellcode Verwaltung gearbeitet. Kann ich mir da eine Kopie in "mein" GitHub ziehen und diese in mein lokales Visual Studio Code einbinden? Und theoretisch euch zu meiner Kopie Zugriff geben, falls ihr das - sollte es mir überhaupt gelingen - dann wieder in euer Projekt aufnehmen wollt?

[madmartin]

Was die Möglichkeit mehrere Victron Lader per Ve.Direct seriell anzuschliessen betrifft wollte ich mich daran machen, sobald @schlimmchen mit seinem PR #319 fertig ist, denn das betrifft auch die serielle Kommunikation.
In der Zwischenzeit bin ich dabei mir einen "Victron emulator" zu bauen, damit ich das nicht an der produktiv-Hardware testen muß.

[schlimmchen]

In der Zwischenzeit bin ich dabei mir einen "Victron emulator" zu bauen, damit ich das nicht an der produktiv-Hardware testen muß.

Sehr geil! Ist der öffentlich? Welche Hardware und Software braucht der?

Im Übrigen habe ich gerade @philippsandhaus angestachelt in #205 den VeDirectFrameHandler auseinanderzunehmen. Vielleicht solltet ihr euch abstimmen (und ich mich raushalten?).

Jedenfalls seh ich zu, dass #319 bereit zum mergen wird. In #205 habe auch auch bemerkt:

Since you are the second person to wait for that PR, I will work hard to bring it into a state that allows merging. That will mean that even more features are coming at a later point in time, but that's fine.

[schlimmchen]

Was ich noch nicht verstanden habe: Habt ihr ein Namenskonzept oder wie stellt ihr eine Überschneidung mit dem OpenDTU master sicher?

@dirk-schulz Da gibt es nur mäßig Probleme, weil OpenDTU-OnBattery features hinzubaut, statt bestehende (all zu stark) zu verändern. Da die Software und auch z.B. die Übersetzungen einigermaßen gekapselt sind, lassen sich Änderungen einigermaßen gut mergen. Das ist dann @helgeerbe's Problem 😉

Habe nur ehrlich gestanden noch nicht mit GitHub zwecks Quellcode Verwaltung gearbeitet. Kann ich mir da eine Kopie in "mein" GitHub ziehen und diese in mein lokales Visual Studio Code einbinden? Und theoretisch euch zu meiner Kopie Zugriff geben, falls ihr das - sollte es mir überhaupt gelingen - dann wieder in euer Projekt aufnehmen wollt?

Ja, so ungefähr. Die Kopie "in dein Github ziehen" heißt "make a fork". Daran kannst du dann arbeiten, wie dir beliebt. Damit ist gemeint: Du klonst das Repository auf deinen Rechner, macht Änderungen, fasst die in commits zusammen, und schiebst diese commits ("push") in deinen "fork". Wenn du fertig bist mit deiner Arbeit, erstellst du einen Pull Request ("Die Bitte, dass @helgeerbe deinen Code in dieses Projekt importiert").

Wie GIT und GitHub funktionieren, kann dir das Internet erklären. Wenn du da keinerlei Erfahrung hast, musst du darin leider erst ein wenig investieren.

Ansonsten hast du dich gefühlt sehr versteift auf den MQTT Victron. Das wäre ja ein anderen Feature. Die Unterstützung für mehrere Victrons beinhaltet vor allem dafür zu sorgen, dass mehrere VeDirectFrameHandler Instanzen existieren und konfiguriert werden können.

Im Übrigen steht dieses Feature in Konflikt mit @philippsandhaus Arbeit zu #205. Da gäbe es ggf. Abstimmungsbedarf zumindest bzgl. dessen, wer Ernst macht und ob ihr euch ggf. ergänzen könntet.

[dirk-schulz]

@schlimmchen
Okay, werde mich mal mit GitHub und dem "fork" mal auseinander setzen. Danke für den einleitenden "Crashkurs", hilft mir, der bislang noch nichts mit gitHub gemacht hat.

Nun ja, was heißt "gefühlt versteift auf den MQTT Victron"?
In der Praxis verspreche ich mir eine bessere Solarausbeute, wenn der Powerlimiter beide/alle Victrons berücksichtigen würde. Aktuell beeinflusst nur ein Victron den Powerlimiter und der zweite Victron lädt zu 100% in die Batterie. Die Batterie ist somit sehr schnell voll und sobald diese voll ist und im Haus zu wenig verbraucht wird, stagniert meist ein Victron und die Panels gehen in die Leerlaufspannung, weil am Ladeausgang zu wenig gezogen wird.
Und meine Tendenz zu MQTT hat 3 Gründe:

1. Nach Sichtung des Codes und mit meinen beschränkten Programmierkenntnissen, habe ich das Gefühl das MQTT zur Beeinflussung des Powerlimiters schneller und einfacher einzubauen wäre. Bei der seriellen Abfrage der Victrons müsste eine Schleife pro Victron (zum auslesen, zum MQTT schreiben, die Configs pro Victron, etc.) eingebaut werden, in der jeweils diese seriell abgefragt werden. Das überlasse ich lieber Euch Profis ;-)

2. Ich habe das Gefühl (aber keine belastbaren Erkenntnisse), dass je mehr an OpenDTU on Battery "drangehangen" wird, irgendwann die Hardware ausgereizt ist. Wie seht ihr das? Wie komme ich darauf?
   Nur Inverter = okay
   Inverter + CAN = okay
   Inverter + CAN + Smartmeter per MQTT auslesen = selten sporadisch keine Werte bei Homeassistant (1-2 mal am Tag)
   Inverter + CAN + Smartmeter + Victron = sporadisch keine Werte in HA (nicht verfügbar alle 20-30min) und zwischendurch wird auch der Inverter als offline angezeigt im Display. Gehe ich wieder zurück auf nur Inverter + CAN-Bus läuft wieder alles stabil.
   Was ist, wenn nun noch ein Victron ausgelesen wird? Wird es dann noch instabiler? Wie seht ihr das als Profis? Ist das ein HW Limit von dem EPS32 oder müsste da von der Programmierung was optimiert werden oder ist das eher ein lokales Problem bei mir (z.B. HW Problem oder MQTT Broker)? Lasse nun z.B. anstelle des Strommeters (Hichi) wieder die Verbrauchswerte vom Shelly 3EM ziehen und habe Subjektiv das Gefühl, dass weniger "offline" des Inverters angezeigt wird. (beides eigentlich MQTT - somit keine Idee, was hier konkret den Unterschied in der Auswirkung ausmacht)

3. Bei wievielen Victrons ist Ausbauende? Wenn nun 2 (wegen 2 hw seriell) möglich sind, was mache ich wenn ich noch 2 weitere einbinden wollte? Oder was wäre, wenn ich morgen anstelle Victron einen anderen Hersteller verwenden will? Habe es noch nicht bis zum Ende durchdacht, aber per MQTT stelle ich mir vor, dass man flexibler ist, oder nicht? Da bezieht man einmal per MQTT die Panelleistung total (egal wieviele Panels und welche Quelle) und kann damit den Inverter beeinflussen.

Ja, gebe zu, es könnte mit MQTT nur bestimmte Usecases abgedeckt sein. Ist halt die Frage, wieviele den Usecase sehen und auch haben.

[schlimmchen]

1. Du hast richtig verstanden, dass die loop() jeweils über die beiden (bzw. beliebig vielen) Victron-Instanzen laufen muss. Ich stelle mir da allerdings einen Controller vor, der eine loop() hat und eine variable Anzahl an Victron-Instanzen abklappert. Ob die von dir vorgesehene Anpassung über MQTT einfacher und schneller zu implementieren ist, wage ich zu bezweifeln.
2. Es gibt selbstverständlich Limits, aber ein oder zwei UARTs mehr dürfen da meiner Einschätzung nach keinen Unterschied machen. Es kann aber auch sein, dass ich da ein wenig naiv bin. Der Knackpunkt ist ggf. die Tatsache, dass die UARTs per Software emuliert werden müssen. *) Jedenfalls ist es ärgerlich zu lesen, dass du Probleme hast mit der Zuverlässigkeit. Wenn du das genauer erfassen kannst, lohnt es sich natürlich ein Issue zu öffnen.
3. Das ist ehrlich gesagt ein gutes Argument. Vor allem der Punkt über die Anbindung sonstiger Laderegler. MQTT wäre eine allgemein funktionierende Schnittstelle. Wie die Daten über die Solarleistung da reinkommen, muss jeder selbst klären, aber OpenDTU-OnBattery könnte dann damit arbeiten.

Na dann schlage ich vor du konzentrierst dich auf dieses Feature? Dann gibt's auch keinen Konflikt mit #205. 👍

*) Ich denke gerade zum ersten Mal darüber nach, UARTs in Hardware nachzurüsten. Beispiel: MAX14830. Da scheint mir aber sowohl die Hardware von der Stange zu fehlen (Breakout-Boards) als auch die Softwareunterstützung. Das ist mega spannend, aber die Integration ohne bestehende Hard-/Software kostet super viel Zeit... Schauen wir mal, ob Software-UART uns retten kann. Das steht seit Monaten auf meiner Liste, dass ich das wenigstens einmal ausprobieren möchte.

[stanpete78]

Ich würde auch die Idee mit MQTT moralisch unterstützen wollen. Das wäre erstmal die flexibelste Möglichkeit.

[dirk-schulz]

@schlimmchen:
Kurzer Zwischenstand: Hut ab, ihr könnt wirklich programmieren.
Ich versuche seit Tagen vergebens eine MQTT Abfrage hinzubekommen und glaube ich muss da aufgeben.
Habe für mich eine eigene Version compiliert, bei der ich stumpf die Victron Werte für den Solar Passthrough verdoppele (weil meine beiden Panelpaare und Victrons ähnliche Leistung bringen). Das läuft seit einer Woche stabil und liefert für mein Setup gute Solar Passthrough Ergebnisse. Okay ja, und programmier technisch sehr geschummelt und so schlecht für andere Nutzbar. Daher muss ich wohl mit meinen beschränkten Programmierkenntnissen hier passen und überlasse Euch Profis besser die Bühne.
Ich würde noch in meiner Version versuchen, ob man das max Limit von DPL per MQTT setzen kann.
Hast Du einen Tipp, wo das sein müsste? Oder habt ihr das eh als Feature geplant?

[schlimmchen]

Related: #457