Setting up Emporia Vue 2 with ESPHome

Setting up Emporia Vue 2 with ESPHome.md

These instructions have moved to https://github.com/emporia-vue-local/esphome

Oh! missed that part of the documentation.

You didn't, I only wrote it just now :)

I'd need to see error logs to know what's wrong. If you're not able to compile anything ESPHome, I'd suggest reaching out on discord or their forums.

@flaviut here's my log;

INFO Reading configuration /config/esphome/emporiavue2.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing emporiavue2 (board: esp32dev; framework: espidf; platform: platformio/espressif32 @ 3.5.0)
--------------------------------------------------------------------------------
Tool Manager: Installing platformio/toolchain-esp32ulp @ ~1.22851.0
Error: Could not find the package with 'platformio/toolchain-esp32ulp @ ~1.22851.0' requirements for your system 'linux_aarch64'

Looks like you are still on a 64Bit system.

…

Am 05.05.2022 um 08:30 schrieb Fran6u ***@***.***>: ***@***.*** commented on this gist. @flaviut here's my log; INFO Reading configuration /config/esphome/emporiavue2.yaml... INFO Generating C++ source... INFO Compiling app... Processing emporiavue2 (board: esp32dev; framework: espidf; platform: platformio/espressif32 @ 3.5.0) Tool Manager: Installing platformio/toolchain-esp32ulp @ ~1.22851.0 Error: Could not find the package with 'platformio/toolchain-esp32ulp @ ~1.22851.0' requirements for your system 'linux_aarch64' — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

@flaviut, @Gagi2k So I have installed a new HA + Esphome (32bit) on a RPI3 and tried compiling, but still having errors (different from the previous). Here is the new error, any ideas?

HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf 3.40302.0 (4.3.2) 
 - tool-cmake 3.16.9 
 - tool-ninja 1.10.2 
 - toolchain-riscv32-esp 8.4.0+2021r2-patch2 
 - toolchain-xtensa-esp32 8.4.0+2021r2-patch2 
 - toolchain-xtensa-esp32s2 8.4.0+2021r2-patch2
Reading CMake configuration...
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- The ASM compiler identification is unknown
-- Found assembler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc -- broken
-- Configuring incomplete, errors occurred!
See also "/data/emporiavue2/.pioenvs/emporiavue2/CMakeFiles/CMakeOutput.log".
See also "/data/emporiavue2/.pioenvs/emporiavue2/CMakeFiles/CMakeError.log".

fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
CMake Error at /data/cache/platformio/packages/tool-cmake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "/data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /data/emporiavue2/.pioenvs/emporiavue2/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/data/cache/platformio/packages/tool-ninja/ninja cmTC_33678 && [1/2] Building C object CMakeFiles/cmTC_33678.dir/testCCompiler.c.obj
    FAILED: CMakeFiles/cmTC_33678.dir/testCCompiler.c.obj 
    /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc   -mlongcalls -Wno-frame-address -o CMakeFiles/cmTC_33678.dir/testCCompiler.c.obj   -c testCCompiler.c
    /bin/sh: 1: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc: not found
    ninja: build stopped: subcommand failed.
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  /data/cache/platformio/packages/framework-espidf/tools/cmake/project.cmake:311 (__project)
  CMakeLists.txt:3 (project)  >

@Fran6u last person who ran into this said that they thought they ran out of memory: https://gist.github.com/flaviut/93a1212c7b165c7674693a45ad52c512?permalink_comment_id=4147507#gistcomment-4147507

I think the issue might be esphome/issues#3076, which apparently will be resolved "soon" :(

You could try building and installing from a desktop/laptop.

@flaviut Just a feedback. I was eventually able to compile the code manually on a laptop running Ubuntu. Many thanks for your help

What can we do to remove the platform restriction, I see that you have it set to only compile on the esp-idf platform. but most users won't have a development environment setup using their desktop, and will be running esphome on a pi,

I noticed that there are issues reading the sensors from the i2c bus when you remove the esp-idf restriction and compile with the arduino platform.

My thought is it's best to make things as accessible as possible for as many as possible.
otherwise great work! it seems to be running pretty solidly on my emporia vue 2

Great question @cpyarger. The reason things are running on esp-idf is because the esp32-arduino project did not support i2c messages longer than 256 bytes. This has been resolved in one of the patch releases of v2.0: espressif/arduino-esp32@7bb30b3

And very recently, it looks like platformio has been updated to also support esp32-arduino v2.0: platformio/platform-espressif32@581c7d0

However, I don't think that switching to esp32-ardunio will be helpful because v2 is based on esp-idf. I'm not sure what the problem here is exactly, but I think someone will need to fix it rather than try and work around it.

@flaviut thanks a lot for this project! though my power for one 200A clamp is nonsense:(right part of graph is raw data without filter)

and power for the other 200A clamp is fine

will incorrect clamp direction cause this?(I'm pretty sure I followed the instruction and they look similar to the image posted in above discussions)
and also does phase A need BLACK as hardcoded or as long as everything is consistent then it's fine? since I find that my black is connected to right/B panel, and red is connected to left/A panel. I just changed them in yaml as well.

@kerhbal that's definitely not incorrect clamp direction. Is everything plugged completely? I found that the clamp connector likes getting lose.

If that's not the problem, are you on a 2 of 3 legs system? In North America, that's usually multi-family homes, commercial, and industrial situations. Do you have the colored wires lined up correctly with the phases in your config?

@flaviut my bad... I accidentally plugged my phase A to C socket, after change it now the power is all good. this is wonderful, thanks!

very happy to be off the hook from their cloud lol, who knows when they unplug the server...

@flaviut Hi. So after installation I noticed my reading seems to be a decimal out of place (lower than expected) How do you recommend I fix this? Screenshot attached.

@flaviut Hi. So after installation I noticed my reading seems to be a decimal out of place (lower than expected) How do you recommend I fix this?

Not sure I understand what's going on. If it's a 5% or so error, you can tune the calibration values.

If it's something else, same advice as before: make sure all connections are tight and maybe all clamps are fully closed

@flaviut It seems to be measuring energy at 10% fraction. And the calibration only affects the voltage and not the energy use.
Also, I seem to be recording values on "circuits 1 & 16" which has no sensors plugged in. Thanks in advance.

I'm really not sure what the problem might be. Sometimes the cables look plugged in, but they're just slightly unplugged. You can try using a multimeter to carefully debug things.

And you should remove the channels you don't use from the config. It's expected to see gibberish data on them.

I'm really not sure what the problem might be. Sometimes the cables look plugged in, but they're just slightly unplugged. You can try using a multimeter to carefully debug things.

And you should remove the channels you don't use from the config. It's expected to see gibberish data on them.

I will just start afresh; take it all apart and re-install. Hopefully i would find the issue/issues.

Sounds like a plan—just make sure to remember to update us when you find the solution! That way things are easier for whoever runs into this next.

…

On Fri, May 13, 2022, 23:37 Fran6u ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ I'm really not sure what the problem might be. Sometimes the cables look plugged in, but they're just slightly unplugged. You can try using a multimeter to carefully debug things. And you should remove the channels you don't use from the config. It's expected to see gibberish data on them. I will just start afresh; take it all apart and re-install. Hopefully i would find the issue/issues. — Reply to this email directly, view it on GitHub <https://gist.github.com/93a1212c7b165c7674693a45ad52c512#gistcomment-4166323>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHY2HNT4MGRAPGBYABX3OTVJ3DQDANCNFSM5LVAHT6A> . You are receiving this because you were mentioned.Message ID: <flaviut/Setting up Emporia Vue 2 with ***@***.***>

This is an excellent piece of work. I have 4 Vue 2s and have ordered another to flash.

The hardware measures data every ¼ second, so you have quite a bit to work with. You do need to remove the sliding_window_moving_average since you do not want smoothed-out data.

Is there any way that the individual CTs can be calibrated/filtered individually? For some I need to catch the motor start spikes and for others the sliding_window_moving_average will be more appropriate.

Are any of the GPIOs still available to be used? I'm considering adding the Home Assistant Glow progect in to the Vue.

Keep up the excellent work!

Is there any way that the individual CTs can be calibrated/filtered individually?

Yes: the &foo and *foo is just a shorthand, as is the [a, b, c]. Each sensor has a set of filters, see https://esphome.io/components/sensor/index.html for details.

Are any of the GPIOs still available to be used?

I haven't checked, but I expect them to be available. Just I2C is used for communication. For me, the UL listing was a big part of why I went with this device over a DIY one, and making that kind of modification would make it no longer listed

Where should I be seeing "&foo and *foo is just a shorthand, as is the [a, b, c]".

They're not in my yaml from the example.

foo is a placeholder. *moving_avg for example.

This is probably a stupid question, but I see a few changes have been made to the configuration. Most notably, the calibration piece for phase a/b voltage. Anyway, I would need to change my current config and install like normal or does anything else need to be done? Assuming none of the sensor names change should everything continue to work as usual?

Thanks

If I remember correctly, there have been no backwards incompatible changes to the configuration. You are welcome to use your existing config. New options would just be filled in with reasonable defaults.

@ccpk1 Ohhh, I like the balance/other power section. Someone I know is going to steal that. =)

I also added this in my HA configuration.yaml:

template:
  - sensor:
      - name: "Home Total Power"
        unit_of_measurement: "W"
        device_class: power
        state: >
          {{ [ states('sensor.home1_total_power'), 
               states('sensor.home2_total_power') ]
               | map('float') | sum }}
        availability: >
          {{ not 'unavailable' in 
             [ states('sensor.home1_total_power'), 
               states('sensor.home1_total_power') ] }}

This was stolen/merged from a couple sources but gives a nice single total power for the house for graphing/metering. It would be easy to make home_total_energy, but the stock Energy dashboard is happy enough adding a couple things so... shrug

Forgive my templating ignorance. Is this adding sensor.home1_total_power and sensor.home2_total_power to give Home Total Power and the 'availabilty' checks that both sensors are available before doing the SUM?

Is this adding sensor.home1_total_power and sensor.home2_total_power to give Home Total Power and the 'availabilty' checks that both sensors are available before doing the SUM?

I believe that's right, and that it works using the availability key. I can't find the appropriate documentation however.

If you do find it, I'd appreciate it if you'd come back and share it here!

I'm seeing some odd behaviour that I don't understand.

In the screen shot above it shows voltage at 240, power at 0 and current at 0.63.
Where is the current coming from?

My config is as below:

esphome:
  name: emporia-main

external_components:
  - source: github://flaviut/esphome@emporia-vue-2022.4.0
    components: [ emporia_vue ]

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

# Enable Home Assistant API
api:

ota: 
  safe_mode: true
  password: !secret OTA_password

# Enable logging
logger:

wifi:
  ssid: !secret dryderdale_wifi_SSID
  password: !secret dryderdale_wifi_password

i2c:
  sda: 21
  scl: 22
  scan: false
  frequency: 200kHz  # recommended range is 50-200kHz
  id: i2c_a
time:
  - platform: sntp
    id: my_time

# these are called references in YAML. They allow you to reuse
# this configuration in each sensor, while only defining it once
.defaultfilters:
  - &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: 12
      # we push a new value every 1.44 seconds
      send_every: 6
  - &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);'
  - &multiply # Current scaling factor
    lambda: 'return x * 0.01;'

sensor:
  - platform: emporia_vue
    i2c_id: i2c_a
    phases:
      - id: main_house_phase  # Verify that this specific phase/leg is connected to correct input wire color on device listed below
        input: BLACK  # Vue device wire color
        calibration: 0.022  # 0.022 is used as the default as starting point but may need adjusted to ensure accuracy
        # To calculate new calibration value use the formula <in-use calibration value> * <accurate voltage> / <reporting voltage>
        voltage:
          name: "Main House Voltage"
          filters: [*moving_avg, *pos]
      # - id: phase_b  # Verify that this specific phase/leg is connected to correct input wire color on device listed below
      #   input: RED  # Vue device wire color
      #   calibration: 0.022  # 0.022 is used as the default as starting point but may need adjusted to ensure accuracy
      #   # 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]
    ct_clamps:
      - phase_id: main_house_phase
        input: "C"  # Verify the CT going to this device input also matches the phase/leg
        power:
          name: "Main House Power"
          id: main_house_power
          device_class: power
          filters: [*moving_avg, *pos]
        current:
          name: "Main house current"
          id: main_house_current
          device_class: current
          filters: [*moving_avg, *pos, *multiply]
      # - phase_id: phase_b
      #   input: "B"  # Verify the CT going to this device input also matches the phase/leg
      #   power:
      #     name: "Phase B Power"
      #     id: phase_b_power
      #     device_class: power
      #     filters: [*moving_avg, *pos]
      # Pay close attention to set the phase_id for each breaker by matching it to the phase/leg it connects to in the panel
      - { phase_id: main_house_phase, input:  "1", power: { name:  "Hob Power", id:  cir1, filters: [ *moving_avg, *pos ] } }
      - { phase_id: main_house_phase, input:  "2", power: { name:  "Oven/Microwave Power", id:  cir2, filters: [ *moving_avg, *pos ] } }
      - { phase_id: main_house_phase, input:  "3", power: { name:  "Kitchen sockets Power", id:  cir3, filters: [ *moving_avg, *pos ] } }
      # - { phase_id: main_house_phase, input:  "4", power: { name:  "Dining room & lounge sockets Power", id:  cir4, filters: [ *moving_avg, *pos ] } }
      # - { phase_id: main_house_phase, input:  "5", power: { name:  "First floor sockets Power", id:  cir5, filters: [ *moving_avg, *pos, multiply: 2 ] } }
      # - { phase_id: main_house_phase, input:  "6", power: { name:  "Main House Water Heater Power", id:  cir6, filters: [ *moving_avg, *pos, multiply: 2 ] } }
      # - { phase_id: main_house_phase, input:  "7", power: { name:  "Hall lights Power", id:  cir7, filters: [ *moving_avg, *pos, multiply: 2 ] } }
      # - { phase_id: main_house_phase, input:  "8", power: { name:  "Lounge/Dining/Cloaks lights Power", id:  cir8, filters: [ *moving_avg, *pos ] } }
      # - { phase_id: main_house_phase, input:  "9", power: { name:  "First floor lights Power", id:  cir9, filters: [ *moving_avg, *pos ] } }
      # - { phase_id: main_house_phase, input: "10", power: { name: "Mains cupboard light Power", id: cir10, filters: [ *moving_avg, *pos ] } }
      # - { phase_id: main_house_phase, input: "11", power: { name: "Attic WiFi Power", id: cir11, filters: [ *moving_avg, *pos, multiply: 2 ] } }
      # - { phase_id: main_house_phase, input: "12", power: { name: "Intruder alarm Power", id: cir12, filters: [ *moving_avg, *pos, multiply: 2 ] } }
      # - { phase_id: main_house_phase, input: "13", power: { name: "Basement lights Power", id: cir13, filters: [ *moving_avg, *pos ] } }
      - { phase_id: main_house_phase, input: "14", power: { name: "Hall socket Power", id: cir14, filters: [ *moving_avg, *pos ] } }
      - { phase_id: main_house_phase, input: "15", power: { name: "Security lights Power", id: cir15, filters: [ *moving_avg, *pos ] } }
      - { phase_id: main_house_phase, input: "16", power: { name: "Charging sockets Power", id: cir16, filters: [ *moving_avg, *pos ] } }
  - platform: template
    name: "Main House Total Power"
    lambda: return id(main_house_power).state; # + id(phase_b_power).state;
    update_interval: 1s
    id: main_house_total_power
    unit_of_measurement: "W"
  - platform: total_daily_energy
    name: "Main House Total Daily Energy"
    power_id: main_house_total_power
    accuracy_decimals: 0
  - { power_id:  cir1, platform: total_daily_energy, accuracy_decimals: 0, name:  "Hob Daily Energy" }
  - { power_id:  cir2, platform: total_daily_energy, accuracy_decimals: 0, name:  "Oven/Microwave Daily Energy" }
  - { power_id:  cir3, platform: total_daily_energy, accuracy_decimals: 0, name:  "Kitchen sockets Daily Energy" }
  # - { power_id:  cir4, platform: total_daily_energy, accuracy_decimals: 0, name:  "Dining room & lounge sockets Daily Energy" }
  # - { power_id:  cir5, platform: total_daily_energy, accuracy_decimals: 0, name:  "First floor sockets Daily Energy" }
  # - { power_id:  cir6, platform: total_daily_energy, accuracy_decimals: 0, name:  "Main House Water Heater Daily Energy" }
  # - { power_id:  cir7, platform: total_daily_energy, accuracy_decimals: 0, name:  "Hall lights Daily Energy" }
  # - { power_id:  cir8, platform: total_daily_energy, accuracy_decimals: 0, name:  "Lounge/Dining/Cloaks lights Daily Energy" }
  # - { power_id:  cir9, platform: total_daily_energy, accuracy_decimals: 0, name:  "First floor lights Daily Energy" }
  # - { power_id: cir10, platform: total_daily_energy, accuracy_decimals: 0, name: "Mains cupboard light Daily Energy" }
  # - { power_id: cir11, platform: total_daily_energy, accuracy_decimals: 0, name: "Attic WiFi Daily Energy" }
  # - { power_id: cir12, platform: total_daily_energy, accuracy_decimals: 0, name: "Intruder alarm Daily Energy" }
  # - { power_id: cir13, platform: total_daily_energy, accuracy_decimals: 0, name: "Basement lights Daily Energy" }
  - { power_id: cir14, platform: total_daily_energy, accuracy_decimals: 0, name: "Hall socket Daily Energy" }
  - { power_id: cir15, platform: total_daily_energy, accuracy_decimals: 0, name: "Security lights Daily Energy" }
  - { power_id: cir16, platform: total_daily_energy, accuracy_decimals: 0, name: "Charging sockets Daily Energy" }

  - platform: template       # Sum of all cir wattages
    name: "Main house Calculated total watts"
    id: calculated_total_watts
    lambda: |-
      return (id(cir1).state + id(cir2).state + id(cir3).state + id(cir14).state + id(cir15).state + id(cir16).state);
    update_interval: 60s
    accuracy_decimals: 0
    # Take the total power and subtract all of the individually monitored circuits which will result in the remaining balance of power that is not individually monitored
  - platform: template
    name: "Main house Balance Power"
    lambda: return max((id(main_house_total_power).state - id(cir1).state - id(cir2).state - id(cir3).state - id(cir14).state - id(cir15).state - id(cir16).state), 0.0f);
    update_interval: 3s
    id: balance_power
    unit_of_measurement: "W"

I've had to add a multiply filter of 0.01 to get sensible current readings as it was showing 28,000 amps at one point!

I've tried to search, has anyone successfully done this to a standard "Emporia Vue" ... the sticker says "Gen 2 Emporia Vue Smart....eter"

@ripvega I'm sorry, but I really don't know what's going on. You shouldn't have to do that multiplication. Maybe try re-flashing, increasing the logging level and posting logs, or double-checking that things are inserted tightly?

@kingdogfish if it looks like this, you should be fine:
. The older model looks different and is neither compatible or possible to add support for here.

Has anyone else noticed erroneous energy spikes and wifi drop-outs using ESPHome v2022.5.0? v2022.4.0 was solid for me.