It was not working with multiple charger at the same time . Do you have any idea or details we want to setup multiple charger and also load testing along with it about ocpp.core HOT 7 CLOSED

Hi,

I'm not sure if I understand your scenario correctly.

We tested OCPP.Core with multiple connections (=simulators)- but only with a limited number. It is not designed for a scenario with multiple servers because the server keeps a local state. With the OCPP-J Profile all chargers keep their connections open and it makes more sense to distribute the chargers on different servers by configuration. A load balancing will be hard to implement.

Your second question is the dynamic power management for the chargers That is a difficult scenario with OCPP! The server has no active part in this and only receives measurent values in certain (slow) intervals. In most cases this will be far to slow to dynamically control the charge rates.

What would be possible is a semi dynamic scenario: The server knows how many chargers have EVs connected and can set limits to evenly distribute the available power. But this does not take into account how fast the EVs are really charging,

Example:

• available Power: 22kW
• 3 chargers with 22kW max
  => With 1 connected EVs the charger gets full 22kW and the others are limited to 0.
  => With 2 connected EVs both these chargers get a 11kW limit.
  => With 3 connected EVs all 3 chargers get a 7.3kW limit.

from ocpp.core.

@dallmann-consulting My Major question is to test with multiple chargers not servers, We want to setup multiple chargers across and want to scale those chargers , currently the remote start and stop and connection is the issue when setting up the WS or WSS to connect to a charger accordingly . You suggested you have already tested with multiple chargers with KEPA chargebox . Kindly help on this did you face any issue

from ocpp.core.

My comment on multiple servers was only to explain the scenario. You probably can't scale OCPP-J like a regular web application.
As I said, we have tested the server with a handful of parallel simulators and that works. But we haven't implemented the RemoteStart /-Stop messages. So I can't comment on that.
What exactly are you doing and what is the problem? Also how are you runnung OCPP.Core? Maybe there is a limitation.

from ocpp.core.

I am connecting to multiple live chargers , but I am not able to start and stop them , since you had suggested you had connected to 5 live charger , how did you test them , how did you start and stop the charger and how the log was checked ?

from ocpp.core.

As I said - there shouldn't be a problem with multiple chargers. This open source version of OCPP.Core was intended for private use. You don't need to start or stop your charger remotely at home. That's why I didn't implement the RemoteStart / -Stop messages so far.
You usually present an RFID token to your charger and that sends a StartTransaction request to the server.
Your scenario sounds like you want to start/stop the charger remotely but you didn't give any details. I cannot help you without further details.

from ocpp.core.

@dallmann-consulting What is happening currently is that when I connected the charger , and when the charger is been stopped it is still showing running when it is been disconnected completely and in the log also show NULL , it didn't receive any error from the charger. If you see the dashboard it still running where the charger is already disconnected . Also specific tag how do I setup for remote start and stop charging with user ID. Need some help

from ocpp.core.

The server needs to rely on messages from the charger. It cannot query a status from the charger.
When the charger wants to start charging it needs to send a "StartTranscation" message. The server checks the (RFID-)token and creates a "Transaction" entry in the database. But this transaction is still active so all "Stop..." values are empty. The UI can only rely on that status and display a red tile.
When the charger wants to stop the charging process it sends a "StopTransaction" message and the server writes the "Stop..." values into the database. If that message is missing the UI keeps showing a red tile. When network connectivity is temporarily interupted the chargers are supposed to store the messages and send them later in the correct order. So the charger needs to send the stop-message!

In the message log you should filter the MeterValues und HeartBeats - these are useless at the moment. You need to find the Start-/StopTransaction messages. Try to find these in the dump directory and the response from the server.
Your open transaction in the database doesn't show a token. Maybe the server denies the stop request and therefore the transaction stays open?
=> find the start/stop messages (dump dir) and the corresponding responses and post them here.

from ocpp.core.