Clarify central system configuration with /path suffix

[andig]

I've not looked at the spec, but running CP against CS, both using this lib, I'm confused why the CS URI is suffixed with the CP ID in https://github.com/lorenzodonini/ocpp-go/blob/master/ocppj/client.go#L83. Shouldn't the CP connect to the CS URI as given?

Note: with the code as given the connection attempt from the CP ends up with:

 websocket: bad handshake, http status: 404 Not Found

[utsavanand2]

Hi @andig! Did you initialize the URL as

const centralSystemURL = "ws://<ip>:<port>/my_charging_station_id"
err := chargePoint.Start(centralSystemURL)

?

Actually you don't have to add the CP ID as the suffix to the CS URL if you're using this client library. You can just use

const centralSystemURL = "ws://<ip>:<port>"
const chargePointID = "my_charging_station_id"
chargePoint := ocpp16.NewChargePoint(chargePointID, nil, nil)
err := chargePoint.Start(centralSystemURL)

Ofcourse this is an oversimplification of the other boilerplate you have to add but this is kind of the gist of the exact problem you're having. The above works for me. Let me know if I misunderstood the issue you're having.

[andig]

Did you see the link to client.go above? Why does the code append the chargepoint id when connecting to the CS?

[andig]

Think I got it. The chargepoint id is appended as last url segment. I was expecting the it to be transported as part of the messages which doesn't seem to be the case.

[andig]

Problem is still there. Then you start the CS using

"ws://<ip>:<port>/path"

Then clients will fail connecting to the same uri:

panic: websocket: bad handshake, http status: 404 Not Found

It seems that the mux router that is part of the server does not handle the path segment correctly?

[utsavanand2]

Yes exactly, if you look at the official OCPP spec it does state to append the charging station ID at the end of the URL as it does in here https://github.com/lorenzodonini/ocpp-go/blob/master/ocppj/client.go#L83

[utsavanand2]

Problem is still there. Then you start the CS using

"ws://<ip>:<port>/path"

Then clients will fail connecting to the same uri:

panic: websocket: bad handshake, http status: 404 Not Found

It seems that the mux router that is part of the server does not handle the path segment correctly?

I believe we do not add the URL as such with this library because it adds that cs ID suffix for us in client.go Did you check out my example? here. If it still doesn't work can you please share your code snippet?

[andig]

Looking more through the example folder I see:

centralSystem.Start(listenPort, "/{ws}")

What is the meaning of the /{ws} suffix? Seems if I change that to a different value, the handshake problems come up. Seems @utsavanand2 is not using this suffix?

[andig]

To reproduce, change https://github.com/lorenzodonini/ocpp-go/blob/master/example/1.6/cs/central_system_sim.go like this to make the listenPath configurable:

// Run central system
listenPath, ok := os.LookupEnv("SERVER_LISTEN_PATH")
if !ok {
    listenPath = "/{ws}"
}
log.Infof("starting central system on port %v and path %v", listenPort, listenPath)
centralSystem.Start(listenPort, listenPath)
log.Info("stopped central system")

Then run the example CS and example CP like this with a custom /ocpp suffix:

SERVER_LISTEN_PATH=/ocpp go run github.com/lorenzodonini/ocpp-go/example/1.6/cs/
INFO[2021-09-13T09:24:49+02:00] no valid SERVER_LISTEN_PORT environment variable found, using default port
INFO[2021-09-13T09:24:49+02:00] starting central system on port 8887 and path /ocpp

CLIENT_ID=foo CENTRAL_SYSTEM_URL=ws://localhost:8887/ocpp go run github.com/lorenzodonini/ocpp-go/example/1.6/cp
ERRO[2021-09-13T09:24:58+02:00] websocket: bad handshake, http status: 404 Not Found

If the /{ws} is a required magic value, it should be documented.

[andig]

@lorenzodonini could you kindly clarify the meaning of the listenPath parameter in

centralSystem.Start(listenPort, listenPath)

Is "/{ws}" as used in the examples a magic value?

[lorenzodonini]

It's not a magic value. It uses the underlying gorilla mux router to register a dynamic HTTP handler route. You could use somePath/{chargePointID} in there instead, but you need to have a {something} block at the end your listen path to register your server for any client.

The protocol specifies that the client ID must be appended to the URL to uniquely identify the charge point, like ws://centralsystem.example.com/ocpp/CP001 (no, it's not passed inside a dedicated handshake/message).

I will improve the documentation (although this specific feature comes from a different library).

[andig]

Thank you so much. Although having worked with Gorilla before I wasn‘t aware of this aspect!