Hello folks, by no means a noob but I feel like one as I haven’t been on the forum for some time - this is because my EmonTX v2 running 2 CTs and the PLL diverter code have been working flawlessly since 2014ish thankfully - I also have a couple of GLCDs (eek) and the lesser-spotted NanodeRF to push stuff up to EmonCMS
All good until I decided to go down the battery storage route with an AC coupled Solis inverter (it was cheap) - I dabbled with Lead Acid as the Pylontechs were on back order. Revisiting the emonTX code and elsewhere, I was able to add a 3rd CT and measure the power in and out of the Solis - all good so far. I am using the emonCMS battery app but have no clue how to measure or indeed work out the SoC? Is there an easy way to read/derive this from the BMS and get the EmonTX running the PLL diverter to do it - I don’t want to re-invent the wheel but am sure someone else may have trodden this path before - my C skills are okay but I did find it hard to tweak Martin’s code for the diverter as I had to add some crude conditions to prevent a runaway situation where the battery would start discharging into the diverter as it saw ‘excess power’ which the battery would happily keep supplying - that seems to be stable now so just this last piece of monitoring needed
I’m afraid I think you’re wrong there - I can’t remember seeing anything relating to SOC, monitoring the a.c. side, which I presume the emonTx will need to do.
I think this is more a question for the DIYBMS community. If they can suggest the algorithm to account for losses in the charge/discharge process, we can take it forward from that.
Thanks Robert, I guess one of the questions was really directed at those who already have batteries and use the ‘mysolarbattery’ app - I’ve seen screenshots of the SoC showing, but where does this feed get its data from - are folks extracting that from battery BMSes or from the inverter or doing a calculation based on input/output as you suggest…I did see one reference to extracting the MODBUS info from the inverter but again this seems a bit overkill to me if there is an easier way…
I have an off grid system with lead acid batteries and I make a calculation as Robert suggested.
One of the reasons I do this is that the SoC reported from my battery management system (SMA Sunny Island) has a lot of discontinuities in the data. I think the Sunny Island has a number of measurements that it uses to estimate the SoC and it makes step changes in the reported figure quite regularly - which look very strange on a chart.
A simple calculation appears to correlate well to the reported SoC for me (± 5%) which is good enough to monitor when to go and have a look.
My calculation is based on differing efficiency during charging (0.69) and discharging (1.04 - which acounts for a bit of self consumption). A limit of 100% SoC corrects for the drift in the estimate when the batteries are full. The factors are based on trial and error over a long period of time.
Thanks @Jaddache - that’s helpful to know, though sounding a bit green, what h/w are you using to measure and calculate the SoC (and how frequently)? Using the EmonTX I already have the power values (positive or negative for discharge/charge) that it pings out every 1s but I’m guessing I would need to sum that up into kWh and do some ‘onboard’ calculations on the TX to derive it (rather than letting emonCMS do it via the input/feed calc for example) and then ping that out as a % value? And/or are you doing the increments/decrements continuously or over a period of time (guessing the former?)
I have an EmonTxCM reporting every 10 sec, with two CTs. One measures PV Output and the other measures total consumption. The power flow through the battery inverter is calculated from the difference between these two values.
When setting up my system I considered making the SoC calculation in the EmonTx. I sought some advice in this forum on how to do this and was advised that:
it can be done as part of EmonCMS input processing; and
the EmonTxCM is a bit busy and additional processor load was best avoided.
Making the calculation as part of the input procesing and storing the SoC in a feed also has the advantage of a relatively easy recovery from a power loss.
Ah! Great okay so that’s a useful comparison. But I’m a bit puzzled as to how you derive the battery charge/discharge and separate out the household usage just using 2 CTs though?
Then what steps do you use to derive the SoC from which values (sorry needing a bit of spoon feeding here!)
We actually have 3 CTs - one for Solar, one for Consumption and one for our Generator - I did not mention that one. The is no grid connection.
Happy to share.
My SoC calculation is in the process steps below.
1-5 accumulates Consumption and then calculates the Battery Output
8-10 seperates out Discharging from Charging
11 Coefficient applied to Discharging power
13 Coefficient appled to Charging power
14 accumulates battery charge
15-19 limits the battery charge values to the maximum capacity of the battery. 17 has the effect of correcting the drift when the battery is full.
20-21 convert to %SoC and log
Wow, thanks, that’s a serious process I think I get it, just a few more questions and I think I can apply something similar in principle (I already have a charge and discharge feed going)
The accumulator just adds/removes energy from the total i.e. the energy estimate - what was the start point for this if it’s a known value for example? More generic question but is there are way to ‘insert’ a value into a feed?
Is the 52.12 value the current kWh value? (how big is your bank!)
For your coefficients, I know you say these were derived over time, but what baseline were you using? The BMS info (assume you have lithium batteries?)
Presumably once you have a ‘known’ value, the kWh value just goes up and down and hence your SoC
I finally got my Pylon last week and have started it up - the info from the BMS seems like a decent baseline so I will start playing with the feeds and see if I can get it to stack up!
So I’ve been trying to apply a similar principle to my charge/discharge values but struggling with the process flows in the CMS - I figured out how to ‘insert’ a value and can get the battery energy value feed to increment or decrement but not both it seems - if I’m not mistaken, your Battery Output by default is -ve for Discharge and +ve for charge hence Line 7 to reverse this?
Line 14 does a W to kWh, but what does Line 15 do? Why a reset to zero? And then what is being added to the feed on Line 16?
I think this is more of a feed manipulation issue for me that I can’t get my head around! Oh and I have no option to add a GOTO statement using the online CMS?
Unfortunately, the on-line emonCMS.org lags behind the stand-alone version in several respects. I understand it’s on Trystan’s radar, but the emonTx V4 is taking priority.
As for running it locally, I dabbled with that a few years back but on a Windows install that I already have php etc running on - there seemed to be some sort of file access issue that I wasn’t able to resolve so I parked it and stumped up the £1/feed/year fee for continuing online - Linux is a bit of a steep learning curve for me at the moment as I already have the other server running for other purposes and moving to a Pi was unnecessary.
Related in a way, hopefully one of you can answer this part - when a Power to kWh conversion is done in the process list, how do I then use the kWh value from the feed? When I tried a test calculation where I took a W value, then power to kWh and then a multiplier to calculate a percentage (simulating an SoC) - the value seemed to use the instantaneous power rather than the cumulative kWh value?
The answer is there - the accumulated value is in the feed, not dropping down in the process list (the blue ‘help’ text tells you " Output: Modified value passed onto next process step." - meaning the ‘not reset’ and with spikes filtered value). When you’ve finished with the instantaneous data, you must zero the process list with “Reset to ZERO” and then add the value from the feed back in to the list with “+ Feed”. (Or of course you can use another Feed.)
Thanks, yes this is what I had envisaged, but when I was watching the values, the SoC I was trying to calculate was fluctuating all over the place, as if it was taking the instantaneous value - I also tried the reset to zero as you suggest and as per @Jaddache 's process and that seemed to mess up my power calcs later on even using the ‘reset to original’.
I’ll have another play later - this was giving me a headache yesterday and I think I am limited without the goto statements as I can’t think of a way to add in a correction factor for charging/discharging without a condition…need to have a think if deriving the SoC is going to be possible with this…
I think you can handle the ratio discharge/charge by starting afresh each time and treating charging and discharging as separate processes, using a Feed as a store. I’m not sure how you prevent the Feed from going negative (meaning you got more out of the battery than you put in) or going over the battery capacity.
If you don’t want a local emonCMS, then I think it’s either a matter of waiting until Trystan can implement the ‘if’ & ‘GOTO’ in emoncms.org, or go back to the original thought of doing it inside the emonTx.
The charge/discharge accumulator doesn’t seem to be a problem, (my power value is -ve for charge and +ve for discharge) so I multiply by -1 and then do a Power to kWh into my batteryenergy feed which increments or decrements the kWh value (I think) - I have now added a max and min value as per Simon’s example to constrain the capacity values. This is really to test the principle so having coefficients for charge/discharge aren’t essential for the moment at least - I have then inserted a known kWh value into my BatteryEnergy feed with some tweaking to get the SoC value that the BMS is reporting - let’s see how that pans out.
I have zero sun at the moment so the battery is doing zero as it hit the lower cut off so I can’t even test things! The bit that was going awry seemd to be be the ‘reset to zero’ and the subsequent ‘+ feed’ which made the BatteryEnergy feed go nuts and hence the SoC - I think that looks okay now…
If nothing, the last point you make was what I orignally wanted to aim for - the BMS has the info already so I wanted to do it without this pain - I may need to dig into RS485 :o
Which again would be easy with a local emonCMS. RS485 to USB adapters are readily available, and we have the interfacer to get the data into emonCMS. It might even be worth looking at the smallest Pi that will run emonCMS & emonHub, and use that just to send the BMS data to emoncms.org.
That could be an option, I could then move off the online CMS altogether - I’ve added another 4 feeds now which is costing £10+ per year, plus the fact it’s not as up to date as the local builds. The dilemma is whether the additional hardware (and redundant nanode base h/w) make the single reading of SoC worthwhile - both from a cost and environmental perspective The other option would be to move off Windows and onto Linux for my existing recycled laptop server, but that will be a steep learning curve - I may just have to live without the SoC for the moment…thanks for all your input (there may be more questions to follow!)
I think I get it, just a few more questions and I think I can apply something similar in principle (I already have a charge and discharge feed going)
The other option would be to move off Windows and onto Linux for my existing recycled laptop server, but that will be a steep learning curve - I may just have to live without the SoC for the moment…thanks for all your input (there may be more questions to follow!)