Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Matis]

Das hat mir keine Ruhe gelassen, Instanz komplett gelöscht und neu installiert, jetzt habe ich Werte bei RESERVE, zwar nicht bei TIME_LAST, aber das kann daran liegen, dass seither das Ereignis ja nicht passiert ist. So ist schon mal super.

[Matis]

@ujok Hab jetzt mal mit der Aktualisierung der RESERVE getestet.
Wenn ein Wert auf einen anderen Wert gesetzt wird, wir NICHT aktualisiert, der alte Wert bleibt stehen.
Wird aber von einem Wert auf 0 Reserve geändert, dann wird aktualisiert.
Also da ist noch der Wurm drin, irgendwie.

[ArnoD]

@matis
Habe die Aktualisierung der Reserve auch noch mal getestet.
Wenn ich die Instanz neu starte, werden die Werte abgerufen und aktualisiert.
Wenn ich kurz nach dem Neustart der Instanz den Wert Reserve wieder ändere, wird dieser auch noch aktualisiert.
Wenn ich dann etwas warte und die Reserve wieder ändere, wird nichts mehr aktualisiert.
Eigentlich das Gleiche verhalten wie bei dem Wert "e3dc-rscp.0.EMS.POWER_PV" der auch nur nach dem Neustart der Instanz ca. 3 sek. Aktualisiert wird und dann nicht mehr.

Folgende States werden bei mir gar nicht angezeigt bzw. aktualisiert:
e3dc-rscp.0.EP.PARAM_0.PARAM_LAST_SOC
e3dc-rscp.0.EP.PARAM_0.PARAM_TIME_LAST_EMPTY
e3dc-rscp.0.EP.PARAM_0.PARAM_TIME_LAST_FULL

[Matis]

@arnod
Da hast du völlig Recht, das ist bei mir exakt das selbe. Ich hab wohl in den ersten Sek. immer auf 0 geändert :)

[brumark]

Gibt es eine Einschränkung beim setzen des Polling Intervalls?

Wenn ich das Intervall für die folgenden TAGs von L auf M ändere, dann werden die gesamten Batteriedaten beim Start genau einmal abgefragt, danach nie wieder.

• TAG_BAT_REQ_FCC
• TAG_BAT_REQ_RC
• TAG_BAT_REQ_USABLE_CAPACITY
• TAG_BAT_REQ_USABLE_REMAINING_CAPACITY

Es scheint so, als ob die Anfrage nicht mehr geschickt wird. Bin für einen Tipp dankbar.

[Schnutexxl]

Hallo Zusammen,

hat denn schon Jemand die HISTORY_DATA genutzt? Per Script die Daten aktualisieren und mit dem History Adapter dann speichern, dass man sie u.a. in VIS nutzen kann?

Schöne Grüße

[kysr]

Hallo zusammen,

ist es möglich mit dem Adapter kWh Tages-/Montas/Jahreswerte auszulesen oder habt ihr das über eine Berechnung gelöst?

[TbsJah]

@kysr zusammen mit sourceanalytics ist das problemlos möglich.
Alternativ über die history Werte

[ArnoD]

@brumark sagte in Test Adapter e3dc-rscp v0.0.x GitHub:

Gibt es eine Einschränkung beim setzen des Polling Intervalls?

Wenn ich das Intervall für die folgenden TAGs von L auf M ändere, dann werden die gesamten Batteriedaten beim Start genau einmal abgefragt, danach nie wieder.

• TAG_BAT_REQ_FCC
• TAG_BAT_REQ_RC
• TAG_BAT_REQ_USABLE_CAPACITY
• TAG_BAT_REQ_USABLE_REMAINING_CAPACITY

Es scheint so, als ob die Anfrage nicht mehr geschickt wird. Bin für einen Tipp dankbar.

Wenn sich der Wert nicht ändert, dann wird auch nichts aktualisiert.
Dachte am Anfang auch das die Werte nicht aktualisiert werden.
Kannst du prüfen, indem du dir die Werte merkst und dann die State löscht und die Instanz neu startest,
wenn jetzt die gleichen Werte eingetragen werden dann liegt es daran das diese sich nicht ändern und dann natürlich auch nicht aktualisiert werden.

[TbsJah]

Habt ihr bereits das regulieren der Ladleistung versucht und hat es funktioniert?
Entscheidend sind doch diese 3 Werte oder habe ich hier ein Missverständnis?

Egal welche Werte ich gesetzt habe, es hatte keine Auswirkung. Es wurde immer 100 % geladen

[git-kick]

@kysr said in Test Adapter e3dc-rscp v0.0.x GitHub:

Hallo zusammen,

ist es möglich mit dem Adapter kWh Tages-/Montas/Jahreswerte auszulesen oder habt ihr das über eine Berechnung gelöst?

Hallo @kysr, setz doch mal in DB.HISTORY_DATA_YEAR den TIME_START Wert, dann bekommst du 12 Monatswerte.

[ArnoD]

@tbsjah

Ja. Habe ich getestet und es funktioniert generell schon mal.
In den Einstellungen der Instanz musst du auch die Wiederholintervalle richtig einstellen, da sonst E3DC wieder die Regelung übernimmt.

Mit SET_POWER_VALUE stellt man den Wert ein und mit SET_POWER_Mode den Modus, also idle, discharge, charge oder grid_charge.

[git-kick]

@tbsjah said in Test Adapter e3dc-rscp v0.0.x GitHub:

Habt ihr bereits das regulieren der Ladleistung versucht und hat es funktioniert?
Entscheidend sind doch diese 3 Werte oder habe ich hier ein Missverständnis?

Egal welche Werte ich gesetzt habe, es hatte keine Auswirkung. Es wurde immer 100 % geladen

Ja stimmt, wobei SET_POWER rein lesend ist und den eingestellten Wert widerspiegeln sollte.
Bei mir ist das Verhalten anders: ich setze SET_POWER_MODE auf "Charge" und dann SET_POWER_VALUE auf die gewünschten Watt. Die Ladeleistung wird reduziert, aber nur kurz, dann schwankt sie etwa im 30-Sekunden-Takt zwischen dem eingestellten Wert und dem maximal möglichen, siehe blaue Linie in ff. Grafik:

Der Kommentar in der E3/DC Tag-Liste zu SET_POWER lautet:
Mit diesem TAG kann in die Regelung des S10s eingegriffen werden. / Bei DC-Systemen ist die Ladeleistung auf die anliegende PV-Leistung beschränkt, bei AC und Hybrid-Systemen kann die Ladeleistung auch größer der PV-Leistung sein. / Achtung: Wenn mit diesem Kommando eingegriffen wird, wird eine eventuell gesetzte Einspeisereduzierung NICHT beachtet! / Achtung: Das Kommando muss mindestens alle 30 Sekunden gesetzt werden, ansonsten geht das EMS in den Normalmodus.
Dementsprechend wiederholt der Adapter die SET_POWER Nachricht alle 15 Sekunden (einstellbar im Admin-Dialog).

Mir ist momentan nicht klar, warum die Ladeleistung nicht durchgehend unten auf dem gesetzten Wert bleibt - wer eine Idee dazu hat, immer her damit :grin:

[Schnutexxl]

@ujok Ich bin auch an einer vernünftigen History interessiert. Das mit dem Setzen des Datenpunktes habe ich verstanden, aber wie kann man das nun realisieren, dass man mit dem History Adapter diese Daten speichern kann. Ich denke mit einem Script geht das, aber mir fehlt hier das nötige Verständnis.

[git-kick]

@schnutexxl said in Test Adapter e3dc-rscp v0.0.x GitHub:

@ujok Ich bin auch an einer vernünftigen History interessiert. Das mit dem Setzen des Datenpunktes habe ich verstanden, aber wie kann man das nun realisieren, dass man mit dem History Adapter diese Daten speichern kann. Ich denke mit einem Script geht das, aber mir fehlt hier das nötige Verständnis.

Der Adapter speichert die empfangenen Daten im Objektbaum, so wie es die meisten Adapter machen. Meines Wissens ist in ioBroker Javascript das Standardtool, um auf die Daten zuzugreifen. Vielleicht kann man auch einen Visualisierungs- oder anderen Datenbank-Adapter auf den Objektbaum aufsetzen. Da gibt es tausend Möglichkeiten.

@ArnoD hat den Vorschlag gemacht, die Daten als JSON-Datei abzulegen; diese Anforderung hat sich aber dann nicht weiter konkretisiert.

Also im Moment gibt es nur den Objektbaum, "as is".
Wenn jemand einen konkreten Vorschlag macht, wie der Adapter die Daten zusätzlich noch bereitstellen soll, damit viele das besser nutzen können, bitte das o.g. Ticket ergänzen oder ein neues anlegen.

[MarcusW]

Hi. Ich nutze den Adapter auch. Leider benötige ich eine einfache Erklärung, wie ich die Datenpunkte für den Verbrauch "day, month + year" in kW umwandle/berechne Mit dem History Adapter habe ich noch nicht gearbeitet.

[git-kick]

@marcusw said in Test Adapter e3dc-rscp v0.0.x GitHub:

Hi. Ich nutze den Adapter auch. Leider benötige ich eine einfache Erklärung, wie ich die Datenpunkte für den Verbrauch "day, month + year" in kW umwandle/berechne Mit dem History Adapter habe ich noch nicht gearbeitet.

Jeder Wert in DB repräsentiert ein Zeitintervall der Länge TIME_INTERVAL, dafür werden die Energiemengen (Wh) geliefert.
Man kann daraus eine mittlere Leistung z.B. DC_POWER / (TIME_INTERVAL/3600) = <MittlerePVLeistungimZeitintervall> berechnen, aber da kann man mit den DB-Daten nur bis auf 900 Sekunden (15 Minuten) genau werden - das ist augenscheinlich auch die Auflösung im E3/DC-Portal bzw. der App.

Wenn man mehr zeitliche Auflösung haben will, muss man entweder mit dem Adapter z.B. alle 5 Sekunden abfragen und POWER_PV abspeichern (dafür gibts die History-DB) oder man nimmt dafür eine spezielle Time-Series-Datenbank wie z.B. InfluxDB (die hat einen Modbus-Adapter und das funktioniert bei mir seit 2 Jahren ohne Ausfall). Deren Daten kann man dann extra visualisieren (Grafana) oder auch in ioBroker (Influx-Adapter - Achtung ich glaube der ist veraltet).

Mein Eindruck aus den bisherigen Diskussionen ist, dass sich ioBroker für hochaufgelöste Zeitreihen eher nicht so gut eignet, dafür aber zur Visualisierung des Status und für regelbasierte Steuerung bei bestimmmten Ereignissen. Aber ich lasse mich da gerne widerlegen!

[ArnoD]

@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:

Bei mir ist das Verhalten anders: ich setze SET_POWER_MODE auf "Charge" und dann SET_POWER_VALUE auf die gewünschten Watt. Die Ladeleistung wird reduziert, aber nur kurz, dann schwankt sie etwa im 30-Sekunden-Takt zwischen dem eingestellten Wert und dem maximal möglichen, siehe blaue Linie in ff. Grafik:

Was hast du da in den Instanzeinstellungen unter "Zeitintervalle für Senden" für eine Zeit eingetragen?
Mit 9 sek. hat es bei mir funktioniert, müsste es aber jetzt mit der neuen Adapterversion 1.0.4 noch mal testen ob sich da was geändert hat.

[ArnoD]

@marcusw sagte in Test Adapter e3dc-rscp v0.0.x GitHub:

Hi. Ich nutze den Adapter auch. Leider benötige ich eine einfache Erklärung, wie ich die Datenpunkte für den Verbrauch "day, month + year" in kW umwandle/berechne Mit dem History Adapter habe ich noch nicht gearbeitet.

Also da musst du nichts mehr umwandeln oder berechnen. Dir geht es um den Hausverbrauch, wenn ich dich richtig verstehe. Wenn du das wirklich genau haben willst, müsstest du deinen Hauszähler auslesen, alle anderen Methoden liefern dir nur einen ungefähren Wert, der nicht mit deinem Zähler übereinstimmen wird.
Als Beispiel nehme ich jetzt mal als Zeitraum den 01.01.2022 bis zum 31.03.2022 also 90 Tage = 2160 h = 7776000 s
Da ich keine Zwischenwerte benötige nehme ich bei beiden den gleichen Zeitraum:
TIME_INTERVAL = 7776000 s
TIME_SPAN = 7776000 s
TIME_START = 2022-01-01 00:00:00.000

Jetzt bekomme ich folgende Werte vom e3dc-rscp Adapter:
Das sind bereits für diesen Zeitraum berechnetet Wh Werte, die du nur noch in kWh (/1000) umrechnen musst.

Wenn ich jetzt die Zählerstände für den gleichen Zeitraum von meinem Hauszähler und PV-Zähler mit denen vom E3DC vergleiche, kommt folgendes raus:
E3DC Einspeiseleistung = 1601 kWh Hauszähler Einspeiseleistung = 1048 kWh
E3DC PV-Leistung = 3871 kWh           PV-Zähler Energieversorger = 3056 kWh
E3DC Netzbezug = 571 kWh                Hauszähler Netzbezug = 752 kWh

Warum die Zählerwerte so abweichen ist meine Vermutung das E3DC einen DC Zähler verwendet und im DC Kreis misst und beim Hauszähler und PV-Zähler vom Energieversorger handelt es sich um AC Zähler die im AC Kreis verbaut sind.
Damit würde sich erklären, warum E3DC immer mehr Leistung zählt als der Zähler vom Energieversorger, da hier die Wechselverluste bereits enthalten sind.
Aber wie gesagt nur eine Vermutung, die ja eventuell jemand hier bestätigen oder berichtigen kann.

Wenn es dir nur um die PV-Leistung geht, kannst du die drei AC Zähler der einzelnen Phasen aus dem Adapter verwenden:
e3dc-rscp.0.PVI.PVI_0.Phase_0.AC_ENERGY_ALL
e3dc-rscp.0.PVI.PVI_0.Phase_1.AC_ENERGY_ALL
e3dc-rscp.0.PVI.PVI_0.Phase_2.AC_ENERGY_ALL
Hier musst du natürlich die drei Phasen zusammenzählen.

Das Gleiche hast du auch für den Netzbezug:
e3dc-rscp.0.PVI.PVI_0.Phase_0.AC_ENERGY_GRID_CONSUMPTION
e3dc-rscp.0.PVI.PVI_0.Phase_1.AC_ENERGY_GRID_CONSUMPTION
e3dc-rscp.0.PVI.PVI_0.Phase_2.AC_ENERGY_GRID_CONSUMPTION
auch hier musst du natürlich die drei Phasen zusammenzählen.

Die Zähler stimmt sogar einigermaßen mit dem vom Energieversorger überein.

[brumark]

@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:

Wenn sich der Wert nicht ändert, dann wird auch nichts aktualisiert.
Dachte am Anfang auch das die Werte nicht aktualisiert werden.
Kannst du prüfen, indem du dir die Werte merkst und dann die State löscht und die Instanz neu startest,
wenn jetzt die gleichen Werte eingetragen werden dann liegt es daran das diese sich nicht ändern und dann natürlich auch nicht aktualisiert werden.

Dass die States nur bei einer Änderung aktualisiert werden ist mir bewusst und auch nicht das Problem.
Es reicht wenn ich z.B. das Intervall vom TAG_BAT_REQ_RC von L auf M ändere. Danach werden die Werte ALLER Tags beginnend mit TAG_BAT nicht mehr aktualisiert. Im ausführlichen Log sehe ich, dass die Werte gar nicht mehr abgefragt werden.

Die beiden TAGs TAG_BAT_REQ_RC und TAG_BAT_REQ_USABLE_REMAINING_CAPACITY ändern ihren Wert beim Laden und Entladen ständig, da macht ein Interval von 12 h keinen Sinn.