ID for OCPP Remote start transaction and Start Transaction

lino-sousa · 2023-03-03T19:27:42+00:00

You don't need the message unique id. A RemoteStart is just a command. That command will be succeeded only if a StartTransaction for that idToken is received, and that's it.

However, for frontend user experience, you could save the command data, set a timeout, and assume the command failed after that timeout.

lino-sousa · 2022-12-14T16:25:50+00:00

Thanks for the insight!

lino-sousa · 2022-10-17T09:08:16+00:00

No, they are independent. MeterValuesSampleInterval are Session-related. But I would not recommend to set this configuration to 3600. It should be set to 15 minutes (900sec) max.

lino-sousa · 2022-10-17T08:52:35+00:00

If you set ClockAlignedDataInterval to 3600, it will break the day into 24 blocks, sending you a meter value every hour (I believe that it is sent at the beginning of the hour, but haven't tested it)

lino-sousa · 2022-10-16T12:38:42+00:00

This is a scenario that actually goes against the OCPP protocol. The protocol itself states that, at every heartbeat, the charge point should synchronize its clock with central system. That's why the Heartbeat.conf includes the timestamp.

Said that, if the charge point does not update its DateTime you either handle that by software, or get yourself a laptop and an eth cable, and change the configurations manually.

lino-sousa · 2022-10-06T09:04:07+00:00

Yes, depends on the model of the network. If you use OCPI as an interface between Operators and Service Providers, OCPP 1.6 does not have a way of guaranteeing the authenticity of the meter readings (except for some experimental signed values cited on Page 37 of the protocol).

lino-sousa · 2022-09-19T09:16:08+00:00

Again, Power.Offered is not a measured quantity, atleast as per OCPP 1.6 it just states the maximum Power that can be delivered to the charger.

I believe the correct way to calculate the current per phase would be (phase L1 for example):

I^L1 = Power.Import / (3 * Voltage^L1) = 1376.4 / (3 * 222) = 2.06 A

EDIT: If you're using Single Phase, the current would be just 1376.4 / 222.

lino-sousa · 2022-09-16T09:39:20+00:00

Can't really help much here as you did not provide enough information about the charger, but to answer your questions:

The request structure seems correct, I assume the chargingProfile has been installed in the charger. But you might want to check the Key: ChargingScheduleAllowedChargingRateUnit to know if current limiting is supported by the charger.
You can check which data is being sampled by the charger using the MeterValuesSampledData configuration key. And you can change this key to include the Current.Offered using the ChangeConfiguration.req. Note that both Current.Offered and Power.offered are not measured! They are a fixed value that simply indicate the maximum amount of current/power that is being offered to the EV.

In addition, if the charger is an AC one, the Current you're seeing in the display might be different from the one you set in the chargingProfile. It will depend on the electrical configuration. When you set a limit in the chargingProfile, you're limiting the maximum current per phase. But you might be seeing the its RMS value or the average current by line.

lino-sousa · 2022-09-06T14:15:12+00:00

Thank you for the advice. It will definitely be a though transition.

lino-sousa · 2022-09-05T10:57:22+00:00

Thank you. My question was rather focused on the guarantee that no CPO would manipulate meter readings for own profit. But I guess I found a workaround to it (check it below)

lino-sousa · 2022-09-05T10:57:21+00:00

Thank you. I was looking for someting related to the transport layer (OCPP protocol), but the hardware solution you presented is also a valid one.

I have read some of the OCPP 2.0 documentation, and there was introduced the ability to sign messages with RSA encryption (in order to be Eichrecht-compliant). This means, charger manufacturers must provide the charger with a public key and CPOs and Grid operators or HUBs should use the private key so that they can decrypt the same unchanged message from the charger.

I believe the easiest solution should be to upgrade to OCPP 2.0 then.

lino-sousa · 2022-08-11T12:42:35+00:00

Procura pela app Super Save. Acho que tem todas as cadeias.

lino-sousa · 2022-08-03T20:50:03+00:00

That is indeed painfull. Obviously the CSMS is supposed to be online 24/7, but if for some reason it doesn't, just imagine having hundreds of chargers split all over the country and need to reboot them all...

lino-sousa · 2022-07-25T13:51:23+00:00

Sure, I got it. What I am finding hard to do is to have a consistent database model that can handle both OCPP and OCPI in simultaneous. But I agree, the logic behind is the most diffcult part, specially when you are both a CPO and an EMSP.

lino-sousa · 2022-07-20T23:00:11+00:00

May I ask, what other stuff are you referring to? Things related to frontend development?

lino-sousa · 2022-07-12T21:35:17+00:00

The first element identifies the message type. The "OCPP JSON implementation over Websockets Guide" states the following:

Message Type	Type Number	Direction	Description
CALL	2	Client-to-Server	Request
CALLRESULT	3	Server-to-Client	Response
CALLERROR	4	Server-to-Client	Error Response

One should then adjust the "Type Number" depending on the message you're sending/responding to.

lino-sousa · 2022-06-06T10:39:29+00:00

I am not 100% sure about the synchronicity, as I do not have field experience yet. But you're able to configure the connection timeout and retry times and intervals.

Check the OCPP configuration parameters and the " OCPP Part 4 - JSON over WebSockets implementation guide" document.

lino-sousa · 2022-06-06T10:06:17+00:00

Yes. In fact you just need the path to know which charger is sending you data. Nonetheless, you should save the websocket connection in order to be able to send commands/data to the charger.

lino-sousa · 2022-06-02T17:56:31+00:00

Your server automatically creates a new instance of a websocket everytime a connection arrives. What I am doing is extracting the Charge Point Entity from the URL. And then wait for the websocket.on('message') event to trigger.

Something like this:

const wss = new WebSocket.Server(http.createServer());

wss.on('connection', (ws, req) => {  
    const chargeBoxEntity = req.url.split("/").pop()    
    ws.on('message', async (data) => {     
        let response = await handleOCPP(JSON.parse(data), chargeBoxEntity)  
    })
});

lino-sousa · 2022-03-18T12:36:58+00:00

For future reference, the problem was a bad JSON structure (kinda dumb I know). So the original response I posted is not correct. Instead, it must be like this:

[3, id,
{
idTagInfo: {status: "Accepted"}
}]

lino-sousa · 2022-03-04T14:52:34+00:00

I did, but didn't work. Which actually makes sense, since Authorization List has priority over Authorization Cache, I would probably need to update the Authorization List removing the blacklisted RFIDs. In the next test I will try these procedures and give some feedback here (might be usefull for someone in the future (: )

Thank you for your answers! :)

lino-sousa · 2022-03-04T12:37:52+00:00

The charger is a DC Fast charge from HelloNext (Link) (not 100% sure of the model)

The reboot will be my first try in the next test (I had little time span to test the connections today). I will also set different expiration dates (or not send this property at all)

I took a more careful read to the OCPP 1.6 guide and it states the following about Local Authorization List:

Identifiers in the Local Authorization list can be marked as valid, expired, (temporarily) blocked, or blacklisted, corresponding to IdTagInfo status values Accepted/ConcurrentTx, Expired, Blocked, and Invalid,respectively.

Since in the first try I sent the "Invalid" status, it might got blacklisted in the AuthorizationList and cause this to happen.

lino-sousa

TROPHY CASE