NEWS
Test Adapter sma-em v1.3.x Latest
-
@tuning said in Test Adapter sma-em v0.7.x Latest:
Gibt es eine möglichkeit diese Zeitbegrenzun raus zu nehmen?
Nein, die Möglichkeit gibt es nicht. Das sollte auch nicht nötig sein, denn genau wie früher werden die realtime Datenpunkte synchron zum selben Zeitpunkt upgedatet, nur eben im Abstand von minimal 1s (früher 200ms, 600ms oder 1s je nach Einstellung des EM oder SHM).
Allerdings möchte ich Dein Problem genauer verstehen.
Wie lange dauert denn die Überschneidung der Pfeile (bei einem Realtime-Intervall von 1s)?
Ich nehme an, Du nutzt die Datenpunkte pregard bzw. psurplus?
Weiterhin nehme ich an, dass Du ein Javascript oder Blockly verwendest um die Vis (welche?) anzusteuern.
Wenn Du Dein Skript hier posten magst, gibt es vielleicht Hinweise wie man die Asynchronitäten der Auslesung und Anzeige der Datenpunkte in den Griff kriegen kann.Ergänzung: Durch die Mittelwertbildung während des Aktualisierungsintervalls kann es passieren, das die Werte von pregard bzw. psurplus beide > 0 sind. Da Dein Skript vermutlich auf > 0 abfragt, führt das dann zu dem von Dir bemerkten Zustand für die Dauer eines Aktualisierungsintervalls (1s).
Ich sehe da mehrere Lösungsmöglichkeiten:- Änderung Deines Skripts, so dass eine Umschaltung der Pfeilrichtung erst erfolgt, wenn einer von beiden Werten = 0 und der andere > 0 ist.
- Generelle Abschaltung der Mittelwertbildung im Adapter für alle realtime Datenpunkte d.h. es wird jeweils der letzte Wert des Aktualisierungsintervalls genommen. Dadurch ist sichergestellt, dass ein eindeutiger Wert =0 oder >0 in pregard bzw. psurplus steht. Nachteil ist, dass eventuelle Änderungen des Leistungswertes während des Aktualisierungsintervalls nicht berücksichtigt werden und es daher zu Ungenauigkeiten kommt, wenn man die Leistungsmesswerte z.B. zur Berechnung der Arbeit benutzen möchte.
- Modifikation der Mittelwertbildung im Adapter für alle realtime Datenpunkte in der Weise, dass wenn pregard bzw. psurplus während eines Aktualisierungsintervalls mindestens 1-mal auf 0 geht, wird der letzte Messwert des Aktualisierungsintervalls statt des Mittelwerts genommen. So ist sichergestellt, dass am Ende des Aktualisierungsintervalls ein eindeutiger Wert =0 oder >0 in pregard bzw. psurplus steht. Nachteil ist dabei, dass sich dadurch Ungenauigkeiten bei der Arbeitsberechnung (s.o.) ergeben- wenn auch geringere.
Im Interesse einer möglichst hohen Messgenauigkeit würde ich die beiden letzten Alternativen nicht bevorzugen. Wie sehen Du und andere User hier im Forum das?
@pdbjjens
Danke für deine Rückmeldung.
Du hast genau recht mit deinen Annahmen.
Ich kann den Skript ändern, dann funktioniert die Anzeige.Das Problem bleibt halt, da SMA kein Lademanagment hat, welches den Spreicher nicht gleich auf 100% ladet, muss man es selber machen. (das Prognosebasierte Lademanagment funktioniert zur Zeit nicht vernünftig)
Und dafür würde ich halt auch die selben schnellen werte wie SMA benötigen. -
@pdbjjens
Danke für deine Rückmeldung.
Du hast genau recht mit deinen Annahmen.
Ich kann den Skript ändern, dann funktioniert die Anzeige.Das Problem bleibt halt, da SMA kein Lademanagment hat, welches den Spreicher nicht gleich auf 100% ladet, muss man es selber machen. (das Prognosebasierte Lademanagment funktioniert zur Zeit nicht vernünftig)
Und dafür würde ich halt auch die selben schnellen werte wie SMA benötigen.Hallo, ich habe das Problem, dass seit ein paar Tagen für psurplus und pregard genau die Hälfte anzeigt wird, als im Sunny Portal. z.B. Sunny Portal 500W im ioBroker 250W. Vorher hat es Monate funktioniert. Ich bin mir nicht bewusst eine Änderung gemacht zu haben. Hat jemand eine Idee, was falsch läuft?
-
Hallo, ich habe das Problem, dass seit ein paar Tagen für psurplus und pregard genau die Hälfte anzeigt wird, als im Sunny Portal. z.B. Sunny Portal 500W im ioBroker 250W. Vorher hat es Monate funktioniert. Ich bin mir nicht bewusst eine Änderung gemacht zu haben. Hat jemand eine Idee, was falsch läuft?
-
Hallo, ich habe das Problem, dass seit ein paar Tagen für psurplus und pregard genau die Hälfte anzeigt wird, als im Sunny Portal. z.B. Sunny Portal 500W im ioBroker 250W. Vorher hat es Monate funktioniert. Ich bin mir nicht bewusst eine Änderung gemacht zu haben. Hat jemand eine Idee, was falsch läuft?
-
@pingpong
Welche Adapter Version ist im Einsatz? Hast Du evtl. ein Update auf v0.7.0 gemacht? -
@pdbjjens
Danke für deine Rückmeldung.
Du hast genau recht mit deinen Annahmen.
Ich kann den Skript ändern, dann funktioniert die Anzeige.Das Problem bleibt halt, da SMA kein Lademanagment hat, welches den Spreicher nicht gleich auf 100% ladet, muss man es selber machen. (das Prognosebasierte Lademanagment funktioniert zur Zeit nicht vernünftig)
Und dafür würde ich halt auch die selben schnellen werte wie SMA benötigen.@tuning said in Test Adapter sma-em v0.7.x Latest:
Und dafür würde ich halt auch die selben schnellen werte wie SMA benötigen.
Ich würde gerne verstehen, warum Dir das Update Intervall von 1s nicht ausreicht.
Würdest Du mir bitte in ein paar Sätzen erklären, wie Dein Lademanagement funktioniert bzw. funktionieren soll?Bisher habe ich von anderen Usern der v0.7.0 kein Feedback, dass sie mit der Mittelwertbildung und einem Update Intervall von 1s in Ihren Applikationen Schwierigkeiten hätten.
Daher meine Frage in die Runde in diesem Thread: sieht jemand die Notwendigkeit, das alte Verhalten zurückzubringen? Wenn ja, warum? -
@tuning said in Test Adapter sma-em v0.7.x Latest:
Und dafür würde ich halt auch die selben schnellen werte wie SMA benötigen.
Ich würde gerne verstehen, warum Dir das Update Intervall von 1s nicht ausreicht.
Würdest Du mir bitte in ein paar Sätzen erklären, wie Dein Lademanagement funktioniert bzw. funktionieren soll?Bisher habe ich von anderen Usern der v0.7.0 kein Feedback, dass sie mit der Mittelwertbildung und einem Update Intervall von 1s in Ihren Applikationen Schwierigkeiten hätten.
Daher meine Frage in die Runde in diesem Thread: sieht jemand die Notwendigkeit, das alte Verhalten zurückzubringen? Wenn ja, warum?Na ich versuche es einmal.
Der SMA Hybrid Wechselrichter hat keine Einstellung wie er die Batterie Laden soll.
Also ladet der WR die Batterie mit allem was geht bis um 11:00 wo die Batterie dann bis am Abend mit 100% rumsteht.
Natürlich könnte ich die Max Ladung z.B. auf 80% begrenzen, ist technisch halt keine richtige Lösung.Außerdem habe ich das Problem, bei kurzen einschalten von Verbrauchern (in meinem Fall, der getaktete Herd),
wechselt er in 3 Sekundentakt zwischen Batterie Laden von PV und Entladen der Batt.
Hab da auch schon mit SMA geschrieben, lt. denen ist es nicht Lebenszyklus verkürzend.
Ich als Techniker sage es tut ihr nicht gut.
Das nächste, ich würde im Herbst gerne die Entladeleistung begrenzen, da sonst die WP die Batterie in einer Stunde leer ist.
Und für diesen Zweck muss ich die Steuerung über Modbus übernehmen und die Leistung vorgeben.
Ich kann aber nur die Lade und Entladeleistung vorgeben. Aber nicht von wo die Energie kommt. (PV oder Netzbezug)
Also muss ich den Wert vom Hm2.0 nehmen und damit schnell Steuern, wie es SMA auch macht.Ich hoffe ich konnte mein anliegen verständlich erklären, warum im schnelle Werte gerne hätte.
Und meine Idee wäre einfach gewesen, die Begrenzung von 1sek. , einfach niedrigere Werte zuzulassen. -
@tuning
Danke für die Erläuterungen. Ohne dass ich die Funktionsweise des Batteriemanagements der SMA Hybridwechselrichter kenne möchte ich bezweifeln, dass es Dir gelingen könnte auf Basis von ioBroker eine verbesserte Regelung zu entwickeln. ioBroker ist kein Realzeitsystem. Selbst wenn der sma-em Adapter die Datenpunkte mit der Messagerate des SHM oder EM updaten würde, also im Abstand von minimal 200ms, würde es nach meiner Einschätzung sehr schwer möglich sein, daraus Realzeit-Steuerinformationen für die Batterie abzuleiten und zur Batterie weiterzuleiten.Die Bildung von Intervallen im sma-em wurde aufgrund eines Lastproblems eingeführt.
https://github.com/iobroker-community-adapters/ioBroker.sma-em/issues/142
ioBroker kann nur eine begrenzte Anzahl von Events pro Zeiteinheit verarbeiten. Überschreitet ein Adapter diese Anzahl wird er temporär suspendiert um den Rest des Systems nicht zu gefährden.
Daher halte ich es für nicht ratsam, die alten Updatezeiten d.i. 200ms ohne Mittelwertbildung wieder zuzulassen.
Auch meine ich, dass wenn eine Applikation mit Intervallen von 1s auf ioBroker nicht funktioniert, sollte sie auf einem dedizierten System implementiert werden. In Deinem Fall empfehle ich, mal nach speziell für das Energiemanagement ausgelegten Systemen zu schauen.
Hast Du Dir schon mal https://openems.github.io/openems.io/openems/latest/edge/architecture.html angeschaut?
Ergänzung: Ich bin gerade eben auf ein ioBroker Skript gestoßen, was das prognosebasierte Laden von SMA ersetzen soll. Vielleicht hilft Dir das auch. -
@tuning
Danke für die Erläuterungen. Ohne dass ich die Funktionsweise des Batteriemanagements der SMA Hybridwechselrichter kenne möchte ich bezweifeln, dass es Dir gelingen könnte auf Basis von ioBroker eine verbesserte Regelung zu entwickeln. ioBroker ist kein Realzeitsystem. Selbst wenn der sma-em Adapter die Datenpunkte mit der Messagerate des SHM oder EM updaten würde, also im Abstand von minimal 200ms, würde es nach meiner Einschätzung sehr schwer möglich sein, daraus Realzeit-Steuerinformationen für die Batterie abzuleiten und zur Batterie weiterzuleiten.Die Bildung von Intervallen im sma-em wurde aufgrund eines Lastproblems eingeführt.
https://github.com/iobroker-community-adapters/ioBroker.sma-em/issues/142
ioBroker kann nur eine begrenzte Anzahl von Events pro Zeiteinheit verarbeiten. Überschreitet ein Adapter diese Anzahl wird er temporär suspendiert um den Rest des Systems nicht zu gefährden.
Daher halte ich es für nicht ratsam, die alten Updatezeiten d.i. 200ms ohne Mittelwertbildung wieder zuzulassen.
Auch meine ich, dass wenn eine Applikation mit Intervallen von 1s auf ioBroker nicht funktioniert, sollte sie auf einem dedizierten System implementiert werden. In Deinem Fall empfehle ich, mal nach speziell für das Energiemanagement ausgelegten Systemen zu schauen.
Hast Du Dir schon mal https://openems.github.io/openems.io/openems/latest/edge/architecture.html angeschaut?
Ergänzung: Ich bin gerade eben auf ein ioBroker Skript gestoßen, was das prognosebasierte Laden von SMA ersetzen soll. Vielleicht hilft Dir das auch.@pdbjjens
Danke für deine Bemühung, insbesondere die aufgezeigten alternativen.Eine Verbesserung, ist schon einmal wenn die Batterie nicht 8 stunden mit 100% steht.
Für dies benötige ich aber auch die kurze Zeit nicht.
Zum kurzen unterbinden zwischen dem Umschalten Laden/Entladen, wird es halt schon knapp werden.Ja, für das prognostizierte Laden, hat es schon mehrere Ansätze gegeben, kann funktionieren.
Allerdings kann der Ersteller des Skriptes, nichts anderes machen als ich eh schon mit Blockly machen.
Es gibt derzeit einfach keine Möglichkeit den WR zu sagen er soll langsamer laden.
Gibt nur 0 oder 1.
Die Parameter im Modbus gibt es, sie sind nur nicht freigeschaltet. Und da der Baugleich Sungrow es kann, ist es nur ein Thema der Firmware.Ich bin mir sicher es wird einmal etwas von SMA kommen, womit man regeln kann, da ich aber schon seit 2022 darauf warte, muss man halt selber etwas tun.
-
Na ich versuche es einmal.
Der SMA Hybrid Wechselrichter hat keine Einstellung wie er die Batterie Laden soll.
Also ladet der WR die Batterie mit allem was geht bis um 11:00 wo die Batterie dann bis am Abend mit 100% rumsteht.
Natürlich könnte ich die Max Ladung z.B. auf 80% begrenzen, ist technisch halt keine richtige Lösung.Außerdem habe ich das Problem, bei kurzen einschalten von Verbrauchern (in meinem Fall, der getaktete Herd),
wechselt er in 3 Sekundentakt zwischen Batterie Laden von PV und Entladen der Batt.
Hab da auch schon mit SMA geschrieben, lt. denen ist es nicht Lebenszyklus verkürzend.
Ich als Techniker sage es tut ihr nicht gut.
Das nächste, ich würde im Herbst gerne die Entladeleistung begrenzen, da sonst die WP die Batterie in einer Stunde leer ist.
Und für diesen Zweck muss ich die Steuerung über Modbus übernehmen und die Leistung vorgeben.
Ich kann aber nur die Lade und Entladeleistung vorgeben. Aber nicht von wo die Energie kommt. (PV oder Netzbezug)
Also muss ich den Wert vom Hm2.0 nehmen und damit schnell Steuern, wie es SMA auch macht.Ich hoffe ich konnte mein anliegen verständlich erklären, warum im schnelle Werte gerne hätte.
Und meine Idee wäre einfach gewesen, die Begrenzung von 1sek. , einfach niedrigere Werte zuzulassen.@tuning sagte in Test Adapter sma-em v0.7.x Latest:
Also muss ich den Wert vom Hm2.0 nehmen und damit schnell Steuern, wie es SMA auch macht.
sry..aber das ist schwachsinn... SMA regelt auch nicht sofort.. auch wenn du es so siehst..
es dauert bis die Batterie anspringt und den Ladestrom her gibt oder eben geladen wirdeine Auflösung alle 10 Sec. recht da dicke um auf die Werte zu reagieren..
welchen SMA Hybrid Wechselrichter hast du da hängen ??
-
@tuning sagte in Test Adapter sma-em v0.7.x Latest:
Also muss ich den Wert vom Hm2.0 nehmen und damit schnell Steuern, wie es SMA auch macht.
sry..aber das ist schwachsinn... SMA regelt auch nicht sofort.. auch wenn du es so siehst..
es dauert bis die Batterie anspringt und den Ladestrom her gibt oder eben geladen wirdeine Auflösung alle 10 Sec. recht da dicke um auf die Werte zu reagieren..
welchen SMA Hybrid Wechselrichter hast du da hängen ??
-
@arteck
Mal kurz zwischendurch ein anderes Thema:
Du hast vor kurzem die SUSy-ID 501 im sma-em ergänzt. Wo hast Du die gefunden? Ist sie mit einem Firmware-Update des SHM gekommen? -
@arteck said in Test Adapter sma-em v0.7.x Latest:
SUNNY TRIPOWER 10.0 SE
Soweit ich eben recherchieren konnte, verwendet der SUNNY TRIPOWER 10.0 SE als Energy Meter den "ganz normalen" SHM. (SUSy 372) und hat auch kein eigenes "neues" eingebautes EM. Die SUSy 501 identifiziert den SUNNY TRIPOWER 10.0 SE aber kein neues Energy Meter. Die SUSy 501 wird daher vom SUNNY TRIPOWER 10.0 SE niemals über das SMA-EMETER-protocol-2 gesendet.
sma-em ist nur für die Erfassung der Messdaten von SHM und EM über das SMA-EMETER-protocol-2 ausgelegt und nicht etwa für die Daten der Wechselrichter. Daher ist das Hinzufügen der SUSy 501 im sma-em sinnlos und ich werde die Änderung mit Deiner Zustimmung wieder entfernen. -
@arteck said in Test Adapter sma-em v0.7.x Latest:
SUNNY TRIPOWER 10.0 SE
Soweit ich eben recherchieren konnte, verwendet der SUNNY TRIPOWER 10.0 SE als Energy Meter den "ganz normalen" SHM. (SUSy 372) und hat auch kein eigenes "neues" eingebautes EM. Die SUSy 501 identifiziert den SUNNY TRIPOWER 10.0 SE aber kein neues Energy Meter. Die SUSy 501 wird daher vom SUNNY TRIPOWER 10.0 SE niemals über das SMA-EMETER-protocol-2 gesendet.
sma-em ist nur für die Erfassung der Messdaten von SHM und EM über das SMA-EMETER-protocol-2 ausgelegt und nicht etwa für die Daten der Wechselrichter. Daher ist das Hinzufügen der SUSy 501 im sma-em sinnlos und ich werde die Änderung mit Deiner Zustimmung wieder entfernen.@pdbjjens ich habs eingepflegt weil es SO RUM kommt.. ich hab die Geräte hier..
hab mir den nicht aus der Nase gezogen... kein Plan woher du die Aussagen hast.. wenn die direkt von SMA kommen.. dann vergiss es..
die wissen selber nicht was die da treiben.. setz ein breakpoint an die Stelle und schau selber (oder hast die Geräte nicht )
-
@pdbjjens ich habs eingepflegt weil es SO RUM kommt.. ich hab die Geräte hier..
hab mir den nicht aus der Nase gezogen... kein Plan woher du die Aussagen hast.. wenn die direkt von SMA kommen.. dann vergiss es..
die wissen selber nicht was die da treiben.. setz ein breakpoint an die Stelle und schau selber (oder hast die Geräte nicht )
@arteck said in Test Adapter sma-em v0.7.x Latest:
sondern direkt im Programm
Heißt das, dass in Deiner Konfiguration im Objektbaum von sma-em.X ein "Unkown SMA device S/N: ...." mit SUSy 501 angezeigt wurde?
Ist in Deiner Installation neben dem SUNNY TRIPOWER 10.0 SE ein SHM2.0 verbaut? Welchen Firmwarestand hat der SHM? -
@arteck said in Test Adapter sma-em v0.7.x Latest:
sondern direkt im Programm
Heißt das, dass in Deiner Konfiguration im Objektbaum von sma-em.X ein "Unkown SMA device S/N: ...." mit SUSy 501 angezeigt wurde?
Ist in Deiner Installation neben dem SUNNY TRIPOWER 10.0 SE ein SHM2.0 verbaut? Welchen Firmwarestand hat der SHM?@pdbjjens sagte in Test Adapter sma-em v0.7.x Latest:
Ist in Deiner Installation neben dem SUNNY TRIPOWER 10.0 SE ein SHM2.0 verbaut? Welchen Firmwarestand hat der SHM?
jaha... diese Hardware hab ich HIER..und jaha genaus das ist der Fall "Unkown SMA device S/N: ...." wenn die susy 501 fehlt
was hast du bei dir..da du dich ja so monierst ??
-
@pdbjjens sagte in Test Adapter sma-em v0.7.x Latest:
Ist in Deiner Installation neben dem SUNNY TRIPOWER 10.0 SE ein SHM2.0 verbaut? Welchen Firmwarestand hat der SHM?
jaha... diese Hardware hab ich HIER..und jaha genaus das ist der Fall "Unkown SMA device S/N: ...." wenn die susy 501 fehlt
was hast du bei dir..da du dich ja so monierst ??
@arteck
Mein SHM hat folgende Parameter:
Hardware-Version des Hauptprozessors A1 18.11.2015 08:59:10
Firmware-Version des Hauptprozessors 2.12.7.R 16.07.2023 01:12:40
Firmware-Version des Betriebssystems 4.00.0.R 16.07.2023 01:12:40
Gerätename Home Manager 2 298 10.12.2020 08:35:35
Geräteklasse Kommunikationsprodukte 18.11.2015 08:59:10
Gerätetyp Sunny Home Manager 2.0 18.11.2015 08:59:10
Firmware-Version 2.12.7.R 16.07.2023 01:12:40
Version des Webconnect 1.05.5.R 25.01.2022 23:06:13Wie es aussieht gibt es Unterschiede in der Version des Hauptprozessors und des Betriebssystems. Auch der Gerätename ist geändert. Dein SHM scheint neuer zu sein.
Offenbar hat SMA das zum Anlass genommen, die SUSy des SHM zu ändern. Das war mir bisher entgangen.
Gut, dass Dir das aufgefallen ist. Selbstverständlich lassen wir Deine Änderung drin.
Ich bereite gerade ein neues Release des sma-em vor. Da wird das dann dabei sein. -
Seit dem Updaten auf 0.7.0 habe ich ebenfalls das Problem, dass die Werte
psurplus
pregard
immer genau den halben Wert des tatsächlichen haben.
Aktuell: tatsächlich 8 kW Einspeisung; psurplus zeigt 4 kW an.
Ich habe das Echtzeit-Aktualisierungsintervall bereits versucht anzupassen, das bringt dann allerdings immer nur für eine halbe Sekunde den richtigen Wert und läuft dann wieder mit den halben Werten falsch weiter. -
@tuning
Danke für die Erläuterungen. Ohne dass ich die Funktionsweise des Batteriemanagements der SMA Hybridwechselrichter kenne möchte ich bezweifeln, dass es Dir gelingen könnte auf Basis von ioBroker eine verbesserte Regelung zu entwickeln. ioBroker ist kein Realzeitsystem. Selbst wenn der sma-em Adapter die Datenpunkte mit der Messagerate des SHM oder EM updaten würde, also im Abstand von minimal 200ms, würde es nach meiner Einschätzung sehr schwer möglich sein, daraus Realzeit-Steuerinformationen für die Batterie abzuleiten und zur Batterie weiterzuleiten.Die Bildung von Intervallen im sma-em wurde aufgrund eines Lastproblems eingeführt.
https://github.com/iobroker-community-adapters/ioBroker.sma-em/issues/142
ioBroker kann nur eine begrenzte Anzahl von Events pro Zeiteinheit verarbeiten. Überschreitet ein Adapter diese Anzahl wird er temporär suspendiert um den Rest des Systems nicht zu gefährden.
Daher halte ich es für nicht ratsam, die alten Updatezeiten d.i. 200ms ohne Mittelwertbildung wieder zuzulassen.
Auch meine ich, dass wenn eine Applikation mit Intervallen von 1s auf ioBroker nicht funktioniert, sollte sie auf einem dedizierten System implementiert werden. In Deinem Fall empfehle ich, mal nach speziell für das Energiemanagement ausgelegten Systemen zu schauen.
Hast Du Dir schon mal https://openems.github.io/openems.io/openems/latest/edge/architecture.html angeschaut?
Ergänzung: Ich bin gerade eben auf ein ioBroker Skript gestoßen, was das prognosebasierte Laden von SMA ersetzen soll. Vielleicht hilft Dir das auch.@pdbjjens sagte in Test Adapter sma-em v0.7.x Latest:
@tuning
ioBroker kann nur eine begrenzte Anzahl von Events pro Zeiteinheit verarbeiten. Überschreitet ein Adapter diese Anzahl wird er temporär suspendiert um den Rest des Systems nicht zu gefährden.
Daher halte ich es für nicht ratsam, die alten Updatezeiten d.i. 200ms ohne Mittelwertbildung wieder zuzulassen.Nachvollziehbar, aber eigentlich die Entscheidung des Nutzers.
Bei mir hat der sma 174 Ereignisse... Mein Shelly 1800
Ich würde eine Option zum anhacken vorschlagen für Echtzeitdaten mit dem Vermerk (nicht empfohlen). Die iobroker vm nutzt 12% der ihr zugewiesenen CPU Kapazität
Support us
751
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge