Emporia Vue Gen 3 Support

[Cossid]

Back in June, a FCC entry for 2AS6P-EMV3A (https://fccid.io/2AS6P-EMV3A/Internal-Photos/Internal-Photos-6584145) went public, which shows the gen 3 device should still be ESP32 adding ethernet, and changing from 3.5mm jacks to a more modular 2-wire system. Shortly after, an erroneous beta invite went out to many unintended users.

Well, now gen 3 appears to be on their store available for purchase (though not yet available from 3rd parties such as Amazon at the time of this posting) Now available through Amazon as well.
Mains-only $99 - https://shop.emporiaenergy.com/products/emporia-vue-energy-monitor-3rd-generation-mains-only
Mains+16 clamp $199 - https://shop.emporiaenergy.com/products/emporia-vue-energy-monitor-3rd-generation-with-16-sensors
I'm not quite certain how long it has been listed on their site or if anyone has received one yet.

Can't make out from the FCC docs what energy monitoring components are present. Figured I'd get the discussion ball rolling, see if anyone who had a beta unit can speak up or anyone has ordered/received one yet.

Edit: Units have now shipped/been received. The ESP32 is still fully unlocked, and it looks like the energy monitoring protocol is the mostly same/similar. The only obvious change is the i2c pins have changed:

i2c:
  sda: 5
  scl: 18

Ethernet addition is a Realtek RTL8201F appears supported by ESPHome, but pins still need to be traced.

ethernet:
  type: RTL8201
  mdc_pin: GPIO32
  mdio_pin: GPIO33
  clk_mode: GPIO0_IN

Other notable changes:

• The order of A B and C channels may have been changed, it is also possible other channels are out of order compared to Gen 2.

And since people will be looking for it, pinout:

RX/TX are labeled on the board transposed (apparently the Vue 2 was like that as well, I've never had one). Labeled as ESP32 traces for clarity.

[flaviut]

The green connectors are quite good, I've used them extensively in my own designs. Nice to see that change.

Modding-wise, the measurement hardware seems very similar. However, Emporia uses a custom-programmed microcontroller for energy measurements, so they can change the protocol however they'd like.

It seems like they've run out of room for a dedicated programming connector, although they've been very helpful in labeling the serial test points on the back. Flashing this one is definitely going to be less noob-friendly, those are some tiny test points!

[digiblur]

At least they do have the points labelled. The other real question is if the bootloader is left enabled and unlocked.

[clowrey]

Ooooh interesting! Yes those are small test points! If I was doing allot of these I would design and 3D print a programming jig with holes for spring loaded pogo pins and alignment pins that go into the large mounting holes around the PCB. Then it would be easy.

[Cossid]

It is now listed on their store product listing pages as well as available on Amazon. Hopefully we'll start seeing information and experimentation soon.

[josesa]

It seems that this will strongly affect the availability of the Vue 2. I was planning to buy it and is no longer available on amazon.de. Only third party sellers going for the double of the price.

But the Vue 3 is not yet available on this side of the Atlantic.

[oliv3r]

I still can't see it on amazon in europe. I've asked emporia when they'll have it available. Otherwise I'll just buy a US version (have family traveling) though I'd have to double check if the unit will happily take 230V as input. Afaik the units where all identical from the reversing that I saw. This is probably because they either require 230V split-phase, or a single 230V phase anyway. Smart in a way. But means you can't use it on 110V single phase setups?

[zackoch]

Awesome that they're labeled, and it's funny there is solder on those in the FCC images 😉
Should I pick one up? 🤔

[Cossid]

I have ordered one from Amazon (in case the ESP32 is locked down, easier return), but they must still be inbound to their warehouses, as the delivery time has been stuck on Monday March 18th since it was added to the site.

Interestingly, the Gen 3 16-clamp version already lists 100+ sales on the Amazon page.

[digiblur]

No argument here. I own the home so it is my rules on adding ethernet in the panel, I'm not throwing it in my mains panel without some sort of protection on it on the line. I'll stick to the WiFi adapter on it, it works fine and they have the external antenna that works great.

[flaviut]

Let's not have this discussion anymore, and especially not here.

Anyone who has any doubt about what's allowed by local regulations and what is safe should have that discussion with a local licensed electrician and not with random strangers online.

[taos15]

I will check the code, but I seen those small 24-32v transformers for doorbell, which are considered low voltage, inside the load center.

[digiblur]

See above?

[taos15]

Saw it after I posted.

[Cossid]

Received mine today. Good news is it is also unlocked.

RX/TX are labeled on the board transposed (apparently the Vue 2 was like that as well, I've never had one). Labeled as ESP32 traces for clarity.

Unconfigured full factory bin dump:
emporia_vue_gen3_oem_untouched.zip

chip_id.txt

8MiB flash:
flash_id.txt

No code sign key / encryption key or burned efuses:
espefuse_summary.txt

10/100 Ethernet is RTL8201F

[Cossid]

Text files attached as files don't appear to be working, here they are as text

chip_id:

esptool.py v4.7.0
Found 1 serial ports
Serial port COM21
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e0:5a:1b:d5:84:9c
Stub is already running. No upload is necessary.
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: e0:5a:1b:d5:84:9c
Hard resetting via RTS pin...

flash_id (8MiB flash):

esptool.py v4.7.0
Found 1 serial ports
Serial port COM21
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e0:5a:1b:d5:84:9c
Stub is already running. No upload is necessary.
Manufacturer: c8
Device: 4017
Detected flash size: 8MB
Hard resetting via RTS pin...

espefuse summary:

espefuse.py v4.7.0
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32

=== Run "summary" command ===
EFUSE_NAME (Block) Description  = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Calibration fuses:
ADC_VREF (BLOCK0)                                  True ADC reference voltage                         = 1163 R/W (0b01001)

Config fuses:
WR_DIS (BLOCK0)                                    Efuse write disable mask                           = 0 R/W (0x0000)
RD_DIS (BLOCK0)                                    Disable reading from BlOCK1-3                      = 0 R/W (0x0)
DISABLE_APP_CPU (BLOCK0)                           Disables APP CPU                                   = False R/W (0b0)
DISABLE_BT (BLOCK0)                                Disables Bluetooth                                 = False R/W (0b0)
DIS_CACHE (BLOCK0)                                 Disables cache                                     = False R/W (0b0)
CHIP_CPU_FREQ_LOW (BLOCK0)                         If set alongside EFUSE_RD_CHIP_CPU_FREQ_RATED; the = False R/W (0b0)
                                                    ESP32's max CPU frequency is rated for 160MHz. 24
                                                   0MHz otherwise                                    
CHIP_CPU_FREQ_RATED (BLOCK0)                       If set; the ESP32's maximum CPU frequency has been = True R/W (0b1)
                                                    rated                                            
BLK3_PART_RESERVE (BLOCK0)                         BLOCK3 partially served for ADC calibration data   = False R/W (0b0)
CLK8M_FREQ (BLOCK0)                                8MHz clock freq override                           = 55 R/W (0x37)
VOL_LEVEL_HP_INV (BLOCK0)                          This field stores the voltage level for CPU to run = 0 R/W (0b00)
                                                    at 240 MHz; or for flash/PSRAM to run at 80 MHz.0
                                                   x0: level 7; 0x1: level 6; 0x2: level 5; 0x3: leve
                                                   l 4. (RO)                                         
CODING_SCHEME (BLOCK0)                             Efuse variable block length scheme                
   = NONE (BLK1-3 len=256 bits) R/W (0b00)
CONSOLE_DEBUG_DISABLE (BLOCK0)                     Disable ROM BASIC interpreter fallback             = True R/W (0b1)
DISABLE_SDIO_HOST (BLOCK0)                                                                            = False R/W (0b0)
DISABLE_DL_CACHE (BLOCK0)                          Disable flash cache in UART bootloader             = False R/W (0b0)

Flash fuses:
FLASH_CRYPT_CNT (BLOCK0)                           Flash encryption is enabled if this field has an o = 0 R/W (0b0000000)
                                                   dd number of bits set                             
FLASH_CRYPT_CONFIG (BLOCK0)                        Flash encryption config (key tweak bits)           = 0 R/W (0x0)

Identity fuses:
CHIP_PACKAGE_4BIT (BLOCK0)                         Chip package identifier #4bit                      = False R/W (0b0)
CHIP_PACKAGE (BLOCK0)                              Chip package identifier                            = 1 R/W (0b001)
CHIP_VER_REV1 (BLOCK0)                             bit is set to 1 for rev1 silicon                   = True R/W (0b1)
CHIP_VER_REV2 (BLOCK0)                                                                                = True R/W (0b1)
WAFER_VERSION_MINOR (BLOCK0)                                                                          = 1 R/W (0b01)
WAFER_VERSION_MAJOR (BLOCK0)                       calc WAFER VERSION MAJOR from CHIP_VER_REV1 and CH = 3 R/W (0b011)
                                                   IP_VER_REV2 and apb_ctl_date (read only)          
PKG_VERSION (BLOCK0)                               calc Chip package = CHIP_PACKAGE_4BIT << 3 + CHIP_ = 1 R/W (0x1)
                                                   PACKAGE (read only)                               

Jtag fuses:
JTAG_DISABLE (BLOCK0)                              Disable JTAG                                       = False R/W (0b0)

Mac fuses:
MAC (BLOCK0)                                       MAC address                                       
   = e0:5a:1b:d5:84:9c (CRC 0x27 OK) R/W 
MAC_CRC (BLOCK0)                                   CRC8 for MAC address                               = 39 R/W (0x27)
MAC_VERSION (BLOCK3)                               Version of the MAC field                           = 0 R/W (0x00)

Security fuses:
UART_DOWNLOAD_DIS (BLOCK0)                         Disable UART download mode. Valid for ESP32 V3 and = False R/W (0b0)
                                                    newer; only                                      
ABS_DONE_0 (BLOCK0)                                Secure boot V1 is enabled for bootloader image     = False R/W (0b0)
ABS_DONE_1 (BLOCK0)                                Secure boot V2 is enabled for bootloader image     = False R/W (0b0)
DISABLE_DL_ENCRYPT (BLOCK0)                        Disable flash encryption in UART bootloader        = False R/W (0b0)
DISABLE_DL_DECRYPT (BLOCK0)                        Disable flash decryption in UART bootloader        = False R/W (0b0)
KEY_STATUS (BLOCK0)                                Usage of efuse block 3 (reserved)                  = False R/W (0b0)
SECURE_VERSION (BLOCK3)                            Secure version for anti-rollback                   = 0 R/W (0x00000000)
BLOCK1 (BLOCK1)                                    Flash encryption key                              
   = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLOCK2 (BLOCK2)                                    Security boot key                                 
   = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 
BLOCK3 (BLOCK3)                                    Variable Block 3                                  
   = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W 

Spi Pad fuses:
SPI_PAD_CONFIG_HD (BLOCK0)                         read for SPI_pad_config_hd                         = 0 R/W (0b00000)
SPI_PAD_CONFIG_CLK (BLOCK0)                        Override SD_CLK pad (GPIO6/SPICLK)                 = 0 R/W (0b00000)
SPI_PAD_CONFIG_Q (BLOCK0)                          Override SD_DATA_0 pad (GPIO7/SPIQ)                = 0 R/W (0b00000)
SPI_PAD_CONFIG_D (BLOCK0)                          Override SD_DATA_1 pad (GPIO8/SPID)                = 0 R/W (0b00000)
SPI_PAD_CONFIG_CS0 (BLOCK0)                        Override SD_CMD pad (GPIO11/SPICS0)                = 0 R/W (0b00000)

Vdd fuses:
XPD_SDIO_REG (BLOCK0)                              read for XPD_SDIO_REG                              = False R/W (0b0)
XPD_SDIO_TIEH (BLOCK0)                             If XPD_SDIO_FORCE & XPD_SDIO_REG                   = 1.8V R/W (0b0)
XPD_SDIO_FORCE (BLOCK0)                            Ignore MTDI pin (GPIO12) for VDD_SDIO on reset     = False R/W (0b0)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V)

[bobzer]

I'm trying to flash ,ine and I got the warning : WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.

during my attempts to test and debug I realized that some efuse values are differents :
ADC_VREF you have 1163 i got 1135
CLK8M_FREQ you have 55 i got 52

I'm not sure it can explain my problems do you think so ?, also maybe it can impact calibration ?

[digiblur]

Nice job!! Glad to see it unlocked!

[digiblur]

New i2c is

i2c:
  sda: 5
  scl: 18

[digiblur]

Hope I didn't step on your toes there Cossid. I got a moment to flash and started tracing the i2c out, super excited the damn thing worked!
The calibrations are a little hot. 121.5V here right now and this is a 60watt'ish bulb. I think it pulls like 56w or so on other meters.

Only have L1 voltage connected right now. No split phase 240 on the bench ;)

[clowrey]

That's awesome its basically the same :) no huge changes to protocol etc..

[digiblur]

Got the calibration tweaked a little and it seems to be solid with a 60w bulb. I'll try something larger once I get it back together and off the bench. Voltage sensor seems to be fine this go around.

https://digiblur.com/2024/03/14/emporia-vue-gen3-esp32-esphome-home-assistant

[cf-mp]

Did you guys solder wires onto the points or use some sort jig and probes to just touch them.

[mattster98]

I'm experiencing the same thing, running black and neutral off a 120v outlet. @DeathBlade , did yours work as expected once installed?

[DeathBlade]

@mattster98 yeah. Once I installed it fully it’s been rock solid. It does read a little high compared to what my utility provider bills me but I’ll take that haha.

All I did was tap both phases off of the least two loaded breakers in my panel and then neutral and the blue wire to my neutral bar then ground to ground. I initially removed the blue wire from the wiring harness because I didn’t need it and then when I started to have issues, I hooked it back up and tied it to neutral just in case it needed a reference on that line instead of it just being open.

Edit: I did have to play with my calibration values to get my voltage reading correct

[mattster98]

Hmm.. got it installed with both CTs and black and red powered on each leg and still reading 0 volts. Seeing blips of current but nothing showing for the voltage. :( This panel doesn't draw power during the day (ideally) so maybe it'll show more consistent power at night when it does. Still would expect voltage regardless. I'll start a new thread on it with my config.

[DeathBlade]

Interesting yeah. You should have voltage regardless. I know I have a high amount of Idle power consumption and never drops below 1100w on average on the low end but even when I was doing some circuit finding with everything basically off I still read voltage with no load.

[larryo108]

I am working to do this now myself. I don’t have a lot fo experience with ESPHome, but I do have a little. I am getting the same error that NateAsOfLate was getting. I have tried flipping TX and RX multiple times and no look. I am using a BDM frame with probe pins and just put a probe pin through IO0. I am pretty sure It is making good contact, but are there any other tips? Do I need to leave IO0 grounded for the whole process or just when turning on my USB? Do I disconnect it before I try to backup the firmware?

[wilywyrm]

Would anybody mind sharing some sample individual circuit readings from their Vue 3? I just hooked up my unit and while the total balance power seems fine, I never see any of the individual circuits go above 0.5W at any point. Seemed others had a pretty plug and play experience with theirs, so at this point I'm wondering if I got a dud...

[wilywyrm]

Also might be relevant: I'm seeing a couple of "malformed reading expected null but got 65535" sensor errors that pop up in the logs every ~30s. Wondering if that's just me too.

[Cossid]

I haven't actually hooked mine up to anything yet, other than directly to the ESP32. I'm still in the planning phase. Digiblur showed above a known load of ~60W, so at least that much is verified.

As I understand it, they slightly changed the protocol for when no CT clamp is present on a channel, which results in that 65535 error, so I'm assuming you have some unpopulated channels. I'm guessing that will require a patch after fully being verified.

[wilywyrm]

I did see digiblur had shared his 60w reading but that looked like a total power reading instead of individual.

But about the 65535 thing, I hadn't seen that was a change for v3. I do have all 16 clamps hooked up, but I wonder if I'm seeing that because there's no load on them (haven't needed the heater this week).

[digiblur]

I saw it a few times. I had mine on the bench with the clamps connected and one had a load on it. Without the clamps it goes a little nuts. I used my old code I had on the Gen 2 versus the new method posted on the github for the Gen 2. I found the new one jumps around to some weird amounts as times on the bench.

[rcdailey]

Did anyone here get past this issue? I'm seeing a 0 reading on the 4 clamps I have connected.

[mattster98]

The USB/COM port connection to the VM is probably the cause. A quick search shows lots of examples of others struggling with various errors trying to run esptool in a VM. Not saying it can't work, but you're adding unnecessary complexity. For these couple steps, probably quickest/easiest to just run those steps on the host OS.

…

On Sun, Sep 22, 2024 at 10:04 PM willchomyc ***@***.***> wrote: Same thing. I am running esptool on a Debian 12 VM incase that's relevant. Just strange that it gets as far as it does then chokes. esptool.py -b 115200 read_flash 0 0x800000 flash_contents.bin esptool.py v4.8.0 Found 1 serial ports Serial port /dev/ttyUSB0 Connecting..... Detecting chip type... Unsupported detection protocol, switching and trying again... Connecting... Detecting chip type... ESP32 Chip is ESP32-D0WD-V3 (revision v3.1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: e0:5a:1b:9f:74:0c Uploading stub... Running stub... Stub running... Configuring flash size... esptool.py -b 115200 read_flash 0 ALL flash_contents.bin esptool.py v4.8.0 Found 1 serial ports Serial port /dev/ttyUSB0 Connecting.... Detecting chip type... Unsupported detection protocol, switching and trying again... Connecting... Detecting chip type... ESP32 Chip is ESP32-D0WD-V3 (revision v3.1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: e0:5a:1b:9f:74:0c Uploading stub... Running stub... Stub running... Configuring flash size... Detected flash size: 8MB — Reply to this email directly, view it on GitHub <#264 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALGX4TLV3N3XPASFAAYZATZX5ZJNAVCNFSM6AAAAABEDVJZZSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANZSGEZTEMQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[willchomyc]

Interesting, I have never had Serial-USB issues running this way before, but that would make sense if others have issues too.

I wasn't able to get esptool going on Windows, so I guess I will have to dual boot or find another machine to use. Will report back.

[mattster98]

Not sure what the issues were getting it running in windows (esptool.exe is a static executable so it should just run). It generally just works and you point it to whatever COM# the FTDI shows up as. Be sure you aren't causing problems with the host OS by having the USB port mapped to VMs when you're trying to use it on the host also!

…

On Mon, Sep 23, 2024, 10:07 AM willchomyc ***@***.***> wrote: Interesting, I have never had Serial-USB issues running this way before, but that would make sense if others have issues too. I wasn't able to get esptool going on Windows, so I guess I will have to dual boot or find another machine to use. Will report back. — Reply to this email directly, view it on GitHub <#264 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALGX4SAHERXMBWBWYUNBDDZYAOA7AVCNFSM6AAAAABEDVJZZSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANZSG4YDAOI> . You are receiving this because you commented.Message ID: ***@***.*** com>

[willchomyc]

ahhh the issue ended up being the USB hub on my PC. Switched ports and it worked both on VM and Windows at 115200 baud. Thanks for the help!

[DrSpaldo]

I was wondering if anyone had an example of how the 3 phase (Aus 240v) config would look?

Also, has anyone come across any guides on how to do the calibration?

[Ocramius]

I could use some help with the initial ESPTool connection with the Vue 3.

My main problem is that /dev/ttyUSB0 does not seem to come up at all (I'm on Ubuntu 20.04).

I've got myself a CP2102 device (this one).

My setup is this one:

The pins are connected as follows:

1. IO0 -> GND
2. GND -> CP2102 GND
3. TXD -> CP2102 TXD
4. RXD -> CP2102 RXD
5. TP12 -> CP2102 3.3V

When I plug my USB in, I observe following behaviors:

• CP2102 LED red, RXD flashes blue once, then nothing else
• If I disconnect IO0 from GND, CP2102 LED red, RXD flashes blue ~5 times then nothing else
• If I reverse RXD / TXD no flashing at all

Anyone got any pointers for me? :D How do I get that /dev/ttyUSB0 showing up?

[Ocramius]

dmesg reports:

[157262.342917] usb 1-2.3: new full-speed USB device number 20 using xhci_hcd
[157262.469489] usb 1-2.3: New USB device found, idVendor=11ca, idProduct=0204, bcdDevice= 1.00
[157262.469503] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[157262.469508] usb 1-2.3: Product: VeriFone USB to UART Bridge
[157262.469513] usb 1-2.3: Manufacturer: Silicon Labs
[157262.469516] usb 1-2.3: SerialNumber: 0001

udevadm is kinda similar here:

❯ sudo udevadm monitor -u
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

UDEV  [57442.765166] add      /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2.3 (usb)
UDEV  [57442.765850] add      /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2.3/1-2.3:1.0 (usb)
UDEV  [57442.769877] bind     /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-2/1-2.3 (usb)

I also tried ls -lah /dev > before.txt, plugged in, ls -lah /dev > after.txt and diff before.txt after.txt and nothing really showed up either.

[Ocramius]

To get some clarity on what may be at fault here: should there be a mount point even if the CP2102 is not connected to anything?

Mostly trying to figure out if the issue is with the headers, or with my serial to USB converter.

[mattster98]

Yes, the USB device IS the CP2102 so in dmesg I'd expect to see it get connected to /dev/something in that output. Here's an example from a raspberry pi (what I had handy)

[   10.825730] usbcore: registered new interface driver usbserial_generic
[   10.825884] usbserial: USB Serial support registered for generic
[   10.929203] usbcore: registered new interface driver cp210x
[   10.931742] usbserial: USB Serial support registered for cp210x
[   10.932109] cp210x 1-1.5.4:1.0: cp210x converter detected
[   10.936538] usb 1-1.5.4: cp210x converter now attached to ttyUSB0

That last line shows you what to look for in /dev

[securelyfitz]

You've got a nonstandard device with a custom product id, so usbserial isn't getting loaded. There should be another device saying it's connected and giving the /dev/ttyUSB# device name. This should happen whether or not you've got anything attached to Tx/Rx

Looks like this is one way to fix your device:
https://blog.manzelseet.com/fixing-cp2102-with-custom-vidpid.html

[Ocramius]

Amazing, that helped on my Ubuntu box! The nixos box needs more checking, but for now I can move forward :-)

No idea how I didn't find that specific article earlier: thanks for digging it up!

[TFenby]

[clowrey]

Need pictures of the PCB or something else to go from. We have no way to guess

[toto99303]

Hello people, got my Vue v3 yesterday and immediatelly flashed it with ESPHome. However it seems like I would need a different YAML configuration for my single phase home in EU. Does anyone have a valid YAML config for Vue v3 for 1-phase?

I found this, but it's for v2, can it be used for v3?
#310

Thanks!

[TrueBankai416]

Just comment out or remove the parts for the other phases? Sent from Proton Mail Android

…

-------- Original Message --------

On 11/7/24 2:20 AM, ToTo wrote: Hello people, got my Vue v3 yesterday and immediatelly flashed it with ESPHome. However it seems like I would need a different YAML configuration for my single phase home in EU. Does anyone have a valid YAML config for Vue v3 for 1-phase? I found this, but it's for v2, can it be used for v3? [#310](#310) Thanks! — Reply to this email directly, [view it on GitHub](#264 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AXE242RIJ7MBJWTLAQN6G4TZ7MIEHAVCNFSM6AAAAABEDVJZZSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMJXGQZTCNI). You are receiving this because you were mentioned.Message ID: ***@***.***>

[willchomyc]

Anyone else try adding current readings to their config? I decided to throw them in since my smart plugs have it, and the readings I am getting don't seem to add up with the voltage and power readings. Example below:

Phase A Voltage | 121.5 V
Phase A Power | 208.9 W
Phase A Current | 0.59 A

Phase B Voltage | 121.5 V
Phase B Power | 261.2 W
Phase B Current | 0.60 A

Circuit 10 Power | 110.8 W
Circuit 10 Current | 1.36 A

[DeathBlade]

I had a no success with it. I ended up just using a helper to calculate amps which is just watts/volts. Probably not the ideal solution but it works for me.

[chippings]

I'm a new Vue 3 owner and I am seriously impressed with the reverse engineering effort that has gone on with the Vue 2 and the Vue 3. I have reviewed much of this repo and the @digiblur information. There be wizards here! I have my Vue 3 working great with ESPHome and I have some recommendations for this repo to help new users, but since I'm new to this device, I would like to get some feedback before recommending any specifics.

First, I need to report as a new user, this repo is fairly confusing. I had my Vue 3 up and working on Home Assistant (with the @digiblur repo) before I even found out that there was a vue3 branch here. I suspect most new users here are going to be on the Vue 3, so it would be great to have better pointers to that. The README on this repo points Vue 3 users to digiblur's excellent blog post which includes YAML that points to the digiblur repo. I saw some discussion regarding maintaining a separate Vue 3 integration vs. having a branch and I don't know what to suggest, but there should be better pointers to it.

I think there should be really obvious sample YAML configs for both the Vue 2 and the Vue 3 in standalone files in the repo with their own commit history separate from the README. I would highly recommend starting with the @bradsjm excellent configuration from his gist. It's a bit out of date and needs updating for the recent I2C clock changes and ota platform entry, but it is one of the best overall ESPHome configs I've ever seen and includes much needed documentation on what is going on.

While reviewing the code prior to my purchase of the Vue 3, I noticed a bug in the B and C clamp current calculation

esphome/esphome/components/emporia_vue/emporia_vue.cpp

Lines 132 to 136 in 983aa78

	if (this->input_port_ <= CTInputPort::C) {
	scalar = 775.0 / 42624.0;
	} else {
	scalar = 775.0 / 170496.0;
	}

Since clamp C is no longer the highest numbered 200A clamp on the Vue 3, this is incorrect. As much as I prefer to use self-documenting symbols, I would suggest simply changing it to the constant "3" as is done in the code directly following so that it works for both the Vue 2 and the Vue 3.

I've read an enormous amount of confusion about negative power values with no concrete explanations of how it should be set up. I'll try to explain here how I believe it should be set up (and what works for me) and then this should probably be documented in the YAML config file for new users.

I believe that all clamps (the A,B,C and the 1,2,3 labeled clamps) are all wired to the ADCs on the board with consistent polarity (the reverse engineered Vue 2 schematics also suggest this is true for the Vue 2). I further believe that the microcontroller produces power readings for all 19 clamps in a consistent manner with consistent polarity. In addition, the 50A and the 200A CT clamps are wired with consistent polarity (black and white wires) and are marked consistently with the breaker direction arrow. (You may note that when viewing the Vue 3 unit with the Phoenix connectors plugged in, the black wire is on one side of the ABC connectors and is on the other side of the 123 connectors, but I don't believe this affects consistency of the actual wiring polarity.)

Assuming that users follow the Vue 3 instructions which say to install the clamps with the "Breaker" arrow pointing toward the circuit breakers, if you visualize the current conductor coming in to the breaker box from the electric supplier, through the phase A clamp, through the breakers, through the circuit 1 clamp, and out of the box to the load you will see that the A clamp and the 1 clamp are pointing toward each other, and thus are installed "opposite" of each other. Thus we would expect one to be producing a positive voltage while the other is producing a negative voltage at any given time. (I don't have a Vue 2, but in looking at the documentation online, it seems that the installation instructions for the Vue 2 differ from the Vue 3 in that for the Vue 2 it is recommended to direct the K->L arrows in the same direction, as opposed to opposite directions on the Vue 3, and thus the *pos/*invert filter settings in the YAML config may be different for a Vue 2 vs a Vue 3).

Since I've observed positive power readings from the ABC clamps, I would definitely assume (and have observed) negative power readings on the 123 circuit clamps. Thus the ESPHome config should use the *pos filter on ABC clamps and the *invert filter on the 123 clamps. If this does not produce correct results, it is likely that the wrong phase is configured for the circuit or that a clamp was installed reversed. Users that have followed the installation instructions correctly should not arbitrarily change *invert on circuits to *pos because they are probably referencing the voltage from the wrong phase which could affect the accuracy of power readings (while being close enough to probably not notice).

On the subject of the I2C, I'm working just fine with the recommended 400kHZ clock frequency with a timeout of 1ms. However, I'm frustrated that I have no idea why other frequencies aren't working. On a virgin (unconfigured from the factory) Vue 3, I believe I measured an I2C clock of 100kHz. I can only guess that we are dealing with some quirk of ESPHome here. It doesn't seem to be a requirement of the hardware as far as I can tell and would appreciate any thoughts on this.

Please let me know what I have wrong here.

[Cossid]

First, I need to report as a new user, this repo is fairly confusing. I had my Vue 3 up and working on Home Assistant (with the @digiblur repo) before I even found out that there was a vue3 branch here. I suspect most new users here are going to be on the Vue 3, so it would be great to have better pointers to that. The README on this repo points Vue 3 users to digiblur's excellent blog post which includes YAML that points to the digiblur repo. I saw some discussion regarding maintaining a separate Vue 3 integration vs. having a branch and I don't know what to suggest, but there should be better pointers to it.

I'd first point out, there hasn't been any official adjustments to the base code for the Vue3 model yet. I'm assuming there will be at some point, but until then everyone has mostly had to maintain their own configs for their own needs/likes.

I think there should be really obvious sample YAML configs for both the Vue 2 and the Vue 3 in standalone files in the repo with their own commit history separate from the README. I would highly recommend starting with the @bradsjm excellent configuration from his gist. It's a bit out of date and needs updating for the recent I2C clock changes and ota platform entry, but it is one of the best overall ESPHome configs I've ever seen and includes much needed documentation on what is going on.

I'm assuming at some point there will either be an alternate official example, or a flag in the configuration to switch between the two versions, but there are probably some code adjustments (like you point out below) that need to happen first.

While reviewing the code prior to my purchase of the Vue 3, I noticed a bug in the B and C clamp current calculation

esphome/esphome/components/emporia_vue/emporia_vue.cpp

Lines 132 to 136 in 983aa78

	if (this->input_port_ <= CTInputPort::C) {
	scalar = 775.0 / 42624.0;
	} else {
	scalar = 775.0 / 170496.0;
	}

Since clamp C is no longer the highest numbered 200A clamp on the Vue 3, this is incorrect. As much as I prefer to use self-documenting symbols, I would suggest simply changing it to the constant "3" as is done in the code directly following so that it works for both the Vue 2 and the Vue 3.

I've noticed this before, and this would actually be a bug in calculating current clamp for both A & B (as assigned by input) in both Vue 2 & Vue 3. While Vue 2 & Vue 3 don't use the same order (inverted from each other), the code looks like it was written expecting to work from the enum position instead of the enum value. I'm assuming the correct code would actually be < CTInputPort::ONE I'm not sure what effect this would have across the project though.

Edit: I just realized there is a Vue3 branch merged back from Digiblur, I hadn't realized that. So yeah, this bug only effects the Vue3 branch. The solution of < ONE would work for both.

Assuming that users follow the Vue 3 instructions which say to install the clamps with the "Breaker" arrow pointing toward the circuit breakers, if you visualize the current conductor coming in to the breaker box from the electric supplier, through the phase A clamp, through the breakers, through the circuit 1 clamp, and out of the box to the load you will see that the A clamp and the 1 clamp are pointing toward each other, and thus are installed "opposite" of each other. Thus we would expect one to be producing a positive voltage while the other is producing a negative voltage at any given time. (I don't have a Vue 2, but in looking at the documentation online, it seems that the installation instructions for the Vue 2 differ from the Vue 3 in that for the Vue 2 it is recommended to direct the K->L arrows in the same direction, as opposed to opposite directions on the Vue 3, and thus the *pos/*invert filter settings in the YAML config may be different for a Vue 2 vs a Vue 3).

I'm not sure that is correct, and this may be where a lot of people are getting confused. The Emporia Vue 3 instructions only give guidance for the arrows for the A/B/C clamps (step 5), and omit instructions for the arrows on the numbered clamps (step 8). The arrows are supposed to point towards the load in all cases. For the incoming mains lines, the circuit box itself is the load, and the arrows should point towards the panel's branches to be distributed. For all the individual numbered circuits/clamps, the loads are actually leaving the breakers, so would point away. It is quite interesting that their install manual has no mention of this. This is probably a big source of confusion.

Since I've observed positive power readings from the ABC clamps, I would definitely assume (and have observed) negative power readings on the 123 circuit clamps. Thus the ESPHome config should use the *pos filter on ABC clamps and the *invert filter on the 123 clamps. If this does not produce correct results, it is likely that the wrong phase is configured for the circuit or that a clamp was installed reversed. Users that have followed the installation instructions correctly should not arbitrarily change *invert on circuits to *pos because they are probably referencing the voltage from the wrong phase which could affect the accuracy of power readings (while being close enough to probably not notice).

I've found with A/B/C arrows pointing to the breakers and numbered clamps pointing towards their loads away from the breakers, I need to use *abs on all (invert would probably work). I've still not done any true validation of any of the readings, I'm not relying on my Emporia for anything currently aside from general patterns.

On the subject of the I2C, I'm working just fine with the recommended 400kHZ clock frequency with a timeout of 1ms. However, I'm frustrated that I have no idea why other frequencies aren't working. On a virgin (unconfigured from the factory) Vue 3, I believe I measured an I2C clock of 100kHz. I can only guess that we are dealing with some quirk of ESPHome here. It doesn't seem to be a requirement of the hardware as far as I can tell and would appreciate any thoughts on this.

That is a good observation on the 100kHz, I hadn't measured anything yet. I don't think it's a quirk of ESPHome itself, but rather the esp-idf version it is using, as that was also the source of breakage from the previous kHz configuration.

This whole thing is sill in the collect enough / verify stage that no official action has been taken yet.

[DrSpaldo]

My electricians will be installing this in a few months, we are using 3 phase in Australia. I hope that all these things are confirmed by then 😃

[Cossid]

So I just learned that there is actually a Vue 3 branch now on the official repo, I wasn't previously aware of that I guess, that changes some things in my response. But I don't think long term this should be managed as separate branches, hopefully we'll find a way to merge them in the long term.

[Cossid]

Well, that's why the manual doesn't say anything... they changed the norms. Typically CT clamps either say K->L or Load ->, but they instead put Breaker -> which is not normal. That seems to be a big source of confusion.

[Cossid]

Source of direction confusion...
My clamps:

Another user's clamps:

I have the ones with "Load ->" and they are actually inverted.
It appears they caught the error and just changed the label? (but did it wrong)

And now when we talk about arrows, it's kind of meaningless without their label text.

Edit: But it shouldn't change the actual reading, because it doesn't change the polarity, when the label changes, the arrow changes, but you wouldn't install either any differently by how they're labeled.

More editing: So it appears the first batch like mine say Load -> are are actually inverted. They corrected it by swapping the wire color coming out of the CT, and when they did that, they changed the labeling to be <- Breaker and those should be correct by virtue of the wires being swapped, despite the label change not changing how you'd install the clamps.

I should also note I'm also using some non-Emporia clamps, and those work great.

So, it seems they got the labeling wrong on the initial batch, corrected the wiring, but also changed the labeling completely. This explains a ton on why we have so many differing interpretations of what the arrows means, why some are getting inverted results and other aren't, etc.

[CJOWood]

Received my Vue 3 a few days ago and got around to flashing it last night... Didn't feel like soldering and did not have needle probes or a bdm frame... So I made do. I am equally proud and disgusted with myself :).

The electrician is coming in 2 days to install. Id like to test it before then. Can I just hook up L1 and N to my bench power to get the device running?

I was getting ESPHome brownout messages when powering it from my USBTTL.

[Ocramius]

That's horrible! I love it!

[bobzer]

so did it work well ?

[clowrey]

Yes just jam the L1 and L2 wires into any AC socket ;)

[CJOWood]

so did it work well ?

Haha, depends on what you mean by "well". It was a very delicate balance but it did technically work. Vue 3 is in the panel with 13 out of 16 circuits monitored. Still figuring out what things are on which circuit (inherited a mess of a labeled panel) and things are very tight because the electricians didn't trim the wires.

[cranky-coder]

I got esphome to flash. Then it said "no improv wifi serial". It doesn't start an ap or anything. So I am not entirely sure what the next step here is. Anyone run into this?

[digiblur]

I got esphome to flash. Then it said "no improv wifi serial". It doesn't start an ap or anything. So I am not entirely sure what the next step here is. Anyone run into this?

Did you include the AP in your yaml config of the bin you flashed?

You can check what is going on by removing GPIO 0 from ground on the device, opening a serial port at 115200 and see what's up with it.

[ProjectPatatoe]

I recommend not soldering to GPIO 0 and instead just stick a probe into it since it'll lean against the hole and stay in anyways. Soldering a lead will cause the ethernet to fail to connect for testing since its like an antenna and the frequencies for ethernet are too high/sensitive.

I am having trouble with the i2c error 3. i just get console spam about it not working.
I've tried the frequency and timeout change but no difference either way. I am using pins 5 and 18.

Also anyone confirm about the pinouts for speaker and LEDs and buzzer? It doesn't seem like either work.

[ProjectPatatoe]

Installed 2024.9.2 but still no luck ):

[bobzer]

Hi,
Thanks everyone for all the documentation and all the hardwork that you did.
I got a vue3 and I try to flash it but always get a timeout error.
I tried a few different way, but all end up the same timeout result.

on the screenshot :
red dot is when it get a timeout,
first try is with a basic but custom firmware
second try is the button prepare for first use
any advice ?

[ProjectPatatoe]

I don't know how much I can contribute to this problem.
But heres what worked for me:
I flashed it using the esphome command from cmd in windows/python and not via the browser. After the initial flash, I've been able to upload OTA still with cmd in windows/python. I've never done via the browser.

[bobzer]

I am trying with the cli but so far it doesn't correctly communicate 😞

esptool.py --baud 115200 flash_id
esptool.py v4.8.1
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: d0:ef:76:60:3f:28
Uploading stub...
Running stub...
Stub running...
WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.
Manufacturer: 00
Device: 0000
Detected flash size: Unknown
Flash voltage set by a strapping pin to 3.3V
Hard resetting via RTS pin...

I tried to plug or not the IO0 and reset with the EN pin, no change

[bobzer]

the even stranger part is that this seem to works :

esptool.py -b 115200 read_flash 0 0x800000 flash_contents.bin
esptool.py v4.8.1
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: d0:ef:76:60:3f:28
Stub is already running. No upload is necessary.
WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.
Configuring flash size...
8388608 (100 %)
8388608 (100 %)
Read 8388608 bytes at 0x00000000 in 783.8 seconds (85.6 kbit/s)...
Hard resetting via RTS pin...

even if I got the same warning

EDIT: just seems to... just realize that the file only contains 00

[ProjectPatatoe]

Are you sure you have the wiring correct? Take the IO0 via to ground to get it into a mode you can flash to. The esphome tries to automate setting the IO0 pin which works if you plug it in to whatever adapter youre using. Didn't work for me but I didn't really care. The boot mode selection is only checked once during powerup so you need to reboot after you change it.

My process was:

1. plug all gnd,TX,RX in to adapter
2. plug IO0 to ground
3. plug 3.3v to boot
4. flash
5. take 3.3v off
6. take IO0 off
7. plug in 3.3v
8. normal boot

If you soldered a wire to the IO0 pad, ethernet will not work until you remove the wire as the loose wire makes ether unreliable.

[bobzer]

thanks for trying to help me,
I went with probes to not solder anything.
And I do have some communication, since it can see the kind of esp32.
I'm pretty sure it's hardware problem because i have a second unit and I did the same thing but it went very well
I don't know if the hardware problem is my fault but anyway I'm gonna try to replace the unit and be fine hopefully

[bobzer]

Hi everyone,
I search sometimes to get a yaml that have everything working (or almost no solar panel nor third phase) and use an ethernet port, so I end up with a mix and match of multiple yaml to create mine
many thanks to everyone, that contribute to this project
I figure it could help some other people, so here we go.
Please feel free to comment on anything 👍

# - https://digiblur.com/2024/03/14/emporia-vue-gen3-esp32-esphome-home-assistant/
# - https://github.com/emporia-vue-local/esphome?tab=readme-ov-file#writing-configuration

substitutions:
  name: emporia-vue3-1
  friendly_name: emporia vue3 1
  area: "Maison"

  # Circuit Labels used for publishing to Home Assistant
  circuit_1:  "Circuit 1"
  circuit_2:  "Circuit 2"
  circuit_3:  "Circuit 3"
  circuit_4:  "Circuit 4"
  circuit_5:  "Circuit 5"
  circuit_6:  "Circuit 6"
  circuit_7:  "Circuit 7"
  circuit_8:  "Circuit 8"
  circuit_9:  "Circuit 9"
  circuit_10: "Circuit 10"
  circuit_11: "Circuit 11"
  circuit_12: "Circuit 12"
  circuit_13: "Circuit 13"
  circuit_14: "Circuit 14"
  circuit_15: "Circuit 15"
  circuit_16: "Circuit 16"

  # Icons for Home Assistant
  icon_circuit: "mdi:power-plug"
  icon_current: "mdi:current-ac"
  icon_meter:   "mdi:meter-electric"
  icon_phase:   "mdi:angle-acute"
  icon_power:   "mdi:transmission-tower-import"
  icon_voltage: "mdi:transmission-tower"

esphome:
  name: ${name}
  area: ${area}
  friendly_name: ${friendly_name}
  name_add_mac_suffix: false

external_components:
  # UPDATES FOR Vue 3
  - source: github://emporia-vue-local/esphome@vue3
    components:
      - emporia_vue

esp32:
  board: esp32dev
  framework:
    type: esp-idf
    version: recommended

preferences:
  # the default of 1min is far too short--flash chip is rated
  # for approx 100k writes.
  flash_write_interval: "48h"

# Enable logging
logger:
  logs:
    # by default, every reading will be printed to the UART, which is very slow
    # This will disable printing the readings but keep other helpful messages
    sensor: INFO

# Enable Home Assistant API
api:
  encryption:
    key: "YOUR ENCRYPTION KEY"

safe_mode:
  disabled: false

ota:
  platform: esphome
  password: "YOUR PASSWORD"
  on_error:
    then:
      - button.press: safe_mode_button

#wifi:
#  ssid: !secret wifi_ssid
#  password: !secret wifi_password

  # Enable fallback hotspot in case wifi connection fails
#  ap:
#    ssid: "emporia-vue-3-1"
#    password: !secret fallback_password

ethernet:
  type: RTL8201
  mdc_pin: GPIO32
  mdio_pin: GPIO33
  clk_mode: GPIO0_IN
  # Optional manual IP
#  manual_ip:
#    static_ip: x.x.x.x
#    gateway: x.x.x.x
#    subnet: 255.255.255.0
text_sensor:
  - platform: ethernet_info
    ip_address:
      name: ESP IP Address
    dns_address:
      name: ESP DNS Address
    mac_address:
      name: ESP MAC Address


# Configure the two status LEDs on the Emporia Vue v3 case
# https://github.com/emporia-vue-local/esphome/discussions/264#discussioncomment-9788390
light:
  - platform: status_led
    #name: "D3_LED"
    id: wifi_led
    #pin: 2
    pin:
      number: 2
      ignore_strapping_warning: true
    restore_mode: ALWAYS_OFF
    #entity_category: config
  - platform: status_led
    #name: "D31_LED"
    id: ethernet_led
    pin: 4
    restore_mode: ALWAYS_OFF
    #entity_category: config

# The restart button platform allows you to restart your node remotely through Home Assistant.
button:
  - platform: restart
    name: Restart
    id: restart_button
    icon: mdi:restart

  - platform: safe_mode
    name: Restart (Safe Mode)
    id: safe_mode_button
    icon: mdi:restart-alert

i2c:
  sda: 5
  scl: 18
  scan: false
  # recommended range is 50-200kHz
  #frequency: 200kHz
  # https://github.com/emporia-vue-local/esphome/commit/019f5494130432059b6ab2156716e7e85aac4d5e
  frequency: 400kHz
  timeout: 1ms
  id: i2c_a

# The preferred way to get time in ESPHome is using Home Assistant. This is used for the daily energy use calculation.
time:
  - platform: homeassistant

# these are called references in YAML. They allow you to reuse
# this configuration in each sensor, while only defining it once
.defaultfilters:
  # throttle_avg - emporia-vue-local
  - &throttle_avg
    # average all raw readings together over a 5 second span before publishing
    throttle_average: 5s
  - &throttle_time
    # only send the most recent measurement every 60 seconds
    throttle: 60s

  # moving_avg - digitalblur
  - &moving_avg
    # we capture a new sample every 0.24 seconds, so the time can
    # be calculated from the number of samples as n * 0.24.
    sliding_window_moving_average:
      # we average over the past 2.88 seconds
      window_size: 24
      # we push a new value every 1.44 seconds
      send_every: 12
  - &invert
    # invert and filter out any values below 0.
    lambda: 'return max(-x, 0.0f);'
  - &pos
    # filter out any values below 0.
    lambda: 'return max(x, 0.0f);'
  - &abs
    # take the absolute value of the value
    lambda: 'return abs(x);'
  - &zero
    # Use for disconnected circuits to return 0
    lambda: "return 0.0f;"
  - &double
    # Use to double the measurement for 240V breakers
    multiply: 2

sensor:
  - platform: emporia_vue
    i2c_id: i2c_a
    phases:
      # Verify that this specific phase/leg is connected to correct input wire color on device listed below
      - id: phase_a
        # Vue device wire color
        input: BLACK
        # 0.022 is used as the default as starting point but may need adjusted to ensure accuracy
        calibration: 0.01916
        # To calculate new calibration value use the formula <in-use calibration value> * <accurate voltage> / <reporting voltage>
        voltage:
          name: "Phase A Voltage"
          filters: [*pos, *pos]
        frequency:
          name: "Phase A Frequency"
          filters: [*throttle_avg, *pos]
      # Verify that this specific phase/leg is connected to correct input wire color on device listed below
      - id: phase_b
        # Vue device wire color
        input: RED
        # 0.022 is used as the default as starting point but may need adjusted to ensure accuracy
        calibration: 0.01912
        # To calculate new calibration value use the formula <in-use calibration value> * <accurate voltage> / <reporting voltage>
        voltage:
          name: "Phase B Voltage"
          filters: [*moving_avg, *pos]
        phase_angle:
          name: "Phase B Phase Angle"
          filters: [*throttle_avg, *pos]
    ct_clamps:
      # Do not specify a name for any of the power sensors here, only an id. This leaves the power sensors internal to ESPHome.
      # These non-throttled power sensors are used for accurately calculating energy.
      # Copy sensors defined later will filter and then send power measurements to Home Assistant.

      # Main Service CT Clamps (up to 3)
      # Verify the correct input on the device is connected to the CT clamp phase defined (Vue 3 inputs are inverted)
      - { input: "A", phase_id: phase_a, power: { id: phase_a_power, filters: *invert } }
      - { input: "B", phase_id: phase_b, power: { id: phase_b_power, filters: *invert } }
      # - { input: "C", phase_id: phase_c, power: { id: phase_c_power, filters: *invert } }

      # Circuit CT Clamps (up to 16)
      # Pay close attention to set the phase_id for each breaker by matching it to the phase/leg it connects to in the panel
      # Use *abs filter to always take the positive absolute value
      # Use *invert filter for inverted positive values (Vue 3 inputs are inverted) or *zero for un-used inputs
      # Use *double filter for double (240v) breakers (this will assume power is evenly divided between the two legs)
      # example for double breaker
      #- { phase_id: phase_a, input: "9", power: { name: "Breaker 2a", id: circuit_9, filters: [ *moving_avg, *invert, multiply: 2 ] } }
      # example for phase b
      #- { phase_id: phase_b, input: "10", power: { name: "Breaker 2b - XYZ", id: circuit_10, filters: [ *moving_avg, *invert ] } }
      - { input: "1",  phase_id: phase_a, power: { id: c1_pwr,  filters: [ *abs ] }, current: { id: c1_cur } }
      - { input: "2",  phase_id: phase_a, power: { id: c2_pwr,  filters: [ *abs ] }, current: { id: c2_cur } }
      - { input: "3",  phase_id: phase_a, power: { id: c3_pwr,  filters: [ *abs ] }, current: { id: c3_cur } }
      - { input: "4",  phase_id: phase_a, power: { id: c4_pwr,  filters: [ *abs ] }, current: { id: c4_cur } }
      - { input: "5",  phase_id: phase_a, power: { id: c5_pwr,  filters: [ *abs ] }, current: { id: c5_cur } }
      - { input: "6",  phase_id: phase_a, power: { id: c6_pwr,  filters: [ *abs ] }, current: { id: c6_cur } }
      - { input: "7",  phase_id: phase_a, power: { id: c7_pwr,  filters: [ *abs ] }, current: { id: c7_cur } }
      - { input: "8",  phase_id: phase_a, power: { id: c8_pwr,  filters: [ *abs ] }, current: { id: c8_cur } }

      # Unused CT clamp inputs are explicitly set to zero (*zero filter) to avoid phantom readings
      - { input: "9",  phase_id: phase_a, power: { id: c9_pwr,  filters: [ *zero ]}, current: { id: c9_cur,  filters: [ *zero ] } }
      - { input: "10", phase_id: phase_a, power: { id: c10_pwr, filters: [ *zero ]}, current: { id: c10_cur, filters: [ *zero ] } }
      - { input: "11", phase_id: phase_a, power: { id: c11_pwr, filters: [ *zero ]}, current: { id: c11_cur, filters: [ *zero ] } }
      - { input: "12", phase_id: phase_a, power: { id: c12_pwr, filters: [ *zero ]}, current: { id: c12_cur, filters: [ *zero ] } }
      - { input: "13", phase_id: phase_a, power: { id: c13_pwr, filters: [ *zero ]}, current: { id: c13_cur, filters: [ *zero ] } }
      - { input: "14", phase_id: phase_a, power: { id: c14_pwr, filters: [ *zero ]}, current: { id: c14_cur, filters: [ *zero ] } }
      - { input: "15", phase_id: phase_a, power: { id: c15_pwr, filters: [ *zero ]}, current: { id: c15_cur, filters: [ *zero ] } }
      - { input: "16", phase_id: phase_a, power: { id: c16_pwr, filters: [ *zero ]}, current: { id: c16_cur, filters: [ *zero ] } }

    # Update total power and balance power readings at the same time.
    on_update:
      then:
        - component.update: total_power
        - component.update: balance_power

      
  # The total power sensor will be updated after all power sensors update via on_update trigger.
  - platform: template
    name: "Total Power"
    lambda: return id(phase_a_power).state + id(phase_b_power).state;
    id: total_power
    update_interval: never
    device_class: power
    state_class: measurement
    unit_of_measurement: "W"

  # The balance power sensor will be updated after all power sensors update via on_update trigger.
  - platform: template
    id: balance_power
    update_interval: never
    device_class: power
    state_class: measurement
    unit_of_measurement: "W"
    lambda: !lambda |-
      return max(0.0f, id(total_power).state
        - id( c1_pwr).state
        - id( c2_pwr).state
        - id( c3_pwr).state
        - id( c4_pwr).state
        - id( c5_pwr).state
        - id( c6_pwr).state
        - id( c7_pwr).state
        - id( c8_pwr).state
        - id( c9_pwr).state
        - id(c10_pwr).state
        - id(c11_pwr).state
        - id(c12_pwr).state
        - id(c13_pwr).state
        - id(c14_pwr).state
        - id(c15_pwr).state
        - id(c16_pwr).state
      );

  # Copy sensors to publish the each power state to Home Assistant.
  - { platform: copy, name: "Phase A Power", source_id: phase_a_power, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_power }
  - { platform: copy, name: "Phase B Power", source_id: phase_b_power, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_power }
  - { platform: copy, name: "Total Power",   source_id: total_power,   filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_power }
  - { platform: copy, name: "Balance Power", source_id: balance_power, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_power }
  - { platform: copy, name: "${circuit_1} Power",  source_id: c1_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_2} Power",  source_id: c2_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_3} Power",  source_id: c3_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_4} Power",  source_id: c4_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_5} Power",  source_id: c5_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_6} Power",  source_id: c6_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_7} Power",  source_id: c7_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_8} Power",  source_id: c8_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_9} Power",  source_id: c9_pwr,  filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_10} Power", source_id: c10_pwr, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_11} Power", source_id: c11_pwr, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_12} Power", source_id: c12_pwr, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_13} Power", source_id: c13_pwr, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_14} Power", source_id: c14_pwr, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_15} Power", source_id: c15_pwr, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }
  - { platform: copy, name: "${circuit_16} Power", source_id: c16_pwr, filters: *throttle_avg, accuracy_decimals: 0, icon: $icon_circuit }

  # Copy sensors to publish the each current state to Home Assistant.
  - { platform: copy, name: "${circuit_1} Current",  source_id: c1_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_2} Current",  source_id: c2_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_3} Current",  source_id: c3_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_4} Current",  source_id: c4_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_5} Current",  source_id: c5_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_6} Current",  source_id: c6_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_7} Current",  source_id: c7_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_8} Current",  source_id: c8_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_9} Current",  source_id: c9_cur,  filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_10} Current", source_id: c10_cur, filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_11} Current", source_id: c11_cur, filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_12} Current", source_id: c12_cur, filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_13} Current", source_id: c13_cur, filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_14} Current", source_id: c14_cur, filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_15} Current", source_id: c15_cur, filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }
  - { platform: copy, name: "${circuit_16} Current", source_id: c16_cur, filters: *throttle_avg, accuracy_decimals: 1, icon: $icon_current }

  # The total daily energy sensors to be published to Home Assistant
  - { platform: total_daily_energy, name: "Total Daily Energy", power_id: total_power,     filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "Balance Daily Energy", power_id: balance_power, filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_1} Daily Energy",  power_id: c1_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_2} Daily Energy",  power_id: c2_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_3} Daily Energy",  power_id: c3_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_4} Daily Energy",  power_id: c4_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_5} Daily Energy",  power_id: c5_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_6} Daily Energy",  power_id: c6_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_7} Daily Energy",  power_id: c7_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_8} Daily Energy",  power_id: c8_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_9} Daily Energy",  power_id: c9_pwr,  filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_10} Daily Energy", power_id: c10_pwr, filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_11} Daily Energy", power_id: c11_pwr, filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_12} Daily Energy", power_id: c12_pwr, filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_13} Daily Energy", power_id: c13_pwr, filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_14} Daily Energy", power_id: c14_pwr, filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_15} Daily Energy", power_id: c15_pwr, filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }
  - { platform: total_daily_energy, name: "${circuit_16} Daily Energy", power_id: c16_pwr, filters: *throttle_time, accuracy_decimals: 0, restore: false, icon: $icon_meter }

[bobzer]

PS: not super happy with the usage of the led, but no much idea of what to do with it ?
maybe could put a sticker on the wifi one to label it differently and have 2 usefull led ? 1 for the ethernet connected and the other one for ... i don't know what ... working ?

[oliv3r]

Afaik io0 is also used as the ethernet phy 50mhz clock signal, so grounding it will kill the clock and thus the phy wont run ...