{"action":"created","issue":{"url":"https://api.github.com/repos/ocpi/ocpi/issues/34","labels_url":"https://api.github.com/repos/ocpi/ocpi/issues/34/labels{/name}","comments_url":"https://api.github.com/repos/ocpi/ocpi/issues/34/comments","events_url":"https://api.github.com/repos/ocpi/ocpi/issues/34/events","html_url":"https://github.com/ocpi/ocpi/issues/34","id":95657744,"number":34,"title":"Notes OCPI workshop #9","user":{"login":"cristinarc","id":12528571,"avatar_url":"https://avatars.githubusercontent.com/u/12528571?v=3","gravatar_id":"","url":"https://api.github.com/users/cristinarc","html_url":"https://github.com/cristinarc","followers_url":"https://api.github.com/users/cristinarc/followers","following_url":"https://api.github.com/users/cristinarc/following{/other_user}","gists_url":"https://api.github.com/users/cristinarc/gists{/gist_id}","starred_url":"https://api.github.com/users/cristinarc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cristinarc/subscriptions","organizations_url":"https://api.github.com/users/cristinarc/orgs","repos_url":"https://api.github.com/users/cristinarc/repos","events_url":"https://api.github.com/users/cristinarc/events{/privacy}","received_events_url":"https://api.github.com/users/cristinarc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-07-17T13:38:02Z","updated_at":"2015-07-27T08:34:06Z","closed_at":null,"body":"1. Introduction chapter:\r\nRutger will add the information to this chapter. It should explain what the protocol is used for. He will work on it in about 3-4 weeks.\r\n2. Types chapter:\r\nCreate it. Simon Schilling will restructure the chapters as soon as we have the document we are going to use for the implementation of the 1st release ready.\r\n3.  PowerType enum:\r\nIs going to be updated to use the OCHP format, RatingsType (should be renamed cause the name is not intuitive for us) and we can add more details just in case there’s some cases for which the eMSP wants more details, like e.g. how many phases connector has and the details of each of them. I couldn’t catch the exact conclusions on this, so feel free to clarify it a bit more.\r\n4. Capabilities enum:\r\nIt will be extended later, at this moment the ones are defined are the ones we can think of. In case we thing about another one just add it. It’s required to add a description to the capabilities to explain how two parties could agree on how to add new capabilities (see next point).\r\n5. How to extend the protocol?:\r\nAdd a new chapter about “Extensibility of the protocol”. This is important in the fact that there’s some Enums where people will want to use new field values and we need to discourage them of adding them. It should explain that the parties which want to use it, will implement it unofficially and create an issue that will be reviewed to see if it can be useful for more parties and therefore added to the specs. Leon will do it after 2 weeks more or less.\r\n6. EVSE-ID format:\r\nAdd the description of the EVSE-ID format, as an advice, not forcing them, since in case there is a change like e.g. changing the name of the company they would need to change the id they have provided, but it could also help them to implement other protocols like OCHP, which demand this format.\r\n7. Suboperator of the location object:\r\nAs it is a bit difficult to understand what it should be used for we need to make it more clear. In order to make it understandable we will add an image in the introduction with the parties can appear: MSP, subMSP, CPO, subCPO; and also add a proper explanation in the corresponding chapter where the field appears. The sub operator at the end is the same company but with a different name (e.g. the company could have different branding on top of the ‘plattform’), like having a different site for a group of Cps but anyways their ids are unique (example taken from EV-BOX). For this scenario example the company should not use the operator field to define this separation, adding this option we discourage companies of reusing it for those cases.\r\nAs there’s different scenarios, add some examples for some different scenarios to make it intuitive.\r\n8. Physical number of the location object:\r\nWill be renamed to visual_number and will turn into an object with 2 parts: sequence number, which will be an integer to order the different visual numbers and the actual visual number that will be a string so the operator has more freedom (didn’t decide about the name about this field yet).\r\n9. DisplayText:\r\nWill be used for all the cases for which we currently are using String and is a text that can or will be displayed to the driver, so it can be translatable (important for countries like Belgium or Finland). Specifically we discussed the fields directions, address, city and name for the location.\r\n10. Skipping:\r\nFor now the fact that a location can have more than one entrance, it can be rethought in a later stage, so we don’t add too much complexity for the 1st release."},"comment":{"url":"https://api.github.com/repos/ocpi/ocpi/issues/comments/125126641","html_url":"https://github.com/ocpi/ocpi/issues/34#issuecomment-125126641","issue_url":"https://api.github.com/repos/ocpi/ocpi/issues/34","id":125126641,"user":{"login":"simonphilips","id":3263809,"avatar_url":"https://avatars.githubusercontent.com/u/3263809?v=3","gravatar_id":"","url":"https://api.github.com/users/simonphilips","html_url":"https://github.com/simonphilips","followers_url":"https://api.github.com/users/simonphilips/followers","following_url":"https://api.github.com/users/simonphilips/following{/other_user}","gists_url":"https://api.github.com/users/simonphilips/gists{/gist_id}","starred_url":"https://api.github.com/users/simonphilips/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/simonphilips/subscriptions","organizations_url":"https://api.github.com/users/simonphilips/orgs","repos_url":"https://api.github.com/users/simonphilips/repos","events_url":"https://api.github.com/users/simonphilips/events{/privacy}","received_events_url":"https://api.github.com/users/simonphilips/received_events","type":"User","site_admin":false},"created_at":"2015-07-27T08:34:06Z","updated_at":"2015-07-27T08:34:06Z","body":"No this is fine for me. I'm still not sure how we can solve the weird 3x230V power nets but it should not come at the cost of complicating the rest of the specification. OCPP2.0 solves it by allowing a vector with a voltage per phase but that seems quite complicated from an eMSP point of view.\r\n\r\nI suggest we keep a line-to-neutral voltage approach for now, even when there is no neutral (like in the 3x230V). I'll use the ground in such cases. For some cars (Tesla) this is still insufficient information to know if they can charge or not, but most of the 3x230V nets are domestic so they're not very likely to be used for roaming. Let's get a working implementation first and find a solution for this problem later."}}