mirror/esphome-emporia-vue-utility
1
0
Fork 0
mirror of https://github.com/nekorevend/esphome-emporia-vue-utility.git synced 2026-01-10 05:10:40 -07:00
Code Issues Packages Projects Releases Wiki Activity

Documentation fixes, and a few changes. (#11)

Browse Source
This commit is contained in:
pixelgrb
2025-10-04 09:42:11 -07:00
committed by GitHub
parent 0ec0d49b83
commit dd177d5a6f
6 changed files with 36 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/basics.md
View File

@@ -28,7 +28,7 @@ The ESPHome Integration is quite magical. Once your device is flashed and runni
![ESPHome integration](esphome_screenshot.png)
### Energy module
You can add the cumulative sensors **Watt-hours Consumed** and **Watt-hours Produced** Home Assistant’s [Energy module](https://www.home-assistant.io/home-energy-management/). This provides a polished and feature-rich view of your energy usage and production.
### Energy dashboard
You can add the cumulative sensors **Watt-hours Consumed** and **Watt-hours Produced** to Home Assistant’s [Energy dashboard](https://www.home-assistant.io/home-energy-management/). This provides a polished and feature-rich view of your energy usage and production.
![Energy module](energy_screenshot.png)
![Energy dashboard](energy_screenshot.png)

15
docs/faq.md
View File

@@ -26,7 +26,7 @@ Later, if you want to customize, see the [section on YAML configuration](yaml.md
### 4. I'm getting intermittent drop outs. What do I check?
- First: **swap the USB power supply**. We have seen a number of the Emporia supply USB power supplies fail, which started out like this and the device failing.
- First: **swap the USB power supply**. We have seen a number of the Emporia USB power supplies fail, which started out like this.
- You may need to move the device closer to your power meter.
- You may need to contact your utililty and ask them to reprovision the device.
@@ -38,13 +38,17 @@ Looks like this in the YAML:
```
api:
encryption:
key: "blah"
key: "M3d8zXcnwM4Uo2fRybLjFUNVs+mnlC1XbEfnlvUNI2c="
```
- Just a security measure. It’s a shared secret between your device and Home Assistant.
- Ensures all ESPHome API traffic (state updates, commands, etc.) is encrypted and authenticated.
- Without it, someone on your LAN could spoof commands to the device.
- ESPHome generates one if you don’t set it yourself.
- To generate one manually:
```
python3 -c "import base64, os; print(base64.b64encode(os.urandom(32)).decode())"
```
---
@@ -52,9 +56,8 @@ api:
Looks like this in the YAML:
```
api:
encryption:
key: "blah"
ota:
password: "blah"
```
- Just a security measure. It’s a shared secret between your device and Home Assistant.
- Used only when flashing new firmware over Wi-Fi (OTA updates).

12
docs/installing_esphome.md
View File

@@ -2,7 +2,7 @@
## Introduction
If this is your time to [ESPHome](https://esphome.io/), the terminology can be confusing. You may hear “flash ESPHome on your device”, but that’s not a totally accurate statement.
If this is your first time to [ESPHome](https://esphome.io/), the terminology can be confusing. You may hear "flash ESPHome on your device", but that’s not a totally accurate statement.
ESPHome is a **framework and toolchain** for creating custom firmware. This usually involves:
- Writing a short YAML configuration file, and optionally providing custom code.
@@ -21,7 +21,7 @@ There are multiple ways to do this and much of the documentation out there is di
You will interact with two distinct parts of ESPHome:
1. **ESPHome** — this is software you will use this to back up the stock firmware, compile this project, and flash the Vue. There are two main ways to do this, with some caveats.
2. **ESPHome integration** — you only need to install the [ESPHome Integration](https://www.home-assistant.io/integrations/esphome) in Home Assistant. It is quite magical. Once the Vue is flashed and running on Wi-Fi, it will auto-discover it and create the sensor entities automatically.
2. **ESPHome Integration** — you only need to install the [ESPHome Integration](https://www.home-assistant.io/integrations/esphome) in Home Assistant. It is quite magical. Once the Vue is flashed and running on Wi-Fi, it will auto-discover it and create the sensor entities automatically.
### How ESPHome works
@@ -46,7 +46,7 @@ This gives you a CLI (command-line interface) to run ESPHome. You run this in t
- Better for developers: quick iteration, local editing of YAML/Python/C++.
- Flexible: you can use local custom code without publishing to GitHub.
- Full control over build logs, debugging, and advanced options.
- You **can** backup the original firmware with this.
- You **can backup the original firmware** with this.
#### 2. ESPHome Device Builder --- [install guide](https://esphome.io/guides/getting_started_hassio/#installing-esphome-device-builder)
@@ -56,13 +56,13 @@ This is a Home Assistant add-on. It is basically a UI wrapper for the ESPHome C
- Runs inside Home Assistant (web UI).
- Better for end users: simpler UI.
- Initial flashing still happens on your PC. It works using WebSerial (via a browser).
- You **cannot** use this to backup the original firmware.
- You **cannot use this to backup the original firmware**.
### What is best for you?
- If you are adamant about [backing up the original Vue firmware](backup_firmware.md), minimally install the CLI just to get the backup step done. You can use either the CLI or the Device Builder to program and flash, and you can switch between them as well.
- If you are adamant about [backing up the original Vue firmware](backup_firmware.md), minimally install the CLI just to get the backup step done. You can use either the CLI or the Device Builder to program and flash, and you can switch between them at any time as well.
- If you like working from the command line and want full control, the ESPHome CLI is straightforward: you write YAML by hand, build, and flash. It’s lean, reproducible, and great if you’re already comfortable with terminals.
- If you like working from the command line and want full control, the ESPHome CLI is straightforward: you write YAML in a text file, build, and flash. It’s lean, reproducible, and great if you’re already comfortable with terminals.
- The Device Builder adds a friendlier interface. It’s easier for beginners, integrates neatly with Home Assistant, and makes troubleshooting or rebuilding devices more point-and-click.

3
docs/wiring_and_usb.md
View File

@@ -77,7 +77,6 @@ Flashing tools (like `esptool`, used by ESPHome) do not have “EN/IO0” pins.
On some USB-serial adapters, those labels or polarities are effectively flipped. That’s why you’ll sometimes need to swap the connections.
Many ESP32 dev boards (NodeMCU/WROOM devkits) hide this logic behind transistors/inverters, so you never think about it. **Bare USB-TTL dongles expose raw DTR/RTS**, where names and polarity are not standardized.
- **Label drift:** Some boards label the header “RTS” where the chip is actually driven like DTR (or vice-versa).
- **Polarity/inversion:** CH340, CP210x, FTDI, etc. often invert DTR/RTS differently. A vendor may “fix” this on the PCB without changing the silkscreen names.
@@ -104,5 +103,5 @@ Those all mean EN/IO0 aren’t being driven with the expected timing and polarit
### Why `--before usb_reset` sometimes works
`--before usb_reset` avoids DTR/RTS entirely by bouncing the USB device. That can momentarily create the right conditions for the bootloader, but it’s crude and unreliable. It also explains why some people need to manually unplug/replug after flashing. Fixing EN/IO0 mapping makes this unnecessary.
The underlying `esptool` has a `--before usb_reset` option, which can work. It avoids DTR/RTS entirely by bouncing the USB device. That can momentarily create the right conditions for the bootloader, but it’s crude and unreliable. It also explains why some people need to manually unplug/replug after flashing. Fixing EN/IO0 mapping makes this unnecessary.

2
docs/yaml.md
View File

@@ -9,7 +9,7 @@ The example YAMLs should work out of the box, provided you fill in the necessary
### Examples
- The [Web Server](https://esphome.io/components/web_server/) component adds a browser-accessible web UI with sensors and logs. Neat, but it duplicates functionality already in Home Assistant, and consumes a lot of memory on the device. If you won’t use it, disable it.
- The [WiFi Signal Strength](https://esphome.io/components/sensor/wifi_signal/) component creates a sensor in HA showing the devices Wi-Fi strength. You can also see this is the device logs. Handy for troubleshooting, but once the connection is stable you may not need an extra entity cluttering HA.
- The [WiFi Signal Strength](https://esphome.io/components/sensor/wifi_signal/) component creates a sensor in HA showing the devices Wi-Fi strength. You can also see this in the device logs. Handy for troubleshooting but once the connection is stable, you may not need an extra entity cluttering HA.
- The [Uptime Sensor](https://esphome.io/components/sensor/uptime/?utm_source=chatgpt.com) reports how long the device has been running since the last reboot. Handy for debugging stability (e.g. “is my device randomly restarting?”). But if you don’t actively monitor it, it’s more HA clutter.
- [MQTT](https://esphome.io/components/mqtt/) is a powerful but more complex alternative to HA’s native ESPHome API. It is essential for some setups, but if you don’t already use MQTT, you can remove it.