Emporia Vue Utility Connect

[monkeyst]

That’s so weird, I’ve never seen the two lines disagree. Looking into on_raw_value, it should just correspond to when the code does W->publish_state(watts);. No idea what’s going on, but maybe another log line for on_value as well would help debug:

        on_raw_value:
            then:
                lambda: |-
                    ESP_LOGI("Vue", "Raw Watts = %0.3f", x);
        on_value:
            then:
                lambda: |-
                    ESP_LOGI("Vue", "Filtered Watts = %0.3f", x);

Still always appears to match for me:

[17:31:36][D][Vue:319]: Parsing V7+ Payload
[17:31:36][I][Vue:080]: Raw Watts = 929.000
[17:31:36][D][sensor:094]: 'Meter Watts': Sending state 929.00000 W with 0 decimals of accuracy
[17:31:36][I][Vue:084]: Filtered Watts = 929.000

Also strange is that none of the “Sending state” lines are named. The empty ‘’s should contain what’s in the “name” field in the yaml, such as for:

- name: "Watts"
  id: watts
  unit_of_measurement: "W"
  ... etc ...

it should say
[13:50:33][D][sensor:094]: ‘Watts’: Sending state 435.00000 with 0 decimals of accuracy

Since you have Watts and kWh sensors, I would expect two “Sending state” lines to say those names…

Note: there are seven states: Watts, kWh Consumed, Wh Consumed, kWh Returned, Wh Returned, kWh Net, and Wh Net (not necessarily in that order) and if you don’t have an ESPHome sensor setup to use one of them then it ends up with empty ‘’s and does nothing.

[alexbeatle]

Looks like it fixed itself!? Maybe!?

I added “filtered watts” to logging I turned on the kettle and it came up and logs. The sensor state also reported it in the histogram.

Snapshot of sensor data:

Snipper of the logs with the “filtered_watts”:

[16:48:47][D][Vue:613]: Sending request for meter reading
[16:48:48][D][Vue:319]: Parsing V7+ Payload
[16:48:48][I][Vue:094]: Watts = 464.000
[16:48:48][D][sensor:094]: ‘’: Sending state 75560248.00000 with 0 decimals of accuracy
[16:48:48][D][sensor:094]: ‘’: Sending state 435.00000 with 0 decimals of accuracy
[16:48:48][D][sensor:094]: ‘’: Sending state 75560.25000 with 0 decimals of accuracy
[16:48:48][D][sensor:094]: ‘’: Sending state 0.43500 with 0 decimals of accuracy
[16:48:48][D][sensor:094]: ‘’: Sending state 75559816.00000 with 0 decimals of accuracy
[16:48:48][I][Vue:076]: kWh = 75559.812
[16:48:48][W][component:214]: Component took a long time for an operation (0.06 s).
[16:48:48][W][component:215]: Components should block for at most 20-30ms.
[16:48:48][D][Vue:613]: Sending request for meter reading
[16:48:49][D][Vue:319]: Parsing V7+ Payload
> [16:48:49][I][Vue:094]: Watts = 1713.000
> [16:48:49][D][sensor:094]: ‘Watts’: Sending state 1713.00000 W with 0 decimals of accuracy
> [16:48:49][I][Vue:098]: Filtered Watts = 1713.000
[16:48:49][D][sensor:094]: ‘’: Sending state 75560256.00000 with 0 decimals of accuracy
[16:48:49][D][sensor:094]: ‘’: Sending state 435.00000 with 0 decimals of accuracy
[16:48:49][D][sensor:094]: ‘’: Sending state 75560.25781 with 0 decimals of accuracy
[16:48:49][D][sensor:094]: ‘’: Sending state 0.43500 with 0 decimals of accuracy
[16:48:49][D][sensor:094]: ‘’: Sending state 75559824.00000 with 0 decimals of accuracy
[16:48:49][I][Vue:076]: kWh = 75559.820
[16:48:49][W][component:214]: Component took a long time for an operation (0.07 s).
[16:48:49][W][component:215]: Components should block for at most 20-30ms.
[16:48:49][D][Vue:613]: Sending request for meter reading
[16:48:50][D][Vue:319]: Parsing V7+ Payload
[16:48:50][I][Vue:094]: Watts = 1713.000
[16:48:50][D][sensor:094]: ‘’: Sending state 75560256.00000 with 0 decimals of accuracy
[16:48:50][D][sensor:094]: ‘’: Sending state 435.00000 with 0 decimals of accuracy
[16:48:50][D][sensor:094]: ‘’: Sending state 75560.25781 with 0 decimals of accuracy
[16:48:50][D][sensor:094]: ‘’: Sending state 0.43500 with 0 decimals of accuracy
[16:48:50][D][sensor:094]: ‘’: Sending state 75559824.00000 with 0 decimals of accuracy
[16:48:50][I][Vue:076]: kWh = 75559.820
[16:48:50][W][component:214]: Component took a long time for an operation (0.05 s).
[16:48:50][W][component:215]: Components should block for at most 20-30ms.
[16:48:50][D][Vue:613]: Sending request for meter reading
[16:48:51][D][Vue:319]: Parsing V7+ Payload
[16:48:51][I][Vue:094]: Watts = 1713.000

[monkeyst]

It’s so strange that there isn’t a corresponding “Filtered Watts” to each “Watts”, considering you don’t have any filters enabled right?

I tried a 1 second poll rate and I get an equal number of each log, though for some reason you are able to get more frequent value changes? My wattage reading stays identical for 15 seconds at a time.

Anyway, I’m pretty stumped but perhaps you can try adding another log line into the parse_meter_watts_v7 function:

nekorevend/esphome-emporia-vue-utility/blob/21b4753cbd24bbff352966599d1cf9bbf0abdac4/src/emporia_vue_utility.h#L552C17-L552C41

I’d add this log line above the publish_state on line 552:

ESP_LOGD(TAG, "Publishing watts value %d", watts);
W->publish_state(watts);

If you end up seeing more “Publishing watts value” than “Filtered Watts” then something is up with ESPHome lol.

[alexbeatle]

This is my config.
The only filters are throttle and delta.
I set refresh rate in the head file to 1s.
I’ll add the other logging and see what happens. For some reason wireless updates don’t work for me, so need to hook up programmer each time.

####################################################
# config for homes without solar / wind production #
####################################################

esphome:
    name: vue-utility
    platform: ESP32
    board: esp-wrover-kit
    includes:
        - emporia_vue_utility.h

# Add your own wifi credentials
wifi:
    ssid: !secret wifi_ssid
    password: !secret wifi_password
    
     # Enable fallback hotspot (captive portal) in case wifi connection fails
    ap:
      ssid: "Vue-Utility Fallback Hotspot"
      password: "************"

ota:
  password: "************"

logger:
    logs:
        # Change to DEBUG / INFO / WARN / ERROR as desired
        Vue: DEBUG

# Enable Home Assistant API
api:
  encryption:
    key: "************"

#mqtt:
#    broker: !secret mqtt_broker
#    id: vue_utility
#    username: !secret mqtt_username
#    password: !secret mqtt_password
#    discovery: False # Only if you use the HA API usually

# This uart connects to the MGM111
uart:
    id: emporia_uart
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200

sensor:
    - platform: custom
      lambda: |-
        auto vue = new EmporiaVueUtility(id(emporia_uart));
        App.register_component(vue);
        return {vue->kWh_net, vue->W};
      sensors:
          - name: "kWh"
            id: kwh
            unit_of_measurement: "kWh"
            accuracy_decimals: 3
            state_class: total_increasing
            device_class: energy
            # Reduce the rate of reporting the value to
            # once every 5 minutes and/or when 0.1 kwh
            # have been consumed, unless the fast_reporting
            # button has been pushed
            filters:
                - or:
                    - throttle: 5min
                    - delta: 0.1 # <- kWh
                    - lambda: |-
                        if (id(fast_reporting)) return(x);
                        return {};
            on_raw_value:
                then:
                    lambda: |-
                        ESP_LOGI("Vue", "kWh = %0.3f", x);
          - name: "Watts"
            id: watts
            unit_of_measurement: "W"
            accuracy_decimals: 0
            state_class: measurement
            device_class: power
            # Report every 5 minutes or when +/- 20 watts
            filters:
                - or:
                    - throttle: 5min
                    - delta: 5  # <- watts
                    - lambda: |-
                        if (id(fast_reporting)) return(x);
                        return {};
            on_raw_value:
                then:
                    lambda: |-
                        ESP_LOGI("Vue", "Watts = %0.3f", x);
            on_value:
                then:
                    lambda: |-
                        ESP_LOGI("Vue", "Filtered Watts = %0.3f", x);


# This gives you a button that temporarily causes results to be
# reported every few seconds instead of on significant change
# and/or every 5 minutes
button:
    - platform: template 
      name: "Fast Reporting"
      id: fast_reporting_button
      on_press:
        - lambda: id(fast_reporting) = true;
        - delay: 5min
        - lambda: id(fast_reporting) = false;

# Global value for above button
globals:
    - id: fast_reporting
      type: bool
      restore_value: no
      initial_value: "false"

# This LED is marked D3 on the pcb and is the power led on the case
status_led:
    pin:
        number: GPIO25
        # It *is* inverted, but being normally on looks better
        inverted: false

[monkeyst]

I see, I would completely comment out the filters: block as a sanity check. Ideally that works just as expected and then you can figure out a filter config that works for you.

If wireless updates are broken for you, I wonder if it’s best to up or downgrade the ESPHome version you’re running? Maybe your current version has a bug… FWIW my version is 2023.12.9. What error message do you get anyway?

EDIT: If you have web_server enabled:

web_server:
  port: 80

You can also try updating through the web UI:

I forget if it wants the “Legacy” or “Modern” format file, so try both.

[baudneo]

My vue utility connect has suddenly stopped reading the meter. In the debug esphome logs it does not show MGM firmware or the MAC address:

[18:57:54][I][Vue:504]: MGM Firmware Version: 0
[18:57:54][I][Vue:505]: MGM Mac Address:  
[18:57:54][I][Vue:506]: MGM Install Code:  (secret)
[18:57:54][I][Vue:507]: Trying to re-join the meter.  If you continue to see this message
[18:57:54][I][Vue:508]: you may need to move the device closer to your power meter or
[18:57:54][I][Vue:509]: contact your utililty and ask them to reprovision the device.
[18:57:54][I][Vue:510]: Also confirm that the above mac address & install code match
[18:57:54][I][Vue:511]: what is printed on your device.
[18:57:54][E][Vue:512]: You can also file a bug at
[18:57:54][E][Vue:513]:   https://forms.gle/duMdU2i7wWHdbK5TA
[18:57:54][W][component:232]: Component <unknown> took a long time for an operation (57 ms).
[18:57:54][W][component:233]: Components should block for at most 30 ms.
[18:57:54][D][Vue:446]: Got meter join response

It says it receives a meter join response, but nothing happens after that.

This happened randomly out of nowhere, no power loss or anything. I have the meter techs trying to re-add the device without success.

Has anyone else seen this behaviour? It seems weird the MGM chip just kind of fails randomly wihtout warning or cause.

I do have a backup of the stock emporia firmware I amg oing to reflash and then do a MGM reset. Hopefully that will revive whatever comms or error is happening on the MGM chip itself.

IIRC, I was on MGM firmware version 2.

Edit: It seems to me that there is the possibility of a bug in the C code? From a brief look over, there are utilities to request MAC, firmware version, install code, etc. I dont know C and have only played with it a bit.

I am guessing that the esp needs to request the firmware, MAC and install code data before it populates the vars with the received data. The ‘meter join response’ seems to indicate it is receiving data from the MGM chip →

                    case 'j': // Meter reading (JOIN - baudneo)
                        handle_resp_meter_join();
                        led_wifi(true);
                        if (startup_step == 3) {
                            send_meter_request();
                            startup_step++;
                        }
                        break;

The handle_resp_meter_join() func is only a log msg, so it fires no matter what if it receives a join repsonse →

        void handle_resp_meter_join() {
            ESP_LOGD(TAG, "Got meter join response");
        }

I need to go through the code some more to see if there is a spot where the ESP is supposed to supply MAC, install or whatever data in order to properly receive data or do a proper join?

Any insight from someone with more C experience would be great.

[baudneo]

Ok nix most of the guessing on my last post, after rebooting the device a few times I am now seeing MAC address, firmware version and install code correctly.

Has anyone had to re-pair the device to the meter after flashing esphome to it? Does it work automatically, or do I need to restore the stock emporia firmware and let the emporia firmware handle the pairing request?

I added some debug logging for the meter join response:

[20:19:59][D][Vue:578]: DEBUG METER RESPONSE -> Full packet as HEX:
[20:19:59][D][esp-idf:000]: E (51971) Vue: 0x3ffb2bb4   24 01 6a 01 01 0d                                 |$.j...|

According to the project protocol docs,

24 = msg start ($)
01 = this msg is a response to a request we sent the MGM chip
6a = msg type (j = meter join)
01 = payload length
01 = payload
0d = end of msg (\r)

I can only get the meter tech to try and provision my device on weekdays (so Tuesday, as Monday is a holiday) while I am at work. I can remotely mess with things on my phone, but it is a pita to change C code using vscode add-on via companion app. I tried before using software reboot button in hass entities. I can also plug it into a zigbee plug to hard power cycle the device.

AFAIK the provision window only lasts a few hours, and they usually do it in the AM.

[monkeyst]

It is my understanding that:

• The MGM chip is solely responsible for being “paired” with the meter.
• None of the changes discussed in this thread ever touch the MGM’s firmware or configuration.
• Pairing is done entirely on the meter’s side by telling the utility company what your MGM’s MAC address and install code are and they tell your meter to talk to your specific MGM chip.
• The firmware on the ESP32 does not impact the pairing status, regardless of if it’s running ESPHome or stock.
  • Which is by design since jrouvier sniffed what the stock firmware sends to the MGM and made the ESPHome version send the same commands.
  • The messages that either firmware sends to the MGM chip is always the same upon boot:
    1. 24 6D 0D: Ask for the MGM’s MAC address.
    2. 24 66 0D: Ask for the MGM’s firmware version.
    3. 24 69 0D: Ask for the MGM’s install code.
    4. 24 6A 0D: Ask the MGM to join the meter.
    5. 24 72 0D: Ask the MGM for the latest meter reading.
    6. Repeat #5 indefinitely. If #5 fails then #4 is resent periodically.
  • Note that none of these commands provide any extra bits of information that could tell the MGM that the ESP32’s firmware had changed from stock to ESPHome or vice versa.

All of that is to say: it is impossible for an ESP32 firmware change to ever necessitate re-pairing your device with the meter because the MGM chip never knew the difference and is never given anything to change its configuration (unless the stock firmware was giving the MGM a firmware update, but that’s not the case for us on ESPHome where the MGM’s firmware would be frozen in time).

Any sort of pairing issue is ultimately an issue on the meter’s side (or some physical aspect like being within signal range).

As for the response you see from the meter join, I have observed that a payload value of 01 is the normal/success case and have only ever observed it saying 00 when it has never been paired with a meter before. Note that it will continue to reply with 01 even if the device is not in range of the meter, so it isn’t really a live-updated value - it possibly behaves more like an e-fuse.

Since your MGM had an issue until you rebooted the device a few times, my guess is the MGM chip is becoming unstable. A reboot might have gotten it back to being able to reply to the initial requests for firmware version and stuff, but it is possible that you are observing the meter communication part of the chip still being broken. Or, like my experience earlier in this thread, my meter itself broke and needed to be replaced. It’s just that since your MGM failed to reply to the boilerplate commands, I am leaning that the MGM itself is faulty instead of the meter having an issue.

[baudneo]

Hard to say what the root cause is. The first time the meter tech tried to reprovision, it did start sending data for a few minutes and then stopped.

I have been trying to get the stock firmware flashed back onto the emporia but unfortunately, it is not working. Does esphome overwrite a boot partition or something? When I reflash the stock emporia firmware using:

❯ esptool.py --port /dev/ttyUSB0 --chip esp32 -b 115200 write_flash --flash_freq 80m 0x0 Downloads/vue-connect-stock.bin
esptool.py v4.7.0
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:7e:57:a4
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x000e2fff...
Compressed 927728 bytes to 575457...
Wrote 927728 bytes (575457 compressed) at 0x00000000 in 50.9 seconds (effective 145.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

It completes and says the hash is fine but when I power it up again, it seems to be running esphome code because the power LED starts to flash slowly (warning) for about 10-30 seconds and then it starts to flash rapidly. (error) This seems to indicate that esphome status led code is still running? Unless emporia firmware does the same kind of power LED flashing?

I have the emporia firmware from when MGM firmware was version: 2. Im wondering if maybe some sort of boot partition or similar is required to boot the stock emporia firmnware? Or perhaps I need to erase the flash first then flash the emporia firmware?

Thanks for the insight and help @monkeyst, it is greatly appreciated.

Edit: I reflashed esphome onto it and there seems to be several flash commands after just the main .bin flash. This leads me to believe I am missing some sort of ‘boot’ partition or similar.

esphome flashing output

INFO Successfully compiled program.
esptool.py v4.7.0
Serial port /dev/ttyUSB1
Connecting.....
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 24:6f:28:7e:57:a4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash will be erased from 0x00010000 to 0x000defff...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Compressed 844624 bytes to 548171...
Wrote 844624 bytes (548171 compressed) at 0x00010000 in 13.0 seconds (effective 519.6 kbit/s)...
Hash of data verified.
Compressed 17440 bytes to 12128...
Wrote 17440 bytes (12128 compressed) at 0x00001000 in 0.6 seconds (effective 242.2 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 144...
Wrote 3072 bytes (144 compressed) at 0x00008000 in 0.1 seconds (effective 381.1 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 512.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
INFO Successfully uploaded program.
INFO Starting log output from /dev/ttyUSB1 with baud rate 115200

Edit: Nvm, was flashing the wrong .bin, I have the original firmware on it and working.

[baudneo]

OK, I flashed stock firmware on and added device. It got caught up at the zigbee firmware upgrade. However, when I power cycled after the failed zigbee upgrade, I can ping the esp32 wifi interface and all 3 LED’s are lit and solid, which according to emporia docs means the wifi and meter are connected. The device shows as offline in the emporia app (due to not finishing install?)

After flashing esphome, I am getting errors, but it does seem to be sending data: empora vue connect output · GitHub

I am hoping it did the zigbee upgrade and that is just the v7+ data structure
throwing errors.

The firmware version is 0, and no MAC or Install code. I am going to flash back to emporia and try and do the zigbee upgrade.

[baudneo]

Well, no luck, the MGM chip seems to be stuck in firmware upgrade mode or something. I am trying to decipher the data it is sending the ESP32. I may set it up as a UART to serial proxy so I can get all the data.

Here is some data I am working on ATM:

# partial struct captures that happen from wireless log viewing via esphome dashboard
0x6f 0x61 0x64 0x20 0x67 0x62 0x6c 0xd
# Full structs
0xa 0x32 0x2e 0x20 0x72 0x75 0x6e 0xd
0xa 0x30 0xd
0xa 0x31 0x2e 0x6c 0x6f 0x61 0x64 0x65 0x72 0x20 0x64 0x20 0x67 0x6c 0xd
0x32 0x2e 0x75 0x6e 0xd
0xa 0x2e 0x20 0x6f 0xa 0x42 0x0 0xd
0x63 0x62 0x20 0x69 0x6e 0x66 0x6f 0x61 0x64 0x33 0x2e 0x20 0x20 0x6e 0x61 0xa 0xa 0x31 0x2e 0x20 0x6f 0x61 0x64 0x20 0x67 0x62 0x6c 0xd
0xa 0x32 0x2e 0x20 0x72 0x75 0xd
0x33 0x69 0x6e 0xd
0x42 0x4c 0x20 0x6e 0xd
0xa 0x33 0x2e 0x20 0x31 0x20 0x75 0x70 0x6c 0x6f 0x2e 0xa 0x42 0x4c 0x20 0x20 0x6f 0xa 0xa 0x47 0x65 0x63 0x6b 0x0 0xd
0xa 0x47 0x65 0x6f 0x69 0x6e 0x4c 0x20 0x75 0x6e 0xd
0xa 0x33 0x75 0x70 0x6c 0x6f 0x61 0x64 0x31 0x2e 0x39 0x2e 0x30 0xd
0xa 0x31 0x2e 0x20 0x75 0x70 0x6c 0x6f 0x64 0x20 0x67 0x62 0x6c 0xd
0xa 0x32 0x2e 0x20 0x72 0x6e 0xd
0xa 0x33 0x20 0x65 0x62 0x6c 0x20 0x66 0x6f 0xd
0xa 0x42 0x4c 0x20 0x3e 0x20 0x0 0xd

From a cursory glance, it seems to have structs that start with 0xa (line feed) and end with 0xd (carriage return). Maybe ive glitched it and something wonderful can come of it (imagine if its dumping its unencrypted firmware out rn, lol) or maybe i bricked it, lol. Either way, it was the emporia firmware that bricked it, so hopefully they can do something about it.

Edit: I’ve flashed it back and forth between stock and esphome while erasing flash completely between each flash a few times now trying to be able to set up the device in the emporia app again, no bueno.

Somehow the emporia firmware still shows 3 solid LED’s for PWR, wifi, and meter link even after an esp32 erase and reflash. I can also ping the esp32 wifi interface and it is grabbing an IP from DHCP. This leads me to believe that the wifi creds are stored in the MGM flash, how else would it be connecting to the AP and grabbing an IP?. I am very confused on whats going on and doing some wild guessing.

When the emporia firmware is flashed onto the device, the 3 LEDs are solid, the reset button does not respond and I can not see the device in my bluetooth scans. Meaning, I cant factory reset it to try and add it back again to restart the zigbee firmware upgrade. The wifi interface is up, grabs an IP from DHCP and is pingable. It seems frozen as the MGM is just blasting data out.

When I flash esphome, only the power LED is solid, the wifi and meter LED’s are off. The esp32 wifi interface is up, grabs an IP from DHCP and is pingable. The MGM chip is sending the data I posted in that gist and the data above. I tried the v7 header file and the data in the code block above is from esphome running the v7 header file, the data in the gist is from the repo header file.

So with emporia and esphome firmware:

• wifi interface is up, grabs an IP from DHCP and is pingable from the LAN.
• MGM UART is blasting data out and seems to inhibit functions on both firmwares.

Keep in mind I am completely erasing the esp32 flash between flashing the firmwares and I have gone back and forth a few times now with the same behaviour. How the hell is the esp32 still connecting to my AP and pulling an IP via DHCP? Is the MGM chip controlling things? I am perplexed.

Edit 2: Seems promising →

Hex to ASCII from the code block above:

oad gbl\r
\n2. run\r
\n0\r
\n1.loader d gl\r
2.u\r
\n. o\nB\r
cb infoad3.  na\n\n1. oad gbl\r
\n2. ru\r
3in\r
BL n\r
\n3. 1 uplo.\nBL  o\n\nGeck\r
\nGeoinL un\r
\n3upload1.9.0\r
\n1. upload gbl\r
\n2. rn\r
\n3 ebl fo\r
\nBL > \r

Yeah, its stuck in bootloader mode:

Gekko Bootloader v1.9.0
1. upload gbl
2. run
3. ebl info
BL >
Gekko Bootloader v1.9.0
1. upload gbl
2. run
3. ebl info
BL >
Gekko Bootloader v1.9.0
1. upload gbl
2. run
3. ebl info
BL >
Gekko Bootloader v1.9.0
1. upload gbl
2. run
3. ebl info
BL >
Gekko Bootloader v1.9.0
1. upload gbl
2. run
3. ebl info
BL >
Gekko Bootloader v1.9.0
1. upload gbl
2. run
3. ebl info
BL >
Gekko Bootloader v1.9.0
1. upload gbl
2. run
3. ebl info

Going to see if i can get a tty to connect to the serial tcp stream and fix things.

[monkeyst]

Very nice investigation! Sucks that the MGM firmware update put it in a bad state… but good luck!

[baudneo]

Emporia refunded me for the purchase price. They were going to send a new one but they don’t do that for Canadian customers, So a refund instead. Think I’ll buy the kingkony AliExpress 16xCT clamp board instead of replacing the vue connect.

Haven’t had time to try and fix the device I have. The “run” and “ebl info” options seem interesting, deff want to take a look at that if I can.

[monkeyst]

It never occurred to me to check AliExpress for a multi-channel CT board, but I could only find this 30 channel model. Can you link the 16 channel one?

[baudneo]

Same price basically, it’s confusing to decipher what they’re selling lol

Kincony KC868-M16 ESP32 16 Channel CT Clamp Energy Monitor no APP control For esphome home assistant
https://a.aliexpress.com/_mtbNM8a

[monkeyst]

[definitely off topic]

I see it uses the audio jack type of plug and would not recommend it. I have the Emporia Vue 2 (as well as the Utility Connect haha) and I’ve had to open up my panel multiple times due to finding out one of the sensors got loose. It’s just a terrible connector for reliability and is probably why the Vue 3 switched to those “Phoenix” plugs.

At least Kincony’s 30 channel model also uses a non-audio-jack connection and should be very reliable. I would go with either the Vue 3 or Kincony’s 30 channel model… both are supported by ESPHome, though the Vue 3 looks like it’s much more of a pain to flash ESPHome onto.

[/definitely off topic]

[baudneo]

Thats some good advice, I was looking at the vue gen 3 and saw it has an ethernet port as well, no point in it being PoE as mains power is right there. Im guessing a person could also spend the time to desolder and resolder terminal blocks or similar?

A happy surprise on my end, they refunded me and also sent a unit out, when I let them know, they said to just keep the old and new units, very nice!

So, the upgrade process failed again but this time, I didnt delete the device from the emporia app, power cycled it and I just left it plugged in. It took a bit, but the esp32 did push a FW update to the MGM chip. My thoughts are that the esp32 downloads the mgm firmware and stores it, then randomly updates it.

I now have a working updated device and the old device stuck in bootloader mode. I havent had time to play with the old device and see if I can get any useful info out of it or fix it. Would be nice if I could get an unencrypted firmware dump, but im not holding my breath.

I now have a spare esp32-WROOM and MGM111 board I can play with at least. When I do try and play around with the old device, I will update this thread with the outcome and any juicy details.

[visualage (Qi Liu)]

Not sure what’s wrong, but I am not able to connect to the ESP32 chip. I am pretty certain that I selected the right voltage (3.3v) for my USB-Serial adapter, and connected the wires in the correct way. I also tried both plugging directly to USB port for power, as well as connect the 5v power from the USB-Serial adapter to the 5v pin. It always complains about some unexpected header value. I can see the stick entered a different mode when trying to read the firmware (all three lights turn solid green). Any suggestion/help would be appreciated. I am using a Apple chip MacBook Pro if that matters.

[visualage (Qi Liu)]

Looks like I need the --before usb_reset argument to esptool.

[jrouvier (Joe Rouvier)]

Hi everyone, original author here. Unfortunately, my current employer prohibits me from working on open source projects. If someone want’s to take over ownership of this I’ll edit the top post URLs to point to their repo.