String Power drops with every mid request intervall

[Armin46]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior: Start Adapter String power goes down to zero after 5 Minutes ( mid request Intervall), it happens with every request again

Screenshots & Logfiles
If applicable, add screenshots and logfiles to help explain your problem.

Versions:

• E3/DC model and battery type
• Adapter version: 1.2.3 working 1.2.4 not working
• JS-Controller version: 5.0.15
• Node version: 8.17.0
• Operating system: Debian 6.1.38-1

Additional context
Add any other context about the problem here.

[git-kick]

@Armin46, thanks for your report. Could you describe what is the data source of the diagram? Is it read via modbus?

Please provide two debug-logs (preferably as file attachments):

1. adapter start (ca 30 secs)
2. just before string power drops

I cannot reproduce the phenomenon in my setup, so having your logs, I could see whether the adapter sends some strange things to your E3/DC.

[Armin46]

Yes the data comes from Modbus.

here are the logfile i copyed both parts in one.

e3dc.txt

I just see when the request is done there is a change in string voltage also.

Do you need anything else ?

[git-kick]

I cannot see the adapter startup. Are you sure the debug log starts before you started the instance?

Remarkable is that the log shows invalid incoming frames twice (search "WRONG" in the log). I had such too, but very rarely. This means that frames divided in several packages on TCP/IP level cannot be completely reassembled on the receiver (adapter) side. I cannot handle this problem within the adapter, there may be some network issue. The adapter just ignores such frames - looking for a "next chance" to get the data.

But nevertheless, the original issue you are reporting probably has a different root cause.

Btw, when you say "when the request is done", which request are you referring to? At a first glance, I can't see any "writing" tag sent by the adapter at all.

[Armin46]

Ich habe gerade gesehen das du aus der Gegend kommst ich wechsle mal ins Deutsch das macht das erklären etwas einfacher.

Du hattest recht der Start war nicht mehr drauf. Ich hab das ganze nochmal wiederholt. Im Log habe ich mal beide Versionen des Adapters eingefügt, jeweils start up und dann zwei Blöcke mit dem mitteleren Abfrage Intervall.

e3dc.txt

Beim Mittleren Abfrage Intervall tritt der Fehler auf und das bei jeder Abfrage also in meinem Fall 5 Minuten. Was mir jetzt da der Akku in verwendung ist auffällt ist das anscheined der Wechselrichter komplett einbricht bei den Abfragen, da auch die Entladung aus dem Akku kurz stoppt.

Richtig schreibvorgänge werden nicht getätigt der Fehler tritt bei dem aktualliseren der Daten auf.

[danielthoene]

Moin! Ich schreibe auch einfach mal deutsch :-)

Habe hier das gleiche Problem. Bei jedem M-Abfrage-Intervall startet der Wechselrichter neu.

Meldung im Log (beim Start des Adapters)

TAG_EMS_REQ_EMERGENCY_POWER_RETRY has no assigned polling interval - assuming 'M' - please check io-package.json TAG_EMS_REQ_EMERGENCY_POWER_OVERLOAD_STATUS has no assigned polling interval - assuming 'M' - please check io-package.json TAG_EMS_REQ_EMERGENCY_POWER_TEST_STATUS has no assigned polling interval - assuming 'M' - please check io-package.json TAG_EMS_REQ_WB_ENFORCE_POWER_ASSIGNMENT has no assigned polling interval - assuming 'M' - please check io-package.json TAG_EMS_REQ_WB_DISCHARGE_BAT_UNTIL has no assigned polling interval - assuming 'M' - please check io-package.json

Ich hole über den Adapter nur die EMS-Datenpunkte.

Der Wechselrichter gibt als Fehlercode 3 0x0 aus...

Gruß, Daniel

UPDATE: Version 1.2.3 funktioniert ohne Probleme! Fehler lässt sich bei mir nur mit 1.2.4 reproduzieren.

[git-kick]

@danielthoene, danke für die Meldung, damit wissen wir dass das kein Einzelfall ist. Was für eine Anlage hast du? (Modell, Baujahr, Firmware)

Die von dir genannten Log-Meldungen verschwinden, wenn du die Adapter-Config neu aufsetzt (leider hat der json-Import hier eine unangenehme Eigenschaft, nämlich neue Einträge zu löschen), siehe README.md

@Armin46, auch in deinen logs sind einige Meldungen "...has no assigned polling interval" - auch hier bitte eine frische Adapter-Konfiguration erzeugen.

[git-kick]

So, jetzt zur Eingrenzung des Problems. Neu in v1.2.4 sind nur folgende Request-Tags:

• TAG_EMS_REQ_EMERGENCY_POWER_OVERLOAD_STATUS
• TAG_EMS_REQ_EMERGENCY_POWER_RETRY
• TAG_EMS_REQ_WB_ENFORCE_POWER_ASSIGNMENT
• TAG_EMS_REQ_WB_DISCHARGE_BAT_UNTIL

D.h. die sind erstmal "verdächtig" - nur leider habe ich keinen einzigen Aufruf in den logs gefunden. Kann mir mal einer von Euch ein langes debug-log senden, 30 min oder so?

Alle Setter-Tags (die grundsätzlich "verdächtig" sind), enthalten meines Wissens REQ_SET oder REQ_START. Auch solche Tags habe ich nicht in den logs gefunden.

@Armin46, ich konnte im txt-file nicht erkennen, was von der v1.2.3 stammt - oder war alles v1.2.4? Es wäre gut, mal für beide Versionen ein 30 min debug-log zu haben, dann kann ich vergleichen, was effektiv nur vom v1.2.4 Adapter kommt.

Was mir (wie oben schon erwähnt) wirklich auffällt, sind die häufigen "Received message with inconsistent length" - das sieht ja fast reproduzierbar aus. Erste Hypothese sind Netzwerkprobleme, aber theoretisch kann es auch sein, dass die E3/DC-Firmware bei bestimmten Anfragen "verrückt spielt" und ungültige Frames schickt. @danielthoene, kannst du bitte auch ein debug-log vom Start des Adapters posten, dann kann ich sehen, ob dieser Effekt auch bei Dir da ist.

Das beobachtete Phänomen sieht ja wie ein "kurzer, begrenzter Absturz" in der E3/DC aus. Wir müssen also herausfinden, welcher Request ihn verursacht und diesen weglassen.

Mit einer neuen Adapter-Konfiguration könnte ihr die vier o.g. Request-Tags alle per "N" in den Polling Intervals ausknipsen - hilft das?

[danielthoene]

@git-kick Ich kann leider erst morgen Abend wieder "rumspielen" und dann berichten... Da das Auslesen und die Steuerung der PV-Anlage essentiell ist für mein Smarthome (Steuerung Wärmepumpe, Klimaanlagen und Luftentfeuchter, Brunnenpumpe etc pp) kann ich da nicht einfach zwischendurch drauf verzichten. Muss erst Vorkehrungen treffen ;-)

Bis dahin schon mal: S10 Mini Baujahr 2015 Firmware: S10_2023_024 (laut RCSP) bzw. S10_2023_02 (laut ModBus) 6,7 kWp 6,9 kWh Akku

Gruß, Daniel

[git-kick]

@danielthoene, danke für deine Antwort und keine Eile mit dem Rest - jeder tut, was er kann und mag, ist ja alles Freizeit :-)

Das mit dem "rumspielen" kann ich auch gut nachvollziehen, ich denke mit Unbehagen an das Testen der Funktion "Umschalten in Inselbetrieb" - jedesmal ein (kurzer) Stromausfall...

Zum Thema Vorkehrungen: bei mir bewährt sich sehr ein zusätzlicher ioBroker Host (in einer VM oder auch am Windows-PC im WSL). Da kann man den Adapter (auch andere, neue, interessante) gut ausprobieren, ohne die Produktionsumgebung anzufassen - natürlich nur, wenn man nichts schreibend macht oder wie im Fall v1.2.4 die Anlage Durcheinander bringt.

Zur Info: meine S10 von 2020 hat die selbe Firmware-Version S10_2023_024, also die ist eher nicht (allein) der Grund.

[danielthoene]

Moin!

Vorweg: 1.2.3 läuft bei mir stabil und ohne Probleme.

Also...

• Instanz gelöscht
• Adapter auf 1.2.4
• Instanz erstellt
• Config erstellt
• geloggt

e3dc-rscp124.txt

dann...

• Instanz gelöscht
• Adapter auf 1.2.3
• Instanz erstellt
• Config erstellt
• geloggt

e3dc-rscpv123.txt

Bei der 1.2.4 werden nicht alle (alten) Datenpunkte erstellt bzw. die Datenpunkte haben andere Namen - zumindest zicken einige meiner Scripte herum.

War das Logging soweit richtig? Kann ich noch mehr machen?

PS: In den Logs habe ich meine E-Mail-Adresse anonymisiert... Andere Benutzernamen oder Passwörter konnte ich nicht finden...

Gruß, Daniel

[Toskache]

Hier auch das gleiche Problem. Gestern Von github die 1.2.4 installiert und heute morgen startet der Wechselrichter nicht mehr. Weder via PV noch aus der Batterie. Wenn ich die Instanz deaktiviere startet der Wechselrichter. Wenn ich die Instanz wieder starte, geht der WR aus und versicht im Abfrageintervall neu zu starten. Wenn ich den ioBroker-Snapshot von vor dem Update einspiele (mit e3dc-rscp V1.2.3) funktioniert wieder alles.

[Armin46]

@danielthoene, danke für die Meldung, damit wissen wir dass das kein Einzelfall ist. Was für eine Anlage hast du? (Modell, Baujahr, Firmware)

Die von dir genannten Log-Meldungen verschwinden, wenn du die Adapter-Config neu aufsetzt (leider hat der json-Import hier eine unangenehme Eigenschaft, nämlich neue Einträge zu löschen), siehe README.md

@Armin46, auch in deinen logs sind einige Meldungen "...has no assigned polling interval" - auch hier bitte eine frische Adapter-Konfiguration erzeugen.

Ich habe jetzt die neue Adapter Konfiguration erzeugt jetzt funktionert es bei mir ohne aussetzter seit gestern abend.

[git-kick]

Report von @SurfGargano (#197):

Mit Version 1.2.4 und eingeschalteter EMS oder EP schaltet sich der Solar Wechselrichter ab. V 1.2.3 funktioniert.

Die Debug Ausgabe gibt keinen Fehler aus.

[git-kick]

Hier auch das gleiche Problem. Gestern Von github die 1.2.4 installiert und heute morgen startet der Wechselrichter nicht mehr. Weder via PV noch aus der Batterie. Wenn ich die Instanz deaktiviere startet der Wechselrichter. Wenn ich die Instanz wieder starte, geht der WR aus und versicht im Abfrageintervall neu zu starten. Wenn ich den ioBroker-Snapshot von vor dem Update einspiele (mit e3dc-rscp V1.2.3) funktioniert wieder alles.

@Toskache, hast du bei Installation von v1.2.4 eine ganz neue Adapterkonfig angelegt (also nicht ein *.json importiert)? Es gibt Hinweise, dass das einen Effekt hat. Und hast du den WB namespace eingeschaltet und eine Wallbox angeschlossen?

[git-kick]

Mit Version 1.2.4 und eingeschalteter EMS oder EP schaltet sich der Solar Wechselrichter ab. V 1.2.3 funktioniert.

Die Debug Ausgabe gibt keinen Fehler aus.

@SurfGargano, hast du bei Installation von v1.2.4 eine ganz neue Adapterkonfig angelegt (also nicht ein *.json importiert)? Es gibt Hinweise, dass das einen Effekt hat. Und hast du den WB namespace eingeschaltet und eine Wallbox angeschlossen?

[SurfGargano]

Ich habe keine neue Adapterkonfiguration angelegt. Gibt es einen anderen Weg als den Adapter zu löschen ?

[git-kick]

Ich habe keine neue Adapterkonfiguration angelegt. Gibt es einen anderen Weg als den Adapter zu löschen ?

Ich lösche immer den Adapter, aber Instanz löschen dürfte auch genügen. Leider löscht der *.json Import alles, was es in der alten Adapterversion noch nicht gab.

[git-kick]

e3dc-rscp124.txt

e3dc-rscpv123.txt

@danielthoene, danke dir. Im Vergleich der beiden logs fallen mir folgende zwei Tags auf, die nur in der v1.2.4 vorkommen:

• TAG_EMS_REQ_WB_DISCHARGE_BAT_UNTIL( UChar8 )
• TAG_EMS_REQ_WB_ENFORCE_POWER_ASSIGNMENT( Bool )

Beide werden mit 0 als Argument gesendet und stehen somit im Verdacht, etwas zu "schreiben". @ka-vaNu, du hast glaube ich diese Tags eingebaut, kannst du etwas über deren Semantik sagen?

Da bei mir (keine E3/DC Wallbox an der E3/DC angeschlossen) auch die v1.2.4 normal läuft, folgende Frage an alle: hat jemand das beschriebene Problem (Wechselrichter startet neu) und keine E3/DC Wallbox an der E3/DC angeschlossen?

[SurfGargano]

hat jemand das beschriebene Problem (Wechselrichter startet neu) und keine E3/DC Wallbox an der E3/DC angeschlossen?

Ja bei mir . S10E Compact, allerdings wenn ich nicht die Konfig neu anlege. Das andere habe ich noch nicht probiert

[SurfGargano]

So, habs probiert. Instanz gelöscht und neu angelegt. Funktioniert jetzt und der WR auch.

[git-kick]

OK, also hängt das Problem nicht davon ab, ob man eine E3/DC Wallbox angeschlossen hat.

Vielmehr sieht es so aus, dass das Problem mit einer neuen Adapterkonfiguration verschwindet. Frage an alle: hat jemand das Problem mit v1.2.4 trotz frischer Adapter-Konfiguration?

(Ich werde versuchen, das Thema Erneuerung der Adapterkonfiguration anzugehen; leider ist der *.json-Import nicht mein Code, sondern kommt als Standard mit.)

[danielthoene]

Moin!

Ich hatte bei meinem ersten Test trotz neuer Config Probleme -> Es wurde nur ein Bruchteil der Datenpunkte angelegt...

Habe es jetzt nochmal versucht (-> Instanz gelöscht; Adapter auf 1.2.4; neue Instanz erzeugt; neue Config "per Hand" eingetragen). Und siehe da: 1.2.4 lässt den WR nicht mehr abstürzen / neustarten! Im Log keine Fehler / Warnungen mehr. Keine Ahnung warum das beim ersten Test nicht ging...? Vorgehensweise war die gleiche.

Mein persönliches Fazit: Neue, "frische", "per Hand" erstellte Config ist beim Update Pflicht.

Und da die Frage aufkam: Ich habe auch keine WB angeschlossen. (S10 Mini von 2015)

Gruß, Daniel

[Toskache]

@Toskache, hast du bei Installation von v1.2.4 eine ganz neue Adapterkonfig angelegt (also nicht ein *.json importiert)? Es gibt Hinweise, dass das einen Effekt hat. Und hast du den WB namespace eingeschaltet und eine Wallbox angeschlossen?

Nein, leider habe ich keine neue Adapterkonfig angelegt - das hatte ich wohl überlesen. Und ich habe alle Namespaces angelegt - somit auch die "WB (Wallbox)"

Eine Frage zur neuen "Adapterkonfig": Ich müsste dafür ja die v1.2.3 entfernen und die v1.2.4 installieren. Neben den Einstellungen und den Abfrageintervallen gehen doch dabei auch die Einstellungen der Objekte (z.B. Export-Konfig für InfluxDB) verloren, oder? Das ist immer ein RIESENHASSEL das alles wieder einzurichten, da ich sehr viele Objekte in eine InxluxDB schiebe. Oder übersehe ich da was?

[git-kick]

Ich habe die Ursache gefunden.

TAG_EMS_REQ_EMERGENCY_POWER_RETRY heißt der Übeltäter. Ich habe den mit v1.2.4 eingebaut, dann aber wegen unklarer Semantik (ebenso wie TAG_EMS_REQ_EMERGENCY_POWER_OVERLOAD_STATUS) in der Konfiguration auf "N" gesetzt. D.h. mit frischer Konfiguration wird das Tag nie gesendet und das Problem tritt nicht auf. Dagegen wird bei Wiederverwendung der Konfiguration über *.json das Intervall auf "M" gesetzt (das steht auch im Log, aber gut versteckt unter vielen ähnlichen Meldungen).

Da ich jetzt weiß, dass dieses Tag "gefährlich" ist, werde ich folgendes tun:

1. Die v1.2.4 nicht auf "stable" setzen und im README warnen. - erledigt -
2. Ab v1.2.5 die beiden o.g. Tags im Code auskommentieren, so dass sie nicht mehr gesendet werden können. - erledigt -
3. Weiter forschen, wie ich die Dauermisere mit dem *.json-Import verbessern kann, so dass neue Konfig-Parameter nicht mehr verschwinden und somit die bestehende Konfiguration behalten werden kann. - offen -

Für Euch bedeutet das im Moment (bis v1.2.5 da ist): Option 1. = zurück auf v1.2.3 Option 2. = Einsatz der v1.2.4 nur mit frischer Konfiguration und Polling Intervall TAG_EMS_REQ_EMERGENCY_POWER_RETRY = "N" (Default). Option 3. = vom aktuellen master installieren - da ist Maßnahme (2.) von oben schon umgesetzt, sollte also das vorliegende Problem (auch mit wiederverwendeter Konfig) beheben.

[Toskache]

Feedback: v1.2.4 (master) installiert und funktioniert (auch ohne neue Konfig) ;-) Vielen Dank für die klasse Arbeit!

[git-kick]

Danke an Euch alle für Feedback und tatkräftige Unterstützung (Test&Logs) - nur so wird der Adapter besser!