Awesome, thanks. The reason I would prefer on the same device is to limit extra wifi devices. Between esphome, openbeken and some other random IoT devices, I’m around 90 ish devices connected to wifi.
I’ve been slowly combining esps and removing devices that had a single task to clear up the airwaves a bit. Not sure if it will solve my problem of congestion (in a city, neighbours are close), but it’s a start.
I’ll upload the code tonight and check. Just a fyi for anyone else reading this, you need to flash the esp with a cable when switching between Arduino and esp-idf (different partition layouts). Idk if it will fail or actually flash OTA when switching and just act weird, I’m just going off the esphome docs for that info.
This is news to me! In my brief testing, I did OTAs back and forth and it seemed to work fine… I had even renamed the sensor entities, so I know it didn’t just fail the OTA and boot the old version.
I think your right, I just checked docs and no mention. IIRC, someone was helping me troubleshoot an issue and told me that’s what esphome called for, it worked, so I stuck with it.
I think the only thing needed, if a person is having issues, is to clean build files. Which is great news because I’ve been taking devices down or out of places that were a PITA, when I could of just used OTA.
Hey, I have been experiencing the no-solar issue as well in SDGE but just monitoring this thread in case there was progress. But, I can’t find the original firmware, anybody got a link or such so that I can try this out?
I played with the code and inspected raw payloads from v2 and I’m confident the data wasn’t there in my case. In fact, after reverting to stock v2, Emporia app didn’t see the solar production either. Reverting to stock to do an MGM upgrade was a last resort but I think it’s necessary to resolve this issue. (Short of reverse-engineering the MGM upgrade process, but that doesn’t seem worth it.)
As far as reprovisioning, the MGM’s keys got wiped when the stock firmware upgraded MGM firmware. From the logs it looks like Emporia has code to backup & restore provisioning keys, but it failed. It’s still a mystery to me why I had to reprovision after swapping back to esphome, but NBD.
But it is also complaining that it needs to be moved closer to the meter now, so I’ll move it away from the place where it worked great for the last couple months to see if it starts working. Annoying that SDGE gave up on these and no longer supports them, not sure I can re-provision it again if I need to.
I was getting a 30s update interval even with the “fast_reporting” or even with removing the sensor filters from the config. The only way I could get more frequent results was by adding “update_interval” like you have. Doing 5 seconds now and it’s going great.
That’s indeed risky! I’m still curious and hopeful the older MGM firmwares still reported solar/energy production as a separate field in the payload. I know ccd said they didn’t see a field (in V2) but perhaps V4 has it? If you could share some payloads with me, I can take a look and see if we can get this working without an MGM update.
I’d need a full “Meter Response Bytes” payload captured in the morning and another in the evening, and of course it has to be for a day where at least some solar energy was sent to the grid.
The payload output lines I’m looking for is for example:
[10:15:30][D][emporia_vue_utility:377]: Meter Response Bytes 0 to 3: 18 9a 01 00
<more lines>
[10:15:30][D][emporia_vue_utility:377]: Meter Response Bytes 148 to 151: 2a 3a f1 ff
If you’re using the OP’s firmware, I believe the first meter read upon boot will print this output but the rest of the reads will not. Otherwise, in the version I made (disclaimer: I never got to test if my version still works for anything below MGM firmware v7) will print it on every read if you include " debug: true" in the sensor YAML config.
The implementation of “fast_reporting” does not speed up the poll rate to the meter. It’s for overriding the 5 minute throttle interval because the OP did not want to have every reading reported/saved to HA. I kept it in the example YAMLs, but I personally don’t use “fast_reporting” in my YAML at all:
Yes, I realize what the intended goal of the “fast_reporting” is. However, I’m pointing out (in case someone was in the same boat) that I couldn’t get below 30-sec intervals with the button or even if I removed the filters altogether.
I wanted more frequent readings, and I saw your config with the “update_interval”, and it was the only way to get the device to provide 5-second readings. This “update_interval” line IS NOT mentioned in the example_config.yaml on the github nor on this discussion page. So thanks!
Got it, yeah the documentation could use some work. Thanks for pointing it out! I’ll add a section to the README to break down all the options for the YAML config.
So, I moved the Vue all around, no connection, put it back where it was and let it sit for a couple of days and I noticed that it had re-connected to the meter.
So, as the sun was coming up this morning I captured a couple of logs. The watts reading has always been correct, with negative watts feeding back, but the watt-hours produced is always zero. Oh, is the MGM firmware version (reported to be 4) supposed to match the payload version (2)? Or is the version keyword overloaded…
Here it is with some solar production:
[08:44:43][D][emporia_vue_utility:718]: Sending request for meter reading
[08:44:43][D][emporia_vue_utility:293]: Parsing V2 Payload
[08:44:43][D][sensor:094]: 'Watt-hours Consumed': Sending state 96.00000 Wh with 0 decimals of accuracy
[08:44:43][D][sensor:094]: 'Watt-hours Produced': Sending state 0.00000 Wh with 0 decimals of accuracy
[08:44:43][D][sensor:094]: 'Watts': Sending state -173.00000 W with 0 decimals of accuracy
[08:44:43][D][sensor:094]: 'Watts Returned': Sending state 173.00000 W with 0 decimals of accuracy
[08:44:43][D][emporia_vue_utility:315]: Meter Divisor: 1
[08:44:43][D][emporia_vue_utility:316]: Meter Cost Unit: 1000
[08:44:43][D][emporia_vue_utility:318]: Meter Flags: 31 33
[08:44:43][D][emporia_vue_utility:319]: Meter Energy Flags: 06
[08:44:43][D][emporia_vue_utility:320]: Meter Power Flags: 00
[08:44:43][D][emporia_vue_utility:322]: Meter Timestamp: 235962
[08:44:43][D][emporia_vue_utility:323]: Meter Energy: 117311.952kWh
[08:44:43][D][emporia_vue_utility:324]: Meter Power: -173W
[08:44:43][D][emporia_vue_utility:333]: Meter Response Bytes 4 to 7: 06 fe 09 cd
[08:44:43][D][emporia_vue_utility:333]: Meter Response Bytes 44 to 47: 00 00 00 01
[08:44:43][D][emporia_vue_utility:333]: Meter Response Bytes 48 to 51: 00 00 03 e8
[08:44:43][D][emporia_vue_utility:333]: Meter Response Bytes 52 to 55: 31 33 00 00
[08:44:43][D][emporia_vue_utility:333]: Meter Response Bytes 56 to 59: 00 ff ff 52
[08:44:43][D][emporia_vue_utility:333]: Meter Response Bytes 148 to 151: 5e 80 10 0e
And a couple of minutes earlier with some consumption:
[08:35:13][D][emporia_vue_utility:718]: Sending request for meter reading
[08:35:13][D][emporia_vue_utility:293]: Parsing V2 Payload
[08:35:13][D][sensor:094]: 'Watts': Sending state 606.00000 W with 0 decimals of accuracy
[08:35:13][D][sensor:094]: 'Watts Consumed': Sending state 606.00000 W with 0 decimals of accuracy
[08:35:13][D][emporia_vue_utility:315]: Meter Divisor: 1
[08:35:13][D][emporia_vue_utility:316]: Meter Cost Unit: 1000
[08:35:13][D][emporia_vue_utility:318]: Meter Flags: 31 33
[08:35:13][D][emporia_vue_utility:319]: Meter Energy Flags: 06
[08:35:13][D][emporia_vue_utility:320]: Meter Power Flags: 00
[08:35:13][D][emporia_vue_utility:322]: Meter Timestamp: 235398
[08:35:13][D][emporia_vue_utility:323]: Meter Energy: 117311.920kWh
[08:35:13][D][emporia_vue_utility:324]: Meter Power: 606W
[08:35:13][D][emporia_vue_utility:333]: Meter Response Bytes 4 to 7: 06 fe 09 af
[08:35:13][D][emporia_vue_utility:333]: Meter Response Bytes 44 to 47: 00 00 00 01
[08:35:13][D][emporia_vue_utility:333]: Meter Response Bytes 48 to 51: 00 00 03 e8
[08:35:13][D][emporia_vue_utility:333]: Meter Response Bytes 52 to 55: 31 33 00 00
[08:35:13][D][emporia_vue_utility:333]: Meter Response Bytes 56 to 59: 00 00 02 5e
[08:35:13][D][emporia_vue_utility:333]: Meter Response Bytes 148 to 151: e3 e1 07 0e
These were just as the solar panels started production, so let me know if I should check at more extreme times.
Oh, is the MGM firmware version (reported to be 4) supposed to match the payload version (2)? Or is the version keyword overloaded…
Yes it’s overloaded, we don’t know how many versions of the payload there are or if they have an actual associated version, so we just use the reported version of the MGM firmware.
And I see… looks like it’s correct to say that there is no apparent additional field in your payload to correspond to energy sent to the grid. Thanks for sharing though!
My device is suddenly not able to connect to my meter. I get “join response value: 1” and I’m not sure what that means.
This device has been working for over 2.5 years without being touched. I looked at the LED’s and the link LED is off, the other two are on.
I went ahead and flashed the new firmware (from nekorevend; I had been using jrouvier’s file up until now) just to see if it made any difference, and it did not.
I’ve contacted my utility and am awaiting a phone call back, nobody seems to know anything about zigbee or home area networks so I don’t have high hopes. I got lucky 2.5 years ago when I had it provisioned that I got connected to someone who knew something about it. I’m hoping a re-provision will fix it but I’m not sure why it would suddenly stop working.
This is the error message I’m getting now. If anyone has any ideas please let me know.
[17:38:10][I][emporia_vue_utility:677]: Join response value: 1
[17:38:38][D][emporia_vue_utility:718]: Sending request for meter reading
[17:38:41][I][emporia_vue_utility:725]: MGM Firmware Version: 2
[17:38:41][I][emporia_vue_utility:726]: MGM Mac Address: <redacted>
[17:38:41][I][emporia_vue_utility:727]: MGM Install Code: <redacted> (secret)
[17:38:41][I][emporia_vue_utility:730]: Trying to re-join the meter. If you continue to see this message
[17:38:41][I][emporia_vue_utility:732]: you may need to move the device closer to your power meter or
[17:38:41][I][emporia_vue_utility:734]: contact your utililty and ask them to reprovision the device.
[17:38:41][I][emporia_vue_utility:736]: Also confirm that the above mac address & install code match
[17:38:41][I][emporia_vue_utility:737]: what is printed on your device.
[17:38:41][E][emporia_vue_utility:738]: You can also try asking for help at
[17:38:41][E][emporia_vue_utility:742]: https://community.home-assistant.io/t/emporia-vue-utility-connect/378347
[17:38:41][W][component:237]: Component emporia_vue_utility.sensor took a long time for an operation (73 ms).
[17:38:41][W][component:238]: Components should block for at most 30 ms.
[17:38:41][I][emporia_vue_utility:677]: Join response value: 1
Otherwise, my 2 cents: My meter bugged out early on when I got the Vue Utility. I had to convince the utility to send someone out to replace my meter entirely, which did the trick.
Thanks for that feedback. I will move it around and see if anything changes. I have a spare Vue sitting around because I ran into issues the first time setting it up, but it turned out to be an issue with provisioning by my utility provider. If I can’t get it to work I’ll have them re-provision with the spare device, and then I can push on a meter swap if it still isn’t working.
My issue was my fault, sort of. I reverted to emporia original firmware and when the emporia esp32 firmware went to update the mgm firmware, there was an issue. I reflashed the esphome hardware and left the mgm chip in bootloader mode.
So, if you do revert to original e.lpria firmware, and the first time it goes to update the mgm zigbee firmware and fails, it will say “update failed, the update will be performed automatically later, please power cycle device”. Just power cycle and leave it be for awhile, the esp32 firmware will eventually update the mgm chip to the latest mgm Igbee firmware.
Even on the new board I got, the same thing happened but I waited for the esp to update the mgm and it all worked out.
More than likely it needs a re provision, that’s not surprising. Just don’t brick your devices like I did. Although, emporia took care of me anyways.
Following up on my issue: It is now solved and working again. It just took getting my utility to remove and then re-add my device. They said it could take up to 24 hours but it started working again about 5 minutes after I hung up the phone. The most difficult part was just getting hold of someone who knew what I was talking about.
Thanks for sharing though!