Gebruik je maar 150Wh per uur? >> x 4 natuurlijk. 
. Ik zag het even fout. Dacht meteen iets geks te zien.
dit is wel wat cryptisch. 
Heb ik iets fout ingesteld en moet ik wat aanpassen? of is er wat anders fout?
De app is best ingewikkeld geworden. Ik heb geprobeerd met de setup1.html een en ander duidelijker te maken. Maar ook dan is het misschien ook nog niet duidelijk. Misschien eens een online sessie doen via YouTube.
1 Like
Ik heb weer een nieuwe versie neergezet:
- Geheugen probleem verbeterd
- Het juiste vermogen bij laden en ontladen
- Charge_only aanpassing
Charge_Only werkt alsvolgt:
- Hij zoekt de de duurste en goedkoopste kwartieren binnen de dag eventueel halve dag
- hij bepaalt het gemiddelde van beide en kijkt of hij het minimale verschil haal van zeg 0.03 per kWh > zon Niet…dan alles naar NOM
- Hij laadt dus altijd de hele batterij op
- Zon surplus kwartierenworden van de laadkwartieren afgehaald om zo altijd 1 volle lading te behalen
- Is er dus voldoende zon om de hele batterij op te laden…dan laad hij niet extra bij van het net.
- De totale capaciteit wordt verdeel over de nom-kwartieren zonder zon surplus.
- is er onvoldoende capaciteit, dan gaan de goedkoopste kwartieren op stop.
Dit verklaart waarschijnlijk ook dat de batterij soms nachts niet geheel wordt opgeladen omdat er later nog zon surplus is. In het voorbeeld van Willem, zou je denken, waarom niet morgens tot 100% opladen…de zon surplus kwartieren liggen ver genoeg weg om naar 100% te willen gaan laden. Voor nu laat ik het even zo…bij charge_only 1 volle lading > via zon en/of net.
Financieel is met saldering charge_only sowieso onverstandig. Je helpt alleen het net te ontlasten. Het voelt wel goed.
3 Likes
Diagnostics beetje compacter gemaakt. Je kan ook uitklappen als je meer wil zien. Deze blijft dan uitgeklapt. (op de telefoon moet ik hem nog een beetje verbeteren)
Verder zit er een verassing in de app: Zoek de nieuwe html. 
3 Likes
Financieel is met saldering charge_only sowieso onverstandig. Je helpt alleen het net te ontlasten. Het voelt wel goed.
Roedi kan je / wil je dit eens uitleggen of vergelijken
@ pdr: Verder zit er een verassing in de app: Zoek de nieuwe html.
De verrassing heb ik nog niet kunnen vinden maar de App is fantastisch!
Hoe zou ik kunnen voorkomen dat zoals op dit moment in de ochtend de dynamische prijs vrij hoog is (€0.27) ik niet de accu laad maar terug lever naar het net? Volgens mij is dat voordelig of maak ik hier een denkfout?
Bedankt!
Geen idee…moet ik eerst veeeeeeel meer info hebben :). Maar als ik naar mijn plan kijk…einde dag zijn er duurdere prijzen…dus wacht hij.
1 Like
We kunnen samen wel een “FAQ” video maken op mijn kanaal?
He…dat is een gaaf idee. Lijkt me echt super leuk om te doen! Ik had de link nog niet gelegd tussen jouw en je YouTube-kanaal. Je stem herkende ik wel meteen. Gaan we doen!
3 Likes
Top! kom er in het nieuwe ff op terug. Eerst kerstvieren.
1 Like
Ik ben hier wel eens opnieuw ingedoken. Het blijft lastige materie. Het werkt als volgt:
Voorbeeld 1: Hoge prijzen (€0.30 → €0.33)
| Laden | 4.1 kWh × €0.30 = €1.23 kosten |
| Gemiddeld ontladen via NOM | 3.0 kWh × €0.33 = €0.99 opbrengst |
| Energieverlies | 1.1 kWh × €0.30 = €0.33 |
| Prijswinst | 3.0 kWh × €0.03 = €0.09 |
| Netto | €0.99 - €1.23 = -€0.24 verlies |
Dit was bij eergisteren.
Maaaaaarrr…hierdoor kwam ik ook achter een denkfout vanuit mijn kant:
Voorbeeld 2: Lage prijzen (€0.15 → €0.18)
| Laden | 4.1 kWh × €0.15 = €0.615 kosten |
| Gemiddeld ontladen via NOM | 3.0 kWh × €0.18 = €0.54 opbrengst |
| Energieverlies | 1.1 kWh × €0.15 = €0.165 |
| Prijswinst | 3.0 kWh × €0.03 = €0.09 |
| Netto | €0.54 - €0.615 = -€0.075 verlies |
Conclusie
Zelfde prijsverschil (€0.03), maar:
- Bij hoge prijzen: €0.24 verlies
- Bij lage prijzen: €0.08 verlies
Het energieverlies (1.1 kWh) kost meer als de prijs hoger is. Daarom werkt een vaste drempel van bijv €0,03 niet goed - je hebt een hogere marge nodig bij hogere prijzen.
Ik heb het model nu aanmoeten passen, zodat we wel rekening gaan houden met dit energieverlies. en dit resulteert dan in twee nieuwe settings:
Het wordt er denk voor het instellen makkelijker op. Je geeft aan dat je minimaal 15 cent winst wil maken en dat je dan pas wil laden en ontladen.
Is de dagwinst tussen 15 cent winst en 5 cent verlies…dan mag het plan Charge_only draaien.
Als dat ook niet lukt… gewoon alles op NOM.
(Deze functionaliteit zal ik vandaag uploaden voor Test)
Pfff…hadden jullie dit verwacht…ik niet hoor. Kostte me best wel wat moeite om dit te begrijpen…3 cent is toch 3 cent.. 
Gevolgen van mijn nieuwe aanpak:
Wat NIET veranderd is:
- De winstberekening in het plan zelf
Wat WEL veranderd is:
- De selectie van kwartieren: welke laad/ontlaad-koppels worden gematcht
- Nu wordt RTE meegenomen bij het bepalen of een koppel winstgevend is
Wat heeft wel invloed op de winstbepaling is de RTE. Ik heb in de app een Laad en ontlaad en NOM efficiency zitten:
- Laad- en ontlaad-efficiency zijn statische voor Marstek API gebruikers en niet muteerbaar. Bij MQTT en Sessy gebruikers leert de app de learnings…maar hij lijkt altijd een beetje hoog uit te komen, daarom heb ik al deze parameters muteerbaar gemaakt (Je moet wel de RTEL_learnings uit zetten)
Afijn…ik probeer de learnings nog te verbeteren.
Tot slot:
Er zit in de app een actuele winst manager (sorry alles heet manager in de app :).
Deze trackt wat er echt geladen en ontladen wordt en houdt semi-realtime bij wat de winst tot nu toe is. Hij kijkt waarvoor je de stroom hebt ingekocht, en ook waarvoor het weer is verkocht. dat doet hij fifo. De winst wordt ook pas gepakt op het moment dat er ontladen wordt.
Het zou mooi zijn als jullie meekijken of dit nu goed werkt. De verschillen met mijn nieuwe aanpassingen tov de oude functionaliteit best wel fors:
- De actuele winst manager berekende een verlies van €0,06 tot nu toe, terwijl het dit moest zijn:
1 Like
