Just to answer my own need for a device that populated all the battery related elements of the Energy Tab. It seems that some other Homey users are frustrated by the incomplete Energy support offered by some battery devices. So if others can make use of it - here it is.
Unreal Battery feeds off the capabilities of your own real battery devices. That’s all, no bells, no whistles. Then it makes the data from your battery device available to the Energy Tab. That really is all it does. Eventually you will be able to use an Advanced Virtual Device to do this, but right now AVD doesn’t support Energy Settings such as homeBattery.
Update With A Flow
Use a flow to update the Unreal Battery - just two cards are needed. Here’s my flow should you wish to emulate it:
The last parameter on the THEN card is simply setting the time-base for the power to energy integration calculation. [It would be really nice if that value were forwarded as a tag from the WHEN card.]
Once you are happy your Unreal Battery is working, you can remove your real battery from Energy via its device settings (Include In Energy => No).
But of course. Please be clear that the role of this device is simply to complete the mapping from a Home Battery Device into the Energy Tab. I have read many posts (and had my own experience) of devices representing Home Batteries that do not fully work with the Energy Tab. Most of the data is there, but perhaps a capability is missing (or misnamed) or the Energy Settings are missing. This device simply aims to complete the jigsaw.
For me it sounds perfect. My virtual batteries are flows that simulate a battery. To help me get insight in which battery to buy in the future. I have build several variants (capacity, charge discharge) giving me insight in ROI. But upto now they only “exist” in ”insights”, now I hope to make them more “visible”
As I understand the definition of a virtual battery, this is NOT a virtual battery - that’s why I called it “Unreal”. The reason I built the Unreal Battery was to overcome the problems that many domestic battery devices have providing all the data that the Energy Tab requires.
The device is a BRIDGE between your Home Battery and the Energy Tab. It takes values from your real Home Battery device and uses these to correctly provide information to the Energy Tab. If that’s what you are looking for - fantastic.
If you are looking for a full on virtual battery, then I am afraid this is not for you.
As @David_Piper status his app is not a virtual battery, it more like a placholder incase you real battery does not appear correct in homey.
BUT
When you combine my flows for a virtual battery and upload the output of my flows to this app. I think it will be a virtual battery showing in homey. (Did not have the time to try it yet)
To keep this thread on-topic, lets follow up discussion on a virtual battery here
Thank you @David_Piper for this solution which is working very nicely for me. I have one question: how is the round trip efficiency calculated? After just over a day of running so far mine is displaying 27% which would be very worrying if it were true but even a basic observation of the energy charged and discharged each day shows the calculation must be wildly out in my case for some reason
The round trip efficiency is calculated very simply by Discharge_Energy/Charge_Energy. BUT the calculation is only done when the SOC >= 98%. If you don’t set a high threshold then you get into all sorts of accountancy around “I’ve charged 2kw and discharged 3kw and SOC is 60% - now how do I square all that away into an efficiency factor”?
With hindsight, a lot of people don’t run their battery at 98%, so maybe I should make it a configurable limit with a value >= 95% (say). If you go much below 95% then the “accounting” errors start to accumulate and the calculation loses its value.
Thanks David. I currently let my battery charge up to 100% (should I not be doing that?). I am in the UK and this week with all the sun, it’s been charging each day from ~5% to 100% during the day before I then dump it out to the grid after 4pm when Octopus pays me a nice high export rate. The battery did this yesterday which is when the RTE got calculated, so not sure why mine is so off then
General advice is to limit the battery charging to about 95% at full rate - if your inverter throttles the charge rate above that (mine does) then charging to 100% is not a problem. If it’s not throttled, then you may want to set a limit.
Interesting observation. Just reviewed the calculation which is:
So it’s brain-dead simple. Your value was ~25% which suggests that when your SOC was last > 98% totalEnergyIn was about 4 times totalEnergyOut. What are the numbers now?
Those totals are calculated from the moment you install the Unreal Battery - so it may be that we are suffering “small sample syndrome” and that the calculation will become increasingly accurate over the next few days.
Here’s the insight from my unreal battery - you can see that RTE started low (not as low as yours) and increased rapidly as the sample size got larger…
Thanks David. I had noticed actually that my inverter (SolarEdge) does indeed seem to slow down the charge rate as it gets close to 100% but I didn’t previously know why that was. Every day’s a school day; thank you!
Funnily enough since I messaged you earlier the sun has topped my battery up to 100% again and now the RTE is showing as 57%. So I will keep an eye on it over the coming days to see if it settles.
BTW my battery doesn’t report its temperature so I’ve just left that at 0. Does that factor in any of the calculations or is it ‘just for info’?
It’s just for info and not used in any calcs. I, too, use the solar edge automation for my Solax inverter. But I have noted there is no battery temperature reported in that device. I have a second app that reports from the Solax inverter and that’s where I am picking up the battery temperature from. If you don’t have a source for data, then it can’t be reported in the Unreal Battery!
Thanks. That prompted me to go take another look at the data points coming from my inverter via modbus and I had missed it does actually report “average” battery temperature so I’ve pumped that into my Unreal Battery device now.
Hi. Interesting idea, but probably a little too complex - the whole point of me setting up this app was it’s essentially a “very-very-very-low-code” solution. If I get into using something like Math.eval or even BLL in the JavaScript I reckon that will be a whole world of pain.
I am unsure why having a calculation capability would remove the need for the two variables in your flow? If the data is going to be available when you get to the Update Real Battery card to be used in a calculation, surely you can simply insert a logic card (or use the Temporary Variables app and it’s calculate card) to do the same job immediately before the Update Real Battery.
Perhaps if you share (a small portion of your flow) I will understand a bit more.
Got it. Basically take the calculation out of the logic card and put it in the tag field in the flow card. That is going to involve getting much more into things like Math.enum in javascript - so I think I go back to my original point of a “very-very-very-low code” solution. For the sake of saving a couple of flow cards and variables I am not sure the cost-benefits add up…
However, if there is no need for these variables to be persistent (i.e. they are re-initialised every time the flow runs), then you could use the Temporary Variables app to avoid the need to have Homey variables hanging around. With the TV app you have a card just like the Logic card you are using, but the result has a fixed name - so in the case of “Calculate expression as a float” the result is always called Result Float. You can have multiple Result Float variables at the same time - but it is hard to disambiguate them, so that is less friendly than using Homey Variables.
Pro - No Homey Variables. Neutral - you still need the same number of flowcards. Con - variable names are fixed and, perhaps, hard to disambiguate. Con - it’s an extra app to install.
