As mentioned in our previous post, we f***ed up the connector to the meter…
Moving on and with a few other hardware versions that never got produced, we ended up having a version 1.03 prototype where the connector is fixed and that kind of works most of the time in some meters:
Note: jumper for disconnecting power (while adjusting the buck converter) was introduced. And also a “Set ESP32 in programming mode” jumper replaced something we tried to do that never worked :-). The unpopulated 6 pin connector is matching a standard FTDI USB to TTL Serial 3.3v Adapter and can be used to flash or debug the ESP32.
Now we have something kind of working, but are struggling with stability. Which was actually quite a surprise for us. We acknowledge we are mostly software guys, but this hardware is soooo simple – what can really go wrong?
It seems Maxim Max3232 ICs are quite commonly faked in China – and since we buy most of our components in China, we have been struggling with 50 ICs that simply did not work (we got a full refund) and multiple batches that are just misbehaving a bit.
Apparently most of these Maxim Max3232 fakes seems to kind of work, but sometimes when they are powered on and the RS232 pins are connected, the build in boost converter will go haywire. The communication will not work and they will get VERY hot.
If you disconnect, leave the IC to cool off a bit and then reconnect. It will sometimes fail and sometimes work. In some meters it will fail more than in others… A quite intermittent and confusing problem…
You can google this problem – it is quite easy to find others with problems like ours and even with solutions that fixed it for them. We are working on trying out which solution will fix it for us – but this takes time when it sometimes works… And when you think you nailed it, it comes back and bite you in the b**.
Note: If you have any info. on how to fix this issue or issues like this, please let us know by writing a comment. We are for sure NOT electrical engineers and will probably end up creating some kind of software solution for this if everything else fails ;-).
The right (also morally right) solution would off cause be to buy genuine Maxim Max3232 and don’t support the Chinese companies producing fake chips. But the genuine Max3232s are actually quite expensive for “poor” tinkeres like us :-). Let’s see if we can design around this flaw and make something that simply works – even if you use semi working fake chips. After all – it is just another challenge and we started this project to push the limits in the first place…
So for sure, if you want to create hardware from the current design, it is on your own risk. Note: the final solution will also be at your own risk, but this prototype is just even more unreliable than what we usually create :-).
Disclaimer: We cannot be held liable for anything written on this site – even if you set your meter, yourself or your building on fire!
Off cause you also won’t have much use for it before the MEP documentation or our software is released.
Anyway – the current unpopulated prototype PCB looks like this:
As we chose to use thru hole components we are kind of “out of space” (which is defined by the size of the “drawer” in the meter). So we are considering pushing our soldering skills and going to SMD components to get more space… Maybe in a future prototype?
The current schematic (without any fixes for fake Max3232s) looks like this:
Warning: The schematic still have the wrong pin numbers for the MEP connector, so don’t trust those! The wiring is correct, but the pin numbers shown are not!
The Max3232 is more or less setup like the reference diagram in it’s datasheet. So not much to explain there (the capacitors are used for the build in boost converter converting the 3.3VDC to the +/- DC voltages needed for RS232 signals).
A Max3232 got two sets of receive/transmit logic. We currently use the first set for the actual communication with the meter, and (mis-)use the second set to set the Enable pin high towards the meter (it might not be exactly +5VDC or +12VDC, but it works). To prevent the Max3232 from setting the Enable pin negative, we have a diode in there (not that we know for sure it is needed 🙂 )… We currently have no use of the receiver part of the second set of the Max3232 receive/transmit logic, so it is just grounded on the RS232 side to prevent it from oscalating.
The resistors connected to the ESP is just to make the initial flashing through the J5 connector work.
Nothing real fancy going on in the schematic as far as we are aware :-), but as mentioned a few stability issues with some meters… So we are trying out different solutions for that.
Btw: if anyone need a copy of the current KiCad project while we wait for something better, feel free to e-mail us. We’ll be happy to share it, but prefer not to put it up for download until we have sorted out the hardware bugs…
Unfortunately the software is covered by the NDA, so we cannot share that yet… So you really have no use for the hardware at this point in time…
As soon as we are released from the NDA with NES, our plans are still to make both hardware and software fully available to you … on this dabbler.dk-blog.
Stay tuned!
Let us finish with a sneak preview of a few decoded meter answers from our software:
Note: Our added comments are formatted with italic. L1 L2 and L3 is the name of the 3 phases measured by the meter. *’s are replacing the stuff we are not allowed to share yet due to the NDA:
0x** Invalid sequence number (this is normal for 1st request)
The meter returns the sequence number to use for the following requests with this error
0x** Successful response
This is some initial reading of the meters setup. It is required to decode some of the other messages correctly.
Flags 0: 0b00000011
Flags 1: 0b00001100
No. of Self-reads: 12
No. of Summations: 11
No. of Demands: 0
No. of Coincident Values: 0
No. of Occurrences: 0
No. of Tiers: 0
No. of Present Demands: 0
No. of Present Values: 55
0x** Successful response
Manufacturer: ELON
Model: 83331-3I
Version: 58.134
0x** Successful response
This response is about aggregated consumptions.
The meter’s display was showing: 115921 kWh when this was received.
This household is NOT producing electricity, so the 201Wh might be from when the meter was initially tested?
This response contains far more values than the ones we chose to decode.
Fwd Active Wh L1L2L3: 115921469
Rev Active Wh L1L2L3: 201
0x** Successful response
This response tell us about the current consumptions etc.
This response contains far more values than the ones we chose to decode.
Fwd Active W L1L2L3: 701
Rev Active W L1L2L3: 0
Import Reactive VAr L1L2L3: 139
Export Reactive VAr L1L2L3: 0
RMS Current (mA) L1: 1536
RMS Current (mA) L2: 1874
RMS Current (mA) L3: 139
RMS Voltage (mV) L1: 232591
RMS Voltage (mV) L2: 233879
RMS Voltage (mV) L3: 234387
Frequency (mHz): 50000
VA L1L2L3: 822
Power Factor L1 (1/1000): 875
Power Factor L2 (1/1000): 836
Power Factor L3 (1/1000): 837
Fwd Active W L1: 311
Fwd Active W L2: 366
Fwd Active W L3: 25
Rev Active W L1: 0
Rev Active W L2: 0
Rev Active W L3: 0
RMS Voltage (mV) L1 – Continuous: 232507
RMS Voltage (mV) L2 – Continuous: 233922
RMS Voltage (mV) L3 – Continuous: 234246
RMS Voltage (mV) L1 – Average: 232185
RMS Voltage (mV) L2 – Average: 232990
RMS Voltage (mV) L3 – Average: 234229
Average Fwd Active W L1L2L3: 701
Average Rev Active W L1L2L3: 0
Average Fwd Active W L1: 311
Average Fwd Active W L2: 366
Average Fwd Active W L3: 25
Average Rev Active W L1: 0
Average Rev Active W L2: 0
Average Rev Active W L3: 0
0x** Successful response
Utility Serial Number: 4080******(digits removed manually on this blog for security reasons)
Image CRC: 55331
Hi!
Any news regarding the NDA-free spec from NES?
– always good to have a project for Christmas 😃
Hi Jan
Unfortunately not yet.
I’ll try to get an status update from NES, but my guess is that they are a bit delayed… Unfortunately.
We are still working on improving the hard- and software, and I’ll try to release more non-NDA information soon.
We still believe that NES will keep their promise and release this, but as the documentation needs an major overhaul to remove stuff they don’t want to release (and we don’t need), it probably just takes more effort than expected.
Have a nice Christmas Holiday, and rest assured we’ll update the blog as soon as we get news from NES.
“and that kind of works most of the time in some meters:”
I love it.. Sounds like you are making progress 😀 😀
Nice job, Keep up the good and interesting work.
Let me know if you need beta testing at Echelon 83331-3IAAD located at N1.
Hi Daniel,
Thank you for the nice words.
Unfortunately NES is delayed with releasing the MEP protocol specs., but I’ve reached out to them – and they are still working on it, so the plans about releasing it has not been trashed.
So we are quite limited in what we can share currently due to the NDA (I’ll not risk releasing software that can be decompiled etc.), but I really need to write more blog posts about our progress. I think we have a hardware that should work stable in all NES meters with the MEP drawer (newer ones might have issues as they have two MEP ports, but that is something that can be solved if/when we have one to test it on). And I’m currently working on a small auto-refreshing GUI dashboard in our software…
Anyway, nice to hear from a the western part of Jutland (assuming that based on your e-mail address – I’m originally from Humlum/Struer myself.). I didn’t know we had distillers in Hjerm :-).
BR
Gert Lynge
Has the project died?
No updates for 2 months.
No, the project has not died. NES’ release of the MEP specifications is delayed, and there is not much we can do about that except remind them that we are waiting (and I have done that).
Also see my answer to the comment on this exact blog entry a couple of days ago.
The situation is kind of unchanged, except:
– We keep NES reminded about they should release the MEP protocol description.
– We have a new hardware version we expect solves the issues with unstable MAX3232’s – and we also did both a SMD and THT version this time. We’ve just received the PCBs, but have not had time to populate and test yet
– We are still working on improving the software… Still a lot of outstanding ideas, although the communication with the meter is mostly done – and seems stable (been running for months on some meters without new issues)
– Some new entries on the blog describing the hard- and software are for sure due soon. I’ll try to make that happen
– Our time is still limited, this is a spare-time project – we both have (sometimes more than) full time jobs. And on top of that Graves is travelling abroad and will be offline for 3 months soon. I’ll off cause try to keep NES reminded about the release (priority 1, as this will enabled other to help or do other projects), write new entries about progress and actually get some work done on on the hard and software :-).
I’m sorry for the delay and no blog updates, but as I’m still under NDA we would not be able to release any specifics about the protocol and software at this point in time anyway.
We’ve never imagined that it would take this long for NES to release the specs., but we understand that this is not their priority 1 and are just glad that it is still in their pipeline.
I’ll just keep refreshing the page regularly waiting (almost) patiently for the NDA to be lifted.
And as you know from email i also have an old 2010 Echelon meter available for testing 🙂
Would much prefer to read from it directly than resort to something like the Shelly 3EM with current clamps (that i can’t fit in the limited space)
Hi Anders,
We are really trying to be patient too – we would love to share the specs and answer questions based on what we learned developing this…
The main goal here is not to be able to share our hard- and software. It will be shared (don’t worry), but not as “a final solution” – only for other to learn from (and laugh at 🙂 ). The important part is to have the documentation available so others can do all kind of projects themselves :-).
In my experience you cannot and should not push large companies like NES. You need to remind them once in a while, but in the end they need to prioritize and find the time themselves…
We for sure don’t want to push them to a degree where they will just trash the project :-).
This is indeed interesting! Keep up the good work!
After moving to our first “own” (read Total Kredit) house, I’ve started tinkering with Home Assistant. Best so far is 48 hours delayed power usage from eloverblik.dk, so this looks promising 🙂
Hi Nicky,
Thank you for the nice words.
Well (sneak preview), this test dashboard served by the ESP32 updates “a bit” more often (every 2 seconds or so) using AJAX (i.e. calling a webservice provided by the same ESP32):
https://www.dabbler.dk/wp-content/uploads/2022/01/MEPDashboard20220120.png