[APP][Pro] SlimLaden Thuis & Auto

Versie 9.9.2 sinds gisternacht.

Laadpaal uitzetten. Geen verschil.

Informatie Megane maakt geen verschil.

Herberekenen. Geen verschil.

Geen probleem dus, maar wel raar als je verwacht dat het laadschema berekent wordt zodra je aankoppeld. Het voordeel is wel dat je al het optimale laadschema EV hebt voordat er geregistreerd wordt dat je inplugt/thuis bent. Ik merk inderdaad dat de Renault app niet altijd zo snel is met registreren/doorgeven dat je inplugged/begint met laden. De laadpaal-app weet het wel meteen.

Zolang het de algehele planning/leercurves niet in de weg zit dus lekker zo laten.

En vandaag weer een kleine laadsessie achter de rug (mijn vrouw wilde 13:30 vertrekken, dus optie “volgende vertrektijd” gebruikt. Was slechts paar kWh wat er nog bij kon, maar wel mooie test.

Ging helemaal zoals je mag verwachten. Ev laden gaf netjes aan dat hij de ingestelde limiet niet kon bereiken, en dat er xx kWh niet kon laden voor het ingestelde tijdstip. Laadplan werd vrijwel meteen berekend en laden startte onmiddellijk. Blij mee

Mijn optie die Ik hiervoor gebruikte (ANWB SlimLaden) begint overigens steeds meer kuren te krijgen. Ik was uitgelogd in de iOS app en inloggen lukte niet meer. Foute inloggegevens meldt de app (zitten in digitale kluis, dus is onzin). Wachtwoord reset werkt ook niet. Dan maar nieuw account aanmaken en zowaar ik kom er weer in. (Wachtwoord en user opgeslagen) even uitloggen en daarna kan je wederom niet meer inloggen. Wat een drama. Maar gelukkig hebben we nu Slim laden in deze app.

Wel nog even verder gezocht bij de ANWB app. Op een forum kwam ik tegen dat de app gaat stoppen. Hij staat ook niet meer in de App Store.

Ook nog even de app van de achterliggende partij die de techniek levert (ev Energy) geladen en daar kan ik dus wel gewoon inloggen uitloggen en werkt gewoon. Maar denk dat het mijn backup blijft en ev SlimLaden van Roedi mijn eerste keuze.

@Keizer Dit is wat ik en jij bedoelen. Zonneopbrengst valt tegen (paar flinke buien) dus zonneladen levert te weinig op. Dus besluit laadplan langer door te gaan met zonneladen. Ik denk dat geforceerd laden van het net beter was geweest (prijsverschil is 3 ct en teruglever vergoeding 2ct) gaat hier echt om paar centen, maar toch.

Boostladen knop dan toch maar ingedrukt :winking_face_with_tongue:

EV blijven proberen/onderzoeken want, ik kwam erachter dat mijn laadpaal veel signalen kreeg.
(Er staat trouwens geen auto aan de laadpaal, maar 50 km verderop.)
Ga uit, ga aan. (binnen 1 minuut) elke 5 minuten ongeveer?

Bij Inrichting - Capability toewijzing

Functie - Capability - Waarde

Auto aangesloten
paal meldt: geen stekkerstatus → hij plant ook zonder auto - [automatisch - niets gevonden] - [-]

Dit heb ik nu gewijzigd in:
Auto verbonden:aangesloten bij true - [is_connected] - [false]

Het gevolg: Nog geen laadplan - verschijnt binnen 5 minuten. Dus …operatie succesvol.

Hoi Roedi,

Supertevreden van je app, die doet perfect wat ik wil en zelfs meer.
Graag had ik nu het EV gedeelte getest, enkel heb ik wat kleinere probleempjes.

  1. het merk van mijn laadpaal staat er niet in (Smappee), maar dit leek me niet onoverkomelijk dus dit kan als een nice-to-have worden gezet
  2. Echter, ik heb twee EV’s (technisch gezien één EV en één hybride) en als ik dit wil instellen via de app, dan kan ik de SOC slechts inlezen van één van beide EV’s waardoor hij telkenmale maar één van beide auto’s perfect kan uitlezen. Is er een mogelijkheid dit uit te breiden zodat hij ziet welke auto ingeplugged wordt adhv de laadcapaciteit?

@Roedi_de_Lion Nou ik gekeken heb bij inrichting - capability toewijzing zie ik daar ook (weer) staan “Vermogen instellen” (ampere regeling (als de paal het kan) )

Mijn paal (go e-charger) kan dat en doet dat via “Stroom limiet”. Die heb ik als Dan-kaart in de go-echarger app, maar die staat niet in het uitklapmenu. Is dat iets wat door jou toe te voegen is?

Hoi Roedi,

Dank voor je super app!

Ik loop sinds vandaag tegen een aanhoudend probleem aan met de Marstek Open API-communicatie (3 batterijen, UDP poort 30000, geen MQTT/Lilygo).

**Setup**: 3x Marstek Venus E (één per fase), aangestuurd via “Marstek - Open API (UDP poort 30000)”. Multi-batterij NOM modus op Sequentieel (SOC-gebaseerde rotatie). Geen andere Marstek-app meer actief (Batterijconnector-app staat uit).

**Symptoom**: de accu’s laden niet, ook niet als ik dat handmatig forceer. Foutenlog (Fouten & Bronnen, Laadplan Controller):

```

20-08 14:52 t/m 14:57 (herhaaldelijk, 15+ meldingen):

[MarstekAPI] [API] ES.GetStatus failed (API queue full - too many pending requests), Bat.GetStatus fallback also failed: API queue full - too many pending requests

20-08 15:07:

[MarstekAPI] [API] Error (failures: 1): Timeout waiting for ES.GetStatus

```

**Wat ik al heb geprobeerd**:

1. De Laadplan Controller / SlimLaden-app 2x herstart — hielp tijdelijk (accu’s laadden een paar minuten), maar het patroon kwam terug.

2. Bevestigd dat alle drie de accu’s gewoon bereikbaar zijn via de officiële Marstek-app (dus geen netwerk-/hardwareprobleem aan de accu-kant).

3. Bevestigd dat er geen andere app meer op dezelfde lokale UDP-poort/accu’s zit (Marstek Batterijconnector staat uit).

4. Handmatig “Laden” geforceerd via Besturing → Handmatige actie, mét “Huidige actie handhaven” aan — dus het automatische plan kan dit niet overschrijven. Toch stopt het laden na een tijdje weer, precies gecorreleerd met bovenstaande foutmeldingen.

Dat laatste punt lijkt me het duidelijkste bewijs dat dit geen planningsprobleem is maar een uitvoeringsprobleem: zelfs een geforceerd, vastgehouden LADEN-commando komt niet betrouwbaar aan bij de accu’s.

**Vraag**: is de queue-capaciteit voor de Open API mogelijk niet berekend op 3 batterijen × 2 status-calls (ES.GetStatus + Bat.GetStatus) per pollcyclus? Of is dit iets anders — een bekende bug, of specifiek voor mijn situatie?

Laat het weten als je meer info nodig hebt (bv. exacte instellingen API-vertraging/retry-timeout, die staan nu op de defaults: 2000ms / 300s).

Bedankt!

Ze gebruiken de naam van je app :face_with_symbols_on_mouth:

In de “oude” versie kon je fouten heel makkelijk verwijderen als je ze gezien had. Hier kan ik dat niet vinden.

Ik heb dit opgelost door met de Virtual Devices app een virtueel apparaat “Ingeplugde auto” te maken. Die heb ik gekoppeld aan de SlimLaden app. Via een flow vul ik de ingeplugde auto met de SoC van de auto die daadwerkelijk is aangesloten:

De flow is iets complexer dan je zou verwachten. Dat komt omdat de Fiat API alleen update als je daadwerkelijk aan het rijden bent. Vandaar dat ik of de Fiat is ingeplugd moet afleiden uit het feit dat er a) een auto is ingeplugd, b) de Fiat thuis is en c) niet de Polestar is ingeplugd. Omdat de SoC van de Fiat inet wordt geupdate tijdens het laden (want alleen tijdens het rijden) bereken ik de live SoC door de laatst bekende SoC te pakken en daar het bijgeladen SoC bij op te tellen. Dat laatste kan ik berekenen door vanuit de Zappi te kijken hoeveel kWh er is bijgeladen sinds de auto is aangesloten en dat de delen op 42 kWh, de capaciteit van de accu van de Fiat.

Gaat dacht ik weg de volgende dag of update :eyes:

slimme, maar complexe flow @Koen_Crijns ! ik probeer hier altijd van te leren…

Kan alleen lokaal bij Diagnostiek en dan een beetje naar beneden scrollen:

Kleine update: probleem is nog steeds actief, ook na herstart en instellingen terugzetten (Sequentieel + “Automatisch” NOM-regelaar, API-vertraging naar 4000ms). Binnen enkele minuten weer dezelfde queue-full-meldingen.

Twee nieuwe foutmeldingen erbij sindsdien:

```

[MQTTManager] [API] Failed STOP for battery1: Timeout waiting for ES.SetMode

[MarstekAPI] [API] ES.SetMode FAILED after 8 attempts: Timeout waiting for ES.SetMode

[MarstekAPI] [API] Error (failures: 3): Timeout waiting for Wifi.GetStatus

```

Opvallend: de `[MQTTManager]`-tag, terwijl ik op Open API zit, geen MQTT. Mogelijk een verkeerd gelabeld logbericht, maar wilde het toch even melden.

Vermoeden: een individueel verzoek dat geen antwoord krijgt, laat zijn plek in de wachtrij niet vrij — waardoor die zich blijft opstapelen tot “queue full”, en uiteindelijk de socket omvalt. Zou dat kunnen kloppen?

Vraagje:

Welke minimale winstmarge hebben jullie ingevuld? Ik heb nu 75ct. maar ik heb geen idee wat gemiddeld haalbaar is.

*Overige waardes zoals afschrijving gewoon ingevuld zoals het hoort.

Ik heb 0,50 ct ingevuld. Even kijken of dat bevalt .

Ja die weet ik, maar wellicht dat dit ook nog in de webversie gemaakt kan worden?

Waar? Geen idee welke marge jullie het over hebben. Maar als dat per kWh is dan komt dat niet vaak voor :winking_face_with_tongue:

nieuwe laad test. Sessie gestart op duur moment en in een situatie dat de sessie over twee blokken verdeeld moet worden voor de goedkoopste uren Vertrektijd morgen 11:30.
Ev aangesloten, en er rolt vrijwel onmiddellijk een laadplan uit.

  • auto gaat onmiddellijk op pauze (stroom is nu duur)
  • Netjes in 2 blokken verdeeld op de goedkoopste uren

Nu maar hopen dat er morgen om 11:30 idd 80% in de autoaccu zit :wink:

Maar zover dik tevreden oven de combinatie

  • EMS: Slimladen
  • Laadpaal: Alfen singel EVE Pro
  • EV: Tesla Y