auto-register unknown charging stations? about steve

[goRaspy]

Hi,
I still didn't find time to play with steve 1.6 as I would like.
I did some quick test with a Schneider smart wallbox (1.6 JSON) and it seems to work like a charm.
Many thanks to the community and specially to you @goekay .

Convening the question, I think like you.
Auto register of charging stations could be very dangerous. I already succeeded a sort of DOS attack (hikari pool error) on steve 1.5 with many "abusive chargepoints" (https://github.com/chargegrid/abusive-charge-point). A first solution may be not to store in DB data sent by "not registered" charge points. Unfortunately it still may create a potential gate for attacks by "BootNotification" (maybe DOS or SQL injection).

But if it is an option, why not. We can imagine to run two steve in parallel and switch cs from "pool" to production server by OCPP "change configuration" (for charging stations which support it).

[V2G-UK]

I guess if it's an option with a warning in the docs, and NOT the default, then one shouldn't complain.

However here is an overview of how Plug&Charge is supposed to work:

https://pdfs.semanticscholar.org/2a46/10cab21e28bbeec8467712cf2e9218507c58.pdf

It's not as simple as a previously unregistered charging station issuing a boot notification!

The overhead needed for public charging can be reduced when it comes to private or semi-public charging. Each local environment, be it a private parking garage or a garage or parking lot of a company with its own EV feet, needs a unique so-called private operator root certificate. Each EVSE (wall-box or charging station) in this local environment will then be equipped with an SECC certificate which is signed by the private operator root certificate – previously created by the EVSE manufacturer – specifically created for this local environment. The respective EVs which are supposed to charge at this local environment need the private operator root certificate to be installed as well in order to check at TLS connection creation whether the SECC certificate is in fact derived from the private operator root certificate.

[csamsel]

I might be wrong, but ISO/IEC 15118 is still far away - It's also not in OCPP (yet), IIRC it's slated for 2.0

[goekay]

@V2G-UK i agree, this will be for sure an opt-in feature. regarding your other point: if in the near future PKI-based or certificate-based trust mechanisms are employed, then this feature becomes more important, because no-one with invalid certificate can communicate with steve anyways. in this case, the hurdle of manually registering charge points is unnecessary.

[V2G-UK]

Christian - My apologies for the somewhat off topic diversion, but nevertheless:

FYI I sit on the ISO/IEC committees that are standardising 15118 Ed. 2 and IEC 63110, the "successor" to OCPP 2.0 if you will. Should you guys wish to provide some input into the process you may want to take a look at this?

http://www.V2G.co.uk/2018/04/iec-63110-project-team-2-kicks-off/

Jim

[goekay]

(somewhat off-topic but since @goRaspy mentioned the issues with "abusive-charge-point"...)

@goRaspy steve should not cause any problems when testing with abusive-charge-point anymore (after aba72d0). the problem was a really special case due the impl of abusive-charge-point and is not likely to occur in production.

we tested it successfully on a 2013 macbook pro with a local mysql instance (and default hikari pool config as in the repo) using up to 100 stations each with 50 connectors while also reducing the message sending time interval from 3 to 1 seconds to produce more load.

[gabriel1lima]

Hi,
I still didn't find time to play with steve 1.6 as I would like.
I did some quick test with a Schneider smart wallbox (1.6 JSON) and it seems to work like a charm.
Many thanks to the community and specially to you @goekay .

@goRaspy
Could you describe your test with Schneider's Smart Wallbox (1.6 JSON) model? The company I work for is considering using Steve with this Schneider charger model. If you can, send me something in this email: [email protected]. Or if you prefer, speak right here. Thank you very much!