Als je dit wilt…zou je in principe niet willen dat hij tussendoor van de zon op gaat laden. Want Of de batterij is vol OF je verdien er niet voldoende geld mee. Anders had het plan zelf wel gekozen voor dit kwartier. Dit is de reden waarom ik gekozen heb voor stop kwartieren tussen laden en ontladen. (bij zon terug naar het net…verlies je ook niet de RTE)
Maar…niet alles draait om winst natuurlijk. Ik zou de app kunnen laten monitoren of er op stop kwartieren toch zonoverschot is, zodat ook deze kwh’s de batterij ingaan. Ik moet hier nog even over nadenken of ik dat wil en ga doen. Bij de API moet ik ook nog voorkomen dat de api niet overbelast wordt.
juist dit wat je beschrijft valt mij inderdaad op dit moment ook op. Op het moment zijn er stop kwartieren en heb ik wel een klein overschot zonne energie. die wordt dus nu naar het net gebracht en niet in de batterij gestopt.
wat mij opvalt is dat sinds ik slimladen ben gaan gebruiken de efficientie van 81% is teruggelopen naar 65% . waarbij ik moet bekennen dat de 81% gemeten is over hele maand november. en nu met slimladen slechts over het stukje december . Ben toevallig op 1 december met het slimladen plan gestart.
Dit is gemeten vanuit de app zelf? Ben wel benieuwd, want de app heeft daar in principe weinig invloed op. Wel op de meting binnen de app…daar zou nog wel iets fout kunnen zitten qua berekening. Dit is wat de app bij mij meet boven de 800W: (Dit legt hij vast in een curve tot 2500W)
In NOM stand verwacht ik het lager, omdat je dan met het grote vermogen van de omvormer een lagere efficiency krijgt.
als je in de marstek app zit, heb je afvoercapaciteit, daar kan je op de kalenderknop drukken en daar heb je dan de laad en ontlaad capaciteiten staan waarmee het weer kan berekenen.
Nog niet perfect…maar iets meer grip op de API krijgen.
Daarnaast heb ik een kleine enquete gemaakt om te kijken welke batterijen en homeys er gebruikt worden. Deze start automatisch wanneer je diagnostics.html start.
Ja, ik had 8.09 geïnstalleerd. Met 8.10 is het weer stabiel.
Ik ben er nu achter waarom de cloud verbinding bij mij wegviel. Ik heb de batterijen gedeeld met een tweede cloud account voor een andere cloud integraties. Die gingen blijkbaar te vaak synchroniseren. Nu ik 1 van die heb uit gezet, is de cloud verbinding weer stabiel.
Voornamelijk API proberen stabiel te krijgen. Eigenlijk is ie niet goed genoeg voor mijn app.
Ik heb een enquete toegevoegd. Voornamelijk om te weten waar de meeste behoefte aan is. En of ik kan overstappen naar functionaliteit die alleen in de nieuwste homeys beschikbaar zijn.
Dan een heel gedoe…de flowkaart “Huidige actie wijzigt” laten werken.
Probleem in hoofdstuk 6: validatiefout. Hij keek naar de verkeerde setting.
Nu ook goede ondersteuning als laden en ontladen verschillen in vermogen.
Foutje opgelost dat hij niet altijd alle beschikbare laadkwartieren benutte.
in je dagelijkse analyse moet je onderzoeken hoeveel kWh je nodig hebt om die pieken op te vangen. En wanneer (welk kwartier) ze nodig zijn.
in je laad/ontlaadlogica moet je een ‘reservecapaciteit’ voorzien, bijvoorbeeld 1 kWh, om die pieken op te kunnen vangen
gelijkaardig aan je Kritieke Apparaten zou je dan een lijst van apparaten kunnen toevoegen die niet meegenomen moeten worden in je analyse (bv: laadpaal). Ik denk niet dat je Kritieke Apparaten volledig herbruikbaar zijn…
Dit is bijna niet te doen verwacht ik. NOM stand wordt ook gewoon door de batterij gedaan. Nou ja…nog eens over nadenken.
Zie punt 4? Of altijd ontladen op bepaalde uren/kwartieren. op een X vermogen.
Met een modbus/lilygo is dit in te stellen (ik dacht ook vanuit mijn app al)
Je weet in principe welke apparaten de pieken verzorgen? >> Je zou dan hier kunnen zeggen: Wanneer apparaat A aangaat…zet batterij op NOM. Of wanneer apparaat aangaat…batterij op x vermogen.
(Dit legt hij vast in een curve tot 2500W)
