Ik heb het zo gedaan.
Ff een vraag, hoe voorkom ik dat hij vanmiddag gaat laden vanuit het net?
Ik wil alleen zonne laden.
Bedankt!
Hoi Roedi,
Ik heb in het verleden de AlphaESS modbus aansturing via homey geprobeerd maar liep daarmee tegen het probleem aan dat Homey mogelijkm de modbus bezet houdt waardoor er geen nieuwe opdrachten naar de AlphaESS konder worden gestuurd. Dat leek ook nu het geval dus voordat ik FE af wil koppelen (geeft nogal gedoe met hen) wilde ik eerst kijken of er al meerdere gebruikers zijn met een AlphaESS die het goed werkend hebben 
Ik mag overigens volgende week met pensioen en dan heb ik ook wat meer tijd over om me te verdiepen in jouw App. Overigens klasse zoals je dit gehaal aanpakt, wordt zeker gewaardeerd 
Jij denkt dus dat als ik de huidige FrankEnergie-handel sturing loskoppel de AlphaESS goed hoort te reageren op jouw App?
Of is er een mogelijk andere oorzaak dat je weet, waarop hij met een error op de commando’s terugkomt?
Mijn router (Ziggo) ondersteunt helaas geen VPN, dus ik ga even kijken wat ik kan met een Raspberry. Dank voor het meedenken.
Hier een complete uitleg voor het opzetten van een VPN via Raspberry.
1 Like
Je kan ook Tailscale gebruiken, dan hoef je geen poorten te openen in je router.
1 Like
Vreemd. Op dit moment met de diverse profielen en instellingen geprobeerd (ook met jouw settings), maar nix nie laden van het net.
Ik weet niet wat er bij mij anders is dan bij jou. Onderstaande laadplan is wat hij nu bij mij geeft en dit is binnen de grenzen van de firmware van Marstek wat ik logisch vind –> grootste deel van de tijd op NOM. In mijn geval heb ik met een flow een laadbegrenzing ingebouwd.
In de ochtend bij hogere prijzen zou ik export-first willen hebben (zie mijn vorige post). Aanvraag bij Marstek gedaan.
Verder werkt alles m.i. momenteel goed en geen onstabiliteiten in de modellen. Stopzetten batterij bij kritisch apparaat de WP werkt. Ik krijg soms een API timeout melding, maar dat lijkt verrder geen invloed te hebben.
Ik heb statisch aan, en handmatig uit.
Maar idd heel vreemd bij jou. Groen en blauw zou niet mogen. Ook bij Dynamisch? Het lijkt net alsof hij de profiel settings niet meeneemt. App opnieuw opstarten?
Herstart gedaan , lost niets op. Ik zie nu ook aan het eind een Stop kwartier ondanks de voorwaarden. Zet hem maar weer handmatig op NOM
Ik heb zo’n vermoeden dat je druk bezig met wederom een grote update ?
,maar ik wil even melden dat bij mij alleen het standaard dynamisch profiel daadwerkelijk iets doet (zonladen )gaat niet over naar NOM
Bij mij werkt slimplanner 1 wel aardig goed. Ik zie ook geen errors in de Marstek API meer.
Gewoon voorwaarde NIET LADEN toevoegen van 00:00 - 00:00 uur. Bij SlimPLanner2 heb ik onderstaande ingesteld en deze zal ik gebruiken bij een te verwachten zonnige dag. Bij een niet zonnige dag haal ik de voorwaarde NIET LADEN weg.
Ik heb net weer een nieuwe versie geplaatst. Ik ben teruggegaan naar twee standaard profielen. Je hebt dus nu niet meer de vrijheid om zelf je voorwaarden te bepalen.
Ik heb dit gedaan omdat er teveel mogelijkheden zijn en ik dit niet zo kan krijgen dat het in alle gevallen goed werkt.
Ook komt uit de enquête eigenlijk naar voren dat de twee standaard profielen vertegenwoordigen wat de meesten van jullie ook willen.
Het dynamische model heb ik ook uitgefaseerd. Ik wil me eerst richten op deze 2 profielen.
Ik kan me voorstellen dat jullie dit als een achteruitgang zien. Maar ik zou jullie willen vragen om eens goed te kijken of het profiel toch niet precies doet wat je graag wilt.
Daarbij blijft het model geen 100% verklaarbaar model. Hier en daar zal je zien dat hij net een kwartier doet, die je niet verwacht of kan verklaren. Voor mij persoonlijk zou ik dat wel graag willen, maar een kleine afwijking vind ik zelf niet zo erg.
Er is nog wel de keuze om Solar Capture ook te laten draaien op STOP kwartieren.
Wel heb ik de winst berekening verder uitgebreid met de zonopwek die rechtstreeks naar het net gaat.
Tot slot. Ik ben er nog steeds niet achter waarom de app nu af en toe opnieuw opstart. Het kan zijn, of eigenlijk hopelijk, kunnen we hier een melding over krijgen in de error card op diagnostics.html. Stuur mij die dan toe.
4 Likes
Ja, FrankEnergie moet eerst losgekoppeld worden. Modbus TCP (poort 502) ondersteunt maar één client tegelijk. Zolang FrankEnergie de verbinding bezet houdt, krijgt elke andere app een error terug.
SlimLaden opent de verbinding, stuurt het commando, en sluit direct weer af — dus geen permanente bezetting. Maar dat werkt pas als er geen andere app op de poort zit.
Ziet er goed uit, het was ook niet meer overzichtelijk. Te veel knoppen om aan te draaien.
Nog even een vraagje, bij stop gaat eventuele overschot naar het net en met solarcapture naar de batterij? Klopt dat of heb ik dat verkeerd?
Ja dat klopt.
Ah, dat verklaart inderdaad het 'probleem’.
Fijn te weten dat jouw SlimLaden-App daar wel rekening mee houdt en hem vrijgeeft. (Dan kan ik eventueel ook nog via Home-assistant de boel extra in de gaten houden )
edit:” Heb zojuist de FE losgekoppeld en de bevestiging gekregen via AlphaESS. De AlphaESS app kan nu de accu weer aansturen.
Moet ik nog bepaalde zaken aan of of uitzetten in de App om het te laten werken? Ik krijg op dit moment nog steeds die connction errors vanuit de Slimladen App.
Ik sta nog in tweestrijd op dit moment om Frank maar helemaal los te gaan koppelen en de AlphaESS zelf aan te gaan sturen. Met FE handelen kom ik nu met een 15kWh ESS op gemiddeld op ca 2 a 2,5 euro per dag opbrengst. Zodra de panelen (6500Wp) straks meer gaan opbrengen voelt het niet goed om die overtollige stroom te moeten verkopen voor een paar centen.
(Mochten er bij anderen positieve ervaringen zijn met zelfaansturing dan hoor ik dat natuurlijk graag in een PB want dat hoort in dit draadje denk ik niet thuis).
Zover enorm bedankt voor je reactie!
Een heel goede stap, back to basics en zorgen dat die basis goed werkt. Ik ben benieuwd naar hoe het werkt en welke optimizer/solver je gebruikt. Het ene profiel optimaliseert primair op kosten, het andere primair op zelf verbruik en daarna pas op kosten. Ik ben nog aan het denken over dat modelletje van Mark Vis.
Eigen gebruiker specifieke wensen kan je zelf maken via een flow.
Mbt dat zelfverbruik & kosten: als er voldoende zonoverschot is of lage prijzen midden van de dag om de batterij te vullen moet hij niet ‘s ochtends al gaan laden met PV stroom terwijl de prijzen nog hoog zijn. Dan moet hij stop of “export first”. Bij mij staat hij nu op “zon overschot” paars maar batterij status NOM dus die absorbeert dan alle overschot PV stroom. Via een flow zet ik hem nu op STOP. Ik zal dit in de backlog invoeren als verbetering.
Terwijl ik dit schrijf verandert hij bij max eigen gebruik paars naar blauw ONTLADEN. Om 18:00 ineens een kwartier op LADEN. Waarom doet het algoritme dit is de vraag.
