Stuck at step with testing exiConnector.py #6
Comments
|
Hi, regarding the exiConnector: Yes, this is a confusing error, which is in fact no error. I just pushed an improvement. Regarding the closed connection, it is unclear which side closes the TCP connection, and why. Is it possible to create a network log with wireshark or tcpdump? |
|
Jup, exiConnector.py works now :) |
|
No, in EvseMode there is no script / service, which would run in background and do the logging. (This is in contrast to the PevMode, where we have the starter.sh, which starts the tcpdump and the pevNoGui script.) |
|
I think I have something, hopefully it makes senses to you. I put the PWM 2 times to 5% for about 1 min. And some more |
|
The tracing worked perfectly. The traces show multiple times the issue with the broken connection, and the situation is always the same: After the TCP connection is correctly established, the iX3 announces the list of supported protocols, in this case the list contains one entry: DIN 70121 from 2012 (btw: This is surprising, this nearly brand-new car does not support ISO 15118, only the 10 year old DIN spec). The evse selects the first entry of the list, and the iX3 confirms this message with an TCP ACK. Afterwards it closes actively the TCP connection. |
|
One idea: Maybe the car is confused about the lots of debug messages, which the evse sends as UDP broadcasts. I is worth a try to set udp_syslog_enable = No in pyPlc.ini. |
|
Looks like it doesn't help :(. Yes, BMW announced plug & charge to be available mid 2023, but not for which models... |
|
Does the same setup work with other car types? |
|
On Sunday a friend with a Tesla Model 3 will come over, hopefully that will work, so we know if it's the iX3 or not. |
|
I think I got the point: The iX3 uses SchemaID 0, but others (Tesla, Ioniq) use SchemaID 1. The pyPLC is hardwired to request Schema 1, which of course does not fit to the announcement of the iX3. Updates of the fsmEvse and the openV2Gx are necessary to be more flexible... |
|
OK, and is this a complex thing to change? I have no clue what would be the difference between SchemaID 0 and SchemaID 1 :). P.S.: This is the log from the Tesla. |
|
The SchemaID is just a number. The car just gives a number to each entry in the list of supported protocols, and the charger picks one entry by telling "I want schemaID 1". In this response, the SchemaID is even optional, so the charger is formally allowed to say "I want", without telling a number. I have no idea, whether this works, but if you want to give a try you could search for aphsDoc.supportedAppProtocolRes.SchemaID = 1; in the openV2Gx, and change the number, or, more interesting, change the "isUsed" to 0 and test whether the car is happy with it. |
|
The clean fix would be: Run through the list of announced protocols, extract the protocol and SchemaID of each entry, find the DIN entry, take the SchemaID of this entry, and send it to the car. |
Hi, I'm following along the manual at https://github.com/uhi22/pyPLC/blob/master/doc/installation_on_raspberry.md
I ignored it and continued steps, since this step worked for me:
seeing some data but seeing "[EVSE] re-initializing fsmEvse due to broken connection"
Any ideas about this?
[21472ms] connection closed
[21477ms] [EVSE] re-initializing fsmEvse due to broken connection
[21477ms] [EVSE] re-initializing fsmEvse
The text was updated successfully, but these errors were encountered: