.PVI_0.String_0.DC_POWER and .PVI_0.String_1.DC_POWER not updating and not in setup list

[smartboart]

Describe the bug

Hello, PVI_0.String_0 and 1 is missing in the Tag List. Only TAG_PVI_REQ_DC_STRING_ENERGY_ALL is present.
So the states for String 0 and 1 not getting updated .
The state String Energy all is getting updated in this case.
After a reboot the String 0 and 1 information were polling again.

see pictures..

Versions:

• Adapter version: 1.1.1
• JS-Controller version: 4.0.24
• Node version: v18.15.0
• Operating system: debian buster / RPI4 8GB
• NPM: 9.5.0

Additional context
I need the states for String 1 and 2 stable and constantly polling for my vis. ...It would be great to habhave this states in the setup tag list...thanks..
The firmware Version of the E3DC would also be great to have. TheModbus Adapter is providing this...

[git-kick]

Hi and thanks for your report.

The firmware Version of the E3DC would also be great to have.

This is content of the INFO namespace, which is not yet supported. I created #149 for this.

[git-kick]

PVI_0.String_0 and 1 is missing in the Tag List. Only TAG_PVI_REQ_DC_STRING_ENERGY_ALL is present.
So the states for String 0 and 1 not getting updated .

Only request-tags are listed in the Polling Intervals list, because the adapter can only control the send time of requests.
With my E3/DC S10, all STRING.DC_... values are reported properly.
Therefore I can exclude that the root cause of the issue is a missing Polling Interval list entry.

We have seen similar issues (particularly with new battery types) when E3/DC introduced new components but did not - at least not so far - update the firmware so that it propagates all values for the new components over RSCP.

This is only a first suspicion, so if you want me to dig in, please provide a silly-log:

1. stop instance
2. delete log
3. set instance to log mode "silly"
4. start instance an let it run for ca. 1 minute
5. store log in a file and make sure to delete cleartext passwords which are logged upon authentication (this will be fixed in v1.1.2)
6. attach logfile to the issue (no inline log please; it's too long)

[smartboart]

Hello, here is the log file...
I need to inform you, that in this log everything went fine. I have watched this behavior 2 times. Only 2 times because i have just yesterday changed my vis from modbus states to RSCP... A restart always fixed the issue.
My E3DC-S10EPro is from 2020.
RSCP_silly_log.txt

[git-kick]

Okay... then it is not worth inspecting the log now.

I find it hard to estimate how large a silly-log will grow untli the error occurs. Perhaps it is better to do something like

1. start normal operation (info log)
2. wait until error occurs
3. delete log
4. set instance to "silly" without restart
5. wait some time until error reoccurs (see Polling Interval setting)
6. save the log...

[ArnoD15]

Hallo Smartboart,
kann es sein, dass es in der Zeit passiert, wo dein Wechselrichter in den Standby-Modus wechselt, um Strom zu sparen?
Mir ist das bei den Temperatur Werten vom WR aufgefallen, dass dann keine Werte mehr vom E3DC übertragen werden.
Habe es jetzt bei mir mal geprüft und in dem gleichen Zeitraum werden auch die Volt, Watt Werte der einzelnen Strings nicht mehr übertragen und auch keine Watt werte der drei Phasen.
Wenn der WR sich wieder einschaltet, funktioniert alles wieder ohne Neustart vom Adapter.
Komisch ist nur, dass es über den Modbus Adapter ja funktioniert.
Denke, das ist eher was für ein Ticket bei E3DC.

[smartboart]

Hi Arno...Könnte gut sein...habe mal ein Chart zusammen gebaut mit den Historie Daten...
Man sieht das Bat Power gegen 0 geht. Später sind dann die Daten weg..Könnte also mit dem Energiesparmodus zu tun haben..

[smartboart]

Heute wieder keine Aktualisierung der PV String Weerte....siehe Bild.leider war der log nicht auf silly, habe aber im laufenden Betrieb umgestellt ohne Adapter neustart. Der log ist angehängt.
This time a restard do not fix it. And the E3DC is not in idle mode...
RSCP_silly_log_ohne Neustart.txt

[smartboart]

um ca. 12:30 ohne zutun wurden dann wieder Daten für String Leistung übergeben.

[git-kick]

So wie ich das sehe, liegt das Problem höchstwahrscheinlich nicht im Adapter, sondern auf der S10-Seite.

[git-kick]

Das Thema wird in #160 weiter bearbeitet.