Ik gebruik deels deze oplossing met wat extra aanpassingen, dus troost je twijfel.
Dit is ook benoemd in de changelog van afgelopen periode.
Ik lees niet bij elke update van een app het changelog. Zeker niet als het gedeelte wat k gebruikt gewoon werkt. Ik laat de manager eerst wel een week mee draaien. Kijken wat het doet. De beslissingen die ik nu zie staan zijn nog niet als gewenst.
Welke KNMI api raadt je aan? Want ik zie er een heleboel op de KNMI site.
Negeer die voorlopig. Ik haal al via OpenMeteo KNMI op. Zit nog wat experimentele code / opties in.
Zoals gezegd, de battery policy moet je opwek en verbruik patronen “leren” dus blanco zal het nog gek doen. En vandaag helemaal met bewolking die hier niet overeenkomt met wat de computer/weer modellen zeggen. Vandaag is eerlijk gezegd wel de meest extreme dag die ik gezien heb.
Oke, slaan we dat even over. De opwek ga ik de flow voor aanmaken. (was net bezig) Mijn patronen word interessant. Ik werk namelijk in ploegendienst, en dus is wat hier in huis gebeurt elke week anders. En dat is denk ik ook waar slim laden van Homewizard de mist in gaat. Afgelopen 5 dagen in de avond niet veel verbruik. Dus vandaag batterij niet vol. Vandaag ben ik thuis dus meer verbruik. Ik vind het prettig dat ik met jou app op het dashboard kan zien wat er gaat gebeuren en wat er gebeurt is. Ik heb dus weer wat te knutselen. 
Ja snap ik, ploegendienst is ook niet makkelijk voor patroon herkennings gericht sturen.
Ik zet de optie op todo lijst voor nu, maar wil eerst de Solcast er uit gooien.
Voor nu weinig / geen klachten van gebruikers dus laat ik het voorlopig even zo.
Hoe minder ik nu verander des te beter het voor mijn mailbox is. 
Ben al blij dat crashes en geheugen problemen over zijn. 
Ploegendienst is de hele rede dat hier een Homey staat. Een week programma in je klokthermostaat heb je dan helemaal niks aan. Het zou dus kunnen zijn dat ik voor bij mijn moeder jou manager op den duur laat draaien, en dat ik bij mij een hybride flow ga maken.
Zoals de Amerikanen zeggen. Als het niet stuk is, probeer het dan niet te maken. Dat is inderdaad rustiger voor je e-mail bakje.
Ik zie in de manager dat deze ook de aanwezigheid bijhoud. Welke invloed heeft dit? Hoe beter ik jou manager begrijp hoe beter ik mijn flow inrichten.
Ah, ik zit alles via safari te knutselen, heel klein i-tje in de hoek zie ik net. 
Laatste vraag voor vandaag, ik heb ook een EPM flow draaien. Deze regelt het afgegeven vermogen van de omvormer(s) naar het verbruik in de woning als het export tarief <€0 is. Of als het afname tarief <€0 wordt zelfs naar 0. Dit zal dat van invloed zijn op het leren en de planning. kan je de manager vertellen dat de PV installatie beperkt is? Zodat dit niet van invloed is op het leren van het PV model?
Eeeeeeh geen idee, je kan een gecombineerde PV waarde berekenen en die sturen naar de batterij policy om deze voor de gek te houden met de werkelijke PV (minus je EMS flow). Maar voor nu is het voor mij gissen wat je en hoe je dit allemaal wilt en verwacht van de battery policy device. Je use case is erg uniek wat het voor mij lastig te sturen valt zonder dit goed te vatten. Voor nu werkt het best leuk en zal alleen maar beter worden.
Op het moment dat de EPM flow ingrijpt komt er dus minder vermogen van de PV omvormer dan verwacht.
Op het moment staat het bij mij zo ingesteld dat indien het export tarief negatief gaat, en de batterijen nog onder de 93% zitten. Het vermogen naar 1600W+sluipverbruik gezet wordt. (2 batterijen) Terwijl op 100% van de PV misschien wel 2434W geleverd kan worden. Als de manager continu het geleerde PV model aanpast zal dit dus het geleerde model beïnvloeden. Het lijkt mij dan zinvol om de manager de inkomende PV data te laten negeren zolang de EPM het vermogen beperkt zodat het geleerde model niet negatief beïnvloed word.
Dus bijvoorbeeld een flow kaartje “begrenzing actief” waarmee dan dus het leermodel even gepauzeerd wordt totdat dit weer opgeheven is.
Verder zal je denk ik je manager al zo gemaakt hebben dat bij een negatief export tarief de batterij geladen wordt. Daar is dus verder geen actie nodig.
Klopt negatief gaat deze uiteraard laden. Helaas nog niet goed kunnen testen omdat deze moment nog weinig voor komen. Verder kan je beleid uit/aan zetten voor je EPM flow. PV curtailing komt nog wanneer ik zin en tijd heb. Zelfde als de post salderen 2027 wat ook een klus wordt.
Met steeds meer batterijen krijgen wij natuurlijk de omgekeerde beweging van steeds meer zonnepanelen. Dat geeft niet, dan levert het overschot van je PV nog wat op. 
Wat wij wel gaan krijgen is dat het import tarief positief is, en het export tarief negatief. (bij afname komt er energiebelasting bij) Dus dit jaar blijft het nog bij extreme gevallen zoals 1 mei. Volgend jaar zal de EPM vaker ingrijpen omdat je dus niet meer je energiebelasting terug krijgt.
Maar die functie hoef wat mij betreft niet in je app te zitten, dat is niet te doen joh voor elk omvormer merk. Alleen de optie dat een beperking aan staat zodat het PV model niet verminkt wordt lijkt mij voldoende.
Waar haal je nu de prijsinformatie? Homey energy? (ik zie verder geen instellingen in je app) Daar zie ik inderdaad ook nog geen import en export tarief. PBTH heeft dit bijvoorbeeld al wel.
Deze app is voor Homewizard hardware, ik heb geen toegang tot andere merken (wil ik ook niet). Alle koppelingen zijn intern binnen deze app. Er zijn apps die “volledig” toegang willen van je Homey en dat weiger ik.
Ik heb al extra logging in de code zitten om te detecteren dat andere apps via Homey “rechten” gedrag of aansturing beinvloeden en dan later klagen dat het niet werkt bij deze app. Ik zie steeds meer EMS apps verschijnen dus ik zie de bui al hangen aangezien er veel gebruikers zijn die Homewizard devices hebben en ik “indirect” tegen problemen knal.
Dynamische prijzen zijn gewoon EPEX (day ahead) net als alle andere apps hier en indicatief, geen provider verschil of custom tarief wel/niet extra teruglevering bonus. Daar zijn andere (betere) apps voor en ga ik mij niet in mengen of concurreren.
Straks komt er een generieke invulling voor post salderen waar inderdaad o.a. energiebelasting het verschil maakt tussen import en export. Maar ik ga geen ANWB, Zonneplan, Tibber, etc tot in de details opnemen.
Al die extra moeite krijg ik niets voor terug.
Door mijn PIB en EPM flow ben ik er wel achter dat twee huizen niet gelijk zijn. Grote lijnen zijn het zelfde, maar je flow op maat maken werkt het mooiste. Voor het laden bij onvoldoende zon ben ik nog met de finetuning bezig. Ik denk wel dat ik jou manager daar in een adviserende rol ga gebruiken. Of zelfs gewoon zijn ding laat doen en ga overheersen als er duidelijk iets anders moet. Ik laat het eerst een week leren en dan ga ik kijken wat het doet.
Je gebruikt nu dus alleen de marktprijs? Dus niet met inkoop/verkoop vergoeding en belasting er bij? Dat maakt uiteraard niet uit om te bepalen of de prijs hoog of laag is. Maar wel voor wat er berekend wordt op de factuur. Als je de tarief instelling zo maakt als in de Homewizard app dan ben je er toch al? Profiel per energieleverancier maken is inderdaad niet te doen.
Ik probeer generiek te blijven. Tot nu is het salderen en dynamisch import/export zo goed als gelijk en gedrag voor de batterij voldoende. Ja straks met 2027 wordt dit anders en zal ik kijken naar specifieke settings. Nee het is marktprijs + belasting en een gemiddelde toeslag (een gemiddelde is van Zonneplan, ANWB, tibber, etc.). Dus het zal niet exact x y of z energieleverancier zijn maar voor wat het nu moet doen is het goed genoeg. Dus geen toeters en bellen aangezien de settings lijst al flink is. Idee was KISS.
Energie beheer is een aardig konijnenholetje. KISS is vrij snel overboord, maar daar was je al achter. Voor nu hou ik dan even mijn sturing er in voor als de het berekende tarief negatief gaat.
Prima, ik kan niet iedereen tevreden houden.
Beste Jeroen,
Sinds een korte periode (schat in sinds een week of 2) krijg ik steeds een batterij error melding van de p1 meter.
Zojuist ook weer. Mij is het onduidelijk wat er gebeurt.
Hierbij het diagnostisch rapport:
7abc13d7-19f3-4c3f-a7e3-c3dfec0dec17
Als ik in de Homewizard app binnen Homey kijk en wat verder er doorheen ga kom ik het volgende tegen (ik had de app net gerestart, maar het log blijft). Nu geeft het aan alsof een andere app oo kde batterijen aanstuurt. Maar de enige andere app die dat zou kunnen is de Homewizard app zelf, en die gebruik ik niet en is ook niet geprogrammeerd op de een of andere manier.
Heb je enig idee wat gaande is?
Ps: soms heb ik laatste tijd ook (onterecht) last dat een batterij zonder wifi staat. Wifi is onveranderd en prima in signaal.
═══════════════════════════════════════
HomeWizard Diagnostic Report
═══════════════════════════════════════
Generated: 2026-06-18T19:43:09.717Z
── App Health ──
Version: 3.16.0 Uptime: 0h (since 2026-06-18T19:33:40.421Z)
Heap: 13.7/15.3MB peak 13.7MB ext 2.5MB limit 70MB
Devices: plugin_battery×2 energy_v2×1
Snapshot: 2026-06-18T19:35:10.427Z
No device snapshots available.
── 
ANOMALIES ──
capability_api_mode_change: 20× — likely 3rd party app overriding battery mode. Last: zero at 2026-06-11T05:35:29.454Z
── Event Journal (last 20) ──
25-4-2026, 17:44:59 capability_api_mode_change [5c2faf39] mode=“zero_discharge_only” count=1
25-4-2026, 17:50:36 capability_api_mode_change [5c2faf39] mode=“standby” count=2
25-4-2026, 17:50:50 capability_api_mode_change [5c2faf39] mode=“to_full” count=6
25-4-2026, 17:50:56 capability_api_mode_change [5c2faf39] mode=“zero_discharge_only” count=8
2-5-2026, 08:30:22 capability_api_mode_change [5c2faf39] mode=“zero_discharge_only” count=9
10-5-2026, 11:25:20 capability_api_mode_change [5c2faf39] mode=“zero” count=10
14-5-2026, 10:58:58 capability_api_mode_change [5c2faf39] mode=“zero” count=11
17-5-2026, 09:48:47 capability_api_mode_change [5c2faf39] mode=“zero” count=12
28-5-2026, 11:46:38 capability_api_mode_change [5c2faf39] mode=“zero” count=14
2-6-2026, 10:45:02 capability_api_mode_change [5c2faf39] mode=“zero” count=15
3-6-2026, 09:47:27 capability_api_mode_change [5c2faf39] mode=“zero” count=16
7-6-2026, 09:45:39 capability_api_mode_change [5c2faf39] mode=“zero” count=17
9-6-2026, 11:45:19 capability_api_mode_change [5c2faf39] mode=“zero” count=18
11-6-2026, 07:07:24 capability_api_mode_change [5c2faf39] mode=“zero_discharge_only” count=19
11-6-2026, 07:35:29 capability_api_mode_change [5c2faf39] mode=“zero” count=20
═══ End of report ═══
Klopt je wifi gaat niet goed, zowel je P1 als de Plugin Battery verliezen verbinding. Omdat de status van mijn app niet overeenkomt met de werkelijke status van je P1 en je Plugin battery krijg je deze meldingen.
In dit geval vals alarm door wifi problemen dus die zal je moeten oplossen.
Misschien is het alleen je Homey die wifi problemen heeft maar dat kan ik niet opmaken uit de log.
2026-06-18T19:23:03.782Z [log] [ManagerDrivers] [Driver:energy_v2] [Device:405176ca-378f-4478-9f35-257ae3a492f4] Polling error: TIMEOUT
2026-06-18T19:23:13.798Z [log] [ManagerDrivers] [Driver:energy_v2] [Device:405176ca-378f-4478-9f35-257ae3a492f4] Polling error: TIMEOUT
2026-06-18T19:23:23.804Z [log] [ManagerDrivers] [Driver:energy_v2] [Device:405176ca-378f-4478-9f35-257ae3a492f4] Polling error: TIMEOUT
2026-06-18T19:24:28.043Z [log] [ManagerDrivers] [Driver:plugin_battery] [Device:d604197a-0120-4c81-8d5e-5414fd57f07d] 📡 LastSeen: IP unchanged (192.168.10.16)
2026-06-18T19:24:28.044Z [log] [ManagerDrivers] [Driver:plugin_battery] [Device:d604197a-0120-4c81-8d5e-5414fd57f07d] 📡 LastSeen: IP unchanged (192.168.10.16)
stderr:
2026-06-18T04:52:47.591Z [err] [ManagerDrivers] [Driver:plugin_battery] [Device:d5c82384-77d0-4325-ba83-5960e3ca5258] Polling error: The user aborted a request.
2026-06-18T04:53:47.682Z [err] [ManagerDrivers] [Driver:plugin_battery] [Device:d604197a-0120-4c81-8d5e-5414fd57f07d] Polling error: The user aborted a request.
2026-06-18T04:53:47.684Z [err] [ManagerDrivers] [Driver:plugin_battery] [Device:d5c82384-77d0-4325-ba83-5960e3ca5258] Polling error: The user aborted a request.
2026-06-18T04:54:35.773Z [err] [ManagerDrivers] [Driver:plugin_battery] [Device:d5c82384-77d0-4325-ba83-5960e3ca5258] Polling error: request to https://192.168.10.10/api/measurement failed, reason: connect EHOSTUNREACH 192.168.10.10:443
2026-06-18T04:54:35.774Z [err] [ManagerDrivers] [Driver:plugin_battery] [Device:d604197a-0120-4c81-8d5e-5414fd57f07d] Polling error: request to https://192.168.10.16/api/measurement failed, reason: connect EHOSTUNREACH 192.168.10.16:443
2026-06-18T04:55:37.742Z [err] [ManagerDrivers] [Driver:plugin_battery] [Device:d604197a-0120-4c81-8d5e-5414fd57f07d] Polling error: The user aborted a request.
