feature: get absorption- and float-voltage from MPPTs

[SW-Niko]

PR includes the following:

• feature: read "absorption voltage" and "float voltage" from MPPTs
• extended: add some VE.Direct asynchronous messages descriptions
• extended: additional VictronMPPT class functions to get "MPPT-Mode", "absorption voltage" and "float voltage"
• bug fix: some HEX-Commands getting lost if we send to fast the next command
• correction of some typing errors

[SW-Niko]

Hallo @schlimmchen
Beim testen der neuen Funktionen ist mir aufgefallen, das die MPPTs nicht immer auf die HEX-Kommandos antworten.
Nur auf ungefähr 30% der HEX-Kommandos bekommen wir eine Antwort.
Das ist bis jetzt nicht weiter negativ aufgefallen, weil die Temperaturen nur angezeigt werden und die
"Network total DC power" zusätzlich als asynchrone Nachricht bei jeder Änderung des Wertes rein kommt.
Ich hab das mal mit einfachen Mitteln gefixt. Aber wenn wir noch mehr HEX-Kommandos versenden dann muss man das vermutlich anders lösen. Im log kann man nun schön verfolgen wie die Daten auf eine Anfrage reinkommen.
[VE.Direct MPPT 7/17] Sending Hex Command: :7ECED0075, Free FIFO-Buffer: 118
[VE.Direct MPPT 7/17] Hex Data: Smart Battery Sense Temperature (0xEDEC): 31.50°C

Momentan wird mit der "absorption voltage" und der "float voltage" noch nichts gemacht.
Ich bin beim testen eines "Solar-Passthrough Modes" der im MPPT Absorption- und Float-Mode funktioniert.
Sollte in den nächsten Tagen kommen.

[schlimmchen]

Beim testen der neuen Funktionen ist mir aufgefallen, das die MPPTs nicht immer auf die HEX-Kommandos antworten.

Das war mir auch schon aufgefallen, aber ich dachte das sei bei mir weggegangen nach Neuverdrahtung. Gerade nochmal die Konsole kurz mitlaufen lassen und bei mir scheinen die HEX-Anforderungen brav und zuverlässig beantwortet zu werden. Ich hatte dazu das Absenden der HEX-Requests synchronisiert mit den asynchronen TEXT Nachrichten, also verschicken nachdem eine valide TEXT Nachricht dekodiert wurde. In deinem Setup scheint das nicht auszureichen.

Ich hab das mal mit einfachen Mitteln gefixt.

Die Idee hatte ich auch schon, hatte mir aber nicht gefallen, weil dann das Alter der Daten entsprechend anwächst. Das hast du wohl auch schon gesehen, denn du schreibst

Aber wenn wir noch mehr HEX-Kommandos versenden dann muss man das vermutlich anders lösen

Die richtige Lösung wäre einen asynchronen Task laufen zu lassen, pro MPPT Controller, der nichts anderes tut als eine Nachricht zu schicken, die Antwort zu dekodieren (oder Timeout), und dann die nächste Nachricht schicken, für alle Datenpunkte, die man einsammeln will. Das alles in eine Loop mit 1s Sleep zwischen den Runden.

Im log kann man nun schön verfolgen wie die Daten auf eine Anfrage reinkommen.

Hm? Das war doch schon vorher da...

Ich bin beim testen eines "Solar-Passthrough Modes" der im MPPT Absorption- und Float-Mode funktioniert.

Da gibt es ein anders Issue/Diskussion dazu, das hab ich schon mitbekommen. Das Thema ist spannend, ich kenne das Problem und es ist lästig und ich hab noch keine Idee, wie man das lösen könnte. Ob man dafür die Float und Absorption Voltage kennen muss, wage ich allerdings zu bezweifeln, denn der Controller teilt seinen Mode ja bereits mit?

[SW-Niko]

Der Bug ist mir erst aufgefallen als ich die Abfrage der "absorption voltage" und der "float voltage" einfach angehängt habe.
sendHexCommand(Command::GET, Register::ChargeControllerTemperature);
sendHexCommand(Command::GET, Register::SmartBatterySenseTemperature);
sendHexCommand(Command::GET, Register::NetworkTotalDcInputPower);
sendHexCommand(Command::GET, Register::BatteryFloatVoltage);
sendHexCommand(Command::GET, Register::BatteryAbsorptionVoltage);

und dann kam ab und zu die "float voltage" auch nach 10 sec noch nicht an. Aber kein problem mit der "absorption voltage".
Irgendwann habe ich die beiden letzten Zeilen vertauscht und dann kam die "float voltage" zuverlässig an aber die "absorption voltage" nicht. 🤔
Ich vermute das der MPPT einen Befehl verwirft, wenn vor der Abarbeitung ein neuer Befehl ankommt. In den Victron Unterlagen / Foren habe ich zu dem Problem nichts gelesen.

Die richtige Lösung wäre einen asynchronen Task laufen zu lassen, pro MPPT Controller, der nichts anderes tut als eine Nachricht zu schicken, die Antwort zu dekodieren (oder Timeout), und dann die nächste Nachricht schicken, für alle Datenpunkte, die man einsammeln will. Das alles in eine Loop mit 1s Sleep zwischen den Runden.

Ja, das wäre die richtige Lösung. Ich habe auch schon daran gedacht, war mir aber nicht sicher ob meine C++ Fähigkeiten schon reichen und deshalb eine einfache Lösung gewählt.
Hmmm.... ich probier mal ob ich das hinbekomme.

Ein Problem haben wir momentan nicht weil ja
sendHexCommand(Command::GET, Register::NetworkTotalDcInputPower);
aktuell noch die letzte Zeile ist und somit immer funktionieren sollte.

Ob man dafür die Float und Absorption Voltage kennen muss, wage ich allerdings zu bezweifeln, denn der Controller teilt seinen Mode ja bereits mit?

Ich regle über die Spannung und nicht über die Leistung/Strom. Und dann verwende ich gleich die im MPPT hinterlegen Spannungen. Ich denke das hat Vorteile. Fasse ich alles noch in Text ... Noch etwas Geduld bitte.

[SW-Niko]

Hallo @schlimmchen ,
Ich habe das Senden der hex commands jetzt umgebaut. Die "NetworkTotalDcInputPower" wird jede Sekunde abgefragt und alle anderen Werte nach 4 Sekunden.

21:59:00.759 > [VE.Direct MPPT 7/17] Sending Hex Command: :7F6ED006B, Free FIFO-Buffer: 118
21:59:00.823 > [VE.Direct MPPT 7/17] Hex Data: MPPT Float Voltage (0xEDF6): 27.20V
21:59:00.872 > [VE.Direct MPPT 7/17] Sending Hex Command: :7F7ED006A, Free FIFO-Buffer: 118
21:59:00.998 > [VE.Direct MPPT 7/17] Hex Data: MPPT Absorption Voltage (0xEDF7): 29.20V
21:59:01.158 > [VE.Direct MPPT 2/40] Sending Hex Command: :727200007, Free FIFO-Buffer: 118
21:59:01.412 > [VE.Direct MPPT 2/40] Hex Data: Network Total DC Power (0x2027): 0.00W
21:59:01.626 > [VE.Direct MPPT 7/17] Sending Hex Command: :727200007, Free FIFO-Buffer: 118
21:59:01.677 > [VE.Direct MPPT 7/17] Hex Data: Network Total DC Power (0x2027): 0.00W
21:59:01.791 > [VE.Direct MPPT 2/40] Sending Hex Command: :727200007, Free FIFO-Buffer: 118
21:59:01.848 > [VE.Direct MPPT 2/40] Hex Data: Network Total DC Power (0x2027): 0.00W
21:59:01.941 > [VE.Direct MPPT 7/17] Sending Hex Command: :727200007, Free FIFO-Buffer: 118
21:59:01.993 > [VE.Direct MPPT 7/17] Hex Data: Network Total DC Power (0x2027): 0.00W
21:59:02.145 > [VE.Direct MPPT 2/40] Sending Hex Command: :727200007, Free FIFO-Buffer: 118
21:59:02.200 > [VE.Direct MPPT 2/40] Hex Data: Network Total DC Power (0x2027): 0.00W
21:59:02.475 > [VE.Direct MPPT 7/17] Sending Hex Command: :727200007, Free FIFO-Buffer: 118
21:59:02.529 > [VE.Direct MPPT 7/17] Hex Data: Network Total DC Power (0x2027): 0.00W
21:59:03.126 > [VE.Direct MPPT 2/40] Sending Hex Command: :7DBED0086, Free FIFO-Buffer: 118
21:59:03.178 > [VE.Direct MPPT 7/17] Sending Hex Command: :7DBED0086, Free FIFO-Buffer: 118
21:59:03.237 > [VE.Direct MPPT 2/40] Hex Data: MPPT Temperature (0xEDDB): 41.10°C
21:59:03.300 > [VE.Direct MPPT 7/17] Hex Data: MPPT Temperature (0xEDDB): 41.10°C

Mir ist beim Testen noch was aufgefallen. Ich konnte plötzlich kein Update über die Weboberfläche machen aber über die serielle Schnittstelle ging es ohne Probleme. Er hat erst wieder funktioniert nachdem ich die Größe der Datei etwas reduzieren konnte.

[schlimmchen]

I know you made this for #1167, but this could and should be its own feature, where we add the float and absorbtion values to the live view, MQTT and HASS. If you are not motivated for that, I can pick it up at some point in the future.

[SW-Niko]

all changes have been implemented. If the test on my system is positive tomorrow then I will update the code.

[SW-Niko]

Ok, works on my system since yesterday

[SW-Niko]

where we add the float and absorbtion values to the live view, MQTT and HASS.

I will do the missing implementations next.
The question is: where should I place the values?

Absorption voltage: 28.6V
Float voltage: 27.2V

On the "Device Info" block or on the "Output(Battery) block?
I would opt for the "Device Info" block above the Charge controller temperature.
Any suggestions?

[schlimmchen]

On the "Device Info" block or on the "Output(Battery) block?

Well, I think the "Output (Battery)" card is better suited for two reasons: (1) It has currently less rows than the "Device Info" card, and (2) these voltages have a relation to the battery voltage itself. So, I would say that card is ideal.

[SW-Niko]

screenshot ...

Hopefully the last question.
I do not have knowledge with HASS.
publishSensor("Battery absorption voltage", "mdi:wrench", "V", "voltage", "measurement", "V", *optMpptData);
Do you think the 2 parameter "mdi:wrench" and "measurement" are ok?

[schlimmchen]

Do you think the 2 parameter "mdi:wrench" and "measurement" are ok?

Hm... I don't know for sure, either. Well, I think "mdi:wrench" as the icon is not a good choice. How about one of these:

And "measurement"... Yeah, that's correct.

However, the first "V" for "subtopic" is not correct. That should be the MQTT subtopic where the measurement is published to. Since you have not pushed the code that publishes the value to MQTT, I can't tell you what the correct subtopic is, yet.

[schlimmchen]

Auf aktuellen Stand von hoylabs/development gehoben.

[stefan123t]

Having had initially no real clue what you were trying to implement and also no Victron MPPT charger to compare with, I searched for the two terms „Absorption Voltage“ and „Float Voltage“.

The best translation I could come up with would be „Ladeschlussspannung“ and „Erhaltungsladungsspannung“. So with this in mind we should use mdi:battery-charging-100 for Absorption voltage and mdi:battery-charging-90 for float voltage, just reverse it in your patch.

Charge curve

With this setting one can choose between three differen charge curves:

• Fixed
• Adaptive
• Adaptive + BatterySafe

The Fixed charge curve will have a fixed absorption time.
The Adaptive and Adaptive + BatterySafe curves derive the Absorption time from the Bulk time. The maximum Absorption timw of these Charge curves is determined by the Absorption time setting.

The Adaptive and Adaptive + BatterySafe curve has a special regulation in the Absorption Phase. The Absorption phase will start when the voltage reaches 14.4V (for a 12V battery) regardless of the specified Absorption voltage. During the Absorption phase the voltage will increase with a fixed ramp until the voltage reaches the Absorption voltage or until the calculated Absorption time is over. In the latter case the Absorption phase will end before the Absorption voltage is reached.

Please refer to the manual for a more detailled description of the charge process.

[schlimmchen]

So with this in mind we should use mdi:battery-charging-100 for Absorption voltage and mdi:battery-charging-90 for float voltage, just reverse it in your patch.

I disagree. The battery is first charged in bulk mode (max current) until the absorption voltage threshold is reached. It is then nearly full (mdi:battery-90). The charge controller then switches to absorption mode (fixed voltage: absorption voltage), until the charge current is... "low" for "some" time. It then enter float mode (fixed voltage: float voltage). The batter is full (mdi:battery-100).

[schlimmchen]

Whoopsie... Why is the absoption voltage so high on one of my charge controllers...

Feature works great! Thanks, @SW-Niko.

[stefan123t]

Okay I do agree that the charge state should reflect the bar graph in the battery icon.
I was just looking at the voltage used to charge the battery and there the voltage is much higher in the absorption phase than in the final float / trickle charge phase.

[SW-Niko]

@schlimmchen thanks for the additional integration work. I saw some problems but running out of time last weekend. 😞

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.