Test Adapter e3dc-rscp v0.0.x GitHub

git-kick

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

Und SOH ist in so fern sehr wichtig, da es das Garanitiekriterium (>80% in 10 Jahren) ist.
Die ursprüngliche Kapazität haben wir ja, doch wo ist die rated Capacity?

Kennst du die spezifizierte Nennspannung? Ich frage, weil die SPECIFIED_CAPACITY in [Wh] angegeben ist, aber die FCC in [Ah] - das könnte man mit der Spannung umrechnen (V*Ah = Wh).
Nach meiner Rechnung müsste die Nennspannung um die 50 V liegen.
Aber womöglich hängt sie auch vom Batterietyp ab.

Bei den DCB gibt es beide Größen: DCB_FULL_CHARGE_CAPACITY und DCB_DESIGN_CAPACITY.
Das ergibt bei mir FCC/DesignC = 112,7/110 = 102%
SOH/ASOC ist 100%
Passt also ganz gut.

Matis

@ujok Hm, bei mir ist Full_charge = Design Cap. = FCC = 126 Ah und trotdem kommen SOH Werte von 98,9 - 99,9 % raus. Da muß also noch irgend was anderes eine Rolle spielen.

ArnoD

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

Gibt es zu dem Verhalten von Status, Mode, Set-Power / Set-Power Mode was Schriftliches?
Ich hab das nicht ganz verstanden um es vernünftig nachvollziehen zu können.

Nein leider ist das nirgends richtig dokumentiert.
In der Tag-Liste sind nur die möglichen Werte für TAG_EMS_REQ_SET_POWER_MODE enthalten und bei TAG_EMS_REQ_SET_POWER steht nur
"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. "

Wenn ich SET_POWER aber alle 10 sek. Setze funktioniert es nicht, sondern, nur wenn ich POWER_MODE immer wieder setze.
Kann es sein, dass du auf gleiche Werte bei SET_POWER nicht reagierst, sondern nur auf unterschiedliche Werte?

Wollte es eigentlich bei PV Leistung mal testen, aber man glaubt es kaum, seit dem Scheint die Sonne nicht mehr :joy:

TbsJah

werden euch noch die Werte im E3DC Portal korrekt angezeigt?
Eventuell nur Zufall aber seit dem Update auf die 0.0.8 werden keine Daten mehr an E3DC geliefert

Der Verlauf wird scheinbar nicht mehr aufgezeichnet.
Auswertung Grafana

ArnoD

@tbsjah
Bis heute 11:15 Uhr wurden noch Daten übermittelt und ich habe die Version 0.0.8 und 0.0.9 bereits länger drauf.

TbsJah

@arnod danke Arno
Muss ich mal E3DC schreiben

TbsJah

Reboot tut gut
Hatte sich doch bei der ersten rscp Abfrage verschluckt

Läuft wieder

Danke für die großartige Arbeit
Und Arno... Was soll ich sagen... Brain halt

Planst du die Ablösung des Eba Tools?

ArnoD

@tbsjah
mal sehen, ob es funktioniert.

ArnoD

@ujok

Bin gerade dabei in VIS die Views zu erstellen und habe da ein Problem mit dem Sonderzeichen "#"
Anscheinen funktioniert das Binding nicht in einem Widget, wenn im zweiten dp Pfad ein # enthalten ist.
Also diese Formel geht nicht:
{v1:e3dc-rscp.0.BAT.BAT#0.DCB#0.DCB_CELL_TEMPERATURE.06;v2:e3dc-rscp.0.BAT.BAT#0.DCB#0.DCB_CELL_TEMPERATURE.07;v1-v2}
Das würde aber funktionieren:
{v1:e3dc-rscp.0.BAT.BAT#0.DCB#0.DCB_CELL_TEMPERATURE.06;v2:e3dc-rscp.0.BAT.BAT0.DCB0.DCB_CELL_TEMPERATURE.07;v1-v2}
oder natürlich, wenn gar keine # enthalten ist:
{v1:e3dc-rscp.0.BAT.BAT0.DCB0.DCB_CELL_TEMPERATURE.06;v2:e3dc-rscp.0.BAT.BAT0.DCB0.DCB_CELL_TEMPERATURE.07;v1-v2}

Ist es möglich, die Raute aus dem Pfad zu entfernen?

Habe auf GitHub ioBroker.vis dieses Problem gemeldet, nur wird die Lösung wahrscheinlich dauern, wenn es überhaupt möglich ist.

Matis

@arnod
Cool, dass du herausgefunden hast woran das liegt, hab mich totprobiert und schliesslich ein Script geschrieben.
Hatte das Problem im smartmeter adapter auch schon, da waren es glaube ich Doppelpunkte.

ArnoD

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

Cool, dass du herausgefunden hast woran das liegt,

Will mich hier nicht mit fremden Federn schmücken :-) , das war nicht ich, sondern ich bin von @liv-in-sky darauf hingewiesen worden.
Es funktionieren anscheinend alle Sonderzeichen wie ä,ü,ö auch nicht.

ArnoD

@ujok

Habe heute einiges testen können.
Hier mal alles was mir so aufgefallen ist:

Das Ändern von folgenden Werten wird nicht beim E3DC übernommen, sondern wieder mit der Einstellung E3DC überschrieben:
e3dc-rscp.0.EMS.WEATHER_REGULATED_CHARGE_ENABLED
Hier kommt diese Warnung im LOG: Don't know how to queue EMS.WEATHER_REGULATED_CHARGE_ENABLED
OK hier wurde in der main.js in Zeile 275 der Tag nicht eingetragen, sollte wohl so richtig sein wie hier in Zeile 3:

const mapChangedIdToSetTags = {
	"EMS.POWERSAVE_ENABLED": ["TAG_EMS_REQ_SET_POWER_SETTINGS", "TAG_EMS_POWERSAVE_ENABLED"],
	"EMS.WEATHER_REGULATED_CHARGE_ENABLED": ["TAG_EMS_REQ_SET_POWER_SETTINGS", "TAG_EMS_WEATHER_REGULATED_CHARGE_ENABLED"],
	"EMS.MAX_CHARGE_POWER": ["TAG_EMS_REQ_SET_POWER_SETTINGS", "TAG_EMS_MAX_CHARGE_POWER"],
	"EMS.MAX_DISCHARGE_POWER": ["TAG_EMS_REQ_SET_POWER_SETTINGS", "TAG_EMS_MAX_DISCHARGE_POWER"],
	"EMS.DISCHARGE_START_POWER": ["TAG_EMS_REQ_SET_POWER_SETTINGS", "TAG_EMS_DISCHARGE_START_POWER"],
	"EMS.USER_CHARGE_LIMIT": ["TAG_EMS_REQ_SET_POWER_SETTINGS", "TAG_EMS_USER_CHARGE_LIMIT"],
	"EMS.USER_DISCHARGE_LIMIT": ["TAG_EMS_REQ_SET_POWER_SETTINGS", "TAG_EMS_USER_DISCHARGE_LIMIT"],
	"EMS.MODE": [],
	"EMS.SET_POWER": [],
};

e3dc-rscp.0.EMS.BATTERY_BEFORE_CAR_MODE
e3dc-rscp.0.EMS.POWER_LIMITS_USED
Alle States unter e3dc-rscp.0.EMS.IDLE_PERIODS_CHARGE

Beim Ändern von folgenden Werten wird die Einstellung beim E3DC übernommen.
Was aber komisch ist das der Wert erst mit der Einstellung E3DC überschrieben wird und dann erst der im ioBroker eingestellte Wert übernommen wird.

e3dc-rscp.0.EMS.POWERSAVE_ENABLED

git-kick

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

Wenn ich SET_POWER aber alle 10 sek. Setze funktioniert es nicht, sondern, nur wenn ich POWER_MODE immer wieder setze.
Kann es sein, dass du auf gleiche Werte bei SET_POWER nicht reagierst, sondern nur auf unterschiedliche Werte?

Der Adapter schreibt neu bei onStateChange && !state.ack
D.h. wenn man den Wert manuell auf "bestätigt" setzt, wird nicht geschrieben - aber das wird wohl hier nicht das Thema sein.
Daher nehme ich an, dass onStateChange bei unverändertem Wert nicht aufgerufen wird (das steuere ich nicht im Adapter, dieser "abonniert" lediglich das Event).
Die Wiederholung (ohne Änderung) alle x Sekunden kann ich in den Adapter einbauen, das nehme ich ins Backlog.

git-kick

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

@ujok

Bin gerade dabei in VIS die Views zu erstellen und habe da ein Problem mit dem Sonderzeichen "#"
Anscheinen funktioniert das Binding nicht in einem Widget, wenn im zweiten dp Pfad ein # enthalten ist.

Ich werde "#" ersetzen durch "_"
Danke @ArnoD für den Hinweis!

git-kick

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

Das Ändern von folgenden Werten wird nicht beim E3DC übernommen, sondern wieder mit der Einstellung E3DC überschrieben:

e3dc-rscp.0.EMS.WEATHER_REGULATED_CHARGE_ENABLED
Hier kommt diese Warnung im LOG: Don't know how to queue EMS.WEATHER_REGULATED_CHARGE_ENABLED
OK hier wurde in der main.js in Zeile 275 der Tag nicht eingetragen, sollte wohl so richtig sein wie hier in Zeile 3:

Muss ich mir ansehen.
Im Code ist die angesprochene Zeile schon drin, aber irgendwo hab ich eine Regression, weil das funktionierte schon mal...

e3dc-rscp.0.EMS.POWER_LIMITS_USED

Da meldet ioBroker jetzt einen "read-only state" - ebenfalls eine Regression.
Wird korrigiert.

e3dc-rscp.0.EMS.BATTERY_BEFORE_CAR_MODE
Alle States unter e3dc-rscp.0.EMS.IDLE_PERIODS_CHARGE

Diese sind noch gar nicht (schreibend) implementiert. Ich versuche, die Liste im README.md aktuell zu halten.

Beim Ändern von folgenden Werten wird die Einstellung beim E3DC übernommen.
Was aber komisch ist das der Wert erst mit der Einstellung E3DC überschrieben wird und dann erst der im ioBroker eingestellte Wert übernommen wird.

e3dc-rscp.0.EMS.POWERSAVE_ENABLED

Das funktioniert bei mir mit 0.0.9-beta einwandfrei. Bin auch nicht ganz sicher ob ich verstanden habe, was genau du als Fehler beschreibst.

git-kick

Hier ist die neue Version:
https://github.com/git-kick/ioBroker.e3dc-rscp/tree/v0.0.10-beta

Ich bitte vor allem um Test von
SET_POWER_MODE (write) / MODE (read)
SET_POWER_VALUE (write) / SET_POWER (read)
Die eingegebenen Werte (write) werden jetzt alle 15 Sekunden (Intervall einstellbar) ans E3/DC gesendet. Aber das Verhalten ist mir nach wie vor unklar: die (read) Werte folgen keineswegs den (write) Werten.

0.0.10-beta

(git-kick)

SET_POWER is now initialized and appears after adapter setup
Translations: EMS_ERROR_*, BAT_FCC, BAT_RC, BAT_SPECIFIED_CAPACITY
Timestamps are displayed in ISO-8601 format
Object names: replaced "#" by "_" to avoid interference with ioBoroker name resolution (e.g. former BAT#0 is now BAT_0) - NOTE: this is likely to break <=0.0.9 based js scripts; adjust object references!
Solved issue setting EMS.WEATHER_REGULATED_CHARGE_ENABLED (before, failed with warning)
Solved issue setting EMS.POWER_LIMITS_USED (before, object was defined r/o)
SET_POWER: values set are re-sent according to a given interval (see admin panel)
SET_POWER: introduced extra objects for entering desired values (SET_POWER_MODE, SET_POWER_VALUE) - E3/DC behavior is still unclear. Feature under development.

ArnoD

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

Die Wiederholung (ohne Änderung) alle x Sekunden kann ich in den Adapter einbauen, das nehme ich ins Backlog.

Das ist wahrscheinlich keine gute Idee, da man ja keine neuen Werte setzt, wenn man nichts steuern will und E3DC dann automatisch in den Standard Modus zurückwechselt.
Morgen habe ich den ganzen Tag Zeit, die neue Version zu testen.
Habe mir da bereits ein Script geschrieben und werde es mal Morgen versuchen.

ArnoD

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

Diese sind noch gar nicht (schreibend) implementiert. Ich versuche, die Liste im README.md aktuell zu halten.

Ok, da war ich zu voreilig, eins nach dem anderen :-)

Das funktioniert bei mir mit 0.0.9-beta einwandfrei. Bin auch nicht ganz sicher ob ich verstanden habe, was genau du als Fehler beschreibst.

Das funktioniert bei mir auch, da ja der Wert übernommen wird. Mir ist nur in VIS aufgefallen, dass der neu gesetzte Wert erst mit dem alten im E3DC gespeicherten Wert überschrieben wird und dann erst der neue Wert übernommen wird. Kann eine Überschneidung sein und ist nicht weiter tragisch, gibt wirklich wichtigeres. Ich achte nur beim Testen auf jede Kleinigkeit und melde diese, um dir eine möglichst genaue Rückmeldung zu geben.
Wenn du willst, kann ich dir erstmal nur die groben Fehler rückmelden.

git-kick

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

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

Die Wiederholung (ohne Änderung) alle x Sekunden kann ich in den Adapter einbauen, das nehme ich ins Backlog.

Das ist wahrscheinlich keine gute Idee, da man ja keine neuen Werte setzt, wenn man nichts steuern will und E3DC dann automatisch in den Standard Modus zurückwechselt.

Ok verstanden. Wie ist denn der Standardmodus definiert? MODE = 0(NORMAL) ?
Dann könnte ich ja den Timer wieder abschalten, sobald man MODE=0 setzt.
Oder besser den Timer wieder entfernen?

git-kick

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

Das funktioniert bei mir mit 0.0.9-beta einwandfrei. Bin auch nicht ganz sicher ob ich verstanden habe, was genau du als Fehler beschreibst.

Das funktioniert bei mir auch, da ja der Wert übernommen wird. Mir ist nur in VIS aufgefallen, dass der neu gesetzte Wert erst mit dem alten im E3DC gespeicherten Wert überschrieben wird und dann erst der neue Wert übernommen wird. Kann eine Überschneidung sein und ist nicht weiter tragisch, gibt wirklich wichtigeres. Ich achte nur beim Testen auf jede Kleinigkeit und melde diese, um dir eine möglichst genaue Rückmeldung zu geben.

Danke, jetzt habe ich es auch gesehen: das ist tatsächlich der Effekt, wenn der "alte" Wert aus der regelmäßigen Abfrage nochmal eintrifft, bevor der "neue" Wert geschrieben und die dazugehörige Rückmeldung eingegangen ist. Das würde ich erstmal so lassen, denn das abzufangen würde nennenswert Komplexität hinzufügen, ohne (außer der Optik) eine wirksame Veränderung zu bringen.

Wenn du willst, kann ich dir erstmal nur die groben Fehler rückmelden.

Neinein, bitte alles melden; ich habs nur nicht gleich verstanden.

Community Forum

NEWS

Test Adapter e3dc-rscp v0.0.x GitHub

0.0.10-beta

Support us

604

32.4k

81.4k

1.3m