Predbat not predicting any battery usage #1964
Comments
|
have you got some of the fox sensors set to kW rather than Watts or vice versa? If you look in the apps.yaml documentation it explains what each sensor needs to be set to |
|
I don't see how that could be changed.. the sensors are what they are.. it's up to predbat to be compatible with them. This is the example config from the documentation, which should work. |
|
When I look at the power chart, the battery line looks normal to me. So I'm not sure what the difference is between your config and mine. There is always the possibility that you happen to have a Fox firmware version which writes the wrong information into the modbus registers. Does it look correct when you look at the modbus integration entities on the settings/integrations page?
It's easy enough to do by adding a template sensor to multiply or divide by 1000. However I understand that some conversions already happen internally (but aren't necessarily visible on the config/charts), for example the sensor.pv_power which confused me for a while. So a figure might be off by 1000x in the chart and the config, but be might correct in the plan (which is the important bit). #1870 I do think the fox.yaml could do with a bit of TLC, for example to enable Fox's 'feed-in first' mode (which I think corresponds to 'freeze charge'). But it is really up to us Fox users to propose & test the changes to fox.yaml, because Trevor does not have a Fox system. There's also some discussion here: #1928 For comparison purposes, here is my apps.yaml: Note that I am running in 'readonly' mode, so don't know if the control side of things is working. I have also never succeeded in getting the carbon intensity working, it reads in the forecasts but that's it. |
|
One thing I notice is charge_rate and discharge_rate are in amps not watts as the documentation says they should be, so either the documentation is wrong or they should be multiplied by sensor.batvolt.. But you're using the amps version and it appears to be working for you, so no idea.. |
|
Well, firstly, I'm only using it for monitoring so if there are issues with control I wouldn't see them. You could try hardwiring a template sensor to return an arbitrary figure in watts to see if that changes what you see, or even just comment out the sensors that you are concerned about. Perhaps if predbat doesn't like the units, it discards the sensor and just uses a default instead. |
|
Hi @TonyHoyle ,
I was looking the entities and found sensor.battery_charge & sensor.battery_discharge in Kw and changed them to W.
After updating the apps.yaml with these sensors and the chart is looking more along the lines of what I should be seeing?
|
|
It isn't clear from the documentation what charge_rate is supposed to be - it just says 'Battery charge rate entity in watts'. That seems to clear up the graphs but of course may be wrong.. Edit: Turns out that was the wrong interpretation, so I removed them from this post. |
|
Cheers @TonyHoyle after adding those sensors, I'd say that my chart is looking more along the lines of what it should be.
|
The sensor that is configured in apps.yaml is expected to be an inverter sensor that (a) gives the current charge rate and (b) is something that Predbat can set to control the charge rate. By using a template sensor for the entity, part b isn't going to work .... Trefor has recently introduced the ability to control charge and discharge rate by % instead of watts value. Is this something the Fox inverter supports? I can certainly expand the documentation to make this clearer, and if the Fox template needs changes, I can make those. |
|
These are all the sensors available, I think read-only Sensors And there are also inputs
What is meant by that exactly? The commanded charge rate, or the actual charge rate right at this instant? For example, if you are in 'self-use' mode, charging the battery from PV, the actual charge rate (sensor.battery_charge) might be 200W or something like that, and changing from moment to moment. The max charge rate might be 20A (sensor.bms_charge_rate), but is not necessarily achievable, for example if the inverter limit is lower than that. The force charge rate (number.force_charge_power) might be 5kW (but it isn't in force charge mode, so that's irrelevant). I don't think there is a single sensor which can be both written to and read, there's one for control & one for monitoring. OK yes you can read the control input, but it's not telling you anything other than what it was set to earlier. To control the charge rates, the force charge power & force discharge power need to be written to (they take affect when in either force charge/discharge). However, if, for example, the battery is cold, the actual charge rate might be less than that (and this will be reflected in the sensor.bms_charge_rate being 5A or whatever instead of 20/25/50A), and also the instantaneous charge rate sensor.battery_charge being low too. To monitor how much the battery is actually outputting in real time (rather than the max), you'd look at sensor.battery_charge (kW) and sensor.battery_discharge (kW), but I don't think you can write to them (or if you can, it'd be ignored). Perhaps some sort of helper, which can accept inputs, writing them to number.force_charge_power, but reflects the sensor.battery_charge (if it is the instantaneous measurement which is needed) or sensor.bms_charge_rate * sensor.invbatvolt (if it is the maximum) when read? Ultimately we could just hardwire either the input or the sensor to a constant. It's not critical to the core functionality as far as I understand it, although nice to have, particularly in winter when the battery might be cold, or if you want to throttle the charge rate to protect the battery via the low_charge functionality.
Not as far as I know. |
|
Will predbat cope with the charge in watts and convert internally or is it necessary to create a battery_charge_w (and the same for discharge) in the same way as we create a pv_power_w? |
My understanding is that we don't actually need to create a pv_power_w, it'll convert internally for the key stuff (but the config page and the charts won't see the converted figure). So alternatively you can adjust the chart to also do the conversion. Regarding on whether it can convert between kW and W for the charging rate, the chart is obviously off, but what does the plan show for the battery SoC (SoC%)? Does it go up and down as expected? |
|
Here are the various charge rate parameters charted over time. For work mode, pink is force-discharge, brown is force-charge, purple is feed-in first. So the closest thing to an instantaneous battery charge sensor would be the inverter battery power sensor.invbatpower, which gives both positive and negative readings regardless of workmode (i.e., I think it is acting as if it was a CT clamp on the line feeding into the battery pack from the BMS). Note that when there is no PV input, the sensor.battery_charge is always a bit below the commanded number.force_charge_power, presumably due to losses during AC/DC conversion. If there is PV, then obviously the sensor.battery_charge will be higher than the number.force_charge_power, since it is being charged simultaneously from both the AC side and the PV. I'm sure that the number.force_charge_power is the one that we need to write to (likewise number.force_discharge_power). Note that number.force_charge_power is persistent across work modes, so you'd set it once and then could leave it henceforth, until you want to change it, and it can be queried too, giving the requested force charge power (which may or may not be achievable, depending on things like the battery temperature, which will affect the upper limit to charge speed, as reflected in the sensor.bms_charge_rate which is in amps, here it is flipping between 20A, 35A and 50A depending on sensor.bms_cell_temp_low. The sensor.battery_charge would also indirectly reflect that). So if I understand things correctly (somewhat questionable!), we need an object to sit in the middle, if queried it should return sensor.battery_charge for the instantaneous battery charge rate (which could be changing from one moment to the next, if there is PV input, for example), and if written it should write to number.force_charge_power for the commanded force charge rate (in both case doing kW-W conversions if needed). Seems strange to me since it is conflating two different things, so I might be on the wrong track here. Perhaps instead of sensor.battery_charge we should be looking at sensor.bms_charge_rate as an upper limit on the force charge rate, combined with the battery voltage. i.e., when queried we should return the lower of either number.force_charge_rate, or (sensor.bms_charge_rate*sensor.invbatvolt). This seems somewhat more logical to me since it is telling predbat what it is able to do, rather than whatever happens to be happening right now with PV and so forth. Not entirely sure of the best way to do that, I'm still somewhat of a newbie. Perhaps a helper number + a couple of automations to write it's contents to number.force_charge_power if written to, and another to update it from sensor.bms_charge_rate whenever that changes?
|
No, this isn't quite right. Instantaneous current rate that the battery is charging or discharging at is defined as 'battery power' in apps.yaml https://springfall2008.github.io/batpred/apps-yaml/#battery-information The charge rate https://springfall2008.github.io/batpred/apps-yaml/#chargedischarge-rate (either in watts or percentage value) is the rate that the inverter is set to force charge at. When you do a charge of the battery at full rate then predbat sets this to the maximum value for your inverter and then issues a 'start charge' command. To stop charging predbat will set this to zero as well as issuing a stop charge command. from what you have said you just need to configure charge rate to number.force_charge_power in apps.yaml (and similar for discharge) |
Great stuff, that sounds way easier :-) Thank you. |
|
It looks like that isn't enough. Service call number/set_value data {'value': 5800, 'entity_id': 'number.force_charge_power'} failed with response None predbat seems to be expecting this (write only) value to return something. It also seems to be writing watts not kw as required. |
|
If you look in the entities list for the FoxESS modbus device, can you see it's contents? In the predbat/config page, I see: and in development tools, I see: If you set a 'friendly name' when configuring the integration, the name might have a prefix (for example, number.foxess_force_charge_power) |
|
Min 0 and Max 7 would be a problem when predbat is trying to set it to 5800 :) |
|
Yeah I haven't tried to address the kW to W thing yet, not sure whether it will handle it or not. I'm running in read-only mode so my installation probably won't ever try to write to it. As far as the plan and the charts are concerned, it all looks good, so it's just the control side of things? I'm using a manually configured charge curve (battery_charge_power_curve in the apps.yaml above) so that's one additional factor which is simpler on my side. If yours is trying to estimate a charge curve then that might also be affected by the kW/W thing. |
|
A W to KW translator seems to work, as in it sets what seem to be sane values. |
If a charge curve isn't supplied, I think it'll try to figure it out from your historical charge data (IIRC, it doesn't simply default to 100%). What I was wondering was if the automatic charge curve might have been the cause of your battery line being flat in your chart. If it is trying to generate it from kW figures without converting, it might have decided that your charge curve was basically 0.001 all the way through the SoC range, hence a flat line. Just a theory, don't know if it holds water or not, but might explain why mine was looking OK and yours wasn't. |
|
Since I think we understand this aspect of the configuration now, how about the other things in the fox.yaml? For example, I think it would be good to get Feed-in First etc working. Not entirely sure I understand which Fox work mode maps onto which predbat work mode, but this is my first guess:
|
The charge curve is optional Predbat does default the charge curve to 100% all the way if you don't specify anything in apps.yaml, or if you set the charge curve to 'auto' it will try to work it out from historical data - but this auto-determination is clearly logged as such in the logfile. https://springfall2008.github.io/batpred/apps-yaml/#battery-chargedischarge-curves |
Ah that must be it, thank you |
The mappings you have presented sound logical, except I see you have mapped Feed-in First to both Freeze charge and Freeze Discharge services. [The Predbat terminology changed recently so what was previously called Discharge is now called Export. The service names look to have not changed though] In Predbat the behaviour of these is different:
https://springfall2008.github.io/batpred/what-does-predbat-do/#predbat-modes It sounds from your description that Feed-in First more closely matches Freeze Export. If there isn't an equivalent of Freeze Charge then you can set support_discharge_freeze to False |
|
I had a go at creating charge_rate_kw and discharge_rate_kw but although it appeared to work I wasn't happy with the amount I had to change (I've never worked on a homeassistant plugin before, and I'm not going to submit anything that would break stuff). Ideally it'd just understand which it was supposed to be using and translate automatically, but where the reading seems to go through a routine that does that, writing all goes direct and it's probably a big change to make that happen.. I've stuck my automations etc. on github in the hope that it helps others: The only thing left I had to override is the minimum battery % (predbat_set_reserve_min) which seems to be set only by the UI and defaults to 4% whereas fox won't let you set a minimum below 10%, otherwise the predictor kept trying to predict it'd run lower. |
|
@springfall2008 @gcoan I think Tony's workaround has pinpointed what the ideal fix would be. Firstly if predbat were able to adapt to a kW entity for these two settings when it needs to command the inverter's charge rate, it would be the simplest solution. Secondly, if the fox.yaml could be updated to refer to number.force_charge_rate and number.force_discharge_rate instead of sensor.bms_charge_rate and sensor.bms_discharge_rate if/when a kW entity is supported, then that would be great. The two sensors are purely read-only so can't be used to command the charge or discharge rates. It has been confirmed that sensor.bms_(dis)charge_rate isn't correct. https://foxesscommunity.com/viewtopic.php?p=7004#p7004 In the short term, perhaps update the comments or documentation with Tony's suggested workaround above (if it looks good to you)? Also, would it be possible to add these into the fox.yaml? Now that the 'freeze export blocked by metric minimum improvement export' issue has been identified, the freeze export is actually behaving correctly in my plan so I think the above is good-to-go. I've discovered that some of the fox inverters also have two more work-modes: 'backup', and 'peak shaving', mine has neither of these, so I don't know what they do, or if they are at all relevant to predbat. There are also two more charge/discharge rate controls, but I don't think they would be suitable. They change everything, including PV charging and supporting the house load, not just the force charge and force discharge modes (they're in amps too). So I feel that these should be ignored unless that's something that predbat wants to control. |
Describe the bug
Predbat consistently suggests I'll use at most 0.005w of battery which means it never predicts any battery usage. Other values seem reasonable and historical battery usage is plotted correctly.
Used the fox.yaml from https://raw.githubusercontent.com/springfall2008/batpred/main/templates/fox.yaml with some minor adjustments for Octopus and setting the soc_max to 10.36 to match my battery.
Expected behaviour
Some prediction of usage, even it it's not accurate yet due to shortage of data.
Predbat version
8.13.3
Environment details
Screenshots
Log file
Can you capture a log file from the time of the issue, debug mode is not normally required.
Predbat debug yaml file
predbat_debug.yaml.txt
Enable debug mode and let Predbat run for one cycle. Look in the 'debug' directory under the Predbat add-on and take the .yaml file for the time period in question.
Rename the predbat_debug_XX_XX_XX.yaml to predbat_debug_XX_XX_XX.yaml.txt and upload it to Github. This will allow your plan to be reproduced and also stores all your settings for review.
The text was updated successfully, but these errors were encountered: