SwiftRR commented 5 months ago

Describe the bug An unexpected calibration event.

Expected behavior No calibration! I am on the Octopus Agile import tariff and Octopus fixed 15p outgoing tariff. Predbat is very active. See screenshots below showing the status report, GE battery power profile on 14-03-2024 and a GE notification for low BMS voltage (See attachment) but no calibration report from GE at all! So would the calibration have been initiated by GE or by Predbat? I have not contacted GE yet but can do. The low voltage notification was from the middle of the calibration time and would not have initiated it.

I had set the predbat entities as suggested in the configuration.md. input_number.predbat_best_soc_keep was set at 0.5 and I have increased this to 0.7 to represent 4% of my total 16.4 kWh battery storage. SOC min is set to 0 and reserve to 4%. If needed, I can supply more information of my predbat setup. I was too late to pick up the start.

Predbat version v7.16.7 xxxx

Environment details

Inverter and battery setup: Givenergy AC 3.0 coupled inverter daily chaining to two 8.2 kWh batteries
Standard HAOS installer or Docker: Raspberry Pi 4.0 operating HA connected to a 500 Gb SSD drive (Samsung T7) I access Predbat on various Mac devices, iMac, iPhone and iPad.

Screenshots If applicable, add screenshots to help explain your problem. The most useful ones can be your battery chart, the Predbat HTML plan and your current settings in HA.

Log file This predbat log picks up the period during which calibration completed at 18:26:30. predbat.log.3.txt I was too late to pick up the start of this event.

gcoan commented 5 months ago

Predbat can't initiate a battery calibration, there's no published API

What you saw was predbat spotting that your battery was calibrating and so it suspends operation until the calibration has finished.

It's likely that it was the low voltage error you saw that caused the battery to decide to calibrate itself but normally if the battery gets too low it just does an automatic grid charge. Something to ask givenergy, sorry

SwiftRR commented 5 months ago

Thanks. I will check out GE early next week. What is bizarre is that Predbat changed its status to Calibration at 08:07:10 am I was notified about a low BMS voltage was 11:29:53 am. At 08:07:10 am, the BMS voltage was steady and well within range. So what caused Predbat to change its Status to Calibration at 08:07:10 am? See relevant screenshots below.

Battery data at start of Predbat calibration

Thanks

Rob

gcoan commented 5 months ago

Predbat sets its status to Calibration when it detects that the inverter is calibrating the battery, which must have happened at around 8:07 or shortly beforehand.

The calibration does a full discharge then a full charge, so my mistake, the BMS under voltage is when the battery is fully discharged from the calibration, so its a consequence of the calibration, not the cause.

Interesting looking in my own notifications, I have two inverters that both had to be calibrated after a new battery was installed. On one inverter there were no notifications durng the calibration, on the other there was both a BMS under voltage and a BMS over voltage during the calibration - presumably as the inverter finds out what the battery low and high limits are.

No clue as to why the inverter decided to do the calibration though

springfall2008 commented 5 months ago

I've heard on the forums that because of the lack of error checking on modbus it's possible that a register write when corrupted can trigger a calibration.

SwiftRR commented 5 months ago

Interesting – so it isn't just me!

Unfortunately my predbat log for the start of the calibration (08:10 on 14-03-2024) is no longer on HA (unless there is a way for me to retrieve it). I have experienced this calibration behaviour twice now, on 12-02-2024 and 14-03-2024. I started using predbat on 30-01-2024. Any data for 12-02-2024 has long since been swallowed up by HA.

So would the corruption have come from predbat or from a deficiency in the GE modbus? Is there anything that can be done from the predbat end to prevent any future unexpected calibrations? I am going to quiz GE about this. The inverter firmware is ancient, nearly 2 years old, with no opportunity for me to update it, although GE KB indicates that there have been several updates. Apparently GE are supposed to be drip feeding these through to AC3.0 coupled users.

With 2 batteries, I do find that their SOCs drift out of sync, with the secondary battery always being a little behind. There is supposed to an OCV that gets them back together when the batteries get to their SOC extremes but this takes about 30 min. Could predbat be preventing this (or could it allow 30 min if it finds that the batteries have drifted apart)? This is readable in givtcp.

I also have some errors listed in my other recent predbat issue #857 Random errors and warnings. Could these be related?

Thanks

Rob

gcoan commented 5 months ago

Its worth you updating your appdaemon.yaml to save more (and longer) log files so they don't get overwritten so quickly

eg

# write log records to a file, retaining 9 versions, rather than the standard appdaemon log
logs:
  main_log:
    filename: /homeassistant/appdaemon/appdaemon.log
    log_generations: 9
    log_size: 10000000

see https://springfall2008.github.io/batpred/install/#appdaemon-install

SwiftRR commented 5 months ago

Thanks. Done

Rob

SwiftRR commented 5 months ago

Is it worth updating the appdaemon.yaml file in the templates folder so that it matches the example config in the documentation, which doesn't have the log_generations line?

Rob

SwiftRR commented 5 months ago

I have done this but I have now lost predbat completely. The plan states 'null' and all the charts have disappeared with error messages. I have restarted my inverted again!

The status report is:

My predbat log is: predbat-4.log

My original appdaemon.yaml is: appdaemon.yaml.txt This was the only file that I changed.

I have changed predbat to 'read only' for the time being and let my inverter take control again until this is fixed.

I have copied back my original appdaemon.yaml file which got installed when I set up predbat. I set up the joint appdaemon/predbat installation. appdaemon.yaml.txt

So please help! I need my predbat back!

Rob

gcoan commented 5 months ago

Have you tried restarting appdaemon after changing the appdaemon.yaml?

gcoan commented 5 months ago

Looking at your appdaemon.yaml, it looks fine, I don't think that's the cause of your issue.

In the logfile it looks like predbat is running fine and then about 11:40 it gets a REST error talking to the inverter and then it just falls in a heap repeatedly.

Predbat has two ways to talk to GivTCP, either by REST which is more efficient or by manipulating the GivTCP Home Assistant entities. Both can be setup in apps.yaml and if the REST call fails Predbat will fallback to using the non-rest approach. Do you have the non-rest GivTCP controls configured for your inverter?

I notice there is a warning message about givtcp2 not being evaluated, I assume you don't have two inverters. The GivTCP2 line should be commented out and all lines referring to it in apps.yaml.

Suggest to get predbat back you shutdown and restart GivTCP which should hopefully restore the REST connection to it. Then lets look at your apps.yaml config

SwiftRR commented 5 months ago

I'm back up so immediate panic over. I had tried restarting everything after any changes.

I have just come off from a 1 hour phone call to GE. It seemed that my inverter had dropped off line. I couldn't access it from apps or the GE portal. Their first fix was to reboot my router. I had no faith in this but it worked! I could then access the inverter again through GE apps and portal and predbat leapt back to life.

I also broached the unexpected calibration and they had no idea why these had happened. I see that you have another sufferer of this 'feature'. Could it be initiated by a sequence of Predbat requests? I only discovered this myself as I was checking my system before a saving session, only to find that I was importing! Then I found the earlier event on 12th Feb.

I have checked my apps.yaml file and found a line:

http://192.168.1.239:6345
http://192.168.1.239:6346
This matched what Trefor had in his video. But I do have num_inverters: 1 I think there are lines to initiate controls for not using REST. I have commented out lines that look like for a 2nd inverter. I have attached my apps.yaml file so that you can see if there are any other rogue entries. apps.yaml.txt

My appdaemon.yaml looks like the set up for the old separate appdaemon/predbat installation. I think the file paths need changing to match my configuration. If I do this, would I change the paths for app_dir and filename: app_dir: /addon_configs/46f69597_appdaemon-predbat/apps filename: /addon_configs/46f69597_appdaemon-predbat/predbat.log

But I am wary about changing these as it coincided with my inverter going off line!

Since predbat coming back, I am still getting some random errors. See iPhone screenshot below

Now to watch Trefor's installation video for the nth time ...

Rob

gcoan commented 5 months ago

The inverter going offline would be the cause of the REST errors you saw in the predbat log. You should also see errors in the GivTCP log. There's a GivTCP error detector (and a predbat one) I wrote in the Output data part of the docs that will alert you if GivTCP stops working.

Looking at your apps.yaml, there are several entries that are not valid YAML and will cause you problems.

A sub-entity has to be indented by two spaces under the YAML heading so:

  reserve:
    - number.givtcp_{geserial}_battery_power_reserve
#    - number.givtcp2_{geserial2}_battery_power_reserve

is valid YAML but

  inverter_mode:
   - select.givtcp_{geserial}_mode

is not

Here's the entries I spotted as being invalid:

  givtcp_rest:
   - http://192.168.1.239:6345

  inverter_mode:
   - select.givtcp_{geserial}_mode
#   - select.givtcp2_{geserial2}_mode
  inverter_time:
   - sensor.givtcp_{geserial}_invertor_time
#   - sensor.givtcp2_{geserial2}_invertor_time
  charge_start_time:
   - select.givtcp_{geserial}_charge_start_time_slot_1
#   - select.givtcp2_{geserial2}_charge_start_time_slot_1
  charge_end_time:
   - select.givtcp_{geserial}_charge_end_time_slot_1
#   - select.givtcp2_{geserial2}_charge_end_time_slot_1
  charge_limit:
   - number.givtcp_{geserial}_target_soc
#   - number.givtcp2_{geserial2}_target_soc
  scheduled_charge_enable:
   - switch.givtcp_{geserial}_enable_charge_schedule
#   - switch.givtcp2_{geserial2}_enable_charge_schedule
  scheduled_discharge_enable:
   - switch.givtcp_{geserial}_enable_discharge_schedule
#   - switch.givtcp2_{geserial2}_enable_discharge_schedule
  discharge_start_time:
   - select.givtcp_{geserial}_discharge_start_time_slot_1
#   - select.givtcp2_{geserial2}_discharge_start_time_slot_1
  discharge_end_time:
   - select.givtcp_{geserial}_discharge_end_time_slot_1
#   - select.givtcp2_{geserial2}_discharge_end_time_slot_1

  # Inverter max AC limit (one per inverter). E.g for a 3.6kw inverter set to 3600
  # If you have a second inverter for PV only please add the two values together
  inverter_limit:
   - 8000

there's a rogue - 3680 that should be commented out or export_limit put in (if you have one):

 # Export limit is a software limit set on your inverter that prevents exporting above a given level
  # When enabled Predbat will model this limit
  #export_limit:
   - 3680
  # - 3000

The sanity check errors in predbat status point to something like a duplicate apps.yaml or predbat.py file, but would need to see the logfile to have a better idea. It might be these apps.yaml issues as well.

Finally the question about pathnames. The logfile doesn't really matter, as long as it points to somewhere you can find the logfile it can be whatever you want. The app_dir should be where appdaemon can find the apps to run. Maybe this is the cause of the sanity check errors if its finding a duplicate file?

SwiftRR commented 5 months ago

Thanks. yaml spacing is so frustrating. It was significant that my 'REST line had a missing space. I have mended all the lines.

Would you uncomment the autostart lines:

When enabled automatic restart will restart the add-on if communication fails

Example below is auto-restart for GivTCP add-on itself

auto_restart:

- shell: 'rm -rf /homeassistant/GivTCP/*.pkl'

- service: hassio/addon_restart

addon: a6a2857d_givtcp

I have changed the appdaemon.yaml file paths back to my original. Predat log objected to my full paths.

I will see how it all goes.

I am so grateful for your help. I am learning so much but I am in a different lower division to your skills. Hopefully somewhere in my comments I will help predbat along its improvement journey.

Rob

gcoan commented 5 months ago

Yes YAML is easy to get wrong as is writing template code in Jinja2, I find that difficult as well.

Anyway, glad you have found and fixed the yaml issues.

The auto-restart is new functionality in predbat to automatically restart GivTCP if it finds an error. I personally haven't added this as I'd prefer to know of the error myself and look at the issue (I use the GivTCP and predbat error monitors to alert me). But that's my personal preference, plenty of people are using it.

Your pathnames look OK for the combined install. I have the combined install on my HA, I did some tests of it when Trefor first released it, but I went back to using the original separate Appdaemon + HACS Predbat as that was what I started with and it was working fine as it was. And I have other things loaded from HACS so having Predbat loaded that way was no big deal for me. But if its working now, then great

SwiftRR commented 5 months ago

All seems set up now. I did temporarily turn on Read Only which seems to have changed some of my settings. I have got back expert mode and the debug options that got turned off. I have been changing back some settings but no bad thing to review everything.

I will see how predbat behaves overnight and we may then be able to close this issue (till next time!) To think that my REST problems may have stemmed from a missing yaml space.

I don't know how long predbat has been operating, nor how many of us are using it. To me, it is truly brilliant, with you providing what is probably the best support in HA. To get wider adoption, installation needs to be smoother. I know that Trefor has talked about an integration. But HA itself is far from easy to set up for the average person, and that is before we start on yaml.......

Rob

gcoan commented 5 months ago

I've added a brief section to the apps.yaml documentation to explain the importance of correctly formatting the apps.yaml file, link to an intro video on youtube and give a brief explanation of how the file should be formatted. Also updated the template appdaemon.yaml file to include log_generations.

Thanks. These will get incorporated in my next documentation release

SwiftRR commented 5 months ago

It is worth checking the apps.yaml file that gets installed during the original installation of appdaemon/predbat combined. I have just viewed Trefor's installation video again and there appears to be missing spaces in the same places as in my apps.yaml file. I first installed predbat towards the end of January 2024 and switched off read only on 30th Jan. I think my initial installation was v7.16.0.

My current installation seems to be running well with no more errors. In predbat.log, I am just seeing one warning linked to run_time_loop which recurs 2 or 3 times an hour, e.g.

2024-03-18 20:53:08.113205 WARNING AppDaemon: Excessive time spent in callback 'run_time_loop() in pred_bat', Thread 'thread.thread-0' - now complete after 188.112003 seconds (limit=120.0)

I noticed that Trefor had the same error in the predbat.log shown in his video. I also see a difference between my inverter time and appdaemon time but no error flagged.

The givtcp log shows a repeated Assertion error:

'AssertionError'>, AssertionError('Unexpected response from remote end: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response'), <traceback object at 0x7f9a458c00>)

I also see the following but rarely:

2024-03-18 21:37:01,708 - Inv1 - read - [ERROR ] - Battery Object empty so skipping

But running smoothly (fingers crossed).

Rob

gcoan commented 5 months ago

There's not a lot that can be done about the timeout warnings, I get them as well.

I do plan to restructure apps.yaml to better align with the documentation as it's grown quite organically. That'd be a good time to get it repackaged in the combined install.

There were some indentation issues in apps.yaml that I corrected 2 weeks ago #820 - your download would have predated this

SwiftRR commented 5 months ago

My predbat has been running smoothly since my problems yesterday. Status reports show no errors and the predbat.log looks fine to my eyes. There are no errors or warnings.

I have attached my latest predbat.log and I would appreciate a 2nd opinion.

predbat.log.txt

The only adverse line that I see is a discrepancies between inverter and appdaemon time after REST gets called: e.g.

2024-03-19 15:21:30.227440 INFO pred_bat: Inverter 0 using Rest API http://192.168.1.239:6345 2024-03-19 15:21:31.578457 INFO pred_bat: Invertor time 2024-03-19 15:20:57+00:00 AppDaemon time 2024-03-19 15:21:31.572216+00:00 difference -0.58 minutes

It could be that predbat has been running inconsistenty for me ever since I initially installed it. The missing spaces in the apps.yaml file could have influenced this. Certainly I now have no repeated REST called to the inverter or fails. I wonder whether all this could have contributed to the calibrations that I have experienced. And the sun has returned for me the last few days and my daily energy costs are currently leaving me in profit (and that includes running my heat pump).

If you are happy with the predbat.log, this issue can be closed (until next issue that I find ......)

Thanks so much for your help.

Rob

gcoan commented 5 months ago

Looking through the logfile, a few thoughts/observations:

your losses are 4, 3, 3 which is a bit on the low side. 5, 5, 5 or some other similar balance is probably a bit more accurate
metric_battery_cycle is set to 0.5p. Read the documentation and make sure you understand what this means - in effect each charge/discharge cycle is valued at 1p and so your battery won't discharge unless its at least 1p beneficial. Entirely personal choice on how you set this, lower values (and zero) will mean more use of your battery, higher values less use
I noticed in your apps.yaml that you had a battery charge curve set. Did you get that from predbat's own calculation (in the logfile) or did you uncomment the one in the template. If its the one predbat calculates then that's fine, otherwise it might not be correct for your battery/inverter.
you are loading previous days history from 7 days ago, is that correct? Depends on your home usage pattern but you might want to increase days_previous to include some extra days so that a spike one day doesn't skew the load prediction the following week. I have mine set to 2, 3, 4, 5, 6, 7, 8 for example to average the entire week
if you are not using the large and small triggers for automations you can comment them out in apps.yaml
the half minute clock difference is nothing to worry about, just that whatever you are running HA is set to a slightly different time than the inverters

Otherwise looks fine

SwiftRR commented 5 months ago

I have reviewed all the comments and think that I have addressed everything now.

your losses are 4, 3, 3 which is a bit on the low side. 5, 5, 5 or some other similar balance is probably a bit more accurate

Changed

metric_battery_cycle is set to 0.5p. Read the documentation and make sure you understand what this means - in effect each charge/discharge cycle is valued at 1p and so your battery won't discharge unless it's at least 1p beneficial. Entirely personal choice on how you set this, lower values (and zero) will mean more use of your battery, higher values less use

I have set at 0p. I remember reading the arguments here and my view is that I have purchased the batteries so I should use them!

I noticed in your apps.yaml that you had a battery charge curve set. Did you get that from predbat's own calculation (in the logfile) or did you uncomment the one in the template. If it's the one predbat calculates then that's fine, otherwise it might not be correct for your battery/inverter.

_I have read the documentation and have viewed Trefor's video here. I used the GE 9.5 kWh settings as I have GE 8.2 kWh batteries and I must have assumed that mine would be the same. But I can see that Predbat checks and I have found the result in predbat.log. I have a profile that was set over 9 days: Find charge curve has 9.0 days of data, max days 9 battery_charge_power_curve: 100 : 0.78 99 : 0.78 98 : 0.69 96 : 0.99 95 : 0.99 94 : 0.99 93 : 0.99 92 : 0.99 90 : 0.99 89 : 0.99 88 : 0.99 87 : 0.99 86 : 0.99 85 : 0.99

Is this suitable to paste into apps.yaml or should I leave predbat to generate another?_

I have also found another entry in predbat.log that refers to: battery_charge_power_curve_discharge: 20 : 1.0 The documentation does refer to battery_discharge_power_curve instead and I found no entry in apps yaml. I don't really know what this is trying to do!

you are loading previous days history from 7 days ago, is that correct? Depends on your home usage pattern but you might want to increase days_previous to include some extra days so that a spike one day doesn't skew the load prediction the following week. I have mine set to 2, 3, 4, 5, 6, 7, 8 for example to average the entire week

Changed. I have found the documentation and I should have picked this up.

if you are not using the large and small triggers for automations you can comment them out in apps.yaml

I found an Export Triggers: entry and have commented this out.

the half minute clock difference is nothing to worry about, just that whatever you are running HA is set to a slightly different time than the inverters

At least this has nothing to be with me!

I have been going back through the early comments in the '1st day with predbat' thread and I can see that many were asking the same questions as I have been doing. So I am not alone and we are all learning. I also found some of your suggested settings which I have been able to incorporate if I had not already done so. Together we can make predbat even better.

If you think everything has now been covered, close the issue!

Rob

gcoan commented 5 months ago

Is this suitable to paste into apps.yaml or should I leave predbat to generate another?_

If you have a predbat generated curve based on a reasonable amount of history then it's good to be copied into your apps.yaml - just keep the indentations correct@

I have also found another entry in predbat.log that refers to: battery_charge_power_curve_discharge: 20 : 1.0 The documentation does refer to battery_discharge_power_curve instead and I found no entry in apps yaml. I don't really know what this is trying to do!

This is probably a typo of my making in the documentation. Copy what's in the logfile generated by predbat into apps.yaml.

Basically the charge and discharge curves are to enable predbat to more accurately model how your battery will charge and discharge at the outer soc limits.

I have been going back through the early comments in the '1st day with predbat' thread and I can see that many were asking the same questions as I have been doing.

Yes there's a lot in that thread, must be one of the largest threads on the givenergy forum.

Cheers

gcoan commented 5 months ago

Ha, well, would you believe, the documentation was actually correct but the discharge curve that Predbat is writing in the logfile, the name was wrong !

The discharge curve in apps.yaml should be named "battery_discharge_power_curve"

I've updated the documentation to better explain about the discharge curve and corrected the predbat code to write out the discharge curve name correctly. This'll go in the next release I push through for Trefor to incorporate

SwiftRR commented 5 months ago

Geoffrey,

Good that I am contributing to predbat now and I can now make some sense out of the predbat.log. The "battery_discharge_power_curve" line no longer features in latest predbat.log and the "battery_charge_power_curve" entries have also disappeared since I pasted the correct entries into my apps.yaml file.

My predbat.log currently shows no errors and no warnings. No adverse readings in my status report. Interesting that today, with Agile rates increasing a bit, that my battery is nearly fully charged. I presume that when Agile import is very close to my 15p fixed outgoing, it may be cheaper to just use Agile straight from the grid.

So I hope I am now sorted and back to tweaking settings underpinning by solid apps.yaml and appdaemon.yaml files.

Rob

gcoan commented 5 months ago

The "battery_discharge_power_curve" line no longer features in latest predbat.log and the "battery_charge_power_curve" entries have also disappeared since I pasted the correct entries into my apps.yaml file.

The charge and discharge curves are created in the logfile when:

you don't have them already set in apps.yaml and
predbat initialises itself, after restarting appdaemon or editing apps.yaml

So you won't see these output again.

My predbat.log currently shows no errors and no warnings. No adverse readings in my status report.

Great stuff. Glad you got there

Interesting that today, with Agile rates increasing a bit, that my battery is nearly fully charged. I presume that when Agile import is very close to my 15p fixed outgoing, it may be cheaper to just use Agile straight from the grid.

The agile rates are not great today. Must be because its a relatively grey and calm day. My own battery was fully charged overnight and is currently still full & exporting at 3.5kW, but the hold charge stops around 11:00 and starts releasing the battery. Planned to be exhausted just after the evening peak. ☹️

Bear in mind that 15p fixed outgoing is valued by Predbat at around 13.5p after losses and since my agile rates are > 15p all day, it's cheaper to use the battery charge early - as long as it lasts through the evening peak. Having said that the plan has just changed to hold charge at 100% through to 15:00 so the cost/benefit of grid importing now vs later must be marginal.

To answer your question though, if grid import is cheaper than export then Predbat will hold your battery for when the rates are higher. There's also some logic that values your battery SoC based on what you paid to charge it up so that figures in the calculation as well

SwiftRR commented 5 months ago

Predbat seems to reassess all the time and, once rates for next day appear, the plan 4-7 pm can change massively between discharging a lot and 'drip-discharge' from battery.

Rob

gcoan commented 5 months ago

Predbat seems to reassess all the time and, once rates for next day appear, the plan 4-7 pm can change massively between discharging a lot and 'drip-discharge' from battery.

Rob

Indeed, I think that's why mine just reassessed due to the forecast rates for tomorrow coming out.

I didn't realise you are on Agile. You may want to uncomment out the norddata lines in apps.yaml, Predbat gets market rate prices in the morning to give a more accurate view of what the agile prices will be the following day

SwiftRR commented 5 months ago

Thanks for the head up on Nordpool.

I have seen the lines and reference in the Energy Rates documentation but had not taken this further. I now have the Nordpool data which is really good.

I like Agile and predbat seems perfect for getting the most out of Agile and cutting out any the tedious manual interventions. My big decision will be whether to flip over to Flux for the summer. But the peak Flux rates are ~10p /unit lower than last summer when I did very well (£300 paid to me in June 2023) And there is now very little difference between the Flux daytime export rate and the 15 p (provided that this survives April rate).

Rob

springfall2008 / batpred

Unexpected Predbat 'calibration' status #856

When enabled automatic restart will restart the add-on if communication fails

Example below is auto-restart for GivTCP add-on itself

auto_restart:

- shell: 'rm -rf /homeassistant/GivTCP/*.pkl'

- service: hassio/addon_restart

addon: a6a2857d_givtcp