Test Adapter e3dc-rscp v0.0.x GitHub

[Matis]

@arnod

CPU-IoBroker: 9,5% bei 30 sek.
8,8% bei e3dc-rscp off
23,5% bei 1 sek.

ed3dc-rscp off:
system.adapter.javascript.0.inputCount: 1000/15sek
system.adapter.javascript.0.outputCount: 400/15sek

e3dc.rscp 1 sek:
system.adapter.javascript.0.inputCount: 4000/15sek
system.adapter.javascript.0.outputCount: 300/15sek
system.adapter.e3dc-rscp.0.inputCount: 66/15sek
system.adapter.e3dc-rscp.0.outputCount: 6325/15sek

Mit einer Sekunde läuft zwar alles noch, doch teilweise brauchen die iobroker-Seiten lange für den Aufbau.
Nach ca. 5 Minuten (so lange hatte ich bisher nie gewartet) waren keine VIS-Anzeigen-Updates mehr möglich. Iobroker lief aber noch.
Die Instanz konnte ich nicht mehr per GUI anhalten.
Kill e3dc-rscp.0 hat funktioniert. Danach lief Iobroker auch wieder gut erreichbar und ich konnte mit 30sek. wieder die Instanz starten.

[Matis]

@arnod
mit 5 sek läuft noch alles sehr stabil und bedienbar:

system.adapter.javascript.0.inputCount: 2400/15sek
system.adapter.javascript.0.outputCount: 480/15sek
system.adapter.e3dc-rscp.0.inputCount: 24/15sek
system.adapter.e3dc-rscp.0.outputCount: 2003/15sek

[ArnoD]

@matis

ok danke, wie sind die Werte vom der Javascript.0 Instanz ohne e3dc-rscp Instanz ?
Vermute mal wesentlich niedriger.
Was passiert wenn du 1 sek. einstellst?

[Matis]

@arnod Siehe eins weiter oben!

[ArnoD]

@matis ok Danke, hatte ich überlesen
Das bedeutet das du mit 1 sek. auch Probleme hast.

@ujok
Man könnte mal versuchen nur die wichtigsten Werte im 1 sek. Takt abzufragen wie
TAG_EMS_REQ_POWER_PV
TAG_EMS_REQ_POWER_BAT
TAG_EMS_REQ_POWER_HOME
TAG_EMS_REQ_POWER_GRID
TAG_EMS_REQ_POWER_ADD

und den Rest alle 10 sek.

[ArnoD]

Ich habe jetzt mal versucht wie viele Werte mit 1 sek. Abgerufen werden können ohne das man ein Problem mit der CPU Auslastung bekommt.
Mit 11 Werten ist es noch im grünen Bereich bei unter 40% und nur ein paar spitzen bis 88%.
Ich habe diese Werte mit "RefreshPeriod": "short" eingestellt:
REQ_POWER_BAT
REQ_POWER_HOME
REQ_POWER_GRID
REQ_POWER_ADD
REQ_MODE (kann man diskutieren, ob man diesen Wert wirklich live benötigt)
REQ_STATUS
REQ_ALIVE
REQ_STATE
REQ_AC_POWER
REQ_AC_VOLTAGE
REQ_AC_CURRENT

Mit diesen Werten sieht die CPU Auslastung auch über einen längeren Zeitraum auf der Synology so aus:

[Matis]

@arnod
@ujok

Woran kann ich denn nun sehen, welcher Wert kurz, mittel, lang ist?
Ich finde es gut, dass es drei Abstufungen gibt.
Die 12 kurzen sind auch alle auf modbus und man bekommte die dort einfach auch im 1 Sek. Takt.
Dafür hätte ich gerne andere vielleicht nicht nur in Minuten oder gar Stunden.

Ich fände es besser, wenn man selbst entscheiden kann, wie lang die Stufen sind,
d.h. alle drei in Stufen in Sekunden und man kann selbst einstellen.
Mal 60 o. 3600 bekommt man sicher noch hin

[git-kick]

@arnod

Danke für die Last-Analyse! Ich habe das eingebaut: mit dem "kurzen" Intervall werden jetzt nur noch die genannten elf Felder abgefragt. Damit pendelt sich die CPU-Last der ioBroker-Instanz auf meinem Entwicklungs-Notebook (i7-1065G7) bei ca. 1,5% ein, wenn ich "Abfrageintervall kurz" = 1 sec setze.

Zusätzlich kann man jetzt ganze Namespaces nach Bedarf ausblenden.

https://github.com/git-kick/ioBroker.e3dc-rscp/tree/v0.0.12-beta

0.0.12-beta

• New in configuration panel: select namespaces to query - use it to reduce CPU load (and transmitted data volume)
• Polling interval: only 11 most important parameters left in "short" class, according to @ArnoD's analysis

[ArnoD]

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

0.0.12-beta

Werde ich gleich mal testen

[ArnoD]

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

Woran kann ich denn nun sehen, welcher Wert kurz, mittel, lang ist?
Ich finde es gut, dass es drei Abstufungen gibt.
Die 12 kurzen sind auch alle auf modbus und man bekommte die dort einfach auch im 1 Sek. Takt.

Sehen kann man es nur im Adapterverzeichnis, indem man sich die RscpTags.json ansieht.
Die Frage, ob man sich diese Werte über Modbus holt, habe ich mir auch schon gestellt, andererseits hat es natürlich auch einen Charme alles mit einem Adapter hinzubekommen und sich die Ressourcen für den zweiten Adapter zu sparen. Kann aber sein, dass man noch darauf zurückgreifen muss, wenn jetzt noch weitere Werte dazukommen.
Ich denke, man muss sich nur gut überlegen, was man wirklich als live Ansicht benötigt. Alle Werte wo ich nicht mit einer Steuerung sofort darauf reagieren will, muss ich auch nicht jede sek. Aktualisieren. Träge Werte wie Temperaturen sicher auch nicht.
Das gute ist erstmal das alles so weit funktioniert und man es sich nach Belieben einstellen kann.
Übrigens, die Zeiten können auch als 0.5 für 30 sek. im Minutenfeld eingegeben werden.

[Matis]

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

Übrigens, die Zeiten können auch als 0.5 für 30 sek. im Minutenfeld eingegeben werden.

Prima, ich hab mal wieder den Fehler gemacht und es mit Komma versucht

Sehr cool, die 0.0.12!

[ArnoD]

Uli 0.0.12 läuft ohne Fehler

Vielleicht eine optische Verbesserung für eine Anzeige in VIS.
Wenn man eine Namespace abwählt, sollten die Werte auch gelöscht werden, da sonst die Anzeigen beim alten Wert hängen bleiben und man in Vis eventuell nicht mitbekommt, dass es alte eingefrorene Werte sind.
Aber wie gesagt nur eine reine optische Korrektur.

[git-kick]

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

Vielleicht eine optische Verbesserung für eine Anzeige in VIS.
Wenn man eine Namespace abwählt, sollten die Werte auch gelöscht werden, da sonst die Anzeigen beim alten Wert hängen bleiben und man in Vis eventuell nicht mitbekommt, dass es alte eingefrorene Werte sind.

Ja, es wäre kein Problem, den jeweiligen Hauptast im Objektbaum zu löschen. Aber dann verschwinden alle Werte, auch z.B. Modellnamen, die sich nie ändern. Ich dachte vielleicht ist es ganz praktisch, die Werte einmal einzuslesen und dann die Aktualisierung zu stoppen. Aber ich stimme auch zu, dass (nicht erkennbar) veraltete Werte unschön sind.
Nicht so einfach ist es, die Werte "zurückzusetzen": erstens müsste ich dann die Werte einzeln anfassen, zweitens ist nicht immer eindeutig, was der "nicht-definiert-Wert" eigentlich ist, womöglich abhängig vom Update-Intervall (short/medium/long). Kurz: das wäre mir zu viel Aufwand/Komplexität für den (nur optischen) Effekt.

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
??

[git-kick]

@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 = 2

Hier 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).

[Matis]

@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.

[git-kick]

@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)

[ArnoD]

@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 = CHARGE

Gute 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

[git-kick]

Hier kommt die nächste Beta:
https://github.com/git-kick/ioBroker.e3dc-rscp/tree/v0.0.13-beta

Neu 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).

[Matis]

@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.

[git-kick]

@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