EmonTx4 Config Resetting

@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 did you reboot the EmonTX?

Can you try that and check the settings have been retained.

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)

Just tried it myself. When you change something a ‘save’ button appears.

This does then save to EEPROM - you see the data and then the saved message.

Odd it seems to be reverting then.

1 Like

@borpin - Yeah. I’ve doubled checked that all works by editing, saving, then going back in and it loads the saved configuration.

MSG also went to 0 at the same time so it’s like it’s completely reset.

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.

1 Like

@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.

1 Like

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.

I’ve now fixed this in v1.5.4 which is now available as a release here: Release 1.5.4 · openenergymonitor/emontx4 · GitHub

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)

The easiest way to upload the latest firmware is via a USB-C cable connected to an emonPi or emonBase. See: https://docs.openenergymonitor.org/emontx4/firmware.html#updating-firmware-using-an-emonbase

I will contact those who have already received emonTx4 units to notify about this and recommend a firmware update.


@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/latest Release 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).

LPL is factory default, I think?

Updated, thanks!

Id does say on there that the default is LowPowerLabs and that there are the other options. Do you think it’s not clear enough on that page?

@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.

1 Like

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 write lifetime

  • 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.

Yes good point, that is required

I’ve updated the documentation to provide a note that a system update is required if the latest firmware version is not in the list.

No (sorry).

I’d make this a list so it lists the 3 files someone will see if they follow the download link with a note to say what each does (and note the factory default).

If you use that link I suggested, this text will update automatically when you create a new release (I think).

@TrystanLea After the upgrade all cumulative figures were reset. Is this normal or to do with the change you’ve needed to make? If normal, is it recommended to set a feed up to persist them?

Yes unfortunately the values will reset with this update. One way to get around this is to use the kWh accumulator process instead of the ‘Log to Feed (join)’ process I recommended in the documentation. I need to think bit more about my advice around that I think.

1 Like