Omnibattery Home Assistant integratie - Deel 1

[JBS]

NiCNCo schreef op donderdag 22 oktober 2026 @ 15:05:
[...]

De sensor kan veel meer data bevatten dan enkel wat je zit als je hem tussen je entiteiten benaderd. Ga naar Homeassistant Tools-->States tab, click op de "set state" en plak of zoek de sensor (sensor.omnibattery_daily_operation_timeline) en bevestig met enter. Dan zul je zien dat deze sensor een grote hoop aan data output. Met een beetje vibe-code in combinatie met deze sensor kan je dus hele mooie log lijstjes laten maken en deze in de vorm van een dashboard card laten gieten om dan vervolgens deze ergens op 1 van je dashboards te plaatsen.

Klopt.
@Mai Pensato, hierbij een voorzetje van de gebruikte attributes van entiteit omnibattery_daily_operation_timeline

• charge_power_w: Vermogen bij het laden (in Watt).
• discharge_power_w: Vermogen bij het ontladen (in Watt).
• actual_soc_pct: Actuele State of Charge (laadstatus in %).
• planned_soc_pct: Geplande State of Charge (in %).
• soc_end_pct: Verwachte laadstatus aan het einde van het interval (in %).
• soc_pct: Standaard/fallback laadstatus (in %).
• stored_energy_end_kwh: Opgeslagen energie in de batterij aan het einde van het interval (in kWh).
• charge_to_battery_kwh: Hoeveelheid geladen energie in de batterij (in kWh).
• actual_charge_to_battery_kwh: Daadwerkelijk geladen energie (in kWh).
• planned_charge_to_battery_kwh: Gepland geladen energie (in kWh).
• discharge_from_battery_kwh: Hoeveelheid ontladen energie uit de batterij (in kWh).
• actual_discharge_from_battery_kwh: Daadwerkelijk ontladen energie (in kWh).
• planned_discharge_from_battery_kwh: Gepland ontladen energie (in kWh).
• consumption_actual_kwh: Werkelijk woningverbruik (in kWh).
• consumption_forecast_kwh: Voorspeld woningverbruik (in kWh).
• solar_to_battery_kwh: Zonne-energie geladen in de batterij (in kWh).
• grid_to_battery_kwh: Netstroom geladen in de batterij (in kWh).

Prijzen komen bij mij van de eniteit sensor.frank_energie_prijzen_gemiddelde_elektriciteitsprijs_alle_uren_all_in

[Pakhaas]

Pakhaas schreef op donderdag 22 oktober 2026 @ 13:11:
[...]

Bedankt ik ga even kijken als ik thuis ben.

Gevonden. Ik heb nu de fase begrenzing op 5500w gezet. Dan heb ik nog iets marge tot 5750w

[Pakhaas]

Nog even een andere vraag. Kan ik ook ergens aangeven dat ik vannacht de EV wil laden? Zodat hij alvast kan kijken of hij daarvoor de batterij op een goedkoop moment moet laden? En als vannacht goedkoper is dan overdag, dat hij het dan uit het net haalt dan uit de batterij.

[Gramser]

Een oprechte vraag: als ik nu twee torentjes 2400AC+ aanstuur met Gielz en gast777 op NoM, en ik met een automatisering de zendures op Manual zet als mijn peblar gaat laden… biedt OmniBattery dan een voordeel? Is het updaten bijvoorbeeld makkelijker? Iets anders?

[B-Force]

Hoe hebben jullie de laadpaal excluded uit de batterij? Ik heb het volgende ingesteld, maar zodra de laadpaal aangaat, trekt hij toch mijn batterij leeg. Dat is precies wat ik niet wil 😅

[Mai Pensato]

JBS schreef op donderdag 22 oktober 2026 @ 15:20:
[...]

Klopt.
@Mai Pensato, hierbij een voorzetje van de gebruikte attributes van entiteit omnibattery_daily_operation_timeline

• charge_power_w: Vermogen bij het laden (in Watt).
• discharge_power_w: Vermogen bij het ontladen (in Watt).
• actual_soc_pct: Actuele State of Charge (laadstatus in %).
• planned_soc_pct: Geplande State of Charge (in %).
• soc_end_pct: Verwachte laadstatus aan het einde van het interval (in %).
• soc_pct: Standaard/fallback laadstatus (in %).
• stored_energy_end_kwh: Opgeslagen energie in de batterij aan het einde van het interval (in kWh).
• charge_to_battery_kwh: Hoeveelheid geladen energie in de batterij (in kWh).
• actual_charge_to_battery_kwh: Daadwerkelijk geladen energie (in kWh).
• planned_charge_to_battery_kwh: Gepland geladen energie (in kWh).
• discharge_from_battery_kwh: Hoeveelheid ontladen energie uit de batterij (in kWh).
• actual_discharge_from_battery_kwh: Daadwerkelijk ontladen energie (in kWh).
• planned_discharge_from_battery_kwh: Gepland ontladen energie (in kWh).
• consumption_actual_kwh: Werkelijk woningverbruik (in kWh).
• consumption_forecast_kwh: Voorspeld woningverbruik (in kWh).
• solar_to_battery_kwh: Zonne-energie geladen in de batterij (in kWh).
• grid_to_battery_kwh: Netstroom geladen in de batterij (in kWh).

Prijzen komen bij mij van de eniteit sensor.frank_energie_prijzen_gemiddelde_elektriciteitsprijs_alle_uren_all_in

De laatste 2 "solar to battery" en "grid to battery"vind ik zeer interessant omdat ik de hele energiedistributie nu met de batterijen erbij in kaar wil brengen. Kan ik dit ook doen voor het ontladen, houdt hij ook ergens vast "discharge to home" en "discharge to grid "?

[Tom35]

Gisteren omgeschakeld van HEMS naar omnibattery, wat een prachtig systeem dat dit is.
Ik heb een 3 fasen systeem met op 2 fasen een zendure 2400 AC+ batterij van 5kw. Daarnaast woon ik in Belgie en dus met het capaciteitstarief waar ik rekening moet mee houden als ik de batterijen van het net oplaadt.
Deze integratie is daar gewoon perfect voor.
Ik laadt per batterij met een max van 1500w en ontlaadt nog met een max van 800W maar voor het capaciteitstarief is dat eigenlijk al te veel.
Ik gebruik nu die Max. gecontracteerd vermogen om de laadlimiet via het net te beperken.

Ik heb voorspellend lasen ingeschakeld om is te zien hoe dit gaat reageren deze winter en gebruik solcast als voorspeller, de pricing heb ik uitgeschakeld als parameter omdat ik geen variabel tarief heb gedurende de dag.
Op zich heb ik geen probleem dat die batterij snachts tot 100% oplaadt, ik weet dat de efficientie maar 85% is dat ik dus ergens 1.5Kwh per dag verlies maar dit is tcoh maar in de maanden november tem februari.

Miscchien 1 vraagjes, je hebt een instelling dat de batterij begint te throttelen als de temperatuur te hoog wordt, is dit iets dat nodig is of zit dat ingebakken in de zendure batterij ?


Allesinds, dank u wel aan diegene die dit geprogrammeerd heeft, wat een prachtige integratie.


Tom

[ Voor 8% gewijzigd door Tom35 op 23-10-2026 08:38 ]

[Taro]

Ik zie OB nu voor het eerst maximaal ontladen op basis van hoge prijs:






Heb dit bewust begrenst tot 3x3000 Watt, waarbij de 4000 Mix AC+ 3000 Watt voor zijn rekening neemt en de Anker Max & Max AC gezamenlijk 3000 Watt en de 3000 Mix AC+ & 4000 Mix Pro ook gezamenlijk 3000 Watt. In theorie kan deze set 17 kW aan, maar heb nog niet alles vast aangesloten en dus hanteer ik een max van 3000 watt voor de stopcontacten. In de toekomst ook meer opslag voor Fase A, dan kan ik die ook langduriger met 4000-5000 watt gaan belasten.

[ Voor 17% gewijzigd door Taro op 23-10-2026 08:50 ]

[Taro]

B-Force schreef op donderdag 22 oktober 2026 @ 21:12:
Hoe hebben jullie de laadpaal excluded uit de batterij? Ik heb het volgende ingesteld, maar zodra de laadpaal aangaat, trekt hij toch mijn batterij leeg. Dat is precies wat ik niet wil 😅

[Afbeelding]

Bij mij staat daarvoor de 3e regel "Huis dekken" uit, die heb je nog aan staan, zet die eens uit?

[bigkevx2]

B-Force schreef op donderdag 22 oktober 2026 @ 21:12:
Hoe hebben jullie de laadpaal excluded uit de batterij? Ik heb het volgende ingesteld, maar zodra de laadpaal aangaat, trekt hij toch mijn batterij leeg. Dat is precies wat ik niet wil 😅

[Afbeelding]

Ik heb het zo gedaan, ik heb een Peblar en deze staat ingesteld op default laden, dus geen solar charging. Ik wissel zelf tussen 1 of 3 fasen.

Bij mij zag ik wel hetzelfde gedrag als wat je omschrijft maar dat verdween eigenlijk wel binnen enkele seconden volgens mij.

[Pixal]

Ik heb OB geinstalleerd en Gielz tijdelijk uitgeschakeld. Alle sensoren ingesteld waaronder solar forecast, koppeling met nordpool erin, batterij op de juiste fase etc. Ik wil nu nog gebruik maken van inkopen tijdens goedkope uren en verkopen op dure uren, zeker nu de zon nauwelijks schijnt.

Afgelopen dagen kreeg ik het apparaat niet aan het laden, terwijl er 20ct prijsverschil tussen goedkope en dure uren zat, ik ben nu dus handmatig de boel aan het regelen.

Verder krijg ik steeds hele wazige plannen, het kan niet anders dan dat één van mijn sensoren verkeerde info stuurt of dat ik een instelling helemaal verkeerd begrepen heb want:

- mijn batterij laadt binnen 3 uur 8kWh, het plan zegt grid charge planned2.96 kWh -> 3h of charging needed ?
- waarom in godsnaam gaat ie op de duurste uren minimale beetjes laden, welke instelling is dat? Ik kan nergens een deadline instelling vinden?
- Home consumption inschatting is te laag maar hij is dat nog aan het leren. Dit belemmert waarschijnlijk ook het hele plan zonder dat ik dat handmatig kan bijstellen?



Als ik mijn batterij nu van handmatig haal en opladen/ontladen toestaan aan zet gaat ie direct met 3000 watt laden en ik heb geen idee waarom en hoe lang, duurste moment van de dag...

Taro schreef op vrijdag 23 oktober 2026 @ 08:44:
[...]

Bij mij staat daarvoor de 3e regel "Huis dekken" uit, die heb je nog aan staan, zet die eens uit?

Dat komt niet overeen met de beschrijving. UIT betekent dat de batterij niets doet terwijl de auto laadt. Deze instelling lijkt juist bedoeld om het totale verbruik min laadpaal te dekken. Ben er nog niet helemaal uit of ik dat wel of niet interessant vind zodra ik volgend jaar zoveel mogelijk NOM wil draaien. (laden doe ik dan toch alleen op de goedkoopste momenten van de dag)

[ Voor 17% gewijzigd door Pixal op 23-10-2026 09:09 ]

[Mai Pensato]

Mai Pensato schreef op vrijdag 23 oktober 2026 @ 00:21:
[...]

De laatste 2 "solar to battery" en "grid to battery"vind ik zeer interessant omdat ik de hele energiedistributie nu met de batterijen erbij in kaar wil brengen. Kan ik dit ook doen voor het ontladen, houdt hij ook ergens vast "discharge to home" en "discharge to grid "?

Ik heb gevonden dat onder dezelfde entiteit ook de attributen: "battery to home" en "battery to grid" zitten. Ik wil van deze 4 statussen dagtellers maken maar kom er nog niet uit hoe ik dit moet doen

@JBS of @NiCNCo kunnejn jullie me in de juiste richting helpen? Ik zal waarschijnlijk Helpers hiervoor moeten aanmaken met YAML code omdat dit nu geen dagtellers zijn maar 15 minuten waarden. Maar wat zit er in: alleen de waarde van de huidge 15 min periode of de vorige 15min waarde of alle waardes van de afgelopen 96 periodes van 15 minuten ?

[ Voor 23% gewijzigd door Mai Pensato op 23-10-2026 09:27 ]

[Gramser]

Gramser schreef op donderdag 22 oktober 2026 @ 19:40:
Een oprechte vraag: als ik nu twee torentjes 2400AC+ aanstuur met Gielz en gast777 op NoM, en ik met een automatisering de zendures op Manual zet als mijn peblar gaat laden… biedt OmniBattery dan een voordeel? Is het updaten bijvoorbeeld makkelijker? Iets anders?

Ik vermoed dat ik mijn vraag te vroeg heb gesteld. Ik lees even mee maar zie vooralsnog geen meerwaarde.

[JBS]

Mai Pensato schreef op vrijdag 23 oktober 2026 @ 00:21:
[...]

De laatste 2 "solar to battery" en "grid to battery"vind ik zeer interessant omdat ik de hele energiedistributie nu met de batterijen erbij in kaar wil brengen. Kan ik dit ook doen voor het ontladen, houdt hij ook ergens vast "discharge to home" en "discharge to grid "?

Ik zie ook battery_to_home_kwh en ...

Ah je bent me al voor: Mai Pensato in "Omnibattery Home Assistant integratie - Deel 1"

[ Voor 14% gewijzigd door JBS op 23-10-2026 09:32 ]

[Mai Pensato]

JBS schreef op vrijdag 23 oktober 2026 @ 09:30:
[...]

Ik zie ook battery_to_home_kwh

ja en ook battery_to_grid Maar hoe maak ik hier dagtellers van ? zie mijn vorige post van paar minuten geleden...

[JBS]

Mai Pensato schreef op vrijdag 23 oktober 2026 @ 09:32:
[...]

ja en ook battery_to_grid Maar hoe maak ik hier dagtellers van ? zie mijn vorige post van paar minuten geleden...

Ik denk dat je daarvoor per attribuut het beste een Utility Meter kunt gebruiken: https://www.home-assistant.io/integrations/utility_meter/.

Maak eerst een template sensor aan voor het battery_to_grid atribuut en maak op basis van die nieuwe entiteit vervolgens een Utility Meter helper aan.

Template sensor:

YAML:

- sensor:
    - name: "Battery to Grid Daily"
      unique_id: battery_to_grid_daily_sensor
      unit_of_measurement: "kWh" 
      device_class: energy
      state_class: total_increasing
      state: >
        {{ state_attr('sensor.omnibattery_daily_operation_timeline', 'battery_to_grid') | float(0) }}

Maar dit kan ook in de UI van HA, je hoeft hierin de YAML bestanden niet in. Niet voor de template sensor en ook niet voor de Utility Meter meter.

[ Voor 50% gewijzigd door JBS op 23-10-2026 09:40 ]

[JoTil]

Taro schreef op vrijdag 23 oktober 2026 @ 08:42:
Ik zie OB nu voor het eerst maximaal ontladen op basis van hoge prijs:
[Afbeelding]

[Afbeelding]

[Afbeelding]

Heb dit bewust begrenst tot 3x3000 Watt, waarbij de 4000 Mix AC+ 3000 Watt voor zijn rekening neemt en de Anker Max & Max AC gezamenlijk 3000 Watt en de 3000 Mix AC+ & 4000 Mix Pro ook gezamenlijk 3000 Watt. In theorie kan deze set 17 kW aan, maar heb nog niet alles vast aangesloten en dus hanteer ik een max van 3000 watt voor de stopcontacten. In de toekomst ook meer opslag voor Fase A, dan kan ik die ook langduriger met 4000-5000 watt gaan belasten.

Wil je een snapshot van je settings bij voorspellend laden delen? Ontladen bij hoge prijs start om één of andere reden niet bij mij.

[Pixal]

Ik hoop nog dat iemand het gouden antwoord op mijn vraag hierboven heeft. Verder heb ik een beetje een unieke situatie die ik eerst moet uitleggen.

Van de meterkast naar mijn schuur loopt een 3-fase grondkabel van 40 meter 2.5mm. Bij de schuur aan het eind van die kabel zit een 4kw omvormer van de zonnepanelen. Net te dun gekozen want toen nog niet bedacht dat er ooit batterijen bij zouden komen. Tussen de meterkast en de omvormer is een extra groepenkast geplaatst zodat op een velige manier (op 1 van de fases) een 3kw batterij kon worden geplaatst. Tehnisch gezien is overbelasting van de kabel dus opgevangen door zekeringen maar in theorie zouden zowel de batterij als de zonnepanelen op vol vermogen kunnen terugleveren en de zekeringen laten slaan.

De kans is klein dat dit gebeurt want als het zonnig is zou er geen reden moeten zijn om op vol vermogen terug te leveren maar om dit te voorkomen had ik een automatisering die de Gielz integratie een beetje kneep. Meer dan x watt van de zonnepanelen en het maximaal ontlaadvermogen van de batterij ging naar beneden.

Kan ik Omnibattery ook op deze manier extern bijsturen? Ik zie heel veel schuifjes maar testen welke ik moet hebben gaat zeer moeizaam omdat Omnibattery vooralsnog alleen maar zelf doet wat ie wil en schuifjes niet lijkt te respecteren of ze direct zelf weer bijstelt.

[ Voor 10% gewijzigd door Pixal op 23-10-2026 11:17 ]

[NiCNCo]

Pixal schreef op vrijdag 23 oktober 2026 @ 11:14:
Ik hoop nog dat iemand het gouden antwoord op mijn vraag hierboven heeft. Verder heb ik een beetje een unieke situatie die ik eerst moet uitleggen.

Van de meterkast naar mijn schuur loopt een 3-fase grondkabel van 40 meter 2.5mm. Bij de schuur aan het eind van die kabel zit een 4kw omvormer van de zonnepanelen. Net te dun gekozen want toen nog niet bedacht dat er ooit batterijen bij zouden komen. Tussen de meterkast en de omvormer is een extra groepenkast geplaatst zodat op een velige manier (op 1 van de fases) een 3kw batterij kon worden geplaatst. Tehnisch gezien is overbelasting van de kabel dus opgevangen door zekeringen maar in theorie zouden zowel de batterij als de zonnepanelen op vol vermogen kunnen terugleveren en de zekeringen laten slaan.

De kans is klein dat dit gebeurt want als het zonnig is zou er geen reden moeten zijn om op vol vermogen terug te leveren maar om dit te voorkomen had ik een automatisering die de Gielz integratie een beetje kneep. Meer dan x watt van de zonnepanelen en het maximaal ontlaadvermogen van de batterij ging naar beneden.

Kan ik Omnibattery ook op deze manier extern bijsturen? Ik zie heel veel schuifjes maar testen welke ik moet hebben gaat zeer moeizaam omdat Omnibattery vooralsnog alleen maar zelf doet wat ie wil en schuifjes niet lijkt te respecteren of ze direct zelf weer bijstelt.

Gewoon de Max contracted power knijpen als je denk dat dat nodig is, voor 3fase max 25A huis aansluiting kan je hem max op 17250W zetten. Ben je echter bank dat je zonnepanalen + batterijen daar boven gaan komen samen, dan knijp je hem dus hier. De batterijen hebben hun eigen max settings, maar die wil je niet geknepen hebben als de accu vol kunnen draaien bij geen zon. Is er wel vollebak zon, dan kijkt de OB naar de totalen en remt hij indien alsnog de batterijen wanneer nodig beneden de batterij instelling. Ik heb precies dezelfde situatie als jou, met een tweede meterkast in de garage, zonnenpanelen 3fase, en 3x batterijen die daar staan, aangesloten met naar het huis middels een 4x2.5mm2 grondkabel van 25m. Heb de temperaturen wel eens gemeten op een goede zon dag, panelen met 4800 watt opbrengst en accu terug laten leveren met 6600watt totaal. De kabel was na 2 uur fysiek niet warmer dan 40gr op de grijze buitenmantel. Dus ik zou met niet al teveel zorgen maken. Maargoed de echte elektricianen onder ons zulle wel anders denken ben ik bang.

[Magnistraal]

Heeft iemand het nieuwe CT003 type met ronde hoeken en geen ext. antenne al aan de praat in HA (omnibatterij)

[Mai Pensato]

JBS schreef op vrijdag 23 oktober 2026 @ 09:33:
[...]

Ik denk dat je daarvoor per attribuut het beste een Utility Meter kunt gebruiken: https://www.home-assistant.io/integrations/utility_meter/.

Maak eerst een template sensor aan voor het battery_to_grid atribuut en maak op basis van die nieuwe entiteit vervolgens een Utility Meter helper aan.

Template sensor:

YAML:

- sensor:
    - name: "Battery to Grid Daily"
      unique_id: battery_to_grid_daily_sensor
      unit_of_measurement: "kWh" 
      device_class: energy
      state_class: total_increasing
      state: >
        {{ state_attr('sensor.omnibattery_daily_operation_timeline', 'battery_to_grid') | float(0) }}

Maar dit kan ook in de UI van HA, je hoeft hierin de YAML bestanden niet in. Niet voor de template sensor en ook niet voor de Utility Meter meter.

Hmm deze attributen geven blijkbaar alleen de planning aan voor de komende periodes van 15 minuten. Ik zoek de historie, hoeveel is er daadwerkelijk de batterij ingegaan vanuit solar en hoeveel vanuit het net en hoeveel is er de batterij uitgegaan voor huisverbruik en hoeveel voor verkoop aan het net. Ik wil die energiedistributie in kaart gaan brengen ook om te weten hoeveel ik prive gebruik en hoeveel echt handel is (inkoop en verkoop vanuit de batterij). Iemand suggesties ?

[JBS]

Mai Pensato schreef op vrijdag 23 oktober 2026 @ 16:11:
[...]

Hmm deze attributen geven blijkbaar alleen de planning aan voor de komende periodes van 15 minuten. Ik zoek de historie, hoeveel is er daadwerkelijk de batterij ingegaan vanuit solar en hoeveel vanuit het net en hoeveel is er de batterij uitgegaan voor huisverbruik en hoeveel voor verkoop aan het net. Ik wil die energiedistributie in kaart gaan brengen ook om te weten hoeveel ik prive gebruik en hoeveel echt handel is (inkoop en verkoop vanuit de batterij). Iemand suggesties ?

Dan zul je denk ik 4 losse template sensoren moeten aanmaken en die allemaal in een eigen Riemann sum integral helper stoppen.

[ Voor 4% gewijzigd door JBS op 23-10-2026 16:23 ]

[Tjaarsveld]

Weet iemand of het mogelijk is om een Marstek accu eerst via de Marstek Modbus intergratie te intergreren in HA en dan toe te voegen aan Omnibattery?

Ik vind dat de Marstek Modbus Intergratie wat makkelijker werkt met individuele accu toe te voegen en geeft mij ook wat meer inzicht in de cell voltage etc


Een nieuwe accu koppellen aam Omnibattery is vrij omslachtig zeker als je er al meerdere hebt, het forceert je om ze allemaal opnieuw te configureren waardoor het wat onduidelijk wort welke accu het is.

[meesje]

Tjaarsveld schreef op vrijdag 23 oktober 2026 @ 17:10:
Weet iemand of het mogelijk is om een Marstek accu eerst via de Marstek Modbus intergratie te intergreren in HA en dan toe te voegen aan Omnibattery?

Ik vind dat de Marstek Modbus Intergratie wat makkelijker werkt met individuele accu toe te voegen en geeft mij ook wat meer inzicht in de cell voltage etc


Een nieuwe accu koppellen aam Omnibattery is vrij omslachtig zeker als je er al meerdere hebt, het forceert je om ze allemaal opnieuw te configureren waardoor het wat onduidelijk wort welke accu het is.

Wat betreft de laatste alinea, ik meen me te herinneren dat gegevens van reeds gekoppelde batterijen bij het opnieuw koppelen gelijk getoond worden.

[JBS]

meesje schreef op vrijdag 23 oktober 2026 @ 18:58:
[...]

Wat betreft de laatste alinea, ik meen me te herinneren dat gegevens van reeds gekoppelde batterijen bij het opnieuw koppelen gelijk getoond worden.

Dat klopt inderdaad. Op dit moment heb ik één batterij gekoppeld. Start ik de wizard om batterijen toe te voegen en kies ik daar 2, dan is de eerste al vooraf ingevuld met de eerder gekoppelde batterij.

[meesje]

Bij mijn drie batterijen heb ik als min soc 10% ingegeven en als hysterese de waarde 2. Twee batterijen hebben nu een soc van 10%, echter de derde op 7%. Het is toch de verwachting dat deze derde gaat bijladen (via het net)? En als ik het goed begrepen heb tot 12% (door de ingestelde laadhysterese).

[Tjaarsveld]

meesje schreef op vrijdag 23 oktober 2026 @ 18:58:
[...]

Wat betreft de laatste alinea, ik meen me te herinneren dat gegevens van reeds gekoppelde batterijen bij het opnieuw koppelen gelijk getoond worden.

Je moet dus elke keer het hele rijtje met accus weer afgaan voordat je de 4e kan toevoegen

Logies lijkt mij om op "Add device" te drukken om een nieuwe accu toe te voegen maar inplaats daarvan stel je hiermee de volledige Omnibattery installatie in

[JBS]

@Tjaarsveld Maar als je in die laatste stap op 'Submit' klikt, dan zul je zien dat de eerste drie stappen vooraf ingevuld zijn met je bestaande batterijen?

[meesje]

JBS schreef op vrijdag 23 oktober 2026 @ 19:50:
@Tjaarsveld Maar als je in die laatste stap op 'Submit' klikt, dan zul je zien dat de eerste drie stappen vooraf ingevuld zijn met je bestaande batterijen?

Dat is inderdaad ook mijn ervaring.

[Tjaarsveld]

JBS schreef op vrijdag 23 oktober 2026 @ 19:50:
@Tjaarsveld Maar als je in die laatste stap op 'Submit' klikt, dan zul je zien dat de eerste drie stappen vooraf ingevuld zijn met je bestaande batterijen?

Klopt ze zijn inderdaad nog ingevuld wel moet ik per Accu 3 schermen doorklikken waarbij hij elke keer de instellingen moet toepassing en daardoor redelijk wat tijd in beslag neemt

Hier de 3 schermen die ik per Accu krijg

Ik wissel nogal van accus en ben nog lang niet klaar met uitbreiden, aardig hinderlijk als ik zometeen 30x een scherm moet doorklikken om 1 Accu toe te voegen

Hier de 3 schermen die je moet doorklikken

[JBS]

@Tjaarsveld Check. Je zou een feature request kunnen indien (https://github.com/ffunes/Omnibattery/issues) hoewel ik vermoed dat het gros van de gebruikers niet zo frequent zal wisselen dus dit minder snel als hinderlijk zal ervaren.

[Tjaarsveld]

JBS schreef op vrijdag 23 oktober 2026 @ 19:56:
@Tjaarsveld Check. Je zou een feature request kunnen indien (https://github.com/ffunes/Omnibattery/issues) hoewel ik vermoed dat het gros van de gebruikers niet zo frequent zal wisselen dus dit minder snel als hinderlijk zal ervaren.

Slim idee zal dit inderdaad doen.

En ja besef best dat ik in de minderheid ben haha

[Cardinal]

Ik heb vanavond even zitten spelen met omnibattery (naast Gielz), maar klopt het dat de predictive model niet verder kijkt dan zonsopgang? Ik bedoel als morgen (bijv) de prijzen hoger zijn, dan wil ik dat hij nu gaat laden en niet zegt, mwah je red het tot zonsopgang, ik doe lekker niets...

Zie ik iets over het hoofd, of is dat nog een gebrek?

[ Voor 8% gewijzigd door Cardinal op 24-10-2026 00:11 ]

[wauswaus]

Dat gebeurt om 00:05.

Jullie ook last van een lege daily operation grafiek op het dashboard? Met als text data may be outdated. The projection is unavailable.

Heb ook een warning in mijn ha log over een eindtijd slot die voor een begin tijd ligt van solar. Vermoed dat de komende wintertijd hier iets mee te doen heeft.

[JBS]

Ja klopt, hier ook.

Bug is al gemeld zie ik https://github.com/ffunes/Omnibattery/issues/678

[ Voor 3% gewijzigd door JBS op 24-10-2026 07:49 ]

[joostdevriesede]

Cardinal schreef op zaterdag 24 oktober 2026 @ 00:06:
Ik heb vanavond even zitten spelen met omnibattery (naast Gielz), maar klopt het dat de predictive model niet verder kijkt dan zonsopgang? Ik bedoel als morgen (bijv) de prijzen hoger zijn, dan wil ik dat hij nu gaat laden en niet zegt, mwah je red het tot zonsopgang, ik doe lekker niets...

Zie ik iets over het hoofd, of is dat nog een gebrek?

Ik heb ook het idee dat er vooral naar de dag zelf wordt gekeken. Het valt me bijvoorbeeld ook al een paar dagen op dat er tussen 23 en 24 uur snel nog even opgeladen wordt van het net, waarschijnlijk om een soort dag doel te halen. Vannacht was dat bijvoorbeeld toch niet nodig, want na 24 uur werd de stroom de volgende (bijna hele dag) goedkoper dan dat uur. Zien anderen ook dat batterij vaak geladen wordt tussen 23 en 24 uur (paars in de grafiek)?

[Pakhaas]

joostdevriesede schreef op zaterdag 24 oktober 2026 @ 08:45:
[...]

Ik heb ook het idee dat er vooral naar de dag zelf wordt gekeken. Het valt me bijvoorbeeld ook al een paar dagen op dat er tussen 23 en 24 uur snel nog even opgeladen wordt van het net, waarschijnlijk om een soort dag doel te halen. Vannacht was dat bijvoorbeeld toch niet nodig, want na 24 uur werd de stroom de volgende (bijna hele dag) goedkoper dan dat uur. Zien anderen ook dat batterij vaak geladen wordt tussen 23 en 24 uur (paars in de grafiek)?

Het zou veel beter zijn als Omnibattery zijn progrognose weer bijstelt zodra de nieuwe tarieven voor de komende dag bekend is.

Zolang het per dag is, is het voor mij nog niet nuttig om met OB te werken.

[Mai Pensato]

Bij mij ook geen projection available.

En inderdaad ook af en toe dat hij net voor middernacht of net na begint te laden terwijl de stroom 1-2 uur later goedkoper is.

Ben nu een week bezig met OB en al heel veel instellingen gecheckt. OB biedt heel veel mogelijkheden, het algoritme is met name gericht op het eigen huisverbruik en dat doet het heel erg goed. Het dashboard ziet er ook heel goed uit.

Waar OB minder goed in is is actief handelen, dus goedkoop inkopen en duur verkopen. Mijn batterijcapaciteit is met 24 kwh groot en ik wil die ook benutten, zeker de laatste maanden van dit jaar. Vanaf 1 jan wordt handelen een stuk minder interessant. Daarvoor heb ik (nog) geen intellingen gevonden in OB om dit automatisch te doen.

Wat ik nu doe is tijdsloten gebruiken voor ontladen en laden. Dit werkt wel ondanks dat hier ook een bug of iets onlogisch tegen kwam. Voor nu pas ik de tijden handmatig aan op de Tibber prijzen. Als OB dit idd niet automatisch kan dan zal ik dit helaas zelf moeten automatiseren.

Zijn er hier anderen die OB ook willen gebruiken voor actief handelen en wat zijn jullie ervaringen?

[wauswaus]

Pakhaas schreef op zaterdag 24 oktober 2026 @ 08:55:
[...]

Het zou veel beter zijn als Omnibattery zijn progrognose weer bijstelt zodra de nieuwe tarieven voor de komende dag bekend is.

Zolang het per dag is, is het voor mij nog niet nuttig om met OB te werken.

Dat zou wel moeten gebeuren aldus de documentatie (https://ffunes.github.io/Omnibattery/configuration/predictive-charging/dynamic-pricing/)

Daar staat:

Automatic re-evaluation¶

The daily plan can be rebuilt by these events:

• Before a selected period: one hour before a future selected period, Omnibattery checks the remaining balance. It silently removes the period if energy is now sufficient or confirms it by notification when the deficit remains. Back-to-back periods are not reconsidered while the previous one is charging.
• Late-day assessment: when solar start has been detected, this runs about 1.5 hours before estimated production ends; otherwise it uses 16:00. It adds eligible future periods only for a remaining deficit of at least 0.3 kWh. This safety top-up is not rejected by the optional arbitrage-margin gate.
• SOC drop: a chronological plan rebuilds after a five-percentage-point drop from the last evaluated fleet average. A fallback non-chronological plan retains the 30-point threshold. An SOC rise does not trigger it.
• Solar forecast revision: a change of at least 1.5 kWh in either direction rebuilds the plan, with a 30-minute cooldown and a maximum of four such rebuilds per day. Measured solar since the saved reading is removed before comparison, and an unavailable sensor is not treated as a collapsed forecast.
• Excluded-device solar claim: a material change in an excluded load, such as an electric vehicle session, rebuilds the plan because that device changes how much forecast solar is available to the battery.
• Tomorrow’s prices: newly published prices rebuild the remaining horizon once per day. If a selected charge period is running, this rebuild waits until it ends.
• Relevant settings: changes to battery minimum/maximum SOC, Solar Forecast Safety Margin, or Guaranteed Minimum SOC rebuild the plan on the next control cycle.

Ik heb ook nog wat twijfels over hoe OB het predictive charging aanvliegt.
Wat ik wil is NOM, wanneer onvoldoende zon aanvullen vanuit grid maar dan deze ingekochte energie alleen gebruiken op momenten waarbij de tarieven hoger zijn dan ingekocht + marge.

Kijk ik even naar afgelopen nacht. Ging de nacht in met een lege batterij. Vervolgens wordt er 15min geladen om 02:45 (prijs: 0.148). Vervolgens wordt deze energie gebruikt om NOM te doen tot 04:45 om weer te laden. Echter, ik zou dat niet willen want het prijs verschil tussen laden en dan NOM was max 0.006 cent.
Ik heb een Min. arbitrage margin ingesteld van 2.5 cent, dus ik zou verwachten dat ie niet zou inkopen.

Begin me steeds meer af te vragen of ik het gedrag dat ik zou willen wel gedaan kan worden door OB.

[CP1977]

Zijn er meer mensen die bij omni battery de dagelijkse werking niet zien? Zou te maken hebben met wintertijd. Puur even ter controle dat ik niet de enige ben met dit issue

ai antwoord

“De foutmelding geeft aan dat de integratie 'Omnibattery' crasht omdat de eindtijd van een energie-interval gelijk is aan of vóór de starttijd ligt (energy interval end must be after start). Dit gebeurt in de logica die een back-up-planning maakt (de chronological planning fallback) wanneer de dynamische prijzen worden berekend.

Dit is een bekend type bug in Home Assistant-integraties die met dynamische energietarieven of uurlijkse schema's werken. De fout treedt vaak op tijdens de overgang naar of van de zomertijd (DST), omdat de klok dan een uur verschuift of herhaalt, waardoor intervallen een lengte van 0 of een negatieve duur krijgen. Vandaag is het zaterdag 24 oktober 2026, en komende nacht (vóór zondag 25 oktober) gaat de wintertijd in, wat dit vermoeden direct bevestigt.”

[ Voor 70% gewijzigd door CP1977 op 24-10-2026 11:15 ]

[meesje]

meesje schreef op vrijdag 23 oktober 2026 @ 19:37:
Bij mijn drie batterijen heb ik als min soc 10% ingegeven en als hysterese de waarde 2. Twee batterijen hebben nu een soc van 10%, echter de derde op 7%. Het is toch de verwachting dat deze derde gaat bijladen (via het net)? En als ik het goed begrepen heb tot 12% (door de ingestelde laadhysterese).

Ervaren jullie ook dat OB niet bijlaadt tot de min SoC? Nu zijn er twee batterijen op 8% en eentje op 6%.

[B-Force]

Mai Pensato schreef op zaterdag 24 oktober 2026 @ 09:01:
Bij mij ook geen projection available.

En inderdaad ook af en toe dat hij net voor middernacht of net na begint te laden terwijl de stroom 1-2 uur later goedkoper is.

Ben nu een week bezig met OB en al heel veel instellingen gecheckt. OB biedt heel veel mogelijkheden, het algoritme is met name gericht op het eigen huisverbruik en dat doet het heel erg goed. Het dashboard ziet er ook heel goed uit.

Waar OB minder goed in is is actief handelen, dus goedkoop inkopen en duur verkopen. Mijn batterijcapaciteit is met 24 kwh groot en ik wil die ook benutten, zeker de laatste maanden van dit jaar. Vanaf 1 jan wordt handelen een stuk minder interessant. Daarvoor heb ik (nog) geen intellingen gevonden in OB om dit automatisch te doen.

Wat ik nu doe is tijdsloten gebruiken voor ontladen en laden. Dit werkt wel ondanks dat hier ook een bug of iets onlogisch tegen kwam. Voor nu pas ik de tijden handmatig aan op de Tibber prijzen. Als OB dit idd niet automatisch kan dan zal ik dit helaas zelf moeten automatiseren.

Zijn er hier anderen die OB ook willen gebruiken voor actief handelen en wat zijn jullie ervaringen?

Dit zou in v 1.5.0 verholpen moeten zijn. Ik had dit aangemeld op het forum van OB. Sinds v 1.5.0 kijkt hij verder vooruit. Eerder keek hij alleen maar tot middernacht, nu tot zonsopkomst de volgende dag. De gedachte is dat je dat moet overbruggen.

Je kan dit natuurlijk heel eenvoudig ondervangen door een automation te maken die ieder uur de re-evaluatie aanroept. Ik heb gedacht om dit te doen, maar eigenlijk zie ik de noodzaak niet zo meer op dit moment. Misschien mis ik een paar cent, maar dat is dan ok.

[meesje]

meesje schreef op zaterdag 24 oktober 2026 @ 11:17:
[...]

Ervaren jullie ook dat OB niet bijlaadt tot de min SoC? Nu zijn er twee batterijen op 8% en eentje op 6%.

Probleem is denk ik opgelost. Ik zag in de logs een melding over predictive charging, terwijl ik dat niet aan had staan. Nog een keer de configuratie opgestart en voorspellend laden aangeklikt. Geen vinkje gezet (deze was niet aangevinkt), maar wel op submit geklikt. Dit heeft kennelijk iets getriggerd, de batterij is nu aan het laden vanaf het net.
Om wat settings te bekijken, heb ik een keer voorspellend laden aangevinkt en toen de setup afgebroken. Kennelijk heeft dit er wel voor gezorgd dat voorspellend laden aan is gezet, maar niet goed ingericht.

[NiCNCo]

Voor iedereen die vandaag vanwege de wintertijd ingang geen voorspellingen hebben en geen graph er is al een oplossing gepost op,

https://github.com/ffunes/Omnibattery/issues/678#issuecomment-6382369492

[meesje]

NiCNCo schreef op zaterdag 24 oktober 2026 @ 15:01:
Voor iedereen die vandaag vanwege de wintertijd ingang geen voorspellingen hebben en geen graph er is al een oplossing gepost op,

https://github.com/ffunes/Omnibattery/issues/678#issuecomment-6382369492

Ook al heb ik dyn.prijzen niet aanstaan, zag wel deze melding in de logs voorbij komen. Google gaf al aan dat dit waarschijnlijk door het uur tijdsverschil komt. Mooi dat er in ieder geval een fix voor is. Bedankt voor het delen.

[xzaz]

Ook toegpast, is de maintainer uberhaupt nog actief?

[Goichi]

xzaz schreef op zaterdag 24 oktober 2026 @ 15:36:
Ook toegpast, is de maintainer uberhaupt nog actief?

Hij is momenteel op verlof tot 3 november, details

[Tom35]

Hier staat predictive loading ook op maar zonder die pricing. Deze nacht heeft hij echter de batterij vol geladen ondanks dat vandaag we zon ging schijnen waardoor ik 10kw zonneenergie op het net gezet heb want de batterijen waren zo goed als vol.

Ik heb ondertussen de marge voor zonneenergie bij netmaden verhoogd naar 3kw, ben benieuwd of dit wel werkt.


Welke zonneenergie voorspeller gebruiken jullie ?


Tom

[JBS]

@Tom35 Had je zonnestroom voorspelling wel de juiste waarde? Of gebruikte je die nog niet?

Ik gebruik Solcast (https://solcast.com/).

[Tom35]

Ik gebruik ook solcast.

Ben een.newbie hierin met HA dus alles nog aan het uitvlooien hoe dat in elkaar zit.

Ik gebruik de sensor resterende voorspelling vandaag van solcast

De data zijn normaal juist ingesteld in solcast


Gegarandeerde min soc staat op 50% met een hysteresisch van 15%... nu is die opnieuw naar 100% aan het gaan merk ik...ik zie in HA ook de melding dat hij moet laden omdat er geen zon meer verwacht wordt vandaag...

Maar waarom gaat die naar 100% als ik 3kw zonnemarge heb ingesteld, de max soc op 50% (5kw) met een +15/-15%

Ik doe duidelijk iets mis of die flipt omdat ik die pricing sensor heb uitgeschakeld...

De curve in solcast komt bijna 1/1 overeen met wat mijn solarlog geregistreerd heeft vandaag..




Tom

[ Voor 112% gewijzigd door Tom35 op 24-10-2026 22:06 . Reden: Added extra data en screenshots ]

[doobieters]

Ik gebruik OmniBattery met 4 Zendure SolarFlow 800 Plus-systemen en 5 AB2000X-batterijen.

Bij één systeem is de berekende cyclusteller (sensor.zendure_solarflow_4_battery_cycle_count_calc_2) plotseling naar 1297,1 cycli gesprongen. De andere drie systemen staan op 3,4, 4,2 en 4,7 cycli.

Bij SolarFlow 4 rapporteert Home Assistant 12,87 kWh totale laadenergie en 13,07 kWh totale ontlaadenergie. De waarde lijkt dus niet in verhouding te staan tot de geregistreerde energie.

Heeft iemand dit ook meegemaakt? En weet iemand hoe ik de berekende cyclusteller veilig kan herstellen, of waardoor deze plotseling zo hoog kan worden?

Ik wil voorkomen dat ik de sensor of statistieken reset zonder de oorzaak te kennen.

[meesje]

Het bijladen wanneer onder de min soc gaat nog niet goed. Mijn situatie was als volgt: in de Zendure app en in OB had ik de min soc op 10% staan en de laadhysterese op 2%. Deze laatste zorgt er voor dat wanneer onder min soc (dus lager dan 10) er bijgeladen wordt tot 12%. Dit voorkomt continu bijladen.
Echter de 10% in OB en 10% in Zendure gaat niet helemaal lekker. Ik heb nu de min soc in OB op 12% gezet en de batterij werd bijgeladen. Echter tot 12% en niet tot de verwachte 14%.
Dit bijladen loopt niet lekker. Bij de andere twee batterijen hetzelfde gedaan (staan nu op 9 en 10% soc). Je zou verwachten dat deze dan ook bijladen worden, maar dat gebeurt niet. Ik had verwacht dat het na bijladen van de eerste batterij de andere twee ook aan de beurt zouden zijn.
Via batterij wijzigen/toevoegen had ik de min soc aangepast van 10 naar 12. Na herstarts bleef het OB dashboard de waarde 10 tonen. Bij opnieuw doorlopen van de config werd er wel 12 getoond… Toen maar in het dashboard onder bediening de min soc op 12 gezet.

Edit: volgens mij moet ik de laadhysterese zien in combinatie met de max soc (zie ook de uitleg in het config scherm). Volgens deze uitleg gaat een batterij pas weer laden wanneer deze van 100 naar 98% is gezakt. Dus ook weer in het kader van een zo’n hoog mogelijk rendement halen. Dus dat batterij 1 is bijladen tot 12% is dan ok. Echter de andere twee batterijen zouden ook moeten bijladen.

[ Voor 30% gewijzigd door meesje op 25-10-2026 12:14 ]

[Gerry1982]

Ik doe dit voor het eerst maar ik loop helaas vast want ik krijg mijn Zendure P1 meter maar niet zichtbaar.

Iemand tips of gaat dat niet lukken met de P1 meter van Zendure?

[Cardinal]

@Gerry1982 Ik zou eerst eens kijken in de Zendure topics of begin hier

[JBS]

@Gerry1982 Wat doe je precies het het eerst? Waar krijg je je P1 meter niet zichtbaar?

[Gerry1982]

JBS schreef op zondag 25 oktober 2026 @ 20:51:
@Gerry1982 Wat doe je precies het het eerst? Waar krijg je je P1 meter niet zichtbaar?

Ik ben nieuw met Home Assistent en dus ook Omnibattery.
Ik heb al veel dingen ingesteld met verschillende integraties HACS, SMA Solar, Forecast Solar, Nord Pool.
Maar tijdens de installatie van Omnibattery moet ik de Netverbruiksensor aangeven maar zie mijn Zendure P1 meter niet ertussen staan. Ook niet bij Instellingen > Hulpmiddelen > Statussen.

Ik doe vast wat verkeerd maar zie nog even niet wat....

[JBS]

@Gerry1982 Hoe heb je die P1 meter geïntegreerd in HA?

[Gerry1982]

JBS schreef op zondag 25 oktober 2026 @ 20:57:
@Gerry1982 Hoe heb je die P1 meter geïntegreerd in HA?

Uhh nog niet?

[JBS]

Gerry1982 schreef op zondag 25 oktober 2026 @ 20:58:
[...]

Uhh nog niet?

Check Cardinal in "Omnibattery Home Assistant integratie - Deel 1"

[ Voor 36% gewijzigd door JBS op 25-10-2026 21:09 ]

[Gerry1982]

Ahh bedankt ik had dit reeds gedaan maar volgens mij ben ik vergeten het IP adres erin te zetten.. morgen maar is verder proberen.

[Supahted]

ph2m schreef op dinsdag 20 oktober 2026 @ 10:20:
Ik Heb Omnibattery met mijn Marstek Venus E v3 met mijn Enphase & APSystems zonnepanelen & Zonneplan nu een paar weken draaien, ben nog aan het fijntunen

Vraagje: welke Electricity price sensor gebruik je voor de zonneplan prijzen?

[ercolano]

Ben gebruiker van een Peblar, Anker, HA met Omni en ben al 2 dagen aan het strijden om opbrengst en kosten van de batterij in kaart te brengen. Geen standaard feature van Omni, dus wellicht offtopic, maar hulp wordt op prijs gesteld.

Wat ik wil is dat elk kwartier de laad of ontlaad Kwh tegen kwartierprijzen worden opgeteld tot een dag en maandtotaal. Voor het eerst in mijn leven de google ai gebruikt om yamls te maken, helpers,cards e.s. en het is ongelooflijk wat een fouten daar in staan (en hoe enthousiast hij weer met verbeteringen op eigen werk komt...). Daar kom ik dus wel achter, maar werkend heb ik het nog niet .Discl al heeeel lang niet meer geprogrammeerd.
Is het kosten aspect iets wat in Omni bijgevoegd kan worden of heeft iemand een link naar een werkende configuratie.

thanxs.

[eymey]

Ik ben sinds ongeveer een weekje ook een voorzichtig enthousiaste gebruiker van Omnibattery!

Heb me ongeveer 1,5 jaar beholpen met een Marstek Venus E, waar ik veel handmatig in veranderde al naar gelang het verwachte prijsverloop, verwacht verbruik in huis, etc. Niet handig om veel mee bezig te moeten zijn.

Onlangs de upgrade gemaakt naar een Zendure SolarFlow 2400 Pro. Voorlopig nog zonder direct gekoppelde zonnepanelen, maar die wil ik nog wel aanschaffen, ook voor off-grid stiuaties. Ook 3 AB3000L's erbij, dus totaal ongeveer 11 kWh . Verder een Enphase systeem met ongeveer 3,5 kWp vermogen.

Nu wilde ik ook meteen van de gelegenheid gebruikmaken om dingen meer geautomatiseerd te laten verlopen, met ook wat betere prijsoptimalisatie, zonder hier steeds zelf mee bezig te zijn. Zodoende op Omnibattery uit gekomen. Want veel andere integraties of pogingen tot geautomatiseerde prijsoptimalisatie hebben nodered nodig, of ik moet nog heel veel zelf automatiseringen schrijven.

In de basis werkt Omnibattery erg mooi! De leercurve is wel groot met diverse parameters. De eerste dagen gedroeg Omnibattery zich naar mijn mening onlogisch, maar met behulp van Gemini (pro) begin ik het nu aardig te begrijpen.

Nu heb ik een aardig mooie setup, die erg mooi gericht is op zo veel mogelijk eigenverbruik, pririteit aan laden op zonne-energie, maar ook voldoende marge voor als de Solcast totaal niet klopt.

Ook de Shelly Pro 1PM die de groep van ons buitenstopcontact in de voortuin monitort, wordt netjes uitgesloten zodat het opladen van onze PHEV met de grannycharger niet wordt gecompenseerd bij NOM (dat verbruik komt dus altijd van het net / uit PV overschot)

Wel mis ik nog wat features (of ik heb nog niet uitgevonden dat ze er al wel zijn / hoe ze werken):

• Een optie om de prognose voor huisverbruik voor komende nacht (of volgende dag) handmatig bij te stellen, bijvoorbeeld als we weten dat we 'wasdag' hebben of wanneer mijn vriendin van plan is brood te gaan bakken

• Nog wat verder vooruit kijken dan alleen tot 'morgenochtend zonsopkomst'

Voorbeeld: Vandaag was m'n Zendure helemaal tot 100% opgeladen tijdens het 'zonnevenster' + goedkopere uren, voor de wekelijkse volledige lading.

Met ons verbruik vanavond en voorspelde verbruik komende nacht en morgenochtend, ziet Omnibattery geen noodzaak om vannacht te gaan laden van het net omdat hij verwacht dat er dan nog genoeg in de batterij zit om de flinke prijspiek in de ochtend op te vangen.

Echter, ik verwacht morgen weinig zon (de 4 kWh die Solcast verwacht, vind ik aan de rooskleurige kant). En ik weet dat we morgen de was gaan doen en andere dingen, én ook de prijsdip in de middag niet zo laag zal zijn als vannacht. Dus ik zou graag willen dat hij vannacht wél gaat opladen.

Nu kwam ik, na suggestie van Gemini, erachter dat als ik de SOC-vloer aanzet en deze op 90% zet, hij vannacht tijdens de goedkope uren tóch een lading vanaf het net inplant! . Ik zie dat sommigen hier graag zouden zien dat die SOC-vloer sneller wordt gerespecteerd, maar ik vind het dus wel een mooie bijkomstigheid dat hij deze toch probeert te voldoen tijdens periodes van lage prijzen.

Nu dus ook een automatisering aangemaakt die, zodra hij wordt aangezet, als eerste trigger direct de SOC-vloer aanzet en op 90% zet. Zo kan ik de avond voor een 'wasdag', als ik zie dat in de nacht de prijzen gunstig zijn, Omnibattery er toch toe verleiden om de batterij in de nacht op te laden! De automatisering zet om 06:00 de SOC-vloer ook weer op 20% en uit

[ Voor 5% gewijzigd door eymey op 25-10-2026 22:57 ]

[bigkevx2]

ercolano schreef op zondag 25 oktober 2026 @ 22:30:
Ben gebruiker van een Peblar, Anker, HA met Omni en ben al 2 dagen aan het strijden om opbrengst en kosten van de batterij in kaart te brengen. Geen standaard feature van Omni, dus wellicht offtopic, maar hulp wordt op prijs gesteld.

Wat ik wil is dat elk kwartier de laad of ontlaad Kwh tegen kwartierprijzen worden opgeteld tot een dag en maandtotaal. Voor het eerst in mijn leven de google ai gebruikt om yamls te maken, helpers,cards e.s. en het is ongelooflijk wat een fouten daar in staan (en hoe enthousiast hij weer met verbeteringen op eigen werk komt...). Daar kom ik dus wel achter, maar werkend heb ik het nog niet .Discl al heeeel lang niet meer geprogrammeerd.
Is het kosten aspect iets wat in Omni bijgevoegd kan worden of heeft iemand een link naar een werkende configuratie.

thanxs.

Tip: vergeet al die algemene AI’s, die zijn voornamelijk bezig met het corrigeren van hun eigen rommel werk en slijten daar ook bijzonder veel woorden = tokens aan om je vooral keer op keer hetzelfde te vertellen en je nog verder van je doel af te brengen.

Ik neem even puur mijn eigen experimenten waarbij ik niet moet vergeten te vertellen dat ik een Ing. titel heb in software engineering dus wel redelijk kan volgen wat er gedaan wordt ;-).

Simpel voorbeeld, ik had wat Apex charts in elkaar zitten draaien zonder AI en wilde dit laten werken op een date selector zoals op het Energy dashboard, dat is gelukt maar als ik eerlijk ben, het zag er niet uit. Ondertussen heb ik via het werk Claude code die ik via Samba aan mijn HA server heb hangen en vroeg hem eens te kijken, 5 min. later had ik exact dezelfde floating date selector in place en als je dan ziet hoe simpel het eigenlijk is….

Dan je vraag, zie mijn resultaat van een middagje ideeën pitchen en bijsturen, dit is geloof ik v6.
Dit is ongeveer wat je bedoeld maar niet helemaal. Kern van mijn punt, met de juiste AI en de juiste prompting zet je dit echt vrij snel in elkaar. De code is meer dan prima, de structuur is goed en als je, net als ik, zegt dat je dezelfde look and feel als in Omnibattery wenst dan is dit het resultaat. De data is semi fictief, ik draai vanaf maart en heb veel gegevens uit home wizard exports en heb pas sinds eind augustus mijn batterijen. Maar het geeft een hele goeie indicatie van waar je naartoe wil gaan. Ik toon hier 1 card waar ik er drie heb staan. 1 met het actuele jaa met echte data en mijn huidige energie contract. 2 met dezelfde data maar dan over drie schijven, mijn dan nog steeds lopende contract onder de 2027 regels, dezelfde data met een vast contract met prijzen als ik deze nu zou moeten afsluiten en 3 via een dynamisch contract.

Overal reken ik ook de financiering mee maar ook mijn ERE vergoeding en EV laad declaratie.

Al met al, precies wat IK denk nodig te hebben.

[ikbenmichel]

Ik ben newbie op dit vlak en ook op Omnibattery terecht gekomen en wil deze vanaf 1 nov gaan gebruiken omdat ik dan overstap naar een dynamisch contract bij frank energie.

Met 2 marstek accu’s, 1 venus 2 via een ew11, en 1 venus 3 ethernet.

Tot nu toe ging het instellen me redelijk af alleen ai nodig gehad om de voorspellende kwartierprijzen van frank energie toe te voegen.

Ik ga deze topic volgen,

[Tazzios]

ercolano schreef op zondag 25 oktober 2026 @ 22:30:
Ben gebruiker van een Peblar, Anker, HA met Omni en ben al 2 dagen aan het strijden om opbrengst en kosten van de batterij in kaart te brengen. Geen standaard feature van Omni, dus wellicht offtopic, maar hulp wordt op prijs gesteld.

Wat ik wil is dat elk kwartier de laad of ontlaad Kwh tegen kwartierprijzen worden opgeteld tot een dag en maandtotaal. Voor het eerst in mijn leven de google ai gebruikt om yamls te maken, helpers,cards e.s. en het is ongelooflijk wat een fouten daar in staan (en hoe enthousiast hij weer met verbeteringen op eigen werk komt...). Daar kom ik dus wel achter, maar werkend heb ik het nog niet .Discl al heeeel lang niet meer geprogrammeerd.
Is het kosten aspect iets wat in Omni bijgevoegd kan worden of heeft iemand een link naar een werkende configuratie.

thanxs.

Ik gebruik zelf Dynamic Energy Cost om de kosten/opbrengst van mijn batterijen, zonnepanelen en warmtepomp te meten.

[Devke]

ercolano schreef op zondag 25 oktober 2026 @ 22:30:
Ben gebruiker van een Peblar, Anker, HA met Omni en ben al 2 dagen aan het strijden om opbrengst en kosten van de batterij in kaart te brengen. Geen standaard feature van Omni, dus wellicht offtopic, maar hulp wordt op prijs gesteld.

Wat ik wil is dat elk kwartier de laad of ontlaad Kwh tegen kwartierprijzen worden opgeteld tot een dag en maandtotaal. Voor het eerst in mijn leven de google ai gebruikt om yamls te maken, helpers,cards e.s. en het is ongelooflijk wat een fouten daar in staan (en hoe enthousiast hij weer met verbeteringen op eigen werk komt...). Daar kom ik dus wel achter, maar werkend heb ik het nog niet .Discl al heeeel lang niet meer geprogrammeerd.
Is het kosten aspect iets wat in Omni bijgevoegd kan worden of heeft iemand een link naar een werkende configuratie.

thanxs.

Probeer Claude eens. Ik vind die voor code vele malen beter.

[fplin]

Ik had de anker solix ac aangesloten in omnibattery met maximum laad en ontlaad vermogen van 1500 Watt. omdat ik de stekker nog gebruikte. nu is de accu aangesloten op een eigen groep en kan ik dus de 3500 watt gaan gebruiken. ik heb in de anker app de instellingen aangepast naar 3500 watt en dat werkt via de anker app. helaas krijg ik deze instelling maar niet werkend in omnibatty die blijft op max 1500 en 1500 staan. waar moet ik zoeken om omnibattery ook 3500 3500 te laten gebruiken. of moet ik alles verwijderen en opnieuw beginnen ?

Wanneer je de limieten in de Anker app hebt aangepast, moet je dat in Omnibattery ook in tabblad Batterij en dan onderaan "Bediening" aanpassen. dit is inmiddels ook aangepast maar hij blijft maar 1500 laden en 1500 watt ontladen. iemand anders nog suggesties ?

[ph2m]

Supahted schreef op zondag 25 oktober 2026 @ 21:15:
[...]


Vraagje: welke Electricity price sensor gebruik je voor de zonneplan prijzen?

[B-Force]

Meest handig is om zelf een zonneplan sensor aan te maken met een template obv nord pool

[Supahted]

ph2m schreef op maandag 26 oktober 2026 @ 17:22:
[...]

[Afbeelding]

Dank voor de info. Kon de sensor niet vinden, maar ben er inmiddels achter. Ik maakte gebruik van de officiele HA Zonneplan integratie, maar deze biedt geen forecast gegevens. Ben nu overgeschakeld naar de HACS Zonneplan integratie en dat gaat goed

[Supahted]

Ik heb Omnibattery nu ook draaien met twee Zendure SolarFlow 2400 AC+ sets (totaal 16.32 kWh capaciteit), maar in Omnibattery worden hier foutieve waarden weergegeven:



Hebben andere mensen met een Zendure SolarFlow 2400 AC+ hier ook last van?

[meesje]

Supahted schreef op maandag 26 oktober 2026 @ 18:42:
Ik heb Omnibattery nu ook draaien met twee Zendure SolarFlow 2400 AC+ sets (totaal 16.32 kWh capaciteit), maar in Omnibattery worden hier foutieve waarden weergegeven:

[Afbeelding] [Afbeelding]

Hebben andere mensen met een Zendure SolarFlow 2400 AC+ hier ook last van?

Herkenbaar. Bij de config van OB moet je zelf aangeven wat de capaciteit is van de batterijen. Dit veld heeft een default waarde van 0,01.

[Supahted]

meesje schreef op maandag 26 oktober 2026 @ 18:46:
[...]

Herkenbaar. Bij de config van OB moet je zelf aangeven wat de capaciteit is van de batterijen. Dit veld heeft een default waarde van 0,01.

Wizard nog eens doorgelopen en ik zie het nu. Niet goed gelezen

[meesje]

Supahted schreef op maandag 26 oktober 2026 @ 18:48:
[...]

Wizard nog een doorgelopen en ik zie het nu. Niet goed gelezen

Ik destijds ook niet hoor. Bij andere integraties werden deze waarden automatisch opgehaald.

[Spikydog]

meesje schreef op maandag 26 oktober 2026 @ 18:52:
[...]

Ik destijds ook niet hoor. Bij andere integraties werden deze waarden automatisch opgehaald.

Thnxs, ik had het ook niet gezien.

[frebs]

CappieL schreef op dinsdag 20 oktober 2026 @ 14:46:
[...]


Ik heb ze beide naast elkaar, maar heb voor nu Gielz even 'uitgezet'. Die staat nu op Standby en ik laat Omnibattery NOM-en.
Heb nog niet de moeite genomen om OB uit te zetten, maar ik zie wel schuifjes staan bij "Laden toestaan" en "Ontladen toestaan". Als je die alle twee uitzet, verwacht ik dat ie niets zal doen.

Ook ik wil graag OB monitoren terwijl Gielz tot 1 januari dynamisch handelt. Als ik OB actief heb met "alle schuifjes" uit, dan doet Gielz niets meer. Alleen als ik OB uitschakel, kan Gielz weer actief worden. Zie ik een instelling in OB over het hoofd?

Gevonden; schuifje Handmatige modus op aan. Dan blijft Gielz werken.

[ Voor 5% gewijzigd door frebs op 27-10-2026 18:19 ]

[JBS]

frebs schreef op dinsdag 27 oktober 2026 @ 17:40:
[...]

Ook ik wil graag OB monitoren terwijl Gielz tot 1 januari dynamisch handelt. Als ik OB actief heb met "alle schuifjes" uit, dan doet Gielz niets meer. Alleen als ik OB uitschakel, kan Gielz weer actief worden. Zie ik een instelling in OB over het hoofd?

En als je tussen die twee stappen even de modus in de Anker app wijzigt zodat Anker tijdelijk de regie overneemt van Omnibattery, en je daarna Gielz activeert?

[meesje]

JBS schreef op dinsdag 27 oktober 2026 @ 18:15:
[...]

En als je tussen die twee stappen even de modus in de Anker app wijzigt zodat Anker tijdelijk de regie overneemt van Omnibattery, en je daarna Gielz activeert?

Ik vermoed dat Anker geen effect heeft op Zendure batterijen.

[Supahted]

meesje schreef op zondag 25 oktober 2026 @ 11:59:
Het bijladen wanneer onder de min soc gaat nog niet goed. Mijn situatie was als volgt: in de Zendure app en in OB had ik de min soc op 10% staan en de laadhysterese op 2%. Deze laatste zorgt er voor dat wanneer onder min soc (dus lager dan 10) er bijgeladen wordt tot 12%. Dit voorkomt continu bijladen.
Echter de 10% in OB en 10% in Zendure gaat niet helemaal lekker. Ik heb nu de min soc in OB op 12% gezet en de batterij werd bijgeladen. Echter tot 12% en niet tot de verwachte 14%.
Dit bijladen loopt niet lekker. Bij de andere twee batterijen hetzelfde gedaan (staan nu op 9 en 10% soc). Je zou verwachten dat deze dan ook bijladen worden, maar dat gebeurt niet. Ik had verwacht dat het na bijladen van de eerste batterij de andere twee ook aan de beurt zouden zijn.
Via batterij wijzigen/toevoegen had ik de min soc aangepast van 10 naar 12. Na herstarts bleef het OB dashboard de waarde 10 tonen. Bij opnieuw doorlopen van de config werd er wel 12 getoond… Toen maar in het dashboard onder bediening de min soc op 12 gezet.

Edit: volgens mij moet ik de laadhysterese zien in combinatie met de max soc (zie ook de uitleg in het config scherm). Volgens deze uitleg gaat een batterij pas weer laden wanneer deze van 100 naar 98% is gezakt. Dus ook weer in het kader van een zo’n hoog mogelijk rendement halen. Dus dat batterij 1 is bijladen tot 12% is dan ok. Echter de andere twee batterijen zouden ook moeten bijladen.

Ik ervaar hier ook problemen mee. Ik heb een minimum SOC ingesteld staan van 10%, maar vandaag stond een van de Zendure batterijen op 6% SOC, terwijl het systeem niet gaat bijladen.

[ Voor 13% gewijzigd door Supahted op 27-10-2026 19:30 ]

[meesje]

Supahted schreef op dinsdag 27 oktober 2026 @ 19:22:
[...]

Ik ervaar hier ook problemen mee. Ik heb een minimum SOC ingesteld staan van 10%, maar vandaag stond een van de Zendure batterijen op 6% SOC, terwijl het systeem niet gaat bijladen.

Google kwam nog met de suggestie dat er een conflict is tussen de min soc in deze Zendure app en in OB. Beide had ik op 10% staan. Volgens Google zou hierdoor de batterij in een inactieve stand komen waardoor ie ook niet meer door OB aangestuurd zou kunnen worden.
Toen voor de zekerheid de min soc in OB op 12% gezet. De afgelopen in de gaten gehouden, maar het werkt inderdaad nog niet helemaal goed. Wel een keertje gezien dat 1 van de 3 batterijen ging bijladen, maar de andere 2 dan weer niet.
Volgens mij de laadhysterese alleen effect op de max soc. Ik dacht ook op de min soc, want dan zou er, in mijn geval, bijgeladen moeten worden tot 14%. Dat is nog nooit gebeurd.

[Supahted]

meesje schreef op dinsdag 27 oktober 2026 @ 19:27:
[...]

Google kwam nog met de suggestie dat er een conflict is tussen de min soc in deze Zendure app en in OB. Beide had ik op 10% staan. Volgens Google zou hierdoor de batterij in een inactieve stand komen waardoor ie ook niet meer door OB aangestuurd zou kunnen worden.
Toen voor de zekerheid de min soc in OB op 12% gezet. De afgelopen in de gaten gehouden, maar het werkt inderdaad nog niet helemaal goed. Wel een keertje gezien dat 1 van de 3 batterijen ging bijladen, maar de andere 2 dan weer niet.
Volgens mij de laadhysterese alleen effect op de max soc. Ik dacht ook op de min soc, want dan zou er, in mijn geval, bijgeladen moeten worden tot 14%. Dat is nog nooit gebeurd.

Ik heb nu de Guaranteed Minimum SOC optie onder predictive charging ingeschakeld. Volgens de documentatie garandeerd deze instelling ten alle tijden de minimum SOC, totdat er solar productie is. Alleen is de laagste waarde die je kan instellen 20%. Eens kijken wat dat doet.

[JBS]

meesje schreef op dinsdag 27 oktober 2026 @ 18:48:
[...]

Ik vermoed dat Anker geen effect heeft op Zendure batterijen.

Ah nee, ik denk dat je daar een punt hebt

Maar het principe is wellicht wel herbruikbaar. Controle van Omnibattery naar Zendure naar Gielz.

[meesje]

Supahted schreef op dinsdag 27 oktober 2026 @ 19:32:
[...]

Ik heb nu de Guaranteed Minimum SOC optie onder predictive charging ingeschakeld. Volgens de documentatie garandeerd deze instelling ten alle tijden de minimum SOC, totdat er solar productie is. Alleen is de laagste waarde die je kan instellen 20%. Eens kijken wat dat doet.

Ik heb nog geen dynamisch contract en predictive functionaliteit nog niet aan staan. Wellicht helpt dit bij jou. Maar ook zonder dit, zou het moeten werken. En in mijn ogen zelfs bijlage tot de grens incl. de laadhysterese. Hiermee voorkom veelvuldig klein bijlaadacties. Mijn vermoeden is een bug. Misschien eerdaags een melding maken via GitHub.

[Supahted]

meesje schreef op dinsdag 27 oktober 2026 @ 19:59:
[...]

Ik heb nog geen dynamisch contract en predictive functionaliteit nog niet aan staan. Wellicht helpt dit bij jou. Maar ook zonder dit, zou het moeten werken. En in mijn ogen zelfs bijlage tot de grens incl. de laadhysterese. Hiermee voorkom veelvuldig klein bijlaadacties. Mijn vermoeden is een bug. Misschien eerdaags een melding maken via GitHub.

Eens. Ik zal e.e.a. nog meer testen en anders een bug report doen.

[meesje]

Supahted schreef op dinsdag 27 oktober 2026 @ 20:15:
[...]

Eens. Ik zal e.e.a. nog meer testen en anders een bug report doen.

Bijlage had overigens bijladen moeten zijn.

Ze staan bij mij nu overigens alle drie keurig op 12%. Morgen is wat zon. Dus ik denk niet genoeg mogelijkheid om te testen.

[ Voor 22% gewijzigd door meesje op 27-10-2026 20:49 ]

[Mann59]

Taro schreef op zondag 18 oktober 2026 @ 23:04:

Wat is Omnibattery?

Omnibattery is een gratis open-source integratie voor Home Assistant waarmee ondersteunde thuisaccu’s centraal kunnen worden uitgelezen en aangestuurd. De integratie kan met één thuisbatterij worden gebruikt, maar ondersteunt ook installaties met meerdere accu’s en zelfs verschillende merken door elkaar.

Daarmee kan Home Assistant een deel van de rol van een Energy Management System (EMS) of Home Energy Management System (HEMS) overnemen. In plaats van dat iedere thuisaccu uitsluitend de eigen regeling van de fabrikant volgt, kan Omnibattery centraal bepalen hoeveel de beschikbare batterijen gezamenlijk moeten laden of ontladen.

Er kunnen maximaal tien ondersteunde thuisaccu’s binnen één installatie worden gecombineerd. Iedere batterij behoudt daarbij zijn eigen omvormer, batterijmanagement en technische beveiligingen. Omnibattery verzorgt de bovenliggende aansturing.

Waarvoor kun je Omnibattery gebruiken?

De basis is het volgen van het huishoudelijke stroomverbruik. Hiervoor gebruikt Omnibattery een vermogenssensor in Home Assistant die de actuele afname van en teruglevering aan het elektriciteitsnet meet.

Daar bovenop zijn verschillende vormen van energiemanagement mogelijk:

• nul-op-de-meter, waarbij thuisaccu’s gezamenlijk proberen de afname en teruglevering rond een ingestelde waarde te houden
• meerdere thuisbatterijen centraal aansturen en het benodigde vermogen verdelen
• laden tijdens ingestelde tijdvakken
• slim laden op basis van dynamische stroomprijzen
• opgeslagen energie bewaren voor duurdere momenten
• onder voorwaarden energie terugleveren bij hoge prijzen
• rekening houden met verwachte zonneopbrengst
• grote verbruikers, zoals een laadpaal of elektrische auto, geheel of gedeeltelijk uitsluiten van de accuregeling
• rekening houden met vermogensgrenzen en eventueel stromen per fase

Predictive Charging kan daarnaast het verwachte energieverbruik, beschikbare batterijcapaciteit, toekomstige stroomprijzen en een zonnevoorspelling combineren om te bepalen hoeveel energie moet worden ingekocht en wanneer dat het voordeligst kan gebeuren.

Dynamische energieprijzen

Voor dynamische prijssturing ondersteunt Omnibattery verschillende prijsbronnen. Op dit moment zijn onder andere beschikbaar:

• Nord Pool
• Zonneplan
• EPEX Spot
• ENTSO-e
• Tibber
• PVPC
• CKW

Afhankelijk van de gebruikte bron kunnen uurprijzen of kwartierprijzen worden verwerkt. De Dynamic Pricing-modus kijkt niet alleen naar de actuele prijs, maar kan ook toekomstige prijsperiodes gebruiken om een laadplan op te stellen.

Een zonnevoorspelling is optioneel, maar kan de planning verbeteren. Onder andere Forecast.Solar en Solcast kunnen hiervoor via Home Assistant worden gebruikt. Daarmee kan bijvoorbeeld worden voorkomen dat een thuisbatterij ’s nachts volledig met goedkope netstroom wordt gevuld terwijl enkele uren later veel zonnestroom wordt verwacht.

Ondersteunde thuisaccu’s

Niet iedere thuisaccu van een ondersteund merk werkt automatisch met Omnibattery. Ondersteuning is afhankelijk van het exacte model en de beschikbare lokale communicatiemethode.

Op dit moment worden officieel de volgende modellen ondersteund:

Merk	Modellen
Marstek	Venus E v2, Venus E v3, Venus A, Venus D
Zendure	SolarFlow 800, 800 Plus, 800 Pro, 1600 AC+, 2400 AC+, 2400 AC Pro, 3000 Mix AC+, 4000 Mix AC+, 4000 Mix Pro
Anker SOLIX	Solarbank Max AC, Solarbank XE AC, Solarbank 4 E5000 Pro
Sessy	Sessy Home Battery
Hoymiles	MS-A2, HiBattery 1920 AC, HiBattery 4020 AC, HiBattery 4020 X
Huawei	SUN2000-omvormer in combinatie met LUNA2000

De verbinding verschilt per merk. Zendure wordt bijvoorbeeld lokaal via HTTP aangestuurd, Anker SOLIX en een aantal Marstek-modellen gebruiken Modbus, Sessy gebruikt een lokale HTTP-interface en Hoymiles gebruikt MQTT via Home Assistant.

De compatibiliteitslijst verandert regelmatig. Controleer daarom voor installatie altijd of het exacte model en de gebruikte firmware of verbinding worden ondersteund.

Wat heb je nodig?

Voor een basisinstallatie zijn volgens de documentatie nodig:

• Home Assistant 2024.4.1 of nieuwer
• HACS voor de aanbevolen installatie
• minimaal één ondersteunde thuisaccu
• een lokale verbinding met die thuisaccu
• een Home Assistant-sensor die totale netafname en teruglevering in watt of kW weergeeft

Voor de netmeting wordt een update ongeveer iedere één tot twee seconden aanbevolen. Een tragere sensor kan ervoor zorgen dat de thuisaccu’s minder snel reageren op veranderingen in het stroomverbruik.

Per fabrikant kunnen aanvullende voorwaarden gelden. Zo moet bij ondersteunde Zendure-modellen de eigen HEMS-aansturing uitgeschakeld zijn. Bij Anker SOLIX moet Third-Party Control worden ingeschakeld en kan maar één Modbus-client tegelijk verbinding maken.

Eén of meerdere thuisaccu’s

Omnibattery is niet uitsluitend bedoeld voor grote installaties. Ook met één ondersteunde thuisbatterij kunnen functies zoals nul-op-de-meter, tijdgestuurd laden, dynamische stroomprijzen en zonnevoorspellingen worden gebruikt.

Bij meerdere accu’s kan Omnibattery het gevraagde vermogen over de beschikbare batterijen verdelen. Daarbij kan rekening worden gehouden met onder andere het laadpercentage, laad- en ontlaadlimieten en de beschikbare capaciteit.

Verschillende ondersteunde merken mogen binnen dezelfde Omnibattery-installatie worden gecombineerd.

Laadpalen en andere grote verbruikers

Een laadpaal of andere grote verbruiker kan de regeling van een thuisaccu behoorlijk beïnvloeden. Wanneer een elektrische auto bijvoorbeeld met 7 kW wordt opgeladen, zou een standaard nul-op-de-meterregeling kunnen proberen een deel daarvan vanuit de thuisbatterij te leveren.

Omnibattery biedt daarom mogelijkheden om zulke verbruikers geheel of gedeeltelijk uit te sluiten van de accuregeling. Daarmee kan bijvoorbeeld worden ingesteld dat de accu wel het normale huishoudelijke verbruik compenseert, maar niet automatisch wordt leeggetrokken om een elektrische auto te laden.

Installatie

De aanbevolen installatie verloopt via HACS. Daarna wordt Omnibattery toegevoegd via:

Instellingen > Apparaten en diensten > Integratie toevoegen

De configuratie begint met de netvermogenssensor en de elektrische grenzen van de aansluiting. Vervolgens kunnen één of meerdere thuisaccu’s worden toegevoegd. Aanvullende onderdelen zoals tijdvakken, uitgesloten apparaten, zonnevoorspellingen en dynamische prijssturing kunnen daarna afzonderlijk worden geconfigureerd.

Handige links

Omnibattery op GitHub
Officiële documentatie
Actuele compatibiliteitslijst
Installatiehandleiding

Dit topic

Dit topic is bedoeld voor het uitwisselen van ervaringen met Omnibattery: installatie, instellingen, ondersteunde thuisaccu’s, combinaties van verschillende merken, Home Assistant-configuraties, dynamische prijssturing, Solar Forecast en laadpalen. Eventuele bugs of problemen kan je het beste gewoon via Github melden zodat de ontwikkelaars dit adequaat op kunnen pakken.

Vermeld bij vragen bij voorkeur het merk en type thuisaccu, de gebruikte verbindingsmethode, Home Assistant-versie en Omnibattery-versie. Dat maakt het voor anderen een stuk eenvoudiger om mee te denken.

Ik heb bij de aansturing van 2 x Marstek Venus E (versie3) Omnibattery nog niet een dag zonder toezicht kunnen laten werken. Er waren freezes van een batterij, waarbij de andere battery na het uitschakelen van een kacheltje van !000 Watt gewoon doorging met het leveren van 1000 Watt aan het net. Etc. Kijk eens naar de "fixed" lijst van de nieuwste pre-release: https://github.com/ffunes/Omnibattery/releases Ik heb het idee dat de ontwerpers de ins- en outs van de batterijen via "reverse-engineering" proberen te beprijpen maar daar nog niet helemaal in slagen. Complimenten voor de intentie, maar als ik een paar dagen niet naar de batterijen om wil kijken disable ik Omnibattery in HA en zet de batterijen in de Marstek App weer op zelf-consumptie.

[Nieass]

Mann59 schreef op dinsdag 27 oktober 2026 @ 21:15:
[...]

Ik heb bij de aansturing van 2 x Marstek Venus E (versie3) Omnibattery nog niet een dag zonder toezicht kunnen laten werken. Er waren freezes van een batterij, waarbij de andere battery na het uitschakelen van een kacheltje van !000 Watt gewoon doorging met het leveren van 1000 Watt aan het net. Etc. Kijk eens naar de "fixed" lijst van de nieuwste pre-release: https://github.com/ffunes/Omnibattery/releases Ik heb het idee dat de ontwerpers de ins- en outs van de batterijen via "reverse-engineering" proberen te beprijpen maar daar nog niet helemaal in slagen. Complimenten voor de intentie, maar als ik een paar dagen niet naar de batterijen om wil kijken disable ik Omnibattery in HA en zet de batterijen in de Marstek App weer op zelf-consumptie.

En ik heb het idee dat jij het een en ander gewoon niet juist hebt ingesteld.

Ik stuur hier namelijk al maandenlang mijn 3 marstek venus e v3's aan zonder de problemen die jij noemt 🤷🏼‍♂️

Ik ben vrij nauw betrokken bij het beta testen en heb regelmatig contact met de ontwikkelaar van de integratie. Ik denk dat in 9vd10 gevallen bij zulke problemen mensen uiteindelijk iets verkeerds hebben ingesteld.

En dat is niet erg, want er zijn ook zoveel mogelijkheden/opties. Maar om nou meteen het probleem neer te leggen bij de integratie....

Wellicht dat je eens kan delen hoe je ze hebt aangesloten (rechtstreeks via UTP?)

En wat je instellingen zijn, dan kan er geholpen worden.

[ Voor 4% gewijzigd door Nieass op 28-10-2026 09:40 ]

[Mann59]

Dank voor je reactie. De 2 Marsteks (Venus E versie 3) zijn via LAN aangesloten op mijn router in de meterkast (LAN kabel naar zolder, daar een 5 poorts switch zonder instelmogelijkheden). De HA Green in de meterkast is ook aangesloten op die router. De Green maakt met de USB kabel verbinding met de P1 (gevoede) verdeler. (Samen met de Green gekocht). Bij de configuratie van Omnibattery heb ik de Mac adressen van de batterijen ingevoerd. (In de Marstek App laten de batterijen beiden hetzelfde IP adres zien). In de Marstek App verschijnt "mode" ipv bijvoorbeeld zelf consumptie. Het dashboard van Omnibattery laat alle waarden zien en ik kan de instellingen veranderen naar wens. Ook de aanpassing van reactie snelheden, stabiel, smooth, agressief hebben effect en tonen soms oscillating als resultaat tot ik fine tune op de situatie van dat moment. (Variatie in belasting). Voor suggesties houd ik me graag aanbevolen. Vriendelijke groet! P.s. ik vergeet te melden dat de Marsteks beiden op versie 151 staan.

[ Voor 6% gewijzigd door Mann59 op 28-10-2026 11:54 ]

[Nieass]

Mann59 schreef op woensdag 28 oktober 2026 @ 11:47:
Dank voor je reactie. De 2 Marsteks (Venus E versie 3) zijn via LAN aangesloten op mijn router in de meterkast (LAN kabel naar zolder, daar een 5 poorts switch zonder instelmogelijkheden). De HA Green in de meterkast is ook aangesloten op die router. De Green maakt met de USB kabel verbinding met de P1 (gevoede) verdeler. (Samen met de Green gekocht). Bij de configuratie van Omnibattery heb ik de Mac adressen van de batterijen ingevoerd. (In de Marstek App laten de batterijen beiden hetzelfde IP adres zien). In de Marstek App verschijnt "mode" ipv bijvoorbeeld zelf consumptie. Het dashboard van Omnibattery laat alle waarden zien en ik kan de instellingen veranderen naar wens. Ook de aanpassing van reactie snelheden, stabiel, smooth, agressief hebben effect en tonen soms oscillating als resultaat tot ik fine tune op de situatie van dat moment. (Variatie in belasting). Voor suggesties houd ik me graag aanbevolen. Vriendelijke groet! P.s. ik vergeet te melden dat de Marsteks beiden op versie 151 staan.

Dat laatste is het probleem v151 is niet stabiel qua modbus verbinding.

Ik ken een mede betatester die nu op v151.2 zit en dat is nu stabiel (die had ook gezeur met v151) Zelf zit ik nog op v149 welke sowieso stabiel is.

Dus vervolgstap, even om v151.2 vragen aan de support. Ben er vrij zeker van dat dit je probleem gaat oplossen.

@Taro wellicht een idee dit te vermelden in de OP? Met zekerheid kan ik melden dat v149 en v151.2 probleemloos werken. Dit mag wel vrij duidelijk vermeld worden want v151 en ik dacht ook v150 hebben veel modbus problemen. Waarbij dus het probleem niet aan de integratie ligt maar aan de batterij Firmware. In dit geval gaat het hier om de Marstek Venus E v3 firmware.

[ Voor 12% gewijzigd door Nieass op 28-10-2026 12:16 ]

[Mann59]

Dank, fijn dat de oorzaak duidelijk is. En eens met jouw suggestie aan Taro. Overigens, het voelt wel onzeker als de betrouwbare werking van Omnibattery zo afhankelijk blijkt van de firmware van Marstek. Ik begrijp natuurlijk dat Marstek hier wijzigingen doorvoert bij de firmware updates die een onvoorzien effect hebben op Omnibattery. Tegelijkertijd lijkt het een beetje op trail and error. Des te belangrijker je suggestie aan Taro. Geef aan op welke versie van de Marstek firmware Omnibattery stabiel werkt. Hartelijke groet!

[meesje]

Sowieso vind ik het knap dat er zoveel producten worden ondersteund. Een erg mooie gedachte, maar lijkt me wel erg bewerkelijk.
Zo ervaar ik een issue met mijn Zendure batterijen dat deze via OB niet bijladen wanneer onder min soc. Is zoiets generiek, specifiek voor een merk, specifiek een type, of zelfs voor een specifieke firmware versie? En dan nog verschillende merken gecombineerd aansturen. Daarom mijn petje af voor de ontwikkelaar.

[Tazzios]

Dat de Marstek updates buggy is geen nieuws en heeft niets met Omnibattery te maken. Alle software die via modbus loopt tegen problemen aan bij sommige firmware versies.

Advies: Stuur je de batterij aan via modbus en werkt het? doe dan geen updates (tenzij je in een avontuurlijke bui bent . )

[Nieass]

Tazzios schreef op woensdag 28 oktober 2026 @ 12:47:
Dat de Marstek updates buggy is geen nieuws en heeft niets met Omnibattery te maken. Alle software die via modbus loopt tegen problemen aan bij sommige firmware versies.

Advies: Stuur je de batterij aan via modbus en werkt het? doe dan geen updates (tenzij je in een avontuurlijke bui bent . )

Sluit ik mij bij aan inderdaad, als het werkt lekker zo laten. Tenzij duidelijk bewezen is dat een nieuwe firmware probleemloos werkt.

In principe als je ze aanstuurt via Omnibattery hoeven je Marsteks (of ander merk) ook geen verbinding met internet te hebben dus voor veiligheid hoef je ook niet te updaten dan.

[ Voor 14% gewijzigd door Nieass op 28-10-2026 13:07 ]

[Gyrolion]

Wat ik wel als advies hier wil meegeven aan iedereen is dat Omnibattery echt even de tijd nodig heeft om je huisverbruik te leren.

Het draait nu een week bij mij en het lijkt allemaal wat logischer te regelen nu, met wat betere voorspellingen.

[JBS]

Gyrolion schreef op woensdag 28 oktober 2026 @ 14:39:
Wat ik wel als advies hier wil meegeven aan iedereen is dat Omnibattery echt even de tijd nodig heeft om je huisverbruik te leren.

Het draait nu een week bij mij en het lijkt allemaal wat logischer te regelen nu, met wat betere voorspellingen.

Klopt inderdaad. Zie voor wat achtergrond informatie over hoe dit in de praktijk werkt JBS in "Omnibattery Home Assistant integratie - Deel 1"

[SonOfSam]

Interessant, nu heb ik net een Marstek venus v3 aangeschaft, maar die moet nog binnenkomen. Heeft het zin om Omnibatterij te installeren om mijn stroomverbruik al te leren kennen? Kan dat uberhaubt zonder batterij?

[JBS]

SonOfSam schreef op woensdag 28 oktober 2026 @ 15:23:
Interessant, nu heb ik net een Marstek venus v3 aangeschaft, maar die moet nog binnenkomen. Heeft het zin om Omnibatterij te installeren om mijn stroomverbruik al te leren kennen? Kan dat uberhaubt zonder batterij?

Dat is ook onderdeel van deze post: JBS in "Omnibattery Home Assistant integratie - Deel 1"

Een gekoppelde batterij is niet nodig om een verbruiksprofiel op te gaan bouwen, maar je komt de installatie wizard van Omnibattery niet door zonder een batterij te koppelen. Deze vlieger gaat dus alleen op als je al een batterij hebt om tijdelijk te koppelen.

Lijkt me overigens wel een feature request waard.

[ Voor 25% gewijzigd door JBS op 28-10-2026 15:30 ]

[eymey]

meesje schreef op woensdag 28 oktober 2026 @ 12:47:
Sowieso vind ik het knap dat er zoveel producten worden ondersteund. Een erg mooie gedachte, maar lijkt me wel erg bewerkelijk.
Zo ervaar ik een issue met mijn Zendure batterijen dat deze via OB niet bijladen wanneer onder min soc. Is zoiets generiek, specifiek voor een merk, specifiek een type, of zelfs voor een specifieke firmware versie? En dan nog verschillende merken gecombineerd aansturen. Daarom mijn petje af voor de ontwikkelaar.

Bedoel je met "Min. Soc" de "soc vloer" bij predictief laden, of een andere instelling per batterij?

Ik heb Omnibattery er nog niet op kunnen betrappen dat hij mijn Zendure SF2400 PRO of één van de AB3000L's onder de 11% heeft laten zakken. Als hij die waarden bereikt gaat de batterij in rust.

En als ik de SOC Floor setting aan zet (die zet ik 's avonds soms geforceerd op 100% als ik morgen veel stroomverbruik verwacht voor de broodbak hobby van m'n vriendin en niet zeker ben van de zonverwachting), dan gaat hij op zoek naar een geschikt moment (qua prijs) om de betreffende SOC te bereiken.

[superduper]

Ik merk de laatste tijd iets vreemds op: als ik de battery (Marstek V3) tot 100% laadt (volgens wekelijkse setting) dan reageert de batterij niet meer op modbus commandos om te ontladen (geregeld door omnibatterij). Ik moet hem dan met de groene knop hard resetten, en dan loopt het weer als een zonnetje.

Laad ik hem op tot 95% (regulier plafond) dan is er geen issue. Ik zit op firmware 148 en heb verder geen enkel probleem.

Weet iemand wat dit kan zijn? Kan natuurlijk de 100% vermijden, maar het moet natuurlijk wel gewoon kunnen,.