Praktijkreferentie voor lokale aansturing, planning en debugging. Gericht op gevorderde gebruikers die prijssturing, Solcast, AppDaemon en eigen logica willen combineren zonder eerst in alle valkuilen te stappen.
Dit zijn de punten die in de praktijk het meeste uitmaakten. Bij elk punt staat meteen waar je in code of configuratie naar wilt kijken.
mode == "charge", power = -2500SOLAR_MARGIN = 0.70SOC_MIN = 10.0, SOC_MAX = 95.0self.laad_slots, _slot_id()CONSERVATISM_MARGIN = 0.10if mode == "charge":
power = -2500 # negatief = laden
elif mode == "discharge":
power = 2500 # positief = ontladen
else:
mode = "Auto"Het grootste deel van de verwarring zit meestal niet in de accu, maar in de gekozen communicatielaag en de rolverdeling tussen integraties.
“Local API over LAN” betekent in de praktijk vaak gewoon: lokaal IP-verkeer op je eigen subnet, terwijl de Marstek zelf via WiFi verbonden is. Dat is op zich prima zolang je netwerk stabiel is.
- Vast IP of DHCP reservation
- Geen client isolation op guest wifi
- Goede 2.4 GHz dekking
- Geen power saving rare fratsen in AP
- Packet loss testen vanaf HA host
- Controleren of UDP 8000 lokaal bereikbaar isZie de app als bootstrap-tool. Goed voor eerste setup en controles, maar niet als primaire orkestratielaag wanneer je met planning, logging en fallback werkt.
De relevante vraag is niet welke integratie theoretisch de beste is, maar welke taak je aan welke route toewijst.
Voorkeursmodel: API voor write-path, BLE als aanvullende read-path. Niet omdat het elegant is, maar omdat je observability en fallback vaak belangrijker zijn dan architecturale zuiverheid.
Eerst de write-path bewijzen met een minimale handtest. Pas daarna automation-logica debuggen.
echo '{"data":{"value":{"limit_type":"passive","value1":0,"value2":0}}}' | \
nc -u -w1 192.168.178.XXX 8000Hier zit het verschil tussen “er draait iets” en “het systeem maakt slimme keuzes zonder zichzelf tegen te werken”.
Forecast is input, geen waarheid. Zodra je forecast te optimistisch verwerkt, ga je netladen in uren die je eigenlijk vrij had moeten houden voor eigen opwek.
SOLAR_MARGIN = 0.70
SOLAR_HIGH = 6.0
SOLAR_LOW = 3.010-95% geeft beduidend meer bruikbare tradingruimte dan 20-85%, maar daardoor moet je recovery en periodieke kalibratie serieus nemen.
SOC_MIN = 10.0 en SOC_MAX = 95.0SOC_MIN = 10.0
SOC_MAX = 95.0
CALIBRATION_SOC_MAX = 100.0
CALIBRATION_HOLD_MINUTES = 60Prijsverschil alleen zegt te weinig. Zonder efficiëntieverlies, cycle cost en displaced solar straf je de verkeerde scenario's niet af.
MIN_SPREAD = 0.08
CONSERVATISM_MARGIN = 0.10Een bruikbare planner heeft meestal minstens drie regimes nodig, plus een correctiemechanisme voor de avondreserve.
Solcast < 3.0 kWh -> ARBITRAGE
Solcast 3.0-6.0 kWh -> HYBRID
Solcast > 6.0 kWh -> SOLAR_PRIORITYDe planner staat of valt met observability, helpers en deploymenthygiëne. Juist daar gaan veel uren verloren.
input_text.marstek_laad_slots
input_text.marstek_ontlaad_slotsEen van de nuttigste verbeteringen is overstappen van uurgetallen naar datum-tijd-slots met timezone.
Voor:
[3, 4]
Na:
["2026-03-13T03:00:00+01:00", "2026-03-13T04:00:00+01:00"]# Backup actieve versie
cp /addon_configs/a0d7b954_appdaemon/apps/marstek_simple.py \
/config/apps/marstek_simple_backup_$(date +%Y%m%d_%H%M%S).py
# Nieuwe versie deployen
cp /config/apps/marstek_simple_v3.6.0.py \
/addon_configs/a0d7b954_appdaemon/apps/marstek_simple.py
# Restart AppDaemon
ha apps restart a0d7b954_appdaemon
# Check startup
ha apps logs a0d7b954_appdaemon | grep "v3.6.0"
# Check errors/warnings
ha apps logs a0d7b954_appdaemon | grep -iE "(error|warning)" | tail -50Geen generieke best practices, maar concrete fouten die tijd kostten en die je liever in één keer voorkomt.
[3,4] lijkt voldoende totdat de daggrens verschuift of AppDaemon herstart.
Forecast als feit behandelen creëert displaced solar en verkeerde laadblokken.
“Goedkoop erin, duur eruit” is te simpel zodra je efficiëntieverlies en cyclusslijtage meeneemt.
Automation debuggen terwijl de directe local control test nog niet hard bewezen was, kost onnodig veel tijd.
Kleine entity-id mismatches of onhandige helperkeuzes breken persistence en observability.
Meer slimheid in de planner is waardeloos als de input-data of state-overgangen nog wiebelen.
# Scheduler draait?
ha apps logs a0d7b954_appdaemon | grep "Scheduler"
# SOC sensor actueel?
ha core states get sensor.mst_vnse3_3bd3_state_of_charge
# Solcast-logica zichtbaar?
ha apps logs a0d7b954_appdaemon | grep "Solcast"
# Handmatig planning triggeren
# Developer Tools -> Events
# Event type: marstek_trigger_planningNee. Voor veel setups is API de write-path en BLE de extra read-path of fallback.
Omdat dagelijkse trading hier bewust binnen 10-95% blijft. De stap naar 100% is bedoeld voor periodieke kalibratie en balancing.
Omdat forecast geen gemeten werkelijkheid is. Timing en lokale omstandigheden zorgen snel voor verkeerde aannames.
Omdat planning anders ambigu wordt rond middernacht of na een restart. Dat zijn precies de fouten die lastig te reproduceren zijn.
Dat een werkend handcommando automatisch betekent dat de complete plannerarchitectuur ook goed staat.
Nee. Firmware, netwerk, prijsbron, forecastbron, huishoudprofiel en integratiepad verschillen per gebruiker.
Deze prompt is bedoeld voor een AI-assistent die eerst de juiste vragen stelt, verschillen per setup expliciet maakt en daarna pas een implementatieplan oplevert.
Gebruik deze prompt in een AI-tool naar keuze. De assistent moet eerst inventariseren, dan valideren en pas daarna concrete YAML, automations, AppDaemon-code of debugstappen voorstellen.
Help mij mijn Marstek-integratie in Home Assistant in 1x goed op te zetten.
Stel eerst alle ontbrekende vragen over firmware, netwerk, API/BLE, prijsbron,
forecastbron, gewenste strategie, veiligheidsgrenzen, logging en deployment.
Geef pas daarna een concreet en reproduceerbaar implementatieplan.