Test Adapter e3dc-rscp v0.0.x GitHub
-
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
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 = 2Hier stimmt noch was nicht.
Ich habe mir dazu nochmal die Tag-Liste angesehen: die Werte für MODE sind dort nicht definiert - ich hatte einfach angenommen, dass sie denen von SET_POWER_MODE entsprechen. Diese Annahme war offenbar falsch.
Wäre es also sinnvoll MODE so zu übersetzen?
0 = IDLE
1 = DISCHARGE
2 = CHARGE(Allerdings wäre mir dann immer noch nicht klar, was sie SET_POWER_MODE Werte genau bedeuten, speziell die Unterschiede NORMAL/IDLE und CHARGE/GRID_CHARGE).
-
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Gibt es noch Wortmeldungen zu der Frage:
Wenn man einen Namespace abschaltet,
A) alles so einfrieren wie es ist oder
B) den Objekt-Teilbaum komplett löschen
??Bitte NICHT löschen "N/A" ist noch viel schlechter als ein alter Wert.
Alte Werte kann jeder selber abfangen, das machen andere Adapter auch nicht. -
@matis said in Test Adapter e3dc-rscp v0.0.x GitHub:
Bitte NICHT löschen "N/A" ist noch viel schlechter als ein alter Wert.
Alte Werte kann jeder selber abfangen, das machen andere Adapter auch nicht.Guter Hinweis! Bei der Darstellung kann man bei Bedarf prüfen, ob ein Wert noch aktualisiert wird oder "eingefroren" ist. Hier als Beispiel der Check, ob der BAT-Namespace abgefragt wird:
console.log(getObject('system.adapter.e3dc-rscp.0').native.query_bat) -
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Wäre es also sinnvoll MODE so zu übersetzen?
0 = IDLE
1 = DISCHARGE
2 = CHARGEGute Fragen
Ist erst mal nicht verkehrt.@matis sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Bitte NICHT löschen "N/A" ist noch viel schlechter als ein alter Wert.
Alte Werte kann jeder selber abfangen, das machen andere Adapter auch nicht.Kein Problem, das kann man über ein Script auch lösen.
Nicht alle meine Ideen in der Nacht sind immer durchdacht
-
Hier kommt die nächste Beta:
https://github.com/git-kick/ioBroker.e3dc-rscp/tree/v0.0.13-betaNeu sind vor allem die veränderbaren Idle-Periods.
Known issue: für die drei SET_POWER... Objekte werden die Namen nicht angezeigt, da ist noch irgendein Fehler versteckt.
0.0.13-beta
- IDLE_PERIODS are now writable - note "SET_IDLE_PERIOD delay" in configuration.
- EMS.MODE was empirically re-mapped to 0 = IDLE, 1 = DISCHARGE, 2 = CHARGE.
- SET_POWER_MODE/VALUE are now acknowledged after frame was queued to E3/DC.
- Units are now trailing the values (no longer at end of name).
-
@ujok Meine heißgeliebten DC_POWER Daten sind jetzt alle "long", so richtig glücklich bin ich mit der Klassifizierung und der Auswahl nicht. Gibt es nicht ne Möglichkeit, die Tags selbst zu setzen? z.B.
-
@matis said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok Meine heißgeliebten DC_POWER Daten sind jetzt alle "long", so richtig glücklich bin ich mit der Klassifizierung und der Auswahl nicht. Gibt es nicht ne Möglichkeit, die Tags selbst zu setzen? z.B.
Die REQ_DC_{POWER,VOLTAGE,CURRENT,STRING_ENERGY_ALL} sind alle unter "medium" einsortiert, s.u. ab Zeile 70.
Die jeweils aktuelle Zuordnung steht in lib/RscpTags.json - es wird halt immer ein trade-off sein zwischen Aktualität und CPU-Last.Nachtrag: bei den Timern ist noch ein Fehler, deshalb werden momentan alle Daten zu selten abgefragt. Ich bin an der Korrektur.
Was meinst Du mit "die Tags selbst zu setzen? z.B."?
TAG_DB_BAT_CHARGE_LEVEL -- % TAG_EMS_REQ_POWER_BAT -- short TAG_EMS_REQ_POWER_HOME -- short TAG_EMS_REQ_POWER_GRID -- short TAG_EMS_REQ_POWER_ADD -- short TAG_EMS_REQ_AUTARKY -- medium TAG_EMS_REQ_SELF_CONSUMPTION -- medium TAG_EMS_REQ_BAT_SOC -- medium TAG_EMS_REQ_COUPLING_MODE -- medium TAG_EMS_REQ_STORED_ERRORS -- medium TAG_EMS_REQ_MODE -- short TAG_EMS_REQ_BALANCED_PHASES -- medium TAG_EMS_REQ_INSTALLED_PEAK_POWER -- long TAG_EMS_REQ_DERATE_AT_PERCENT_VALUE -- long TAG_EMS_REQ_DERATE_AT_POWER_VALUE -- long TAG_EMS_REQ_POWER_WB_ALL -- medium TAG_EMS_REQ_POWER_WB_SOLAR -- medium TAG_EMS_REQ_EXT_SRC_AVAILABLE -- long TAG_EMS_REQ_STATUS -- short TAG_EMS_REQ_USED_CHARGE_LIMIT -- medium TAG_EMS_REQ_BAT_CHARGE_LIMIT -- medium TAG_EMS_REQ_DCDC_CHARGE_LIMIT -- medium TAG_EMS_REQ_USER_CHARGE_LIMIT -- medium TAG_EMS_REQ_USED_DISCHARGE_LIMIT -- medium TAG_EMS_REQ_BAT_DISCHARGE_LIMIT -- medium TAG_EMS_REQ_DCDC_DISCHARGE_LIMIT -- medium TAG_EMS_REQ_USER_DISCHARGE_LIMIT -- medium TAG_EMS_REQ_REMAINING_BAT_CHARGE_POWER -- medium TAG_EMS_REQ_REMAINING_BAT_DISCHARGE_POWER -- medium TAG_EMS_REQ_EMERGENCY_POWER_STATUS -- medium TAG_EMS_REQ_BATTERY_TO_CAR_MODE -- medium TAG_EMS_REQ_BATTERY_BEFORE_CAR_MODE -- medium TAG_EMS_REQ_GET_IDLE_PERIODS -- medium TAG_EMS_REQ_GET_POWER_SETTINGS -- medium TAG_EMS_REQ_GET_MANUAL_CHARGE -- medium TAG_EMS_REQ_EMERGENCYPOWER_TEST_STATUS -- medium TAG_EMS_REQ_GET_SYS_SPECS -- long TAG_EMS_REQ_POWER_PV_AC_OUT -- medium TAG_EMS_REQ_ALIVE -- short TAG_EP_REQ_IS_READY_FOR_SWITCH -- medium TAG_EP_REQ_IS_GRID_CONNECTED -- medium TAG_EP_REQ_IS_ISLAND_GRID -- medium TAG_EP_REQ_IS_INVALID_STATE -- medium TAG_EP_REQ_IS_POSSIBLE -- medium TAG_EMS_AC_REACTIVE_POWER -- VAr TAG_PVI_REQ_ON_GRID -- medium TAG_PVI_REQ_STATE -- short TAG_PVI_REQ_LAST_ERROR -- medium TAG_PVI_REQ_TYPE -- long TAG_PVI_REQ_VOLTAGE_MONITORING -- medium TAG_PVI_REQ_FREQUENCY_UNDER_OVER -- medium TAG_PVI_REQ_SYSTEM_MODE -- medium TAG_PVI_REQ_POWER_MODE -- medium TAG_PVI_REQ_TEMPERATURE -- medium TAG_PVI_REQ_TEMPERATURE_COUNT -- long TAG_PVI_REQ_MAX_TEMPERATURE -- medium TAG_PVI_REQ_MIN_TEMPERATURE -- medium TAG_PVI_REQ_DEVICE_STATE -- medium TAG_PVI_REQ_SERIAL_NUMBER -- long TAG_PVI_REQ_VERSION -- long TAG_PVI_REQ_AC_MAX_PHASE_COUNT -- long TAG_PVI_REQ_AC_POWER -- short TAG_PVI_REQ_AC_VOLTAGE -- short TAG_PVI_REQ_AC_CURRENT -- short TAG_PVI_REQ_AC_APPARENTPOWER -- medium TAG_PVI_REQ_AC_REACTIVEPOWER -- medium TAG_PVI_REQ_AC_ENERGY_ALL -- medium TAG_PVI_REQ_AC_MAX_APPARENTPOWER -- medium TAG_PVI_REQ_AC_ENERGY_GRID_CONSUMPTION -- medium TAG_PVI_REQ_DC_POWER -- medium TAG_PVI_REQ_DC_VOLTAGE -- medium TAG_PVI_REQ_DC_CURRENT -- medium TAG_PVI_REQ_DC_STRING_ENERGY_ALL -- medium TAG_BAT_REQ_MAX_BAT_VOLTAGE -- medium TAG_BAT_REQ_MAX_CHARGE_CURRENT -- long TAG_BAT_REQ_EOD_VOLTAGE -- long TAG_BAT_REQ_MAX_DISCHARGE_CURRENT -- long TAG_BAT_REQ_CHARGE_CYCLES -- long TAG_BAT_REQ_TERMINAL_VOLTAGE -- medium TAG_BAT_REQ_DEVICE_NAME -- long TAG_BAT_REQ_DCB_COUNT -- long TAG_BAT_REQ_RSOC_REAL -- medium TAG_BAT_REQ_ASOC -- medium TAG_BAT_REQ_FCC -- long TAG_BAT_REQ_RC -- long TAG_BAT_REQ_MAX_DCB_CELL_TEMPERATURE -- medium TAG_BAT_REQ_MIN_DCB_CELL_TEMPERATURE -- medium TAG_BAT_REQ_DCB_ALL_CELL_TEMPERATURES -- medium TAG_BAT_REQ_DCB_ALL_CELL_VOLTAGES -- medium TAG_BAT_REQ_READY_FOR_SHUTDOWN -- medium TAG_BAT_REQ_INFO -- medium TAG_BAT_REQ_TRAINING_MODE -- medium TAG_BAT_REQ_USABLE_CAPACITY -- long TAG_BAT_REQ_USABLE_REMAINING_CAPACITY -- long TAG_BAT_REQ_DCB_INFO -- medium TAG_BAT_REQ_SPECIFICATION -- long TAG_BAT_REQ_INTERNALS -- long TAG_BAT_REQ_TOTAL_USE_TIME -- medium TAG_BAT_REQ_TOTAL_DISCHARGE_TIME -- medium TAG_BAT_REQ_DEVICE_STATE -- medium -
Die v0.0.14-beta bringt zwei Punkte:
- die Abfrage-Timer laufen jetzt (hoffentlich) korrekt, also wirklich kurz/mittel/lang
- in der Konfiguration kann man jetzt für jedes Abfrage-Tag einzeln S/M/L auswählen
0.0.14-beta
- Polling intervals (S/M/L) are now assignable per request tag, see second configuration tab.
- Bug fix: short and medium timers for polling intervals did not work properly.
-
Da ist man mal zwei Tage weg und schon gibt es zwei neue Versionen
Werde ich gleich mal installieren und testen.
-
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Polling intervals (S/M/L) are now assignable per request tag, see second configuration tab.
Bug fix: short and medium timers for polling intervals did not work properly.Sehr gute Lösung! Und funktioniert.
Der Adapter wird wirklich so mega professionell.
Mit der Auswahlmöglichkeit bleibt das auch alles transparent und einfach zu nutzen.
Eben mit dem Hauptfokus Daten zu liefern.Mein Problem mit dem bereits existierenden e3dc Adapter war immer, dass dort viel zu viel passiert das nicht transparent ist wenn man sich nicht tagelang mit jedem Detail beschäftigt.
Mit deinem Adapter hat man einfach Daten mit denen man dann machen kann, was man will und damit auch immer sicher ist, dass man weiß was auf das Hauskraftwerk geschrieben wird. Denn ich will nie eine Diskussion haben müssen, dass irgendwelche Garantie nicht mehr gilt, weil man selbst in die Lade- oder Entladeprozesse eingegriffen hat.
-
@ujok
Es sind ja jetzt einige neue Einstellmöglichkeiten dazu gekommen Uli wofür ist die neue Instanz Einstellung: SET_IDLE_PERIOD Schreibverzögerung?
Mir ist aufgefallen das der Wert EMS.POWER_BAT immer wieder mal nicht jede sek. Abgerufen wird, obwohl dieser auf short eingestellt ist.
Wenn man sich die drei Werte POWER_BAT, POWER_GRID und POWER_HOME mit 1 sek. Anzeigen lässt, bleibt POWER_BAT ab und zu hängen. -
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
Da ist man mal zwei Tage weg und schon gibt es zwei neue Versionen
Werde ich gleich mal installieren und testen.
Sei froh, dass du die v13 verpasst hast - die war buggy
-
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok
Es sind ja jetzt einige neue Einstellmöglichkeiten dazu gekommen Uli wofür ist die neue Instanz Einstellung: SET_IDLE_PERIOD Schreibverzögerung?
Mir ist aufgefallen das der Wert EMS.POWER_BAT immer wieder mal nicht jede sek. Abgerufen wird, obwohl dieser auf short eingestellt ist.
Wenn man sich die drei Werte POWER_BAT, POWER_GRID und POWER_HOME mit 1 sek. Anzeigen lässt, bleibt POWER_BAT ab und zu hängen.Hmm, es gibt wirklich etliche Sonderfälle und Tricks in dem Adapter, aber die POWER_{HOME,GRID,BAT,ADD} werden überall gleich behandelt, die S/M/L-Einstellung sollte der einzig mögliche Unterschied sein :rätsel:
Bei mir ändern sich auch nicht immer alle Werte gleichzeitig. Kann es nicht einfach sein, dass POWER_BAT mal ein paar Sekunden gleich bleibt? Z.B. weil das E3/DC die BAT_POWER etwas träger anpasst, oder weil die Messung etwas träger ist... wie lange bleibt POWER_BAT denn bei dir unverändert (während die anderen Werte schwanken)? -
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
BAT_POWER etwas träger anpasst, oder weil die Messung etwas träger ist... wie lange bleibt POWER_BAT denn bei dir unverändert (während die anderen Werte schwanken)?
Habe es jetzt mit dem Modbus Adapter verglichen und dort ist es auch so. Wahrscheinlich hast du recht, dass sich der Wert einfach nicht jede sek. Ändert.
Den Text hatte ich schon gelesen, nur nicht ganz verstanden. Heißt das, mit SET_IDLE_PERIOD in der eingestellten Zeit alle bis dahin gemachten Änderungen in einem Aufruf übertragen werden? und bis dahin alle Änderungen nicht aktiv sind?
Was ist mit SET_POWER_MODE und SET_POWER_VALUE, werden diese dann auch erst verzögert übertragen ? -
@ujok
Kann es sein das die beiden Tags:
e3dc-rscp.0.EMS.REMAINING_BAT_CHARGE_POWER und e3dc-rscp.0.EMS.REMAINING_BAT_DISCHARGE_POWER
nicht abgerufen werden?Diese Werte ändern sich bei mir nicht, obwohl gerade aus der Batterie entladen wird.
Bin davon ausgegangen das diese beiden Werte die restliche verbleibende Lade / Entladeleistung anzeigen. -
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
BAT_POWER etwas träger anpasst, oder weil die Messung etwas träger ist... wie lange bleibt POWER_BAT denn bei dir unverändert (während die anderen Werte schwanken)?
Habe es jetzt mit dem Modbus Adapter verglichen und dort ist es auch so. Wahrscheinlich hast du recht, dass sich der Wert einfach nicht jede sek. Ändert.
Den Text hatte ich schon gelesen, nur nicht ganz verstanden. Heißt das, mit SET_IDLE_PERIOD in der eingestellten Zeit alle bis dahin gemachten Änderungen in einem Aufruf übertragen werden? und bis dahin alle Änderungen nicht aktiv sind?
Wenn du innerhalb einer Idle-Period (an den 5 Feldern) Änderungen machst, wird erst dann übertragen, wenn du für eine Dauer von mindestens <SET_IDLE_PERIOD delay> nichts mehr änderst. Dann werden alle Änderungen auf einmal übertragen. Anders herum: jede Änderung setzt für diese eine Idle Period einen Timeout bzw. setzt ihn zurück; erst wenn er abläuft, wird übertragen.
(Ich ergänze den Text im README.md, damit das etwas klarer wird.)Was ist mit SET_POWER_MODE und SET_POWER_VALUE, werden diese dann auch erst verzögert übertragen ?
Nein, diese werden aktuell nach jeder Änderung zunächst einzeln übertragen und danach (sofern MODE ungleich 0 ist) alle <SET_POWER resend interval> paarweise wiederholt.
Das könnte ich analog zu den idle periods umstellen, wenn sinnvoll und hilfreich. -
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
@ujok
Kann es sein das die beiden Tags:
e3dc-rscp.0.EMS.REMAINING_BAT_CHARGE_POWER und e3dc-rscp.0.EMS.REMAINING_BAT_DISCHARGE_POWER
nicht abgerufen werden?Diese Werte ändern sich bei mir nicht, obwohl gerade aus der Batterie entladen wird.
Bin davon ausgegangen das diese beiden Werte die restliche verbleibende Lade / Entladeleistung anzeigen.Die beiden Werte werden abgerufen (voreingestelltes Intervall M) und zeigen bei mir auch sinnvolle Werte an (habe allerdings aktuell keine PV-Leistung anliegen).
Was den Inhalt anbelangt, kenne ich auch nur die Beschreibung aus der Tag-Liste. Diese lese ich so, dass es sich um die über die aktuelle Ladeleistung hinaus noch verfügbare Ladeleistung handelt, also z.B. 2000 W wenn gerade mit 1000 W geladen wird und das Maximum der Anlage bei 3000 W Ladeleistung liegt.Die entsprechende Summe
BAT_0.SPECIFIED_CHARGE_POWER = POWER_BAT + REMAINING_BAT_CHARGE_POWER
geht bei mir auch einigermaßen auf. -
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Die beiden Werte werden abgerufen (voreingestelltes Intervall M) und zeigen bei mir auch sinnvolle Werte an (habe allerdings aktuell keine PV-Leistung anliegen).
Ok dann ist bei mir noch was schiefgelaufen, diese beiden Werte ändern sich nicht.
Werde den Adapter noch mal neu installieren und dann noch mal prüfen. -
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Wenn du innerhalb einer Idle-Period (an den 5 Feldern) Änderungen machst, wird erst dann übertragen, wenn du für eine Dauer von mindestens <SET_IDLE_PERIOD delay> nichts mehr änderst. Dann werden alle Änderungen auf einmal übertragen. Anders herum: jede Änderung setzt für diese eine Idle Period einen Timeout bzw. setzt ihn zurück; erst wenn er abläuft, wird übertragen.
(Ich ergänze den Text im README.md, damit das etwas klarer wird.)Ok jetzt verstanden
Was ist mit SET_POWER_MODE und SET_POWER_VALUE, werden diese dann auch erst verzögert übertragen ?
Nein, diese werden aktuell nach jeder Änderung zunächst einzeln übertragen und danach (sofern MODE ungleich 0 ist) alle <SET_POWER resend interval> paarweise wiederholt.
Das könnte ich analog zu den idle periods umstellen, wenn sinnvoll und hilfreich.Bitte erstmal so lassen. Kann sein das die automatische Wiederholung auch noch rausmuss, das kann ich aber erst sicher sagen, wenn ich mein Script soweit fertig habe um zu sehen was für die Steuerung besser funktioniert.
-
@ujok
Habe den Adapter neu installiert und vor der Neuinstallation alles gelöscht.
Der Tag REMAINING_BAT_DISCHARGE_POWER wird bei mir nur einmal beim Start aktualisiert, und zwar immer auf denselben Wert von 11997W und bleibt dann so obwohl die Batterie ja entladen wird. Habe diesen Wert auch schon auf s eingestellt und ändert sich nicht.Den Wert REMAINING_BAT_CHARGE_POWER kann ich im Moment nicht testen wegen fehlender PV-Leistung vom Dach.
Update:
Ok habe jetzt den Fehler gefunden bzw. bin ich hier von was anderem ausgegangen.
Der Tag REMAINING_BAT_DISCHARGE_POWER ist bei mir die Rückmeldung von MAX_DISCHARGE_POWER.
Diese beiden Tags haben immer denselben Wert.
Das Gleiche ist auch bei REMAINING_BAT_CHARGE_POWER und MAX_CHARGE_POWER.
Da ist REMAINING_BAT_CHARGE_POWER auch die Rückmeldung von der Einstellung MAX_CHARGE_POWER.Uli, wenn das bei dir anders ist, hat E3DC hier zwei unterschiedliche Werte je nach Model auf die Tags gelegt.
