Zendure zenSDK Lokal API, SmartMode, SolarFlow AC 800 Pro 2
-
@jockel_bln
nach ausgiebigen Tests steuere ich meinen Hyper2000 per Blockly im 20 Sekunden Abstand
und einer Hysterese mit 30 Watt. Also Änderungen nur wenn mehr oder weniger 30 Watt anstehen.Den Versuch mit einer Liste und Mittelwert habe ich auch gemacht. Hat für mich keinen Vorteil gebracht. Die Regelung war dann zu träge.
Tagsüber ist mein Zielwert -30 Watt, also einspeisen und Nachts 0 Watt.
Die Lade- und Entladegrenze bestimme ich nach Zellspannung, nicht nach SOC.
So sieht meine Regelung mit diesen Werten aus. War ein Tag mit viel Sonne, wenig Wolken.
-
Mir geht es soweit sehr gut. Und bei dir auch alles in Ordnung?
Ja das ist auch eine Idee mit dem Entladeachutz. Das könnte ich ja auch mit soc triggern. Du machst das ganze ja mit volt. Bin nur noch nicht ganz schlau geworden was du mit deinen internen Variablen da alles abfragst. Ich denke du triggerst auf Volt oder?
Dann müsste ich nur mein ganzes Script umbauen, da ich überall mir soc getrickert habe wann er aufhören soll zu entladen und starten soll. Sollte aber nicht das große Problem sein.@Daniel-8 sagte:
Ja das ist auch eine Idee mit dem Entladeachutz. ... Du machst das ganze ja mit volt. Bin nur noch nicht ganz schlau geworden was du mit deinen internen Variablen da alles abfragst. Ich denke du triggerst auf Volt oder?Blockly-Beispiel für einen Batterie-Entladeschutz (3 Batterien) mit Ruhephase.
Logik steuert den Entladeschutz (batteryLock) basierend auf der niedrigsten Zellspannung (minVol) von 3 Batterien oder/und dem Status socLimit (Wert 2: Entladelimit erreicht).
Einschaltbedingung (batteryLock = true)
Entladeschutz wird aktiv, wenn:- socLimit 2: Discharge limit reached vom System gesetzt wurde.
ODER wenn: - die niedrigste Zellspannung (minVol) irgendeiner Batterie die Sperrspannung batteryLockMinCellVoltage erreicht oder unterschreitet
- und die Batterien aktuell nicht geladen werden.
(Die Bedingung "und Wert vom Objekt ID packStae" !== 1 kann bei Bedarf entfernt werden.
Wird die Bedingung packState !== 1 entfernt, greift der Entladeschutz bei Unterspannung auch während eines aktiven Ladevorgangs.)Ausschaltbedingung (batteryLock = false)
Entladeschutz wird erst wieder freigegeben, wenn:- minVol-Spannungen aller Batterien die Freigabespannung batteryUnlockMinCellVoltage erreicht haben
- und diese Bedingung nach Ablauf der Ruhezeit batteryRecoveryTimeSec (im Beispiel 300 Sek.) weiterhin erfüllt ist.
Blockierung der Freigabe
Sinkt die minVol-Spannung auch nur einer einzigen Batterie (bis die Ruhephase beendet ist) unter batteryUnlockMinCellVoltage, bleibt der Entladeschutz aktiv.
Die Blockierung löst sich erst, wenn alle minVol-Spannungen nach der Ruhephase >= batteryUnlockMinCellVoltage sind.
Blockly:
<xml xmlns="https://developers.google.com/blockly/xml"> <variables> <variable id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</variable> <variable id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</variable> <variable id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</variable> <variable id="xY{w8?Sp~0Jea0SewLzs">batteryLock</variable> <variable id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</variable> <variable id="sP`Q7/BVq;3R/4DW.u.r">batteryRecoveryTimeSec</variable> <variable id="6jV)pWhw1z4,L)/zXmp@">nowSec</variable> </variables> <block type="comment" id="q%5A|9!9VEO/[RIxyyxk" x="-487" y="7288"> <field name="COMMENT">Batterie-EntladeSchutz</field> <next> <block type="variables_set" id="2:Gt3XKhq!Tv%P|FIPHL"> <field name="VAR" id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</field> <value name="VALUE"> <block type="math_number" id="exRP{MzsuzPDK%##_eWf"> <field name="NUM">3.16</field> </block> </value> <next> <block type="variables_set" id="5S-e!(n,h3);}|jBV1o1"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> <value name="VALUE"> <block type="math_number" id="e?Sm3LluJI7G!Wy3ssg8"> <field name="NUM">3.25</field> </block> </value> <next> <block type="variables_set" id="6LJ1}M`-WMN(Mc:9JpAS"> <field name="VAR" id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</field> <value name="VALUE"> <block type="math_number" id="i`KrHC_9AY@Do0oNq5qr"> <field name="NUM">0</field> </block> </value> <next> <block type="variables_set" id="{n`pU`kxEM/P^m_(B}^C"> <field name="VAR" id="xY{w8?Sp~0Jea0SewLzs">batteryLock</field> <value name="VALUE"> <block type="logic_boolean" id="ihR.E7~nU1_7?e7vv_e!"> <field name="BOOL">FALSE</field> </block> </value> <next> <block type="variables_set" id="o]O/6V?.;?LlU%.)p80Y"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> <value name="VALUE"> <block type="math_number" id="it+qm2_0U.N;4qhi|xpn"> <field name="NUM">0</field> </block> </value> <next> <block type="variables_set" id="~Redn5|k~t|9;@8LIg-#"> <field name="VAR" id="sP`Q7/BVq;3R/4DW.u.r">batteryRecoveryTimeSec</field> <value name="VALUE"> <block type="math_number" id="YoM,?ty6Y`uv}XM{b~!?"> <field name="NUM">300</field> </block> </value> <next> <block type="comment" id="DGde)CSQo@lMo!CLi5mz"> <field name="COMMENT">------</field> <next> <block type="comment" id="wktby7iKttVv%Tb|TDb*"> <field name="COMMENT">Trigger auf Zählerwert, &#10;der im 5 sek Intervall aktualisiert wird</field> <next> <block type="on_ext" id="_(9^AZcnK}=,Ei_Kv[LC"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="1"></mutation> <field name="CONDITION">ne</field> <field name="ACK_CONDITION"></field> <value name="OID0"> <shadow type="field_oid" id="Lm`Zdj39dhg+OGr~]zO_"> <field name="oid">ID auswählen</field> </shadow> </value> <statement name="STATEMENT"> <block type="variables_set" id="cr/vPHG5wrI/)s2dFh#O"> <field name="VAR" id="6jV)pWhw1z4,L)/zXmp@">nowSec</field> <value name="VALUE"> <block type="procedures_callcustomreturn" id="G)tyOY[1!o6OfU!_Ca2["> <mutation name="getNowSec"></mutation> </block> </value> <next> <block type="comment" id="K~m7(ghLFmTYDE`MYJ;A"> <field name="COMMENT">Batterie-Entladeschutz</field> <next> <block type="controls_if" id="UZF)Vdt[Ka6uG9uuTY~t"> <value name="IF0"> <block type="logic_multi_or" id="|)s|Y;@N@hJ2-s52mBa5"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="2"></mutation> <value name="OR0"> <block type="logic_compare" id="45G,;?OwD8%h~ldSS8w="> <field name="OP">EQ</field> <value name="A"> <block type="get_value" id="Q[b$!$kp?6{n%Has47[k"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.properties.socLimit</field> </block> </value> <value name="B"> <block type="math_number" id="T:XU,@?lf-r/[QvwJjqh"> <field name="NUM">2</field> </block> </value> </block> </value> <value name="OR1"> <block type="logic_multi_and" id="D9h16~UW5]UXhC//fv3d"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="2"></mutation> <value name="AND0"> <block type="logic_multi_or" id="XVDcsJf=)+p;zDD/-wjf"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="3"></mutation> <value name="OR0"> <block type="logic_compare" id="cw/|eVq~ILYKhKZKYBcT"> <field name="OP">LTE</field> <value name="A"> <block type="get_value" id="/UQ+w-%gCevTP-JZN0ZL"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX1.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="w.Tc[CRU!3PsOIN3I96l"> <field name="VAR" id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</field> </block> </value> </block> </value> <value name="OR1"> <block type="logic_compare" id="6Ek.ijD@y([?LgQtHNWj"> <field name="OP">LTE</field> <value name="A"> <block type="get_value" id="9nI%HL}@-%HkC7!JLDHV"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX2.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="fcy{slPU}X^{,mUQ$~cb"> <field name="VAR" id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</field> </block> </value> </block> </value> <value name="OR2"> <block type="logic_compare" id="bj?!GD(bZG^Mzt1ck{E7"> <field name="OP">LTE</field> <value name="A"> <block type="get_value" id="}=n%TD4gwM/y`O).YYd0"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX3.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="UZYC~yvF_#D(K.R$[uF^"> <field name="VAR" id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</field> </block> </value> </block> </value> </block> </value> <value name="AND1"> <block type="logic_compare" id="*5nHL,zgPP^,t!DE%(`]"> <field name="OP">NEQ</field> <value name="A"> <block type="get_value" id="?U4REz3Eh]R}cZB.rz=d"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.properties.packState</field> </block> </value> <value name="B"> <block type="math_number" id="UvwDD_A8LY|EfJZ,:F@3"> <field name="NUM">1</field> </block> </value> </block> </value> </block> </value> </block> </value> <statement name="DO0"> <block type="variables_set" id="VTf!*(b/CJ-qLxv7lEr%"> <field name="VAR" id="xY{w8?Sp~0Jea0SewLzs">batteryLock</field> <value name="VALUE"> <block type="logic_boolean" id="|AQTUnl~BPG}LM;OSess"> <field name="BOOL">TRUE</field> </block> </value> </block> </statement> <next> <block type="comment" id="R-D?;8wK0j]puzzvPuoB"> <field name="COMMENT">Batterie-Entladeschutz-freigeben</field> <next> <block type="controls_if" id="+dF*{iMDKGY#Qvvy(*zY"> <value name="IF0"> <block type="logic_multi_and" id="p^3K59JHzdibBf;t+U+-"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="6"></mutation> <value name="AND0"> <block type="logic_compare" id="?6%=)T79u``im$;+*Tq^"> <field name="OP">GTE</field> <value name="A"> <block type="get_value" id="iWO4}oEf66q-/Cvc0oQ_"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX1.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="8_PNms`XF9jdQz6@L:mn"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="AND1"> <block type="logic_compare" id="zz*tv82dEU$|~mV3%P9d"> <field name="OP">GTE</field> <value name="A"> <block type="get_value" id=":FA.`M/x%:gTaZPWYVG)"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX2.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="$ssLTQL#Fl%Z*?/{C{b|"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="AND2"> <block type="logic_compare" id="c:*S{CB}Gfi423l/f)kE"> <field name="OP">GTE</field> <value name="A"> <block type="get_value" id="cnz=%3!yKuH}4VCt$?bY"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX3.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="uG+bBCL]gsN@S7_RVDB3"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="AND3"> <block type="logic_compare" id="3nEr+~W9j)kQ^nV+[N?!"> <field name="OP">EQ</field> <value name="A"> <block type="variables_get" id="C8`BTyNs%NAg7kMvlUYm"> <field name="VAR" id="xY{w8?Sp~0Jea0SewLzs">batteryLock</field> </block> </value> <value name="B"> <block type="logic_boolean" id="EJ-sB9syx#_9qvUU42Ok"> <field name="BOOL">TRUE</field> </block> </value> </block> </value> <value name="AND4"> <block type="logic_compare" id="J_^0kKM_$W+*f9UIwiyf"> <field name="OP">EQ</field> <value name="A"> <block type="variables_get" id="-c[Boi^=f_L@o89d%-1+"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> </block> </value> <value name="B"> <block type="math_number" id="b5BNuEF[c)|OA(`I$hzR"> <field name="NUM">0</field> </block> </value> </block> </value> <value name="AND5"> <block type="logic_compare" id="JYHVI=$XZd4yT.5JKa/I"> <field name="OP">NEQ</field> <value name="A"> <block type="get_value" id="M0NaYd_42,lyBW26ph50"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.properties.socLimit</field> </block> </value> <value name="B"> <block type="math_number" id="`YcCAe+4Bo~V+AJ_SFPa"> <field name="NUM">2</field> </block> </value> </block> </value> </block> </value> <statement name="DO0"> <block type="variables_set" id="MppP4%F=t?^QdUdX|zK)"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> <value name="VALUE"> <block type="math_number" id="xTb?%j~?eG%|)~I%~$H;"> <field name="NUM">1</field> </block> </value> <next> <block type="variables_set" id="~y-;{aekR5u=)Lcjcmq7"> <field name="VAR" id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</field> <value name="VALUE"> <block type="variables_get" id="/Pvokl7!J/UxnpNV)RXd"> <field name="VAR" id="6jV)pWhw1z4,L)/zXmp@">nowSec</field> </block> </value> </block> </next> </block> </statement> <next> <block type="controls_if" id="L9+R34gAdvFlQQFvyb[("> <mutation elseif="1"></mutation> <value name="IF0"> <block type="logic_multi_and" id="d8f?pBj$Dhhw:H]:!cx+"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="4"></mutation> <value name="AND0"> <block type="logic_compare" id="~+edNWwk8KDUFrRV@`0u"> <field name="OP">EQ</field> <value name="A"> <block type="variables_get" id=":+*{_E|:-XeEo]FO(Hzw"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> </block> </value> <value name="B"> <block type="math_number" id="e*.V!rE--SqqwdH,]TLj"> <field name="NUM">1</field> </block> </value> </block> </value> <value name="AND1"> <block type="logic_compare" id="O1S7=i|fU1An_ZGvUjN_"> <field name="OP">NEQ</field> <value name="A"> <block type="get_value" id="jpu3K06Q`F#X0CZ.^@vg"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.properties.socLimit</field> </block> </value> <value name="B"> <block type="math_number" id="B{_Iq[gX0]n}6QpaG{4U"> <field name="NUM">2</field> </block> </value> </block> </value> <value name="AND2"> <block type="logic_compare" id="7ke.udnkXtjy~0D#+vpG"> <field name="OP">GTE</field> <value name="A"> <block type="math_arithmetic" id="tgk~6%GON^}e*W)5cyBp"> <field name="OP">MINUS</field> <value name="A"> <shadow type="math_number" id="5JJe0WCM{:gX,j+ZMcW{"> <field name="NUM">1</field> </shadow> <block type="variables_get" id="q~X8Qpdd(wDYVv;YR]+I"> <field name="VAR" id="6jV)pWhw1z4,L)/zXmp@">nowSec</field> </block> </value> <value name="B"> <shadow type="math_number" id="#}t|j-lK_nM;ymfEr{9z"> <field name="NUM">1</field> </shadow> <block type="variables_get" id="Tli~uzyBY4VQ[^#*cv9$"> <field name="VAR" id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</field> </block> </value> </block> </value> <value name="B"> <block type="variables_get" id="SVqkf}0d(8nFzZY%(47:"> <field name="VAR" id="sP`Q7/BVq;3R/4DW.u.r">batteryRecoveryTimeSec</field> </block> </value> </block> </value> <value name="AND3"> <block type="logic_multi_or" id="J@;UdnB}q!)tnRf:yXv*"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="3"></mutation> <value name="OR0"> <block type="logic_compare" id="U:YtHF4peVzU.~#)A+hG"> <field name="OP">LT</field> <value name="A"> <block type="get_value" id="#K.wNl~TMX4}CC]s-,Y%"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX1.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="w6]SU{cLrBFyif%~*Bn3"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="OR1"> <block type="logic_compare" id="haB3_nxso1wmaAY4sy_Q"> <field name="OP">LT</field> <value name="A"> <block type="get_value" id="*l93=O|DLf^p.HfyWj@0"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX2.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="MRk-4KFQ.dlaWRW5u@T_"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="OR2"> <block type="logic_compare" id="J(y~EhV185@jV/}`T3N9"> <field name="OP">LT</field> <value name="A"> <block type="get_value" id="W2FrEZO//03{^s;OEDT|"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX3.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="3q-J9rr)jaD41*zXn[OF"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> </block> </value> </block> </value> <statement name="DO0"> <block type="variables_set" id=";S$}/6P*I?j6ny(S(`iR"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> <value name="VALUE"> <block type="math_number" id="h|;yAP]o_qb23pp9p|yu"> <field name="NUM">0</field> </block> </value> </block> </statement> <value name="IF1"> <block type="logic_multi_and" id="H*62i9g%uL:$:).rK@dJ"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="2"></mutation> <value name="AND0"> <block type="logic_compare" id="Ucu9qyHMv]:bco9l?#hM"> <field name="OP">EQ</field> <value name="A"> <block type="variables_get" id="3YWdK;66aezB[5HNWw}?"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> </block> </value> <value name="B"> <block type="math_number" id="jqHjEZ/9BJ4[}NEV$zy@"> <field name="NUM">1</field> </block> </value> </block> </value> <value name="AND1"> <block type="logic_compare" id="5t^QB+7eR?G]$oVwO5c?"> <field name="OP">GTE</field> <value name="A"> <block type="math_arithmetic" id=";FSTa2:!uguH_zU2;4zw"> <field name="OP">MINUS</field> <value name="A"> <shadow type="math_number" id="5JJe0WCM{:gX,j+ZMcW{"> <field name="NUM">1</field> </shadow> <block type="variables_get" id="Q-0~AIKA4tZ:tC4jj6}t"> <field name="VAR" id="6jV)pWhw1z4,L)/zXmp@">nowSec</field> </block> </value> <value name="B"> <shadow type="math_number" id="#}t|j-lK_nM;ymfEr{9z"> <field name="NUM">1</field> </shadow> <block type="variables_get" id="SrkxeO`G,/gpyE^=}`l%"> <field name="VAR" id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</field> </block> </value> </block> </value> <value name="B"> <block type="variables_get" id="cjZr;!,[V](9`|)`:W-_"> <field name="VAR" id="sP`Q7/BVq;3R/4DW.u.r">batteryRecoveryTimeSec</field> </block> </value> </block> </value> </block> </value> <statement name="DO1"> <block type="variables_set" id="#tjc#5}4O:eLNM.0X%Dp"> <field name="VAR" id="xY{w8?Sp~0Jea0SewLzs">batteryLock</field> <value name="VALUE"> <block type="logic_boolean" id="zLM.lu~5sBG8k@}m.[f2"> <field name="BOOL">FALSE</field> </block> </value> <next> <block type="variables_set" id="*c?l}!|ZKKoGPe#!EEqw"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> <value name="VALUE"> <block type="math_number" id="W(%Wnq=,*LUd^npC:*)~"> <field name="NUM">0</field> </block> </value> </block> </next> </block> </statement> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </statement> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> <block type="procedures_defcustomreturn" id="*[JBn(Fqq9m3!8LlvpAh" x="-87" y="7463"> <mutation statements="false"></mutation> <field name="NAME">getNowSec</field> <field name="SCRIPT">cmV0dXJuIE1hdGguZmxvb3IoRGF0ZS5ub3coKSAvIDEwMDApOw0K</field> <comment pinned="false" h="80" w="160">liefert aktuelle Sekunden</comment> </block> </xml> - socLimit 2: Discharge limit reached vom System gesetzt wurde.
-
@maxclaudi
Jetzt bin ich bisserl neidisch.
Dein Blockly ist so schön strukturiert. Chapeau !
Meins sieht mehr nach Spaghetti aus, du weist was ich meine. 🤪 -
@Daniel-8 sagte:
Ja das ist auch eine Idee mit dem Entladeachutz. ... Du machst das ganze ja mit volt. Bin nur noch nicht ganz schlau geworden was du mit deinen internen Variablen da alles abfragst. Ich denke du triggerst auf Volt oder?Blockly-Beispiel für einen Batterie-Entladeschutz (3 Batterien) mit Ruhephase.
Logik steuert den Entladeschutz (batteryLock) basierend auf der niedrigsten Zellspannung (minVol) von 3 Batterien oder/und dem Status socLimit (Wert 2: Entladelimit erreicht).
Einschaltbedingung (batteryLock = true)
Entladeschutz wird aktiv, wenn:- socLimit 2: Discharge limit reached vom System gesetzt wurde.
ODER wenn: - die niedrigste Zellspannung (minVol) irgendeiner Batterie die Sperrspannung batteryLockMinCellVoltage erreicht oder unterschreitet
- und die Batterien aktuell nicht geladen werden.
(Die Bedingung "und Wert vom Objekt ID packStae" !== 1 kann bei Bedarf entfernt werden.
Wird die Bedingung packState !== 1 entfernt, greift der Entladeschutz bei Unterspannung auch während eines aktiven Ladevorgangs.)Ausschaltbedingung (batteryLock = false)
Entladeschutz wird erst wieder freigegeben, wenn:- minVol-Spannungen aller Batterien die Freigabespannung batteryUnlockMinCellVoltage erreicht haben
- und diese Bedingung nach Ablauf der Ruhezeit batteryRecoveryTimeSec (im Beispiel 300 Sek.) weiterhin erfüllt ist.
Blockierung der Freigabe
Sinkt die minVol-Spannung auch nur einer einzigen Batterie (bis die Ruhephase beendet ist) unter batteryUnlockMinCellVoltage, bleibt der Entladeschutz aktiv.
Die Blockierung löst sich erst, wenn alle minVol-Spannungen nach der Ruhephase >= batteryUnlockMinCellVoltage sind.Blockly:
<xml xmlns="https://developers.google.com/blockly/xml"> <variables> <variable id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</variable> <variable id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</variable> <variable id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</variable> <variable id="xY{w8?Sp~0Jea0SewLzs">batteryLock</variable> <variable id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</variable> <variable id="sP`Q7/BVq;3R/4DW.u.r">batteryRecoveryTimeSec</variable> <variable id="6jV)pWhw1z4,L)/zXmp@">nowSec</variable> </variables> <block type="comment" id="q%5A|9!9VEO/[RIxyyxk" x="-487" y="7288"> <field name="COMMENT">Batterie-EntladeSchutz</field> <next> <block type="variables_set" id="2:Gt3XKhq!Tv%P|FIPHL"> <field name="VAR" id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</field> <value name="VALUE"> <block type="math_number" id="exRP{MzsuzPDK%##_eWf"> <field name="NUM">3.16</field> </block> </value> <next> <block type="variables_set" id="5S-e!(n,h3);}|jBV1o1"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> <value name="VALUE"> <block type="math_number" id="e?Sm3LluJI7G!Wy3ssg8"> <field name="NUM">3.25</field> </block> </value> <next> <block type="variables_set" id="6LJ1}M`-WMN(Mc:9JpAS"> <field name="VAR" id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</field> <value name="VALUE"> <block type="math_number" id="i`KrHC_9AY@Do0oNq5qr"> <field name="NUM">0</field> </block> </value> <next> <block type="variables_set" id="{n`pU`kxEM/P^m_(B}^C"> <field name="VAR" id="xY{w8?Sp~0Jea0SewLzs">batteryLock</field> <value name="VALUE"> <block type="logic_boolean" id="ihR.E7~nU1_7?e7vv_e!"> <field name="BOOL">FALSE</field> </block> </value> <next> <block type="variables_set" id="o]O/6V?.;?LlU%.)p80Y"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> <value name="VALUE"> <block type="math_number" id="it+qm2_0U.N;4qhi|xpn"> <field name="NUM">0</field> </block> </value> <next> <block type="variables_set" id="~Redn5|k~t|9;@8LIg-#"> <field name="VAR" id="sP`Q7/BVq;3R/4DW.u.r">batteryRecoveryTimeSec</field> <value name="VALUE"> <block type="math_number" id="YoM,?ty6Y`uv}XM{b~!?"> <field name="NUM">300</field> </block> </value> <next> <block type="comment" id="DGde)CSQo@lMo!CLi5mz"> <field name="COMMENT">------</field> <next> <block type="comment" id="wktby7iKttVv%Tb|TDb*"> <field name="COMMENT">Trigger auf Zählerwert, &#10;der im 5 sek Intervall aktualisiert wird</field> <next> <block type="on_ext" id="_(9^AZcnK}=,Ei_Kv[LC"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="1"></mutation> <field name="CONDITION">ne</field> <field name="ACK_CONDITION"></field> <value name="OID0"> <shadow type="field_oid" id="Lm`Zdj39dhg+OGr~]zO_"> <field name="oid">ID auswählen</field> </shadow> </value> <statement name="STATEMENT"> <block type="variables_set" id="cr/vPHG5wrI/)s2dFh#O"> <field name="VAR" id="6jV)pWhw1z4,L)/zXmp@">nowSec</field> <value name="VALUE"> <block type="procedures_callcustomreturn" id="G)tyOY[1!o6OfU!_Ca2["> <mutation name="getNowSec"></mutation> </block> </value> <next> <block type="comment" id="K~m7(ghLFmTYDE`MYJ;A"> <field name="COMMENT">Batterie-Entladeschutz</field> <next> <block type="controls_if" id="UZF)Vdt[Ka6uG9uuTY~t"> <value name="IF0"> <block type="logic_multi_or" id="|)s|Y;@N@hJ2-s52mBa5"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="2"></mutation> <value name="OR0"> <block type="logic_compare" id="45G,;?OwD8%h~ldSS8w="> <field name="OP">EQ</field> <value name="A"> <block type="get_value" id="Q[b$!$kp?6{n%Has47[k"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.properties.socLimit</field> </block> </value> <value name="B"> <block type="math_number" id="T:XU,@?lf-r/[QvwJjqh"> <field name="NUM">2</field> </block> </value> </block> </value> <value name="OR1"> <block type="logic_multi_and" id="D9h16~UW5]UXhC//fv3d"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="2"></mutation> <value name="AND0"> <block type="logic_multi_or" id="XVDcsJf=)+p;zDD/-wjf"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="3"></mutation> <value name="OR0"> <block type="logic_compare" id="cw/|eVq~ILYKhKZKYBcT"> <field name="OP">LTE</field> <value name="A"> <block type="get_value" id="/UQ+w-%gCevTP-JZN0ZL"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX1.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="w.Tc[CRU!3PsOIN3I96l"> <field name="VAR" id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</field> </block> </value> </block> </value> <value name="OR1"> <block type="logic_compare" id="6Ek.ijD@y([?LgQtHNWj"> <field name="OP">LTE</field> <value name="A"> <block type="get_value" id="9nI%HL}@-%HkC7!JLDHV"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX2.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="fcy{slPU}X^{,mUQ$~cb"> <field name="VAR" id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</field> </block> </value> </block> </value> <value name="OR2"> <block type="logic_compare" id="bj?!GD(bZG^Mzt1ck{E7"> <field name="OP">LTE</field> <value name="A"> <block type="get_value" id="}=n%TD4gwM/y`O).YYd0"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX3.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="UZYC~yvF_#D(K.R$[uF^"> <field name="VAR" id="|jA}O24Zru$2XpwXW9oM">batteryLockMinCellVoltage</field> </block> </value> </block> </value> </block> </value> <value name="AND1"> <block type="logic_compare" id="*5nHL,zgPP^,t!DE%(`]"> <field name="OP">NEQ</field> <value name="A"> <block type="get_value" id="?U4REz3Eh]R}cZB.rz=d"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.properties.packState</field> </block> </value> <value name="B"> <block type="math_number" id="UvwDD_A8LY|EfJZ,:F@3"> <field name="NUM">1</field> </block> </value> </block> </value> </block> </value> </block> </value> <statement name="DO0"> <block type="variables_set" id="VTf!*(b/CJ-qLxv7lEr%"> <field name="VAR" id="xY{w8?Sp~0Jea0SewLzs">batteryLock</field> <value name="VALUE"> <block type="logic_boolean" id="|AQTUnl~BPG}LM;OSess"> <field name="BOOL">TRUE</field> </block> </value> </block> </statement> <next> <block type="comment" id="R-D?;8wK0j]puzzvPuoB"> <field name="COMMENT">Batterie-Entladeschutz-freigeben</field> <next> <block type="controls_if" id="+dF*{iMDKGY#Qvvy(*zY"> <value name="IF0"> <block type="logic_multi_and" id="p^3K59JHzdibBf;t+U+-"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="6"></mutation> <value name="AND0"> <block type="logic_compare" id="?6%=)T79u``im$;+*Tq^"> <field name="OP">GTE</field> <value name="A"> <block type="get_value" id="iWO4}oEf66q-/Cvc0oQ_"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX1.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="8_PNms`XF9jdQz6@L:mn"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="AND1"> <block type="logic_compare" id="zz*tv82dEU$|~mV3%P9d"> <field name="OP">GTE</field> <value name="A"> <block type="get_value" id=":FA.`M/x%:gTaZPWYVG)"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX2.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="$ssLTQL#Fl%Z*?/{C{b|"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="AND2"> <block type="logic_compare" id="c:*S{CB}Gfi423l/f)kE"> <field name="OP">GTE</field> <value name="A"> <block type="get_value" id="cnz=%3!yKuH}4VCt$?bY"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX3.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="uG+bBCL]gsN@S7_RVDB3"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="AND3"> <block type="logic_compare" id="3nEr+~W9j)kQ^nV+[N?!"> <field name="OP">EQ</field> <value name="A"> <block type="variables_get" id="C8`BTyNs%NAg7kMvlUYm"> <field name="VAR" id="xY{w8?Sp~0Jea0SewLzs">batteryLock</field> </block> </value> <value name="B"> <block type="logic_boolean" id="EJ-sB9syx#_9qvUU42Ok"> <field name="BOOL">TRUE</field> </block> </value> </block> </value> <value name="AND4"> <block type="logic_compare" id="J_^0kKM_$W+*f9UIwiyf"> <field name="OP">EQ</field> <value name="A"> <block type="variables_get" id="-c[Boi^=f_L@o89d%-1+"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> </block> </value> <value name="B"> <block type="math_number" id="b5BNuEF[c)|OA(`I$hzR"> <field name="NUM">0</field> </block> </value> </block> </value> <value name="AND5"> <block type="logic_compare" id="JYHVI=$XZd4yT.5JKa/I"> <field name="OP">NEQ</field> <value name="A"> <block type="get_value" id="M0NaYd_42,lyBW26ph50"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.properties.socLimit</field> </block> </value> <value name="B"> <block type="math_number" id="`YcCAe+4Bo~V+AJ_SFPa"> <field name="NUM">2</field> </block> </value> </block> </value> </block> </value> <statement name="DO0"> <block type="variables_set" id="MppP4%F=t?^QdUdX|zK)"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> <value name="VALUE"> <block type="math_number" id="xTb?%j~?eG%|)~I%~$H;"> <field name="NUM">1</field> </block> </value> <next> <block type="variables_set" id="~y-;{aekR5u=)Lcjcmq7"> <field name="VAR" id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</field> <value name="VALUE"> <block type="variables_get" id="/Pvokl7!J/UxnpNV)RXd"> <field name="VAR" id="6jV)pWhw1z4,L)/zXmp@">nowSec</field> </block> </value> </block> </next> </block> </statement> <next> <block type="controls_if" id="L9+R34gAdvFlQQFvyb[("> <mutation elseif="1"></mutation> <value name="IF0"> <block type="logic_multi_and" id="d8f?pBj$Dhhw:H]:!cx+"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="4"></mutation> <value name="AND0"> <block type="logic_compare" id="~+edNWwk8KDUFrRV@`0u"> <field name="OP">EQ</field> <value name="A"> <block type="variables_get" id=":+*{_E|:-XeEo]FO(Hzw"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> </block> </value> <value name="B"> <block type="math_number" id="e*.V!rE--SqqwdH,]TLj"> <field name="NUM">1</field> </block> </value> </block> </value> <value name="AND1"> <block type="logic_compare" id="O1S7=i|fU1An_ZGvUjN_"> <field name="OP">NEQ</field> <value name="A"> <block type="get_value" id="jpu3K06Q`F#X0CZ.^@vg"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.properties.socLimit</field> </block> </value> <value name="B"> <block type="math_number" id="B{_Iq[gX0]n}6QpaG{4U"> <field name="NUM">2</field> </block> </value> </block> </value> <value name="AND2"> <block type="logic_compare" id="7ke.udnkXtjy~0D#+vpG"> <field name="OP">GTE</field> <value name="A"> <block type="math_arithmetic" id="tgk~6%GON^}e*W)5cyBp"> <field name="OP">MINUS</field> <value name="A"> <shadow type="math_number" id="5JJe0WCM{:gX,j+ZMcW{"> <field name="NUM">1</field> </shadow> <block type="variables_get" id="q~X8Qpdd(wDYVv;YR]+I"> <field name="VAR" id="6jV)pWhw1z4,L)/zXmp@">nowSec</field> </block> </value> <value name="B"> <shadow type="math_number" id="#}t|j-lK_nM;ymfEr{9z"> <field name="NUM">1</field> </shadow> <block type="variables_get" id="Tli~uzyBY4VQ[^#*cv9$"> <field name="VAR" id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</field> </block> </value> </block> </value> <value name="B"> <block type="variables_get" id="SVqkf}0d(8nFzZY%(47:"> <field name="VAR" id="sP`Q7/BVq;3R/4DW.u.r">batteryRecoveryTimeSec</field> </block> </value> </block> </value> <value name="AND3"> <block type="logic_multi_or" id="J@;UdnB}q!)tnRf:yXv*"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="3"></mutation> <value name="OR0"> <block type="logic_compare" id="U:YtHF4peVzU.~#)A+hG"> <field name="OP">LT</field> <value name="A"> <block type="get_value" id="#K.wNl~TMX4}CC]s-,Y%"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX1.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="w6]SU{cLrBFyif%~*Bn3"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="OR1"> <block type="logic_compare" id="haB3_nxso1wmaAY4sy_Q"> <field name="OP">LT</field> <value name="A"> <block type="get_value" id="*l93=O|DLf^p.HfyWj@0"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX2.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="MRk-4KFQ.dlaWRW5u@T_"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> <value name="OR2"> <block type="logic_compare" id="J(y~EhV185@jV/}`T3N9"> <field name="OP">LT</field> <value name="A"> <block type="get_value" id="W2FrEZO//03{^s;OEDT|"> <field name="ATTR">val</field> <field name="OID">0_userdata.0.zendure.1600ACplus.packData.CXXXXXXXXXXXXX3.minVol</field> </block> </value> <value name="B"> <block type="variables_get" id="3q-J9rr)jaD41*zXn[OF"> <field name="VAR" id="GVuE})ec/#[QQ!56ZE6s">batteryUnlockMinCellVoltage</field> </block> </value> </block> </value> </block> </value> </block> </value> <statement name="DO0"> <block type="variables_set" id=";S$}/6P*I?j6ny(S(`iR"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> <value name="VALUE"> <block type="math_number" id="h|;yAP]o_qb23pp9p|yu"> <field name="NUM">0</field> </block> </value> </block> </statement> <value name="IF1"> <block type="logic_multi_and" id="H*62i9g%uL:$:).rK@dJ"> <mutation xmlns="http://www.w3.org/1999/xhtml" items="2"></mutation> <value name="AND0"> <block type="logic_compare" id="Ucu9qyHMv]:bco9l?#hM"> <field name="OP">EQ</field> <value name="A"> <block type="variables_get" id="3YWdK;66aezB[5HNWw}?"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> </block> </value> <value name="B"> <block type="math_number" id="jqHjEZ/9BJ4[}NEV$zy@"> <field name="NUM">1</field> </block> </value> </block> </value> <value name="AND1"> <block type="logic_compare" id="5t^QB+7eR?G]$oVwO5c?"> <field name="OP">GTE</field> <value name="A"> <block type="math_arithmetic" id=";FSTa2:!uguH_zU2;4zw"> <field name="OP">MINUS</field> <value name="A"> <shadow type="math_number" id="5JJe0WCM{:gX,j+ZMcW{"> <field name="NUM">1</field> </shadow> <block type="variables_get" id="Q-0~AIKA4tZ:tC4jj6}t"> <field name="VAR" id="6jV)pWhw1z4,L)/zXmp@">nowSec</field> </block> </value> <value name="B"> <shadow type="math_number" id="#}t|j-lK_nM;ymfEr{9z"> <field name="NUM">1</field> </shadow> <block type="variables_get" id="SrkxeO`G,/gpyE^=}`l%"> <field name="VAR" id="@Atp40732e@i1#ciD6Vf">batteryRecoveryStartSec</field> </block> </value> </block> </value> <value name="B"> <block type="variables_get" id="cjZr;!,[V](9`|)`:W-_"> <field name="VAR" id="sP`Q7/BVq;3R/4DW.u.r">batteryRecoveryTimeSec</field> </block> </value> </block> </value> </block> </value> <statement name="DO1"> <block type="variables_set" id="#tjc#5}4O:eLNM.0X%Dp"> <field name="VAR" id="xY{w8?Sp~0Jea0SewLzs">batteryLock</field> <value name="VALUE"> <block type="logic_boolean" id="zLM.lu~5sBG8k@}m.[f2"> <field name="BOOL">FALSE</field> </block> </value> <next> <block type="variables_set" id="*c?l}!|ZKKoGPe#!EEqw"> <field name="VAR" id="]@mNu993N=|~3.$l@Acs">batteryRecoveryPending</field> <value name="VALUE"> <block type="math_number" id="W(%Wnq=,*LUd^npC:*)~"> <field name="NUM">0</field> </block> </value> </block> </next> </block> </statement> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </statement> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> </next> </block> <block type="procedures_defcustomreturn" id="*[JBn(Fqq9m3!8LlvpAh" x="-87" y="7463"> <mutation statements="false"></mutation> <field name="NAME">getNowSec</field> <field name="SCRIPT">cmV0dXJuIE1hdGguZmxvb3IoRGF0ZS5ub3coKSAvIDEwMDApOw0K</field> <comment pinned="false" h="80" w="160">liefert aktuelle Sekunden</comment> </block> </xml>@maxclaudi [sagte]: socLimit 2: Discharge limit reached vom System gesetzt wurde.
Wird dann nicht das Entladen automatisch durch die Firmware beendet?
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU) - socLimit 2: Discharge limit reached vom System gesetzt wurde.
-
@maxclaudi [sagte]: socLimit 2: Discharge limit reached vom System gesetzt wurde.
Wird dann nicht das Entladen automatisch durch die Firmware beendet?
@maxclaudi [sagte]: socLimit 2: Discharge limit reached vom System gesetzt wurde.
Wird dann nicht das Entladen automatisch durch die Firmware beendet?
natürlich, aber deswegen ist die Variable batteryLock nicht auf true. socLimit könnte früher den BatterieEntladeschutz wieder freigeben, je nachdem welche Volt Du angegeben hast. Und das möchte man ja nicht.
Zusätzlich ist das eine Absicherung durch Messwerte und man muss nicht allein auf socLimit vertrauen ;-) -
@maxclaudi
Jetzt bin ich bisserl neidisch.
Dein Blockly ist so schön strukturiert. Chapeau !
Meins sieht mehr nach Spaghetti aus, du weist was ich meine. 🤪 -
Blockly - Einfache DPL Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads
Dazu wird der dp auto_in_out_Limit verwendet.
Dieses Blockly bietet eine einfache und robuste DPL-Regelung mit integriertem Batterie-Entladeschutz, die vorhandenen PV-Überschuss intelligent zum Laden der Batterien verwendet.
-
Keine blockierenden Timer oder Timeouts:
Die zeitliche Entprellung (Regeltakt) wird rein ressourcenschonend über den Vergleich der Systemzeit gelöst. -
Hardware-Schonung:
Integrierte Hysterese (30W voreingetellt in Variable, leicht anpassbar) sowie feste Rundungsschritte (10W beim Entladen / 50W beim AC-Laden) verhindern Zappeln der Leistungselektronik und minimieren den Bus-Traffic. -
BMS- & PV-Priorisierung:
reine Geräteleistungen werden mit dem Zähler verrechnet, sodass das System auch bei BMS-Abregelung (SoC > 95%) stabil bleibt.
Das Blockly ist im Inneren ausführlich kommentiert, weshalb ich mir eine lange Erklärung erspare.
Wichtige Hinweise zum Setup:
-
Konfiguration:
Alle Variablen im Konfigurations-Bereich (oberhalb des Triggers) dürfen NUR als positive Werte eingetragen werden!
Die Vorzeichen-Umkehrung übernimmt das Skript automatisch. -
Trigger-Wert:
Der Trigger erwartet positive Werte als Bezug und negative Werte als Einspeisung.
Sollte auf ein json getriggert werden, muss das json in ein Objekt übergeben werden.
Ein Beispiel dazu (für z.B. einen Shelly Pro 3EM) ist HIER -
Erweiterter Entladeschutz:
sollte lieber auf Basis von echten Messwerten erfolgen.
Dazu empfehle ich das Blockly von HIER
Es kann einfach per Import angepasst und integriert werden.
edit/Nachtrag Hinweis:
Verhalten in der Dämmerung (Tote Zone):
Wundert euch nicht, wenn das LOG beim Übergang vom Tag zur Nacht (Überschuss zwischen 0W und -120W) einige Zeit still bleibt und nichts loggt.
Das ist gewollt!
In diesem Bereich berechnet das Skript im Hintergrund ein Limit von 0.
Sobald es richtig dunkel wird und/oder euer Haus echten Netzbezug anfordert, wirft das Script die positiven Logs für die Entladung.
Die "debug output"-Blöcke sind ohnehin nur zum ersten Testen und können/sollten von euch im Live-Betrieb gelöscht werden.Bitte Urheber im Skript beachten. Viel Spaß damit!
Im nächsten post folgt der Blockly-Code.
-
-
Blockly - Einfache DPL Regelung (Nulleinspeisung & AC-Laden) für Einsteiger in Verbindung mit dem Steuerungs-Script dieses Threads
Dazu wird der dp auto_in_out_Limit verwendet.
Dieses Blockly bietet eine einfache und robuste DPL-Regelung mit integriertem Batterie-Entladeschutz, die vorhandenen PV-Überschuss intelligent zum Laden der Batterien verwendet.
-
Keine blockierenden Timer oder Timeouts:
Die zeitliche Entprellung (Regeltakt) wird rein ressourcenschonend über den Vergleich der Systemzeit gelöst. -
Hardware-Schonung:
Integrierte Hysterese (30W voreingetellt in Variable, leicht anpassbar) sowie feste Rundungsschritte (10W beim Entladen / 50W beim AC-Laden) verhindern Zappeln der Leistungselektronik und minimieren den Bus-Traffic. -
BMS- & PV-Priorisierung:
reine Geräteleistungen werden mit dem Zähler verrechnet, sodass das System auch bei BMS-Abregelung (SoC > 95%) stabil bleibt.
Das Blockly ist im Inneren ausführlich kommentiert, weshalb ich mir eine lange Erklärung erspare.
Wichtige Hinweise zum Setup:
-
Konfiguration:
Alle Variablen im Konfigurations-Bereich (oberhalb des Triggers) dürfen NUR als positive Werte eingetragen werden!
Die Vorzeichen-Umkehrung übernimmt das Skript automatisch. -
Trigger-Wert:
Der Trigger erwartet positive Werte als Bezug und negative Werte als Einspeisung.
Sollte auf ein json getriggert werden, muss das json in ein Objekt übergeben werden.
Ein Beispiel dazu (für z.B. einen Shelly Pro 3EM) ist HIER -
Erweiterter Entladeschutz:
sollte lieber auf Basis von echten Messwerten erfolgen.
Dazu empfehle ich das Blockly von HIER
Es kann einfach per Import angepasst und integriert werden.
edit/Nachtrag Hinweis:
Verhalten in der Dämmerung (Tote Zone):
Wundert euch nicht, wenn das LOG beim Übergang vom Tag zur Nacht (Überschuss zwischen 0W und -120W) einige Zeit still bleibt und nichts loggt.
Das ist gewollt!
In diesem Bereich berechnet das Skript im Hintergrund ein Limit von 0.
Sobald es richtig dunkel wird und/oder euer Haus echten Netzbezug anfordert, wirft das Script die positiven Logs für die Entladung.
Die "debug output"-Blöcke sind ohnehin nur zum ersten Testen und können/sollten von euch im Live-Betrieb gelöscht werden.Bitte Urheber im Skript beachten. Viel Spaß damit!
Im nächsten post folgt der Blockly-Code.
Blockly von Post
Das Blockly musste als Datei hinzugefügt werden, weil es zu groß ist
Datei: zenSDK_DPL_BLOCKLY.zip enthält nur zenSDK_DPL_BLOCKLY.xml
- Datei herunterladen und Virenscan.
- zenSDK_DPL_BLOCKLY.zip entpacken
- in iobroker neues, leeres Blockly erstellen
- zenSDK_DPL_BLOCKLY.xml
importieren:
Bitte den Urheber im Skript beachten.
Falls es Dir hilft oder Du Dich bedanken möchtest: Ein positives Voting als Dankeschön ist völlig ausreichend :-)
download:
zenSDK_DPL_BLOCKLY.zip
edit/ps:
so sieht es aus, wenn Batterie-Entladeschutz auf Messwerten basierend aus post nachträglich intergriert wurde:
-
-
Blockly von Post
Das Blockly musste als Datei hinzugefügt werden, weil es zu groß ist
Datei: zenSDK_DPL_BLOCKLY.zip enthält nur zenSDK_DPL_BLOCKLY.xml
- Datei herunterladen und Virenscan.
- zenSDK_DPL_BLOCKLY.zip entpacken
- in iobroker neues, leeres Blockly erstellen
- zenSDK_DPL_BLOCKLY.xml
importieren:
Bitte den Urheber im Skript beachten.
Falls es Dir hilft oder Du Dich bedanken möchtest: Ein positives Voting als Dankeschön ist völlig ausreichend :-)
download:
zenSDK_DPL_BLOCKLY.zip
edit/ps:
so sieht es aus, wenn Batterie-Entladeschutz auf Messwerten basierend aus post nachträglich intergriert wurde:@maxclaudi Wow, da hast du ja ordentlich was erstellt - danke fürs Teilen
Mir ist da etwas bezüglich smartMode aufgefallen.
Am Wochenende wollte ich meinen IR Lesekopf etwas nachjustieren, da ist plötzlich das komplette Gehäuse zerbröselt und er damit unbenutzbar geworden.
Ich also zum Baumarkt und habe mir als schnellen Ersatz nen EcoTracker besorgt. Da ich ein neugieriger Mensch bin habe ich ihn natürlich in der Zendure App gekoppelt und den Speicher im Eigenverbrauchsmodus laufen lassen.Dabei habe ich folgendes beobachtet: Speicher und Tracker kommunizieren nach der Kopplung (via Cloud) lokal und die Regelung funktioniert gut und sehr schnell. Allerdings wechselt der Wert von smartMode je nach dem was gerade für ein acMode aktiv ist. Bei acMode 1 (laden) springt der smartMode auf 0 und umgekehrt. Gerade morgens und abends geschieht das natürlich ständig im Wechsel.
Es läuft nebenher kein weiteres Skript, auch deins nicht, ich frage die Werte nur per http get vom Speicher ab.Wenn das wirklich so designt ist, wird bei smartMode=0 wirklich alles in den Flash geschrieben? Immerhin wechselt inputLimit am Tage ständig in kurzen Intervallen.
Da Zendure 10 Jahre Garantie auf die Geräte gibt, sollten sie das doch so konstruiert haben, dass der Flash bei der internen Steuerung diese Zeit überlebt.Das wollte ich nur mal so berichten, jetzt gucke ich mir dein Skript an - ganz schön viel Stoff für einen alten Mann
-
@maxclaudi Wow, da hast du ja ordentlich was erstellt - danke fürs Teilen
Mir ist da etwas bezüglich smartMode aufgefallen.
Am Wochenende wollte ich meinen IR Lesekopf etwas nachjustieren, da ist plötzlich das komplette Gehäuse zerbröselt und er damit unbenutzbar geworden.
Ich also zum Baumarkt und habe mir als schnellen Ersatz nen EcoTracker besorgt. Da ich ein neugieriger Mensch bin habe ich ihn natürlich in der Zendure App gekoppelt und den Speicher im Eigenverbrauchsmodus laufen lassen.Dabei habe ich folgendes beobachtet: Speicher und Tracker kommunizieren nach der Kopplung (via Cloud) lokal und die Regelung funktioniert gut und sehr schnell. Allerdings wechselt der Wert von smartMode je nach dem was gerade für ein acMode aktiv ist. Bei acMode 1 (laden) springt der smartMode auf 0 und umgekehrt. Gerade morgens und abends geschieht das natürlich ständig im Wechsel.
Es läuft nebenher kein weiteres Skript, auch deins nicht, ich frage die Werte nur per http get vom Speicher ab.Wenn das wirklich so designt ist, wird bei smartMode=0 wirklich alles in den Flash geschrieben? Immerhin wechselt inputLimit am Tage ständig in kurzen Intervallen.
Da Zendure 10 Jahre Garantie auf die Geräte gibt, sollten sie das doch so konstruiert haben, dass der Flash bei der internen Steuerung diese Zeit überlebt.Das wollte ich nur mal so berichten, jetzt gucke ich mir dein Skript an - ganz schön viel Stoff für einen alten Mann
Hallo @Jockel_Bln,
zu deiner Sorge bezüglich des Flash-Speichers:
Jeder moderne Hersteller setzt bei Steuerungsgeräten heute auf Flash-Komponenten mit sogenanntem Wear-Leveling.
Dieses Verfahren sorgt dafür, dass Schreibvorgänge gleichmäßig über den gesamten Speicher (Blöcke) verteilt werden, um die Lebensdauer der Zellen drastisch zu erhöhen.Wenn Zendure hier die üblichen Industriestandards nutzt, sollte die Lebensdauer für den "normalen" Betrieb ausreichend ausgelegt sein.
Allerdings altern Flash-Speicher bei übermäßig vielen Schreibzyklen unweigerlich.
Wenn Speicherbereiche degradieren, zeigt sich das meistens nicht durch einen Totalausfall, sondern durch sporadische, schwer zu diagnostizierende Fehler im System.Meine goldene Regel für Skripte:
Man sollte es trotz Wear-Leveling einfach nicht übertreiben.Genau aus diesem Grund nutzt mein Beispiel-Blockly die Hysterese und eine Zeitsperre.
Alle wichtigen Werte dafür sind in den Variablen auf die eigenen Bedürfnisse und das eigene Setup einstellbar.Werte sollten niemals im Sekunden- oder Minutentakt unfiltriert oder in Dauerschleifen zum Zendure-System gesendet werden.
Solange man das beachtet und dem System "Ruhepausen" gönnt, ist man – denke ich – auf der sicheren Seite.Viel Spaß beim Einlesen in das Skript – nimm Dir ruhig Zeit, es läuft Dir nicht weg! :-)
-
Hallo @Jockel_Bln,
zu deiner Sorge bezüglich des Flash-Speichers:
Jeder moderne Hersteller setzt bei Steuerungsgeräten heute auf Flash-Komponenten mit sogenanntem Wear-Leveling.
Dieses Verfahren sorgt dafür, dass Schreibvorgänge gleichmäßig über den gesamten Speicher (Blöcke) verteilt werden, um die Lebensdauer der Zellen drastisch zu erhöhen.Wenn Zendure hier die üblichen Industriestandards nutzt, sollte die Lebensdauer für den "normalen" Betrieb ausreichend ausgelegt sein.
Allerdings altern Flash-Speicher bei übermäßig vielen Schreibzyklen unweigerlich.
Wenn Speicherbereiche degradieren, zeigt sich das meistens nicht durch einen Totalausfall, sondern durch sporadische, schwer zu diagnostizierende Fehler im System.Meine goldene Regel für Skripte:
Man sollte es trotz Wear-Leveling einfach nicht übertreiben.Genau aus diesem Grund nutzt mein Beispiel-Blockly die Hysterese und eine Zeitsperre.
Alle wichtigen Werte dafür sind in den Variablen auf die eigenen Bedürfnisse und das eigene Setup einstellbar.Werte sollten niemals im Sekunden- oder Minutentakt unfiltriert oder in Dauerschleifen zum Zendure-System gesendet werden.
Solange man das beachtet und dem System "Ruhepausen" gönnt, ist man – denke ich – auf der sicheren Seite.Viel Spaß beim Einlesen in das Skript – nimm Dir ruhig Zeit, es läuft Dir nicht weg! :-)
Werte sollten niemals im Sekunden- oder Minutentakt unfiltriert oder in Dauerschleifen zum Zendure-System gesendet werden.
Solange man das beachtet und dem System "Ruhepausen" gönnt, ist man – denke ich – auf der sicheren Seite.Das sehe ich ganz genau so und das lässt sich ja per externer Regelung so umsetzen.
Um so mehr wundert es mich, dass es bei der internen Regelung eben nicht so läuft. Entweder läuft da etwas anders als von extern, oder sie fahren werkseitig auf Verschleiß
-
Werte sollten niemals im Sekunden- oder Minutentakt unfiltriert oder in Dauerschleifen zum Zendure-System gesendet werden.
Solange man das beachtet und dem System "Ruhepausen" gönnt, ist man – denke ich – auf der sicheren Seite.Das sehe ich ganz genau so und das lässt sich ja per externer Regelung so umsetzen.
Um so mehr wundert es mich, dass es bei der internen Regelung eben nicht so läuft. Entweder läuft da etwas anders als von extern, oder sie fahren werkseitig auf Verschleiß@Jockel_Bln,
es kommt vermutlich ganz darauf an, wie lange man ein System heute überhaupt noch nutzen möchte.Ich lese in den Foren immer wieder von Amortisierung in X Jahren.
Die Leute kaufen ein Gerät und erwarten voller Vorfreude ein System, das sich nach kürzester Zeit bezahlt gemacht haben soll.
Dabei werden dann Zeiträume von mehreren Jahren oft als „kurze Zeit“ abgetan.Am Anfang ist man dann mehr oder weniger zufrieden.
Doch nach einigen Monaten oder ein, zwei Jahren ist das System zwar noch lange nicht amortisiert, aber es gibt bereits neuere, bessere Geräte mit noch mehr Software-Features.
Die älteren Generationen profitieren davon meist gar nicht oder nur bedingt.Ich habe – nicht nur im näheren Bekanntenkreis – beobachtet, dass viele Nutzer dann vom „Mehr-haben-wollen“-Fieber gepackt werden, ähnlich einem kleinen Goldrausch.
Vorbei sind die anfänglichen Berechnungen und das geduldige Abwarten der Amortisation.
Das eigene, eigentlich tadellos funktionierende System wird plötzlich als „altes Eisen“ degradiert.Kurzerhand wird ein Gerät, das zuvor einige hundert Euro gekostet hat, durch ein neues Modell ersetzt – das nach nicht einmal zwei Jahren Betrieb.
Ich nehme mich da selbst ehrlich gesagt gar nicht mal aus.Und bis zu diesem Zeitpunkt hält ein FLASH-Speicher wahrscheinlich immer locker durch.
Edit/PS: Beim krampfhaften Hinterherjagen nach jedem einzelnen Watt sollte man immer bedenken: Was kostet eine gesparte kWh – selbst bei einem angenommenen Preis von 1 Euro – im Verhältnis zu einem durchgedrehten Gerät mit defektem FLASH-Speicher?
-
Ich habe testweise in der config das API Skriptes mal "const maxOutputLimit = 2400" eingestellt, trotzdem lässt sich der Datenpunkt control.inverseMaxPower auf max 800 stellen. Wie kommt das?
In der App kann ich die max Ausgangsleistung auf 2400 stellen, das ist dann auch unter properties.inverseMaxPower zu sehen. -
Ich habe testweise in der config das API Skriptes mal "const maxOutputLimit = 2400" eingestellt, trotzdem lässt sich der Datenpunkt control.inverseMaxPower auf max 800 stellen. Wie kommt das?
In der App kann ich die max Ausgangsleistung auf 2400 stellen, das ist dann auch unter properties.inverseMaxPower zu sehen.@Jockel_Bln sagte:
Ich habe testweise in der config das API Skriptes mal "const maxOutputLimit = 2400" eingestellt, trotzdem lässt sich der Datenpunkt control.inverseMaxPower auf max 800 stellen. Wie kommt das?maxOutputLimit und control.inverseMaxPower sollten aus meiner Sicht denselben maximalen Leistungswert haben und sind im Script auch so vorgesehen.
maxOutputLimit = 2400verhindert jedoch nicht, dass Du den Datenpunktcontrol.inverseMaxPowerspäter auf 800 W setzt. Der Datenpunkt schreibt die Einstellung direkt ins Gerät – genau wie die Zendure-App. Die Script-Konfiguration wird dadurch nicht verändert.Deshalb ist es ganz normal, dass Du
control.inverseMaxPowerauf 800 W einstellen kannst, obwohlmaxOutputLimitim Script auf 2400 W steht.Meine Empfehlung ist,
inverseMaxPowerniemals dynamisch zu verändern. Das Script ist bewusst so aufgebaut, dassmaxOutputLimitundinverseMaxPowerdenselben maximalen Leistungswert repräsentieren.Wenn Du
inverseMaxPowerdauerhaft ändern möchtest, solltest Du deshalb auchmaxOutputLimitin der Script-Konfiguration auf denselben Wert anpassen. Nur so stimmen Script-Konfiguration und Gerätekonfiguration weiterhin überein.Die eigentliche Leistungsregelung sollte anschließend ausschließlich über
outputLimiterfolgen.inverseMaxPowersehe ich als feste Obergrenze des Wechselrichters und nicht als Regelparameter.Der Hintergrund ist auch, dass Zendure
inverseMaxPowerselbst als maximale Geräteleistung behandelt.
In der App ist eine Erhöhung über die Standardleistung hinaus nur nach entsprechender Bestätigung möglich; für noch höhere Leistungen sind sogar weitere Nachweise erforderlich.
Deshalb habe ich das Script bewusst auf diese Verwendung ausgelegt. -
@Jockel_Bln sagte:
Ich habe testweise in der config das API Skriptes mal "const maxOutputLimit = 2400" eingestellt, trotzdem lässt sich der Datenpunkt control.inverseMaxPower auf max 800 stellen. Wie kommt das?maxOutputLimit und control.inverseMaxPower sollten aus meiner Sicht denselben maximalen Leistungswert haben und sind im Script auch so vorgesehen.
maxOutputLimit = 2400verhindert jedoch nicht, dass Du den Datenpunktcontrol.inverseMaxPowerspäter auf 800 W setzt. Der Datenpunkt schreibt die Einstellung direkt ins Gerät – genau wie die Zendure-App. Die Script-Konfiguration wird dadurch nicht verändert.Deshalb ist es ganz normal, dass Du
control.inverseMaxPowerauf 800 W einstellen kannst, obwohlmaxOutputLimitim Script auf 2400 W steht.Meine Empfehlung ist,
inverseMaxPowerniemals dynamisch zu verändern. Das Script ist bewusst so aufgebaut, dassmaxOutputLimitundinverseMaxPowerdenselben maximalen Leistungswert repräsentieren.Wenn Du
inverseMaxPowerdauerhaft ändern möchtest, solltest Du deshalb auchmaxOutputLimitin der Script-Konfiguration auf denselben Wert anpassen. Nur so stimmen Script-Konfiguration und Gerätekonfiguration weiterhin überein.Die eigentliche Leistungsregelung sollte anschließend ausschließlich über
outputLimiterfolgen.inverseMaxPowersehe ich als feste Obergrenze des Wechselrichters und nicht als Regelparameter.Der Hintergrund ist auch, dass Zendure
inverseMaxPowerselbst als maximale Geräteleistung behandelt.
In der App ist eine Erhöhung über die Standardleistung hinaus nur nach entsprechender Bestätigung möglich; für noch höhere Leistungen sind sogar weitere Nachweise erforderlich.
Deshalb habe ich das Script bewusst auf diese Verwendung ausgelegt.Wenn Du inverseMaxPower dauerhaft ändern möchtest, solltest Du deshalb auch maxOutputLimit in der Script-Konfiguration auf denselben Wert anpassen. Nur so stimmen Script-Konfiguration und Gerätekonfiguration weiterhin überein.
Danke für deine ausführliche Antwort, aber kann es sein, dass wir aneinander vorbei reden?
Ich habe ja maxOutputLimit in der Konfiguration geändert, trotzdem steht im Datenpunkt control.inverseMaxPower weiterhin 800 und lässt sich auch nicht größer einstellen.inverseMaxPower sehe ich als feste Obergrenze des Wechselrichters und nicht als Regelparameter.
Das habe ich ja auch so verstanden und wollte sie halt zum Test über 800 setzen.
In der App ging es nach einer Bestätigung durch mich. Im Automatikmodus des HEMS regelt er dann auch über die 800 hinaus hoch. -
Wenn Du inverseMaxPower dauerhaft ändern möchtest, solltest Du deshalb auch maxOutputLimit in der Script-Konfiguration auf denselben Wert anpassen. Nur so stimmen Script-Konfiguration und Gerätekonfiguration weiterhin überein.
Danke für deine ausführliche Antwort, aber kann es sein, dass wir aneinander vorbei reden?
Ich habe ja maxOutputLimit in der Konfiguration geändert, trotzdem steht im Datenpunkt control.inverseMaxPower weiterhin 800 und lässt sich auch nicht größer einstellen.inverseMaxPower sehe ich als feste Obergrenze des Wechselrichters und nicht als Regelparameter.
Das habe ich ja auch so verstanden und wollte sie halt zum Test über 800 setzen.
In der App ging es nach einer Bestätigung durch mich. Im Automatikmodus des HEMS regelt er dann auch über die 800 hinaus hoch.@jockel_bln
ach ja :-)- Stoppe das Script.
- setze: const maxOutputLimit = 2400;
- Script speichern
- Komplettes Verzeichnis "0_userdata.0.zendure.xxxxx" löschen.
- Script neu starten.
Es sollte auch reichen, wenn bei gestoppten Script - vor Neustart - nur der Datenpunkt gelöscht wird: 0_userdata.0.zendure.xxxxx.control.inverseMaxPower
-
Das war es
-
Guten Morgen allerseits,
seit vergangenen Freitag hab ich auch endlich meinen SF800 Pro2 (aktuelle Firmware V2.0.0) am Netz. Aktuell laufen die 4 Solarmodule noch über dem Hoymiles Wechselrichter, um erstmal alle Verbindungen und Settings zu testen.
Das AC-Laden und auch das Entladen funktioniert aber schon mal unglaublich gut mit den Scripten hier aus dem Thread, ich bin immer noch schwer begeistert, was hier auf die Beine gestellt wurde!
@maxclaudi Sowohl dein ZenSDK-Script, als auch das zur Nulleinspeisung sind der Hammer! Ich hoffe du hast nichts dagegen, wenn ich das erstmal 1:1 übernommen habe, um meine Anlage ans Laufen zu bringen.Über das Wochenende haben sich aber ein paar Fragen ergeben, auf die ich bis jetzt keine Antwort gefunden habe:
-
Am Morgen erreichte der Akku die 10%-Marke und sollte da ja eigentlich stoppen mit der Einspeisung. Allerdings ging er irgendwie bis auf 8% runter und startete dann mit voller Last das AC-Laden, bis er wieder 10% erreicht hatte. Ab da dann keinerlei Auffälligkeiten und alles lief super. Ist das so korrekt und normal?
-
Die von dir gewählten 15s Regelungsintervall, sind die sozusagen als "Best Practice" von dir getestet? Wären zB 10s schon zu kurz bei der Regelungsträgheit des SF800?
-
Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe, aber da find ich nirgendwo Infos zu. Weder bei Zendure in der App, noch in dem ZenSDK oder im Adapter von nograx. Habt ihr ne Idee, wie ich das vernünftig tracken kann? Vielleicht über nen Shelly zwischen SF800 und Netz?
-
Ich sehe, dass der SF800 fleißíg zwischen Laden und Entladen hin und her wechselt. Da wir Warmwasser über einen Durchlauferhitzer beziehen sind das dann schon mal recht kurze Intervalle. Da überlege ich, wie man das evtl rausfiltern/ausschließen kann.
Aber bei den früheren Generationen von Zendure habe ich gelesen, dass nur alle 10min zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen. Ist die Technik mittlerweile soweit, dass das kein Problem mehr darstellt oder ist das vermeiden von sehr häufigen Lade/Entlade-Wechseln immer noch zu empfehlen?
Soweit erstmal von mir :-)
Freue mich, wenn ich zukünftig irgendwie was sinnvolles zum Thema hier beitragen kann
-
-
Guten Morgen allerseits,
seit vergangenen Freitag hab ich auch endlich meinen SF800 Pro2 (aktuelle Firmware V2.0.0) am Netz. Aktuell laufen die 4 Solarmodule noch über dem Hoymiles Wechselrichter, um erstmal alle Verbindungen und Settings zu testen.
Das AC-Laden und auch das Entladen funktioniert aber schon mal unglaublich gut mit den Scripten hier aus dem Thread, ich bin immer noch schwer begeistert, was hier auf die Beine gestellt wurde!
@maxclaudi Sowohl dein ZenSDK-Script, als auch das zur Nulleinspeisung sind der Hammer! Ich hoffe du hast nichts dagegen, wenn ich das erstmal 1:1 übernommen habe, um meine Anlage ans Laufen zu bringen.Über das Wochenende haben sich aber ein paar Fragen ergeben, auf die ich bis jetzt keine Antwort gefunden habe:
-
Am Morgen erreichte der Akku die 10%-Marke und sollte da ja eigentlich stoppen mit der Einspeisung. Allerdings ging er irgendwie bis auf 8% runter und startete dann mit voller Last das AC-Laden, bis er wieder 10% erreicht hatte. Ab da dann keinerlei Auffälligkeiten und alles lief super. Ist das so korrekt und normal?
-
Die von dir gewählten 15s Regelungsintervall, sind die sozusagen als "Best Practice" von dir getestet? Wären zB 10s schon zu kurz bei der Regelungsträgheit des SF800?
-
Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe, aber da find ich nirgendwo Infos zu. Weder bei Zendure in der App, noch in dem ZenSDK oder im Adapter von nograx. Habt ihr ne Idee, wie ich das vernünftig tracken kann? Vielleicht über nen Shelly zwischen SF800 und Netz?
-
Ich sehe, dass der SF800 fleißíg zwischen Laden und Entladen hin und her wechselt. Da wir Warmwasser über einen Durchlauferhitzer beziehen sind das dann schon mal recht kurze Intervalle. Da überlege ich, wie man das evtl rausfiltern/ausschließen kann.
Aber bei den früheren Generationen von Zendure habe ich gelesen, dass nur alle 10min zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen. Ist die Technik mittlerweile soweit, dass das kein Problem mehr darstellt oder ist das vermeiden von sehr häufigen Lade/Entlade-Wechseln immer noch zu empfehlen?
Soweit erstmal von mir :-)
Freue mich, wenn ich zukünftig irgendwie was sinnvolles zum Thema hier beitragen kannGuten Morgen allerseits,
seit vergangenen Freitag hab ich auch endlich meinen SF800 Pro2 (aktuelle Firmware V2.0.0) am Netz. Aktuell laufen die 4 Solarmodule noch über dem Hoymiles Wechselrichter, um erstmal alle Verbindungen und Settings zu testen.
Das AC-Laden und auch das Entladen funktioniert aber schon mal unglaublich gut mit den Scripten hier aus dem Thread, ich bin immer noch schwer begeistert, was hier auf die Beine gestellt wurde!
@maxclaudi Sowohl dein ZenSDK-Script, als auch das zur Nulleinspeisung sind der Hammer!Dankeschön, wobei das DPL-Blockly-Skript nur eine Basis-Vorlage sein soll ;-)
Ich hoffe du hast nichts dagegen, wenn ich das erstmal 1:1 übernommen habe, um meine Anlage ans Laufen zu bringen.
Genau dafür ist es gedacht – als Vorlage für den Einstieg.
- Am Morgen erreichte der Akku die 10%-Marke und sollte da ja eigentlich stoppen mit der Einspeisung. Allerdings ging er irgendwie bis auf 8% runter und startete dann mit voller Last das AC-Laden, bis er wieder 10% erreicht hatte. Ab da dann keinerlei Auffälligkeiten und alles lief super. Ist das so korrekt und normal?
Da über minSoc festgelegt wird, wann die untere Entladegrenze erreicht ist, veranlasst die Firmware automatisch ein Nachladen der Batterie(n), bis mindestens minSoc wieder erreicht ist.
Siehe auch Zendure FAQ, Zitat:
...Zudem erkennt das System automatisch, wenn der Batteriestand kritisch niedrig ist (z. B. bei geringer PV-Erzeugung) und schaltet in diesem Fall selbstständig auf Netzstrom um, um Schäden an der Batterie zu vermeiden.
Wenn während des Betriebs noch Leistung aus der Batterie entnommen wird, stoppt die Entladung nicht exakt bei minSoc. minSoC ist ein berechneter Schätzwert und nicht direkt gemessene Volt. Deshalb kann die Batterie im laufenden Entladevorgang durchaus noch etwas weiter entladen werden.
Hinzu kommt, dass sich die Zellspannungen je nach Betriebszustand unterscheiden. Eine ruhende Batterie hat andere Zellspannungen als eine gerade geladene oder entladene Batterie.
Wenn Du das sofortige Nachladen vermeiden möchtest, würde ich einen Batterie-Entladeschutz über gemessene Volt realisieren.
Dann könntest Du minSoc z. B. auf 10 % setzen und den eigentlichen Batterieschutz über die gemessene minimale Zellspannung realisieren.Testweise könntest Du minVol auf z. B. 3,2 V verwenden und beobachten, welchem SoC dieser Wert bei Deinen Batterien ungefähr entspricht. Liegt das beispielsweise bei 15–20 %, wird die Entladung bereits dort beendet, ohne dass anschließend sofort wieder zwangsweise (wie bei minSoc) nachgeladen wird.
- Die von dir gewählten 15s Regelungsintervall, sind die sozusagen als "Best Practice" von dir getestet? Wären zB 10s schon zu kurz bei der Regelungsträgheit des SF800?
Die 15 Sekunden sind kein fester Optimalwert, sondern eher ein praxisnaher Erfahrungswert, der sich an den typischen Reaktionszeiten solcher (auch prof.) Systeme orientiert und sich in meinen Tests als praktikabel erwiesen hat. Bei meinen Regelungen gibt es unterschiedliche Zeiten.
Wenn Du das Basis-Script verwendest, kannst Du gerne andere Zeiten testen.Beim Erhöhen der Ausgangsleistung (Entladen) kommt das System meiner Erfahrung nach auch mit etwa 10 Sekunden gut zurecht. Die neue Leistung sollte dann aber auch für eine gewisse Zeit gehalten werden.
Das Reduzieren der Ausgangsleistung reagiert etwas schneller. Je nach System können hier auch etwa 6 Sekunden ausreichend sein.
Beim AC-Laden würde ich dagegen keine ständig schwankenden Leistungswerte vorgeben. Meiner Meinung nach ist es sinnvoller, mit einer möglichst konstanten Ladeleistung über einen längeren Zeitraum zu arbeiten.
- Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe, aber da find ich nirgendwo Infos zu. Weder bei Zendure in der App, noch in dem ZenSDK oder im Adapter von nograx. Habt ihr ne Idee, wie ich das vernünftig tracken kann? Vielleicht über nen Shelly zwischen SF800 und Netz?
Mich interessieren in erster Linie die Zählerwerte, denn das ist letztlich die Energie, die ich bezahlen muss.
Wenn Du dafür einen Shelly Plug oder eine andere Zwischensteckdose einsetzen möchtest, solltest Du darauf achten, dass auch negative Leistungen bzw. Rückspeisung korrekt erfasst werden. Tasmota-basierte Steckdosen unterstützen das beispielsweise.
- Ich sehe, dass der SF800 fleißíg zwischen Laden und Entladen hin und her wechselt. Da wir Warmwasser über einen Durchlauferhitzer beziehen sind das dann schon mal recht kurze Intervalle. Da überlege ich, wie man das evtl rausfiltern/ausschließen kann.
Aber bei den früheren Generationen von Zendure habe ich gelesen, dass nur alle 10min zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen. Ist die Technik mittlerweile soweit, dass das kein Problem mehr darstellt oder ist das vermeiden von sehr häufigen Lade/Entlade-Wechseln immer noch zu empfehlen?
Das liegt daran, dass im DPL-Skript derzeit keine Mindesthaltezeit für den acMode (Mindest-acMode-Intervall) integriert ist.
Es sind auch keine Lastprofile implementiert etc.
Gerade bei reinen AC-Systemen im DPL-Betrieb ist das nicht ganz einfach umzusetzen.Deshalb bin ich beim 1600AC+ auch froh über die Off-Grid-Steckdose, an der sich ein Mikrowechselrichter betreiben lässt.
Der SF800 Pro 2 besitzt diese Möglichkeit ebenfalls.
Du könntest testweise einen 800-W-Hoymiles-Mikrowechselrichter an der Off-Grid-Steckdose betreiben.
Zwar wird die Batterie dann ebenfalls über AC geladen, der zusätzliche Umweg über das öffentliche Netz entfällt jedoch.
Wird gerade keine Leistung benötigt, lädt das System die Batterien automatisch über den an der Off-Grid-Steckdose angeschlossenen Wechselrichter.Alternativ kannst Du natürlich auch die vorhandenen DC-MC4-PV-Eingänge für die PV-Module nutzen.
Dadurch reduzierst Du die Anzahl der Wechsel zwischen AC-Laden und AC-Entladen deutlich und vermeidest zusätzlich unnötige Wandlungsverluste. -
-
Guten Morgen allerseits,
seit vergangenen Freitag hab ich auch endlich meinen SF800 Pro2 (aktuelle Firmware V2.0.0) am Netz. Aktuell laufen die 4 Solarmodule noch über dem Hoymiles Wechselrichter, um erstmal alle Verbindungen und Settings zu testen.
Das AC-Laden und auch das Entladen funktioniert aber schon mal unglaublich gut mit den Scripten hier aus dem Thread, ich bin immer noch schwer begeistert, was hier auf die Beine gestellt wurde!
@maxclaudi Sowohl dein ZenSDK-Script, als auch das zur Nulleinspeisung sind der Hammer!Dankeschön, wobei das DPL-Blockly-Skript nur eine Basis-Vorlage sein soll ;-)
Ich hoffe du hast nichts dagegen, wenn ich das erstmal 1:1 übernommen habe, um meine Anlage ans Laufen zu bringen.
Genau dafür ist es gedacht – als Vorlage für den Einstieg.
- Am Morgen erreichte der Akku die 10%-Marke und sollte da ja eigentlich stoppen mit der Einspeisung. Allerdings ging er irgendwie bis auf 8% runter und startete dann mit voller Last das AC-Laden, bis er wieder 10% erreicht hatte. Ab da dann keinerlei Auffälligkeiten und alles lief super. Ist das so korrekt und normal?
Da über minSoc festgelegt wird, wann die untere Entladegrenze erreicht ist, veranlasst die Firmware automatisch ein Nachladen der Batterie(n), bis mindestens minSoc wieder erreicht ist.
Siehe auch Zendure FAQ, Zitat:
...Zudem erkennt das System automatisch, wenn der Batteriestand kritisch niedrig ist (z. B. bei geringer PV-Erzeugung) und schaltet in diesem Fall selbstständig auf Netzstrom um, um Schäden an der Batterie zu vermeiden.
Wenn während des Betriebs noch Leistung aus der Batterie entnommen wird, stoppt die Entladung nicht exakt bei minSoc. minSoC ist ein berechneter Schätzwert und nicht direkt gemessene Volt. Deshalb kann die Batterie im laufenden Entladevorgang durchaus noch etwas weiter entladen werden.
Hinzu kommt, dass sich die Zellspannungen je nach Betriebszustand unterscheiden. Eine ruhende Batterie hat andere Zellspannungen als eine gerade geladene oder entladene Batterie.
Wenn Du das sofortige Nachladen vermeiden möchtest, würde ich einen Batterie-Entladeschutz über gemessene Volt realisieren.
Dann könntest Du minSoc z. B. auf 10 % setzen und den eigentlichen Batterieschutz über die gemessene minimale Zellspannung realisieren.Testweise könntest Du minVol auf z. B. 3,2 V verwenden und beobachten, welchem SoC dieser Wert bei Deinen Batterien ungefähr entspricht. Liegt das beispielsweise bei 15–20 %, wird die Entladung bereits dort beendet, ohne dass anschließend sofort wieder zwangsweise (wie bei minSoc) nachgeladen wird.
- Die von dir gewählten 15s Regelungsintervall, sind die sozusagen als "Best Practice" von dir getestet? Wären zB 10s schon zu kurz bei der Regelungsträgheit des SF800?
Die 15 Sekunden sind kein fester Optimalwert, sondern eher ein praxisnaher Erfahrungswert, der sich an den typischen Reaktionszeiten solcher (auch prof.) Systeme orientiert und sich in meinen Tests als praktikabel erwiesen hat. Bei meinen Regelungen gibt es unterschiedliche Zeiten.
Wenn Du das Basis-Script verwendest, kannst Du gerne andere Zeiten testen.Beim Erhöhen der Ausgangsleistung (Entladen) kommt das System meiner Erfahrung nach auch mit etwa 10 Sekunden gut zurecht. Die neue Leistung sollte dann aber auch für eine gewisse Zeit gehalten werden.
Das Reduzieren der Ausgangsleistung reagiert etwas schneller. Je nach System können hier auch etwa 6 Sekunden ausreichend sein.
Beim AC-Laden würde ich dagegen keine ständig schwankenden Leistungswerte vorgeben. Meiner Meinung nach ist es sinnvoller, mit einer möglichst konstanten Ladeleistung über einen längeren Zeitraum zu arbeiten.
- Mir fehlt irgendwie eine Angabe, wieviel kWh ich geladen/eingespeist habe, aber da find ich nirgendwo Infos zu. Weder bei Zendure in der App, noch in dem ZenSDK oder im Adapter von nograx. Habt ihr ne Idee, wie ich das vernünftig tracken kann? Vielleicht über nen Shelly zwischen SF800 und Netz?
Mich interessieren in erster Linie die Zählerwerte, denn das ist letztlich die Energie, die ich bezahlen muss.
Wenn Du dafür einen Shelly Plug oder eine andere Zwischensteckdose einsetzen möchtest, solltest Du darauf achten, dass auch negative Leistungen bzw. Rückspeisung korrekt erfasst werden. Tasmota-basierte Steckdosen unterstützen das beispielsweise.
- Ich sehe, dass der SF800 fleißíg zwischen Laden und Entladen hin und her wechselt. Da wir Warmwasser über einen Durchlauferhitzer beziehen sind das dann schon mal recht kurze Intervalle. Da überlege ich, wie man das evtl rausfiltern/ausschließen kann.
Aber bei den früheren Generationen von Zendure habe ich gelesen, dass nur alle 10min zwischen Laden und Entladen gewechselt werden soll, um die Relais zu schonen. Ist die Technik mittlerweile soweit, dass das kein Problem mehr darstellt oder ist das vermeiden von sehr häufigen Lade/Entlade-Wechseln immer noch zu empfehlen?
Das liegt daran, dass im DPL-Skript derzeit keine Mindesthaltezeit für den acMode (Mindest-acMode-Intervall) integriert ist.
Es sind auch keine Lastprofile implementiert etc.
Gerade bei reinen AC-Systemen im DPL-Betrieb ist das nicht ganz einfach umzusetzen.Deshalb bin ich beim 1600AC+ auch froh über die Off-Grid-Steckdose, an der sich ein Mikrowechselrichter betreiben lässt.
Der SF800 Pro 2 besitzt diese Möglichkeit ebenfalls.
Du könntest testweise einen 800-W-Hoymiles-Mikrowechselrichter an der Off-Grid-Steckdose betreiben.
Zwar wird die Batterie dann ebenfalls über AC geladen, der zusätzliche Umweg über das öffentliche Netz entfällt jedoch.
Wird gerade keine Leistung benötigt, lädt das System die Batterien automatisch über den an der Off-Grid-Steckdose angeschlossenen Wechselrichter.Alternativ kannst Du natürlich auch die vorhandenen DC-MC4-PV-Eingänge für die PV-Module nutzen.
Dadurch reduzierst Du die Anzahl der Wechsel zwischen AC-Laden und AC-Entladen deutlich und vermeidest zusätzlich unnötige Wandlungsverluste.Vielen Dank für die ausführlichen Antworten.
Genau dafür ist es gedacht – als Vorlage für den Einstieg.
Sehr komfortabler und umfangreicher Einstieg
Wenn während des Betriebs noch Leistung aus der Batterie entnommen wird, stoppt die Entladung nicht exakt bei minSoc. minSoC ist ein berechneter Schätzwert und nicht direkt gemessene Volt. Deshalb kann die Batterie im laufenden Entladevorgang durchaus noch etwas weiter entladen werden.
Hinzu kommt, dass sich die Zellspannungen je nach Betriebszustand unterscheiden. Eine ruhende Batterie hat andere Zellspannungen als eine gerade geladene oder entladene Batterie.
Wenn Du das sofortige Nachladen vermeiden möchtest, würde ich einen Batterie-Entladeschutz über gemessene Volt realisieren.
Dann könntest Du minSoc z. B. auf 10 % setzen und den eigentlichen Batterieschutz über die gemessene minimale Zellspannung realisieren.Testweise könntest Du minVol auf z. B. 3,2 V verwenden und beobachten, welchem SoC dieser Wert bei Deinen Batterien ungefähr entspricht. Liegt das beispielsweise bei 15–20 %, wird die Entladung bereits dort beendet, ohne dass anschließend sofort wieder zwangsweise (wie bei minSoc) nachgeladen wird.
OK, also ist das erstmal normal und ich sollte mich um einen entsprechenden Entladeschutz kümmern, das ist gut zu wissen.
Das liegt daran, dass im DPL-Skript derzeit keine Mindesthaltezeit für den acMode (Mindest-acMode-Intervall) integriert ist.
Es sind auch keine Lastprofile implementiert etc.
Gerade bei reinen AC-Systemen im DPL-Betrieb ist das nicht ganz einfach umzusetzen.Alternativ kannst Du natürlich auch die vorhandenen DC-MC4-PV-Eingänge für die PV-Module nutzen.
Dadurch reduzierst Du die Anzahl der Wechsel zwischen AC-Laden und AC-Entladen deutlich und vermeidest zusätzlich unnötige Wandlungsverluste.Spätestens sobald ich auslesen und messen kann, wieviel kWh ich per AC in den SF800Pro schiebe und wieviel ich wieder ins Haus einspeise, kommen die 4 vorhandenen Panels direkt an den SF800 und es wird nur noch zum Kalibrieren per AC aufgeladen. Mein Hoymiles Wechselrichter kommt bei 4 Panels (SO/SW) sowieso regelmäßig an seine Belastungsgrenze mit den 2 MPPT, durch die 4 MPPT kann der SF800 da noch schön von aufladen.
Ich würde halt gern wissen, wieviel Energie ich per PV gewinne, bzw. einspeise, aber da muss ich ja auch die Energie per AC-Ladung wieder abrechnen. Ich hab mittlerweile nen Shelly dazwischen, der auch beide Richtungen kann (oder können soll), aber bisher blick ich bei den Messwerten von dem nicht durch. Der hat einen Wert für "ReturnedEnergy", was für mich dann die Einspeisung wäre. Und einen Wert "Energy", der aber der Gesamtwert in & out zu sein scheint. Passt für mich aber rechnerisch auch noch nicht ganz zusammen, aber das könnte auch einfach an mir liegen
Und sofern ich die kurzen Sprünge durch den Durchlauferhitzer über das Script irgendwie rausgefiltert bekomme, dürfte das die schnellen und großen Lastwechsel nochmal deutlich reduzieren.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
470
Online33.0k
Benutzer83.6k
Themen1.3m
Beiträge