Test Adapter e3dc-rscp v0.0.x GitHub

[git-kick]

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

Frage eines Newby der den Adapter gerade installiert und eingerichtet hat. Ist das Verhalten normal?

e3dc-rscp.0
	2021-11-24 19:41:29.438	warn	E3/DC connection closed
e3dc-rscp.0
	2021-11-24 19:41:29.437	warn	Disconnected from E3/DC
e3dc-rscp.0
	2021-11-24 19:41:29.420	debug	Successfully written data to socket
e3dc-rscp.0
	2021-11-24 19:41:29.420	debug	OUT: magic: >E3DC< is OK - ctrl: >0011< is OK - Version 1, with CRC - seconds: 1637779179 - nseconds: 0 - length: 23 TAG_BAT_REQ_DATA - type: 0x0E - Container - length: 16 <Container content follows...> TAG_BAT_INDEX - type: 0x05 - UInt16 - length: 2 value: 3 TAG_BAT_REQ_ASOC - type: 0x00 - None - length: 0 CRC32
e3dc-rscp.0
	2021-11-24 19:41:29.420	debug	Sending request TAG_BAT_REQ_DATA
e3dc-rscp.0
	2021-11-24 19:41:29.420	info	Connection to E3/DC is established
e3dc-rscp.0
	2021-11-24 19:41:29.418	debug	Probing for PVI units - 0..2.
e3dc-rscp.0
	2021-11-24 19:41:29.418	debug	Probing for BAT units - 0..3.
e3dc-rscp.0
	2021-11-24 19:41:29.417	info	Reconnecting to E3/DC ...
e3dc-rscp.0
	2021-11-24 19:41:29.148	error	Failed writing data to socket
e3dc-rscp.0
	2021-11-24 19:41:29.147	debug	OUT: magic: >E3DC< is OK - ctrl: >0011< is OK - Version 1, with CRC - seconds: 1637779179 - nseconds: 0 - length: 23 TAG_BAT_REQ_DATA - type: 0x0E - Container - length: 16 <Container content follows...> TAG_BAT_INDEX - type: 0x05 - UInt16 - length: 2 value: 3 TAG_BAT_REQ_ASOC - type: 0x00 - None - length: 0 CRC32
e3dc-rscp.0
	2021-11-24 19:41:29.146	debug	Sending request TAG_BAT_REQ_DATA
e3dc-rscp.0
	2021-11-24 19:41:19.418	warn	E3/DC connection closed
e3dc-rscp.0
	2021-11-24 19:41:19.417	warn	Disconnected from E3/DC
e3dc-rscp.0
	2021-11-24 19:41:19.399	debug	Successfully written data to socket
e3dc-rscp.0
	2021-11-24 19:41:19.399	debug	OUT: magic: >E3DC< is OK - ctrl: >0011< is OK - Version 1, with CRC - seconds: 1637779179 - nseconds: 0 - length: 23 TAG_BAT_REQ_DATA - type: 0x0E - Container - length: 16 <Container content follows...> TAG_BAT_INDEX - type: 0x05 - UInt16 - length: 2 value: 2 TAG_BAT_REQ_ASOC - type: 0x00 - None - length: 0 CRC32
e3dc-rscp.0
	2021-11-24 19:41:19.399	debug	Sending request TAG_BAT_REQ_DATA
e3dc-rscp.0
	2021-11-24 19:41:19.398	info	Connection to E3/DC is established
e3dc-rscp.0
	2021-11-24 19:41:19.397	debug	Probing for PVI units - 0..2.
e3dc-rscp.0
	2021-11-24 19:41:19.397	debug	Probing for BAT units - 0..3.
e3dc-rscp.0
	2021-11-24 19:41:19.397	info	Reconnecting to E3/DC ...

Das Verhalten ist nicht das gewünschte. Die Meldung "Reconnecting..." kommt, nachdem die tcpConnection ein "end"-Event wirft - warum bei dir die tcpConnection immer wieder abbricht, kann ich nicht sagen. Ein möglicher Grund wären Netzwerkthemen wie Portfreigaben in der Firewall, das ist aber reine Spekulation.

[git-kick]

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

Habe mich heute länger mit dem Steuern der Ladeleistung Batterie beschäftigt und ich muss sagen das sieht gut aus bis auf die Werte von EMS.MODE.
Hatte heute beobachtet das EMS.MODE = 2 (ENTLADEN MODUS) angezeigt hat, aber die Batterie gerade geladen wurde.

Das ist wirklich etwas frustrierend. Ich sehe im Adapter kaum einen Ansatzpunkt, was da falsch laufen könnte. Vielleicht vergleichen wir das Verhalten mit dem von RscpGUI...

Jetzt habe ich die neue Version 0.0.11-beta installiert und werde diese Morgen testen.
Was mir bereits aufgefallen ist, dass bei mir die CPU Auslastung bei Einstellung „Abfrageintervall kurz“ = 3s immer noch zwischen 70% und 90% liegt.
Das kann doch nicht mehr an den paar Werten liegen die jetzt noch alle 3s abgefragt werden.
Ich bin hier etwas ratlos, was da die Ursache sein kann.
Wenn ich den Adapter stoppe, ist die CPU Auslastung gleich wieder auf 14% bis 19%.

Also sinkt die Last leider nicht wie erhofft proportional mit der Menge der abgefragten Daten. Trotzdem werde ich mal das Abschalten der Namespaces einbauen, dann bekommen wir noch mehr Anhaltspunkte, wo die CPU-Last vor allem entsteht. Leider kenne ich den ioBroker noch nicht so gut und weiß deshalb nicht, welche Aufrufe besonders "CPU-belastend" sind.

Werde aber Morgen weitere Versuche machen, ob ich noch was rausfinde.
Hatte beim ersten Start auch mehrere Warnungen und Fehler im LOG die jetzt aber nicht mehr auftreten.
Hier ein paar der Fehlermeldungen die Liste ist zu lang um hier alle anzuzeigen, da sich diese immer wiederholen:

Das ist interessant, habe ich bisher nicht beobachtet. Vermutlich hängt es mit dem "Hochfahren" des Adapters zusammen, da starte ich in schneller Folge viele Abfragen, um den Objektbaum komplett aufzubauen. Ich werde mal versuchen, dieses Verhalten bei mir zu reproduzieren.

[Matis]

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

Gestern abend hat sich der E3DC Wechselrichter mit einem lauten Knall verabschiedet und eine Panzersicherung am Hausanschluss gekillt.

Das ist so, wenn ein IGBT platzt. Das sind die MOSFETs, die im Wechselrichter die Ströme schalten, damit wieder AC draus wird. e3dc ist da aber sehr flink und tauscht dir das ganze Modul aus.
Mit dem aktuellen Wetter verpaßt du ja nicht viel

[Matis]

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

Gerade der Teil mit den Verlusten würde mich interessieren

Das ist mit teilen des dahboards nicht so einfach gemacht. Ich hab im Hintergrund ein dutzend js scripts, die auch teilweise mit der Wärmepumpe verknüpft sind. Im Grunde habe ich mir einen eigenen Zähler für die DC Werte erstellt, der Sonne und Batterie über den Tag im Sekundentakt akumuliert. Dann DC-Solar - Bat. entladen + Bat. laden ins Verhältnis gesetzt zum AC Produktionszähler, der auch vorhanden sein muß. Das Ergebnis ist der Verlust. Wenn viel eingespeißt wird sind das um die 5%, an Tagen mit viel Batteriebeteiligung kommen die Verluste der Batterie dazu, es geht bis auf 20%.

[ecki945]

@ujok habe den Fehler gefunden. Hatte bei der Eingabe des Passwortes am E3DC nicht darauf geachtet dass da zwischen Groß und Klein Schreibung unterschieden wird. Nun funktioniert es

[ArnoD]

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

Gestern abend hat sich der E3DC Wechselrichter mit einem lauten Knall verabschiedet

Das sage ich jetzt nicht meiner Frau, den der E3DC steht bei mir im Waschraum
Hoffe, das ist schnell wieder repariert.

[ArnoD]

@ujok

Vielleicht vergleichen wir das Verhalten mit dem von RscpGUI...

Das habe ich bereits gemacht, dort wird dasselbe angezeigt, also liegt es schon mal nicht an dir
Ich vermute schon fast, dass EMS.MODE nicht die Rückantwort von SET_POWER_MODE ist, sondern eine andere Logik hat.

Was die CPU Auslastung angeht, habe ich jetzt ein paar Versuche gemacht.
Die Auslastung kommt nicht nur von der e3dc-rscp Instanz, sondern auch von der Javascript Instanz.
Ich verstehe da aber noch nicht die Zusammenhänge warum, die sich gegenseitig beeinflussen.
Jeder Instanz für sich bewirkt eine CPU Last, die man als normal bezeichnen würde:
e3dc-rscp Instanz Abfrageintervall kurz auf 1 s eingestellt.

e3dc-rscp.0 = 12 %- 17 % CPU Auslastung , inputCount= 90 events/15 s , outputCount = 1976 events/15 s
javascript.0 = = 3 %- 9 % CPU Auslastung , inputCount= 404 events/15 s , outputCount = 84 events/15 s
javascript.1 = = 2 %- 3 % CPU Auslastung , inputCount= 415 events/15 s , outputCount = 12 events/15 s

wenn ich jetzt aber zwei Instanzen zusammen laufen lasse passiert Folgendes:

e3dc-rscp.0 = 20 %- 26 % CPU Auslastung , inputCount= 96 events/15 s , outputCount = 2783 events/15 s
und
javascript.1 = =160 %- 178 % CPU Auslastung , inputCount= 9462 events/15 s , outputCount = 11 events/15 s

In der javascript.1 Instanz läuft nur ein Script und das reagiert oder überwacht keine Änderungen oder Werte von e3dc-rscp wo die inputCount= 9462 events/15 s. herkommen nur durch den Start von e3dc-rscp ist mir ein Rätsel.

Im nächsten Versuch habe ich alle Skripte in javascript.1 gestoppt und die javascript.1 Instanz gestartet.
Das Ergebnis hat mich jetzt total verwundert.
Im ioBroker wurde jetzt keine CPU Auslastung mehr angezeigt, aber auf der Synology hatte der Prozess io.javascript.1 40% CPU Auslastung, obwohl alle Scripte gestoppt waren und wieder der Anstieg bei den input count events.

Im nächsten Versuch habe ich eine neue Javascript Instanz 3 erstellt und das ganze wieder mit der e3dc-rscp Instanz gestartet,
dasselbe Ergebnis. Die CPU Auslastung steigt auf 100% bei der Synology und die input count events steigen auf bis zu 9000 an.

Bin jetzt noch ratloser als vorher.

Wenn ich das aber mit einer besseren Hardware lösen kann, ist es für mich auch in Ordnung
Uli auf welcher Hardware läuft dein ioBroker ?

[Thomas Braun]

@arnod
Da dürften bei 3 Instanzen auch die Skripte alle dreifach laufen.
Den Sinn von drei javaskript-Instanzen musst du jetzt mal erklären.

[git-kick]

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

Wenn ich das aber mit einer besseren Hardware lösen kann, ist es für mich auch in Ordnung
Uli auf welcher Hardware läuft dein ioBroker ?

PC mit Ryzen 5 3600 und Win 10
Der läuft 24x7 und beherbergt neben ioBroker (in einer Ubuntu-VM) und der InfluxDB (für die E3DC - Zeitreihen) auch meine private Cloud mit allen möglichen Diensten inkl. Mail, DMS, Fotogalerie, Streaming, Backup etc.

[Matis]

@arnod Ich hab auf meiner Synology die CPU Probleme nicht, aber ich hab auch nur eine JS Instanz.0. Warum sollte man denn mehrere laufen lassen?

[ecki945]

Der Adapter ist ja der Hammer. Großes Lob am den Entwickler @ujok

[ArnoD]

@thomas-braun
Die drei Instanzen sind nicht das Problem, auch wenn nur eine Installiert ist bleibt das Problem dasselbe, habe es nur mit einer dritten ohne Scripte getestet um sicher zu sein das die Scripte keinen Einfluss haben. ( javascript.0 und javascript.1 waren während dem Test gestoppt)
Ich habe immer zwei Instanzen vom Javascript Adapter, da ich eine zum Testen oder erstellen von neuen Scripten verwende.

[ArnoD]

@matis
Da bei dir der ioBroker nicht einfriert, wenn du den Adapter e3dc.rscp mit dem Abfrageintervall kurz auf 1 s laufen lässt,
könntest du mal den Adapter e3dc.rscp stoppen und dann dir diese beiden Werte ansehen:
system.adapter.javascript.0.inputCount
system.adapter.javascript.0.outputCount

Danach auch den Adapter e3dc.rscp starten um zu sehen wie weit diese Werte ansteigen:
system.adapter.javascript.0.inputCount
system.adapter.javascript.0.outputCount
system.adapter.e3dc-rscp.0.inputCount
system.adapter.e3dc-rscp.0.outputCount

Würde mich mal interessieren wie weit sich das bei dir aufschaukelt.

[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