Omnibattery Home Assistant integratie - Deel 1

[Taro]

En hoppa, laden is gestart:



3000 Watt via Fase A, 1500 watt via Fase B en 1500 watt. via Fase C.

Ziet er als volgt uit:


Vervolgens:


Een paar seconden later:


De 4000 Mix AC+ springt ook regelmatig naar een hoger vermogen ivm ingestelde max van 3000 ipv 1500:

[ Voor 50% gewijzigd door Taro op 19-10-2026 00:13 ]

[brogel]

leuk dat je en topic hebt gemaakt.

Een eerste vraagje.
Nu de donkere periode er stilaan aankomt, vroeg ik me af wat ik het beste doe als er verschillende dagen bijna geen vermogen naar de batterij gaat.

Stel dat ik de minimale SOC op 10% heb staan en deze wat blijft schommelen tussen 10 en 15%.
Kan ik de batterij dan het beste om de X dagen vanuit het net opladen? Zit er zo’n functionaliteit in OmniBattery?

Ik weet dat OB de functie heeft om één keer per week naar 100% te laden, maar ook daarvoor gebruikt hij bij mij geen stroom uit het net. Tijdens de donkere dagen zal er natuurlijk ook niet genoeg PV zijn om de batterij tot 100% te laden.

Of hoef ik me hier geen zorgen over te maken en kan ik hem gewoon zijn ding laten doen?

[nodri2000]

Hier draait ook omnibattry via HA op een Marstek Venus 3.

Probleem is dat Omnibattery de accu niet gaat opladen als ik deze via de LAN kabel aansluit. Elke dag moet ik dan via de app de accu op self optimisation zetten, erg vervelend. Weet iemand hoe ik dat gedrag kan aanpassen? Via Omni heb ik wel meer functies dan de app.

[Slonzo]

brogel schreef op maandag 19 oktober 2026 @ 08:29:
Of hoef ik me hier geen zorgen over te maken en kan ik hem gewoon zijn ding laten doen?

Heeft weinig met Omnibattery te zien, dat vraag je beter in een batterijtopic
Maar het blijft gewoon een LFP batterij dus het is niet geweldig om hem in lage SOC te laten staan.
Ik zou hem in idle rond de 50% houden door de "reserve" instelling tot daar op te trekken.
Of tussen de 30 en 70% proberen te houden als je de batterij wel actief gebruikt.

[dehardstyler]

brogel schreef op maandag 19 oktober 2026 @ 08:29:
leuk dat je en topic hebt gemaakt.

Een eerste vraagje.
Nu de donkere periode er stilaan aankomt, vroeg ik me af wat ik het beste doe als er verschillende dagen bijna geen vermogen naar de batterij gaat.

Stel dat ik de minimale SOC op 10% heb staan en deze wat blijft schommelen tussen 10 en 15%.
Kan ik de batterij dan het beste om de X dagen vanuit het net opladen? Zit er zo’n functionaliteit in OmniBattery?

Ik weet dat OB de functie heeft om één keer per week naar 100% te laden, maar ook daarvoor gebruikt hij bij mij geen stroom uit het net. Tijdens de donkere dagen zal er natuurlijk ook niet genoeg PV zijn om de batterij tot 100% te laden.

Of hoef ik me hier geen zorgen over te maken en kan ik hem gewoon zijn ding laten doen?

Ik heb met dezelfde vraag zitten spelen al. Ik kan met mijn opwek de batterij dus echt gaan uitzetten in in ieder geval december en januari. Ik had mezelf voorgenomen om de batterij tot 50% te laden en dan echt uit te zetten, maar ik moet even kijken wat er dan gebeurt en of de batterij niet toch (langzaam) blijft leeg gaan. Als dat het geval is, ga ik de batterij gewoon met een script in HA tussen de 40 en 60% houden die 2 maanden en laat ik de batterij dus wel gewoon aan staan, maar in Standby modus. Is dus even afhankelijk wat er straks eind november gebeurt.

Heeft iemand hier al eens voor langere tijd op standby gestaan en blijft de batterij dan inderdaad leeglopen? Ik zie bij mij een verbruik van zeg 11 a 12W als de batterij op 12% staat en dus "leeg" is. Ik neem aan dat als je dat twee maanden doet je dus het percentage zelfs onder die 12% kan krijgen?

[harrak1974]

Goedemorgen,

Ook ik ga dit topic met interesse volgen.

Heb 2 solarbanK Max ac’s draaien via HA/Omni

Onlangs heb ik Omni bijgewerkt maar daarna bleek dat mijn laadpaal niet meer werd uitgesloten tijdens het laden terwijl deze nog wel Volgens Omni uitgesloten was.

Uiteindelijk heb ik Omni moeten verwijderen en opnieuw geïnstalleerd en toen gekozen voor de oude software(1.4x).

Nu werkt alles weer zoals voorheen en blijft mijn laadpaal netjes buiten het bereik van de Ankers. Kortom, de ankers worden niet leeggetrokken door de laadpaal.

Ik Lees wel dat dit ook in de nieuwe versie van Omni zou moeten kunnen, het uitsluiten?

Zijn er meerdere gebruikers die dit ook ervaren hebben?

[apt]

Leuke ontwikkeling. Ik had ook lopen denken over dit probleem en nog geen zin gehad om het op te lossen.

Het gecombineerd aansturen van meerdere batterijen is nuttig. Ik was zelf aan het werk aan een optimalisatie routine voor het laden van verwarming (zie het als thermische batterij), SWW-buffer, twee rijdende accu's, en als sluitstuk een thuisaccu. Vergelijk mijn werk met de day ahead optimizer addon.

Mijn idee op basis van dat werk is dat het juist essentieel is voor je energie management om de randvoorwaarden voor verwarming en vervoer goed te kennen om die integraal mee te optimaliseren. Ik vraag me op basis van de onderstaande passage af of jij precies het omgekeerde doet door te doen alsof de grote gebruikers (warmtepomp / auto) niet bestaan?

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.

Ik denk dat ik behoefte zou hebben aan een addon die een combinatie is van een day ahead optimizer die integraal optimaliseert en daarbij ook sets batterijen kan optimaliseren. De gedacht is dan dus dat je eerst schuift met gebruik binnen de gestelde randvoorwaarden en dan de batterij optimaliseert.

Ik vermoed dat de twee optimalisatie routines nu niet met elkaar samenwerken?
Hoe kijken jullie tegen een dergelijke integratie van functies?

[KoningPaulus]

Dank voor het opstarten! Ga ik met interesse volgen en hopelijk deze winter wat mee doen icm HA.

[MikeyMan]

Interessant. Heb nu zelf een HA aansturing voor m'n laadpaal (Zaptec Go 2) in elkaar gevibe-code. De Zendures 'volgen' in principe vanzelf nu met de HA integratie. Maar dit is wellicht een wat nettere oplossing.

Dit vervangt dan de zensdk integratie? Of werkt dit naast elkaar?

[CappieL]

@Taro heb mijn Zendure Solarflow 2400AC (zonder + of Pro) in Omnibattery zitten en die doet het ook.
Kwam er later achter dat zowel Gielz als Omnibattery als kapitein wilden dienen, dus heb voor nu Gielz op 'Standby' gezet en laat ik OB nu het regelwerk doen.
Als ik weer terug wil naar Gielz, weet jij welke instelling ik dan moet hebben in OB om nog wel te kunnen monitoren? Moet ik OB dan op Handmatige modus zetten met 0W im- en export?

[JBS]

In het verlengde van mijn interesse in hoe Omnibattery het huishoudelijk verbruiksprofiel opbouwt (JBS in "Het grote Anker Solix plug-and-play thuisaccu systemen topic") en continu herziet/bijschaaft, heb ik Gemini eens een analyse laten doen op de codebase. Het heeft me goed geholpen om beter te begrijpen wat Omnibattery nou eigenlijk onder de motorkap doet rondom dit onderdeel. Wellicht ook interessant voor anderen, dus hieronder het resultaat van deze (ook weer door Gemini gevalideerde) analyse.

Lap tekst, en ongetwijfeld missen er details of nuances, maar voor mij geeft dit een mooi beeld én de bevestiging dat het nuttig is Omnibattery al te laten draaien zonder dat ie al daadwerkelijk de batterij aanstuurt om zo te werken aan het verbruiksprofiel.

1. Wat is er per se nodig om te starten en te blijven lopen?

Om het huishoudelijk verbruiksprofiel op te bouwen en continu bij te werken, stelt de integratie een paar harde eisen:

• Actieve stroomdata: Het systeem moet het verbruik kunnen berekenen of aflezen. Dit vereist dat de data van de netstroom-sensor (slimme meter) en de telemetrie van de batterij continu binnenkomen, óf dat er een specifieke optionele sensor voor het huisverbruik is ingesteld.
• Vakantiemodus (Vacation Mode) uitgeschakeld: Deze modus is expliciet bedoeld om het inleren van verbruik te pauzeren. Om nieuwe data op te nemen in het profiel, moet deze schakelaar uit staan.
• Tijd (Samples): Hoewel het systeem direct start met een tijdelijke schatting, is het pas écht in staat tot nauwkeurige voorspellingen zodra het voldoende overeenkomende dagen (samples voor doordeweeks en weekend) heeft geleerd of uit de database heeft kunnen ophalen.

2. De rol van de batterij (De Meetbasis)

Het systeem leert het gedrag van het huishouden niet via een aparte meter, maar gebruikt de batterij en slimme meter als cruciale rekencomponenten.

• De batterij als meetinstrument: De basis voor het profiel wordt live berekend met de formule: Huisverbruik = Netstroom (Grid) + Batterij (AC) + Zonnepanelen. De integratie trekt het opladen van de batterij (vanuit het net) af van het netverbruik, en telt het ontladen van de batterij op bij het huisverbruik. Hierdoor vervuilt het opladen van de batterij de verbruikshistorie van het huis niet.
• Correcties bij offline of lege batterijen: Als een batterij de verbinding verliest, wordt deze genegeerd zodat vastgelopen data ("frozen ac_power") het profiel niet opblaast. Zodra batterijen helemaal leeg zijn (Min SOC), wordt het stroomverbruik uit het net verzameld in een speciale teller (Grid at Min SOC) en toegevoegd aan het profiel, zodat het totale verbruik niet wordt onderschat.

3. Hoe het historische verbruiksprofiel wordt opgebouwd

• 28-daags kwartierprofiel: Op basis van de meetdata verdeelt het systeem een dag in 96 lokale kwartieren en leert het een 28-daags verbruiksprofiel met behulp van trapezium-integratie.
• Slimme patroonherkenning: Bij de analyse wordt rekening gehouden met de overgang tussen zomer- en wintertijd (DST-aware binning) en worden specifieke wegingen voor doordeweekse dagen, weekenden en dagtypes toegepast.
• Filteren van externe factoren: Externe grootverbruikers (zoals een EV-lader) worden automatisch van dit basisprofiel afgetrokken, zodat ze de normale voorspelling niet in de war schoppen.
• Historische backfill & Onvolwassen profielen: Bij een nieuwe installatie haalt het systeem via een "Recorder backfill" historische verbruiksdata stilletjes op de achtergrond op uit Home Assistant. Als er toch onvoldoende data is, wordt het reeds verbruikte deel van de dag aangevuld met een tijdelijke, genormaliseerde dagcurve.
• Handmatige correctie: Uitzonderlijke verbruiksdagen kunnen achteraf (tot maximaal de laatste 35 hele dagen) handmatig uit de geleerde consumptie worden gehaald met de actie omnibattery.exclude_consumption_days.

4. De rol van zonne-energie (PV) en onvoorspelbaarheid

Zonne-energie is weerafhankelijk. Daarom gebruikt Omnibattery hiervoor geen 28-daags historisch profiel, maar actuele data en dynamische correcties:

• Focus op actuele voorspellingen: De integratie gebruikt actuele zonne-voorspellingen (bijv. Solcast) als directe input voor de uren die nog komen.
• Live accumulator: Het systeem berekent continu de nog verwachte zonne-energie door de daadwerkelijk geproduceerde energie af te trekken van de initiële voorspelling (resterend = voorspelling - al_geproduceerd).
• Veiligheidsmarges (Safety Margins): Omdat zon-voorspellingen vaak optimistisch zijn, maakt de integratie gebruik van een instelbare "Solar Forecast Safety Margin" (een veiligheidsmarge in kWh). Deze functie heeft de eerdere instelling voor een procentuele marge ("Predictive grid charge margin") volledig overgenomen. Bij nieuwe installaties wordt deze kWh-buffer standaard ingesteld op 5% van de totale batterijcapaciteit.
• Directe herberekening (Re-evaluatie): Zodra de voorspelling voor zonne-energie met 1,5 kWh of meer verandert, herrekent het systeem direct het laadplan.
• Avond-correctie (Evening re-evaluation): Ongeveer 1,5 uur voordat de zonneproductie eindigt, controleert het systeem of de opwek is tegengevallen of het verbruik hoger was. Is dit het geval, dan worden er dynamisch extra net-laadmomenten in de avond ingepland.

5. Triggers voor re-evaluatie

De Omnibattery integratie kent verschillende automatische en handmatige triggers om het actuele laadplan en de bijbehorende voorspelling (re-evaluatie) gedurende de dag te herzien. Op basis van de codebase zijn dit de specifieke triggers:

• Zonne-voorspelling wijzigt: Het systeem herrekent het laadplan direct zodra de voorspelling voor de verwachte zonne-energie met 1,5 kWh of meer verschuift.
• Publicatie van nieuwe prijzen: Er vindt een her-evaluatie plaats op het moment dat de elektriciteitsprijzen voor de volgende dag worden gepubliceerd.
• Wijziging in instellingen (Runtime opties): Het systeem triggert een herberekening wanneer instellingen zoals de max SOC, de minimum SOC grens (floor), of een veiligheidsmarge worden aangepast.
• Pre-slot controle: Bij het gebruik van Dynamic Pricing is er een automatische mid-day herziening 1 uur voordat een geplande goedkope laad-sessie (slot) begint, waarbij de actuele capaciteit en zonne-verwachting worden gecontroleerd om te verifiëren of het laden via het net nog steeds nodig is.
• Avond-evaluatie (Evening re-evaluation): Een vaste automatische check die 1,5 uur voor het verwachte einde van de zonneproductie (of om 16:00 uur als er geen zon is gedetecteerd) draait. Deze trigger controleert of het actuele verbruik hoger uitviel of de zonneproductie is tegengevallen, waarna er dynamisch extra net-laadmomenten in de avond kunnen worden ingepland.
• SOC-daling (SOC-drop trigger): Bij een onverwachte daling in de State of Charge (SOC) van de batterij (bijvoorbeeld in de ochtend na een sterke nachtelijke afname) wordt een opwaartse her-evaluatie geactiveerd om gemiste goedkope momenten te ondervangen.
• Systeemopstart en herstel (Startup & Retry): Een her-evaluatie wordt getriggerd bij het opstarten van de integratie (bijvoorbeeld na een Home Assistant herstart als de initiële nachtelijke planning was gemist), of wanneer ontbrekende/falende prijs- of zonne-forecastdata succesvol is hersteld via retries.
• Handmatig: De herziening kan op elk gewenst moment handmatig worden gestart via de "Re-evaluate" knop in het dashboard, die beschikbaar is in zowel Dynamic Pricing als Time Slot modes.

6. Hoe en waar wordt de data opgeslagen?

De data-opslag werkt in drie fysieke en logische lagen om slijtage te voorkomen en snelheid te garanderen.

A. De opslaglocaties

1. JSON-bestanden (.storage/): De opgebouwde profielen worden opgeslagen in de verborgen map /config/.storage/ van Home Assistant. Schrijfacties worden gegroepeerd en vertraagd (debounced, met een ~5 minuten throttle) om slijtage aan SSD's of SD-kaarten te voorkomen, en geforceerd weggeschreven (flush) bij een herstart.
2. Home Assistant Database (Recorder): Hierin staan de ruwe sensordata. Bij een herstart vult het systeem via Recorder queries eventueel ontbrekende profieldagen (tot 28 dagen) met terugwerkende kracht aan.
3. Werkgeheugen (RAM): In het actieve Python-proces van de integratie wordt het model vastgehouden voor bliksemsnelle, real-time berekeningen.

B. Hoe wordt het historische profiel bewaard?

• Voor elke dag uit het 28-daagse venster ligt er een opgeslagen JSON-array met exact 96 intervallen (per 15 minuten).
• Elk interval bevat de netto-vraag (gecorrigeerd voor uitgesloten apparaten en de batterij).
• De opslag is tijdsbewust (DST-aware), waardoor dagen met 23 of 25 uur bij zomer-/wintertijd netjes kloppen.

C. Hoe wordt de HUIDIGE dag vastgelegd? (Live-tracking & Afsluiting)

• Live Accumulator: In het geheugen draait continu een teller (accumulator) die de exacte kWh-stand van het verbruik en de opwek van vandaag tot nu toe bijhoudt. Deze wordt elke ~5 minuten als back-up naar de .storage geschreven.
• Intraday combinatie: Voor de voorspelling van vandaag combineert het systeem de werkelijk gemeten kwartieren (uit de accumulator) met de nog verwachte kwartieren (uit de historie).
• 23:55 Dagafsluiting (Capture): Om exact 23:55 uur (lokale tijd) wordt de actuele dag definitief bevroren. Het systeem valideert of er genoeg datadekking was, en voegt deze dag vervolgens toe aan de permanente 28-daagse historie in de .storage JSON-files. Om middernacht reset de live-teller zich naar 0.0 kWh voor de volgende dag.

[ Voor 13% gewijzigd door JBS op 19-10-2026 13:25 ]

[meesje]

Via het HA Zendure topic al regelmatig omnibattery voorbij zien komen. Tof dat er een apart topic voor is.

[xzaz]

Ik heb dit dus draaiend maar liep tegen een probleem aan dat bij mij de 0 op de meter niet werd aangehouden. Zie dit issue. Uiteindelijk via Claude een fix weten te genereren en sindsdien staat die goed te draaien.

Ik ben nog wel erg zoekende in de batterij SOC. Gister stond die bijvoorbeeld de hele dag zo rond mijn minumum en zoek eigenlijk een soort extra saftey system die het rond de 50% houdt. Dit is dan exclusief de absolute min SOC. Die staat bij mij ook best hoog op 23%.

Edit: Ah precies dus wat hierboven wordt besproken!

[ Voor 5% gewijzigd door xzaz op 19-10-2026 14:33 ]

[NiCNCo]

Gebruik het nu enkele dagen. Ziet er zeer belovend uit. Het heeft wel even tijd nodig om de standaard verbruikwaarden (fallbacks waarden) te overschrijven met actuele waarden van het huis. Fase protectie werk naar behoren.

Ik gerbruik hem met gekoppelt met drie stapeltjes Zendure 2400AC +/PRO ieder op een andere fasen, en een Peblar EV. Loadbalancing gaat goed, batterijen worden netjes geremd naar veilige waarden als EV of andere gebruikers de fasen te zwaar belasten.

De geautomatiseerde planningen is nog even bezien, hoe het werkt, en hoe die rekent is even wennen, er wordt wel netjes een samenvatting van het plan steeds in de notificatie van HA geplaats. Maar met de afgelopen dagen aan saaie, vlakke en vooral dure dynamische prijzen is het inslaan en verkopen nog niet echt in beeld geweest. En en vanaf volgend jaar niet eens relevant meer natuurlijk. Omnibattery gaat echt ver met zijn slimmigheden op optimaal te laden en ontladen, vroegtijdig inslaan van capaciteit en alles, het zorgen voor ruimte wanneer nodig

Ondanks erg compleet, en benieuwd naar de werking over tijd, mis ik momenteel een paar buttons op de main dashboard voor het sneller handmatig kunnen laden/onladen. Nu moet je eerst de manual overide aanzetten op de control pagina, en dan apart per batterij het gewenste power slide aanpassen. Beetje veel werk. Kan het met een automatie oplossen, maar dan moet ik de automatie vanuit een ander dashboard benaderen, dus zou fijn zijn als zulk dergelijke toggles op het maindashboard (optioneel) erbij geplaats zouden kunnen worden. Verder erg mooie intergratie en ga er komende tijd nog even lekker mee spelen er ervaringen opdoen.

[ Voor 27% gewijzigd door NiCNCo op 19-10-2026 14:38 ]

[meesje]

Zojuist Omnibattery binnen Home Assistant geïnstalleerd voor mijn drie Zendure SF800plus batterijen. Wellicht doe ik iets verkeerd maar omnibattery zorgde er voor dat mijn batterijen met 3x800w gingen ontladen, terwijl er geen vraag was in de woning. Ik kan het zo snel niet vinden. Ik maak geen gebruik van dynamische prijzen of predictive functionaliteit. Ik heb wel mijn solaredge omvormer gekoppeld.
Wat zie ik over het hoofd? Met google (Gemini) kom ik er niet uit. Om er voor te zorgen dat de batterijen snel leeg lopen heb ik handmatige modus maar even aangezet. Onder 'bediening' staat alles uit of op automatisch, behalve de PD-regelaar. Deze staat aan, maar heb ik niet bewust aangezet.
Hebben jullie nog advies. HA heb ik al opnieuw opgestart.

Toevoeging: Zojuist valt me op dat bij de batterijen de geforceerde modus op discharge stond. Deze maar op none gezet. Nu ik dit type springt deze weer naar discharge.

[ Voor 10% gewijzigd door meesje op 19-10-2026 15:44 ]

[xzaz]

Weet iemand wat Effiencientie / Levensduurrendement is? Deze daalt bij mij heel snel en staat op 87%.

[GoBieN-Be]

Is dat een statistiek bij de batterij zelf?

[xzaz]

GoBieN-Be schreef op maandag 19 oktober 2026 @ 16:03:
Is dat een statistiek bij de batterij zelf?

Ja, is onderdeel van de batterij zelf. Gaat om een solarflow 4000 mix pro.

[ Voor 9% gewijzigd door xzaz op 19-10-2026 16:29 ]

[meesje]

Zie mijn bericht hiervoor. Ik denk dat ik de oplossing heb. Bij configureren van omnibattery moet je de sensor ingeven voor je p1 meter. Ik maak gebruik van een HW P1 meter. De sensor heet 'sensor.p1_meter_vermogen'. Echter via google/gemini toch iets kunnen vinden. Omdat deze sensor een gecombineerde sensor is, moest ik de optie 'meterteken omgekeerd' uitzetten (deze staat standaard aan). Nu is 1 van de 3 batterijen een beetje aan het laden.

[JBS]

xzaz schreef op maandag 19 oktober 2026 @ 15:48:
Weet iemand wat Effiencientie / Levensduurrendement is? Deze daalt bij mij heel snel en staat op 87%.

Ik had m'n analyse van de codebase nog openstaan, dus ook die vraag nog even geteld:

Binnen de Omnibattery integratie verwijst Efficiëntie (of Levensduurrendement) naar de Round-Trip Efficiency (RTE). Dit is een sensor (zichtbaar op de device card) die het procentuele rendement van de batterij berekent, oftewel de verhouding tussen de energie die erin is gegaan en de energie die er weer uit is gekomen na conversieverliezen.

De berekening van dit levensduurrendement werkt als volgt in de codebase:

• Lange termijn (Levensduurbasis): Voor AC-only batterijen berekent het systeem de efficiëntie altijd op basis van de hardwaretellers voor de totale levensduur (lifetime charge and discharge counters) in plaats van dagelijkse data. Dit zorgt voor een consistente langetermijnmeting over verschillende batterijmodellen heen.
• Correctie voor directe zonnepanelen (Venus D/A modellen): Bij DC-gekoppelde systemen waar zonnepanelen direct op de batterij zijn aangesloten, kon de efficiëntiesensor onjuiste waardes (boven de 100%) aangeven omdat de AC-laadteller het directe DC-laden niet registreerde. Voor deze units berekent de sensor het werkelijke vermogen op de batterijcellen (true terminal power: battery_cell_power = battery_power + MPPT) en integreert en bewaart deze totalen over herstarts heen.
• Inclusief Backup/Off-grid gebruik: Stroom die via de backup-poort wordt ontladen, wordt in de gedeelde berekeningen meegenomen bij de totale ontlading, zodat de berekening van de Round-Trip Efficiency (RTE) kloppend blijft.

[meesje]

In HA zie ik dat mijn HW P1 meter elke 5 seconden een waarde toont. Kan ik hieruit concluderen of er ook daadwerkelijk elke 5 sec een waarde bekend is? Mijn slimme meter kan elke sec waarden uitlezen. Levert dit problemen op? Kan ik hieraan nog iets verbeteren? Omnibattery adviseert zelfde elke 1-2 sec uitlezen van waarden.

[ Voor 10% gewijzigd door meesje op 19-10-2026 16:40 ]

[xzaz]

meesje schreef op maandag 19 oktober 2026 @ 16:40:
In HA zie ik dat mijn HW P1 meter elke 5 seconden een waarde toont. Kan ik hieruit concluderen of er ook daadwerkelijk elke 5 sec een waarde bekend is? Mijn slimme meter kan elke sec waarden uitlezen. Levert dit problemen op? Kan ik hieraan nog iets verbeteren? Omnibattery adviseert zelfde elke 1-2 sec uitlezen van waarden.

In de specs staat dat ze gewoon elke seconde moeten kunnen leveren. Misschien HomeWizard even bellen? Zelf heb ik gewoon een kabel naar een RpI in de meterkast die het met ser2net doorstuurt naar de integratie in HA. Als ik die gegevens nog ergens nodig heb is het een kwestie van een tweede regel in het config bestand van ser2net.

[meesje]

xzaz schreef op maandag 19 oktober 2026 @ 17:03:
[...]

In de specs staat dat ze gewoon elke seconde moeten kunnen leveren. Misschien HomeWizard even bellen? Zelf heb ik gewoon een kabel naar een RpI in de meterkast die het met ser2net doorstuurt naar de integratie in HA. Als ik die gegevens nog ergens nodig heb is het een kwestie van een tweede regel in het config bestand van ser2net.

HW en bellen is geen goede combi.
Ik heb net een google/gemini opdracht gedaan en via die weg bevestigd gekregen dat:
De officiële HomeWizard integratie op Home Assistant peilt (pollt) de lokale API standaard elke 5 seconden. Dit is bewust zo geprogrammeerd om de wifi-chip van de HomeWizard P1 meter stabiel te houden en netwerkverkeer te beperken, hoewel de meter intern inderdaad elke seconde data ontvangt.
En daarna twee oplossing geboden gekregen:
1. Via HACS HomeWizard Instant installeren
2. De update-frequentie forceren met een automatisering

Later er maar eens verder in verdiepen. Wat ik begrepen heb is dat de Gielz Zendure integratie al standaard de P1 meter elke sec uitleest.

[Taro]

MikeyMan schreef op maandag 19 oktober 2026 @ 11:13:
Interessant. Heb nu zelf een HA aansturing voor m'n laadpaal (Zaptec Go 2) in elkaar gevibe-code. De Zendures 'volgen' in principe vanzelf nu met de HA integratie. Maar dit is wellicht een wat nettere oplossing.

Dit vervangt dan de zensdk integratie? Of werkt dit naast elkaar?

Je moet andere aansturingen zoals HEMS, Zendure HA of Gielz-integratie uitzetten. Directe ZenSDK commando's moet je ook niet meer gebruiken aangezien OB en de andere kapitein elkaar dan gaan tegenwerken.

Ik was ook gewend om met +-10 toggles alles zelf te kunnen beïnvloeden, ik moet dit nog even leren loslaten, maar heb er vertrouwen in dat icm 1-2 weekjes inleren ik hopelijk wat achterover kan gaan leunen en niet meer iedere dag keuzes hoeft te maken

[Taro]

CappieL schreef op maandag 19 oktober 2026 @ 12:16:
@Taro heb mijn Zendure Solarflow 2400AC (zonder + of Pro) in Omnibattery zitten en die doet het ook.
Kwam er later achter dat zowel Gielz als Omnibattery als kapitein wilden dienen, dus heb voor nu Gielz op 'Standby' gezet en laat ik OB nu het regelwerk doen.
Als ik weer terug wil naar Gielz, weet jij welke instelling ik dan moet hebben in OB om nog wel te kunnen monitoren? Moet ik OB dan op Handmatige modus zetten met 0W im- en export?

Dat durf ik niet te zeggen, mijn gevoel zegt: Deactiveer het tijdvak of laat het tijdvak aanstaan, maar vink daarbinnen laden en ontladen uit? Hopelijk heeft iemand anders het definitieve antwoord.

[AUijtdehaag]

Komt er ook nog ondersteuning voor een AECC battery, nu de modbus registers bekend zijn?

[NiCNCo]

meesje schreef op maandag 19 oktober 2026 @ 16:40:
In HA zie ik dat mijn HW P1 meter elke 5 seconden een waarde toont. Kan ik hieruit concluderen of er ook daadwerkelijk elke 5 sec een waarde bekend is? Mijn slimme meter kan elke sec waarden uitlezen. Levert dit problemen op? Kan ik hieraan nog iets verbeteren? Omnibattery adviseert zelfde elke 1-2 sec uitlezen van waarden.

Standaard geeft de HomeWizard intergratie elke 4 a 5 seconden nieuwe waarden af, ook als de slimmer meter zelf dit vaker doet. Wat je echter kan doen is zelf sensoren creeren die de P1 vaker pingen voor waarden. Dit werkt zeer gemakkelijk en zo draaid het bij mij ook.

Let op: dit moet je wel zelf knutselen in bijvoorbeeld de File Editer intergratie.

_{Plaats eerst deze regels in je /homeassistant/configuration.yaml}

homeassistant:
  packages: !include_dir_named packages

Maak vervolgens een nieuwe .yaml aan in de Packages folder.
Ik heb het "homewizard_p1_fast.yaml" genoemd, naam maar verder niet uit.

In de homewizard_p1_fast.yaml plaats je vervolgens onderstaande script, save de yaml, dan in de HA in de Tools tab "check configuartions" ff draaien, en als HA de "Configuration will not prevent Home Assistant from starting!", aanduid, dan is het veilig om Homeassistant een herstart te geven.

Na de herstart zullen er meerdere nieuwe P1 entitieten aangemaakt zijn (te zoeken met benaming "P1 FAST" ) die iedere 1 a 2 seconden verversen (afhankelijke van je netwerk) als het goed is.

Ik weet helaas niet goed hoe je code kan delen hier bij tweakers met correcte indentatie, dus ik hoop dat onderstaande werkt na een copy paste in je homewizard_p1_fast.yaml. Het script creeert nieuwe extra entitieiten voor de P1 waaronder de totale vermogen, totale current, voltage / current per fase. Deze zijn dan te gebruiken in Omnibattery voor snellere uitlezing van je P1 meter. Succes, hoop dat het je lukt zonder problemen, anders gewoon even een chatgpt of dergelijke vragen wat hier bedoelt wordt. Groet een mede-tweaker

homewizard_p1_fast.yaml scipt hieronder: (alles in het kader 1:1 copy/pasten en het ip adres invullen op de tweede regel tussen de slashes natuurlijk).

rest:
  - resource: "http://VUL HIER IP ADRES HOMEWIZARD P1 METER/api/v1/data"
    scan_interval: 1
    timeout: 5

    sensor:
      - name: "P1 Fast Current Phase 1"
        unique_id: p1_fast_current_phase_1
        unit_of_measurement: "A"
        device_class: current
        state_class: measurement
        value_template: "{{ value_json.active_current_l1_a | float }}"

      - name: "P1 Fast Current Phase 2"
        unique_id: p1_fast_current_phase_2
        unit_of_measurement: "A"
        device_class: current
        state_class: measurement
        value_template: "{{ value_json.active_current_l2_a | float }}"

      - name: "P1 Fast Current Phase 3"
        unique_id: p1_fast_current_phase_3
        unit_of_measurement: "A"
        device_class: current
        state_class: measurement
        value_template: "{{ value_json.active_current_l3_a | float }}"

      - name: "P1 Fast Voltage Phase 1"
        unique_id: p1_fast_voltage_phase_1
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement
        value_template: "{{ value_json.active_voltage_l1_v | float }}"

      - name: "P1 Fast Voltage Phase 2"
        unique_id: p1_fast_voltage_phase_2
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement
        value_template: "{{ value_json.active_voltage_l2_v | float }}"

      - name: "P1 Fast Voltage Phase 3"
        unique_id: p1_fast_voltage_phase_3
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement
        value_template: "{{ value_json.active_voltage_l3_v | float }}"

      - name: "P1 Fast Power Phase 1"
        unique_id: p1_fast_power_phase_1
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        value_template: "{{ value_json.active_power_l1_w | float }}"

      - name: "P1 Fast Power Phase 2"
        unique_id: p1_fast_power_phase_2
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        value_template: "{{ value_json.active_power_l2_w | float }}"

      - name: "P1 Fast Power Phase 3"
        unique_id: p1_fast_power_phase_3
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        value_template: "{{ value_json.active_power_l3_w | float }}"

      - name: "P1 Fast Power Total"
        unique_id: p1_fast_power_total
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        value_template: "{{ value_json.active_power_w | float }}"

      - name: "P1 Fast Current Total"
        unique_id: p1_fast_current_total
        unit_of_measurement: "A"
        device_class: current
        state_class: measurement
        value_template: "{{ value_json.active_current_a | float }}"

[ Voor 12% gewijzigd door NiCNCo op 19-10-2026 18:05 ]

[MikeyMan]

Taro schreef op maandag 19 oktober 2026 @ 17:23:
[...]

Je moet andere aansturingen zoals HEMS, Zendure HA of Gielz-integratie uitzetten. Directe ZenSDK commando's moet je ook niet meer gebruiken aangezien OB en de andere kapitein elkaar dan gaan tegenwerken.

Ik was ook gewend om met +-10 toggles alles zelf te kunnen beïnvloeden, ik moet dit nog even leren loslaten, maar heb er vertrouwen in dat icm 1-2 weekjes inleren ik hopelijk wat achterover kan gaan leunen en niet meer iedere dag keuzes hoeft te maken

Maar haal je er dan ook toegevoerde waarde uit? Ik bedoel, als het spul eenmaal draait, draait het.

[Taro]

MikeyMan schreef op maandag 19 oktober 2026 @ 17:50:
[...]
Maar haal je er dan ook toegevoerde waarde uit? Ik bedoel, als het spul eenmaal draait, draait het.

Mijn huidige automatiseringen en toggles zijn t/m 31-12-2026 vermoedelijk beter dan wat OB mij out of the box kan leveren. Maar nu de zon al minder zichtbaar is en de dynamische spread wat minder lijkt te worden zou ik vermoedelijk toch vaker/meer naar NOM overstappen dan handelen. En NOM met 3x Zendure en 2x Anker SOLIX gecombineerd is erg lastig. Dus nu alleen OB draaien, met NOM over die 5 accu's heen en dat werkt prachtig. Wel heb ik het idee dat die het dagverbruik nog te pessimistisch inschat en daardoor de accu's eerder leeg zijn dan verwacht, maar is hopelijk een kwestie van langer laten inleren.

Dus ja, heb er nu al voordeel / toegevoegde waarde van door de NOM over 5 verschillende type accu's van 2 verschillende merken heen. Als die dan ook nog bij voldoende dynamische spread daadwerkelijk extra gaat inkopen en duur verkopen, dan ben ik helemaal happy.

Ik zie trouwens wel dat beide Anker's voorkeur krijgen boven de Zendure's, vermoedelijk aangezien efficiëntie daar op 100% staat, maar dat lijkt mij niet heel realistisch

[B-Force]

Taro schreef op zondag 18 oktober 2026 @ 23:58:
Zo zien overigens de komende uren er uit:
[Afbeelding]

Wat de integratie nog niet ziet en meeneemt is dat om 2:00 het laden van 1 van de 2 EV's is gepland. Vannacht ging dat goed aangezien Omnibattery en de EV Lader tegelijk stonden gepland en dus werkten ze elkaar niet tegen. Een mooie toevoeging zou zijn als het EV Laden ook in de integratie zou kunnen worden meegenomen

Hoe laat je die grafiek zien? 😍


Verder ben ik sinds een maand ook over op Omnibattery. Na een week of 2 begon hij ook goed te regelen en was mijn huis verbruik op orde.

Nu loop ik tegen 2 punten nog aan, kan niet echt vinden hoe dat nu precies werkt:
- ik heb de ev lader uitgesloten, maar deze zit wel nog in mijn geschatte huisverbruik. Hoe krijg ik die er uit?
- ik heb het gevoel dat de RTE niet meegerekend wordt om te gaan laden. Nu laadt hij 's nachts bijvoorbeeld voor 32 cent, om de morgen af te dekken waar het tarief tussen de 35 en 38 cent ligt. Met een RTE van 85% is dat niet per se wat ik zou willen...

[ Voor 30% gewijzigd door B-Force op 19-10-2026 18:35 ]

[meesje]

Niet om te bashen, maar het valt me op dat de HomeWizard batterij niet officieel ondersteund wordt. Volgens mij zijn er genoeg Tweakers die deze batterij met een ander merken of merken combineren.

[bigkevx2]

Ik heb nu nog niet alles gelezen maar door de eye candy al rete enthousiast!

Met 3 Zendure en de eigen ontwikkelingen die ik nu aan het maken ben lijkt dit veel van mijn uitdagingen al op te lossen.

Eerste knuppel die ik gooi: OB of Gielz met gast777? En vooral, waarom?

En ja, als ik straks tijd heb ga ik alles lezen, beloofd. Maar ben heel benieuwd

[meesje]

Ervaren jullie ook dat drie grafieken niet juist werken als de batterij(en) in stand-by staan? Bij mij is de SoC nu 10%, maar eerder vandaag, bij hogere SoC (maar wel in stand-by) merkte ik dit al eerder op.
Energie en Vermogen zijn nu helemaal blanco, en de SOC toont voor de gehele dag de huidige stand.

[Goichi]

AUijtdehaag schreef op maandag 19 oktober 2026 @ 17:26:
Komt er ook nog ondersteuning voor een AECC battery, nu de modbus registers bekend zijn?

Je kan vragen deze batterij te te voegen:

OmniBattery Discussions

[meesje]

bigkevx2 schreef op maandag 19 oktober 2026 @ 18:52:
Ik heb nu nog niet alles gelezen maar door de eye candy al rete enthousiast!

Met 3 Zendure en de eigen ontwikkelingen die ik nu aan het maken ben lijkt dit veel van mijn uitdagingen al op te lossen.

Eerste knuppel die ik gooi: OB of Gielz met gast777? En vooral, waarom?

En ja, als ik straks tijd heb ga ik alles lezen, beloofd. Maar ben heel benieuwd

Lees ook het artikel op iotdomotica.nl (zie een eerdere post in dit topic).
Zelf ben ik vandaag voor OB gegaan. Het ziet er super mooi uit, ik hoef niet met NodeRed aan de slag, en je kunt OB gewoon via HACS updaten. Ik weet het, allemaal kleine argumenten. Ik had had Gielz+gast777 draaiend en er veel mee gespeeld, ook andere zaken toegevoegd aan HA. Op een later moment besloten om HA alleen in te zetten voor energie zaken. Zodoende een nieuwe installatie gedaan van HA.

[meesje]

meesje schreef op maandag 19 oktober 2026 @ 19:16:
Ervaren jullie ook dat drie grafieken niet juist werken als de batterij(en) in stand-by staan? Bij mij is de SoC nu 10%, maar eerder vandaag, bij hogere SoC (maar wel in stand-by) merkte ik dit al eerder op.
Energie en Vermogen zijn nu helemaal blanco, en de SOC toont voor de gehele dag de huidige stand.

[Afbeelding]

Misschien niet helemaal gerelateerd aan stand-by. Want nu zijn deze grafieken wel gevuld met data. Ik zal het komende tijd in de gaten houden.

[meesje]

NiCNCo schreef op maandag 19 oktober 2026 @ 17:43:
[...]

Standaard geeft de HomeWizard intergratie elke 4 a 5 seconden nieuwe waarden af, ook als de slimmer meter zelf dit vaker doet. Wat je echter kan doen is zelf sensoren creeren die de P1 vaker pingen voor waarden. Dit werkt zeer gemakkelijk en zo draaid het bij mij ook.

Let op: dit moet je wel zelf knutselen in bijvoorbeeld de File Editer intergratie.

_{Plaats eerst deze regels in je /homeassistant/configuration.yaml}

homeassistant:
  packages: !include_dir_named packages

Maak vervolgens een nieuwe .yaml aan in de Packages folder.
Ik heb het "homewizard_p1_fast.yaml" genoemd, naam maar verder niet uit.

In de homewizard_p1_fast.yaml plaats je vervolgens onderstaande script, save de yaml, dan in de HA in de Tools tab "check configuartions" ff draaien, en als HA de "Configuration will not prevent Home Assistant from starting!", aanduid, dan is het veilig om Homeassistant een herstart te geven.

Na de herstart zullen er meerdere nieuwe P1 entitieten aangemaakt zijn (te zoeken met benaming "P1 FAST" ) die iedere 1 a 2 seconden verversen (afhankelijke van je netwerk) als het goed is.

Ik weet helaas niet goed hoe je code kan delen hier bij tweakers met correcte indentatie, dus ik hoop dat onderstaande werkt na een copy paste in je homewizard_p1_fast.yaml. Het script creeert nieuwe extra entitieiten voor de P1 waaronder de totale vermogen, totale current, voltage / current per fase. Deze zijn dan te gebruiken in Omnibattery voor snellere uitlezing van je P1 meter. Succes, hoop dat het je lukt zonder problemen, anders gewoon even een chatgpt of dergelijke vragen wat hier bedoelt wordt. Groet een mede-tweaker

homewizard_p1_fast.yaml scipt hieronder: (alles in het kader 1:1 copy/pasten en het ip adres invullen op de tweede regel tussen de slashes natuurlijk).

rest:
  - resource: "http://VUL HIER IP ADRES HOMEWIZARD P1 METER/api/v1/data"
    scan_interval: 1
    timeout: 5

    sensor:
      - name: "P1 Fast Current Phase 1"
        unique_id: p1_fast_current_phase_1
        unit_of_measurement: "A"
        device_class: current
        state_class: measurement
        value_template: "{{ value_json.active_current_l1_a | float }}"

      - name: "P1 Fast Current Phase 2"
        unique_id: p1_fast_current_phase_2
        unit_of_measurement: "A"
        device_class: current
        state_class: measurement
        value_template: "{{ value_json.active_current_l2_a | float }}"

      - name: "P1 Fast Current Phase 3"
        unique_id: p1_fast_current_phase_3
        unit_of_measurement: "A"
        device_class: current
        state_class: measurement
        value_template: "{{ value_json.active_current_l3_a | float }}"

      - name: "P1 Fast Voltage Phase 1"
        unique_id: p1_fast_voltage_phase_1
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement
        value_template: "{{ value_json.active_voltage_l1_v | float }}"

      - name: "P1 Fast Voltage Phase 2"
        unique_id: p1_fast_voltage_phase_2
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement
        value_template: "{{ value_json.active_voltage_l2_v | float }}"

      - name: "P1 Fast Voltage Phase 3"
        unique_id: p1_fast_voltage_phase_3
        unit_of_measurement: "V"
        device_class: voltage
        state_class: measurement
        value_template: "{{ value_json.active_voltage_l3_v | float }}"

      - name: "P1 Fast Power Phase 1"
        unique_id: p1_fast_power_phase_1
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        value_template: "{{ value_json.active_power_l1_w | float }}"

      - name: "P1 Fast Power Phase 2"
        unique_id: p1_fast_power_phase_2
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        value_template: "{{ value_json.active_power_l2_w | float }}"

      - name: "P1 Fast Power Phase 3"
        unique_id: p1_fast_power_phase_3
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        value_template: "{{ value_json.active_power_l3_w | float }}"

      - name: "P1 Fast Power Total"
        unique_id: p1_fast_power_total
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        value_template: "{{ value_json.active_power_w | float }}"

      - name: "P1 Fast Current Total"
        unique_id: p1_fast_current_total
        unit_of_measurement: "A"
        device_class: current
        state_class: measurement
        value_template: "{{ value_json.active_current_a | float }}"

Bedankt. Zie ook mijn eerdere bericht. Google/gemini kwam al met twee suggesties:
1. Via HACS HomeWizard Instant installeren
2. De update-frequentie forceren met een automatisering

Allebei nog niet verder naar gekeken. Voor het tweede kreeg ik onderstaande yaml code.

[JoTil]

B-Force schreef op maandag 19 oktober 2026 @ 18:29:
[...]


Hoe laat je die grafiek zien? 😍


Verder ben ik sinds een maand ook over op Omnibattery. Na een week of 2 begon hij ook goed te regelen en was mijn huis verbruik op orde.

Nu loop ik tegen 2 punten nog aan, kan niet echt vinden hoe dat nu precies werkt:
- ik heb de ev lader uitgesloten, maar deze zit wel nog in mijn geschatte huisverbruik. Hoe krijg ik die er uit?
- ik heb het gevoel dat de RTE niet meegerekend wordt om te gaan laden. Nu laadt hij 's nachts bijvoorbeeld voor 32 cent, om de morgen af te dekken waar het tarief tussen de 35 en 38 cent ligt. Met een RTE van 85% is dat niet per se wat ik zou willen...

Volgens mij was dat RTE probleempje opgelost nadat ik de arbitrage margin van 0 af heb gehaald.

[B-Force]

JoTil schreef op maandag 19 oktober 2026 @ 19:51:
[...]

Volgens mij was dat RTE probleempje opgelost nadat ik de arbitrage margin van 0 af heb gehaald.

Welke instelling heb je aangepast dan precies? En naar welke waarde?

Ik blijf het hele tarief opbouw stuk lastig vinden, kan je nagaan wat er gebeurt als salderen er af gaat..

[JBS]

B-Force schreef op maandag 19 oktober 2026 @ 20:19:
[...]


Welke instelling heb je aangepast dan precies? En naar welke waarde?

Ik blijf het hele tarief opbouw stuk lastig vinden, kan je nagaan wat er gebeurt als salderen er af gaat..

Nu wil ik geen AI output copy/past'er worden, maar ook deze vraag kan op basis van de codebase heel mooi beantwoord worden:

Wat doet de Arbitragemarge (Arbitrage margin)?

De arbitragemarge (Minimum arbitrage margin) beschermt je tegen onvoordelige laad- en ontlaadcycli bij dynamische energiecontracten.

Wanneer je batterij laadstroom inkoopt en later weer gebruikt of teruglevert, treedt er altijd energieverlies op (het rendement of de round-trip efficiency, vaak rond de 80–90%). De arbitragemarge zorgt ervoor dat het prijsverschil (de spread) tussen het goedkoopste uur en het duurste uur groot genoeg is om:

1. De conversieverliezen te dekken (het verlies van laden en ontladen).
2. Jou de ingestelde winstmarge per kWh op te leveren.

• Bij laden vanaf het net: Er wordt alleen een laadslot ingepland als de verwachte ontlaadprijs op een later moment voldoende hoger is dan de inkoopprijs + verliezen + jouw marge.
• Bij terugleveren/verkopen (High Price Sale): Er wordt alleen energie geëxporteerd als de actuele verkoopprijs hoog genoeg is ten opzichte van de inkoopprijs.

Instelling op 0 zet deze controle uit.

Waar stel je dit in?

Je kunt de arbitragemarge op twee manieren instellen:

Methode 1: Via het Omnibattery Dashboard (Snelst)

1. Open in de linkerbalk van Home Assistant het Omnibattery paneel.
2. Ga bovenin naar het tabblad Bediening (Control).
3. Zoek het blok Voorspellend laden (Predictive Charging) of Dynamische prijzen.
4. Pas de schuifbalk of het veld Minimale arbitragemarge aan (in €/kWh, bijvoorbeeld 0.02 voor 2 cent winstmarge per kWh).

Methode 2: Via de Integratie-instellingen van Home Assistant

1. Ga naar Instellingen → Apparaten & Diensten.
2. Zoek de Omnibattery integratie en klik op Opties (Options).
3. Selecteer het onderdeel Voorspellend laden (Predictive charging) of Dynamische prijzen (Dynamic Pricing).
4. Vul de gewenste waarde in bij Minimum arbitrage margin (in €/kWh) en sla op.

[JoTil]

B-Force schreef op maandag 19 oktober 2026 @ 20:19:
[...]


Welke instelling heb je aangepast dan precies? En naar welke waarde?

Ik blijf het hele tarief opbouw stuk lastig vinden, kan je nagaan wat er gebeurt als salderen er af gaat..

In de integratie ( dus niet via het dashboard) kan je de minimal arbitrage margin aanpassen. Hierna verschijnt deze wel in het dashboard. Dit is de marge die je minimaal wil maken, naast rekening te houden met de RTE

Die tariefopbouw heb ik ook last van en heb het nog niet helemaal scherp. Bij mij werkt bv het solar surplus ontladen nog niet lekker. Die staat ook open op GIT

[ Voor 18% gewijzigd door JoTil op 19-10-2026 20:33 ]

[B-Force]

Thx @JBS en @JoTil . Idd pas na het aanpassen in de integratie komt deze instelling in het dashboard naar voren. Dat lijkt me een schoonheidsfoutje.

(En ik ben nog oldskool: stel liever een vraag op het forum met de verwachting en hoop dat ook anderen hier iets mee kunnen, dan AI gebruiken 😉)

[Taro]

B-Force schreef op maandag 19 oktober 2026 @ 18:29:
[...]
Hoe laat je die grafiek zien? 😍

Ik kan natuurlijk een hele mooie uitleg verzinnen, maar die stond volgens mij direct vanaf het begin al aan.

Kan dat te maken hebben met een vinkje ivm voorspellend laden ofzo?

[meesje]

Taro schreef op maandag 19 oktober 2026 @ 21:20:
[...]

Ik kan natuurlijk een hele mooie uitleg verzinnen, maar die stond volgens mij direct vanaf het begin al aan.

Kan dat te maken hebben met een vinkje ivm voorspellend laden ofzo?

De ‘dagelijkse werking’ grafiek heb ik ook. Ik heb zowel voorspellingen als dynamische prijzen niet aan staan. Deze grafiek lijkt me standaard aanwezig. Ik maak gebruik van v1.5.0 van Omnibattery.

[ Voor 10% gewijzigd door meesje op 19-10-2026 21:24 ]

[Mai Pensato]

Super dat er nu een topic voor Omnibattery is! Toevallig heb ik het gisteren geinstalleerd.

Mijn situatie:

• Ik werk al enkele jaren met Home Assistant
• Zonnepanelen 12.800 wp met een SolarEdge 12,5k 3 fase omvormer nu 3,5 jaar Die zit in HA met de TCP Modbus integratie
• Sinds eind september 3 Zendure SolarFlow 3000 Mix batterijen, allemaal op een eigen groep en per fase 1 batterij. Dus totale capaciteit 24 kwH en vermogen 9 kW
• Per 1 october een dynamisch contract bij Tibber (met dus kwartierprijzen)

Ik wilde eigenlijk voor de route Gielz1986+Gast777 proxy gaan, maar hikte een beetje tegen de complexiteit/leercurve aan (ik heb bijvoorbeeld geen enkele ervaring met NodeRed).

Toen ik las over Ombibattery ben ik me daar in gaan verdiepen. Wat me vooral aanspreekt is dat 1 oplossing is voor meerdere batterijen met bovendien Tibber als standaard integratie en ook Solcast.

Ik heb er nu dus 1 dag mee gewerkt. De afgelopen weken heb ik de batterijen in aangepaste modus gehad in HEMS en heb ik per dag periodes ingesteld met laden/ontladen etc. afhankelijk van Tibber prijzen en de verwachte zonnestraling.

Wat ik tot nu toe zie is dat OB heel erg goed "nul op de meter" nastreeft. Sinds gisteravond heeft hij nauwelijks stroom van het net afgehaald en alleen vanmorgen een beetje zonnestroom aan het net geleverd.

Wat ik wil is zeker tot 1 januari ook dynamisch handelen. Dat heeft me de afgelopen weken met de handmatige modus al een leuk resultaat opgeleverd. OB heeft daar nog niks mee gedaan. De batterijcapaciteit van mijn set blijft ook laag (gisteravond met ruim 60% begonnen, nu staat hij op 18% en in het plan (de grafiek dagelijkse werking) zie ik dat hij vannacht gedurende 6 goedkope kwartieren gaat opladen tot net boven de 50%

Wat ik dus wil is dat hij vanmiddag al extra goedkope stroom uit het net geladen zou hebben en dit vanavond voor hoge prijze verkocht zou hebben

Ik ben er nog niet achter hoe ik dit in OB moet instellen. Ik heb "voorspellend laden" ingeschakeld. De optie "dynamic pricing" zie ik niet..

Ook heb ik nog niet gevonden waar ik de "minimum arbitrage margin" kan instellen, ondanks de duidelijke uitleg van @JBS enkele posts geleden.

Het lijkt wel of ik een andere versie van OB heb : 1.5.0 ? mijn HA staat overigens op Nederlands.

Wie kan me hiermee verder helpen ??

[Mai Pensato]

Waar stel je dit in?

Je kunt de arbitragemarge op twee manieren instellen:

Methode 1: Via het Omnibattery Dashboard (Snelst)

1. Open in de linkerbalk van Home Assistant het Omnibattery paneel.
2. Ga bovenin naar het tabblad Bediening (Control).
3. Zoek het blok Voorspellend laden (Predictive Charging) of Dynamische prijzen.
4. Pas de schuifbalk of het veld Minimale arbitragemarge aan (in €/kWh, bijvoorbeeld 0.02 voor 2 cent winstmarge per kWh).

Methode 2: Via de Integratie-instellingen van Home Assistant

1. Ga naar Instellingen → Apparaten & Diensten.
2. Zoek de Omnibattery integratie en klik op Opties (Options).
3. Selecteer het onderdeel Voorspellend laden (Predictive charging) of Dynamische prijzen (Dynamic Pricing).
4. Vul de gewenste waarde in bij Minimum arbitrage margin (in €/kWh) en sla op.

Ik probeer dit ook in te stellen. Methode 1: als ik bij Bediening "VOORSPELLEND LADEN" aanvink (ik zie nergens Dynamische prijzen??) dan zie ik geen veld met minimale arbitragemarge. Wel zie ik een optie "prijsrem zonne-overschot" waar ik een bedrag per kWh kan instellen als " min. besparing voor prijsrem" ?? Ook zie ik een optie "slim voorontladen" waar ik ook een bedrage per kWh kan instellen als "drempel negatieve injectie"

[meesje]

Mai Pensato schreef op maandag 19 oktober 2026 @ 21:51:
[...]

Ik probeer dit ook in te stellen. Methode 1: als ik bij Bediening "VOORSPELLEND LADEN" aanvink (ik zie nergens Dynamische prijzen??) dan zie ik geen veld met minimale arbitragemarge. Wel zie ik een optie "prijsrem zonne-overschot" waar ik een bedrag per kWh kan instellen als " min. besparing voor prijsrem" ?? Ook zie ik een optie "slim voorontladen" waar ik ook een bedrage per kWh kan instellen als "drempel negatieve injectie"

Je bent niet de enige. Ik zie de optie voor dynamische prijzen ook niet. Wel sensoren, batterijen, tijdvakken, uitgesloten apparaten en zonnevoorspellingen. Hopelijk kan iemand helpen. Of moet je de integratie helemaal opnieuw doen (verse install)?

[Mai Pensato]

@meesje Dynamic Pricing heb ik gevonden. Als je bij configureren kiest voor "Voorspellend Laden" kun je kiezen uit drie opties: Tijdslot - Dynamische Prijs - Realtime prijs.

Daar heb ik gekozen voor Dynamische Prijs (vanwege mijn Tibber contract).

Alleen wel een beetje verwarrend dat je dat in de Bediening tab dan niet terug ziet.

Waar ik de minimum margin kan vinden en instellen weet ik nog steeds niet. Zou kunnen dat het komt door een slechte vertaling van Engels naar Nederlands in HA.

[meesje]

Mai Pensato schreef op maandag 19 oktober 2026 @ 22:15:
@meesje Dynamic Pricing heb ik gevonden. Als je bij configureren kiest voor "Voorspellend Laden" kun je kiezen uit drie opties: Tijdslot - Dynamische Prijs - Realtime prijs.

Daar heb ik gekozen voor Dynamische Prijs (vanwege mijn Tibber contract).

Alleen wel een beetje verwarrend dat je dat in de Bediening tab dan niet terug ziet.

Waar ik de minimum margin kan vinden en instellen weet ik nog steeds niet. Zou kunnen dat het komt door een slechte vertaling van Engels naar Nederlands in HA.

Bedankt! Eerdaags wil ik overstappen van variabel naar dynamisch. Eens kijken of dat goed gaat.
Voorspellend laden kun je overigens wel via Bediening aanzetten. Er komt dan een optie herbereken. Verder heb ik niet geklikt.

[ Voor 8% gewijzigd door meesje op 19-10-2026 22:39 ]

[meesje]

Zelf zou ik overigens wel fijn vinden om terug te zien
- wat de capaciteit is van de batterij
- eventuele uitbreiding
Nu moet ik op wachten tot de batterijen helemaal vol zijn om vertrouwen te hebben in OB.

Wat me trouwens opvalt, is dat de getoonde temperatuur niet hetzelfde is als die in de Zendure app wordt getoond. Die in OB zijn wat hoger. B.v. 29 graden. En de batterij in de Zendure app 25 graden. Kan het zijn dat OB de temperatuur van de omvormer toont? En Zendure die van de batterijen?

[Taro]

Is het deze middelste optie? Of is dit geen optie maar een actie?

[ Voor 10% gewijzigd door Taro op 19-10-2026 23:09 ]

[JoTil]

Nee, het is deze:



Of te wel: number.omnibattery_min_arbitrage_margin

[Mai Pensato]

JoTil schreef op maandag 19 oktober 2026 @ 23:11:
Nee, het is deze:

[Afbeelding]

Of te wel: number.omnibattery_min_arbitrage_margin

Waar vind je deze!??

[Taro]

Mai Pensato schreef op maandag 19 oktober 2026 @ 23:15:
[...]

Waar vind je deze!??

Ah, die heb ik ook, naar Apparaten en Diensten gaan, dan Omnibattery -> Omnibattery System kiezen en dan in de onderste lijst.

Daarna krijg ik ook de onderste melding te zien:

[ Voor 31% gewijzigd door Taro op 19-10-2026 23:22 ]

[xzaz]

Blijkt wel dat het allemaal nog wat duidelijker kan. Ook de documentatie laat nog wel te wensen over. Maar goed dat er nu een topic voor is. Desalniettemin een goede start.

[Mai Pensato]

Ah nu vind ik deze ook. Vreemd dat deze dan niet erbij staat in de knoppen bij Bediening.... Voor de zekerheid: De minimum marge die betekent wat je nog overhoud na aftrek van de kosten en efficientie-verliezen? Dus in de berekening wordt al meegenomen de kosten die de energieleverancier rekent (in mijn geval Tibber 0,018 per kWh) en de RTE (heb ik op 85% laten staan) ?

[Mai Pensato]

De batterijen zijn nu volgeladen. Ik zie in de verwachting nog niet dat hij morgenvroeg extra gaat ontladen als de stroomprijzen hoog zijn. Hij ontlaadt dan alleen het eigen verbruik. En de battetijen zitten nog erg vol als morgen de zon begint te schijnen. Solcast geeft asn 38 kwh voor morgen. Wat moet ik instellen zodat er morgenvroeg verkocht wordt asn het net?

Ik heb verkoop bij hoge prijs aanstaan op overschot+arbitrage

[ Voor 7% gewijzigd door Mai Pensato op 20-10-2026 00:44 ]

[Mai Pensato]

De batterijen ontladen nu alleen voor het eigen verbruik. Ik zou willen dat ze ook stroom verkopen tijdens de ochtendpiek maar dat gebeurt niet.en staat ook niet in de verwachting. Terwijl Solcast aangeeft dat er vandaag veel zon komt en de stroomprijzen vanmiddag ook relatief laag zijn. Ergens heb ik iets niet goed staan in de instellingen maar ik weet niet wat...

Ik heb dus Verkoop bij hoge prijs aanstaan op "overschot+arbitrage" En ik heb de minimum-arbitragemarge laag staan op EUR 0,01/kwh. Retourrendement staat op 0.85

Ik heb dan nu maar mijn autolader (plug in hybride) na alvast aangezet zodat de batterijen toch een stuk leger worden....

Wie kan me verder helpen?

[B-Force]

Taro schreef op maandag 19 oktober 2026 @ 21:20:
[...]

Ik kan natuurlijk een hele mooie uitleg verzinnen, maar die stond volgens mij direct vanaf het begin al aan.

Kan dat te maken hebben met een vinkje ivm voorspellend laden ofzo?

Dat is hem idd vlgs mij. Zie hem nu ook 👍🏻

[ph2m]

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

[SmartHomeJunkie]

Ik zie in de manual nog geen Ecoflow batterijen staan. Is er iemand die deze toevallig wel al geprobeerd heeft?

Op Github zie ik er ook nog geen aanvraag voor. Ik zou die zelf kunnen toevoegen, maar vroeg me af of iemand er al mee aan het experimenteren was geweest.

[meesje]

Ik zie in het dashboard onderstaande melding. Hebben jullie dit ook? Ik heb geen predictive functie aan staan.

[CappieL]

meesje schreef op dinsdag 20 oktober 2026 @ 12:27:
Ik zie in het dashboard onderstaande melding. Hebben jullie dit ook? Ik heb geen predictive functie aan staan.

[Afbeelding]

Die melding heb ik ook.
OB maakt gewoon een prognose voor de rest van de dag.
Daar probeert hij dan o.b.v. van je stroomverbruik, resterende PV-opbrengst en huidige SOC de SOC en laadstrategie (mocht je die hebben) weer te geven.

[brommetje]

Vraagje kan ik ook Omnibattery naast Gielz installeren alleen met de monitor functie?

[CappieL]

brommetje schreef op dinsdag 20 oktober 2026 @ 14:06:
Vraagje kan ik ook Omnibattery naast Gielz installeren alleen met de monitor functie?

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.

[xzaz]

Ik heb de situatie dat bij 100% de mppt trackers worden uitgezet? Dat lijkt mij zonde de rest van de opbrengst moet toch gewoon door worden gegeven?

Edit: Dit is dus een instelling in de app van Zendure: "Overtollige energie exporteren".

[ Voor 43% gewijzigd door xzaz op 20-10-2026 15:11 ]

[CappieL]

xzaz schreef op dinsdag 20 oktober 2026 @ 15:03:
Ik heb de situatie dat bij 100% de mppt trackers worden uitgezet? Dat lijkt mij zonde de rest van de opbrengst moet toch gewoon door worden gegeven?

Edit: Dit is dus een instelling in de app van Zendure: "Overtollige energie exporteren".

Ik weet niet of je die functie ook in Omnibattery kunt aanpassen, zal afhangen van de ondersteuning van jouw specifieke batterij in OB.
Kun je die instelling ook via de REST-api wijzigen? Indien dat kan, zou het wellicht ondersteund kunnen worden in OB.

[xzaz]

CappieL schreef op dinsdag 20 oktober 2026 @ 15:16:
[...]


Ik weet niet of je die functie ook in Omnibattery kunt aanpassen, zal afhangen van de ondersteuning van jouw specifieke batterij in OB.
Kun je die instelling ook via de REST-api wijzigen? Indien dat kan, zou het wellicht ondersteund kunnen worden in OB.

Claude geeft:

Ja, waarschijnlijk wel. gridReverse staat in de Zendure-HA-wiki als schrijfbare eigenschap (Read/Write), met een int-waarde:

- 0: uit
- 1: terugleveren toegestaan
- 2: terugleveren verboden

Dat de eigenschap schrijfbaar is, staat in die wiki. De wiki zegt niet hoe je hem schrijft: er staat geen endpoint, MQTT-topic of voorbeeld-payload. Ook voor jouw model (4000 Mix Pro) heb ik dit niet bevestigd, want de wiki gaat over de SolarFlow 800.

Hoe je het waarschijnlijk aanroept
Bij de lokale zenSDK-API gebruikten de eerder gevonden bronnen een POST naar /properties/write. Dat is hetzelfde endpoint als bij z1986 #275(https://github.com/Gielz1986/Zendure-HA-zenSDK/issues/275). De payload zou dan zo kunnen zijn, maar dit is een voorbeeld en niet

POST http://<ip-van-toestel>/properties/write
{"sn": "<serienummer>", "properties": {"gridReverse": 1}}

[Michael755]

Kleine tip. De Marstek Venus C en Marstek Venus E V1.0 werken ook met een Elfin ew11.

Ik loop alleen tegen het probleem aan dat de min. Suc niet bewaakt kan worden. Ik heb nu een automation in HA gezet om dit te bewaken. Hoop dat dit met een update verholpen kan worden. Vanmorgen waren er 2 batterijen maar 10% (dit is te laag voor een Marstek)

[ Voor 6% gewijzigd door Michael755 op 20-10-2026 16:20 ]

[AUijtdehaag]

Goichi schreef op maandag 19 oktober 2026 @ 19:18:
[...]

Je kan vragen deze batterij te te voegen:

OmniBattery Discussions

Done

[Gyrolion]

Hier ook maar eens de omnibatterij geïnstalleerd op de home assistant instantie.

Voor alsnog ziet het er uit alsof dit wel is wat ik zocht! Ik was iederen dag aan het pielen met de verschillende prijzen om de Gielz automation fatsoenlijk draaiende te houden, dus als deze dat straks allemaal automatisch voor mij gaat doen.. geweldig! Hands off en niet meer over nadenken.

[JBS]

Gyrolion schreef op woensdag 21 oktober 2026 @ 10:30:
Hier ook maar eens de omnibatterij geïnstalleerd op de home assistant instantie.

Voor alsnog ziet het er uit alsof dit wel is wat ik zocht! Ik was iederen dag aan het pielen met de verschillende prijzen om de Gielz automation fatsoenlijk draaiende te houden, dus als deze dat straks allemaal automatisch voor mij gaat doen.. geweldig! Hands off en niet meer over nadenken.

Dat is zeker één van de belangrijkste features:

Predictive Grid Charging: Automatically charges from the grid when solar forecast + battery won't cover tomorrow's consumption. Supports fixed time slots, dynamic pricing, and real-time pricing modes. An optional grid-charge margin (%) tops up the grid amount to hedge optimistic solar forecasts.

Loslaten is uiteindelijk hopelijk dan weer één van mijn belangrijkste features
De tijdlijn in het Omnibattery dashboard geeft al veel inzichten, maar ik merk dat ik het ook prettig vindt per kwartier/uur te kunnen zien wat de batterij gedaan heeft of gepland is te gaan doen. In de entiteit sensor.omnibattery_daily_operation_timeline zit ontzettend veel nuttige data waarmee je iets als onderstaande kunt maken. Credits naar o.a. @lubbertkramer, hoewel dit concept al langer rondzwerft

(heb m'n batterij overigens gelimiteerd op 100W, dus negeer de schamele kWh's die de batterij in of uit gaan).

[Mai Pensato]

@JBS dat is een heel mooi overzicht, Hoe heb je dit overzicht gemaakt op basis van die sensor? Ik heb die sensor wel gevonden (heet bij mij "Dagelijkse bedrijfstijdlijn") maar ik zie daar bijv niets over accu, zon->accu, verbruik en prijs ??

[bigkevx2]

Zo! Ik ben ook om.

Wat een mooie integratie en met nog meer opties dan wat ik al dacht na alles gelezen te hebben. Ook al een voor mij eerste feature request ingediend om de prachtige animatie uit te breiden met een EV plugged in state. Nu zie je de EV alleen tot leven komen als hij stroom trekt. Totaal niet relevant voor de werking maar hey, het ook wil ook wat.

Nu uitgebreid testen en daarna misschien wel afscheid nemen van gielz

[meesje]

Ik merk dat als bij ons de kookplaat aangaat de PD-status wijzigt naar oscillerend. Volgens mij is is dit redelijk normaal, toch? Ik kan nog wel een aanpassing doen zodat de HW P1 meter elke sec. wordt uitgelezen ipv elke 5 sec.

[ Voor 27% gewijzigd door meesje op 21-10-2026 18:40 ]

[bigkevx2]

meesje schreef op woensdag 21 oktober 2026 @ 18:39:
Ik merk dat als bij ons de kookplaat aangaat de PD-status wijzigt naar oscillerend. Volgens mij is is dit redelijk normaal, toch? Ik kan nog wel een aanpassing doen zodat de HW P1 meter elke sec. wordt uitgelezen ipv elke 5 sec.

Dit zou ik ook doen. HW instant via HACS, works like a charm.

[meesje]

bigkevx2 schreef op woensdag 21 oktober 2026 @ 18:45:
[...]

Dit zou ik ook doen. HW instant via HACS, works like a charm.

Daar heb ik mijn oog op laten vallen. Kan mooi parallel lopen met de HW integratie. Die sensoren hou ik gekoppeld in het standaard HA energie dashboard. En de nieuwe sensor koppel ik aan Omnibattery.

[meesje]

Hoe moet ik de waarde bij Efficiëntie lezen? Is dit de RTE? Bij twee van de drie batterijen geeft deze de waarde 100%, terwijl de berekening ontladen/geladen bij beide een resultaat van iets meer dan 85% op. Dit volgens mij voor mijn Zendure SF800plus-sen een prima RTE, toch?
De derde batterij met een extra ab2000x is nog bezig met ontladen (de andere twee staan op 10% SoC en zijn stand-by). Ik ben benieuwd welke cijfers deze oplevert wanneer SoC op 10%.

[Mai Pensato]

meesje schreef op woensdag 21 oktober 2026 @ 20:11:
Hoe moet ik de waarde bij Efficiëntie lezen? Is dit de RTE? Bij twee van de drie batterijen geeft deze de waarde 100%, terwijl de berekening ontladen/geladen bij beide een resultaat van iets meer dan 85% op. Dit volgens mij voor mijn Zendure SF800plus-sen een prima RTE, toch?
De derde batterij met een extra ab2000x is nog bezig met ontladen (de andere twee staan op 10% SoC en zijn stand-by). Ik ben benieuwd welke cijfers deze oplevert wanneer SoC op 10%.

Efficientie waarde die bij de batterij staat is in ieder geval niet de RTE, want die kan m.i. nooit 100% zijn. Wat dit wel weergeeft weet ik ook (nog) niet.

Wat ik wel weet is dat de instelling Retourrendement wel de RTE betreft. Deze waarde staat standaard op 0.85 maar kun je zelf aanpassen voor je eigen batterijen. Voor zover ik begrepen heb wordt dit retourrendement door het algoritme meegenomen als je voorspellend laden hebt aangevinkt met dynamic pricing. Meegenomen worden: de waarde van de prijssensor, het retourrendement en de minimum arbitragemargin (EUR/kWh) die je ook zelf kunt instellen

[meesje]

Mai Pensato schreef op woensdag 21 oktober 2026 @ 21:21:
[...]

Efficientie waarde die bij de batterij staat is in ieder geval niet de RTE, want die kan m.i. nooit 100% zijn. Wat dit wel weergeeft weet ik ook (nog) niet.

Wat ik wel weet is dat de instelling Retourrendement wel de RTE betreft. Deze waarde staat standaard op 0.85 maar kun je zelf aanpassen voor je eigen batterijen. Voor zover ik begrepen heb wordt dit retourrendement door het algoritme meegenomen als je voorspellend laden hebt aangevinkt met dynamic pricing. Meegenomen worden: de waarde van de prijssensor, het retourrendement en de minimum arbitragemargin (EUR/kWh) die je ook zelf kunt instellen

Nog even verder gekeken. Het veld Efficiëntie betreft entiteit sensor.zendure_solarflow_round_trip_efficiency_total
Je zou dus verwachten dat dit wel de RTE is.

Google geeft de volgende mogelijke uitleg

Waarom geeft hij 100% aan?
De integratie gebruikt waarschijnlijk een van deze twee methodes die bij een lege batterij misgaan:
• De "Sinds Laatste Volledige Lading"-methode: Veel efficiëntiesensoren meten de stroom tijdens één cyclus. Als de batterij helemaal leegloopt naar zijn minimum (10% SoC), stopt de ontlaadsensor met tellen. Soms reset de integratie de efficiëntieberekening op dat exacte nulpunt (of minimum) alvast naar een basrawaarde (100%) voor de volgende cyclus, nog voordat er opnieuw geladen is.
• Wiskundige afronding bij stilstand: Omdat de batterij nu op 10% staat en er (hopelijk) geen stroom meer in of uit gaat, is de actuele energiestroom 0. Als de integratie de efficiëntie berekent op basis van actuele wattages in plaats van opgetelde kilowatturen (kWh), kan de formule door de nulwaarden vastlopen of standaard terugvallen op 100%.

Daarnaast geeft Google handvatten om zelf de RTE te bereken wat neerkomt op ontladen gedeeld door geladen.

Waar kan ik jouw instelling Retourrendement vinden? Deze zie ik niet zo snel.

In ieder geval fijn om te zien dat ik een RTE haal van iets meer dan 85%. Daar ben ik wel blij mee.

[Mai Pensato]

meesje schreef op woensdag 21 oktober 2026 @ 21:32:
[...]

Nog even verder gekeken. Het veld Efficiëntie betreft entiteit sensor.zendure_solarflow_round_trip_efficiency_total
Je zou dus verwachten dat dit wel de RTE is.

Google geeft de volgende mogelijke uitleg

Waarom geeft hij 100% aan?
De integratie gebruikt waarschijnlijk een van deze twee methodes die bij een lege batterij misgaan:
• De "Sinds Laatste Volledige Lading"-methode: Veel efficiëntiesensoren meten de stroom tijdens één cyclus. Als de batterij helemaal leegloopt naar zijn minimum (10% SoC), stopt de ontlaadsensor met tellen. Soms reset de integratie de efficiëntieberekening op dat exacte nulpunt (of minimum) alvast naar een basrawaarde (100%) voor de volgende cyclus, nog voordat er opnieuw geladen is.
• Wiskundige afronding bij stilstand: Omdat de batterij nu op 10% staat en er (hopelijk) geen stroom meer in of uit gaat, is de actuele energiestroom 0. Als de integratie de efficiëntie berekent op basis van actuele wattages in plaats van opgetelde kilowatturen (kWh), kan de formule door de nulwaarden vastlopen of standaard terugvallen op 100%.

Daarnaast geeft Google handvatten om zelf de RTE te bereken wat neerkomt op ontladen gedeeld door geladen.

Waar kan ik jouw instelling Retourrendement vinden? Deze zie ik niet zo snel.

In ieder geval fijn om te zien dat ik een RTE haal van iets meer dan 85%. Daar ben ik wel blij mee.

Retourrendement: in het Dashboard onder Bediening, voorspellend laden moet wel aangevinkt zijn.

Bij mij geven alle 3 de batterijen nu 100% Efficientie aan, ik heb ook wel eens getallen tussen 85 en 90% gezien. Waarom die nu op 100% staat weet ik niet

[meesje]

Mai Pensato schreef op woensdag 21 oktober 2026 @ 21:47:
[...]

Retourrendement: in het Dashboard onder Bediening, voorspellend laden moet wel aangevinkt zijn.

Bij mij geven alle 3 de batterijen nu 100% Efficientie aan, ik heb ook wel eens getallen tussen 85 en 90% gezien. Waarom die nu op 100% staat weet ik niet

Ah helder. Voorspellend laden staat bij mij niet aan. Mooi dat je deze variabele zelf kunt inregelen. Het zou nog mooier zijn als OB dit percentage op een gegeven moment zelf bepaalt op basis van historie.

Wat betreft Efficiëntie, deze zag ik gedurende de dag ook lagere waarden tonen. Wat me nu opvalt bij mijn derde batterij (de andere twee zijn leeg) is dat het percentage klimt naar 100% naarmate de batterij richting de ingesteld SoC van 10% gaat.

Komende tijd maar verder in de gaten houden. In ieder geval blij met mijn rendement van 85%.

[meesje]

Wauw, mijn derde batterij is (SF800plus met ab2000x) is zelfs geëindigd op een RTE van ruim 87%. Helemaal happy!

[Magnistraal]

bigkevx2 schreef op woensdag 21 oktober 2026 @ 18:45:
[...]

Dit zou ik ook doen. HW instant via HACS, works like a charm.

"Homewizard instant" installeren NAAST de officiele HW integratie.

HW instant is een programma waarbij je de polling handmatig kunt instellen.

Ik gebruik het al enige tijd en staat ingesteld op 1 seconde.
Standaard staat de HW polling soms wel op 8 seconden.
Bij een te trage reactie van de HW P1 loopt je geld mis.

https://github.com/taurgis/homeassistant-homewizard-instant

Tevens nog een opmerking/tipje:
Als je OB gebruikt ga dan niet in de Marstek zitten neuzen, dit helpt de boel in de zeik.
Beter de App geheel verwijderen.

[ Voor 13% gewijzigd door Magnistraal op 22-10-2026 08:48 ]

[Pakhaas]

Ik heb OB nu ook in HA staan en ben even benieuwd of het volgende mogelijk is met een extra automatisering.

Zodra de EV (die staat bij ons op fase 3, geen loadbalancing) aan staat dan wil ik dat het vermogen van de batterij op fase 3 wordt beperkt tot max 1800w laden ipv 2000w. Met Gielz lukt dat nu gewoon, maar kan ik dat ook met OB doen? Is er een sensor waarmee ik het vermogen van een batterij kan aanpassen?

[Gyrolion]

Ik denk dat je met de number.<batterij>max_charge_power in de omnibattery hier wel wat mee kan doen ism met een automatisering.
Deze kan je ten alle tijde aanpassen, dus een automatisering, auto gaat laden zichtbaar via charge active sensor, zet max_charge_power op 1800w.

Maar omnibatterij heeft intern ook load balancering op 3 fases, dat is misschien ook interessant voor je.

[ Voor 3% gewijzigd door Gyrolion op 22-10-2026 12:34 ]

[Pakhaas]

Gyrolion schreef op donderdag 22 oktober 2026 @ 12:32:
Ik denk dat je met de number.<batterij>max_charge_power in de omnibattery hier wel wat mee kan doen ism met een automatisering.
Deze kan je ten alle tijde aanpassen, dus een automatisering, auto gaat laden zichtbaar via charge active sensor, zet max_charge_power op 1800w.

Maar omnibatterij heeft intern ook load balancering op 3 fases, dat is misschien ook interessant voor je.

Ja dat is ook zeker een optie. Vul je dan per fase in hoeveel vermogen er door kan?

[Gyrolion]

Pakhaas schreef op donderdag 22 oktober 2026 @ 12:44:
[...]

Ja dat is ook zeker een optie. Vul je dan per fase in hoeveel vermogen er door kan?

Ik heb er maar 1 batterij in staan, maar je regelt hem per batterij.

Dus als je weet welke batterij op fase 3 zit kan je diegene limiteren.

Ook in loadbalancing geef je aan welke batterij op welke fase zit.

Dit is het menu per batterij:

[ Voor 30% gewijzigd door Gyrolion op 22-10-2026 12:47 ]

[Pakhaas]

Gyrolion schreef op donderdag 22 oktober 2026 @ 12:46:
[...]

Ik heb er maar 1 batterij in staan, maar je regelt hem per batterij.

Dus als je weet welke batterij op fase 3 zit kan je diegene limiteren.

Ook in loadbalancing geef je aan welke batterij op welke fase zit.

Dit is het menu per batterij:

[Afbeelding]

Ja ik weet welke fase de betreffende batterij staat, maar ik zie geen load balancing opties in dat menu per batterij

[Gyrolion]

Als ik het zo begrijp kijkt de app naar de 3 fases (deze stel je in bij de 3 fase config) en stel je de batterij per fase in. wordt er dan overbelasting gezien op een bepaalde fase zal omnibattery de batterij op deze fase limiteren.

[Pakhaas]

Gyrolion schreef op donderdag 22 oktober 2026 @ 13:09:
Als ik het zo begrijp kijkt de app naar de 3 fases (deze stel je in bij de 3 fase config) en stel je de batterij per fase in. wordt er dan overbelasting gezien op een bepaalde fase zal omnibattery de batterij op deze fase limiteren.

Bedankt ik ga even kijken als ik thuis ben.

[NiCNCo]

Gyrolion schreef op donderdag 22 oktober 2026 @ 13:09:
Als ik het zo begrijp kijkt de app naar de 3 fases (deze stel je in bij de 3 fase config) en stel je de batterij per fase in. wordt er dan overbelasting gezien op een bepaalde fase zal omnibattery de batterij op deze fase limiteren.

Ja, Omnibattery ziet alle fasen van je P1. Ziet hij een overbelasting (lees verbruik boven je ingestelde max amperage, deze stel jezelf in tijdens de OB setup in het three-fase-configuration menu) normaliter 25A voor de meesten. En je OB beheert tevens een batterij die op dezelfde fasen ingesteld staat als waar er overbelasting gaande is, dan regelt OB gelijk het vermogen terug tot het amperage zakt tot onder de max waarden. Afhankelijk van hoe zwaar de fase tijdelijk over zijn max schiet door een zware EV charge bijvoorbeeld dan zal OB de battery als sckrik reactie op 0 zetten, en voorzichtig in staffels omhoog brengen als er weer ruimte is. Of hij bij lage overbelasting regelt OB de batterij ietsjes terug. Je hebt hier dus geen aparte automisering voor nodig, het zit er netjes ingebakken.

[NiCNCo]

Mai Pensato schreef op dinsdag 20 oktober 2026 @ 00:10:
Ah nu vind ik deze ook. Vreemd dat deze dan niet erbij staat in de knoppen bij Bediening.... Voor de zekerheid: De minimum marge die betekent wat je nog overhoud na aftrek van de kosten en efficientie-verliezen? Dus in de berekening wordt al meegenomen de kosten die de energieleverancier rekent (in mijn geval Tibber 0,018 per kWh) en de RTE (heb ik op 85% laten staan) ?

de abitrage instelling staat wel in het Omni dashboard onder de controls tab --> in het predictieve charging venster, je moet alleen even de toggle "advanced setting" bovenaan in hetzelfde venster indrukken voor meer/of minder settings

[NiCNCo]

Mai Pensato schreef op woensdag 21 oktober 2026 @ 10:58:
@JBS dat is een heel mooi overzicht, Hoe heb je dit overzicht gemaakt op basis van die sensor? Ik heb die sensor wel gevonden (heet bij mij "Dagelijkse bedrijfstijdlijn") maar ik zie daar bijv niets over accu, zon->accu, verbruik en prijs ??

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.

[ Voor 20% gewijzigd door NiCNCo op 22-10-2026 15:08 ]

[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 "?