-
-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
auto-register unknown charging stations? #55
Comments
Hi, Convening the question, I think like you. 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). |
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!
|
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 |
@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. |
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 |
(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. |
@goRaspy |
off-topic but it is being discussed in ChargeTimeEU/Java-OCA-OCPP#37
i can see the value of such feature, but it is highly dangerous to accept/register unknown stations. therefore, i was thinking maybe to add a new flag to the main.properties and the user of steve can make the decision and steve can act accordingly. but first i want to collect opinions from the community. @victormunoz @V2G-UK what do you think?
The text was updated successfully, but these errors were encountered: