Control your HomeWizard products (not the Link or Smart Switch.)
Stable: v3.15.106 Test/beta: v3.16.0
Nederlands forum topic hier, maar meeste info zal in dit engelse gedeelte te vinden zijn omdat dit al langer loopt.
→ [APP][Pro][NL] Homewizard 🧙♂️
HOMEWIZARD ENERGY PRODUCTS NOTES
Wifi P1 dongle support is only working when dongle has firmware 2.09! Please check firmware before you try to add it. This firmware support mDNS (auto discovery) hence easier to add. It is the same technique used as ChromeCast (Google). So if you face issues with your wifi network and struggle with the devices not found you can check you wifi vendor support pages on ChromeCast issues as it the same discovery method. Wait for the dongle to get this firmware from the cloud before you try to add it.
kwh1 & kwh3 (SDM230 & SDM630), energy sockets and the watermeter (~August 2022) before you try to add them you MUST enable Local API in your Homewizard Energy app. This is disabled by default and will not allow a discovery to work (mDNS method).
Make sure your wifi devices are getting a reserved ip address in your DHCP scope of your Wifi / Router dhcp.
PLUGIN BATTERY
If you want to control your Plugin Battery via Homey you have to add the P1 as a APIv2 device.
You can have it next to your existing P1api1 and disable the Homey Energy include to avoid double energy tracking. Or you remove the old one but do note that historical data for this P1 will be lost.
Steps:
Add P1 as APIv2 (during the pairing process you have to press the P1 button on the device so be sure you near your P1 within 30 sec.
Make sure devices are not on a Guest wifi SSID or AP client isolation is turned on (must be off!)
Make sure multicast is enabled on all your access points and routers
(unifi?) Disable Multicast enhancement
Reboot homey (mDNS discovery might be stuck)
Reboot your wifi accesspoints/routers (unifi / ubiquiti common issues)
Power cycle your device P1, KWH, watermeter or socket(s)
Verify “LOCAL API” is on in Homewizard Energy app for the device(s)
Watermeter does not work when on battery only (must be usb powered to enable LOCAL API mode)
Install mDNS discovery app on your iphone/android and check for _hwenergy._tcp and see you can see your devices there.
Toggle the LOCAL API in the official HomeWizard Energy app and restart the HW app on Homey to discover again
Or
Pihole and Adguard users:
For those users that have Homewizard device issues (! Icon) or devices that wont move to available is a tip related to Pihole and/or Adguard.
Multicast DNS isnt handled properly via these DNS sinkholes. You should install AVAHI service on your Pihole and/or Adguard linux server that picks up these queries and resolves these queries locally.
For Homewizard Energy devices my suggestion is reserve static ip’s in the dhcp server scope of your router (when possible). Some routers and dhcpserver keep cycle their dhcp scope.
More advanced tip(and those who are knowledgeable enough to implement): separate your IoT devices from your local LAN. Most of these IoT devices are cheap China tech and not known to proper firmware updates. When you separate these you need mdns repeater/proxy/relay on your router. But only if you know how to do it as its very complex to implement and requires a high level of network understanding (vlans & firewall rules).
HOMEWIZARD (legacy, yeah the old appliance)
Upon first deployment you need add the HomeWizard unit first,
then you can add the related/connected components
from HomeWizard to your Homey (ie. Heatlink, Energylink etc.
Get your local Homewizard IP address and local password (not the Homewizard Online account!)
If trying to add this in the Homey GUI and get a quick flash of this screen and blank after, please use the webinterface of Homey GUI https://my.homey.app.
Homey does not support Heatlink and Energylink directly without the Homewizard unit.
Homewizard have protected their 868mhz communication with Energylink and Heatlink so you still need the Homewizard unit to make this work.
Supports: Energylink, Heatlink, Windmeter, Rainmeter, Temperature sensors, Smoke & Motion sensors
Does not support: Light bulbs & Power sockets (use KlikAanKlikUit or Smartwares app to control these).
Note on Motion sensor: There is a 10 seconds delay (use KlikAanKlikUit or Smartwares app if you need direct response).
### Solar Forecast Pipeline Simplified — Removed Stale Correction Layers (v3.16.0)
* **Solar (PV) forecast accuracy improved by removing several correction layers that had drifted out of sync with the underlying yield-learning** — Three changes: (1) the daily PV bias factor (a correction learned from past forecast-vs-actual ratios) no longer applies once the per-slot solar yield factors have converged (≥10 learned slots) — previously it kept multiplying an already-corrected forecast by up to 1.54×, double-counting the correction (`learning-engine.js`, `getDailyPvBiasFactor`); (2) the “clear-sky ceiling” — a separate hard radiation-based cap on the PV forecast — has been removed entirely; the forecast is now radiation × learned yield factor, capped only by the panel’s rated capacity; (3) an abandoned experimental “Cabauw decorrelation” scaffold (unused nowcast correction, never enabled) has been stripped from `weather-forecaster.js` and `learning-engine.js`. Together these collapse a stack of stacking correction layers into a single traceable pipeline (radiation → yield-learning → daily-bias gate → DP forecast), with the *same* forecast feeding the DP optimizer, the planning chart, and the explainability text — verified by code-trace, no separate snapshots.
* **Overnight battery reserve now also reacts to forecast model disagreement, not just historical accuracy** — The refill-reserve floor (which holds back charge overnight when next-day PV is uncertain) previously based its confidence only on past forecast accuracy and bias-corrected delivery ratio. It now also folds in the *forward* spread between weather-model ensembles (MF/GFS/ICON/KNMI) for the upcoming day — wide model disagreement raises the reserve floor even when historical accuracy looks fine, since past accuracy can’t see that tomorrow’s forecast is unusually uncertain. `optimization-engine.js`, `refillConfidenceFromForecast`.
* New economic-dominance regression test: lifting the PV forecast for any slot can never *decrease* the optimizer’s projected profit under net-metering (more free PV input is always neutral-or-better). `test/optimizer-properties.test.js`
### Planning Chart No Longer Projects a Grid Charge the Runtime Won’t Make (v3.15.97)
* **The planning table no longer shows `to_full` (grid charge) on a low-SoC slot when the PV forecast is strong** — On a cheap, low-SoC slot where the forecast PV roughly cancels forecast consumption (net surplus ≈ 0), the planning mapper’s low-SoC grid top-up fired and projected `to_full`, while the live runtime peak-shaved from PV and never pulled from the grid. The chart over-promised a grid charge that reality skips. The planning top-up is now suppressed whenever PV is strong (≥ 400 W), mirroring the runtime — which suppresses top-up via its real `estimatedNetPvSurplusW` signal whenever PV is producing. Strong PV now projects PV-only charging (`pv_trickle` / `zero_charge_only`); the top-up still fires when PV is genuinely weak or absent and no peak-shave is possible. Economically sound too: when PV refills the battery for free, a grid top-up is pure cycle-cost loss. Regression tests in `test/policy-planning.test.js`
### SoC-Drift False Positive on Planned Charge from Empty (v3.15.97)
* **A planned `to_full` charge from an empty battery is no longer flagged as a BMS-calibration drift** — When the battery legitimately starts the day at 0% (drained overnight by the planned evening discharge) and the plan commands a normal `to_full` grid charge, the SoC-drift detector fired a false ` SoC drift detected` the instant charging began. Cause: the drift timer was anchored to when SoC *last changed*, which for an empty+idle battery was hours earlier overnight — so the “20 minutes stuck while charging” threshold was already satisfied before a single minute of real charging had elapsed. The detector now anchors to when *charging-while-stuck began* (new `computeChargeStuckAnchor` helper, reset whenever the battery is idle or SoC leaves 0%), so the delta measures sustained charging duration. A fresh `to_full` stays silent; a battery that genuinely won’t take charge for 20+ min still fires correctly, and the real BMS-calibration two-phase signature (75 W → 800 W) is unchanged. Regression tests in `test/battery-soc-drift.test.js`
### Overnight Reserve Now Reacts to PV-Forecast Bias (v3.15.97)
* **The battery holds an overnight reserve when the PV forecast has been over-optimistic, not just when it is volatile** — The refill-reserve floor (which keeps the battery from draining to empty before an uncertain next-day PV refill) was driven only by forecast *volatility* (CV). A *consistently* over-optimistic forecast — low CV but PV delivering only ~half of what was predicted — produced full confidence and no reserve, so the battery drained to 0% overnight and was forced into a thin-margin morning grid top-up. The reserve confidence now also folds in the bias-corrected delivery ratio (`refillConfidenceFromForecast` in `optimization-engine.js`): when PV under-delivers versus the forecast the DP actually uses, confidence drops proportionally and the floor engages. Over-delivery is upside and is ignored. Scales by SoC-span fraction, so 1–4 battery setups behave consistently. Unit tests in `test/refill-confidence.test.js`
### Explainability Tells You Why the Battery Holds Reserve (v3.15.97)
* **The decision reason now explains an overnight reserve hold** — When the refill-reserve floor holds charge back on a slot where the price would normally allow discharging, the explainability panel previously showed only the generic “DP gepland: bewaren”. It now shows a dedicated reason (“ Reserve aangehouden voor morgenochtend — PV-voorspelling onzeker …”) whenever the reserve is the reason discharge is withheld. New branch in `explainability-engine.js`, tests in `test/explainability-refill-reserve.test.js`
### Planning Chart Battery Power No Longer Shows Impossible Values (v3.15.97)
* **The planning table’s `Batt(W)` column is clamped to the hardware charge/discharge limit** — On the leading partial-hour row the per-slot SoC is stepwise (held per DP slot, then jumps), so dividing a full-slot SoC delta by a shorter collapsed group implied a charge power above the physical maximum (e.g. 1602 W on an 800 W unit). The optimizer itself always respects `maxChargePowerW`; this is a display-only clamp so the diagnostic never shows a physically impossible power
### Weak-PV Surplus No Longer Exported Before a Reachable Peak (v3.15.97)
* **A cloudy-afternoon slot with a small PV surplus now charges the battery instead of dumping it to the grid** — Observed live (2026-06-01 14:00): a strong ~2 kW PV surplus was exported (−1.7 kWh to grid) while the battery sat at 57% with room to spare and an evening price peak of €0.52 ahead. Cause: the PV-uncertainty/cloud haircut (`pvCloudFactor ≈ 0.60`) pushed the slot’s `pvCoverage` just under the `pvStrongCoverage` threshold (0.5), blocking the `pvStoreWins` path; simultaneously the next hour was a strong-PV slot, which resets `trickleSuffixMaxPrice` to 0 (the cap assumes that refill saturates the battery, making a later peak unreachable), blocking the `pvTrickle` path. With both blocked the slot fell through to `pvExportWins` and the surplus was exported — even though the uncapped store value (€0.374) beat the price (€0.25) and the battery never saturated (the plan peaked at 85%). `optimization-engine.js` now stores a weak-slot surplus when the battery still has room and the uncapped store value beats the price, treating the later peak as reachable. The trickle cap is unchanged for strong-PV slots, so genuine export-wins cases (a peak that PV truly refills) still export. Regression test `test/dp-pvstrong-cap-export.test.js`
* **The planning chart projected PV charging too low** — The chart’s SoC projection multiplied the PV-charge step by the round-trip efficiency (`rte ≈ 0.74`), so 1.6 kWh of PV into a 5.376 kWh battery drew as +22% instead of +30% of state-of-charge. Round-trip efficiency belongs in the *value* math (`storeValue = price × rte`), not in the SoC *state*: the battery physically gains the charged kWh. Every other projection path already tracked raw kWh — the grid-charge branch in the same function and the optimizer forward-sim in `optimization-engine.js` — so only the PV-charge branch was inconsistent. Removed the stray `* rte` in `buildPlanningSchedule` (`policy-engine.js`); display-only, no runtime decision effect
### Planning Chart Matches Real Export Decisions (v3.15.97)
* **The planning chart no longer projects the battery filling on slots the optimizer actually exports** — On variable/cloudy days the chart could show the battery charging up to full from PV while the live policy was exporting that surplus to the grid (plan ≠ reality). Cause: the chart’s SoC projection valued storing PV with the *uncapped* maximum future price, while the runtime mapper uses the *trickle-capped* store value — a far evening peak that tomorrow’s PV will refill anyway should not make storing today worthwhile. When a future peak sits beyond a strong-PV refill, the uncapped value over-stated storing and the chart drew a fill that never happened. Both projections (the optimizer forward-sim in `optimization-engine.js` and the re-mapper `_mapActionToHwModeForPlanning` in `policy-engine.js`, which drives the drawn SoC line) now gate PV charging on the same capped *store-beats-export* test the runtime uses: when exporting wins, the slot is shown as `standby` with a flat SoC. Verified live — `export more profitable → standby, no override`, `drift 0.0pp`
### PV Forecast Cap at Inverter Peak (v3.15.97)
* **PV forecast can no longer exceed the system’s physical peak** — On clear days where actual PV ran well above the morning model, the intraday correction ratio (e.g. ×2) multiplied the forecast above `pv_capacity_w`, producing impossible values (e.g. 5.8 kW on a 3.57 kWp system) on the “Batterij Vandaag” and “PV Opwek” charts — and, worse, made the DP over-estimate PV recharge (risking premature discharge stop). The blended/bias/intraday-corrected forecast is now capped at the inverter peak as the final step before the optimizer, the chart forecast line, and the stored hourly forecast consume it. Solcast values are additionally clamped at the source (`solcast-provider.js`), since a misconfigured Solcast resource capacity can report above the physical system limit
### EV Charging Gate (v3.15.94)
* **New flow action `Set EV charging state` (v3.15.94)** — Tell the policy engine when an electric vehicle starts or stops charging. While EV charging is active the battery is forced to `zero_charge_only` (`standby` when SoC ≥ max): the EV draws from grid and PV instead of cycling the home battery, but PV surplus may still top up the battery. The flag auto-clears after 8 hours as a safety net in case the “stop” trigger is missed, and is persisted to settings so it survives app restarts. Implemented as an early-return gate in `_mapPolicyToHwMode` so it overrides discharge for any policy mode (`balanced`, `eco`, `aggressive`, `balanced-dynamic`). Logged as `[MAPPING][EV]` for diagnostics
### Internationalisation (v3.15.94)
* **7 new languages added** — Driver compose, capabilities, flow cards, and locale strings now include German (de), Danish (da), French (fr), Swedish (sv), Norwegian (no), Finnish (fi), and Hungarian (hu)
### UI Text Fix (v3.15.94)
* **“Standby” spelling normalized** — `Stand-by` (with hyphen, including non-breaking hyphen variant) replaced by `Standby` in `driver.settings.compose.json` and `explainability-engine.js`
TCP ping socket-destroy on error path (v3.15.93) — tcpPing in both includes/legacy/homewizard.js and drivers/energy_socket/device.js previously closed the socket only on connect and timeout events, not on error. While Node usually auto-closes sockets on error, edge cases (e.g. EHOSTUNREACH with retained native references) could accumulate file descriptors over days. Error handler now calls socket.destroy() explicitly
SHARED_SOCKET_AGENT.maxSockets scales with device count (v3.15.93) — The shared HTTP agent for energy_socket devices was hard-capped at maxSockets: 4. With 15+ devices the agent became a bottleneck: failing devices held slots up to ~17s on the timeout/retry path, starving healthy devices. maxSockets is now set to max(4, ceil(deviceCount / 3)) on each device init (idempotent — last writer wins). A user with 19 energy sockets now gets 7 slots instead of 4
Recovery poller jitter (v3.15.93) — When multiple energy_socket devices go offline simultaneously (e.g. WiFi access-point hiccup), all their 10-second TCP-ping recovery pollers would fire in lockstep, producing a thundering herd on the AP during recovery. Each recovery poller now starts after a random 0-10s delay before its setInterval begins, spreading the load
EHOSTUNREACH / ENETUNREACH backoff (v3.15.93) — On hard network errors (host unreachable / route down), the device now skips polling for 60 seconds instead of retrying every 10s. The backoff is reset on successful poll or any discovery callback (available, address-changed, last-seen). Saves CPU and log noise when a device is genuinely offline
Open-Meteo retry on transient failures (v3.15.93) — weather-forecaster.js now uses fetchWithRetry for the three Open-Meteo endpoints (ensemble radiation, standard hourly, tilted irradiance). On TIMEOUT or 5xx response the request is retried once after 3s. Open-Meteo overloads at peak times occasionally caused stale weather cache for up to an hour; the retry catches most transient failures
Xadi price endpoints fetched in parallel (v3.15.93) — The Xadi provider previously fetched /today, /next24h, and /day/tomorrow sequentially (each with a 10s timeout, worst case ~30s). Now all three are fetched in parallel via Promise.allSettled, reducing worst case to ~10s. Deduplication via seenTimestamps Set is preserved
kWhPrice page-structure-change detection (v3.15.93) — When the kwhprice.eu HTML scraper returned 0 slots, the provider silently returned an empty array — even if the HTML was large (indicating the page loaded but the CSS selector no longer matched). The provider now throws an explicit “page structure may have changed” error when html.length > 2000 and 0 slots are parsed, engaging the stale-cache fallback and surfacing the issue in the logs
Drop [MEM][socket] init log spam (v3.15.93) — Each energy_socket device wrote two [MEM][socket] heap-stats log lines on init. With 19 devices that’s 38 noise lines per app restart with no operational value. Removed
Per-model GTI via solar transposition + KNMI kt bias classification (v3.15.83) — PV forecast accuracy per Open-Meteo model now uses Global Tilted Irradiance (GTI) computed via the Perez transposition model rather than GHI. This ensures the per-model radiation error is evaluated on the same tilted plane as the actual panel yield. Simultaneously, the daily radiation bias factor is now selected based on the KNMI clearness index (kt) rather than Open-Meteo cloud cover fraction — OM systematically over-estimates cloud cover (42% vs 15% measured), causing the wrong bias tier to be selected on partially-cloudy days
PV chart data key separated + kt-based bias apply + memory reduction (v3.15.84) — The PV chart now uses a dedicated data key independent of the forecast pipeline, preventing stale forecast values from persisting across recomputes. kt-based bias is applied earlier in the forecast chain so downstream models see the corrected irradiance. Internal forecast buffers reduced to lower heap usage during ensemble fetches
Chart midnight rollover fix + ensemble fetch timeout 10→15s (v3.15.85) — The planning chart camera image swapped tomorrow’s chart for today’s after midnight due to a day-boundary comparison error; fixed. The Open-Meteo ensemble fetch timeout was extended from 10s to 15s to reduce spurious timeout failures on slow upstream responses. Battery policy capabilities now expose projected profit, PV forecast, bias factor, and current DP plan summary as Homey capability values
Policy: fix policy_enabled permanently stuck after predictive interaction with restart (v3.15.87) — Two related bugs that left policy_enabled = false after HW Slim laden (predictive) ended: (1) Restart DURING predictive: _policyEnabledBeforePredictive was in-memory only and lost on restart; the restore guard (!== null) skipped the restore, blocking all policy runs until the next restart. Fixed: persist the value to settings at predictive-start; fall back to persisted value (then true) when restoring. (2) Restart AFTER predictive ended before restore ran: _isPredictiveMode was false on init, so neither the restore branch nor the P1 poll path fired; policy stayed disabled. Fixed: at startup, if policy_enabled_before_predictive is present in settings and the hardware is no longer in predictive mode, restore policy_enabled immediately. Both paths now trigger an immediate policy check on predictive end instead of waiting up to 15 minutes for the next slot boundary
Policy: min-price discharge override for DP preserve at night (v3.15.87) — The DP optimizer could choose preserve at night to protect opportunity value for next-day PV recharge, even when the current price exceeded the user’s configured minimum discharge price. This occurred when the SoC was near the PV absorption cliff: one discharge step would drop SoC below the refillable threshold, so the DP correctly valued the future state but violated the user’s price floor intent. Added a policy-layer override that forces discharge when DP says preserve, price ≥ configured minimum, SoC > min_soc, and no PV is active. Observed: 3-hour discharge gap at SoC 32%, price €0.268–0.281, minimum €0.180
Optimizer: smooth isolated preserve islands in discharge sequences (v3.15.86) — A single preserve slot flanked by discharge on both sides with a price delta below 1 ct is a DP numerical edge case (floating-point score tie at a local price minimum). Such slots are now overridden to discharge in a post-DP smoothing pass; projected SoC is propagated forward accordingly. Observed impact: one 15-min standby at €0.273 between €0.281 and €0.274 discharge slots
KNMI station ground-truth for model accuracy (v3.15.81) — PV forecast accuracy tracking now uses independent in-situ radiation measurements from the nearest KNMI automatic weather station (e.g. Cabauw) as the daily actual, instead of Open-Meteo’s own historical data. Open-Meteo used its own archived data as the “actual” reference, creating circular validation that could not detect systematic model bias. KNMI station data is fetched hourly via the EDR API and accumulated into a daily average used as ground-truth in the nightly learning step. Falls back to Open-Meteo if fewer than 4 daylight readings were collected or if no API key is configured. Requires a KNMI EDR API key configured in device settings (register at dataplatform.knmi.nl)
NOCT temperature derating for fallback PV forecast (v3.15.81) — The pre-learning fallback PV forecast (used before sufficient yield data has accumulated) now applies a thermal derating factor for high ambient temperatures. Silicon PV panels lose approximately 0.4%/°C above 25°C cell temperature; on hot summer days the flat-PR fallback overpredicted by up to 10%. The correction uses ambient temperature from the Open-Meteo forecast and the standard NOCT model. Panels with a learned yield factor already embed temperature effects empirically — correction applies only to the fallback path
P1 meter identify accepts empty response body (v3.15.82) — The P1 meter returns an empty HTTP body on /api/system/identify; the strict JSON object-type check caused a false “Invalid response format” error. HTTP status code alone is now used to detect failure
Solcast p10 cloud-aware selection (v3.15.80) — When Solcast’s pv_estimate (p50) exceeds the Open-Meteo NWP forecast by ≥10% for a given slot, the optimizer switches to pv_estimate10 (pessimistic 10th-percentile) for that slot. On clear days both models agree and p50 is used; on overcast days where Solcast’s satellite/ML lags a weather front, OM sees the cloud cover first and the p10 switch prevents over-reliance on PV that won’t arrive. Logged as p10=Xslots per day in [PV blend]
Cloud uncertainty discount in DP (v3.15.80) — When cloud cover exceeds 70%, pvCoverage in the DP forward and backward passes is discounted by up to 40% (factor 0.6–1.0). Prevents the optimizer from discharging at break-even prices early in the day by relying on uncertain PV recharge that may not materialise on overcast days. Shown in the PV bias line as ×0.87 (pv-onzekerheid) and logged as [PV cloud uncertainty]
Per-model OM radiation curves in PV accuracy chart (v3.15.80) — The PV forecast accuracy section now shows a second chart with individual Open-Meteo model curves (Météo-France ARPEGE, GFS, ICON, KNMI) alongside actual measured production. Per-model Watt estimates are recorded per 15-min accuracy sample and stored in pv_predictions. Per-model EMA accuracy scores are shown as pills once a full day of data has accumulated
Météo-France ARPEGE Europe replaces ECMWF IFS04 in ensemble blend (v3.15.80) — ECMWF IFS04 returned null shortwave_radiation for all hourly slots via the Open-Meteo ensemble endpoint and contributed nothing to the blend or accuracy tracking. Replaced with Météo-France ARPEGE Europe (10 km, West-European coverage), which provides full hourly radiation data. Accuracy prior set to 0.82
Battery Policy — Grid Top-Up Timing (v3.15.79)
Low-SoC top-up deferred to cheapest upcoming slot (v3.15.79) — lowSocGridTopUp now only fires when the current price is the minimum price in the next 8 hours. Previously, the top-up could trigger at any price below dynamicMaxChargePrice, causing premature grid charging when a cheaper DP-planned slot existed shortly ahead. With two batteries (1600 W charge rate), charging at a sub-optimal price erases the efficiency margin entirely
Diagnostics & PV Accuracy (v3.15.78)
Policy run debug: dynamicMaxChargePrice + lowSocGridTopUp (v3.15.78) — The policy_last_run_debug snapshot now stores dynamicMaxChargePrice (the effective charge price ceiling at the time of the run) and lowSocGridTopUp (whether the low-SoC grid top-up path was triggered). Both are shown in the diagnostic output. Previously, post-hoc diagnosis of unexpected to_full decisions was impossible because only the current dynamic max was available, not the value from the actual run
PV net surplus accuracy tracking (v3.15.78) — Learning engine now tracks predicted vs actual net PV surplus (PV minus consumption during solar hours). An EMA correction factor pv_net_surplus_factor [0.4–1.1] adjusts the terminal value calculation in the DP optimizer so next-day battery dispatch is planned on realistic rather than idealised surplus
Optimizer terminal value uses adjusted PV tomorrow (v3.15.78) — terminalPvKwhTomorrow passes the surplus-accuracy-corrected PV estimate to the DP forward pass, preventing the optimizer from over-discharging today when tomorrow’s PV was historically over-predicted
Battery Policy — Night Behaviour Fixes (v3.15.77)
Sunset guard broken after midnight weather refresh (v3.15.77) — After midnight, a weather cache refresh set todaySunset to the current day’s future sunset timestamp. Because the current time (e.g. 00:48 UTC) was before that sunset (19:30 UTC), _afterSunset evaluated to false, letting stale PV estimates (EMA still decaying) pass the guard and map preserve to zero_charge_only instead of standby. Fix: _afterSunset is now also true when the current time is before todaySunrise, covering the entire pre-dawn window regardless of which day’s sunset is cached
SoC staleness at policy run (v3.15.77) — battery_group_average_soc is updated by a 60-second interval; when the policy engine ran between updates it used a stale SoC, causing the DP to plan from the wrong starting point. Fix: _updateBatteryGroup() is now called immediately before _getBatteryState() on every policy run, refreshing the capability from live WS data
Event history battery power from WS (v3.15.77) — battW in event history entries now reads _lastPower directly from the plugin_battery WebSocket (seconds-fresh) instead of the 30s-stale battery_group_power_w capability. Falls back to the capability when no plugin_battery device is found
BMS calibration detection (v3.15.77) — Battery management systems occasionally run a calibration cycle: battery charges at full power but reports SoC=0% and power=0W. This caused event history entries to look like unexplained grid spikes. Policy engine now detects this signature (soc=0%, battW≈0, gridW>700W, nighttime, no charge/discharge mode commanded) and marks the entry exception: bms_calibration
Multi-source rain correction + ensemble averaging (v3.15.74) — Buienradar now samples 5 geographic points (center + N/S/E/W at ±0.05°) for more representative local precipitation. PV forecast now averages 4 Open-Meteo radiation models (ECMWF, GFS, ICON, KNMI Harmonie), with spread-adjusted weighting to reduce outlier influence
3-class daily PV bias stratification by cloud cover (v3.15.73) — Daily PV bias factor is now derived from three cloud-cover classes (clear/partial/overcast) rather than a single global correction, improving accuracy for mixed-sky days
Intraday PV scaling with winsorised ratios + CV dampening (v3.15.72) — Intraday reoptimisation scales the PV forecast to match morning actuals. Ratio samples are now winsorised (outlier-clipped) and dampened by their coefficient of variation, preventing a single cloudy-then-clear hour from over-correcting the full-day forecast
Clear-sky forecast floor (v3.15.63) — Intraday reopt now enforces a clear-sky model as a ceiling on per-slot PV corrections; slots cannot be scaled above theoretical maximum irradiance
Earlier Updates (v3.13–v3.15.58)
v3.15.40 — Negative price charging (to_full when price < 0); preserve→standby bij negatieve prijzen; slot0RemainingFrac fix; P1 firmware batteryPower=0 correctie
v3.15.37 — Yield-factor normalisation; Solcast moved to _updateWeather; cycle recorded on discharge→charge transition; predictive modes in camera
v3.15.35–36 — Startup crash fix (serialised settings write queue); SDM polling spread; memory log per device type
The power sensor from homewizard adds up to the total usage in homey energy. But the watcher should be the overall power usage. And all the other devices a slice of that. Now I have more usage then the watcher says.
Hi all, Homewizard app is not compatible yet with Homey 3.0. It was just released (final) and I have it installed today myself so I can start development/update on the Homewizard app to make it work properly with Homey 3.0.
That problem is related to your Homewizard wifi connectivity. I have no problems with the beta app myself (still running and getting Energylink data). Another one could be Homewizard and Energylink distance. Not sure how your units are placed and configured but it sounds like you have to check it first.
I noticed the same thing (before the beta version), but like Jeroen said it’s a Homewizard issue.
What i did , i connect Homewizard to a KAKU switch and connect the switch to Homey.
At 00:05 Homey checks with Energylink if the values are not greater then 1kwh.
If they are greater Homey switch the KAKU off and after 30 sec on , to reset Homewizard.
And the problem is fixed
Yes correct. Another problem what could cause this is if you have other integrations (domoticz or HASS etc) talking to your Homewizard unit. The Homewizard unit gets overloaded (high cpu or open connections) which eventually make the Homewizard unresponsive for a while. Not sure if you have other http gets getting data from Homewizard?
No I only use HomeWizard with Energylink at the moment. Maybe I’am switching tot Youless in the near future so I can switch off Homewizard. But for now I’am happy with your app and investigate the connection with Homey as you mention.
Latest Updates (v3.15.106–v3.16.0)
SoC drift detected` the instant charging began. Cause: the drift timer was anchored to when SoC *last changed*, which for an empty+idle battery was hours earlier overnight — so the “20 minutes stuck while charging” threshold was already satisfied before a single minute of real charging had elapsed. The detector now anchors to when *charging-while-stuck began* (new `computeChargeStuckAnchor` helper, reset whenever the battery is idle or SoC leaves 0%), so the delta measures sustained charging duration. A fresh `to_full` stays silent; a battery that genuinely won’t take charge for 20+ min still fires correctly, and the real BMS-calibration two-phase signature (75 W → 800 W) is unchanged. Regression tests in `test/battery-soc-drift.test.js`
Reserve aangehouden voor morgenochtend — PV-voorspelling onzeker …”) whenever the reserve is the reason discharge is withheld. New branch in `explainability-engine.js`, tests in `test/explainability-refill-reserve.test.js`
Full Changelog
