I see these adapters as commodity items and they should all work, but maybe someone else has a stronger opinion on them. However, I would choose one that lets you change the output voltage. It’s not as relevant for flashing the Emporia but it’d be more versatile for other devices you might want to flash in the future.
Something like this has a jumper selector for what voltage you’d want, but note that it looks like you’d have to buy your own jumper wires.
EDIT: That one looks like the voltage selector changes the voltage both on VCC and on the actual TX, which is weird… Looking at this instead, it doesn’t explicitly say it does that (though it might), but at least one of the user reviews mentions using it on their ESP32!
Also looks like it comes with a ribbon cable, though it is female-female and you’d need male to stick into the holes on the Emporia.
BTW, if you have a Flipper Zero it has a UART function that lets it act as a standard USB-UART adapter.
Thanks for the input. I ended up going with this one which has pins for DTR and RTS as well as separate 3.3V and 5V pins. I have some MtF breadboard jumper wires I’m going to test out. If I can’t tape them down to get a secure connection I have no problems soldering and desoldering. I have been wanting to get a flipper zero, but sadly don’t have one yet. Again, thank you for the response.
I got this flashed last night using @monkeyst fork since that seems to have applied some PR fixes that are not yet merged on the original repo. Watts seem to be reported accurately, but my kWh sensor is inaccurate.
I wish this were accurate but sadly I consume much more power than this
Is the kWh sensor supposed to accumulate? If that is correct, when does it reset? Can it be used to replace sensor.vue_123_1mon for the energy dashboard?
Logs from ESPHome
INFO ESPHome 2023.12.9
INFO Reading configuration /config/emporia-vue.yaml...
INFO Starting log output from 192.168.0.68 using esphome API
INFO Successfully connected to vue-utility @ 192.168.0.68 in 0.268s
INFO Successful handshake with vue-utility @ 192.168.0.68 in 0.041s
[18:11:10][I][app:102]: ESPHome version 2023.12.9 compiled on Jan 27 2024, 17:20:35
[18:11:10][C][status_led:019]: Status LED:
[18:11:10][C][status_led:020]: Pin: GPIO25
[18:11:10][C][wifi:573]: WiFi:
[18:11:10][C][wifi:405]: Local MAC: 24:6F:28:7E:87:14
[18:11:10][C][wifi:410]: SSID: [redacted]
[18:11:10][C][wifi:411]: IP Address: 192.168.0.68
[18:11:10][C][wifi:413]: BSSID: [redacted]
[18:11:10][C][wifi:414]: Hostname: 'vue-utility'
[18:11:10][C][wifi:416]: Signal strength: -49 dB ▂▄▆█
[18:11:10][C][wifi:420]: Channel: 11
[18:11:10][C][wifi:421]: Subnet: 255.255.255.0
[18:11:10][C][wifi:422]: Gateway: 192.168.0.1
[18:11:10][C][wifi:423]: DNS1: 192.168.0.231
[18:11:10][C][wifi:424]: DNS2: 192.168.0.232
[18:11:10][C][logger:439]: Logger:
[18:11:10][C][logger:440]: Level: DEBUG
[18:11:10][C][logger:441]: Log Baud Rate: 115200
[18:11:10][C][logger:443]: Hardware UART: UART0
[18:11:10][C][logger:447]: Level for 'Vue': DEBUG
[18:11:10][C][uart.arduino_esp32:137]: UART Bus 1:
[18:11:10][C][uart.arduino_esp32:138]: TX Pin: GPIO22
[18:11:10][C][uart.arduino_esp32:139]: RX Pin: GPIO21
[18:11:10][C][uart.arduino_esp32:141]: RX Buffer Size: 256
[18:11:10][C][uart.arduino_esp32:143]: Baud Rate: 115200 baud
[18:11:10][C][uart.arduino_esp32:144]: Data Bits: 8
[18:11:10][C][uart.arduino_esp32:145]: Parity: NONE
[18:11:10][C][uart.arduino_esp32:146]: Stop bits: 1
[18:11:10][C][version.text_sensor:021]: Version Text Sensor 'VUE ESPHome Version'
[18:11:10][C][version.text_sensor:021]: Icon: 'mdi:new-box'
[18:11:11][C][mdns:115]: mDNS:
[18:11:11][C][mdns:116]: Hostname: vue-utility
[18:11:11][C][ota:097]: Over-The-Air Updates:
[18:11:11][C][ota:098]: Address: vue-utility.local:3232
[18:11:11][C][api:139]: API Server:
[18:11:11][C][api:140]: Address: vue-utility.local:6053
[18:11:11][C][api:144]: Using noise encryption: NO
[18:11:11][C][mqtt:133]: MQTT:
[18:11:11][C][mqtt:135]: Server Address: 192.168.0.178:1883 (192.168.0.178)
[18:11:11][C][mqtt:136]: Username: [redacted]
[18:11:11][C][mqtt:137]: Client ID: [redacted]
[18:11:11][C][mqtt:142]: Topic Prefix: 'vue-utility'
[18:11:11][C][mqtt:144]: Log Topic: 'vue-utility/debug'
[18:11:11][C][mqtt:147]: Availability: 'vue-utility/status'
[18:11:11][C][mqtt.text_sensor:023]: MQTT Text Sensor 'VUE ESPHome Version':
[18:11:11][C][mqtt.text_sensor:024]: State Topic: 'vue-utility/sensor/vue_esphome_version/state'
[18:11:11][C][mqtt.sensor:028]: MQTT Sensor 'kWh':
[18:11:11][C][mqtt.sensor:032]: State Topic: 'vue-utility/sensor/kwh/state'
[18:11:11][C][mqtt.sensor:028]: MQTT Sensor 'Watts':
[18:11:11][C][mqtt.sensor:032]: State Topic: 'vue-utility/sensor/watts/state'
[18:11:11][C][mqtt.button:029]: MQTT Button 'Fast Reporting':
[18:11:11][C][mqtt.button:030]: State Topic: 'vue-utility/button/fast_reporting/state'
[18:11:11][C][mqtt.button:030]: Command Topic: 'vue-utility/button/fast_reporting/command'
[18:11:21][D][Vue:616]: Sending request for meter reading
[18:11:21][D][Vue:319]: Parsing V7+ Payload
[18:11:21][I][Vue:085]: Watts = 1734.000
[18:11:21][D][sensor:094]: '': Sending state 191236816.00000 with 0 decimals of accuracy
[18:11:21][D][sensor:094]: '': Sending state 0.00000 with 0 decimals of accuracy
[18:11:21][D][sensor:094]: '': Sending state 191236.81250 with 0 decimals of accuracy
[18:11:21][D][sensor:094]: '': Sending state 0.00000 with 0 decimals of accuracy
[18:11:21][D][sensor:094]: '': Sending state 0.00000 with 0 decimals of accuracy
[18:11:21][I][Vue:067]: kWh = 0.000
[18:11:21][W][component:214]: Component <unknown> took a long time for an operation (0.08 s).
[18:11:21][W][component:215]: Components should block for at most 20-30ms.
[18:11:51][D][Vue:616]: Sending request for meter reading
[18:11:51][D][Vue:319]: Parsing V7+ Payload
[18:11:51][I][Vue:085]: Watts = 1737.000
[18:11:51][D][sensor:094]: '': Sending state 191236816.00000 with 0 decimals of accuracy
[18:11:51][D][sensor:094]: '': Sending state 0.00000 with 0 decimals of accuracy
[18:11:51][D][sensor:094]: '': Sending state 191236.81250 with 0 decimals of accuracy
[18:11:51][D][sensor:094]: '': Sending state 0.00000 with 0 decimals of accuracy
[18:11:51][D][sensor:094]: '': Sending state 0.00000 with 0 decimals of accuracy
[18:11:51][I][Vue:067]: kWh = 0.000
[18:11:51][W][component:214]: Component <unknown> took a long time for an operation (0.08 s).
[18:11:51][W][component:215]: Components should block for at most 20-30ms.
Edit: using the original emporia_vue_utility.h (with manually patched #15 PR) I get the following:
[19:16:53][D][Vue:487]: Sending request for meter reading
[19:16:53][E][Vue:237]: Short meter reading packet
[19:16:53][E][Vue:289]: If you continue to see this, please file a bug at
[19:16:53][E][Vue:290]: https://forms.gle/duMdU2i7wWHdbK5TA
[19:16:53][E][Vue:291]: and include a few lines above this message and the data below until "EOF":
[19:16:53][E][Vue:292]: Full packet:
[19:16:53][E][Vue:301]: Meter Response Bytes 0 to 3: 18 e3 01 00
[19:16:53][E][Vue:301]: Meter Response Bytes 4 to 7: 00 00 25 fc
[19:16:53][E][Vue:301]: Meter Response Bytes 8 to 11: 10 66 0b 00
[19:16:53][E][Vue:301]: Meter Response Bytes 12 to 15: 00 01 00 00
[19:16:53][E][Vue:301]: Meter Response Bytes 16 to 19: 25 00 00 00
[19:16:53][E][Vue:301]: Meter Response Bytes 20 to 23: 00 00 00 01
[19:16:53][E][Vue:301]: Meter Response Bytes 24 to 27: 03 00 22 01
[19:16:53][E][Vue:301]: Meter Response Bytes 28 to 31: 00 00 02 03
[19:16:53][E][Vue:301]: Meter Response Bytes 32 to 35: 00 22 e8 03
[19:16:53][E][Vue:301]: Meter Response Bytes 36 to 39: 00 00 04 00
[19:16:53][E][Vue:301]: Meter Response Bytes 40 to 43: 2a a8 04 00
[19:16:53][I][Vue:304]: MGM Firmware Version: 8
[19:16:53][E][Vue:305]: EOF
[19:16:53][W][component:214]: Component <unknown> took a long time for an operation (0.13 s).
[19:16:53][W][component:215]: Components should block for at most 20-30ms.
TL;DR: I’ve pushed a new commit on my fork that should “fix” the behavior. Please copy the new header file. It will give you an ever-increasing kWh usage value as reported by the meter/payload. It does not reset unless there are some resets done by your particular meter. In theory, the value you will see is the total consumption the meter has counted in its entire lifetime.
This might not be the behavior you want but should be more meaningful than what you see now. I’m also not sure if that is the expected sensor behavior for use in HA’s Energy tab. That’s why I put “fix” in quotes in the TL;DR. I use a different source right now for my HA Energy tab so I wouldn’t know. If you do want to use it, give it a shot and see if its behavior is what you’d expect! Let me know and I’ll happily make adjustments if needed.
Anyway, given your log output I expect your “kWh” to now say something like 191236.813 (but will be higher now).
Now I’ll ramble a bit:
What you’ve seen for “kWh” was a “net” value which is the amount of energy that was used (or produced) since the last reading. This is calculated based on the kWh_returned and kWh_consumed readings that are provided by the payload. Depending on how often your meter actually updates these values (@baudneo said theirs updates every 5 minutes despite the “Watts” updating every 5 seconds), this can very often be reported as a 0 change due to no changes in the interim readings. Upon reading the original logic for V2 more carefully, I realize now that their behavior for “net” is totally different. The original “net” behavior doesn’t reset and isn’t representing just the change seen between two readings. What I should do to match its behavior is to make "net" be "total consumed" - "total returned" and call it a day. I’ve made that change on my fork now.
I’ve only had it running for a few minutes, but the value is increasing in what I believe are accurate increments.
I think it takes the energy dashboard a little while to update. I’m guessing I’ll have one large spike to fix, but after that I believe it should display correctly based on the behavior I saw from the emporia cloud API. It didn’t start out at the total value from the meter, but was a constantly increasing value. Yet the dashboard was able to break that down into hourly usage. I didn’t make it past a month, so I’m not sure if it resets monthly or not.
I will have to rethink my energy price template sensor (currently on a tiered rate), but that shouldn’t be a problem.
Thanks for the update! I’ll make a new post or edit this one in a couple days with an update after I’ve had some time to observe.
Update: the kWh sensor is working great with the energy dashboard. I had one spike to clean up with usage and cost (and I haven’t updated the stats pre-update), but it is working exactly as intended.
Bought emporia vue utility connect. Planning to flash it with ESPHome. I decided to link it with my meter with the native firmware first. This required calling my utility company hotline. They weren’t successful, saying that emporia pushed a firmware update earlier this year and I need to upgrade my device firmware before my vue can be linked with the meter. Requested an updated through emporia customer support, waiting for it to complete.
Questions.
How does one do firmware updates in the future or they won’t be needed?
Has anybody experienced comm issues with the vue utility meter to the smart meter lately? Perhaps it’s specific to the North California PG&E utility company.
I am running on the assumption that no firmware updates are needed if the pairing is completed. If not, I suppose just keep a backup of the stock firmware and put it back on and ask them to give it another update down the line? Then back up the updated firmware and hope they didn’t change the payload format again.
Comms with my PG&E meter has been spotty even with the replacement meter and I end up lacking data for hours at a time. See the gaps in the graph over the past 7 days:
Emporia said the update was to accommodate frequent disconnects from the meter, reported by many users. Maybe helpful for you.
After updating emporia firmware PG&E was able to connect me and I see the connection in the app.
Waiting on the USB programmer to flash to ESPHome. Can report back if any issues.
Incidentally, how to backup and restore the stock firmware?
In the Emporia app → Hamburger menu → Manage Devices → [your device] → Vue Info → Scroll to the bottom and see what it says for “Firmware Version:”. Mine says Zigbee-513.
You’ll use esptool, the commands can look like this:
Backup: .\esptool --port COM#? --chip esp32 -b 115200 read_flash 0x0 0x400000 .\vueUtilityConnect_stock.bin
Restore: .\esptool --port COM#? --chip esp32 -b 115200 write_flash --flash_freq 80m 0x0 .\vueUtilityConnect_stock.bin
I suggest also backing up the ESPHome firmware once its fully set up.
So I just flashed my utility connect with the vue-utility.yaml from:
No errors during the build and download. The LEDs seem ok. The device immediately got auto-discovered by HASS in ESPHome, however all values are showing as “unknown”. Pressing the “Fast Reporting” didn’t help.
Maybe it takes some time for them to start refreshing?
I did establish connection with the stock firmware and ran it for a few days.
Thank you for this. I was having the same issue, and with your code I am at least getting some values now.
[16:53:20][W][component:214]: Component took a long time for an operation (0.06 s).
[16:53:20][W][component:215]: Components should block for at most 20-30ms.
This bit is annoying me though, but I suppose there’s nothing to be done about it.
Glad it worked out! I was going to ask for the logs from ESPHome instead of from Home Assistant:
That “Fast Reporting” is something I don’t think needs to exist and I don’t have in my yaml. It isn’t telling the firmware to poll the meter faster, it is just disabling the throttling:
the or means any of the 3 options can return a value and if fast reporting is enabled then it will always return a value, ignoring the throttle and delta options.
The reason you might not notice a difference is probably that the delta between samples is commonly larger than 20W so it’ll report the value every time anyway.
Note that in my fork I had changed the default poll rate to 30 because that is what the stock firmware does.
But you can override it in the yaml. In the case below I overrode it to a 15 second poll rate: auto vue = new EmporiaVueUtility(id(emporia_uart), 15);
15 should be good for you too, as I’ve observed that’s approximately as fast as my PG&E meter will update its value (ie. you can poll faster but the value doesn’t actually change).
I’ve seen that performance complaint a lot in my other ESPHome devices and it just becomes something I ignore haha. The code could absolutely be optimized but it doesn’t seem worth the effort, especially if we’re getting values at a delay from the meter anyway.
I updated the interval to 1s and logs started reporting per the meter. Even short lived bursts get reported (ex. running a small temp controller which turns on the heater for a second or so (1.3kW) - that shows in the logs).
This however did not translate to the values in the sensor, even though delta>20.
I commented out the filter section for testing. I see the values update much faster on the sensor, yet still not as fast as in the logging - the small bursts of power from the heater aren’t reported.
Interesting, so regarding seeing values in the logging, you mean something like this right?
[15:51:17][D][Vue:319]: Parsing V7+ Payload
[15:51:17][I][Vue:080]: Watts = 430.000
[15:51:17][D][sensor:094]: 'Meter Watts': Sending state 430.00000 W with 0 decimals of accuracy
I’m not aware of anything past that that would be slowing down the rate of reporting to the sensor in HA, especially since you commented out the filters…
For these two lines, is one showing up less often than the other?
[15:51:17][I][Vue:080]: Watts = 430.000
[15:51:17][D][sensor:094]: 'Meter Watts': Sending state 430.00000 W with 0 decimals of accuracy
Yep. The few watts=1310.000 shown in the logs (few seconds or so), get filtered out of the sensor value.
13:50:31][D][Vue:613]: Sending request for meter reading
[13:50:31][D][Vue:319]: Parsing V7+ Payload
[13:50:31][I][Vue:094]: Watts = 1310.000
[13:50:31][D][sensor:094]: ‘’: Sending state 75492176.00000 with 0 decimals of accuracy
[13:50:31][D][sensor:094]: ‘’: Sending state 435.00000 with 0 decimals of accuracy
[13:50:31][D][sensor:094]: ‘’: Sending state 75492.17969 with 0 decimals of accuracy
[13:50:31][D][sensor:094]: ‘’: Sending state 0.43500 with 0 decimals of accuracy
[13:50:31][D][sensor:094]: ‘’: Sending state 75491744.00000 with 0 decimals of accuracy
[13:50:31][I][Vue:076]: kWh = 75491.742
[13:50:31][W][component:214]: Component took a long time for an operation (0.05 s).
[13:50:31][W][component:215]: Components should block for at most 20-30ms.
[13:50:32][D][Vue:613]: Sending request for meter reading
[13:50:32][D][Vue:319]: Parsing V7+ Payload
[13:50:32][I][Vue:094]: Watts = 1310.000
[13:50:32][D][sensor:094]: ‘’: Sending state 75492176.00000 with 0 decimals of accuracy
[13:50:32][D][sensor:094]: ‘’: Sending state 435.00000 with 0 decimals of accuracy
[13:50:32][D][sensor:094]: ‘’: Sending state 75492.17969 with 0 decimals of accuracy
[13:50:32][D][sensor:094]: ‘’: Sending state 0.43500 with 0 decimals of accuracy
[13:50:32][D][sensor:094]: ‘’: Sending state 75491744.00000 with 0 decimals of accuracy
[13:50:32][I][Vue:076]: kWh = 75491.742
[13:50:32][W][component:214]: Component took a long time for an operation (0.05 s).
[13:50:32][W][component:215]: Components should block for at most 20-30ms.
[13:50:33][D][Vue:613]: Sending request for meter reading
[13:50:33][D][Vue:319]: Parsing V7+ Payload
[13:50:33][I][Vue:094]: Watts = 1310.000
[13:50:33][D][sensor:094]: ‘’: Sending state 75492176.00000 with 0 decimals of accuracy
[13:50:33][D][sensor:094]: ‘’: Sending state 435.00000 with 0 decimals of accuracy
[13:50:33][D][sensor:094]: ‘’: Sending state 75492.17969 with 0 decimals of accuracy
[13:50:33][D][sensor:094]: ‘’: Sending state 0.43500 with 0 decimals of accuracy
[13:50:33][D][sensor:094]: ‘’: Sending state 75491744.00000 with 0 decimals of accuracy
[13:50:33][I][Vue:076]: kWh = 75491.742
[13:50:33][W][component:214]: Component took a long time for an operation (0.05 s).
[13:50:33][W][component:215]: Components should block for at most 20-30ms.
[13:50:34][D][Vue:613]: Sending request for meter reading
[13:50:34][D][Vue:319]: Parsing V7+ Payload
[13:50:34][I][Vue:094]: Watts = 508.000
