growat in homewizard#5
Open
Wouwmw wants to merge 1151 commits into
Open
Conversation
Changelog: Baseload fix for energy_v2 (notification tag added), PV Graph planning adjusted, added green line with actual Watts production vs estimate
Changelog: Baseload fix (oscillation), Changed city looking for weather to long lat method instead
Changelog: Cheap tariff fix when battery is not full but pv cant cover it
Changelog: Balance-dynamic mapping fix, discharge price adjustment
Changelog: More planning tariff tuning
Changelog: Use household usage to calculate discharge policy. Added diagnostic caption to easier support remote problems.
Changelog: Added zero mode during PV surplus and certain tariffs with less margin to profit (ie 0.01 profit)
Changelog: Energy-socket http agent adjustments, battery-policy explainability reasoning improvements
…morrow on the battery-policy device as "webcam"
Changelog: Slot boundary alignment, virtual grid power fix, peaktiming PV free-cycle bypass, DP discharge allowed during PV hours
Changelog: Webcam fix tomorrow battery policy, image might not update till afternoon prices are available
Changelog: Cheapest hour fix diring night while 12 hours later are cheaper
Changelog: Refractor 15min timeslots for learning household usage, solar and forecasting.
Changelog: Household usage fix
Changelog: Ignore open-meteo pv estimate outside sunrise-sunset, fallback open-meteo bad gateway, use cached data when more than 24 hours.
Changelog: Widget light and dark added
Changelog: Lowered factor from 0.8 to 0.6 for policy engine to fully discharge during night
- Ensemble fetch adds diffuse_radiation + direct_normal_irradiance per model - WeatherForecaster._solarElevAz + _computeGTI compute real tilted irradiance per model using isotropic sky transposition (replaces GHI scaling workaround) - GHI=null fallback: past slots where OM omits GHI still compute GTI from DNI+DHI - Solar azimuth uses atan2 (correct quadrant); acos+sign-flip was wrong - KNMI clearness index (kt = actual_GHI / clear_sky_GHI) replaces OM cloud% for daily bias EMA classification — OM systematically over-predicts cloud cover - isClear threshold 40% → 20% as fallback when KNMI data unavailable - Intraday scaling ratio corrected: meanRatio/biasCorrFactor (was 1+(x-1)/bias) - Settings: DP history shows day+month in timestamps; PV tomorrow shows clear-sky reference and flat-battery threshold Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- learning_pv_chart_data: split pvPredictions/modelAcc out of learning_status so _updateWeather (hourly) no longer overwrites chart data with empty payload - getDailyPvBiasFactor: use KNMI kt for clear/overcast classification, matching recordDailyPvBiasFromPredictions — fixes record/apply mismatch that caused mixed EMA (1.335) to be used on clear days instead of pv_daily_bias_clear - _computeKnmiKt: extract shared helper; compute today's partial kt after each KNMI fetch and expose via getTodayKt() for policy to consume - _lastEnsembleData: null after _learnFromYesterday to free raw API response - forecast_days: 3→2 across all three OM fetches (optimizer horizon is 48h) - _settingsFootprintKB: fix getAll() → enumerate known keys via settings.get() Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…le timeout 10→15s P1 poll now detects Amsterdam date change and swaps _chartTomorrow → _chartToday with image.update(), preventing stale yesterday chart during overnight predictive (SlimLaden) pause when _updatePlanningChart is never called. Ensemble Open-Meteo fetch timeout raised from 10s to 15s; was timing out ~3x/day with fallback to standard shortwave_radiation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ilities Enables live troubleshooting via Homey skill/MCP without log access. - policy_profit_eur: optimizer projected daily profit - pv_forecast_kwh: blended OM+Solcast forecast for today - bias_factor: intraday PV correction ratio (actual/forecast) - plan_summary: compact slot count "0↑ 6↓ 9=" Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Single preserve slot flanked by discharge on both sides with price delta <1ct is a DP numerical edge case. Override to discharge and propagate SoC. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Changelog: open meteo now takes solar orientation, planning fix with 15min slot issue affecting battery mode
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
_lastEnsembleData was kept as an instance property, holding the full Open-Meteo ensemble JSON (~3 MB) permanently in old-space. Moving perModelGhiAvgToday extraction into _mergeApiResponses lets the local ensembleData variable go out of scope immediately after the merge, allowing V8 to GC it. Measured: heap drops from 21.6 MB back to 18.9 MB after each fetch cycle. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Model accuracy blending now uses rank weights [4,3,2,1] instead of proportional accuracy scores. More robust to single bad days where one model gets a large relative error that drowns out the others. - Skip accuracy update on overcast days (actual GHI < 150 W/m²): low absolute radiation means noise dominates relative error, so those days carry no useful signal about model skill. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Price refresh was skipped entirely when HW Smart Charging (predictive mode) was active. kwhprice.eu publishes tomorrow's prices at ~13:15–15:00 CEST; if the app started before that window, prices were never re-fetched and tomorrow's slots stayed missing all day. Now fetches prices on every tick regardless of predictive mode; skips only the optimizer/policy run and weather refresh (which write battery modes and would conflict with HW's own control). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…erage in planning Three bugs fixed: 1. policy_enabled stuck false after restart DURING predictive: in-memory _policyEnabledBeforePredictive was lost; restore guard (!== null) skipped. Fixed: persist to settings at predictive-start; restore path reads settings as fallback (then defaults true). Immediate _runPolicyCheck on predictive end. 2. policy_enabled stuck false after restart AFTER predictive ended (before restore ran): _isPredictiveMode was false on init so neither branch fired. Fixed: on startup in _connectP1Device, if policy_enabled_before_predictive is in settings and hardware is no longer predictive, restore immediately. 3. pvCoverage not shown in planning diagnostic: forward pass now stores pvCoverage per slot; buildPlanningSchedule propagates it; settings/index.html renders pvcov column. Min-price discharge override uses slotMeta.pvCoverage < 0.05 threshold (not live PV sensor) to avoid suppressing override on overcast days. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The current slot skipped the scheduleMap lookup via `continue`, leaving pvCoverage, pvW, consumptionW, sampleCount and reason blank. Fixed by loading scheduleMap data first, then overriding hwMode/policyMode/soc with live policyState values. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Changelog: Policy fix night time discharge got blocked
…ttings - Skip startup mode-restore when policy_enabled=false or auto_apply=false, so user's manual battery mode survives an app restart - Fix setBatteryGroupMode to sync the advanced-settings 'mode' field after applying a programmatic mode change (was stale due to cache read-after-write) - Fix dead flow-trigger code in setBatteryGroupMode (prev read after cache was already overwritten with normalized) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Changelog: Bugfix P1 stale mode state.
Changelog: Bugfix, battery groups also patched
Previous fix checked policy_enabled/auto_apply which didn't help when both are true (the default). Real guard: only restore from history when the battery is at firmware default (zero_charge_only). If the persisted capability shows any other mode (e.g. zero/NOM), the user set it intentionally — don't overwrite. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
No reliable way to distinguish firmware default from user/policy-set mode. Restoring from policy_mode_history on startup overwrote manual changes made just before an update (e.g. user sets NOM, policy maps to zero_charge_only, update fires, history had predictive → wrong mode restored). Policy runs at T+45s and applies the correct mode. The brief gap is acceptable. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Changelog: Bugfix battery mode
Use battery_group_charge_mode capability as source of truth for the mode advanced-setting at startup. Capability is Homey-persisted and has no write-lag race unlike policy_mode_history. No hardware command sent — only the settings panel is updated if it was stale. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Changelog: P1 as source of truth after app restart
auto_apply=false is a valid user choice. The force-to-true was silently re-enabling policy application on every restart/update, overriding the user's explicit setting and causing unwanted mode changes. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
policy_mode capability has an 'off' value but it was never checked. Policy would run and apply mode changes regardless. Now guards early in _runPolicyCheck, same as the policy_enabled check. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…t to off When policy_mode switches to 'off', hardware stayed in last policy-applied mode (e.g. zero_charge_only) instead of returning to the user's configured mode from the energy_v2 settings panel. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Changelog: Forced early exit policy mode off checks
…-detect - legacy + energy_socket: tcpPing error handler now destroys socket to avoid native FD leak on error paths (EHOSTUNREACH etc.) - energy_socket: SHARED_SOCKET_AGENT.maxSockets scales with deviceCount (max(4, ceil(n/3))) so 19-device users get 7 slots instead of 4 - energy_socket: recovery poller starts with 0-10s random jitter to prevent thundering herd on AP when multiple devices recover simultaneously - energy_socket: 60s skip-poll backoff on EHOSTUNREACH/ENETUNREACH; reset on success or discovery callbacks - energy_socket: drop [MEM][socket] init log spam (38 lines per restart) - weather-forecaster: fetchWithRetry helper — 1× retry after 3s on TIMEOUT or 5xx, applied to ensemble/standard/tilted Open-Meteo fetches - xadi-provider: /today, /next24h, /day/tomorrow fetched in parallel via Promise.allSettled (~10s worst case instead of ~30s sequential) - kwhprice-provider: throw on HTML>2kB but 0 slots parsed (detects page structure change, engages stale-cache fallback instead of returning []) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Document connectivity, memory, and provider-reliability fixes: TCP ping socket destroy, dynamic maxSockets, recovery jitter, EHOSTUNREACH backoff, Open-Meteo retry, Xadi parallel fetch, kWhPrice page-structure detection. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Changelog: Energy socket tuning, memory improvements, tcp connect check to Homewizard legacy as fallback
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since this year it is possible to get the information of a growat sun system to homewizard app it self. But could it be to get the data in the homewizard app of homey. In homewizard you need a plus account.