Been there, done that when I got a new laptop with Win 8 on it. It lasted about 48 hours before I decided the OS was total rubbish, unusable for what I wanted and how I do things, and the best thing I ever did with Win 8 was use it to download Ubuntu. That was a STEEP learning curve because I had no fall-back.
Hello @Robert.Wall - me again! I thought I’d sussed this using the processing but alas without calibrating the charge and discharge values my SoC drifted all over the place yesterday (almost 24 hours without grid power :))
So I am trying to use a calibrated value for the charge value which seems to increment my BatteryEnergy fine, however for some reason when it comes to the Discharge value with the -1.1 factor, the new -ve value is not taken off the kWh (at line 10) - I can’t figure out why this is happening - the process is below (it could be something obvious that I haven’t considered?)
I can’t see anything obvious, and I’m afraid I really can’t spare the time to look into this in depth.
I cant see anything obviously wrong either and i do like the way you sorted the charge and discharge power.
Is this evident in a graph with the charge, discharge and battery energy feeds displayed?
Hi @Jaddache thanks, it was the only way I could figure out how to use two different calibration values for charge/discharge without using if or gotos 
Playing around a bit more I have a hunch that adding to a cumulative feed twice within the same process makes it go weird as with the -ve values, the graph stays at zero and flat lines, with the charge values I can see it incrementing, so I think that the W-kWh at line 5 seems to override what happens at line 10 hence a zero value? I’m stumped if this is the case 
So what would happen if you only did one W-kWhr step - after you recalled the charge and discharge feeds and added them together?
I think that would probably solve as then there would only one entry into the BatteryEnergy feed - but I’m not sure how I would go about doing the summation of the charge/discharge feeds - does the process just take the last value? In which case I think that would solve it - I’ll need to have a play when I have a moment later (intermittent cloud cover at the moment so might be a good time to test!)
For me it was key to read the process descriptions very carefully. Some process descriptions pass out a modified value from the step before, others like the W-kWhr process only effect the feed value and the W value is passed to the next step.
Good luck.
You might find it helpful to track down the code and read it. My crib note says
/var/www/emoncms/Modules/process/process_processlist.php
but it might no longer be correct.
So I think my hunch is correct in that you can’t do a power kWh feed twice in the same process, so as suggested here is my workaround by adding the Charge feed (line 8) to the calibrated (line 7) Discharge feed, BUT crucially this creates an issue in that my calibration factor for charge (line 9) then applies to discharge too e.g. 1000W discharge, calibrate to 1100W, BUT adding the 0 Charge value and then the factor on 0.9 makes it 990W, so I can’t think of a way around this other than to fudge the discharge value to offset the charge correction - my head is about to explode 
Are you using the charge and discharge feeds for something other than to calculate the battery SoC? If not then I suggest applying the calibration factor before you log the value to the feed. The charge and discharge feeds could be corrected later if required.
Only for the instantaneous values for the battery app, my charge offset seems to be tracking pretty closely at the moment and I will keep an eye on the discharge later as I think it’s possible to ‘fudge’ it by over factoring that value which is then decreased proportionally - I have adjusted it to -1.25 and can tweak it as I monitor - I think that keeps it as ‘clean’ as it can be…ideally I think I’m reading around how to extract the SoC from the BMS without excessive hardware or coding!
Thanks for your input on this 
1 Like