Setting charge profile - amperage of evse unit....

[retrocoder-78]

Hello!

I am playing around with charge profiles and see that SteVe has an area implemented to do so. I guess my biggest question is what would be a default entry of information to set a 32 amp evse to say 15 amps? This will change the pilot signal frequency that the evse is giving to a vehicle.

I have done some searching but have not come up with a explanation of setting these variables in a fairly simple way in regards to sending the evse a new charge profile....

Or, what would be the process for seeing what charge profile is currently loaded on a factory set evse to then change the few parameters to lower the power output?

Any advice or a point in the right direction would be much appreciated!

Thanks!

[retrocoder-78]

Okay, so I have been trying to do some understanding how the implementation works in simple terms. I contacted an esve oem asking if their unit ships with a default charging profile. And, the answer is no. Which makes sense since when I ask for the composite schedule via SteVe to my evse I get nothing back. I was hoping for a yes from the oem so I could look inside the file to get familiar with a working implementation....

For example, you want to set your esve exactly how it currently works (default from the oem), but, you want to dial back the amperage to half it's current capacity because you are plugging it into a circuit that matches that reduced capacity. So, here's the user case, this is what the setting of that charge profile would look like in this case. Or, put simply, here's the information you would enter into SteVe and send over to your evse to test....I have not come across example user cases and example settings if that makes sense.....Maybe this post can be that!

Doing some googling on the topic there is some explanation from ampcontrol.io. Now, they are explaining how it works (charge profiles) to sell their service. Which I get and really appreciate the explanation they give. But, in all honesty, I want to understand how to control the charge profile in simple terms independently of any services. Which is the whole idea behind OCPP, not being having to be tied to an entity to control your evse.

https://www.ampcontrol.io/post/how-to-send-ev-charging-profiles-to-your-open-charge-point-protocol-ocpp-charging-station

So, at this point, given that the evse I am working with is charge profile clear, I am going to start playing with sending profiles and seeing what the result is. In any case, since clear charging profile has been implemented in SteVe, if I am not happy with the setting, I can just clear those and the evse should be returned to the manufactures default.

Feel free if anyone reading has a SetChargingProfile.req and some user cases attached to such, I would love to read the inside.....Hopefully after some testing I will post user cases and some test settings that match those and the evse I am working with.

Thanks!

[csamsel]

When developing SteVe we never got to actually test this or play around with it due to not having access to a charging station supporting it. Any insight would be welcome.

[goekay]

@retrocoder-78 please look into the charging profile parts of the ocpp spec. the use cases, definitions and explanations are broad and detailed, and hopefully leave very little room to interpretation. i hope they help you.

[retrocoder-78]

Thanks for the comments @csamsel @goekay. I will take a look at the user cases soon. Thank you for that information! I have done some preliminary testing with SteVe and the evse I have and charge profile commands are being sent and received successfully. But, the evse is not following commands to reduce the power output. This looks to be a evse issue.

I was provided new firmware for the evse and loaded that via the evse's oem interface. And, when I request GetCompositeSchedule it does return it's current power output. Which before it would return no information. So, a step in the correct direction on the evse side.

I have involved the evse oem to see why their unit is not reducing the power when requested to. I can see clearly now that their are two parts to the ocpp protocol at play. The implementation of the back end as is what SteVe is, and the the implementation on the evse. Both are important!

Thank you both for your time. I will continue to update as this plays out. SteVe has made this testing possible. Thank you to you both and the team for an impressive piece of software! 😊

[goekay]

nice, please keep in mind that setting charging profiles on a transaction level is not possible with the current implementation: https://github.com/RWTH-i5-IDSG/steve/issues/367#issuecomment-656274936

[retrocoder-78]

Good information. Thank you! At this point my testing is specific to CharePointMaxProfile. I am measuring the change on the J1772 pilot pin duty cycle with test equipment to watch the change in the evse's max power setting. So, this should all be possible based on the functionality currently available in SteVe.

[retrocoder-78]

For those possibly following or keeping track of, sorry for the lag in an update. I have been testing several evse's on the market and their ocpp implementation most definitely varies from unit to unit, manufacturer to manufacturer. While I am still in the process of waiting on test equipment to show the changes in duty cycle on the pilot pin of the J1772 connector, what I found so far is the ChargePointMaxProfile only registers on Connector id 0. So, if you want to send a charge profile to a unit specifying ChargePointMaxProfile, it's under the connector id of 0. When I register a charge point in SteVe they all come up as a connector id of 1. This is a bit of me learning about ocpp and the SteVe implementation. So, I was able to successfully send a charge profile to a evse by setting a profile TxDefaultProfile which allows setting to connector id of 1. Worked like a charm. My only goal at this point lacking test equipment was to test by plugging in an electric vehicle, could the evse be 'turned down' from it's maximum default setting using SteVe. And, the answer is totally yes. I went further to start and stop transactions by adding tags but I am going to save that testing for another post. But, the transaction portion worked and worked well.

So, I'll be back to this thread to show some more testing but, the take away, if one would like to turn down a charge point (half amperage for example a 32 amp evse operating at 16 amps) using SteVe, when you create a charge point, they are a connector id of 1. When creating a charging profile settings that worked for my purposes:

Charging Profile Purpose: TxDefaultProfile Charging Profile Kind: RECURRING Recurrency Kind: DAILY Duration (in seconds): 86400 Charging Rate Unit: (Pick A or W)

Start Period (in sec) = 0, Power Limit (in amperes) = 16, Number Phases = 1

SteVe is amazing software and well thought out. I am really glad to be able to be learning about ocpp and having SteVe to do that has been very enjoyable so far! So, huge thanks to the SteVe team and all involved.

:)

[chuck-h]

See also #552

[retrocoder-78]

Hello all!

Again, I apologize for the time between updates. I have done some more extensive testing (having some access to more testing equipment) and having found that once a charge profile is sent to a evse, and begins a charge session, that evse is locked to that profile. So, if you wanted to send a new profile during that session, the evse does not adjust until the session is stopped, and a new session started.

I have verified this with live evse's and vehicles. And, also test equipment watching the change in the duty cycle on the control pilot pin.

I am going to test further (a wider selection of evse's) and I'll report back any results I find.

:)

[chuck-h]

Looks like @retrocoder-78 is seeing several noncompliant EVSE. OCPP doc 5.16.3 is crystal clear.

[retrocoder-78]

@chuck-h Oh, absolutely. And what's interesting, while many of the oem's say, OCPP 1.6J, they are not on the OCPP approved list. Because of what you mention, how they have implemented OCPP, wouldn't pass an audit. And, what I am finding in the industry, rather than follow OCPP, it's a bit of a wild west of following the standard and not.

I am going to keep testing though! I find the results quite interesting. :)

[scobin3]

Hi @retrocoder-78, As @chuck-h pointed out, on OCPP doc 5.16.3., you MUST send a "TxProfile" to change the setting when a transaction is alive. Otherwise, you have to wait until the transaction is done to change the "TxDefaultProfile". But SteVe is lacking a parameter ("Transaction ID", to be specific) to set the TxProfile. See this: [https://github.com/RWTH-i5-IDSG/steve/issues/367] I've been trying with EV and EVSE for a while, hoping SteVe can add the Transaction ID for TxProfile in the future :) Thank you, SteVe Team!

[chuck-h]

Or you can use a sledgehammer and delete any other profiles from the EVSE first: https://github.com/chuck-h/steve/commit/4498e88

[retrocoder-78]

Great information! What I have seen is a TxDefaultProfile can be sent, but the specific hardware must react following OCPP protocols.

The hardware I have tested doesn't react. So, to implement any form of reaction to 2 charge boxid's being grouped together, the transaction needs to be stopped. Charge profile loaded. Transaction started again with new profile. This is the limitation of TxDefaultProfile.

Yes, the SteVe team is amazing. Hands down! Have learned so much regarding OCPP and it's implementation via SteVe!

Quite possibly what you mention, could this be a feature request? It would simplify to some degree implementation of that general use case of two charge boxid's sharing a single circuit.

On Wed, 2 Feb 2022, 11:36 am scobin3, @.***> wrote:

Hi @retrocoder-78 https://github.com/retrocoder-78, As @chuck-h https://github.com/chuck-h pointed out, on OCPP doc 5.16.3., you MUST send a "TxProfile" to change the setting when a transaction is alive. Otherwise, you have to wait until the transaction is done to change the "TxDefaultProfile". But SteVe is lacking a parameter ("Transaction ID", to be specific) to set the TxProfile. See this: [https://github.com//issues/367 https://github.com/RWTH-i5-IDSG/steve/issues/367] I've been trying with EV and EVSE for a while, hoping SteVe can add the Transaction ID for TxProfile in the future :) Thank you, SteVe Team!

— Reply to this email directly, view it on GitHub https://github.com/RWTH-i5-IDSG/steve/issues/462#issuecomment-1028289471, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQLQX5KYVHHX3STTEPGHRZLUZGBT3ANCNFSM4UT6SLFA . You are receiving this because you were mentioned.Message ID: @.***>

[retrocoder-78]

Any profile loaded as long as it's on the same stack level overwrites the last profile. That's my experience working with the hardware that's available and the TxDefaultProfile. Clearing all the profiles loaded is an easy way to start with a clean slate. But, beyond that, it's now adjusting based on those two boxid's I have described and their current status notification to ensure the circuit they exist on is not tripped.

Having said that. Just clearing all the profiles before starting a new session is one way to ensure it's only what your loading is going to have an effect on the current transaction.

On Wed, Feb 2, 2022 at 11:47 AM chuck-h @.***> wrote:

Or you can use a sledgehammer and delete any other profiles from the EVSE first: @.*** https://github.com/chuck-h/steve/commit/4498e88

— Reply to this email directly, view it on GitHub https://github.com/RWTH-i5-IDSG/steve/issues/462#issuecomment-1028298163, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQLQX5KVZYKLVB4ULTQKM3TUZGC5NANCNFSM4UT6SLFA . You are receiving this because you were mentioned.Message ID: @.***>

[justarandomnerd]

Hi @retrocoder-78 Thank you for keeping everything updated. I am trying to run a few tests and I had a question. What equipment did you use to measure the duty cycle on pilot pin of the J1772? And also is there any way to know what charging profile is being used in an active transaction?

[Anmirazik]

hi @retrocoder-78 , is there any way i can contact you ? I also would like to test the smart charging implementations using steve , maybe we can communicate thru email or something for implementing something more advanced, u can contact me thru annasdzikrullah321@gmail.com

i would like to say thank you for making this thread , i also have successfully send set charging profile commands from steve to the simulated charger based on everest . Just some basic implementations btw , really appreciate it @retrocoder-78