Future Development

[fboundy]

@springfall2008 @iainfogg @gcoan - moving our discussion here as it seems more appropriate.

Couple of things:

If you are on Facebook you might want to join the new Octopus Automation group. Lots of like-minded people.

I posted a quick poll on there to ask what inverters people are using:

Looks like we have got about 40% covered already. Next on my list to look at were Solax and SolarEdge and that would get 80% which seems a good target.

[gcoan]

I'm not on facebook so can't really join the group, but interesting to see what inverters different people have.

One theme several of us came up with was 'better UI and easier control'. So as a starter, should we agree what we think we have today and where we want to get to?

In terms of today and positives (+) and negatives (-) I'd say:

• lots of configuration options so richness to tweak predbat as you want

• too much configuration so newcomers get lost in the learning curve
• not clear what each of the different options do and the descriptions are in the docs not the dashboards

• rich output from predbat that can be mapped into Apex or similar charts to show most things you would ever want

• even now I'm not sure what some of the charts tell me!
• the charts have different time periods so difficult to read and compare information from one chart to another (I have changed my charts to all have the same time periods and am using a custom grid layout so I can read them vertically)
• bewildering amount of information on many of the charts (I have made some cut-down charts with 'key info' which are easier to read key things like soc, import, load and pv)

• the new HTML predbat plan actually does away with the need to look at the charts most of the time, its very easy to read and see what is happening hour by hour

• again, lots and lots of data. I've shortened my forecast window to 36 hours but the plan can still be enormous and takes a while to scroll down it. Doesn't really suit being part of a wider dashboard
• the apex charts don't really work well on a mobile phone. Tablet they are OK-ish but still a lot of data to see

My desires:
x an out of the box dashboard for predbat that new users can install to give them a usable "predbat experience" without the learning curve
x easy to apply standard sets of settings (the new work on groups might meet this)
x less settings
x settings that are not relevant to different user types are hidden eg iboost, car charging
x tool tips and links to docs within the dashboard to explain what everything does
x maybe two views: plan/chart view and control/setup view
x scrollable/dynamic graphs. e.g can see the next 6 hours of plan and scroll to the right to see the next 6, or scroll out to see the 'big picture'
x mechanism to maintain the basic dashboard automatically with new releases, doesn't rely on people having to apply delta's manually based on release note changes

[iainfogg]

Not ignoring this, I'll reply later in the week

[iainfogg]

OK, I'm lagging behind a bit as I've been away, and everything seems to have got very complicated while I was away with AppDaemon etc. so I'm not even on the most recent version to comment properly on that.

However, I'll try and sum up my thoughts on going forward. I think much of this is similar to what others have said at different times too, so I think we're on similar lines.

User experience

In an ideal world, I'd like new users to be able to get going without needing to edit any YAML anywhere. Some integrations offer a configuration screen when they're set up (e.g. the Octopus one), and that could ask questions to get some of the key info that's needed.

Also, I'd like to see custom cards being set up that can be used to add specific chunks of UI, again without needing to edit YAML. I've done some hacking around here, and there are some issues currently with it. HA simply doesn't seem to support distributing some types of cards e.g. an Entities card with specific entities that you want to see. However, I did get an Apex Chart working.

In terms of settings, I'm keen on simple config wherever possible, I know this has now been done although I've not seen it. Being able to select a tariff then get all the complicated stuff set for you is what many people will want to have, I think. Hopefully this aspect is either done, or at least the direction of travel is set and we can keep improving as we go.

Some people have a fairly simple use case - for example, they're on Intelligent, and want to keep their battery charged when they charge their car (including additional slots). I'd like Predbat to feel like a good solution for that use case, but to do that, it needs to be really simple - plug and play, click a few drop-downs, type a bit of text and it's good to go. I'd love it if it were simple for people in that sort of situation, as well as for those people who want fine grained control and don't mind hacking around to get it.

Feature development

Personally I would lean towards turning down more feature requests, at least for a while. My concern is that Predbat becomes more and more complex, and because of the current structure, it becomes harder and harder to maintain.

I'd rather freeze the feature set, to get time to improve both the UI and also code quality.

And in fact, I'd potentially consider dropping some features to make it more simple, both for the number of parameters, and also for the sake of the code.

Code quality

At the moment, the code seems to me to be typical of code that's evolved rapidly, from something relatively simple, to something huge.

It's gone from 350 lines in v1.0 to over 9,000 lines in v7.13.4. Also, some of the methods have become really long (and therefore really complicated), and I still find I haven't properly got my head round how big parts of it work.

Also, we don't have automated tests, which makes it easy for tweaks to algorithms to introduce issues. And having so many parameters makes setting up automated tests even harder too.

I'd be keen on:

• Getting some automated tests in place (I've done some experimenting to start this, but it's nowhere near currently)
• Getting coding standards implemented (I've got a PR and an issue that's mostly done the first step of this, but I'd like to see more e.g. checking for variable types, and other coding errors that can slip in)
• Breaking the code up into smaller classes in separate files, improving their readability and testability
• I'd aim to support the last one with some code complexity metrics if possible, to show our progress as we go
• Having either interfaces or some sort of plugin structure to make it easy to drop in different versions of key components e.g. a tariff class, or an inverter class, or a plan optimiser class or whatever, so that you can get a working system by joining up a variety of classes that are built to work together
• Aiming for code that is understandable by a reasonable number of us, to better support maintainability going forward
• Moving the repo from a personal repo to an organisation repo (actually, it's changing Trefor's account from a personal one to an organisation one), so @springfall2008 can give more fine-grained permissions to other contributors than can be done with the current model.

I think that's it for now, but I'll update this if I think of more.

[iainfogg]

@fboundy I did check out that Facebook group you mentioned. I got the impression that lots of people there are really early on their journey with HA, compared to the GivTCP group, for example. I know that's a generalisation, but it reinforced for me the importance of improving the UI, simplifying the parameters and setup etc. if we are keen to see a wider group of people benefiting from Predbat goodness 😄

[JonathanLew1s]

I'd agree on simplification. It's a great solution that potentially misses a potential user base due to complexity to install and complexity to understand the myriad of settings and the relevant tuning.

• Remove the requirement for AppDaemon
• One Button Mode (On/Off) - Read the tariff information from the relevant integration and set optimal predbat settings. Hide everything but the prediction html.
• Effort Setting - I expect users have different requirements, some will want to minimise spend at any level of effort, some will want best effort without excessive charge/discharge, others just avoid peak import. Set the relevant back end settings based on an aggression setting with frequency of runs, metrics, weights etc set based on aggression level.
• Consistency in numbers where possible. It's not always easy to determine if the value is a cost, percentage, kWh etc. SOC reserve is a percentage yet SOC keep is kWh. I'm a proponent of percentages.

[marksie1988]

Personally I feel that some major improvements could be made doing the following:

• Inverters should have their own class, with it being decoupled from predbat, currently having the GivTCP directly linked and then a "bodge" to add other inverters feels dirty, moving them out of the main code to use specific definitions would be better.
• Convert it to an integration - having to install appdaemon and load it through that is a pain, I dont really want appdaemon on my install so would be much better
• Better descriptions of the settings - some of the wording is up to interpretation and doesnt explain what they actually are. for example: inverter_mode / load_power (assume this is load in the house) / battery_power (is this kwh? ah?)
• some inverters use soc_kw some use soc_%, just change this to be "soc" and then have the code work out if its kw or %

[marksie1988]

Atomic Calendar Revive.

[iainfogg]

Looks neat @marksie1988

[marksie1988]

@iainfogg fyi I'm making progress on creating an integration version. It's very basic at the moment and just had the frontend config parts.

[iainfogg]

Hi @marksie1988 did you see the one I'd been working on? It's at iainfogg/predbat_ha

I've also done some work to get the basics of the UI for config (although haven't fleshed it out to have everything in, it just has a couple of values in it, but it does work and allows editing of existing values).

It also sets up a few random sensors as a proof of concept, they need replacing with real ones.

You're welcome to work on my repo if you like, and to build out the config part. Or feel free to work on your own too if that's easier. I'll give you contributor rights if you want it.

If you do want to run mine, you'll just need to comment out the call to the initialize function for old Predbat. I was working on building a stub for Appdaemon, so the old Predbat code could run with next to no modifications, but where it thinks it's calling Appdaemon for getting state etc, it'd actually be calling my code, which would redirect to HA calls instead. It's early days with that, and it throws errors currently, but commenting that one line should make it runnable.

This isn't necessarily the best approach, but it felt worth pursuing as it saves rewriting the core Predbat code as well as adding the new stuff in.

And there's a lot of work to be done on sync / sync, and making it runnable in whatever form we end up with.

[marksie1988]

Ah nice I didn't realise you had a version started, I'll take a look but would make sense to work together and get it working quicker 👍

I'll take a look when I get chance.

[LupoLoopy]

Hi Team!

I currently run SolarEdge (Modbus integration) and do a small bit of development (more scripting than coding these days). Is there any way I can help move the SolarEdge module forward, or is this already covered by one of the existing crew? I'm happy to develop or just to test code that someone else has conceived.

[springfall2008]

Yes certainly, if you could get predbat set up on your system and then propose any changes to make it work that would be awesome. It's hard for me to do without a test platform.

[Sandbox6168]

Hi all, before I start I want to say that I am finding batpred to be great so far.

However I was trying to debug some problems I was having with batpred setting incorrect times and I found the code fairly hard to follow with all of the inverter login merged into a single file.

I noticed that some people mentioned they were looking into splitting inverters out into separate classes, is that still ongoing? I'd be happy to help with this as I think it's going to be important as batpred grows.