Move entities into separate file to

[RustyDust]

allow for easier adding/editing. Please check whether the substitutions are ok (look for the "aka" settings in mappings.py) Some changes I made that may be specific to my setup:

• removed the hardcoded MinimumKeepBatteryPowerPecentage that was set to 7.0% and use the value of BackupBuffer instead. I checked with the dumps available to me and so far this seems to be present everywhere.
• reworked the calculation of the allSensorsPrefix so that it is done only once. If your settings show up with an ID of unknown please let me know.

If you want other entities added: feel free ;) Things not present in any given setup should be automatically discarded.

[RustyDust]

Forgot to add: wfm - ymmv :-D

[weltmeyer]

Did you see my concern about the backbuffer being zero and so making 'calc_restrictedcapacity' always 0? :)

[RustyDust]

Yes, I saw your comment but wasn't near my setup to check whether there are differences. Since my setup reports USOC: 18, RSOC:25 I agree that your initial idea is correct and the battery seems to be using 7% as silent reserve. Still I'm not entirely happy with a fixed value because that could change without notice. So the safer approach seems to be to just use RSOC-USOC just in case a firmware update changes this. What do you think?

[weltmeyer]

RSOC and USOC both reach 100% at the same time...

RSOC is x% from 10kwh for example while USOC is y% from (10kwh-7%=9300kwh) if Battery is full then you have both at 100% if battery is 50% full (5kwh) you have 50%rsoc and ~46.2%usoc

[RustyDust]

Hmm. I see what you mean. The thing is: I can verify your algorithm using your data and the one TobyRh was kind enough to send. That said, it doesn't compute for my setup :-( Example:

# Battery System:
{'battery_system':
 [...] {'ecu': {'board': 'Kontron SMARC-sAMX6i module\x00',
                    'system': {
                               [...]
                               'storage_capacity': '4',
                               'storage_capacity_per_module': '5500'
                               [...]
                               },
 [...]
 'marketing_capacity': '5500',
 'modules': 4,
 [...]
 }

# Status
{
 [...]
 'RSOC': 25,
 'RemainingCapacity_Wh': 11002,
 [...]
 'USOC': 18,
 [...]
 }

As you can see the reported value for RemainingCapacity_Wh is totally off. Ignoring that and assuming we have 5500 Wh for that (22.000 Wh * RSOC / 100) that would give me 3960 Wh "usable" capacity left and a 7% "reserve" of 1540 Wh.

Using your algorithm my USOC should be 19 because of (5500 - 1540) / (22.000 - 1540) = 3960 / 20460 = 0,19355 ≈ 19%

If however I do the calculation without subtracting the reserve: (5500 - 1540) / 22.000 = 3960 / 22000 = 0.18 = 18%

So it seems that not only different setups provide different sets of data but also use different algorithms to get to the values returned :-(

Anyway, since using different measurements from my system I found that the larger the values and by using the wrong reported value for RemainingCapacity_Wh as the base for the calculations the more the results tend to lean to your approach. So we'll be using that ;) In the end it doesn't really matter that much and since the system itself can't calculate properly as my setup shows it shouldn't matter that neither variant seems to be completely accurate.

[RustyDust]

Oh, and btw: I'd love to have a battery with a capacity between 44.000 Wh and 53.500 Wh as one would expect when doing the math with different RemainingCapacity_Wh values reported by my setup :-D

[weltmeyer]

Sorry, did not have the time to merge this. If you create a new pull request I can do it. Or..even better.. do you want the rights to do it yourself?

[RustyDust]

Ooops, my fault. I shouldn't do cleanup work when too tired. I'll restore the repo and issue another PR. And if you'd give me merge accees, I'd be really honored.