Simplification of Predbat options

[springfall2008]

As raised by many people including @fboundy the Predbat options are too complex and there are too many

I'm wondering rather than having configuration groups as suggested that instead doing a few things

1. Delete a bunch of options/hard-wire them (some may change for other inverters)
2. Add an expert mode which exposes some extra options

Please can @iainfogg @fboundy review and see what you think of the ideas, they can be tweaked:

https://github.com/springfall2008/batpred/commit/b6e2319d02be837de39775e900651f4e7cc9a748

Actually the code isn't removing the sensors in non-expert mode, I think i need to add the flag to the table to change load_config but I'll do that soon if we think it's a good way to go

[iainfogg]

I'll have a look later in the week @springfall2008

[gcoan]

How do we install this? I couldn’t see it as a beta release or main? Manually copy the GitHub release into HA?

On 18 Nov 2023, at 20:35, Trefor Southwell @.***> wrote:

 As raised by many people including @fboundy the Predbat options are too complex and there are too many

I'm wondering rather than having configuration groups as suggested that instead doing a few things

Delete a bunch of options/hard-wire them (some may change for other inverters) Add an expert mode which exposes some extra options Please can @iainfogg @fboundy review and see what you think of the ideas, they can be tweaked:

b6e2319

Actually the code isn't removing the sensors in non-expert mode, I think i need to add the flag to the table to change load_config but I'll do that soon if we think it's a good way to go

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[fboundy]

Depends how you have things set up. I’ve now got Git set up to use a samba share of my HA appdaemon folder so I can simply swap branches. If not you will need to copy from the GitHub branch.

Certainly happy to look at the code to test if it works for Agile/Outgoing Fixed - probably won’t be till later this week. On 19 Nov 2023 at 00:15 +0000, Geoffrey Coan @.***>, wrote:

How do we install this? I couldn’t see it as a beta release or main? Manually copy the GitHub release into HA?

On 18 Nov 2023, at 20:35, Trefor Southwell @.***> wrote:

As raised by many people including @fboundy the Predbat options are too complex and there are too many

I'm wondering rather than having configuration groups as suggested that instead doing a few things

Delete a bunch of options/hard-wire them (some may change for other inverters) Add an expert mode which exposes some extra options Please can @iainfogg @fboundy review and see what you think of the ideas, they can be tweaked:

b6e2319

Actually the code isn't removing the sensors in non-expert mode, I think i need to add the flag to the table to change load_config but I'll do that soon if we think it's a good way to go

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[springfall2008]

So I've done another push to the branch which I think is now much cleaner.

The defaults for all the HA config items are now in the configuration table rather mixed around in the code. I think maybe the other apps.yaml config items should be combined with this as a next step to put things in one place.

When you disable expert mode (or indeed iboost or balance) the extra options are changed to be listed as 'Disabled'. After a HA reboot they should go away totally. When you turn the feature back on they should re-appear.

The dashboard yaml needs splitting into basic and expert options and the documentation updating we if actually go with this approach.

[springfall2008]

I've also experimented auto-generating the YAML dashboard, I can write the file out to the config directory but I don't know how to display it - any ideas?

[gcoan]

The problem is that most of the ha config is now maintained as blobs in the database so it's not as easy to program into.

But the older method of using files still works. Not tested it but this article explains how to maintain a dashboard via a yaml file. Need to point configuration.yaml to use it

https://community.home-assistant.io/t/how-can-i-manage-the-dashboards-using-yaml-files/538385/2 On 19 Nov 2023 at 19:23 +0000, Trefor Southwell @.***>, wrote:

I've also experimented auto-generating the YAML dashboard, I can write the file out to the config directory but I don't know how to display it - any ideas? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[springfall2008]

I've made a beta release of these changes here: https://github.com/springfall2008/batpred/releases/tag/v7.13

It needs some more testing but I don't think it breaks anything major, lets see

[gcoan]

I've installed the 7.13 beta and looked at the release notes and the settings that are being removed and those that are going to expert mode.

All the settings you've removed, apart from one, the new defaults match my setup so no impact to me and they make sense to remove. However I didn't get a load of errors in my dashboard, it appears that the deleted entities are still there? The exception was metric_cloud_enable which was a beta feature and is now permanently on. I didn't understand what this was doing, and re-reading the docs, I'm still not entirely sure what it does to simulate cloud coverage and "modulates PV output" so I don't know if its permanent inclusion is good or bad. To me 'modulate' implies a sine wave or other periodic variation, so 10 minutes at PV10%, 10 minutes at PV50%, etc??

My guess though was that rather than having a single input_number.predbat_pv_metric10_weight to weight the usage of the 10% PV prediction to the 50% PV prediction, the weighting changes depending on the kWh values of the 10% and 50% predictions. e.g. if there is a large variation between 10% and 50% prediction then the weighting towards the 10% is increased, and if there is small variation between the two then more weight it applied to the 50%. I had thought of doing an automation like this myself, to take more a pessimistic PV prediction when the 10% indicates it will be materially worse than the 'standard' 50%. Is this how it works? Could you expand the docs further please?

Looking at the entities that have gone to expert mode, again the defaults for these pretty much match my settings with the few exceptions being:

• inday adjustment. I had this set to 1, new default is 0.95. Our daily home pattern is the same most of the time so I never specified anything different. The 5% delta won't make much difference either way.
• battery cycle, I have this set to 0, new default is 2. Figured I've already paid for the battery so I'll use it and whether its cost beneficial or not is already reflected in the different loss figures
• second pass, I have this currently set to true. TBD whether this is a good thing or not, but I was figuring to give predbat the best chance of calculating the prediction it can by leaving it turned on
• load filter modal, I have this set to false, new default is true. Same comment as above about consistent daily consumption so didn't set it on.

I'd suggest that the various balance inverter switches also should be moved to expert mode. rate_low_match_export - should this be part of expert mode? Also seems that this has been accidentally removed from the config document wonder whether battery_rate_scaling, load_scaling and pv_scaling could also be expert mode config options? Since the new predbat_calculate_best switch is an expert option, should predbat_calculate_best_charge also be?

And finally, I like the idea of the auto-generated dashboard, but mine isn't, and I'm periodically getting the status error:

[gcoan]

Bit of feedback, could be a bug introduced by the expert mode, or could be something else? Expert mode = off Predbat status=charging target soc=39% I noticed one inverter (soc=17%) was charging the other (soc=46%) was discharging - so they were cross charging. I thought you'd made a change to set discharging to disabled when mode=charging, but the charge rates were allowing full charge and discharge

update: I manually turned discharge rate of the discharging inverter to 0 to stop the cross charge, but of course next 5 min run, predbat changed it back.

I turned expert mode off, its now freeze charging, both discharge rates are set to zero. here's the logfile: appdaemon (11).log

[springfall2008]

Bit of feedback, could be a bug introduced by the expert mode, or could be something else? Expert mode = off Predbat status=charging target soc=39% I noticed one inverter (soc=17%) was charging the other (soc=46%) was discharging - so they were cross charging. I thought you'd made a change to set discharging to disabled when mode=charging, but ithe charge rates were allowing full charge and discharge

So that is 'set_discharge_during_charge' and I don't think I changed it, do you see the option?

[springfall2008]

I've installed the 7.13 beta and looked at the release notes and the settings that are being removed and those that are going to expert mode.

Thanks for testing.

All the settings you've removed, apart from one, the new defaults match my setup so no impact to me and they make sense to remove. However I didn't get a load of errors in my dashboard, it appears that the deleted entities are still there? The exception was metric_cloud_enable which was a beta feature and is now permanently on. I didn't understand what this was doing, and re-reading the docs, I'm still not entirely sure what it does to simulate cloud coverage and "modulates PV output" so I don't know if its permanent inclusion is good or bad. To me 'modulate' implies a sine wave or other periodic variation, so 10 minutes at PV10%, 10 minutes at PV50%, etc??

Basically it's 5 minutes at above average and 5 minutes below average and the modulation amount relates to the difference between PV 50% and PV 10%. The reason is to account for drain on the battery during cloud cover which before wasn't modelled. I think it's safe to use as I've been testing it for a while now.

My guess though was that rather than having a single input_number.predbat_pv_metric10_weight to weight the usage of the 10% PV prediction to the 50% PV prediction, the weighting changes depending on the kWh values of the 10% and 50% predictions. e.g. if there is a large variation between 10% and 50% prediction then the weighting towards the 10% is increased, and if there is small variation between the two then more weight it applied to the 50%. I had thought of doing an automation like this myself, to take more a pessimistic PV prediction when the 10% indicates it will be materially worse than the 'standard' 50%. Is this how it works? Could you expand the docs further please?

The weighting says how much of the cost of the 10% plan to include in calculation of the overall plan. If there is no variation between 10% and 50% then this will have no impact anyhow, if there is a big difference it will have a larger impact. The weighting is simply how much to take the 10% into account. I don't see the need for a second order weighting on top of this, but maybe I missed something?

e.g. if PV50% says 10Kwh and PV10% says 9Kwh and weighting is 10% then 9.9kWh would be assumed. If weighting was 100% then 9Kwh would be assumed.

Looking at the entities that have gone to expert mode, again the defaults for these pretty much match my settings with the few exceptions being:

• inday adjustment. I had this set to 1, new default is 0.95. Our daily home pattern is the same most of the time so I never specified anything different. The 5% delta won't make much difference either way.

The 5% delta is just if your load does go up then it won't count all of the increase into the future.

• battery cycle, I have this set to 0, new default is 2. Figured I've already paid for the battery so I'll use it and whether its cost beneficial or not is already reflected in the different loss figures

Makes sense.

• second pass, I have this currently set to true. TBD whether this is a good thing or not, but I was figuring to give predbat the best chance of calculating the prediction it can by leaving it turned on

You are starting to sound like an expert user :)

• load filter modal, I have this set to false, new default is true. Same comment as above about consistent daily consumption so didn't set it on.

Fair enough, although it probably won't impact you either way.

I'd suggest that the various balance inverter switches also should be moved to expert mode.

I think if balance is off then the switches won't show, if you enable it then they will show.

rate_low_match_export - should this be part of expert mode? Also seems that this has been accidentally removed from the config document

This has been removed from the code too.

wonder whether battery_rate_scaling, load_scaling and pv_scaling could also be expert mode config options?

I did wonder about that, do you ever use them? I sometimes do to bump up my load or reduce the PV estimate to see scenarios.

Since the new predbat_calculate_best switch is an expert option, should predbat_calculate_best_charge also be?

Calculate best when turned off removes the entire best calculation, not something most people will use.

I don't know about calculate_best_charge I guess not calculating charging could make sense if you only want to export?

And finally, I like the idea of the auto-generated dashboard, but mine isn't, and I'm periodically getting the status error:

This is due to the old vs new Appdaemon, I think I'll change the location to /config which should work for everyone

[gcoan]

So that is 'set_discharge_during_charge' and I don't think I changed it, do you see the option?

yes I see the option now, still too many config options ! It is set to true for me still so it should have prevented the cross charging.

Maybe having expert mode off caused a different path through the code?

[gcoan]

All the settings you've removed, apart from one, the new defaults match my setup so no impact to me and they make sense to remove. However I didn't get a load of errors in my dashboard, it appears that the deleted entities are still there? The exception was metric_cloud_enable which was a beta feature and is now permanently on. I didn't understand what this was doing, and re-reading the docs, I'm still not entirely sure what it does to simulate cloud coverage and "modulates PV output" so I don't know if its permanent inclusion is good or bad. To me 'modulate' implies a sine wave or other periodic variation, so 10 minutes at PV10%, 10 minutes at PV50%, etc??

Basically it's 5 minutes at above average and 5 minutes below average and the modulation amount relates to the difference between PV 50% and PV 10%. The reason is to account for drain on the battery during cloud cover which before wasn't modelled. I think it's safe to use as I've been testing it for a while now.

I'm not massively bothered either way now that its in the base (always on) predbat code, I'll treat it as part of the "predbat magic" that I don't pretend to understand ... So in a 30 minute charging period, rather than assuming PV50% for the entire period (weighted by the metric10 factor, etc), its now adjusting the amount of anticipated PV every 5 minutes based on the difference between the PV10 and PV50? Of course predbat has no knowledge of when the clouds will appear. I'm still not entirely getting what it does and why, predbat magic !

The weighting says how much of the cost of the 10% plan to include in calculation of the overall plan.

I'm OK with how the metric 10 works, I have mine set to 0.3. Its just the interplay of this with the cloud model I didn't understand.

• inday adjustment. I had this set to 1, new default is 0.95. Our daily home pattern is the same most of the time so I never specified anything different. The 5% delta won't make much difference either way.

The 5% delta is just if your load does go up then it won't count all of the increase into the future.

For me as I have a heat pump the house load in winter is very weather dependent. Looking at my data, I'm typically in the range 35-45kW a day but November 18th was 30kW and November 11th was 62!
I try to mitigate this by having 7 days of load history so at least I get a reasonable smoothed average and turn on calculate_inday_adjustment

I'd suggest that the various balance inverter switches also should be moved to expert mode.

I think if balance is off then the switches won't show, if you enable it then they will show.

Just tried it, and yes this is the case. I just thought balance inverters was more of an expert-mode concept.

wonder whether battery_rate_scaling, load_scaling and pv_scaling could also be expert mode config options?

I did wonder about that, do you ever use them? I sometimes do to bump up my load or reduce the PV estimate to see scenarios.

I don't use any of these. They seemed more advanced config options to me and not what most users would use.

Since the new predbat_calculate_best switch is an expert option, should predbat_calculate_best_charge also be?

Calculate best when turned off removes the entire best calculation, not something most people will use.

I don't know about calculate_best_charge I guess not calculating charging could make sense if you only want to export?

Agreed, seems a limited use switch that most people wouldn't need to set, so hence make it expert mode?

And finally, I like the idea of the auto-generated dashboard, but mine isn't, and I'm periodically getting the status error:

This is due to the old vs new Appdaemon, I think I'll change the location to /config which should work for everyone

I haven't installed the new appdaemon yet. I see there are installation instructions bow for how to move things around to keep predbat working with the new appdaemon so I will move soon and I'd expect new users will be on the new appdaemon anyway.

Looking on my HA instance I have got a /homeassistant directory and /config is a symbolic link to /homeassistant I think the error is that it can't find the file or maybe doesn't have write permissions?

[springfall2008]

So that is 'set_discharge_during_charge' and I don't think I changed it, do you see the option?

yes I see the option now, still too many config options ! It is set to true for me still so it should have prevented the cross charging.

Maybe having expert mode off caused a different path through the code?

It needs to be false for your use case

[gcoan]

And finally, I like the idea of the auto-generated dashboard, but mine isn't, and I'm periodically getting the status error:

This is due to the old vs new Appdaemon, I think I'll change the location to /config which should work for everyone

I haven't installed the new appdaemon yet. I see there are installation instructions bow for how to move things around to keep predbat working with the new appdaemon so I will move soon and I'd expect new users will be on the new appdaemon anyway.

Looking on my HA instance I have got a /homeassistant directory and /config is a symbolic link to /homeassistant I think the error is that it can't find the file or maybe doesn't have write permissions?

Update: installed v7.13.1 and it has written the predbat dashboard OK.

Having fiddled with it, I don't think it is yet the automagical solution I was hoping it to be.

Best result would be if this could automatically be added to HA, but I recognise that will probably need changes to configuration.yaml and a HA restart to happen.

The problem is that it (at the moment), its not a complete dashboard, its the YAML for a dashboard card so to get this into HA you need to:

• open the YAML with a file editor (navigating where it is on the file system)
• select all, copy
• go to dashboards, either create a new dashboard, or edit an existing one
• add card
• scroll down to the bottom of the list of cards
• click Manual
• select all (the default YAML) and paste in the YAML from the filesystem file
• save etc etc

This is quite a few steps for a newby to get right. Its much the same as the sample charts where I tried to paste them directly into a dashboard and of course all the indentation is off and that doesn't work.

Extra suggestion: move predbat status to near the top, its currently very near the bottom

[gcoan]

So that is 'set_discharge_during_charge' and I don't think I changed it, do you see the option?

yes I see the option now, still too many config options ! It is set to true for me still so it should have prevented the cross charging. Maybe having expert mode off caused a different path through the code?

It needs to be false for your use case

thanks. I wonder how that got changed, I don't recall changing it, but clearly it has been at some point

I've looked and I don't think this config option is covered in the docs?

[fboundy]

OK - I have 7.13.1 installed in read_only. I've got my own code running alongside it. The metrics aren't quire comparable yet but I will get things set up so they are and do a comparison over the next week. The basics are very similar. My instinct is that Predbat seems to charge the battery more that my code for the same conditions but I've just recoded lot of mine and it may be under-estimating what is required. They are also currently running over different forecast periods so not apples and apples at all.

[gcoan]

So that is 'set_discharge_during_charge' and I don't think I changed it, do you see the option?

It needs to be false for your use case

thanks. I wonder how that got changed, I don't recall changing it, but clearly it has been at some point

I've looked and I don't think this config option is covered in the docs?

I can see discharge rate is now zero during charging. Sorted, thanks

[springfall2008]

OK - I have 7.13.1 installed in read_only. I've got my own code running alongside it. The metrics aren't quire comparable yet but I will get things set up so they are and do a comparison over the next week. The basics are very similar. My instinct is that Predbat seems to charge the battery more that my code for the same conditions but I've just recoded lot of mine and it may be under-estimating what is required. They are also currently running over different forecast periods so not apples and apples at all.

Are you accounting for the value of export in your predictions and also the downsides of the PV10% scenario? What about hybrid inverters and how the losses are different?

[fboundy]

Yes, I account for the value of export but at present on Agile it is almost never worth more than the cost of import and I don't generate enough solar to export much anyway. I've tested it using Flux instead and it does what I would expect (I pull the tariff direct from OE so I don't rely of Bottlecap Dave - this makes it much easier to test other tariffs).

I don't account for the low case Solcast at present (though I can and should) but I have reset the Metric_10 factor in Predbat to zero to make the case the same.

I don't yet allow for the potential difference in efficiency with a hybrid inverter but having analysed a year's worth of data from my system I'm not convinced that the Solis is much more efficient in DC:DC conversion.

One difference I have noticed is in the load calculation. Like Predbat I am averaging the last 7 days but mine appears to be 20-30% lower which seems odd and needs a little more investigation. Mine is calculated from instantaneous rates rather than Total which probably makes it more prone to sampling bias. Taking the gradient of the Total is a better approach so I will change to that.

All of this has been made a lot more complicated by the various Breaking Changes to AppDaemon and the Octopus Energy integration!

[ungrim97]

Putting here, as I suspect it is related to the config updates. I am seeing a type error in my logs that appears to be stoping PredBat working.

    self.soc_max *= self.base.battery_scaling
TypeError: unsupported operand type(s) for *=: 'float' and 'NoneType'

self.soc_max should be coming from the GE REST api as "Invertor_Details": { "Battery_Capacity_kWh": 14.7456, ... } and I believe the battery_scaling is the default 1.0 as I don't believe I have this configured anywhere

This is very likely a "User Error" on my part whilst adjusting to the new config setup. Advice welcome

[ungrim97]

Adding battery_scaling: 1.0 in to my app.yaml appears to have fixed this. Not sure why it didn't get the default

[fboundy]

No I think this is a bug that has crept in through the edits to support Solis inverters. I had the same last night when I reinstalled from HACS rather than my branch of the Repo.

Let me have a look and I will try to get a patch to Trefor to fix this. On 21 Nov 2023 at 13:04 +0000, Mike Eve @.***>, wrote:

Putting here, as I suspect it is related to the config updates. I am seeing a type error in my logs that appears to be stoping PredBat working. self.soc_max = self.base.battery_scaling TypeError: unsupported operand type(s) for =: 'float' and 'NoneType' self.soc_max should be coming from the GE REST api as "Invertor_Details": { "Battery_Capacity_kWh": 14.7456, ... } and I believe the battery_scaling is the default 1.0 as I don't believe I have this configured anywhere This is very likely a "User Error" on my part whilst adjusting to the new config setup. Advice welcome — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[springfall2008]

No I think this is a bug that has crept in through the edits to support Solis inverters. I had the same last night when I reinstalled from HACS rather than my branch of the Repo. Let me have a look and I will try to get a patch to Trefor to fix this. … On 21 Nov 2023 at 13:04 +0000, Mike Eve @.**>, wrote: Putting here, as I suspect it is related to the config updates. I am seeing a type error in my logs that appears to be stoping PredBat working. self.soc_max = self.base.battery_scaling TypeError: unsupported operand type(s) for *=: 'float' and 'NoneType' self.soc_max should be coming from the GE REST api

I think this maybe my bug I deleted the default by mistake, now restored

[fboundy]

Ah - OK.

[iainfogg]

Please can @iainfogg @fboundy review and see what you think of the ideas, they can be tweaked

Sorry, been away for a few days so couldn't look at this until now - looks like it's now all done and released? Let me know if you need anything on this, apart from general feedback once I've been able to check it out (which I've avoided so far due to the various changes needed due to both AppDaemon and updates to the YAML file).

[gcoan]

I've noticed in the logfile that the predbat.yaml seems to be being written almost every run of predbat - does it need to be? Would think it'd only be needed on first load when all the entities are created or when expert mode is turned on?

[iainfogg]

Just a thought @springfall2008 - in terms of simplifying options, it feels like we've got lots of options for continuing whether Predbat does charging and discharging.

There are two calculate options, plus various set options, plus read only.

I wonder if this could all be broken down to a single option read only? Where it plans both, but doesn't set anything?

I've only ever needed finer control where something's been going wrong with either the plan or my kit.

[springfall2008]

Just a thought @springfall2008 - in terms of simplifying options, it feels like we've got lots of options for continuing whether Predbat does charging and discharging.

There are two calculate options, plus various set options, plus read only.

I wonder if this could all be broken down to a single option read only? Where it plans both, but doesn't set anything?

I've only ever needed finer control where something's been going wrong with either the plan or my kit.

I think the main use model is some people don't want to force export.

That said what about replacing them all with one drop down menu that has the modes e.g:

Read only Plan charge Plan discharge Plan charge & discharge

Might be easier?

[gcoan]

The drop down mode is a good idea, nice simple to understand, and reintroduces some of the other modes to predbat that have been lost in the option simplification

On 23 Nov 2023, at 14:13, Trefor Southwell @.***> wrote:

 Just a thought @springfall2008 - in terms of simplifying options, it feels like we've got lots of options for continuing whether Predbat does charging and discharging.

There are two calculate options, plus various set options, plus read only.

I wonder if this could all be broken down to a single option read only? Where it plans both, but doesn't set anything?

I've only ever needed finer control where something's been going wrong with either the plan or my kit.

I think the main use model is some people don't want to force export.

That said what about replacing them all with one drop down menu that has the modes e.g:

Read only Plan charge Plan discharge Plan charge & discharge

Might be easier?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[iainfogg]

Yep, I really like the single drop down option with the four choices, good idea @springfall2008

[springfall2008]

I'll put that on backlog :)

[springfall2008]

Please review: https://github.com/springfall2008/batpred/tree/predbat-mode

[gcoan]

Hi Trefor,

I've not tried installing the code yet, but had a quick look at it and the documentation changes.

It looks to be a great simplification, will definitely help new users with less options and selectors. Could I suggest though that the default mode be Monitor so it's a conscious decision (guided by following the install instructions) to turn predbat on. I remember when I had first installed and configured predbat, it started making changes and I had to ask for help as to how to stop it until I understood it better !

Other observation is I think you've taken the code fork ahead of the PR for doc changes I'd made over the weekend. Looking at the customisation.md history I don't see my changes which you'd approved.

Probably need to add something to the install & what does predbat do docs as well (both of which I probably tweaked).

[springfall2008]

Good point about the default, I can see Monitor maybe useful.

The only thing is I couldn't decide if Monitor should plan charge and discharge but not control the inverter (like read-only mode) or do what I made it do currently which is just show the base (not predbat controlled plan). Both can be useful but clearly there is a crossover with read-only mode.

You can merge your PR first and I can resolve any conflicts when I do my PR

[gcoan]

I think' Monitor as a distinct mode has its advantages, and then it's separate from read only. As long as we're clear what the two do and how they are different, it's ok.

[gcoan]

I've been trying the new beta 7.14

Suggest the release notes need to make clearer that predbat_mode is a breaking change and that when upgrading predbat will start in the Monitor mode and users have to be changed to the appropriate new mode.

Think changing the mode should be added explicitly also (step 12?) to the install summary, and also could be added as an FAQ (and explain about read-only mode as well)

I'm not getting any errors on my dashboard about entities no longer existing : calculate best charge/discharge and set charge window all appear to exist still?? Update: Is calculate best also now redundant?

One issue, the new select.predbat_mode does not appear on the collapsable card. Here's a new version with the mode added at the top:

    cards:
      - type: vertical-stack
        title: Predbat 🦇
        cards:
          - type: entities
            entities:
              - predbat.status
              - select.predbat_mode
          - type: custom:collapsable-cards
            title: 🔀 Control
            defaultOpen: true
            cards:
              - type: custom:collapsable-cards
                title: 🔀 Options
                defaultOpen: true
                cards:
                  - type: custom:auto-entities
                    card:
                      type: entities
                    filter:
                      include:
                        - entity_id: switch.predbat*
                      exclude: []
                    unique: true
                    sort:
                      method: friendly_name
                      numeric: false
              - type: custom:collapsable-cards
                title: 🔀 Switches
                defaultOpen: true
                cards:
                  - type: custom:auto-entities
                    card:
                      type: entities
                    filter:
                      include:
                        - entity_id: switch.predbat*
                      exclude: []
                    unique: true
                    sort:
                      method: friendly_name
                      numeric: false
              - type: custom:collapsable-cards
                title: 🔢 Input Variables
                defaultOpen: false
                cards:
                  - type: custom:auto-entities
                    card:
                      type: entities
                    filter:
                      include:
                        - entity_id: input_number.predbat*
                      exclude: []
                    unique: true
                    sort:
                      method: friendly_name
                      numeric: false
          - type: custom:collapsable-cards
            title: '#️⃣ Sensors'
            defaultOpen: false
            cards:
              - type: custom:collapsable-cards
                title: 💷 Cost Sensors
                defaultOpen: false
                cards:
                  - type: custom:auto-entities
                    card:
                      type: entities
                    filter:
                      include:
                        - entity_id: predbat.*cost*
                        - entity_id: predbat.*rate*
                        - entity_id: predbat.*metric*
                      exclude:
                        - entity_id: predbat.*start*
                        - entity_id: predbat.*end*
                        - entity_id: predbat.*duration*
                    unique: true
                    sort:
                      method: friendly_name
                      numeric: false
              - type: custom:collapsable-cards
                title: 🕛 Time/Duration Sensors
                defaultOpen: false
                cards:
                  - type: custom:auto-entities
                    card:
                      type: entities
                    filter:
                      include:
                        - entity_id: predbat.*start*
                        - entity_id: predbat.*end*
                        - entity_id: predbat.*duration*
                        - entity_id: predbat.*record*
                      exclude: []
                    unique: true
                    sort:
                      method: friendly_name
                      numeric: false
              - type: custom:collapsable-cards
                title: ⚡ Power Sensors
                defaultOpen: false
                cards:
                  - type: custom:auto-entities
                    card:
                      type: entities
                    filter:
                      include:
                        - entity_id: predbat.*soc*
                        - entity_id: predbat.*energy*
                        - entity_id: predbat.*load*
                        - entity_id: predbat.*battery*
                        - entity_id: predbat.*kw*
                        - entity_id: predbat.*power*
                      exclude: []
                    unique: true
                    sort:
                      method: friendly_name
                      numeric: false
              - type: custom:collapsable-cards
                title: 1️⃣ Binary Sensors
                defaultOpen: false
                cards:
                  - type: custom:auto-entities
                    card:
                      type: entities
                    filter:
                      include:
                        - entity_id: binary_sensor.predbat*
                      exclude: []
                    unique: true
                    sort:
                      method: friendly_name
                      numeric: false

[iainfogg]

Maybe on upgrade the system should figure out which mode most closely reflects the user's current settings.

I had charge and discharge calculated and set, so you can figure out that I want the the "control charge and discharge" mode.

[gcoan]

Maybe on upgrade the system should figure out which mode most closely reflects the user's current settings.

I had charge and discharge calculated and set, so you can figure out that I want the the "control charge and discharge" mode.

I don't know if that's possible @iainfogg; the python code gets replaced, appdaemon restarted and it has to instantiate all its entities, etc. Maybe if the upgrade release doesn't (yet) replace the existing set_charge entities (as the release note says they are) and they are instead (at the moment) deprecated to read-only it could read the prior values and deduce the initial Mode setting? Either way, its a breaking change of a new control function and existing controls no longer operating as they used to

[springfall2008]

Maybe on upgrade the system should figure out which mode most closely reflects the user's current settings. I had charge and discharge calculated and set, so you can figure out that I want the the "control charge and discharge" mode.

I don't know if that's possible @iainfogg; the python code gets replaced, appdaemon restarted and it has to instantiate all its entities, etc. Maybe if the upgrade release doesn't (yet) replace the existing set_charge entities (as the release note says they are) and they are instead (at the moment) deprecated to read-only it could read the prior values and deduce the initial Mode setting? Either way, its a breaking change of a new control function and existing controls no longer operating as they used to

I did think about this, but it's kind of a pain to implement and it's a fairly minor thing the user has to do to select the right mode so I didn't in the end.

[iainfogg]

And presumably plenty of people have upgraded without issue, so that sounds good.

Do you have any download stats from HACS or GitHub @springfall2008 ? Interested to know how long it takes for people to upgrade, and how many people are using Predbat.

[springfall2008]

And presumably plenty of people have upgraded without issue, so that sounds good.

Do you have any download stats from HACS or GitHub @springfall2008 ? Interested to know how long it takes for people to upgrade, and how many people are using Predbat.

I'm afraid I don't get any usage statistics. It wouldn't be that hard to add them to Predbat but I'm not sure I want to collect data for GDPR reasons.

Trefor.

[iainfogg]

@springfall2008 I would have thought that the data would be anonymous, just number and times of downloads per release, so not affecting GDPR requirements. I think I've seen it on another integration, just can't remember which one. If I find it, I'll let you know.