Feature/evse postponed charing

[alexbelkedev]

This PR currently implements only a basic deferred charging approach based on a user-defined start time. It does not yet implement deadline-based smart charging with optimization for low-price time slots.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

❗ There is a different number of reports uploaded between BASE (ca6d6c5) and HEAD (0d89287). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (ca6d6c5)	HEAD (0d89287)
java	1	0

Additional details and impacted files

@@              Coverage Diff               @@
##             develop    #3641       +/-   ##
==============================================
- Coverage      58.56%   15.52%   -43.04%     
==============================================
  Files           3095      294     -2801     
  Lines         134205     8497   -125708     
  Branches        9870     1443     -8427     
==============================================
- Hits           78586     1318    -77268     
+ Misses         52695     7137    -45558     
+ Partials        2924       42     -2882     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[janklostermann]

Hi Alex Belke, could you please write in the description of the pull request, what you are intending to achieve and how (also from a users perspective)?
That would be cool, as I am wondering, if (and how much) my ideas overlap or are worth an independent PR.

[sfeilmeier]

Hi Alex Belke, could you please write in the description of the pull request, what you are intending to achieve and how (also from a users perspective)? That would be cool, as I am wondering, if (and how much) my ideas overlap or are worth an independent PR.

@janklostermann During OpenEMS Hackathon at KIT we discussed EVSE "Smart" tasks. This was a first (vibe) coding approach to implement this feature. EVSE currently supports two variants of Tasks in its JSCalendar property: Manual and Smart.

"Manual" tasks allow defining a Mode in certain periods of the day - e.g. FORCE_CHARGE from 2 to 4 am when prices are cheap.

"Smart" tasks will allow to define constraint that leaves space for the optimizer. E.g. "The EV has to be charged with at least 15 kWh till 7a.m. for my daily commute".

Does this match with your ideas? Maybe we should continue discussion about use-cases in OpenEMS Community?

[janklostermann]

@sfeilmeier That sound like a great idea.

In my fantasy it could lead to a collaborative behavior driven development, where we can jointly understand different use-cases, detail them out and specify what each one is about, and what not. Define the (acceptance) tests that show that an implementation does the trick, and serve as documentation as well. And then implement to satisfy these tests.

But let's start small and simply talk about our use-cases. Let's sharpen them and then spread them out into separate forum threads to detail them out.
What do you think?

Do you want to start the initial thread? (Referencing your activities and results from the hackathon (that I unfortunately missed completely)?)

[alexbelkedev]

@janklostermann Thanks for the feedback and the questions.

This PR is only a first prototype from the OpenEMS hackathon at KIT. My intention here was to try a simple postponed charging approach for EVSE:
the user defines a start time, and charging starts at that time.

After discussing it again with the other participants, it became clear that the intended target use-case was actually different:
a smarter charging task where the user defines a deadline / target, and the system finds a suitable charging window, e.g. based on low energy prices.

So this PR does not yet implement that full “smart” behavior. At the moment it is more a technical draft / spike to explore one possible direction.

I also agree that it would be very useful to first collect and sharpen the use-cases in the OpenEMS Community, and then derive clearer acceptance criteria from them. I’d be happy to continue the discussion in a dedicated thread.

[janklostermann]

@alexbelkedev The smarter solutions always are attractive. But not always suitable. Especially if the data needed for them to be smart is not available.
There might be use-cases where such a simple time-bound case and maybe a way to connect more of such simple controllers through a configurable logic together might be the thing needed. (I think of e.g. channelSingleThreshold as another one.)
I haven't seen a forum thread on such a simple combining logic and potential controller elements to be connected by this logic yet. This timer control you proposed here could be one of these.) . So that could become a sub-thread of the above mentioned discussion...