[APP][Pro] Homewizard 🧙‍♂️

Apps
, ,
1

Control your HomeWizard products (not the Link or Smart Switch.)

Stable: v3.15.3
Test/beta: v3.15.4

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).

image
image750×1167 71.2 KB

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:

  1. 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.

    565fd0827e1e53c061ec839ec0f9d397ddbba29d_2_230x500
    565fd0827e1e53c061ec839ec0f9d397ddbba29d_2_230x500230×500 27 KB

  2. Then you can add/pair your Plugin Battery (it is not really an order if battery is first or last, it is just key that the P1 is added as APIv2).

    323b5c1f2524f99b3e0f668f9d286f5dca15dd64_2_302x500
    323b5c1f2524f99b3e0f668f9d286f5dca15dd64_2_302x500302×500 21.4 KB

  3. After this you can add a flow and control the mode of the Plugin Battery via the P1apiv2.

TROUBLESHOOT TIPS FOR P1, KWH (SDM230/SDM630), WATERMETER, ENERGY-SOCKETS AND PLUGIN-BATTERY

  • Check de logs in the app settings (version v3.10.x)

image
image458×500 43.8 KB

  • Make sure Homey is in the same (wifi network)
  • 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.

IMG_0069
IMG_00691088×1411 107 KB

TIPS

  • 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)

small

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!)

image
image321×568 14.3 KB

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).

Relevant sources and links
Project master source: GitHub - jtebbens/com.homewizard: Homewizard app for Homey · GitHub
Beta channel: https://github.com/jtebbens/com.homewizard/tree/beta
Test install from app store: HomeWizard | Homey

ONLY SENT DIAGNOSTIC REPORTS WHEN I ASK FOR IT

Developers: Jeroen Tebbens, Jeroen Bos, Nick Bockmeulen, Freddie Welvering, Emile

7 Likes
2

:memo: Latest Updates (v3.15.3)

Battery Policy — Multi-Battery Discharge Fix

  • Discharge power capped at 800 W - HW firmware limits discharge (max_production_w) to 800 W regardless of battery count (charge scales linearly, discharge does not). The fallback calculation incorrectly assumed unitCount × 800 W, causing 3-battery setups to report “capaciteit: 2400W” in explainability text while actual discharge was locked at 800 W. Fixed in policy-engine, explainability-engine, and device _getBatteryState() fallback. If the max_production_w and max_consumption_w are properly set (eg. 1600w) that value will be used.

  • WebSocket capability guard - max_consumption_w and max_production_w are now only updated when actually present in the WS payload (typeof === 'number'). Previously, missing fields were written as 0, which caused the ?? fallback to pass through 0 instead of triggering the corrected 800 W fallback

  • Confidence rounding - Learning-adjusted confidence now uses Math.round() after adjustment, preventing 14-decimal-place values (e.g. 99.33326922747905) in timeline entries and flow tokens

Battery Policy — Learning Engine

  • 15-minute consumption resolution - Consumption patterns upgraded from hourly (7 × 24 = 168 slots) to 15-minute (7 × 24 × 4 = 672 slots). Includes automatic migration from old hourly format, spreading existing averages evenly across quarter slots

  • Amsterdam timezone fix - All consumption recording now uses _getAmsterdamTime() (via toLocaleString with Europe/Amsterdam timezone) instead of getHours() which returns UTC on Homey. One-time reset migration clears old UTC-indexed data; re-learning takes ~24–48h

  • Daily profile export - New getDailyProfile(dayOfWeek) method returns 96 slots with predicted wattage, enabling per-day consumption charts in the settings UI

Battery Policy — Expansion Analysis (new)

  • What-if battery comparison - New computeExpectedProfit() method on OptimizationEngine runs the DP for 1–4 battery scenarios without modifying the live schedule. Shows marginal daily/yearly profit per additional battery, power bottleneck slots where house consumption exceeds discharge capacity, and payback period based on configurable investment cost

  • Settings tab “Uitbreiding” - New tab visualises expansion scenarios with per-unit profit cards, shortfall indicators, and user-adjustable battery price input

Battery Policy — Consumption Profile Chart (new)

  • Learned consumption chart - New chart in the planning tab renders the learned 15-min consumption profile per day-of-week. Features day selector (Ma–Zo), peak detection with top-3 labels, colour-coded bars (green → yellow → red), and current-slot highlight. Updates hourly via policy_consumption_profile setting

Optimizer Engine — Refactoring

  • Pure DP kernel - Backward induction extracted into _runBackwardDP() — a fully side-effect-free method returning {dp, policy, ...}. Forward pass remains in compute(). Enables computeExpectedProfit() to reuse the same DP logic without touching _schedule

  • Projected profit tracking - _schedule now includes projectedProfit (€) from the DP value function at current SoC, used by expansion analysis

Previous Updates (v3.14.29+)

Battery Policy — Optimizer & Scheduling

  • DP discharge allowed during PV hours - Removed the pvCoverage > 0.5 discharge block from the optimizer’s backward induction. During delay-charge hours the battery correctly discharges to cover house load while PV exports to the grid; the old block suppressed this and left ~1 kWh/day of discharge revenue uncollected (battery entered the solar morning at 30–40% SoC instead of min_soc). The minDischargePrice floor already prevents irrational low-price PV-hour discharge

  • Slot-boundary alignment - Policy check interval now aligns to the next UTC 15-minute boundary (:00, :15, :30, :45) on startup instead of running at an arbitrary offset. Without alignment the interval drifted ~11 min into each EPEX slot, leaving only ~4 min of discharge per slot

Battery Policy — PV Detection

  • Virtual grid power fix - virtualGridPower = gridPower − batteryPower is now always applied (both when charging and discharging). The old code used raw gridPower when discharging, causing battery over-discharge (e.g. −337 W) to create apparent grid export (−220 W) and falsely trigger PV-ON at 06:51 before sunrise

  • PeakTiming PV free-cycle bypass - PeakTiming discharge suppression is now skipped when pvKwhRemaining ≥ storedKwh. When remaining PV today can cover what’s currently stored, recharging is free and the RTE cost threshold is irrelevant. Re-engages in the evening when PV is nearly exhausted. Prevents the battery from staying half-full all morning because PeakTiming assumed grid recharge cost

:memo: Previous Updates (v3.14.24+)

Battery Policy — Planning & Optimizer

  • Discharge SoC projection now consumption-aware - zero_discharge_only keeps grid at ~0W by matching discharge to actual house consumption (variable 0–800W), not fixed max discharge power. Planning chart SoC curve now reflects real depletion speed based on learned consumption per slot

  • Discharge floor consistent between DP and display - Optimizer now enforces min_discharge_price as a hard constraint in backward induction; eliminates the bug where planning showed “standby” but SoC dropped (DP had internally discharged below the threshold)

  • Opportunistic discharge in dynamic mode - When respect_minmax is disabled, the DP uses opportunistic_discharge_floor (default €0.20) instead of min_discharge_price, consistent with the policy engine’s opportunistic logic. Planning display matches

  • Pre-peak urgent charging - When an expensive hour is ≤30 min away and SoC is below target, policy switches to to_full even when PV is producing (≥400W), ensuring the battery fills in time

Battery Policy — Weather & PV

  • Lat/lon location fields - Weather location now uses separate latitude/longitude number fields instead of a city name text field. Existing city names are automatically migrated on first startup

  • Forecast blending - New weather fetch is blended with the previous cache (α=0.6) to smooth sudden Open-Meteo model-run jumps; prevents PV forecast from jumping between runs

  • Weather refresh interval - Cache refresh now uses the existing weather_update_interval setting (default 3h, min 1h) instead of a hardcoded 3-hour interval

Battery Policy — Scoring

  • PV overschot score rebalanced - Score reduced from +1000 to +250 to keep all scores in the readable 20–300 range; still dominates preserve but no longer produces scores like 1170

Bug Fixes

  • battery_group_charge_mode capability missing - Self-healing guard added: if the capability is absent when a battery event arrives, it is re-added before setCapabilityValue() is called, preventing repeated “Invalid Capability” errors

  • BaseloadMonitor false oscillation - _detectOscillation() now trims 1 outlier from each end before computing the range; a single bad sample from battery mode-transition measurement lag no longer invalidates an otherwise clean night

  • BaseloadMonitor energy_v2 - Battery power sourced from plugin_battery (accurate) instead of the P1 payload.power_w field (unreliable when firmware doesn’t report battery state)

  • Settings crash on PV/weather change - homey.settings.unset() is synchronous; removed erroneous .catch() call that crashed when settings were changed

:memo: Previous Updates (v3.14.19)

Battery Policy — Planning & Intelligence

  • Single source of truth - Planning view now reads directly from the optimizer schedule; no duplicate policy logic in the frontend

  • Accurate SoC projection - Forward pass now reflects PV-assisted charging during preserve slots (firmware runs zero_charge_only when PV is available)

  • Solar yield learning - Per-slot yield factors (W per W/m²) learned from actual PV measurements, absorbing panel capacity, orientation, PR and shading into one number. Approach inspired by de Gruijter’s app “Power by the Hour”

  • Weekend/weekday consumption patterns - Learning engine distinguishes weekday vs weekend consumption; falls back to group average until enough per-day samples accumulate

  • Consumption-aware planning - Optimizer uses learned consumption forecasts per slot; discharge offsetting local consumption is valued at full retail price vs 30% for export

  • Battery cycle cost - Configurable degradation cost (€/kWh discharged); optimizer only cycles the battery when the price spread exceeds the cycle cost, preventing unprofitable small arbitrage rounds

:memo: Previous Updates (v3.14.1)

Battery Policy — 15-Minute Pricing

  • 15-min price granularity - Policy decisions now use the actual 15-minute spot price instead of the hourly average, enabling more precise charge/discharge timing during short price dips or peaks

  • Optimizer on 15-min slots - The 24h dynamic-programming scheduler now plans across 96 slots (15-min) instead of 24 hourly slots, making it possible to exploit short cheap windows (e.g. wind surplus at night)

Battery Policy — Explainability

  • Reasons match the winning mode - Decision reasons are now filtered to only show why the actual recommendation was made; conflicting reasons from other modes no longer appear

  • Mapping explanation - When scoring favours charging but conditions prevent it (price above ceiling, no PV), a prominent notice now explains the gap: “Laden wint (score 140) maar prijs €0.26 > max laadprijs €0.14 → Standby: wacht op betere conditie”

  • Battery very low reason - SoC between 1–10% now correctly shows “Batterij erg laag — laden aanbevolen” instead of “normaal bereik”

  • Zero mode threshold - Explainability engine now mirrors policy engine exactly: respects min_soc = 0 without a hardcoded 1% floor

Bug Fixes

  • Weather forecast timezone - Fixed 1-hour offset caused by timezone: auto + appending Z; now uses timezone: UTC

  • Sunshine duration ensemble - Fixed all-zero sunshine when using multi-model Open-Meteo requests (models= parameter causes model-specific key names like sunshine_duration_ecmwf_ifs04; plain key absent)

  • Sunshine radiation fix - Fixed radiation calculation which made the planning be mapped incorrectly

  • Planning SoC projection - Fixed all hours showing standby due to early return if (soc < minSoc) return 'standby' in planning display; radiation-based PV formula corrected (pvCapW × radiation/1000 instead of maxChgW × factor)

  • ZERO MODE threshold - Policy engine and explainability now both respect user’s min_soc setting; removed hardcoded 5% / 1% floors

Technical

  • 36-hour forecast horizon - Weather forecaster extended from 24h to 36h to always cover tonight + full tomorrow even when run in the evening

  • SunMultiSource removed - Replaced with WeatherForecaster ensemble (3-model average); next-4h radiation used for PV estimation

:memo: Previous Updates (v3.13.58)

Bug Fixes

  • Baseload Negative Values - Fixed BaseloadMonitor._fallback() including negative power samples in bottom-10% calculation, which caused the baseload (sluipverbruik) to report negative values; now filters to p >= 0 && p < 1000 W (consistent with _computeSmartBaseload)

  • Baseload Battery Correction - Fixed updatePower() only correcting for battery discharge (batteryPower < 0) but not for charging; now applies householdPower = gridPower − batteryPower for both directions; result clamped to 0 to prevent negative household consumption from rounding/timing mismatches

  • RTE Learning — Counter Reset Bug - Fixed efficiency estimator resetting both charge and discharge counters when measured RTE < 0.50; a low ratio simply means the cycle is not complete yet (not enough discharge accumulated relative to charge); counters now preserved and continue accumulating; only reset on confirmed measurement error (RTE > 0.85) or stale counters (> 10 kWh either side)

  • RTE Learning — SoC Null Guard - Fixed soc <= 5 orphan-clear guard in EfficiencyEstimator firing on every charge start because null <= 5 is true in JavaScript; guard now requires typeof soc === 'number'

  • RTE Learning — Wrong SoC Source - Fixed battery-policy/device.js reading measure_battery capability (does not exist on the policy device → always null) instead of the soc variable already resolved from battery_group_average_soc on the P1 device

  • Battery Policy bugs - Fixed Recommended mode text to active mode, leftover battery SoC in morning to discharge. Fix for to_full when PV is not enough to charge battery but the market prices are at their lowest (zero_change_only vs to_full)

  • Ratelimit on flowcards in energy (apiv2) - Ratelimit to avoid action flowcard to execute every second crippling the application and make it cpu/memory crash

  • Energy socket connectivity - Improve connectivity when there is poor wifi (10s timeouts, was 5s) and retry logic

Technical

  • WebSocket slow_handler threshold raised from 100 ms to 250 ms to better reflect ARM CPU reality on Homey; journal entries throttled to once per handler per 5 minutes to prevent log noise

  • WebSocket preflight_fail journal events throttled to once per 10 minutes via _journalThrottled(); log output still emitted on every failure for debugging

  • Settings page copy button — navigator.clipboard.writeText() silently fails inside Homey’s sandboxed iframe; now always uses textarea + execCommand('copy') as primary path; if that also fails a selectable textarea is shown as manual fallback

:memo: Previous Updates (v3.13.54)

Bug Fixes

  • Baseload Negative Values - Fixed BaseloadMonitor._fallback() including negative power samples in bottom-10% calculation, which caused the baseload (sluipverbruik) to report negative values; now filters to p >= 0 && p < 1000 W (consistent with _computeSmartBaseload)

  • Baseload Battery Correction - Fixed updatePower() only correcting for battery discharge (batteryPower < 0) but not for charging; now applies householdPower = gridPower − batteryPower for both directions; result clamped to 0 to prevent negative household consumption from rounding/timing mismatches

  • RTE Learning — Counter Reset Bug - Fixed efficiency estimator resetting both charge and discharge counters when measured RTE < 0.50; a low ratio simply means the cycle is not complete yet (not enough discharge accumulated relative to charge); counters now preserved and continue accumulating; only reset on confirmed measurement error (RTE > 0.85) or stale counters (> 10 kWh either side)

  • RTE Learning — SoC Null Guard - Fixed soc <= 5 orphan-clear guard in EfficiencyEstimator firing on every charge start because null <= 5 is true in JavaScript; guard now requires typeof soc === 'number'

  • RTE Learning — Wrong SoC Source - Fixed battery-policy/device.js reading measure_battery capability (does not exist on the policy device → always null) instead of the soc variable already resolved from battery_group_average_soc on the P1 device

Technical

  • WebSocket slow_handler threshold raised from 100 ms to 250 ms to better reflect ARM CPU reality on Homey; journal entries throttled to once per handler per 5 minutes to prevent log noise

  • WebSocket preflight_fail journal events throttled to once per 10 minutes via _journalThrottled(); log output still emitted on every failure for debugging

  • Settings page copy button — navigator.clipboard.writeText() silently fails inside Homey’s sandboxed iframe; now always uses textarea + execCommand('copy') as primary path; if that also fails a selectable textarea is shown as manual fallback

:memo: Previous Updates (v3.13.47)

New Features

  • Active Mode Capability - New active_mode capability shows the battery mode actually active on the hardware, which may differ from recommended_mode when confidence is below threshold, auto-apply is off, or a manual override is active
  • New Policy Modes - Added Fixed Pricing and Dynamic Pricing (V2) options to the policy mode picker
  • Global Error Handlers - App now catches unhandled promise rejections, uncaught exceptions, and Node.js process warnings (MaxListenersExceededWarning etc.) for better crash diagnostics

Bug Fixes

  • Coverage Ratio Calculation - Fixed inverted battery coverage ratio: a 1751 W load with 800 W max now correctly reports 46% coverage instead of 100%
  • Multi-Unit Battery Power - Max discharge/charge fallback now scales with battery group size (2.7 kWh/unit × 800 W/unit) instead of hardcoding 800 W regardless of how many units are installed
  • PV Virtual Grid Calculation - Fixed virtual grid calculation: battery charging power is now subtracted (not added) to correctly show true export potential when evaluating PV decisions
  • WebSocket Null Guards - Fixed crashes when ws._events is accessed after the socket is already cleaned up; removeAllListeners and event dispatch now guard against null ws reference
  • Cost Model Reset - Battery cost model now resets at or below min_soc even when firmware cuts discharge power to 0 W (no longer waits for isDischarging to be true)
  • Sensor/History Overflow - LearningEngine now uses exponential moving average (alpha=0.01) after 100 samples per slot, preventing sum and count from growing unboundedly over years

Performance (CPU)

  • WebSocket Throttle - Measurements now processed immediately on receive with a 2 s throttle, replacing the previous fixed polling interval; system/battery topics reduced to 30 s (was 10 s)
  • energy_v2 Tiered Updates - Capability updates split into realtime / 10 s / 30 s / 60 s tiers; voltage, current, and frequency no longer updated on every WebSocket message
  • energy_v2 Battery Group - Battery group interval reduced from 10 s to 60 s
  • energy_v2 Flow Triggers - energy_import_kwh flow trigger rate-limited to 60 s (was 5 s), preventing 12 triggers/min per device
  • energy_socket Polling - Minimum poll interval raised to 30 s (was 2 s); startup offset staggered 5–35 s; TCP keep-alive extended to 35 s to match interval
  • plugin_battery Startup Stagger - First poll staggered 0–30 s per device to prevent 3 simultaneous TLS handshakes at startup
  • plugin_battery Battery Group - Battery group interval reduced from 10 s to 60 s
  • plugin_battery Capability Batching - All capability updates in _handleMeasurement are now batched with Promise.allSettled (non-blocking) instead of sequential await
  • Baseload Throttle - BaseloadMonitor._processNightSample stores at most 1 sample per 30 s; _detectNearZeroLong is now time-based instead of sample-count-based; night history downsampled to 30 s resolution on save
  • Battery Policy P1 Polling - P1 capability polling interval increased from 5 s to 15 s

Technical

  • onUninit / onDeleted split across all drivers (energy_v2, energy_socket, plugin_battery, cloud_p1, battery-policy): timers/intervals cleaned up on both app stops and explicit device deletion; baseload deregistration and settings wipe only on deletion
  • __deleted guard added to onPoll, _fallbackPoll, _updateBatteryGroup, and _handleMeasurement to prevent errors after uninit
  • PV state detection uses separate hysteresis thresholds for ON (−200 W) vs OFF (−150 W) to prevent bouncing; grid range widened to −150…+250 W when already in PV state
  • active_mode updated after every policy run to reflect the actual battery_group_charge_mode capability value from the P1 device; battery_policy_state.currentMode patched to match for accurate SoC projection
  • RTE learning bounds enforced (50–85%); values outside this range fall back to the configured setting and trigger an estimator reset; learning threshold lowered to 1.0 kWh per side (was 2.5 kWh) for faster convergence
  • EfficiencyEstimator.reset(eff) method added
  • Explainability engine: soc=0 reason now mirrors policy-engine export-wins analysis; arbitrage reason now shows when price is above break-even but blocked by min_discharge_price; PV surplus reason mirrors PV OVERSCHOT opportunity-cost logic
  • Coverage ratio formula corrected to min(maxDischarge / load, 1.0) in PolicyEngine, _applyPeakShavingRules, and ExplainabilityEngine
  • Battery group max power fallback derived from battery_group_total_capacity_kwh in device, policy engine, and explainability engine

:open_book: Full Changelog

Click to expand complete version history
1 Like
3

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.

For example

image
57F5CEFC-1B53-4603-A68E-7D8EF589CEDC.jpg1125×2436 308 KB

650 should be the bottom value. (Total usage)

4

I don’t even see Energie (HomeWizard)

5

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.

6

Thanks for the quick reply! If you need any info let me know. I will wait until the next release

7

Thanks!

8

Beta release (pending) Energylink is now detected as overall measure (Smart Meter/Slimme Meter).
To use this you have to pair your Energylink again.

image
image.jpg510×902 103 KB

9

:+1:

10

Ok beta version is approved so you guys can play with it.

11

Thanks! The p1 energy is added to the energy measured in the zones so the total energy is not correct.

12

Please explain. Don’t understand.

13

After I log out and in (app) everything looks fine.

14

Ok

15

After a wile the Engerylink values won’t update anymore. Resetting the app does not resolve the problem.

16

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.

17

Mmm strange, never noticed that problem before…

18

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 :grinning:

19

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?

20

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.