v7.17.12 does not solve update problems

[PianSom]

Currently on 7.17.9, running under appdaemon in docker, feeding from a Core HA (previously without issues).

Updating to 7.17.12 causes a silent failure.

Appdeamon log reports only

2024-05-05 14:36:35.713315 INFO pred_bat: Requested install of latest version v7.17.12

Solved by restarting appdaemon

[gcoan]

7.17.10 wouldn't auto-update to 7.17.12 for me, gave the error 'Changed to ERROR: Exception raised PredBat.async_download_predbat_version() takes 2 positional arguments but 3 were given'

Manually upgraded to 7.17.12 via HACS, restarted appdaemon and its running OK now

[SwiftRR]

I am on v7.17.11 (still have automatic upgrade OFF). For completeness, I have attached my predbat.log from #1054 (for v7.17.11). predbat.log

I have also added my appdaemon-predbat log from HACS below. This still includes the async error (which I have emboldened) and is in my predbat.log.

I am happy to try v7.17.12 to see if this makes any difference.

2024-05-05 12:10:00.069604 WARNING pred_bat: Worker Ags: {'id': 'bfcb55c5ab2e4bc8895cd97651717e24', 'name': 'pred_bat', 'objectid': '24d6f8c738a247ecbdbf52a9270dcd8e', 'type': 'scheduler', 'function': <bound method PredBat.run_time_loop of <predbat.PredBat object at 0x7fabf1d710>>, 'pin_app': True, 'pin_thread': 0, 'kwargs': {'interval': 300, 'random_start': 0, 'random_end': 0, '__thread_id': 'thread-0'}} 2024-05-05 12:10:00.072497 WARNING pred_bat: ------------------------------------------------------------ 2024-05-05 12:10:00.076793 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 "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(*args, **kw) ^^^^^^^^^^^^^^ File "/config/apps/predbat.py", line 14253, in run_time_loop raise e File "/config/apps/predbat.py", line 14249, in run_time_loop self.update_pred(scheduled=True) File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(*args, **kw) ^^^^^^^^^^^^^^ File "/config/apps/predbat.py", line 13187, in update_pred self.download_predbat_releases() File "/config/apps/predbat.py", line 4699, in download_predbat_releases self.download_predbat_version(latest_version) File "/config/apps/predbat.py", line 13328, in download_predbat_version task = self.create_task(self.async_download_predbat_version(self, version)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: PredBat.async_download_predbat_version() takes 2 positional arguments but 3 were given

2024-05-05 12:10:00.078162 WARNING pred_bat: ------------------------------------------------------------ 2024-05-05 12:15:00.074112 WARNING pred_bat: ------------------------------------------------------------ 2024-05-05 12:15:00.075874 WARNING pred_bat: Unexpected error in worker for App pred_bat: 2024-05-05 12:15:00.076829 WARNING pred_bat: Worker Ags: {'id': 'bfcb55c5ab2e4bc8895cd97651717e24', 'name': 'pred_bat', 'objectid': '24d6f8c738a247ecbdbf52a9270dcd8e', 'type': 'scheduler', 'function': <bound method PredBat.run_time_loop of <predbat.PredBat object at 0x7fabf1d710>>, 'pin_app': True, 'pin_thread': 0, 'kwargs': {'interval': 300, 'random_start': 0, 'random_end': 0, '__thread_id': 'thread-0'}} 2024-05-05 12:15:00.077769 WARNING pred_bat: ------------------------------------------------------------ 2024-05-05 12:15:00.081621 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 "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(*args, **kw) ^^^^^^^^^^^^^^ File "/config/apps/predbat.py", line 14253, in run_time_loop raise e File "/config/apps/predbat.py", line 14249, in run_time_loop self.update_pred(scheduled=True) File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(*args, **kw) ^^^^^^^^^^^^^^ File "/config/apps/predbat.py", line 13187, in update_pred self.download_predbat_releases() File "/config/apps/predbat.py", line 4699, in download_predbat_releases self.download_predbat_version(latest_version) File "/config/apps/predbat.py", line 13328, in download_predbat_version task = self.create_task(self.async_download_predbat_version(self, version)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: PredBat.async_download_predbat_version() takes 2 positional arguments but 3 were given

2024-05-05 12:15:00.083261 WARNING pred_bat: ------------------------------------------------------------ Update complete s6-rc: info: service legacy-services: stopping s6-rc: info: service legacy-services successfully stopped s6-rc: info: service appdaemon: stopping [15:23:28] INFO: Service AppDaemon exited with code 0 (by signal 0) s6-rc: info: service appdaemon successfully stopped s6-rc: info: service init-appdaemon: stopping s6-rc: info: service init-appdaemon successfully stopped s6-rc: info: service legacy-cont-init: stopping s6-rc: info: service legacy-cont-init successfully stopped s6-rc: info: service fix-attrs: stopping s6-rc: info: service base-addon-log-level: stopping s6-rc: info: service fix-attrs successfully stopped s6-rc: info: service base-addon-log-level successfully stopped s6-rc: info: service base-addon-banner: stopping s6-rc: info: service base-addon-banner successfully stopped s6-rc: info: service s6rc-oneshot-runner: stopping s6-rc: info: service s6rc-oneshot-runner successfully stopped s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service base-addon-banner: starting

---

Add-on: appdaemon-predbat Predbat pre-install in AppDaemon

Add-on version: 1.0.10 You are running the latest version of this add-on. System: Home Assistant OS 11.5 (aarch64 / raspberrypi4-64) Home Assistant Core: 2024.3.3 Home Assistant Supervisor: 2024.04.4

Please, share the above information when looking for help or support in, e.g., GitHub, forums or the Discord chat.

s6-rc: info: service base-addon-banner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service base-addon-log-level: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service base-addon-log-level successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service init-appdaemon: starting s6-rc: info: service init-appdaemon successfully started s6-rc: info: service appdaemon: starting s6-rc: info: service appdaemon successfully started s6-rc: info: service legacy-services: starting [15:23:34] INFO: Starting AppDaemon... s6-rc: info: service legacy-services successfully started

[ivenhov]

I had the same problem on 7.17.10 with appdaemon-predbat 1.0.10. I turned off 'Predbat automatic update enable' in UI (Switches ) After that HA showed me new version of Predbat is available 7.17.12 which I took. Now 7.17.12 runs as normal and 'Predbat automatic update enable' is turned on.

[SwiftRR]

I am joining the testing of v7.17.12. Just installed and have I re-enabled automatic upgrading. Fingers-crossed.

Rob

[thevilla]

I have this issue with 7.17.9 however I'm unable to make any changes to Predbat hence I have been unable to apply the patch. Is there a tested method to get out of the update issue or is a reinstall necessary? Thanks.

[murkle]

Please can someone give me a quick hint how to force an update or roll-back? I have

2024-05-05 18:17:53.869641 INFO pred_bat: --------------- PredBat - update at 2024-05-05 18:15:00+01:00 with clock skew 0 minutes, minutes now 1095
2024-05-05 18:17:54.411706 INFO pred_bat: Predbat /config/apps/predbat.py version v7.17.10 currently running, latest version is v7.17.12 latest beta v7.17.12
2024-05-05 18:17:54.414917 INFO pred_bat: Autoupdate: There is an update pending v7.17.12 Fix crash with update service - auto update triggered!
2024-05-05 18:17:54.416926 INFO pred_bat: ERROR: Exception raised PredBat.async_download_predbat_version() takes 2 positional arguments but 3 were given

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 "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock
  return f(*args, **kw)
         ^^^^^^^^^^^^^^
File "/config/apps/predbat.py", line 14231, in update_time_loop
  raise e
File "/config/apps/predbat.py", line 14226, in update_time_loop
  self.update_pred(scheduled=False)
File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock
  return f(*args, **kw)
         ^^^^^^^^^^^^^^
File "/config/apps/predbat.py", line 13187, in update_pred
  self.download_predbat_releases()
File "/config/apps/predbat.py", line 4699, in download_predbat_releases
  self.download_predbat_version(latest_version)
File "/config/apps/predbat.py", line 13328, in download_predbat_version
  task = self.create_task(self.async_download_predbat_version(self, version))
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: PredBat.async_download_predbat_version() takes 2 positional arguments but 3 were given

2024-05-05 16:01:17.441649 WARNING pred_bat: ------------------------------------------------------------

and nothing seems to be running. I installed https://github.com/springfall2008/appdaemon-predbat a few days ago and it's been fine until today

[murkle]

I've manually edited this line, looks promising:

Original (non-working) task = self.create_task(self.async_download_predbat_version(self, version))

[RobinCu]

I have this issue with 7.17.9 however I'm unable to make any changes to Predbat hence I have been unable to apply the patch. Is there a tested method to get out of the update issue or is a reinstall necessary? Thanks.

If you're stuck on 7.17.9 try the following: Restart AppDaemon, Toggle on Auto Update, wait for the update to 7.17.12 toggle off Auto Update

[thevilla]

I have switch.predbat_auto_update_ enable which is off and will not enable. I also see auto update in the appdaemon-predbat config page which I can toggle. I can see 7.17.12 as an option but it will not install.

On Sun, 5 May 2024, 18:38 RobinC, @.***> wrote:

I have this issue with 7.17.9 however I'm unable to make any changes to Predbat hence I have been unable to apply the patch. Is there a tested method to get out of the update issue or is a reinstall necessary? Thanks.

If you're stuck on 7.17.9 try the following: Restart AppDaemon, Toggle on Auto Update, wait for the update to 7.17.12 toggle off Auto Update

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1057#issuecomment-2094889280, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ3HYNZMK4LZPCAEA7FKMBLZAZVBRAVCNFSM6AAAAABHHXS5K6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUHA4DSMRYGA . You are receiving this because you commented.Message ID: @.***>

[gcoan]

I have switch.predbat_auto_update_ enable which is off and will not enable.

I also see auto update in the appdaemon-predbat config page which I can

toggle. I can see 7.17.12 as an option but it will not install.

What version are you on? There's a bug in .9 and.10 that the auto update doesn't work and crashes predbat.

You can either edit the predbat.py file as @murkle did to correct the auto update error and then predbat should update itself to.12

If you can't turn the auto update on then try restarting AppDaemon-predbat add on.

Alternatively if you don't want to edit the predbat code then uninstall AppDaemon-predbat, restart home assistant, install it again and turn on auto update and it shout update to .12 ok

[thevilla]

Thanks, I'll give the update a go. Just about to board a ferry so I'll be unable to try til tomorrow. Thanks for the suggestion.

On Sun, 5 May 2024, 18:54 Geoffrey Coan, @.***> wrote:

I have switch.predbat_auto_update_ enable which is off and will not enable.

I also see auto update in the appdaemon-predbat config page which I can

toggle. I can see 7.17.12 as an option but it will not install.

What version are you on? There's a bug in .9 and.10 that the auto update doesn't work and crashes predbat.

You can either edit the predbat.py file as @murkle https://github.com/murkle did to correct the auto update error and then predbat should update itself to.12

If you can't turn the auto update on then try restarting AppDaemon-predbat add on.

Alternatively if you don't want to edit the predbat code then uninstall AppDaemon-predbat, restart home assistant, install it again and turn on auto update and it shout update to .12 ok

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1057#issuecomment-2094893425, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ3HYN3UJ7YO3MBDSMGUXX3ZAZW6FAVCNFSM6AAAAABHHXS5K6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUHA4TGNBSGU . You are receiving this because you commented.Message ID: @.***>

[PianSom]

I followed the instructions here, and got on to 7.17.12

I have just seen an update to 7.18.0 is available, have attempted an update but my appdeamon log is filling up with -

2024-05-06 20:55:14.825286 CRITICAL AppDaemon: Thread will be restarted
2024-05-06 20:55:14.826233 INFO AppDaemon: Adding thread 8
2024-05-06 20:55:15.843168 CRITICAL AppDaemon: Thread thread-8 has died
2024-05-06 20:55:15.844251 CRITICAL AppDaemon: Pinned apps were: ['pred_bat']
2024-05-06 20:55:15.845200 CRITICAL AppDaemon: Thread will be restarted
2024-05-06 20:55:15.846249 INFO AppDaemon: Adding thread 8
2024-05-06 20:55:16.862296 CRITICAL AppDaemon: Thread thread-8 has died
2024-05-06 20:55:16.863520 CRITICAL AppDaemon: Pinned apps were: ['pred_bat']
2024-05-06 20:55:16.864483 CRITICAL AppDaemon: Thread will be restarted
2024-05-06 20:55:16.865390 INFO AppDaemon: Adding thread 8
2024-05-06 20:55:17.882237 CRITICAL AppDaemon: Thread thread-8 has died
2024-05-06 20:55:17.883339 CRITICAL AppDaemon: Pinned apps were: ['pred_bat']
2024-05-06 20:55:17.884234 CRITICAL AppDaemon: Thread will be restarted

A restart of the appdaemon container solved the problem

[gcoan]

have just seen an update to 7.18.0 is available, have attempted an update but my appdeamon log is filling up with -

I had exactly the same issue, predbat auto updated itself to 7.18.0 and then got stuck with the pinned threads dying issue.

Sat like that for over 2 hours before I saw this github update, went to look at my own predbat and found it similarly stuck.

Tried to downgrade and it wouldn't downgrade either.

Restarted appdaemon, downgraded and then manually upgraded to 7.18.0 and its all running OK now.

@springfall2008 despite Predbat dying with these appdaemon errors the predbat.status Error attribute never got set nor did predbat.status get changed from 'Idle' so my predbat auto-detect failure didn't identify that there was an issue.....

[screig]

I can't update to 7.18, is this relevant:

2024-05-06 21:57:17.932 ERROR (MainThread) [homeassistant.components.hassio.handler] Client error on /addons/46f69597_appdaemon-predbat/changelog request 0, message='Attempt to decode JSON with unexpected mimetype: application/octet-stream', url=URL('http://172.30.32.2/addons/46f69597_appdaemon-predbat/changelog')
2024-05-06 21:57:17.932 WARNING (MainThread) [homeassistant.components.hassio.data] Could not fetch changelog for 46f69597_appdaemon-predbat: 

[gcoan]

I don't think that is relevant, I think its a bug in Home Assistant 2024.4 that's causing these JSON parse errors. I get the same (I think) on other add-on's.

If you are getting the same thread error on 7.18, it shows up in the appdaemon.log file - restarting appdaemon seems to sort it out

[SwiftRR]

I have been gong round in circles with this issue for a couple of hours. This reply links to previous 2 replies. Disparity between status report (which looks stuck) and actual process in HTML plan. Automatic update changed my predbat to v7.18.0. I had no errors in appdaemon log but my status report seems to be stuck on IDLE. This is despite the predbat plan showing discharge (which GE app is also showing).

I have tried restarting appdaemon add-on. The log shows that appdaemon had been stopped and had started, with no errors. Status still stuck on IDLE.

I turned automatic update OFF (so back to 7.17.12 for me) and have restarted HA. No difference. Plan still showing discharge and status shows idle. Predbat log also showing idle.

Problem selecting a Force discharge slot I set force discharge at 21:30 and this has finally kicked the recording status to 'discharge'. I will see what happens at 22:00 HOWEVER, in the Selector switches, all the slots for this evening were missing (first available slot was 00:00). I then went to Devices and Services/Entities and all the slots were there. So I could then force discharge the slot 21:30. So this looks like a bug, I am afraid.

Manually upgrading from 7.16.12 to 7.18.0 At the next slot: 22:00, the status and plan both matched as 'discharge'. I then tried manually upgrading to 7.18.0 and the status again changed to idle, despite plan discharging. I have then downgraded again to 7.16.12 but I had to restart appdaemon add on as this had crashed this time. I also restarted givtcp add on I force discharged 22:00 and the plan and status now agree with 'discharging'. I then turned the force discharge OFF and plan and status now agree.

I am now leaving predbat on 7.16.12 with automatic update OFF.

Current predbat log attached. predbat.log

The status and plan have just both changed to freeze charging again so at least they are both in sync.

Hope this helps you to identify what is happening.

Rob

[gcoan]

Hi Rob, oh gosh you are having problems.

I've had a Quick Look at the logfile and can't see anything immediately obvious or wrong, predbat seems to be running fine on 7.17.12. I'm on 7.18.0 and its running fine for me, and I just checked the predbat.manual* selectors on my predbat dashboard and they all are populated as I would expect them to be.

Sometimes the Home Assistant UI can get confused, I get pages that never load and very occasionally weird stuff but nothing like what you have described. Usually refreshing the browser window sorts it out. Did you try that when the selectors were partially filled?

When you said the inverters were discharging but predbat was stuck on idle, have you got any screen shots of the plan and inverter state, and do you know what time this was happening to cross-check to the logfile? I personally use the GivTCP battery card, a power flow card and the key givtcp entities all on a page so I can see (and change) what my inverters are actually doing - do you have something similar:

[SwiftRR]

Geoffrey, I have status and plan now nicely synced on 7.17.12 and I hope they will stay synced throughout the night. I know that the status can change within a slot but mine seemed to be firmly stuck on idle.

I will try to set up a dashboard page like yours for future reference.

This is my overnight plan. I have had enough of predbat for the day .........

[RobinCu]

Rob, I'm not sure this issue with the Predbat Plan card: https://github.com/pacemaker82/PredBat-Table-Card/issues/25 is causing all your issues but could be cause future troubleshooting to be challenging.
It may be worth cross-referencing Trefor's original HTML plan if you see any split 30-minute slots.

[SwiftRR]

I have updated manually to v7.18.1. Predbat did crash when I attempted to update and I had to restart the appdaemon add-on to recover predbat. It then took some time to install but did get there. I don't have any or the carbon stuff switched on.

Here's predbat.log predbat.log

..... and various relevant graphics

I am feeling like I have lost the plot and I don't really know what is going on ...... Perhaps I had better follow my own earlier advice and hand things over to predbat. From the battery image, charging is taking place but very slowly so perhaps this equates to 'idle'.

Rob

[gcoan]

From the battery image, charging is taking place but very slowly so perhaps this equates to 'idle'.

The battery image matches what I would expect to be happening from the predbat plan. Your solar generation is above your house load and since the battery isn't full, its slowly filling the battery up.

Another way at looking at what's happening is to use the custom bar chart card in HA. I have it setup with power meters showing what my home is doing. The top bit is just different inverter sensors, the bottom is smart plugs and Shelly CT clamps:

type: custom:bar-card
entities:
  - entity: sensor. givtcp_xxx_import_power
    name: Import Power
  - entity: sensor. givtcp_xxx_export_power
    name: Export Power
  - entity: sensor. givtcp_xxx_pv_power
    name: Solar GE Inverter 1
  - entity: sensor. givtcp2_xxx_pv_power
    name: Solar GE Inverter 2
  - entity: sensor.fit_solar_power
    name: Solar FIT
  - entity: sensor.givtcp_xxx_charge_power
    name: G Charge Power
  - entity: sensor.givtcp2_xxx_charge_power
    name: H Charge Power
  - entity: sensor.givtcp_xxx_discharge_power
    name: G Discharge Power
  - entity: sensor.givtcp2_xxxx_discharge_power
    name: H Discharge Power
  - entity: sensor.ashp_power
  - entity: sensor.house_power
  - entity: sensor.extension_power
  - entity: sensor.cooker_power
  - entity: sensor.kettle_energy_power
  - entity: sensor.dishwasher_energy_power
  - entity: sensor.washing_machine_energy_power
  - entity: sensor.tumble_dryer_energy_power
  - entity: sensor.fridge_power
  - entity: sensor.tasmota_tv_energy_power
  - entity: sensor.internet_ha_current_power
  - entity: sensor.horse_shed_heater_energy_power
  - entity: sensor.workshop_heater_energy_power
max: 5
decimal: 1

Here's my power flow card:

              - type: custom:power-flow-card-plus
                entities:
                  battery:
                    entity: sensor.givtcp_xxx_battery_power
                    state_of_charge: sensor.givtcp_xxx_soc
                    display_state: one_way
                  grid:
                    entity: sensor.givtcp_xxxx_grid_power
                    invert_state: true
                    use_metadata: false
                  solar:
                    entity: sensor.givtcp_xxx_pv_power
                    display_zero_state: true
                  home:
                    subtract_individual: true
                  individual:
                    - entity: sensor.extension_power
                      name: Extension
                      icon: mdi:home-outline
                      color: red
                      display_zero_tolerance: 50
                    - entity: sensor.ashp_power
                      name: ASHP
                      icon: mdi:heat-pump-outline
                      color: '#9007DD'
                      display_zero_tolerance: 50
                clickable_entities: true
                display_zero_lines:
                  mode: show
                  transparency: 50
                  grey_color:
                    - 189
                    - 189
                    - 189
                use_new_flow_rate_model: true
                w_decimals: 0
                kw_decimals: 1
                min_flow_rate: 0.75
                max_flow_rate: 10
                max_expected_power: 2600
                min_expected_power: 0.01
                watt_threshold: 1000
                transparency_zero_lines: 0
                title: G395 PowerFlow+

[SwiftRR]

Geoffrey, Thanks for sharing the power code for your cards which I have used. My status report continues to show 'idle' despite 'discharging' being shown in the HTML plan and in the cards. All at about 19:00 on 07-05-2024.

I find the inconsistency unnerving with predbat displaying the status differently in different places. See screenshots below and predbat.log (The last line shows Idle being reset.)

Despite this, my plan seems to be working just fine.

predbat.log

Rob

[RobinCu]

Rob, don't be fooled by the Giv battery card "Battery: DISCHARGING". It's not linked to the inverter or Predbat status. It's derived from the live energy flow at the time. Many people have been confused by it (it probably needs a health warning but it's not part of the Predbat ecosystem).

So if I'm reading your screenshots correctly the plan shows you're in Idle, the down arrows in the plan state column isn't force discharging, it's just the forecasted SOC direction (based on load & PV).

[SwiftRR]

RobinCu, I have been combing through the documentation again and I have just noticed that predbat uses 'state' in the HTLM plan but 'status' in the predbat report. ..... and 'Status' when battery SOC is decreasing is 'Idle' unless the discharge is being forced.

Your reply is very timely. The confusion is reinforced by the alternative plan, which uses the 'friendly' term of 'discharging': So the same slot is shown with a 'state' of '↘︎' in Trefor's HTML plan and 'Discharging' in the 'Friendly plan'. ...... and they both mean that the status is 'Idle'.

I will crawl back into my hole now and I won't get worried about the 'inconsistency' again. Predbat can be a steep learning curve.

Thanks again.

Rob

[gcoan]

Robin is quite correct Rob, there isn't an issue here.

Your battery can be in one of three states: charging, discharging or idle. Corresponding to what is happening to the battery charge level - going up, going down or staying constant.

The givtcp battery card you are using shows LIVE what is happening to the battery. The power flow card I shared the yaml configuration for (or the bar charts) all show the same, what's happening to the battery now.

The predbat plan shows what predbat plans will happen to the battery in a 30 minute period. There's quite a few more different status's in predbat, and details of each are described https://springfall2008.github.io/batpred/what-does-predbat-do/#predbat-status in the documentation.

Just dwelling on Idle as that's been the one that has caused confusion, the battery is not being instructed to force charge or force discharge, but the battery will respond to what house load and solar generation there is. With solar generation greater than house load the battery will charge and the battery Soc level increase, and obviously if there is less solar than house load the battery level will decrease. Predbat shows on the plan what it PREDICTS will happen over the 30 minute period, but its only a prediction and actual solar and actual house load can vary this. So in the plan above, there's no solar at 9pm so the house load will cause the battery level to reduce (hence the downward arrow) and the battery card/power meter will show the battery is discharging.

But tomorrow when its sunny, your solar will start charging the battery and the predbat plan will show an upwards arrow. But if say you turn a kettle on, this will probably be taking more power than the solar panels can deliver so your battery will start discharging to meet the load. All perfectly normal behaviour.

I think the predbat table card shows status's of Charging, Discharging and Maintaining SOC to show the upwards, downwards and rightwards arrows that Trefor uses to show battery direction WHEN in Idle mode. Remember that these are planned activity over a 30 minute period and actual activity will depend on house load and solar generation.

In Trefor's plan when the battery is force charging (filling the battery from grid) or force discharging (emptying the battery and exporting to grid) these are shown as Charging and Discharging and in the table card they are shown as Planned Charging and Planned Discharging.

[SwiftRR]

Thanks Geoffrey and Robin,

Tonight has been a big epiphany moment for me in this respect.

I began my Predbat journey in late January. With the large swings in rates up until recently, charging and discharging have been easy to follow. With little variation now, hovering around 15p, there is little need for big changes. So my plans have correctly been largely 'Idle'.

As I have learnt what predbat does, I have questioned why predictions have been made. I should know better – in most cases 'Predbat knows best'. I now understand what is going on here and I am 😊.

Rob

[pacemaker82]

I think the predbat table card shows status's of Charging, Discharging and Maintaining SOC to show the upwards, downwards and rightwards arrows that Trefor uses to show battery direction WHEN in Idle mode. Remember that these are planned activity over a 30 minute period and actual activity will depend on house load and solar generation.

In Trefor's plan when the battery is force charging (filling the battery from grid) or force discharging (emptying the battery and exporting to grid) these are shown as Charging and Discharging and in the table card they are shown as Planned Charging and Planned Discharging.

Correct - the table card will show "Planned xxx" or "Maintaining SOC" when Predbat is doing something. Otherwise the description is based on idle arrows (charge up, down discharge, or idle). This is also clear because the background colours of the table card illustrate predbat is doing something, vs just idle behaviour has no background colour on the cell. This is the same as Trefor's HTML card.

[pacemaker82]

I have updated the readme with a new friendly states section which outlines what my card is doing: https://github.com/pacemaker82/PredBat-Table-Card