springfall2008 / batpred Goto Github PK
View Code? Open in Web Editor NEWHome battery prediction and charging automation for Home Assistant, supporting many inverter types
Home Page: https://springfall2008.github.io/batpred/
Home battery prediction and charging automation for Home Assistant, supporting many inverter types
Home Page: https://springfall2008.github.io/batpred/
I noticed that scheduled charge was working fine - however scheduled discharge was being ignored by the system.
On investigating the givTCP entities, enable charge schedule was "true"
Enable discharge was "false" - and if set to "true" manually, would quickly revert to false
Could that be why there is a problem?
I see in config we have:
scheduled_charge_enable:
- switch.givtcp_{geserial}_enable_charge_schedule_2
But there is no corresponding entry for scheduled discharge enable?
(note, the _2 suffix was added due to an issue with givTCP recently where all MQTT entities were renamed)
I have noticed that if it is currently within the discharge window, and the recalc wants to update the start or end time, sending that instruction to GivTCP appears to disable Force Discharge. This means the invertor stops exporting until the next recalc cycle at which point the Force Discharge setting is re-enabled.
This is similar to something I recall happening when I was hand rolling automations for charging/discharging so it could be the result of a GivTCP bug but if batpred checked, and updated if necessary, the Force Discharge setting after the discharge window has been set the impact would be minimised.
Alternatively, would it be worth separating the optimisation and actions (setting the correct values) into separate loops? This would mean you could rerun the calculations at a lower frequency, but have a higher frequency loop to check the values match the output of the last optimisation. The log currently seems to occaionally have workarounds for different bugs logged out which this could also take out of the optimisation loop.
My system has an export limitation in place, I have been playing around with a simple script to try and optimize charging so that when we generate > Export we can pipe the spare into the battery. This has meant that instead of capping out at 5kw it has been able to cap closer to the total PV value so the system.
I would be nice if batpred supported this sort of thing, it would improve generation for anyone where PV > Invertor output.
Just as the title says. It's in the octopus integration under
sensor.octopus_energy_electricity_numbershere_morenumbershere_current_standing_charge
Line 1792 in 0713c71
The car_charge_limit
is read from app.yaml
, but overwrites the charge limit read from the octopus intelligent details. Probably want to read the "static" value first, then overwrite with the octopus value if available.
Great work by the way.
I don't have an electric vehicle, I also only have 1.3kw Solar panels, and to add insult to injury, I don't get paid for export. I am on the agile tariff. So what would be the best settings for for this? I have an 8.2kwh batter with a DoD of 100%
Is there an option somewhere where you can minimise grid imports?
Hi i noticed that something odd on the log:
@ TS 00:15:52. it said now 09-19 23:14:00. Tim zone is Europe/London both on appdaemon.yml and apps.yaml.
My first charge slot was at 23:30-00:00. tht was triggered correctly, but at 23:45, th aemon changed the start tim to 22:30-2300.
2023-09-20 00:15:52.565870 INFO pred_bat: Charge window will be: 2023-09-21 05:00:00+01:00 - 2023-09-21 05:30:00+01:00 - current soc 78.target 100
2023-09-20 00:15:52.567479 INFO pred_bat: Configuring charge window now (now 09-19 23:14:00 target set_window_minutes 30 charge start time 09-20 05:00:00
2023-09-20 00:15:52.569196 INFO pred_bat: Inverter 0 charge window is 05:00:00 - 05:30:00, being changed to 05:00:00 - 05:30:00
**2023-09-20 00:15:52.570634 INFO pred_bat: Not setting charging SOC as we are not within the window (now 09-19 23:14:00 target set_soc_minutes 30 charge start time 09-20 05:00:00)**
2023-09-20 00:15:52.572087 INFO pred_bat: Adjust reserve to default (as set_reserve_enable is true)
2023-09-20 00:15:52.573503 INFO pred_bat: Inverter 0 Current reserve is 4.0 already at target
2023-09-20 00:15:52.574932 INFO pred_bat: Completed run status Idle
2023-09-20 00:15:52.586617 INFO AppDaemon: Previous message repeated 1 times
2023-09-20 00:15:52.587008 WARNING AppDaemon: Excessive time spent in callback 'update_time_loop() in pred_bat', Thread 'thread.thread-1' - now complete after 82.585794 seconds (limit=60.0)
also plots have gone weird after midnight.
edit:plots came back okay at 0100 and this was in the log:
2023-09-20 01:04:55.021018 INFO pred_bat: Inverter 0 Updated start and end charge window to 00:30:00 - 01:00:00 (old 00:46:00 - 01:00:00)
It seems the v3.0 branch has some breaking changes, where detailedForecast is replaced by forecast - need to support this
Great project - thanks for all the hard work. I have a suggestion for a feature. I'd like to be able to leave space in the battery when it charges from the grid.
I have a 3.6 kW hybrid inverter with a 9.5 kWh battery and 4.4 kW of PV. I'm on the Octopus Flux tariff. In the middle of the day, if my battery is full and the PV is generating (for example) 4.4 kW, then 3.6 kW goes to the grid, but the remaining 800 W is lost. If there was space in the battery, some would go to the grid and some to the battery, and nothing would be lost. I can't see a way of doing that with the current config options.
The simplest implementation I can think of would be a "best_soc_max" that sets the maximum that'll charge from the grid, leaving some space for the surplus later in the day. Along with that, setting the battery charge power to (for my example case) 800 W would mean at max PV generation 3.6 kW goes to the grid and the excess to the battery.
More sophisticated would be to calculate the likely excess, based on the max output of the inverter, the capacity of the PV and the solar forecast, and use that to set the max SOC during the grid charge.
Hi
I love the tool you've created. I'm trying to tune it to do what I want whilst I'm waiting for our export MPAN to be issued.
I've modified the config to
best_soc_margin: 0 best_soc_min: 0 best_soc_keep: 0 best_soc_step: 0.25 best_soc_pass_margin: 0
As you will see, the best and best10 predictions keep a reserve of around 2kwh prior to the overnight charging window where I would have expected it to maximise discharge, and estimate hitting 0kwh just before the charging window.
Any tips to tweak this would be great.
Thanks
Originally opened on Facebook: I no longer have Load, PV or Import data appearing in the pred_bat log and also not in the Data or Power charts. This data is available from GivTCP. As requested logs are attached
home-assistant_2023-09-20T19-42-32.646Z.log
appdaemon.log
a0d7b954_appdaemon_2023-09-20T19-33-41.581Z.log
Maybe add a short description of each entity in a field so the user can click on one and read it.
Different users have varying needs for averaging of consumption data - from previous day only to 3/5/7/14-day average, but also the same day last week appears popular for those with a weekly usage cycle. Also, giving yesterday's consumption a higher weighting than earlier days is a useful technique.
Consider mirroring the more flexible scheme of weighted averages that I recently introduced in palm.py. It can accommodate (almost) any regime a user could dream up. Here are some examples:
# Uncomment required settings or make your own using positive integers only. Examples:
# Most recent day only
# load_hist_weight = [1]
# 3-day average
load_hist_weight = [1, 1, 1]
# 7-day average
# load_hist_weight = [1, 1, 1, 1, 1, 1, 1]
# Same day last week - useful if, say, Monday is always wash-day
# load_hist_weight = [0, 0, 0, 0, 0, 0, 1]
# Weighted average (a more extreme example)
# load_hist_weight = [4, 2, 2, 1, 1, 1, 1]
When people go away their usage profile changes.
A holiday mode toggle could change days_previous to '1' while away rather than using say 7/14 days previous. It's easier than modifying the apps.yml
Hi, I think it'd be good to update the README with some info to help others to contribute, if you're up for them doing that.
Things like:
There may be other things, but they're what came to mind.
I'm getting the following error:
2023-07-25 10:10:04.340105 WARNING pred_bat: ------------------------------------------------------------
2023-07-25 10:10:04.340366 WARNING pred_bat: Unexpected error in worker for App pred_bat:
2023-07-25 10:10:04.340596 WARNING pred_bat: Worker Ags: {'id': '69099532cee14d6ca41329e600f77a94', 'name': 'pred_bat', 'objectid': '28934eeb431f40c8870d421805df2dce', 'type': 'scheduler', 'function': <bound method PredBat.run_time_loop of <predbat.PredBat object at 0x7f42499d1d90>>, 'pin_app': True, 'pin_thread': 1, 'kwargs': {'interval': 300, 'random_start': 0, 'random_end': 0, '__thread_id': 'thread-1'}}
2023-07-25 10:10:04.340769 WARNING pred_bat: ------------------------------------------------------------
2023-07-25 10:10:04.343343 WARNING pred_bat: Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/appdaemon/threading.py", line 1022, in worker
funcref(self.AD.sched.sanitize_timer_kwargs(app, args["kwargs"]))
File "/config/appdaemon/apps/batpred/predbat.py", line 4044, in run_time_loop
raise e
File "/config/appdaemon/apps/batpred/predbat.py", line 4040, in run_time_loop
self.update_pred(scheduled=True)
File "/config/appdaemon/apps/batpred/predbat.py", line 3549, in update_pred
metric, self.charge_limit_percent, import_kwh_battery, import_kwh_house, export_kwh, soc_min, soc, soc_min_minute = self.run_prediction(self.charge_limit, self.charge_window, self.discharge_window, self.discharge_limits, self.load_minutes, pv_forecast_minute, save='base', end_record=end_record)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/appdaemon/apps/batpred/predbat.py", line 1854, in run_prediction
save, self.time_abs_str(end_record + self.minutes_now), self.dp2(final_soc), self.dp2(final_metric), self.dp2(soc_min), self.time_abs_str(soc_min_minute), self.dp2(final_load_kwh), self.dp2(final_pv_kwh)))
^^^^^^^^^
UnboundLocalError: cannot access local variable 'final_soc' where it is not associated with a value
2023-07-25 10:10:04.343602 WARNING pred_bat: ------------------------------------------------------------
Config file is using the standard REST connection:
givtcp_rest:
- 'http://homeassistant.local:6345'
However, when I comment out the REST comment so it uses the HA entity control, predbat starts working fine. Switching back to REST control and predbat continues to work fine.
This has happened a couple of times now.
It seems like if the communication via REST becomes broken then it doesn't try to recover that connection other than restarting predbat.
Hi Trefor,
To run multiple instances of batpred do I just need to duplicate apps.yaml and in the second one change the name of the two following tags below?
pred_bat2:
module: predbat
class: PredBat
prefix: predbat2
It looks like the most recent release as of June 6th may have a small problem?
2023-06-06 22:10:00.030098 WARNING pred_bat: Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/appdaemon/threading.py", line 1022, in worker funcref(self.AD.sched.sanitize_timer_kwargs(app, args["kwargs"])) File "/config/appdaemon/apps/batpred/predbat.py", line 2552, in run_time_loop self.update_pred() File "/config/appdaemon/apps/batpred/predbat.py", line 2065, in update_pred load_minutes = self.minute_data_load(now_utc) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/appdaemon/apps/batpred/predbat.py", line 715, in minute_data_load entity_ids = self.get_arg('load_today', indirect=False) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/appdaemon/apps/batpred/predbat.py", line 599, in get_arg value = self.resolve_arg(arg, value, default=default, indirect=indirect, combine=combine, attribute=attribute, index=index) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/appdaemon/apps/batpred/predbat.py", line 577, in resolve_arg item = self.resolve_arg(arg, item, default=default, indirect=indirect) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/config/appdaemon/apps/batpred/predbat.py", line 584, in resolve_arg value = value.format(**self.args) ^^^^^^^^^^^^^^^^^^^^^^^^^ KeyError: 'geserial'
Looking at the prebat.py 4.0 source, I can't see any code to handle the responses listed in apps.yaml? Am I missing some aspect to how the car charging prediction now works?
Setting the car_charging_planned to a sensor results in:
INFO pred_bat: WARN: Return bad int value EV Disconnected from car_charging_planned
2023-06-02 12:14:21.136105 INFO pred_bat: Previous message repeated 848 times
apps.yaml
car_charging_planned_response:
- 'yes'
- 'on'
- 'true'
- 'connected'
- 'ev connected'
- 'charging'
- 'paused'
- 'waiting for car demand'
- 'scheduled'
- 'enabled'
- 'latched'
- 'locked'
- 'plugged in'
predbat.py:
planned = self.get_arg('car_charging_planned', False)
if isinstance(planned, str):
if planned.lower() in self.get_arg('car_charging_planned_response', ['yes', 'on', 'enable', 'true']):
planned = True
else:
planned = False
I'm Octopus Flux so your script correctly detected high export rate between 4-7PM. I have a gen 1 GIV-HY5.0 inverter that can only export 2500kwh and yet the script insists on starting export at 17:30 and exporting 4.6kwh in 1.5hours. My inverter needs 2 hours to export that amount so I suspect that something somewhere is set incorrectly.
I looked in the config but there is no place to define max charge/discharge rate.
BTW in the logs I can see this:
Found 1 inverters total reserve 0.38 soc_max 9.52 soc 8.95 charge rate 2.6 kw discharge rate 2.6 kw ac limit 5.0 kw loss charge 4 % loss discharge 4 % inverter loss 6 %
so it clearly knows the limits and yet the data produced is wrong
When set_window_notify (also set_discharge_notify, set_soc_notify, set_reserve_notify) are set to True, Home Assistant will send a notification to any phones with the companion app installed. This is fine and useful for me, but my SO doesn't need to know the ins and outs of battery charging. It would be great to have section in apps.yaml to configure which devices receive the notification, instead of all-or-nothing
I followed your guide and video on setting up IO having switched from Flux, and have therefore set my settings as per https://github.com/springfall2008/batpred#cheap-night-rate-with-a-good-export-rate-eg-intelligent-with-octopus-outgoing
I kinda expected that predbat would schedule export at the end of the window thus minimising the risk of running out, but it seems to be scheduling a few random tiny discharge_best drops throughout the window with the final large one ending half an hour before the low rate kicks in:
Does that seem right?
Thanks
Adam
Some users would like to hold discharge of the battery when their car charges, add this as an option
Some users would like charts in battery % rather than kWh
Line 996 in b4983ba
I have a new feature request (unless it is already there and I've missed it!)
Currently when the EV is charging on grid power (in my case during an Intelligent Octopus charging slot) and the target SoC is below the battery's current SoC, the battery discharges into the EV.
To reduce unnecessary battery cycles, I'd prefer if there was an option to hold the existing battery SoC (i.e. disable discharging) whilst in an active charging slot (or for non-IO users if it detects the EV is charging from grid).
I know this might mean that by the end of the night's cheap rate the battery SoC stays higher than the target SoC meaning a full battery earlier than planned resulting in exporting solar (although I have a solar diverter to avoid this) but I would rather export solar during the day than charge my EV direct from the battery overnight.
Is this easy to do or is it a silly idea because of something I've missed?
When batteries are over voltage and go from 100% to 0% SoC due to a bug in GE's reporting. BatPred misscalculates SoC targets as it thinks there is less battery capacity.
Saw this today on a 2 * 5.2 setup, where first one battery "faulted" and only 4.2kws was used for calcs, then when my second one over voltaged it went up to 5.1 for some reason.
I Know GE were meant to fix this at some point in the future. But not sure what update its in.
This is a suggestion rather than specifically an issue.
I have noticed that for due to the periodic scheduling of batpred, you can miss out on part of your discharge window because both the window and the force discharge need to be set. The window can be set in advance but the force discharge can only be set by the first scheduled run within the discharging window, so in the worst case you will miss out on discharging for period equal to your recalc period length.
What would be nice is if the next scheduled recalc is after the start of the discharge window, that a recalc is specifically scheduled to run at the start of the discharge window, or potentially a specific task to enable force discharge.
This would mean that the usual recalc loop could be performed at a much lower frequency (every 30 mins) without the loss of export time.
Line 512 should be testing for the existence of metric_octopus_export
, not metric_octopus_import
:
if 'metric_octopus_export' in self.args:
instead of
if 'metric_octopus_import' in self.args:
Running code through the pylint linting tool identifies some things to be fixed... "Your code has been rated at -6.17/10"
Since the Octopus energy was updated https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy it seems that batpred can no longer read the rates from it.
sensor.octopus_energy_electricity_22l4330885_2199998082940_current_rate is what my rate sensor is called, just in case your auto discovery is looking for something different
I'd like the value of the battery prior to end of day forced charge/discharge so that I can plot this as a gauge on the dashboard (I therefore know how much extra energy I can use in the day as a value to drive automations etc)
Hi
I’m not sure if this is just too fine grained to be handled, and its not a major issue… but I noticed that when I initiated an Octopus Intelligent bump charge (which is at the ‘day’ import rate) that Predbat started to charge my giv battery (not just the car). I figure this is because it sees the planned_dispatches on the dispatching sensor but perhaps doesn’t differentiate between the source (bump-charge vs smart-charge) and presumes the dispatch window is at the cheap rate?
No big deal but thought I’d let you know.
Many thanks for your work @springfall2008 - its a great tool.
Adam
Currently all notifications go to notify.notify
. Would it be possible to make this a configurable option as notify
sends to all "people" in HA. Had a look at the code and it looks like some of the work for this has already been done, it's just not exposed in a way we can configure.
Octopus have introduced Power-ups in my area, where I can opt in to get 2 hours of free electricity. The Agile rate shown on my meter will not change but Octopus will credit my account in about 2 weeks time to make it free. My question for Trefor is whether there is a way to factor this in to Predbat so that it keeps some capacity in my battery before this 2 hour window to allow me to charge from the grid for free. Many thanks.
Currently predbat will ovewrite charge and discharge rate settings, but the user can't set the max/min themselves.
This is a fantastic tool.
One thing I noticed, was that though I had the solcast integration installed, the entities created didn't have "solcast" in the entity names, so did not match the default config file. Easy to fix - I simply removed the bolt sections below.
I mention it only because the comments in that file suggest they won't need changing, so if it is a change in nomenclature by the solcast integration it might be good to know. Cheers either way!!
#Set these to match solcast sensor names (unlikely to need changing)
pv_forecast_today: sensor.**solcast_**forecast_today
pv_forecast_tomorrow: sensor.**solcast_**forecast_tomorrow
pv_forecast_d3: sensor.**solcast_**forecast_d3
pv_forecast_d4: sensor.**solcast_**forecast_d4
Errors being generated once target SoC has been set (e.g. first charge window 23:30, initial target SoC set at 23:04, errors start appearing from 23:09 onwards). Predbat stops the current cycle after generating this error...
2023-05-31 23:09:28.550241 WARNING pred_bat: ------------------------------------------------------------
2023-05-31 23:09:28.550859 WARNING pred_bat: Unexpected error in worker for App pred_bat:
2023-05-31 23:09:28.551057 WARNING pred_bat: Worker Ags: {'id': '59e7d07f2e0f480d9ec0c6952185feb7', 'name': 'pred_bat', 'objectid': 'dbe1e7dd995a4ba58ff99662476fac52', 'type': 'scheduler', 'function': <bound method PredBat.run_time_loop of <predbat.PredBat object at 0x7f5b96148950>>, 'pin_app': True, 'pin_thread': 1, 'kwargs': {'interval': 300, '__thread_id': 'thread-1'}}
2023-05-31 23:09:28.551512 WARNING pred_bat: ------------------------------------------------------------
2023-05-31 23:09:28.552965 WARNING pred_bat: Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/appdaemon/threading.py", line 1022, in worker
funcref(self.AD.sched.sanitize_timer_kwargs(app, args["kwargs"]))
File "/config/appdaemon/apps/predbat.py", line 2401, in run_time_loop
self.update_pred()
File "/config/appdaemon/apps/predbat.py", line 2098, in update_pred
self.charge_limit = [self.current_charge_limit * self.soc_max / 100.0 for i in range(0, len(self.charge_window))]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/appdaemon/apps/predbat.py", line 2098, in
self.charge_limit = [self.current_charge_limit * self.soc_max / 100.0 for i in range(0, len(self.charge_window))]
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
TypeError: can't multiply sequence by non-int of type 'float'2023-05-31 23:09:28.553132 WARNING pred_bat: ------------------------------------------------------------
Line 2080 originally has:
self.current_charge_limit = inverter.current_charge_limit
I've temporarily fixed it by converting it to a float:
self.current_charge_limit = float(inverter.current_charge_limit)
Also possibly linked to this (maybe an error somewhere else or due to my "float" change) a warning on the main appdaemon.log:
2023-06-02 02:44:02.541499 INFO pred_bat: WARN: Return bad value number.givtcp_ce1234g567_target_soc from soc_percent
2023-06-02 02:44:02.543557 INFO pred_bat: Inverter 0 Current SOC is 100.0 % and new target is 29 %
2023-06-02 02:44:02.582685 INFO pred_bat: Inverter 0 Current reserve is 29.0 already at target
The above can't seem to read the inverter's current target SoC so it constantly sets it to the expected 29% target every 5 minutes even though it is already set to 29%.
Hi Trefor,
As per FB, last night there was 69% battery remains at 21:43, with the Intelligent off-peak rate starting at 23:30.
Any idea why it wasn't discharging? Logs from today enclosed. I will update when it happens again.
Ab Iboost (Eddi boost) when rate below zero and stop battery discharging to house would work
Before 16:00, predbat.rates shows an incorrect value at 23:00 and 23:30. For me it shows at 38p/kWh.
The Agile rates are published up until 22:30, and I think batpred uses yesterday's rates to extrapolate forwards? It seems to be fine from 00:00 onwards, using the previous day's values.
38 p/kWh is much higher than the average rate and it's pushing up the "average" attribute of predbat.rates
Sorry if I've explained this badly - let me know if you need anything more!
Hi Trefor.
Not sure this is an issue with the calculations or just my own specific setup (using latest v6.7) but last night the calculated target SoC was fluctuating every 5 minutes.
My Zappi was charging the car too so the battery was discharging into the EV when the target was below the actual SoC (this is something I would prefer it not to do even if it means the actual SoC ends up higher than the target SoC at the end of the final Intelligent Octopus cheap charging window at 5:30am).
But because the target SoC would move between either side of the actual SoC, the battery was charging then discharging into the EV. Solcast forecast wasn't changing - everything should be static.
This is an extract of the log showing it moving around every 5 minutes:
2023-07-18 00:00:05.061102 INFO pred_bat: predict base end_record 07-18 23:30:00 final soc 2.05 kwh metric 160.74 p min_soc 0.38 @ 07-18 01:15:00 kwh load 33.38 pv 12.48
2023-07-18 00:00:05.064066 INFO pred_bat: [ 00:00, 01:00, 02:00, 03:00, 04:00, 05:00, 06:00, 07:00, 08:00, 09:00, 10:00, 11:00, 12:00, 13:00, 14:00, 15:00, 16:00, 17:00, 18:00, 19:00, 20:00, 21:00, 22:00, 23:00]
2023-07-18 00:00:05.066968 INFO pred_bat: SOC: [ 4.48, 1.38, 0.38, 0.38, 0.38, 0.38, 0.38, 0.38, 0.42, 0.46, 0.67, 1.2, 1.78, 2.69, 3.64, 4.31, 4.74, 4.92, 5.03, 4.94, 4.65, 4.03, 3.16, 2.37]
2023-07-18 00:00:05.069773 INFO pred_bat: STATE: [ g<be-, g<be-, g<be-, g<be-, g<be-, g<be-, g<be-, g~be+, g<be-, g~be+, g~be+, g~be-, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be-, g~be-, g~be-, g~be-, g~be-]
2023-07-18 00:00:05.073700 INFO pred_bat: LOAD: [ 0.0, 4.26, 8.59, 13.48, 17.93, 22.27, 22.82, 23.26, 23.81, 24.51, 25.2, 25.8, 26.57, 27.2, 27.77, 28.44, 29.04, 29.67, 30.12, 30.53, 30.9, 31.5, 32.32, 33.08]
2023-07-18 00:00:05.076779 INFO pred_bat: PV: [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.07, 0.37, 0.91, 1.62, 2.52, 3.68, 5.08, 6.66, 8.23, 9.6, 10.66, 11.49, 12.06, 12.38, 12.47, 12.48, 12.48, 12.48]
2023-07-18 00:00:05.079809 INFO pred_bat: IMPORT: [ 0.0, 1.32, 4.7, 9.59, 14.04, 18.37, 18.85, 19.0, 19.06, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1, 19.1]
2023-07-18 00:00:05.089595 INFO pred_bat: EXPORT: [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
2023-07-18 00:00:05.092586 INFO pred_bat: CAR: [ 0.0, 3.89, 8.8, 13.7, 18.61, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52, 23.52]
2023-07-18 00:00:05.106100 INFO pred_bat: METRIC: [ 0.0, 9.87, 35.21, 71.89, 105.29, 137.81, 150.9, 156.65, 159.29, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74, 160.74]
2023-07-18 00:00:05.774754 INFO pred_bat: Battery has 1.25 hours left - now at 4.48
2023-07-18 00:00:08.035205 INFO pred_bat: Inverter 0 Current charge Limit is 40.0 % and new target is 34 %
2023-07-18 00:05:03.842971 INFO pred_bat: predict base end_record 07-18 23:30:00 final soc 2.08 kwh metric 159.14 p min_soc 0.38 @ 07-18 01:20:00 kwh load 33.12 pv 12.52
2023-07-18 00:05:03.845925 INFO pred_bat: [ 00:05, 01:05, 02:05, 03:05, 04:05, 05:05, 06:05, 07:05, 08:05, 09:05, 10:05, 11:05, 12:05, 13:05, 14:05, 15:05, 16:05, 17:05, 18:05, 19:05, 20:05, 21:05, 22:05, 23:05]
2023-07-18 00:05:03.848998 INFO pred_bat: SOC: [ 4.38, 1.28, 0.38, 0.38, 0.38, 0.38, 0.38, 0.39, 0.38, 0.49, 0.75, 1.23, 1.94, 2.86, 3.75, 4.38, 4.82, 5.0, 5.09, 4.93, 4.65, 4.0, 3.12, 2.34]
2023-07-18 00:05:03.851784 INFO pred_bat: STATE: [ g~be-, g<be-, g<be-, g<be-, g<be-, g<be-, g<be-, g~be-, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-]
2023-07-18 00:05:03.854619 INFO pred_bat: LOAD: [ 0.0, 4.38, 8.7, 13.58, 18.04, 22.05, 22.58, 23.03, 23.68, 24.3, 24.97, 25.66, 26.34, 26.95, 27.56, 28.24, 28.84, 29.46, 29.9, 30.32, 30.66, 31.29, 32.12, 32.87]
2023-07-18 00:05:03.857382 INFO pred_bat: PV: [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.09, 0.41, 0.97, 1.71, 2.65, 3.85, 5.27, 6.86, 8.41, 9.74, 10.8, 11.63, 12.16, 12.44, 12.51, 12.52, 12.52, 12.52]
2023-07-18 00:05:03.860205 INFO pred_bat: IMPORT: [ 0.0, 1.43, 4.9, 9.78, 14.24, 18.24, 18.69, 18.83, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92, 18.92]
2023-07-18 00:05:03.863068 INFO pred_bat: EXPORT: [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
2023-07-18 00:05:03.866077 INFO pred_bat: CAR: [ 0.0, 4.06, 8.96, 13.87, 18.78, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28, 23.28]
2023-07-18 00:05:03.868986 INFO pred_bat: METRIC: [ 0.0, 10.72, 36.73, 73.38, 106.8, 136.82, 149.95, 155.4, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14, 159.14]
2023-07-18 00:05:04.111692 INFO pred_bat: Battery has 1.25 hours left - now at 4.38
2023-07-18 00:05:23.988556 INFO pred_bat: Inverter 0 Current Reserve is 34.0 % and new target is 42 %
2023-07-18 00:10:03.969237 INFO pred_bat: predict base end_record 07-18 23:30:00 final soc 2.08 kwh metric 160.49 p min_soc 0.38 @ 07-18 01:20:00 kwh load 32.92 pv 12.52
2023-07-18 00:10:03.972195 INFO pred_bat: [ 00:10, 01:10, 02:10, 03:10, 04:10, 05:10, 06:10, 07:10, 08:10, 09:10, 10:10, 11:10, 12:10, 13:10, 14:10, 15:10, 16:10, 17:10, 18:10, 19:10, 20:10, 21:10, 22:10, 23:10]
2023-07-18 00:10:03.974940 INFO pred_bat: SOC: [ 4.09, 0.93, 0.38, 0.38, 0.38, 0.38, 0.38, 0.39, 0.4, 0.51, 0.78, 1.29, 2.05, 2.9, 3.82, 4.47, 4.84, 5.01, 5.09, 4.9, 4.62, 3.95, 3.06, 2.28]
2023-07-18 00:10:03.977675 INFO pred_bat: STATE: [ g<be-, g<be-, g<be-, g<be-, g<be-, g<be-, g<be-, g<be-, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be-, g~be-, g~be-, g~be-, g~be-, g~be-]
2023-07-18 00:10:03.980556 INFO pred_bat: LOAD: [ 0.0, 4.55, 8.87, 13.75, 18.22, 21.89, 22.42, 22.88, 23.53, 24.16, 24.84, 25.51, 26.16, 26.84, 27.41, 28.04, 28.69, 29.3, 29.73, 30.17, 30.5, 31.14, 31.99, 32.73]
2023-07-18 00:10:03.983367 INFO pred_bat: PV: [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.11, 0.45, 1.03, 1.78, 2.75, 3.96, 5.4, 6.99, 8.53, 9.84, 10.88, 11.68, 12.19, 12.45, 12.51, 12.52, 12.52, 12.52]
2023-07-18 00:10:03.986270 INFO pred_bat: IMPORT: [ 0.0, 1.55, 5.35, 10.23, 14.69, 18.36, 18.78, 18.91, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0, 19.0]
2023-07-18 00:10:03.989287 INFO pred_bat: EXPORT: [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
2023-07-18 00:10:03.992100 INFO pred_bat: CAR: [ 0.0, 4.23, 9.13, 14.04, 18.95, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04, 23.04]
2023-07-18 00:10:03.994904 INFO pred_bat: METRIC: [ 0.75, 12.39, 40.85, 77.45, 110.93, 138.44, 151.51, 156.75, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49, 160.49]
2023-07-18 00:10:04.234854 INFO pred_bat: Battery has 1.1666666666666667 hours left - now at 4.09
2023-07-18 00:10:59.225191 INFO pred_bat: Inverter 0 Current Reserve is 42.0 % and new target is 45 %
2023-07-18 00:15:03.968007 INFO pred_bat: predict base end_record 07-18 23:30:00 final soc 5.43 kwh metric 167.34 p min_soc 3.73 @ 07-18 08:00:00 kwh load 32.63 pv 12.52
2023-07-18 00:15:03.970946 INFO pred_bat: [ 00:15, 01:15, 02:15, 03:15, 04:15, 05:15, 06:15, 07:15, 08:15, 09:15, 10:15, 11:15, 12:15, 13:15, 14:15, 15:15, 16:15, 17:15, 18:15, 19:15, 20:15, 21:15, 22:15, 23:15]
2023-07-18 00:15:03.973829 INFO pred_bat: SOC: [ 4.19, 4.28, 4.28, 4.28, 4.28, 4.28, 3.96, 3.81, 3.76, 3.87, 4.15, 4.69, 5.45, 6.38, 7.24, 7.83, 8.22, 8.37, 8.44, 8.22, 7.94, 7.22, 6.34, 5.58]
2023-07-18 00:15:03.976778 INFO pred_bat: STATE: [ g<bf+, g<be-, g<bf+, g<bf+, g<bf+, g<bf+, g~be-, g~be-, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be+, g~be-, g~be+, g~be+, g~be+, g~be-, g~be-, g~be-, g~be-, g~be-]
2023-07-18 00:15:03.979655 INFO pred_bat: LOAD: [ 0.0, 4.63, 8.95, 13.82, 18.29, 21.64, 22.14, 22.65, 23.28, 23.92, 24.61, 25.27, 25.93, 26.55, 27.16, 27.83, 28.45, 29.05, 29.47, 29.91, 30.23, 30.92, 31.76, 32.48]
2023-07-18 00:15:03.982436 INFO pred_bat: PV: [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.01, 0.13, 0.49, 1.08, 1.86, 2.84, 4.07, 5.53, 7.12, 8.64, 9.93, 10.96, 11.73, 12.22, 12.46, 12.51, 12.52, 12.52, 12.52]
2023-07-18 00:15:03.985245 INFO pred_bat: IMPORT: [ 0.0, 4.73, 9.07, 13.97, 18.47, 21.83, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91, 21.91]
2023-07-18 00:15:03.988120 INFO pred_bat: EXPORT: [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
2023-07-18 00:15:03.991012 INFO pred_bat: CAR: [ 0.0, 4.4, 9.3, 14.21, 19.12, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8, 22.8]
2023-07-18 00:15:03.993890 INFO pred_bat: METRIC: [ 3.0, 38.46, 71.04, 107.79, 141.51, 166.72, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34, 167.34]
2023-07-18 00:15:04.244884 INFO pred_bat: Battery has 48.0 hours left - now at 4.19
2023-07-18 00:15:38.917053 INFO pred_bat: Inverter 0 Current Reserve is 45.0 % and new target is 42 %
Here are my full logs starting at around 11pm to about 12:15am:
https://pastebin.com/dyBC0DFD
Here is my apps.yaml:
https://pastebin.com/X7ZcSmch
Cheers!
More than likely something I've done but I seem to have lost the helper card from my dashboard, is there an easy way to readd the whole card?
I think the data behind a few of my charts might not be correct. I know i'm an above average user for energy but surely these figures aren't correct?
Background - 16kWp in solar panels, 2 x AC Coupled Inverters and 2 x 9.5kWh batteries.
Log file -
a0d7b954_appdaemon_2023-09-21T16-00-18.004Z.log
Any help would be very much appreciated :)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.