# Per-minute energy sensors from an Emporia Vue in Home Assistant > magico13/ha-emporia-vue is a custom Home Assistant integration that reads an Emporia Vue energy monitor over the vendor cloud and exposes one averaged sensor per channel, plus two diagnostics for the cloud link itself. It is a small, well instrumented integration whose real dependency is Emporia's API and your willingness to store vendor tokens. **magico13/ha-emporia-vue** — Home Assistant Integration for Emporia Vue Energy Monitor - Repository: https://github.com/magico13/ha-emporia-vue - Stars: 760 · Forks: 111 - Language: Python - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/magico13-ha-emporia-vue ## One entity per channel, averaged over the minute The scope of this integration is narrow and that is its virtue. It reads data from the Emporia Vue energy monitor and creates a sensor for each device channel showing average usage over each minute. No dashboards, no scenes, no automations. Just a set of sensors you can use in Home Assistant the same way you would use any other numeric entity. The design choice that matters is the averaging interval. A minute of average usage is a shape that suits Home Assistant's statistics and energy dashboards better than a raw instantaneous draw, and it also reduces the number of updates a downstream system has to absorb. A channel that switches on and off within a minute is still represented, but as its average rather than as a spike, which is a deliberate trade of detail for smoothness. Who is it for? Home Assistant users who own the Emporia Vue hardware and want its channel data inside their home automation setup. If you are looking for a way to read the device without Home Assistant, the underlying library does that job on its own, which is the next point. One housekeeping note from the README, worth quoting because it matters for anyone writing about it: this project is not associated with or endorsed by Emporia Energy. It is a community integration for a consumer device, built against a vendor API, and the vendor is not behind it. ## HACS as a custom repository, not a store listing Installation runs through the Home Assistant Community Store, and the first thing to understand is that this integration is not part of the default store. It has to be added as a custom repository, and the README walks through the UI steps. From the HACS entry in the sidebar, you open Integrations, use the three-dot menu in the top right to select Custom repositories, paste the url for this GitHub repository into the Add custom repository URL field, set the category to Integration, and press Add. Then you select Emporia Vue from the list and press the download button. The remaining configuration happens inside the Home Assistant Integrations screen. There is a wrinkle the README flags. You may need to restart Home Assistant and clear your browser cache before the integration appears, and it suggests trying ctrl+shift+r if it does not show up in the configuration list. That is a normal annoyance of custom integrations, not a fault in this one, and it is worth knowing before you conclude the install failed. If you would rather not use HACS, the manual path is described too: merge the custom_components folder with the one in your Home Assistant config folder, and you may need to manually install the PyEmVue library. Configuration itself is done directly in the Home Assistant UI, with no manual config file editing required. You add the integration from Configuration, then Integrations, then the + button, search for Emporia Vue, and enter the email and password used for the Emporia App. ## The dependency sits in PyEmVue, not in this repository Data is pulled from the Emporia API using the PyEmVue Python module, also written by the same author. That relationship explains a lot about how the integration behaves, including the part that is most interesting in it. If you want the data without Home Assistant, PyEmVue is the piece to use. The integration is the layer that turns those readings into Home Assistant entities, with the averaging, the config flow and the diagnostics. That separation is good design, and it also means there are two things to trust rather than one. The cloud is the other dependency. Every number in Home Assistant comes from the Emporia API, reached with your Emporia account credentials, not from the device on your wall. The device is the sensor, but the data path goes out to the vendor and back. That has consequences for anyone considering this for monitoring, and the integration is honest about it by shipping diagnostics specifically for cloud reliability, which is the subject of the next section. The repository structure reflects a normal Home Assistant custom component. There is a custom_components/ directory holding the integration itself, a hacs.json file that declares the custom repository to HACS, an info.md file that HACS renders as the integration description, a tests/ directory with a pytest.ini at the root, and a LICENSE.txt at the top level. ## Two diagnostic sensors that explain a missing update Most integrations of this kind fail silently. The numbers stop changing and the user is left guessing whether the device is broken, the API changed, or the integration is at fault. This one ships two diagnostic entities specifically for that situation. The first, Emporia API Retries, counts recoverable update failures since the integration was loaded. Its attributes break out total and consecutive retries separately for minute, daily and monthly telemetry, so you can tell a single blip from a sustained pattern. The separation of totals and streaks is what makes the entity useful rather than decorative. The second, Emporia API Latency, records the duration of the latest minute telemetry update in milliseconds. The README is careful about what that number means: it is the end-to-end API update time, because PyEmVue does not expose the underlying HTTP response's connection-only timing. So the figure includes the whole update path rather than just the socket handshake, and it should be read as the update duration, not as a network latency measurement. The failure policy is also spelled out, which is rarer than it should be. Brief outages retain the last successful telemetry for two failed polls. A third consecutive failure marks the affected telemetry unavailable until the API recovers. In other words you get two polls of stale data before the entity reports unavailable, a grace period that avoids flapping on a momentary blip and a hard stop that prevents stale readings from being presented as current indefinitely. If a channel goes stale in your Home Assistant, the answer is in these two entities. ## OAuth2 with PKCE, and the token route when it does not fit The authentication story has two paths, and the newer one has a hard version requirement. If your Emporia account uses Google or Apple, you select Sign in with Google or Sign in with Apple when adding the integration and complete the sign-in in your browser. This requires Home Assistant 2025.4 or newer. The integration uses Home Assistant's native OAuth2/PKCE flow and stores the resulting Emporia tokens using the existing token refresh mechanism, which means you are not maintaining a token lifecycle by hand. The callback route has one detail that catches people out. The browser returns through My Home Assistant, and it has to point at the same Home Assistant instance where you started setup. Your instance does not need to be publicly accessible, but your browser must be able to reach it. That is a different requirement from the usual one, and it is worth reading before you conclude the flow is broken. The scopes are listed in the README as well: openid, email and aws.cognito.signin.user.admin. The third one is there because Cognito's GetUser operation requires it to read the signed-in user's profile, and the README is explicit that it does not grant AWS administrator privileges. That distinction is worth reading, since a scope with an admin-looking name in an energy integration should be explained rather than assumed. Email and password authentication, and manually supplied tokens, remain supported. The manual route is documented in detail: sign in at web.emporiaenergy.com, open the browser Developer Tools, go to the Application tab in Chrome or Edge or the Storage tab in Firefox, and under IndexedDB, com.amplify.awsCognitoAuthPlugin, default.store, copy the values of the keys ending in .hostedUi.idToken, .hostedUi.accessToken and .hostedUi.refreshToken, keeping only the values inside the quotes, which should start with eyJ. Those three values are then used in the token authentication step of the integration setup. That is a manual, browser-based procedure, and it is the reason the OAuth path exists. ## MIT licensed, actively released, and outside the default store On maintenance, the signals are good. The repository is not archived, the last push was on 2026-10-11, and the release list shows v0.13.0 on 2026-10-11, v0.12.3 on 2026-08-05, described as a setup failure fix, and v0.12.2 on 2026-06-28, described as better charger control and status. The release notes in those titles are a good sign for a device integration, because they show the author is fixing the parts users actually hit. The licence is MIT, with the terms in LICENSE.txt at the root of the repository. That is a permissive licence, and the practical question for anyone embedding this in a larger product is limited to whether the attribution notice travels with redistribution. The structural caveat is the custom component status. Anything outside the Home Assistant default store sits outside the core compatibility and review process, so a Home Assistant release that changes an internal API can break a custom integration without a deprecation cycle. The repository's own version numbers show the author responding to change, and the presence of a tests/ directory and pytest.ini suggests some regression cover, but the responsibility for checking compatibility after a Home Assistant upgrade stays with the person running it. The second caveat is vendor dependency. The integration depends on an API that the vendor controls, and on an account that the vendor can change the rules for. The Google and Apple sign-in path depends on Cognito, and the manual path depends on the internal structure of the vendor's web client's storage, which is the kind of thing that can change without notice. A consumer integration that polls a cloud API has a maintenance burden that a local one does not, and the diagnostics in this integration are the acknowledgement of that. ## When the integration is the wrong tool There are two cases where you should use something else, and both are about the data path rather than about features. The first is local-only monitoring. Every reading here comes from the Emporia API. If your requirement is that consumption data continues to be captured during an internet outage, or that no third party sees your household's energy use, this integration cannot meet it, and the retry and latency entities are there to tell you when it is failing rather than to make it work. PyEmVue has the same property, since it talks to the same API. The second is the case where you need a single number rather than a set of sensors. If you want the current household draw for one script or one dashboard, pulling it through PyEmVue directly is smaller than running an integration, a config flow and a set of entities for a value you read once. In exchange for accepting the cloud dependency, you get Home Assistant's own machinery: statistics, recorder history, the energy dashboard, automations and templates, all of which work against these sensors without extra code. That is the actual value, and it is real. The two diagnostic entities are a good example of the author's approach to the cloud dependency, which is to instrument it rather than pretend it away. ## Conclusion Adopt ha-emporia-vue if you have an Emporia Vue and want per-channel consumption in Home Assistant with visible diagnostics when the vendor cloud misbehaves. Do not adopt it if your goal is local-only monitoring, because every reading comes from the Emporia API rather than from the device. Verify first that your Emporia account signs in with email and password or that you can complete the Google or Apple flow on Home Assistant 2025.4 or newer, then confirm the integration still loads after your next Home Assistant upgrade, since it is a custom component rather than a core one. ## FAQ ### How do I install the ha-emporia-vue Home Assistant integration? The easiest route is HACS, and the integration has to be added as a custom repository because it is not in the default store. In HACS open Integrations, use the three-dot menu to select Custom repositories, paste the repository url into the Add custom repository URL field, set the category to Integration, press Add, then select Emporia Vue and press the download button. A Home Assistant restart and a browser cache clear may be needed before it appears. ### What data does the ha-emporia-vue integration create in Home Assistant? It creates a sensor for each device channel showing average usage over each minute. It also creates two diagnostic entities, Emporia API Retries, which counts recoverable update failures broken out for minute, daily and monthly telemetry, and Emporia API Latency, which records the duration of the latest minute telemetry update in milliseconds. ### Can I use ha-emporia-vue with a Google or Apple sign-in Emporia account? Yes, and it requires Home Assistant 2025.4 or newer. Select Sign in with Google or Sign in with Apple when adding the integration and complete the sign-in in your browser, which uses the native OAuth2 and PKCE flow and stores the tokens through the existing token refresh mechanism. Email and password and manually supplied tokens remain supported as alternatives. ### What happens when the Emporia API is unreachable in ha-emporia-vue? Brief outages keep the last successful telemetry for two failed polls, and a third consecutive failure marks the affected telemetry unavailable until the API recovers. Recoverable failures are counted by the Emporia API Retries entity. ## Sources - [Issues](https://github.com/magico13/ha-emporia-vue/issues) - [License: MIT](https://github.com/magico13/ha-emporia-vue/blob/master/LICENSE) - [magico13/ha-emporia-vue on GitHub](https://github.com/magico13/ha-emporia-vue) - [README](https://github.com/magico13/ha-emporia-vue/blob/master/README.md) - [Releases](https://github.com/magico13/ha-emporia-vue/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/magico13-ha-emporia-vue