Will investigate when I am back from my vacation.
Proost, have a Nice holliday
@Jeroen_Tebbens Enjoy your vacation.
@micke_011 thank you for your donation 
Latest Updates (v3.15.37) test/beta
Battery Policy — PV Forecast & Learning
- Yield-factor normalisation (v1 + v2) — Yield factors learned while
radiation_bias_factor > 1.5was active were systematically under-calibrated (biased radiation as baseline). One-time reset so they re-learn against unbiased radiation. v2 also resets the bias factor itself, which had been artificially inflated to the cap by the miscalibrated yield factors - (optional) Solcast moved to
_updateWeather— Solcast forecast is now fetched on every weather update (including when policy is disabled), keeping the PV chart current at all times. If you have no Solcast API key it will stick to Open Meteo without adjustments. - Intraday PV scaling tuned — Lower learning weights for intraday correction; prevents overreaction to temporary deviations early in the day
- Cycle recorded on discharge→charge transition — Battery cycles are now also recorded when SoC never reaches 0% (typical on PV-heavy days): trigger is the transition from discharging to charging once ≥ 0.3 kWh has been discharged
Battery Policy — Battery Mode Camera
- Predictive modes visible in camera — In predictive mode (Homewizard Slim Laden active) modes were not recorded because the policy does not run. The slot interval now also records mode + SoC when policy is disabled, so switches between predictive_charge, predictive_discharge, predictive_zero and predictive_standby become visible in the Battery Modes webcam
Memory & Stability
- Startup crash fix (v3.15.35) —
homey.settings.setallocates ~30 MB V8 heap per call regardless of payload size. With multiple devices initialising concurrently, heap peaked at 70+ MB → Memory Warning. All drivers now use a serialised write queue (8 s between writes). Rebuildable UI state (planning, explainability, weather) lives in_liveStatein memory and is served viaapi.js— never written tohomey.settings - Settings page live-state —
Homey.geton the settings page now automatically merges in-memory live-state via a GET/getLiveStateAPI call. Existing render code requires no changes - SDM230_v2 / SDM630_v2 polling spread (v3.15.36) — When multiple SDM devices are present, the first poll is spread across the polling interval to avoid simultaneous HTTP requests
- Initial weather and policy deferred — Weather fetch deferred to T+30 s, first policy check to T+45 s after startup. Prevents a cumulative heap peak of 70+ MB during the onInit cascade on setups with many devices
- Device-type counter in memory log —
[MEM]log line now shows instance counts per driver type (energy_v2=2 plugin_battery=1 …) to speed up triage of crashes from users with different device configuration - Heatlink fix — User reported issue heatlink not properly detecting target temperature changes (due to long polling interval)
Latest Updates (v3.15.38) test / beta
Battery Cycle Tracking
- Cycle accumulators survive restarts —
_cycleKwhDischarged,_cycleRevenueand_cycleCostare now persisted to device store (alongside_costEnergy/_costAvg). Previously a restart during an active discharge silently reset all accumulators to zero, causing the evening discharge to be missing from cycle history and ROI tracking - RTE learning cycle fix — Balance guard lowered from 1.45 → 1.40. The old threshold (1.45) meant the minimum measurable RTE at guard-passage was 1/1.45 = 68.9%, just below the 70% floor — so every measurement that barely passed the guard was immediately discarded. With 1.40 the minimum is 71.4%, ensuring a valid measurement every time the guard passes
Battery Policy
- Negative price → always charge to full — When spot price is negative, the mapper now returns
to_fullregardless of PV state. Charging at negative prices earns money, so PV-mode guards (zero_charge_only,pvStoreWins) are bypassed
UI
- Learning status always current —
learning_statusis now written on every_updateWeathercall (hourly), not only when the optimizer runs. Previously, with policy disabled or in predictive mode, the Leerdagen/coverage/PV-accuracy pills in the settings UI would show stale values
41cca1ef-9cf1-4569-bb4c-6c0893c8ebc0
If I change my heatlink temperature automatically or manually, it will be adjusted first and then reset back to the old temperature. And then he goes to the fixed value.
Use test version. Heatlink fix has been added there.
Hey Jeroen, quick question—I can’t figure out how to change the P1 meter to the 3-phase meter data in the battery policy. Which repair tool should I be using for this?
No support added for 3 phase. Not sure even why it needs 3 phase as battery policy should act on overall self usage and if that is 1 or 3 phases that doesn’t matter. The battery policy looks at grid usage and batteries and your solar.
Installed the test version.
Tested it and for now it is working.
Thanks.
Yes am aware, yet HW plugin battery is mostly dutch users at this moment. But I’ll put it on my to do list.
Hi Jeroen, as of yesterday the Battery app remains in stand-by although there is a large export to the grid.
=== HomeWizard Battery Policy — Support Info ===
Tijdstip: 2026-04-30T08:39:17.054Z
-– Batterij —
Aantal: 3 Capaciteit: 8.06 kWh
Max laad: 2400W Max ontlaad: 800W
SoC nu: 9% Modus nu: standby
-– PV —
Capaciteit: 6500W Geleerde slots: 56/96
PR instelling: 0.75 PV actief: true
-– Instellingen —
Beleidsmodus: balanced-dynamic Tarieftype: dynamic
Strict min/max: true
Max laadprijs: €0.120 Min ontlaadprijs: €0.160
Min SoC: 0% Max SoC: 100%
Efficiëntie: 0.78 Cycluskosten: €0.075/kWh
-– Laatste policy run (v3.15.52) —
Tijdstip: 2026-04-30T08:36:58.369Z
Prijs: €0.133 SoC: 9% Huidig verbruik: 0W
Scores: laden=0 ontladen=0 behoud=0
Beslissing: standby → standby
Break-even: €0.000 Gem. kostprijs: €-0.024
Optimizer: standby
Prijsrange 12h: €0.088 – €0.355
Yes there is a bug in the test version that blocks the planning. Where it should either charge or discharge but it doesnt. I also have another user facing same issues.
I am currently a bit blocked fixing as I am part of the closed beta for Homewizard SlimLaden so my battery and P1 set up is not controlled by the code so hard troubleshooting/fix the problem.
For now turn the battery policy off and make it zero or perhaps you have your own flows to put the battery in your desired state. When I got the fix done I will communicate.
Will do, Thanks and succes with testing.
Hi Jeroen, you have been quite busy, all appears to be working correct, thanks for that. I see in the changelog you are working on a household usage, this sounds like learning for anticipation. If Im correct can you also think about the influence of a big user like loading an electric car. Either keep it out of the equation or do something smart since in my experience this upsets the normal household usage irregular and for a long time of not every day. In my case the 75kWh battery is no match for the 3 Homewizzard batteries. If Im wrong please disregard my remark.
Busy yes, very. I do try to anticipate in house hold usage. But I have not found an acceptable way to keep an EV out of it as I have no way to track this. My app currently has no higher privileges to tap into other Homey devices (call it root access to Homey).
If it would be a kWh meter perhaps, or some flowcard that needs to feed the EV activity (ie watt usage) in to the battery policy to do some magic about it.
If I would aim for kWh meter that would not be fair to expect users to locked in to such a solution. So let me think about it.
Does your EV stop charging when done or does it slow feed watt’s? Is there a threshold?
I see the issue, don’t spend to much time on it I would say. My EV is charged by an Amina-S “laadpaal” controlled by Homey. Before installing your HomeWizzard app I had a simple flow that based on the solar production tried to force the export (max 6200W Solar) to zero by controlling the load current (per amp) to the car and switching between 1 and 3 phase with low/high solar production. With the HW app and the HW batteries this became way to complicated since both were doing the same but with high and detailed steps. My gut feeling says the batteries should deliver power during the night so full before the evening peak. My approach (I think) would be to stop the HW battery app when loading the car but I am not sure yet. My worry is the influence of loading will upset your effort to define a household baseline. (Loading a car or possibly a small business at home, swimming pool ??) To answer your question the car is charged dynamically with a flow and on top of that is slowed down by the car when approaching 100%. When full no power is consumed unless I e.g. start the AC for heating or cooling the car before departure. Possibly you might consider accepting a flow output (variable?) that will detract EV usage from the household as you envision, this way everybody can switch off disturbances whatever they are in their installation but again my advise would be not to overcomplicate your excellent work. The point is my/a car is plugged in when at home but not always as empty and not every day charging the same kWh when charging and on top of that although I prefer solar this is not always available or negative grid price is also ok but also not always available. To much variables, holy grail? In addition I have an on/off heat pump requesting 1.5 kW whenever it decides to.
