Het grote Indevolt thuisbatterij topic

[Xirt]

Xirt schreef op dinsdag 20 januari 2026 @ 10:44:
[...]

Je kan de working modus via een service wijzigen. De reden hiervoor is dat het Gen-1 model een fysieke knop heeft om 'm in standalone (portable) modus te zetten: in deze modus kan je dus niets met de API aansturen en dat kan ik in een service afvangen.

Misschien dat ik een Gen-2 only drop-down kan maken. Met het Gen-1 verhaal hierboven als motivatie voor het bestaan van de service (die is dan eigenlijk redundant voor Gen-2). Ga ik naar kijken.

Done - alleen even afwachten of Home Assistant deze approach ook goed gaat keuren aangezien de service nu overlapt met de configuratie voor Gen-2. Eerst maar eens de integraite uberhaupt in de core krijgen .

[eppo16]

Gijs4 schreef op dinsdag 20 januari 2026 @ 18:22:
Thuisbatterij heeft de prijzen vandaag iets verhoogd zie ik.

Dat is dé januari aanbieding.

[Jan Workum]

Ross11 schreef op dinsdag 20 januari 2026 @ 21:44:
Indevolt is nog niet zo lang bezig op de accu markt. Lees niet over gebruikers die problemen hebben met deze accu's en de eventuele garantie afhandeling.
Dit omdat er bij de introductie van de HW accu toch wel de nodige problemen waren.
Vind het wel een leuk setje en de Energienerts waren er ook wel over te spreken, maar !
Is er iets bekend, bij iemand, over problemen/ garantie afhandeling of juist geen problemen, of zijn er gewoon nog niet genoeg in omloop om hier een oordeel over te geven.

Nu een maand PowerFlex 6kWh in gebruik en geen enkel issue. Doet keurig z'n nul op de meter werk.

[AquilaXL]

eppo16 schreef op woensdag 21 januari 2026 @ 06:37:
[...]

Dat is dé januari aanbieding.

Ja die "aanbieding" is weg en dat terwijl januari nog lang niet is afgelopen. Daarnaast was hij volgens de socials ook bijna uitverkocht maar hij blijkt gewoon voorradig. Het is maar net hoe je het verkoopt zo blijkt.

[Jessy007]

AquilaXL schreef op woensdag 21 januari 2026 @ 19:56:
[...]


Ja die "aanbieding" is weg en dat terwijl januari nog lang niet is afgelopen. Daarnaast was hij volgens de socials ook bijna uitverkocht maar hij blijkt gewoon voorradig. Het is maar net hoe je het verkoopt zo blijkt.

Nu komen de dilemma’s weer welken moet ik kopen 😂 ik denk dat ik beter even kan wachten.

[EricDi]

Vraag:

Ik heb twee powerflexes in een draadloze cluster gezet. Beide staan nu op een aparte gedeelde groep. Dus ik cap ze beide individueel tot 800w. Probleem is dat het cluster nu in totaal niet meer dan 800w trekt.

In het Nettolading scherm staan beide apparaten op 800w. Zelfs als ik één aparaat op 1000w zet gaat het niet hoger dan 800w.

Dit lijkt mij een bug? Of is dit verwacht gedrag?

[johansen]

EricDi schreef op donderdag 22 januari 2026 @ 10:10:
Vraag:

Ik heb twee powerflexes in een draadloze cluster gezet. Beide staan nu op een aparte gedeelde groep. Dus ik cap ze beide individueel tot 800w. Probleem is dat het cluster nu in totaal niet meer dan 800w trekt.

In het Nettolading scherm staan beide apparaten op 800w. Zelfs als ik één aparaat op 1000w zet gaat het niet hoger dan 800w.

Dit lijkt mij een bug? Of is dit verwacht gedrag?

Ik had dit een paar posts hierboven ook al opgemerkt. Lijkt mij een bug, ik wilde deze nog wel even bij ze melden. Workaround is om tijdens het chargen het cluster even te disbanden. Niet ideaal maar het is even niet anders.

[Xirt]

Ik ben benieuwd of dat een bug is vanuit de app of vanuit het apparaat. Indien mogelijk: probeer de configuratie eens in te stellen via de API (direct of via Home Assistant) om te kijken wat dat doet.

[sysiwan]

GrensDeal (geen garantie)
https://www.mydealz.de/de...00-71kwh-speicher-2715011

[JeroenH2025]

Ik heb sinds een aantal weken de SolidFlex (7,1kw) en heb hem ingesteld op zelf-consumptie. Werkt allemaal prima, alleen valt me 1 ding op: nadat de batterij 100% is volgeladen blijft hij constant doorladen. Op een zonnige dag is hij na 3 uur volgeladen en als ik hem dan niet zelf op standby zet gaat alle energie verloren. Ik had verwacht dat hij bij 100% alle overtollige zonnestroom gewoon weer het net opstuurt.
Ik heb dit nu met HA kunnen oplossen, door de batterij bij 100% SOC in standby te zetten en dan 's avonds weer in zelfconsumptie zodat ik de avond en de nacht kan ontladen.
Meer mensen die dit constateren en hoort dit zo te werken in zelf consumptie mode?

[mrme12345]

JeroenH2025 schreef op donderdag 22 januari 2026 @ 13:35:
Ik heb sinds een aantal weken de SolidFlex (7,1kw) en heb hem ingesteld op zelf-consumptie. Werkt allemaal prima, alleen valt me 1 ding op: nadat de batterij 100% is volgeladen blijft hij constant doorladen. Op een zonnige dag is hij na 3 uur volgeladen en als ik hem dan niet zelf op standby zet gaat alle energie verloren. Ik had verwacht dat hij bij 100% alle overtollige zonnestroom gewoon weer het net opstuurt.
Ik heb dit nu met HA kunnen oplossen, door de batterij bij 100% SOC in standby te zetten en dan 's avonds weer in zelfconsumptie zodat ik de avond en de nacht kan ontladen.
Meer mensen die dit constateren en hoort dit zo te werken in zelf consumptie mode?

Laat je hem vaak naar 100% gaan? Want het is bekend bij LFP batterijen dat ze moeite hebben om het percentage te bepalen, zeker bij een hoog of laag niveau. De batterij kan dan aangeven dat die op 100% zit op basis van voltage, maar in werkelijkheid zal dat nog niet het geval zijn. Je kunt het beste de batterij gewoon zijn gang laten gaan en als die echt helemaal vol is stopt die vanzelf en daarbij niet teveel op het percentage letten. Het is ook goed om de batterij minimaal 1 x per week of 2 weken helemaal vol te laden (dus tot die zelf stopt), daarmee is die weer gebalanceerd en zal die ook beter het werkelijke percentage van lading kunnen bepalen.

[JeroenH2025]

mrme12345 schreef op donderdag 22 januari 2026 @ 13:42:
[...]

Laat je hem vaak naar 100% gaan? Want het is bekend bij LFP batterijen dat ze moeite hebben om het percentage te bepalen, zeker bij een hoog of laag niveau. De batterij kan dan aangeven dat die op 100% zit op basis van voltage, maar in werkelijkheid zal dat nog niet het geval zijn. Je kunt het beste de batterij gewoon zijn gang laten gaan en als die echt helemaal vol is stopt die vanzelf en daarbij niet teveel op het percentage letten. Het is ook goed om de batterij minimaal 1 x per week of 2 weken helemaal vol te laden (dus tot die zelf stopt), daarmee is die weer gebalanceerd en zal die ook beter het werkelijke percentage van lading kunnen bepalen.

Volgens de P1 meter is er al 6KW naar de batterij gegaan zodra die de 100% aantikt en bij ontladen haal ik er ook wel bijna 6KW uit tot de SOC van 10% is bereikt. Maar als ik hem zijn gang laat gaan blijft hij nog uren lang doorladen waardoor er zeker 2 KW extra 'verloren' gaat. Maar ik zal hem inderdaad eens helemaal doorlaten gaan totdat hij zelf stopt en dan meten hoeveel er daadwerkelijk naar de batterij is gegaan

[duvekot]

JeroenH2025 schreef op donderdag 22 januari 2026 @ 15:26:
[...]


Volgens de P1 meter is er al 6KW naar de batterij gegaan zodra die de 100% aantikt en bij ontladen haal ik er ook wel bijna 6KW uit tot de SOC van 10% is bereikt. Maar als ik hem zijn gang laat gaan blijft hij nog uren lang doorladen waardoor er zeker 2 KW extra 'verloren' gaat. Maar ik zal hem inderdaad eens helemaal doorlaten gaan totdat hij zelf stopt en dan meten hoeveel er daadwerkelijk naar de batterij is gegaan

De P1 meter kan helemaal niet meteen hoeveel er naar de batterij is gegaan ...die kan alleen meer de netto ontrekking uit het net of de netto levering aan het net zien ... Voor wat er daadwerkelijk in de batterij gaat of er uit komt moet je echt kijken naar de batterij zelf (of een tussen meter als je die hebt). En stroom kan nooit "verloren" gaan .. het stroomt altijd ergens heen totdat het niet meer kan stromen.

[johansen]

Xirt schreef op donderdag 22 januari 2026 @ 11:46:
Ik ben benieuwd of dat een bug is vanuit de app of vanuit het apparaat. Indien mogelijk: probeer de configuratie eens in te stellen via de API (direct of via Home Assistant) om te kijken wat dat doet.

In HA heb ik nog geen Entities kunnen vinden die betrekking hebben op het cluster. Ik ben pas net nieuw in de wereld van HA, dus misschien kun je me op het goede pad sturen waar ik kan zoeken

[Xirt]

Op dit moment zijn er nog geen specifieke entities in de integratie hiervoor, maar ik heb wel de datapunten gekregen om main/sub te onderscheiden (moet ik nog toevoegen). Waar ik op doelde is dat je volgens mij de drie apparaten toe zou voegen in HA en dan zou je voor alledrie de instellingen vanuit daar in kunnen stellen i.p.v. via de app. Op die manier omzeil je eventuele bugs / limitaties in de app.

[johansen]

Xirt schreef op donderdag 22 januari 2026 @ 19:40:
Op dit moment zijn er nog geen specifieke entities in de integratie hiervoor, maar ik heb wel de datapunten gekregen om main/sub te onderscheiden (moet ik nog toevoegen). Waar ik op doelde is dat je volgens mij de drie apparaten toe zou voegen in HA en dan zou je voor alledrie de instellingen vanuit daar in kunnen stellen i.p.v. via de app. Op die manier omzeil je eventuele bugs / limitaties in de app.

Ah op die fiets. Ja, zo'n dashboard had ik eerder deze week al gemaakt. Ik kan per device de limieten ingeven in HA. Maar als je je Indevolts als cluster hebt draaien, worden de individuele Inverter input limits niet gebruikt. Ik heb ze op 800/1200/800 staan, maar het cluster laadt dan in totaal niet sneller dan 800W (en deze middag ook even 1200W). Ik zou verwachten dat het cluster dan kijkt naar de instellingen per device, en dan binnen het cluster device 1 met max 800w laadt laden, device 2 met max 1200w en device 3 met max 800w. DUs in totaal max 2800W (en geen 800 of 1200W).

Bij het ontladen werk het namelijk wel goed. Daar worden wel de indidivuele instellingen (max AC output power) gebruikt binnen het cluster en dus bij elkaar opgeteld.

Hopelijk heb ik het een beetje helder kunnen duiden

Hieronder een stuk HA dashboard van de Indevolts:

[Xirt]

Dat klinkt als iets dat dan echt in het device zit. Niet in de app of een andere coordinator (HA). Indevolt heeft regelmatig firmware updates met verbeteringen dus dit is wel iets dat mogelijk interessant is om te melden.

Ik heb zelf vandaag twee outliers gezien zonder log record (timeouts e.d. zouden in log moeten komen). Ik kan dit waarschijnlijk wel afvangen in de integratie, maar ik vroeg mij af of dit aan mijn opstelling / verbinding ligt of dat dit vaker voorkomt?

[duvekot]

Xirt schreef op donderdag 22 januari 2026 @ 22:49:
Dat klinkt als iets dat dan echt in het device zit. Niet in de app of een andere coordinator (HA). Indevolt heeft regelmatig firmware updates met verbeteringen dus dit is wel iets dat mogelijk interessant is om te melden.

Ik heb zelf vandaag twee outliers gezien zonder log record (timeouts e.d. zouden in log moeten komen). Ik kan dit waarschijnlijk wel afvangen in de integratie, maar ik vroeg mij af of dit aan mijn opstelling / verbinding ligt of dat dit vaker voorkomt?

[Afbeelding]

Dat ziet er meer uit alsof het ophalen van metrics mislukt is .. en daardoor maar een "0" geregistreerd is .. ipv "null" .. of een gevolg hoe de grafiek omgaat met ontbreken data. (Komt me bekend voor uit Grafana/Prometheus nml)

[Xirt]

Het interessante is dat ik negatieve SOC values krijg (zowel op master als packs enkele occurrences), 0.12KhW voor Total Discharge, etc. Dat lijkt dus anders dan een echte nulwaarde. Ik krijg ook geen foutmelding voor het falen van de API call (dit wordt afgevangen in de code) en verachillende sensoren hebben de outliers op verschillende momenten. Ik zal in mijn lokale omgeving anders elke call gaan loggen om te kijken of ik outliers terug kan vinden in de waarden vanuit de API payload.

Afhankelijk van de bron kan Indevolt er naar kijken of kan ik eventueel de code aanpassen om outliers af te vangen voordat ze de statistieken in gaan. Of beiden... To be continued.

[duvekot]

Xirt schreef op donderdag 22 januari 2026 @ 23:20:
Het interessante is dat ik negatieve SOC values krijg (zowel op master als packs enkele occurrences), 0.12KhW voor Total Discharge, etc. Dat lijkt dus anders dan een echte nulwaarde. Ik krijg ook geen foutmelding voor het falen van de API call (dit wordt afgevangen in de code) en verachillende sensoren hebben de outliers op verschillende momenten. Ik zal in mijn lokale omgeving anders elke call gaan loggen om te kijken of ik outliers terug kan vinden in de waarden vanuit de API payload.

Afhankelijk van de bron kan Indevolt er naar kijken of kan ik eventueel de code aanpassen om outliers af te vangen voordat ze de statistieken in gaan. Of beiden... To be continued.

Negative SoC klinkt wel apart idd

Voor je het weet heb je "dark matter" of een begin van wat uiteindelijk een "zpm" werd

Voor debug is een geheel apart tool die de calls doet en de data ophaalt misschien handig. Die stopt de data direct in een MQTT .. en daar dan verder naar kijken.

Of zitten verschillende zaken elkaar in de weg? Dus dat zowel de app van Indevolt en je HA op het zelfde moment de boel proberen op te halen?

(Of kan je via de API ook "historische" data ophalen?)

[Xirt]

Issue lijkt in het apparaat zelf te zitten. Ik log nu elke response (om de 30s) en kon op basis van mijn outliers vrij snel het probleem in mijn log vinden:



Dit is het voorbeeld van Total Charging Energy, maar ik vermoed dat de rest eenzelfde soort probleem gaat hebben (bij de bron). Op dit moment wacht ik nog antwoord af op een aantal andere vragen, dus ik wacht even met contact opnemen om Indevolt te vriend te houden. Wel ga ik even kijken of ik de outliers af kan vangen in de code (startend met de "increasing over time"-sensoren).

[duvekot]

Xirt schreef op vrijdag 23 januari 2026 @ 09:00:
Issue lijkt in het apparaat zelf te zitten. Ik log nu elke response (om de 30s) en kon op basis van mijn outliers vrij snel het probleem in mijn log vinden:

[Afbeelding]

Dit is het voorbeeld van Total Charging Energy, maar ik vermoed dat de rest eenzelfde soort probleem gaat hebben (bij de bron). Op dit moment wacht ik nog antwoord af op een aantal andere vragen, dus ik wacht even met contact opnemen om Indevolt te vriend te houden. Wel ga ik even kijken of ik de outliers af kan vangen in de code (startend met de "increasing over time"-sensoren).

Interesting 🤔 ... Omdat alles via WiFi gaat ..zou je eens kunnen kijken naar de netwerk logs van de AP waarmee die verbinding heeft (of een aparte losse AP maken zodat je zeker weet waar die verbinding mee heeft) en eens kijken naar het aantal verzoeken wat er op die tijdstippen binnen komen ... Die CPU in de accu heeft ook geen oneindige capaciteit .. dus loopt misschien wel tegen zijn limieten aan? Of als het echt op xx min : 30sec en xx min: 00sec opgevraagd wordt .. wie weet zit er dan een andere proces in de weg? Dus wat als het :12sex en :42sex wordt? Zit er een patroon in het tijdstip waarop het faalt?

Leuke debug uitdaging .. maar voor mij makkelijk praten .. ik heb niet zo'n accu hier staan

[Sjorsl820]

Xirt schreef op donderdag 22 januari 2026 @ 22:49:
Dat klinkt als iets dat dan echt in het device zit. Niet in de app of een andere coordinator (HA). Indevolt heeft regelmatig firmware updates met verbeteringen dus dit is wel iets dat mogelijk interessant is om te melden.

Ik heb zelf vandaag twee outliers gezien zonder log record (timeouts e.d. zouden in log moeten komen). Ik kan dit waarschijnlijk wel afvangen in de integratie, maar ik vroeg mij af of dit aan mijn opstelling / verbinding ligt of dat dit vaker voorkomt?

[Afbeelding]

Dacht al dat het aan mij lag, ik haal er om de dag (ongeveer) ook een outlier uit. Bijvoorbeeld;

[Xirt]

duvekot schreef op vrijdag 23 januari 2026 @ 09:25:
[...]

Interesting 🤔 ... Omdat alles via WiFi gaat ..zou je eens kunnen kijken naar de netwerk logs van de AP waarmee die verbinding heeft (of een aparte losse AP maken zodat je zeker weet waar die verbinding mee heeft) en eens kijken naar het aantal verzoeken wat er op die tijdstippen binnen komen ... Die CPU in de accu heeft ook geen oneindige capaciteit .. dus loopt misschien wel tegen zijn limieten aan? Of als het echt op xx min : 30sec en xx min: 00sec opgevraagd wordt .. wie weet zit er dan een andere proces in de weg? Dus wat als het :12sex en :42sex wordt? Zit er een patroon in het tijdstip waarop het faalt?

Leuke debug uitdaging .. maar voor mij makkelijk praten .. ik heb niet zo'n accu hier staan

Ik haal alle sensorwaarden tegelijk op (one call), maar slechts enkele waarden geven outliers: steeds een andere waarde op een ander moment. Dit lijkt me echt meer iets voor Indevolt om te onderzoeken .

Update: Toch alvast gemaild naar Indevolt...

[Xirt]

Alsof ze onze chat in de gaten houden...

[EricDi]

johansen schreef op donderdag 22 januari 2026 @ 11:20:
[...]

Ik had dit een paar posts hierboven ook al opgemerkt. Lijkt mij een bug, ik wilde deze nog wel even bij ze melden. Workaround is om tijdens het chargen het cluster even te disbanden. Niet ideaal maar het is even niet anders.

[Afbeelding]

[Afbeelding]

Dit probleem lijkt vandaag bij mij opgelost te zijn. De cluster laad nu met meer dan 800w.

[johansen]

Er staat nu idd een nieuwe firmware versie klaar zie ik

[Jessy007]

Xirt schreef op vrijdag 23 januari 2026 @ 13:14:
Alsof ze onze chat in de gaten houden...

[Afbeelding]

Ze weten zelfs hoelang we op de wc zitten 😂😳

[eMKa]

jeweetwel2 schreef op maandag 19 januari 2026 @ 21:41:
[...]

Ja , ging ook weer weg na een paar uur

Ben sinds gisteren eigenaar van een Indevolt systeem en de Solarmann P1 meter. Ik heb ook dit probleem, maar bij mij is het nog niet na een paar uur opgelost. Ik heb ook alle indicaties dat hij zou moeten werken. Op 2.4Ghz netwerk, zichtbaar in netwerk en pingbaar maar geen werking / groen logo in de app.

Iemand tips wat te doen?

Edit: Opgelost. Moet je wel de uplink vanuit de meter op de invoer P1 (splitter) aansluiten, duh!

[ Voor 8% gewijzigd door eMKa op 24-01-2026 08:51 ]

[EricDi]

Het laden in een cluster is nog steeds bugged.

Een tijdelijke oplossing is om de nettolading per batterij in te stellen op de gewenste totale gedeelde lading. I.e. instellen op 1600w per batterij zorgt voor 800w per batterij in een cluster van twee batterijen.

Hopelijk lossen ze dit snel op

[ Voor 243% gewijzigd door EricDi op 24-01-2026 12:40 ]

[wjhuberts]

Ik heb het topic en de nodige reacties zitten doorlezen, maar daarmee zijn al mijn vragen nog niet beantwoord.

Eerst even de situatie schets:
Heb thuis een 3-fasen aansluiting. Heb daarnaast een tweetal sets zonnepanelen, ieder met een eigen 1-fase omvormer, die op 2 verschillende fasen zijn aangesloten.

Ik overwoog in eerste instantie om een powerflex systeem aan te schaffen met de maximale set aan accu’s en die op een aparte groep aan te sluiten, maar twijfel nu sterk of dat wel de meest ideale oplossing is. Mijn verbruik zit over 3 fasen verdeeld en de teruglevering via de batterij zal dan alleen maar plaatsvinden voor het verbruik wat op die fase zit waar de batterijen ook op aangesloten zitten toch? Het verbruik van de andere fasen zal niet door de capaciteit van de batterij opgevangen worden toch?

Het hele topic doorlezend, zit ik te denken of een 3-fasen opstelling zoals ook in de handleiding getekend een beter alternatief is. Ik zou dan 3 omvormers doen met ieder een extra batterij erachter (totaal dus 4,4 kw per fase). Daarmee is het verbruik van alle 3 de fasen voor een deel gecovered door de batterijen.
Blijft alleen de vraag over hoe het zit met de opbrengst van de zonnepanelen. Op 2 van de 3 fasen heb ik een set zonnepanelen zitten, dus de batterijen op die fasen kunnen met de overcapaciteit van de zonnepanelen op die fasen bijgeladen worden. Maar, die laatste fase, waar geen zonnepanelen aan gekoppeld zitten; Hoe gaat die batterij zich bijladen, er even vanuit gaande dat je de batterijen niet wilt laten bijladen vanuit het net. Ik betwijfel nu of die uberhaupt wel geladen gaat worden. Iemand daar een idee over?

[Jan Workum]

wjhuberts schreef op zaterdag 24 januari 2026 @ 13:01:
Ik heb het topic en de nodige reacties zitten doorlezen, maar daarmee zijn al mijn vragen nog niet beantwoord.

Eerst even de situatie schets:
Heb thuis een 3-fasen aansluiting. Heb daarnaast een tweetal sets zonnepanelen, ieder met een eigen 1-fase omvormer, die op 2 verschillende fasen zijn aangesloten.

Ik overwoog in eerste instantie om een powerflex systeem aan te schaffen met de maximale set aan accu’s en die op een aparte groep aan te sluiten, maar twijfel nu sterk of dat wel de meest ideale oplossing is. Mijn verbruik zit over 3 fasen verdeeld en de teruglevering via de batterij zal dan alleen maar plaatsvinden voor het verbruik wat op die fase zit waar de batterijen ook op aangesloten zitten toch? Het verbruik van de andere fasen zal niet door de capaciteit van de batterij opgevangen worden toch?

Het hele topic doorlezend, zit ik te denken of een 3-fasen opstelling zoals ook in de handleiding getekend een beter alternatief is. Ik zou dan 3 omvormers doen met ieder een extra batterij erachter (totaal dus 4,4 kw per fase). Daarmee is het verbruik van alle 3 de fasen voor een deel gecovered door de batterijen.
Blijft alleen de vraag over hoe het zit met de opbrengst van de zonnepanelen. Op 2 van de 3 fasen heb ik een set zonnepanelen zitten, dus de batterijen op die fasen kunnen met de overcapaciteit van de zonnepanelen op die fasen bijgeladen worden. Maar, die laatste fase, waar geen zonnepanelen aan gekoppeld zitten; Hoe gaat die batterij zich bijladen, er even vanuit gaande dat je de batterijen niet wilt laten bijladen vanuit het net. Ik betwijfel nu of die uberhaupt wel geladen gaat worden. Iemand daar een idee over?

3 batterijen in een cluster op 3 verschillende fasen aangestuurd vanuit de p1 poort van de slimme meter zullen ongeacht of er maar op 2 fasen zonnepanelen zijn aangesloten evenwichtig geladen of ontladen worden. Fysiek gezien: Als je op fase 1 en 2 beiden 1500W pv input hebt (totaal dus 3000W) en op fase 3 niets dan krijgen batterij op fase 1 en 2 elk 1000W pv input en batterij op fase 3 1000W uit het net. Vanuit fase 1 en 2 gaat 2x500W het net op. In de meter wordt de 2x500 netinvoer uit fase 1 en 2 verrekend met de 1000W netgebruik via fase 3, per saldo is dat nul.

[Xirt]

Ik heb de main/sub sensor toegevoegd in de repository: deze diagnostic sensor staat standaard uit (disabled), maar kan ingeschakeld worden door mensen die een cluster hebben.

Indevolt gaf zelf aan dat er maar twee waarden teruggegeven zullen worden vanuit de API (main vs. sub), maar ik kreeg een derde waarde die ik voor nu aangenomen heb als "standalone" (geen cluster). Aangezien ik zelf geen cluster heb zou het heel fijn zijn als mensen met een cluster (bijv. @EricDi @johansen) aan kunnen geven of de informatie bij hun nu juist weergegeven wordt in HA. Bij voorbaat dank!

[AquilaXL]

wjhuberts schreef op zaterdag 24 januari 2026 @ 13:01:
Ik heb het topic en de nodige reacties zitten doorlezen, maar daarmee zijn al mijn vragen nog niet beantwoord.

Eerst even de situatie schets:
Heb thuis een 3-fasen aansluiting. Heb daarnaast een tweetal sets zonnepanelen, ieder met een eigen 1-fase omvormer, die op 2 verschillende fasen zijn aangesloten.

Ik overwoog in eerste instantie om een powerflex systeem aan te schaffen met de maximale set aan accu’s en die op een aparte groep aan te sluiten, maar twijfel nu sterk of dat wel de meest ideale oplossing is. Mijn verbruik zit over 3 fasen verdeeld en de teruglevering via de batterij zal dan alleen maar plaatsvinden voor het verbruik wat op die fase zit waar de batterijen ook op aangesloten zitten toch? Het verbruik van de andere fasen zal niet door de capaciteit van de batterij opgevangen worden toch?

Het hele topic doorlezend, zit ik te denken of een 3-fasen opstelling zoals ook in de handleiding getekend een beter alternatief is. Ik zou dan 3 omvormers doen met ieder een extra batterij erachter (totaal dus 4,4 kw per fase). Daarmee is het verbruik van alle 3 de fasen voor een deel gecovered door de batterijen.
Blijft alleen de vraag over hoe het zit met de opbrengst van de zonnepanelen. Op 2 van de 3 fasen heb ik een set zonnepanelen zitten, dus de batterijen op die fasen kunnen met de overcapaciteit van de zonnepanelen op die fasen bijgeladen worden. Maar, die laatste fase, waar geen zonnepanelen aan gekoppeld zitten; Hoe gaat die batterij zich bijladen, er even vanuit gaande dat je de batterijen niet wilt laten bijladen vanuit het net. Ik betwijfel nu of die uberhaupt wel geladen gaat worden. Iemand daar een idee over?

Ik vermoed dat beide sets zonnepanelen niet exact hetzelfde opwekken. De elektriciteitsmeter ziet wel alle fases maar gebruikt maar 1 telwerk. Omdat de software het totaal vermogen zal splitsen over het aantal accu's, is het onvermijdelijk dat ze ook vanuit het net gaan laden. Als het jouw echt gaat om het puur opvangen van je PV opbrengst dan kan je beter naar een Victron systeem want zo'n stekker-batterijen bied geen waterdichte oplossing voor jouw vraagstuk.

[cdiepenh]

Ha allemaal, sorry ben redelijk nieuw hier in de Indevolt Topic en ik hoop dat ik toch wat vragen kan stellen.

Ik ben van plan om die Power Flex 2000 te kopen en dan mogelijk met 2 extra batterijen maar vraag me inderdaad af of je deze aan elkaar gekoppeld op een aparte groep moet zetten of dat je hem gewoon in een niet te drukke bestaande groep kan bij plaatsen, dus een WCD ergens gebruiken die weinig vermogen gebruikt in die groep.

En deze Power Flex 2000 kunnen ook als nood stroom voorziening werken, moet je dan iets extra doen in de meterkast of bij de automaten?
Of regelt die Indevolt Power flex 2000 dat geheel automatisch ivm de Indevolt app?
Hoor graag .

Ik ben best handig met Elektro maar ben graag wel voorzichtig voordat ik van alles kan knutselen.

Dank allemaal.

[Xirt]

Je kan 'm in met standaardinstellingen gewoon op een bestaande groep gooien waar andere apparaten op zitten. Standaard wordt er dan met maximaal 2400W geladen (max. van een apparaat dat niet op een eigen groep zit) en met 800W teruggegeven (dat is de max. in deze setup). Ik heb 'm zelf op een vrijwel lege groep zitten, met een dedicated kabel vanaf de meterkast (dus ooit krijgt ie z'n eigen groep).

De noodstroom komt uit de WCD op het apparaat. Het is dus niet zo dat het apparaat stroom terug gaat geven naar je normale groepen op het moment dat de stroom eraf ligt (dat mag volgens mij ook niet). Ik heb begrepen dat het switchen naar die WCD wel split-second / automatisch is, maar je zal dus zelf je apparatuur daarop aan moeten sluiten indien nodig (e.g. koelkast bij lage stroomstoring).

[AquilaXL]

cdiepenh schreef op zaterdag 24 januari 2026 @ 22:08:
Ha allemaal, sorry ben redelijk nieuw hier in de Indevolt Topic en ik hoop dat ik toch wat vragen kan stellen.

Ik ben van plan om die Power Flex 2000 te kopen en dan mogelijk met 2 extra batterijen maar vraag me inderdaad af of je deze aan elkaar gekoppeld op een aparte groep moet zetten of dat je hem gewoon in een niet te drukke bestaande groep kan bij plaatsen, dus een WCD ergens gebruiken die weinig vermogen gebruikt in die groep.

En deze Power Flex 2000 kunnen ook als nood stroom voorziening werken, moet je dan iets extra doen in de meterkast of bij de automaten?
Of regelt die Indevolt Power flex 2000 dat geheel automatisch ivm de Indevolt app?
Hoor graag .

Ik ben best handig met Elektro maar ben graag wel voorzichtig voordat ik van alles kan knutselen.

Dank allemaal.

Voor de meeste vragen kan je de zoekfunctie in dit forum gebruiken en dan heb je vrij snel het antwoord. Maar om jou vragen te beantwoorden:

- Als je 800watt ontladen genoeg vind dan kan je hem in een stopcontact stoppen. Een "drukke" of minder "drukke" groep maakt hierin niet uit. Als je wilt dat de accu boven de 800watt gaat ontladen dan dien je een aparte groep in te bouwen.

- Het is voor een stekker-batterij niet mogelijk om je huis te voeden bij spanningsuitval. Op de omvormer zit een stopcontact welke je kan gebruiken om bepaalde apparaten te voeden wanneer er geen stroom is. Er zijn batterijen die wel je huis kunnen voorzien maar dat zijn vaak Victron installaties die bij je meterkast er tussen worden geplaatst.

[duvekot]

cdiepenh schreef op zaterdag 24 januari 2026 @ 22:08:
Ha allemaal, sorry ben redelijk nieuw hier in de Indevolt Topic en ik hoop dat ik toch wat vragen kan stellen.

Ik ben van plan om die Power Flex 2000 te kopen en dan mogelijk met 2 extra batterijen maar vraag me inderdaad af of je deze aan elkaar gekoppeld op een aparte groep moet zetten of dat je hem gewoon in een niet te drukke bestaande groep kan bij plaatsen, dus een WCD ergens gebruiken die weinig vermogen gebruikt in die groep.

En deze Power Flex 2000 kunnen ook als nood stroom voorziening werken, moet je dan iets extra doen in de meterkast of bij de automaten?
Of regelt die Indevolt Power flex 2000 dat geheel automatisch ivm de Indevolt app?
Hoor graag .

Ik ben best handig met Elektro maar ben graag wel voorzichtig voordat ik van alles kan knutselen.

Dank allemaal.

Om met je laatste vraag te starten ...de Indevolt doet helemaal niets/nada/noppes in je meterkast .. en je kan ook niet daar wat aanpassen om de noodstroom uitgang van de Indevolt te gebruiken. Het is eigenlijk niets meer dan een stopcontact (op de Indevolt) waarmee je een apparaat van stroom kan voorzien .. niet een hele groep.

[JooJoo]

Even een vraag over de koppeling van Indevolt met HA en Homey. Hoe groot is de kans dat in de toekomst Indevolt ook met Homey gekoppeld kan worden. Iemand een idee?

[Xirt]

Ik denk dat dat lastig te zeggen is: Homey heeft een kleinere community i.v.m. HA en volgens mij is het aantal beschikbare apps ook een stuk kleiner dan het aantal integraties dat HA heeft. Het duurt daardoor mogelijk langer dan bij HA.

Maar iedereen kan een app maken en de documentatie van de API van Indevolt is beschikbaar en wordt nog steeds verbeterd: het is dus eigenlijk wachten op een Homey + Indevolt gebruiker die het oppikt (net als ik nu voor HA heb gedaan).

[EricDi]

Xirt schreef op zaterdag 24 januari 2026 @ 21:15:
Ik heb de main/sub sensor toegevoegd in de repository: deze diagnostic sensor staat standaard uit (disabled), maar kan ingeschakeld worden door mensen die een cluster hebben.

Indevolt gaf zelf aan dat er maar twee waarden teruggegeven zullen worden vanuit de API (main vs. sub), maar ik kreeg een derde waarde die ik voor nu aangenomen heb als "standalone" (geen cluster). Aangezien ik zelf geen cluster heb zou het heel fijn zijn als mensen met een cluster (bijv. @EricDi @johansen) aan kunnen geven of de informatie bij hun nu juist weergegeven wordt in HA. Bij voorbaat dank!

Ik heb geupdate, maar zie nog geen cluster info.

[johansen]

EricDi schreef op zondag 25 januari 2026 @ 14:13:
[...]
Ik heb geupdate, maar zie nog geen cluster info.

Same here. Ik zie geen main/sub sensor verschijnen.

[johansen]

Xirt schreef op zaterdag 24 januari 2026 @ 21:15:
Ik heb de main/sub sensor toegevoegd in de repository: deze diagnostic sensor staat standaard uit (disabled), maar kan ingeschakeld worden door mensen die een cluster hebben.

Indevolt gaf zelf aan dat er maar twee waarden teruggegeven zullen worden vanuit de API (main vs. sub), maar ik kreeg een derde waarde die ik voor nu aangenomen heb als "standalone" (geen cluster). Aangezien ik zelf geen cluster heb zou het heel fijn zijn als mensen met een cluster (bijv. @EricDi @johansen) aan kunnen geven of de informatie bij hun nu juist weergegeven wordt in HA. Bij voorbaat dank!

Ik heb even in de code gekeken en volgens mij zit er een kleine bug in de nieuwe mode sensor (key 606).

In sensor.py staat:
state_mapping={"1000": "master", "1001": "slave", "1002": "standalone"}

terwijl state_mapping als dict[int, str] wordt gebruikt en raw_value een int lijkt te zijn.
Daardoor matcht .get(raw_value) niet en blijft de sensor leeg / onzichtbaar.

Oplossing lijkt te zijn:
state_mapping={1000: "master", 1001: "slave", 1002: "standalone"}

Verder: de sensor staat terecht als entity_registry_enabled_default=False, maar daardoor valt hij makkelijk “weg” als de mapping faalt. Na bovenstaande fix verwacht ik dat hij correct zichtbaar wordt bij disabled entities.

Ik test dit graag opnieuw zodra dit is aangepast.

p.s. bovengenoemde is in samenspraak met chatGPT (ik ben geen techneut). Als ik chatGPT mag geloven, is bovengenoemde de reden dat het nog niet lijkt te werken. Hopelijk heb je er iets aan!

[Xirt]

Thanks. Ik zal 'm even checken maar de 1002 werkt bij mij al prima met de huidige type hinting. Ik ben inderdaad geswitched van int naar string, omdat de API geen int terug bleek te geven: vandaar waarschijnlijk de inconsistentie in de code.

De mapping moet wel string keys hebben om te matchen met de waardes van de API call of ik moet de string eerst converteren naar int en dan de de mapping met int keys maken. Maar je kan 'm dus al wel eventueel enablen om te kijken wat / of ie dan wel toont: bij mij toont je netjes "standalone".

[ Voor 27% gewijzigd door Xirt op 25-01-2026 18:09 ]

[Xirt]

Ik heb net versie 1.6 ontvangen van de API documentatie waarin bevestigd wordt dat "1002" inderdaad de waarde is voor "standalone" (geen cluster). Ik heb nogmaals de payload gecheckt en 1002 wordt als String gestuurd (volgens mij omdat Indevolt het als ENUM ziet). Daarnaast zijn zover ik zie alle gemelde fouten en ontbrekende data punten opgenomen in het nieuwe document.

Bij deze een kleine update op de repo op basis van de nieuwe informatie:

• Bypass setting (enabled / disabled) toegevoegd
• Led indicator setting (enabled / disabled) toegevoegd
• Decimalen verwijderd voor instellingen (zijn altijd integers)
• Type hinting voor ENUM sensors gecoorrigeerd

[SilencerNL]

Zojuist de main/sub mode sensor getest. De waardes kloppen hier. De main batterij geeft aan "Cluster (main)" en de andere 2 stapels "Cluster (sub)". Nice job!

[lemval]

Ik was nieuwsgierig naar het werkelijke gebruik van de thuisaccu's. Dus heb ik de teruglevering op 0 gezet en een 'deep standby' ingeschakeld tussen 6 uur 's avonds en 8 uur 's ochtends. In de slaapstand rapporteert de 'battery power' inderdaad 0 watt en in de tijd dat deze niet aan het laden (of ontladen) is, zo'n 25 watt.

Echter, als ik kijk naar de totale 'battery SOC' heb ik 75% om 6 uur 's avonds en 73% om 8 uur 's ochtends. Dat zou grofweg betekenen dat ik 2% op 8 kWh (de nacht daarvoor 3%) kwijt ben aan eigen gebruik. In geen geval was de temperatuur van de accu's onder de 5 graden Celsius gekomen. Het eigengebruik in 'deep standby' lijkt daarmee dus nog steeds grofweg 15 watt.

Wat nog meer bizar is dat met een 'battery power' op 24 watt (dus actief) vandaag tussen 8 en 9 (geen invoeding van zonnepanelen) in 60 minuten 6% verlies is (gisteren 'slechts' 3%). Is er iemand anders met dezelfde ervaringen?

Nu weet ik dat het percentage niet heel secuur is, maar het rendement is hiermee wel ver te zoeken. Dus eigenlijk zou ik via een API de batterij uit 'deep standby' willen halen op het moment dat ik overschot heb van mijn panelen en weer in slaap brengen zodra de 'discharge limit' is bereikt. Is bekend of ze dit wellicht zelf gaan inbouwen?

[Edit: Heb de vraag ook even bij Thuisbatterij.nl uitgezet]

[vrieske]

lemval schreef op maandag 26 januari 2026 @ 10:36:
Ik was nieuwsgierig naar het werkelijke gebruik van de thuisaccu's. Dus heb ik de teruglevering op 0 gezet en een 'deep standby' ingeschakeld tussen 6 uur 's avonds en 8 uur 's ochtends. In de slaapstand rapporteert de 'battery power' inderdaad 0 watt en in de tijd dat deze niet aan het laden (of ontladen) is, zo'n 25 watt.

Echter, als ik kijk naar de totale 'battery SOC' heb ik 75% om 6 uur 's avonds en 73% om 8 uur 's ochtends. Dat zou grofweg betekenen dat ik 2% op 8 kWh (de nacht daarvoor 3%) kwijt ben aan eigen gebruik. In geen geval was de temperatuur van de accu's onder de 5 graden Celsius gekomen. Het eigengebruik in 'deep standby' lijkt daarmee dus nog steeds grofweg 15 watt.

Wat nog meer bizar is dat met een 'battery power' op 24 watt (dus actief) vandaag tussen 8 en 9 (geen invoeding van zonnepanelen) in 60 minuten 6% verlies is (gisteren 'slechts' 3%). Is er iemand anders met dezelfde ervaringen?

Nu weet ik dat het percentage niet heel secuur is, maar het rendement is hiermee wel ver te zoeken. Dus eigenlijk zou ik via een API de batterij uit 'deep standby' willen halen op het moment dat ik overschot heb van mijn panelen en weer in slaap brengen zodra de 'discharge limit' is bereikt. Is bekend of ze dit wellicht zelf gaan inbouwen?

[Edit: Heb de vraag ook even bij Thuisbatterij.nl uitgezet]

had je deze post gezien? https://gathering.tweakers.net/forum/view_message/84248432 of zoek op 'verbruik' binnen dit topic. Meerdere mensen hadden dit ook en hebben een oplossing gevonden.

[ Voor 3% gewijzigd door vrieske op 26-01-2026 15:46 ]

[lemval]

vrieske schreef op maandag 26 januari 2026 @ 15:37:
[...]
had je deze post gezien? https://gathering.tweakers.net/forum/view_message/84248432 of zoek op 'verbruik' binnen dit topic. Meerdere mensen hadden dit ook en hebben een oplossing gevonden.

Yep. Ik volg het forum met grote aandacht. De bypass staat bij mij ook uit; had ik in mijn bericht natuurlijk moeten toevoegen. Ter verduidelijking wat info van de afgelopen tijd; oordeel zelf N.B.: Rated capacity: 8,04 kWh

[ Voor 2% gewijzigd door lemval op 26-01-2026 16:04 . Reden: Capaciteit toegevoegd van info uit Xirt's plugin ]

[lemval]

En gezien ik nu toch mijn PowerFlex 2000 met 3 modules aan het bekijken ben: Alhoewel de nul-op-de-meter heel goed lijkt te werken, levert een magere zon van vandaag het onderstaande op. Naast de 24 watt gerapporteerd verbruik in normale stand wordt nog eens zo'n 25-150 watt extra verbrand om de accu te laden (afhankelijk van de laadstroom). Niet vreemd op zich dat de installatie dan wat extra gebruikt om te laden, maar dan gebruik ik het magere overschot in deze dagen liever voor verwarming. Vandaag overdag dus een verval van 73% (5,87 kWh) naar 49% (3,94 kWh), ondanks een magere lading van 0.13 kWh. Het totale verval is dus niet de 0.17 vanuit de sensor, maar 1.93. Ook interessant om te noemen, indien ik mijn teruglevering op 800 watt zet (de extra groep komt pas later) en deze staat niet in 'deep standby', dan laadt de batterij regelmatig bij van het net om aan de minimale SOC te blijven voldoen. Of dit ook zo is bij 'deep standby', ga ik nog uitproberen.

[johansen]

Xirt schreef op maandag 26 januari 2026 @ 09:02:
Ik heb net versie 1.6 ontvangen van de API documentatie waarin bevestigd wordt dat "1002" inderdaad de waarde is voor "standalone" (geen cluster). Ik heb nogmaals de payload gecheckt en 1002 wordt als String gestuurd (volgens mij omdat Indevolt het als ENUM ziet). Daarnaast zijn zover ik zie alle gemelde fouten en ontbrekende data punten opgenomen in het nieuwe document.

Bij deze een kleine update op de repo op basis van de nieuwe informatie:

• Bypass setting (enabled / disabled) toegevoegd
• Led indicator setting (enabled / disabled) toegevoegd
• Decimalen verwijderd voor instellingen (zijn altijd integers)
• Type hinting voor ENUM sensors gecoorrigeerd

Helaas, ik krijg die nieuwe settings niet te zien.
Heb al een en ander geprobeerd. Met en zonder cluster. Ook het main/sub zie ik hier niet.

Ik heb 2x Powerflex Eco en 1x Powerflex Hybrid. Alledrie laatste firmware.
Alles draait verder prima op HA Green. Ik heb de custom integration nieuw clean geïnstalleerd. En voor de zekerheid ook het cluster disbanded (dit had helaas geen resultaat; ja ik heb HA gerestart).



Suggesties om het aan de praat te krijgen?

[Xirt]

Aan de decimalen te zien is dit nog steeds een oude versie van de integratie. Weet je zeker dat je geen oude codebase teruggezet hebt? Als de oude bestanden er niet meer zijn, dan zou ik op z'n minst verwachten dat Home Assistant bij een volledige restart ofwel foutmeldingen gaat geven (in het log), ofwel de integratie helemaal niet laadt.

[johansen]

Xirt schreef op maandag 26 januari 2026 @ 21:57:
Aan de decimalen te zien is dit nog steeds een oude versie van de integratie. Weet je zeker dat je geen oude codebase teruggezet hebt? Als de oude bestanden er niet meer zijn, dan zou ik op z'n minst verwachten dat Home Assistant bij een volledige restart ofwel foutmeldingen gaat geven (in het log), ofwel de integratie helemaal niet laadt.

Helaas.
Ik draai de nieuwe code (number.py cast naar int, native_step=1).

De waarden zijn integers, maar HA toont bij NumberMode.BOX nog steeds ,0. Dit lijkt frontend-gedrag, geen integratiebug.

Grid_charging (2618) wordt aangemaakt, light (7171) en bypass (680) verschijnen nergens (ook niet disabled), terwijl ze in dezelfde code staan en generation=2 hebben.
Dit kan alleen als 7171 en 680 niet in de lokale API-response zitten.

[honda4life]

Komt deze integratie nog in HACS?
Nog zo eenvoudig voor upgrade.

[Xirt]

Dit lijkt meer op ee HA bug, dan op een probleem met de integratie. De cast naar int werkt bij de anderen wel (zie ook screenshot lemval) en ook de waarde zou automatisch opgevraagd moeten worden vanuit de API op het moment dat een nieuwe entitity geregistreerd wordt bij het opstarten.

Ik zal proberen vandaag even een logger toe te voegen die naar het system log schrijft op het moment van initialisatie; misschien dat dat een handvat geeft om te kijken wat er gebeurd.

[Xirt]

honda4life schreef op maandag 26 januari 2026 @ 23:14:
Komt deze integratie nog in HACS?
Nog zo eenvoudig voor upgrade.

Ja, er is al een PR voor de initiele versie die slechts één platform mag bevatten (alleen sensoren):

https://github.com/home-assistant/core/pull/160595

Alleen duurt het normaal wel een tijdje (soms redelijk wat maanden) alvorens een integratie helemaal "klaar" is en opgenomen wordt. En daarna moet ik dan de andere entities toe gaan voegen via follow-up CRs.

Ik probeer in ieder geval snelle opvolging te geven waar mogelijk (eerste review was hopelijk het grootst; flink wat herschreven, maar ziet er nu een stuk netter uit).

[duvekot]

Xirt schreef op dinsdag 27 januari 2026 @ 06:07:
[...]

Ja, er is al een PR voor de initiele versie die slechts één platform mag bevatten (alleen sensoren):

https://github.com/home-assistant/core/pull/160595

Alleen duurt het normaal wel een tijdje (soms redelijk wat maanden) alvorens een integratie helemaal "klaar" is en opgenomen wordt. En daarna moet ik dan de andere entities toe gaan voegen via follow-up CRs.

Ik probeer in ieder geval snelle opvolging te geven waar mogelijk (eerste review was hopelijk het grootst; flink wat herschreven, maar ziet er nu een stuk netter uit).

Zal het helpen als je gewoon elke dag zorgt dat je PR up to date blijft met de huidige development branch? En die 3 checks die nog gedaan wil worden door de GitHub workflow .. had je die al eens zelf nagelopen of die een succes gaan zijn als ze geapproved gaan worden?

[Xirt]

Ik heb begrepen dat dat juist averechts werkt (beetje spammen). Min of meer "reset" je dan de timer van hoe lang het item al uitstaat bij de reviewer. Ik kan me ook wel voorstellen dat ze een soort cycle hebben waarbij ze begin van de maand meer reviewen e.d. en mid / einde maand meer focus hebben op de komende release. Ik wacht voor nu dus nog geduldig af.

Mocht er een manier zijn om vanuit de userbase te laten weten dat er interesse is in deze core integratie (bijv. subscriben op de PR), dan sta ik daar uiteraard positief tegenover .

[johansen]

Xirt schreef op dinsdag 27 januari 2026 @ 06:01:
Dit lijkt meer op ee HA bug, dan op een probleem met de integratie. De cast naar int werkt bij de anderen wel (zie ook screenshot lemval) en ook de waarde zou automatisch opgevraagd moeten worden vanuit de API op het moment dat een nieuwe entitity geregistreerd wordt bij het opstarten.

Ik zal proberen vandaag even een logger toe te voegen die naar het system log schrijft op het moment van initialisatie; misschien dat dat een handvat geeft om te kijken wat er gebeurd.

Vandaag hebben de units nog een firmware update gekregen. Ik ging net even HA herstarten, en wat zag ik tot mn verrassing?



Ik heb niks met de integratie gedaan verder. En herstarten had ik gisteren ook al talloze keren gedaan. Dus dan heeft de firmwareupdate vermoedelijk iets te maken hiermee... Maar goed, het werkt dus! Thx!

[lemval]

Reactie vanuit de leverancier is om (ook bij NOM) de 'deep standby' aan te zetten gedurende het hele etmaal:

U kunt de diepe stand-by gerust instellen van 00:00 tot 24:00. De batterij zal automatisch uit de diepe stand-by ontwaken zodra er geladen of ontladen moet worden.

Wij zijn momenteel met Indevolt in overleg om deze optie standaard ingeschakeld te laten, omdat dit in de praktijk zorgt voor een efficiëntere werking.

Dat zou dus veel gunstiger voor het behoud van lading zijn. Dat heb ik inmiddels ingesteld. Resultaat zal ik binnenkort delen.

[johansen]

lemval schreef op dinsdag 27 januari 2026 @ 18:26:
Reactie vanuit de leverancier is om (ook bij NOM) de 'deep standby' aan te zetten gedurende het hele etmaal:


[...]


Dat zou dus veel gunstiger voor het behoud van lading zijn. Dat heb ik inmiddels ingesteld. Resultaat zal ik binnenkort delen.

Ik vraag me wel af of Deep Standby bij koudere temperaturen juist kwaad zou kunnen; dus indien je batterij buiten of in de schuur staat.

[Xirt]

johansen schreef op dinsdag 27 januari 2026 @ 17:56:
[...]


Vandaag hebben de units nog een firmware update gekregen. Ik ging net even HA herstarten, en wat zag ik tot mn verrassing?

[Afbeelding]

Ik heb niks met de integratie gedaan verder. En herstarten had ik gisteren ook al talloze keren gedaan. Dus dan heeft de firmwareupdate vermoedelijk iets te maken hiermee... Maar goed, het werkt dus! Thx!

Helemaal top! Dan ga ik (voor nu) ook geen extra loggers toevoegen . Uiteindelijk hoop ik dat iedereen de updates via de reguliere HA updates binnen gaat krijgen, maar de 2026.02 release gaan we in ieder geval niet meer halen .

[vrieske]

lemval schreef op dinsdag 27 januari 2026 @ 18:26:
Reactie vanuit de leverancier is om (ook bij NOM) de 'deep standby' aan te zetten gedurende het hele etmaal:


[...]


Dat zou dus veel gunstiger voor het behoud van lading zijn. Dat heb ik inmiddels ingesteld. Resultaat zal ik binnenkort delen.

Ben heel benieuwd!

[Cranfbob2UI]

JooJoo schreef op zaterdag 24 januari 2026 @ 23:57:
Even een vraag over de koppeling van Indevolt met HA en Homey. Hoe groot is de kans dat in de toekomst Indevolt ook met Homey gekoppeld kan worden. Iemand een idee?

De eerste stappen zijn gezet, zie:
https://community.homey.app/t/indevolt-battery/148405

[tiesvts]

Ik heb sinds 24 uur ook een powerflex met extra accu draaien. Na wat problemen met koppelen van p1 meter wat met geen mogelijkheid lukte tot ik vannacht een ingeving had en bedacht verrek het vinkje onderling communiceren staat uit in mijn router bij het 2.4ghz netwerk. Dus daarna was het helemaal in orde. Nu zat ik wat in de indevolt app te struinen en zag daar Energiekalibratie..en de interval staat op 0 dagen. Wat is dit en wat is de juiste instelling? Alvast bedankt

[ErikRe]

Batterijen “moeten” af en toe ff op 100% geladen worden, de kalibratiefunctie is niets meer dan een teller die na x dagen de accu naar 100% SOC laad. De leverancier raad elke 15 dagen aan, na 100% gaat teller vanaf 0 weer aftellen tot ingestelde kalibratie moment.

[tiesvts]

Dank voor het antwoord..ik heb hem nu op 14 dagen gezet.

[florijn11]

Welke Indevolt

IK heb een Segemcom CS 50001 van 2017 Slimme Meter Met Homewizard P1 meter.

Heb 13 4,16 kWp panelen en 3 fasen Solid Edge omvormer
Ik wek 4480 kwh op en lever 3019 kwh terug dus 1461 kwh zelf verbruik
Doordat ik met een airco 1413 kwh bij verwarm heb ik 3329 kwh uit het net opgenomen en is het gasverbruik nog 381 m3 ipv 1300 m3
Welke en Hoeveel accu 's raden jullie aan ?

[ArjoK]

@florijn11Bepaal voor jezelf eerst het doel van je thuisbatterij. Heb je al de keuze voor Indevolt gemaakt? Anders beter eerst een kijkje in het algemene topic Thuisaccu: al interessant (voor mij)?

[florijn11]

ArjoK schreef op donderdag 29 januari 2026 @ 14:23:
@florijn11Bepaal voor jezelf eerst het doel van je thuisbatterij. Heb je al de keuze voor Indevolt gemaakt? Anders beter eerst een kijkje in het algemene topic Thuisaccu: al interessant (voor mij)?

Ja gezien de voordelen vlgs video thuisbatterij.nl wel maar zijn er ook nadelen andere uitbreibare systemen.

[ArjoK]

florijn11 schreef op donderdag 29 januari 2026 @ 15:16:
[...]

Ja gezien de voordelen vlgs video thuisbatterij.nl wel maar zijn er ook nadelen andere uitbreibare systemen.

Ja, als in je hebt een keuze gemakt voor Indevolt?
Je hebt nu een HW P1meter, dan heb je dus verbruiksdata wat je gaat helpen bij het bepalen van de grootte/capaciteit van de batterij, maar dan nog moet je weten welk doel je voor ogen hebt met de batterij.

[tiesvts]

Ik heb een gedachtengang en vraag me af of ik goed zit. Om het standby verbruik te verminderen wordt aangeraden om de bypass socket uit te schakelen. 1 van de redenen waarom ik deze indevolt heb aangeschaft heb is om in geval van (langdurige) stroomuitval deze icm met rechtsreeks aangesloten zonnepanelen nog te kunnen gebruiken en zo nog stroom te hebben. Echter als nu de stroom uitvalt (en dus ook mijn wifi netwerk) hoe krijg ik dan nog stroom uit de bypass socket? Deze staat tenslotte uit en om die aan te zetten moet ik dat via de app doen..en wifi die dan ook is uitgevallen. Of ben ik nu een heel erge doomdenker? Is het dan toch slimmer de bypass aan te laten?

Edit..ik zie dat meer mensen deze gedachten hebben en dat er misschien een Bluetooth verbinding die mogelijk zou kunnen maken. Hopelijk komt deze functie nog..

[ Voor 13% gewijzigd door tiesvts op 29-01-2026 15:55 ]

[johansen]

tiesvts schreef op donderdag 29 januari 2026 @ 15:45:
Ik heb een gedachtengang en vraag me af of ik goed zit. Om het standby verbruik te verminderen wordt aangeraden om de bypass socket uit te schakelen. 1 van de redenen waarom ik deze indevolt heb aangeschaft heb is om in geval van (langdurige) stroomuitval deze icm met rechtsreeks aangesloten zonnepanelen nog te kunnen gebruiken en zo nog stroom te hebben. Echter als nu de stroom uitvalt (en dus ook mijn wifi netwerk) hoe krijg ik dan nog stroom uit de bypass socket? Deze staat tenslotte uit en om die aan te zetten moet ik dat via de app doen..en wifi die dan ook is uitgevallen. Of ben ik nu een heel erge doomdenker? Is het dan toch slimmer de bypass aan te laten?

Edit..ik zie dat meer mensen deze gedachten hebben en dat er misschien een Bluetooth verbinding die mogelijk zou kunnen maken. Hopelijk komt deze functie nog..

Dit werkt al. Net even geprobeerd met mn telefoon in vliegtuigmodus; je kunt dan via de Indevolt app kiezen voor "Direct device connection" en dan scan je de QR code van het apparaat. Je komt dan (via bluetooth) gewoon in de apparaat-settings waar je de bypass socket kunt inschakelen.

[duvekot]

johansen schreef op donderdag 29 januari 2026 @ 16:38:
[...]

Dit werkt al. Net even geprobeerd met mn telefoon in vliegtuigmodus; je kunt dan via de Indevolt app kiezen voor "Direct device connection" en dan scan je de QR code van het apparaat. Je komt dan (via bluetooth) gewoon in de apparaat-settings waar je de bypass socket kunt inschakelen.

op Android of IOs?

[johansen]

duvekot schreef op donderdag 29 januari 2026 @ 19:11:
[...]

op Android of IOs?

iOS. Maar kan me niet voorstellen dat het met Android niet zou werken hoor 🙂

[Cranfbob2UI]

Cranfbob2UI schreef op woensdag 28 januari 2026 @ 09:08:
[...]


De eerste stappen zijn gezet, zie:
https://community.homey.app/t/indevolt-battery/148405

Eerste test app voor Homey is gepubliceerd:

https://community.homey.a...battery/148405/8?u=rchu57

[Xirt]

Inmiddels staat de nieuwe codebase voor de HA integratie een tijdje online op mijn repo en ben ik benieuwd of er nog items zijn waar eventueel naar gekeken moet worden. Dan kan ik daar mooi nog even naar kijken alvorens alles uiteindelijk als core integratie beschikbaar wordt.

Specifiek probeer ik te begrijpen hoe clusters werken: voor zover ik bet nu begrijp kan je een batterijstack binnen een cluster autonoom instellen en word het cluster gebruikt voor load balancing (aangestuurd vanaf de main en rekening houdend met de individuele instellingen van elke stack). Dat betekent dus ook dat de huidige implementatie al OK zou zijn (je voegt simpelweg elke stack van het cluster toe aan HA, want het zijn individuele devices, en vanuit daar kan je ze configureren). Is dat correct of is dit "te simpel" gedacht?

[ErikRe]

Ik heb een cluster draaien met jouw integratie…👍👍Ik stuur het cluster in HA aan door enkel de master commando te geven…de subs doen dan hetzelfde

[Xirt]

Gaat dat dan over alle instellingen/services of over een deel daarvan? Ik kan me bijvoorbeeld voorstellen dat je wel de limieten wilt beheren per apparaat (bijv. als één stack op een eigen groep zit en de andere niet)?

[ErikRe]

De subs staan continu in “real time” mode. je kunt de master mode aanpassen dan volgen de subs. Ook charge discharge commando wordt door de subs gevolgd. Voor zover ik kan zien moeten alle andere mogelijkheden separaat worden ingevoerd. Limieten aanpassen moet dus per apparaat, handiger is inderdaad met 1 handeling

[ErikRe]

Het enige wat nu nog ontbreekt is de aansturing om overschot van solar (niet gekoppeld aan de indvolt’s) in de accu’s te krijgen. Dit kan/kon nu alleen nog maar door in de app de mode “eigen gebruik voorrang” te kiezen. Dit is niet wat ik wil, want zodra zon weg is gaat ie batterijen weer ontladen. Zou mooi zijn als deze functie op ‘e’en of andere manier in HA komt.

[duvekot]

ErikRe schreef op vrijdag 30 januari 2026 @ 08:17:
Het enige wat nu nog ontbreekt is de aansturing om overschot van solar (niet gekoppeld aan de indvolt’s) in de accu’s te krijgen. Dit kan/kon nu alleen nog maar door in de app de mode “eigen gebruik voorrang” te kiezen. Dit is niet wat ik wil, want zodra zon weg is gaat ie batterijen weer ontladen. Zou mooi zijn als deze functie op ‘e’en of andere manier in HA komt.

Daarvoor moet je wel los weten wat je zonnepanelen precies doen . Dus onafhankelijk van het daadwerkelijk verbruik van het huis (dus zonder zonnepanelen en de batterij in en output). Dan is het een kwestie van meten en bepalen of er op basis van de huidige productie er stoom de batterij in moet of niet. En dan op basis daarvan de juiste aansturing richting de batterij te doen. Maar dat is dus iets wat in mijn ogen buiten de daadwerkelijke HA integratie zit van de Indevolt, maar wel daar gebruik van maakt.

[Nanuk]

ErikRe schreef op vrijdag 30 januari 2026 @ 08:17:
Het enige wat nu nog ontbreekt is de aansturing om overschot van solar (niet gekoppeld aan de indvolt’s) in de accu’s te krijgen. Dit kan/kon nu alleen nog maar door in de app de mode “eigen gebruik voorrang” te kiezen. Dit is niet wat ik wil, want zodra zon weg is gaat ie batterijen weer ontladen. Zou mooi zijn als deze functie op ‘e’en of andere manier in HA komt.

Dit dus. In de 'winter' de batterij vullen met het beetje overschot aan zon en verder op de goedkope uren. Verder alleen ontladen tijdens dure uren met minimaal 5 ct prijsverschil tov de goedkope uren.

Voor het zomer half jaar is het wederom vullen met zonnestroom op de goedkope uren en tijdens dure uren wat je zelf niet gaat gebruiken op het net dumpen, wederom alleen bij voldoende prijsverschil.

Waarschijnlijk is dat wel binnen HA op te lossen als ik eens de juiste brainwave heb.

[Xirt]

Ik heb mijn ontladen uit staan zolang het dag is / er zonneproductie is. Tijdens de dag laadt ie dus alleen maar (in "eigen verbruik voorrang"-modus). Dit is uiteraard wel geregeld vanuit HA en ik kan de automatisering later vandaag wel even posten als startpunt.

Wat betreft de instellingen voor limieten van het cluster: die moeten wel separaat blijven omdat de integratie niet kan weten of een cluster op een aparte groep zit of niet (dus mag ontladen met 800W of meer). Ook spelen met verschillende SOC ondergrenzen kan interessant zijn als de stacks verschillend zijn. Maar je zou deze instellingen van de stacks wel kunnen koppelen door een automatisering te maken in HA: als de limiet van de "main" wijzigt, stel dan de limiet van de "sub" in op de waarde van de "main".

De services (charge, discharge, etc.) zouden dus eigenlijk alleen moeten werken voor de stack die als "main" ingesteld staat (want die verspreid deze instelling)?

[Nanuk]

Waar ik ook tegenaan loop is dat als (b.v.) de inductieplaat laag staat dan gaat ie op en af in ongeveer het tempo dat de batterij reageert. Dus gaat de batterij in tegenfase op het net sturen wat ik er net vanaf heb gehaald. Over het algemeen zou het handiger zijn dat je altijd iets van het net blijft halen in plaats van op nul sturen. Dus een offset in kan stellen voor je nul op de meter.

[Xirt]

Ik gebruik dit momenteel om ervoor te zorgen dat de batterij overdag overschot gebruikt om te laden en daaromheen ontlaad op basis van "vraag". Dit zorgt er in ieder geval voor dat de batterij niet de hele dag lang bleef wisselen tussen laden en ontladen en kan uitgebreid worden met andere logica om het geheel "slimmer" te maken.

code:

alias: Batterijmanagement (ontladingsstatus)
description: ""
triggers:
  - trigger: sun
    event: sunrise
    offset: "01:00:00"
    id: trigger_sunrise
  - trigger: sun
    event: sunset
    offset: "-01:00:00"
    id: trigger_sunset
  - trigger: numeric_state
    entity_id:
      - sensor.energy_production_today_remaining
    below: 0.1
    id: trigger_no_production
conditions: []
actions:
  - if:
      - condition: trigger
        id:
          - trigger_sunrise
    then:
      - action: number.set_value
        metadata: {}
        target:
          entity_id:
            - number.indevolt_cms_sf2000_max_ac_output_power
        data:
          value: "0"
    else:
      - action: number.set_value
        metadata: {}
        target:
          entity_id:
            - number.indevolt_cms_sf2000_max_ac_output_power
        data:
          value: "800"
mode: single

Note: mijn zonnepanelen liggen op het zuiden. Vandaar dat ik een uur voor zonsondergang de switch al om kan zetten (dit kan je uiteraard aanpassen).

[ Voor 5% gewijzigd door Xirt op 30-01-2026 09:11 ]

[lemval]

Zo, een paar grauwe dagen verder met de PowerFlex 2000 Eco 8 kWh bekeken met: teruglevering op 0, deep standby altijd aan, bypass uit en nul-op-de-meter. Dit is dus vanaf 00:00u op 28 januari tot en met 23:59u op 30 januari.
Capaciteitsverlies: 40% - 33% = 7% x 8.04 kWh = 563 Watt = ~ 11.5 Watt per uur.
Ontlading verwaarloosbaar (10 Wh totaal), totaallading is 0 Wh. Grafiek van inkomende en verwerkte laadstroom onderaan als grafiek.
Geen onaardig gebruik, wetende dat de API gewoon blijft werken, nul-op-de-meter ook, de app ook.

Ondanks het koude weer hebben de batterijen een temperatuur van minimaal 5 graden behouden (stack staat in onverwarmde garage), dus geen idee of 'deep standby' ook zorgdraagt voor de verwarming.

Hoe dan met het behouden van de minimale SOC? Rond 23:00u zakte deze onder de (tijdelijke) grens van 34%. De volgende ochtend om 5:00u heeft de PF zo'n 90 seconde met 2 kWh geladen om de batterij weer op pijl te krijgen. Daarvoor is de PF 4 minuten uit 'deep standby' gegaan. Dus zelfs in 'deep standby' houdt de PF de ontlaatlimiet in de gaten.

johansen heeft reeds aangegeven dat je via een directe verbinding in nood de bypass kan aanzetten via Bluetooth, dus lijkt de enige reden nog om niet standaard vanuit 'deep standby' te werken is: zorgen dat jouw vriezer ook bij afwezigheid blijft doordraaien.

[ariedude]

Interessant topic! Even voor mijn beeldvorming;-) Ik heb PV, EV, electrisch verwarmen enzovoort. Tibber als leverancier. Via HA o.a. de auto aansturen adhv OCPP en EV smart Charging icm GE-spot. Ik vind het uiteraard ook leuk om met HA bezig te zijn icm dit soort technieken maar mijn vraag is, in hoeverre is de software van de Indevolt volwassenen genoeg om te draaien zonder HA als een op zichzelf staande oplossing?

HA heb ik op Unraid als een VM draaien maar het blijft een extra stukje afhankelijkheid als er een storing is in dat systeem. Benieuwd naar jullie mening.

[johansen]

Xirt schreef op vrijdag 30 januari 2026 @ 06:06:
Inmiddels staat de nieuwe codebase voor de HA integratie een tijdje online op mijn repo en ben ik benieuwd of er nog items zijn waar eventueel naar gekeken moet worden. Dan kan ik daar mooi nog even naar kijken alvorens alles uiteindelijk als core integratie beschikbaar wordt.

Specifiek probeer ik te begrijpen hoe clusters werken: voor zover ik bet nu begrijp kan je een batterijstack binnen een cluster autonoom instellen en word het cluster gebruikt voor load balancing (aangestuurd vanaf de main en rekening houdend met de individuele instellingen van elke stack). Dat betekent dus ook dat de huidige implementatie al OK zou zijn (je voegt simpelweg elke stack van het cluster toe aan HA, want het zijn individuele devices, en vanuit daar kan je ze configureren). Is dat correct of is dit "te simpel" gedacht?

Jouw implementatie werkt so far super. Ik ga straks nog wel even kijken of ik gebruik ga maken van jouw automation mbt niet ontladen op de dag, want ik vind het jammer dat dit out of the box niet handig werkt. Welke Energy Mode heb jij dan ingesteld standaard? Ik werk nu of met Smart (icm Idle) of met Self-Consumed (dat laatste in de avond uren). Ik ben dus ook veel zelf handmatig tussen modes aan het switchen.

Ik heb nog wel een aanvulling voor de implementatie. Voor de Max AC Output Power heb ik nu meerdere waardes. Namelijk de individuele waardes (van de 2 subs en de main, zoals in jouw implementatie). 2 subs staan op 800W en de main op 1400W (eigen groep). Het cluster heeft hier ook een eigen setting voor, en die heb ik op 3000W staan (800+800+1400) in de Indevolt app. Deze clustersetting (3000W) zit niet in de implementatie. Is er een mogelijkheid om die toe te voegen?

Max AC Output Power werkt dus anders dan Grid Charging. Grid charging houdt qua max van het cluster namelijk de waarde aan van de main en daar heb je dus geen clustersetting.

[honda4life]

Wat is het nut van zelf een automation te schrijven als je de modus zelfconsumptie hebt?
Laat de batterij maar ontladen overdag als er te weinig zon is, dat is extra laadcapaciteit als er nadien terug meer zon is (alleen maar financieel voordeel als je 1+ cyclus per dag kan benutten).
Ja, je kan misschien wat meer opsparen voor variabele tarieven of piekvermogens maar voor de rest zie ik weinig meerwaarde (als HA eens blijft hangen zonder dat je het door hebt... je batterij ook)
Ik zou ook opletten met frequent parameters wegschrijven, deze worden mogelijk in een flash geheugen zonder wear-leveling telkens opgeslagen en dat zal ook niet bevorderlijk zijn voor de levensduur van je microcontroller / geheugenchip.
Het enige dat ik kan bedenken is dat als er toch te veel injectie is (onder andere pulserende last), dat er enkel de basislast gevoed wordt.

Een droogkast draaien is hier helaas 200 Wh verlies door de continu in- en uitschakelende warmtepomp en het te traag volgen van de batterij.

[ Voor 13% gewijzigd door honda4life op 30-01-2026 15:39 ]

[johansen]

honda4life schreef op vrijdag 30 januari 2026 @ 15:36:
Wat is het nut van zelf een automation te schrijven als je de modus zelfconsumptie hebt?
Laat de batterij maar ontladen overdag als er te weinig zon is, dat is extra laadcapaciteit als er nadien terug meer zon is (alleen maar financieel voordeel als je 1+ cyclus per dag kan benutten).
Ja, je kan misschien wat meer opsparen voor variabele tarieven of piekvermogens maar voor de rest zie ik weinig meerwaarde (als HA eens blijft hangen zonder dat je het door hebt... je batterij ook)
Ik zou ook opletten met frequent parameters wegschrijven, deze worden mogelijk in een flash geheugen zonder wear-leveling telkens opgeslagen en dat zal ook niet bevorderlijk zijn voor de levensduur van je microcontroller / geheugenchip.
Het enige dat ik kan bedenken is dat als er toch te veel injectie is (onder andere pulserende last), dat er enkel de basislast gevoed wordt.

Een droogkast draaien is hier helaas 200 Wh verlies door de continu in- en uitschakelende warmtepomp en het te traag volgen van de batterij.

Nou, ik weet niet of je de afgelopen dagen hebt gezien hoeveel zon er was? (lees: geen) Dan schiet zelfconsumptie niet echt op. Ik heb afgelopen week de batterijen geladen tegen relatief lage dynamische tarieven in de nacht. Als ik de accu's op zelfconsumptie ga zetten, gaan ze overdag (als er nauwelijks zon is) stroom leveren terwijl de stroom midden op de dag goedkoop is. Dat wil ik dus niet.

In de winter wil ik dat de batterijen laden met lage tarieven, ontladen bij hoge tarieven (bv 10 cent verschil of boven de 35 cent/kw) en tussendoor idle zijn TENZIJ er overschot van zon is. Als er geen overschot is, dan lekker niks doen wanneer de tarieven niet hoog zijn.

Daar heb je dus echt een automation voor nodig, tenzij je steeds handmatig de modus gaat omzetten.

[roy77]

Wij hebben 2 sets van 12 kW geplaatst in cluster.
Alsnik de HW dongel ook in de splitter steek werkt de Solarman dongel niet goed meer.
Ook zie ik op de app constamt 0 pv terwijl er toch wel zon schijnt.
Iemand enig idee hoe dat kan?

[Nexoez]

roy77 schreef op vrijdag 30 januari 2026 @ 16:31:
Wij hebben 2 sets van 12 kW geplaatst in cluster.
Alsnik de HW dongel ook in de splitter steek werkt de Solarman dongel niet goed meer.
Ook zie ik op de app constamt 0 pv terwijl er toch wel zon schijnt.
Iemand enig idee hoe dat kan?

Je moet de splitter apart gaan voeden. Was hier ook het geval.

[tiesvts]

johansen schreef op donderdag 29 januari 2026 @ 22:56:
[...]

iOS. Maar kan me niet voorstellen dat het met Android niet zou werken hoor 🙂

Android werkt ook prima..net getest.

[Xirt]

johansen schreef op vrijdag 30 januari 2026 @ 14:58:
[...]


Jouw implementatie werkt so far super. Ik ga straks nog wel even kijken of ik gebruik ga maken van jouw automation mbt niet ontladen op de dag, want ik vind het jammer dat dit out of the box niet handig werkt. Welke Energy Mode heb jij dan ingesteld standaard? Ik werk nu of met Smart (icm Idle) of met Self-Consumed (dat laatste in de avond uren). Ik ben dus ook veel zelf handmatig tussen modes aan het switchen.

Ik heb nog wel een aanvulling voor de implementatie. Voor de Max AC Output Power heb ik nu meerdere waardes. Namelijk de individuele waardes (van de 2 subs en de main, zoals in jouw implementatie). 2 subs staan op 800W en de main op 1400W (eigen groep). Het cluster heeft hier ook een eigen setting voor, en die heb ik op 3000W staan (800+800+1400) in de Indevolt app. Deze clustersetting (3000W) zit niet in de implementatie. Is er een mogelijkheid om die toe te voegen?

Max AC Output Power werkt dus anders dan Grid Charging. Grid charging houdt qua max van het cluster namelijk de waarde aan van de main en daar heb je dus geen clustersetting.

Hij staat bij mij 24/7 op "self-consumed prioritized" en overdag mag ie dus niet ontladen. Als gevolg daarvan laadt ie overdag op als ik overproductie heb, en ontlaadt ie als er geen productie is. Met her huidige weer doet ie dus voornamelijk helemaal niets...

Zou je een screenshot kunnen sturen van de Indevolt app met de 3000W instelling? Volgens mij staat dit datapunt namelijk niet in de API specs dus ik moet 'm even uit gaan vragen bij Indevolt.

[roy77]

Top beode dongels en apps werken nu.
Alleen staat de pv op 0 op de Indevolt app.
Eerst maar eens wat meer zon afwachten maar ik neem aan dat op de app ook de zonnestroom opwek wordt aangegeven?

[johansen]

roy77 schreef op vrijdag 30 januari 2026 @ 17:12:
Top beode dongels en apps werken nu.
Alleen staat de pv op 0 op de Indevolt app.
Eerst maar eens wat meer zon afwachten maar ik neem aan dat op de app ook de zonnestroom opwek wordt aangegeven?

Nee, die blijft 0. Want dat gaat alleen over zonnepanelen die direct op je Indevolt zijn aangesloten namelijk.

[Xirt]

Bij mij niet, maar ik heb een ECO variant: mijn overschot van PV wordt wel doorgesluisd naar de batterij maar in de app toont ie altijd als 0W (want vanuit de batterij gezien komt het van het net). Als je PV direct op de batterij hebt is dat waarschijnlijk wel anders. In HA zie ik uiteraard wel alles goed (op basis van verschillende bronnen).

[johansen]

Xirt schreef op vrijdag 30 januari 2026 @ 17:03:
[...]

Hij staat bij mij 24/7 op "self-consumed prioritized" en overdag mag ie dus niet ontladen. Als gevolg daarvan laadt ie overdag op als ik overproductie heb, en ontlaadt ie als er geen productie is. Met her huidige weer doet ie dus voornamelijk helemaal niets...

Zou je een screenshot kunnen sturen van de Indevolt app met de 3000W instelling? Volgens mij staat dit datapunt namelijk niet in de API specs dus ik moet 'm even uit gaan vragen bij Indevolt.

Zie het bijgevoegde gifje. Je ziet dan dat ik eerst naar de clusterinstelling ga (3000W) en daarna naar de instelling van de Main (1400W).

Hopelijk een beetje duidelijk zo.

[Xirt]

Top, ik ga vanavond even contact opnemen. Thanks!