Evidence summary
Official documentation checked: October 17, 2026. Initial research: July 26, 2026. This is a United States, research-based compatibility guide built from official utility-data, standards, manufacturer, platform, account and privacy documentation. We did not connect a customer utility account, install a monitor, authenticate a third-party service, inspect network traffic, test an API, compare latency, or measure recovery after an outage. A documented capability is therefore treated as a bounded route, not proof that it will work for every account, utility, model, region or household.
Commercial relationship: None declared. There are no affiliate links, rankings or purchase recommendations.
Quick answer
Start with the decision you need to make and the data contract required to support it. A utility download, vendor dashboard, CSV export, official cross-vendor integration, cloud connector and direct local interface are different architectures. They can differ in authorization, interval, fields, retention, export, control permissions, deletion and support.
Do not treat an app screen as an API, a CSV export as local device access, a named integration as feature parity, or a community connector as vendor-supported. Even a connector running on your computer can depend on the vendor cloud. When the current portal or export already answers the question, keeping that route avoids adding another account, client and support dependency.
Who this guide is for
This guide is for U.S. renters, apartment dwellers and small-home households that have already chosen an appropriate monitoring level and now need to understand where the data goes, what an app or integration exposes, and what new dependencies they would accept. Hardware selection belongs before this step. Panel access, electrical installation and permission remain separate safety decisions.
- Use it to compare data routes, not hardware performance.
- Use it to identify missing account, retention, export or deletion facts.
- Use a utility or approved-meter process for billing disputes.
- Use a separately validated direct-test protocol for latency, reliability or outage-recovery claims.
Separate the layers before comparing
Scroll horizontally to see all columns.
| Layer | Buyer question | Common mistake |
|---|---|---|
| Measurement source | Utility meter, panel monitor, selected circuit, plug load or inferred device? | Assuming every field has the same physical boundary. |
| Data route | Portal, download, automated transfer, vendor cloud, local interface or third-party connector? | Calling every route an API. |
| Account and consent | Who authenticates, authorizes, shares and revokes access? | Confusing sharing with ownership transfer. |
| Data contract | Which fields, units, timezone, interval, gaps and retention apply? | Combining exports without normalizing semantics. |
| Action surface | View only, export, automate, control or delete? | Assuming a voice command exposes analytics or history. |
| Support lifecycle | Official, experimental, community-only, retired or unknown? | Trusting a visible menu option after support ends. |
A useful integration record names every layer. A product logo or compatibility badge alone is not enough.
Ten data and integration routes
Scroll horizontally to see all columns.
| Route | What it can establish | What it does not establish |
|---|---|---|
| Utility Download My Data | A customer can obtain the exact utility-provided file and interval. | Automatic transfer, real-time data, device attribution or identical utility coverage. |
| Utility Connect My Data | An authorized third party can receive data under an exact implementation and consent route. | Availability at every utility or every smart meter. |
| Vendor dashboard | The current app or web interface exposes documented fields and history. | Export, public API, local access or indefinite support. |
| Vendor export | A dated file can be analyzed outside the app. | Identical fields, retention or resolution across vendors. |
| Official cross-vendor integration | Named models and accounts exchange bounded data or controls. | Universal compatibility or feature parity. |
| Vendor-documented cloud connector | A vendor may document a client-side program that reads its cloud. | Direct local device access, offline operation or tested client compatibility. |
| Third-party cloud connector | A maintained service may poll or receive vendor-cloud data. | Local-only operation, vendor endorsement or zero additional data exposure. |
| Community connector | May provide an experimental path for technically capable users. | Vendor support, stable authentication or a reliability guarantee. |
| Documented local interface | Exact official protocol can support a local route. | Existence merely because a device has a mobile app or web page. |
| No new integration | The current portal, bill or export is sufficient. | That the household is missing a necessary feature. |
Utility data: download and automated transfer are different
The U.S. Department of Energy’s Green Button overview describes a common data format and distinguishes customer download from customer-authorized automated transfer. Available intervals can be 15-minute, hourly, daily or monthly, depending on the utility. That variability matters: a monthly file can support bill and trend review, but it cannot answer a seconds-level load question.
For automated transfer, verify the exact utility, service account, recipient, consent scopes, revocation path and implementation status. A smart meter alone does not prove that Connect My Data is available. The Alliance testing program assesses specific implementations; this guide makes no certification or conformance finding for a utility, product or household.
Emporia: app, export, integrations and account dependencies
Emporia’s data-storage documentation describes cloud retention that varies by resolution: second-level data for three hours, minute-level data for seven days, fifteen-minute data for one year through CSV export, and hourly/daily aggregates for the device lifetime. Limited on-device buffering does not establish a local archive. These are current vendor statements, not retention or recovery tests performed here.
The current CSV export guide describes on-demand, device/date-range exports. Its second, minute and fifteen-minute files contain power in kW; hourly and daily files contain energy in kWh. Check the Home/device timezone and interval boundary before comparing files. A shared column label does not make power and energy interchangeable.
The developer-access page states that Emporia does not offer a public API for direct device/account access or a direct local device interface, and that community connectors are independently maintained and unsupported by Emporia. Read that statement alongside its separately documented MCP cloud connector below; it is not evidence that every programmatic route is absent.
Named controls have narrower contracts. Emporia documents Nest, Honeywell Total Connect Comfort, Resideo, Sensi and Home Connect routes. Its Nest update describes Google OAuth and Home/Eco Hold constraints. Neither page proves that an exact thermostat, appliance, account or region will work in a household we have not tested.
Scroll horizontally to see all columns.
| Question | Documented route | Required qualification |
|---|---|---|
| History | Cloud retention varies with resolution. | Export before needed detail ages out; no local archive inferred. |
| Export | Resolution-specific CSV files. | Distinguish kW from kWh, and align timezone, boundaries and gaps. |
| Direct local device access | The developer page says no local API/interface. | A locally running MCP process still reads the cloud. |
| Sharing | Shared users can view, control and change settings. | Review Home membership and every device it exposes. |
| Thermostat/appliance links | Named, account-linked platforms. | Check exact model, region, scopes, Home and mode restrictions. |
| Voice assistants | Basic on/off for compatible plugs and chargers. | The guide does not support energy-usage queries or arbitrary analytics through voice. |
Combined Vues and Nesting represent different parallel and hierarchical measurement boundaries; using the wrong relationship can double-count data. Utility Connect is a separate eligible-meter/HAN route with feature exclusions. Neither is a shortcut around exact configuration and permission review.
A local MCP process is not a local device API
Emporia’s MCP guide documents a program running on the user’s computer that reads Emporia cloud data for an MCP-compatible client. It requires a native email/password account rather than third-party sign-in. This is a separately documented programmatic route, with account, client and cloud dependencies. We did not install it, enter credentials, inspect an API payload, audit its code or test any client.
The browser-based AI Energy Assistant is another route, documented as a research release. Its examples do not prove response accuracy, complete fields, savings, privacy, deletion completion or reliability. Review the exact data recipients, account permissions and fallback before connecting either route. Keep existing exports when they already answer the decision.
Sense: export, cloud polling, experimental and retired routes
Sense’s support notice distinguishes the end of direct panel-monitor sales from continued support for installed monitors. It also warns that long-term integration compatibility depends on partners. A working monitor, an eligible utility-meter account and a current partner integration are separate states.
The current download guide describes hour/day CSV export through the Sense Home app, with range and frequency limits. Historical web-only instructions are not the current workflow used here. Home Assistant’s Sense documentation classifies that integration as cloud polling, with documented active-power updates every sixty seconds and trend updates every five minutes. Those are platform descriptions, not timing measurements or Sense endorsement by this publication.
The smart-plug guide separates exact model/version routes and experimental Sense Labs features. An apparently responsive control is not proof that an unsupported model works. Disabling the integration can permanently remove associated history. The LG EnerVu2 notice documents retirement rather than continued compatibility.
Scroll horizontally to see all columns.
| Route | Evidence-safe treatment |
|---|---|
| Sense Home app export | Hour/day CSV; inspect current account, date-range, frequency, field and timezone limits. |
| Home Assistant | Platform-documented cloud polling, not direct local device access or a measured service level. |
| Alexa | Bounded power/device-state queries, documented for the United States and an authorized Sense account. |
| Smart plugs | Use the exact current model/version/app route; some paths are experimental and are not established for reliability-critical decisions. |
| Philips Hue | One Hue Bridge on the same network/subnet; Hue Bridge Pro is not supported by that guidance. |
| ecobee | Historical HVAC data sharing supports detection research; no immediate new detections or thermostat-control capability established here. |
| Network Device Identification | Opt-in, same-network/subnet status broadcasts; the private-content limitation is Sense’s statement, not our network test. |
| LG EnerVu2 | Retired; follow the documented removal/migration boundary, even if an old menu option remains visible. |
Sharing, transfer, unlinking, reset and deletion are not the same
Before connecting another household member or third-party service, write down who owns the source account, who can change settings, which data is shared, how access is revoked and what happens when the account holder moves. A sharing feature may grant control rather than view-only access. An email or ownership transition may use a device-sharing workflow rather than an in-place account rename.
Deletion and reset need separate treatment. Vendor documentation may describe account deletion, device removal, data reset and integration unlinking as different operations. Some are destructive or irreversible. Export any history that must be retained, confirm whether the device must be online, identify which account or home is affected, and record whether third-party copies remain outside the vendor account.
Scroll horizontally to see all columns.
| Action | Question to answer first |
|---|---|
| Share access | Can the recipient only view, or can they control and change settings? |
| Authorize a third party | What scopes, recipient, duration and revocation path apply? |
| Transfer ownership | Does history move, or is a new home/account setup required? |
| Unlink an integration | What data or detected devices disappear from each platform? |
| Reset data | Is the reset irreversible, and should history be exported first? |
| Delete account | Which activity, usage, device and shared data are deleted or retained? |
Read Emporia’s current sharing rules at Home level: adding a shared device to a Home can give its recipient access to every device there, with equal view/control/settings permissions. The account-transition guide describes sharing to a new email account but also warns that deletion removes historical account energy data. Do not treat that combination as a guarantee that every copy or history survives deletion; export needed history and resolve the exact account/Home consequences first.
Sense separately documents account deletion, reset versus factory reset, monitor-to-meter transition without data transfer and provider-account verification. These do not establish that the operations were performed, are reversible, or preserve third-party copies.
Privacy and security: compare questions, not winners
Official privacy and security pages can document encryption, authentication, MFA, sharing and policy terms. They do not provide a matched comparative test proving that one platform is more private or more secure. A household-specific review should instead inventory the data path, account roles, cloud dependency, third parties, retention, exports, deletion, policy jurisdiction and support/update horizon.
- Do not assume local merely means private, or cloud necessarily means insecure.
- Do not infer data minimization from a short feature list.
- Do not infer security superiority from a certification badge without matching scope.
- Recheck policy and authentication changes before release or account setup.
Use the current Emporia privacy policy, Sense privacy policy and Sense security overview as attributed documentation. The NIST consumer-IoT baseline provides an ecosystem-level framework; it does not certify either platform or resolve a household’s legal or security questions.
What documentation cannot verify
This review did not directly test authentication failures, polling cadence, rate limits, missing intervals, timezone changes, duplicate records, revocation, platform outages, local-network isolation, account migration, deletion completion or recovery after internet loss. Therefore it does not rank reliability, latency, completeness, privacy, security or ease of use.
A direct test would need exact accounts and products, a preregistered field map, timestamps, controlled outages, repeated runs, documented versions, consent, safe credential handling and retained raw evidence. Synthetic fixtures in the package test only the routing logic.
A fail-closed verification workflow
- Define the decision. Trend review, spreadsheet analysis, automation, sharing, transfer or deletion require different evidence.
- Name the measurement boundary. Utility total, mains total, selected circuit, plug load or inferred device.
- Identify the exact route. Utility download, authorized transfer, vendor dashboard/export, official integration, third-party connector or local interface.
- Verify current support. Official, experimental, community-only, retired or unknown.
- Verify account and region. Utility, meter, product, model, OAuth scopes, account owner and revocation.
- Freeze the data contract. Fields, units, timezone, interval, history, gaps, export format and deletion.
- Check whether local-only is required. A cloud route cannot satisfy that requirement by wording alone.
- Keep destructive actions separate. Export before reset, transfer or deletion when history matters.
- Hold unsupported comparisons. Reliability, latency, recovery, privacy and security winners require matched evidence.
- Choose no new integration when sufficient. Avoid unnecessary accounts and support dependencies.
Normalize exports before combining them
Two files can both contain a column named “energy” and still describe different things. One may use cumulative kilowatt-hours while another uses interval watt-hours; one may use local time with daylight-saving transitions while another uses UTC; one may represent whole-home mains while another represents a selected circuit or inferred device. Before joining data, create a small field dictionary and preserve the original files unchanged. A spreadsheet that silently changes timezone, rounds timestamps or treats missing intervals as zero can produce a persuasive but false comparison.
Scroll horizontally to see all columns.
| Field | Record explicitly | Do not assume |
|---|---|---|
| Timestamp | Format, timezone, daylight-saving treatment and interval start/end convention. | Rows from two files refer to the same instant. |
| Measurement | Power or energy, instantaneous or interval, cumulative or incremental. | Watts and watt-hours can be joined directly. |
| Unit | W, Wh, kWh or another declared unit. | A numeric column uses the same scale in every export. |
| Boundary | Utility total, mains, circuit, plug or inferred device. | Totals should reconcile without overlap or missing loads. |
| Quality | Missing, estimated, interpolated, duplicated or reset records. | A blank or absent interval equals zero consumption. |
| Identity | Account, home, device, channel and version identifiers. | A renamed device remains the same data series. |
Keep a reproducible transformation log: original filename and hash, export date, parser version, field mapping, timezone conversion, duplicate policy, missing-data policy and output hash. This is especially important when a vendor changes authentication, export schema or retention. The log does not turn a consumer export into billing evidence; it only makes the household analysis traceable.
Decision table
Scroll horizontally to see all columns.
| Need | Evidence-safe route | Hold or stop when |
|---|---|---|
| Monthly or interval trend | Utility download or existing vendor export. | Required interval or fields are absent. |
| Automatic utility transfer | The exact utility-documented, customer-authorized Connect My Data route. | Utility, recipient, consent or revocation is unknown. |
| Cross-vendor control | Exact official integration and supported models. | Only platform logos or community instructions are found. |
| Local-only data | Exact official local interface. | Documentation shows cloud-only or is silent. |
| Share with household member | Exact role/permission review. | View versus control permissions are unclear. |
| Move, transfer or delete | Export plus documented transition/deletion workflow. | History, ownership or irreversibility is unclear. |
| Billing dispute | Utility bill and approved utility/meter process. | A consumer integration is being treated as settlement evidence. |
| Reliability winner | Matched direct test. | Only documentation or synthetic fixtures exist. |
| No unmet need | Keep existing/no new integration. | Nothing; no purchase is a valid outcome. |
Treat support state as a first-class field
An integration can exist in documentation while occupying very different lifecycle states. “Official current” means the vendor or platform presently documents the exact route. “Experimental” means the route may change or fail more often and should not carry reliability-sensitive conclusions. “Community-only” means a third party maintains the connector without the product vendor’s support. “Retired” means readers need a migration or removal path. “Unknown” means the current status could not be established and the claim must remain held.
Scroll horizontally to see all columns.
| State | Permitted wording | Required next action |
|---|---|---|
| Official current | Exact models, region, account and bounded capabilities are documented. | Recheck authentication, fields and support date before release. |
| Experimental | Available as an early-access or Labs route. | Keep reliability and permanence unknown; provide fallback. |
| Community-only | An unofficial connector exists. | Disclose maintainer and unsupported status; do not infer vendor support. |
| Retired | The former route is no longer supported. | Stop presenting it as current; explain unlink, export or migration. |
| Unknown | Current status was not verified. | Hold the integration claim. |
Support state must be attached to the exact integration, not merely the product brand. A company can continue supporting installed hardware while ending direct sales, retire one partner integration while keeping others, or move one feature into an experimental program. Those changes affect the reader route even when the underlying monitor still functions.
Unknowns that must remain visible
- Exact utility and account eligibility.
- Current model, region and authentication support.
- Field definitions, units, timezone and missing-data behavior.
- Polling or transfer cadence, rate limits and outages.
- Retention at each resolution and what an export includes.
- Shared-user permissions and third-party copies.
- Deletion, reset, unlink and ownership-transfer consequences.
- Support and update horizon.
- Current experimental or retired integration state.
Bottom line
The useful comparison is not “which app has more logos.” It is whether one exact, current route provides the data and action needed with acceptable account, cloud, retention, export, deletion and support dependencies. Verify the route at the level of utility, model, account, fields and date. When those facts are missing, hold. When the current portal or export is sufficient, keep it.
Related reading
- Choose the appropriate home-energy monitoring boundary.
- Compare existing-owner Sense routes with current Emporia hardware.
- Review installation safety and permission boundaries.
For a small-home audit, start with the question, inspect the existing bill or utility export, choose the least invasive sufficient measurement and retain the limits of the chosen data route.
Method and sources
This is a source-linked comparison of documented architectures and account consequences, checked October 17, 2026. Official manufacturer, utility-data, standards and platform documentation supports the bounded examples; product behavior was not tested. Models, region, account, software version, data fields and support state must be confirmed for the exact route before it is treated as a household candidate.
The routing logic is deterministic and non-scoring. It checks declared goal/source compatibility, support, authorization, region, fields, resolution, retention, export, deletion and local requirements. Software fixtures include mismatched architectures, missing information, retired/experimental routes and destructive-action precedence. These checks validate the logic under supplied inputs; they do not establish real eligibility, API payloads, latency, recovery, privacy, security or deletion completion.
The inline links identify the primary evidence beside each material statement. Manufacturer features and safeguards are attributed statements. Emporia’s developer API wording is qualified by its separately documented MCP connector; sharing/history wording remains a limit rather than a promise of safe deletion. No customer account, utility record, credentials, private dataset, physical installation or independent performance comparison was used.
What changed
October 17, 2026: refreshed export, account and integration documentation; distinguished the MCP cloud connector from direct local device access; and tightened software checks for mismatched routes and missing information. No direct product or account testing was added.