WR shutdowns / unclear reasons with Version 2024.03.23

[peff74]

What happened?

Sometimes the inverter is stopped for unknown reasons, even though there is enough energy available. Today:

This example clearly shows that there is enough energy available, yet the DPL shuts down the inverter three times in a row. You can clearly see the increase in voltage on the battery, as the inverter is no longer absorbing energy.

To Reproduce Bug

Difficult to impossible, I haven't been able to recognize a specific trend yet, it just happens several times a day from time to time. Sometimes only once, then several times in a row

Expected Behavior

that it works as well as in the previous versions ;-)

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

0169b29

Relevant log/trace output

No response

Anything else?

No response

[schlimmchen]

I recognize that this is an issue, you clearly proved that it exists.

However, until more info is available (a verbose DPL log (console excerpt) while the problem is happening), I assume that your power meter was unavailable, simply because it is the most likely explanation.

Please tell us what power meter interface you are using.

[SW-Niko]

I recognized the same fault 3-4 times a day. I'm using a Shelly 3EM (HPPT+Json). I spend already some time to dig into the problem. Not sure if it is a DTU problem or a external problem (WLAN, Router, Shelly)

Maybe it would help if we tried to identify similarities in our systems?

[peff74]

The electricity meter data is transmitted via MQTT. I read the electricity meter via IR using a self-built module. Providing a log will be difficult, then I would have to be on the lookout all day. However, the electricity meter was available at the time. Top count. I don't save the values in the DB that often though, so the graph looks a bit more squared off.

[schlimmchen]

Providing a log will be difficult, then I would have to be on the lookout all day.

Well, yes, but unfortunately we don't have a working crystal ball to look into and find an explanation for your issue...

Connect a PC or Raspberry Pi or something and log the OpenDTU-OnBattery serial output with timestamps. Once the problem re-occurs, you can cut the log in hindsight.

The electricity meter data is transmitted via MQTT.

That's probably reliable, so a power meter timeout is unlikely.

I recognized the same fault 3-4 times a day.

The screenshot you shared shows events very close together and in the morning. That seems more like you are using solar-passthrough and the solar output is fluctuating around 20W (the current threshold for enabling/disabling the inverter based on solar-passthrough). That's normal.

[schlimmchen]

How about the VE.Direct connection? Is it always reliable? The data from the VE.Direct interface times out after 10 seconds. This is a fix in the recent release. Previous releases would use outdated VE.Direct data forever. Do you even use VE.Direct and solar-passthrough?

[peff74]

Yes, it's all very strange. I'll go back to my previous version today: 2024.02.19.post1 Maybe it will disappear again. I use VE.Direct and solar-passthrough :-) The phenomena happened to me in the afternoon.

[peff74]

I just remembered that I also updated the FW of the Victron 100/20 to 1.63 to test whether the Victron 100/20 problem disappears with changing cloud cover. But that shouldn't really be a problem either, or?

[SW-Niko]

Hello, I double checked the configuration and the option solar-passthrough was off.

Today again 4 entries. The long one was triggered by an empty battery. @peff74 We use completely different ways to get the power meter information but in the end the same result. Switching of the inverter for 10-20 sec. I will try to collect more information by using my tiny statistic logging function.

[peff74]

As I have already written, I am back to 2024.02.19.post1 (0169b29) today. Since then, everything has been running smoothly again. However, there was also a LAN cable provisionally installed because we had earthworks in the garden. This was badly squashed in the garden shed door. Today, I reconnected the permanently installed underground cable, too. I think I will give the new version another change in the next few days

[cerise21]

Habe es geschafft, mal zwei Inverter-Abschaltungen im Log festzuhalten. Die am Laderegler gemessenen PV-Leistungen waren jeweils weit vom 20W-Schwellwert entfernt. Zwischen den Abschaltzeiten in den Screenshots und den Zeitstempeln im Logfile ist ein Offset von ca. 3min 30s (Logfile-Zeit ist früher). Das Abschalten um 09:43:39 findet man im Logfile bei 09:40:00 und das um 09:56:01 bei 09:52:33.

Ist der DPL möglicherweise wegen der Lesefehler/Timeouts bei den VE.Direct-Daten der Meinung, dass keine PV-Leistung mehr reinkommt? Vielleicht sollte er da, bis das, die VE.Direct-Fehler verursachende, blockierende Powermeter-Lesen ein Refactoring erfahren hat (?), nicht so streng sein und den Inverter nicht direkt abschalten?

(hier: Firmware 2024.03.23; Powermeter SDM630, kabelgebunden (RS485))

hoymiles_shutdown.log

Und hier noch ein Abschalt-Event mit 'verbose logging' für den DPL. hoymiles_shutdown2.log

Der Zeitpunkt im Logfile ist 11:36:32.

Mich irritieren die MQTT- und TCP-Disconnect-Meldungen? Sind mir bisher nie aufgefallen.

[schlimmchen]

Sehr gut, das hilft!

Hm. Also das sieht in der Tat danach aus, als wäre die Kommunikation vom Victron Laderegler so schlecht bzw. gestört, dass zwischendrin der Wechselrichter abgeschaltet wird, weil weder die Batterie entladen werden kann, noch solare Leistung zur Verfügung steht.

Es ist auch plausibel, dass das etwas mit deinem PowerMeter zu tun hat. Allerdings möchte ich trotzdem nachhaken, wie du den Laderegler angeschlossen hast am ESP32? Direkt? Mit MOSFET Level-Shiftern? Mit ADUM1201? Falls nicht letzteres, würde ich trotz allem bitten, dass du einmal versuchst deine Situation mit einem ADUM1201 zu verbessern.

Wenn dann immerhin weniger Frames defekt sind, würde das Problem vermutlich verschwinden.

Dennoch muss woanders nachgearbeitet werden. Den DPL aber "weniger streng" zu machen, wie von dir vorgeschlagen, überzuegt mich nicht. Der Laderegler schickt ja jede Sekunde einen Frame, und erst nach 10 Sekunden wird angenommen, dass ein Problem vorliegt. Das ist schon echt lang.

Ich sehe in deinem Log auch, dass der Hex-Buffer übergelaufen ist. Das muss heißen, dass einmal fälschlicherweise ein HEX Frame erkannt wurde und dass der "niemals" endete. Wenn die Kommunikation zwischen Laderegler und ESP32 schlecht ist und das Newline nicht entziffert werden kann und stattdessen kein Zeichen oder ein anderes Zeichen dekodiert wurde, dann kann sowas passieren. Daher wäre es schon wichtig, diese Datenleitung robust zu machen.

[SW-Niko]

Hallo, Das deckt sich auch mit meinen Untersuchungen. Da hat @schlimmchen schon recht, die VE.Direkt würde ich auch zuerst angreifen. Eine schlechte Verbindung deckt sich mit dem Fehlerbild.

Bei meinem System ist das Fehlerbild identisch. Ich kann auch all diese Probleme feststellen wie ich in #752 beschrieben habe. Der Empfangs-Pufferüberlauf der Seriellen Schnittstelle verursacht meistens auch einen Checksum Fehler und kann auch zu einem Überlauf des Hex Frame führen, weil das Ende-Zeichen (Newline) durch den Überlauf verloren ging.

Ein kleiner Trick hat bei mir geholfen, den Pufferüberlauf um 95% zu reduzieren. Ich habe einfach beim Powermeter (Bei mir ein Shelly 3EM) den Timeout auf 500ms reduziert. Dadurch wird die DTU nicht mehr so sehr blockiert und kann die Daten vom VE.Direkt Puffer zügiger abholen.

[cerise21]

den Laderegler angeschlossen ... am ESP32

habe ich mit nMOS-Levelshiftern (PCB von @lukasvfl99). (Wobei ich da gerade festgestellt habe, dass, zumindest auf meiner verbastelten Platine, die ESP-seitige Versorgung 'LV' floatet. LV angeschlossen an 3.3V bringt allerdings, gemessen an der Häufigkeit der VE.Direct-checksum-Fehler, keinen Vorteil.)

Die Levelshifter habe ich jetzt durch ein ADUM1210 ersetzt. Der 'Data Age'-Zähler des Ladereglers läuft jetzt (gefühlt) seltener hoch bis 10s. Er zeigt einige Sekunden lang Werte zwischen 0s und 2s an und läuft dann meistens bis 5s oder 6s hoch. Die checksum-Fehler kommen trotzdem noch im Schnitt alle 7-8s. Mal sehen, ob sich an den Inverter-Shutdowns nun etwas ändert…

Ja,

"weniger streng"

ist wahrscheinlich keine gute Idee; wenn regulär neue Werte nach 1-2s da sind.

@SW-Niko Der

Timeout auf 500ms reduziert

existiert anscheinend nur für die per HTTP+JSON angesprochenen Powermeter.

[schlimmchen]

Der 'Data Age'-Zähler des Ladereglers läuft jetzt (gefühlt) seltener hoch bis 10s.

Der sollte niemals bis 3 kommen...

Verschwindet das denn, wenn du testweise deinen PowerMeter deaktivierst? Du nutzt den SDM, oder? Wäre gut zu wissen, dass es tatsächlich daran liegt. Bei dir wäre das ja besonders leicht verifizierbar bei der Fehlerhäufigkeit, die du siehst...

[cerise21]

Ja, ohne aktiviertes Powermeter (SDM630) sind die checksum-Fehler komplett weg und der Data-Age-Zähler kommt max. auf 1s. (vgl. dort)

[E1yot]

Ich hatte heute auch Probleme mit Inverter-Abschaltung. Ursache ist zwar vermutlich eine andere, aber passt dennoch zum Thema. Mein Setup: HMS-1800-4T, 4 Module, keine Batterie Im 2024.03.07-Release hatte ich die DTU erstmalig eingerichtet, noch ohne Wechselrichter. Die Parameter hatte ich bereits für Betrieb ohne Batterie gesetzt, die Schwellwerte für Batterienutzung entsprechend auf 0 bzw. 1 gesetzt. In der aktuellen Version gibt es den Schalter "Speisung von Solarmodulen". Ist dieser aktiviert, werden die Eingabemasken für den Schwellwert deaktiviert. Hier standen jedoch noch 0 und 1 als Wert, Minimumwert wird nun aber als 16 angegeben. Es kommt jedoch keine Fehlermeldung, wenn die nicht angezeigten Werte falsch sind. Der Umrichter schaltet dann jedoch ab. Nach Korrektur der Werte auf 16, Speichern und anschließendem Aktivieren von "Speisung aus Solarmodulen" schaltet der Wechselrichter nicht mehr ab.

[schlimmchen]

Also @cerise21 und @SW-Niko hatten/haben scheinbar Probleme wegen des PowerMeters. @peff74 Auf welcher Version läuft deine OpenDTU denn nun und was ist mit deinem Problem?

[TomBrett72]

Hallo zusammen, bekomme ebenfalls sehr viele kurze Abschaltungen (heute 11 in 20min), besonders wenn z.B. Waschmaschine läuft. Aktuelle firmware. Victron 100/30 über ADUM angeschlossen. Das Kabel ist keine 40cm lang. Shelly EM über HTTP/JSON. Einphasiger Haushalt. Im logfile ist für mich nicht nachvollziehbar, warum der WR erst erfolgreich auf eine Leistung gestellt wird und dann in der nächsten Rechnung ein anderer Leistungswert verrechnet wird. Dann kommt immer was Negatives raus und der WR geht folgerichtig aus. Vielleicht hilft Euch das auch weiter...

17:47:29.663 > [DPL::updateInverter] sending limit of 40.5 % (243 W respectively), max output is 600 W
17:47:29.817 > [DPL::announceStatus] waiting for a power limit command to complete
17:47:30.016 > Success
17:47:30.218 > Fetch inverter: 114184000369
17:47:30.318 > [DPL::updateInverter] actual limit is **40.0 % (240 W respectively)**, effective 2059 ms after update started, requested were 40.5 %
17:47:30.429 > [DPL::announceStatus] waiting for sufficiently recent inverter data
17:47:30.493 > Success
17:47:30.620 > [DPL::announceStatus] waiting for sufficiently recent power meter reading
17:47:35.648 > PowerMeterClass: TotalPower: -142.78
17:47:35.765 > [DPL::loop] ******************* ENTER **********************
17:47:35.825 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 80 %, StopTH: 20 %, SoC age: 182043 s, ignore: yes
17:47:35.901 > [DPL::getBatteryVoltage] BMS: -1.00 V, MPPT: 26.45 V, inverter: 26.60 V, returning: 26.45V
17:47:36.045 > [DPL::loop] dcVoltage: 26.45 V, loadCorrectedVoltage: 26.54 V, StartTH: 26.00 V, StopTH: 25.00 V
17:47:36.157 > [DPL::loop] StartTH reached: yes, StopTH reached: no, SolarPT disabled, use at night: no
17:47:36.272 > [DPL::calcPowerLimit] battery use allowed, solar power (DC): 0 W
17:47:36.348 > [DPL::calcPowerLimit] target consumption: -13 W, base load: 60 W, power meter does include inverter output
17:47:36.469 > [DPL::calcPowerLimit] power meter value: -142 W, power meter valid: yes, **inverter output: 70 W**, solar power (AC): 0 W
17:47:36.533 > [DPL::calcPowerLimit] match household consumption with limit of -59 W
17:47:36.632 > [DPL::setNewPowerLimit] input limit: -59 W, min limit: 12 W, max limit: 400 W, hysteresis: 12 W
17:47:36.725 > [DPL::announceStatus] calculated limit is less than minimum power limit
17:47:36.930 > [DPL::updateInverter] Stopping inverter...

[cerise21]

Habe den Eindruck, dass mit 2024.05.07 die WR-Abschaltungen deutlich häufiger auftreten. Morgens und abends in einem Zeitraum bis zu ca. zwei Stunden nach Sonnenauf- bzw. vor Sonnenuntergang sehr oft, aber auch über den Tag verteilt einige Male. In weiten Bereichen der genannten Zeiträume ist die PV-Leistung deutlich oberhalb des eingestellten unteren Leistungslimits (20W) des Inverters. Das System scheint in eine Art Schwingungszustand zu geraten, in dem der Inverter wiederholt ein- und ausgeschaltet wird.

[schlimmchen]

@TomBrett72 Du hast ja inverter output: 70 W bereits markiert. Ich hab leider keine Erklärung dafür, warum der Inverter sechs Sekunden nach dem letzten Limit meldet, er würde 70W produzieren. Läuft dein WR denn stabil auf verschiedenen Limits, wenn du den DPL ausschaltest und ein Limit fest einstellst? Schwingt der?

Achso, Moment... Du hast eine 24V Batterie... Das Limit ist wohl korrekt eingestellt und vermutlich produziert der Inverter auch tatsächlich die gewünschte Leistung, er misst es nur selbst nicht. Siehe #613 und als mögliche zukünftige Lösung #899.

@cerise21 Logs?

[TomBrett72]

@schlimmchen Danke für die Hinweise! Bin im Winter ohne DPL sehr stabil gefahren, jedoch Leistungen kleiner 100W. Muss ich nochmal höhere Leistungen probieren.

@cerise21 Hallo, hab mir auch mal Deine Logs von oben reingezogen... ich sehe da viel, was ich anfangs auch hatte: 11:37:17 — All missing | 11:37:17 — Nothing received, resend whole request oder extrem: 11:36:55 — [DPL::updateInverter] actual limit is 1.0 % (15 W respectively), effective 23933 ms after update started, requested were 1.3 %

Lass mich raten, Dein Hoymiles ist nahezu neben der DTU platziert? Ich habe es mit vielen Versuchen geschafft, die Verbindung DTU-HM zu verbessern. Hab das Layout meiner Box mehrfach gedreht, Antennenrichtung verändert, den Akku zwischen DTU und HM genommen. Zu guter Letzt die große Antenne an der DTU ausgebaut und gegen die kleine Leiterplattenantenne getauscht. Dabei immer aufpassen, daß das WLAN für den Stromzähler gut bleibt. Es geht da wirklich um 10 Zentimeter hin oder her!

Noch was: Kann Dein HM-1500 wirklich 1% Minimalleistung gut darstellen? Ich meine gelesen zu haben, man sollte mindestens 1% pro Kanal als kleinste Leistung vorhalten. Zumindest hab ich meinen HM-600 deswegen auf 12W eingestellt und der tut - aus anderen Gründen nicht immer :-)

[cerise21]

Dein Hoymiles ist nahezu neben der DTU platziert?

Ja genau. Mit den Antennen hab’ ich auch schon einiges probiert: NRF mit großer Antenne, mit PCB-Antenne, ohne Antenne, 'Alu-Hüte' zum Dämpfen (?) über den Antennen bei beiden NRF-Boards, 'Alu-Hut' über der Hoymiles-Antenne. Nichts davon war irgendwie deutlich besser.

man sollte mindestens 1% pro Kanal als kleinste Leistung vorhalten

Aktuell habe ich die Minimalleistung auf 50W erhöht. Und das ist, in Kombination mit einer minimalen Grundlast von ca. 100W und einem Ziel-Verbrauch von 50W, möglicherweise der Grund für das häufige Aus-/Einschalten des Inverters… Ich senke jetzt den Ziel-Verbrauch testweise auf 40W.

Mit dem Aufzeichnen der

Logs

mit websocat habe ich gerade irgendwie Probleme — meist steigt das Programm schon nach wenigen Zeilen aus; manchmal geht’s ein paar Minuten gut, bis das hier kommt: websocat: WebSocketError: UTF-8 failure websocat: error running Kommen da 'komische' Zeichen auf der Konsole an?

Ich habe ja diese VE.Direct-Kommunikationsfehler, so dass vom MPPT manchmal keine Werte gelesen werden können (MPPT: -1.00V). Dann schaltet der DPL in den 'battery use allowed, solar power (DC): 0 W' -Modus und gewährt dem Inverter, bei entsprechendem Verbrauch des Haushalts, deutlich mehr 'input limit' als es im 'battery use prevented, solar power (DC): 219 W' -Modus kurz vorher, bei funktionierender VE.direct-Kommunikation, der Fall war. Könnte dies zu einem Schwingen, d. h. permanentem Hoch- und Runterregeln des Inverterlimits führen? (Im folgenden Transscript ist dies nicht der Fall, da sich der Verbrauch relativ konstant um die minimale Grundlast herum bewegt; es sind aber die zwei 'Betriebsmodi' eingefangen.)

1716891816.357178 [VE.Direct MPPT 22/1] checksum 0xa0 != 0x00, invalid frame 1716891816.3981814 [VE.Direct MPPT 22/1] checksum 0x11 != 0x00, invalid frame 1716891816.444973 PowerMeterClass: TotalPower: 49.85 1716891816.50737 [DPL::loop] * ENTER ** 1716891816.5582583 [DPL::loop] battery interface enabled, SoC: 30 %, StartTH: 35 %, StopTH: 20 %, SoC age: 10 s, ignore: no 1716891816.6671274 [DPL::getBatteryVoltage] BMS: 49.82 V, MPPT: -1.00 V, inverter: 49.90 V, returning: 49.82V 1716891816.705474 [DPL::loop] dcVoltage: 49.82 V, loadCorrectedVoltage: 49.86 V, StartTH: 49.30 V, StopTH: 48.90 V 1716891816.7370942 [DPL::loop] StartTH reached: no, StopTH reached: no, SolarPT enabled, use at night: yes 1716891816.7904806 [DPL::calcPowerLimit] battery use allowed, solar power (DC): 0 W 1716891816.8397858 [DPL::calcPowerLimit] target consumption: 50 W, base load: 100 W, power meter does include inverter output 1716891816.8901827 [DPL::calcPowerLimit] power meter value: 49 W, power meter valid: yes, inverter output: 48 W, solar power (AC): 0 W 1716891816.9582772 [DPL::calcPowerLimit] match household consumption with limit of 47 W 1716891816.99311 [DPL::setNewPowerLimit] input limit: 47 W, min limit: 50 W, max limit: 800 W, hysteresis: 10 W 1716891817.0336566 [DPL::announceStatus] calculated limit is less than minimum power limit 1716891817.1141577 [DPL::updateInverter] Stopping inverter... 1716891817.163557 Last missing 1716891817.2144015 Request retransmit: 12 1716891817.2424889 [VE.Direct MPPT 22/1] checksum 0x15 != 0x00, invalid frame 1716891817.2859533 [DPL::announceStatus] waiting for a start/stop/restart command to complete 1716891817.3213065 Last missing 1716891817.3800645 Request retransmit: 12 1716891817.4265938 Middle missing 1716891817.481341 Request retransmit: 1 1716891817.5089011 [VE.Direct MPPT 22/1] checksum 0x28 != 0x00, invalid frame 1716891817.5410266 Middle missing 1716891817.5896127 Request retransmit: 3 1716891817.6216881 Middle missing 1716891817.657268 Retransmit timeout 1716891818.8220398 [VE.Direct MPPT 22/1] checksum 0xa2 != 0x00, invalid frame 1716891819.2168884 Success 1716891819.2568448 Fetch inverter: xxx 1716891819.690139 Last missing 1716891819.7224872 Request retransmit: 4 1716891819.833668 Last missing 1716891819.8697696 Request retransmit: 4 1716891819.9756951 Success 1716891820.03394 [DPL::updateInverter] Stopping inverter... 1716891820.7703013 Middle missing 1716891820.803327 Request retransmit: 2 1716891820.872257 [VE.Direct MPPT 22/1] checksum 0x28 != 0x00, invalid frame 1716891820.9132016 Middle missing 1716891820.945129 Request retransmit: 4 1716891821.0434952 Middle missing 1716891821.0698159 Request retransmit: 4 1716891821.1385052 Middle missing 1716891821.1778789 Request retransmit: 6 1716891821.383179 Middle missing 1716891821.4138694 Request retransmit: 6 1716891821.509759 Middle missing 1716891821.5621166 Retransmit timeout 1716891822.4565027 [VE.Direct MPPT 22/1] Resetting state machine (was 2) after timeout 1716891823.7083783 All missing 1716891823.7486792 Nothing received, resend whole request 1716891823.8061864 [VE.Direct MPPT 22/1] checksum 0x9c != 0x00, invalid frame 1716891825.5882423 All missing 1716891825.6169412 Nothing received, resend whole request 1716891825.8065255 [VE.Direct MPPT 22/1] checksum 0x28 != 0x00, invalid frame 1716891831.0263462 PowerMeterClass: TotalPower: 102.36 1716891831.069092 [DPL::announceStatus] waiting for a start/stop/restart command to complete 1716891831.2572122 Success 1716891831.3010454 [VE.Direct MPPT 22/1] checksum 0x16 != 0x00, invalid frame 1716891831.8102543 [VE.Direct MPPT 22/1] checksum 0x9e != 0x00, invalid frame 1716891833.4249635 [VE.Direct MPPT 22/1] Resetting state machine (was 2) after timeout 1716891834.1514494 Fetch inverter: xxx 1716891834.6766076 Middle missing 1716891834.7136536 Request retransmit: 3 1716891834.834253 Success 1716891834.8993595 [DPL::announceStatus] waiting for sufficiently recent power meter reading 1716891834.982209 [VE.Direct MPPT 22/1] checksum 0x28 != 0x00, invalid frame 1716891835.6282191 Middle missing 1716891835.6614475 Request retransmit: 1 1716891835.7477014 Middle missing 1716891835.7768428 Request retransmit: 2 1716891835.8568351 Middle missing 1716891835.88934 Request retransmit: 4 1716891836.0256355 Middle missing 1716891836.052539 Request retransmit: 4 1716891836.2957003 Middle missing 1716891836.3312974 Request retransmit: 6 1716891836.3907106 Middle missing 1716891836.44106 Retransmit timeout 1716891836.830386 [VE.Direct MPPT 22/1] checksum 0x22 != 0x00, invalid frame 1716891838.8100154 [VE.Direct MPPT 22/1] checksum 0x28 != 0x00, invalid frame 1716891840.8104067 [VE.Direct MPPT 22/1] checksum 0x9c != 0x00, invalid frame 1716891845.874376 PowerMeterClass: TotalPower: 100.88 1716891845.908825 [DPL::loop] * ENTER ** 1716891845.9447987 [DPL::loop] battery interface enabled, SoC: 30 %, StartTH: 35 %, StopTH: 20 %, SoC age: 5 s, ignore: no 1716891845.9711328 [DPL::getBatteryVoltage] BMS: 49.83 V, MPPT: 49.88 V, inverter: 50.00 V, returning: 49.83V 1716891846.0007954 [DPL::loop] dcVoltage: 49.83 V, loadCorrectedVoltage: 49.83 V, StartTH: 49.30 V, StopTH: 48.90 V 1716891846.054205 [DPL::loop] StartTH reached: no, StopTH reached: no, SolarPT enabled, use at night: yes 1716891846.091203 [DPL::calcPowerLimit] battery use prevented, solar power (DC): 219 W 1716891846.1536222 [DPL::calcPowerLimit] target consumption: 50 W, base load: 100 W, power meter does include inverter output 1716891846.2183268 [DPL::calcPowerLimit] power meter value: 100 W, power meter valid: yes, inverter output: 0 W, solar power (AC): 205 W 1716891846.2905455 [DPL::calcPowerLimit] limited to solar power: 50 W 1716891846.316362 [DPL::setNewPowerLimit] input limit: 50 W, min limit: 50 W, max limit: 800 W, hysteresis: 10 W 1716891846.3582788 [DPL::setNewPowerLimit] inverter max: 1500 W, inverter is NOT producing, requesting: 50 W, reported: 60 W, diff: 10 W 1716891846.4258857 [DPL::updateInverter] Starting inverter... 1716891846.4562232 [VE.Direct MPPT 22/1] checksum 0x15 != 0x00, invalid frame 1716891846.4854136 [DPL::announceStatus] waiting for a start/stop/restart command to complete 1716891846.892568 [VE.Direct MPPT 22/1] checksum 0x28 != 0x00, invalid frame 1716891848.176382 Success 1716891848.8140695 [VE.Direct MPPT 22/1] checksum 0x7e != 0x00, invalid frame 1716891849.1909611 Fetch inverter: xxx 1716891849.706363 Middle missing

[TomBrett72]

Hallo @cerise21, ich bin damals so vorgegangen, daß ich zunächst alle "onbattery-features" deaktiviert habe und meinen HM600 auf eine Konstantlast eingestellt habe. Also kein Stromzähler, kein Victron, kein BMS, kein MQTT. Klar, da muß man aufpassen, da es ohne DPL keinen Batteriewächter gibt. Das fängt wunderbar die Grundlast ab und ist gut kalkulierbar - 100Watt sind halt 2,4kWh, daß muß die Sonne erstmal scheinen. Der DTU-Zugriff auf den HM sollte sauber aller 10 Sekunden funktionieren. Zur Not muß eben die DTU noch weiter weg vom HM. Wenn das tut, DPL einschalten und OHNE Stromzähler anfahren, nur dann wird mit Grundlast gerechnet. [DPL::calcPowerLimit] target consumption: 50 W Warum 50 Watt Grundlast vom Netzversorger kaufen und das "Gezappel" oben selber regeln wollen? Das Stück von 50W auf 100W Grundlast ist zu klein für die Mindestlast des HM-1500. Meine Meinung. Alle reden doch von "NULL-Einspeisung". Die MPPTs vom HM schwingen auch noch (schätze mindestens 30Watt beim HM1500) und suchen den "besseren Arbeitspunkt". Also bei mir steht da -19W. Ja, MINUS! Gerechnet NULL - offset shelly - hysterese 1% je MPPT Müsstest Du also -30W eintragen, wenn Du unter allen Umständen unter NULL Watt am Zählerschrank bleiben möchtest. Dein HM1500 hat somit mindestens 100W zu arbeiten, das sollte genug sein, damit er nicht AUS macht.

[cerise21]

Hallo @TomBrett72 , danke für die Beschreibung Deiner Vorgehensweise bzgl. der DTU-Kommunikationsprobleme.

Zur Not muß eben die DTU noch weiter weg vom HM.

Ich vermute, dies wird der einzig zuverlässige Weg sein, um die Probleme der Funkverbindung anzugehen… Kabel zu MPPT, Pylon, Huawei, Powermeter und Versorgung müssten durch längere ersetzt werden. Im Moment ist halt alles schön kompakt aufgebaut.

Die aktuell besprochenen Wechselrichter-Abschaltungen werden aber eher durch die blockierende Powermeter-Abfrage, die zu Störungen in der VE.direct-Kommunikation führt (?), verursacht (?).

Das Stück von 50W auf 100W Grundlast ist zu klein für die Mindestlast des HM-1500

Ja, das wird wohl so sein.

Alle reden doch von "NULL-Einspeisung"

Will ich ja im Prinzip auch. Dachte halt, dass mit 50W 'Sicherheitsabstand' die unvermeidlichen 'Unterschwinger' der Gesamtleistungsaufnahme nach Wegschalten von Lasten etwas weiter von der Einspeiseschwelle 'entfernt' sind. Und da der Akku bis jetzt morgens immer wieder leer war, habe ich doch nichts verschenkt, bzw. unnötig

50 Watt Grundlast vom Netzversorger

gekauft. Oder ist das falsch gedacht?

[cerise21]

Gestern hatte ich einige der folgenden Abschaltungen, in Konstellationen, bei denen ich, trotz der vorhandenen VE.direct-Kommunikationsfehler, gedacht hätte, dass die Abschaltung nicht hätte erfolgen sollen.

Bei Sekunde 1716968943 hat der DPL-Loop keinen MPPT-Spannungs-/Leistungswert zur Verfügung, geht deshalb in den

battery use prevented, solar power (DC): 0 W

-Modus, hat keine Energiequelle zur Verfügung, und schaltet ab.

Mit SoC > StopTH (22% > 20%) sollte doch die Batterie während des angenommenen 'Aussetzers' des Ladereglers, bzw. 'fehlender' Solarproduktion diese Lücke überbrücken(?) D. h. ich hätte erwartet, dass der

battery use allowed, solar power (DC): 0 W

-Modus aktiviert worden und der Inverter durchgelaufen wäre.

1716968932.4833882 [VE.Direct MPPT 22/1] checksum 0xff != 0x00, invalid frame 1716968932.6209054 [VE.Direct MPPT 22/1] failed to disassemble the hex message: :4AAAYNO 1716968937.692137 [DPL::loop] * ENTER ** 1716968937.7514873 [DPL::loop] battery interface enabled, SoC: 22 %, StartTH: 35 %, StopTH: 20 %, SoC age: 0 s, ignore: no 1716968937.824757 [DPL::getBatteryVoltage] BMS: 49.51 V, MPPT: 49.53 V, inverter: 49.60 V, returning: 49.51V 1716968937.8509524 [DPL::loop] dcVoltage: 49.51 V, loadCorrectedVoltage: 49.57 V, StartTH: 49.30 V, StopTH: 48.90 V 1716968937.8758297 [DPL::loop] StartTH reached: no, StopTH reached: no, SolarPT enabled, use at night: yes 1716968937.9043133 [DPL::calcPowerLimit] battery use prevented, solar power (DC): 128 W 1716968937.9308586 [DPL::calcPowerLimit] target consumption: 40 W, base load: 100 W, power meter does include inverter output 1716968937.95523 [DPL::calcPowerLimit] power meter value: 46 W, power meter valid: yes, inverter output: 63 W, solar power (AC): 118 W 1716968937.978906 [DPL::calcPowerLimit] limited to solar power: 69 W 1716968938.0085123 [DPL::setNewPowerLimit] input limit: 69 W, min limit: 50 W, max limit: 800 W, hysteresis: 10 W 1716968938.0367527 [DPL::setNewPowerLimit] inverter max: 1500 W, inverter is producing, requesting: 69 W, reported: 60 W, diff: 9 W 1716968938.067811 [DPL::announceStatus] the system is stable, the last power limit is still valid 1716968938.0950012 [HuaweiCanClass::loop] Data request error 1716968942.771581 Middle missing 1716968942.8073277 Request retransmit: 1 1716968942.8352733 [VE.Direct MPPT 22/1] failed to disassemble the hex message: :A5010000009000000FFFFFFFF5A133E130000000000FE0000000000880000001B009E27920030 1716968942.88637 [VE.Direct MPPT 22/1] failed to disassemble the hex message: :A5010000009000000FFFFFFFF5A133E130000000000FE0000000000880000001B009E27920030 PID 0XA058 1716968942.9194543 [VE.Direct MPPT 22/1] failed to disassemble the hex message: :A5010000009000000FFFFFFFF5A133E130000000000FE0000000000880000001B009E27920030 PID 0XA058 FW 161 1716968942.9526253 [VE.Direct MPPT 22/1] hexRx buffer overflow - aborting read 1716968942.9909263 [VE.Direct MPPT 22/1] checksum 0xdd != 0x00, invalid frame 1716968943.024402 PowerMeterClass: TotalPower: 41.23 1716968943.128081 [DPL::loop] * ENTER ** 1716968943.1669486 [DPL::loop] battery interface enabled, SoC: 22 %, StartTH: 35 %, StopTH: 20 %, SoC age: 10 s, ignore: no 1716968943.2001538 [DPL::getBatteryVoltage] BMS: 49.51 V, MPPT: -1.00 V, inverter: 49.60 V, returning: 49.51V 1716968943.232208 [DPL::loop] dcVoltage: 49.51 V, loadCorrectedVoltage: 49.57 V, StartTH: 49.30 V, StopTH: 48.90 V 1716968943.3329196 [DPL::loop] StartTH reached: no, StopTH reached: no, SolarPT enabled, use at night: yes 1716968943.3629725 [DPL::calcPowerLimit] battery use prevented, solar power (DC): 0 W 1716968943.4297216 [DPL::announceStatus] no energy source available to power the inverter from 1716968943.4666858 [DPL::updateInverter] Stopping inverter... 1716968943.5081863 Middle missing 1716968943.5400105 Request retransmit: 1 1716968943.5724132 [VE.Direct MPPT 22/1] checksum 0xe7 != 0x00, invalid frame 1716968943.6112242 [DPL::announceStatus] waiting for a start/stop/restart command to complete 1716968943.6555781 Middle missing 1716968943.687112 Request retransmit: 1

[TomBrett72]

Hi @cerise21, zuerst - ich denke hier denkt keiner falsch. Man kann die Sache immer von mehreren Seiten beleuchten. Ich hab auch höchsten Respekt vor der geleisteten Programmierarbeit und bin beim Entschlüsseln sämtlicher Funktionen nocht nicht am Ende. Nicht zuletzt wegen mangelnder C++ Kenntnisse, suche z.B. einen Programmablaufplan. Vielleicht schieße ich mich auch deshalb auf Deine Hardware ein - hast doch in meinen Augen wirklich tolle teure Komponenten! Programmfehler sollten andere auch haben.

Zum Kabelumbau. So wie Du das beschreibst hätte ich auch keine Lust drauf ;) Der Störenfried ist doch der HM1500. Der ist wetterfest und hat nur Verbindung zum Akku und zur Steckdose. Wenn Du den aus der Box rausnimmst und testweise ein PV-Verlängerungskabel an einen Eingang anschließt? Bei 48Volt reichen doch selbst die standard 4qmm-Strippen. Die Hinweise in der WIKI https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Kabell%C3%A4nge%28n%29-zwischen-Batterie-und-Wechselrichter sind Dir bekannt? Das kann den Wechselrichter auch verrückt machen.

Ob man Strom verschenkt sagt einem der Zweirichtungszähler vom Netzversorger. Sind bei mir 7kWh in 116Tagen. Sind Regelschwankungen, Full-Solar-PT und Volllasttests. Den SPT hab ich z.B. abgewählt. Ist ne feine Idee, mir aber zu zappelig und ich möchte die wenigen super-Sonnen-Tage nutzen um den Zellausgleich im Akku zu fahren. Möchte eher in Richtung #676 gehen.

[HuaweiCanClass::loop] Data request error Hast auch Fehler auf dem CAN!? CAN High/Low schön verdrillt? Abschlußwiderstand richtig? Kenne die Komponenten nicht. Manche haben den 120Ohm eingebaut manche nicht.

Ok, Du möchtest möglichst wenig Strom verschenken. Mein Vorschlag für die DPL-Einstellwerte: angestrebter Netzbezug: NULL Hysterese: 30 min Leistungslimit: 60 Grundlast: 100 max Leistungslimit: 400 - vorerst, solange verringern, bis die Batterie am nächsten Morgen noch bisschen was üprig hat. Ich arbeite dabei auch mit Solarprognose für den nächsten Tag und bremse meine Anlage aus, wenn es n mieser Tag wird. Je höher das max-Leistungslimit umso höher sind die Regelverluste. Zumal wenn der HM erst nach 20 autsch Sekunden umstellt. https://auswahl-plz-bereich.solar-wetter.com/

ich glaub, mehr kann ich nicht beitragen. Viel Erfolg und lass mal hören, welche Maßnahme es gebracht hat!

[cerise21]

@TomBrett72 Danke für die ausführlichen Hinweise/Vorschläge/Links. Ich werde weiter testen. Mit der CAN-Verbindung weiss ich nicht. was da los ist; das Kabel ist mE. gut. Widerstand ist aktiv; vielleicht probiere ich mal ohne...

[Solar320]

Ich habe damit schon immer ein Problem aber leider wird ja bei erreichen einer Einspeisung, zb durch weitere ungeregelte Wechselrichter, immer gleich der Hauptwechselrichter in Standby versetzt. Ich hätte da gern ein Häkchen womit man die StandBy schaltung abschalten kann, speziell wenn man Nulleinspeisung ohne Akku macht.

Aufgrund der langsamen Regelung kommt es nämlich zu mehreren Minuten langen Ausfällen des Wechselrichters (HM800) zb. wenn eine Heizung Kochplatte usw. ständig ein und aus schaltet. Dann braucht man mal Energie, wenn die Heizung gerade läuft und mal nicht wenn die Heizung gerade aus ist und die zweite Solaranlage einen Überschuß einspeist. Wenn jetzt der Hauptwechselrichter deswegen ausgeht und etliche minuten nicht einspeist, weil er scheinbar sehr sehr lange braucht um wieder einzuschalten, dann wird in mehreren Heizphasen nicht eingespeist und die Energie kommt zum großteil aus dem Netz.

Das heist, die Standbyschaltung dürfte erst mit mehreren Minuten Verzögerung ausschalten (oder halt gar nicht) und in der Zwischenzeit auf dem minimum von zB. 10W bleiben. Das tut keinem weh wenn da mal 10W für eine 1/4h eingespeist werden.

Dadurch kann die Regelung insgesamt viel schneller wider hochregeln wenn die Heizung erneut einschaltet, aus dem Standby wider aufzuwachen dauert dagegen eine halbe Ewigkeit.

Die Regelung ist bei schnell wechselnden Heizlasten ohnehin schon zu langsam, wenn die Regelung einschaltet ist die Heizphase schon zur Hälfte vorbei, wenn sie ausschaltet war die Heizphase schon eine ganze weile vorbei und sie speist weiter ein. Das lässt sich nicht verhindern weil die Regelung nunmal so ist wie sie ist.

Ich habe meine Nulleinspeisung deswegen momentan ausgeschaltet.

EDIT: Um die Regelung so schnell wie möglich zu bekommen bräuchte man mehrere CT Klappkerne, einen an der Sammelleitung der Wechselrichter und 3 an den Phasen. Möglichst alle in ein Messgerät laufend damit die Zeitdifferenzen der Messung so gering wie möglich sind. Sinnvoll ist das dann aber nicht wenn der Wechselrichter etliche Sekunden braucht um seinen Wert anzupassen....die Verzögerungen muss man ja alle zusammenrechnen.. Die schnellste Regelung ist vermutlich die bei der der Wechselrichter selbst die CT Klappkerne angeschlossen hat und direkt auf Leistungsänderungen reagieren kann. (Deye Sun 12K)

[schlimmchen]

Ich hätte da gern ein Häkchen womit man die StandBy schaltung abschalten kann, speziell wenn man Nulleinspeisung ohne Akku macht.

Den Schalter gibt es und der heißt "Inverter wird von Solarmodulen gespeist".

Außerdem soll es mal eine Zeitverzögerung geben vor dem Ausschalten des WR, sodass bei Schwankungen der WR eingeschaltet bleibt. Nur relevant bei Systemen mit Batterie.

[Solar320]

Ok, eingeschaltet ist die option bei mir gewesen. Ich hab das jetzt nochmal mit der aktuelle Version in Betrieb genommen und hoffe das morgen die Sonne mal voll runterprasselt. Dann dürfte der WR jetzt hoffentlich nicht mehr abschalten. :)