Discussions points and comments here

[zarch1972]

Testing issues.

[beaylott]

Sounds interesting but probably need to scope it out a bit more. Sounds like there is quite a bit of overlap with the Open Energy Monitor Demand Shaper work:

https://community.openenergymonitor.org/t/emoncms-demand-shaper-module/9097

Although that is less focussed on batteries but is plugged into octopus.

The open energy monitor forum could be another place to discuss:

https://community.openenergymonitor.org/latest

[Leccyplanet]

Worth considering adding as integration to home assistant or similar. Already has gui, automatons, scripts, database, grafana. Plus loads of other integrations. Save a lot of work building on what's already there.

[zarch1972]

Sounds interesting but probably need to scope it out a bit more. Sounds like there is quite a bit of overlap with the Open Energy Monitor Demand Shaper work:

https://community.openenergymonitor.org/t/emoncms-demand-shaper-module/9097

Although that is less focussed on batteries but is plugged into octopus.

The open energy monitor forum could be another place to discuss:

https://community.openenergymonitor.org/latest

Thanks Ben. Yep, aware of what Glyn and Trystan are doing as I already own an emonPi / emonTX setup.

My worry about their product is that its focused around their EVSE charger, and rightly so. What i'm thinking about is a more open and modular approach, where you can just plug in and use different API at each end (inputs and outputs).

So far, the Octolux work by Chris Elsworth creating charging 'rules' is the best so far. But its tied solely to a Lux inverter. My thoughts are to keep the rules bit in place alongside the Agile code, but then expand the output side to more batteries than just Lux.

[zarch1972]

Worth considering adding as integration to home assistant or similar. Already has gui, automatons, scripts, database, grafana. Plus loads of other integrations. Save a lot of work building on what's already there.

I already use Home Assistant for monitoring various household things and scooting them off to both influx and grafana. You're right, it has great support and importantly a large user / developer base.

But my concern about HA is the brains bit of the project. Correct me if i'm wrong, but I see HA only capable of simple if this time, do this. Like a basic scheduler?

Plus, the yaml knowledge to get entities, rules and dashboards up and running isn't really inviting to non-techies. Especially if we'd be after a very accessible product?

[Leccyplanet]

Worth considering adding as integration to home assistant or similar. Already has gui, automatons, scripts, database, grafana. Plus loads of other integrations. Save a lot of work building on what's already there.

I already use Home Assistant for monitoring various household things and scooting them off to both influx and grafana. You're right, it has great support and importantly a large user / developer base.

But my concern about HA is the brains bit of the project. Correct me if i'm wrong, but I see HA only capable of simple if this time, do this. Like a basic scheduler?

Plus, the yaml knowledge to get entities, rules and dashboards up and running isn't really inviting to non-techies. Especially if we'd be after a very accessible product?

Its a good point about the yaml knowledge etc, however, the initial proposal of running on a Pi Zero or similar would require a certain level of technical expertise to get up and running. I wonder if its worth considering running it as an online service. Obvious issues with security etc, but reduces the technical side of things to almost zero and would save a huge amount of effort on supporting diy home environments.

[beaylott]

We have been doing a lot of work with Home Assistant and trying to use it in exactly the way you are talking about. Its great having the UI and it makes certain things automatic but it also can make doing some things really complicated and as soon as you stray off the beaten path and into developing new components or automations it starts to get tricky. A lot of the internal API you need to use is poorly documented and a bit of a moving target. Our integration for HA does some configuration and basic scheduling. This is sufficient for our purposes atm but I think if you want to do what you are talking about above it would make sense to separate it out. There is also nothing to stop this being integrated back into HA as a component if its made in the right way.

What we have been considering for our new project (which also includes the battery use case you outline above) is to keep Home Assistant for visualisations, limited control, user facing UI, and all the other nice stuff that HA builds in but move configuration, device interfacing, and other more complex functions (like scheduling) into a separate process. This would then talk to HA via the MQTT API (so there is an MQTT broker in the mix somewhere). We were provisionally calling this component the 'scheduler'. Based on your description it seems to match most of your requirements?

I would consider splitting the UI frontend into a separate component. Maybe something based on flask (I am assuming this is going to be in Python...)? It may also make sense to split any CLI in same way as well and write the core as a library?

[beaylott]

Also, HA is now a pretty heavy weight dependency. We have had to do quite a bit of management for it. Its light on resources when running but not a very well scoped or modular bit of software.

[robertosfield]

Can't comment on the implementation side at this point as it's just a interest about possible use of batteries in our household and being a open source guy peeked my interest. On the discussion front for my open source projects I currently use groups.google.com, it's free and works pretty well.