When I’ve gone back to the Serial Config, the radio is back enabled and CT3 is back to 50A.
I can plug into CT4 for now but wanted to report the issue.
I’m struggling to find steps to reproduce but I have been messing with the EmonHub config. I can can say with certainty that I have not been anywhere near the Serial Config page at the times where this has happened.
Not necessarily. If Trystan is using the ‘old’ emonTx V3 setup - it saves the settings to memory immediately, but to EEPROM only when you do a 's’ave. This is deliberate so that you have a fall-back in case you get into a mess - restarting without doing a 's’ave restores the last version saved to EEPROM.
@Robert.Wall I say definitely because I’ve seen the message about saving to EEPROM, closed the Serial Config, started up EmonHub and the readings have been fine for a while.
But are you sure you saved first? - Did you see the saved data echoed back? Closing the Serial Config in the browser doesn’t save.
If that’s not the problem, then are rogue characters being sent to the serial input - say during plugging/unplugging, or restarting whatever follows the programmer?
Here’s my documentation for the emonTx V3CM version. Your sketch might not use all (or any!) of this. Config.pdf (47.9 KB)
Hello @abbbbbottttt On the serial config page, when the emonTx4 connects, could you check the firmware version that you have there? it should be printed in the log window.
I think I’ve experienced this on one test system here, but Im struggling to reproduce it in a way that would allow me to understand what might be happening. If you notice this again @abbbbbottttt or anyone else please let me know.
@TrystanLea Will do. To be honest, I moved my 20A clip to one of the ones that defaults to 20A and P3 is now empty. However, I’ll notice if the radio re-enables. That said, it’s been stable since I stopped messing around with Serial Config, restarting Emonhub,etc.
I was able to replicate this issue properly this morning and realise that it’s a fundamental issue affecting emonTx4 firmware versions up to and including v1.5.3.
If compiling from source it is important to update your local copy of the emonEProm library in addition to the main emonTx4 firmware directory (GitHub - openenergymonitor/emonEProm at avrdb)
@TrystanLea - docs site needs updating (references 1.5.3 as latest).
You can use latest in the URL for a permanent ref to latest firmware which I think automatically updates the link text. https://github.com/openenergymonitor/emontx4/releases/latestRelease 1.5.4 · openenergymonitor/emontx4 · GitHub
A reminder of which is which (Classic/Latest/LPL) would not go amiss I suspect in the docs as well (even a link to definition).
@TrystanLea - The only bit that caught me out when updating from the emonBase is that do you need to do a system update before trying the firmware update? It seemed to be that way.
A little more background on the issue fixed above:
The emonTx4 EEPROM is used for two different functions:
1. Storing configuration e.g radio, nodeid, CT channel calibrations etc.
2. Storing cumulative energy values
The emonTx4 EEPROM size is 512 bytes long.
The configuration section currently takes up bytes 0-105.
With the fix today (v1.5.4) the energy values are stored in a circular buffer 13x29bytes long = 377 bytes total, starting on byte 132 through to byte 508.
My mistake in the previous version was to mistake the block size to be 28 bytes, I then allocated 14 blocks starting at byte 110. (110+(28×14))=502 bytes which would have been ok. There is however an identification byte alongside each block of energy values, which makes each block 29 bytes long, (110+(29x14)) = 516 bytes, which unfortunately caused the last few bytes to wrap around and erase the expected signature at the start of the EEPROM resulting in the configuration resetting.
The fix today shortens the circulation buffer by one block and also moves that circular buffer a little further from the config section so that we can add more config options in future if needed.
EEPROM memory has a limited cycle life, stated as 100,000 cycles in the datasheet.
Energy values are updated to EEPROM if at least one channel changes by more than a threshold value compared to the last value stored in EEPROM, currently set to 200Wh in the emonEProm library. In practice this means that the channel recording the highest consumption will set the EEPROM update rate for all channels.
If we assume a consumption of 4000 kWh/year, 4000,000 Wh / 200 Wh = 20,000 updates per year. But these updates are cycled across the circular buffer which is 13 blocks long and so in terms of wear on any particular byte, the actual wear rate is 20,000/13 =~ 1540 writes per byte per year.
100,000 / 1540 = an EEPROM lifetime of ~65 years
A higher consuming channel say 10,000 kWh per year would result in a lifetime of 26 years.
