Test Adapter e3dc-rscp v0.0.x GitHub

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.

ArnoD

@ujok
Ok konnte es nicht lassen und musste es gleich testen :-)
Ich bin jetzt schon begeister, was man bereits jetzt mit deiner Hilfe alles steuern kann.

SET_POWER Wiederholintervall s im Adapter auf 9 eingestellt.

Was habe ich getestet:

Versuch das Entladen der Batterie zu steuern.
SET_POWER_VALUE auf 100 eingestellt
SET_POWER_MODE auf 2 für ENTLADEN MODUS.
Rückmeldung SET_POWER = 100
Funktioniert :+1:
Es werden die eingestellten Werte von E3DC beim Entladen immer um 10W bis 50 W überschritten, warum kann ich noch nicht sagen.
Wenn der Eigenverbrauch über dem eingestellten Wert liegt, wird der Rest aus dem Netz bezogen.
bei eingestellten 100W werden 123W-129W entladen.
bei eingestellten 200W werden 219W-222W entladen.
bei eingestellten 300W werden 330W entladen.
bei eingestellten 400W werden 408W-420W entladen.
Die Logik, falls es eine gibt, erschließt sich mir noch nicht.
Versuch Laden der Batterie ohne PV-Leistung
SET_POWER_VALUE auf 100 eingestellt
SET_POWER_MODE auf 3 für LADEN MODUS.
Rückmeldung SET_POWER = 100
Funktioniert :+1:
Es werden die eingestellten Werte von E3DC beim Laden ohne PV Leistung immer um 64W bis 86 W unterschritten.
bei eingestellten 300W werden 234W geladen.
bei eingestellten 400W werden 336W geladen.
bei eingestellten 500W werden 414W geladen.
Benötigte Leistung wird aus dem Netz bezogen da ja keine PV Leistung ansteht.
Wofür man jetzt noch SET_POWER_MODE=4 für NETZ_LADE MODUS benötigt muss ich Morgen mit PV Leistung vom Dach testen.
Versuch Umschalten in den Leerlauf.
SET_POWER_VALUE nicht geändert und auf 100 eingestellt gelassen um zu testen was passiert.
SET_POWER_MODE auf 1 für IDLE MODUS.
Rückmeldung SET_POWER = 0
Funktioniert :+1:
SET_POWER wird mit 0W rückgemeldet, obwohl SET_POWER_VALUE nicht geändert wurde.
Bedeutet das hier E3DC automatisch auf 0W schaltet und SET_POWER_VALUE ignoriert.
Versuch Umschalten in den Normal/Auto Modus.
SET_POWER_VALUE nicht geändert und auf 100 eingestellt gelassen um zu testen was passiert.
SET_POWER_MODE auf 0 für Normal/Auto Modus.
Rückmeldung SET_POWER = 0
Das funktioniert leider nicht.
E3DC geht hier nicht in den Normal/Auto Modus und übernimmt die Steuerung wieder selber, sondern stoppt das Entladen der Batterie und bezieht alles aus dem Netz.
Uli hier vermute ich das Problem beim erneuten Senden der Daten nach 10 sek. und denke, dass man es mit deinem Vorschlag den Timer mit Mode 0 auszuschalten lösen kann.

Man kann also das laden und entladen der Batterie nach Belieben steuern und muss nur beachten, dass die Leistung was fehlt und nicht von der Batterie kommt aus dem Netz bezogen wird.

Nachtrag:
Komisch ist die Rückmeldung von e3dc-rscp.0.EMS.MODE.
Wenn SET_POWER_MODE = 0 ist MODE = 0
Wenn SET_POWER_MODE = 1 ist MODE = 0
Wenn SET_POWER_MODE = 2 ist MODE = 1
Wenn SET_POWER_MODE = 3 ist MODE = 2
Wenn SET_POWER_MODE = 4 ist MODE = 2

Hier stimmt noch was nicht.

Ach ja DANKE für die Änderung # im Pfad. Binding in Widgets funktioniert jetzt. :+1:

ArnoD

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

Aber das Verhalten ist mir nach wie vor unklar: die (read) Werte folgen keineswegs den (write) Werten.

Bei SET_POWER_MODE und Mode nicht, aber bei SET_POWER_VALUE und SET_POWER ist es bei mir jedenfalls der Fall.
Außer wenn SET_POWER_MODE = 0 oder 1 ist, was aber auch richtig ist, da im IDLE MODUS und Normal/Auto Modus der Wert SET_POWER_VALUE ignoriert werden kann.

git-kick

Super, merci @ArnoD für den ausführlichen und systematischen Test.

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

Versuch Umschalten in den Normal/Auto Modus.
SET_POWER_VALUE nicht geändert und auf 100 eingestellt gelassen um zu testen was passiert.
SET_POWER_MODE auf 0 für Normal/Auto Modus.
Rückmeldung SET_POWER = 0
Das funktioniert leider nicht.
E3DC geht hier nicht in den Normal/Auto Modus und übernimmt die Steuerung wieder selber, sondern stoppt das Entladen der Batterie und bezieht alles aus dem Netz.
Uli hier vermute ich das Problem beim erneuten Senden der Daten nach 10 sek. und denke, dass man es mit deinem Vorschlag den Timer mit Mode 0 auszuschalten lösen kann.

OK, das Deaktivieren des Timers bei SET_POWER_MODE=0 kommt in der nächsten Version.

Nachtrag:
Komisch ist die Rückmeldung von e3dc-rscp.0.EMS.MODE.
Wenn SET_POWER_MODE = 0 ist MODE = 0
Wenn SET_POWER_MODE = 1 ist MODE = 0
Wenn SET_POWER_MODE = 2 ist MODE = 1
Wenn SET_POWER_MODE = 3 ist MODE = 2
Wenn SET_POWER_MODE = 4 ist MODE = 2

Hier stimmt noch was nicht.

Ja, das Verhalten von MODE hat mich auch sehr verwirrt. Ich habe bisher keine Idee, was der Adapter da jeweils tun soll.

Community Forum

NEWS

Test Adapter e3dc-rscp v0.0.x GitHub

0.0.10-beta

Support us

772

32.4k

81.4k

1.3m