Adax with Power Estimation

Adax with Power Estimation for Homey Adax with Power Estimation connects Adax WiFi panel heaters and thermostats to Homey through the Adax Cloud API. The app is built for Homey users who want better control, estimated power in watts, and more useful energy data than the official integration normally provides. The app can be used in parallel with the Adax mobile app, but not in parallel with Adax's official Homey app. This is an unofficial community app developed by me as a private individual, without affiliation, approval, or any formal connection to Adax. The app is not a commercial product, and I do not earn money from it. Important before you start In practice, this app imports Adax rooms, not necessarily individual physical heaters. Each Homey device you add will therefore normally represent one room in Adax. The Adax API is largely room-centric. If you have multiple panel heaters in the same Adax room, control, status, and energy data will often be treated together on room level. If you want to control two heaters differently, each heater should therefore live in its own Adax room. For example: - Panel Heater Living Room North - Panel Heater Living Room South It is also a good idea to use the same names both as room names in Adax and as device names in Homey, so it stays clear which heater is which. If multiple heaters are placed in the same Adax room, you should expect that they cannot be separated cleanly in this app when it comes to control, status, and energy data. Setup and migration If you already use the official Adax Homey app, you should remove the device there first. The cleanest migration path is normally: 1. Remove the device from the official Adax Homey app. 2. If necessary, remove the device from the Adax mobile app, reset it, and add it again in the Adax mobile app so it can still be controlled there. 3. In the Adax mobile app, go to Account and open the section for third-party integration / external API. 4. Create a new API password and note the generated password. 5. Go back to the account page in the Adax app and note your account ID. 6. Install Adax with Power Estimation in Homey. 7. Open Configure for Adax with Power Estimation in Homey and save the Adax account ID and API password once. 8. Then add new Adax devices in Homey and choose the rooms you want to import. Once the account is saved in the app, new heaters will reuse those credentials automatically during pairing. Cloud fetching is shared per Adax account, so all devices on the same account reuse the same account data instead of polling separately. Temperature sources Each heater can be configured with its own temperature source in the device settings: - Adax internal uses the temperature reported by Adax in the normal way. - External via Flow lets you feed in temperature from another Homey sensor through a dedicated Flow card. This makes it possible to use a separate room sensor as the temperature basis for each heater. A typical setup is: 1. Select External via Flow on the heater. 2. Set the desired maximum age for external temperature in minutes. 3. Create a Flow that updates the heater when another temperature sensor changes, for example: - When sensor X updates - Then: Set external temperature for the selected Adax heater to the sensor value If the external temperature becomes older than the configured maximum age, the app automatically falls back to Adax's internal temperature for that heater. The external temperature is used in Homey for presentation and the app's local logic. It is not sent into Adax Cloud as a real measured room temperature. Power and energy Many Adax WiFi devices do not expose real watt measurements through the public API. Power values in Homey are therefore estimated. The app uses available room state, local logic, and cloud data from Adax to provide a practical power estimate in watts that works well for load control, Flows, and power-tariff awareness. Nominal watt is set to 1000 W by default. If your heater has a different nominal power rating, this must be changed manually in the device settings in Homey. This value is not synced from the Adax app. Energy history uses a hybrid model. The app combines local energy accumulation based on estimated power with cloud corrections from Adax whenever such data is available. The result is normally a better estimate of accumulated energy usage than local polling alone, while Homey still keeps live energy values moving between cloud reconciliations. Cloud energy replaces estimates for the same explicit time interval. Past-hour withEnergy windows are accepted only without overlap; completed energy_log periods can replace them later, including daily periods and downward revisions. When energy_log returns HTTP 502, local estimates and non-overlapping withEnergy windows continue, with per-room status and last-success/data timestamps in device settings. The 0.3.52 work-in-progress reconciles explicit cloud periods into internal history and reflects corrections in the public meter, including decreases. Eligible historical overcounting can also be repaired as described below. This draft has not been published; see the audit in project memory. Each heater can also show an extra consumption value in Homey, independent of the normal total energy counter. By default it shows consumption today, and in device settings you can change this to last hour, last 24 hours, this month, this year, or total logged in the app. The extra display also includes which period is being shown directly in the value text. The same periods can be used in Flows for comparisons and automations. Limitations This integration uses Adax's public REST API and inherits the limitations of that API: - Commands sent from Homey are normally picked up by the device fairly quickly. - Status changes made directly on the device or in the Adax mobile app can take significantly longer before they are reflected back in Homey. - Sync from the device to Adax Cloud, and then from Adax Cloud back to Homey, is the slowest part of the chain. - Some status values and power values are estimated and should not be treated as directly measured hardware values. Homey therefore works best as the active control surface for these devices, not as a perfect real-time mirror of all manual changes made outside Homey. Disclaimer The app is provided as-is, without any kind of warranty. Use is at your own risk. I cannot be held responsible for errors, downtime, API changes at Adax, missing compatibility, incorrect calculations, or economic consequences caused by using the app. Functionality and compatibility can change if Adax changes its API, cloud services, authentication, or other underlying infrastructure. Energy data limitations (0.3.48): Adax documents withEnergy as past-hour energy, but does not precisely define energyTime boundaries. The app provisionally interprets it as the end of an hour; this is not a verified metering guarantee. Device settings show whether a window was applied or skipped. Revisions for an identical window replace its previous value; overlapping different windows remain excluded. Only numeric energyWh and explicit energy_log fromTime/toTime periods are reconciled; missing data is not zero. Prioritizing completed energy_log periods is an app policy, not an Adax accuracy claim. Local estimates continue between accepted cloud periods. Existing totals are not reset. Energy log polling (0.3.49): normally every six hours per room; consecutive failures wait 6, 12, then 24 hours (capped). Successful responses reset to six hours. Requests are serialized per Homey app with at least ten seconds after each completed request. Separate Homey installations are not coordinated. Local estimates and withEnergy remain enabled. Historical repair (0.3.52): completed energy_log periods from the last eight days that end before the new accounting baseline can reduce proven historical overcounting when stored cumulative history brackets both boundaries within 65 minutes and is nondecreasing through the period. Unknown edge consumption is left unchanged; missing periods are never zero-filled. The internal history is adjusted following its recorded growth shape (not a claim of accurate hourly cloud data). Each repaired interval is persisted with provenance and applied once, including across restarts. Overlapping replacements, changed values for an already repaired period, periods crossing the accounting start, or insufficient history are skipped for review. At most 256 repairs per device are retained; markers are never silently discarded. A historical repair lowers the public meter at repair time, so Insights may show a drop and Homey consumption summaries may react to it. Old Insights entries are not rewritten. Version 0.3.52 also projects ordinary cloud corrections onto their original periods in internal history and settles recorded debt on a changed cloud reconciliation. It does not alter simulated live watts. Per-device diagnostics distinguish request success from applied/skipped accounting and show the historical correction total. No additional Adax polling is introduced. Control and stability (0.3.52): commands preserve a complete per-room desired state with a revision, including OFF followed by a target change. A later ON sends the retained target in Celsius x100. A stale or deleted queued request is skipped. Fresh post-acceptance settings are required for confirmation; that confirms cloud settings, not the physical relay. A recent persisted unsent command may resume after restart; sent/accepted/unknown commands are reconciled without blind replay. Failed outcomes are explicitly unknown. Local power transitions integrate old watts before changing estimated output; network reads occur outside local accounting commits. Historical energy cannot force live watts to zero. Enabled alone never means full heating, including the legacy on/off inference option. Explicit heating indicators, when present, take priority; otherwise temperature/hysteresis and pending intent remain estimates. No documented relay-status field exists in the current public OpenAPI. Device settings show the power basis. A room with multiple heaters still uses aggregate nominal wattage, not per-heater measurements. Transport has a 15-second whole-request deadline, a 4 MiB response limit, stream failure handling and shared token renewal. The API graph now counts attempted REST requests including failures, controls and authentication retries (not token endpoint calls or other integrations). Historical samples before this update were success-only, so full comparable coverage needs a new rolling window. History cap is 20,000 samples; extreme traffic above that can still truncate history. Calendar consumption uses the Homey timezone, with DST-aware yesterday boundaries; UTC is used if unavailable. Unobserved integration gaps beyond 15 minutes are flagged rather than invented. Estimated OFF does not prove the element is physically off while a command is queued or uncertain. For strict peak protection, verify against a real main meter or retain power headroom until the action is observed. Corrected cumulative meter decreases have offline coverage but have not been physically validated against all Homey Energy or third-party consumers.