Not sure that this is the correct place to be asking this question but here goes anyway
I have an Emporia Vue 2 which is a really nice piece of kit, well made and reliable.
I do however have a few issues:
Unfortunately they do not make it easy to get local data from the unit as there is no local offload and everything has to be via their cloud server using preferably their phone app.
If you have any connectivity issues it is a big problem as you cannot get any data from the unit.
There is no official API so Home Assistant integration is via a non-official method
There is a restriction on the number of times you can query their server per day which limits the number of 1min interval update calls you can make.
As a result I have been looking for some advice on perhaps reflashing the unit with some alternate firmware that would enable me to send data straight to my MQQT server and not sure if that would even be possible.
I’ve never come across one of those and I can’t remember seeing the name mentioned here.
I think you’ve discovered the real problem with commercial units: while they work and do what you want, they’re (usually) fine, even though many have questionable accuracy in ‘difficult’ conditions. But when the manufacturer goes out of business, the website disappears and all your historic data vanishes instantly. Or worse, they decide that data has a value and have you over a barrel when they charge you to access your own data.
My recommendation, if you want flexibility and (importantly) you have the knowledge and aptitude to find out how it works and figure out how to extend the capabilities, is to go down the open-source route.
Look around this site, and feel free to ask any questions. There’s usually somebody able to answer reasonably promptly.
Thank you Robert, you are 100% correct, buying some open hardware is my next option
The Emporia Vue appears to have a ESP32 microprocessor in it, not sure what A/D converter it is using but am thinking I may open my one up to check. Would be nice if I could just change the firmware but will see what happens.
Unless you can find somebody who has already done the work and published it, then you’ll need to reverse-engineer the hardware - at least far enough to understand the functions you’re going to need to use, so that you know what your software needs to do. That could be a significant task.
I didn’t find that page until after I got mine independently working using the same basic idea but a different flow to generate the updated firmware image. I tried quite a few more dead ends than the author of the blog linked above - to save anyone the trouble, the obvious idea of downloading the firmware, and then using a hex editor to change the SSID, password and MQTT server in the firmware image and then uploading it does not work. It doesn’t pass Espressif’s NVS cyclical redundancy checks (CRC) because the data doesn’t match the hash and it gives an NVS_READ_ERR. So you sort of have to do something similar to what is outlined in the blog to get this to work - my method is different but a lot of the flow is the same and I haven’t actually written it up like the blog author did. But once it works, though, you get exactly what one would want - which is a completely local solution which doesn’t use the cloud at all, and writes the all data to the MQTT server on your local network about once every 5 seconds.
At this point, there’s a complete open source firmware based on ESPHome available for the Emporia Vue 2. Installation instructions are here: Setting up Emporia Vue 2 with ESPHome · GitHub
So I’ve been very interested in the Emporia Vue 2, and have partially reverse engineerd the PCB from photo’s. I don’t have one (yet) so haven’t gone into all deep and dirty details, but here’s the PDF I’ve got so far: https://github.com/emporia-vue-local/emporia-vue2-reversing/raw/master/vue2_schematic.pdf The repo also contains the KiCad files I used to reverse things
What makes me wonder now, this device seems to be much cheaper but what compromises did they make compared to what emonTX seems to do? Also, having everything inside a single box is also super nice.
If I where to make this myself with these idea’s, I’d probably do something very similar, though maybe bring-out the Ethernet port of the ESP, and maybe use a better ADC (dual ADC please to keep voltage and current measurements in sync
This helps, but it’s not the answer. You still have phase errors from the c.t. even though, with a galvanic connection you can have zero phase error on the voltage. Being able to sample two channels out of sync by a defined and controlled amount is what you need.
Of course, that would be then the software side of things, ensuring clock-cycle accuracy of the sampling moments. I suppose there’d always be at least one clock cycle difference unless you can start measurments simultaniously (e.g. the start bit in one register so you can do EN0 | EN1) …
