Load manager use cases and accessing the web interface - sending charging commands to SteVe

[ashupani10]

Hi,

I have been trying to use the load manager with SteVe, however, I am stuck with some problems in accessing it (web interface) after building. Also, I have some questions. It would be very kind of you if you could help me with some of them.

1. What is the formal way to set up the database for LoadManager in MariaDB --> For now I have made another database ( similar to the setup process of SteVe) and the installation was successful.
2. How do I access the web interface? --> I have tried using localhost:9092 port but nothing is seen.
3. What are the functionalities of this Load Manager? --> Basically I want to send custom profiles to a chargepoint through SteVe in every 't' seconds depending on the load of the house and limit of the house. Would that be possible through Load manager?

Thanks in advance for your help.

Warm regards,

Ashutosh

[chuck-h]

Hi Ashutosh,

First off, as the author of LoadManager, I would recommend you don't bother trying to use it or its database model. It is a project I barely started and is not at all functional.

Secondly, I believe that the branch of SteVe in this repository will do what you want. I implemented this a few years back (https://github.com/chuck-h/steve/issues/4#issuecomment-443600375) and did limited testing with my Delta AC Mini OCPP charging station. You simply post an http message to the Steve web interface port, and the charging current limit is adjusted.

In the example below Steve is running at 192.168.1.133:9090 and the message is http://192.168.1.133:9090/steve/currentlimit/post?node=Delta01-C1&fulljson={"amp":12} . The http response is just diagnostics.

I am still running the version from this repository and have not pulled any updates from upstream. You may be able to copy the 4498e88 change to Steve, which supports this behavior, and merge with the current release of SteVe at https://github.com/RWTH-i5-IDSG/steve, YMMV.

This type of dynamic current control is essential to effective EVEMS as described, for example in https://www.csagroup.org/wp-content/uploads/CSA-RR_ElectricVehicle_WebRes.pdf If there is a genuine need for this in a SteVe context, Sevket might be willing to accept a pull request with this function to the main distribution. Depending on the use case it is likely that some kind of authentication would be needed on current-change commands.

@goekay

[ashupani10]

Hi @chuck-h,

Thank you very much for the answer. It works!

Just one more thing, have also implemented the getCompositeSchedule command in a similar fashion? And I found that charging commands are piling up in the database, Is there a way to delete the previous commands sent? I will also try to implement them myself if they are not already present, otherwise if its already there, it will be very useful.

Yes, I also feel the same regarding the implementation of this use case in SteVe. This is a very common use case and most of the commercial OCPP compliant charging management systems implement this to a certain degree.

Thank you for your continual support.

Warm regards,

Ashutosh

[chuck-h]

Hello Ashutosh,

The charging profiles can be manually deleted from the web interface steve/manager/chargingProfiles, but there is no feature to automatically garbage-collect them after use.

Here are a few alternatives I have thought of:

1. Add code which executes when a new current-limit message is received. It would search the database for old TxDefault profiles in the database that apply to this charge station and connector. If old profiles exist, either 1a. delete all old profiles, then generate a new profile (following existing code path), or 1b. re-use an old profile, updating the current limit value
2. Fill in the validTo field (existing code leaves it NULL) for each generated profile. Create a separate scheduled task (profile garbage collector) which periodically inspects the database and deletes profiles which have passed their validTo times.

Your inquiry has kick-started me into thinking about this project again. Are you interested in cooperating on moving it forward? What are your personal goals with it?

See my recent comment at #5

Chuck

[ashupani10]

Hi @chuck-h,

Thank you for your prompt answer. I really like the ideas and I think they will be worthwhile to give a shot.

To answer your last question first, I am a master's student in the field of energy science. To be honest, I am fairly new to the world of IoT and EV charging protocols but, I am very interested in energy systems optimization and modeling topics especially Home Energy Management Systems (HEMS). I believe that home EV charging is a major part of it today.

Being new to this field also means that I am fairly amateur in server-client-based coding, communication protocols, interfaces, and APIs. However, I am very eager to learn them. For now, I have experience in python but mostly from the point of view of data analytics and optimization, ( as mentioned earlier, I am a beginner when it comes to this side of python). So as for the question of cooperation, yes I am interested to move it forward. But I feel that I will play the role of a learner for most of the initial days before I can start making real contributions code-wise. It will be a nice wholesome experience for me to gather depth in these topics. Not only that it will be a nice side project to work on alongside you and your guidance. Looking forward.

Cheers,

Ashutosh

[chuck-h]

@ashupani10 wrote " I have experience in python but mostly from the point of view of data analytics and optimization".

I was considering whether the general problem of setting currents in N charge stations to meet max current ratings in M feeder circuits while optimizing vehicles' charge state at some future time would be a linear-programming task. What do you think? Is this something you could think through and code?

It may be too early to implement a general case, but maybe not!

[ashupani10]

Hi @chuck-h,

So as far as I understand, this is a scheduling problem with N EVSE (charge points) and M Feeder circuits. And the target is to maximize the SoC of all the vehicles connected while maintaining the constraint of current limit and duration of charging. Am I right?

Yes. This would be something I would be interested in doing.

Cheers,

Ashutosh

[chuck-h]

@ashupani10 That would be great to have you working on the scheduling problem! @followthebeast had some thoughts in a comment on #5 also.

You described the goal well. Some localities have "time of use" rates; there may be a power cost optimization. Also there is an idea of "fairness" along the lines that if there isn't enough power available to give everyone a full charge, at least everyone should get a fair share.

Depending on the use case we typically won't know as much as we would like about state-of-charge and vehicle departure time.

My specific use case is residential overnight charging with each station dedicated to a specific user. Therefore we can know what kind of car and what the user's typical daily schedule is. We don't have time-of-use rates here (Seattle, WA USA).