batpred
batpred copied to clipboard
springfall2008
House battery being used when car is charging despite "Car charging hold" being set
Describe the bug My house battery is being used when car is charging despite "Car charging hold" being set.
The scenario is a little complicated. I plugged the car in to take advantage of solar but Intelligent Octopus Go decided it would like to charge the car immediately. So the car is getting power from 3 sources: solar, battery (never more than 2kW for some reason) and grid.
For added confusion, the battery is sometimes being charged (for occasional 30 minute slots) but mostly discharging.
I tried reducing the self-sufficiency metric from 5.0 (a recent change) to 3.0 (which I've used for a long time) but this didn't make a discernable difference.
Expected behaviour The battery should not discharge when the car is being charged from the grid
Predbat version
8.17.3
Environment details
- GE 9.5kW with hybrid inverter and some solar panels
- Standard HAOS installer
- The car is an ID.3. The electricity supplier is Octopus Intelligent Go
Screenshots
Log file
Predbat debug yaml file
predbat_debug_14_10_00.yaml.txt
Note that the car reached its target SOC in this cycle so it had stopped charging by 2.10pm
Predbat is on "Control charge" rather than "Control charge and discharge" to stop the car using a forced export. This is toggled in automations. This is a workaround that is fine.
Predbat gets the car slots from Octopus, are you sure they just haven't updated yet?
I suppose the behaviour could be explained by Octopus repeatedly changing its mind about the charging slots and predbat needing to play catch up. It has been tending to do that recently but I don't think it was in this case. The plan knew about the charging slots when it was in Demand status and those slots didn't seem to change.
Perhaps one to monitor. It doesn't often happen that the car is getting charged by solar diversion and even rarer that Octopus decides to charge during the day.
Steve
I literally had this event yesterday, but I think it's to do with the speed at which information is available from Octopus via the API and PredBats consideration of it.
I plugged in the car at 14:36 yesterday, I have a small automation that sets the IOG required charge to 100-battery level + 5% (to account for loss).
Yesterday, IOG immediately decided to charge my car, great, I had cheap elec coming till 3:30pm.
My battery starts discharging as part of this, because PredBat has yet to see this information.
About 5 minutes later, the slots appeared in my plan and my battery correctly got set to 0 output and all was well.
I'm not sure if there is a better hook? IOG was showing binary_sensor.octopus_energy_a_xxxxxxx_intelligent_dispatching = ON before Predbat had the details in the plan, I am tempted to say if that = ON my battery should be set to 0 output.
Otherwise - I feel the responsiveness was reasonably quick and likely cost me less than 2-3p in potential sale of battery before the nightly refill.
There is a watchlist function in apps.yaml that should trigger predbat to run earlier if a sensor changes:
# Watch list, a list of sensors to watch for changes and then update the plan if they change
# This is useful for things like the Octopus Intelligent Slot sensor so that the plan update as soon as you plugin in
# Only uncomment the items you actually have set up above in apps.yaml, of course you can add your own as well
# Note those using +[] are lists that are appended to this list, whereas {} items are single items only
#watch_list:
# - '{octopus_intelligent_slot}'
# - '{octopus_ready_time}'
# - '{octopus_charge_limit}'
# - '{octopus_saving_session}'
# - '+[car_charging_planned]'
# - '+[car_charging_soc]'
# - '{car_charging_now}'
This isn't in the documentation so I need to add it ....
Had this exact issue earlier. The watch_list looks great, I don't quite understand why some use +[] and others use {} though
octopus_charge_limit and car_charging_soc are both mapping to single numeric values, so why are they added differently?
Had this exact issue earlier. The watch_list looks great, I don't quite understand why some use +[] and others use {} though
octopus_charge_limit and car_charging_soc are both mapping to single numeric values, so why are they added differently?
If only we had some documentation to look at 😉 ?
I think its because car_charging_soc can be a list if you have multiple cars https://springfall2008.github.io/batpred/apps-yaml/#multiple-electric-cars
OK, fair point, but in my defence none of the variables are typed in the docs and it isn't actually clear ;)
I don't have multiple cars and the car_charging_soc definition itself (and car_charging_planned) doesn't mention anything about a 'list' and the phrasing "point to a sensor" implies that it is only one single item
car_charging_soc - You should configure this to point to a sensor (on the HA integration for your EV charger) that specifies the car's current charge level expressed as a percentage - it must NOT be set to a sensor that gives the car's current kWh value as this will cause Predbat to charge the car to an incorrect level. If you don't specify a sensor, Predbat will default to 0%.
As I have only one entry, in my system it is not a list, so I think in my case it would also work as {} because of that.
If a single item works using both {} and +[] then I think the additional syntax is unnecessary and confusing and it would make sense to just mandate the use of {} for all entries
I can tidy up the words to make it clearer that car_charging_soc is a list if you have multiple cars.
In your case, yes I think it would work with {}, and be interesting if you can confirm it does. I agree it is a bit confusing having different syntax that is unfortunately not documented at present (other than what's in the actual apps.yaml template), but I would argue that actually using +[] for everything is more future-proofed and flexible for those that do have multiple cars.
But anyway, not proposing to change that, but I will add something to the documentation to describe the watchlist. Let me know if it works as you expect it to for IOG
Sorry, I meant better to just use the list capable format +[] for everything. Will test it out and check.
**The binary_sensor.octopus_energy_xxx_intelligent_dispatching went:
- ON at 12:36:58
- OFF at 12:44:58
- ON at 13:06
- OFF at 14:30
Predbat was:
- Freeze exporting from 09:10:33 - 12:33:29
- Demand 12:33:29 - 13:10:10
- Charging 13:10:10-13:15:31
- Demand 13:15:31 - 13:20:25
- Charging 13:20:25 - 13:24:24
- Demand 13:24:24 - 13:33:56
- Charging 13:33:56 - 13:40:26
- Demand 13:40:26 - 13:50:32
- Charging 13:50:32 - 14:00:24
- Demand 14:00:24 - 14:07:11
- Charging 14:07:11 - 14:12:15
- Hold charging 14:12:15 - 14:21:55
- Demand 14:21:55 - 14:31:31
- Freeze exporting 14:31:31 - 15:11;28
The Zappi was:
- Paused 10:41:54 - 12:34:51
- Boosting (ie Octopus) 12:35:51 - 12:44:56
- Paused 12:44:56 - 12:54:07
- Charging (i.e. solar) 12:54:07 - 12:56:07
- Paused 12:56:07 - 13:00:21
- Charging 13:00:21 - 13:02:34
- Paused 13:02:34 - 13:03:40
- Charging 13:03:40 - 13:06:59
- Boosting 13:06:59 - 14:01:43
- Charging 14:01:43 - 14:03:44
- Boosting 14:03:44 - 14:09:49
- Completed thereafter
The changes around 1pm were probably me trying to workaround the problem, but between 13:06:59 and 14:01:43 it was just Boosting (i.e. Octopus initiating the charge). You'll see from the predbat timeline that predbat was toggling between Demand and Charging during that period.
According to the apps.yaml tab in predbat, I have binary_sensor.octopus_energy_xxx_intelligent_dispatching on the watchlist. It is there as a single item, not any kind of list:
- binary_sensor.octopus_energy_xxx_intelligent_dispatching
- time.octopus_energy_xxx_intelligent_target_time = 08:00:00
- number.octopus_energy_xxx_intelligent_charge_target = 13
- binary_sensor.octopus_energy_xxx_octoplus_saving_sessions
- +[car_charging_planned]
- +[car_charging_soc]
Steve
I have added an explanation of watch_list to the documentation and expanded car_charging_soc to make it clear it can be a list
- binary_sensor.octopus_energy_xxx_intelligent_dispatching
- time.octopus_energy_xxx_intelligent_target_time = 08:00:00
- number.octopus_energy_xxx_intelligent_charge_target = 13
- binary_sensor.octopus_energy_xxx_octoplus_saving_sessions
- +[car_charging_planned]
- +[car_charging_soc]
My take on how this should be configured @stevedundee2 is that it should be a list of apps.yaml configuration item names NOT the underlying sensor names, i,e.
watch_list:
- '{octopus_intelligent_slot}'
- '{octopus_ready_time}'
- '{octopus_charge_limit}'
- '{octopus_saving_session}'
- '+[car_charging_planned]'
- '+[car_charging_soc]'
- '{car_charging_now}'
that's the way I have written the documentation, and if I'm right, thats why its not worked for you
I think in the actual yaml file that's how they are but I copied from the apps.yaml tab in predbat, which seems to expand them. Sorry for the confusion.
In that tab it also shows the current vales, except for binary_sensor.octopus_energy_xxx_intelligent_dispatching. I don't know whether that's a clue or just how binary_sensor works.
Is the watch list the problem? That sensor didn't changed for an hour but predbat was toggling between Demand and Charging multiple times.
Steve
-------- Original Message -------- On 03/04/2025 21:28, Geoffrey Coan wrote:
I have added an explanation of watch_list to the documentation and expanded car_charging_soc to make it clear it can be a list
- binary_sensor.octopus_energy_xxx_intelligent_dispatching
- time.octopus_energy_xxx_intelligent_target_time = 08:00:00
- number.octopus_energy_xxx_intelligent_charge_target = 13
- binary_sensor.octopus_energy_xxx_octoplus_saving_sessions
- +[car_charging_planned]
- +[car_charging_soc]
My take on how this should be configured @.***(https://github.com/stevedundee2) is that it should be a list of apps.yaml configuration item names NOT the underlying sensor names, i,e.
watch_list: - '{octopus_intelligent_slot}' - '{octopus_ready_time}' - '{octopus_charge_limit}' - '{octopus_saving_session}' - '+[car_charging_planned]' - '+[car_charging_soc]' - '{car_charging_now}'
that's the way I have written the documentation, and if I'm right, thats why its not worked for you
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
[gcoan]gcoan left a comment (springfall2008/batpred#2188)
I have added an explanation of watch_list to the documentation and expanded car_charging_soc to make it clear it can be a list
- binary_sensor.octopus_energy_xxx_intelligent_dispatching
- time.octopus_energy_xxx_intelligent_target_time = 08:00:00
- number.octopus_energy_xxx_intelligent_charge_target = 13
- binary_sensor.octopus_energy_xxx_octoplus_saving_sessions
- +[car_charging_planned]
- +[car_charging_soc]
My take on how this should be configured @.***(https://github.com/stevedundee2) is that it should be a list of apps.yaml configuration item names NOT the underlying sensor names, i,e.
watch_list: - '{octopus_intelligent_slot}' - '{octopus_ready_time}' - '{octopus_charge_limit}' - '{octopus_saving_session}' - '+[car_charging_planned]' - '+[car_charging_soc]' - '{car_charging_now}'
that's the way I have written the documentation, and if I'm right, thats why its not worked for you
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Originally the problem was that predbat kept toggling between charging and demand when solar excess was being used by Zappi and Octopus was boosting. There have been loads of predbat updates meantime and I don't know whether something has been fixed, but the past few times have worked correctly. There can be quite long periods where the battery is still being used, but these have all seemed to be explainable by the combination of the wait for Home Assistant to get updates from Octopus and/or the car and then Predbat waiting for the next calculation.
So it seems this is fixed as far as I am concerned.