NEWS
Test Adapter e3dc-rscp v0.0.x GitHub
-
@arnod Wenn du die AC_A... Objekte löscht und den Adapter neu startest, werden diese mit korrektem Namen angelegt.
Deshalb lösche ich immer den ganzen Baum, um keine Altlasten mitzuschleppen.
Wh ist meiner Meinung nach richtig, das ist im rscpGui falsch. So hätte ich schon 54GW eingespeist :)@matis sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Wenn du die AC_A... Objekte löscht und den Adapter neu startest, werden diese mit korrektem Namen angelegt.
Ja, ist jetzt richtig.
Werde ich in Zukunft berücksichtigen, Danke.Ist es möglich bei EMS diese Tags noch mit aufzunehmen ?
TAG_EMS_REQ_SET_POWER
TAG_EMS_REQ_SET_POWER_MODE
TAG_EMS_REQ_SET_POWER_VALUE
TAG_EMS_SET_POWER
TAG_EMS_REQ_STATUSDamit wäre es möglich das E3DC zu steuern.
-
@matis
kleiner Exkurs vom Thema:Ich teile mal meinen Haupt-VIS der PV, denn ich bin so begeistert endlich Zugriff auf die String-Daten zu haben.
Das hilft sehr in der Optimierung und letztendlich auch in der Beurteilung, ob die Stringlänge immer rechnerisch mit maximalmen Temp.koeffizient festgelegt werden muss oder ob man da auch mal empirisch rangehen kann.
Vor allem auch bei meinen komplexen Strings mit Verschattung.
Mit IoBroker kann man ja hervorragend Daten sammeln und auswerten.
Mit dem prozentualen Verhältnis zu kWp des Strings lassen sich auch Ausfälle o.ä. sehr gut sehen.Also nochmals vielen Dank für den Adapter und die rasende Fortentwicklung.
Ich hab die Wärmepumpe teilweise mit eingebaut, eine komplett unabhängige Ladeoptimierung der Wärmepumpe definiert und kann über die mit Smartmeter eingebundenen eHz Zähler für Verbrauch, Produktion und Einspeisung/Bezug auch die PV Messungen vergleichen und die Verluste (5-16% je nach Batteriebeteiligung) sehen.
-
DC Prod. = Solar - Bat. laden + Bat. entladen
AC Prod. = tatsächliche Prod. vom ehz-Prod.ZählerVerlust: (DC-AC)/DC*100 [%]
Bewegt sich bei mir zwischen 5%, wenn es wenige Batteriebeteiligung gibt und direkt in den Verbrauch oder Einspeisung geht, bis zu 16%, wenn viel Batteriebeteiligung und damit Batterie-Lade und -Entlade-Verluste dazukommen.
Letztendlich ist es das Verhältnis des solaren Ertrages zu dem was wirklich AC verwendbar ist. -
DC Prod. = Solar - Bat. laden + Bat. entladen
AC Prod. = tatsächliche Prod. vom ehz-Prod.ZählerVerlust: (DC-AC)/DC*100 [%]
Bewegt sich bei mir zwischen 5%, wenn es wenige Batteriebeteiligung gibt und direkt in den Verbrauch oder Einspeisung geht, bis zu 16%, wenn viel Batteriebeteiligung und damit Batterie-Lade und -Entlade-Verluste dazukommen.
Letztendlich ist es das Verhältnis des solaren Ertrages zu dem was wirklich AC verwendbar ist.@matis sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Letztendlich ist es das Verhältnis des solaren Ertrages zu dem was wirklich AC verwendbar ist.
Genau da liegt mein Problem. Hast du einen DC Zähler verbaut oder woher nimmst den DC Solar Wert?
-
@matis sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Letztendlich ist es das Verhältnis des solaren Ertrages zu dem was wirklich AC verwendbar ist.
Genau da liegt mein Problem. Hast du einen DC Zähler verbaut oder woher nimmst den DC Solar Wert?
@arnod
Na DC mißt das S10, was du brauchst ist ein Produktionszähler.
e3dc schlägt den Verlust einfach auf den Hausverbrauch drauf. Deshalb ist der ständig zu hoch.
Das kannst du aber nur rausrechnen, wenn du einen zusätzlichen Produktionszähler hast. Dann ist Produktion - Einspeisung = echter Hausverbrauch. Oder du hast zusätlich noch einen Hausverbrauch Zähler. -
@arnod
Na DC mißt das S10, was du brauchst ist ein Produktionszähler.
e3dc schlägt den Verlust einfach auf den Hausverbrauch drauf. Deshalb ist der ständig zu hoch.
Das kannst du aber nur rausrechnen, wenn du einen zusätzlichen Produktionszähler hast. Dann ist Produktion - Einspeisung = echter Hausverbrauch. Oder du hast zusätlich noch einen Hausverbrauch Zähler.@matis
Habe ganz vergessen das man jetzt DC_STRING_ENERGY_ALL auslesen kann. Das war ja bis jetzt nicht möglich.
Danke Uli :+1: :grinning:Hatte bis jetzt nur den Produktionszähler, der ja erst nach der Batterie im AC Netz verbaut ist und natürlich den Hausverbrauch / Einspeise Zähler.
Deswegen war ich jetzt gerade etwas verwirrt, wo du die DC Solar Leistung auslesen kannst. -
@matis
Habe ganz vergessen das man jetzt DC_STRING_ENERGY_ALL auslesen kann. Das war ja bis jetzt nicht möglich.
Danke Uli :+1: :grinning:Hatte bis jetzt nur den Produktionszähler, der ja erst nach der Batterie im AC Netz verbaut ist und natürlich den Hausverbrauch / Einspeise Zähler.
Deswegen war ich jetzt gerade etwas verwirrt, wo du die DC Solar Leistung auslesen kannst. -
Ok Rückmeldung was mir aufgefallen ist.
BAT:
Bat#0 Anzeige und Werte i.O
Bat#1 Anzeige und Werte i.O
Schöner Wohnen:
Der Wert ASOC im e3dc.rscp ist im RSCPGui SOH (State of Health), konnte in der RSCP-TAG Liste ASOC auch nicht finden.PVI
PVI#0 Anzeige und Werte i.O (auch die Werte Phase#0-2)
Schöner Wohnen:
Der Wert AC_APPARENTPOWER ist "name": UNDEFINED_NAME
AC_ENERGY_ALL und AC_ENERGY_GRID_CONSUMPTION ist sie Einheit in RSCPGui "kWh" und in e3dc.rscp "Wh", bin mir nicht sicher was hier richtig ist.
AC_REACTIVEPOWER die Einheit für Blindleistung ist VArKeine Fehlermeldungen im LOG
vier Warnungen, die man ja ignorieren soll :-)@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
...Schöner Wohnen:
Der Wert ASOC im e3dc.rscp ist im RSCPGui SOH (State of Health), konnte in der RSCP-TAG Liste ASOC auch nicht finden.
...
Schöner Wohnen:
Der Wert AC_APPARENTPOWER ist "name": UNDEFINED_NAME
AC_ENERGY_ALL und AC_ENERGY_GRID_CONSUMPTION ist sie Einheit in RSCPGui "kWh" und in e3dc.rscp "Wh", bin mir nicht sicher was hier richtig ist.
AC_REACTIVEPOWER die Einheit für Blindleistung ist VArASOC: den Namen habe ich tatsächlich von rxhan/RscpGui, dort heißt das Tag (programmintern) so.
Aber ich gebe dir Recht, alle 4 Namen (RSOC, ASOC, SOC, SOH) zu verwenden macht nicht so viel Sinn.
Ich schau mir das an und suche eine "schöne" Lösung, die möglichst nicht von den offiziellen RSCP-Tagnamen abweicht. (Btw, in RscpGui sind zig Tags, die nicht in der offiziellen Liste stehen; rxhan muss mehr als die publizierte Tag-Liste haben.)AC_REACTIVEPOWER: [VAr], das nehme ich auf, danke!
-
@matis sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Wenn du die AC_A... Objekte löscht und den Adapter neu startest, werden diese mit korrektem Namen angelegt.
Ja, ist jetzt richtig.
Werde ich in Zukunft berücksichtigen, Danke.Ist es möglich bei EMS diese Tags noch mit aufzunehmen ?
TAG_EMS_REQ_SET_POWER
TAG_EMS_REQ_SET_POWER_MODE
TAG_EMS_REQ_SET_POWER_VALUE
TAG_EMS_SET_POWER
TAG_EMS_REQ_STATUSDamit wäre es möglich das E3DC zu steuern.
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
...Ist es möglich bei EMS diese Tags noch mit aufzunehmen ?
TAG_EMS_REQ_SET_POWER
TAG_EMS_REQ_SET_POWER_MODE
TAG_EMS_REQ_SET_POWER_VALUE
TAG_EMS_SET_POWER
TAG_EMS_REQ_STATUSDamit wäre es möglich das E3DC zu steuern.
Ja, ist im Backlog.
-
@arnod said in Test Adapter e3dc-rscp v0.0.x GitHub:
...Schöner Wohnen:
Der Wert ASOC im e3dc.rscp ist im RSCPGui SOH (State of Health), konnte in der RSCP-TAG Liste ASOC auch nicht finden.
...
Schöner Wohnen:
Der Wert AC_APPARENTPOWER ist "name": UNDEFINED_NAME
AC_ENERGY_ALL und AC_ENERGY_GRID_CONSUMPTION ist sie Einheit in RSCPGui "kWh" und in e3dc.rscp "Wh", bin mir nicht sicher was hier richtig ist.
AC_REACTIVEPOWER die Einheit für Blindleistung ist VArASOC: den Namen habe ich tatsächlich von rxhan/RscpGui, dort heißt das Tag (programmintern) so.
Aber ich gebe dir Recht, alle 4 Namen (RSOC, ASOC, SOC, SOH) zu verwenden macht nicht so viel Sinn.
Ich schau mir das an und suche eine "schöne" Lösung, die möglichst nicht von den offiziellen RSCP-Tagnamen abweicht. (Btw, in RscpGui sind zig Tags, die nicht in der offiziellen Liste stehen; rxhan muss mehr als die publizierte Tag-Liste haben.)AC_REACTIVEPOWER: [VAr], das nehme ich auf, danke!
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Aber ich gebe dir Recht, alle 4 Namen (RSOC, ASOC, SOC, SOH) zu verwenden macht nicht so viel Sinn.
Da es sich um unterschiedliche Werte handelt, würden drei Bezeichnungen schon Sinn ergeben.
Nur ASOC und SOH sind demnach dasselbe und da würde ich bei der offiziellen Bezeichnung SOH bleiben.
ASOC kann ich auch mit Google nicht finden . -
@matis sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
den DC Ertrag gabe es schon immer auch über modbus.
Ja als Wert, aber nicht als Zähler. Man hätte allerdings ein Script schreiben können.
-
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Aber ich gebe dir Recht, alle 4 Namen (RSOC, ASOC, SOC, SOH) zu verwenden macht nicht so viel Sinn.
Da es sich um unterschiedliche Werte handelt, würden drei Bezeichnungen schon Sinn ergeben.
Nur ASOC und SOH sind demnach dasselbe und da würde ich bei der offiziellen Bezeichnung SOH bleiben.
ASOC kann ich auch mit Google nicht finden .Da es sich um unterschiedliche Werte handelt, würden drei Bezeichnungen schon Sinn ergeben.
Nur ASOC und SOH sind demnach dasselbe und da würde ich bei der offiziellen Bezeichnung SOH bleiben.
ASOC kann ich auch mit Google nicht finden .Hier ist ASOC gut beschrieben:
https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/444857/rsoc-vs-asoc-what-s-the-differenceAber SOH ist offenbar viel weiter verbreitet als ASOC. Deshalb nehme ich auf:
RSOC => SOC/Ladezustand
ASOC => SOH/Alterungszustand
(für die Namen; die Tag-IDs will ich unverändert lassen, um konsistent zu einer evtl mal vollständig verfügbaren offiziellen Tag-Liste zu bleiben.)Weshalb sprichst du von 3 Bezeichnungen?
Es gibt daneben auch noch REAL_RSOC. Weiß jemand, was das bedeutet?
-
Da es sich um unterschiedliche Werte handelt, würden drei Bezeichnungen schon Sinn ergeben.
Nur ASOC und SOH sind demnach dasselbe und da würde ich bei der offiziellen Bezeichnung SOH bleiben.
ASOC kann ich auch mit Google nicht finden .Hier ist ASOC gut beschrieben:
https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/444857/rsoc-vs-asoc-what-s-the-differenceAber SOH ist offenbar viel weiter verbreitet als ASOC. Deshalb nehme ich auf:
RSOC => SOC/Ladezustand
ASOC => SOH/Alterungszustand
(für die Namen; die Tag-IDs will ich unverändert lassen, um konsistent zu einer evtl mal vollständig verfügbaren offiziellen Tag-Liste zu bleiben.)Weshalb sprichst du von 3 Bezeichnungen?
Es gibt daneben auch noch REAL_RSOC. Weiß jemand, was das bedeutet?
@ujok Ich antorte mal als interessierter Mitleser, der (immer noch) keine e3dc besitzt.
[Klugscheißermodus]
SOC ist für mich der State of Charge also der Ladezustand.
kann sein dass sich dieser auf die restlich verbleibend mögliche Energiemenge bezieht (auch bei schlechterer Batterie auf 100 gerechnet) und somit der RSOC den "wahren" wert angibt.Entsprechen ist der SOH mit "Alterungszustand" nicht so ganz richtig übersetzt, obwohl das Alter in den meisten Fällen den SOH beeinflussen wird.
State of Health bezeichnet ja eigentlich den "Gesundheitszustand" der natürlich auch beim "gesundheitlichen" Ausfall einer Zelle/einiger Zellen auch nach geringem Alter bereits in die Knie gehen könnte[/Klugscheißermodus]
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
Da es sich um unterschiedliche Werte handelt, würden drei Bezeichnungen schon Sinn ergeben.
Nur ASOC und SOH sind demnach dasselbe und da würde ich bei der offiziellen Bezeichnung SOH bleiben.
ASOC kann ich auch mit Google nicht finden .Hier ist ASOC gut beschrieben:
https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/444857/rsoc-vs-asoc-what-s-the-differenceAber SOH ist offenbar viel weiter verbreitet als ASOC. Deshalb nehme ich auf:
RSOC => SOC/Ladezustand
ASOC => SOH/Alterungszustand
(für die Namen; die Tag-IDs will ich unverändert lassen, um konsistent zu einer evtl mal vollständig verfügbaren offiziellen Tag-Liste zu bleiben.)Weshalb sprichst du von 3 Bezeichnungen?
Es gibt daneben auch noch REAL_RSOC. Weiß jemand, was das bedeutet?
@ujok
Ich versuche es mal so zu erklären wie ich es zumindest verstanden habe.
Wenn ich falsch informiert bin bitte korrigieren.E3DC verhindert in der Ladesteuerung eine Tiefenentladung oder 100% Ladung, indem 10 % nicht genutzt werden also nur 90% der Batterie Kapazität stehen tatsächlich zur Verfügung.
Wenn jetzt im Portal ein SOC von 0% angezeigt wird (entspricht RSOC) , sind tatsächlich noch z.B 5% enthalten (entspricht RSOC REAL).
Wie viel % für den unteren und wie viel für den oberen Bereich verwendet werden, weiß ich leider auch nicht.RSOC => SOC/Ladezustand Portal (entspricht 90% der Nennkapazität beim S10 E PRO / beim S10 E und S10 mini können es 100% sein je nach Batterie)
RSOC REAL => SOC (entspricht 100% der Nennkapazität)
ASOC => SOH/Alterungszustand (Verhältnis der aktuell maximal nutzbaren Kapazität zur Nennkapazität) -
@ujok Ich antorte mal als interessierter Mitleser, der (immer noch) keine e3dc besitzt.
[Klugscheißermodus]
SOC ist für mich der State of Charge also der Ladezustand.
kann sein dass sich dieser auf die restlich verbleibend mögliche Energiemenge bezieht (auch bei schlechterer Batterie auf 100 gerechnet) und somit der RSOC den "wahren" wert angibt.Entsprechen ist der SOH mit "Alterungszustand" nicht so ganz richtig übersetzt, obwohl das Alter in den meisten Fällen den SOH beeinflussen wird.
State of Health bezeichnet ja eigentlich den "Gesundheitszustand" der natürlich auch beim "gesundheitlichen" Ausfall einer Zelle/einiger Zellen auch nach geringem Alter bereits in die Knie gehen könnte[/Klugscheißermodus]
@homoran sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Entsprechen ist der SOH mit "Alterungszustand" nicht so ganz richtig übersetzt, obwohl das Alter in den meisten Fällen den SOH beeinflussen wird.
Der SoH gibt das Verhältnis der aktuell maximal nutzbaren Kapazität zur Nennkapazität an.
Bei einer 100-Ah-Batterie mit einem SoH von 80% hat diese eine Restkapazität von 80 Ah -
@ujok
Ich versuche es mal so zu erklären wie ich es zumindest verstanden habe.
Wenn ich falsch informiert bin bitte korrigieren.E3DC verhindert in der Ladesteuerung eine Tiefenentladung oder 100% Ladung, indem 10 % nicht genutzt werden also nur 90% der Batterie Kapazität stehen tatsächlich zur Verfügung.
Wenn jetzt im Portal ein SOC von 0% angezeigt wird (entspricht RSOC) , sind tatsächlich noch z.B 5% enthalten (entspricht RSOC REAL).
Wie viel % für den unteren und wie viel für den oberen Bereich verwendet werden, weiß ich leider auch nicht.RSOC => SOC/Ladezustand Portal (entspricht 90% der Nennkapazität beim S10 E PRO / beim S10 E und S10 mini können es 100% sein je nach Batterie)
RSOC REAL => SOC (entspricht 100% der Nennkapazität)
ASOC => SOH/Alterungszustand (Verhältnis der aktuell maximal nutzbaren Kapazität zur Nennkapazität)@arnod sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
E3DC verhindert in der Ladesteuerung eine Tiefenentladung oder 100% Ladung, indem 10 % nicht genutzt werden also nur 90% der Batterie Kapazität stehen tatsächlich zur Verfügung.
das passt ja zu dem was ich schrob.
@arnod sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Der SoH gibt das Verhältnis der aktuell maximal nutzbaren Kapazität zur Nennkapazität an.
Bei einer 100-Ah-Batterie mit einem SoH von 80% hat diese eine Restkapazität von 80 AhDas ist klar.
Aber die Restkapazität ist nicht vom Alter alleine abhängig, deswegen meinte ich ja nur dass Übersetzung des SoH (State of Health) mit "Alterungszustand nicht glücklich gewählt sei -
@ujok
Ich versuche es mal so zu erklären wie ich es zumindest verstanden habe.
Wenn ich falsch informiert bin bitte korrigieren.E3DC verhindert in der Ladesteuerung eine Tiefenentladung oder 100% Ladung, indem 10 % nicht genutzt werden also nur 90% der Batterie Kapazität stehen tatsächlich zur Verfügung.
Wenn jetzt im Portal ein SOC von 0% angezeigt wird (entspricht RSOC) , sind tatsächlich noch z.B 5% enthalten (entspricht RSOC REAL).
Wie viel % für den unteren und wie viel für den oberen Bereich verwendet werden, weiß ich leider auch nicht.RSOC => SOC/Ladezustand Portal (entspricht 90% der Nennkapazität beim S10 E PRO / beim S10 E und S10 mini können es 100% sein je nach Batterie)
RSOC REAL => SOC (entspricht 100% der Nennkapazität)
ASOC => SOH/Alterungszustand (Verhältnis der aktuell maximal nutzbaren Kapazität zur Nennkapazität) -
@arnod sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Da hast du recht. Mir fällt nur gerade keine besserer Bezeichnung ein :-)
mir doch auch nicht ;-)
die wörtliche Übersetzung "Gesundheitszustand" klingt auch bescheuert -
@matis, die PVI-Werte sind jetzt drin: v0.0.7-beta
Zur Performance: es sind natürlich jetzt schon viele Werte, aber ich denke das Hauptproblem ist die dynamische Objektstruktur (je nachdem wieviele BATs, PVIs etc. gefunden werden). Jeder State wird deshalb aktuell mittels setObjectNotExists() geschrieben, was vermutlich Overkill (mangels besserem Wissen) ist.
Wer kann mir hier helfen: wie behandelt man dynamische Objektstrukturen auf "schlanke" Weise?Die Idee mit der Auswahl von Werten und deren Update-Frequenz hatte ich auch schon. Aber eine Konfig-Seite, in der man das alles pro Wert einzeln einstellen kann, mag ich mir gar nicht vorstellen - und auch nicht programmieren :innocent:
Also da wäre eine schlaue Systematik gefragt, z.B. (feste) Bereiche, die man de/aktivieren kann und (feste) Gruppen, denen man ein Abfrageintervall zuordnen kann. Vorschläge sind willkommen.Eine Frage zum Thema Update-Frequenz 1-3 sec: welchen Zweck hat eine so hohe zeitliche Auflösung? Ich denke der ioBroker ist doch nicht für real-time Prozessteuerung gedacht... und für die Langzeitbetrachtung läuft bei mir nebenher noch InfluxDB mit Grafana (Werte alle 5 sec), das ist hocheffizient bzgl. CPU und Speicher.
@ujok sagte in Test Adapter e3dc-rscp v0.0.x GitHub:
Also da wäre eine schlaue Systematik gefragt, z.B. (feste) Bereiche, die man de/aktivieren kann und (feste) Gruppen, denen man ein Abfrageintervall zuordnen kann. Vorschläge sind willkommen.
Habe jetzt länger überlegt was hier am besten wäre.
Um den Aufwand in Grenzen zu halten wären zwei Gruppen mit unterschiedlichen Abfrageintervalle wohl ausreichend.
Die Werte, die man am besten im sek. Takt benötigt und eine Gruppe mit den Werten, die man im 60 min. Takt benötigt.Muss mir mal ansehen wie das eigentlich andere gelöst haben, die auch so viele Werte abfragen und schreiben müssen, wie z.B hm-rpc Adapter.
@Homoran
Hast du eventuell einen Vorschlag oder Idee wie man das ganze Ressourcen schonender programmieren kann?
Support us
791
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge