On my new EmonPi2, I was under the impression that the E1 to E6 input values contain the total energy (Watt-Hours) read from the 6 CT inputs, and that the firmware contained logic to preserve these in non-volatile storage?
If that is the case, then how come my feeds based on these inputs suddenly dropped? Here is the total kWh reading for my immersion heater for example:
I’ve just seen a comment from @Robert.Wall In another thread:
The front end sketch should be saving the ‘E’ values to EEPROM when any one of them changes significantly, but I believe the library that does this has been changed since I wrote it and it no longer works as intended - if at all.
Is that the case? Then, umm, I hate to say this, but shouldn’t this get fixed asap?
Hello @Martin_Robinson apologies, I had not appreciated that this was an issue. I have now tracked it down to an error in the emon_DB_6CT sketch itself and have pushed a fix to the firmware repository.
Next I will issue new pre-compiled firmwares and will update this thread again once I’ve done that.
@Robert.Wall I was using the wrong CT channel index for EmonLibDB_setWattHour in the main sketch using 0-5 rather than the correct 1-6. That caused the saved values to shift at every power cycle. E6 becomes the pulse value, E5 becomes the last E6 and so on. An embarrassing mistake! My modifications to your emonEProm library appear to be ok.
Hello @diyhouse the 12CT firmware does not implement the EEPROM code for saving energy values and so does not save the energy values at all, I would recommend using the Wh accumulator process when using the energy values, this automatically removes resets in the energy values (this is not a solution to the above issue with the 6CT firmware but does work for the 12CT firmware).
Another option is to use the Power to kWh process on the power values, which is a good solution for both firmware’s (though I will be issuing the updated 6CT firmware’s soon - I’m going to include one other thing in this release at the same time).
Pre-compiled versions of the latest firmware with the fix for the mis-allocation of the energy values are now available. It’s possible to update these via the Emoncms firmware update tool or using the EmonScripts emonupload python tool, both are detailed in the respective firmware sections of the EmonPi2/Tx5 & Tx4 E.g: Firmware — OpenEnergyMonitor 0.0.1 documentation .
Here’s an example screenshot of the firmware listed on an EmonPi2: