e3dc-rscp.0.PVI.PVI_0.Phase_[0|1|2].AC_VOLTAGE und e3dc-rscp.0.PVI.PVI_0.TEMPERATURE.[00|01|02|03] liefern keine Werte mehr #160

Toskache · 2023-05-08T07:48:05Z

Seit dem Update auf 1.2.1 bleibt die Datenerfassung von

e3dc-rscp.0.PVI.PVI_0.Phase_[0|1|2].AC_VOLTAGE und
e3dc-rscp.0.PVI.PVI_0.TEMPERATURE.[00|01|02|03]

regelmäßig stehen und es werden keine Werte mehr ausgelesen.
Das gleiche Verhalten ist auch mit der Version 1.2.2 zu beobachten.

Wenn man den Adapter neu startet, kommen die Werte wieder an.

Versions:

Adapter version: 1.2.1 und 1.2.2
"iobroker -v" = 4.0.24
Operating system: docker unter Unraid

The text was updated successfully, but these errors were encountered:

git-kick · 2023-05-08T08:39:24Z

Das sieht aus wie in #148
Wir glauben, das ist ein Thema in der E3/DC, kein Adapterthema.
Ich werde einen Hinweis ins README aufnehmen.

Toskache · 2023-05-08T08:44:38Z

Hmm, komisch ist nur, dass es

mit den vorherigen Versionen hat es durchgehend funktioniert hat,
alle anderen Werte des Adapters weiter durchgehend abgerufen werden und
nach einem Neustart des Adapters die Werte wieder reinkommen.

git-kick · 2023-05-08T08:58:10Z

Im Moment sehe ich keinen Ansatzpunkt, im Adapter einen Fehler zu suchen. Ich habe das Problem nicht und auch keine logs, die die Auffälligkeiten zeigen.

Vielleicht kannst du mit den anderen Betroffenen in #148 noch weitere Hinweise / Muster / Verdachtsmomente sammeln.

Toskache · 2023-05-08T09:40:54Z

Ok, werde ich versuchen.
Anbei schon einmal ein "Silly-Log" mit folgender Historie:

Adapter gestoppt
Log geleert
silly-mode eingeschaltet
Adapter gestartet
Hänger war da (--> Zeile 156)
Adapter neu gestartet (--> Zeile 34843)
Hänger war weg
Log gestopt

Hier hören meine "Interpretations-Künste" jedoch auf ;-)

33dc-rscp_silly.log

git-kick · 2023-05-08T14:04:47Z

Danke für das Log und die Voranalyse! Ich denke damit komme ich dem Problem näher.

Der Adapter sendet zu Beginn für BAT und PVI sog. probing Nachrichten um herauszufinden, wieviele BAT und wieviele PVI die Anlage hat. Kommt z.B. für PVI#0 eine Antwort mit Daten, dann merkt sich der Adapter, dass es PVI#0 gibt. Kommt dann für PVI#1 und PVI#2 eine Fehlerantwort, dann ist das Thema erledigt und der Adapter fragt künftig immer nur PVI#0 ab.
(Leider sind für RSCP keine Tags dokumentiert, mit denen man die Anzahl von PVIs und BATs abfragen kann.)

Im log sehe ich nun die drei probing-Requests nach dem ersten Instanz-Start

Zeile 101: PVI#0 - keine Antwort
Zeile 126: PVI#1 - Antwort "Fehler"
Zeile 144: PVI#2 - Antwort "Fehler"

Und hier ist das Problem: der Adapter interpretiert das als "keine PVI vorhanden" - was falsch ist.

Stattdessen lohnt es sich, das nochmal zu probieren, denn nach dem zweiten Instanz-Start läuft alles gut:

Zeile 34918: PVI#0 - Antwort mit gültigen Daten
Zeile 34938: PVI#1 - Antwort "Fehler"
Zeile 34956: PVI#2 - Antwort "Fehler"

Dies ist das erwartete Verhalten mit 1 PVI.

Es kommt also vor, dass ein Request oder die Antwort irgendwie verloren geht. Normalerweise repariert sich das selbst, bei der nächsten Abfrage werden die Daten ja wieder aktualisiert - aber hier führt es zum Fehlverhalten, weil der Adapter den probing-Request nur einmal sendet.

Ich überlege mir irgendetwas mit einem Timer/Retry, damit der Adapter da robuster wird.

Dass das Verhalten in vorherigen Adapter-Versionen immer i.O. war, muss Zufall sein - an der probing-Logik habe ich schon sehr lange nichts mehr geändert.

Dass das Problem immer mal wieder im laufenden Betrieb auftritt und dann wieder verschwindet, kann ich mir nur mit Instanz-Restarts (manuell herbeigeführt oder sonstwie, durch ioBroker) erklären. Hast du jedesmal, bevor es wieder ging, manuell neu gestartet? (einmal sehe ich in der Grafik, dass ab ca. 03:00 Uhr wieder Werte kommen)

Toskache · 2023-05-08T14:21:30Z

Das hört sich ja super an! Danke!
Als ich festgestellt habe, dass hin und wieder die Daten fehlten und ein Neustart des Adapters hilft, habe ich den Adapter automatisch (ich glaube jede Stunde) neu starten lassen. Das war aber auch nicht jedes mal erfolgreich, was sich natürlich durch Deine Ausführung erklären lässt. Im Gegenteil ist ein solcher automatischer Neustart gefährlich, da dadurch ein funktionierender Adapter "kaputt" gehen kann. Ich habe dann heute früh den automatischen Neustart deaktiviert. Seitdem läuft es - bis jetzt zumindest.

Warum der Adapter früher stabiler war erschließt sich mir auch nicht. Ich benutze zeitgleich auch die my3E-App, welch auch via RSCP mit der Anlage (P10_2022_046) kommuniziert. Vielleicht kommen sich die Abfragen "ins Gehege"!? Zumindest ändert sich laut Changelog sehr viel an der my3e-RSCP-Schnittstelle.

BTW: Meine Anlage hat auch noch nie Werte im TAG_PVI_REQ_FREQUENCY_UNDER_OVER geliefert - aber das ist wohl ein anderes Problemchen.

Und nochmals vielen Dank für Deinen Einsatz und Deine Unterstützung!

PS: Falls relevant: Ich setze hier auch das ChargeControl-Skript von ArnoD15 ein https://github.com/ArnoD15/iobroker_E3DC

git-kick · 2023-05-08T14:33:04Z

BTW: Meine Anlage hat auch noch nie Werte im TAG_PVI_REQ_FREQUENCY_UNDER_OVER geliefert - aber das ist wohl ein anderes Problemchen.

zu TAG_PVI_REQ_FREQUENCY_UNDER_OVER siehe #126 - ich nehme an, deine Anlage gehört zu denen, die das nicht senden.

git-kick · 2023-05-08T14:35:52Z

Ich benutze zeitgleich auch die my3E-App, welch auch via RSCP mit der Anlage (P10_2022_046) kommuniziert. Vielleicht kommen sich die Abfragen "ins Gehege"!? Zumindest ändert sich laut Changelog sehr viel an der my3e-RSCP-Schnittstelle.

Was genau ist die "my3E-App" und die "my3e-RSCP-Schnittstelle"? Kannst du mir dazu bitte einen Link geben?

Toskache · 2023-05-08T16:25:47Z

Ich benutze zeitgleich auch die my3E-App, welch auch via RSCP mit der Anlage (P10_2022_046) kommuniziert. Vielleicht kommen sich die Abfragen "ins Gehege"!? Zumindest ändert sich laut Changelog sehr viel an der my3e-RSCP-Schnittstelle.

Was genau ist die "my3E-App" und die "my3e-RSCP-Schnittstelle"? Kannst du mir dazu bitte einen Link geben?

my3E ist eine geniale iOS-App, die Live- und Historisch Daten schick aufbereitet (inkl. Ust.- Unterstützung) https://my3e.de/

git-kick · 2023-05-08T16:43:31Z

my3E ist eine geniale iOS-App, die Live- und Historisch Daten schick aufbereitet (inkl. Ust.- Unterstützung) https://my3e.de/

Da hab ich Pech, weil Android - trotzdem danke.

git-kick · 2023-05-15T10:08:57Z

Im master branch ist jetzt eine neue Art des "probings" implementiert. Der Adapter startet mit 2 BATs und 3 PVIs und reduziert den maxIndex dann bei entsprechenden Fehlernachrichten von der E3/DC.

Im info-Log wird berichtet, die die beiden maxIndex nach dem Adapterstart angepasst werden.

Vielleicht kannst du @Toskache mal testen, die Änderung war ziemlich tricky, nicht dass ich eine Regression eingebaut habe... wenn alles passt, kommt demnächst das v1.2.2 release.

Toskache · 2023-05-15T18:17:40Z

Vielleicht kannst du @Toskache mal testen, die Änderung war ziemlich tricky, nicht dass ich eine Regression eingebaut habe... wenn alles passt, kommt demnächst das v1.2.2 release.

Ich werde es jetzt mal installieren und testen.

Toskache · 2023-05-16T09:49:34Z

@git-kick
Es scheint so, als ob seit der aktuellen Version keine Werte mehr für
e3dc-rscp.0.PVI.PVI_0.String_0.DC_POWER und e3dc-rscp.0.PVI.PVI_0.String_1.DC_POWER reinkommen.
e3dc-rscp.0.EMS.POWER_PV wird jedoch mit Werten gefüttert
Andere "fehlende" Werte sind mir bisher nicht aufgefallen.

33dc-rscp_silly.log

git-kick · 2023-05-16T09:54:15Z

ok danke, ich schau mir das an, sobald ich Zeit finde.

Toskache · 2023-05-16T13:54:50Z

Nachtrag:
Ich glaube alles aus e3dc-rscp.0.PVI.PVI_0.String_0 und e3dc-rscp.0.PVI.PVI_0.String_1 wird nicht mehr aktualisiert....

git-kick · 2023-05-18T17:42:15Z

Bei mir kommen die Werte, also ist es kein grundsätzlicher Fehler.

In deinem Log kann ich sehen, dass die nötige TAG_PVI_REQ_DC_POWER Anfrage nie vorkommt.
(Sie müsste als Teil von TAG_PVI_REQ_DATA abgegeben sein, damit die Anlage die DC-Werte liefert.)
Hier ein Auszug aus deinem log, in dem man sieht, was alles angefragt wird:

2023-05-16 11:35:45.384 - silly: e3dc-rscp.0 (6905) OUT: magic: >E3DC< is OK - ctrl: >0011< is OK - Version 1, with CRC - seconds: 1684229745 - nseconds: 0 - length: 325
TAG_PVI_REQ_DATA - type: 0x0E - Container - length: 318
TAG_PVI_INDEX - type: 0x05 - UInt16 - length: 2 value: 0
TAG_PVI_REQ_TEMPERATURE_COUNT - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_TYPE - type: 0x00 - None - length: 0
TAG_PVI_REQ_SERIAL_NUMBER - type: 0x00 - None - length: 0
TAG_PVI_REQ_VERSION - type: 0x00 - None - length: 0
TAG_PVI_REQ_ON_GRID - type: 0x00 - None - length: 0
TAG_PVI_REQ_STATE - type: 0x00 - None - length: 0
TAG_PVI_REQ_LAST_ERROR - type: 0x00 - None - length: 0
TAG_PVI_REQ_VOLTAGE_MONITORING - type: 0x00 - None - length: 0
TAG_PVI_REQ_POWER_MODE - type: 0x00 - None - length: 0
TAG_PVI_REQ_SYSTEM_MODE - type: 0x00 - None - length: 0
TAG_PVI_REQ_AC_MAX_PHASE_COUNT - type: 0x00 - None - length: 0
TAG_PVI_REQ_MAX_TEMPERATURE - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_MIN_TEMPERATURE - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_AC_MAX_APPARENTPOWER - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_DEVICE_STATE - type: 0x00 - None - length: 0
TAG_PVI_REQ_AC_POWER - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_AC_VOLTAGE - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_AC_CURRENT - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_AC_APPARENTPOWER - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_AC_REACTIVEPOWER - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_AC_ENERGY_ALL - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_AC_ENERGY_GRID_CONSUMPTION - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_AC_POWER - type: 0x03 - UChar8 - length: 1 value: 0x01
TAG_PVI_REQ_AC_VOLTAGE - type: 0x03 - UChar8 - length: 1 value: 0x01
TAG_PVI_REQ_AC_CURRENT - type: 0x03 - UChar8 - length: 1 value: 0x01
TAG_PVI_REQ_AC_APPARENTPOWER - type: 0x03 - UChar8 - length: 1 value: 0x01
TAG_PVI_REQ_AC_REACTIVEPOWER - type: 0x03 - UChar8 - length: 1 value: 0x01
TAG_PVI_REQ_AC_ENERGY_ALL - type: 0x03 - UChar8 - length: 1 value: 0x01
TAG_PVI_REQ_AC_ENERGY_GRID_CONSUMPTION - type: 0x03 - UChar8 - length: 1 value: 0x01
TAG_PVI_REQ_AC_POWER - type: 0x03 - UChar8 - length: 1 value: 0x02
TAG_PVI_REQ_AC_VOLTAGE - type: 0x03 - UChar8 - length: 1 value: 0x02
TAG_PVI_REQ_AC_CURRENT - type: 0x03 - UChar8 - length: 1 value: 0x02
TAG_PVI_REQ_AC_APPARENTPOWER - type: 0x03 - UChar8 - length: 1 value: 0x02
TAG_PVI_REQ_AC_REACTIVEPOWER - type: 0x03 - UChar8 - length: 1 value: 0x02
TAG_PVI_REQ_AC_ENERGY_ALL - type: 0x03 - UChar8 - length: 1 value: 0x02
TAG_PVI_REQ_AC_ENERGY_GRID_CONSUMPTION - type: 0x03 - UChar8 - length: 1 value: 0x02
TAG_PVI_REQ_TEMPERATURE - type: 0x03 - UChar8 - length: 1 value: 0x00
TAG_PVI_REQ_TEMPERATURE - type: 0x03 - UChar8 - length: 1 value: 0x01
TAG_PVI_REQ_TEMPERATURE - type: 0x03 - UChar8 - length: 1 value: 0x02
TAG_PVI_REQ_TEMPERATURE - type: 0x03 - UChar8 - length: 1 value: 0x03
CRC32

All diese Werte müssten auch bei Dir aktualisiert werden, kannst du das bestätigen?

Stellt sich die Frage, warum der Adapter bei dir nicht auch nach DC_POWER fragt.
Erster Ansatz: bitte schau in den Adaptereinstellungen unter "Abfrageintervalle", was bei TAG_PVI_REQ_DC_POWER steht.
(Wäre das 'N', dann hätten wir die Lösung - aber das ist wahrscheinlich zu einfach ;)

Toskache · 2023-05-18T18:42:45Z

Hm, leider scheint die Lösung nicht so einfach zu sein:

Ich habe hier auch schon andere Werte erfolglos probiert.

Wobei die o.g. AC-Werte wohl alle aktualisiert werden nur mit der den beiden Strings (DC) sieht es düster aus:

NACHTRAG 1:
Ich habe jetzt mal wieder dieVersion 1.1.2 installiert. Damit werden wieder alle Werte installiert.

NACHTRAG 2 :
Das ist reproduzierbar
Installiere ich die 1.2.2: keine Wertaktualisierung
Installiere ich die 1.1.2: Werte werden aktualisiert

git-kick · 2023-05-19T07:36:58Z

Bei mir kommen die Werte, also ist es kein grundsätzlicher Fehler.

Das war eine Falschmeldung von mir. Ich habe es jetzt auch nachvollzogen.

Tatsächlich ist beim Umbau des "probing" die Abfrage PVI_REQ_DC_MAX_STRING_COUNT verloren gegangen, d.h. der Adapter hat nie nach der Anzahl der Strings gefragt und deshalb so getan, als gäbe es keine.

Das ist im master korrigiert.

Dagegen konnte ich die Thematik bei TEMPERATURE noch nicht nachvollziehen. Hier zeigt ja auch der Ausschnitt aus deinem log , dass die Anfragen korrekt rausgehen. Falls du weiterhin keine TEMPERATURE-Werte bekommst, melde dich bitte nochmal, das ist dann ggf. ein anderer Fehler.

Danke für dein geduldiges Testen und die genaue Beschreibung, die mich auf die Fährte gebracht hat!

Toskache · 2023-05-19T12:31:47Z

@git-kick
Ich habe den master eingespielt und es sieht soweit gut aus! Ich werde das mal beobachten.
Wie kommst Du darauf, dass ich mit den TEMPERATURE-Werten ein Problem habe? Die Werte kamen immer.

git-kick · 2023-05-19T13:08:54Z

Wie kommst Du darauf, dass ich mit den TEMPERATURE-Werten ein Problem habe? Die Werte kamen immer.

Siehe Titel des Issues...

Toskache · 2023-05-19T13:47:40Z

Ja, die Temperaturen waren beim öffnen des issues weg. Mit dem ersten probing-fix wurden die Temperaturen wieder aktualisiert. Nur e3dc-rscp.0.PVI.PVI_0.String_0.* und e3dc-rscp.0.PVI.PVI_0.String_1.* wurden nicht aktualisiert.
Jetzt sieht soweit alles wieder gut aus.

git-kick · 2023-05-19T17:35:36Z

Sehr gut, dann lass ich die v1.2.2 noch eine Weile "abhängen" und wenn nicht noch etwas aufkommt, wird das ein Release.

git-kick · 2023-05-26T09:50:23Z

Release v1.2.2 ist auf npm (noch nicht "stable" in ioBroker-Repo).

git-kick self-assigned this May 8, 2023

git-kick added the out-of-adapter-scope E.g. issue of E3/DC firmware label May 8, 2023

git-kick closed this as completed May 8, 2023

git-kick added bug Something isn't working high prio Item is near top of backlog and removed out-of-adapter-scope E.g. issue of E3/DC firmware labels May 8, 2023

git-kick reopened this May 8, 2023

git-kick added this to the v1.2.2 milestone May 8, 2023

git-kick mentioned this issue May 8, 2023

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

Closed

git-kick added a commit that referenced this issue May 8, 2023

revised changes due to #160

5c2681f

git-kick mentioned this issue May 26, 2023

Update e3dc-rscp to 1.2.2 ioBroker/ioBroker.repositories#2310

Merged

git-kick closed this as completed May 26, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

e3dc-rscp.0.PVI.PVI_0.Phase_[0|1|2].AC_VOLTAGE und e3dc-rscp.0.PVI.PVI_0.TEMPERATURE.[00|01|02|03] liefern keine Werte mehr #160

e3dc-rscp.0.PVI.PVI_0.Phase_[0|1|2].AC_VOLTAGE und e3dc-rscp.0.PVI.PVI_0.TEMPERATURE.[00|01|02|03] liefern keine Werte mehr #160

Toskache commented May 8, 2023 •

edited

Loading

git-kick commented May 8, 2023

Toskache commented May 8, 2023

git-kick commented May 8, 2023

Toskache commented May 8, 2023 •

edited

Loading

git-kick commented May 8, 2023

Toskache commented May 8, 2023 •

edited

Loading

git-kick commented May 8, 2023 •

edited

Loading

git-kick commented May 8, 2023

Toskache commented May 8, 2023

git-kick commented May 8, 2023

git-kick commented May 15, 2023

Toskache commented May 15, 2023

Toskache commented May 16, 2023 •

edited

Loading

git-kick commented May 16, 2023

Toskache commented May 16, 2023

git-kick commented May 18, 2023 •

edited

Loading

Toskache commented May 18, 2023 •

edited

Loading

git-kick commented May 19, 2023

Toskache commented May 19, 2023 •

edited

Loading

git-kick commented May 19, 2023

Toskache commented May 19, 2023

git-kick commented May 19, 2023

git-kick commented May 26, 2023

e3dc-rscp.0.PVI.PVI_0.Phase_[0|1|2].AC_VOLTAGE und e3dc-rscp.0.PVI.PVI_0.TEMPERATURE.[00|01|02|03] liefern keine Werte mehr #160

e3dc-rscp.0.PVI.PVI_0.Phase_[0|1|2].AC_VOLTAGE und e3dc-rscp.0.PVI.PVI_0.TEMPERATURE.[00|01|02|03] liefern keine Werte mehr #160

Comments

Toskache commented May 8, 2023 • edited Loading

git-kick commented May 8, 2023

Toskache commented May 8, 2023

git-kick commented May 8, 2023

Toskache commented May 8, 2023 • edited Loading

git-kick commented May 8, 2023

Toskache commented May 8, 2023 • edited Loading

git-kick commented May 8, 2023 • edited Loading

git-kick commented May 8, 2023

Toskache commented May 8, 2023

git-kick commented May 8, 2023

git-kick commented May 15, 2023

Toskache commented May 15, 2023

Toskache commented May 16, 2023 • edited Loading

git-kick commented May 16, 2023

Toskache commented May 16, 2023

git-kick commented May 18, 2023 • edited Loading

Toskache commented May 18, 2023 • edited Loading

git-kick commented May 19, 2023

Toskache commented May 19, 2023 • edited Loading

git-kick commented May 19, 2023

Toskache commented May 19, 2023

git-kick commented May 19, 2023

git-kick commented May 26, 2023

Toskache commented May 8, 2023 •

edited

Loading

Toskache commented May 8, 2023 •

edited

Loading

Toskache commented May 8, 2023 •

edited

Loading

git-kick commented May 8, 2023 •

edited

Loading

Toskache commented May 16, 2023 •

edited

Loading

git-kick commented May 18, 2023 •

edited

Loading

Toskache commented May 18, 2023 •

edited

Loading

Toskache commented May 19, 2023 •

edited

Loading