-
Notifications
You must be signed in to change notification settings - Fork 32
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
EvseMode: Car closes the connection after AppProtocolResponse #9
Comments
Progress Note:
Next step: adapt the fsmEvse, to run through the list of supported protocols, select the DIN, and respond with the assigned SchemaID. |
Pushed the fix of fsmEvse. In best case, this should be the solution for the issue.
When running with the iX3, this should look like
and for the Tesla
|
Did the steps, but when wanting to start the service (I use these parameters: https://github.com/ArendJanKramer/SmartEVSE-3/blob/modem_docs/manual/Modem.md)
Also tried to install can |
This sounds like chademo is enabled in the ini file. Just replace it with "none". |
Ok cool, looks like we are on the right track :-). Only the energycapacity should be around 74 kWh netto or 80 kWh bruto.
Second try without unplugging the car, just switching SmartEVSE to off and then back to Smart to re-initiate the modem procedure.
Third try after unplugging the car and re-plugging it:
|
Great, so I close this issue. |
Start of the discussion was here: #6 (comment)
Cross references:
SmartEVSE/SmartEVSE-3#25
SmartEVSE/SmartEVSE-3#25 (comment)
Problem description: After successful SLAC, SDP and protocol handshake, the car closes the TCP connection. This happens stable with the BMW iX3. No problem with Tesla and Hyundai Ioniq.
Root cause: The openV2Gx sets the supportedAppProtocolRes.SchemaID = 1, because we assume, that the car sends a list of supported schemas where the first enty is DIN and has SchemaID 1. The iX3 sends the (one-and-only) DIN schema entry with SchemaID = 0 (which is allowed), and closes the connection after the pyPlc selects the SchemaID 1.
Clean solution would be, that the pyPlc parses the list of announced schemas, selects the entry with DIN, and sends back the SchemaID of that entry back to the car, no matter which value it is.
Potential workaround could be, to send no SchemaID at all. The SchemaID is an optional field, and in best case the vehicle is also happy without it. There is the risk, that some car types will accept this, maybe others not.
The text was updated successfully, but these errors were encountered: